타입스크립트 7.0, Go 네이티브 포팅으로 빌드가 8~12배 빨라졌다

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

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

• 대규모 오픈소스 프로젝트 테스트에서도 개선 폭이 꽤 노골적임

  • 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 자원이 충분한 환경에서는 기본 설정보다 더 높은 성능 향상도 가능함

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

---

기술 맥락

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

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

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

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

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