CI/CD는 죽었다 — 에이전트 시대의 Continuous Compute와 의도 기반 워크플로우

AI 에이전트가 만드는 코드 변화량 | 기존 CI/CD의 붕괴 지점 | Continuous Compute 아키텍처 | 의도 기반 에이전트 루프 | “준비한다”는 것의 구체적 의미

CI/CD 파이프라인은 인간 개발자의 작업 리듬에 맞춰 설계됐다. 일주일에 한두 개의 diff를 올리고, 동료가 리뷰하고, GitHub Actions가 빌드·테스트·배포를 실행한다. 이 선형 파이프라인은 수십 년간 잘 작동했다.

그러나 Agent Harness — Claude Code, Cursor, Copilot 같은 에이전트 기반 개발 도구 — 가 코드를 생성하기 시작하면서 균열이 생겼다. 에이전트는 수천 개의 짧은 브랜치를 동시에 만들고, 각 브랜치에서 빌드·테스트를 실행하며, 수많은 PR을 병합 대기열에 밀어 넣는다. 인간의 지연 시간 뒤에 숨겨져 있던 CI/CD의 느림이 더 이상 숨겨지지 않는다.

이 글은 CI/CD Is Dead, Agents Need Continuous Compute and Computers 영상(AI Engineer 채널, Hugo Santos & Madison Faulkner, 2026.05.13)의 핵심 내용을 정리한다.

기존 CI/CD가 붕괴하는 지점

CI/CD는 세 가지 전제 위에 서 있다. (1) 변경 사항이 적고, (2) 검증 주기가 느려도 되며, (3) 병합은 순차적으로 일어난다. 에이전트는 이 세 가지 전제를 동시에 깨뜨린다.

변경 사항의 폭발. 최근 몇 달간 GitHub에서 커밋 수와 코드 추가/삭제 라인 수가 비정상적으로 급증했다. Namespace 팀에서도 PR 수가 4배 증가했다고 한다. 에이전트가 만드는 코드 변경의 규모가 인간 중심 시스템의 설계 한계를 넘어선 것이다.

검증 병목. 수천 개의 에이전트가 동시에 PR을 열면, 각각에 대해 빌드·테스트·리뷰를 수행해야 한다. 검증에 유사한 시간이 소요되므로, 에이전트 수가 늘어날수록 대기 시간이 선형적으로 증가한다.

병합 불가능. 수천 개의 짧은 수명 브랜치가 동시에 존재하면, 여러 버전의 코드를 병합하는 것이 사실상 불가능해진다. 병합 과정은 고성능 데이터베이스의 직렬화(serialization) 문제와 유사하다 — 모든 변경 사항이 단일 원장(ledger, 즉 Git 저장소)에 기록되어야 한다. 인간은 잠금 시간이 길지만, 기계는 짧다. 따라서 병합까지 걸리는 시간(time-to-merge)이 핵심 병목이 된다.

핵심 관찰: 문제의 본질은 “CI/CD가 느리다”가 아니라 “CI/CD의 설계 전제가 에이전트 규모와 맞지 않는다”는 것이다. 파이프라인을 튜닝하는 것으로는 한계가 있다.

Continuous Compute — 새로운 아키텍처

영상에서 제시하는 대안은 Continuous Compute(지속적 컴퓨팅)다. CI/CD의 선형 파이프라인을, 에이전트 규모에서 동작하는 컴퓨팅 아키텍처로 교체하는 방향이다.

인테이크(Intake). 수천 개의 에이전트가 동시에 요청을 보내는 환경에서, 입력 트래픽을 조절하고 속도 제한(rate limiting)을 거는 첫 번째 관문이다.

캐시(Cache). 단순한 저장소가 아니라 오케스트레이션 계층이다. 빌드·테스트·배포의 중간 결과를 캐싱하여, 동일한 작업의 반복을 피하고 올바른 인프라로 요청을 라우팅한다.

에이전트 ID(Agentic Identity). 소프트웨어(에이전트)에 대한 식별자를 부여하는 개념이다. 대규모 재시도(retry)를 고려하여, 어떤 에이전트가 어떤 작업을 수행 중인지 추적하고 관리한다.

이 아키텍처의 핵심은 하드웨어와 소프트웨어의 공동 설계(HW/SW co-design)다. Mitchell Hashimoto(HashiCorp 창업자)도 GitHub를 클라우드 시대에 맞게 진화시키고, 대규모 추론(inference)을 지원해야 한다는 의견을 냈다. 기존 CI/CD 인프라 위에 개선 사항을 삽입하는 것으로 시작하되, 궁극적으로는 에이전트 사용자에게 최적화된 시스템으로 전환해야 한다는 방향이다.

PR이 사라진다 — 의도 기반 에이전트 루프

Continuous Compute의 가장 급진적인 주장은 PR(Pull Request)이 사라진다는 것이다. 개발의 시작점이 코드 변경(PR)이 아니라, 달성하고자 하는 의도와 계획(Intent & Plan)이 된다.

에이전트 루프의 작동 방식을 단계별로 정리하면 다음과 같다.

1. 의도 정의: 달성하고자 하는 목표를 명확히 한다. 선형 티켓, Slack 메시지, 문서 등 어디에 기록되든 상관없다.
2. 에이전트 실행: 에이전트가 잘 알려진 커밋(known commit)을 체크아웃하여 시작하고, 계획을 코드로 구현한다.
3. 내부 검증: 에이전트가 직접 빌드하고 테스트한다. 실패하면 수정하고 재시도한다. 이 루프 안에서 유효성 검사가 이루어진다.
4. 외부 검증: 현재는 인간이 피드백을 제공하지만, 미래에는 보안·API 규정 준수를 담당하는 다른 에이전트가 평가한다.
5. Pre-merge 대기열: 작업이 완료되면 직접 Git 저장소에 반영되지 않고, 사전 병합(pre-merge) 대기열에 들어간다.
6. 인간 검토: 인간은 코드 자체가 아닌, 의도와 결과(기능 작동 영상, 보안 에이전트 결과 등)를 검토한다.

여기서 잠깐, 5번 단계를 자세히 보자. 수천 개의 에이전트가 동시에 같은 코드베이스의 여러 부분을 수정하는 상황에서, 완료된 변경 사항을 바로 main에 머지하면 충돌이 필연적으로 발생한다. 여러 사람이 동시에 같은 문서를 수정하다 충돌나는 것과 같은 이치다.

Pre-merge 대기열은 이 충돌을 관리하는 임시 대기 공간이다. 완료됐지만 아직 main에 반영되지 않은 변경 사항들이 모여 있다. 그리고 직렬화(serialization)는 이 대기열에 쌓인 변경 사항들을 순서대로 하나씩 처리하여, 충돌 없이 main에 안전하게 병합하는 과정이다. Git 저장소라는 단일 원장(ledger)에 일관성 있게 기록되도록 보장하는 것이 목표다.

사실 이 개념 자체는 기존 CI/CD의 merge queue(GitHub Merge Queue, Bors 등)와 원리가 같다. 차이는 속도와 통합 방식에 있다. 기존 merge queue는 CI 파이프라인 끝에 있는 별도 단계지만, CC에서는 직렬화가 에이전트 루프 안에서 일어난다. stateful environment 덕분에 재시도가 빠르고, 여러 에이전트의 변경을 의미론적으로 그룹화할 수 있다. 직렬화 병목 자체를 없애는 게 아니라, 병목을 더 빠르게 통과하게 만드는 접근이다.

에이전트 루프에서 또 하나 중요한 개념이 상태 저장 환경(stateful environment)이다. 에이전트가 매번 처음부터 시작하면 지연이 발생한다. 이전 작업의 상태와 메모리를 유지하는 환경이 빠른 루프의 전제 조건이다. 계획이 변경되면 허니스가 의도와 계획을 조정하여 새로운 루프를 생성하는 구조다.

멀티버스 — 병렬 실행의 극단

에이전트 루프가 충분히 빨라지면, 하나의 계획을 해결하기 위해 여러 커밋에서 동시에 작업하는 것이 가능해진다. 영상에서는 이를 멀티버스(Multiverse)라고 부른다.

시작점이 항상 최신 커밋일 필요가 없다. 에이전트는 과거의 여러 커밋에서 각각 작업을 시작하고, 가장 좋은 결과를 선택할 수 있다. 물론 동시에 탐색하는 후보 커밋들이 늘어나면 리소스 사용량도 증가하므로, 불필요한 작업을 피하고 점진적으로 작업하는 것이 중요하다.

CI가 완전히 사라지는 것은 아니다. 역할이 변화한다. 코드 작동 여부 확인은 별도 단계가 아니라 루프의 일부가 되고, 규정 준수를 위한 불변성(invariants)은 지속적으로 강제된다. 조정(coordination)은 CI에서 벗어나 전체 루프의 일부가 되고, 거버넌스(governance)는 허니스(harness)로 이동하여 팀이 정의한 프로세스를 따르도록 강제한다.

”준비한다”는 구체적으로 무엇인가

영상 전체를 관통하는 핵심 질문이 하나 있다. “준비한다”는 것은 수동적 대기가 아니라 시스템의 근본적 재구축을 의미한다. 세 가지 층위로 나뉜다.

1. 문제 인식의 전환. 기존 CI/CD를 “느리다”고 보고 튜닝하는 수준이 아니라, 개발 방식 자체가 근본적으로 달라졌음을 인지하는 것이다. 인간 중심의 PR 단위 작업에서, 에이전트가 수천 개의 짧은 브랜치를 동시에 처리하는 방식으로 패러다임이 바뀌었다.

2. 아키텍처 재구축. 이 글에서 다룬 Continuous Compute 아키텍처를 도입하는 것이다. 의도와 계획 중심의 워크플로우 전환, 캐싱을 오케스트레이션 계층으로 활용, HW/SW 공동 설계, 상태 저장 환경 구축 등이 포함된다.

3. 검증 방식의 변화. 인간 검토자가 모든 PR을 세세하게 검토하는 것은 불가능해진다. 내부 검증(빌드·테스트)은 에이전트가 자동화하고, 외부 검증(보안·컴플라이언스)은 다른 에이전트가 수행한다. 인간은 의도와 결과를 검토하는 역할로 전환한다.

이 세 가지를 종합하면, “준비한다”는 것은 새로운 개발 패러다임에 맞는 시스템 아키텍처, 개발 프로세스, 도구를 도입하거나 재구성하는 적극적인 과정이다. 단순히 “빨라질 것이니 대비하자”가 아니라, 지금 당장 시작해야 하는 구조적 변화다.

정리

이 변화의 방향은 명확하다. 코드 생성 비용이 0에 가까워지고, 에이전트가 인간보다 훨씬 빠르게 코드를 작성하는 시대에, 인간 중심으로 설계된 CI/CD 파이프라인은 한계에 도달할 수밖에 없다.

물론 이 영상의 내용이 당장 모든 팀에 적용되는 것은 아니다. 대부분의 팀은 여전히 인간 중심 개발을 하고 있고, 에이전트 Harness를 본격적으로 도입한 팀은 소수다. 하지만 Namespace, Cursor, Claude Code 등 에이전트 기반 도구를 사용하는 팀에서는 이미 PR 수가 급증하고 있으며, 이 문제는 몇 주에서 몇 달 사이에 현실화될 것이다.

적용 가능한 판단 기준을 정리하면 다음과 같다.

• 에이전트 Harness를 사용 중이고, PR 병목을 체감하고 있다면 — 지금 당장 빌드·테스트 캐싱과 내부 루프 자동화부터 시작할 시점이다
• 에이전트 도입을 계획 중이라면 — PR 중심 워크플로우에서 의도 기반 워크플로우로의 전환을 아키텍처 로드맵에 포함해야 한다
• 당장 에이전트를 사용하지 않는다면 — 이 변화의 방향을 인지하고, CI/CD 개선 시 에이전트 규모를 고려하는 수준으로 준비하면 충분하다