메타데이터
- 채널: Tech Bridge
- 원제: [한영자막] TypeScript 7 정식 출시, 컴파일 속도가 진짜 10배 빨라졌을까요?
- 발화자: 앤더스 헤일스버그(Anders Hejlsberg, Microsoft 기술 연구원, TypeScript/C# 설계자)
- URL: https://www.youtube.com/watch?v=XNqrW__UD0o
- 영상 길이: 10:40
- 업로드일: 2026-07-27
- 다이제스트 작성일: 2026-07-27
1층: 한 줄 요약
Microsoft가 TypeScript 컴파일러/도구 전체를 Go로 네이티브 포팅한 TypeScript 7을 정식 출시했다. 네이티브 코드 전환과 멀티코어 동시성 활용 덕분에 평균 10배, 코어를 더 투입하면 최대 12배까지 컴파일·타입체크 속도가 빨라졌으며, 언어 서버 응답도 10초대에서 2초 이내로 단축됐다.
2층: 핵심 포인트 (요약)
- 배경: TypeScript는 14년 전 시작, 처음부터 오픈소스. 현재 NPM 월 다운로드 약 10억 건, 1년 전 GitHub 최다 사용 언어 등극.
- 문제: TypeScript 컴파일러 자체가 TypeScript(자바스크립트)로 작성된 "셀프 호스팅" 구조라 브라우저 UI에 최적화된 JS 런타임 위에서 연산 집약적 컴파일 작업을 돌려야 했고, 대형 프로젝트(예: VS Code — 약 8,000개 파일, 130만 줄)에서 성능·메모리 부족 문제가 자주 보고됨.
- 해법: 약 2년 전부터 실험 시작, 전체 툴체인을 Go 언어로 네이티브 포팅하는 프로젝트를 본격 추진. 코드/구조/알고리즘/의미론은 TypeScript 6과 99.99% 동일하게 유지해 호환성을 확보하면서 언어만 교체.
- 성능 향상 요인: 평균 10배 향상 중 절반은 네이티브 코드 전환, 나머지 절반 이상은 공유 메모리 동시성(멀티코어 병렬 처리) 활용에서 나옴. 이 속도 향상은 "컴파일러가 만들어내는 실행 코드"가 아니라 "컴파일러/도구 자체의 실행 속도"를 의미.
- 실시간 데모: VS Code 프로젝트(8,000개 파일, 130만 줄) 컴파일 시 TypeScript 6은 약 50초, TypeScript 7은 기본 설정(4개 타입체커 동시 실행)으로 약 6.5초(7.5배), 16코어 중 12개를 타입체크에 할당하면 4.5초(약 12배)까지 단축.
- 극단적 사례: 32코어·128GB 빌드 머신에서 1,500만 줄 규모 TypeScript 코드베이스를 컴파일하는 스크린샷 — 모든 코어가 동시에 가동. 기존 컴파일러였다면 코어 1개만 사용하고 나머지는 유휴 상태였을 것.
- 메모리: 코어를 더 써도 이전 컴파일러와 거의 동일한 메모리 사용량으로 훨씬 빠르게 실행됨.
- 언어 서비스 전환: LSP(Language Server Protocol) 기반으로 전환되어 다른 에디터와의 통합이 쉬워졌고, AI 코드 생성 도구들이 LSP로 의미론적 검증을 하는 흐름과도 맞물림.
- 언어 서버 데모: Visual Studio에서 TypeScript 7 확장을 설치해 TypeScript 6과 병행 사용 가능(향후 기본값 전환 예정). "모든 참조 찾기" 등 즉각 반응. 언어 서버를 재시작해 8,000개 파일 재분석을 완료하는 데 2초가 채 안 걸림 — TypeScript 6은 동일 작업에 약 10~12초 소요.
- 검증 과정: 지난 1년간 네이티브 프리뷰를 공개해 업계 파트너들의 피드백을 반영, 현재 코드는 매우 안정적인 상태.
- 마이그레이션 가이드: 컴파일러 API에 의존하는 코드베이스(예: Vue, Astro, Svelte 등 프레임워크 툴체인 — 자동 자막상 "View", "Molar"로 오기됐으나 문맥상 Vue 계열 프레임워크로 추정)는 아직 TypeScript 6을 유지해야 함. 프로세스 간 호출 가능한 네이티브 코드 API는 TypeScript 7.1에서 제공 예정. API가 필요 없다면 즉시 TypeScript 7로 전환 권장.
3층: 상세 내용 (발화 흐름 그대로 정리)
도입 — TypeScript의 성장
- 헤일스버그는 자신을 Microsoft 기술 연구원으로 소개하며 TypeScript 7 출시를 발표.
- TypeScript 프로젝트는 시작한 지 약 14년, 처음부터 오픈소스로 운영.
- 정적 타입으로 JS 개발자 생산성을 높이고, 그 타입 정보를 활용해 좋은 툴링을 만드는 데 집중해옴.
- 현재 NPM 월평균 다운로드 거의 10억 건, 불과 1년 전 GitHub 최다 사용 프로그래밍 언어 등극. 10년 전엔 상상 못 한 성장이며 팀에 겸손함과 동기부여를 준다고 언급.
문제 제기 — 대형 프로젝트의 컴파일 속도
- 큰 커뮤니티만큼 대형 프로젝트도 많아짐. 예시로 자매 프로젝트인 Visual Studio Code(약 8,000개 파일, 130만 줄)를 듦.
- 이런 규모의 프로젝트는 컴파일·타입체크에 상당한 시간이 소요됨.
- TypeScript는 처음부터 "셀프 호스팅"(TypeScript로 TypeScript를 작성)해왔고, 이는 초기에 도구를 직접 매일 사용하며 문제를 몸으로 느낄 수 있었다는 장점이 있었음.
- 하지만 컴파일러가 JS 앱처럼 실행된다는 뜻이기도 해서, 성능·확장성 문제 발생. JS는 브라우저 UI 작성에 최적화된 언어이지 컴파일러 같은 연산 집약적 워크로드에는 최적화돼 있지 않음. 가장 흔한 문제 보고는 성능이 아니라 메모리 부족(OOM).
해법 — Go로 네이티브 포팅
- 약 2년 전 실험을 시작해 전체 툴셋을 Go 언어로 네이티브 코드 전환하는 프로젝트를 본격 추진.
- TypeScript 7은 이 노력의 결과물이며 지난 10년간 가장 큰 규모의 릴리스.
- 평균 약 10배 성능 향상. 그중 절반은 네이티브 코드 자체에서, 나머지 절반 이상은 공유 메모리 동시성 활용에서 나옴.
- 중요한 구분: 이 속도 향상은 "우리가 만드는 도구(컴파일러)"의 속도이지, "그 도구가 만들어낸 실행 코드"의 속도가 아님.
- 통상 프로젝트들이 30% 개선을 자랑하는 것과 비교해, 10배는 "진정한 게임 체인저"이며 대규모 프로젝트의 생산성을 극적으로 바꿈.
동시성이 특히 중요한 이유
- "공짜 점심은 끝났다" — 무어의 법칙은 이제 더 빠른 코어가 아니라 더 많은 코어를 제공하는 방향으로 감.
- 데모에 사용된 머신은 16코어. 향후 연산 집약적 워크로드의 속도 개선은 코어 하나가 아니라 모든 코어를 활용하는 데 달려있다고 강조.
호환성 — TypeScript 6과의 관계
- TypeScript 7은 TypeScript 6 코드베이스를 그대로 "포팅"한 것. 코드/구조/알고리즘/의미론은 동일하며 구현 언어만 바뀜.
- 기존 동작과 99.99% 동일해 호환성이 매우 뛰어남. TypeScript 6과 거의 동일하게 동작하되 일부 사소한 디테일만 다를 수 있음.
라이브 데모 1 — 커맨드라인 컴파일 속도
- VS Code 프로젝트를 TypeScript 6으로 컴파일: 약 50초 소요.
- TypeScript 7로 전환해 재시도(중간에 명령어를 잘못 입력하는 해프닝 있음 — 자막상 "tsc --noEmit /diagnostics"로 네이티브 컴파일러 지정): 약 6~6.5초 → 약 7.5배 향상.
- 진행자가 "10배라고 하지 않았냐"고 묻자, 헤일스버그가 이번 컴파일 전 과정(파싱, 바인딩, 출력)이 모두 동시성으로 처리됐다고 부연. 각 파일이 다른 파일과 나란히 병렬 처리되고, 타입체크 단계는 기본적으로 4개의 타입체커가 동시에 각각 파일의 1/4씩 담당.
- 머신이 실제로는 16코어이므로 "더 잘할 수 있다"며 타입체커를 12개(코어의 3/4)로 늘려 재컴파일 → 4.5초로 단축, 약 12배 향상. 다른 작업 성능은 저하되지만 다른 실행 중 작업이 없다면 모든 자원을 투입해도 무방하다고 설명.
- 메모리 사용량은 이전 컴파일러와 거의 동일한데 실행 시간만 대폭 단축됐다는 점을 강조.
32코어 극단 사례
- 가장 좋아하는 스크린샷으로, 32코어·128GB 빌드 머신이 1,500만 줄 규모 TypeScript 코드베이스를 컴파일하는 모습을 공유. 모든 코어가 바쁘게 작동하는 반면, 기존 컴파일러였다면 녹색 막대(활성 코어) 하나만 표시되고 나머지 CPU는 유휴 상태였을 것이라고 대비.
언어 서비스 — LSP 전환과 라이브 데모
- 커맨드라인 빌드뿐 아니라 "언어 서비스"(에디터 내 실시간 지원)가 실제로 더 중요하다고 언급.
- TypeScript 7의 언어 서비스는 LSP(Language Server Protocol)를 사용하도록 전환됨. 일상 사용에서는 체감되지 않지만, 다른 에디터와의 통합이 훨씬 쉬워지고, AI가 생성한 코드의 의미론적 유효성 검증에도 LSP가 점점 더 활용되는 추세와 맞물림.
- Visual Studio 데모: TypeScript 7이 확장 프로그램으로 설치돼 있고, 현재는 Visual Studio 설치 시 TypeScript 6이 기본이며 확장 설치 시 두 버전이 공존. 향후 TypeScript 7이 기본값이 될 예정.
- 하단 여백에 네이티브 언어 서버 사용 중임이 표시됨. 이 언어 서버에서는 거의 모든 작업(예: 특정 식별자의 "모든 참조 찾기")이 즉각 처리됨. 구문 오류 시 빨간 물결선도 즉시 표시.
- 언어 서버를 재시작해 실행 파일 종료 → 재시작 → 8,000개 파일 재분석 → 오류 밑줄 표시까지의 전체 과정이 2초가 채 걸리지 않음을 시연.
- 비교를 위해 TypeScript 7을 비활성화하고 TypeScript 6으로 전환 후 재시연: 기존 언어 서비스가 응답하기까지 약 10~12초 소요. 대규모 프로젝트에서 IDE를 켰을 때 필요한 기능이 바로 뜨는지 여부의 차이로 이어짐.
검증 상태와 마이그레이션 권장 사항
- TypeScript 7은 지난 1년간 네이티브 프리뷰로 공개돼 상당한 테스트를 거침. 프리뷰 단계에서 사용해본 업계 파트너들의 피드백을 반영해 문제를 보고받고 수정, 현재 코드는 매우 안정적.
- 컴파일러 API를 사용하는 코드베이스(예: Vue/Astro/Svelte 등 — 자막에 "View", "Molar"로 오기됐으나 문맥상 이들 프레임워크의 툴체인으로 추정)가 아니라면 TypeScript 7로 전환할 것을 적극 권장.
- 컴파일러 API 의존 코드베이스는 당분간 TypeScript 6을 계속 사용해야 하며, 두 버전이 공존 가능한 구조로 설계됨.
- Microsoft는 업계·파트너와 협력해 새로운 네이티브 코드 API 및 프로세스 간 호출 가능한 API를 구축 중이며, 이는 TypeScript 7.1에서 제공될 예정.
- API가 필요 없는 경우라면 즉시 TypeScript 7로 전환해 향상된 성능이 주는 여유 시간을 누리라고 권장하며 발표 마무리.
4층: 시사점 / 생각해볼 점
- 네이티브 포팅의 명분: TypeScript 사례는 "셀프 호스팅(자기 언어로 자기 도구를 작성)"의 초기 장점(빠른 피드백 루프, dogfooding)과 장기적 한계(JS 런타임이 연산 집약적 워크로드에 부적합)를 모두 보여주는 좋은 사례. Babel(Rust), esbuild/Vite(Go/Rust), swc(Rust) 등 JS 생태계 전반에서 네이티브 언어로 도구를 재작성하는 흐름과 같은 맥락.
- 동시성이 성능 향상의 절반 이상: 단순히 "네이티브 언어로 옮겼다"보다 "멀티코어를 실제로 활용하도록 설계했다"는 점이 더 크게 기여했다는 게 흥미로운 포인트. 코어 수가 계속 느는 하드웨어 트렌드에서 소프트웨어가 이를 활용하도록 설계하는 것이 핵심 경쟁력이 될 것.
- 호환성 우선 전략: 코드/알고리즘/의미론을 그대로 유지한 채 구현 언어만 바꾸는 "포팅" 방식은 대규모 생태계(수백만 프로젝트가 의존)에서 안전하게 마이그레이션하는 모범 사례로 참고할 만함.
- API 의존성이 마이그레이션의 마지막 장벽: 컴파일러 API에 의존하는 프레임워크 툴체인(Vue, Astro, Svelte 등)은 TypeScript 7.1까지 기다려야 함 — 대규모 언어/툴 마이그레이션에서 "코어 기능은 빠르지만 확장 생태계 API 호환은 늦게 따라온다"는 전형적 패턴.
- 실무 임팩트: 대형 모노레포/코드베이스를 운영 중이라면 컴파일 시간·IDE 반응 속도가 개발자 경험(DX)과 생산성에 직결되므로, TypeScript 7 전환은 (컴파일러 API 의존이 없다면) 우선순위 높은 업그레이드로 고려할 만함.
원문 자막 출처
- 자동 생성 자막(영문 원본 + 한국어 자동 번역) 기반으로 정리. 일부 고유명사(프레임워크명 등)는 자동 자막 오기 가능성이 있어 문맥으로 보정함.