---
title: "타입스크립트 7.0, Go 네이티브 포팅으로 빌드가 8~12배 빨라졌다"
published: 2026-07-12T04:05:03.249Z
canonical: https://jeff.news/article/4984
---
# 타입스크립트 7.0, Go 네이티브 포팅으로 빌드가 8~12배 빨라졌다

마이크로소프트가 타입스크립트 7.0을 출시하면서 기존 자바스크립트 기반 구현을 Go로 네이티브 포팅했다. 전체 빌드는 평균 8~12배 빨라졌고, VS코드 빌드는 125.7초에서 10.6초로 줄었으며, 슬랙은 CI 타입 검사 시간을 7.5분에서 1.25분으로 낮췄다.

## 타입스크립트가 이번엔 문법보다 속도로 크게 움직임

- 마이크로소프트가 타입스크립트 7.0을 공식 출시했음. 핵심은 새 문법 자랑이 아니라, 도구 체계 자체를 Go 기반 네이티브 구현으로 옮긴 것임
  - 기존 타입스크립트는 자바스크립트 기반 구현이었음
  - 7.0은 기존 코드 구조와 로직은 최대한 유지하면서 Go로 포팅해 네이티브 실행 속도와 공유 메모리 기반 멀티스레딩을 활용함
  - 마이크로소프트는 전체 빌드 성능이 평균 8~12배 좋아졌다고 밝힘

> [!IMPORTANT]
> VS코드 전체 빌드 시간은 125.7초에서 10.6초로 줄었음. 대략 11.9배 개선이라, “조금 빨라짐” 수준이 아니라 피드백 루프 자체가 달라지는 숫자임

- 대규모 오픈소스 프로젝트 테스트에서도 개선 폭이 꽤 노골적임
  - VS코드는 125.7초에서 10.6초로 단축됨
  - 센트리는 139.8초에서 15.7초로 줄었음
  - 블루스카이는 24.3초에서 2.8초, 플레이라이트는 12.8초에서 1.47초로 개선됨

- 메모리 사용량도 같이 줄었음. 빌드가 빨라졌는데 메모리를 더 먹는 식의 교환이 아니라는 게 중요함
  - VS코드 프로젝트는 전체 빌드 메모리가 5.2GB에서 4.2GB로 약 18% 감소함
  - 블루스카이는 26%, 플레이라이트는 11% 줄었다고 나옴

## 에디터 체감 속도도 같이 건드림

- 타입스크립트는 빌드만 느린 게 문제가 아님. 자동완성, 참조 검색, 오류 진단이 늦으면 개발자가 계속 멈칫하게 됨
  - 마이크로소프트는 프로젝트 로딩, 자동완성, 참조 검색, 오류 진단 응답성이 모두 좋아졌다고 설명함
  - VS Code 코드베이스에서 오류가 있는 파일을 열었을 때 첫 번째 오류가 뜨기까지 걸린 시간이 17.5초에서 1.3초 미만으로 줄었다고 함

- 타입스크립트 7.0은 LSP 기반 새 언어 서버를 도입했음
  - VS코드, 비주얼 스튜디오, 웹스톰 같은 주요 개발 도구에서 성능 개선을 제공하는 구조임
  - 새 언어 서버는 기존 버전 대비 명령 실패율을 80% 이상, 서버 충돌을 60% 이상 줄였다고 밝힘

- 기업 실사용 검증도 꽤 넓게 돌렸음
  - 마이크로소프트 내부에서는 VS코드, 오피스, 팀즈, 파워BI, 엑스박스 코드베이스에서 테스트함
  - 외부로는 블룸버그, 캔바, 피그마, 구글, 노션, 슬랙, 버셀 등이 실제 코드베이스 검증에 참여함

## CI와 병렬 처리까지 들어감

- 슬랙 사례가 특히 현실적임. 타입스크립트 성능 개선이 로컬 개발자 경험을 넘어 병합 대기 시간까지 줄였음
  - 슬랙은 타입스크립트 7 도입 후 CI 타입 검사 시간을 약 7.5분에서 1.25분으로 줄였음
  - 병합 대기 시간도 40% 감소했다고 전함
  - 마이크로소프트 뉴스 서비스 팀은 매월 약 400시간의 CI 대기 시간을 절감했다고 함

- 새 옵션으로 병렬 처리 제어도 가능해짐
  - `--checkers` 옵션은 타입 검사 작업을 여러 코어에 분산함
  - `--builders` 옵션은 프로젝트 참조 빌드의 병렬 처리 수준을 조정함
  - CPU 자원이 충분한 환경에서는 기본 설정보다 더 높은 성능 향상도 가능함

> [!TIP]
> 대형 모노레포나 CI 타입 검사 시간이 긴 팀은 타입스크립트 7.0을 별도 브랜치에서 먼저 벤치마크해볼 만함. 다만 타입스크립트를 내장해 쓰는 일부 프레임워크는 7.1 이후 지원을 기다려야 할 수 있음

- 바로 npm으로 사용할 수 있지만, 모든 생태계가 즉시 따라오는 건 아님
  - 뷰, 아스트로, 스벨트, MDX처럼 타입스크립트를 내부에 깊게 붙여 쓰는 도구는 새 API가 제공될 타입스크립트 7.1 이후 본격 지원될 전망임
  - 즉 라이브러리나 프레임워크 조합이 복잡한 팀은 속도 개선만 보고 바로 올리기보다 호환성 체크가 먼저임

---

## 기술 맥락

- 이번 선택의 핵심은 타입스크립트를 “더 똑똑하게” 만들기보다 “덜 기다리게” 만드는 쪽이에요. 대형 코드베이스에서는 타입 검사와 언어 서버 응답이 느리면 개발자가 저장할 때마다 흐름이 끊기거든요.

- 마이크로소프트가 Go로 포팅한 이유는 네이티브 실행 속도와 멀티스레딩을 제대로 쓰기 위해서예요. 기존 로직을 최대한 유지했다고 밝힌 것도 중요한데, 완전히 새 컴파일러를 만든다기보다 기존 타입스크립트 동작을 보존하면서 실행 기반을 바꾸려는 전략에 가까워요.

- LSP 기반 새 언어 서버는 에디터 생태계를 넓게 가져가려는 선택이에요. VS코드만 빨라지는 구조라면 효과가 제한적인데, 표준 프로토콜을 쓰면 웹스톰 같은 다른 도구도 같은 성능 개선 흐름을 받을 수 있거든요.

- CI 개선은 팀 단위 비용과 바로 연결돼요. 슬랙의 타입 검사 시간이 7.5분에서 1.25분으로 줄고 병합 대기 시간이 40% 낮아졌다는 건, 개발자 한 명의 체감이 아니라 조직 전체의 대기열이 줄어든다는 의미예요.

- 다만 프레임워크가 타입스크립트를 내부에 깊게 물고 있으면 바로 갈아타기 어렵습니다. 뷰, 아스트로, 스벨트, MDX 쪽은 7.1 이후 새 API 지원을 기다려야 할 수 있어서, 실제 도입은 프로젝트 의존성 구조를 보고 판단해야 해요.

## 핵심 포인트

- 타입스크립트 7.0은 기존 컴파일러 구조와 로직을 최대한 유지하면서 Go 네이티브 실행 환경으로 옮긴 버전임
- VS코드 전체 빌드는 125.7초에서 10.6초로 약 11.9배 빨라졌고, 센트리·블루스카이·플레이라이트에서도 큰 개선이 확인됨
- 새 언어 서버는 LSP 기반이며 명령 실패율을 80% 이상, 서버 충돌을 60% 이상 줄였다고 설명됨
- --checkers와 --builders 옵션으로 타입 검사와 프로젝트 참조 빌드를 여러 코어에 분산할 수 있음
- 뷰, 아스트로, 스벨트, MDX처럼 타입스크립트를 내장하는 도구는 타입스크립트 7.1 이후 본격 지원될 전망임

## 인사이트

프론트엔드 대형 코드베이스에서 타입스크립트 병목은 빌드보다 일상적인 피드백 루프를 갉아먹는 문제가 컸음. 이번 7.0은 언어 기능 추가보다 도구 체계의 체감 속도를 바꾸는 릴리스라서, 모노레포와 CI 비용을 가진 팀일수록 바로 체크할 가치가 큼.