100개 이상의 Claude Agent를 병렬로 돌려 테스트를 자동화한 사례 연구

TL;DR Highlight

Imbue 팀이 100개 이상의 Claude agent를 병렬로 오케스트레이션하여 CLI 도구 `mngr`의 end-to-end 테스트를 완전히 자동화하고 AI가 테스트 실행·디버그·수정을 직접 수행하는 프로덕션 아키텍처를 공개했다.

Who Should Read

CLI 도구나 내부 플랫폼의 테스트 자동화를 고민 중인 개발자, 또는 여러 AI agent를 병렬로 오케스트레이션하는 시스템을 설계하려는 백엔드/DevOps 엔지니어.

Core Mechanics

전체 파이프라인은 4단계로 구성된다. tutorial.sh 스크립트의 명령어 블록을 → pytest 함수로 변환하고 → 각 pytest 함수마다 agent를 하나씩 띄워 실행·디버그·수정까지 맡긴 뒤 → 모든 agent의 결과를 하나로 통합한다.
tutorial.sh 작성 자체도 agent를 활용한다. 50개 정도 예시를 직접 쓴 뒤 빈 주석(예: `# Managing snapshots`)만 남기고, coding agent에게 나머지를 채우도록 시킨다. 이미 코드베이스 안에 auto-generate된 man page가 있어서 agent가 꽤 정확하게 예시를 생성한다.
agent가 생성한 예시가 나쁘게 나와도 오히려 유용하다. 인터페이스가 너무 복잡하거나 문서화가 부족하다는 신호로 해석해서, mngr 자체의 인터페이스를 단순하게 다듬는 데 그 신호를 활용했다.
tutorial 블록 1개가 pytest 함수 여러 개로 변환되는 1:N 구조다. 같은 명령이라도 환경이나 입력이 달라지면 결과가 달라지므로, happy path(정상 경로)와 unhappy path(오류 경로)를 별도 테스트로 분리한다.
테스트 함수가 어떤 tutorial 블록에서 파생됐는지 추적 가능하도록, agent에게 해당 블록을 함수 안에 명시적으로 '인용'하도록 요구한다. 그리고 별도 스크립트로 모든 tutorial 블록에 대응하는 pytest 함수가 최소 하나씩 존재하는지 자동 검증한다.
e2e 테스트의 Arrange(준비)·Act(실행)·Assert(검증) 세 단계는 사람이 쓰기도 어렵고 agent도 처음에는 잘 못 쓴다는 걸 처음부터 전제하고 설계했다. 첫 단계에서 완성도를 기대하지 않고, 이후 agent가 직접 실행하며 수정하는 단계에서 품질을 높이는 구조다.
테스트 프레임워크는 Python의 subprocess 모듈 위에 얇은 레이어를 얹은 형태다. CLI 명령 실행 후 stdout, stderr, exit code를 가져오는 기본 구조에, 테스트 함수가 더 간결하고 맥락을 담을 수 있도록 유틸리티를 추가했다.
이 전체 흐름이 `sync-tutorial-to-e2e-tests`라는 슬래시 커맨드 하나로 패키징되어 있다. 사람이 직접 튜토리얼을 쓰고, 나머지 변환·실행·수정은 agent가 병렬로 처리하는 human-in-the-loop 구조다.

Evidence

100개 agent를 병렬로 돌리는 것 자체보다 비용 모델 이해가 더 중요하다는 댓글이 있었다. 실제 코드베이스에서 agent 한 번 실행에 repo 구조·관련 파일·최근 변경 사항 파악만으로 20~50k 토큰이 소모되는데, 100개 agent가 10~20개 repo에서 매시간 돌면 실제 작업 전에 이미 하루 수백만 토큰이 나간다는 구체적인 계산을 제시했다.
병렬 agent의 observability(관측 가능성) 문제를 지적하는 댓글도 있었다. agent 1개면 로그만 봐도 뭐가 잘못됐는지 알 수 있지만, 100개면 집계·패턴 감지·공통 실패 알림이 필요하고, 40개가 같은 단계에서 타임아웃 나면 의존성 문제인지 인프라 포화인지 판단하기가 어렵다는 점을 실무 경험 기반으로 공유했다.
블로그 글이 결국 자사 agent 오케스트레이션 제품인 `mngr`를 팔기 위한 마케팅 피치라는 비판 댓글이 있었다. 기술적 내용은 흥미롭지만 맥락을 감안해서 읽어야 한다는 시각이다.
agent가 tmux 세션 안에서 실행된다는 원문 언급에 대해 '왜 굳이 tmux냐'는 의아함을 표하는 댓글이 있었다. 이는 `mngr`가 내부적으로 tmux를 세션 관리에 활용하는 설계 선택인데, 일반적인 서버 프로세스 관리 방식과 달라서 낯설다는 반응이다.
개인적으로는 Claude Code에서 기능 하나 만들 때도 몇 시간씩 babysit 해야 하는데 '17분마다 프로덕션 배포'같은 글이 나오면 내가 뭔가 잘못하고 있는 건지 혼란스럽다는 솔직한 댓글이 있었고, 이에 공감하는 반응이 많았다. 블로그에 나오는 결과와 실제 현장 경험 사이의 간극이 크다는 공감대가 형성됐다.

How to Apply

CLI 도구의 e2e 테스트를 처음 만들어야 하는데 예시 케이스 작성이 막막한 경우, 핵심 명령어 50개 정도를 직접 쓴 tutorial.sh를 만들고 나머지 빈 주석(예: `# 스냅샷 삭제 시나리오`)은 coding agent에게 채우도록 시키면 초안을 빠르게 확보할 수 있다. 이때 agent가 엉뚱한 예시를 쓰면 인터페이스 개선 신호로 활용하면 된다.
pytest 기반 e2e 테스트를 운영 중인데 어떤 테스트가 어떤 문서/시나리오에 대응하는지 추적이 안 되는 경우, 테스트 함수 안에 원본 tutorial 블록을 명시적으로 인용하는 fixture API를 추가하고 별도 스크립트로 매핑을 검증하면 문서-테스트 동기화를 자동화할 수 있다.
여러 agent를 병렬로 돌리는 시스템을 설계할 때 무조건 동시에 많이 띄우기보다, API rate limit과 예산 범위 안에서 실패 원인을 추적할 수 있는 수준의 동시성을 먼저 정해야 한다. 특히 agent 하나당 context 로딩에만 20~50k 토큰이 들 수 있으니, 배치 작업이라면 하루 토큰 예산을 먼저 역산해서 agent 수와 실행 빈도를 결정하라.
100개 이상 agent를 병렬 운영할 계획이라면 단순 로그 확인으로는 디버깅이 안 되므로, 처음부터 집계 대시보드와 '같은 단계에서 N개 이상 실패 시 알림' 같은 패턴 기반 알림을 설계에 포함시켜야 한다.

Code Example

snippet

# 테스트 프레임워크 예시 (원문에서 발췌)
def test_help_succeeds(e2e: E2eSession) -> None:
    e2e.write_tutorial_block("""
    # or see the other commands--list, destroy, message, connect, push, pull, clone, and more!
    """)
    # subprocess 기반의 얇은 레이어로 CLI 명령을 실행하고
    # stdout, stderr, exit code를 검증하는 구조

# tutorial.sh 블록 예시
# 빈 주석을 남기고 coding agent가 명령어를 채움
# Managing snapshots
mngr snapshot list
mngr snapshot create my-snapshot
mngr snapshot restore my-snapshot

Terminology

e2e 테스트end-to-end 테스트의 약자. 실제 사용자가 쓰는 것처럼 전체 시스템을 처음부터 끝까지 돌려보는 테스트. 단위 테스트(함수 하나)나 통합 테스트(모듈 간)보다 범위가 넓다.

pytestPython에서 가장 널리 쓰이는 테스트 프레임워크. 테스트 함수를 작성하고 한 번에 실행·결과 확인이 가능하다.

fixturepytest에서 테스트 함수가 실행되기 전 공통 환경(DB 연결, 임시 폴더 생성 등)을 준비해주는 설정 코드. 테스트마다 반복 작성을 피할 수 있다.

subprocessPython 표준 라이브러리. 다른 프로그램(CLI 명령 포함)을 코드 안에서 실행하고 결과(stdout, stderr, exit code)를 받아올 수 있다.

tmux터미널 멀티플렉서. 하나의 터미널에서 여러 세션을 만들어 백그라운드로 유지할 수 있는 도구. mngr은 내부적으로 각 agent 실행을 tmux 세션으로 관리한다.

오케스트레이션여러 agent나 프로세스를 조율해서 하나의 목표를 달성하도록 관리하는 것. 어떤 순서로 실행할지, 실패하면 어떻게 재시도할지, 결과를 어떻게 합칠지 등을 총괄하는 역할이다.