핵심 요약
"Type X is not assignable to type Y"는 대부분 ① union을 안 좁혔거나 ② 리터럴이 넓은 타입으로 추론됐거나 ③ 객체 형태가 미세하게 다를 때 난다. 에러 메시지의 마지막 줄("... is missing the following properties" 등)이 진짜 원인을 알려준다.
1. 패턴별 해결
| 상황 | 해결 |
|---|---|
| string이 'a'|'b'에 안 맞음 | as const 또는 union으로 좁히기 |
| 객체 프로퍼티 누락/초과 | 선택적(?)·정확한 형태로 맞춤 |
| undefined 가능성 | 옵셔널 체이닝/가드로 좁히기 |
| any로 새는 외부 데이터 | zod 등으로 파싱·검증 |
2. 자주 통하는 한 줄
// 리터럴이 string으로 넓어질 때
const role = 'admin' as const // 'admin' 리터럴 유지
const cfg = { mode: 'dark' } as const // 전체 readonly 리터럴
// union 좁히기
if (typeof x === 'string') { x.trim() }3. 함정
as Y강제 캐스팅은 에러만 숨긴다 — 런타임에 터진다. 정말 안전할 때만- 함수 타입은 매개변수가 반공변 — 콜백 시그니처 불일치가 헷갈리는 원인
any는 전염된다. 경계(외부 입력)에서 한 번 검증하고 내부는 타입 유지
자주 묻는 질문
그냥 as로 캐스팅하면 안 되나요?
컴파일 에러는 사라지지만 타입 안전성도 사라집니다. 실제로 형태가 보장될 때만 쓰고, 외부 데이터는 zod 같은 런타임 검증으로 좁히는 게 안전합니다.
"excess property" 에러는 왜 객체 리터럴에서만 나나요?
객체 리터럴을 직접 할당할 때만 초과 프로퍼티를 엄격히 검사합니다. 변수를 거치면 통과하는데, 이는 의도치 않은 오타를 잡으려는 설계입니다.
댓글 0