TypeScript 7.0 Beta 공개, 무엇이 달라졌는가

 

출처: Microsoft Developer Blogs | 3일 전 (41KB)

 

tsc가 10배 빨라졌다는 소식은 사실이다. MS가 2026년 4월에 TypeScript 7.0 Beta를 공개했는데, 한 줄로 요약하면 컴파일러를 Go로 다시 작성한 것이다. 그 결과 VS Code 1.5M LOC 기준 타입체크가 77.8초에서 7.5초로 줄었다. 메모리 사용량도 절반이다.

 

다만 솔직히 5.x도 충분히 잘 돌아가지 않았는가. 굳이 7.0이 필요했던 이유, 그리고 5.x에서 갈아탈 때 무엇이 깨지는지가 진짜 궁금한 지점이다. 6.0이 어디로 갔는지도 의문이다.

 

이 글에서는 TypeScript 7.0의 핵심 변경점, 버전 점프 사유, 마이그레이션 영향, ESLint/ts-node 같은 생태계 도구 호환성, 지금 도입해도 되는지 판단 기준까지 정리한다. 베타 시점 한국어 정리 글이 거의 없어서 출처를 모아 한 번에 묶었다.

 

TypeScript 7.0은 무엇이며, 왜 6.0을 건너뛰었는가

 

본격 변경점에 들어가기 전에 버전 넘버링부터 짚고 갈 필요가 있다. 5.9 다음이 6.0이 아니라 7.0인 것이 어색하기 때문이다.

 

코드명 "Corsa"부터 7.0까지

 

MS는 2025년 3월에 TypeScript Native Port라는 이름으로 새 컴파일러 프로젝트를 공개했다. 코드명은 "Corsa"였다. 발표 당시에는 별도 저장소(microsoft/typescript-go)에서 개발 중이었고, 1년 정도 베이크 타임을 거친 끝에 2026년 4월 메인 라인 7.0 Beta로 통합됐다.

 

요약하면 1년 사이에 일어난 일이다. 별도 실험 → 동등성 검증 → 정식 7.0 흡수의 흐름이다. 이것이 빠르다고 느낄 수도 있는데, Anders Hejlsberg가 직접 코어를 작성한 프로젝트라 진행이 빨랐던 듯하다.

 

6.0이 빠진 진짜 이유

 

6.0이 그냥 사라진 것이 아니다. 5.x 라인을 별도 유지보수 라인으로 분리하기 위해 비워둔 것이다. 즉 의미는 다음과 같이 정리된다.

 

• 5.x: 기존 JS 기반 컴파일러. 점진적 패치만 받는다
• 6.x: 비워둠 (5.x LTS 라인 보호용 갭)
• 7.x: Go 네이티브 컴파일러로 완전히 전환된 새 라인

 

이런 식으로 메이저 점프를 줘야 "5.x는 안전하게 쓰고 있고, 7.0은 옵트인"이라는 메시지가 명확해진다. 5.9에서 6.0으로 가는 형태였다면 자동 업그레이드 환경에서 사고가 나기 쉬웠을 것이다.

 

Anders Hejlsberg가 직접 작성한 Go 포팅

 

이 부분이 화제였다. Hejlsberg는 Turbo Pascal, Delphi, C#을 만든 사람이고 TypeScript 원조 설계자다. 보통 이런 위치라면 매니지먼트 모드로 돌아가는데, 본인이 직접 Go 포트 핵심 코드를 작성했다. 인터뷰에서는 "타입 체커는 내가 가장 잘 아는 영역이라 직접 하는 것이 빨랐다"고 밝혔다.

 

이 사실의 의미는 크다. 단순 리라이트가 아니라 원작자가 다시 작성한 동등 구현이다. 그래서 Edge case 동작도 1:1로 보존하기 쉬웠던 것이다.

 

컴파일러를 Go로 다시 작성했다, 그렇다면 왜 Go였는가

 

핵심 변경점의 첫 번째다. JS로 작성된 tsc를 Go로 다시 작성한 것이다.

 

Rust가 아니라 Go였던 이유

 

후보로 Rust도 있었다. 다만 최종적으로 Go가 채택됐다. 이유는 인터뷰에서 두 가지로 정리된다.

 

첫째, 코드 구조 호환성이다. 기존 TypeScript 컴파일러는 JS로 작성됐고, 클래스/객체/포인터-같은-참조에 의존하는 자료구조가 많다. Go는 mutable struct + pointer 모델이라 JS의 객체 그래프를 그대로 옮기기 좋다. Rust는 borrow checker 때문에 그래프 구조를 옮기는 데 매번 싸워야 한다. 1:1 포팅이 목표였기 때문에 Go가 압도적으로 유리했다.

 

둘째, 빌드 속도와 GC 모델이다. Go는 컴파일이 빨라서 컴파일러 자체 빌드가 빠르고, GC가 있어서 short-lived 객체를 다루는 컴파일러 워크로드에 잘 맞는다. Rust로 갔다면 Arena allocator 같은 것을 직접 작성해야 했을 것이다.

 

물론 "Rust였다면 더 빨랐을 것"이라는 의견도 있다. 다만 MS 입장에서는 출시 시점이 중요했다. Go로 18개월 만에 출시하는 것이 Rust로 30개월 걸리는 것보다 가치가 컸던 것이다.

 

같은 언어를 두 번 구현한다는 의미

 

이는 사실 흔치 않은 결정이다. 보통 컴파일러 리라이트는 syntax나 semantics를 갈아엎으면서 함께 진행한다. 그러나 TS 7.0은 언어 의미는 하나도 바꾸지 않고 구현체만 교체했다.

 

장점은 명확하다. 마이그레이션 비용이 거의 0이다. tsconfig 그대로, 타입 정의 그대로, 빌드 결과물도 동일하다. 단지 tsc 실행이 빨라졌을 뿐이다.

 

단점도 있다. 두 가지 구현을 동시에 유지해야 한다. 5.x는 JS 컴파일러로 계속 패치되고, 7.x는 Go로 새 기능이 추가된다. 한동안 양쪽 모두 살아 있어야 한다. MS가 이 부담을 지기로 한 것이다.

 

속도 — 정말로 10배 빨라졌다

 

 

출처: https://www.pinterest.com/pin/84442561758052546/

 

본론이다. 모두가 궁금해하는 것은 "그래서 얼마나 빨라졌는가"이다.

 

공식 벤치마크 정리

 

MS가 공개한 수치를 표로 정리하면 다음과 같다. 출처는 Microsoft DevBlog 공식 발표이다.

 

프로젝트	5.x 타입체크	7.0 타입체크	배율
VS Code (1.5M LOC)	77.8초	7.5초	**10.4배**
Playwright	11.1초	1.1초	**10.0배**
TypeORM	17.5초	1.3초	**13.4배**
date-fns	6.5초	0.7초	**9.2배**
RxJS	1.1초	0.1초	**10.6배**

 

평균 10배 정도 빠르다. 작은 프로젝트보다 큰 프로젝트에서 효과가 더 크다. 왜일까? Go 버전이 멀티코어를 본격 활용하기 때문이다. JS 버전은 single-thread 기반이라 코어 많은 머신에서도 1코어만 사용했지만, 7.0은 모듈 단위 병렬 타입체크가 가능하다.

 

메모리 사용량 절반

 

속도만이 아니다. 메모리도 절반 이하로 줄었다. VS Code 빌드 기준 4.2GB → 2.1GB 수준이다. 이것이 가능한 이유는 두 가지다.

 

• GC 효율: Go GC는 짧은 수명 객체에 최적화돼 있다. JS V8은 일반 목적이라 컴파일러처럼 객체가 폭발하는 워크로드에서 비효율적이었다.
• 자료구조 패킹: JS 객체는 hidden class + property 메타데이터 때문에 같은 정보라도 메모리를 더 많이 사용한다. Go struct는 그저 필드만 들어간다.

 

CI 환경에서 메모리가 빡빡하던 사용자에게는 이것이 속도보다 더 반가운 변화일 수 있다.

 

LSP 응답성: 에디터 멈춤이 사라졌다

 

진짜 체감 차이가 큰 영역은 tsserver(LSP) 부분이다. 큰 프로젝트에서 VS Code가 멈추는 경험은 누구나 해봤을 것이다. 자동완성을 1초 기다리고, 타입 인포가 뜨는 데 2초가 걸리고, 'Find References'를 누르면 화면이 굳는다.

 

7.0에서는 이것이 거의 사라졌다. 같은 프로젝트에서 자동완성이 50ms 안쪽으로 표시된다. Hejlsberg가 데모에서 보여준 영상을 보면 정말 즉각적이다. 이는 단순히 컴파일러가 빨라진 것이 아니라, 에디터 작업 흐름이 바뀌는 수준의 변화다.

 

Next.js / NestJS / 모노레포 영향 추정

 

한국에서 많이 사용하는 프레임워크 기준으로 추정해 보면 다음과 같다.

 

• Next.js 프로젝트: next build 시 TS 체크가 보통 30~60초 잡아먹는데, 3~6초 수준으로 떨어질 가능성이 높다
• NestJS 백엔드: 데코레이터/메타데이터가 많아서 5.x에서 느렸다. 7.0에서 가장 큰 수혜를 볼 영역 중 하나다
• Turborepo/Nx 모노레포: 패키지마다 tsc를 돌리는 구조라 누적 시간이 길었다. 7.0에서는 누적 빌드 시간이 1/10 수준으로 가능하다

 

CI 비용 절감 효과도 무시할 수 없다. GitHub Actions에서 빌드가 5분 → 1분 수준으로 줄면 월 사용량 자체가 달라진다.

 

tsgo 바이너리, 배포 방식이 바뀌었다

 

속도 다음으로 큰 변화는 배포 방식이다.

 

npm install로 받는 것이 바이너리가 된다

 

기존에는 npm install -D typescript를 실행하면 JS 파일 한 뭉치가 설치됐다. 7.0부터는 다르다. 플랫폼별 prebuilt 바이너리가 함께 설치된다.

 

node_modules/
  typescript/
    bin/
      tsgo            <- Go로 컴파일된 네이티브 바이너리
      tsc             <- 호환성 래퍼 (tsgo 호출)

 

tsc 명령은 그대로 동작한다. 내부적으로 tsgo를 호출하는 방식이다. 호환성이 깨질 일은 거의 없다.

 

플랫폼별 prebuilt: Windows / macOS / Linux

 

지원 플랫폼은 베타 시점에 다음과 같다.

 

• Windows x64, ARM64
• macOS x64, ARM64 (Apple Silicon)
• Linux x64, ARM64
• Linux musl(Alpine) — Docker 이미지용

 

설치 시 npm이 자동으로 플랫폼을 감지해서 맞는 바이너리만 받는다. 멀티플랫폼 모노레포에서도 신경 쓸 것이 없다.

 

Node 의존성 제거 (tsx, ts-node 같은 도구 영향)

 

이 부분은 미묘한 지점이다. tsc 자체는 더 이상 Node가 필요 없다. 다만 ts-node, tsx 같은 런타임 트랜스파일러는 여전히 Node 위에서 동작한다.

 

7.0에서는 이런 도구들도 영향을 받는다. tsx는 esbuild 기반이라 큰 영향이 없지만, ts-node는 내부적으로 TS 컴파일러 API를 호출한다. 공식 API는 호환성이 유지되지만, 내부 구조에 의존하던 패치 도구(예: ttypescript)는 깨질 수 있다.

 

베타 시점에 ts-node는 7.0과 동작하지만, 일부 커스텀 트랜스포머 사용자는 마이그레이션이 필요하다.

 

5.x에서 7.0으로 갈아타도 되는가? 마이그레이션 가이드

 

 

출처: https://unsplash.com/photos/a-blue-and-white-logo-on-a-white-background-4igDDHdrnhE

 

가장 실무적인 질문이다. 결론부터 말하면 베타이므로 신중히, 사이드 프로젝트는 OK, 회사 코드는 RC 이후 권장이다.

 

호환성: tsconfig는 그대로 작동한다

 

기본 시나리오에서는 정말로 아무 작업 없이 동작한다. tsconfig.json 그대로, package.json에서 "typescript": "^7.0.0-beta"로 변경하기만 하면 된다. 빌드 결과물(JS 출력)도 byte 단위로 동일하다 — MS가 회귀 테스트를 그렇게 설계했다.

 

깨질 수 있는 것들

 

다만 "보통" 시나리오를 벗어나면 이슈가 있다.

 

• 커스텀 트랜스포머: ttypescript / ts-patch 같은 도구로 컴파일러를 패치하던 사용자 — 베타에서는 동작하지 않는다. 7.0이 트랜스포머 API를 새로 정의 중이다
• TypeScript 컴파일러 API 직접 사용: ESLint 플러그인 일부, 빌드 도구 일부. 메이저 도구는 곧 패치되겠지만 마이너한 것은 시간이 걸린다
• 타입 체크 비표준 동작에 의존하던 코드: 예를 들어 5.x에서 우연히 통과하던 inferring edge case가 7.0에서 더 엄격해질 수 있다. 실제로 GitHub 이슈에 이런 리포트가 몇 건 올라와 있다

 

typescript-eslint, ts-node, tsx 호환성

 

생태계 핵심 도구별 상태를 정리하면 다음과 같다 (베타 시점).

 

도구	7.0 호환 상태	메모
typescript-eslint	부분 호환	7.x 대응 PR 진행 중. 메이저 룰은 동작
ts-node	동작함	일부 옵션은 deprecated 예고
tsx	동작함	esbuild 기반이라 영향 적음
ttypescript	미동작	트랜스포머 API 미정
Webpack ts-loader	동작함	공식 API만 사용
Vite	동작함	별도 영향 없음
Jest ts-jest	부분 호환	일부 설정에서 이슈 리포트 있음

 

ESLint 사용자는 typescript-eslint 정식 7.0 대응 릴리스가 나오기 전까지는 회사 프로젝트 도입을 자제하는 것이 안전하다.

 

5.x 라인 EOL 일정 (확정 안 됨)

 

이 부분은 공식적으로 명확히 정해지지 않았다. 현재 알려진 정보를 기준으로 한 추정은 다음과 같다.

 

• 5.x: 7.0 정식 출시 후 최소 12개월 보안 패치 유지 (예상)
• 5.9: 마지막 5.x 메이저로 굳어질 가능성이 있음
• 6.0: 영구 결번

 

확정 일정은 7.0 정식 GA 발표(2026년 하반기 예상) 시점에 함께 나올 듯하다. 그때까지는 5.x를 안심하고 사용해도 된다.

 

그렇다면 지금 도입해야 하는가? 의사결정 체크리스트

 

베타이므로 답이 명확하지는 않다. 시나리오별로 정리한다.

 

사이드 프로젝트 — 바로 OK

 

개인 토이 프로젝트, 학습용, 데모는 그냥 7.0 베타를 설치해도 된다. 깨져도 손해가 없고, 속도 차이를 체감해 보는 것이 가치 있다. 설치는 간단하다.

 

npm install -D typescript@beta

 

회사 모노레포 — RC 이후 권장

 

프로덕션 코드, 특히 모노레포는 RC(Release Candidate)가 나올 때까지는 기다리는 것이 안전하다. 이유는 두 가지다.

 

• typescript-eslint 같은 핵심 도구가 아직 100% 호환되지 않는다
• 회사 빌드 파이프라인이 일부 내부 API에 의존하고 있을 가능성이 있다

 

대신 실험용 브랜치에서 7.0 빌드를 돌려보고 CI 시간 차이를 측정해 두는 작업은 지금부터 해도 된다. 정식 출시 시점에 즉시 마이그레이션 결정을 하려면 데이터가 있어야 한다.

 

CI 빌드 시간이 진짜 병목이라면

 

현재 CI에서 TS 체크가 가장 큰 시간을 차지하고 있고, 그것이 비즈니스에 직접 영향(배포 속도, 개발자 대기 시간)을 주는 상황이라면 부분 도입을 시도해 볼 가치가 있다. 예를 들어 다음과 같다.

 

• PR 검증용 사이드 잡으로만 7.0을 돌려서 빠른 피드백 받기
• 메인 빌드는 5.x 유지, 캐시 미스 시 7.0으로 fallback 빌드

 

이런 하이브리드도 가능하다.

 

도입 전 확인할 것 5가지

 

• [ ] typescript-eslint: 사용 중인 룰셋이 7.0에서 동작하는지
• [ ] 커스텀 트랜스포머: ttypescript/ts-patch 의존 여부
• [ ] 빌드 도구: Webpack/Vite/Turborepo가 7.0을 공식 지원하는지
• [ ] 타입 정의: @types/* 패키지 중 7.0에서 깨지는 것이 없는지 (대부분 OK)
• [ ] CI 환경: prebuilt 바이너리 플랫폼이 사용 중인 CI(Linux x64/musl)와 일치하는지

 

이 다섯 가지를 모두 통과하면 도입 리스크가 낮다.

 

TypeScript 7.0이 결국 개발자에게 의미하는 것

 

핵심을 5줄로 압축하면 다음과 같다.

 

• TypeScript 7.0은 컴파일러를 Go로 다시 작성한 메이저 릴리스다. 언어 의미는 그대로다
• 속도 10배, 메모리 절반. VS Code 빌드 기준 77.8초 → 7.5초다
• 6.0은 결번이다. 5.x LTS 라인을 보호하려고 메이저 점프를 시킨 것이다
• 베타 시점이므로 사이드 프로젝트는 OK, 회사 코드는 RC 이후 권장이다
• typescript-eslint, ttypescript, ts-node 같은 생태계 도구 호환성을 별도로 체크해야 한다

 

느린 tsc 때문에 빌드를 기다리고, VS Code가 멈추고, CI 비용이 새는 시대가 드디어 끝나가는 듯하다. 정말 오래 걸렸다. 5.x 시리즈 내내 "왜 이렇게 느린가?"라는 소리를 들었던 것이 결국 이 답이었던 셈이다.

 

각설하고, 지금 당장은 베타를 설치해서 자기 프로젝트에서 직접 벤치를 돌려보는 것이 가장 의미 있는 액션이다. 1년치 CI 시간을 미리 계산해 보면 정식 출시 때 빨리 갈아탈 동기가 충분히 생긴다. 회사에 도입을 제안할 데이터로도 사용할 수 있다.

 

다만 이 글은 4월 베타 시점 정리이므로 RC/GA 시점에 일부 내용이 바뀔 수 있다. 정식 EOL 일정이나 trans-former API 같은 미확정 부분은 발표가 나오면 업데이트할 예정이다.