주체적 검증에는 다른 인프라가 필요하다
출처: CircleCI 블로그
이전에 저는 에이전트가 작성한 코드를 검증하는 핵심 접근법에 대해 설명했습니다: 피드포워드와 피드백 기법. 피드포워드 기법은 더 나은 프롬프트와 계획 전략을 고안함으로써 오류를 사전에 방지하는 방법입니다. 피드백은 에이전트가 실제로 작업을 완수했음을 알려주는 신호를 제공합니다. 피드백은 Ralph 루프나 Codex·Claude Code의 /goal 명령과 같은 일반적인 에이전트 패턴에서 핵심 요소이며, 알려진 조건이 충족될 때까지 작업을 계속하도록 합니다.
이번 글에서는 에이전트 피드백 루프를 구축할 때 발생하는 문제와 CircleCI에서 효과적이라고 판단한 대안들을 살펴보겠습니다.
검증을 위한 인프라가 병목
검증 체크—리너, 테스트, 혹은 다른 에이전트—는 어디선가 실행되어야 합니다. 개발 단계에서는 보통 엔지니어의 노트북, 원격 VM 혹은 Codespace, 혹은 원격 빌드 시스템에서 이루어집니다. 에이전트가 코드를 작성하도록 할 때도 마찬가지입니다. 하지만 에이전트는 기존 로컬·원격 테스트 방식에 새로운 문제를 만들고, 동시에 에이전트 중심으로 보다 효율적인 테스트·검증 기회를 제공합니다.
첫 번째 단계로 로컬 검증
시작 단계에서는 대부분의 팀이 코딩 에이전트와 동일한 머신에서 검증을 수행합니다. 이 접근법에는 장점이 많습니다. 개발자는 이미 작업 환경을 갖추고 있을 가능성이 높고, 그 환경에서 에이전트를 제어하며 필요 시 IDE로 전환해 직접 코드를 손볼 수 있습니다. 코딩 에이전트는 테스트, 리너, 빌드 명령을 실행하고 오류를 고치는 방법을 스스로 찾아냅니다. 이는 엔지니어가 AI 도입 이전에 하던 일을 실용적으로 확장한 형태라 할 수 있습니다.
하지만 여러 에이전트를 장시간 실행하면 다음과 같은 문제가 나타납니다:
- 하나의 머신에 서비스 인스턴스를 다수 띄우기가 어렵습니다. 충분한 CPU·RAM이 있더라도
localhost에서 전체 스택을 모두 구동하는 것은 고통스러운 작업입니다. - 대규모 검증 스위트(예: Playwright 테스트)는 많은 리소스를 소모해 결국 노트북이 느려집니다.
- 로컬 환경은 엔지니어별 설정·환경 특이점 때문에 “지저분”해집니다. 테스트를 깨끗한 CI 환경에서 실행하는 이유는 “내 머신에서는 동작하지만 검증된 환경에서는 안 된다”는 상황을 없애기 위함입니다.
- 대부분의 팀에서 로컬 검증은 승인 절차에 카운트되지 않습니다. 에이전트가 모든 체크를 통과하더라도 CI 파이프라인이 끝날 때까지 머지 승인을 받을 수 없습니다.
이러한 문제는 해결 가능합니다. 예를 들어 에이전트를 컨테이너 안에서 실행해 재현성을 확보하거나, Vercel의 portless와 같은 도구로 localhost 문제를 완화할 수 있습니다. 하지만 보통 애플리케이션 자체를 수정해야 하고, 개발자마다 동일한 설정을 유지해야 하는 부담이 있습니다.
에이전트와 검증 환경을 같은 머신에 두는 가장 큰 문제는 결합도입니다. 개발자가 에이전트가 실행되는 머신에 완전 접근 권한이 있으면 에이전트가 멈췄을 때 즉시 트러블슈팅할 수 있습니다. 그러나 점점 더 많은 코딩 에이전트가 Devin 같은 자동화·백그라운드 에이전트 시스템을 통해 클라우드 기반으로 실행됩니다. 이 경우 환경 관리가 복잡해집니다. 초기 스크립트나 커스텀 컨테이너로 환경을 맞출 수는 있지만, 결국 에이전트 인프라 제공자가 지원하는 범위에 의존하게 됩니다. 에이전트가 작업을 오래 수행할수록 실패 가능성도 높아집니다. 디스크가 가득 차거나 메모리가 부족해지면, 혹은 에이전트가 실수로 머신을 손상시키면 모든 것이 중단됩니다.
검증 환경을 에이전트가 접근 가능한 도구로 만들고, 완전히 커스터마이징할 수 있게 하면 훨씬 유연합니다. 에이전트와 검증 환경을 독립적으로 교체할 수 있고, 에이전트가 환경을 넘겨받아 작업을 이어갈 수도 있습니다. 예시로는 Claude’s Managed Agent 설계나 Deepagents 플러그형 샌드박스가 있습니다.
CI를 피드백 소스로 활용하기
이 시점에서 많은 팀이 이미 원격·확장·재현 가능한 환경을 보유하고 있다는 사실을 깨닫습니다: 바로 CI 파이프라인입니다. CI를 통과해야 한다면, 에이전트가 CI에 푸시하고 CI 피드백을 기반으로 루프를 돌리는 것이 자연스럽습니다. Codex와 Claude Code는 PR을 CI가 통과할 때까지 감시하고, 리뷰어가 만족할 때까지 작업을 이어가는 기능을 제공합니다. CI를 활용하면 다음과 같은 장점이 있습니다:
- 애플리케이션 인스턴스 수에 제한받지 않음
- 어떤 체크가 실행될지 정확히 알 수 있음
- 에이전트가 직접 비밀 정보에 접근할 수 없는 보안 장벽이 내장됨
이 접근법은 실제로 작동합니다! 하지만 로컬 검증과 마찬가지로 단점도 존재합니다. 첫째, CI 파이프라인은 시작 오버헤드가 있습니다. “깨끗한” 환경이라면 매번 처음부터 시작해야 하죠. 둘째, 많은 CI 파이프라인은 에이전트가 필요로 하는 것보다 더 많은 검증을 수행합니다. CI는 조직 전체의 게이트 역할을 하므로 CVE 스캔, 문서 생성, 성능 테스트 등 다양한 체크가 포함됩니다. 이러한 체크는 실제 변경된 코드와 무관하게 매번 실행됩니다. 즉, 자동화의 목적은 일관성을 확보해 메인 브랜치를 깨뜨리지 않게 하는 것이지만, 진행 중인 개발 단계에서는 과도한 검증이 될 수 있습니다.
셋째, 대부분의 CI 파이프라인은 희귀한 오류를 잡기 위해 설계되었습니다. 일반적인 CI 설정은 빌드 단계를 병렬로 퍼뜨려 실행합니다. CircleCI를 포함한 대부분의 CI 시스템은 하나의 잡이 실패해도 다른 잡을 중단하지 않으며, 모든 피드백을 수집해 개발자가 전체 빌드를 고칠 수 있게 합니다. 이는 린팅 오류가 테스트 실패를 가릴 수 없게 하기 위함이죠. 개발자는 로컬에서 테스트를 충분히 수행했다고 가정하고, 대부분의 경우 빌드가 통과한다는 전제하에 전체 빌드 시간을 단축합니다. 하지만 실제 개발 과정에서는 테스트가 깨지거나 린터 오류가 발생하거나 CI에서 빌드가 실패하는 상황이 빈번합니다. CI를 피드백 소스로 삼으면 실패가 많이 발생하고, 파이프라인이 아직 실행 중이기 때문에 피드백을 받는 데 시간이 걸립니다.
다음으로는 피드백을 에이전트에 전달하는 문제가 있습니다. CI 시스템이 빌드 출력을 제공할 수는 있지만, 직접적인 명령어 출력처럼 바로 전달되지 않습니다. 보통 API를 통해 로그를 재조합하고 문제를 진단해야 하며, 이 과정에서 필요한 정보를 모으기 위해 토큰을 소모하게 됩니다.
마지막으로 비용 문제가 있습니다. 에이전트가 반복적으로 작업하면 CI 사용량이 급증해 비용이 크게 늘어날 수 있습니다.
로컬 개발과 마찬가지로 CI 프로세스를 수정해 개발 루프에 맞게 최적화할 수 있습니다. 캐싱을 활용해 의존성 설치 시간을 줄이고, 빌드 시스템이 지원한다면 증분 빌드를 활용하세요. 높은 병렬성을 억제하려면, 체크를 순차적으로 혹은 단일 잡으로 실행하는 “보수적인” 파이프라인을 별도로 만들 수 있습니다. 이러한 “dev” 파이프라인은 에이전트에게 하나의 파일로 결과를 제공해 토큰 소모를 줄여줍니다. 다만, 원래 목적이 아니던 CI 파이프라인에 기능을 억지로 끼워넣는 것이므로, 트리거 설정에 신중을 기해야 합니다. 예를 들어 전체 파이프라인이 불필요하게 실행되지 않도록 해야 합니다.
Chunk 사이드카 + 마이크로빌드 등장
당신이 진정 원하고 있는 것은 양쪽의 장점을 모두 갖춘 환경입니다: 원격 테스트 환경, 에이전트 친화적인 피드백, 그리고 특정 체크가 이미 수행됐음을 증명할 수 있는 방법. 그리고 CI 비용이 폭증하지 않아야 합니다.
[Chunk 사이드카](https://ci