Agent-to-Agent Pair Programming: Claude와 Codex를 짝 프로그래머로 함께 돌리기

TL;DR Highlight

CLI 툴 loop는 Claude와 Codex를 tmux에서 동시 실행하여 개발자와 리뷰어 역할로 상호 대화하는 페어 프로그래밍을 구현한다.

Who Should Read

Claude Code나 Codex 같은 AI 코딩 에이전트를 실무에 도입해서 쓰고 있는 개발자 중, 단일 에이전트의 한계를 느끼고 멀티 에이전트 워크플로우를 실험해보고 싶은 사람.

Core Mechanics

저자는 Claude와 Codex를 코드 리뷰에 나란히 써보다가 흥미로운 패턴을 발견했다. 두 에이전트가 같은 피드백을 줄 때 그건 노이즈가 아니라 오히려 강한 신호였고, 팀 내에서 두 리뷰어가 동의하는 피드백은 100% 반영하는 규칙을 자연스럽게 만들게 됐다.
이를 바탕으로 'loop'라는 CLI 툴을 만들었다. tmux 위에서 claude와 codex를 나란히 띄우고, 두 에이전트 사이에 직접 메시지를 주고받을 수 있는 브릿지를 연결해주는 단순한 도구다. GitHub에 오픈소스로 공개되어 있다(https://github.com/axeldelafosse/loop).
loop는 interactive TUI(터미널 UI)를 그대로 사용하기 때문에 사람이 중간에 개입할 수 있다. 질문에 답하거나, 방향을 수정하거나, 후속 지시를 내릴 수 있어서 완전 자동화가 아니라 '루프 안에 머무는' 방식으로 설계됐다.
Cursor 연구팀이 장기 실행 코딩 에이전트 연구에서 발견한 것처럼, 잘 작동하는 에이전트 워크플로우는 인간 팀 협업 구조와 닮아 있다. Claude Code의 'Agent teams'나 Codex의 'Multi-agent' 기능도 메인 에이전트가 서브에이전트에게 작업을 배분하는 구조인데, 저자는 여기서 한 발 더 나아가 서브에이전트끼리 직접 소통하게 만들었다.
에이전트를 계속 루프로 돌리면 예상보다 더 많은 코드 변경이 일어날 수 있다. 저자는 이를 대체로 긍정적으로 보지만, 인간이 나중에 리뷰할 때 변경량이 너무 많아져서 어려워지는 문제가 생긴다. 이를 해결하기 위한 open question으로 PR을 여러 개로 분리할지, PLAN.md를 git이나 PR 설명에 공유할지 등을 언급하고 있다.
여러 에이전트 툴을 동시에 쓰는 이유는 다양하다. 벤더 락인(vendor lock-in) 회피, 오픈소스 기여, 구독 한도 최대 활용, 또는 각 모델의 강점과 관점 차이를 활용하기 위해서다. 저자는 멀티 에이전트 앱들이 에이전트 간 통신을 일급 기능(first-class feature)으로 지원해야 한다고 주장한다.
저자의 경험에 따르면 Claude는 생성과 창의적 작업에 강하고, Codex는 꼼꼼하고 정확한 감사(audit)와 비판적 리뷰에 강하다. 두 모델의 성격 차이가 페어 프로그래밍 역할 분담에 자연스럽게 맞아떨어진다는 관찰이다.

Evidence

실제로 비슷한 방식을 쓰고 있다는 경험담이 있었다. Claude가 작업을 완료했다고 표시한 결과물을 Codex에게 리뷰시켰더니, Claude가 작업을 완전히 성공적으로 마친 경우는 매우 드물었고 Codex가 거의 항상 문제를 찾아냈다는 것이다. 특히 Claude에게 작업 결과를 'why/where/how' 문서로 정리하게 한 뒤 Codex에게 넘기면 리뷰 품질이 좋아진다는 팁도 공유됐다.
멀티 에이전트 설정의 효과가 실제로 '여러 에이전트'여서인지 아니면 '두 가지 설정(system prompt, model, temperature, context pruning, toolset 등)을 교대로 적용'하는 것 자체의 효과인지 구분하기 어렵다는 회의적인 의견도 있었다. 즉, 핵심은 에이전트 수가 아니라 다른 관점과 설정을 도입하는 것일 수 있다는 지적이다.
PLAN.md를 git이나 PR에 넣는 아이디어에 대해 날카로운 반론이 나왔다. PLAN.md가 git에 들어가는 순간 그건 이미 '구현 계획의 다운스트림'이 되어버린다. 실제로 중요한 것은 원래 의도(intent)인데, 계획에서 구현이 어긋났을 때 왜 그 결정이 내려졌는지 추적하기가 더 어려워진다는 주장이다.
페어 프로그래밍 자체가 사람한테도 잘 안 맞는다는 의견이 있었다. 머릿속의 복잡한 사고 과정을 실시간으로 말로 설명하기가 어렵고, 옆에서 보면 코드를 무작위로 바꾸는 것처럼 보인다는 것이다. 이 댓글은 AI 에이전트에 인간 협업 패턴을 적용하는 것 자체에 회의적인 시각을 담고 있다.
멀티 에이전트에 대한 체계적인 측정이 부족하다는 지적이 반복됐다. 대부분의 증거가 아직 일화적(anecdotal)이고, '바이브는 좋지만 과학이 필요하다'는 표현이 여러 댓글에 나왔다. 유사한 툴로 claude-review-loop(https://github.com/hamelsmu/claude-review-loop)가 언급되기도 했다.

How to Apply

Claude Code와 Codex 구독을 둘 다 쓰고 있다면, `loop` CLI를 설치해서 Claude가 코드를 작성하고 Codex가 리뷰하는 페어 프로그래밍 워크플로우를 실험해볼 수 있다. 두 에이전트가 동의하는 피드백을 '반드시 반영' 규칙으로 삼으면 리뷰 노이즈를 줄이면서 중요한 이슈를 놓치지 않을 수 있다.
Claude에게 작업을 완료한 후 why/where/how 형태의 작업 요약 문서를 작성하게 하고, 이를 Codex에게 리뷰 컨텍스트로 넘기면 리뷰 품질이 향상된다. 이 패턴은 loop 없이도 수동으로 즉시 적용 가능하다.
에이전트 루프가 예상보다 많은 변경을 만들어내는 문제가 있다면, PR을 기능 단위로 작게 쪼개거나 에이전트에게 변경 범위를 명시적으로 제한하는 시스템 프롬프트를 추가하는 것이 좋다. '스코프를 벗어난 변경은 별도 이슈로 기록만 하고 수정하지 말 것'처럼 명시하면 인간 리뷰 부담을 줄일 수 있다.

Terminology

TUITerminal User Interface의 약자로, 터미널 안에서 키보드로 조작하는 텍스트 기반 인터페이스. Claude Code나 Codex의 대화형 터미널 화면이 여기에 해당한다.

tmux터미널 멀티플렉서(multiplexer). 하나의 터미널 창을 여러 개의 독립 창으로 분할하거나 세션을 유지해주는 CLI 도구. loop는 이걸 이용해 Claude와 Codex를 나란히 실행한다.

vendor lock-in특정 공급사의 서비스나 API에 종속되어 다른 곳으로 이동하기 어려워지는 상황. 여러 AI 에이전트를 병행 사용하면 이 리스크를 분산할 수 있다.

orchestrator멀티 에이전트 시스템에서 전체 작업을 조율하고 서브에이전트들에게 세부 작업을 분배하는 메인 에이전트. 팀장 역할에 해당한다.

first-class feature소프트웨어에서 기능이 부가적으로 끼워진 게 아니라 핵심 설계 원칙으로 지원된다는 의미. 저자는 에이전트 간 통신이 앱의 주변 기능이 아닌 핵심 기능으로 지원돼야 한다고 주장하는 맥락에서 사용했다.

PLAN.md에이전트가 작업을 시작하기 전 계획을 정리해두는 마크다운 파일. 에이전트의 작업 의도와 방향을 문서화하는 용도로 활용되며, git에 포함하거나 PR 설명에 첨부하는 방식이 논의됐다.