TypeScript 타입이 맞지 않을 때

TypeScript의 타입 문제는 한번 터지면 제대로 고치지 않으면 같은 실수를 반복한다. 특히 date, optional, null을 다룰 때 주의가 필요하다.

빌드 에러의 정확한 위치 찾기

컴파일 에러 메시지를 끝까지 읽는다. 어느 파일의 몇 번째 줄에서 뭐가 맞지 않는지 명확하게 나온다. 처음에는 에러가 많아 보이지만 하나씩 해결하면 나머지는 자동으로 사라질 수 있다.

# 타입 확인만 하기 (컴파일 X)
npx tsc --noEmit
# 모든 에러 확인
npm run build

타입 가드 추가하기

API에서 받은 데이터가 항상 같은 형태라고 보장할 수 없다. 런타임에 타입을 확인하는 가드 함수를 만들어야 한다. 특히 optional 필드와 null은 명시적으로 처리한다.

Optional과 Null 구분

value?: string (optional)과 value: string | null (nullable)은 다르다. 첫 번째는 필드 자체가 없을 수 있고, 두 번째는 필드가 있지만 null일 수 있다. API 응답 형태에 맞춰 정확히 정의한다.

실제 응답 확인

API에서 실제로 어떤 구조로 응답하는지 확인한다. Postman이나 curl로 직접 호출해보고, 응답을 TypeScript 타입으로 정의할 때 참고한다.

# 실제 API 응답 확인
curl -s https://api.example.com/data | jq .

타입 정의 리뷰

타입 파일을 다시 읽으면서:

1. 필드가 정말 optional인가
2. 타입이 정확한가 (string vs number)
3. enum 값이 완전한가
4. nested object의 타입은 맞는가

점진적 수정

타입 에러가 많으면 한 번에 다 고치려고 하지 말고 하나씩 처리한다. 파일별로, 함수별로 나눠서 수정하면 실수가 줄어든다.

단위 테스트

타입을 수정한 후 실제로 동작하는지 확인한다. 특히 API 응답 파싱, 데이터 변환, null 처리 부분을 테스트한다.

공유 타입 정의

여러 파일에서 같은 타입을 쓴다면 별도 파일에 정의해두고 재사용한다. 이렇게 하면 타입을 수정할 때 한 곳만 바꾸면 된다.

# 타입 정의 파일
# src/types/api.ts 같은 식으로 분류

이런 방식으로 타입 문제를 다루다 보면 TypeScript의 이점을 제대로 활용할 수 있다. 런타임 에러를 빌드 시에 잡을 수 있다는 게 진짜 가치다.