TypeScript 타입 단언이 늘어날 때 점검하기

문제를 크게 잡으면 모든 파일이 의심스러워져서 손대기 어려워진다. 타입 안정성 문제도 마찬가지다. 작게 나눠서 확인해야 한다.

사용자 관점과 개발자 관점

TypeScript 타입 문제는 사용자 화면에 직접 보이지 않는다. 하지만 개발자 신호(컴파일 에러, 런타임 타입 불일치)는 명확하다.

사용자가 보는 모습과 개발자가 보는 신호를 구분해야 한다. 타입 가드나 optional 체크가 제대로 되어 있는지 확인하자.

개발자 신호 읽기

TypeScript 문제는 화면만 보고 판단하면 놓치는 값이 많다. 타입 가드가 애매하면 다른 부분을 고쳐도 결과가 안 바뀐다.

• 타입 가드: 값이 정말 그 타입인가?
• optional/null 체크: null일 가능성은 없는가?
• 타입 단언: 정말 이 타입이라고 확신하는가?

빌드와 타입 체크

수정 전에 현재 상태를 정해두자. 정상이 뭔지 알아야 뭐가 비정상인지 판단할 수 있다:

npm run build
npx tsc --noEmit

npm run build에서 성공했다고 해도, tsc --noEmit으로 더 엄격한 타입 체크를 할 수 있다.

수정 전 고정할 값

TypeScript 문제는 로컬과 운영의 차이가 자주 숨어 있다. 같은 코드가 특정 환경에서만 에러를 낼 수도 있다.

각 환경에서 의존성 버전, 타입 정의, 런타임 값이 어떻게 다른지 기록해두면 원인 추적이 쉬워진다.

타입 가드 확인 과정

한 가지만 수정한 후 타입 체크를 다시 실행한다. 에러 개수가 줄었는지, 다른 에러가 생겼는지 관찰한다.

optional/null을 확인하는 순서를 정하자. 비슷한 타입 문제가 반복된다면, 같은 방식으로 접근하면 시간이 단축된다.

빌드 에러 목록 확인

검증 루틴으로 매번 같은 순서를 따르면 문제를 빠르게 찾을 수 있다. 예를 들어:

1. tsc --noEmit로 타입 에러 목록 확인
2. 가장 많이 나타나는 에러부터 수정
3. 한 가지만 수정 후 다시 체크
4. 반복

운영 단계

작은 확인을 남겨두면 다음 문제를 훨씬 짧게 처리할 수 있다. 비슷한 타입 에러가 나중에 다시 생기면, 이전 기록을 참고해서 빠르게 고칠 수 있다.