TypeScript 7.0 발표에서 제일 눈에 띄는 숫자는 8~12배야. vscode 빌드는 125.7초에서 10.6초로 줄고, sentry는 139.8초에서 15.7초로 줄었다고 Microsoft가 말해.1
그런데 이 발표의 핵심은 “컴파일러가 빨라졌다”보다 조금 더 일상적인 곳에 있어.
개발자가 기다리던 시간이 줄어든 거야. 편집기를 열고, 에러가 뜨기를 기다리고, 자동완성을 기다리고, --watch가 다시 돌기를 기다리고, CI의 타입 체크를 기다리던 시간.
TypeScript 7.0은 타입 체크를 배치 작업에서 대화형 피드백으로 더 가까이 끌고 온 발표야.
무슨 일이 있었나
Microsoft의 TypeScript 팀은 TypeScript 7.0을 Go 기반 네이티브 포트로 내놨어. 기존 JavaScript/TypeScript 구현을 버리고 완전히 새 언어처럼 다시 설계했다기보다, 기존 코드베이스의 구조와 논리를 최대한 보존하면서 Go로 옮긴 쪽에 가까워. 목표는 결과의 호환성을 유지하면서 네이티브 코드 속도, 공유 메모리 기반 멀티스레딩, 병렬 처리를 얻는 것이었어.1
설치 방식은 평범해. npm install -D typescript로 새 tsc를 받는다. 큰 변화는 안쪽에 있어. 파싱, 타입 체크, emit 같은 단계가 병렬화되고, 편집기 쪽은 Language Server Protocol 기반의 새 언어 서버를 쓴다. --watch도 다시 만들어졌어. 파일 변화를 계속 훑는 비싼 polling 대신, Parcel 쪽 파일 watcher를 Go로 옮겨 더 안정적인 감시 기반을 세웠다고 설명해.1
flowchart LR edit["코드 수정"] --> lsp["편집기 진단·자동완성"] lsp --> local["로컬 tsc·watch"] local --> ci["CI 타입 체크"] ci --> merge["merge queue"] lsp -. "빨라진 피드백" .-> edit local -. "빨라진 피드백" .-> edit
이 그림에서 중요한 건 끝의 CI만이 아니야. TypeScript는 개발 도중 계속 끼어든다. 파일을 열 때, 참조 찾기를 할 때, 자동완성이 뜰 때, 빨간 줄이 생길 때, 저장 후 --watch가 다시 돌 때마다 개발자의 호흡을 잡아. TypeScript 7.0은 그 호흡 전체를 줄이는 발표야.
숫자가 말하는 것
Microsoft가 제시한 공개 프로젝트 기준으로는 기본 설정에서도 vscode 11.9배, sentry 8.9배, bluesky 8.7배, playwright 8.7배, tldraw 7.7배 빨라졌어. 메모리도 같은 표에서 대체로 줄었고, VS Code 코드베이스에서 에러가 있는 파일을 열어 첫 에러를 보기까지 걸리던 시간은 약 17.5초에서 1.3초 미만으로 줄었다고 해.1
회사의 실제 피드백도 같은 방향이야. Slack은 TypeScript 7.0이 merge queue 시간을 40% 줄였고, CI 타입 체크 시간이 약 7.5분에서 1.25분으로 내려갔다고 말했다. Microsoft News Services 팀은 CI 빌드를 기다리는 시간이 한 달에 400시간 줄었다고 했고, Canva는 편집기에서 첫 에러를 보기까지 걸리던 시간이 약 58초에서 4.8초로 줄었다고 전했어.1
이 숫자를 그대로 독립 벤치마크로 받아들이면 안 돼. 발표 주체가 직접 고른 사례니까. 그래도 방향은 분명해. 대형 TypeScript 코드베이스에서 “로컬에서는 느려서 CI에 맡긴다”는 습관이 줄어들 수 있어. 그게 바뀌면 개발자는 더 자주, 더 작은 단위로 확인하게 된다.
이건 AI 코딩 도구에도 중요해. agentic workflow에서 에이전트가 코드를 고치고 테스트·타입 체크 결과를 읽어 다음 행동을 고르는 루프가 길어질수록, 컴파일러 피드백의 속도는 모델 성능만큼이나 작업 시간을 좌우해. 타입 체크가 8분이면 에이전트도 8분을 기다린다. 타입 체크가 1분이면 같은 시간 안에 더 많이 고치고 확인할 수 있어.
스핀과 확인된 것
발표문의 스핀은 “native era”, 즉 TypeScript 도구 체인이 네이티브 시대에 들어갔다는 말이야. 그 표현은 과장이 섞일 수 있지만, 확인된 변화는 꽤 구체적이야. Go 기반 새 코드베이스, 멀티스레드 타입 체크, --checkers와 --builders로 조절하는 병렬화, --singleThreaded 디버그 모드, 새 LSP 서버, 새 --watch 기반이 함께 들어왔어.1
특히 병렬화는 그냥 코어를 많이 쓰면 끝나는 문제가 아니야. TypeScript 팀은 타입 체크가 파일 간 의존성과 순서에 민감하기 때문에, 고정된 수의 타입 체커 worker가 항상 같은 방식으로 파일을 나눠 보게 했다고 설명해. --checkers 8을 쓰면 일부 프로젝트는 더 빨라지지만, 메모리 사용량이 늘 수 있고 환경마다 결과가 달라질 수 있어. 그래서 팀마다 CI runner, 개발자 노트북, monorepo 구조에 맞춰 값을 고정해야 할 가능성이 커.
여기서 TypeScript 7.0은 단순 업그레이드라기보다 새 운영 변수를 들고 온 셈이야. “빨라졌다”에서 끝나지 않고, 어느 환경에 몇 개의 checker와 builder를 둘지 정해야 한다.
아직 못 넘긴 선
7.0은 모든 생태계가 바로 넘어갈 수 있는 릴리스는 아니야. 가장 큰 이유는 API야. Microsoft는 TypeScript 7.0이 아직 API를 싣지 않고, 7.1에서 새롭고 다른 API를 낼 예정이라고 설명해. 그래서 typescript-eslint처럼 컴파일러 API에 기대는 도구는 당분간 TypeScript 6.0과 나란히 돌아가야 해.1
Vue, MDX, Astro, Svelte 같은 embedded language 워크플로우도 비슷해. Angular 템플릿 타입 체크처럼 TypeScript를 자기 컴파일러나 언어 서비스 안에 끼워 쓰는 도구는 아직 7.0을 온전히 쓰기 어렵다. Microsoft도 이런 프로젝트는 당분간 TypeScript 6.0을 계속 써야 한다고 말해.1
호환성 쪽에도 손볼 게 있어. TypeScript 7.0은 6.0의 새 기본값을 받아들이고, 6.0에서 deprecated였던 일부 설정과 문법을 hard error로 바꾼다. strict는 기본값이 true가 되고, module은 esnext, types는 빈 배열, rootDir은 ./로 바뀐다. target: es5, moduleResolution: node/node10, baseUrl 같은 낡은 설정도 더 이상 그대로 두기 어렵다.1
즉 “npm으로 올리면 끝”인 팀도 있겠지만, 오래된 설정과 플러그인이 많은 팀은 먼저 TypeScript 6.0 정리부터 해야 해.
다음에 볼 것
첫째, 7.1의 API가 얼마나 빨리 생태계를 끌어오느냐를 봐야 해. typescript-eslint, Vue, Svelte, Astro, Angular 같은 도구가 7.x 네이티브 경로를 쓰기 시작해야 이 변화가 JavaScript 생태계 전체로 퍼져.
둘째, 대형 코드베이스가 --checkers와 --builders를 어떻게 고정하는지 봐야 해. 속도와 메모리의 균형을 어디에 두느냐가 monorepo 운영의 새 표준이 될 수 있어.
셋째, AI 코딩 도구의 피드백 루프가 실제로 짧아지는지 봐야 해. 모델이 더 똑똑해지는 것과 별개로, 타입 체크가 빨라지면 에이전트가 시도하고 되돌리는 비용이 낮아진다. TypeScript 7.0의 진짜 무게는 여기서 드러날 가능성이 커.
댓글