Herdr 기반 Multi-Agent Workflow 구축기

1. 프롬프트 하나로 끝난다던 환상, 그리고 마주친 벽

최근 Claude Code, Antigravity, Cursor, Codex 등 뛰어난 AI 코딩 도구들이 보편화되면서, 프롬프트 한 줄로 "기능을 추가해 줘"라고 요청하면 코드가 뚝딱 완성되는 놀라운 경험을 누구나 겪어보았을 것입니다.

토이 프로젝트나 단순 스크립트 작성 단계에서는 단일 AI 에이전트 하나만 띄워놓고 대화형으로 코딩해도 충분히 훌륭합니다. 하지만 여러 개발자가 함께 협업하며 복잡한 비즈니스 규칙, 엄격한 DDD 아키텍처, 트랜잭션 경계가 얽힌 실제 엔터프라이즈 백엔드 환경에 진입하는 순간, 단일 에이전트 방식은 급격한 한계와 실패를 드러내기 시작합니다.

팀 프로젝트에서 나에게 할당된 복잡한 기능 티켓을 처리할 때, 단 하나의 에이전트 세션에 DB 마이그레이션 DDL부터 JPA 리포지토리, 도메인 엔티티, 서비스 로직, REST API, 테스트 코드까지 전 과정을 통째로 맡기면 얼마 못 가 치명적인 문제들이 터져 나옵니다. 대화가 15~20턴을 넘어가면 초반에 강조했던 프레임워크 규약이나 도메인 불변식을 잊고 코드를 제멋대로 덮어씁니다. 에이전트가 짠 코드를 개발자가 한 줄씩 눈으로 디버깅하며 문법 오류나 비즈니스 예외 누락을 수동으로 지적하는 피곤한 핑퐁이 반복됩니다. 가끔은 자기가 작성한 설계와 코드의 결함을 스스로 찾아내지 못하고 "완벽합니다"라며 맹점을 정당화합니다.

이런 문제들과 마주한 끝에 질문의 방향을 바꾸었습니다.
"AI 한 대에게 모든 걸 맡기지 말고, 각 분야의 전문 에이전트가 서로를 검증하고 개선하는 자율 에이전트 팀을 구축해보면 어떨까?"

2. 왜 단일 에이전트가 아닌 '멀티 에이전트(Multi-Agent)'인가?

멀티 에이전트 체계는 단일 에이전트로 진행하는 개발 과정에서 갖지 못하는 몇 가지 장점이 있습니다.

① 인지 부하 분산과 역할의 순수성

단일 에이전트에게 "기존 코드를 분석하고, 설계를 작성한 뒤, 구현하고 테스트까지 해줘"라고 지시하면, LLM 내부 메커니즘은 인지 과부하를 겪습니다.

한 프롬프트 안에서 조사자이자, 설계자이자, 개발자이자, 테스터의 역할을 동시에 부여받으면 가장 시간과 노력이 많이 드는 코드베이스 조사 단계를 생략하고, 부족한 Context를 가지고 적절히 코드를 짜는 지름길을 택하게 됩니다.

반면, 멀티 에이전트 체계에서는 담당 에이전트에게 "당신은 오직 사실관계(Domain 관계, DB 스키마, 호출 흐름)만 조사하는 조사관이다. 절대 코드를 짜지 마라"라는 단일 목적만 부여합니다. 각 에이전트가 하나의 페르소나에 100% 집중할 때 산출물의 밀도와 정확도가 극대화됩니다.

② 자가 확증 편향 타파와 독립적 검증

사람도 자신이 작성한 보고서의 오탈자나 논리적 오류를 스스로 찾아내기 매우 어렵습니다. LLM 역시 자신이 세운 가정과 설계에 대해 자기 확증 편향을 가집니다.

단일 에이전트 세션에서 "내가 짠 코드에 버그가 있어?"라고 물으면, 방금 자기가 짠 로직의 전제를 그대로 계승하여 "문제없이 완벽합니다"라고 답변하기 일쑤입니다.

멀티 에이전트 체계에서는 설계자가 작성한 계획을 전혀 모르는 독립된 검증자에게 넘깁니다. 검증자는 "이 설계/코드에는 반드시 치명적인 결함이 있다"는 전제하에 실제 소스코드를 직접 열어 실측 대조하며, 이 과정에서 수많은 잠재적 런타임 익셉션과 레이스 컨디션을 사전에 걸러냅니다.

③ 컨텍스트 윈도우 위생과 성능 저하 방지

LLM의 컨텍스트 윈도우가 100만 토큰 이상으로 커졌더라도, 긴 대화가 이어질수록 초기 지시사항을 망각하거나 중간 정보를 놓치는 'Lost in the Middle' 및 추론 성능 저하는 여전히 실재하는 문제입니다.

단일 에이전트는 파일 30개를 열어본 수만 줄의 텍스트, Gradle 빌드 에러 로그, 장황한 스택 트레이스를 모두 하나의 세션 컨텍스트에 담고 갑니다.

멀티 에이전트 환경에서는 각 작업 단계가 끝나면 정제된 핵심 산출물만을 다음 에이전트에 핸드오프합니다. 수천 줄의 조사 과정이나 빌드 로그는 해당 Pane에 갇혀 격리되므로, 오케스트레이터와 설계자의 컨텍스트는 항상 깨끗하고 날카로운 상태를 유지합니다.

④ 이종 모델 시너지와 사각지대 상쇄

모든 작업에 최상위 모델을 쓰면 API 비용이 폭발하고 금방 토큰 한도에 도달합니다. 반대로 모든 작업에 경량 모델만 쓰면 복잡한 도메인 아키텍처 추론이 무너집니다.

대규모 탐색과 단순 반복 코딩/테스트는 비용이 저렴하고 토큰 컨텍스트가 방대하며 속도가 빠른 모델에 맡기고, 고도의 도메인 및 아키텍처 설계는 깊은 추론력을 가진 최상위 모델에 집중 투입합니다.

Claude가 작성한 코드를 Gemini가 리뷰하고, Gemini가 작성한 코드를 Claude가 리뷰하며, 서로 다른 학습 데이터와 아키텍처를 가진 두 모델이 서로의 사각지대를 보완해 줍니다.

3. 실전의 시작: Antigravity와 Claude Code의 이종 페어링

시작은 아주 단순한 실험이었습니다.
"Anthropic의 Claude Code와 Google의 Antigravity를 양쪽에 띄우고 서로 맞물리게 하면 어떨까?"

실제로 두 모델을 맞물려보니 시너지는 상상을 초월했습니다.

Claude Code의 Opus 모델은 복잡한 비즈니스 로직, 객체지향적 책임 분리, 유스케이스 설계에 압도적 강점을 보였습니다. Antigravity의 Gemini 3.6 Flash 모델은 대용량 컨텍스트와 무서운 속도로 실제 파일시스템을 뒤져 DB 컬럼 타입, Spring 빈 의존성, 레거시 트랜잭션 규칙을 조사하는 데 타의 추종을 불허했습니다.

동일 모델 간 검증에서 놓치던 사각지대를, 학습 아키텍처와 시각이 완전히 다른 두 빅테크 모델이 서로를 교차 검증하며 빈틈없이 메워주며 코드의 완성도를 높일 수 있었습니다.

4. '복붙 셔틀'의 종말: 터미널 멀티플렉서 Herdr의 도입

이종 모델 페어링은 환상적이었지만, 곧바로 새로운 물리적 병목에 부딪혔습니다.

1번 터미널(Claude)에서 설계를 복사하고 2번 터미널(Antigravity)로 전환하여 붙여넣고, "검증해 줘" 라고 요청하고… 다시 결과를 복사해서 1번에 붙여넣고 “이런 문제가 있어. 확인해봐” 라고 요청하고…. 같은 작업이 반복되고 있었습니다.

에이전트 역할은 나눴는데, 정작 개발자인 내가 터미널 사이를 오가는 '복붙 셔틀'이 되어버렸습니다.

이 수동 전환 지옥을 끝내기 위해 여러 가지 방법을 찾아보았고, 때마침 발견한 것이 바로 Herdr였습니다.

Herdr는 화면만 쪼개 보여주는 일반 터미널 도구와 결이 달랐습니다. 에이전트의 생명주기와 메시지 전달을 총괄하는 '에이전트 전용 백그라운드 오케스트레이션 엔진'에 가까웠습니다.

• Herdr는 각 Pane의 출력 스트림을 실시간 감시하며 에이전트가 일하는 중인지(Working), 막혔는지(Blocked), 완료되었는지(Done)를 스스로 판단합니다. 사람이 터미널 앞에서 대기하며 엔터 칠 타이밍을 잴 필요가 완전히 사라졌습니다.

• 하나의 Pane이 설계를 마치고 Done을 띄우는 순간, Herdr 데몬이 JSON-over-Socket IPC로 출력 마크다운을 낚아채서 다음 Pane의 표준 입력(stdin)으로 프롬프트와 함께 즉시 직결 주입합니다. 복붙 피로도가 말 그대로 0이 되었습니다.

• 단일 세션에서 긴 빌드나 전체 테스트를 돌리면 개발자의 프롬프트 창까지 꽁꽁 얼어붙곤 했습니다. Herdr에서는 각 Pane이 독립된 프로세스와 가상 TTY로 격리되어 있어, 하나의 Pane이 백그라운드에서 수백 개의 테스트를 돌리는 중에도 다른 Pane의 터미널에서는 언제든 작업을 진행할 수 있었습니다.

5. Herdr 멀티 Pane의 진화 과정: 코딩 Pane 분리부터 8개 Agent Pane 완성까지

처음부터 8개의 Pane을 완벽하게 갖추고 시작한 것은 아니었습니다. 복잡한 개발 task들을 하나씩 처리해 나가며 수많은 실패와 병목을 겪었고, 고통이 발생할 때마다 전담 Pane을 하나씩 떼어내어 진화시키는 여정을 거쳤습니다.

1단계: 일대일 핑퐁에서 시작된 첫 번째 분리 (coding Pane)

초기에는 메인 세션(Claude Code) 혼자서 요구사항 분석, 아키텍처 설계, 코드 작성, 컴파일까지 모든 것을 도맡았습니다. 하지만 수십 개의 파일 편집 내역과 방대한 컴파일 에러 로그가 메인 세션에 그대로 누적되면서, 대화가 10턴만 넘어가도 초기의 도메인 규칙을 잊어버리는 컨텍스트 오염이 발생했습니다.

이를 해결하기 위해 coding Pane을 최초로 분리했습니다. 메인 오케스트레이터는 전체적인 설계와 지시만 내리고, 대량의 코드 타이핑과 컴파일 에러 디버깅은 압도적인 속도를 가진 Gemini Flash에게 위임하여 메인의 컨텍스트를 깨끗하게 보호하기 시작했습니다.

2단계: "내가 짠 코드는 완벽해"를 깨부순 이종 이중 리뷰어

코딩 Pane을 분리했지만 곧이어 새로운 문제에 부딪혔습니다. 코딩이 끝난 뒤 코드를 작성한 에이전트 본인이나 개발자 1명에게 "검토해 봐"라고 시키면, 자가 확증 편향에 빠져 "모든 요구사항이 완벽히 충족되었습니다"라는 영혼 없는 대답만 돌아왔고 결국 버그가 메인 브랜치로 유입되었습니다.

이에 "이 코드에는 반드시 결함이 숨어 있다"고 가정하고 파괴적으로 검토하는 서로 다른 모델로 이루어진 2개의 독립 리뷰 Pane을 신설했습니다. 아키텍처 위반과 도메인 불변식을 짚어내는 claude-review와, Null 안전성·SQL N+1·트랜잭션 롤백을 파고드는 antigravity-review를 배치했습니다. 특히 두 리뷰어를 순차가 아닌 동시에(Parallel) 가동하여 대기 시간을 절반으로 줄이고 상호 독립적인 다각도 교차 검증망을 완성했습니다.

3단계: 코딩 끝나고 엎는 건 너무 늦다 - 설계 검증(design-verify) 도입

하지만 코딩과 리뷰가 아무리 완벽해도 또 다른 거대한 낭비가 남아 있었습니다. 코딩이 다 끝나고 리뷰 단계에 이르러서야 "기본 도메인 모델링이 잘못되었다"거나 "트랜잭션 경계 설계가 어긋났다"는 근본적인 결함을 발견하는 경우였습니다. 이럴 때마다 기껏 작성한 수백 줄의 프로덕션 코드를 통째로 롤백하고 처음부터 다시 짜야 했습니다.

이 거대한 재작업을 원천 차단하기 위해 결함 검출 시점을 코딩 착수 전으로 앞당기는 전략을 도입했습니다. 설계 문서가 작성되는 즉시 실제 소스코드를 열어 대조하며 검증하는 design-verify Pane을 배치했습니다. 설계 단계에서 엣지 케이스와 아키텍처 결함을 100% 털어내고 코딩에 들어가자, 전체 개발 사이클 반복이 줄어들어 개발 시간이 절반으로 빨라졌습니다.

4단계: 지휘관과 설계자의 분리 - 설계 전담(design) Pane 독립

설계 검증 루프가 안착되자 새로운 병목이 나타났습니다. 메인 오케스트레이터가 수백 줄에 달하는 상세 도메인 설계 문서 작성을 직접 도맡다 보니, 깊은 설계 추론 과정에서 오케스트레이터의 컨텍스트 윈도우가 급격히 바닥났습니다. 정작 여러 Pane을 조율하고 개발자와 소통하며 통제해야 할 지휘관의 인지 능력이 저하되고 있었습니다.

이에 "오케스트레이터는 직접 문서를 쓰지 않고, 오직 지휘와 게이트키핑에만 전념한다"는 원칙을 세우고, 깊은 객체지향 추론과 설계를 전담하는 design Pane을 독립 분리했습니다.

5단계: 상상으로 설계하지 마라 - 조사(research) Pane 격리

설계 전담 Pane을 분리했음에도 간혹 엉뚱한 설계가 나오는 경우가 있었습니다. 설계 에이전트에게 조사와 설계를 한 번에 맡겼더니, 방대한 코드베이스 탐색을 건너뛰고 자신의 기억에 의존해 설계를 시작하는 현상이 발생한 것입니다.

이를 원천 봉쇄하기 위해 설계 착수 전 코드베이스의 패키지 의존성, DB 스키마 타입, 비동기 이벤트 흐름, 기존 구현 패턴만을 파헤쳐 팩트시트를 작성하는 research Pane을 독립시켰습니다. "설계자는 코드를 직접 상상해서 뒤지지 말고, 조사관이 제출한 객관적 팩트시트만을 근거로 설계하라"는 엄격한 분업 규칙을 확립했습니다.

6단계: 로그의 역습- 테스트(test) Pane 분리

마지막으로 남은 복병은 전체 테스트 구동이었습니다. gradle test 전체를 돌릴 때마다 수천 줄에 달하는 빌드 출력과 기존에 인지된 다른 에이전트의 베이스라인 실패 로그가 터미널을 뒤덮었고, 메인 오케스트레이터의 대화창과 Context를 심각하게 잠식했습니다.

이를 막기 위해 전체 테스트 스위트 실행과 결함 판정을 전담하는 test Pane (Gemini Flash)을 분리하여 무거운 로그 출력을 서브 Pane 안에 격리시켰습니다. Gemini Flash 모델로 동작하는 Agent는 빠른 속도로 끝없이 긴 테스트 로그를 한 번에 처리해 냈습니다.

7단계: 세션 시작과 함께 준비 완료 - 훅(Hook) 기반 자동 프로비저닝 완성

이제 7개의 전문 Pane 체계가 완성되었지만, 매번 Herdr을 시작할 때마다 수동으로 7개의 창을 쪼개고 각각의 도구와 프롬프트를 주입하는 일은 또 다른 번거로움이었습니다.

이를 세션 시작 훅에 스크립트로 자동화했습니다. 이제 Herdr 세션이 열리는 즉시 1개의 Main Orchestrator + 7개의 전문 Specialist Pane이 유기적으로 정렬된 완전한 워크스페이스가 1초 만에 자동으로 펼쳐집니다.

6. 1 Orchestrator + 7 Specialists

앞서 살펴본 점진적 분리 과정을 거쳐, 현재는 지휘와 품질 게이트키핑만을 전담하는 메인 오케스트레이터 1개 + 전문화된 7개의 하위 Agent Pane이라는 총 8개 Pane 체제로 최종 수렴하게 되었습니다.

각 Pane은 더 이상 중복되거나 모호한 역할을 갖지 않으며, 단일 책임 원칙에 따라 자신만의 전담 임무와 그에 최적화된 LLM 엔진을 부여받아 독립적으로 기동합니다.

메인 오케스트레이터 Pane은 직접 코드를 읽거나 쓰지 않으며, 아래 정의된 7개의 전문 Pane에게 명확한 프로토콜로 작업을 위임하고 그 결과를 검증·통합하는 역할만 수행합니다.

Pane 명칭	전담 임무	탑재 모델	선정 이유 및 핵심 역할
main	전체 파이프라인 지휘 & 게이트키핑	Claude Sonnet	개발자와 소통, 단계별 위임 및 Git 커밋/머지 통제
research	코드베이스 사실관계 실측 조사	Gemini 3.7 Flash	빠른 속도와 방대한 컨텍스트로 패키지, DB 스키마, 호출 흐름 탐색
design	아키텍처 및 상세 설계서 작성	Claude 3.7 Opus	깊은 추론 능력을 바탕으로 설계서 작성
design-verify	적대적 설계 검증	Gemini 3.7 Flash	"이 설계는 틀렸다"는 전제로 결함과 엣지 케이스 공격
coding	코드 구현 및 컴파일	Gemini 3.7 Flash	압도적인 속도와 프레임워크 규약 준수 고속 코딩
claude-review	1차 코드 리뷰 (구조/DDD)	Claude Sonnet	아키텍처 계층 위반, 결합도, 트랜잭션 경계, 비즈니스 불변식 검토
antigravity-review	2차 코드 리뷰 (버그/안정성)	Gemini 3.7 Flash	Null 안전성, SQL/N+1, 예외 누락, 멱등성, 코딩 컨벤션 검토
test	전체 테스트 스위트 회귀 검증	Gemini 3.7 Flash	전체 Gradle 테스트 실행

7. End-to-End Multi-Agent 워크플로우

아무리 뛰어난 7개의 전문 에이전트를 배치했더라도, 엄격하고 결정론적인 워크플로우 규칙이 없으면 멀티 에이전트 시스템은 순식간에 혼란과 비효율의 수렁에 빠집니다. 에이전트로 작업을 하면서 경험한 워크플로우의 핵심 필요성은 다음과 같습니다.

1. '자유 방임형 자율성'의 실패 방지: 에이전트들에게 "너희들끼리 알아서 토론해서 기능 개발해 봐"라고 자율성을 주면, 에이전트들은 섣부른 코딩에 돌입하거나, 끝없는 핑퐁 대화로 토큰만 낭비합니다. 각 에이전트에게 명확한 입력과 출력 계약을 강제하는 파이프라인이 필수적입니다.

2. 소프트웨어 공학의 'Shift-Left' 원칙 실현: 결함은 발견 시점이 뒤로 갈수록 수정 비용이 기하급수적으로 폭증합니다. 코딩 착수 전 설계 문서 단계에서 결함을 최대한 제거하는 것이 전체 개발 리드타임을 단축하고 코드 롤백을 없애는 최선의 방법입니다.

3. 품질 게이트의 결정론적 수렴: "이슈가 없을 때까지 검증을 반복한다", "테스트 실패 0건 확인"과 같은 엄격한 게이트키핑을 통해, LLM의 컨디션이나 확률적 편차에 상관없이 항상 프로덕션 레벨의 무결점 품질로 결과물이 수렴합니다.

4. 인간 개발자의 인지 에너지 보존: 프로세스가 명확히 정의되어 있으면 개발자는 에이전트의 세부 작업마다 불안해하며 개입할 필요가 없습니다.

개발자는 오직 "설계 검증 완료 후 최종 승인"과 "최종 머지 시점"이라는 가장 중요한 통제점에서만 에너지를 집중할 수 있습니다.

이를 위해 오케스트레이터 에이전트에게 7개의 전문 Agent Pane을 다음과 같은 워크플로우로 배치하여 동작하도록 하였습니다. 그리고 워크플로우가 동작하면서 에이전트 간 책임은 더욱 명확해졌으며 개발자의 개입이 필요한 설계 검토와 최종 검증 외의 과정은 개발자의 개입 없이도 자연스럽게 동작하는 구조가 완성되었습니다. 그리고, 이렇게 개발자의 개입이 줄어든 덕분에 저는 중요한 검토, 검증 과정에 더욱 집중할 수 있게 되었습니다.

8. Multi-Agent Workflow 도입 후 체감한 4가지 변화

팀 단위로 협업하는 백엔드 프로젝트 환경에서, 내게 할당된 복잡한 기능 티켓들을 처리하기 위해 이 워크플로우를 구축해 활용하면서 극적인 변화를 실질적으로 체감할 수 있었습니다.

첫째, 정신적 피로도와 불안감이 감소하였습니다. 과거에는 AI가 짠 코드에 숨겨진 버그가 없을지 불안해하며 수백 줄을 하나씩 쳐다보며 디버깅하느라 에너지 소모가 컸습니다. 지금은 research, design-verify, 이중 리뷰어가 다단계로 검토해 주므로, 개발자는 핵심 비즈니스 설계 승인과 아키텍처 의사결정에만 뇌 에너지를 온전히 집중할 수 있습니다.

둘째, 설계 단계 조기 결함 차단으로 대규모 재작업이 줄었습니다. AI의 코딩이 다 끝난 뒤에야 뒤늦게 도메인 모델링 오류를 발견해 코드를 통째로 갈아엎던 낭비가 사라졌습니다. 설계 단계에서 결함을 미리 걸러내어, 코딩 착수 후 불필요한 시행착오 없이 높은 완성도로 구현을 마무리하게 되었습니다.

셋째, 작업 속도와 퀄리티를 모두 챙길 수 있게 되었습니다. 혼자서 티켓을 담당하지만 산출물은 마치 전담 시니어 스쿼드가 달라붙어 사전 조사, 상세 마크다운 설계서, 2중 교차 리뷰, 한글 Javadoc, 전체 회귀 테스트를 완벽히 마친 것과 같은 최상의 퀄리티로 팀 코드베이스에 기여하게 되었습니다.

넷째, 자동화된 설계 문서화와 투명한 의사결정 이력을 자산화하게 되었습니다. 바쁜 일정에 쫓겨 문서화를 생략하던 과거와 달리, 워크플로우를 타는 것만으로 실측 팩트시트, 도메인 설계서, 적대적 검증 피드백이 고스란히 파일로 남게 되어 팀의 영구적인 지식 자산으로 축적되고 있습니다.

9. 마치며: 나만의 최적화된 Multi-Agent Workflow를 찾아서

본 글에서 소개한 1 Orchestrator + 7 Specialists 구성은 약 2주간에 걸쳐 수차례 시행착오 끝에 도출한 저만의 결과물입니다. 이 구성이 모든 개발자와 모든 프로젝트를 위한 ‘만능 정답’은 아닙니다. UI 중심 프론트엔드 환경이라면 시각적 회귀 테스트 에이전트가 중심이 될 것이고, 빠른 가설 검증이 중요한 초기 스타트업이라면 2~3개의 가벼운 Pane 구성이 더 적합할 수 있습니다.

중요한 것은 숫자가 아닌 '원칙'입니다

1. 역할의 순수성 : 한 에이전트에게 너무 많은 역할을 맡기지 말고, 조사·설계·구현·검증을 분리하여 집중도를 극대화할 것.

2. 자가 확증 편향을 깨는 적대적 상호 검증 : 자신이 작성한 설계를 맹신하지 않고, 다른 시각을 가진 에이전트에게 결함을 공격하게 만들 것.

3. 간결한 컨텍스트 : 장황한 원시 로그는 개별 에이전트에 격리하고, 정제된 산출물만으로 소통할 것.

4. 개발자의 최종 통제권 : AI에게 모든 결정을 위임하지 않고, 설계 승인과 최종 검토 등의 핵심 통제점을 개발자가 쥐고 있을 것.

Multi-Agent Workflow를 구축한 이후, 나만의 자율 에이전트 팀을 지휘하고 품질 게이트를 최종 승인하는 에이전트 리더로 역할이 진화했습니다. AI 코딩의 진정한 미래는 "더 거대한 단일 프롬프트"에 의존하는 것이 아니라, 자신의 프로젝트와 필요에 맞춰 가장 신뢰할 수 있는 협업 파이프라인을 직접 설계하고 진화시켜 나가는 것에 있습니다. 이제 각자의 기술 스택과 개발 환경에 딱 맞는 AI 자율 협업 팀을 구축해 보시길 바랍니다.

informalife