컴파일·린트·테스트의 대기 시간을 줄이는 업데이트
Cloudflare가 2026년 9월 28일 공개한 VoidZero 소식의 핵심은 자바스크립트 개발 과정에서 반복되는 검증을 빠르게 만드는 것이다. VoidZero가 Cloudflare에 합류한 뒤 네 달 동안 80건이 넘는 릴리스를 내고 1,200건 이상의 이슈를 종료했으며, 컴파일러부터 린터, 포매터, 테스트 실행기까지 성능 개선을 진행했다고 밝혔다.
이번 발표는 하나의 도구만 바꾸는 소식이 아니다. Oxc, Rolldown, Vite, Oxlint, Vitest처럼 서로 연결된 도구들의 개선과 이를 묶은 Vite+ 1.0을 함께 다룬다. 개발자에게 중요한 질문은 제품 수보다 현재 프로젝트에서 가장 오래 기다리는 단계가 무엇이고, 해당 업데이트가 그 시간을 줄일 수 있는가다.
개인 프로젝트에서는 저장 후 결과를 확인하는 시간이, 학생과 연구자에게는 실험용 웹 앱을 수정하고 검증하는 시간이 영향을 받을 수 있다. 팀에서는 같은 검증을 여러 개발자와 CI가 반복하므로 작은 차이도 누적될 수 있다. 다만 발표에 나온 배수를 프로젝트 전체의 속도 향상으로 받아들이면 안 된다. 각 수치는 서로 다른 도구와 비교 조건을 가리킨다.
발표된 성능 수치는 어디에 적용되는가
- Oxc React Compiler: 기존 Babel 기반 React Compiler 구현과 비교해 컴파일이 10배 빠르다고 발표했다. 웹 페이지가 사용자에게 10배 빠르게 표시된다는 뜻은 아니다.
- Vitest 5: Vitest 4보다 최대 50% 빠르다는 설명이다. 테스트 구성과 실행 환경에 따라 실제 차이는 달라질 수 있다.
- tsgolint: 대규모 코드베이스에서 타입 정보를 활용하는 린트를 ESLint와 typescript-eslint 조합보다 12~18배 빠르게 수행한다고 밝혔다.
- Oxfmt: JSON, CSS, SCSS, Less, GraphQL, YAML 포매터를 Rust로 다시 작성했으며, Prettier 대비 7배 빠르다는 수치를 제시했다. 자신의 파일 구성과 포맷 결과를 함께 확인해야 한다.
이 수치들을 더하거나 곱해서 전체 개발 시간의 절감률을 계산할 수는 없다. 예를 들어 테스트 실행보다 의존성 설치가 오래 걸리는 CI에서는 테스트 도구만 바꿔도 전체 실행 시간의 차이가 작을 수 있다. 반대로 타입 기반 린트가 대부분의 시간을 차지하는 저장소라면 해당 단계의 개선이 직접적인 효과로 이어질 수 있다.
비교할 때는 전체 명령의 완료 시간과 내부 단계별 시간을 구분하는 편이 좋다. 첫 실행과 캐시가 남은 실행, 로컬과 CI도 나누어 측정해야 한다. 발표 수치에 가까운 결과가 나오는지보다 자신이 반복하는 작업에서 기다림이 얼마나 줄었는지가 선택에 더 유용한 기준이다.
React 프로젝트는 컴파일러와 플러그인부터 확인한다
Oxc React Compiler는 React 팀의 Rust 재작성 작업을 바탕으로 만든 React Compiler 구현이다. Cloudflare는 기존 Babel 구현보다 컴파일이 빠르고 메모리 사용이 적으며, 구현의 완성도와 오류 처리도 개선했다고 설명했다. React를 사용한다는 이유만으로 모든 프로젝트에 같은 효과가 생기는 것은 아니므로 현재 React Compiler 사용 여부부터 확인할 필요가 있다.
원문에서 제시한 Vite 적용 예시는 @vitejs/plugin-react의 ^6.1.0 버전과 oxc-transform-react 패키지를 설치하고, React 플러그인 설정에 compiler: true를 지정하는 방식이다. 실제 적용에서는 프로젝트에 설치된 Vite와 플러그인 버전, 기존 Babel 설정, 다른 변환 플러그인과의 조합을 먼저 살펴야 한다.
검증 대상으로는 자주 수정하는 React 화면이 적합하다. 컴파일 시간과 함께 개발 서버의 오류 표시, 프로덕션 빌드 성공 여부, 주요 사용자 동작을 확인한다. 컴파일 단계가 빨라졌더라도 필요한 변환이 빠지거나 동작이 달라지면 전환의 이점이 줄어든다. 설정과 잠금 파일의 변경 범위를 작게 유지하면 문제가 생겼을 때 원인을 좁히기 쉽다.
Vitest 5는 실행 시간과 테스트 신뢰성을 함께 본다
Vitest 5의 속도 개선에는 프로젝트 사이의 변환 파일 공유, 디스크에 모듈을 저장하는 캐시, 메인 프로세스와 워커 사이의 전송량 감소가 포함된다. 여러 프로젝트를 묶어 테스트하거나 같은 모듈을 반복해서 다루는 저장소라면 이러한 변경이 자신의 테스트 구성과 맞는지 살펴볼 만하다.
함께 소개된 vitest doctor는 설정, 가져오기, 변환, 테스트 실행에 걸린 시간을 나누어 보여주고 다른 구성을 시험해 더 빠른 설정을 추천한다. 테스트가 느리다는 인상만으로 워커 수나 실행 옵션을 바꾸기보다, 어느 구간에서 시간이 쓰이는지 확인하는 데 활용할 수 있다.
브라우저 테스트를 다루는 사용자는 Trace View도 확인할 대상이다. 원문에 따르면 브라우저 상호작용, 단언, DOM 스냅샷을 기록해 실패를 재생하거나 HTML 보고서에서 살펴볼 수 있다. 실행 시간을 줄이는 효과와 별개로, 간헐적으로 발생하는 실패의 원인을 찾는 데 도움이 되는지 평가할 수 있다.
업그레이드 후 실패가 늘었다고 해서 곧바로 호환성 문제라고 판단할 필요는 없다. Vitest 5는 기다리지 않은 비동기 단언을 실패로 처리하고, 각 테스트 전에 모의 함수 호출 기록을 초기화하는 변경을 소개했다. 기존에 통과하던 테스트가 비동기 작업을 제대로 기다렸는지, 이전 테스트의 상태에 의존했는지 확인해야 한다. 반복 실행으로 간헐적 실패를 찾는 –repeats 옵션도 함께 검토할 수 있다.
타입 기반 린트는 규칙의 범위를 대조해야 한다
tsgolint는 Oxlint에서 타입 정보를 활용하는 린트 엔진이며, 이번 발표에서 안정화 상태에 도달했다고 밝혔다. 단순한 문법 검사로 찾기 어려운 문제를 TypeScript 타입 데이터로 검사하는 영역이다. 원문은 typescript-eslint의 타입 기반 규칙 61개 가운데 59개를 지원한다고 설명한다.
59개 지원은 기존 린트 설정 전체를 그대로 대체한다는 의미가 아니다. 프로젝트가 사용하는 규칙 중 지원되지 않는 항목이 있는지, 별도 플러그인이나 사용자 정의 규칙이 필요한지 대조해야 한다. 특히 연구용 코드나 오래 유지한 서비스처럼 예외 설정이 쌓인 저장소에서는 규칙 이름뿐 아니라 실제 진단 결과도 비교하는 편이 좋다.
Oxlint는 린트와 타입 검사에 하나의 TypeScript 프로그램을 공유해 같은 프로젝트를 두 번 분석하는 작업을 줄일 수 있다고 설명했다. 원문의 설정 예시는 typeAware와 typeCheck를 함께 활성화한다. 기존 타입 검사 명령을 정리하려면 먼저 프로젝트 참조, 생성 파일, 검사 제외 경로를 포함해 필요한 오류가 계속 발견되는지 확인해야 한다.
전환 판단에는 실행 시간과 진단 차이를 함께 사용한다. 같은 코드에서 기존 도구가 잡던 오류를 새 도구가 놓치는지, 새로 보고하는 오류가 무엇인지 살핀다. 검증이 끝날 때까지 결과를 비교하되, 두 도구를 계속 중복 실행한다면 기대했던 시간 절감이 줄어들 수 있다는 점도 계산에 넣는다.
Oxfmt 전환에서는 파일 변경량이 중요하다
Oxfmt는 Oxc 도구 체인의 성능 개선을 포맷 작업으로 확장한다. Cloudflare는 여러 파일 형식의 포매터를 Rust로 재작성하면서 Prettier와 호환되는 출력과 사용 방식을 유지한다고 설명했다. 원문에는 Prettier 설정을 옮기기 위한 –migrate prettier 명령도 제시돼 있다.
포매터의 효과는 실행 속도만으로 결정되지 않는다. 현재 사용하는 설정과 플러그인, 파일 무시 규칙이 어떻게 반영되는지 확인해야 한다. JSON 설정 파일, 스타일 파일, GraphQL 문서, YAML 설정처럼 저장소에서 자주 바뀌는 파일을 골라 결과를 비교하면 실제 변경 범위를 파악하기 쉽다.
프로젝트 전체를 한 번에 포맷하면 기능 수정과 관계없는 차이가 크게 생길 수 있다. 포맷 변경을 별도 변경 사항으로 검토하고, 편집기 저장 동작과 CI 검사에 같은 도구 및 설정이 적용되는지 맞추는 편이 좋다. 개인 사용자에게도 이 과정은 중요하다. 로컬에서 저장할 때마다 CI와 다른 결과가 만들어지면 빨라진 실행 시간보다 수정에 쓰는 시간이 더 커질 수 있다.
대규모 앱의 Bundled Dev와 통합 도구 Vite+는 구분해서 평가한다
Bundled Dev는 실험 상태의 개발 모드다
Bundled Dev는 과거 Full Bundle Mode로 불렸으며, Vite의 프로덕션 번들러를 개발 중에도 사용하는 방식이다. 발표는 대규모 애플리케이션의 개발 서버 속도 개선과 원격 샌드박스의 네트워크 부담 감소를 기대 효과로 제시했다. Cloudflare 대시보드의 내부 개발자들이 이미 사용한다는 사례도 소개했다.
다만 원문 시점에는 여전히 실험 상태다. 설정 예시도 experimental 아래 bundledDev를 활성화하는 형태다. Cloudflare 내부 사용 사례를 모든 프로젝트의 안정성 보장으로 해석해서는 안 된다. 개발 서버 시작, 첫 화면 요청, 파일 수정 후 반영 시간, 오류 표시, 사용하는 플러그인의 동작을 자신의 앱에서 확인해야 한다.
앱 규모가 작고 현재 개발 서버가 충분히 빠르다면 우선순위가 낮을 수 있다. 반면 모듈 수가 많거나 원격 개발 환경에서 요청 비용을 체감하는 프로젝트는 비교할 이유가 있다. 기존 개발 모드로 쉽게 돌아갈 수 있게 설정 변경을 분리하면 실험의 부담을 줄일 수 있다.
Vite+ 1.0은 도구 선택과 설정을 묶는다
Vite+ 1.0은 Vite 8, Vitest 5, Rolldown, Oxlint, Oxfmt와 작업 캐시를 통합한 도구 체인으로 소개됐다. 개별 도구의 속도뿐 아니라 어떤 도구를 고르고 어떻게 연결할지 결정하는 부담을 줄이는 것이 목표다. 새 학습 프로젝트나 사이드 프로젝트에서는 기본 구성을 빠르게 마련할 수 있는지가 평가 기준이 된다.
기존 저장소에서는 통합 자체보다 이전 비용을 살펴야 한다. 패키지 명령, 편집기 설정, CI 작업, 캐시 설정이 얼마나 바뀌는지 확인한다. 여러 설정이 팀의 실제 요구를 반영하고 있다면 기본값으로 옮기는 과정에서 그 의도가 빠질 수 있다. 통합 도구를 채택하는 선택과 필요한 개별 도구만 먼저 바꾸는 선택을 각각 비교할 수 있다.
AI 에이전트의 반복 검증에도 같은 측정 기준을 쓴다
Cloudflare는 개발 경험의 최적화 대상에 사람뿐 아니라 AI 에이전트도 포함된다고 설명했다. 에이전트가 코드를 수정한 뒤 타입 검사, 린트, 빌드, 테스트 결과를 기다리는 과정에서도 도구의 실행 시간이 병목이 될 수 있다는 관점이다.
이 경우에는 한 번의 테스트 속도보다 작업 완료까지 반복한 검증의 총시간이 더 직접적인 지표다. 같은 수정 과제에서 명령 실행 시간, 재시도 횟수, 최종 통과 여부를 함께 비교할 수 있다. 도구를 바꾸면서 검사를 생략하거나 실패 기준을 느슨하게 했다면 같은 조건의 성능 비교로 보기 어렵다.
도구가 빨라졌다는 사실만으로 에이전트의 결과 품질이나 이용 비용이 일정 비율로 좋아진다고 단정할 수는 없다. 검증 결과를 정확히 읽고 필요한 수정을 하는지까지 관찰해야 한다. 학생과 연구자가 에이전트로 실험용 앱을 만드는 경우에도 완료 시간과 결과의 재현성을 함께 확인하는 것이 유용하다.
프로젝트에 남길 판단 근거는 속도·호환성·유지 비용이다
- 가장 느린 명령을 고른다. 빌드, 타입 검사, 린트, 포맷, 테스트 중 반복 비용이 큰 항목부터 시간을 측정한다.
- 변경 대상을 좁힌다. 관련 도구와 설정을 먼저 바꾸고, 여러 도구를 동시에 교체해 원인을 구분하기 어려운 상황을 피한다.
- 같은 결과를 내는지 확인한다. 테스트 통과 여부뿐 아니라 진단 메시지, 포맷 차이, 빌드 결과와 주요 동작을 비교한다.
- 실제 실행 환경에서 재측정한다. 로컬과 CI, 캐시가 없는 실행과 재실행을 구분하고 프로젝트의 평소 사용 패턴에 맞춰 판단한다.
- 복구에 필요한 변경을 확인한다. 패키지 버전, 잠금 파일, 설정을 함께 검토해 기존 환경으로 돌아가는 경로를 확보한다.
Cloudflare는 Vite, Vitest, Rolldown, Oxc, Vite+를 오픈 소스이자 특정 공급업체에 종속되지 않는 커뮤니티 중심 프로젝트로 유지하겠다는 약속을 재확인했다. 다만 이 설명만으로 개별 패키지의 라이선스 조건, 별도 서비스의 요금, 조직별 사용 정책까지 확정할 수는 없다. 적용할 버전의 문서와 라이선스를 확인하고, 외부 서비스나 연동 기능을 사용한다면 비용과 권한 조건도 따로 살펴야 한다.
이번 발표를 활용하는 방법은 자신의 병목과 연결되는 도구부터 검증하는 것이다. 컴파일이 느리면 React Compiler 경로를, 타입 기반 린트가 오래 걸리면 tsgolint를, 테스트 분석이 필요하면 Vitest 5를 우선 살핀다. 전체 도구 체인의 정리가 필요한 시점이라면 Vite+의 기본 구성과 이전 비용을 함께 비교하는 편이 합리적이다.
출처와 검증
이 글은 2026년 9월 28일 Cloudflare Blog에 공개된 Four months of VoidZero at Cloudflare: making the open-source JavaScript toolchain faster for all humans and agents를 바탕으로 작성했다. 릴리스 수, 이슈 종료 수, 성능 비교와 기능 상태는 해당 발표의 설명을 기준으로 한다.
성능 배수는 Cloudflare가 제시한 비교 결과이며 모든 프로젝트에서 같은 개선을 보장하지 않는다. 실제 적용 시에는 사용하는 버전의 공식 문서에서 호환성과 변경 사항을 확인하고, 특히 실험 상태로 소개된 Bundled Dev는 현재 상태를 다시 확인해야 한다. 가격이나 별도 서비스 정책은 제공된 정보만으로 판단하지 않았다.