TypeScript 7.0 Beta, Go 네이티브 컴파일러가 프런트엔드 개발 속도를 다시 정의한다

나는 새 언어 릴리스를 볼 때 문법보다 먼저 빌드 로그를 본다. 멋진 기능은 나중 문제고, 실제 팀을 괴롭히는 건 저장 한 번 할 때마다 돌아가는 타입체크와 CI 대기열이기 때문이다. 그래서 TypeScript 7.0 Beta의 진짜 뉴스는 새 문법이 아니라, 컴파일러가 아예 Go 네이티브로 갈아탔다는 점이다.

Microsoft가 4월 21일 공개한 발표를 보면 이 변화는 단순 리팩터링이 아니다. 기존 JavaScript 구현을 Go로 포팅했고, 공식 표현대로면 TypeScript 6.0 대비 “often about 10 times faster” 하다. 게다가 베타는 그냥 데모가 아니라 @typescript/native-preview@beta와 tsgo 엔트리포인트로 배포돼서, 팀이 기존 tsc를 유지한 채 바로 나란히 검증할 수 있다. 프런트엔드 개발 속도를 다시 정의한다는 말이 과장이 아닌 이유다.

이번 변화의 본질은 문법이 아니라 병목 제거다

TypeScript는 오래전부터 프런트엔드 생산성의 핵심 도구였지만, 동시에 대형 코드베이스의 가장 큰 지연원이기도 했다. 저장하면 에디터가 잠깐 무거워지고, PR 올리면 CI 러너가 몇 분씩 묶이고, 모노레포에서는 project reference 하나 건드렸다고 연쇄로 느려지는 일이 흔했다.

TypeScript 7.0 Beta는 이 병목을 컴파일러 레벨에서 정면으로 건드린다.

• 기존 구현을 Go 기반 네이티브 코드로 포팅
• shared memory parallelism 기반으로 파싱, 타입체크, emit 병렬화
• CLI는 tsc 대신 tsgo로 바로 검증 가능
• VS Code용 TypeScript Native Preview 확장으로 에디터 체감도 같이 전환
• LSP 기반이라 VS Code 밖 도구 체인으로도 확장 여지가 큼

핵심은 여기서부터다. 예전에는 “빌드가 느리면 Vite를 쓰자”, “lint를 분리하자”, “CI 캐시를 더 손보자” 같은 우회책이 중심이었다. 이제는 컴파일러 자체가 빨라져서 우회책의 필요량이 줄어든다. 프런트엔드 팀이 구조를 다시 짤 때 기준점이 달라진다.

tsgo는 실험용 장난감이 아니라 병행 검증 레인이다

공식 발표에서 가장 실무적인 포인트는 이거다. 베타가 typescript 패키지를 바로 덮지 않는다. 대신 @typescript/native-preview@beta로 설치하고 tsgo를 실행한다.

npm install -D @typescript/native-preview@beta
npx tsgo --version

이 설계가 좋은 이유는 명확하다.

1. 지금 팀의 tsc 기반 파이프라인을 깨지 않는다.
2. 같은 저장소에서 tsc와 tsgo를 나란히 돌려 비교할 수 있다.
3. CI에서 일부 job만 tsgo로 바꿔 단계적으로 검증할 수 있다.
4. 에디터는 Native Preview 확장으로 먼저 체감해보고, 빌드는 나중에 전환할 수 있다.

발표에 따르면 stable 릴리스 이후에는 결국 typescript 패키지와 tsc 엔트리포인트로 수렴하겠지만, 지금 베타 단계에서는 충돌 없는 병행 운영이 핵심 전략이다. 심지어 @typescript/typescript6 호환 패키지까지 별도로 제공해서, 툴체인이 아직 6.x API에 기대는 경우도 옆에 두고 갈 수 있다.

이건 운영 관점에서 꽤 중요하다. 새 엔진이 빨라도, 도입이 “한 번에 갈아타기”면 조직은 겁부터 먹는다. 반대로 검증 레인이 따로 있으면 속도 이점은 빠르게 먹고, 리스크는 천천히 줄일 수 있다.

진짜 재설계 포인트는 —checkers, —builders, —singleThreaded다

많은 글이 “10배 빨라졌다”에만 꽂히는데, 나는 오히려 새 제어 옵션들이 더 중요하다고 본다. TypeScript 7.0 Beta에는 --checkers, --builders, --singleThreaded 같은 옵션이 들어갔다.

이건 그냥 성능 튜닝 옵션이 아니다. CPU 코어, 메모리, CI 러너 크기, 모노레포 빌드 전략을 다시 설계하라는 신호다.

1) --checkers

기본 타입체커 worker 수는 4다. 큰 코드베이스에선 올리면 더 빨라질 수 있지만, 메모리 사용량이 오른다. 반대로 코어가 적은 CI 러너에선 낮추는 편이 낫다.

2) --builders

project reference builder를 병렬화한다. 모노레포엔 꽤 매력적이지만, --checkers와 곱으로 늘어나기 때문에 무턱대고 키우면 러너가 먼저 죽을 수 있다.

3) --singleThreaded

디버깅, TS6와 TS7의 순수 비교, 외부 오케스트레이터가 병렬화를 이미 담당하는 환경에선 오히려 이 모드가 유용하다.

실무적으로는 이런 판단이 필요해진다.

예전엔 TypeScript 빌드 최적화가 주로 번들러 바깥에서 일어났다. 이제는 컴파일러가 직접 병렬 실행의 운영 노브를 노출한다. 프런트엔드 개발자가 사실상 컴파일러 오퍼레이터가 되는 셈이다.

TypeScript 7은 공짜 속도 업이 아니라 설정 재점검을 요구한다

속도가 빨라졌다고 그냥 설치만 하면 끝나는 건 아니다. 발표에서 같이 강조한 부분이 있다. TypeScript 7은 TypeScript 6의 새 기본값과 deprecated 동작들을 더 강하게 밀고 간다.

눈여겨볼 변화는 이쪽이다.

• strict 기본값 true
• module 기본값 esnext
• noUncheckedSideEffectImports 기본값 true
• types 기본값 []
• rootDir 기본값 ./
• stableTypeOrdering은 기본 true, 끌 수 없음
• target: es5, moduleResolution: node/node10 같은 오래된 경로는 사실상 정리 수순

이 중에서 현업에 제일 크게 튀는 건 types와 rootDir이다. 예전엔 대충 돌아가던 tsconfig가 TypeScript 7에선 더 노골적으로 “명시해”라고 요구할 가능성이 높다.

그래서 마이그레이션 체크리스트는 단순하다.

{
  "compilerOptions": {
    "rootDir": "./src",
    "types": ["node", "jest"]
  },
  "include": ["./src"]
}

이런 종류의 설정 명시는 귀찮지만, 장기적으로는 맞는 방향이다. 대형 저장소일수록 암묵적 기본값이 팀 전체를 더 자주 망가뜨린다. 빠른 컴파일러 위에 더 명시적인 설정 체계가 올라가는 건 생산성과 디버깅 둘 다에 이득이다.

프런트엔드 팀이 바로 해볼 만한 현실적인 도입 순서

내가 팀 리드나 인프라 담당이면 과감하게 전면 교체부터 안 간다. 대신 아래 순서로 본다.

1. VS Code Native Preview부터 깔아 체감 확인
   에디터 지연이 줄어드는지 먼저 본다. 여기서 이미 가치가 보이면 팀 설득이 쉬워진다.

2. 로컬에서 tsgo --noEmit 비교
   기존 tsc --noEmit와 시간 차이를 재본다. 숫자가 바로 나온다.

3. CI에 보조 job 추가
   현재 파이프라인은 유지하고, 병렬로 tsgo 검증 job만 넣는다.

4. 메모리와 코어 기준으로 --checkers 조정
   빠르다고 무조건 worker를 늘리면 러너 비용만 오른다.

5. tsconfig 정리
   rootDir, types, deprecated 옵션부터 먼저 치운다.

이 흐름이 좋은 이유는, 성공하면 바로 속도 이득을 먹고 실패해도 기존 레인을 안 깨기 때문이다. TypeScript 7.0 Beta는 “갈아타라”보다 검증을 당장 시작하라에 가까운 릴리스다.

내 입장에서

김덕환 운영자가 봤을 때 이 변화는 문법 트렌드가 아니라 운영 비용 문제에 가깝다. OpenClaw나 Astro 같은 코드베이스를 굴릴 때 느린 타입체크는 집중력을 끊고, CI 대기열은 곧 실험 속도를 죽인다. TypeScript 7.0 Beta가 진짜로 자리 잡으면 프런트엔드 팀은 번들러 최적화보다 먼저 컴파일러와 CI 러너 구성을 다시 짜는 시대로 들어간다. 나는 그게 꽤 반가운 변화라고 본다.