TypeScript 6.0 마이그레이션: strict 기본값과 tsgo 전환 준비

TypeScript 6.0의 strict 기본화, ES2025·ES2022 전환, 빌드 최적화와 tsgo 호환성 준비 방법을 정리한다.

2026-08-14 · 최초 발행 2026-05-08

기본 설정이 바뀌는 TypeScript 6.0

TypeScript 6.0은 2026년 3월 23일 정식 출시됐다. JavaScript 기반 컴파일러의 마지막 주요 버전이며, strict 모드 기본화, ESNext 계열 기본값 전환, 빌드 시간 20~50% 단축을 통해 Go 컴파일러 기반 TypeScript 7.0(Project Corsa)으로 가는 연결 구간을 맡는다.

이번 변경은 기능 몇 개를 더한 수준이 아니다. 오랫동안 유지된 tsconfig.json 기본값이 바뀌므로, 기존 설정과 암묵적 타입 검사에 기대던 코드가 직접 영향을 받는다.

strict를 명시하지 않은 프로젝트에는 이제 true가 적용된다. 느슨한 타입 검사로 시작하던 새 프로젝트와 달리, TypeScript 6.0에서는 "strict": false를 적지 않는 한 엄격 검사 플래그가 활성화된다.

컴파일 설정의 기본값도 교체됐다.

옵션 이전 기본값 TypeScript 6.0 기본값
target ES3 ES2025
module CommonJS ES2022 (esnext 기반)
types 모든 @types 패키지 [] (명시적 지정 필요)
rootDir 입력 파일에서 추론 .

레거시 옵션도 정리 대상이다. --outFile의 역할은 Vite, esbuild, Rollup 등의 번들러로 넘어갔고, moduleResolution: classic을 사용 중인 경우 nodenext 또는 bundler로 옮겨야 한다. target: es5는 최소 지원 타겟이 ES2015로 올라가면서 deprecation 경고 뒤 삭제가 예고됐다.

strict를 피하지 못하는 코드 경로

명시 없음false 명시tsconfig.json 로드strict 명시 여부?strict: true (신규 기본값)레거시 모드 (임시 지원)noImplicitAny 활성strictNullChecks 활성exactOptionalPropertyTypes 활성strictFunctionTypes 활성strictPropertyInitialization활성ignoreDeprecations: '6.0'필요TS 7.0에서 완전 제거 예정

엄격 모드가 기본값이 되면서, 컴파일러가 추론하지 못했던 영역을 명시적으로 다뤄야 한다.

암묵적 any를 그대로 두지 않는다

이전에는 타입을 추론할 수 없는 매개변수에 암묵적 any가 붙을 수 있었다. TypeScript 6.0에서는 이런 지점이 즉시 오류가 되므로 타입을 지정하거나 좁혀야 한다.

// TypeScript 6.0 이전: 암묵적 any 허용
function process(data) {  // data: any (오류 없음)
  return data.value;
}

// TypeScript 6.0: 오류 발생
// Error: Parameter 'data' implicitly has an 'any' type. ts(7006)
function process(data: unknown) {  // 명시적 타입 필요
  if (typeof data === 'object' && data !== null && 'value' in data) {
    return (data as { value: unknown }).value;
  }
}

optional property의 부재와 undefined를 구분한다

exactOptionalPropertyTypes는 속성이 아예 없는 경우와 undefined를 값으로 설정한 경우를 같은 것으로 취급하지 않는다. 선택 속성에 undefined를 허용해야 한다면 타입에 그 의도를 직접 적어야 한다.

interface UserProfile {
  name: string;
  bio?: string;  // 있거나 없음 (undefined 할당 불가)
}

const profile: UserProfile = {
  name: "Alice",
  bio: undefined  // Error: undefined를 명시적으로 허용하려면 bio?: string | undefined
};

null 가능성은 반환 경로에서 처리한다

strictNullChecks가 적용되면 함수 반환값과 옵셔널 체이닝이 만나는 지점에서도 타입 좁히기가 필요해진다. 존재 여부를 확인하지 않은 객체 접근은 더 이상 통과하지 않는다.

// 6.0 이전
function getUser(id: string) {
  const user = db.find(id);
  return user.name;  // user가 undefined일 수 있어도 오류 없음
}

// 6.0 이후
function getUser(id: string) {
  const user = db.find(id);
  if (!user) throw new Error(`User ${id} not found`);
  return user.name;  // 타입 가드 필수
}

오류량에 맞춰 마이그레이션 범위를 나눈다

오류가 적은 프로젝트라면 Microsoft가 공개한 마이그레이션 CLI로 기계적인 변환을 먼저 처리할 수 있다.

# 공식 마이그레이션 도구
npx @andrewbranch/ts5to6

# 처리 내용:
# - baseUrl → paths 마이그레이션
# - rootDir 명시적 설정
# - import assertions → import attributes 변환
# - 멀티 tsconfig extends 체인 수정

오류가 수천 개라면 strict를 한 번에 적용하기보다, 임시 레거시 모드에서 플래그별로 전환하는 편이 현실적이다.

// 1단계: 임시 레거시 모드 (ts7.0에서 제거 예정)
{
  "compilerOptions": {
    "strict": false,
    "ignoreDeprecations": "6.0"
  }
}
# 2단계: 플래그별 순차 활성화
# noImplicitAny → strictNullChecks → exactOptionalPropertyTypes 순서 권장
단계 활성화 플래그 예상 오류 밀도
1 noImplicitAny 높음 (함수 매개변수)
2 strictNullChecks 중간~높음
3 exactOptionalPropertyTypes 중간
4 strictPropertyInitialization 낮음

증분 빌드와 프로젝트 경계를 다시 활용한다

TypeScript 6.0의 컴파일러 성능 개선은 증분 컴파일, 프로젝트 레퍼런스, 타입 해석 캐싱에서 이뤄진다.

증분 컴파일은 변경 파일과 그 의존 파일만 다시 컴파일하도록 의존성을 추적한다. 단일 컴포넌트를 수정했을 때 전체 코드베이스를 재검증하지 않으며, 벤치마크에서는 증분 빌드 시간이 40~60% 단축됐다.

// tsconfig.json
{
  "compilerOptions": {
    "incremental": true,
    "tsBuildInfoFile": ".tsbuildinfo"
  }
}

대형 모노레포에서는 프로젝트 레퍼런스로 서브패키지를 독립적인 컴파일 단위로 나눌 수 있다. 11분 빌드가 3분으로 줄어든 사례가 보고됐고, 빌드 캐시와 함께 사용하면 중·대형 프로젝트에서 68~74% 단축 효과를 얻을 수 있다.

// packages/core/tsconfig.json
{
  "compilerOptions": {
    "composite": true,
    "outDir": "dist"
  }
}

// packages/app/tsconfig.json
{
  "references": [{ "path": "../core" }]
}
# 빌드 실행
tsc --build

watch 모드에서는 타입 해석 결과를 더 적극적으로 캐시한다. 에디터 응답성은 30% 향상됐고, 메모리 사용량은 25% 감소했다. CI 환경에서는 이 변화가 비용 절감에도 연결된다.

Go 기반 tsgo가 겨냥하는 컴파일러 교체

TypeScript 7.0(Project Corsa)은 Go로 컴파일러를 다시 작성한다. 기존 TypeScript 컴파일러에는 12년 동안 누적된 복잡한 공유 변경 가능 상태(shared mutable state)가 있고, 이 패턴은 Rust의 소유권(ownership) 모델과 충돌한다. Go는 GC 기반 메모리 안전성, goroutine 같은 내장 동시성 프리미티브, 컴파일러 구현에서의 검증된 트랙 레코드를 이유로 선택됐다.

TypeScript 7.0 (Go 컴파일러)TypeScript 6.0 (JS 컴파일러)10x 느림10x 빠름TypeScript 소스tsc (JavaScript)타입 체크 + JS 출력TypeScript 소스tsgo (Go 바이너리)타입 체크 + JS 출력VS Code 1.5M 줄: 77초7.5초

성능 비교에서는 VS Code 1.5M 줄 기준으로 TypeScript 6.0이 77초, TypeScript 7.0 tsgo가 7.5초를 기록해 약 10x 개선을 보였다. 500K 줄 규모의 중간 앱은 약 35초에서 약 3.5초로 줄었으며, 메모리 사용량은 기준의 33%로 3x 절감됐다.

코드베이스 TypeScript 6.0 TypeScript 7.0 (tsgo) 개선율
VS Code (1.5M 줄) 77초 7.5초 ~10x
중간 규모 앱 (500K 줄) ~35초 ~3.5초 ~10x
메모리 사용량 기준 기준의 33% 3x 절감

TypeScript 7.0 베타는 2026년 4월에 공개됐고, 타입 체크 호환성은 98% 이상이다. 6.0 대비 차이는 74건이다. 현재 tsgo--noEmit 타입 체크 모드를 프로덕션 준비 완료 상태로 지원한다. 반면 es2021 이전 타겟, 데코레이터(decorator), watch 모드는 아직 지원되지 않거나 진행 중이며, VS Code 풀 에디터 통합은 2026년 중반으로 예정돼 있다.

TypeScript 6.0에서 strict 모드를 완전히 적용하고 레거시 옵션을 제거한 코드베이스는 7.0(tsgo) 전환 시 추가 마이그레이션 없이 동작 호환성을 보장받는다.

# 현재 tsgo 설치 및 테스트
npm install -g @typescript/native-preview
tsgo --noEmit  # 타입 체크만 수행

업그레이드 전에 확인할 설정

✅ strict: false 또는 ignoreDeprecations: "6.0" 임시 추가
✅ rootDir를 "./src"로 명시 (기존 추론 의존 시)
✅ types 배열을 명시적으로 나열 (예: ["node", "jest"])
✅ module: "commonjs" 명시 (CJS 환경 유지 시)
✅ target을 "es2020" 이상으로 설정 (es5 사용 불가)
✅ outFile 의존 코드 → 번들러(Vite/esbuild)로 이전
✅ moduleResolution: "classic" → "nodenext" 또는 "bundler"
✅ npx @andrewbranch/ts5to6 실행으로 자동 변환
✅ 단계별 strict 플래그 활성화 및 오류 수정
✅ tsgo --noEmit으로 TypeScript 7.0 호환성 사전 검증

TypeScript 6.0은 새 프로젝트의 기본 설정을 현대화하는 동시에, 기존 프로젝트가 TypeScript 7.0으로 넘어갈 수 있도록 정비 기준을 제시한다. strict 적용과 설정 정리는 당장의 오류 수정에 그치지 않고, 10x 빠른 컴파일러로 이동하기 위한 준비 작업이다.

Sources

TypeScripttsconfigstrict 모드빌드 최적화tsgo