← 전체 글로 돌아가기

TypeScript

에러 타입을 구분하면 디버깅이 훨씬 쉬워진다

런타임 에러, 빌드 에러, 네트워크 에러를 명확히 구분하고 기록해두면, 배포 후 문제가 생겼을 때 원인을 빨리 찾을 수 있다.

배포 후 에러가 발생하면 대부분 몇 가지 패턴으로 나뉜다. 에러 종류를 명확히 구분하는 습관을 들이면 디버깅 시간이 확 줄어든다.

TypeScript 타입 에러

빌드 단계에서 잡아야 할 타입 에러가 런타임에 터지는 경우가 있다. 이는 타입 검사 설정이 느슨하거나 any 타입이 많다는 뜻이다.

npm run build
npx tsc --noEmit --strict

--strict 플래그로 엄격한 타입 검사를 하면 대부분의 타입 관련 버그를 사전에 잡을 수 있다.

런타임 에러

타입 체크는 통과했지만 실행 중에 에러가 나는 경우다. 주로 null 체크 누락, 배열 인덱스 범위 초과, 속성 접근 실수다.

// 위험: items가 없을 수도 있음
const firstItem = items[0].name;

// 안전: optional chaining
const firstItem = items?.[0]?.name;

네트워크 에러

API 요청 실패, 타임아웃, CORS 문제 같은 네트워크 관련 에러다. 이들은 환경에 따라 다르게 나타나므로, 배포 환경에서만 발생하는 에러가 많다.

network 에러가 발생했을 때 "요청: GET /api/items, 상태코드: 503, 응답시간: 12초" 같이 자세히 기록해두면, 동일한 패턴의 에러가 나중에 생겼을 때 즉시 대응할 수 있다.