Rosetta Page

TypeScript 7 진행 상황 - 2025년 12월

I
Inkyu Oh

SW Engineering•2025.12.04

TypeScript 블로그 포스트 번역
2025년 12월 2일
원문: https://devblogs.microsoft.com/typescript/progress-on-typescript-7-december-2025


개요

작성자: Daniel Rosenwasser (Principal Product Manager)

올해 초, TypeScript 팀은 컴파일러와 언어 서비스를 네이티브 코드로 포팅하고 있다고 발표했습니다. 이를 통해 더 나은 원시 성능, 메모리 사용량, 병렬 처리를 활용할 수 있게 됩니다. 이 노력("Project Corsa"로 코드명이 지어졌으며, 곧 "TypeScript 7.0"이 될 예정)은 상당한 작업이었지만, 지난 몇 개월 동안 큰 진전을 이루었습니다. 우리는 현재 상황에 대한 업데이트를 제공하고, 새로운 TypeScript 도구 세트가 오늘날 얼마나 "실제"인지 보여드리고 싶습니다.
또한 우리의 향후 로드맵과 TypeScript 7.0 포팅을 완료하기 위해 작업을 어떻게 우선순위를 정하고 있는지에 대한 소식도 있습니다.

에디터 지원 및 언어 서비스

많은 개발자들에게 프로젝트 재작성은 최종 릴리스될 때까지 완전히 이론적으로 느껴질 수 있습니다. 하지만 여기서는 그렇지 않습니다.
TypeScript의 네이티브 미리보기는 빠르고, 안정적이며, 오늘날 사용하기 쉽습니다 – 에디터를 포함해서요.
TypeScript의 언어 서비스(에디터의 TypeScript 및 JavaScript 기능을 제공하는 것)는 네이티브 포팅 노력의 핵심 부분이며, 쉽게 시도해볼 수 있습니다. Visual Studio Code Marketplace에서 최신 버전을 받을 수 있으며, 매일 업데이트됩니다.
우리 팀은 여전히 기능을 포팅하고 사소한 버그를 수정하고 있지만, 기존 TypeScript 편집 경험을 정말로 만드는 대부분의 것들이 이미 있고 잘 작동하고 있습니다.
여기에는 다음이 포함됩니다:
  • 코드 완성 (자동 import 포함!)
  • Go-to-Definition
  • Go-to-Type-Definition
  • Go-to-Implementation
  • Find-All-References
  • Rename
  • Quick Info/Hover Tooltips
  • Signature Help
  • Formatting
  • Selection Ranges
  • Code Lenses
  • Call Hierarchy
  • Document Symbols
  • Quick Fixes for Missing Imports
마지막 주요 업데이트 이후 눈에 띄는 몇 가지가 있을 수 있습니다 – 자동 import, find-all-references, rename 등입니다. 우리는 이러한 기능들이 많은 개발자들이 네이티브 미리보기를 시도하지 못하게 막았던 누락된 부분이었다는 것을 알고 있습니다. 이제 이러한 기능들이 다시 구현되었으며 일상적인 사용에 준비되어 있다고 말씀드릴 수 있습니다! 이러한 작업들은 이제 프로젝트 참조를 포함한 모든 TypeScript 또는 JavaScript 코드베이스에서 작동합니다.
또한 공유 메모리 병렬 처리를 활용하면서 동시에 안정성을 개선하기 위해 언어 서비스의 일부를 재설계했습니다. 일부 팀은 원래 경험이 때때로 "충돌하기 쉬웠다"고 보고했지만, 속도 개선 때문에 종종 이를 감수했습니다. 새로운 아키텍처는 더 견고하며, 크고 작은 코드베이스를 문제 없이 처리할 수 있어야 합니다.
포팅하고 다듬을 것이 더 있지만, 우리 팀은 TypeScript의 네이티브 미리보기를 시도해볼 가치가 있을 것으로 생각합니다. 더 빠른 로드 시간, 더 적은 메모리 사용량, 그리고 전반적으로 더 빠르고 반응성 있는 에디터를 기대할 수 있습니다.
경험에 만족하지 않으면, 우리의 확장 프로그램을 사용하면 VS Code의 기본 제공 TypeScript 경험과 새로운 경험 사이를 쉽게 전환할 수 있습니다. 우리는 정말로 당신과 당신의 팀이 오늘 VS Code용 네이티브 미리보기 확장 프로그램을 시도해보기를 권장합니다!

컴파일러

TypeScript 컴파일러도 네이티브 포팅에서 상당한 진전을 이루었습니다. VS Code 확장 프로그램과 마찬가지로, 우리는 @typescript/native-preview 패키지 이름으로 새 컴파일러의 야간 미리보기 빌드를 발행해왔습니다. npm을 통해 다음과 같이 설치할 수 있습니다:
# 로컬 개발 의존성
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 모드와 같은 기능도 이제 모두 포팅되었으며 작동합니다! 이는 대부분의 프로젝트가 이제 최소한의 변경으로 네이티브 미리보기를 시도할 수 있다는 의미입니다.
# --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.08s
16.25s
116.84s
8.19x
vscode
89.11s
8.74s
80.37s
10.2x
typeorm
15.80s
1.06s
14.20s
9.88x
playwright
9.30s
1.24s
8.07s
7.51x

TypeScript 5.9와의 예상되는 차이점

새 컴파일러를 사용할 때 몇 가지 주의사항이 있습니다. 이 중 많은 것들은 최종 7.0 릴리스 전에 해결할 계획인 시점 문제이지만, 일부는 기본 TypeScript 경험을 더 좋게 만들기 위한 장기적 결정에 의해 더 많이 주도됩니다. TypeScript 7.0의 약속은 우리가 새 코드베이스에 초점을 크게 이동하여 기존 격차를 해소하고 새 도구 체인을 더 많은 개발자의 손에 넣어야 한다는 의미입니다. 하지만 먼저 현재의 변경 사항과 제한 사항을 살펴보겠습니다.

사용 중단 호환성

TypeScript 7.0은 TypeScript 6.0에서 사용 중단할 계획인 동작과 플래그를 제거합니다. 지금 6.0의 예정된 사용 중단 목록을 우리 이슈 추적기에서 볼 수 있습니다. 몇 가지 주요 예시는 다음과 같습니다:
이것은 포괄적이지 않으므로, 이슈 추적기를 확인하여 현재 상태를 확인하세요. 프로젝트가 이러한 사용 중단된 동작에 의존하는 경우, TypeScript 7.0과의 호환성을 보장하기 위해 코드베이스 또는 tsconfig.json에 일부 변경을 해야 할 수 있습니다.
우리 팀은 ts5to6이라는 도구를 실험하고 있습니다. 이 도구는 tsconfig.json을 자동으로 업데이트하는 데 도움이 됩니다. 이 도구는 extends와 references에 대한 휴리스틱을 사용하여 코드베이스의 다른 프로젝트를 업데이트하는 데 도움이 됩니다. 현재 baseUrl과 rootDir 설정만 업데이트할 수 있지만, 향후 더 많은 것이 추가될 수 있습니다.
npx @andrewbranch/ts5to6 --fixBaseUrl your-tsconfig-file-here.json
npx @andrewbranch/ts5to6 --fixRootDir your-tsconfig-file-here.json

Emit, --watch, 및 API

6.0 준비 상태에도 불구하고, 새 컴파일러를 즉시 교체할 수 없는 경우가 있습니다.
한 가지는 JavaScript emit 파이프라인이 완전히 완료되지 않았다는 것입니다. TypeScript에서 JavaScript emit이 필요하지 않은 경우(예: Babel, esbuild 또는 다른 것을 사용하는 경우) 또는 최신 브라우저/런타임을 대상으로 하는 경우, tsgo를 빌드에 실행하면 잘 작동합니다. 하지만 TypeScript가 더 오래된 런타임을 대상으로 하는 것에 의존하는 경우, 다운레벨 컴파일에 대한 우리의 지원은 현실적으로 es2021 대상까지만 가며, 데코레이터 컴파일에 대한 지원이 없습니다. 우리는 es2015로 돌아가는 전체 --target 지원으로 이를 해결할 계획이지만, 그 작업은 여전히 진행 중입니다.
또 다른 문제는 새로운 --watch 모드가 일부 시나리오에서 기존 TypeScript 컴파일러보다 덜 효율적일 수 있다는 것입니다. 일부 경우에는 nodemon을 실행하고 --incremental 플래그와 함께 tsgo를 실행하는 것과 같은 다른 솔루션을 찾을 수 있습니다.
마지막으로, Corsa/TypeScript 7.0은 기존 Strada API를 지원하지 않습니다. Corsa API는 여전히 진행 중이며, 안정적인 도구 통합이 존재하지 않습니다. 이는 Strada API에 의존하는 린터, 포매터 또는 IDE 확장과 같은 모든 도구가 Corsa에서 작동하지 않을 것임을 의미합니다.
이러한 문제 중 일부에 대한 해결 방법은 typescript와 @typescript/native-preview 패키지를 나란히 설치하고, 필요한 도구에 대해 ≤6.0 API를 사용하고, 타입 체킹에는 tsgo를 사용하는 것일 수 있습니다.

JavaScript 검사 및 JSDoc 호환성

또 다른 주목할 점은 우리의 JavaScript 타입 검사 지원(부분적으로 JSDoc 주석으로 구동됨)이 처음부터 다시 작성되었다는 것입니다. 우리의 내부를 단순화하기 위한 노력으로, 우리는 이전에 인식하고 분석했던 복잡하고 덜 사용되는 패턴에 대한 일부 지원을 제거했습니다. 예를 들어, TypeScript 7.0은 @enum과 @constructor 태그를 인식하지 않습니다. 우리는 또한 JavaScript의 일부 "완화된" 타입 검사 규칙을 제거했습니다. 예를 들어:
  • Object를 any로 해석
  • String을 string으로 해석
  • Foo를 typeof Foo로 해석(후자가 TypeScript 파일에서 유효했을 때)
  • 모든 any, unknown, undefined 타입의 매개변수를 선택적으로 해석
등등. 이 중 일부는 여기에서 검토되고 문서화되고 있습니다. 하지만 목록을 업데이트해야 할 수도 있습니다.
이는 일부 JavaScript 코드베이스가 이전보다 더 많은 오류를 볼 수 있으며, 새 컴파일러와 잘 작동하도록 업데이트해야 할 수 있음을 의미합니다. 반면에, 우리는 새로운 구현이 더 견고하고 유지보수하기 쉬우며, TypeScript의 JSDoc 지원을 자체 타입 구문과 정렬한다고 믿습니다.
JavaScript 타입 검사 지원에서 무언가가 작동해야 한다고 생각하거나 누락되었다고 느끼면, 우리의 GitHub 저장소에 이슈를 제출하도록 권장합니다.

미래에 집중하기

작년에 TypeScript를 다시 작성하기로 결정했을 때, 많은 불확실성이 있었습니다. 커뮤니티가 흥미로워할까요? 코드베이스가 안정화되는 데 얼마나 오래 걸릴까요? 팀들이 이 새로운 도구 세트를 얼마나 빨리 채택할 수 있을까요? 어느 정도의 호환성을 제공할 수 있을까요?
모든 면에서 우리는 매우 기쁘게 놀랐습니다. 우리는 매우 높은 호환성을 가진 타입 체커를 구현할 수 있었습니다. 결과적으로, Microsoft 내부와 외부의 프로젝트들은 최소한의 노력으로 네이티브 컴파일러를 쉽게 사용할 수 있었다고 보고합니다. 안정성은 잘 진행되고 있으며, 우리는 연말까지 대부분의 언어 서비스 기능을 완료할 예정입니다. 많은 팀들이 이미 차단 문제 없이 일상적인 작업에 Corsa를 사용하고 있습니다.
6.0이 다가오면서, 우리는 JavaScript 코드베이스에서 다음에 무엇이 일어날지 고려해야 합니다. 우리의 초기 계획은 "TypeScript 7+ 충분한 성숙도와 채택에 도달할 때까지" 6.0 라인에서 계속 작업하는 것이었습니다. 우리는 더 많은 개발자를 차단 해제하기 위해 여전히 남은 작업이 있다는 것을 알고 있습니다(예: API 표면에 대한 더 많은 작업). Strada 라인 – 우리의 JavaScript 기반 컴파일러 – 개발을 종료하는 것이 우리가 이러한 차단 요소를 더 빨리 제거하는 최선의 방법입니다. 이를 가능한 한 빨리 완료하는 데 도움이 되도록, 우리는 Strada 프로젝트에서 몇 가지 단계를 취하고 있습니다.

TypeScript 6.0은 마지막 JavaScript 기반 릴리스입니다

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이 릴리스된 후의 추가 서비싱은 패치 릴리스 형태로 제공되며, 다음의 경우에만 발행됩니다:
  • 보안 문제
  • 높은 심각도의 회귀(즉, 5.9에 없었던 새롭고 심각한 버그)
  • 6.0/7.0 호환성과 관련된 높은 심각도의 수정
이전 릴리스와 마찬가지로, 패치 릴리스는 드물며, 절대적으로 필요할 때만 발행됩니다.
하지만 지금 당장은, 우리는 TypeScript 6.0과 7.0이 가능한 한 호환성이 높기를 원합니다. 우리는 6.0 라인에 병합되는 열린 PR에 대해 매우 높은 기준을 유지할 것입니다. 이는 오늘부터 적용되며, 대부분의 개발자는 TypeScript 6.0에서 어떤 문제가 해결될지에 대한 기대를 설정해야 합니다. 또한 기여자들은 우리가 6.0에 pull request를 병합할 가능성이 매우 낮으며, 우리의 대부분의 초점이 7.0을 패리티와 안정성으로 가져오는 데 있다는 것을 이해해야 합니다. 우리는 이 점에서 투명하고 싶으므로 "낭비된" 작업이 없으며, 우리 팀이 두 코드베이스 간의 변경 포팅에서 합병증을 피할 수 있습니다.

언어 서비스 이슈 재설정

대부분의 핵심 타입 검사 코드가 동작 차이 없이 포팅되었지만, 언어 서비스는 다른 이야기입니다. 새로운 아키텍처를 고려하면, 완성, hover 툴팁, 네비게이션 등을 제공하는 코드의 대부분이 크게 다시 작성되었습니다. 또한 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을 당신의 손에 넘겨드릴 수 없을 정도로 기대하고 있습니다!
행복한 해킹!


저자 정보

Daniel Rosenwasser - Principal Product Manager
Daniel Rosenwasser는 TypeScript 팀의 제품 관리자입니다. 그는 프로그래밍 언어, 컴파일러, 그리고 훌륭한 개발자 도구에 대한 열정을 가지고 있습니다.
0
19

댓글

?

아직 댓글이 없습니다.

첫 번째 댓글을 작성해보세요!

Inkyu Oh님의 다른 글

더보기
TypeScript에서 Discriminated Unions을 위한 Omit

TypeScript에서 Discriminated Unions을 위한 Omit

Inkyu Oh • SW Engineering

0
0
5
언어의 환상: 지시어(directive)의 정체

언어의 환상: 지시어(directive)의 정체

Inkyu Oh • Front-End

0
0
94

유사한 내용의 글

언어의 환상: 지시어(Directives)의 진실

언어의 환상: 지시어(Directives)의 진실

Inkyu Oh • Front-End

0
0
100
Next.js 16

Next.js 16

Inkyu Oh

1
0
56
언어의 환상: 지시어(directive)의 정체

언어의 환상: 지시어(directive)의 정체

Inkyu Oh • Front-End

0
0
94
React 19.2

React 19.2

Inkyu Oh • Front-End

0
1
56