작은 수정에도 모든 테스트가 다시 도는 이유
모노레포에서 웹 화면의 문구 한 줄을 고쳤는데 서버 패키지의 테스트와 공통 라이브러리 빌드까지 처음부터 다시 도는 일이 있다. GitHub에 푸시할 때마다 동일한 명령 목록을 실행하는 CI라면 변경된 파일과 관계없는 작업에도 실행 시간을 쓴다. 코딩 에이전트가 여러 브랜치에 PR을 빠르게 만들수록 대기열과 반복 실행이 더 눈에 띈다.
Vercel이 2026년 10월 28일 공개 베타로 발표한 Vercel CI는 이 문제를 작업 단위에서 줄이려는 서비스다. Turborepo가 파악한 패키지 간 의존 관계와 작업 입력을 바탕으로, 이번 변경 때문에 다시 실행해야 할 작업을 계산한다. 이미 캐시에 결과가 있는 작업은 복원하거나 건너뛰고 남은 작업만 실행한다.
여기서 '변경된 코드의 테스트만'이라는 말은 수정한 파일 하나에 연결된 테스트 함수만 정밀 선택한다는 뜻이 아니다. 현재 기준은 Turborepo의 패키지와 task 그래프다. 예를 들어 공통 라이브러리가 바뀌면 이를 사용하는 웹과 API 패키지의 관련 작업이 다시 실행될 수 있다. 반대로 독립된 문서 패키지의 변경은 다른 패키지의 테스트를 건너뛸 여지가 있다.
공식 발표는 Vercel 내부 저장소에서 git push부터 CI 통과까지 걸린 시간이 기존보다 2~6배 짧아졌다고 소개한다. 이 수치는 공급자가 자기 환경에서 측정한 결과이며, 일반적인 프로젝트의 성능을 보장하지 않는다. 캐시 적중률이 낮거나 대부분의 작업이 하나의 공통 입력에 의존한다면 이점이 작을 수 있다.
이 서비스는 애플리케이션 배포 기능 자체와 구분해서 봐야 한다. Vercel CI는 푸시 후 검사 작업을 실행하고 결과를 GitHub의 검사 상태로 돌려준다. 배포가 필요한 프로젝트에서는 기존 배포 절차와 함께 사용하며, 테스트가 통과했다고 애플리케이션이 자동으로 안전해지는 것은 아니다.
Turborepo의 작업 그래프와 캐시를 어떻게 이용하나
Vercel CI가 실행할 작업의 기준은 저장소의 turbo.json이다. Turborepo는 각 패키지의 lint, test, build 같은 작업과 작업 간 의존 관계를 하나의 그래프로 다룬다. Vercel CI는 이 가운데 tags 배열에 ci가 표시된 작업을 대상으로 변경 영향을 판단한다. 실행 여부를 결정하는 로직을 별도의 GitHub Actions YAML에 중복해서 적을 필요가 없다는 점이 특징이다.
푸시가 들어오면 먼저 저장소와 의존성을 준비하는 단계가 실행된다. 이어 Turborepo가 대상 작업을 추리고 Vercel Remote Cache에서 이미 계산된 결과가 있는지 확인한다. 캐시로 해결되지 않은 작업은 각자 분리된 실행 환경에서 돌고, 다른 작업의 결과가 필요한 경우에는 그 작업이 끝난 뒤 시작한다. 공식 문서는 Remote Cache가 별도 설정 없이 켜진다고 설명한다.
예를 들어 웹 앱의 test 작업이 공통 패키지 build에 의존하도록 dependsOn을 설정했다면, 테스트보다 공통 패키지 빌드가 먼저 끝나야 한다. 공통 패키지가 바뀌지 않았고 유효한 캐시가 있으면 이전 결과를 재사용할 수 있다. 하지만 빌드 입력이나 환경 변수를 잘못 선언하면 캐시가 최신 코드와 맞지 않을 위험이 있다. 캐시를 쓰는 CI일수록 입력 정의를 점검해야 하는 이유다.
작업에 ci 태그를 붙였다고 모든 패키지의 모든 작업이 무조건 실행되는 것도 아니다. 공식 설정 문서는 패키지별 turbo.json에서 ci 태그를 재정의하거나 !ci로 작업을 제외하는 방법을 안내한다. 다만 !ci를 붙인 작업이라도 다른 CI 작업의 필수 의존성이라면 먼저 실행될 수 있다. 이 차이를 모르면 제외했다고 생각한 작업이 계속 실행되는 상황을 만날 수 있다.
Vercel은 작업마다 독립된 컴퓨팅 자원을 할당한다. 기본 작업 환경은 CPU 2개와 메모리 4GB이고, 설치 준비 단계는 기본 CPU 4개와 메모리 8GB다. 테스트가 무겁다면 ci:cpus:8 같은 태그로 작업 자원을 조정할 수 있지만, 더 많은 CPU를 선택하면 같은 실행 시간에도 청구되는 CPU 분이 늘어난다.
기존 저장소에 연결하는 순서
공식 문서에 따르면 시작 전 Turborepo 2.11.7 이상과 Vercel CLI 64.3.1 이상이 필요하다. 저장소는 GitHub에 있어야 하고, 같은 저장소가 Vercel 팀의 프로젝트 하나 이상과 연결돼 있어야 한다. 여러 Vercel 팀에 걸쳐 프로젝트가 연결된 저장소는 현재 지원 대상이 아니다. GitLab이나 Bitbucket을 사용하는 팀이라면 베타 기능을 바로 옮겨 쓸 수 없다.
먼저 현재 package.json에 lint나 test 같은 실제 스크립트가 있는지 확인하고 turbo.json에서 해당 작업을 정의한다. 아래 예시는 test를 CI 대상으로 표시하는 최소 구조다. 저장소의 패키지별 명령과 의존성은 프로젝트마다 다르므로 이 설정만 복사하면 테스트가 저절로 생기는 것은 아니다. 실행할 스크립트가 없다면 먼저 패키지 쪽에서 만들어야 한다.
그다음 GitHub 저장소를 Vercel 프로젝트에 연결한 뒤 로컬 복제본에서 vercel ci enable을 실행한다. 이 명령은 Vercel CI를 명시적으로 활성화하는 단계다. 단순히 turbo.json에 태그를 적었다고 서비스가 바로 시작되지는 않는다. 설정을 검토하고 변경을 커밋해 GitHub에 푸시하면 베타가 지원하는 트리거를 통해 검사가 시작된다.
설정을 직접 작성하기 어렵다면 Vercel이 공개한 설정용 에이전트 스킬도 있다. 공식 안내의 npx skills use vercel/ci@setup 명령을 코딩 에이전트에게 실행하도록 요청하면 초기 작업을 선택하고 설정을 만든 뒤 PR을 여는 흐름을 안내한다. 다만 외부 스킬은 설치 전 내용을 확인하고, 자동 생성된 PR의 권한과 설정을 검토한 다음 병합해야 한다. 이 글에서는 스킬 설치나 실제 Vercel 프로젝트 연결을 실행하지 않았다.
실행이 시작되면 Vercel 대시보드의 CI 탭과 CLI, MCP에서 작업별 상태와 로그를 확인할 수 있다. 발표 글은 vc ci ls, vc ci inspect, vc ci logs 같은 조회 명령을 소개한다. GitHub PR의 검사 상태에도 결과가 표시되므로 기존 브랜치 보호 규칙에서 실패한 CI를 병합 차단 조건으로 사용할 수 있다. 이전 CI를 바로 삭제하기보다 같은 변경을 양쪽에서 비교한 뒤 전환하는 편이 안전하다.
{
"tasks": {
"test": {
"tags": ["ci"]
}
}
}테스트 환경 변수와 의존성은 따로 확인해야 한다
로컬에서는 통과하는 테스트가 CI에서 실패하는 흔한 이유 중 하나는 환경 변수다. Vercel CI는 Turborepo를 이용해 각 작업을 실행하는데, Turborepo의 기본 Strict Mode에서는 turbo.json에 명시하지 않은 환경 변수를 작업에 전달하지 않는다. 대시보드에 값을 등록해도 테스트 스크립트가 이를 읽도록 작업 설정을 하지 않았다면 값이 보이지 않을 수 있다.
공식 환경 변수 문서는 작업의 env 배열에 API_TOKEN 같은 이름을 선언하는 방법을 안내한다. env에 넣은 값은 작업 해시에도 영향을 주므로 값이 바뀌면 캐시가 무효화된다. 반면 passThroughEnv는 값을 전달하지만 작업 해시에는 포함하지 않는다. 결과에 영향을 주는 값을 무심코 passThroughEnv로만 넘기면 캐시 재사용 판단이 부정확해질 수 있다.
비밀값은 Vercel의 저장소별 CI 환경 변수에 Secret으로 저장하고 코드에 직접 넣지 않는 것이 기본이다. 팀에서 여러 저장소가 같은 값을 써야 한다면 Shared Environment Variables를 연결하는 방식도 있다. vercel.json의 상수 설정은 저장소에 커밋되는 파일이므로 비밀키를 적는 장소가 아니다. CI 설정을 에이전트에게 맡겼더라도 이 구분은 사람이 확인해야 한다.
설치 단계도 작업 실행 단계와 분리된다. 공식 설정 문서에 따르면 의존성 설치를 대체하는 installCommand를 지정하면 기본 설치가 자동으로 이어지지 않으므로 명령 안에서 직접 의존성을 설치해야 한다. 또 설치 과정에서 저장소 디렉터리 밖에 놓은 파일은 이후 개별 작업 환경에 전달되지 않는다. 로컬 컴퓨터의 전역 도구를 그대로 기대하는 설정은 실패할 수 있다.
현재 Vercel CI의 기본 실행 이미지는 Linux다. 운영체제별 테스트가 필요한 프로젝트라면 Windows와 macOS 검사를 별도의 CI에 남겨야 한다. 브라우저 기반 E2E 테스트를 배포 환경에 연결하는 기능도 공식 문서에 있지만, 접근 권한과 배포 완료를 기다리는 의존성을 따로 구성해야 한다. 서비스가 변경된 작업을 골라 준다고 테스트 환경의 차이까지 자동으로 없애 주지는 않는다.
무료 베타라는 표현보다 CPU 분당 비용을 먼저 봐야 한다
Vercel의 10월 28일 발표 글은 베타를 모든 플랜에서 이용할 수 있다고 소개한다. 그런데 같은 날 갱신된 공식 CI 요금 문서는 Pro의 CPU 분당 0.0035달러와 Enterprise의 별도 견적만 제시하고 Hobby 항목은 표시하지 않는다. 따라서 Hobby에서 어떤 조건으로 이용할 수 있는지, 무료 할당량이 있는지는 이 두 자료만으로 확정할 수 없다. 실제 활성화 전에 계정 대시보드의 이용 가능 여부와 청구 조건을 확인해야 한다.
요금 문서가 설명하는 계산 단위는 CPU minute이다. 작업이 CPU 8개를 배정받아 2분 30초 실행되면 8 × 2.5로 CPU 분 20개를 사용한다. Pro에 명시된 단가만 적용하면 20 × 0.0035달러로 0.07달러다. 이 값은 해당 작업 하나의 단순 계산 예시일 뿐, 실제 한 번의 전체 CI 실행 비용을 뜻하지 않는다.
전체 실행에는 저장소를 복제하고 의존성을 설치하는 부트스트랩 단계도 포함된다. 기본적으로 CPU 4개가 배정되며, 이후 각 테스트 작업에는 기본 CPU 2개가 배정된다. 요금 문서는 이 단계들도 실행 시간에 따라 CPU 분을 사용한다고 명시한다. 같은 테스트라도 패키지 설치 시간, 병렬 작업 수, 선택한 CPU 수에 따라 전체 비용이 달라진다.
캐시에서 복원하거나 변경 영향이 없어 건너뛴 작업은 CPU 분을 사용하지 않는다. 반대로 매번 바뀌는 입력 때문에 캐시가 무효화되면 예상보다 많은 작업이 실행될 수 있다. 따라서 전환 전에는 기존 CI의 평균 실행 시간만 볼 것이 아니라 변경 유형별 작업 수와 캐시 적중률, 설치 시간, 필요한 CPU 크기를 함께 기록해야 한다.
공식 발표의 2~6배 속도 개선은 비용 절감 보증도 아니다. 더 많은 컴퓨팅을 병렬로 투입하면 대기 시간은 줄어도 CPU 사용량은 늘 수 있다. Vercel CI를 검토하는 팀이라면 빠른 PR 피드백이 필요한지, 실제로 반복되는 무관한 작업이 얼마나 많은지부터 계산하는 편이 좋다. 이미 변경 범위별 작업을 잘 나누고 있는 기존 CI라면 전환 효과가 제한적일 수 있다.
기존 GitHub Actions를 바로 없애지 않아도 된다
Vercel CI가 맞는 팀은 패키지가 여러 개이고 작업 간 의존성이 뚜렷하며, 코드 변경마다 불필요한 검사 실행이 반복되는 팀이다. 특히 Turborepo를 이미 사용하고 있다면 기존 turbo.json에 ci 태그를 추가하는 방식으로 실험을 시작할 수 있다. 단일 패키지 저장소도 지원하지만, 검사 작업이 몇 개 없는 작은 프로젝트에서는 새로운 서비스 연결과 과금 관리가 더 번거로울 수 있다.
기존 GitHub Actions가 이미 필요한 패키지만 선택적으로 실행하고 있다면 Vercel CI가 반드시 더 빠르다고 할 수 없다. 오히려 작업 캐시와 자원 할당 방식이 바뀌면서 처음에는 실행 결과가 달라질 수 있다. 테스트를 옮기기 전에 어떤 파일 변경이 어떤 작업을 실행해야 하는지 목록으로 정리하면, 실제 선택 결과를 검증하기 쉬워진다.
공식 문서상 현재 트리거는 GitHub에 git push를 하는 경우뿐이다. 수동 실행, 일정 실행, 다른 코드 호스팅 서비스까지 모두 대체하는 범용 CI라고 생각하면 안 된다. 리눅스 이외의 운영체제 검사나 별도 배포 승인 절차가 필요하다면 기존 도구를 병행해야 한다. 베타이므로 설정과 지원 범위가 변경될 가능성도 있다.
처음 시험할 때는 실패해도 운영 배포를 막지 않는 린트나 작은 테스트 작업부터 태그를 붙여 보는 방법이 적절하다. 같은 커밋을 기존 CI와 Vercel CI에서 비교하면서 빠진 검사가 없는지, 캐시 복원 결과가 정상인지, 비용이 얼마인지 확인한다. 그다음에야 GitHub 브랜치 보호 규칙의 필수 검사 항목을 변경하는 편이 좋다. 이 절차는 도입 판단을 위한 권장 흐름이며 실제로 검증한 벤치마크 결과는 아니다.
정리하면 이번 발표의 핵심은 AI가 CI를 대신 판단한다는 것이 아니라, 이미 선언된 작업 그래프를 이용해 검사 범위를 줄이고 필요한 자원만 실행한다는 점이다. 공식 문서의 요구 버전과 제한, CPU 단가를 확인한 뒤 자기 저장소의 변경 패턴에 맞춰 시험하는 것이 가장 직접적인 활용법이다. 실제 설정 방법과 변경되는 베타 조건은 아래 공식 문서를 기준으로 다시 확인할 수 있다.