2026년 3월 6일, TypeScript 팀이 TypeScript 6.0 RC를 공개했습니다. 이번 릴리스는 단순한 기능 추가 버전이 아니라, 앞으로 이어질 TypeScript 7 네이티브 포트 전환의 징검다리라는 점에서 의미가 큽니다.
이미 TypeScript를 실무에 쓰고 있다면 이번 버전에서 중요한 건 “새 문법이 몇 개 늘어났다”가 아닙니다. 어떤 설정과 문법이 사라질 준비를 하고 있는지, 그리고 지금 손봐야 TS 7 전환 때 덜 아픈지를 읽어야 합니다.
이 글에서는 TypeScript 6.0 RC 기준으로 꼭 봐야 할 변화만 추려서 정리하고, 실무 프로젝트에서 바로 점검할 체크포인트까지 연결해 보겠습니다.
왜 TypeScript 6.0이 중요한가
TypeScript 팀은 6.0을 현재 JavaScript 코드베이스 기반의 마지막 큰 전환 릴리스로 설명합니다. 이후 나올 TypeScript 7은 Go 기반 네이티브 코드베이스를 토대로 한 새 세대 컴파일러가 될 예정입니다.
이 방향은 갑자기 나온 얘기가 아닙니다. 2025년 3월 TypeScript 팀은 공식 블로그에서 최대 10배 빠른 TypeScript를 목표로 네이티브 포트를 진행 중이라고 밝혔고, 2026년 2월 11일 6.0 Beta, 2026년 3월 6일 6.0 RC를 통해 그 전환 경로를 구체화했습니다.
- TypeScript 6.0 RC: Announcing TypeScript 6.0 RC ↗
- TypeScript 6.0 Beta: Announcing TypeScript 6.0 Beta ↗
- 네이티브 포트 배경: A 10x Faster TypeScript ↗
즉, 6.0은 새 기능을 맛보는 버전이면서 동시에 TS 7 호환성을 미리 정리하는 버전입니다.
이번 RC에서 개발자가 바로 체감할 만한 변화
1. this를 쓰지 않는 함수의 타입 추론이 더 자연스러워졌습니다
RC에서 눈에 띄는 변화 중 하나는 generic call 안의 함수 표현식 타입 추론 개선입니다. 특히 객체 리터럴 안에서 메서드 문법을 사용할 때, 기존보다 덜 까다롭게 추론됩니다.
TypeScript 팀 설명대로 이전에는 this를 암묵적으로 가질 수 있는 함수가 문맥적으로 민감한 함수로 취급되면서 추론 우선순위에서 밀리는 경우가 있었습니다. 6.0에서는 실제로 this를 사용하지 않는 함수라면 이런 제약을 완화해 더 많은 코드를 자연스럽게 통과시킵니다.
이 변화는 대규모 코드베이스에서 “왜 arrow function은 되는데 method syntax는 안 되지?” 같은 의문을 줄여줍니다. 특히 JSX generic 사용이나 복잡한 helper API를 많이 쓰는 팀이라면 체감 가능성이 높습니다.
2. Node 서브패스 import에서 #/ 패턴을 공식 지원합니다
6.0은 Node의 subpath imports와 더 자연스럽게 맞물립니다. 이제 최신 Node 20 계열 환경과 함께 #/로 시작하는 import alias를 TypeScript에서도 지원합니다.
예를 들면 다음처럼 작성할 수 있습니다.
{
"imports": {
"#": "./dist/index.js",
"#/*": "./dist/*"
}
}
import { formatDate } from "#/utils/date.js";
기존 상대 경로 지옥을 줄이고 싶지만, 번들러 전용 alias와 Node 표준 방식 사이에서 애매했던 프로젝트라면 이 지원이 꽤 반갑습니다. 다만 공식 블로그 기준으로 이 동작은 node20, nodenext, bundler 해석 전략에서 맞물려 동작하므로, 현재 tsconfig 조합을 같이 확인해야 합니다.
3. --stableTypeOrdering로 TS 7 차이를 미리 줄일 수 있습니다
6.0의 핵심 메시지는 “TS 7 대비”입니다. 그 상징 같은 옵션이 바로 --stableTypeOrdering입니다.
TypeScript 7은 병렬 타입 체크와 네이티브 구현 특성 때문에 내부 타입 정렬 방식이 더 결정적이어야 합니다. 그래서 6.0에 7.0과 더 유사한 타입 정렬 동작을 미리 흉내 내는 옵션이 들어왔습니다.
이 옵션은 특히 다음 상황에서 유용합니다.
- declaration emit 차이를 비교해야 할 때
- 6.0과 7.0 preview 결과를 나란히 검증할 때
- 순서 차이 때문에 노이즈가 커지는 대형 저장소에서 마이그레이션 리스크를 줄이고 싶을 때
다만 TypeScript 팀은 이 옵션이 상시 권장 옵션은 아니며, 코드베이스에 따라 타입 체크 성능 저하가 생길 수 있다고 안내합니다. 즉, 운영 기본값이라기보다 전환 점검용 도구로 보는 편이 정확합니다.
라이브러리와 표준 API 측면의 변화
es2025 target/lib가 추가됐습니다
6.0은 target과 lib에 es2025 옵션을 추가했습니다. JavaScript 언어 문법 자체가 크게 늘었다기보다, 표준 라이브러리 타입 구성이 조금 더 정돈된 쪽에 가깝습니다.
대표적으로 공식 글은 다음 항목을 예로 듭니다.
RegExp.escapePromise.try- Iterator 관련 메서드
Set관련 메서드
이미 런타임과 폴리필 전략이 정리된 프로젝트라면, esnext 대신 조금 더 구체적인 타깃을 검토해 볼 시점입니다.
Temporal 타입이 내장됩니다
드디어 Temporal API 타입이 TypeScript에 기본 포함됩니다. 공식 글 기준으로 --target esnext 또는 "lib": ["esnext"] 같은 설정에서 사용할 수 있습니다.
날짜와 시간을 다룰 때 Date의 한계를 느껴 왔다면 반가운 변화입니다. 아직 런타임 지원은 환경별로 다르지만, 최소한 타입 정의를 별도 패키지에 의존하지 않고 실험할 수 있다는 점이 큽니다.
const tomorrow = Temporal.Now.instant().add({
hours: 24,
});
Map#getOrInsert, RegExp.escape 같은 표준 API 타입도 따라옵니다
이번 릴리스는 “새로운 TypeScript 전용 기능”보다 표준 JavaScript 생태계를 더 빠르게 타입 시스템에 반영한다는 느낌이 강합니다. 즉, TS 6.0을 보는 관점도 “문법 업데이트”보다는 “현대 JS 실행 환경과의 정렬”에 가깝습니다.
진짜 중요한 포인트: 무엇이 사라지거나 바뀌는가
실무에서 더 중요한 건 여깁니다. 6.0은 여러 설정과 오래된 문법에 대해 분명하게 선을 긋습니다.
assert 기반 import assertions는 사실상 종료 수순입니다
이제 아래 문법은 더 이상 미래 지향적이지 않습니다.
import data from "./foo.json" asserts { type: "json" };
대신 import attributes의 with 문법을 써야 합니다.
import data from "./foo.json" with { type: "json" };
JSON import, CSS module import, asset import 주변을 정리하던 팀이라면 이건 꼭 반영해야 합니다.
tsconfig.json이 있는데 tsc foo.ts를 실행하면 이제 에러가 납니다
기존에는 프로젝트 루트에 tsconfig.json이 있어도 파일 인자를 직접 넘기면 그 설정이 무시되는 경우가 있었습니다. 이 동작은 혼란을 자주 만들었고, 6.0에서는 이를 명시적인 에러로 바꿨습니다.
공식 예시는 아래와 같습니다.
tsc foo.ts
error TS5112: tsconfig.json is present but will not be loaded if files are specified on commandline. Use '--ignoreConfig' to skip this error.
이건 CI나 스크립트에서 생각보다 영향이 큽니다. package.json scripts, custom build wrappers, editor task 설정에 tsc <file> 패턴이 남아 있다면 미리 찾아보는 편이 안전합니다.
여러 deprecated 옵션은 7.0에서 더 이상 버틸 수 없습니다
Beta 공지의 핵심 메시지는 분명합니다. 6.0에서 보이는 deprecation은 그냥 경고가 아니라 7.0 제거 예고장에 가깝습니다.
공식 글은 필요하면 tsconfig.json에 아래 설정으로 deprecation을 일시 무시할 수 있다고 안내합니다.
{
"compilerOptions": {
"ignoreDeprecations": "6.0"
}
}
하지만 이건 유예책일 뿐입니다. 장기적으로는 없앨 설정을 계속 끌고 가는 셈이라, 샘플 저장소나 레거시 패키지부터 차례로 정리하는 편이 맞습니다.
실무 프로젝트에서 지금 바로 점검할 체크리스트
TypeScript 6.0 RC를 바로 도입하지 않더라도, 아래는 지금 확인할 가치가 있습니다.
1. tsconfig에 낡은 옵션이 남아 있는지 확인합니다
- deprecated compiler option 사용 여부
- import assertions 구문 사용 여부
moduleResolution과module조합이 현재 런타임과 맞는지dom.iterable같은 과거 관성 설정이 불필요하게 남아 있는지
2. 사내 빌드 스크립트에서 tsc <file> 패턴을 찾습니다
테스트용으로 한두 파일만 검사하던 스크립트가 의외로 많습니다. 6.0부터는 이런 사용이 더 명확하게 깨질 수 있으니, tsc -p, tsc --project, 또는 필요 시 --ignoreConfig를 의도적으로 쓰는 쪽으로 바꾸는 게 낫습니다.
3. TS 7을 염두에 두고 경고를 빚처럼 쌓아두지 않습니다
6.0은 끝이 아니라 중간 버전입니다. 지금 경고를 미뤄 두면, TS 7 전환 때는 성능 개선의 이점보다 설정 제거 대응에 시간을 더 쓰게 될 가능성이 큽니다.
4. 큰 저장소라면 --stableTypeOrdering로 차이를 미리 측정합니다
특히 declaration emit이나 API report를 체크인하는 저장소라면, 이 옵션으로 7.0 preview와의 diff를 먼저 줄여 보는 게 좋습니다.
그래서 지금 업그레이드해야 할까
2026년 3월 13일 기준, 공식 최신 상태는 TypeScript 6.0 RC입니다. 아직 정식 릴리스가 아니라서 모든 팀이 즉시 production 기본값으로 올릴 필요는 없습니다.
하지만 아래 조건이라면 지금 테스트할 이유가 충분합니다.
- TypeScript 버전을 자주 따라가는 팀
- Node ESM, bundler, modern web platform API를 적극 활용하는 팀
- TS 7 네이티브 포트 전환을 미리 대비하고 싶은 팀
- 대형 모노레포에서 타입 체크 성능과 안정성을 중요하게 보는 팀
반대로 레거시 tsconfig 의존성이 강하거나 오래된 import 패턴이 많다면, 바로 전면 업그레이드보다 경고 정리와 설정 청소를 먼저 하는 편이 현실적입니다.
마무리
TypeScript 6.0 RC의 핵심은 기능 몇 개보다도 방향성입니다. 이제 TypeScript는 현대적인 JavaScript 표준과 더 밀착되고 있고, 동시에 TypeScript 7 네이티브 전환을 위한 정리 작업을 본격화하고 있습니다.
실무 관점에서 기억할 건 세 가지입니다.
- 6.0은 TS 7 전환 준비 버전입니다.
- deprecated 경고는 곧 제거될 가능성이 큽니다.
- 지금 미리
tsconfig, import 문법, 빌드 스크립트를 점검하면 다음 업그레이드가 훨씬 쉬워집니다.
곧 정식 릴리스가 나오면 RC와의 차이도 다시 정리해 볼 만합니다. 그전까지는 공식 RC 글과 Beta 글을 기준으로, 프로젝트에 어떤 설정 부채가 남아 있는지부터 확인해 보시길 권합니다.