더 빠른 컴파일러가 반갑지 않은 개발자는 드물 것이다. 다만 도입 여부를 속도 하나로 결정하기는 어렵다. 빌드는 코드를 처리하는 동안 계약을 검사하고, 잘못된 입력에 오류를 내고, 편집기와 배포 과정에 연결된다. 시간을 줄였는데 필요한 오류까지 사라진다면 좋아진 것인지 다시 물어야 한다. 새 도구를 검토한다면 벤치마크보다 먼저 비교표를 만들고 싶다.
Cloudflare의 공식 글 Introducing tsrs: a Port of TypeScript to Rust는 호환성을 유지하면서 구현을 바꾸려는 실험과 진단 순서 같은 남은 차이를 설명한다. 성능과 개발 상태는 유지보수자가 보고한 내용이며, 여기서 직접 실행한 측정값은 아니다. 이 소식에서 가져오고 싶은 것은 특정 구현에 대한 결론보다, 각자의 프로젝트에서 무엇을 비교해야 하는지에 관한 질문이다.
같아야 하는 동작부터 적기
가상의 애플리케이션에 세 묶음의 검사가 있다고 해보자. 실제 제품 코드, 공용 타입 패키지, 의도적으로 잘못 만든 작은 입력들이다. 앞의 두 묶음은 올바른 코드가 계속 통과하는지 본다. 마지막 묶음은 잘못된 코드가 여전히 의도한 이유로 거부되는지 확인한다. 빨간 빌드가 초록색으로 바뀌었다고 무조건 개선은 아니다. 보호하던 조건을 놓쳐서 통과했을 수도 있다. 거부해야 하는 사례를 도입 전에 정해두는 이유다.
오류는 파일 이름, 위치, 진단 코드처럼 나눠 기록할 수 있다. 먼저 같은 진단이 있는지 비교하고, 순서도 따로 살핀다. 기존 도구가 A·B·C를, 새 도구가 C·A·B를 출력한다면 문자열 전체 비교에서는 크게 달라 보인다. 진단의 집합만 보면 같을 수 있다. 그렇다고 순서를 버려도 된다는 뜻은 아니다. 편집기나 검사 스크립트가 그 순서에 기대고 있는지까지 알아야 동등성을 판단할 수 있다.
잘못된 입력은 작고 이름이 분명할수록 좋다. 필수 필드 누락, 호환되지 않는 콜백처럼 그 사례가 지키는 요구사항을 이름에 남긴다. 후보 도구가 잘 처리하는 사례만 나중에 고르면, 원하던 결론에 맞춘 시험이 되기 쉽다. 비교표는 좋아하는 도구가 바뀌어도 남아 있어야 한다. 오류 문구와 위치가 조금 달라지는 것이 실제 사용에 어떤 영향을 주는지도 별도 칸에 적어두면, 차이를 모두 결함으로 보거나 모두 무시하는 일을 피할 수 있다.
같은 일을 재고 있는지 보기
그다음에 시간을 넣는다. 설명을 위한 가상의 측정이 12초와 4초라면 비율은 세 배다. 하지만 한쪽은 처음부터 빌드했고 다른 쪽은 캐시를 썼다면 같은 일을 비교하지 않았다. 코드 리비전, 옵션, 의존성 잠금 파일, 작업자 수, 기기, 캐시 상태를 함께 기록해야 한다. 최초 빌드와 수정 직후의 검사도 다른 작업이다. 이 숫자들은 실제 도구를 측정한 결과가 아니라, 비교 조건이 왜 필요한지 보여주기 위한 예시다.
숫자는 가정을 드러낼 때 유용하다. 하루에 작업을 막는 검사를 40번 하고 매번 8초가 줄어든다면, 단순 계산으로 320초, 5분 20초다. 모든 검사가 사람을 기다리게 하고 같은 차이가 반복된다는 가정이 붙는다. 백그라운드에서 병렬로 도는 작업이라면 사람이 되찾는 시간은 더 작을 수 있다. 빌드 시간의 차이를 곧바로 개인 생산성 향상으로 바꾸지 말아야 하는 이유다. 어떤 대기를 줄이고 싶은지부터 정해야 측정값에 쓸모가 생긴다.
운영에 맞는지도 한 칸을 차지한다. 편집기와 지속적 통합 환경은 같은 엔진을 쓰는가. 오류를 낸 버전을 식별할 수 있는가. 문제가 생기면 애플리케이션 코드를 바꾸지 않고 돌아갈 수 있는가. 언어의 새 기능이 추가되면 어떻게 따라가는가. 이런 질문이 실험을 막는 것은 아니다. 어디까지 맡겨도 되는지 정하는 데 가깝다. 로컬 비교나 배포를 막지 않는 보조 검사부터 시작하면, 증거를 모으면서 기존 경로를 유지할 수 있다.
채택 기준을 결과보다 먼저
가상의 프로젝트라면 이렇게 기준을 정할 수 있겠다. 필요한 정상·오류 사례를 유지하고, 남은 진단 차이를 설명하며, 실제 중요한 작업에서 시간을 줄이고, 돌아갈 경로를 확인한다. 어느 정도의 차이를 의미 있다고 볼지는 프로젝트가 정할 몫이다. 작은 라이브러리와 큰 대화형 코드베이스의 우선순위가 같을 필요는 없다. 설명하지 못한 호환성 차이는 빠르다는 이유로 지워지지 않는다. 속도는 의미가 달라진 부분을 대신 판단해주지 못한다.
반복하는 개발 작업이 빨라지는 일은 반갑다. 그래서 더 차분히 비교할 가치가 있다. 어느 구현 언어가 이겨야 하는지 논쟁하기 전에, 실제 작업 하나를 고르고 그곳에서 ‘같다’는 말의 뜻을 정해보면 좋겠다. 다른 사람도 읽을 수 있는 비교표에 동작과 시간을 나란히 놓는 것이다. 그러고 나면 벤치마크 숫자는 비로소 제 역할을 한다. 필요한 동작을 지킨 후보들 가운데, 우리 일에 더 맞는 것을 고르는 근거가 된다.
