TypeScript 7.0 출시 — Go 네이티브 전환으로 빌드가 10배 빨라진다

TypeScript 7.0이 Go 언어로 작성된 네이티브 컴파일러 프로젝트 코사(Project Corsa)로 완전히 전환되었습니다. Microsoft 공식 개발 블로그에 따르면 싱글 스레드로 작동하던 기존 Node.js 환경의 제약을 극복하고 멀티스레딩을 극대화하여 빌드 속도를 평균 10배가량 단축했습니다. 이번 아키텍처 개편이 가져온 핵심적인 작동 원리 변화와 함께 실무 적용 과정에서 고려해야 할 마이그레이션 전략을 소개합니다.

Project Corsa: 왜 Rust가 아닌 Go를 선택했을까?

최근 웹 생태계의 많은 도구가 Rust로 재작성되는 흐름 속에서, Microsoft의 TypeScript 개발팀이 '프로젝트 코사'의 언어로 Go를 선택한 것은 철저히 아키텍처의 호환성과 생산성을 고려한 결정이었습니다. 가장 큰 이유는 기존 TypeScript 컴파일러가 지닌 복잡한 추상 구문 트리(AST)와 심볼 그래프 구조를 Go의 객체 및 포인터 모델로 일대일 매핑하기가 가장 직관적이었기 때문입니다. 서로를 가리키는 순환 참조 그래프 구조가 많은 컴파일러 특성상, 엄격한 소유권 검사를 수행하는 Rust보다 가비지 컬렉션을 제공하는 Go가 이식 작업에 훨씬 적합했습니다.

컴파일러 설계의 핵심인 메모리 관리 측면에서도 가비지 컬렉터의 존재가 결정적이었습니다. 수천만 개의 구문 노드와 복잡한 타입을 끊임없이 생성하고 해제해야 하는 타입 체킹 과정에서 수동으로 메모리를 관리하는 일은 개발 생산성을 저해하는 걸림돌이 됩니다. C++나 Rust 대신 Go를 선택함으로써 개발팀은 수동 메모리 오버헤드를 제어하는 고통에서 벗어나, 기존 자바스크립트 컴파일러와의 완벽한 시맨틱 일관성을 확보하는 데 역량을 집중할 수 있었습니다.

멀티코어 환경을 활용한 병렬 처리 구조 역시 Go의 고루틴과 공유 메모리 모델 덕분에 안정적으로 안착했습니다. TypeScript 7.0은 이러한 병렬 아키텍처를 바탕으로 워커 스레드 개수를 미세하게 조율하는 --checkers 옵션과, 멀티프로젝트 모노레포를 고속으로 병렬 빌드하는 --builders 옵션을 새롭게 추가했습니다. 여기에 Go 환경으로 새롭게 포팅한 파셀(Parcel)의 파일 감시 엔진을 내장하여 개발 서버의 파일 변경 감지 속도까지 비약적으로 개선했습니다.

VS Code 팀의 마이그레이션 지표와 새로운 설정

가장 거대한 TypeScript 코드베이스 중 하나를 다루는 Visual Studio Code 개발팀의 마이그레이션 결과는 매우 인상적입니다. 개발팀의 발표에 따르면, 기존 Node.js 컴파일러 환경에서 125.7초가 소요되던 타입 체크 시간이 TypeScript 7.0 도입 이후 10.6초로 단축되었습니다. 에디터 프로젝트 로드 시간 역시 기존 9.6초에서 1.2초 미만으로 극적인 성능 향상을 기록했습니다.

이러한 아키텍처 전환 덕분에 자동 완성, 자동 임포트, 참조 찾기처럼 개발 중에 가장 자주 사용하는 기능들이 지연 없이 즉시 반응합니다. 개발 생산성에 직접적인 영향을 주는 언어 서비스 성능이 완전히 새로운 차원으로 올라선 셈입니다.

현재 VS Code에서는 TypeScript 7 전용 확장 프로그램을 설치하면 새로운 언어 서버가 기본으로 활성화됩니다. 명령 팔레트의 “Enable/Disable TypeScript 7 Language Server” 명령으로 TypeScript 6과 7을 전환할 수 있습니다.

설정을 적용하고 에디터를 다시 시작하면 백그라운드에서 실행되는 새로운 엔진이 적용되며, 대규모 모노레포 환경에서도 막힘없는 에디팅 속도를 바로 체감할 수 있습니다.

임시 마이그레이션 장벽: typescript-eslint와 도구 호환성 해결법

TypeScript 7.0은 Go 기반의 네이티브 컴파일러 아키텍처로 완전히 전환되면서 기존의 프로그래매틱 API를 제공하지 않습니다. 이로 인해 컴파일러 내부 API를 직접 호출해 코드 분석을 수행하는 typescript-eslint나 Volar, Svelte, Astro 등의 임베디드 템플릿 검사기가 작동을 멈추는 호환성 문제가 생깁니다. 이 제약은 프로그래매틱 API가 정식 복원될 TypeScript 7.1 전까지 유지되는 과도기적인 장벽입니다.

이를 해결하기 위해 typescript-eslint처럼 typescript 패키지를 직접 가져오는 도구에는 TypeScript 6 호환 패키지를 제공하고, TypeScript 7 컴파일러는 @typescript/native 별칭으로 함께 설치할 수 있습니다.

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@latest",
    "typescript": "npm:@typescript/typescript6@latest"
  }
}

이 설정을 활용하면 typescript-eslint나 외부 프레임워크 린터가 구동될 때만 호환 패키지인 @typescript/typescript6를 바라보게 격리되므로, 7.0 도입으로 인한 정적 분석 오작동 우려를 말끔히 해소할 수 있습니다.

설정 파일 청소: 하드 에러로 전환된 레거시 옵션 목록

TypeScript 7.0은 컴파일러 엔진을 네이티브 코드로 재작성하면서 기존에 유지되던 레거시 옵션들을 대거 제거했습니다. 이전 버전에서 경고 수준에 머물렀던 하위 호환성 전용 설정들이 이제는 빌드 프로세스를 즉시 중단시키는 오류로 처리됩니다. 이는 컴파일러 내부의 불필요한 예외 처리 경로를 줄이고 엔진의 강점인 병렬 처리 속도를 극대화하기 위한 조치입니다.

가장 대표적인 변화는 ES5 지원 중단입니다. 이제 컴파일 속도를 늦추는 구형 브라우저용 변환 코드가 배제되며, 최소 컴파일 대상이 ES2015로 상향 조정되었습니다. 이에 따라 기존의 target: "es5" 설정이나 하위 호환성을 위한 이터레이터 옵션인 downlevelIteration은 더 이상 사용할 수 없습니다. 구형 타겟 컴파일이 꼭 필요한 프로젝트라면 바벨이나 swc 같은 외부 트랜스파일러를 빌드 파이프라인 후속 단계에 배치해야 합니다.

이 외에도 엄격한 타입 검사를 수행하는 strict 옵션이 기본적으로 켜지며, 모듈 해석의 기본 설정도 최신 규격으로 자동 전환됩니다. 컴파일 속도 향상을 방해하던 수많은 과거의 유산이 정리된 만큼, 최신 컴파일 환경에 맞춰 설정을 가볍게 유지해야 안정적인 빌드 속도를 얻을 수 있습니다.

TypeScript 7.0 도입 타이밍 설계하기

TypeScript 7.0이 선사하는 압도적인 성능 향상은 매우 매력적이지만, 생태계가 완전히 정착하기까지는 약간의 유예 기간이 필요합니다. 특히 외부 분석 도구나 프레임워크 템플릿 검사기를 복잡한 호환성 우회 설정 없이 안정적으로 연동하고자 한다면, 프로그래매틱 API가 공식 복원될 7.1 버전의 출시를 기다리는 편이 안전합니다. 반면 빌드 속도가 개발 생산성을 극심하게 가로막고 있어 즉각적인 성능 개선이 시급한 대규모 프로젝트라면, 앞서 소개한 호환성 패키지를 도입해 선제적인 마이그레이션을 감행하는 것도 실무적으로 좋은 선택입니다.

참고 링크