TypeScript 7.0, Go 기반 컴파일러로 빌드 대기 시간을 줄여요

TypeScript 7.0, Go 기반 컴파일러로 빌드 대기 시간을 줄여요

AI 뉴스 썸네일

TypeScript 7.0은 TypeScript 도구 체인을 Go 기반 네이티브 코드로 옮긴 릴리스예요. Microsoft는 대형 코드베이스의 전체 빌드에서 보통 8~12배 빠른 결과를 봤고, VS Code 같은 프로젝트에서는 첫 오류 표시 시간도 크게 줄었다고 밝혔어요. 2

핵심 요약

구분	핵심	왜 볼만한가요
컴파일러	TypeScript 7.0은 Go 기반 네이티브 포트예요	대형 프로젝트의 타입 검사와 빌드 대기 시간이 크게 줄 수 있어요
편집기	새 언어 서버는 LSP 기반으로 동작해요	VS Code, Visual Studio, WebStorm 같은 도구의 피드백 속도에 영향을 줘요
전환 포인트	안정적인 컴파일러 API는 아직 없어요	eslint, Vue, MDX, Astro, Svelte 같은 도구는 TypeScript 6 병행이 필요할 수 있어요
설정 변화	TypeScript 6.0의 새 기본값과 제거된 옵션을 따라가요	`rootDir`, `types`, `moduleResolution` 같은 설정을 미리 점검해야 해요

1. TypeScript 7.0은 속도 개선이 핵심이에요

TypeScript 7.0의 가장 큰 변화는 컴파일러와 언어 서버 구현이 Go 기반 네이티브 코드로 바뀐 점이에요. 기존 TypeScript 코드베이스의 구조와 동작을 최대한 유지하면서, 실행 성능과 병렬 처리 여지를 크게 늘린 방식이에요. Microsoft가 공개한 비교표에 따르면 `vscode`는 전체 빌드 시간이 125.7초에서 10.6초로 줄었고, `sentry`, `bluesky`, `playwright`, `tldraw`도 7.7~11.9배 개선을 보였어요. 2

이 변화는 단순히 CI 시간이 줄어드는 문제로만 끝나지 않아요. TypeScript는 에디터에서 자동완성, 오류 표시, 참조 찾기, watch 모드까지 계속 관여해요. 큰 저장소를 다루는 팀이라면 빌드 한 번보다 “수정하고 바로 확인하는 시간”이 더 자주 체감돼요. TypeScript 7.0은 이 짧은 반복 시간을 줄이는 쪽에 무게가 실려 있어요.

728x90

Microsoft가 든 예시도 편집기 경험에 가까워요. VS Code 코드베이스에서 오류가 있는 파일을 열었을 때 첫 오류가 보이는 시간이 약 17.5초에서 1.3초 미만으로 줄었다고 해요. 언어 서버가 빨라지면 개발자는 코드를 바꾼 뒤 기다리는 시간이 줄고, 잘못된 타입 변경을 더 빨리 확인할 수 있어요.

Go로 옮겼지만 사용 방식은 크게 달라지지 않아요

설치는 기존처럼 npm의 `typescript` 패키지를 통해 이뤄져요. 개발자는 `npx tsc` 같은 익숙한 실행 방식을 그대로 쓸 수 있어요. VS Code 사용자는 TypeScript 7 전용 확장을 먼저 써 볼 수 있고, Visual Studio와 WebStorm 같은 편집기도 LSP 기반 언어 서버 흐름을 따라갈 수 있어요. 2

다만 “TypeScript로 만든 앱이 더 빨라진다”는 뜻은 아니에요. 여기서 빨라지는 건 TypeScript 코드를 검사하고 JavaScript로 넘기는 도구예요. 런타임 성능이 아니라 개발 도구와 빌드 파이프라인 성능에 가까운 변화예요.

병렬 처리 옵션은 팀 환경에 맞춰 봐야 해요

TypeScript 7.0은 파싱, 타입 검사, emit 같은 작업을 병렬로 처리해요. `--checkers`, `--builders`, `--singleThreaded` 같은 옵션도 새로 들어왔어요. 예를 들어 `--checkers 8`을 쓰면 더 많은 CPU 코어를 활용할 수 있지만, 메모리 사용량은 늘 수 있어요. 작은 CI runner나 메모리가 빠듯한 개발 환경에서는 기본값이 항상 정답이 아닐 수 있어요.

모노레포를 운영하는 팀은 `--builders`도 봐야 해요. 프로젝트 참조가 많은 저장소에서는 동시에 빌드할 수 있는 프로젝트 수가 전체 시간을 좌우할 수 있어요. 반대로 의존성 그래프가 복잡하면 병렬 수를 높여도 기대만큼 빨라지지 않을 수 있어요.

마이그레이션에서 가장 큰 제약은 API예요

TypeScript 7.0은 아직 안정적인 프로그래밍 API를 제공하지 않아요. 이 점이 생태계 전환에서 가장 큰 제약이에요. `typescript-eslint`, Vue, MDX, Astro, Svelte, Angular 템플릿 타입 검사처럼 TypeScript 컴파일러 API를 직접 쓰는 도구는 당분간 TypeScript 6.0과 함께 가야 할 수 있어요. Microsoft는 TypeScript 7.1에서 새 API를 제공할 계획이라고 밝혔어요. 2

그래서 이번 릴리스를 바로 전면 적용하기보다, 빌드와 에디터 지원을 나눠서 보는 편이 안전해요. 앱 코드의 전체 타입 검사는 TypeScript 7.0으로 빠르게 돌리고, 특정 프레임워크나 플러그인이 필요한 워크플로는 TypeScript 6.0을 유지하는 식이에요. Microsoft도 `@typescript/typescript6`나 npm alias를 통한 병행 설치 방법을 안내하고 있어요.

설정 기본값도 같이 점검해야 해요

TypeScript 7.0은 TypeScript 6.0의 새 기본값을 따라가요. `strict` 기본값은 켜지고, `module`은 `esnext`, `types` 기본값은 빈 배열로 바뀌어요. `target: es5`, `moduleResolution: node/node10`, `baseUrl`, `downlevelIteration` 같은 오래된 설정은 더 이상 맞지 않을 수 있어요. 2

특히 오래된 웹앱이나 Node 타입을 암묵적으로 끌어다 쓰던 프로젝트는 `types` 변화에서 막힐 수 있어요. `src` 밖에 `tsconfig.json`이 있는 프로젝트는 `rootDir`을 명시해야 기존 출력 구조를 유지할 가능성이 커요. 속도 개선만 보고 올리기보다 TypeScript 6.0 변경 사항을 먼저 적용해 두는 쪽이 전환 비용을 낮춰요.

왜 중요한가요

TypeScript 7.0은 JavaScript 생태계에서 “타입 검사 비용”을 다시 계산하게 만드는 릴리스예요. 프런트엔드와 백엔드를 TypeScript로 함께 운영하는 팀은 코드가 커질수록 타입 검사와 에디터 반응 속도에 시간을 잃어요. 이 시간이 8~12배 줄면 PR 검증, merge queue, 로컬 피드백 루프가 모두 달라질 수 있어요. 2

개발자 도구를 만드는 팀에도 의미가 커요. 언어 서버가 빨라지면 에디터, 코드 리뷰 도구, 자동 리팩터링 도구가 더 짧은 시간 안에 타입 정보를 쓸 수 있어요. TypeScript 7.0의 change notes를 보면 JavaScript 지원과 오래된 옵션도 함께 바뀌어서, 도구 제작자는 성능뿐 아니라 호환성까지 같이 봐야 해요. 3

다만 지금은 “모두 바로 올리면 끝”인 릴리스가 아니에요. 컴파일러 API가 아직 안정화되지 않았고, 일부 프레임워크 워크플로는 TypeScript 6.0에 남아 있어야 해요. 실제 도입은 `tsc` 단독 빌드, 에디터 언어 서버, 프레임워크 플러그인, CI runner 자원까지 나눠서 시험해 보는 방식이 좋아요.

참고 자료

1. TypeScript 7.0 발표 — GeekNews
2. Announcing TypeScript 7.0 — Microsoft TypeScript Blog
3. TypeScript 7.0 change notes — Microsoft GitHub