TypeScript 7.0, 네이티브 컴파일러 전환으로 무엇이 달라지나

프로젝트가 커질수록 타입 체크와 빌드 시간이 개발 속도를 갉아먹는다는 불만은 TypeScript를 쓰는 팀이라면 한 번쯤 겪어봤을 것이다. 캐시를 아무리 잘 구성해도 대규모 코드베이스에서는 저장 후 에러가 뜨기까지 걸리는 시간이 체감상 길게 느껴진다. TypeScript 7.0은 이 문제를 컴파일러 자체를 새로 만드는 방식으로 접근했다.

무엇이 근본적으로 바뀌었나

JavaScript 기반에서 네이티브 코드로

기존 TypeScript 컴파일러는 JavaScript로 작성되어 Node.js 위에서 동작했다. 7.0은 같은 기능과 동작 방식을 유지하면서 컴파일러 자체를 Go 언어로 새로 작성해, 하드웨어 성능을 훨씬 직접적으로 활용할 수 있게 만들었다. 언어 문법이나 타입 시스템이 바뀐 게 아니라, 그 문법을 처리하는 엔진 자체를 교체한 셈이다.

체감할 수 있는 성능 차이

공개된 실측 결과를 보면 실제 오픈소스 프로젝트 기준으로 빌드 시간이 8배에서 12배가량 줄었고, 메모리 사용량도 두 자릿수 비율로 감소했다. 특히 에디터에서 코드를 저장한 뒤 첫 에러가 표시되기까지 걸리는 시간이 십수 초에서 1초 남짓으로 줄었다는 결과는, 매일 반복되는 저장-확인 루프의 체감 속도에 직접 영향을 준다.

기존 언어 기능과의 호환성

주목할 점은 컴파일러 엔진을 완전히 새로 짰음에도 기존 문법과 타입 시스템의 동작 논리는 그대로 유지하려 했다는 점이다. 즉 새로운 문법을 배우거나 타입 선언 방식을 바꿀 필요는 없고, 같은 코드를 훨씬 빠른 엔진으로 처리하게 되는 셈이다. 다만 엔진이 바뀌면서 일부 세부 동작(유니코드 문자 처리 방식 등)이 예전보다 정확해진 부분도 있어, 아주 드물게 기존에는 통과하던 코드가 새로 오류로 잡히는 경우도 있을 수 있다.

실제 적용 팁

바로 전환하지 말고 병행 사용부터 시작하기

기존 6.0에서 문제없이 컴파일되던 코드는 대체로 7.0에서도 동일하게 동작한다고 알려져 있지만, 6.0의 새 기본값을 그대로 물려받기 때문에 프로젝트마다 설정을 다시 점검할 필요가 있다. 두 버전을 동시에 설치해 쓸 수 있는 방법이 제공되므로, 메인 브랜치를 곧바로 옮기기보다 별도 브랜치나 CI 잡에서 먼저 빌드해보고 결과를 비교하는 편이 안전하다.

설정 파일의 기본값 변화를 먼저 점검하기

루트 디렉터리나 타입 패키지 목록처럼 이전에는 자동으로 추론되던 값들이 이제 명시적으로 지정해야 하는 항목으로 바뀐 부분이 있다. 마이그레이션 전에 tsconfig의 각 옵션이 새 기본값에서 어떻게 해석되는지 하나씩 확인하고, 필요하면 명시적으로 값을 채워 넣는 작업을 먼저 끝내두는 편이 이후 빌드 오류를 줄인다.

빌드 도구 체인의 호환 여부 확인하기

번들러 로더나 다른 언어 확장을 지원하는 도구 중 일부는 아직 새 컴파일러의 프로그래밍 인터페이스를 지원하지 않아 당분간 이전 버전에 의존해야 한다. 프로젝트에서 쓰는 빌드 체인이 이런 도구에 의존하고 있다면, 전체 전환보다는 타입 체크 단계만 먼저 새 컴파일러로 옮기고 번들링은 기존 도구 체인을 유지하는 절충안도 고려할 만하다.

CI 파이프라인부터 먼저 옮겨보기

로컬 개발 환경보다 CI 환경에서 먼저 새 컴파일러를 적용해보면 위험 부담이 적다. CI에서 병렬로 두 버전을 돌려 빌드 시간과 오류 개수를 비교해보고, 문제가 없다고 확인된 뒤에 팀 전체 로컬 환경으로 전환하는 순서를 밟으면 예상치 못한 문제가 개발자 각자의 로컬 환경에서 산발적으로 터지는 상황을 피할 수 있다.

주의할 점

오래된 문법이나 특정 모듈 해석 방식처럼 이번 버전에서 지원이 끊긴 옵션들이 있으므로, 오래 유지보수된 프로젝트일수록 설정 파일 전체를 한 줄씩 검토하는 과정이 필요하다. 또한 성능 개선폭은 프로젝트 규모와 코드 구조에 따라 달라질 수 있으므로, 공개된 수치를 그대로 자신의 프로젝트에 대입하기보다는 실제로 한 번 빌드해보고 차이를 직접 측정해보는 편이 정확하다.

정리

TypeScript 7.0은 문법이 아니라 컴파일러 엔진 자체를 바꿔 눈에 띄는 성능 향상을 가져온 릴리스다. 다만 기본값 변화와 일부 도구의 호환성 문제 때문에 곧바로 전면 전환하기보다는, 별도 브랜치에서 먼저 빌드해보고 설정 파일을 점검한 뒤 단계적으로 옮기는 접근이 실무에서는 더 안전하다.