GN⁺: 10배 더 빠른 TypeScript
(devblogs.microsoft.com)- Microsoft가 컴파일러와 도구의 네이티브 포팅을 통해 Typescript 성능 10배 향상 발표
- 에디터 시작 시간 대폭 향상, 빌드 타임 10배 단축, 메모리 사용량을 대폭 줄임
- 2025년 중반까지
tsc미리 보기 버전을 출시하고, 2025년 말에 완전한 프로젝트 빌드 및 랭귀지 서비스 제공 예정
TypeScript 성능 개선 배경
- TypeScript의 핵심 가치는 뛰어난 개발자 경험임
- 코드베이스가 커질수록 TypeScript의 가치가 높아지지만, 대규모 프로젝트에서는 성능 문제 발생
- 긴 로드 및 검사 시간 문제 발생
- 빠른 에디터 시작 시간 vs 전체 코드베이스 분석 간의 균형 필요
- AI 기반 기능은 빠르고 정확한 의미 정보 제공 필요
- 명령줄 빌드를 통한 코드베이스 상태 검증 요구 증가
네이티브 포트 진행 계획
- TypeScript 컴파일러와 도구의 네이티브 포트 작업 시작
- 성능 개선 목표:
- 에디터 시작 시간 대폭 단축
- 빌드 시간 최대 10배 단축
- 메모리 사용량 감소
- 2025년 중반: 명령줄 타입 검사 가능한
tsc미리보기 버전 출시 예정 - 2025년 말: 완전한 프로젝트 빌드 및 언어 서비스 제공 예정
코드 실행 및 테스트
- TypeScript Go 코드 저장소에서 코드 빌드 및 실행 가능
- 저장소에서
tsc및 언어 서버 빌드 및 실행 지침 제공 - 새로운 기능에 대한 정기 업데이트 예정
얼마나 빨라졌나?
- 현재 TypeScript 프로젝트의 빌드 시간을 여러 인기 코드베이스에서 테스트한 결과 다음과 같은 성능 향상이 나타남:
- VS Code 프로젝트는 약 150만 줄의 코드에서 기존 77.8초에서 7.5초로 약 10.4배 빨라짐
- Playwright 프로젝트는 약 35만 줄의 코드에서 기존 11.1초에서 1.1초로 약 10.1배 개선
- TypeORM 프로젝트는 약 27만 줄의 코드에서 기존 17.5초에서 1.3초로 약 13.5배 개선
- date-fns 프로젝트는 약 10만 줄의 코드에서 기존 6.5초에서 0.7초로 약 9.5배 개선
- tRPC 프로젝트는 약 1만 8천 줄의 코드에서 기존 5.5초에서 0.6초로 약 9.1배 개선
- rxjs 프로젝트는 약 2천 줄의 코드에서 기존 1.1초에서 0.1초로 약 11배 개선
- 아직 기능이 완전하지 않지만, 대부분의 코드베이스에서 10배 이상의 성능 개선 예상
- 빠른 타입 검사와 코드 탐색 가능해짐
- AI 도구 통합 및 고급 리팩토링 지원 가능
에디터 성능 개선
- 에디터 로드 및 응답 속도 개선
- Visual Studio Code 코드베이스 기준 로드 시간:
- 현재: 9.6초 → 네이티브 버전: 1.2초 (약 8배 개선)
- 메모리 사용량도 약 50% 감소
- 언어 서비스 작업 (자동 완성, 빠른 정보 보기, 정의로 이동 등) 성능 향상 예상
- 언어 서버 프로토콜(LSP) 기반으로 이전 작업 진행 중
버전 로드맵
- TypeScript 5.8 출시 완료, TypeScript 5.9 곧 출시 예정
- JS 기반 TypeScript 코드베이스는 6.x 버전으로 계속 개발 진행
- 네이티브 코드베이스가 안정화되면 TypeScript 7.0으로 출시 예정
- TypeScript 6 → JS 기반 버전
- TypeScript 7 → 네이티브 기반 버전
- TypeScript 7 출시 후에도 6.x 버전은 일정 기간 유지 예정
다음 단계
- 성능, 컴파일러 API, LSP 등에 대한 추가 정보 공개 예정
- GitHub FAQ에서 자주 묻는 질문 확인 가능
- 2025년 3월 13일 TypeScript 커뮤니티 Discord에서 AMA 진행 예정 (PDT 오전 10시 | UTC 오후 5시)
논란이 꽤 핫한지 Anders Hejlsberg가 직접 코멘트를 남겼네요
반가운 소식입니다! 신기하게 MS의 타입스크립트 언어는 예상과 달리 정말 의외의(?) 선택들을 많이 하는 것 같습니다. MS 입장에서는 거의 첫번째 오픈소스 프로젝트인데다 JS를 대체하려고 했던 구글의 Dart와 달리 JS를 보완하려고 했던 선택도 참 현명하게 느껴졌고, 이번 네이티브 포팅 언어도 자사 언어도 많고 할텐데 구글의 Go를 선택한 점도 놀랍습니다.
왜 Go 인가란 논의 스레드 재미있네요.
https://github.com/microsoft/typescript-go/discussions/411
고민해야할 것들도 많고...
닷넷은 이해가 가는데 러스트는 go 와 같은 위치라고 생각돠네요 아무래도 기존 만들어진 js 관련 go 프로젝트와 라이브러리도 결정에 영향을 미쳤을것 같숩니다
개인적으로 ts 가 어떤 경우는 유형이 매우 복잡해저서... 거의 포기하다시피 하는 경우(그냥 any로 써버림)가 있는데, 언어에 대해 이해가 부족해서 이겠죠? 상황에 따라 진짜 빨간줄 없애려고 시간낭비 많이 합니다.
SWC는 바벨처럼 호환 가능한 자바스크립트 코드를 생성하고, 번들링하는 것 까지가 초점이고, 이건 타입스크립트 코드를 자바스크립트로 변환하거나 오류를 체크하는 게 초점입니다.
TypeScript 코드가 더 이상 TypeScript로 작성되지 않으면, 팀이 TypeScript를 직접 사용하지 않게 되어 장기적으로 개발 경험에 영향을 미칠 수 있음
개밥을 먹는다고 하죠. 자신이 만든 것을 직접사용하는. 그런데 언어의 경우는 조금 고민이 되는군요.
개인적인 생각으로 ts의 기반인 js의 runtime들이 (e.g. spidermonkey, v8) 대부분 c++로 짜여져있고 js로 구현한 런타임이 없으며,
js -> js 컴파일또한 pure js를 쓰면 너무 느려 esbuild니 뭐니 다 넘어가는걸 보면,
ts에서도 굳이 개밥먹기를 고집해야하나 싶긴 합니다
아, 글을 좀 더 읽어보니 에디터가 빨라지고 그런 이야기가 있어서 헷갈렸던 것 같네요.
- tsc 가 10배 빨라짐. 즉, ts -> js 트랜스파일링 시간이 매우 줄어듬.
- VSCode 같은 ts 로 개발된 큰 프로젝트를 로드할 때 속도가 매우 빨라짐. 즉, ts 의 구문 검사 등 tsc 의 기능을 공유하는 로직이 빨라졌다는 의미.
- VSCode 가 동작하는 속도가 빨라졌다는 것은 아님
이런 내용이었군요.
재귀로 구성된 제너릭 타입을 사용할 때, 느려져서 차선책을 사용한 경험이 있습니다. 10배라면 이런 부분도 개선할 수 있을지 기대되네요.
Hacker News 의견
- TypeScript 팀의 Daniel Rosenwasser가 발표 소식을 전하며, 팀 리더 Ryan Cavanaugh와 함께 질문에 답변할 준비가 되어 있음
- Discord AMA에서 더 많은 정보를 얻을 수 있음
- 빠른 개발 도구는 훌륭하며, TypeScript 팀이 항상 개발 경험에 깊이 고민하는 점이 기쁨
- TypeScript 코드가 더 이상 TypeScript로 작성되지 않으면, 팀이 TypeScript를 직접 사용하지 않게 되어 장기적으로 개발 경험에 영향을 미칠 수 있음
- Flow가 OCaml로 작성되어 실패한 사례를 언급하며, 팀의 생각이 궁금함
- 이전에 Rust로 빠른 tsc를 시도한 사례로 두 프로젝트를 언급함
- stc: 중단됨
- ezno: 활발히 개발 중이며, tsc와 1:1 대응을 목표로 하지 않음
- 프로젝트가 유연한 스크립팅 언어로 시작하지만, 결국 더 네이티브한 표현이 승리하는 경우가 많음
- 낮은 수준의 표현으로 시작하는 것이 더 나을 수도 있다고 생각함
- JS 런타임을 서버에서 사용하는 기본 가정을 재고하게 됨
- 스크립팅 언어의 장점이 점점 줄어들고 있음
- 잠시 만우절인 줄 알았음
- Go를 선택한 것이 좋음
- Rust 대신 Go를 선택한 것이 인상적임
- AOT 컴파일된 .NET을 선택하지 않은 것이 아쉬움
- 새로운 코드베이스를 기존과 최대한 호환되게 유지하는 것이 중요함
- Go의 문법이 TypeScript 코드베이스와 유사하여 포팅이 용이함
- Golang과 TypeScript의 문법적 유사성에 놀람
- Golang에서 sum types를 사용하기 어려웠던 경험을 공유함
- Daniel과 Anders가 네이티브 포트에 대해 심도 있는 논의를 한 팟캐스트를 소개함
- 대규모 TypeScript 파일을 리팩토링하는 과정에서 성능 문제가 발생함
- TypeScript로의 코드베이스 전환이 팀에 큰 도움이 되었지만, 성능 문제는 여전히 존재함
- PHP를 사용하다가 4년 전부터 TypeScript를 사용하기 시작함
- TypeScript의 타입 시스템이 유용하며, 컴파일 속도가 빠름
- Microsoft의 팬은 아니지만, TypeScript는 잘 만들어진 언어라고 생각함