---
title: "타입스크립트 7 공개, 고 포팅으로 빌드가 최대 10배 이상 빨라짐"
published: 2026-07-08T16:06:35.000Z
canonical: https://jeff.news/article/4811
---
# 타입스크립트 7 공개, 고 포팅으로 빌드가 최대 10배 이상 빨라짐

마이크로소프트가 고(Go)로 네이티브 포팅한 타입스크립트 7을 공개했다. 전체 빌드는 보통 8~12배 빨라지고, VS 코드 코드베이스에서는 125.7초가 10.6초로 줄었으며, 편집기 첫 오류 표시도 17.5초에서 1.3초 미만으로 내려갔다.

## 타입스크립트가 드디어 네이티브 속도로 움직임

- 마이크로소프트가 타입스크립트 7을 공개함. 가장 큰 변화는 고(Go)로 만든 네이티브 포트임
  - 목표는 타입스크립트 도구 전체를 한 자릿수 배가 아니라 “한 자릿수 자릿수(order of magnitude)” 수준으로 빠르게 만드는 것임
  - 기존 타입스크립트 코드베이스의 구조와 로직을 최대한 유지해서, 두 컴파일러의 결과와 호환성을 맞추려 했다고 설명함
  - 네이티브 코드 속도, 공유 메모리 멀티스레딩, 새 최적화 덕분에 전체 빌드에서 보통 8~12배 빨라진다고 함

- 설치는 기존처럼 npm에서 `typescript`를 받으면 됨
  - `npm install -D typescript`로 설치하면 새 `tsc` 실행 파일이 들어옴
  - `npx tsc`로 실행할 수 있음
  - VS 코드, 비주얼 스튜디오, 웹스톰 같은 에디터는 새 언어 서버 프로토콜(LSP) 기반 지원을 통해 타입스크립트 7을 쓸 수 있음

- 개발자가 체감하는 변화는 빌드 시간만이 아님
  - 에디터에서 프로젝트가 열리는 시간
  - 전체 참조 찾기(find-all-references)
  - 자동완성
  - 실시간 진단과 빨간 밑줄
  - `tsc --watch` 피드백 루프까지 전부 빨라지는 방향임

> [!IMPORTANT]
> VS 코드 코드베이스에서 “에디터를 열고 첫 오류가 보이기까지” 시간이 기존 약 17.5초에서 타입스크립트 7 기준 1.3초 미만으로 줄었다고 함. 이건 단순 빌드 벤치마크보다 개발자 체감이 훨씬 큰 숫자임.

## 실제 프로젝트 벤치마크 숫자가 꽤 세다

- 공개된 전체 빌드 시간 비교는 이렇다
  - vscode: 타입스크립트 6은 125.7초, 타입스크립트 7은 10.6초로 11.9배 빠름
  - sentry: 139.8초에서 15.7초로 8.9배 빠름
  - bluesky: 24.3초에서 2.8초로 8.7배 빠름
  - playwright: 12.8초에서 1.47초로 8.7배 빠름
  - tldraw: 11.2초에서 1.46초로 7.7배 빠름

- 메모리 사용량도 대체로 줄었음
  - vscode는 5.2GB에서 4.2GB로 18% 감소
  - sentry는 4.9GB에서 4.6GB로 6% 감소
  - bluesky는 1.8GB에서 1.3GB로 26% 감소
  - playwright는 1.0GB에서 0.9GB로 11% 감소
  - tldraw는 0.6GB에서 0.5GB로 15% 감소

- 타입 체커 워커 수를 4개에서 8개로 올리면 더 빨라지는 케이스도 있음
  - vscode는 7.51초까지 내려가 16.7배 속도 향상
  - sentry는 12.08초로 11.6배
  - bluesky는 2.01초로 12.1배
  - playwright는 1.16초로 11배
  - tldraw는 1.06초로 10.6배

## 대형 팀에서 이미 꽤 굴려봄

- 타입스크립트 팀은 10년 넘게 쌓인 수만 개 테스트에 더해, 실제 대형 코드베이스에서 타입스크립트 7을 검증했다고 함
  - 내부적으로 Loop, Office, PowerBI, Teams, Xbox 팀이 테스트함
  - 외부에서는 Bloomberg, Canva, Figma, Google, Lattice, Linear, Miro, Notion, Sentry, Slack, Vanta, Vercel, VoidZero 등이 피드백을 줬다고 함
  - GitHub의 타입스크립트·자바스크립트 프로젝트를 대상으로 회귀를 잡는 테스트 인프라도 타입스크립트 7 기준으로 다시 구축함

- 안정성 지표도 개선됐다고 밝힘
  - 새 언어 서버는 타입스크립트 6.0 대비 실패한 언어 서버 명령을 80% 이상 줄임
  - 서버 크래시는 60% 이상 줄었다고 함

- 실제 팀 피드백 숫자도 흥미로움
  - 슬랙은 타입스크립트 7로 머지 큐 시간이 40% 줄었다고 함
  - 슬랙의 CI 타입 체크 시간은 약 7.5분에서 1.25분으로 줄었음
  - 마이크로소프트 뉴스 서비스 팀은 CI 빌드 대기 시간에서 월 400시간을 절약했다고 함
  - Canva는 에디터에서 첫 오류가 보이기까지 약 58초 걸리던 것이 4.8초로 줄었다고 함
  - Vanta는 큰 프로젝트 중 하나에서 최대 9배 속도 향상을 봤다고 함

## 병렬화는 빨라졌지만 튜닝 포인트가 생김

- 타입스크립트 7은 파싱, 타입 체크, 출력 같은 여러 단계를 병렬로 처리함
  - 파싱과 출력은 파일 단위 독립성이 높아 병렬화 효과가 잘 남
  - 타입 체크는 파일 간 의존성이 복잡해서 더 조심스럽게 나눠야 함

- 새 플래그로 병렬화 정도를 조절할 수 있음
  - `--checkers`는 타입 체커 워커 수를 조절함
  - 기본값은 4개임
  - 큰 코드베이스와 코어가 많은 머신에서는 값을 올리면 빨라질 수 있음
  - 대신 메모리 사용량이 늘 수 있음

- `--builders`는 프로젝트 레퍼런스 빌드 병렬화를 제어함
  - 모노레포처럼 프로젝트가 많은 구조에서 유용할 수 있음
  - 다만 `--checkers 4 --builders 4`는 최대 16개 타입 체커가 동시에 돌 수 있어 과할 수 있음
  - CI 러너처럼 코어와 메모리가 제한된 환경에서는 값을 낮추는 게 나을 수 있음

- `--singleThreaded`도 생김
  - 디버깅, 타입스크립트 6과 7 성능 비교, 외부 빌드 오케스트레이션, 리소스가 아주 제한된 환경에서 쓸 수 있음
  - 타입 체크 워커를 1개로 제한할 뿐 아니라 파싱과 출력도 단일 스레드로 강제함

## 워치 모드도 갈아엎음

- 타입스크립트 7의 `--watch` 모드는 새 기반으로 다시 만들어짐
  - 파셀 번들러의 파일 워처를 기반으로 한 크로스플랫폼 파일 감지 구조를 사용함
  - 고 표준 라이브러리에 내장 파일 워처 API가 없고, 기존 서드파티 라이브러리는 안정성·성능·크로스플랫폼·빌드 툴체인 문제가 있었다고 함

- 순수 폴링 방식은 큰 프로젝트에서 너무 비쌌음
  - 특히 `node_modules` 의존성이 많은 대형 프로젝트에서는 주기적으로 파일 변경을 확인하는 비용이 큼
  - 타입스크립트 팀은 파셀 워처의 C++ 구현을 고로 포팅하고, 최소한의 어셈블리 shim만 사용해 별도 C++ 툴체인 의존을 피했다고 설명함

## 마이그레이션에서 조심할 부분

- 타입스크립트 7.0은 아직 안정적인 프로그래밍 API를 제공하지 않음
  - 새 API는 타입스크립트 7.1에서 제공될 예정임
  - `typescript-eslint`처럼 컴파일러 API가 필요한 도구는 당장 타입스크립트 6 API가 필요할 수 있음
  - 이를 위해 `@typescript/typescript6` 호환 패키지가 제공됨

- 타입스크립트 6과 7을 나란히 쓰는 구성이 가능함
  - `@typescript/typescript6`는 `tsc6` 실행 파일과 타입스크립트 6 API를 제공함
  - npm alias로 `typescript`는 6 호환 패키지에 두고, `@typescript/native` 같은 별도 alias로 7을 설치하는 식의 구성이 안내됨

> [!WARNING]
> Vue, MDX, Astro, Svelte, Angular 템플릿 타입 체크처럼 타입스크립트를 내부에 임베드하는 워크플로는 아직 타입스크립트 7을 바로 활용하기 어려울 수 있음. 이유는 7.0에 안정적인 프로그램 API가 없기 때문임.

- 설정 기본값 변화도 꽤 큼
  - `strict`가 기본 true
  - `module` 기본값은 `esnext`
  - `target`은 `esnext` 직전의 안정 ECMAScript 버전
  - `noUncheckedSideEffectImports`는 true
  - `libReplacement`는 false
  - `stableTypeOrdering`은 true이고 끌 수 없음
  - `rootDir`은 이제 `./`가 기본이라, `src` 같은 내부 소스 디렉터리를 명시해야 할 수 있음
  - `types`는 기본 `[]`라서 필요한 전역 선언 패키지를 명시해야 함

- 더 이상 지원하지 않는 설정도 많음
  - `target: es5`는 지원 중단
  - `downlevelIteration` 지원 중단
  - `moduleResolution: node/node10/classic`은 지원 중단, `nodenext`나 `bundler` 권장
  - `module: amd/umd/systemjs/none`은 지원 중단, `esnext`나 `preserve` 권장
  - `baseUrl` 지원 중단, `paths`는 프로젝트 루트 기준 상대 경로로 바꾸는 방향 권장
  - `esModuleInterop`과 `allowSyntheticDefaultImports`는 false로 둘 수 없음
  - `alwaysStrict`는 true로 간주되고 false 설정 불가

## 타입 시스템과 자바스크립트 지원도 바뀜

- 템플릿 리터럴 타입은 이제 유니코드 코드 포인트를 더 자연스럽게 보존함
  - 예를 들어 `"😀abc"`를 머리와 꼬리로 나누면, 타입스크립트 7에서는 `["😀", "abc"]`가 됨
  - 이전에는 UTF-16 인덱싱처럼 `"\ud83d"`, `"\ude00abc"`로 쪼개질 수 있었음
  - 일부 UTF-16 코드 유닛 기반 타입 유틸리티에는 깨지는 변경일 수 있음

- 자바스크립트 파일 분석도 타입스크립트 파일과 더 일관되게 바뀜
  - 값은 타입 위치에 바로 쓸 수 없고 `typeof`를 써야 함
  - `@enum` 특수 처리가 사라짐
  - 단독 `?` 타입은 더 이상 쓸 수 없고 `any`를 써야 함
  - `@class`가 함수를 생성자로 만들어주지 않음
  - Closure 스타일 함수 타입 문법은 지원되지 않음

## 에디터 경험은 LSP 기반으로 정리됨

- VS 코드 사용자는 타입스크립트 7 전용 확장을 설치하면 기본 경험으로 켜짐
  - 명령 팔레트에서 타입스크립트 7 언어 서버를 끄고 켤 수 있음
  - 향후 몇 주 안에 VS 코드 자체에도 타입스크립트 7 지원이 들어갈 예정임

- 비주얼 스튜디오는 최신 버전에서 워크스페이스에 따라 타입스크립트 7을 자동 활성화함
  - 다른 현대적 에디터도 LSP 기반으로 지원 가능함
  - 자동 import, 확장 hover, inlay hint, code lens, go-to-source-definition, JSX linked editing, tag completion 등 빠진 기능들이 계속 채워졌다고 함

---

## 기술 맥락

- 타입스크립트 7의 가장 큰 의사결정은 기존 자바스크립트 구현을 고로 네이티브 포팅한 거예요. 단순히 새 컴파일러를 만든 게 아니라, 기존 로직과 구조를 최대한 유지해서 결과 호환성을 지키면서 속도를 끌어올리려 한 거예요.

- 병렬화가 까다로운 이유는 타입 체크가 파일 하나만 보고 끝나는 일이 아니기 때문이에요. 여러 파일이 같은 전역 타입과 의존 타입을 공유하고, 순서에 민감한 결과도 있을 수 있거든요. 그래서 타입스크립트 7은 고정된 워커 수로 항상 같은 방식으로 일을 나눠 결과 안정성을 맞추려 해요.

- `--checkers`와 `--builders`가 생긴 건 모든 팀의 머신 조건이 다르기 때문이에요. 개발자 노트북은 코어가 많아도 CI 러너는 메모리가 적을 수 있고, 모노레포는 프로젝트 그래프 때문에 병렬화 병목이 달라질 수 있어요. 그래서 기본값만 믿기보다 팀 환경에 맞춰 숫자를 고정하는 게 중요해요.

- API가 아직 없는 7.0이라는 점도 큰 제약이에요. 타입스크립트를 그냥 `tsc`와 에디터 언어 서버로 쓰는 팀은 바로 이득을 볼 수 있지만, Vue나 Angular처럼 타입스크립트를 내부 컴파일러에 깊게 끼워 쓰는 생태계는 7.1 API가 나올 때까지 병행 구성이 필요해요.

- 설정 기본값 변화는 성능과 별개로 마이그레이션 리스크예요. 특히 `rootDir`, `types`, `strict` 기본값은 기존 프로젝트에서 갑자기 빌드 결과나 전역 타입 인식이 달라질 수 있어서, 타입스크립트 6으로 먼저 경고와 폐기를 정리한 뒤 7로 올리는 편이 덜 아파요.

## 핵심 포인트

- 타입스크립트 7은 기존 코드베이스의 구조와 로직을 최대한 유지하면서 고로 다시 구현한 네이티브 포트다.
- vscode, sentry, bluesky, playwright, tldraw 등 실제 오픈소스 프로젝트에서 7.7~11.9배 빌드 속도 향상을 보였다.
- 새 언어 서버는 타입스크립트 6 대비 실패한 명령을 80% 이상, 서버 크래시를 60% 이상 줄였다고 한다.
- 7.0은 안정적 프로그래밍 API를 제공하지 않아 일부 생태계 도구는 타입스크립트 6과 병행해야 한다.
- strict 기본값, module 기본값, rootDir, types 등 설정 변화와 여러 하드 에러가 있어 마이그레이션 체크가 필요하다.

## 인사이트

타입스크립트 7은 문법 기능 하나보다 개발 피드백 루프 자체를 바꾸는 릴리스다. 특히 모노레포와 대형 프론트엔드 조직에서는 빌드 시간뿐 아니라 에디터가 다시 ‘쓸 만해지는’ 효과가 더 크게 느껴질 수 있다.