TypeScript 6.0 마이그레이션 — strict 기본·Temporal·Go 컴파일러 7.0 준비

핵심 요약

TypeScript 6.0은 5.x JS 코드베이스의 마지막 릴리스다. 7.0은 Go로 재작성된 새 컴파일러(10배 빠름)로, 6.0의 변경은 그 전환을 부드럽게 만들기 위한 정리 작업이다. 지금 6.0으로 안 올라가면 7.0 점프가 더 아프다.

• strict가 기본값 true
• module 기본 esnext, target 기본 ES2025
• Temporal 타입 내장
• #/ subpath imports 정식 지원
• Stage 3 decorator metadata
• target: es5 deprecated (es2015이 최저)

1. strict 기본 — 가장 큰 변경

// 5.x: tsconfig.json에 명시 안 하면 비활성
{ "compilerOptions": {} }
// 6.0: 자동으로 strict: true

// 5.x 동작 유지하려면 명시
{ "compilerOptions": { "strict": false } }

새 프로젝트는 변화 없음. 기존 프로젝트 업그레이드 시 수많은 에러 노출 가능.

가장 흔한 에러

// Error: 'foo' is possibly 'undefined'
function greet(name?: string) {
  return 'Hi, ' + name.toUpperCase()  // strictNullChecks
}

// Error: 'this' implicitly has type 'any'
class Foo {
  bar() { setTimeout(function() { this.baz() }) }  // noImplicitThis
}

// Error: Parameter implicitly has 'any'
function add(a, b) { return a + b }  // noImplicitAny

2. Temporal 내장 — Date 작별 준비

// 5.x — 외부 polyfill
import { Temporal } from '@js-temporal/polyfill'

// 6.0 — 내장 타입
const now = Temporal.Now.zonedDateTimeISO('Asia/Seoul')
const tomorrow = now.add({ days: 1 })
const diff = tomorrow.since(now)  // Duration

// 시간대 정확한 비교
const meeting = Temporal.ZonedDateTime.from({
  year: 2026, month: 5, day: 1,
  hour: 14, timeZone: 'Asia/Seoul',
})

런타임 polyfill은 별도 필요(엔진 구현 진행 중). 타입만 표준화.

3. #/ subpath imports — 정식

// package.json
{
  "imports": {
    "#utils/*": "./src/utils/*.ts",
    "#config": "./src/config/index.ts"
  }
}

// 사용
import { format } from '#utils/date'
import config from '#config'
// tsconfig paths 없이 동작

Node.js·Bun도 동일 spec 따라가서 런타임 일관성. tsconfig paths 점진 대체 가능.

4. ES2025 default + 표준 라이브러리 추가

// 새로 lib에 포함:
// - Set.prototype.union/intersection/difference 등
// - Promise.try
// - Iterator helpers (.map, .filter, .take, .toArray)
// - RegExp /v flag
// - Float16Array

// 예시
const result = items.values()
  .filter(x => x.active)
  .map(x => x.id)
  .take(10)
  .toArray()
// 5.x에선 .filter는 Array에만

5. Stage 3 Decorator — metadata 지원

const meta = Symbol.metadata

class User {
  @reflect
  accessor name: string
}

function reflect(target: any, ctx: ClassFieldDecoratorContext) {
  ctx.metadata.fields ??= []
  ctx.metadata.fields.push(ctx.name)
}

console.log(User[meta]?.fields)  // ['name']
// 프레임워크가 reflect-metadata 없이 메타 추출 가능

NestJS·TypeORM 같은 프레임워크 영향 큼. 마이그레이션은 6.0에선 opt-in.

6. 6.0 → 7.0 (Go 재작성) 미리보기

7.0은 동일 언어 사양. 코드 변경 0, 도구만 교체. 6.0에서 strict·decorator·Temporal 정리해두면 7.0 전환 매끄러움.

7. 마이그레이션 단계

Step 1: 6.0 RC 설치 + strict 끄고 빌드

npm i -D typescript@~6.0.0
// tsconfig.json
{ "compilerOptions": { "strict": false, "target": "ES2020" } }
// 일단 컴파일 통과시키기

Step 2: target 점진 상승

// ES2020 → ES2022 → ES2025
// 각 단계마다 빌드 + 테스트

Step 3: strict 옵션 1개씩

// strictNullChecks → noImplicitAny → noImplicitThis → strictFunctionTypes ...
// 한 번에 켜지 말고 한 옵션씩
{ "compilerOptions": {
  "strictNullChecks": true,
  "noImplicitAny": true
}}

Step 4: subpath imports로 마이그레이션

// 기존 paths
"paths": { "@utils/*": ["src/utils/*"] }
// → package.json imports로 이전 (런타임도 동작)

Step 5: Decorator metadata

NestJS 11+, TypeORM 0.4+에서 stage 3 지원. 둘 다 stable 후 전환.

8. 깨지는 외부 라이브러리

• 옛날 reflect-metadata 의존 코드 — stage 3로 전환 필요
• target es5 명시한 빌드 스크립트 — es2015 이상으로
• Date 직렬화 폴리필 일부 — Temporal과 충돌 가능
• tsconfig "module": "commonjs"는 그대로 동작 (수정 안 해도 됨)

9. 점검 체크리스트

1. tsc --noEmit로 에러 카운트 (수백 개면 단계 분할)
2. strict 옵션 1개씩 enable
3. tsconfig target 1단계씩 올림
4. 외부 라이브러리 6.0 호환 확인 (특히 NestJS·tRPC·zod)
5. CI에 ts 6.0 + 5.x 매트릭스 빌드 (점진 전환)
6. 패키지 자체가 라이브러리면 peerDependencies에 ts ^5.0.0 || ^6.0.0 표기

10. 7.0이 나오면?

2026년 하반기 7.0 RC, 2027년 정식 예상. 6.0에서 strict·Temporal·subpath까지 정리해두면 7.0 업그레이드는 패키지 매니저 명령 1줄.

자주 묻는 질문

5.x로 머물러도 되나?

2026년 말까지는 OK. 2027년부터 새 라이브러리들이 6.0 syntax 쓰기 시작하면 격차 누적.

strict 켜는 게 너무 빡센데 회피책?

// 점진 도입 — 파일 단위 비활성
// @ts-strict-ignore
// 또는 디렉터리 단위
// tsconfig.legacy.json
{ "extends": "./tsconfig.json", "compilerOptions": { "strict": false }, "include": ["legacy/**"] }

Bun·Deno는 6.0 지원?

Bun 1.2+ 6.0 syntax 파싱 OK. Deno도 마찬가지. 단 stage 3 decorator는 런타임 polyfill 필요할 수 있음.