러스트로 다시 쓴 타입스크립트 체커, tsz가 tsgo보다 빠르다고 나옴

• 러스트로 작성된 타입스크립트 체커 겸 언어 서비스인 tsz가 공개됨

  • 목표는 기존 타입스크립트 툴체인보다 빠른 타입 검사와 에디터 지원을 제공하는 것
  • 프로젝트 설명상 tsgo를 성능 기준점으로 삼고 있고, 그보다 더 빠른 쪽을 노리는 분위기임

• 현재 공개된 성능 수치는 ‘40개 성공 마이크로벤치마크 합산’ 기준임

  • 즉, 작은 케이스에서는 꽤 인상적인 숫자를 보여주지만 이걸 바로 대형 서비스 코드베이스 성능으로 읽으면 안 됨
  • 프로젝트 쪽에서도 대형 프로젝트 성능 최적화는 아직 진행 중이고, 지금은 큰 프로젝트에 최적화돼 있지 않다고 못 박음

• 호환성은 타입스크립트 공식 테스트 스위트를 기준으로 맞추는 중임

  • tsc와 비교해서 진단 메시지, 자바스크립트 출력, 선언 파일 출력, 언어 서비스 동작을 검증함
  • 흥미로운 건 “컴파일러 테스트 100% 통과해도 완전 호환이라고 확신하지 않는다”고 말한 부분임
  • 실제 전체 프로젝트 벤치마크에서는 아직 컴파일에 실패하는 케이스가 많고, 공식 테스트가 못 잡는 버그도 많다고 함

• 속도만 보는 프로젝트는 아님. Sound Mode라는 더 엄격한 타입 검사 실험도 같이 하고 있음

  • 타입스크립트는 현실적인 자바스크립트 생태계 호환성 때문에 일부 느슨한 타입 동작을 허용함
  • tsz는 여기서 더 엄격한 모드를 탐색하면서 “빠른 타입스크립트”뿐 아니라 “더 안전한 타입스크립트” 가능성도 건드리는 셈임

• 지금 개발자가 받아들일 만한 결론은 이거임. 당장 tsc를 갈아엎을 물건은 아니지만, 타입스크립트 툴링의 다음 병목이 어디인지 보여주는 신호탄에 가까움

  • 대형 프로젝트 호환성과 언어 서비스 품질이 따라오면 VS Code, 빌드 파이프라인, CI 타입 체크 시간이 전부 영향권에 들어감
  • 반대로 타입스크립트 호환성은 워낙 미묘한 구석이 많아서, 마이크로벤치마크만으로 승자를 말하기엔 아직 너무 이름

---

기술 맥락

• tsz가 러스트를 고른 이유는 타입 검사와 언어 서비스가 결국 CPU를 많이 쓰는 작업이라서예요. 대형 타입스크립트 코드베이스에서는 에디터 진단 하나, CI 타입 체크 하나가 개발자 대기 시간으로 바로 튀어나오거든요.

• 다만 타입스크립트 컴파일러를 새로 쓰는 건 단순히 빠른 파서를 만드는 문제가 아니에요. tsc의 진단, 출력, 선언 파일 생성, 언어 서비스 동작을 거의 그대로 맞춰야 기존 프로젝트가 깨지지 않아요.

• 그래서 공식 테스트를 통과했다는 말도 조심해서 봐야 해요. 원문이 직접 말하듯이 테스트 스위트가 못 잡는 실제 프로젝트 버그가 있고, 전체 프로젝트 벤치마크에서 아직 실패하는 케이스도 많거든요.

• Sound Mode는 더 재미있는 지점이에요. 타입스크립트의 느슨함을 유지할지, 더 엄격한 타입 안정성을 선택할지는 생산성과 안정성 사이의 트레이드오프라서 팀마다 답이 달라질 수밖에 없어요.