타입스크립트 7 공개, 고 포팅으로 빌드가 최대 10배 이상 빨라짐

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

• 마이크로소프트가 타입스크립트 7을 공개함. 가장 큰 변화는 고(Go)로 만든 네이티브 포트임

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

• 설치는 기존처럼 npm에서 typescript를 받으면 됨

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

• 개발자가 체감하는 변화는 빌드 시간만이 아님

  • 에디터에서 프로젝트가 열리는 시간
  • 전체 참조 찾기(find-all-references)
  • 자동완성
  • 실시간 진단과 빨간 밑줄
  • tsc --watch 피드백 루프까지 전부 빨라지는 방향임

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

• 공개된 전체 빌드 시간 비교는 이렇다

  • 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을 설치하는 식의 구성이 안내됨

• 설정 기본값 변화도 꽤 큼

  • 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로 올리는 편이 덜 아파요.