TypeScript 7 마이그레이션 가이드: Go 네이티브 컴파일러 전환 전 확인할 것

TypeScript 7은 기존 컴파일러를 조금 튜닝한 버전이 아니다. Microsoft가 TypeScript 컴파일러와 언어 서비스를 Go로 옮긴 네이티브 구현이다. 공식 벤치마크의 큰 속도 향상은 매력적이지만, 프레임워크 플러그인과 프로그래밍 API를 사용하는 프로젝트는 숫자만 보고 바로 교체하면 안 된다.

먼저 보는 결론

2026년 7월 28일 기준 TypeScript 7.0이 정식 공개됐다. 일반적인 tsc 타입 검사 프로젝트는 병행 검증을 시작할 수 있지만 Vue·Svelte·Astro·MDX·Angular처럼 TypeScript API와 언어 서비스 통합에 의존하는 환경은 공식 호환 상태를 먼저 확인해야 한다.

목차

1. Go 포팅이 빨라진 이유와 벤치마크 해석
2. TypeScript 6과 7의 역할
3. 전환 전 호환성 점검
4. 두 컴파일러를 함께 돌리는 검증 방법
5. 실패 없이 전환하는 단계별 절차

1. “10배”는 모든 작업이 10배라는 뜻이 아니다

Microsoft의 초기 공식 측정에서 VS Code 코드베이스 타입 검사는 77.8초에서 7.5초, Playwright는 11.1초에서 1.1초로 줄었다. 병렬 처리와 메모리 공유가 가능한 네이티브 구조가 큰 프로젝트의 로딩과 타입 검사에 유리했다.

프로젝트	기존 구현	네이티브 구현	공식 측정 속도 향상
VS Code	77.8초	7.5초	10.4배
Playwright	11.1초	1.1초	10.1배
TypeORM	17.5초	1.3초	13.5배
date-fns	6.5초	0.7초	9.5배

이 수치는 Microsoft가 공개한 특정 코드베이스의 타입 검사 결과다. 애플리케이션 번들링, 테스트, 네트워크 요청, 런타임 실행이 모두 10배 빨라지는 것은 아니다. 실제 프로젝트에서는 tsc --noEmit 시간과 에디터 초기화, CI 전체 시간을 분리해 측정한다.

측정할 항목을 섞지 않는다.

기존 CI가 10분이고 타입 검사가 30초였다면 컴파일러가 10배 빨라져도 전체 시간은 약 27초만 줄 수 있다. 병목이 테스트나 Docker 빌드라면 체감이 작다.

2. TypeScript 7은 6의 동작을 기준으로 이어진다

TypeScript 7은 TypeScript 6의 타입 검사와 명령행 동작에 맞춰 설계됐다. 6에서 폐기된 옵션은 7에서 오류가 될 수 있고, strict와 모듈·타깃 기본값 변화도 확인해야 한다. 먼저 TypeScript 6에서 경고와 폐기 설정을 정리하면 전환 폭을 줄일 수 있다.

영역	바로 시험하기 좋은 경우	기다리거나 병행해야 하는 경우
CLI 타입 검사	표준 tsconfig.json과 tsc --noEmit 사용	폐기 옵션·특수 모듈 해석에 의존
에디터	VS Code 기본 TS/JS 편집 기능	전용 언어 서비스 플러그인에 의존
프레임워크	일반 React·Node 프로젝트	Vue·Svelte·Astro·MDX·Angular 템플릿 타입 검사
도구 연동	컴파일러를 명령으로만 실행	TypeScript 프로그래밍 API를 직접 호출

728x90

3. 설치 전에 의존 방식을 검색한다

# package.json과 코드에서 TypeScript API 의존 확인
rg '"typescript"' package.json pnpm-lock.yaml package-lock.json yarn.lock
rg "from ['\"]typescript['\"]|require\\(['\"]typescript['\"]\\)" .

# 폐기 예정 설정 확인
npx tsc --showConfig > current-tsconfig.json
npx tsc --noEmit

빌드 도구, 린터, 코드 생성기, 프레임워크 플러그인이 typescript 패키지의 API를 직접 호출하면 CLI 결과만 같아도 전체 작업이 깨질 수 있다. 모노레포라면 패키지별 설정과 프로젝트 참조도 따로 확인한다.

4. 기존 컴파일러와 같은 커밋을 비교한다

전환 첫날부터 기존 검사를 제거하지 않는다. 같은 소스에서 TypeScript 6과 7을 함께 실행하고 오류 목록, 생성 파일, 실행시간을 저장한다.

{
  "devDependencies": {
    "@typescript/native": "npm:typescript@^7.0.2",
    "typescript": "npm:@typescript/typescript6@^6.0.2"
  },
  "scripts": {
    "typecheck:ts6": "tsc6 --noEmit",
    "typecheck:ts7": "tsc --noEmit",
    "typecheck:compare": "npm run typecheck:ts6 && npm run typecheck:ts7"
  }
}

공식 안내의 별칭 설치 방식을 사용하면 같은 프로젝트에서 두 버전을 비교할 수 있다. 실제 버전 번호는 설치 전에 npm과 공식 릴리스 문서에서 다시 확인한다.

오류 결과 비교빌드 산출물 비교에디터 기능 확인CI 시간 측정

비교 결과에 남길 값

• 두 버전의 정확한 패키지 버전과 Node.js 버전
• 클린 캐시와 웜 캐시 각각의 실행시간
• 오류 개수뿐 아니라 오류 코드·파일·위치 차이
• 선언 파일과 JavaScript emit 차이
• 자동 import, rename, find references 등 팀이 쓰는 편집 기능
• 프레임워크 빌드·테스트·린트 결과

5. 전환은 기능 플래그처럼 되돌릴 수 있게 한다

1. TypeScript 6에서 폐기 옵션과 새 기본값 문제를 먼저 해결한다.
2. TypeScript 7을 별칭으로 설치해 CI의 비차단 작업으로 추가한다.
3. 1~2주 동안 오류 차이와 실행시간을 기록한다.
4. 지원하지 않는 프레임워크 작업은 TypeScript 6에 남긴다.
5. 차이가 없는 패키지부터 TypeScript 7 검사를 필수 게이트로 바꾼다.
6. 문제가 생기면 패키지 별칭과 에디터 설정을 되돌린다.

채택 판단 예시

모노레포의 백엔드 패키지는 타입 검사 92초가 11초로 줄고 오류 결과가 같았다. Vue 프론트엔드는 템플릿 타입 검사 도구가 기존 API에 의존했다. 따라서 백엔드는 TypeScript 7을 필수 검사로 전환하고 프론트엔드는 TypeScript 6을 유지한다. 저장소 전체를 한 번에 바꿀 필요는 없다.

전환 판단은 한 번으로 끝나지 않는다

TypeScript 7 패치 릴리스나 프레임워크의 네이티브 컴파일러 지원 공지가 나오면 보류한 패키지를 다시 검사한다. CI에 버전·오류 차이·실행시간을 남겨두면 감으로 재논의하지 않고 이전 측정값과 바로 비교할 수 있다.

핵심 요약

• 공식 10배 수치는 특정 코드베이스의 타입 검사 결과이며 전체 CI 속도와 다르다.
• TypeScript 6의 폐기 옵션과 기본값 변화를 먼저 정리한다.
• 프레임워크 플러그인과 프로그래밍 API 의존 여부가 핵심 호환성 기준이다.
• 두 컴파일러를 같은 커밋에서 병행 실행하고 패키지 단위로 전환한다.

참고한 공식 자료

• Microsoft: Announcing TypeScript 7.0
• Microsoft: A 10x Faster TypeScript
• Microsoft TypeScript Go 저장소
• TypeScript 7 의도된 변경 사항

확인 기준일: 2026년 7월 28일. 기존 글의 AI 논문 목록과 Oracle 서버 내용은 TypeScript 전환과 직접 관련이 없어 보존하지 않았다.