TypeScript 7.0 RC 해설: Go 네이티브 컴파일러 전환은 속도보다 마이그레이션 경계와 도구 호환성을 먼저 봐야 하는 이유

2026년 6월 18일 공개된 TypeScript 7.0 RC는 단순한 버전 업데이트가 아닙니다. 컴파일러와 언어 서비스의 기반이 JavaScript 실행 환경에서 Go 기반 네이티브 코드로 옮겨가는 전환점입니다. 그래서 이 글의 핵심 질문은 "얼마나 빨라졌나"가 아니라 "우리 팀은 어디까지 안전하게 바꿀 수 있나"입니다.

1. 한 줄 문제 정의

핵심 한 줄: TypeScript 프로젝트가 커질수록 타입 체크 시간과 에디터 지연은 개발 속도를 직접 깎아 먹지만, 컴파일러 교체는 빌드 도구와 린터, 코드 생성기까지 같이 흔들 수 있습니다.

TypeScript 7.0 RC는 이 병목을 Go 기반 네이티브 컴파일러로 줄이려는 릴리스입니다. Microsoft는 7.0이 TypeScript 6.0보다 흔히 약 10배 빠르다고 설명합니다. 다만 RC는 정식 GA 직전 후보라는 뜻이지, 모든 주변 도구가 이미 7.0 구조에 맞춰졌다는 뜻은 아닙니다.

이 글은 대형 TypeScript 앱, 모노레포, Next.js/Vite/Node.js 백엔드, 디자인 시스템 패키지를 운영하는 개발팀을 대상으로 합니다. 반대로 작은 개인 프로젝트에서 타입 체크가 이미 10초 안에 끝난다면 지금 당장 얻는 이익은 제한적입니다.

2. 먼저 결론

핵심 한 줄: 지금 할 일은 전면 교체가 아니라 6.0과 7.0 RC를 나란히 돌려서 차이를 계측하는 것입니다.

제가 추천하는 도입 순서는 세 단계입니다. 먼저 CI에 TypeScript 6.0 기준 타입 체크 시간을 기록합니다. 다음으로 TypeScript 7.0 RC를 별도 job으로 붙여 같은 코드에서 시간, 메모리, 오류 차이를 비교합니다. 마지막으로 lint, test, build, codegen, IDE 확장이 모두 통과할 때만 기본 tsc를 바꿉니다.

지금 바로 평가해야 하는 팀은 타입 체크가 느려서 PR 검토가 밀리는 팀, VS Code에서 대형 타입을 열 때 지연이 큰 팀, 패키지가 많은 모노레포를 운영하는 팀입니다. 아직 관찰만 해도 되는 팀은 TypeScript Compiler API를 깊게 쓰는 빌드 도구, 커스텀 transformer, AST 분석 도구에 크게 의존하는 팀입니다. 공식 발표에서도 안정적인 프로그램 API는 TypeScript 7.1 이후로 잡혀 있습니다.

3. 핵심 구조 분해

핵심 한 줄: TypeScript 7.0은 언어 문법을 바꾼 릴리스라기보다, 같은 타입 규칙을 더 빠른 엔진으로 옮긴 릴리스입니다.

초보 개발자 기준으로 TypeScript를 자동차에 비유하면, .ts 코드는 운전자가 쓰는 지도이고, tsc는 그 지도를 검사하는 정비소입니다. TypeScript 7.0 RC에서 바뀌는 것은 운전 규칙이 아니라 정비소의 장비입니다.

구조는 크게 네 층으로 나눌 수 있습니다. 첫째, 프로젝트의 tsconfig.json이 어떤 파일을 어떤 규칙으로 검사할지 정합니다. 둘째, 컴파일러가 파일 그래프를 읽고 타입 관계를 계산합니다. 셋째, 언어 서비스가 VS Code 같은 에디터에 자동완성, 오류 표시, 정의 이동을 제공합니다. 넷째, ESLint, ts-morph, API Extractor, 프레임워크 플러그인 같은 주변 도구가 TypeScript API를 호출합니다.

7.0 RC의 속도 향상은 주로 둘째와 셋째 층에서 체감됩니다. 하지만 실제 마이그레이션 위험은 넷째 층에서 더 자주 나옵니다. 주변 도구가 기존 JavaScript 기반 TypeScript API를 전제로 만들어졌다면, 컴파일러 본체가 빨라져도 전체 파이프라인은 바로 갈아탈 수 없습니다.

4. 설계 의도 해설

핵심 한 줄: Microsoft가 Go 포트를 선택한 이유는 TypeScript 코드를 새 언어로 재발명하려는 것이 아니라, 기존 의미론을 보존하면서 실행 비용을 줄이려는 쪽에 가깝습니다.

공식 RC 글은 새 Go 코드베이스가 처음부터 다시 쓴 재작성이라기보다 기존 구현을 체계적으로 포팅한 것이라고 설명합니다. 이것이 중요합니다. 완전 재작성은 더 과감한 내부 구조를 만들 수 있지만, 타입 판정 결과가 미묘하게 달라질 위험이 큽니다. 반대로 포팅은 혁신의 폭을 줄이는 대신 호환성 약속을 강화합니다.

Go 선택의 실무적 의미는 세 가지입니다. 네이티브 바이너리라 Node.js 런타임 오버헤드를 덜 받습니다. 공유 메모리와 병렬 처리로 큰 프로젝트를 더 빨리 훑을 여지가 큽니다. 그리고 에디터 언어 서비스도 같은 기반을 쓰면 초기 로딩과 대형 타입 탐색이 가벼워질 수 있습니다.

대신 얻는 만큼 포기하는 것도 있습니다. JavaScript 생태계에서 TypeScript 컴파일러 내부 객체를 직접 만지던 도구는 전환 기간에 보수적으로 움직여야 합니다. 그래서 7.0 RC는 "모든 걸 오늘 바꾸라"는 신호가 아니라, "컴파일러 실행 경계와 API 의존성을 분리하라"는 신호로 보는 편이 정확합니다.

5. 근거 및 비교

핵심 한 줄: 비교 기준은 버전 숫자가 아니라 실행 경계, 호환성, CI 되돌리기 가능성입니다.

선택지	장점	위험	추천 상황
TypeScript 6.0 유지	주변 도구 호환성이 가장 예측 가능함	대형 코드베이스의 타입 체크 병목은 그대로 남음	Compiler API 의존이 많고 릴리스 안정성이 최우선인 팀
TypeScript 7.0 RC 병행	속도 이익을 실제 코드에서 검증 가능함	RC 특성상 회귀나 도구 미지원 가능성이 남음	CI에 추가 job을 붙일 수 있는 팀
즉시 7.0 RC 기본 전환	가장 빠르게 빌드 시간을 줄일 수 있음	lint, codegen, IDE 플러그인에서 예상 밖 문제가 날 수 있음	도구 의존이 단순하고 롤백이 쉬운 내부 프로젝트

공식 자료 기준으로 TypeScript 7.0 RC는 npm install -D typescript@rc로 설치할 수 있습니다. 7.0 Beta 단계에서는 @typescript/native-preview와 tsgo를 통해 6.0과 나란히 비교하는 흐름이 강조됐고, 7.0 안정 릴리스에서는 typescript 패키지와 tsc 진입점으로 전환되는 구조가 예고됐습니다.

Node.js의 TypeScript 타입 스트리핑도 함께 봐야 합니다. Node.js 문서는 TypeScript 파일 실행 시 타입을 지우는 기능이 안정화됐다고 설명하지만, 이 기능은 타입 체크를 하지 않고 tsconfig.json도 읽지 않습니다. 즉 Node의 타입 스트리핑은 실행 편의성의 문제이고, TypeScript 7.0은 타입 검사와 에디터 성능의 문제입니다. 둘은 대체재가 아니라 서로 다른 층입니다.

6. 실제 동작 흐름 / 단계별 실행 방법

핵심 한 줄: 실전 검증은 "현재 기준 기록 → 7.0 RC 별도 실행 → 오류 차이 분류 → 롤백 가능한 전환" 순서가 안전합니다.

먼저 현재 기준을 남깁니다. CI 로그에 이미 타입 체크 시간이 있다면 좋고, 없다면 아래처럼 별도 로그를 남깁니다.

npm ls typescript
time npx tsc --noEmit --pretty false

다음으로 별도 브랜치나 별도 CI job에서 TypeScript 7.0 RC를 설치합니다.

npm install -D typescript@rc
npx tsc --version
time npx tsc --noEmit --pretty false

모노레포라면 패키지별로 결과를 나눠야 합니다. 한 번에 루트만 돌리면 어떤 패키지가 깨졌는지 늦게 알게 됩니다.

pnpm -r exec tsc --noEmit --pretty false
# 또는 turbo/nx를 쓰는 경우 기존 typecheck target을 그대로 사용
pnpm turbo run typecheck --continue

주변 도구 점검은 별도 체크리스트로 분리합니다. eslint, vitest, storybook, api-extractor, ts-morph 기반 스크립트, 프레임워크 빌드를 각각 돌려야 합니다.

pnpm lint
pnpm test
pnpm build
pnpm exec api-extractor run --local

마지막으로 결과를 네 그룹으로 분류합니다. 6.0과 7.0 모두 통과한 항목, 7.0에서 새로 잡힌 실제 버그, 7.0 RC 회귀로 의심되는 항목, 주변 도구 미지원 항목입니다. 이 분류가 있어야 "빠르다"와 "올려도 된다"를 혼동하지 않습니다.

7. 실수/함정

핵심 한 줄: TypeScript 7.0 마이그레이션 실패는 대부분 컴파일러 자체보다 주변 도구 경계를 놓칠 때 생깁니다.

함정 1: 빠른 tsc 결과만 보고 전체 빌드가 빨라졌다고 판단

예방 방법은 tsc --noEmit, 프레임워크 build, lint, test 시간을 따로 기록하는 것입니다. 복구 방법은 병목이 남는 job을 분리해서 TypeScript 문제가 맞는지 확인하는 것입니다.

함정 2: Compiler API 의존 도구를 한 번에 올림

공식 자료는 안정적인 프로그램 API가 7.1 이후에 제공될 예정이라고 설명합니다. 예방 방법은 API 의존 도구를 목록화하는 것입니다. 복구 방법은 @typescript/typescript6 또는 기존 TypeScript 6.x 실행 경로를 남겨 도구별로 천천히 넘기는 것입니다.

함정 3: tsconfig.json 경고를 임시 무시로 덮음

TypeScript 6.0은 7.0을 준비하는 전환 릴리스였습니다. 일부 deprecated 옵션은 6.0에서 ignoreDeprecations로 미룰 수 있지만 7.0에서는 제거될 수 있습니다. 예방 방법은 6.0에서 경고를 먼저 줄이는 것입니다. 복구 방법은 옵션을 제거하거나 대체 설정으로 바꾸는 작은 PR을 먼저 분리하는 것입니다.

함정 4: Node.js 타입 스트리핑과 타입 체크를 혼동

Node.js는 타입을 지우고 실행할 수 있지만 타입 오류를 검사하지 않습니다. 예방 방법은 실행 스크립트에는 erasableSyntaxOnly 같은 제약을 쓰고, CI에는 tsc --noEmit을 별도로 유지하는 것입니다.

8. 강점과 한계

핵심 한 줄: TypeScript 7.0의 강점은 대형 코드베이스에서 크게 보이고, 한계는 도구 생태계의 전환 속도에서 드러납니다.

강점은 명확합니다. 타입 체크가 빠르면 PR 피드백이 빨라집니다. 에디터 응답성이 좋아지면 개발자가 타입을 피하지 않고 더 자주 확인합니다. 모노레포에서는 작은 개선이 아니라 매일 여러 번 반복되는 대기 시간이 줄어듭니다.

하지만 모든 팀에 같은 효과가 나지는 않습니다. 타입 체크보다 번들링, 테스트, E2E가 더 느린 팀은 체감 이익이 작을 수 있습니다. 커스텀 transformer나 AST 기반 내부 도구가 많은 팀은 7.0 전환보다 도구 호환성 확인에 시간이 더 들 수 있습니다.

제 판단은 이렇습니다. TypeScript 7.0 RC는 "도입 후보"로는 충분히 강합니다. 그러나 "기본 컴파일러 즉시 교체"는 CI 롤백이 준비된 팀에만 권합니다. 빠른 도구는 좋은 도구이지만, 빌드 체계에서는 되돌릴 수 있는 도구가 더 좋은 도구입니다.

9. 더 깊게 공부할 포인트

핵심 한 줄: 공부 순서는 RC 발표, 6.0 전환 변경점, 네이티브 포트 배경, Node.js 타입 실행 경계 순서가 좋습니다.

먼저 7.0 RC 발표에서 설치 방식, 6.0 병행 방식, 프로그램 API 제한을 확인합니다. 다음으로 6.0 발표에서 어떤 옵션과 동작이 7.0을 위해 정리됐는지 봅니다. 그 다음 네이티브 포트 발표를 읽으면 왜 Go 기반으로 옮겼는지 이해하기 쉽습니다.

Node.js 백엔드 개발자라면 Node의 TypeScript 문서도 같이 봐야 합니다. 직접 실행 가능한 TypeScript와 타입 체크 가능한 TypeScript는 같은 말이 아닙니다. 이 차이를 이해하면 "빌드 없는 개발 경험"과 "신뢰 가능한 타입 검증"을 분리해서 설계할 수 있습니다.

참고자료

• Announcing TypeScript 7.0 RC - Microsoft Developer Blogs (2026-06-18)
• Announcing TypeScript 7.0 Beta - Microsoft Developer Blogs (2026-04-21)
• Announcing TypeScript 6.0 - Microsoft Developer Blogs (2026-03-23)
• A 10x Faster TypeScript - Microsoft Developer Blogs (2025-03-11)
• Modules: TypeScript - Node.js Documentation (2026-06-21 확인)

10. 실행 체크리스트 + 작성자 관점

핵심 한 줄: TypeScript 7.0 RC는 "빠르니 교체"가 아니라 "빠른지, 같은지, 되돌릴 수 있는지"를 확인한 뒤 바꿔야 합니다.

• 현재 TypeScript 버전과 타입 체크 시간을 CI 로그에 기록했는가?
• TypeScript 7.0 RC를 기존 job 대체가 아니라 별도 job으로 먼저 붙였는가?
• 6.0과 7.0의 오류 차이를 실제 버그, RC 회귀, 도구 미지원으로 분류했는가?
• ESLint, test, framework build, codegen, API 문서 생성까지 함께 통과했는가?
• Compiler API 또는 ts-morph 의존 도구 목록을 만들었는가?
• 롤백 방법이 package.json 한 줄 수정 또는 lockfile 되돌리기로 충분한가?
• Node.js 타입 스트리핑을 쓰는 스크립트와 CI 타입 체크를 분리했는가?

완료 기준(Definition of Done): 같은 커밋에서 TypeScript 6.0 기준 job과 TypeScript 7.0 RC job의 결과, 실행 시간, 오류 차이를 모두 기록했고, 주변 도구까지 통과하거나 미지원 항목의 우회 경로가 문서화된 상태입니다.

작성자 관점에서 저는 TypeScript 7.0 RC를 적극적으로 시험해볼 가치가 있다고 봅니다. 특히 타입 체크가 2분 이상 걸리는 팀은 하루만 투자해도 의사결정에 필요한 숫자를 얻을 수 있습니다. 다만 도구 체인이 복잡한 팀은 7.0을 기본값으로 바꾸기 전에 6.0 실행 경로를 남겨 두는 것이 맞습니다. 이번 전환의 승자는 가장 빨리 올린 팀이 아니라, 가장 빨리 검증하고 가장 쉽게 되돌릴 수 있게 만든 팀입니다.