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는 정말 경계가 불분명한 곳에서 마지막으로 쓰는 선택지예요. 버튼과 링크처럼 가능한 조합이 정해져 있다면 타입이 그 조합을 안내하게 만들 수 있습니다. 면접에서는 이 설계 판단을 보여주는 게 중요해요."

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

🎯 출제 의도

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

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

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

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

🦁 영호의 리뷰 포인트
"영철 님, 이렇게 짜면 사용자는 문서를 다 읽어야만 올바른 조합을 알 수 있어요. 타입 시스템이 '버튼이면 onClick이 필요하고, 링크면 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="홈으로" />

never는 "이 props는 이 모드에서 오면 안 된다"는 금지 조건을 표현합니다. 덕분에 컴포넌트 사용자는 런타임에서 클릭해 보기 전에 편집기와 컴파일러 단계에서 잘못된 조합을 확인할 수 있습니다.

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

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

면접 질문 2. 조건부 타입(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>;

이 방식은 타입 선언을 없애는 기술이 아니라 런타임 함수와 타입 선언이 서로 어긋날 가능성을 줄이는 기술입니다. API 응답 파서, 액션 생성 함수, 폼 스키마처럼 한쪽이 바뀌면 다른 쪽도 따라가야 하는 코드에서 특히 효과가 큽니다.

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

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

🔗 실전 변형 질문 (Related Variations)

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

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

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

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

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

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

📝 마무리 퀴즈

Q1. ButtonProps에서 href?: string, onClick?: () => void처럼 전부 optional로 두면 왜 위험한가요?

✅ 정답: 타입이 버튼 모드와 링크 모드의 필수 조건을 강제하지 못해 런타임에서 의미 없는 조합이 허용되기 때문

💡 상세 해설:

• 원리 설명: 다형성 컴포넌트는 "쓸 수 있는 props"보다 "같이 오면 안 되는 props"를 타입으로 표현해야 안전합니다. Discriminated Union과 never는 그 경계를 컴파일 타임에 드러냅니다.
• 오답 피드백: optional을 많이 쓰면 유연해 보이지만, 실제로는 문서만 믿고 써야 하는 불안정한 API가 됩니다.
• 📌 핵심 기억법: 좋은 타입은 허용보다 금지를 더 분명히 말합니다.

Q2. infer를 활용한 유틸리티 타입을 설명할 때 핵심은 무엇인가요?

✅ 정답: 조건부 타입의 extends 절에서 타입의 일부를 추론해 재사용 가능한 결과 타입으로 꺼내는 방식

💡 상세 해설:

• 원리 설명: infer는 런타임 값을 꺼내는 문법이 아니라 타입 패턴 매칭입니다. 함수 리턴 타입, Promise 내부 타입, 배열 요소 타입처럼 "타입 구조 안쪽"을 안전하게 꺼냅니다.
• 오답 피드백: any로 대체하면 당장은 편하지만, 호출부가 바뀌었을 때 타입 정보가 끊겨 컴파일러의 도움을 잃습니다.
• 📌 핵심 기억법: infer는 타입 엔진에게 "여기 이름 붙여줘"라고 부탁하는 문법입니다.

Q3. 영철이의 테스트 타임: 외부 API 응답 타입을 다룰 때 unknown이 any보다 안전한 이유는 무엇인가요?

✅ 정답: 속성 접근 전에 타입 가드나 스키마 검증을 사용해, 불확실한 데이터를 안전하게 좁히게 만들기 때문

💡 상세 해설:

• 원리 설명: 면접에서 unknown을 설명할 때는 "모든 값을 받을 수 있지만, 검증 전에는 쓸 수 없다"는 제약을 말해야 합니다. 이 제약이 런타임 데이터 경계에서 안전망이 됩니다.
• 오답 피드백: as SomeType 단언은 컴파일러를 설득할 뿐 실제 데이터를 검증하지 않습니다.
• 📌 핵심 기억법: 외부 데이터는 먼저 의심하고, 좁힌 뒤 사용합니다.

🐣 영철이의 퇴근 일기

오늘은 타입을 "에러 없애는 장식"처럼 쓰던 습관을 내려놓았다. 영수네 통합 버튼을 만들면서 any 하나면 편해 보였지만, 그 순간 컴포넌트 사용자가 어떤 조합을 넣어도 타입이 침묵한다는 걸 알았다.

💡 "타입은 개발자를 귀찮게 하려고 있는 게 아니라, 미래의 잘못된 사용법을 오늘 막아주는 계약서다."

다음 코드 리뷰에서는 props를 optional로 늘리기 전에 "이 조합이 실제로 가능한가?"부터 물어봐야겠다. 면접에서도 유틸리티 타입 이름을 나열하는 대신, 타입이 사용자에게 어떤 안전한 길만 열어주는지 설명하는 사람이 되고 싶다.