네이티브 코드로 포팅 중인 TypeScript 7(프로젝트 Corsa)의 최신 진행 상황과 에디터·컴파일러 지원, 예상 변경 사항, 로드맵을 소개합니다.
2025년 12월 2일
15개의 반응
수석 프로덕트 매니저 (Principal Product Manager)
올해 초, TypeScript 팀은 컴파일러와 언어 서비스를 네이티브 코드로 포팅하고 있다고 발표했습니다. 이는 더 나은 순수 성능, 메모리 사용량, 그리고 병렬성을 활용하기 위함입니다. “Project Corsa”(곧 “TypeScript 7.0”)라는 코드명으로 진행 중인 이 노력은 상당한 규모의 작업이었지만, 지난 몇 달 사이에 큰 진전을 이뤘습니다. 지금 우리가 어디까지 와 있는지, 그리고 오늘날 이 새로운 TypeScript 도구 모음이 얼마나 “실전용” 상태인지에 대해 업데이트를 드리게 되어 기쁩니다.
또한 앞으로의 로드맵과, TypeScript 7.0 작업을 어떻게 우선순위화하여 이 포팅을 마무리하려 하는지에 대한 소식도 전해 드리겠습니다.
많은 개발자에게 대규모 프로젝트 리라이트는 실제로 출시되기 전까지는 이론적인 이야기처럼 느껴질 수 있습니다. 이번에는 그렇지 않습니다.
TypeScript의 네이티브 프리뷰는 현재도 빠르고, 안정적이며, 사용하기 쉽습니다 – 에디터에서까지도 마찬가지입니다.
TypeScript의 언어 서비스(에디터에서 TypeScript 및 JavaScript 기능을 제공하는 요소)는 네이티브 포트 작업의 핵심 부분이며, 간단히 체험해 볼 수 있습니다. Visual Studio Code 마켓플레이스에서 최신 버전을 받을 수 있으며, 이 확장 프로그램은 매일 업데이트됩니다.
팀은 여전히 기능을 포팅하고 자잘한 버그를 수정하고 있지만, 기존 TypeScript 편집 경험을 구성하는 대부분의 요소는 이미 구현되어 있고 잘 동작합니다.
여기에는 다음이 포함됩니다.
이전 주요 업데이트 이후로 눈에 띄는 변화가 몇 가지 더 있다는 점을 알아차리셨을 수 있습니다 – 자동 import, 모든 참조 찾기, 이름 바꾸기 등입니다. 이러한 기능들이 네이티브 프리뷰를 시도하는 것을 망설이게 만들던 빠진 퍼즐 조각이었다는 것을 잘 알고 있습니다. 이제 이 기능들이 재구현되어 일상적인 사용에 적합한 상태가 되었다는 점을 알려드리게 되어 기쁩니다! 이제 이러한 작업은 프로젝트 레퍼런스를 사용하는 코드베이스를 포함하여, 모든 TypeScript 및 JavaScript 코드베이스에서 동작합니다.
또한 공유 메모리 병렬성을 활용하면서도 신뢰성을 개선하기 위해 언어 서비스의 일부를 재설계했습니다. 일부 팀에서는 초기 경험이 때때로 약간 “크래시가 잦다”고 보고했지만, 속도 향상 덕분에 이를 감수하기도 했습니다. 새로운 아키텍처는 훨씬 견고해졌으며, 크고 작은 코드베이스를 가리지 않고 문제 없이 처리할 수 있어야 합니다.
아직 포팅하고 다듬어야 할 부분이 남아 있긴 하지만, 여러분 팀이 TypeScript 네이티브 프리뷰를 시도해 볼 가치는 충분히 있을 것입니다. 더 빠른 로드 타임, 더 적은 메모리 사용량, 그리고 전반적으로 더욱 경쾌하고 반응성 좋은 에디터를 기대하실 수 있습니다.
경험이 마음에 들지 않는다면, 확장 프로그램을 통해 VS Code에 내장된 기존 TypeScript 환경과 새로운 환경 사이를 손쉽게 전환할 수 있습니다. 여러분과 여러분의 팀이 VS Code용 네이티브 프리뷰 확장 프로그램을 오늘 바로 시도해 보시길 진심으로 권장합니다!
TypeScript 컴파일러 역시 네이티브 포트에서 상당한 진전을 이뤄냈습니다. VS Code 확장 프로그램과 마찬가지로, 새 컴파일러의 나이틀리 프리뷰 빌드를 @typescript/native-preview라는 패키지 이름으로 게시해 왔습니다. 다음과 같이 npm을 통해 설치할 수 있습니다.
bash# 로컬 개발 의존성 npm install -D @typescript/native-preview # 전역 설치 npm install -g @typescript/native-preview
이 패키지는 기존 tsc 명령과 유사하게 동작하는 tsgo 명령을 제공합니다. 두 명령은 나란히 사용할 수 있습니다.
자주 받는 질문 중 하나는, TypeScript 7을 사용해 빌드를 검증하는 것이 “안전한가?”입니다. 즉, TypeScript 5.9가 찾아내는 것과 동일한 오류를 신뢰성 있게 찾아낼 수 있는지에 대한 질문입니다.
답은 매우 강력한 예입니다. TypeScript 7의 타입 체크는 거의 완성 단계에 와 있습니다. 참고로, 컴파일러 테스트 케이스는 약 20,000개 정도이며, 그중 약 6,000개는 TypeScript 6.0에서 하나 이상의 오류를 발생시킵니다. 이들 중 74개를 제외한 모든 케이스에서 TypeScript 7 역시 하나 이상의 오류를 발생시킵니다. 남은 74개는 모두 아직 미완성된 작업(예: 정규식 문법 검사나 isolatedDeclarations 오류)과 관련이 있거나, 의도적인 변경(사용 중단, 기본 설정 변경 등)과 관련이 있는 것으로 파악되어 있습니다. 오늘 당장 TypeScript 7을 사용해 프로젝트의 오류를 타입 체크하는 데 자신감을 가져도 됩니다.
단일 패스/단일 프로젝트 타입 체크 이상의 부분에서도, 커맨드라인 컴파일러는 주요 기능에서 상당 부분 기존과 동등한 수준에 도달했습니다. --incremental, 프로젝트 레퍼런스 지원, --build 모드 같은 기능이 모두 포팅되어 동작 중입니다! 이는 대부분의 프로젝트가 최소한의 변경만으로 네이티브 프리뷰를 시도해 볼 수 있다는 뜻입니다.
bash# --build 모드에서 기존 tsc 실행... tsc -b some.tsconfig.json --extendedDiagnostics # --build 모드에서 *새 컴파일러* 실행... tsgo -b some.tsconfig.json --extendedDiagnostics
이 기능들이 단순히 제공되기만 하는 것이 아니라, 기존 TypeScript 5.9 및 그 이전 버전(“Strada 코드베이스”라고도 부름)에 구현된 버전보다 극적으로 더 빠를 것입니다. 앞서 설명한 바와 같이, 이는 부분적으로는 네이티브 코드 성능 덕분이지만, 공유 메모리 병렬성 사용 덕분이기도 합니다. 좀 더 구체적으로 말하면, 이제 TypeScript는 단일 프로젝트에 대해 빠른 멀티스레드 빌드를 수행할 수 있을 뿐만 아니라, 여러 프로젝트를 병렬로 빌드할 수도 있다는 뜻입니다! 여기에 --incremental 재구현을 결합하면, 대규모 프로젝트에서 작은 변경을 빌드할 때 TypeScript 빌드가 거의 순간적으로 느껴지게 만드는 데 근접하고 있습니다.
참고로, --incremental 옵션 없이도, TypeScript 7은 전체 빌드에서 6.0 컴파일러 대비 거의 10배에 가까운 속도 향상을 보이는 경우가 많습니다!
| 프로젝트 | tsc (6.0) | tsgo (7.0) | 차이 | 속도 향상 배수 |
|---|---|---|---|---|
| sentry | 133.08초 | 16.25초 | 116.84초 | 8.19배 |
| vscode | 89.11초 | 8.74초 | 80.37초 | 10.2배 |
| typeorm | 15.80초 | 1.06초 | 14.20초 | 9.88배 |
| playwright | 9.30초 | 1.24초 | 8.07초 | 7.51배 |
새 컴파일러를 사용할 때 유의해야 할 점들이 몇 가지 있습니다. 이들 중 상당수는 7.0 최종 릴리스 이전에 해결할 계획인 시점성 이슈이지만, 일부는 기본 TypeScript 경험을 더 좋게 만들기 위한 장기적인 결정에 따른 것입니다. TypeScript 7.0의 약속을 지키기 위해서는 기존 격차를 줄이고 새로운 툴체인을 더 많은 개발자에게 전달하기 위해 새로운 코드베이스에 역량을 집중해야 합니다. 그에 앞서, 현재의 변경 사항과 제약 사항을 먼저 살펴보겠습니다.
TypeScript 7.0에서는 TypeScript 6.0에서 사용 중단 예정인 동작 및 플래그를 제거할 예정입니다. 현재 이슈 트래커에서 6.0에 예정된 사용 중단 목록을 확인할 수 있습니다. 대표적인 예시는 다음과 같습니다.
--strict가 기본으로 활성화됩니다.--target의 기본값이 최신 안정 ECMAScript 타겟(예: es2025)이 됩니다.--target es5가 제거되며, es2015가 지원되는 최저 타겟이 됩니다.--baseUrl이 제거됩니다.--moduleResolution node10(a.k.a. node)이 제거되고, 대신 bundler 및 nodenext가 권장됩니다.rootDir의 기본값이 현재 디렉터리가 되며, outDir을 사용하는 경우에는 명시적인 rootDir이 필요하거나, 최상위 소스 파일들이 tsconfig.json과 동일한 디렉터리에 있어야 합니다.이 목록이 전부는 아니므로, 이슈 트래커에서 최신 상태를 확인해 주세요. 프로젝트가 이러한 사용 중단된 동작에 의존하고 있다면, TypeScript 7.0과의 호환을 위해 코드베이스나 tsconfig.json에 일부 변경이 필요할 수 있습니다.
팀은 ts5to6라는 도구를 사용해 tsconfig.json을 자동으로 업데이트하는 실험을 진행 중입니다. 이 도구는 extends 및 references에 대한 휴리스틱을 사용해 코드베이스 내 다른 프로젝트 설정도 함께 업데이트하는 것을 돕습니다. 현재는 baseUrl과 rootDir 설정만 업데이트할 수 있지만, 향후 더 많은 항목이 추가될 수 있습니다.
bashnpx @andrewbranch/ts5to6 --fixBaseUrl your-tsconfig-file-here.json npx @andrewbranch/ts5to6 --fixRootDir your-tsconfig-file-here.json
--watch, 그리고 API6.0과 동등한 수준의 준비 상태를 갖춘다고 해도, 새 컴파일러를 당장 그대로 교체해 사용할 수 없는 상황이 일부 존재합니다.
우선, JavaScript 출력(emit) 파이프라인이 아직 완전히 완료되지 않았습니다. TypeScript에서 JavaScript emit이 필요 없다면(예: Babel, esbuild 등 다른 도구를 사용하는 경우), 또는 최신 브라우저/런타임을 타겟팅한다면, 빌드에 tsgo를 사용하는 것은 전혀 문제가 없습니다. 하지만 TypeScript의 downlevel 컴파일에 의존해 구형 런타임을 타겟팅하고 있다면, 현재로서는 사실상 es2021 타겟까지, 그리고 데코레이터 컴파일을 지원하지 않는 수준이라고 보는 것이 현실적입니다. es2015까지 거슬러 올라가는 전체 --target 지원을 구현할 계획이지만, 해당 작업은 아직 진행 중입니다.
또 다른 이슈로, 새로운 --watch 모드는 일부 시나리오에서 기존 TypeScript 컴파일러보다 효율적이지 않을 수 있습니다. 어떤 경우에는 nodemon과 tsgo의 --incremental 플래그를 함께 사용하는 등의 대안을 찾을 수 있을 것입니다.
마지막으로, Corsa/TypeScript 7.0은 기존 Strada API를 지원하지 않습니다. Corsa API는 아직 개발 중이며, 이를 기반으로 한 안정적인 툴링 통합도 존재하지 않습니다. 즉, Strada API에 의존하는 린터, 포매터, IDE 확장 프로그램 등은 Corsa와 함께 사용할 수 없습니다.
이러한 문제들에 대한 우회책으로는 typescript와 @typescript/native-preview 패키지를 나란히 설치한 뒤, 툴링에는 ≤6.0 API를 사용하고, 타입 체크에는 tsgo를 사용하는 방법이 있습니다.
또 하나 짚고 넘어가고 싶은 부분은, JavaScript 타입 체크 지원(부분적으로 JSDoc 애너테이션에 의해 동작)이 완전히 새로 작성되었다는 점입니다. 내부 구조를 단순화하기 위해, 이전에 인식·분석하던 복잡하거나 사용 빈도가 낮은 일부 패턴 지원을 축소했습니다. 예를 들어, TypeScript 7.0은 @enum 및 @constructor 태그를 인식하지 않습니다. 또한 JavaScript에서 다음과 같은 “완화된” 타입 체크 규칙도 제거했습니다.
Object를 any로 해석String을 string으로 해석Foo를, TypeScript 파일에서 유효했을 typeof Foo로 해석any, unknown, undefined 타입의 모든 매개변수를 선택적(optional)로 간주등등입니다. 이들 중 일부는 여기에서 검토 및 문서화되고 있으며, 목록은 이후 갱신될 수 있습니다.
그 결과, 일부 JavaScript 코드베이스에서는 이전보다 더 많은 오류가 발생할 수 있으며, 새 컴파일러와 잘 동작하도록 코드를 업데이트해야 할 수도 있습니다. 반면, 새 구현은 더욱 견고하고 유지보수하기 쉬우며, TypeScript의 JSDoc 지원을 자체 타입 문법과 보다 잘 정렬시킨다고 믿습니다.
어떤 기능이 “당연히 동작해야 한다”고 느끼시거나, JavaScript 타입 체크 지원에서 빠져 있다고 생각되는 부분이 있다면, GitHub 저장소에 이슈를 남겨 알려 주시길 권장합니다.
작년 TypeScript 리라이트를 시작했을 때는 불확실한 점이 많았습니다. 커뮤니티가 이 작업에 열광해 줄까? 코드베이스가 안정화되는 데 얼마나 걸릴까? 팀들이 이 새로운 도구 모음을 얼마나 빨리 채택할 수 있을까? 어느 정도의 호환성을 제공할 수 있을까?
모든 측면에서 결과는 매우 긍정적이었습니다. 우리는 매우 높은 호환성을 가진 타입 체커를 구현할 수 있었습니다. 그 결과, Microsoft 내부와 외부의 프로젝트 모두 최소한의 노력으로 네이티브 컴파일러를 사용할 수 있었다고 보고하고 있습니다. 안정성도 순조롭고, 연말까지 대부분의 언어 서비스 기능을 완료하는 궤도에 올라 있습니다. 많은 팀이 이미 일상 업무에 Corsa를 사용하고 있으며, 막히는 이슈 없이 잘 활용하고 있습니다.
6.0 출시가 다가오면서, JavaScript 코드베이스에서 이후에 무엇을 할지 고민해야 합니다. 초기 계획은 “TypeScript 7+가 충분한 성숙도와 채택률에 도달할 때까지” 6.0 라인에서 작업을 계속하는 것이었습니다. 여전히 더 많은 개발자의 발목을 잡는 문제(예: API 표면에 대한 추가 작업)를 해결해야 한다는 것을 알고 있으며, Strada 라인 – 즉 JavaScript 기반 컴파일러 –의 개발을 종료하는 것이 이러한 장애물을 더 빠르게 제거하는 최선의 방법이라고 보고 있습니다. 이를 최대한 빨리 달성하기 위해, Strada 프로젝트에서 몇 가지 조치를 취하고자 합니다.
TypeScript 6.0은 현재 TypeScript/JavaScript 코드베이스에 기반한 마지막 릴리스가 될 것입니다. 다시 말해, TypeScript 6.1을 출시할 계획은 없으며, 다만 드문 경우에는 패치 릴리스(예: 6.0.1, 6.0.2 등)가 있을 수 있습니다.
TypeScript 6.0은 TypeScript 5.9 라인과 7.0 사이의 “브리지” 릴리스로 생각할 수 있습니다. 6.0은 7.0과 정렬되도록 기능을 사용 중단 처리하며, 타입 체크 동작 측면에서 매우 높은 호환성을 유지합니다.
에디터 측면에서 Strada 특화 기능(예: 언어 서비스 플러그인)이 필요한 대부분의 코드베이스는, 6.0을 에디터 기능용으로, 7.0을 빠른 커맨드라인 빌드용으로 사용하는 데 큰 문제가 없을 것입니다. 반대의 조합도 가능합니다. 개발자는 에디터에서 더 빠른 경험을 위해 7.0을 사용하고, TypeScript 6.0 API에 의존하는 커맨드라인 툴링에는 6.0을 사용하는 식입니다.
TypeScript 6.0 이후의 추가 서비스는 패치 릴리스 형태로 제공되며, 다음과 같은 경우에만 배포될 예정입니다.
기존 릴리스와 마찬가지로, 패치 릴리스는 드물게만 제공되며, 반드시 필요할 때에만 발행됩니다.
현재로서는 TypeScript 6.0과 7.0이 최대한 호환되도록 보장하고자 합니다. 6.0 라인에 어떤 오픈 PR을 머지할지에 대해서는 매우 높은 기준을 적용할 것입니다. 이는 오늘부로 적용되며, 대부분의 개발자는 TypeScript 6.0에서 어떤 이슈가 해결될 수 있을지에 대해 기대치를 조정해야 함을 의미합니다. 또한 기여자들은 우리가 6.0에 대한 풀 리퀘스트를 머지할 가능성이 매우 낮고, 대부분의 집중력이 7.0의 동등성과 안정성 확보에 쏠릴 것임을 이해해야 합니다. 이는 “헛된” 작업을 방지하고, 두 코드베이스 간 변경 사항 포팅에서 발생하는 복잡성을 줄이기 위한 투명성 차원입니다.
핵심 타입 체크 코드 대부분은 동작상의 차이 없이 포팅되었지만, 언어 서비스는 사정이 다릅니다. 새로운 아키텍처에 따라, 코드 완성, 호버 툴팁, 네비게이션 등을 구동하는 코드 상당 부분이 대거 재작성되었습니다. 또한 TypeScript 7.0은 기존의 커스텀 TSServer 프로토콜 대신 표준 LSP 프로토콜을 사용하기 때문에, TypeScript VS Code 확장 프로그램에 특화된 일부 동작은 달라졌을 수 있습니다.
그 결과, 언어 서비스 동작에 특화된 버그나 제안 이슈는 7.0 라인에서 재현되지 않거나, 논의의 “리셋”이 필요할 가능성이 높습니다.
이러한 이슈들은 수작업으로 검증하는 데 시간이 많이 들기 때문에, 언어 서비스 동작과 관련된 기존 이슈들은 일괄적으로 정리하여 닫을 예정입니다. “7.0 LS Migration” 레이블과 함께 닫힌 이슈와 동일한 문제를 겪는다면, 네이티브 나이틀리 확장에서 재현 가능함을 확인한 뒤 _새 이슈를 등록_해 주세요. 아직 7.0에 포팅되지 않은 기능에 대해서는, 해당 기능이 구현된 이후에 새 이슈를 올려주시면 감사하겠습니다.
몇 달 전 네이티브 프리뷰를 공개했을 때, 프로젝트의 상태에 대한 기대치를 신중하게 관리해야 했습니다. 이제는, 네이티브 TypeScript 경험이 실제로 존재하며, 안정적이고, 더 널리 사용될 준비가 되었다고 자신 있게 말씀드릴 수 있는 단계에 이르렀습니다. 동시에 우리는 여전히 여러분의 피드백을 매우 중요하게 생각합니다.
따라서 VS Code 네이티브 프리뷰 확장 프로그램을 설치하고, 가능한 곳에서 @typescript/native-preview 컴파일러 패키지를 사용해 보며, 여러분의 프로젝트에서 직접 시도해 보시기를 권장합니다. 사용해 보신 뒤 어떤지 알려 주시고, GitHub 저장소에 이슈를 등록해 주셔서 문제를 해결하고 앞으로 무엇을 우선적으로 작업할지 결정하는 데 도움을 주세요.
TypeScript의 미래가 매우 기대되며, TypeScript 7.0을 여러분의 손에 쥐어 드릴 날을 손꼽아 기다리고 있습니다!
즐거운 해킹 되세요!
(원문과 동일)
수석 프로덕트 매니저 (Principal Product Manager)
Daniel Rosenwasser는 TypeScript 팀의 프로덕트 매니저입니다. 그는 프로그래밍 언어, 컴파일러, 그리고 뛰어난 개발자 도구에 열정을 가지고 있습니다.