Chapter 6: 검증 가능한 바이브 코딩 — 멀티에이전트로 작업·검증·리뷰 분리
6.1 이 주제의 테제를 증명하는 버그
멀티에이전트 셋업 코드를 한 줄 쓰기 전에, Codex GitHub issue #11354 [contributors, 2026]를 먼저 보자. 사용자가 config에 subagents = false를 설정하고 /review를 실행했다. 결과: Codex의 /review 명령이 서브에이전트를 다시 활성화했다 — 명시적 config 설정을 덮어쓴 것이다. 사용자의 명시적 설정이 모델의 동작을 통제하지 못했다. config 파일이 권위를 갖지 않은 것이다.
이것이 검증 가능한 바이브 코딩이 왜 필요한지에 대한 가장 강력한 논거다: 자신이 설정한 것도 항상 믿을 수 없는데, 단일 에이전트가 생산하고 스스로 검토한 것은 더욱 믿을 수 없다. 도구가 명시적 설정을 조용히 무시할 수 있다면, 독립적 검증은 선택이 아니라 유일한 신뢰 가능한 검사다.
원칙이 그렇다. 실제로는 어떻게 보이는가. Mejba Ahmed가 실험을 했다: Claude Code 안에서 Codex를 서브에이전트로 실행했다 [Ahmed, 2026]. 결과: "작업이 분리됐다." Claude Code가 설계를 하면, Codex가 구현을 하고, 다시 Claude Code가 리뷰를 한다. 같은 에이전트가 자신의 작업을 검토하지 않으니, 맹점이 줄었다.
이게 이 챕터의 핵심 아이디어다: 검증 가능한 바이브 코딩은 작업·검증·리뷰를 다른 에이전트가 담당하게 분리하는 것이다.
"바이브 코딩(vibe coding)"은 자연어로 코드를 생성하는 LLM 기반 개발 방식이다 [Korean Dev Blog, 2026]. 이것의 문제는 기본적으로 검증 불가능하다는 것이다. 멀티에이전트로 분리하면 검증 가능해진다. config-override 버그는 왜 하네스 자체에도 외부 검사가 필요한지를 보여준다.
6.2 두 가지 메커니즘
Claude Code: Agent Teams
Anthropic의 Agent Teams [Anthropic, 2026]는 다음을 제공한다:
- 공유 태스크 리스트: 모든 에이전트가 같은 태스크를 보고, 리프 태스크를 "claim"해서 실행
- 파일 잠금: 에이전트가 파일을 편집하기 전 lock을 획득 — 충돌 방지
- SendMessage: peer 에이전트에게 직접 메시지 전송
- 이벤트 훅:
TeammateIdle,TaskCreated,TaskCompleted훅으로 에이전트 반응 트리거
실험적 결론: "3-5명의 팀원 / 팀원당 5-6개 태스크"가 최적이다 [Anthropic, 2026]. "3명의 집중된 팀원이 5명의 산만한 팀원보다 자주 낫다."
Codex: TOML 서브에이전트
Codex에서는 .codex/agents/ 폴더의 TOML 파일로 전문 에이전트를 정의하고, 오케스트레이터 에이전트가 이들을 호출한다 [OpenAI, 2026]. 복잡한 런타임 협업보다 단순하지만, 작업 분리에는 충분하다.
6.3 검증 가능한 바이브 코딩의 네 가지 패턴
각 패턴: (a) 언제 쓰는가, (b) Claude Code에서의 셋업, (c) Codex에서의 셋업, (d) 실패 모드.
패턴 A: 구현–검증 분리
한 에이전트가 구현하고, 다른 에이전트가 테스트를 작성하고, 세 번째 에이전트가 리뷰한다.
언제: 새 기능 구현 시.
Claude Code 셋업:
# TaskCreate 의존성 그래프
Task 1: implement-auth-endpoint
Task 2: write-auth-tests [blocked_by: implement-auth-endpoint]
Task 3: review-auth [blocked_by: write-auth-tests]
Codex 셋업:
# .codex/agents/implementer.toml
name = "implementer"
developer_instructions = "Implement the feature. Write the code only. Do not write tests."
# .codex/agents/tester.toml
name = "tester"
developer_instructions = "Write Jest tests for the implemented feature. Use mocks. Aim for 80% coverage."
# .codex/agents/reviewer.toml
name = "reviewer"
developer_instructions = "Review the implementation and tests. Check for security issues and edge cases."
실패 모드: 구현 에이전트와 테스트 에이전트가 같은 가정을 공유하면 테스트가 무의미해진다. 테스트 에이전트에게 "구현 파일을 읽지 말고 스펙에서만 테스트를 작성하라"고 지시하면 완화된다.
패턴 B: 적대적 리뷰 (Dual-engine)
두 다른 모델/에이전트가 같은 코드를 독립적으로 리뷰한다.
언제: 중요한 코드 변경, 보안 관련 코드.
Claude Code + Codex 조합: Mejba의 실험처럼 [Ahmed, 2026], Claude Code가 설계·리뷰를 하고 Codex가 구현을 하면 두 모델의 맹점이 겹치지 않는다.
실패 모드: 두 에이전트가 같은 학습 데이터에서 온 것이라면 같은 실수를 한다. 진정한 독립성은 다른 모델을 쓸 때만 보장된다.
패턴 C: 의존성 그래프 실행
복잡한 기능을 DAG(Directed Acyclic Graph)로 분해하고 병렬 실행한다.
언제: 여러 독립 모듈을 동시에 개발할 때.
아래는 "결제 시스템 구현" 태스크를 DAG로 분해한 예시다:
[결제 모델 정의] → [결제 서비스 구현] → [결제 컨트롤러]
↗
[결제 검증 로직] ──────────────────────
↑
[Stripe API 클라이언트]
Claude Code에서는 TaskCreate + addBlockedBy로 이 그래프를 선언한다 [Anthropic, 2026]. 에이전트들이 리프 태스크(선행 의존성 없는 태스크)부터 자율적으로 claim해서 실행한다.
Codex에서는 오케스트레이터 에이전트가 이 순서를 관리하고 각 서브에이전트에게 태스크를 할당한다.
실패 모드: 의존성을 너무 세밀하게 쪼개면 오버헤드가 커진다. "의존성이 없는 태스크들만 병렬화한다"는 원칙을 지킨다.
패턴 D: 점진적 구축
한 번에 큰 기능을 구현하는 것이 아니라 작은 검증된 단계로 점진적으로 쌓는다.
언제: 복잡한 시스템, 실패 위험이 높은 변경.
[brunch), 2026]의 멀티에이전트 회고에서 가장 중요한 교훈: "반복적(iterative)이 선행 계획(upfront)보다 낫다." 에이전트에게 전체 설계를 먼저 내고 구현하게 하는 것보다, 최소한의 스켈레톤 → 기능 1개 → 기능 2개 순서로 단계마다 검증하면서 진행하는 것이 더 안전하다.
6.4 네 가지 안티패턴 (피해야 할 것)
[brunch), 2026]의 한국 개발자 멀티에이전트 회고에서 추출한 실패 패턴:
- "협업 = 릴레이"의 오해: 에이전트 A가 완료하면 에이전트 B에게 넘기는 릴레이 방식은 진짜 협업이 아니다. 에이전트들이 공유 상태를 보고 동시에 작업해야 한다.
- "미리 구조화하면 더 좋다"의 오해: 태스크를 너무 세밀하게 쪼개고 의존성을 복잡하게 선언하면 실제 작업보다 오케스트레이션 오버헤드가 커진다.
- "오케스트레이터 = 컨트롤러"의 오해: 오케스트레이터가 모든 것을 제어하려 하면 병목이 된다. 오케스트레이터는 의존성을 선언하고 팀원들이 자율적으로 실행하도록 해야 한다.
- "더 많은 에이전트 = 더 빠른 결과"의 오해: Anthropic의 실험 결과 3-5명이 최적이다 [Anthropic, 2026]. 더 많으면 coordination overhead가 gains를 잡아먹는다.
6.5 MorphLLM 벤치마크의 시사점
MorphLLM이 블라인드 리뷰어들에게 Claude Code와 Codex의 결과물을 보여준 연구 [MorphLLM, 2026]: 리뷰어들이 출처를 모를 때 Claude Code 결과를 67:25로 선호했다. Terminal-Bench에서는 Codex가 이겼다.
이것이 왜 "검증 가능한" 바이브 코딩이 필요한지를 보여준다: 벤치마크 점수는 실제 선호와 다르다. 에이전트 자신의 평가(벤치마크)는 독립 검증(블라인드 리뷰)과 다를 수 있다. 멀티에이전트 분리는 이 갭을 줄이는 메커니즘이다.
참고문헌
- Anthropic, "Agent Teams," 2026. [Anthropic, 2026]
- Anthropic, "Subagents," 2026. [Anthropic, 2026]
- Mejba Ahmed, "I ran Codex inside Claude Code," 2026. [Ahmed, 2026]
- B327Roy, "Multi-agent retrospective (Korean)," 2026. [brunch), 2026]
- MorphLLM, "Codex vs Claude Code Benchmark," 2026. [MorphLLM, 2026]
- OpenAI, "Codex subagents," 2026. [OpenAI, 2026]
- Korean Developer, "바이브 코딩 플레이리스트," 2026. [Korean Dev Blog, 2026]
- Intuition, "Codex as superapp — multi-agent guide," 2026. [IntuitionLabs, 2026]
- Jagtap, "Codex AGENTS.md auto-optimization," 2026. [Jagtap, 2026]
- GitHub, "Codex subagents issue #11354 — /review가 config 무시하고 서브에이전트 재활성화," 2026. [contributors, 2026]