[번역] TypeScript 7.0 RC 발표

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

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

Daniel Rosenwasser - 2026-06-18

오늘 우리는 TypeScript 7.0의 릴리스 후보(Release Candidate, RC) 버전을 발표하게 되어 매우 기쁩니다!

그동안 TypeScript 7.0의 개발 과정을 지켜보지 않으셨다면, 이번 릴리스가 완전히 새로운 토대 위에 구축되었다는 점이 매우 중요하게 다가올 것입니다. 지난 1년 동안 우리는 기존의 TypeScript 코드베이스(JavaScript로 컴파일되는 부트스트랩된 코드베이스)를 Go 언어로 포팅(Porting)해 왔습니다. 네이티브 코드의 속도와 공유 메모리 병렬 처리(Shared Memory Parallelism)가 결합된 TypeScript 7.0은 TypeScript 6.0보다 종종 약 10배 더 빠릅니다.

새로운 컴파일러를 사용하려면 다른 릴리스와 마찬가지로 npm에서 typescript 패키지를 설치하면 됩니다.

npm install -D typescript@rc

새로운 Go 코드베이스는 처음부터 다시 작성된 것이 아니라 기존 구현에서 체계적으로 포팅되었으며, 타입 체크 로직은 구조적으로 TypeScript 6.0과 동일합니다. 이러한 아키텍처적 동등성 덕분에 컴파일러는 여러분이 이미 의존하고 있는 것과 정확히 동일한 시맨틱(Semantics)을 계속해서 강제할 수 있습니다. TypeScript 7.0은 지난 10년 동안 구축해 온 방대한 테스트 스위트를 통해 검증되었으며, 이미 Microsoft 내부 및 외부의 수백만 라인 규모의 여러 코드베이스에서 사용되고 있습니다. 매우 안정적이고 호환성이 높으며, 지금 바로 여러분의 일상적인 워크플로우와 CI 파이프라인에서 테스트할 준비가 되어 있습니다.

우리는 1년 넘게 Microsoft 내부의 여러 팀을 비롯하여 Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Slack, Vanta, Vercel, VoidZero 등 여러 기업의 팀과 협력하여 그들의 코드베이스에서 TypeScript 7.0의 프리릴리스 빌드를 테스트해 왔습니다. 피드백은 압도적으로 긍정적이었으며, 많은 팀이 빌드 시간의 대부분을 단축하고 훨씬 더 가볍고 유연한 편집 환경을 경험하며 유사한 속도 향상을 보고했습니다. 결과적으로 우리는 이번 릴리스 후보가 훌륭한 상태라고 확신하며, 여러분이 직접 사용해 보시기를 고대하고 있습니다.

TypeScript 7.0 RC 사용하기

앞서 언급했듯이, TypeScript 7.0 RC를 사용하려면 npm을 통해 설치할 수 있습니다.

npm install -D typescript@rc

설치 후에는 이전 버전의 TypeScript와 마찬가지로 tsc를 실행할 수 있으며, 이전과 동일한 결과를 훨씬 더 빠르게 확인할 수 있습니다!

> npx tsc --version
Version 7.0.1-rc

편집 환경을 경험해 보려면 VS Code용 TypeScript Native Preview 확장 프로그램을 설치할 수 있습니다. 에디터 지원은 매우 견고하며 이미 수개월 동안 많은 팀에서 널리 사용되고 있습니다. 이는 여러분의 코드베이스에서 즉시 TypeScript 7.0을 사용해 볼 수 있는 쉽고 부담 없는 방법입니다. 이 확장 프로그램은 커맨드 라인 환경과 동일한 기반을 사용하므로, 커맨드 라인에서와 마찬가지로 에디터에서도 동일한 성능 향상을 누릴 수 있습니다. 특히 언어 서버 프로토콜(Language Server Protocol, LSP)을 기반으로 구축되어 대부분의 현대적인 에디터나 Copilot CLI와 같은 도구에서도 쉽게 실행할 수 있습니다.

TypeScript 6.0과 병행 실행하기

7.0 RC가 프로덕션에 투입될 준비가 거의 되었음에도 불구하고, 안정적인 프로그래밍 방식의 API(Programmatic API)는 최소 몇 달 후인 TypeScript 7.1이 되어야 제공될 예정입니다. 이를 고려하여, 우리는 당분간 "어떤 것이 진짜 tsc인가?"라는 충돌 없이 TypeScript 6.0과 7.0을 병행해서 실행할 수 있도록 보장하는 것을 우선순위로 두었습니다.

6.0에서 7.0으로의 전환 과정의 일환으로, 우리는 새로운 호환성 패키지인 @typescript/typescript6를 출시했습니다. 이 패키지는 tsc6라는 이름의 실행 파일을 제공하므로, 필요한 경우 자체 tsc 바이너리를 포함하는 TypeScript 7.0과 이름 충돌 없이 나란히 설치할 수 있습니다. 또한 이 새로운 패키지는 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.0"
  }
}

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

{
  "devDependencies": {
    "typescript": "npm:@typescript/typescript6@^6.0.0",
    "typescript-7": "npm:typescript@rc"
  }
}

Nightly 릴리스

TypeScript 7의 나이틀리(Nightly) 버전은 현재 npm의 @typescript/native-preview 패키지로 계속 게시되고 있으며, 다음 명령으로 설치할 수 있습니다.

npm install -D @typescript/native-preview

해당 패키지에서 제공하는 바이너리 이름은 여전히 tsgo입니다. TypeScript 7이 npm에서 latest 태그로 게시되면, 모든 안정 버전, 주요 프리릴리스 및 나이틀리 버전이 npm의 typescript 패키지로 게시될 예정입니다.

병렬화 및 제어

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

체커(Checker) 병렬화

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

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

타입 체크 워커의 기본 개수는 4개이지만, 새로운 --checkers 플래그로 설정할 수 있습니다. 일반적인 머신이 더 많은 CPU 코어를 가진 대규모 코드베이스에서는 이 숫자를 늘려 빌드 속도를 더 높일 수 있지만, 일반적으로 메모리 사용량이 증가하는 비용이 발생합니다. 마찬가지로 CPU 코어가 적고 메모리가 적은 머신(예: CI 러너)에서는 불필요하거나 부수적인 오버헤드를 피하기 위해 이 숫자를 줄이는 것이 좋을 수 있습니다.

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

프로젝트 참조 빌더(Project Reference Builder) 병렬화

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

--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 패키지를 명시적으로 나열 (예: bun, mocha, jasmine 등)
+         "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로 설정할 수 없습니다.

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

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

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

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

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

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

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 선언을 사용하세요.

후위(Postfix) !는 지원되지 않습니다. 그냥 T를 사용하세요.

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

Closure 스타일의 함수 구문(예: function(string): void)은 더 이상 지원되지 않습니다. 대신 TypeScript 약어(Shorthand)를 사용하세요(예: (s: string) => void).

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

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

에디터 경험

TypeScript 7.0의 성능 향상은 커맨드 라인 경험에만 국한되지 않고 에디터 경험으로도 확장됩니다. VS Code 사용자의 경우, TypeScript Native Preview 확장 프로그램은 에디터에서 TypeScript 7.0을 사용해 볼 수 있는 원활한 방법을 제공하며 널리 사용되고 있습니다. Visual Studio 사용자의 경우, 최신 버전의 에디터가 워크스페이스에 따라 자동으로 TypeScript 7을 활성화합니다. 물론 TypeScript 7은 여러분이 선택한 어떤 에디터에서도 훌륭하게 작동할 것입니다. 새로운 토대는 언어 서버 프로토콜(LSP)을 기반으로 구축되었으며, 여러 스레드를 활용하여 동시 요청을 최대한 빠르게 처리할 수 있습니다.

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

또한 지난 몇 달 동안 성능과 안정성을 지속적으로 개선해 왔습니다. 품질 기준을 높게 유지하기 위해 테스트 및 진단 인프라의 상당 부분을 재구축했으며, GitHub의 주요 TypeScript 및 JavaScript 코드베이스를 대상으로 언어 서버를 퍼즈 테스트(Fuzz-test)할 수 있게 되었습니다. 데이터 통찰력에 따르면, TypeScript 7은 실제로 TypeScript 6.0에 비해 실패하는 언어 서버 명령을 20배 이상 줄였다고 믿습니다.

이 확장 프로그램은 Visual Studio Code의 내장 TypeScript 확장 프로그램과 거의 동일한 설정 및 대부분의 기능을 지원합니다.

TypeScript 7.0을 향한 여정

이제 TypeScript 7.0 RC를 사용할 수 있게 되었으며, 우리의 현재 계획은 다음 달 내에 TypeScript 7.0을 정식 출시하는 것입니다. 우리는 릴리스 조율 및 물류, 보고된 회귀(Regression) 문제, 그리고 TypeScript 7.1의 향후 API 기능에 집중할 것입니다.

그때까지 실제 프로젝트에서 TypeScript 7.0을 사용해 보시고 피드백을 주시면 특히 감사하겠습니다. 문제가 발생하면 microsoft/typescript-go 이슈 트래커에 알려주시면 안정적인 릴리스가 훌륭한 상태가 될 수 있도록 최선을 다하겠습니다.

또한 TypeScript 7.0 사용 경험을 공유하고 Bluesky의 @typescriptlang.org, Mastodon의 @[email protected], 또는 Twitter의 @typescript를 태그해 주시기 바랍니다.

우리 팀은 여러분이 이번 릴리스를 사용해 보게 되어 매우 기쁩니다. 지금 바로 사용해 보시고 의견을 들려주세요. 즐거운 코딩 되세요!

– TypeScript 팀 드림