코드 에이전트 오케스트라 — 멀티 에이전트 코딩이 실제로 작동하려면

오늘 O'Reilly AI CodeCon에서 코딩 에이전트 오케스트레이션을 주제로 발표했다. 실제 소프트웨어 개발 워크플로우에서 AI 코딩 에이전트를 조율하는 다양한 패턴을 다뤘는데, 첫 번째 서브에이전트를 생성하는 것부터 품질 게이트를 갖춘 병렬 에이전트 팀 운영까지 폭넓게 소개했다. 이 글은 해당 발표 내용을 실제로 적용해보려는 분들을 위해 정리한 것이다.

인터랙티브 슬라이드 덱을 함께 보거나 관련 자료를 받고 싶다면 아래 링크를 참고하라:

• 전체 인터랙티브 슬라이드 덱
• 개요 및 자료 페이지

지금 이 순간

예전엔 AI 하나와 페어 작업을 했다. 이제는 에이전트 팀을 관리한다.

6개월 전만 해도 대부분의 개발자는 AI 어시스턴트 하나와 긴밀한 동기식 루프로 작업했다. 프롬프트를 입력하고, 기다리고, 결과를 검토하고, 피드백을 주고, 이 과정을 반복했다. 한계는 단일 컨텍스트 창이 담을 수 있는 양이었고, 대화 스레드가 곧 작업 공간이었다.

이 방식은 이미 구시대의 것이 됐다. 지금 가장 높은 생산성을 내는 개발자들은 여러 에이전트를 비동기로 조율하고 있다. 각 에이전트는 저마다의 컨텍스트 창, 파일 범위, 담당 영역을 갖고 동작하며, 개발자는 전체를 내려다보며 오케스트레이터 역할을 맡는다. 코드베이스 자체가 작업 공간이 되는 것이다. 대화 스레드가 아니라. 이는 지휘자(뮤지션 한 명을 실시간으로 이끄는)에서 오케스트레이터(전체 앙상블을 비동기로 조율하는)로의 전환이다. 이 변화의 초기 징후는 에이전트 코딩의 미래에서 다룬 바 있다.

이번 발표는 그 전환을 실제로 어떻게 이뤄낼지를 다뤘다. 패턴, 도구, 품질 게이트, 그리고 이를 잘 실행하기 위한 규율까지.

AI 지원 코딩의 8단계

대부분의 개발자는 3~4단계에 머물러 있다. 오케스트레이션 영역은 6단계부터 시작되며, 5단계까지 올라온 것과는 근본적으로 다른 역량이 필요하다.

Steve Yegge가 최근 개발자가 AI 도구와 함께 성장하는 8단계를 정리했는데, 지금 내가 어디에 있고 어디로 향하는지를 파악하는 데 유용한 프레임워크다.

이번 발표는 5단계부터 8단계까지를 다뤘다. 당신은 지금 이 사다리의 어디쯤 있는가?

전환: 지휘자에서 오케스트레이터로

지휘자 모델은 에이전트 하나를 동기식으로 다루며, 컨텍스트 창이 곧 한계다. 오케스트레이터 모델은 저마다의 컨텍스트 창을 가진 여러 에이전트를 비동기로 운용하면서, 개발자는 계획을 세우고 주기적으로 점검한다.

이 사고방식의 핵심 전환은 페어 프로그래밍과 팀 관리의 차이다. 지휘자 모델에서는 AI 에이전트 하나를 실시간으로 이끈다. 동기식이고 순차적이며, 컨텍스트 창이 절대적인 한계로 작용한다. 이 모델에 적합한 도구로는 Claude Code CLI와 Cursor의 인에디터 에이전트 모드가 있다.

오케스트레이터 모델에서는 전체 앙상블을 조율한다. 저마다의 컨텍스트 창을 가진 여러 에이전트가 비동기로 동작하며, 개발자는 작업을 계획하고 배분한 뒤 주기적으로 확인한다. 이 모델에 적합한 도구로는 Agent Teams, Conductor, Codex, Copilot Coding Agent 등이 있다.

실제 팀을 관리하는 것과 마찬가지로, 이제는 다른 역량이 필요하다. 직접 코드를 작성하는 대신 명확한 스펙 작성, 작업 분해, 결과물 검증이 핵심이 된다.

단일 에이전트의 한계

단일 에이전트를 쓰다 보면 결국 세 가지 벽에 부딪힌다. 컨텍스트 과부하, 전문화 부재, 조율 불가. 서브에이전트는 처음 두 가지를 해결하고, 에이전트 팀은 세 가지 모두를 해결한다.

에이전트 하나로는 왜 모든 것을 처리할 수 없을까? 세 가지 제약이 있다.

컨텍스트 과부하. 에이전트 하나가 담을 수 있는 정보에는 한계가 있다. 대규모 코드베이스는 단일 컨텍스트 창을 압도하고, 대화가 길어질수록 중요한 정보가 빠져나간다.

전문화 부재. 데이터 레이어, API, UI, 테스트까지 모든 것을 혼자 처리하는 에이전트는 두루두루 알지만 깊이가 없다. 데이터 레이어만 전담하는 에이전트는 전체 코드베이스를 동시에 다루는 제너럴리스트보다 훨씬 나은 데이터베이스 코드를 작성한다.

조율 불가. 서브에이전트를 여러 개 생성하더라도 서로 소통하거나, 작업 목록을 공유하거나, 의존성을 해결할 방법이 없다. 조율 수단 없이 에이전트를 늘릴수록 관리는 오히려 복잡해진다.

왜 멀티 에이전트인가?

병렬성, 전문화, 격리, 누적 학습은 단순히 더해지는 게 아니라 곱해진다. 집중된 에이전트 세 개는 같은 시간을 세 배로 쓰는 제너럴리스트 에이전트 하나를 꾸준히 앞선다.

멀티 에이전트로 가야 할 네 가지 복합적인 이유:

• 병렬성 (처리량 3배) - 에이전트 세 개가 프론트엔드, 백엔드, 테스트를 동시에 구축한다.
• 전문화 (집중된 컨텍스트) - 각 에이전트는 자신이 담당하는 파일만 본다. db.js만 아는 에이전트는 전체 코드베이스를 다루는 에이전트보다 훨씬 나은 데이터베이스 코드를 작성한다.
• 격리 (안전한 실행) - Git 워크트리를 활용하면 각 에이전트가 자신만의 작업 디렉터리를 갖는다. 작업 중 머지 충돌이 발생하지 않는다.
• 누적 학습 - AGENTS.md 파일에 세션을 거치며 발견한 패턴과 주의사항이 쌓이면, 매 세션이 다음 세션을 더 낫게 만든다.

패턴 1: 서브에이전트 — 집중된 위임

서브에이전트는 가장 단순한 멀티 에이전트 패턴이자, 처음으로 시도해볼 패턴이다.

서브에이전트는 Task 도구를 사용해 부모 오케스트레이터에서 전문화된 자식 에이전트를 생성한다. 부모는 작업을 조각으로 분해하고, 각 조각마다 서브에이전트를 생성한 뒤, 의존성 그래프를 직접 관리한다.

구체적인 예를 들어보자. Claude Code에 이런 프롬프트를 입력한다. "Express와 SQLite를 사용해 Link Shelf라는 북마크 관리자를 만들어라." 부모 오케스트레이터는 이를 서브에이전트 세 개의 브리프로 분해한다.

1. 데이터 레이어 서브에이전트 - 스키마와 CRUD 작업이 포함된 db.js를 구축하고, 완료 시 DATA.md 보고서를 작성
2. 비즈니스 로직 서브에이전트 - 입력 규칙이 포함된 validation.js를 구축하고, 완료 시 LOGIC.md 보고서를 작성
3. API 라우트 서브에이전트 - DATA.md와 LOGIC.md을 모두 읽고, Express 라우트가 포함된 server.js를 구축

처음 두 서브에이전트는 독립적이어서 병렬로 실행된다. 세 번째는 앞선 둘에 의존하므로, 보고서 파일이 준비될 때까지 대기한다. 부모가 이 의존성 그래프를 직접 관리한다.

데모 1: 서브에이전트가 Link Shelf를 구축하다

부모가 프롬프트를 분해하고, 데이터와 유효성 검사 서브에이전트를 병렬로 생성한 뒤, 두 보고서가 모두 준비되면 API 라우트를 구동하는 과정을 확인할 수 있다. 마지막에는 테스트가 통과된다.

서브에이전트가 해결하는 것: 에이전트별 컨텍스트 격리, 전문화, 독립 작업의 병렬 실행. 비용 면에서는 총 약 22만 토큰으로 중립적이다.

아직 남아있는 문제: 부모가 의존성 그래프를 직접 관리해야 한다. 에이전트 간 직접 메시지를 주고받을 수 없다. 공유 작업 목록이 없다. 파일 범위를 꼼꼼히 지정하지 않으면 두 에이전트가 같은 파일에 쓸 수도 있다.

정리하자면, 서브에이전트는 수동 조율을 전제로 병렬 실행을 제공한다. 단순한 작업 분해에는 충분하다. 하지만 조율 자체가 병목이 된다면 에이전트 팀이 필요하다.

프로 팁: 계층적 서브에이전트 — 팀의 팀

위임을 한 단계에서 멈추지 마라. 피처 리드를 생성하고, 그 리드가 각자의 전문가를 또 생성하게 하라. 누구의 컨텍스트 창도 폭발시키지 않으면서 3배 더 깊은 분해가 가능하다.

오케스트레이터가 서브에이전트 여섯 개를 직접 생성하면 컨텍스트가 분산된다. 대신 피처 리드 두 명을 생성하고, 각 리드가 자신만의 전문가 두세 명을 생성하게 하라.

부모 오케스트레이터는 에이전트 두 개하고만 대화하니 컨텍스트를 깔끔하게 유지할 수 있다. 피처 리드 A는 "검색 기능을 구축하라"는 브리프를 받고, 스스로 데이터, 로직, API 서브에이전트로 분해한다. 부모는 그 세부 사항을 볼 필요가 없다.

이는 실제 엔지니어링 조직의 작동 방식과 닮아 있다. 엔지니어링 부사장이 개별 엔지니어에게 직접 작업을 배분하지 않는다. 테크 리드 계층을 통해 내려간다.

패턴 2: 에이전트 팀 — 진정한 병렬 실행

에이전트 팀은 서브에이전트에 없는 조율 수단을 추가한다. 의존성 추적이 가능한 공유 작업 목록, 팀원 간 P2P 메시지, 충돌 방지를 위한 파일 잠금이 그것이다.

에이전트 팀은 진정한 병렬 실행을 위한 Claude Code의 실험적 기능이다. 아래 명령어로 활성화할 수 있다:

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

아키텍처는 세 계층으로 구성된다:

1. 팀 리드 (최상단) - 작업을 분해하고, 작업 목록을 생성하며, 결과를 종합한다
2. 공유 작업 목록 (중간) - 상태(pending, in_progress, completed, blocked)가 있는 작업들, 의존성 추적, 파일 잠금
3. 팀원들 (하단) - 각자 독립적인 Claude Code 인스턴스로, 저마다의 컨텍스트 창을 갖고 tmux 분할 창에서 실행

팀원들은 공유 목록에서 작업을 자율적으로 가져간다. 리드를 거치지 않고 서로 직접 메시지를 주고받는다. 팀원이 작업을 완료로 표시하면, 해당 작업에 의존하던 막힌 작업들이 자동으로 해제된다. 언제든 Ctrl+T을 누르면 작업 목록의 시각적 오버레이를 토글할 수 있다.

데모 2: 에이전트 팀이 검색 기능을 병렬로 구축하다

이것이 핵심 데모다. 작동하는 Link Shelf 앱에서 시작해, Claude Code에 프롬프트 하나를 입력한다. "세 명짜리 에이전트 팀을 만들어 검색 기능을 추가하라." 리드는 백엔드, 프론트엔드, 테스트 팀원을 생성한다. 백엔드 팀원은 검색 API 엔드포인트 작업을 시작하고, 프론트엔드 팀원은 검색 UI 작업을 시작한다. 테스트 팀원은 처음에는 API를 기다리며 대기 상태다. 백엔드가 완료되고 API 계약을 프론트엔드에 메시지로 전달하면, 테스트 작업이 자동으로 해제된다. 세 명이 동시에 작업한다.

데모 3: 에이전트 팀 소통을 가까이서 보다

이 짧은 데모는 소통 메커니즘을 집중적으로 보여준다. Ctrl+T 작업 목록 오버레이, 백엔드가 API 엔드포인트를 완료로 표시했을 때 의존성이 자동으로 해제되는 모습, 그리고 백엔드 에이전트가 리드를 거치지 않고 프론트엔드 에이전트에게 API 계약을 직접 전달하는 P2P 메시지를 확인하라.

에이전트 팀: 메커니즘의 작동 원리

에이전트 팀을 작동하게 하는 두 가지 메커니즘이 있다. 자동 의존성 해결이 가능한 공유 작업 목록, 그리고 리드가 병목이 되지 않도록 하는 P2P 메시지다.

공유 작업 목록은 각 작업에 상태를 부여한다. pending, in_progress, completed, blocked. 막힌 작업에는 명시적인 의존성이 있다. 백엔드 팀원이 검색 API를 completed로 표시하면, 막혀 있던 테스트 작성 작업이 자동으로 pending으로 바뀌고 팀원 한 명이 이를 가져간다. 파일 잠금은 두 팀원이 같은 파일을 동시에 수정하는 것을 막는다.

P2P 메시지도 핵심이다. 백엔드 에이전트가 프론트엔드 에이전트에게 API 계약을 직접 전달한다. "GET /search?q= 는 [{id,title,url}]을 반환합니다." 이 메시지는 리드를 거치지 않는다. 팀원이 유휴 상태가 되면 리드에게 자동으로 알림이 간다. 이 P2P 방식 덕분에 리드가 조율의 병목이 되지 않는다.

에이전트 팀: 핵심 정리

팀원은 3~5명이 최적이다. 토큰 비용은 팀 크기에 비례해 선형으로 증가하며, 집중된 팀원 세 명이 분산된 팀원 다섯 명보다 꾸준히 나은 성과를 낸다.

• 조율이 있는 진정한 병렬성 - 단순히 동시에 실행하는 것이 아니다. 의존성 추적이 가능한 공유 작업 목록 덕분에 작업이 올바른 순서로 처리된다.
• P2P 메시지로 병목 방지 - 팀원들이 직접 소통한다. 백엔드가 리드를 거치지 않고 프론트엔드에게 API 계약을 전달한다.
• 위험한 작업에 대한 계획 승인 - 팀원이 구현 전에 계획을 작성하도록 요구하라. 리드가 검토한 뒤 승인 또는 거절함으로써, 코드가 존재하기 전에 아키텍처 문제를 잡아낼 수 있다.
• 적정 팀 규모 유지 - 팀원 3~5명이 최적이다. 토큰 비용은 팀 크기에 비례해 선형으로 증가한다.

에이전트 팀 프로 팁: 안정성

루프 가드레일과 강제 반성 단계를 도입하면 멈춰버리는 에이전트가 크게 줄어든다. 모든 작업 완료 시 자동으로 트리거되는 전담 @reviewer 팀원을 두면, 리드는 항상 리뷰를 통과한 코드만 받는다.

루프 가드레일 + 반성 단계. 모든 팀원에게 엄격한 MAX_ITERATIONS=8을 설정하라. 재시도 전마다 반성 프롬프트를 강제로 실행한다:

"무엇이 실패했는가? 이를 고칠 구체적인 변경 사항은 무엇인가? 같은 방식을 반복하고 있지는 않은가?"

이 변화 하나만으로 멈춰버리는 에이전트가 크게 줄어든다. 없으면 에이전트는 같은 방식을 무한히 반복한다. 있으면 스스로 수정한다.

전담 @reviewer 팀원. 아래 제약 조건으로 영구 리뷰어를 생성하라:

• 모델: Claude Opus 4.6 (읽기 전용)
• 도구: lint, 테스트, 보안 스캔만
• 트리거: 모든 TaskCompleted 이벤트 시 자동 실행
• 비율: 빌더 3~4명당 리뷰어 1명

리드는 리뷰를 통과한 코드만 받는다. 팀 자체에 영구적인 CI 품질 게이트를 내장한 것과 같다.

패턴 3: 대규모 오케스트레이션

에이전트를 5개, 10개, 혹은 20개 이상으로 여러 저장소와 피처에 걸쳐 관리해야 할 때는 목적에 맞게 설계된 오케스트레이션 도구가 필요하다. 2026년의 모든 도구는 세 개의 티어 중 하나에 해당하므로, 상황에 맞는 티어를 선택하면 된다.

2026년 도구 생태계는 세 가지 티어로 나뉜다:

티어 1: 인프로세스 서브에이전트와 팀

Claude Code 서브에이전트와 에이전트 팀. 단일 터미널 세션, 별도 도구 불필요. 여기서 시작하라.

티어 2: 로컬 오케스트레이터

내 컴퓨터에서 격리된 워크트리에 여러 에이전트를 생성한다. 대시보드, diff 리뷰, 머지 제어로 루프 안에 머문다. 잘 아는 코드베이스에서 에이전트 3~10개를 운용할 때 최적이다. Conductor, Vibe Kanban, Gastown, OpenClaw + Antfarm, Claude Squad, Antigravity, Cursor Background Agents 등이 있다.

티어 3: 클라우드 비동기 에이전트

작업을 배분하고 노트북을 닫으면, 돌아올 때 풀 리퀘스트가 준비돼 있다. 에이전트가 클라우드 VM에서 실행되므로 터미널도 로컬 설정도 필요 없다. Claude Code Web, GitHub Copilot Coding Agent, Jules by Google, Codex Web by OpenAI 등이 있다.

2026년의 대부분의 개발자는 세 가지 티어를 모두 활용할 것이다. 티어 1은 인터랙티브 작업에, 티어 2는 병렬 스프린트에, 티어 3은 밤새 백로그를 소화하는 데 쓸 것이다.

도구 소개

Conductor by Melty Labs

Conductor는 Mac에서 멀티 에이전트 오케스트레이션을 시작하는 가장 빠른 방법이다. 각각의 git 워크트리에서 Claude Code와 Codex 에이전트를 병렬로 실행하며, 시각적 대시보드와 diff 중심의 리뷰 UI를 제공한다. 무료로 사용할 수 있으며, API 비용만 부담하면 된다. 현재는 macOS(Apple Silicon 및 Intel)만 지원한다. 시각적 모니터링이 필요한 상황에서 동일 저장소에 피처 3~8개를 병렬로 작업할 때 가장 빛을 발한다.

Claude Code 웹

claude.ai/code의 Claude Code 웹은 티어 3 버전으로, 완전히 브라우저 기반이어서 터미널이 필요 없다. GitHub 저장소를 연결하고 작업을 설명하면 Anthropic이 관리하는 클라우드 VM에서 실행된다. 실행 중에 방향을 조정하거나, PR을 자동으로 생성하게 할 수 있으며, iOS 앱에서도 접근 가능하다. 핵심 차이를 정리하면 이렇다. 팀(터미널)은 에이전트와 함께 작업하는 방식이고, 웹(브라우저)은 위임하고 자리를 떠나는 방식이다.

GitHub Copilot 코딩 에이전트

중요한 구분이 있다. IDE의 Copilot 에이전트 모드는 동기식이고 인터랙티브하다. GitHub의 Copilot 코딩 에이전트는 완전한 비동기 방식이다. GitHub 이슈를 @copilot에 배분하거나 Agents 패널을 통해 실행하면, GitHub Actions 환경에서 작업한 뒤 드래프트 PR을 생성한다. 이제는 당신에게 태그하기 전에 자체 리뷰 루프도 실행한다. Claude Code와 Codex를 포함한 서드파티 에이전트도 같은 Agents 패널을 통해 이용할 수 있으며, Slack, Jira, Linear, Azure Boards에서도 트리거할 수 있다.

Jules by Google

Jules는 Gemini 기반의 Google 비동기 클라우드 코딩 에이전트다. 워크플로우는 이렇다. GitHub 저장소를 연결하고 작업을 설명하면, Jules가 계획을 생성하고 당신이 승인한 뒤에야 코드 작업을 시작한다. 이후 클라우드 VM에서 실행되고, 전체 추론 과정과 터미널 로그가 담긴 PR을 반환한다. 오디오 체인지로그, 작업 중간 개입, GitHub 이슈를 직접 파이핑하는 Jules Tools CLI 같은 차별화된 기능도 있다. 별도 설정 없이 저장소의 AGENTS.md을 자동으로 읽는다.

OpenAI Codex 웹

Codex 웹은 이 분야에서 가장 널리 쓰이는 도구 중 하나다. 각 작업은 GitHub 저장소가 미리 로드된 별도의 샌드박스 컨테이너에서 실행된다. 웹, CLI(오픈 소스), macOS 앱, IDE 확장, GitHub 통합을 아우르는 생태계가 ChatGPT 계정 하나로 연결된다. 검증 가능한 증거 기능은 모든 작업에 대해 터미널 로그와 테스트 결과의 출처를 함께 반환하므로, 정확히 무슨 일이 있었는지 감사할 수 있다.

Cursor Cloud Agents + Glass

에이전트의 근본 원리는 같지만 격리된 클라우드 VM에서 실행된다. 웹, 데스크탑 앱, Slack, Linear, GitHub, API, 심지어 cursor.com/agents를 스마트폰에 PWA로 설치해서도 에이전트를 시작할 수 있다. Glass는 에이전트 관리를 주된 인터페이스로, 기존 에디터는 필요할 때 꺼내 쓰는 도구로 만든 Cursor의 새로운 인터페이스다. 이는 생태계 전반에 걸쳐 나타나는 큰 흐름을 반영한다. 컨트롤 플레인이 주된 경험이 되고, 에디터는 그 아래의 하나의 도구가 되는 것이다.

Vibe Kanban

Vibe Kanban은 "둠스크롤링 갭" 문제를 해결한다. 에이전트가 작업 중일 때 아무것도 할 일이 없는 2~5분의 공백 말이다. 상세한 프롬프트가 담긴 작업 카드를 만들고 "진행 중"으로 드래그하면, 각 카드는 자신만의 워크트리와 브랜치를 갖는다. 보드 안에서 diff를 리뷰하고, 실행 중인 에이전트에게 피드백을 보낼 수도 있다. Claude Code, Codex, Gemini CLI, Amp, Cursor Agent CLI 등을 지원한다. 크로스 플랫폼(Mac, Windows, Linux), 무료, BYOK.

대규모 운용을 위한 프로 팁

멀티 모델 라우팅은 품질을 희생하지 않으면서 비용을 줄인다. 기계가 생성한 것보다 사람이 직접 작성한 AGENTS.md가 길이와 상관없이 더 가치 있다. 연구에 따르면 AI가 작성한 규칙은 효과가 없으며 오히려 성공률을 소폭 떨어뜨릴 수도 있다.

멀티 모델 라우팅

모든 작업에 가장 비싼 모델이 필요하진 않다. 계획 및 아키텍처 작업은 저렴한 Gemini/Claude/OpenAI 모델로 라우팅하고, 구현은 Sonnet, Opus 또는 Codex로, 리뷰는 전담 보안 모델로 라우팅하라. MODEL_ROUTING.md 파일을 만들어 설정하면 된다:

Planning       -> Gemini 
Implementation -> Claude Opus or Sonnet 
Review         -> etc.
Tests          -> etc.

워크트리 라이프사이클 스크립트

쉘 alias 세 개로 반복적인 작업을 자동화할 수 있다:

agent-spin <feature>   # create worktree + branch + start agent
agent-merge <feature>  # rebase + review + open PR
agent-clean            # remove finished worktrees

bash 코드 약 12줄이다. Conductor를 사용하면 이를 시각적으로 처리해준다.

AGENTS.md는 반드시 사람이 직접 작성

이것이 가장 중요하다. 연구 결과(Gloaguen 외, ETH 취리히)에 따르면 LLM이 생성한 AGENTS.md 파일은 효과가 없으며, 추론 비용을 20% 이상 높이면서 오히려 성공률을 평균 약 3% 떨어뜨릴 수 있다. 반면 개발자가 직접 작성한 컨텍스트 파일은 약 4%의 성과 향상을 제공한다. 에이전트가 AGENTS.md에 직접 쓰는 것은 절대 허용하지 마라. 리드가 모든 줄을 승인해야 한다. 명확한 섹션으로 간결하게 유지하라:

## STYLE
- Use functional components with hooks
- Prefer named exports

## GOTCHAS
- SQLite requires WAL mode for concurrent reads
- Express middleware order matters for auth

## ARCH_DECISIONS
- All state in SQLite, no in-memory caches
- One Express router per feature module

## TEST_STRATEGY
- Integration tests over unit tests for API routes
- Use supertest for HTTP assertions

품질 게이트: 신뢰하되 검증하라

세 가지 품질 게이트가 에이전트 결과물을 신뢰할 수 있게 만든다. 계획 승인은 코드가 생기기 전에 잘못된 아키텍처를 잡아내고, 훅은 모든 라이프사이클 이벤트에서 자동 검사를 실행하며, AGENTS.md는 세션을 거치며 학습을 누적한다.

계획 승인. 팀원이 코딩을 시작하기 전에 계획을 작성하도록 요구하라. 리드가 접근 방식을 검토하고 승인 또는 거절한다. 잘못된 계획을 고치는 게 잘못된 코드를 고치는 것보다 훨씬 비용이 적다. 흐름은 다음과 같다:

teammate >>> writes plan >>> lead review >>> approve/reject >>> implement

훅. 라이프사이클 이벤트에서 자동으로 실행되는 검사다. TeammateIdle 훅은 에이전트가 작업을 마치기 전에 모든 테스트가 통과하는지 확인한다. TaskCompleted 훅은 작업을 완료로 표시하기 전에 lint와 테스트를 실행한다. 훅이 실패하면 에이전트는 통과할 때까지 계속 작업한다:

task done >>> hook runs npm test >>> pass? allow  |  fail? keep working

누적 학습을 위한 AGENTS.md. 이 파일에는 발견한 패턴, 주의사항, 스타일 선호도가 기록된다. 모든 에이전트는 세션 시작 시 이를 읽고, 모든 세션이 끝나면 이를 업데이트한다. 첫 번째 세션에서 테스트 패턴을 발견하면 AGENTS.md에 업데이트되고, 두 번째 세션은 같은 실수를 반복하지 않는다.

병목이 이동했다

병목은 더 이상 생성이 아니다. 이제는 검증이다. 에이전트는 놀라운 속도로 인상적인 결과물을 만들어낼 수 있다. 그 결과물이 정말 올바른지 확신하는 것이 이제 어려운 부분이다.

변경 전에 통과하던 테스트가 변경으로 인한 회귀를 잡아낸다는 보장은 없다. 에이전트는 기술적으로 유효하지만 정작 중요한 케이스를 빠뜨린 테스트를 작성할 수 있다. 컨텍스트 창의 한계 때문에 대규모 코드베이스에서 작업하는 에이전트는 현재 뷰 밖의 중요한 제약 조건을 놓칠 수 있다. 그리고 단일 개발자에게는 성가신 엣지 케이스에 불과했던 불안정한 환경이, 에이전트 40개가 동시에 같은 불안정한 테스트를 만나면 시스템 전체를 막는 장애물이 된다.

검증 인프라가 생성 능력을 따라잡기 전까지, 사람의 검토는 선택적인 부가 작업이 아니다. 안전 시스템이다. 에이전트의 결과물이 그럴싸해 보인다고 신뢰하는 게 아니라, 아키텍처적 이해와 테스트 규율을 갖추고 엄밀하게 평가해야 한다.

데모 4: 품질 게이트와 자기 개선 에이전트

이 데모는 모든 것을 하나로 묶는다. 세 가지를 주목하라. 첫째, 계획 승인 흐름. 팀원이 즐겨찾기 기능 추가를 제안하는데, 리드가 계획에 데이터베이스 마이그레이션 단계가 빠진 것을 발견하고 거절한다. 팀원이 수정안을 제출한다. 둘째, 작업 완료 시 훅이 작동하는 모습. TaskCompleted 훅이 빠진 console.log 구문을 잡아내고, 에이전트가 작업을 완료로 표시하기 전에 이를 수정한다. 셋째, 마지막에 AGENTS.md에 새 항목이 추가된다. "기존 테이블에 컬럼을 추가할 때는 항상 ALTER TABLE 마이그레이션을 포함하라." 이 학습은 이후 모든 세션에 이어진다.

Ralph 루프와 자기 개선 에이전트

Ralph 루프 패턴은 개발을 작은 원자 단위 작업으로 나누고, 에이전트를 상태 없이 반복하는 루프로 실행한다. 각 반복은 작업 선택, 구현, 검증, 통과 시 커밋, 컨텍스트 초기화 후 반복으로 이어진다. 외부 메모리를 통해 연속성을 유지하면서 컨텍스트 과부하를 피하는 방식이다.

Geoffrey Huntley와 Ryan Carson이 대중화한 Ralph 루프는 "자는 동안 코드가 배포되는" 패턴의 핵심이다. Carson의 독립형 ralph 도구(snarktank/ralph)가 핵심 루프를 구현하며, 그의 Antfarm 프로젝트는 동일한 패턴을 사용해 OpenClaw 위에 멀티 에이전트 오케스트레이션을 계층으로 얹는다. 핵심 아이디어는 도구를 가리지 않고 적용할 수 있다.

다섯 단계 사이클:

1. 선택 - tasks.json에서 다음 작업을 선택
2. 구현 - 변경사항을 만든다
3. 검증 - 테스트, 타입 검사, lint를 실행
4. 커밋 - 검사를 통과하면 커밋하고 작업 상태를 업데이트
5. 초기화 - 에이전트 컨텍스트를 지우고 다음 작업으로 새로 시작

핵심 통찰은 "상태 없는 반복"이다. 매 반복마다 초기화함으로써 에이전트가 혼란을 누적하지 않는다. 작고 범위가 명확한 작업은 거대한 프롬프트 하나보다 환각이 적고 코드도 깔끔하다.

신뢰성을 높이는 안전장치: 오류를 자동 재시도를 위해 피드백으로 돌려보내되, 3번 이상 같은 자리에서 막히면 중단하고 재배분하라. 항상 피처 브랜치에서 작업하라. 반복 횟수, 시간, 토큰에 엄격한 한계를 설정하라. 에이전트가 PR을 열면, 당신이 검토한 뒤 머지한다.

초기화를 거쳐도 지속되는 메모리 채널은 네 가지다. git 커밋 히스토리, 진행 로그, 작업 상태 파일(tasks.json), 그리고 장기 시맨틱 메모리로서의 AGENTS.md. 하룻밤 루프 하나로 시작해서, 10개 브랜치에 10개 루프로 발전시켜라.

에이전트를 시간이 지날수록 더 스마트하게 만들기

REFLECTION.md 제안을 활용한 자기 반성. 모든 작업 후 에이전트가 REFLECTION.md를 작성하도록 강제하라. 무엇이 놀라웠는지, AGENTS.md에 추가할 패턴 하나, 개선할 프롬프트 하나. 리드가 검토하고 승인된 학습을 병합한다. 이것이 누적 학습이 실제로 복리로 작동하는 방식이다. 즉흥적이 아닌, 체계적으로.

토큰 예산과 종료 기준. 에이전트별로 엄격한 예산을 설정하라. 프론트엔드 18만 토큰, 백엔드 28만 토큰. 예산의 85%에 도달하면 자동으로 일시 정지하고 리드에게 알린다. 같은 오류로 3번 이상 반복해서 막히면 종료하고 새 에이전트에게 재배분하라.

Beads / 영속적 메모리. Gastown의 "beads" 패턴은 완전한 출처 정보와 함께 모든 결정과 결과를 불변하는 git 기반 레코드로 남긴다. 에이전트는 작업 그래프와 SQL로 조회 가능한 데이터 플레인을 통해 과거 beads를 검색한다. 전통적인 벡터 기반 RAG가 아니라, 단순한 마크다운 파일을 훨씬 뛰어넘는 구조화된 조회 가능한 조직 메모리다.

규율: 이것이 작동하게 만드는 것

사람이 병목이었던 것은 버그가 아니라 기능이었다. 사람의 속도에서는 오류가 천천히 누적되고 고통이 일찍 수정을 강요한다. 에이전트 군대와 함께라면, 작은 실수가 당신이 따라잡을 수 없는 속도로 복리로 불어난다.

사람이 느리게 코드를 작성할 때는 고통을 일찍 느낀다. 테스트가 실패하고, 코드 리뷰에서 뭔가를 잡아내고, 중복을 알아차린다. 고통이 즉각적이므로 진행하면서 수정한다.

오케스트레이션된 에이전트 군대와 함께라면 자연스러운 병목이 없다. 사소해 보이는 실수들 — 코드 스멜 하나, 중복 하나, 불필요한 추상화 하나 — 이 지속 불가능한 속도로 복리로 불어난다. 루프 밖으로 나온 당신은 너무 늦을 때까지 고통을 느끼지 못한다. 그러다 어느 날 기능을 하나 추가하려는데 아키텍처가 허용하지 않는다. 테스트도 똑같이 신뢰할 수 없다. 에이전트가 그것도 작성했으니까.

이것이 모든 품질 게이트가 중요한 이유다. 계획 승인, 훅, 토큰 예산, 사람 검토 — 이것들은 있으면 좋은 것이 아니다. 없으면 에이전트로 스스로를 막다른 골목으로 몰게 될 것이기 때문에 존재한다.

작업을 위임하라. 판단은 위임하지 마라

명확한 통과/실패 기준이 있는 범위 한정 작업, 보일러플레이트, 마이그레이션, 테스트 스캐폴딩은 에이전트에게 맡겨라. 당신이 직접 해야 할 것은 아키텍처, 만들지 않을 것 결정하기, 전체 컨텍스트를 갖춘 리뷰, 그리고 좋은 시스템을 만드는 안목이다.

에이전트는 엄밀한 평가 함수가 있는 작업 — 에이전트가 자신의 작업을 스스로 측정할 수 있는 — 에서 탁월하다. 보일러플레이트, 마이그레이션, 테스트 스캐폴딩, 그리고 당신이 직접 해볼 시간이 없었을 접근 방식 탐색에 진짜 강점이 있다.

당신이 직접 해야 할 것: 아키텍처와 API 설계(에이전트는 학습 데이터에서 나쁜 아키텍처를 많이 봤고, 스타트업에 엔터프라이즈 패턴을 기꺼이 카고-컬팅할 것이다), 만들지 않을 것 결정하기(거절은 에이전트에게 없는 기능이다), 전체 시스템 컨텍스트를 갖고 에이전트 결과물 리뷰하기(에이전트는 항상 로컬 뷰만 갖는다).

기능을 더 적게, 하지만 올바른 것을 만들어라. 코드 생성의 속도는 세이렌의 노래다. 이해를 유지할 수 있을 만큼 충분히 속도를 늦춰라. 자신의 시스템에 대한 이해를 잃으면, 고치는 능력도, 확장하는 능력도, 심지어 고장난 것을 알아차리는 능력도 잃는다.

스펙이 곧 레버리지다

50개의 에이전트를 병렬로 오케스트레이션할 때, 모호한 생각은 당신의 속도를 늦추는 게 아니라 배가된다. 모호한 요구사항이 수십 개의 병렬 실행에 전파되고, 각각이 조금씩 다른 방향으로 어긋난다. 뛰어난 엔지니어는 에이전트에서 더 많은 레버리지를 얻는다. 더 적은 것이 아니라.

평범한 결과와 탁월한 결과의 차이는 거의 전적으로 스펙의 품질에 달려 있다. 모호한 스펙은 전체 플릿에 오류를 배가시킨다. 명확한 아키텍처, 통합 경계, 엣지 케이스, 불변 조건이 담긴 정밀한 스펙은 어디서나 정밀한 구현으로 배가된다.

스펙은 더 이상 프롬프트가 아니다. 스펙은 명시적으로 표현된 제품 사고다. 이것이 뛰어난 소프트웨어 엔지니어가 이 도구에서 더 많은 레버리지를 얻는 이유다. 코드를 타이핑하는 기계적인 작업은 자동화되고 있다. 시스템을 이해하는 인지적 작업은 자율적인 작업자 전체 플릿에 걸쳐 증폭되고 있다.

공장 모델

당신은 이제 단순히 코드를 작성하는 것이 아니다. 당신의 소프트웨어를 만드는 공장을 짓고 있다. 그 공장에는 생산 라인이 있다. 계획, 생성, 모니터링, 검증, 통합, 회고.

공장에는 품질 관리가 있다. 공장에는 프로세스 문서가 있다. 공장에는 정밀하게 명세되지 않으면 출력이 잘못 나오는 입력이 있다. 공장은 환경이 불안정하면 멈춘다. 이 모든 특성이 에이전트 소프트웨어 개발에 그대로 적용된다.

여섯 단계 생산 라인:

1. 계획 - 인수 기준이 있는 스펙을 작성하라. 스펙이 곧 레버리지다.
2. 생성 - 팀을 구성하고 에이전트를 배분하라.
3. 모니터링 - 5~10분마다 진행 상황을 확인하고 막힌 부분을 해결하라. 과도하게 개입하지 말 것.
4. 검증 - 테스트를 실행하고 코드를 리뷰하라. 병목은 생성이 아닌 검증이다.
5. 통합 - 브랜치를 머지하고 충돌을 해결하라.
6. 회고 - 새 패턴으로 AGENTS.md를 업데이트하라. 학습이 누적된다.

공장 운용을 위한 실용적인 팁:

• WIP 한도 설정: 의미 있게 리뷰할 수 있는 것보다 많은 에이전트를 실행하지 마라. 3~5개가 최적이다.
• 종료 기준 정의: 에이전트가 같은 오류로 3번 이상 반복해서 막히면 중단하고 재배분하라.
• 비동기 점검: 5~10분마다 진행 상황을 확인하라. 에이전트가 자율적으로 작업하게 두라.
• 파일 하나에 소유자 하나: 두 에이전트가 같은 파일을 수정하게 두지 마라. 충돌은 속도를 죽인다.

이 프레임워크에 대한 더 자세한 내용은 공장 모델을 참고하라.

오늘 당장 시작할 5가지 패턴

이번 발표에서 다섯 가지만 가져간다면:

1. 작업 분해를 위한 서브에이전트. Task 도구를 사용해 구체적인 브리프와 파일 소유권이 있는 집중된 자식 에이전트를 생성하라. 별도 설정 없이 바로 시작할 수 있다. 오늘 당장 시작하라.
2. 병렬 실행을 위한 에이전트 팀. CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1을 활성화하라. 리드 한 명에 팀원 세 명을 구성하라. 조율에는 공유 작업 목록을 활용하라.
3. 격리를 위한 Git 워크트리. 각 에이전트가 자신만의 워크트리를 갖게 하라. 머지 충돌 없이 깔끔하게 통합된다. Conductor 같은 도구는 이를 자동으로 처리해준다.
4. 신뢰를 위한 품질 게이트. 위험한 변경에는 계획 승인을 요구하라. 작업 완료 시 테스트를 실행하는 훅을 추가하라. 검증 없이 에이전트 결과물을 신뢰하지 마라.
5. 누적 학습을 위한 AGENTS.md. 패턴, 주의사항, 스타일 선호도를 문서화하라. 모든 세션이 이를 읽고, 모든 세션이 이를 업데이트한다. 지식이 누적된다.

오늘 첫 번째 패턴부터 시작하라. 다음 주에는 에이전트 팀으로 발전시켜라. 그다음 품질 게이트와 누적 학습을 더하라.