03. 🛡️ 타입스크립트 고급 타입 설계와 추론

📌 이 면접 항목의 목표

⏱️ 예상 읽기 시간: 20분 (핵심 요약: 10분)

🗺️ 이 챕터의 흐름
[개념 사전] → [질문 1: 컴포넌트 다형성 설계] → [질문 2: 조건부 타입 & infer] → [연관 변형 질문]

🎯 이 챕터를 다 읽으면 할 수 있는 것

• 유니언과 교차 타입을 활용해 결합도가 낮고 안전한 Props를 설계할 수 있습니다.
• Conditional Types와 infer를 사용해 복잡한 라이브러리 수준의 유틸리티 타입을 구현합니다.
• any 대신 unknown과 satisfies를 써야 하는 상황을 논리적으로 설명합니다.

📚 핵심 개념 사전 (Concept Glossary)

1. 제네릭 (Generics)

타입을 마치 함수의 파라미터처럼 사용하는 기술입니다. 선언 시점이 아니라 사용 시점에 타입을 확정하므로, 재사용성이 높으면서도 타입 정보를 잃지 않는 설계가 가능합니다.

2. 조건부 타입 (Conditional Types)

T extends U ? X : Y 형태로, 타입 시스템 내에서 '조건문'을 실행하는 기술입니다. 입력 타입에 따라 결과 타입을 동적으로 결정할 때 필수적입니다.

3. infer 키워드

조건부 타입 내에서 추론할 타입에 이름을 붙이는 마법 같은 키워드입니다. 예를 들어, 함수의 리턴 타입이나 배열의 요소 타입을 런타임이 아닌 타입 엔진 단에서 뽑아낼 때 사용합니다.

🗺️ 이 문서의 배경 세계관: '영수네 커뮤니티'

• 🐣 영철 ( 신입 ): "영호 님! '영수네 통합 버튼' 컴포넌트를 만드는데, <a> 태그로 쓰일 때랑 <button>으로 쓰일 때 Props 타입을 다르게 주기가 너무 힘들어요. 그냥 any 박으면 안 될까요? 😅"
• 🦁 영호 ( 리드 ): "영철 님, any를 박는 순간 타입스크립트를 쓰는 의미가 사라집니다. 그건 '안전 벨트를 자르고 운전하겠다'는 소리예요. 유니언 타입과 제네릭만 있으면 훨씬 우아하게 해결할 수 있는데 말이죠. 면접에서 이런 '설계 고민'을 보여줘야 시니어로 인정받는 겁니다."

Q1. 유니언 타입과 교차 타입을 활용하여 컴포넌트의 props 다형성을 안전하게 설계하는 방법을 설명해 보세요.

🎯 출제 의도

단순히 interface를 정의하는 수준을 넘어, 서로 배타적인 속성 관계를 타입으로 강제할 수 있는지(Discriminated Unions) 설계 역량을 확인합니다.

🐣 영철이의 Naive 구현 (Bad Case)

영철이는 모든 속성을 옵셔널(?)로 만들어서 발생할 수 있는 런타임 에러를 방지하지 못했습니다.

// 🐣 영철: "있는 것만 쓰면 되니까 다 옵셔널로 하면 편하겠죠?"
interface ButtonProps {
  label: string;
  onClick?: () => void; // 버튼일 때 필수
  href?: string;        // 링크일 때 필수
}
 
// ⚠️ 버그 발생: href가 없는데 링크로 동작하거나, onClick이 없는데 버튼인 경우를 막지 못함
<Button label="클릭" /> // 아무 동작 안 함

🦁 영호의 팩폭 조언
"영철 님, 이렇게 짜면 사용자는 문서를 다 읽어야만 이 컴포넌트를 쓸 수 있어요. 타입 시스템이 '이건 버튼이니까 href는 넣지 마!'라고 말해줘야죠. 이것이 바로 동적 다형성의 핵심입니다."

🦁 영호의 아키텍처 가이드 (Good Case)

영호 리드는 Discriminated Unions를 사용하여 타입이 사용자를 가이드하게 만듭니다.

// 🦁 영호: "타입이 스스로의 용도를 증명하게 하세요."
type BaseProps = { label: string };
 
type ButtonProps = BaseProps & {
  as: 'button';
  onClick: () => void; // 필수
  href?: never;        // 절대 오면 안 됨
};
 
type LinkProps = BaseProps & {
  as: 'a';
  href: string;        // 필수
  onClick?: never;
};
 
type PolymorphicProps = ButtonProps | LinkProps;
 
function CustomButton(props: PolymorphicProps) {
  // ... 구현 로직
}
 
// ✅ 성공: as가 'a'면 자동 완성으로 href를 요구함
<CustomButton as="a" href="/home" label="홈으로" />

📊 레벨별 답변 가이드 (Self-Check)

• Level 1 (Junior): "유니언은 | 기호로 여러 타입 중 하나를 선택하는 것이고, 교차는 &로 타입들을 합치는 것입니다."
• Level 2 (Senior): "유니언 타입을 활용한 Discriminated Union(식별 가능한 유니언) 패턴을 설명합니다. 공통 속성(tag, as 등)을 리터럴 타입으로 두어 컴파일러가 타입을 좁힐 수 있게 설계하는 실무 사례를 제시합니다."
• Level 3 (Specialist): "제네릭을 활용한 Polymorphic Component 설계 기법을 설명합니다. HTML 태그 종류에 따라 자동으로 IntrinsicElements 타입을 매핑해주어, 커스텀 컴포넌트가 브라우저 표준 속성까지 완벽하게 지원하도록 만드는 고도화된 설계를 제안합니다."

Q2. 조건부 타입(Conditional Types)과 infer 키워드를 활용하여 복잡한 유틸리티 타입을 직접 구현해 본 경험을 설명해 보세요.

🎯 출제 의도

타입스크립트 엔진의 내부 동작 원리를 깊이 이해하고 있는지, 라이브러리 수준의 복잡한 타입을 제어할 수 있는 '타입 엔지니어링' 능력을 확인합니다.

🐣 영철이의 Naive 구현 (Bad Case)

영철이는 함수의 리턴 타입을 알아내기 위해 매번 수동으로 타입을 선언하고 있습니다.

// 🐣 영철: "함수를 수정하면 리턴 타입도 수동으로 고쳐야 해서 번거로워요..."
function getUser() {
  return { id: 1, name: '영철' };
}
 
type User = { id: number; name: string }; // ⚠️ 함수가 바뀌면 여기도 고쳐야 함 (싱크 미스 가능성)

🦁 영호의 팩폭 조언
"영철 님, 타입스크립트에게 직접 물어보세요. infer를 쓰면 함수의 배를 갈라(?) 리턴 타입을 직접 꺼내올 수 있습니다. 우리가 쓰는 ReturnType<T> 하드웨어가 바로 이렇게 생겼죠."

🦁 영호의 아키텍처 가이드 (Good Case)

영호 리드가 infer를 사용해 직접 GetReturnType 유틸리티를 만드는 과정을 보여줍니다.

// 🦁 영호: "타입 엔진이 스스로 추론하게 만드세요."
 
// T가 함수라면, 그 리턴 타입을 R로 추론(infer)해서 반환하라!
type MyReturnType<T> = T extends (...args: any[]) => infer R ? R : never;
 
function getBoardAction() {
    return { type: 'CREATE_POST', payload: '오늘도 코딩!' };
}
 
// ✅ 이제 getBoardAction이 바뀌어도 자동으로 추론됨!
type Action = MyReturnType<typeof getBoardAction>;

📊 레벨별 답변 가이드 (Self-Check)

• Level 1 (Junior): "조건부 타입은 타입판 삼항 연산자고, infer는 타입을 추론할 때 씁니다."
• Level 2 (Senior): "infer가 오직 extends 절에서만 사용 가능하다는 제약을 알고 있으며, Promise의 내부 값 타입을 꺼내거나 배열의 첫 번째 요소 타입을 추출하는 구체적인 예시를 들어 설명합니다."
• Level 3 (Specialist): "분산 조건부 타입(Distributive Conditional Types)의 특성을 이해하고, 유니언 타입이 들어왔을 때 어떻게 동작하는지 설명합니다. 이를 활용해 특정 속성만 제거하는 Omit이나 Exclude 같은 유틸리티 타입이 내부적으로 어떻게 재귀적으로 동작하는지 논리적으로 분석합니다."

🔗 실전 변형 질문 (Related Variations)

Q9. 타입스크립트에서 컴파일 타임에 제네릭(Generics)의 타입 추론 메커니즘이 어떻게 동작하나요?

• 🎯 출제 의도: 제네릭이 단순히 타입을 복사-붙여넣기 하는 수준을 넘어, 컴파일러가 어떻게 데이터의 흐름으로부터 타입을 역추론(Inference)하는지 심도 있게 파악합니다.
• 💡 핵심 원리 & 답변: 타입스크립트 컴파일러는 함수에 전달된 실제 인자(Value)의 타입을 보고, 그와 매칭된 제네릭 타입 변수(T 등)를 결정합니다. 이를 '타입 인수 추론'이라 합니다. 만약 인자가 여러 개라면 각 인자의 공통 분모(LUB, Least Upper Bound)를 찾아 타입을 좁힙니다. 개발자가 명시적으로 타입을 적지 않아도 되는 이유는 컴파일러가 하향식(Top-down) 및 상향식(Bottom-up) 추론을 병행하여 가장 구체적인 타입을 찾아내기 때문입니다. 이 메커니즘을 이해하면 불필요한 타입 단언 없이도 안전한 코드를 짤 수 있습니다.

Q23. unknown 타입을 사용하여 안전하게 데이터를 캐스팅하는 전략을 설명해 보세요.

• 🎯 출제 의도: any라는 치트키 대신, 타입 시스템을 존중하며 불확실한 데이터를 다루는 '안전한 방어 프로그래밍' 역량을 확인합니다.
• 💡 핵심 원리 & 답변: unknown은 any와 마찬가지로 모든 값을 받을 수 있는 '최상위 타입'이지만, any와 결정적인 차이가 있습니다. unknown 타입의 변수는 그 안에 무엇이 들어있는지 타입 가드(typeof, instanceof 등)로 명확히 검증하기 전까지는 어떠한 속성 접근이나 연산도 허용되지 않습니다. 즉, 개발자에게 "이 값은 위험할 수 있으니 먼저 확인하고 써!"라고 컴파일러가 강제하는 것입니다. 외부 API 응답이나 사용자 입력처럼 신뢰할 수 없는 데이터는 반드시 unknown으로 선언하고 런타임 체크를 거친 뒤 사용하는 것이 모던 타입스크립트의 표준 정석입니다.

Q24. satisfies 연산자가 도입된 이유와, as 타입 단언 방식과의 차이는 무엇인가요?

• 🎯 출제 의도: 타입스크립트 4.9+ 버전의 최신 기능을 이해하고, 객체의 정밀한 타입 정보(Literal Identity)를 잃지 않으면서도 명세와 일치하는지 검증하는 고급 기술을 확인합니다.
• 💡 핵심 원리 & 답변: as는 컴파일러에게 "내가 맞으니까 입 다물어"라고 강요하는 '타입 단언'이며, 속성 이름 오타 등이 있어도 잡아내지 못할 수 있습니다. 반면 satisfies는 특정 인터페이스를 만족하는지 검사하면서도, 해당 객체의 구체적인 리터럴 정보를 그대로 유지합니다. 예를 들어 색상 객체에 Record<string, string>을 satisfies하면, 각 색상 이름이 무엇인지(예: 'red')를 타입 엔진이 기억하므로 나중에 오타 검사가 가능해집니다. 명시적 타입 선언보다 훨씬 유연하고 강력한 정적 분석을 가능하게 합니다.

🐣 영철이의 복기 일기

오늘 infer라는 녀석을 처음 만났는데, 클래스의 생성자 인자 타입까지 뽑아내는 걸 보고 소름 돋았다. 그동안 any로 대충 때우며 "어차피 내가 아는 타입인데 뭐!"라고 생각했던 과거의 나를 반성한다. 타입스크립트는 단순한 검사기가 아니라, 코드를 더 견고하게 만들어주는 훌륭한 설계 도구였다.

💡 "타입은 문서다. 어떤 값을 넣어야 하고 무엇이 나오는지 사용자가 고민하게 만들지 마라."

내일은 리액트의 심장, '렌더링 엔진'을 파헤쳐보기로 했다. 영호 님이 "Fiber 아키텍처 모르면 5년 차라고 하지 마라"고 하셨는데... 떨린다! 💓