답변.

타입 가드 — 코드 블록 내에서 변수의 유형을 특정 검사(예: typeof, instanceof 또는 param is SomeType 형태의 표현식을 반환하는 특별한 함수)를 기반으로 세분화할 수 있게 해주는 메커니즘입니다.

주요 장점 — 컴파일 타임 동안 유형 검사를 통해 실행 오류를 방지하고 안전성을 보장합니다.

예제:

interface Fish { swim: () => void }
interface Bird { fly: () => void }

function isFish(pet: Fish | Bird): pet is Fish {
  return (pet as Fish).swim !== undefined;
}

function move(pet: Fish | Bird) {
  if (isFish(pet)) {
    pet.swim();
  } else {
    pet.fly();
  }
}

여기서 함수 isFish는 사용자 정의 타입 가드입니다.

주의 사항:

모든 추가 논리적 검사는 유형화와 밀접하게 관련되어야 합니다.
타입 가드 함수에서 오류가 발생하면 실행 시점에 잘못된 유형 정의로 이어질 수 있습니다.

함정 질문.

질문: "타입스크립트 컴파일러가 항상 가드 함수의 반환값만을 의존하게 되는지, 아니면 함수 내부에서 다른 분석을 사용하는가?"

답변: 타입스크립트 컴파일러는 param is Type 반환값의 시그니처에만 의존합니다. 함수 가드 내부에서 발생하는 일은 구현의 정확성을 검사하지 않습니다.

예제 (위험한 오류!):

function isString(x: any): x is string {
  return true;
}

// 컴파일러는 항상 문자열로 간주하지만 실제로는 아닙니다:
if (isString(123)) {
  // 여기서 x는 문자열 타입이지만 실제로는 숫자입니다
}

주제의 미세한 차이로 인한 실제 오류 사례.

역사

프론트엔드와 백엔드 간 공유 DTO 프로젝트에서 사용자 정의 타입 가드 내에 엄격한 검사를 추가하는 것을 잊어버렸습니다. 결과적으로 일부 데이터가 필요 타입으로 잘못 인식되어, 클라이언트에서 누락된 속성을 사용하려 할 때 충돌이 발생했습니다.

역사

개발자는 선택적 필드를 기반으로 타입 가드를 작성했으나 데이터 구조가 이 필드를 아예 포함하지 않을 수 있었습니다. 결과적으로 타입별 switch-case에서 분기가 누락되어 컴파일러는 경고를 하지 않았고, 런타임에서 예외가 발생했습니다.

역사

하나의 서비스에서 타입스크립트로 전환할 때 내장된 타입 가드(typeof, instanceof)에만 의존했습니다. 실행 중 객체 프로토타입이 변경되면서 검사가 부정확해져, 프로덕션에서 디버깅하기 어려운 버그를 초래했습니다.

타입스크립트의 타입 가드(Type Guards) 메커니즘을 설명하고 사용 예를 제시하십시오. 주요 장점은 무엇이며 사용자 정의 타입 가드 함수를 구현할 때 고려해야 할 주의 사항은 무엇입니까?

답변.

함정 질문.

주제의 미세한 차이로 인한 실제 오류 사례.