TypeScript 실무 효율을 200% 높이는 유틸리티 타입 핵심 정리

🎯 타겟 독자: TypeScript를 사용하지만 매번 interface를 새로 만드는 것이 귀찮은 프론트엔드/백엔드 개발자, 중복 코드를 줄이고 타입 안정성을 높이고 싶은 실무자.


📝 요약: TypeScript의 Utility Types는 기존 타입을 변형하여 새로운 타입을 만들어내는 강력한 기능입니다. 이 글에서는 실무에서 가장 빈번하게 사용되는 Pick, Omit, Partial, Record의 정확한 사용법과, 이를 조합하여 API 요청/응답 타입을 효율적으로 관리하는 패턴을 소개합니다.

타입스크립트 유틸리티 타입

1. 왜 유틸리티 타입을 써야 하나요?

개발을 하다 보면 하나의 User 인터페이스가 상황에 따라 조금씩 다르게 필요할 때가 있습니다.

  • 회원가입 시: ID와 생성일은 필요 없음 (아직 안 만들어졌으니까)
  • 프로필 수정 시: 이메일은 수정 불가 (Readonly 필요)
  • 목록 조회 시: 비밀번호 필드는 제외 (보안상)

이때마다 UserSignupDto, UserUpdateDto를 일일이 새로 만드는 것은 중복이며 유지보수의 악몽입니다. 유틸리티 타입을 쓰면 원본 타입 하나로 모든 파생 타입을 만들어낼 수 있습니다.

2. 필수 유틸리티 타입 Best 4

① Pick <Type, Keys> : 쏙쏙 골라내기

거대한 타입에서 필요한 몇 가지 속성만 선택해서 새로운 타입을 만듭니다.

interface User { id: number; email: string; username: string; admin: boolean; } // 로그인 화면에는 이메일과 비밀번호만 필요함 type UserLogin = Pick<User, "email" | "password">; // 결과: { email: string; password: string; }

② Omit <Type, Keys> : 콕 집어 빼기

Pick의 반대입니다. 특정 속성만 제거하고 나머지는 다 가져옵니다.

// 클라이언트에 내려줄 때 민감한 정보 제외 type UserResponse = Omit<User, "password" | "admin">; // 결과: { id: number; email: string; username: string; }

③ Partial <Type> : 모두 선택 사항으로

모든 속성을 Optional (?) 상태로 만듭니다. 주로 PATCH(수정) API 요청 타입에 쓰입니다.

// 일부 정보만 수정할 수 있으므로 모든 필드가 선택 사항 type UpdateUserDto = Partial<User>; // 결과: { id?: number; email?: string; ... }

④ Record <Keys, Type> : 객체 사전 만들기

키(Key)와 값(Value)의 타입이 고정된 객체(Dictionary/Map)를 정의할 때 가장 깔끔합니다.

type Role = "admin" | "user" | "guest"; // 각 역할별 권한 페이지 목록 정의 const permissions: Record<Role, string[]> = { admin: ["settings", "users"], user: ["mypage"], guest: ["login"] // "manager" 같은 엉뚱한 키를 넣으면 에러 발생! };

3. 실무 응용 패턴 (조합해서 쓰기)

유틸리티 타입은 중첩해서 쓸 때 진가를 발휘합니다.

예를 들어, "회원 정보를 수정하되, ID는 수정 못 하고, 나머지 필드는 선택적으로 보내도 된다"는 요구사항을 코드로 표현하면 다음과 같습니다.

// 1. Omit으로 'id' 제거 (수정 불가 필드 제거) // 2. Partial로 나머지 필드를 모두 Optional로 변경 type UserUpdatePayload = Partial<Omit<User, "id">>; /* 결과 타입: { email?: string; username?: string; admin?: boolean; // id는 아예 존재하지 않음 } */

4. 결론

TypeScript의 유틸리티 타입을 잘 활용하면 "단 하나의 진실된 타입(Single Source of Truth)"을 유지할 수 있습니다.

원본 인터페이스인 User가 바뀌면, Pick이나 Omit으로 파생된 DTO들도 자동으로 같이 바뀝니다. 코드를 복사-붙여넣기 하지 마세요. 타입에게 계산을 맡기세요.

이 블로그의 인기 게시물

Docker 컨테이너 'Connection Refused' (Errno 111) 오류 해결 가이드

이미지
🎯 타겟 독자: Docker 입문자, 컨테이너를 띄웠으나 localhost 로 접속이 안 되는 백엔드 개발자, MSA(마이크로서비스) 구축 중 통신 오류를 겪는 엔지니어. 📝 요약: Docker 접속 오류(Errno 111)의 90%는 애플리케이션이 '0.0.0.0'이 아닌 '127.0.0.1' 로 바인딩 되어 있거나, 포트 포워딩(-p) 설정이 누락되어 발생합니다. 이 글에서는 네트워크 인터페이스의 차이를 이해하고, 외부 접속을 허용하는 올바른 설정법을 정리합니다. 1. 문제 정의: "컨테이너는 떴는데 접속이 안 돼요" Docker 입문자들이 가장 흔하게 겪는 상황입니다. docker ps 로 확인하면 상태(STATUS)는 분명히 Up 인데, 브라우저나 Postman으로 접속하면 즉시 연결이 거부됩니다. curl: (7) Failed to connect to localhost port 8080: Connection refused Python: ConnectionRefusedError: [Errno 111] Connection refused 이 문제는 방화벽 때문이 아닙니다. "누구의 요청을 들을 준비가 되었는가(Listen Address)" 에 대한 설정이 잘못되었기 때문입니다. 2. 원인 분석: 127.0.0.1의 함정 핵심은 Loopback(127.0.0.1) 과 Any Address(0.0.0.0) 의 차이입니다. 로컬 PC에서 개발할 때 서버를 localhost 로 띄우는 건 보안상 좋은 습관입니다. 하지만 Docker 컨테이너는 독립된 IP를 ...
자세한 내용 보기

Redis 캐싱 전략 완벽 가이드: Look Aside부터 Write Back까지 (DB 부하 줄이기)

이미지
🎯 타겟 독자: 사용자가 몰릴 때마다 DB CPU가 100%를 치는 상황을 겪는 백엔드 개발자, Redis를 단순히 get/set 으로만 쓰고 있는 주니어 엔지니어. 📝 요약: 캐시(Cache)는 성능 향상의 치트키지만, 잘못 쓰면 데이터 불일치(Inconsistency) 라는 재앙을 부릅니다. 이 글에서는 가장 대중적인 Look Aside(Lazy Loading) 패턴과 쓰기 성능을 극대화하는 Write Back 패턴의 작동 원리, 장단점, 그리고 언제 무엇을 써야 하는지 명확한 기준을 제시합니다. 1. 캐싱 패턴이 왜 중요한가요? "그냥 Redis에 넣으면 되는 거 아닌가요?"라고 묻는다면 반은 맞고 반은 틀립니다. 캐시를 데이터베이스(DB)와 어떤 순서로 연동하느냐에 따라 시스템의 데이터 정합성 과 성능 이 완전히 달라지기 때문입니다. 2. 패턴 ① Look Aside (Lazy Loading) - 국룰 전략 현업에서 80% 이상 사용되는 가장 일반적인 읽기 전략입니다. 캐시를 옆(Aside)에 두고 필요할 때만 데이터를 가져옵니다. 작동 순서 앱이 데이터를 찾을 때 먼저 캐시(Redis)를 찌릅니다. 캐시에 데이터가 있으면(Cache Hit) 바로 반환합니다. (DB 부하 0) 없으면(Cache Miss) DB에서 조회 하여 가져옵니다. 가져온 데이터를 캐시에 저장 하고 반환합니다. public User getUser(Long id) { // 1. 캐시 조회 User user = redisTemplate.opsForValue().get("user:" +...
자세한 내용 보기

브라우저 렌더링 원리: Reflow와 Repaint 최적화 가이드 (CRP 심층 분석)

이미지
📌 핵심 요약 CRP(Critical Rendering Path) 의 5단계: DOM → CSSOM → Render Tree → Layout → Paint 성능의 주범 Reflow(Layout) 와 Repaint 의 차이점 애니메이션 성능 최적화: 왜 top/left 대신 transform 을 써야 하는가? (GPU 가속과 Composite) "사용자가 주소창에 URL을 입력하고 엔터를 쳤을 때, 화면에 네이버 메인이 뜨기까지 무슨 일이 일어나는가?" 이 질문은 네트워크 관점(DNS, TCP/IP)에서도 답변할 수 있지만, 프론트엔드 개발자라면 렌더링 엔진(Rendering Engine)이 HTML과 CSS를 해석해서 픽셀로 바꿔주는 과정, 즉 CRP(Critical Rendering Path)를 설명할 수 있어야 합니다. 이 원리를 알아야 "왜 리액트가 Virtual DOM을 쓰는지", "왜 애니메이션이 버벅이는지" 이해할 수 있습니다. 1. 렌더링 파이프라인 (The Pipeline) 브라우저는 다음 5단계를 거쳐 화면을 그립니다. DOM 트리 생성: HTML 문서를 파싱 하여 태그 간의 관계(부모-자식)를 트리 구조로 만듭니다. CSSOM 트리 생성: CSS 파일과 인라인 스타일을 파싱 하여 스타일 규칙 트리를 만듭니다. Render Tree 생성: DOM과 CSSOM을 결합하여 "실제로 화면에 표시될 노드" 만 추려냅니다. Layout (Reflow): 각 노드가 화면의 어느 위치에, 어떤 크기(px) 로 배치될지 기하학적 계산을 수행합니다. ...
자세한 내용 보기