프로그래밍 에이전트가 CI를 병목으로 만들었다. 빌드 파이프라인 가속만으로는 충분하지 않다

프로그래밍 에이전트 사용이 확대되면서 지속적 통합(CI)이 새로운 병목 지점이 되었다. 이러한 결론은 단일 도구의 발표가 아니라, 9월에 Anthropic, Linear, Depot의 엔지니어링 팀들이 소개한 경험에 근거한다. Anthropic의 CI 작업량은 6개월 동안 25배 증가했으며, 엔지니어들은 2021년부터 2025년 사이에 분기별로 배포하던 코드보다 약 8배 많은 코드를 이제 한 분기에 배포하고 있다. Linear에서는 테스트 모음의 규모가 1월 이후 거의 4배에 가까워졌고, 이제 에이전트가 대부분의 테스트를 작성한다.

Anthropic은 테스트 영향 분석을 사용해 변경의 영향을 받을 가능성이 있는 테스트만 실행했고, Linear는 파이프라인을 거의 전면적으로 재설계했다. 이러한 조치는 대기 시간을 줄이지만, 문제의 한 계층인 저장소 검사 속도만 해결한다.

왜 CI 속도만으로는 더 이상 충분하지 않은가?

CI는 역사적으로 인간의 작업 방식에 맞춰 설계되었다. 개발자는 매주 제한된 수의 병합 요청을 열고, 다른 작업으로 이동하는 동안 파이프라인 결과를 기다린다. 반면 에이전트는 코드와 테스트, 병합 요청을 동시에 생성할 수 있어 CI 작업 수를 배수로 늘린다. 이 글은 CI 실행기를 판매하는 기업인 Blacksmith가 실행하는 작업 수에서 주간 5%에서 10% 사이의 성장을 관찰했다고 지적한다.

두 번째 문제는 검증의 위치다. 에이전트는 변경 사항을 작성한 뒤 병합 요청을 생성하고 결과를 기다린다. 결과가 20분 뒤에 도착하면 작업의 맥락을 잃었을 수 있으며, 각각의 문제는 새로운 대기 사이클을 의미한다.

저장소는 시스템이 아니다

독립형 애플리케이션에서는 저장소 테스트가 시스템 동작에 가까운 그림을 제공할 수 있다. 그러나 클라우드 네이티브 환경에서 저장소는 수십 개의 서비스를 포함할 수 있는 시스템의 한 서비스일 뿐이며, 나머지 시스템은 대개 모의 인터페이스나 테스트 데이터로 표현된다.

따라서 어떤 변경이 단위 테스트를 통과하고 CI를 거치며 격리된 환경에서 작동한 뒤, 서비스 경계를 가로지르는 첫 번째 실제 요청에서 실패할 수 있다. 예를 들면 다른 서비스가 의존하는 필드 이름의 변경, 일련의 재시도를 유발하는 시간 제한 축소, 테스트 환경에서 테이블 잠금을 일으키는 스키마 변경, 또는 실제 소비자 서비스가 호출할 때 다르게 동작하는 엔드포인트 등이 있다.

이 글은 DevOps Research and Assessment(DORA)의 데이터를 인용한다. 이 데이터는 인공지능 도입 증가가 소프트웨어 전달 빈도의 증가와 전달 과정의 불안정성을 동시에 연관시킨다고 본다. 즉, 코드를 더 빠르게 생성한다고 해서 더 나은 검증이 보장되는 것은 아니다.

실제로 무엇이 바뀌는가?

제안된 해결책은 CI를 없애거나 에이전트의 속도를 늦추는 것이 아니라, 검증의 일부를 에이전트 작업 루프 안에서 더 이른 시점으로 옮기는 것이다. 이를 통해 변경 사항은 저장소의 복사본만이 아니라 실제 시스템을 대상으로 테스트된다. Cursor와 같은 도구는 격리된 클라우드 환경을 사용하며, Cursor가 병합하는 병합 요청의 30% 이상은 이러한 방식으로 작동하는 에이전트에서 나온다. GitHub Copilot cloud agent, Codex, Devin, Greptile을 비롯한 다른 도구들도 임시 환경에서 코드를 실행하는 다양한 형태를 제공한다.

그러나 이러한 환경에는 일반적으로 브랜치와 그 설정, 그리고 초기화 스크립트가 설치할 수 있는 것만 들어 있으며, 다른 서비스나 실제 메시지 목록, 운영 환경 데이터와 유사한 데이터베이스는 포함되지 않는다. 따라서 이 글은 루프가 닫히기는 하지만 잘못된 대상을 중심으로 닫힐 수 있다고 본다.

공유 환경과 통제된 검증

이 글은 Kubernetes 클러스터 안에서 안정적인 공유 서비스 버전을 실행하고, 변경된 서비스만 배포하는 가벼운 테스트 환경을 생성할 것을 제안한다. 태그가 지정된 요청은 이 서비스로 전달하고, 나머지 경로는 안정적인 공유 버전에 연결한다. 이렇게 하면 각 에이전트마다 시스템 전체를 복제하는 대신 다수의 에이전트가 환경을 공유할 수 있다. 이 글은 환경 비용이 컨테이너 하나의 비용에 가까워질 수 있고 실행에 몇 초가 걸릴 수 있다고 추정하지만, 이러한 추정을 모든 환경에서 입증하는 독립적인 측정값은 출처에 제시되지 않는다.

환경만으로는 충분하지 않다. 플랫폼 팀은 어떤 요청을 보낼지, 어떤 로그를 수집할지, 어떤 계약을 입증해야 할지를 정하는 승인된 절차가 필요하다. 또한 테스트가 접촉한 서비스와 그 결과를 기록해야 검토 도구와 병합 게이트가 읽을 수 있는 기록이 된다. 작성자는 에이전트가 공유 클러스터 안에서 안전하지 않은 작업을 실행하는 것을 방지하려면 거버넌스가 필수적이라고 강조한다.

certi.news의 관점에서 진정한 변화는 단순히 CI를 가속하는 것이 아니라 검증의 «성공»이 무엇을 의미해야 하는지를 다시 정의하는 데 있다. 저장소 테스트는 여전히 중요하지만, 더 빠른 속도로 에이전트가 만들어 내는 분산 시스템에서는 그것만으로 충분하지 않다. 비용, 격리, 데이터 보안, 검증 정확도 측정에 관한 질문은 여전히 열려 있으며, 이 자료는 입증된 표준이나 특정 제품이 아니라 분석적 주장을 제시한다.