타입이 막아 준 새벽 전화

1. 어젯밤까지 멀쩡하던 화면이 하얗게

웹 개발을 하다 보면 한 번쯤 겪는 장면이 있습니다. 어제까지 멀쩡하던 상품 페이지가 하얗게 비었다는 전화가 새벽에 걸려 오는 거죠. 원인은 허무할 만큼 작습니다. 서버 쪽에서 가격 필드 이름을 price에서 salePrice로 바꿨는데, 화면 코드는 여전히 price를 찾고 있었던 겁니다. 자바스크립트는 없는 값을 만나도 따지지 않고 undefined를 넘겨주고, 그 값에 쉼표를 찍으려는 순간 에러가 나면서 화면 전체가 멈춥니다. 테스트에서 그 페이지를 안 열어 봤다면 사용자가 먼저 발견하게 되고요. 사람이 하는 일이라 이런 실수는 없어지지 않습니다. 그래서 사람보다 먼저 알아챌 장치가 필요합니다.

2. 배포 전에 먼저 울리는 알람

그 장치가 타입스크립트(TypeScript)입니다. 마이크로소프트가 2012년에 공개한 언어로, 자바스크립트에 타입을 얹었습니다. 작년 10월 나온 깃허브 옥토버스 보고서를 보면 2025년 8월 월간 기여자 수 기준으로 타입스크립트가 파이썬과 자바스크립트를 제치고 깃허브 1위 언어가 됐습니다. 데이터의 모양을 타입으로 정해 두면, price를 salePrice로 바꾸는 순간 그 필드를 쓰던 모든 곳에 빨간 줄이 그어지고 빌드가 멈춥니다. 효과가 가장 큰 건 서버와 화면이 같은 타입을 나눠 쓸 때입니다. API 명세에서 타입을 뽑아 쓰거나, Strapi처럼 콘텐츠 구조에서 타입 파일을 만들어 주는 도구를 쓰면 양쪽이 같은 약속을 보게 됩니다.

3. 타입은 실행되는 순간 사라집니다

여기서 많이들 놓치는 부분이 있습니다. 타입스크립트의 타입은 코드가 자바스크립트로 바뀌는 순간 전부 지워집니다. 내 코드끼리 주고받는 값은 지켜 주지만, API 응답이나 사용자가 입력한 폼, 서버 환경 변수처럼 바깥에서 들어오는 값까지 보장하지는 못합니다. 그래서 경계에서 한 번 더 확인하는 도구로 Zod를 많이 함께 씁니다. 데이터가 어떤 모양이어야 하는지 스키마로 한 번 적어 두면, 거기서 타입을 뽑아 쓰고 실제로 들어온 값도 같은 기준으로 검사할 수 있습니다. 값이 어긋나면 화면이 깨지기 전에, 어느 필드가 왜 틀렸는지 적힌 에러가 입구에서 먼저 납니다. 같은 실수라도 어디서 터지느냐에 따라 고치는 시간이 달라지죠.

4. 세컨드펭귄의 시선: 프로젝트는 strict로 시작합니다

타입을 엄격하게 쓰는 데도 비용은 듭니다. 처음엔 타입 에러와 씨름하느라 손이 느려지고, 급할 때는 any 한 단어로 덮어 버리고 싶은 유혹도 생깁니다. 그래도 올해 7월 나온 타입스크립트 7.0은 strict를 아예 기본값으로 두었고, Go로 옮겨 쓴 덕에 전체 빌드가 8~12배 빨라졌다고 합니다. 우리는 Next.js 프로젝트를 strict로 시작하고, 바깥에서 들어오는 값은 경계에서 스키마로 한 번 더 확인합니다. 모르는 값은 any 대신 unknown으로 받아 확인한 뒤에 쓰고요. Next.js 빌드는 타입 검사를 통과하지 못하면 멈추니, 타입 에러가 있는 코드는 배포까지 가지 못합니다. 낮에 조금 느리더라도 새벽 전화가 없는 쪽을 골랐습니다.