타입 검사가 빨라진 뒤에 남은 질문

TypeScript 7의 타입 검사가 네다섯 배 빨라졌다는 첫 측정값을 보고 내가 먼저 물은 것은 “어느 앱에서?”였다. 배수가 커도 원래 1초 걸리던 검사인지, 16초 걸리던 검사인지에 따라 한 번 기다리는 시간은 다르다.

그래서 Firstage에서 타입 검사 명령을 실행하는 앱과 서비스 18개를 비교했다. 각 명령은 TypeScript 6과 7로 각각 세 번 실행했고, 증분 캐시를 끈 타입 검사 실행 시간의 중앙값을 썼다. 18개 모두 두 버전에서 검사를 통과했다. 패키지별 속도 향상은 2.15 ~ 6.24배였고, 그 배수의 중앙값은 4.84배였다.

검사	TypeScript 6 → 7	속도 향상	한 번에 줄어든 시간
asset-service	4.65 → 0.75초	6.24배	3.90초
Journey 앱	11.55 → 2.62초	4.42배	8.93초
Journey worker	15.99 → 5.88초	2.72배	10.11초
Journey API	16.17 → 6.70초	2.41배	9.46초

asset-service는 배수가 가장 컸다. 한 번의 검사에서 가장 많이 줄어든 곳은 Journey worker였다. 배수는 2.72배지만 10.11초가 줄었다. Journey API도 배수만 보면 2.41배지만 9.46초가 줄었다. 배수 순서와 실제로 기다리는 시간의 순서가 같지 않았다.

원래 3초도 걸리지 않던 검사 7개는 속도 향상 중앙값이 5.57배였지만, 한 번에 줄어든 시간의 중앙값은 1.39초였다. 3 ~ 10초 걸리던 검사 8개는 각각 4.84배와 4.18초, 10초 이상 걸리던 검사 3개는 2.72배와 9.46초였다. 이것은 이번 표본의 모습이다. 검사 대상이 클수록 TypeScript 7의 효과가 작다는 결론은 낼 수 없다. 짧은 검사를 하루에 여러 번 기다린다면 1초도 의미가 있겠지만, 아직 실행 횟수는 재지 않았다.

개발자가 기다리는 시간

내게 타입 검사는 코드를 고친 뒤 첫 답을 받는 경로 중 하나다. 답이 빨리 오면 방금 바꾼 코드를 머릿속에 두고 다시 고칠 수 있다. AI가 초안을 빨리 만들어도, 그 코드가 의도대로 작동하는지 확인하고 오류를 고치는 과정은 그대로 남는다. 그래서 요즘은 코드를 만드는 시간만큼, 믿을 수 있는 피드백이 돌아오는 시간을 보게 된다.

이번에 잰 것은 로컬 타입 검사뿐이다. 빌드, 테스트, CI 대기열, 리뷰 시간은 포함하지 않았다. asset-service의 타입 검사가 6.24배 빨라졌다고 해서 그 서비스의 빌드나 변경 하나를 끝내는 시간도 6.24배 빨라졌다고 말할 수는 없다.

창업자가 따져야 할 두 시간

작은 팀에서는 사람의 집중 시간도, 컴퓨팅 자원도 한정돼 있다. 그렇지만 둘을 같은 숫자로 계산하면 우선순위를 잘못 잡기 쉽다. 검사가 자주 실행되는지, 다른 검사를 시작하지 못하게 막는지에 따라 1초와 10초의 무게가 달라진다. 이번 측정에는 실행 빈도와 실제 CI 경로가 없으니 가장 높은 배수나 가장 긴 시간만 보고 다음 투자 순서를 정할 수 없다.

CPU가 쓴 총시간, 메모리, CI 러너 요금도 재지 않았다. 화면에서 결과를 기다리는 시간이 네 배 짧아져도 컴퓨팅 비용이 4분의 1이 됐다는 뜻은 아니다. 사람에게 돌아온 시간과 기계가 사용한 자원을 따로 기록해야 한다.

Linear의 글에서 가져온 질문

Linear는 최근 AI 코딩으로 CI가 병목이 됐다는 글에서 네이티브 TypeScript로 바꾼 뒤 tsc 검사의 주간 중앙값이 73% 줄었다고 썼다. 하지만 내가 더 오래 생각한 대목은 26초 걸리던 변경 감지 작업이었다. 이 작은 단계가 API 테스트 샤드 여덟 개의 시작을 막고 있었고, Linear는 이를 8초로 줄였다. 짧은 검사라도 경로 앞에 놓이면 뒤의 모든 일이 기다린다.

Linear는 PR의 CI 대기 시간과 테스트당 러너 시간도 따로 다뤘다. 테스트 규모가 연초보다 거의 네 배로 늘어난 가운데 PR 대기는 6분 넘게 걸리던 상태에서 5분 조금 넘는 수준으로, 테스트당 러너 시간은 약 절반으로 바뀌었다. 여러 변경을 함께 적용한 결과이므로 tsc의 73%를 CI 전체의 개선 폭으로 읽어서는 안 된다. Linear의 수치를 Firstage에 그대로 옮길 수도 없다.

테스트를 나눠 병렬로 돌리면 사람이 기다리는 시간은 줄어도 러너 사용량은 늘 수 있다. Linear가 테스트를 나누기 전에 셋업 시간을 줄인 과정도 그래서 눈에 들어왔다. 시간을 벌기 위해 어디에 컴퓨팅 자원을 더 쓸지, 어디서 낭비를 먼저 없앨지 따로 판단한 셈이다.

Firstage에서 이제 확인하고 싶은 것은 어느 검사가 개발자를 실제로 기다리게 하는지다. 그 검사가 하루에 몇 번 실행되는지, CI에서 다음 단계를 막는지, 러너는 얼마나 오래 쓰는지까지 봐야 한다. 그때야 TypeScript 7이 돌려준 시간이 내 작업과 팀의 자원에 어떤 차이를 만들었는지 말할 수 있다.