타입스크립트 러스트판 tsrs, 최대 8배의 조건

effidev·2026년 10월 21일

타입스크립트 프로젝트에서 타입 검사를 돌려 놓고 결과가 나올 때까지 기다리는 시간이 아깝다면, 2026년 10월 20일에 같은 날 나온 소식 둘이 걸린다. 하나는 클라우드플레어와 보이드제로(VoidZero)가 공개한 타입스크립트 러스트판 tsrs다. 타입스크립트 7의 검사기를 러스트(Rust)라는 언어로 옮긴 것인데, 같은 수의 검사 스레드(동시에 일하는 일꾼 수)로 맞추면 타입스크립트 7.0보다 최대 8배 빠르고 메모리를 약 70% 덜 쓴다고 클라우드플레어 글은 적었다.

다른 하나는 마이크로소프트가 같은 날 내놓은 타입스크립트 7.1 베타다. 이쪽은 공식 표에서 빨라진 폭이 1.2배에서 1.9배다.

이 사이트는 두 가지를 직접 해 봤다. 인텔 맥에서 npm으로 tsrs를 설치하고 실행해 봤더니 “이 플랫폼은 지원하지 않는다”는 문장이 뜨고 멈췄다. 그래서 같은 맥에서 할 수 있는 쪽, 즉 타입스크립트 7.0.2와 7.1 베타를 공개 저장소 zod로 세 번씩 재 봤다. 평균 2.39초가 2.04초로 1.2배 빨라졌고, 출력 597줄(오류 593개)은 한 글자도 다르지 않았다.

이 글은 타입스크립트를 쓰지만 검사기가 어떻게 만들어지는지는 모르는 사람을 위해 썼다. tsc, 포트, 검사 스레드 같은 말은 처음 나올 때 한 줄로 풀었다. 읽고 나면 “8배”가 어떤 조건에서 나온 숫자인지, tsrs를 내 컴퓨터에서 돌릴 수 있는지, 오늘 당장 무엇을 시험해 볼 만한지 알 수 있다.

근거로 삼은 자료는 다섯 가지다. 클라우드플레어의 10월 20일 블로그 글, 마이크로소프트 타입스크립트 블로그의 7.1 베타 공지(같은 날), tsrs 저장소의 README와 호환성·사용법·벤치마크 문서, npm에 올라온 tsrs와 타입스크립트 패키지 정보, 그리고 해커뉴스 토론이다. 직접 해 본 일은 세 가지다. tsrs 설치와 실행 시도, 타입스크립트 7.0.2와 7.1 베타의 시간·메모리 측정, 두 버전의 출력 비교다. 그 밖의 숫자는 전부 각 자료가 적은 값이고, 어느 쪽 값인지 문장마다 밝혔다.

타입 검사기를 또 옮기는 이유: 7.0은 이미 10배 빨랐다

타입스크립트는 자바스크립트에 “이 값은 숫자다, 문자다” 같은 꼬리표(타입)를 붙여 쓰는 언어다. 꼬리표가 맞는지 따져 오류를 알려 주는 일이 타입 검사이고, 이 일을 하는 프로그램이 tsc다. 코드 편집기가 빨간 줄을 긋는 것도, 저장소에 코드를 올릴 때 자동으로 도는 검사(CI)가 실패하는 것도 결국 이 검사기가 한 일이다.

그 검사기가 너무 느리다는 불만 끝에 마이크로소프트는 타입스크립트 7.0(2026년 7월 8일 공개)에서 검사기를 Go 언어로 다시 썼다. 다른 언어로 같은 논리를 옮겨 쓰는 일을 **포트(port)**라고 부른다. 7.1 베타 공지의 최적화 항목도 “지난 릴리스에서 타입스크립트 7이 6의 약 10배 성능을 낸다고 말했다”는 문장으로 시작한다.

클라우드플레어 글이 던진 질문은 이것이다. Go 포트가 이미 10배 빠른데 왜 러스트로 또 옮기나. 글의 답은 속도만이 아니라 웹어셈블리(WebAssembly, 브라우저와 샌드박스 안에서 프로그램을 돌리는 형식)다. Go 프로그램을 웹어셈블리로 만들면 Go의 쓰레기 수거기(메모리를 자동으로 치우는 장치)까지 같이 담아야 하는데, 러스트는 메모리 관리 방식 덕분에 웹어셈블리 쪽과 직접 주고받기 쉽고 메모리도 적게 쓴다는 설명이다.

또 하나의 배경이 글에 직접 적혀 있다. 지금까지 타입스크립트를 다른 언어로 옮긴 시도는 많았지만 성공한 포트는 타입스크립트 팀의 Go 포트 하나였다. 그런데 “최전선 AI 모델이 이제 대규모 포트를 며칠 만에 거의 혼자 해낸다”는 것이다. 타입스크립트 러스트판 tsrs가 이 흐름 위에 있다는 이야기는 뒤에서 다시 다룬다.

클라우드플레어 쪽 소식은 이 사이트가 지난 9일에도 다뤘다. 이 회사에 자바스크립트 도구가 모이는 흐름은 Deno 팀 합류 소식에서도 보였다. tsrs 글은 클라우드플레어를 자바스크립트 생태계를 받치는 무료 오픈소스 도구(비트 Vite, 롤다운 Rolldown, 옥스린트 Oxlint, 옥스포맷 Oxfmt 등)의 집이라고 소개한다.

같은 날 나온 둘, 무엇이 다른가

타입스크립트 러스트판 tsrs의 저장소 README는 이 도구를 “타입스크립트 7 컴파일러와 언어 서버의 드롭인 대체품”이라고 소개한다. 목표는 완전한 호환(100% conformance)이고, 7.1 정식판에 맞춰 이를 달성하겠다고 한다. 클라우드플레어 글은 “우리는 타입스크립트를 포크하지 않는다. 언어의 설계와 방향은 타입스크립트 팀이 전적으로 맡아야 한다”고 못박았다.

버전 이름 0.18.0-ts7.1.0-dev.20260929는 읽는 법이 있다. 사용법 문서에 따르면 앞의 0.18.0이 tsrs 버전이고, 뒤의 ts7.1.0-dev.20260929는 따라가는 타입스크립트 개발판 날짜다. 즉 아직 나오지 않은 7.1의 개발 중인 코드를 옮긴 것이라 지금 쓰는 7.0.2와 같은 기준이 아니다.

호환성 문서는 이 도구의 성격을 이렇게 적는다. tsrs는 Go 구현(b85298b6a81f 커밋)을 함수 하나씩 옮긴 포트이고, “Go 코드가 명세다. 진단 메시지, 순서, 문구, 종료 코드가 Go와 다르면 tsrs의 버그다. tsrs의 출력이 더 나아 보이더라도 마찬가지다.” 새로 설계한 검사기가 아니라 Go 검사기를 그대로 따라 하는 것이 목표라는 뜻이다.

8배라는 숫자가 서 있는 자리

클라우드플레어 글의 문장은 “같은 수의 타입 검사 스레드를 쓸 때 타입스크립트 7.0보다 최대 8배 빠르고 메모리를 약 70% 덜 쓴다”다. 글 속 차트는 그림이라 숫자를 글로 옮길 수 없었지만, tsrs 저장소가 벤치마크 결과를 글로 공개해 두었다.

측정 조건은 이렇다. vCPU 16개짜리 리눅스 서버(AMD EPYC 9R45)에서 -p <프로젝트> --noEmit으로 타입 검사만 시켰고, tsrs는 10번 번갈아 돌린 중앙값, 타입스크립트 7.0.2(저장소 표에서는 tsgo라고 부른다)는 3번의 중앙값이다. 기록 날짜는 10월 16일이고, 저장소는 이 벤치마크의 자동 실행이 지금 꺼져 있고 “역사적 스냅샷”이라고 밝혔다.

표의 앞 세 열이 “아무 옵션도 주지 않았을 때”다. 이때 타입스크립트 7.0.2는 검사 스레드를 4개 쓰고 tsrs는 이 서버에서 16개를 쓴다(작은 프로젝트는 더 적게). 즉 기본 설정끼리 비교한 배수는 도구의 속도 차이에 일꾼 수 차이가 섞인 값이다. 뒤의 세 열처럼 둘 다 4개로 맞추면 17개 프로젝트에서 4.37배에서 11.81배로 좁혀진다. 기본 설정 쪽은 4.20배에서 16.87배다. 메모리는 기본 설정에서 2.17배(Compiler)에서 4.61배(mui-docs) 덜 쓴다.

클라우드플레어 글의 “최대 8배”는 같은 스레드 수 표의 범위(4.37배에서 11.81배) 안에 들어가는 값이다. 글은 벤치마크를 타입스크립트 팀과 같은 설정으로 맞췄다고 밝혔지만, 저장소 표의 최대치와 글의 숫자가 왜 다른지는 적지 않았다. 측정 기계와 시점, 대상 프로젝트가 다를 수 있다는 점만 짚어 둔다.

해커뉴스에는 이 차이를 짚은 댓글이 있다. 한 사용자가 글의 차트를 읽고 이렇게 적었다. vscode 프로젝트를 검사하는 데 타입스크립트 7.1 야간판은 5.28초, tsrs는 1.73초로 약 3배라는 것이다. 다른 사용자는 같은 값이 7.0 대비 4배, 7.1 대비 3배라고 요약했다. 이 값들은 이 사이트가 차트 원본을 확인한 것이 아니라 댓글이 읽은 값이다.

여기서 분명해지는 것이 하나 있다. “8배”는 기준이 무엇이냐에 따라 3배도, 17배도 되는 숫자다. 7.0과 비교하는지 7.1과 비교하는지, 스레드 수를 맞췄는지, 어떤 프로젝트인지부터 확인해야 내 환경에서 얼마나 기대할지 가늠할 수 있다.

마이크로소프트의 표에서 1.9배는 한 줄뿐이다

7.1 베타 공지는 “기본값인 검사 스레드 4개, --noEmit 조건에서” 7.0과 7.1 베타를 비교한 표를 실었다.

메모리는 bluesky 2,017MiB에서 1,698MiB(15.8% 감소), mui-docs 8,093MiB에서 4,079MiB(49.6%), sentry 6,587MiB에서 5,216MiB(20.8%), t3code-server 6,894MiB에서 5,197MiB(24.6%), vscode 8,387MiB에서 6,943MiB(17.2%)다.

다섯 줄 중 1.9배는 mui-docs 한 줄이고, 나머지는 1.2배에서 1.4배다. 클라우드플레어 글이 “7.1 베타가 7.0보다 최대 2.5배 빠르다”고 쓴 것과 비교하면, 같은 날 나온 두 글이 7.1 베타의 최대치를 1.9배와 2.5배로 다르게 말한다. 어느 쪽이 틀렸다는 뜻은 아니다. 클라우드플레어 쪽 표의 대상과 비교 조건을 이 사이트는 글로 확인하지 못했다. 다만 어떤 숫자를 믿든 평균적인 프로젝트에서 기대할 값은 1.2배에서 1.4배 근처로 보는 편이 안전하다.

공지가 적은 최적화 목록은 49개다. 검사기 안쪽 자료 구조를 작게 만들고 메모리 할당을 줄이는 항목이 많다. 이 목록이 뒤에서 나올 한 해커뉴스 댓글과 이어진다.

7.1 베타를 같은 저장소로 세 번씩 돌려 보니

숫자를 옮기는 데서 멈추지 않고 같은 질문을 이 사이트의 기계에 던졌다. 지난 11일 글에서 bun check와 tsc를 재 본 것과 같은 방식이다. 이번에는 비교 대상이 타입스크립트 두 버전이다.

• 기계: 인텔 코어 i7-9750H(12스레드), 메모리 16GB, 맥 OS. 애플 실리콘이 아니다.
• 도구: npm에서 받은 [email protected]와 [email protected], 각각 별도 폴더에 설치
• 대상: 공개 저장소 zod의 10월 19일 커밋(afdac65)을 --depth 1로 받은 것. node_modules는 설치하지 않았고 코드는 건드리지 않았다.
• 방법: tsc --noEmit --pretty false -p tsconfig.json을 같은 폴더에서 세 번씩 실행해 벽시계 시간과 최대 메모리를 쟀다. 메모리는 time -l의 최대 상주 메모리를 1MB=1,048,576바이트로 나눈 값이다.

세 설정 모두 1.2배에서 1.3배였다. 마이크로소프트 표의 1.2배에서 1.4배 구간 안이다. 클라우드플레어 글의 2.5배도, 공식 표의 최대 1.9배도 이 프로젝트에서는 나오지 않았다. 메모리는 공식 표(15.8%에서 49.6%)의 중간쯤이다.

정확도도 봤다. 두 버전이 낸 출력은 597줄(오류 593개와 이어지는 설명 줄)인데 diff로 비교하니 0줄이 달랐다. 이 저장소에서는 7.1이 새로 내는 오류가 없었다는 뜻이다.

한계도 분명하다. 저장소 하나, 기계 하나의 값이다. node_modules가 없어 타입 선언을 못 찾는 오류가 대부분이라 실제 개발 환경과는 다르다. 검사에 2~5초 걸리는 작은 프로젝트라서 절대 시간으로는 0.35초에서 1.1초를 아낀 셈이고, 몇십 초 걸리는 프로젝트에서 이 차이가 얼마나 커지는지는 공식 표의 몫이다. 지난 글과 같은 zod 저장소지만 커밋이 달라서(그때는 10월 9일 284243f) 두 글의 숫자를 직접 비교하지는 않는다.

인텔 맥에서 tsrs는 이렇게 멈췄다

같은 맥에서 tsrs도 해 봤다.

npm init -y
npm i tsrs        # 오류 없이 끝남
npx tsrs --version

설치는 아무 경고 없이 끝났다. 실행하자 다음 세 줄이 나오고 종료 코드 1로 멈췄다. 뜻을 옮기면 이렇다.

tsrs: darwin-x64용 바이너리가 든 선택 의존성 @tsrs/darwin-x64를 찾을 수 없다.
이 플랫폼은 지원하지 않는다. 지원: darwin-arm64, linux-arm64-gnu, linux-arm64-musl, linux-x64-gnu, linux-x64-musl.
직접 빌드한 바이너리를 쓰려면 TSRS_BINARY=/path/to/tsrs 를 지정하라.

tsrs는 러스트로 만든 실행 파일을 운영체제별로 따로 올려 두고, 설치할 때 내 컴퓨터에 맞는 하나만 가져오는 방식이다. 내 컴퓨터에 맞는 것이 없으면 설치는 통과하고 실행할 때 실패한다. 호환성 문서의 표도 같은 내용이다. 미리 만든 실행 파일은 macOS 애플 실리콘(arm64), 리눅스 x64와 arm64(glibc, musl 둘 다)뿐이고, 윈도 x64는 “다음 릴리스용으로 설정되어 있으며 0.18.0 이하에는 윈도용 패키지가 없다”, 인텔 맥용은 “없다”고 적혀 있다.

CI가 윈도나 인텔 맥 러너(작업을 돌리는 컴퓨터)를 쓰는 팀이라면 설치 단계는 통과하고 검사 단계에서 멈출 가능성이 크다. 윈도는 직접 확인하지 못했으므로 “문서가 그렇게 적었다”는 선까지만 말한다.

우회로는 두 가지가 문서에 있다. 하나는 직접 빌드한 바이너리를 TSRS_BINARY로 지정하는 것인데, 이 맥에는 러스트 도구(cargo)가 없어 시도하지 않았다. 다른 하나는 @tsrs/wasm이다. 단일 스레드로 도는 웹어셈블리판이라 속도 이점은 줄지만 운영체제를 가리지 않는다. 저장소는 2,000개 적합성 표본에서 네이티브 단일 스레드 결과와 바이트까지 같았다고 적었다. 설치 없이 브라우저에서 해 볼 수 있는 놀이터(tsrs-playground.void.app)도 열려 있다고 README가 안내한다.

오류 목록은 같아야 한다, 어디까지 같은가

검사기는 빠르기 전에 맞아야 한다. 호환성 문서가 내놓은 증거는 이렇다.

• 타입스크립트의 적합성 시험에서 오류 기준 파일 13,462개 중 13,458개가 일치한다. 나머지 4개는 “시험 도구의 부산물”이라고 적었다.
• 타입·심볼 기준 파일 12,779개는 전부 일치한다.
• 인기 저장소 400곳의 진단을 Go판과 비교하는 도구가 있는데, 자동 실행은 지금 꺼져 있다.

벤치마크 17개 프로젝트에서 7.0.2와 tsrs의 오류 개수가 같은 곳은 9곳이다. 다른 8곳은 tsrs가 따라가는 7.1 개발판에서 타입스크립트 자체가 바뀌었기 때문이라고 저장소는 설명하고, 7.1 개발판으로 직접 돌리면 tsrs와 똑같은 오류가 나온다고 덧붙였다. 예를 들어 vscode는 7.0.2에서 359개, tsrs에서 371개다. 그러니 “7.0.2 결과와 같아야 한다”는 기대로 tsrs를 돌리면 개수가 다를 수 있고, 그건 버그가 아닐 수 있다. 비교 대상은 7.0.2가 아니라 7.1 베타나 개발판이다.

진짜 버그도 한 건 적혀 있다. 검사 스레드 16개 조건에서 drizzle-orm은 오류 개수는 같은데 위치가 다르다고 “tsrs의 버그”라고 저장소가 표시했다.

빠진 기능도 있다. --init과 --showConfig는 “지원하지 않는다”며 종료한다. --generateTrace는 추적을 시작하지 못했다고 경고하고 일반 검사만 한다. --watch는 리눅스와 맥에서만 되고 윈도에서는 “지원하지 않는다”며 끝난다. 언어 서버에서 .vue·.svelte·.astro 같은 확장 파일을 처리하는 기능, 자동 타입 내려받기도 아직 없다. 결과가 스레드 수에 따라 흔들리는 문제도 일부 남아 있어서, 타입스크립트와 가장 가깝게 비교하려면 --checkerAssignment go --noLazyMembers 옵션과 --checkers 수 맞추기를 쓰라고 안내한다.

감시 모드에서 나온 53배, 그 숫자의 조건

가장 큰 배수는 따로 있다. 저장소는 vscode 프로젝트를 감시 모드(--watch, 파일을 고칠 때마다 다시 검사)로 돌린 결과를 공개했다. vCPU 8개짜리 리눅스 서버이고, 편집한 파일은 어디서도 불러오지 않는 시험 파일 하나다.

편집기에서 코드를 고칠 때마다 빨간 줄이 뜨는 속도에 가장 가깝게 닿는 값이 이 표다. 1초 넘게 걸리던 재검사가 사람이 거의 느끼지 못하는 30밀리초대로 내려온다는 이야기다. 다만 수정한 파일을 아무도 불러오지 않았다는 조건 때문에 가장 유리한 경우라는 점은 밝혀 둬야 한다. 여러 파일이 불러오는 중심 파일을 고치면 다시 검사할 범위가 넓어진다. 그리고 이 표는 리눅스 기준이다. 맥은 파일 저장이 끝났다는 신호가 따로 없어서, 저장 이벤트가 도착한 뒤(약 13밀리초 뒤) 재검사를 시작한다고 사용법 문서가 따로 설명한다.

에이전트가 옮긴 타입스크립트 러스트판을 어떻게 읽을까

클라우드플레어 글은 포트 자체를 AI 에이전트가 해냈다는 전제 위에 서 있다. 같은 글은 이 팀이 원본 Next.js와 보조를 맞추는 프로젝트 비넥스트(Vinext)에서 쓰는 방식을 타입스크립트에도 쓰겠다고 했다. 매일 아침 에이전트가 원본의 변경을 읽고 추적 이슈를 열며, 매일 밤 호환성 표를 새로 뽑는다는 것이다. 시험이나 이슈에서 틈이 드러나면 에이전트가 두 코드베이스에서 바뀐 곳을 찾아 재현 코드를 만들고, 관련 시험을 옮기고, 고칠 안을 낸다는 설명이다.

tsrs 저장소에는 이 방식이 규칙으로 남아 있다. 저장소의 코딩 에이전트용 지침(AGENTS.md)은 성능·메모리 변경이 병합되려면 숫자를 붙여야 한다고 못박는다. 실행 명령어 수 1%, 벽시계 시간 2%, 최대 메모리 5% 중 하나 이상을 개선해야 하고, 이미 시도했다가 버린 접근은 목록에서 확인한 뒤 새 근거가 있을 때만 다시 시도하라고 적었다. 병합 기준이 사람의 인상이 아니라 숫자와 시험 기준 파일로 적혀 있다는 점이 이 저장소의 특징이다. 앞서 본 13,458개 일치가 그 기준 중 하나다.

해커뉴스에서는 이 점이 가장 크게 갈렸다. 한 댓글은 에이전트가 사람이 쓰지 않을 방식으로 코드를 쓰기 때문에 예상 못 한 방식으로 깨질 수 있고 사람이 안 읽은 컴파일러를 믿기 어렵다고 적었다. 다른 댓글은 타입스크립트에 이미 방대한 시험 모음이 있어서 속이 불투명한 상자라도 기준 파일로 동작을 확인할 수 있다고 맞섰다. 이 사이트가 말할 수 있는 건 하나다. 위 일치율은 저장소가 공개한 숫자이고, 이 맥에서는 tsrs를 돌리지 못해 직접 검증하지 못했다.

가장 눈에 띄는 댓글은 타입스크립트 팀 소속이라고 밝힌 사용자의 것이다. 해커뉴스 닉네임 DanRosenwasser는 tsrs 프로젝트를 흥미롭게 지켜봤고 메인테이너(관리자)들과 이 도구가 왜 빠른지, 어떤 최적화가 안전한지 함께 이해하는 중이라고 적었다. 팀이 직접 “러스트 바이브 포트”도 해 봤는데, 속도의 상당 부분이 언어 선택만으로 나오지는 않는다고 의심한다고 했다. 그리고 7.1을 더 빠르고 가볍게 만들 최적화 일부는 tsrs에서 발견된 것이라고 했다. 이 댓글의 작성자가 7.1 베타 공지의 글쓴이(다니엘 로젠바서)와 같은 사람인지는 이 사이트가 확인하지 못했다. 다만 클라우드플레어 글도 7.1의 일부 최적화가 tsrs에서 타입스크립트로 올려 보낸(upstream) 것이라고 같은 말을 한다.

정리하면 두 도구는 경쟁이면서 서로를 빠르게 만드는 중이다. 같은 날 나온 7.1 베타가 앞서 본 1.2배에서 1.9배를 얻은 데에 tsrs에서 나온 최적화가 일부 들어 있다는 것이 양쪽 설명이다.

클라우드플레어가 강조한 쪽은 샌드박스다

속도 경쟁처럼 보이지만 글이 강조한 쪽은 다른 곳에 있다. 클라우드플레어는 몇 주 전 워커스(Workers)에서 러스트를 직접 지원한다고 발표했다며, 빌드와 배포 시스템 전체를 워커스 위에서 촘촘히 반복해 돌리면 작은 메모리 사용량의 이득이 빨리 쌓인다고 적었다. 그래서 에이전트와 함께 쓰면 개발 도구 전체를 클라우드플레어의 격리된 환경 안에서, 심지어 브라우저나 임베디드 기기 안에서도 돌릴 수 있게 된다는 그림이다.

해커뉴스에서는 두 댓글이 이 점을 짚었다. 한 사용자는 처음에는 “더 빠른 러스트 타입스크립트 컴파일러를 만들자”가 아니라 웹어셈블리 샌드박스 안에서 돌 컴파일러가 필요했던 것으로 이해했다고 적었다. 또 다른 사용자는 이 회사의 필요가 일반 웹 개발자의 반복 주기와는 많이 다르니 서둘러 갈아탈 필요는 없다고 경고했다. 글은 tsrs를 더 깊이 통합해 볼 예로 옥스린트(Oxlint)의 타입 정보를 쓰는 검사 규칙을 들었다.

여기서 읽을 수 있는 것은 방향이다. 타입 검사기가 사람이 터미널에서 돌리는 프로그램에서 에이전트가 격리 환경 안에서 수없이 부르는 부품으로 옮겨 가고 있다는 점이다. 그런 부품에는 시작이 빠르고 메모리가 작은 쪽이 유리하다. 클라우드플레어 글의 무게는 내 노트북의 검사 시간보다 이쪽에 실려 있다.

오늘 해 볼 시험 셋

세 단계로 정리한다. 앞의 둘은 누구나, 마지막은 애플 실리콘 맥이나 리눅스를 쓰는 사람만 할 수 있다.

1. 지금 값을 먼저 잰다. 바꾸기 전 기준이 없으면 빨라졌는지 알 수 없다.

time npx tsc --noEmit --pretty false > before.txt

2. 7.1 베타를 별도로 받아 같은 일을 시킨다. 현재 설치를 건드리지 않는 임시 폴더가 안전하다.

mkdir /tmp/ts71 && cd /tmp/ts71 && npm init -y && npm i -D typescript@beta
cd -  # 내 프로젝트로 돌아온다
time /tmp/ts71/node_modules/.bin/tsc --noEmit --pretty false > after.txt
diff before.txt after.txt

diff가 비어 있으면 같은 오류를 더 빨리 낸 것이다. 새 오류가 나오면 공지의 “눈여겨볼 동작 변화”를 본다. 예를 들어 7.1은 조건부 타입에서 분배되는 타입 매개변수를 더 엄격하게 검사해서, 이전에 통과하던 코드가 새 오류를 낼 수 있다고 적었다.

3. 애플 실리콘이나 리눅스라면 tsrs도 같은 방식으로 시험한다.

pnpm dlx tsrs -p . --noEmit --pretty false > tsrs.txt

공정하게 비교하려면 --checkers를 맞추고, 정확히 같은 결과를 보려면 --checkerAssignment go --noLazyMembers를 붙이라고 저장소는 안내한다. 비교 기준은 7.0.2가 아니라 7.1 베타여야 한다. 위에서 본 대로 tsrs는 7.1 개발판을 따라가기 때문이다. 그리고 지금은 실험 단계이니 운영 CI에 바로 넣지 말고 병행 실행으로 결과만 비교하는 편이 낫다.

절약 시간이 얼마나 되는지 감을 잡는 계산도 해 두자. 마이크로소프트 표의 mui-docs는 한 번에 22.2초가 11.9초가 되어 10.3초를 아낀다. 하루 50번 돌리는 CI라면 515초, 약 8분 반이다. 이 사이트의 zod는 한 번에 0.35초를 아꼈으니 같은 50번이어도 18초다. 검사가 몇 초면 끝나는 프로젝트에서는 체감이 작고, 몇십 초 걸리는 프로젝트에서 차이가 커진다.

tsrs 숫자 중 직접 못 본 것들

• tsrs를 실제로 돌려 보지 못했다. 이 맥이 인텔이라 실행 파일이 없고, 러스트 도구도 없어 직접 빌드도 하지 않았다. tsrs의 속도·메모리·일치율은 전부 클라우드플레어 글과 tsrs 저장소 문서의 값이다.
• 클라우드플레어 글의 차트 값은 그림이라 읽지 못했다. 8배·2.5배는 글의 문장이고, vscode 5.28초 대 1.73초는 해커뉴스 댓글이 읽은 값이다.
• 저장소의 벤치마크 표는 “역사적 스냅샷”이고 자동 실행이 꺼져 있다. 10월 16일 기준이며 이후 릴리스(0.18.0은 10월 19일)에서 달라졌을 수 있다.
• 측정은 zod 하나와 인텔 맥 하나다. node_modules가 없는 상태라 실제 개발 환경의 검사 시간과 다르다. 세 번 평균과 --checkers 4의 1회 값이라 오차도 있다.
• 7.1 베타 공지는 “약 한 달 뒤 릴리스 후보(RC), 그 직후 정식판”이라고만 적었다. tsrs 정식판의 날짜는 두 글 어디에도 없다.
• 해커뉴스 댓글 작성자의 신원은 확인하지 못했다. 토론 전체는 10월 21일 오전 기준 324점, 댓글 146개였다.
• 에디터 연동, 윈도 실행, 대형 사설 모노레포에서의 동작은 해 보지 않았다.

지금 기준으로 이 글이 권하는 것은 하나다. 타입 검사 시간이 신경 쓰인다면 tsrs보다 먼저 typescript@beta를 임시 폴더에 받아 내 프로젝트에서 diff까지 돌려 보는 것이다. 이 맥에서도 되는 시험이고, 결과가 같다면 7.1 정식판을 기다리는 동안 얼마나 빨라질지 미리 알 수 있다.