[번역] TypeScript 7.0 발표

라이브러리, 프레임워크•2026.07.11

원문: https://devblogs.microsoft.com/typescript/announcing-typescript-7-0

Daniel Rosenwasser - 2026-07-08

오늘 우리는 TypeScript를 10배 더 빠르게 네이티브로 포팅한 TypeScript 7의 출시를 발표하게 되어 자랑스럽게 생각합니다!

초창기부터 TypeScript는 확장 가능한 JavaScript를 제공하겠다고 약속해 왔습니다. JavaScript 세계에 강력한 타입 체크와 풍부한 툴링을 도입함으로써, TypeScript는 여러 플랫폼에서 복잡하고 수준 높은 앱을 구축하는 것을 가능하게 했습니다.

지난해, 우리 팀은 확장을 위한 TypeScript의 다음 단계를 공개했습니다. 바로 툴셋의 모든 부분을 수십 배 더 빠르게 만드는 것이었습니다. 우리의 임무는 현대적인 하드웨어를 최대한 활용할 수 있도록 Go 언어로 구축된 TypeScript의 네이티브 포트(Native Port)를 만드는 것이었습니다. 이 포팅 작업은 최대한 충실하게 진행되었으며, 두 컴파일러 간의 결과가 일관되고 호환되도록 기존 코드베이스의 구조와 로직을 유지하면서 새로운 코드를 작성했습니다. 핵심적인 차이점은 이 새로운 코드베이스를 통해 TypeScript 7이 네이티브 코드 속도, 공유 메모리 멀티스레딩, 그리고 전체 빌드 시 일반적으로 8배에서 12배 사이의 속도 향상을 가져오는 수많은 새로운 최적화를 제공한다는 점입니다.

다른 릴리스와 마찬가지로 TypeScript 7은 npm을 통해 설치할 수 있습니다.

npm install -D typescript

이렇게 하면 워크스페이스에 새로운 tsc 실행 파일이 설치됩니다(npx tsc를 통해 실행 가능). 물론 TypeScript 경험의 큰 부분은 에디터 지원이기도 합니다. 여러분이 즐겨 사용하는 코드 에디터는 새로운 언어 서버 프로토콜(LSP) 지원과 새로운 속도 및 멀티스레딩 개선 사항을 통해 TypeScript 7을 쉽게 지원할 것입니다. VS Code, Visual Studio, WebStorm 또는 기타 현대적인 에디터를 사용하든 TypeScript 7은 훌륭하게 작동할 것입니다. 에디터 문서를 확인해 보세요. 예를 들어, VS Code에는 지금 바로 사용할 수 있는 TypeScript 7 전용 확장 프로그램이 있으며, Visual Studio는 워크스페이스에 따라 TypeScript 7을 자동으로 활성화합니다.

더 빠른 TypeScript는 무엇을 의미할까요?

더 빠른 TypeScript는 서류상으로는 훌륭해 보이지만, 실제로는 무엇을 의미할까요? 개발의 모든 단계에서 TypeScript가 어디에 등장하는지 생각해보면 도움이 될 것입니다.

전형적인 개발 일과는 에디터를 열고, TypeScript 파일을 열고, 프로젝트 전체에서 '모든 참조 찾기(find-all-references)'와 같은 작업을 실행하는 것으로 시작될 수 있습니다. 그런 다음 편집을 시작하면 자동 완성이 팝업되고, 편집하는 즉시 빨간색 물결선(에러 표시)이 나타나기를 기대할 것입니다. 여러분(그리고 최근에는 아마도 AI 에이전트)이 프로젝트를 빌드할 준비가 되면 tsc를 실행하고, 출력에서 에러를 확인한 다음, 생성된 코드를 실행할 것입니다.

더 빠른 TypeScript는 위의 모든 과정이 간소화됨을 의미합니다. 에디터가 프로젝트를 완전히 로드할 때까지 기다리는 시간이 순식간에 지나가는 것처럼 느껴질 것입니다. '모든 참조 찾기', 자동 완성, 진단(Diagnostics)의 지연 시간은 이전의 아주 적은 시간밖에 걸리지 않을 것입니다. 그리고 tsc를 실행할 때, 특히 --watch 모드에서 피드백 루프를 강화하고 그 어느 때보다 빠르게 반복 작업을 수행할 수 있습니다.

실제 프로젝트에서 이를 확인할 수 있습니다. 사실, 몇몇 오픈 소스 프로젝트에서 직접 비교해 볼 수도 있습니다. 다음은 상당히 큰 오픈 소스 코드베이스에서 TypeScript 6와 7을 실행했을 때의 빌드 시간입니다.

코드베이스	TypeScript 6	TypeScript 7	속도 향상
vscode	125.7s	10.6s	11.9x
sentry	139.8s	15.7s	8.9x
bluesky	24.3s	2.8s	8.7x
playwright	12.8s	1.47s	8.7x
tldraw	11.2s	1.46s	7.7x

위 표에서 설명된 TypeScript 6와 7 사이의 프로젝트 컴파일 시간, 7.7배에서 11.9배 범위

또한 TypeScript 7은 일반적으로 빌드 기간 동안 더 적은 총 메모리를 사용하면서도 더 나은 성능을 보여줍니다.

코드베이스	TypeScript 6	TypeScript 7	메모리 변화
vscode	5.2GB	4.2GB	-18%
sentry	4.9GB	4.6GB	-6%
bluesky	1.8GB	1.3GB	-26%
playwright	1.0GB	0.9GB	-11%
tldraw	0.6GB	0.5GB	-15%

위 표에서 설명된 TypeScript 6와 7 사이의 메모리 감소 차이, -6%에서 -26% 범위

물론 전체 빌드 이상의 경험이 있습니다. 동일한 컴퓨터에서 에러가 있는 파일을 VS Code 코드베이스에서 열었을 때, 이전에는 에디터를 연 시점부터 첫 번째 에러를 볼 때까지 약 17.5초가 걸렸습니다. TypeScript 7을 사용하면 1.3초 미만이 걸리며, 이는 13배 이상 빠릅니다.

실전 검증을 마친 프로덕션 준비 완료

TypeScript 프로젝트에는 10년 넘게 구축된 수만 개의 테스트가 포함되어 있으며, 이는 main 브랜치의 모든 커밋마다 실행됩니다. 이를 통해 우리의 모든 릴리스가 안정적이고 신뢰할 수 있음을 보장해 왔습니다.

하지만 TypeScript 7은 평범한 릴리스가 아닙니다. 테스트 스위트 외에도, 우리는 TypeScript 7이 프로덕션 용도로 견고한지 확인하기 위해 다양한 리소스를 활용했습니다.

지난 1년 동안 우리는 내부 및 외부의 많은 대규모 팀과 협력하여 실제 코드베이스에서 TypeScript 7을 테스트했습니다. 결과는 압도적으로 긍정적이었으며, 많은 기업이 TypeScript 7이 안정적이고 빠르며 도입하기 쉽다고 보고했습니다. 예를 들어, VS Code 팀은 최근 개발 사이클을 더 빠르게 진행하기 위해 TypeScript 7의 프리뷰 버전을 사용한 경험을 강조했습니다. 또한 Loop, Office, PowerBI, Teams, Xbox와 같은 Microsoft 팀과 협력하여 TypeScript가 가장 큰 규모의 코드베이스에서도 준비되었는지 확인했습니다. 마찬가지로 Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel, VoidZero 등의 기업들이 우리와 협력하여 그들의 코드베이스에서 TypeScript 7을 테스트하고 개선을 위한 피드백을 주었습니다.

또한, 우리는 더 넓은 테스트 인프라의 상당 부분을 TypeScript 7에서 실행되도록 재구축했습니다. TypeScript 6 및 이전 버전에는 컴파일러와 언어 서비스의 회귀(Regression)를 감지하기 위해 GitHub의 TypeScript 및 JavaScript 프로젝트에 대한 자동 및 온디맨드 테스트가 있었습니다. 동일한 테스트가 다시 도입되어 TypeScript 7을 대상으로 실행되고 있으며, 실제 코드베이스에서 문제를 찾아내어 핵심 테스트 스위트의 공백을 메우고 더 나은 경험을 제공할 수 있게 되었습니다.

명시적인 피드백, 자동화된 크래시 리포트, 그리고 공격적인 테스트의 조합은 품질 면에서 측정 가능한 차이를 만들어냈습니다. 실제로 우리의 데이터 인사이트에 따르면, TypeScript 7.0의 새로운 언어 서버는 TypeScript 6.0에 비해 실패하는 언어 서버 명령을 80% 이상 줄였고, 서버 크래시를 60% 이상 줄였습니다.

또한 대규모 팀들로부터 놀라운 피드백을 받았습니다.

Slack 엔지니어들은 TypeScript 7이 머지 큐(Merge queue) 대기 시간의 40%를 제거했으며, CI에서의 타입 체크 시간을 약 7.5분에서 1.25분으로 단축했다고 말했습니다. 이전에는 언어 서버 로드 시간 때문에 에디터에서의 로컬 개발이 거의 "불가능"할 정도였고, 엔지니어들은 보통 CI가 전체 타입 체크를 하도록 내버려 두었습니다. TypeScript 7은 동일한 코드베이스를 몇 초 만에 로드할 수 있게 하여 로컬 타입 체크를 다시 가능하게 만들었습니다.

Vanta의 빌드는 비약적으로 향상되어, 가장 큰 프로젝트 중 하나에서 최대 9배 더 빠른 속도 향상을 보여주었습니다.

마찬가지로 Microsoft의 News Services 팀은 TypeScript 7을 도입함으로써 CI 빌드를 기다리는 시간을 한 달에 400시간 절약했다고 전했습니다.

작년에 PowerBI에서 작업하는 엔지니어들은 에디터에서의 TypeScript 7 경험을 코드베이스 작업을 위한 "생명의 은인"이라고 묘사했습니다. 그들은 TypeScript 7이 VS Code에서 이름 변경(Rename) 기능을 지원하기 전부터 이 경험을 기본으로 채택했습니다.

Loop의 모노레포에서 작업하는 개발자들도 열광했습니다. 이전의 에디터 경험은 그들의 규모에서 사용할 수 없는 수준으로 묘사되었지만, TypeScript 7 경험은 사용하기에 "놀랍다"고 평가되었습니다.

Canva 개발자들은 TypeScript 7의 언어 서비스가 에디터에서 첫 번째 에러를 보는 데 걸리는 시간을 약 58초에서 약 4.8초로 단축하는 극적인 속도 향상을 보여주었다고 말했습니다.

TypeScript 6.0과 병행 실행하기

TypeScript 7.0이 출시되었지만, API는 함께 제공되지 않습니다. TypeScript 7.1에서 새로운(그리고 다른) API를 제공할 예정이지만, 그때까지는 컴파일러에 대한 프로그래밍 방식의 접근이 여전히 필요한 유틸리티(예: typescript-eslint)를 위해 TypeScript 6.0과 병행하여 실행할 수 있도록 보장하는 것을 우선순위로 두었습니다.

6.0/7.0 전환 프로세스의 일환으로, 우리는 새로운 호환성 패키지인 @typescript/typescript6를 게시했습니다. 이 패키지는 tsc6라는 이름의 실행 파일을 제공하므로, 필요한 경우 이름 충돌 없이 TypeScript 7.0(tsc 바이너리 포함)과 나란히 설치할 수 있습니다. 또한 이 새로운 패키지는 TypeScript 6.0 API를 다시 내보내므로(Re-export), TypeScript 7용으로는 tsc를 사용하면서 다른 툴링은 계속해서 6.0에 의존할 수 있습니다.

typescript-eslint와 같은 일부 도구는 피어 종속성(Peer dependencies)을 통해 typescript에서 직접 임포트할 것을 기대하므로, npm 별칭(Alias)을 통해 이를 달성하는 것을 권장합니다. 다음 명령을 실행하거나,

npm install -D typescript@npm:@typescript/typescript6

package.json을 다음과 같이 수정할 수 있습니다.

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

이렇게 하면 tsc6 실행 파일만 남게 된다는 점에 유의하세요. 7.0의 tsc를 얻으려면 TypeScript 7에 대한 다른 별칭을 추가하면 되며, npx tsc는 7.0에서 바로 작동할 것입니다.

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  }
}

나이틀리 빌드와 `@typescript/native-preview`

지금까지 대부분의 개발자는 @typescript/native-preview 패키지를 통해 TypeScript 7을 설치해 왔습니다. 이 패키지는 새로운 코드베이스의 나이틀리(Nightly) 빌드를 제공했으며, 주간 다운로드 수가 850만 건을 넘을 정도로 커뮤니티에 큰 도움이 되었습니다!

하지만 앞으로 나이틀리 빌드는 곧 next 태그가 붙은 표준 typescript 패키지에서 재개될 예정입니다. 다음 명령으로 설치할 수 있습니다.

npm install -D typescript@next

커스텀 스케일링: 병렬화 및 제어

TypeScript 7.0은 이제 파싱(Parsing), 타입 체크, 에밋(Emit)을 포함한 많은 단계를 병렬로 수행합니다. 파싱과 에밋 같은 일부 단계는 파일 간에 거의 독립적으로 수행될 수 있습니다. 따라서 병렬화는 오버헤드가 상대적으로 적으면서 대규모 코드베이스에서 자동으로 잘 확장됩니다. 하지만 TypeScript 빌드의 모든 단계가 쉽게 병렬화되는 것은 아닙니다.

TypeScript 7은 타입 체크나 프로젝트 참조(Project reference) 빌드와 같이 복잡한 단계의 병렬화 동작을 미세 조정하기 위해 실험적인 --checkers 및 --builders 플래그를 도입합니다. 또한 병렬화를 완전히 비활성화하는 --singleThreaded 플래그도 도입하는데, 이는 디버깅이나 리소스가 제한된 환경에서 실행할 때 유용할 수 있습니다.

타입 체커 병렬화

타입 체크와 같은 다른 단계는 파일 간에 더 복잡한 의존성을 가집니다. 대부분의 파일은 의존성 및 글로벌 스코프의 동일한 타입 정보에 의존하게 되므로, 타입 체커를 완전히 독립적으로 실행하는 것은 계산과 메모리 측면 모두에서 낭비가 될 수 있습니다. 반면에 타입 체크는 때때로 프로그램 정보의 상대적인 순서에 의존하므로, 처음부터 타입 체크를 할 때는 동일한 결과를 보장하기 위해 항상 동일한 순서로 파일을 체크해야 합니다.

이러한 함정을 피하면서 병렬화를 가능하게 하기 위해, TypeScript 7.0은 자신만의 세계관을 가진 고정된 수의 타입 체커 워커(Worker)를 생성합니다. 이 타입 체크 워커들은 일부 공통 작업을 중복해서 수행할 수 있지만, 동일한 입력 파일이 주어지면 항상 동일하게 파일을 나누고 동일한 결과를 생성합니다.

타입 체크 워커의 기본값은 4개이지만, 새로운 --checkers 플래그로 구성할 수 있습니다. 일반적인 머신이 더 많은 CPU 코어를 가진 대규모 코드베이스에서는 이 숫자를 늘려 빌드 속도를 더 높일 수 있지만, 일반적으로 메모리 사용량이 증가하는 비용이 발생합니다. 예를 들어, 위의 표에서 우리는 기본값인 --checkers 4로 TypeScript 7을 실행했습니다. 동일한 머신에서 --checkers 8을 사용했을 때의 결과는 다음과 같습니다.

코드베이스	TypeScript 6	TypeScript 7 (`--checkers 8`)	속도 향상
vscode	125.7s	7.51s	16.7x
sentry	139.8s	12.08s	11.6x
bluesky	24.3s	2.01s	12.1x
playwright	12.8s	1.16s	11x
tldraw	11.2s	1.06s	10.6x

보시다시피, 이러한 코드베이스는 더 많은 코어를 할당함으로써 더 나은 속도 향상을 얻지만, 결과는 프로젝트와 기본 머신에 따라 다를 것입니다.

반면에 CPU 코어가 적고 메모리가 적은 머신(예: CI 러너)에서는 불필요하거나 부수적인 오버헤드를 피하기 위해 이 숫자를 줄이고 싶을 수 있습니다. --checkers 1만큼 낮은 값을 지정하여 타입 체크를 사실상 싱글 스레드로 만들고 중복 작업을 제거할 수 있습니다.

드문 경우지만, --checkers의 수를 변경하면 순서에 의존적인 결과가 나타날 수 있습니다. 빌드 환경 전체에서 고정된 수의 체커를 지정하면 모든 사람이 동일한 결과를 얻도록 보장하는 데 도움이 될 수 있지만, 이는 팀의 재량에 달려 있습니다.

프로젝트 참조 빌더 병렬화

TypeScript 7.0은 프로젝트 내의 빌드를 병렬화할 수 있을 뿐만 아니라, 이제 여러 프로젝트를 동시에 빌드할 수도 있습니다. 이 동작은 새로운 --builders 플래그로 구성할 수 있으며, 이는 --build로 실행할 때 동시에 실행할 수 있는 병렬 프로젝트 참조 빌더의 수를 제어합니다. 이는 많은 프로젝트가 있는 모노레포에서 특히 유용할 수 있습니다.

--checkers와 마찬가지로 빌더 수를 늘리면 빌드 속도가 빨라질 수 있지만, 메모리 사용량이 증가할 수 있습니다. 또한 --checkers와 곱셈 효과가 있으므로 머신과 코드베이스에 적절한 균형을 찾는 것이 중요합니다. 예를 들어, --checkers 4 --builders 4로 빌드하면 최대 16개의 타입 체커가 동시에 실행될 수 있으며, 이는 과도할 수 있습니다.

--checkers와 달리 빌더 수를 변경해도 다른 결과가 생성되지는 않아야 합니다. 하지만 프로젝트 참조를 빌드하는 것은 근본적으로 프로젝트의 의존성 그래프에 의해 병목 현상이 발생합니다(--isolatedDeclarations와 별도의 구문론적 선언 파일 에밋을 활용하는 코드베이스에서의 타입 체크는 제외).

싱글 스레드 모드

어떤 경우에는 컴파일러 전체에서 싱글 스레드 작동을 강제하는 것이 도움이 될 수 있습니다. 이는 디버깅, TypeScript 6와 7의 성능 비교, 외부에서 병렬 빌드를 오케스트레이션할 때, 또는 리소스가 매우 제한된 환경에서 실행할 때 유용할 수 있습니다. 싱글 스레드 모드를 활성화하려면 새로운 --singleThreaded 플래그를 사용할 수 있습니다. 이는 타입 체크 워커 수를 1로 제한할 뿐만 아니라 파싱과 에밋도 싱글 스레드에서 수행되도록 보장합니다.

개선된 `--watch` 모드

TypeScript 7은 완전히 재구축된 --watch 모드와 함께 출시됩니다. --watch는 이제 효율적이고 안정적인 크로스 플랫폼 파일 감시 기능을 제공하는 Parcel 번들러의 파일 워처(File-watcher)를 기반으로 한 새로운 토대 위에서 작동합니다.

우리 팀이 파일 감시 로직을 포팅하기 시작했을 때, Go 언어에서의 크로스 플랫폼 파일 감시와 관련하여 몇 가지 문제에 직면했습니다. 표준 라이브러리는 내장된 파일 감시 API를 제공하지 않으며, 우리가 조사한 기존 서드파티 라이브러리들은 안정성, 성능, 크로스 플랫폼 지원 또는 빌드 도구 통합 문제 등 다양한 이슈가 있었습니다. 우리는 파일 변경 사항을 확인하기 위해 주기적으로 폴링(Polling)하는 솔루션을 구축할 수 있었고, 이는 여러 운영 체제에서 광범위하게 작동했습니다. 하지만 이는 특히 node_modules에 많은 의존성이 있는 대규모 프로젝트에서 계산 비용이 많이 들었습니다. 동적 스케줄링 전략을 사용하더라도 순수 폴링 솔루션은 일반적인 용도로 사용하기에는 너무 부담스럽다는 것을 알게 되었습니다.

수년 동안 Visual Studio Code는 @parcel/watcher에 의존해 왔으며, 최근 몇 년 동안 VS Code의 TypeScript는 간접적으로 이 파일 감시 기능에 의존해 왔습니다. 유망해 보였지만, Parcel 워처의 문제 중 하나는 C++로 작성되어 빌드 시 전체 C++ 툴체인이 필요하다는 점이었습니다. VS Code에서 Parcel 워처를 사용한 긍정적인 경험을 바탕으로, 우리는 새로운 툴체인 의존성을 도입하지 않기 위해 몇 가지 최소한의 어셈블리 심(Shim)을 사용하여 이를 Go로 포팅하는 방법을 탐구했습니다.

이 탐구는 성공적이었습니다. C++에서 Go로의 매우 직접적인 번역으로 시작된 작업은 포팅된 테스트 스위트를 여전히 통과하면서도 관용적인 Go 코드로 더욱 정제되었습니다. 이 워처는 독립적인 패키지로, 우리가 무엇을 감시하고 왜 감시하는지에 대한 관심사를 깔끔하게 분리할 수 있게 해주었습니다. 이제 우리는 여러 플랫폼에서 --watch 모드의 리소스 개선을 확인하고 있으며, TypeScript 7의 초기 사용자들로부터 긍정적인 피드백을 듣고 있습니다.

Visual Studio Code와 TypeScript 프로젝트 모두에 막대한 이점을 제공한 Parcel 작업을 수행한 Devon Govett에게 감사의 인사를 전하고 싶습니다. 우리는 이 포트가 시간이 지남에 따라 원래의 Parcel 워처 코드베이스에도 기회와 통찰력을 제공하기를 바랍니다.

5.x 이후의 업데이트 및 6.0의 새로운 동작

TypeScript 7.0은 TypeScript 6.0의 타입 체크 및 명령줄 동작과 호환되도록 제작되었습니다. 실제로 TypeScript 6.0에서 깨끗하게 컴파일되는 거의 모든 TypeScript 코드(stableTypeOrdering 플래그가 켜져 있고 ignoreDeprecations 플래그가 설정되지 않은 경우)는 TypeScript 7.0에서도 동일하게 컴파일되어야 합니다.

그렇긴 하지만, TypeScript 7.0은 6.0의 새로운 기본값을 채택하며, TypeScript 6.0에서 더 이상 사용되지 않는(Deprecated) 플래그와 구문에 대해 엄격한 에러를 발생시킵니다. 6.0이 아직 비교적 새롭기 때문에 많은 프로젝트가 새로운 동작에 적응해야 할 것이라는 점은 주목할 만합니다. 개발자들이 TypeScript 7.0으로의 전환을 더 쉽게 하기 위해 TypeScript 6.0을 먼저 채택할 것을 권장하며, 이러한 지원 중단에 대한 자세한 내용은 TypeScript 6.0 릴리스 블로그 포스트에서 확인할 수 있습니다.

설정의 주요 기본값 변경 사항을 요약하면 다음과 같습니다.

strict가 기본적으로 true입니다.

module이 기본적으로 esnext입니다.

target이 esnext 바로 이전의 현재 안정적인 ECMAScript 버전으로 기본 설정됩니다.

noUncheckedSideEffectImports가 기본적으로 true입니다.

libReplacement가 기본적으로 false입니다.

stableTypeOrdering이 기본적으로 true이며, 끌 수 없습니다.

rootDir이 이제 ./로 기본 설정되며, 내부 소스 디렉토리는 명시적으로 설정해야 합니다.

types가 이제 []로 기본 설정되며, 이전 동작은 ["*"]로 설정하여 복구할 수 있습니다.

우리는 rootDir과 types 변경이 가장 "놀라운" 변화일 수 있다고 생각하지만, 쉽게 해결할 수 있습니다. tsconfig.json이 src와 같은 디렉토리 외부에 있는 프로젝트는 동일한 디렉토리 구조를 유지하기 위해 rootDir을 포함하기만 하면 됩니다.

  {
      "compilerOptions": {
          // ...
+         "rootDir": "./src"
      },
      "include": ["./src"]
  }

types 변경의 경우, 특정 글로벌 선언에 의존하는 프로젝트는 이를 명시적으로 나열해야 합니다. 예를 들어:

  {
      "compilerOptions": {
          // 필요한 @types 패키지를 명시적으로 나열 (예: node, jest, mocha 등)
+         "types": ["node", "jest"]
      }
  }

동작하지 않고 엄격한 에러로 바뀐 지원 중단 사항은 다음과 같습니다.

target: es5는 더 이상 지원되지 않습니다.

downlevelIteration은 더 이상 지원되지 않습니다.

moduleResolution: node/node10은 더 이상 지원되지 않으며, 대신 nodenext와 bundler가 권장됩니다.

module: amd, umd, systemjs, none은 더 이상 지원되지 않으며, 번들러나 브라우저 기반 모듈 해석과 함께 esnext 또는 preserve를 사용하는 것이 권장됩니다.

baseUrl은 더 이상 지원되지 않으며, paths는 baseUrl 대신 프로젝트 루트를 기준으로 상대적으로 업데이트할 수 있습니다.

moduleResolution: classic은 더 이상 지원되지 않으며, bundler 또는 nodenext가 권장되는 대체제입니다.

esModuleInterop 및 allowSyntheticDefaultImports를 false로 설정할 수 없습니다.

alwaysStrict는 true로 간주되며 더 이상 false로 설정할 수 없습니다.

module 키워드는 네임스페이스 선언에서 사용할 수 없습니다.

asserts 키워드는 임포트에서 사용할 수 없으며, 대신 with 키워드를 사용해야 합니다(ECMAScript의 임포트 속성 구문 개발 방향에 맞추기 위함).

/// <reference no-default-lib /> 지시문은 skipDefaultLibCheck 하에서 더 이상 존중되지 않습니다.

명령줄 빌드는 현재 디렉토리에 tsconfig.json 파일이 있는 경우 명시적인 --ignoreConfig 플래그를 전달하지 않는 한 파일 경로를 받을 수 없습니다.

템플릿 리터럴 타입이 이제 유니코드 코드 포인트를 보존함

TypeScript 7.0은 템플릿 리터럴 타입에서 추론할 때 유니코드 코드 포인트를 더 자연스럽게 처리합니다. 예를 들어:

type HeadTail<S> = S extends `${infer Head}${infer Tail}` ? [Head, Tail] : never;
type Result = HeadTail<"😀abc">;
//   ^
// 7.0에서: ["😀", "abc"]
// 이전에는: ["\ud83d", "\ude00abc"]

이전에는 TypeScript가 JavaScript의 UTF-16 인덱싱 동작을 따라 "😀"를 서로게이트 쌍(Surrogate pair)의 두 절반(\ud83d와 \ude00)으로 나누었습니다. 이는 기술적으로 JavaScript의 인덱싱과 일치했지만(예: 추론된 Head 타입이 "😀abc"[0]과 같음), 대개 사람들이 의도한 것이 아니었으며 의미가 없는 짝을 이루지 못한 서로게이트를 포함하는 문자열 리터럴 타입을 생성할 수 있었습니다.

이는 문자열 Length 유틸리티와 같이 의도적으로 UTF-16 코드 단위를 모델링한 타입 레벨 문자열 조작에 있어서는 하위 호환성이 깨지는 변경(Breaking change)입니다. 실제로는 새로운 동작이 더 유용하고 덜 놀라울 것으로 기대합니다. 템플릿 리터럴 추론은 이제 for...of로 문자열을 반복하거나 [...str]로 스프레드할 때와 동일한 직관을 따르며, "😀"를 하나의 단위로 취급합니다.

JavaScript 차이점

기존 코드베이스를 포팅하면서, 우리는 JavaScript 지원 방식도 재검토할 기회를 가졌습니다.

TypeScript는 원래 JSDoc 주석을 사용하고 분석 및 타입 추론을 위해 특정 코드 패턴을 인식함으로써 JavaScript 파일을 지원했습니다. 대개 이는 대중적인 코딩 패턴을 기반으로 했지만, 때로는 Closure나 JSDoc 문서 생성 도구가 이해할 수 있는 작성 가능한 모든 것을 기반으로 하기도 했습니다. 이러한 접근 방식은 느슨하게 작성된 JSDoc 코드베이스를 가진 개발자들에게는 도움이 되었지만, 잘 작동하기 위해 수많은 타협과 특수 사례가 필요했으며 .ts 파일에서의 TypeScript 분석과 여러 면에서 차이가 있었습니다.

TypeScript 7.0에서는 JavaScript 지원을 TypeScript 파일을 분석하는 방식과 더 일관되게 재작업했습니다. 몇 가지 차이점은 다음과 같습니다.

타입이 기대되는 곳에 값을 사용할 수 없습니다. 대신 typeof someValue를 작성하세요.

@enum은 더 이상 특별하게 인식되지 않습니다. (typeof YourEnumDeclaration)[keyof typeof YourEnumDeclaration]에 대한 @typedef를 생성하세요.

독립적인 ?는 더 이상 타입으로 사용할 수 없습니다. 대신 any를 사용하세요.

@class는 함수를 생성자로 만들지 않습니다. 대신 class 선언을 사용하세요.

접미사 !는 지원되지 않습니다. 그냥 T를 사용하세요.

타입 이름은 식별자 옆이 아니라 @typedef 태그 내에 정의되어야 합니다(즉, /** @typedef {T} */ TypeAliasName;이 아니라 /** @typedef {T} TypeAliasName */).

Closure 스타일의 함수 구문(예: function(string): void)은 더 이상 지원되지 않습니다. 대신 TypeScript 단축 표기법을 사용하세요(예: (s: string) => void).

또한 this에 별칭을 지정하거나 함수 prototype 전체를 재할당하는 것과 같은 일부 JavaScript 패턴은 더 이상 특별하게 처리되지 않습니다.

JS 지원의 일부가 변경되는 동안, 우리는 TypeScript 6.0과 7.0 사이의 차이점을 더 자세히 담기 위해 이 CHANGES.md 파일을 업데이트해 왔습니다.

에디터 경험

위에서 언급했듯이, TypeScript 7.0의 성능 개선은 명령줄 경험에만 국한되지 않고 에디터 경험으로도 확장됩니다. VS Code 사용자를 위해 우리는 TypeScript 7 전용 확장 프로그램을 준비했습니다. 이 확장 프로그램을 설치하면 자동으로 기본 환경이 됩니다. 커맨드 팔레트에서 "Disable TypeScript 7 Language Server" 및 "Enable TypeScript 7 Language Server" 명령을 사용하여 언제든지 비활성화하거나 다시 활성화할 수 있습니다. 앞으로 몇 주 안에 TypeScript 7 지원이 VS Code 자체의 일부로 포함될 예정입니다.

Visual Studio 사용자의 경우, 최신 버전의 IDE가 워크스페이스에 따라 TypeScript 7을 자동으로 활성화합니다. 별도로 수행할 작업은 없습니다.

물론 TypeScript 7은 여러분이 선택한 어떤 에디터에서도 훌륭하게 작동할 것입니다. 새로운 토대는 언어 서버 프로토콜(LSP)을 기반으로 구축되었으며, 여러 스레드를 활용하여 동시 요청을 최대한 빠르게 처리할 수 있습니다.

처음 데뷔한 이후로 자동 임포트, 확장 가능한 호버(Hover), 인레이 힌트(Inlay hints), 코드 렌즈(Code lenses), 소스 정의로 이동(Go-to-source-definition), JSX 연결 편집 및 태그 완성 등 누락되었던 기능들을 추가해 왔습니다. TypeScript 7.0 베타에서 누락되었던 시맨틱 하이라이팅(Semantic highlighting), "임포트 정렬", "사용하지 않는 임포트 제거" 등의 기능도 이제 포함되었습니다.

또한 지난 몇 달 동안 성능과 안정성을 계속해서 추진해 왔습니다. 품질 기준을 높게 유지하기 위해 테스트 및 진단 인프라의 상당 부분을 재구축했으며, GitHub의 주요 TypeScript 및 JavaScript 코드베이스를 대상으로 언어 서버를 퍼즈 테스트(Fuzz-test)할 수 있게 되었습니다. 위에서 언급했듯이, TypeScript 7의 새로운 언어 서버는 TypeScript 6보다 훨씬 더 안정적입니다.

TypeScript와 임베디드 언어

Vue, MDX, Astro, Svelte 등을 사용하는 워크플로우는 아직 TypeScript 7을 활용하지 못할 가능성이 높다는 점을 말씀드려야 할 것 같습니다. 마찬가지로 Angular와 같은 템플릿 내의 특수한 타입 체크도 TypeScript 7을 사용하지 않을 가능성이 큽니다. 이는 주로 TypeScript 7이 아직 안정적인 프로그래밍 방식의 API를 노출하지 않기 때문이며, 따라서 TypeScript를 자체 컴파일러와 언어 서버에 임베드하는 도구(예: Volar)는 현재 TypeScript 6.0에만 의존할 수 있습니다. 우리는 이 문제를 해결하기 위해 노력하고 있으므로 이는 일시적인 문제일 것으로 예상합니다. 우리는 이러한 프로젝트의 메인테이너들과 적극적으로 협력하여 TypeScript 7이 이러한 워크플로우를 지원하도록 할 것입니다.

그때까지는 언어 서버 플러그인이 필요하지 않은 시나리오에서 TypeScript 7을 사용할 것을 권장합니다. Angular를 사용하는 프로젝트는 tsc를 사용한 CLI에서의 빠른 프로젝트 전체 에러 감지에는 TypeScript 7을 사용하고, 에디터 지원에는 TypeScript 6.0을 조합하여 사용할 수 있습니다. Vue, MDX, Astro, Svelte 등을 사용하는 프로젝트는 당분간 TypeScript 6.0을 계속 사용해야 합니다. VS Code에서 사용자는 단순히 "Disable TypeScript 7 Language Server" 명령을 실행하여 TypeScript 6.0으로 되돌릴 수 있습니다.

향후 계획

TypeScript 7.0은 TypeScript 프로젝트의 주요 이정표입니다. 이 포팅 작업은 1년 넘게 우리 팀의 주된 관심사였으며, 7.0이 출시됨에 따라 우리는 새로운 기능 작업, 인체공학적 개선, 더 많은 성능 향상, 그리고 더 넓은 생태계를 위한 새로운 API 구현으로 돌아갈 것입니다. 이는 중대한 변화처럼 보이지만, TypeScript 7.0 이전의 릴리스와 상당히 유사한 타임라인을 유지하며 3~4개월마다 새로운 기능이 포함된 버전을 게시할 예정입니다. TypeScript 7.1이 곧 다가옴에 따라, 커뮤니티가 앞으로 나아가는 데 도움이 되도록 모든 공백을 메울 수 있기를 바랍니다.

또한 온라인에서 TypeScript 7.0을 사용한 경험을 공유해 주시기를 권장합니다. Bluesky의 @typescriptlang.org, Mastodon의 @typescript@fosstodon.org, 또는 Twitter의 @typescript를 팔로우하고 태그하여 여러분과 다른 사람들이 TypeScript 7에 대해 어떻게 생각하는지 알려주세요.

우리는 이 새로운 릴리스가 TypeScript 생태계에 엄청난 가치가 있을 것임을 알고 있습니다. 여러분의 일상적인 코딩 경험이 더 빠르고, 재미있고, 생산적이며, 즐거워지기를 바랍니다.

TypeScript 툴셋의 네이티브 시대에 오신 것을 환영합니다.

즐거운 코딩 하세요!

– TypeScript 팀 드림