에이전트 간 페어 프로그래밍

source https://axeldelafosse.com/blog/agent-to-agent-pair-programming

Claude와 Codex를 페어 프로그래머처럼 함께 일하게 만들고, 둘이 직접 대화하게 할 수 있다면 어떨까요? 한쪽은 메인 작업자, 다른 한쪽은 리뷰어 역할을 맡는 식입니다.

흥미로운 점은, 최고의 agentic workflow가 의외로 사람 협업과 아주 비슷하게 생겼다는 겁니다. Cursor 연구진도 장시간 실행되는 코딩 에이전트를 연구하면서 같은 점을 발견했고, 그 결과 메인 orchestrator가 worker들에게 작업을 나눠 주는 멀티 에이전트 워크플로를 만들었습니다. 이건 대부분의 인간 팀이 일하는 방식과도 닮아 있습니다. Claude Code의 “Agent teams”나 Codex의 “Multi-agent” 기능도 기본 구조는 비슷합니다. 서브에이전트가 메인 에이전트에게 보고하는 식입니다. 앞으로는 서브에이전트끼리도 사람처럼 서로 상호작용하게 될 수 있습니다.

저는 여러 agent harness를 활용해 사람 협업을 흉내 내는 방향, 그리고 프로그래머들이 익숙하게 쓰는 또 다른 협업 방식인 페어 프로그래밍에 이 아이디어를 적용해 보고 싶었습니다. Claude와 Codex를 나란히 두고 코드 리뷰 에이전트를 만들던 중 재미있는 점을 발견했습니다. 둘은 서로 다른 피드백을 주기도 했고, 같은 피드백을 줄 때도 있었습니다. 그런데 같은 피드백이 겹쳐도 전혀 거슬리지 않았습니다. 오히려 아주 강한 신호로 느껴졌습니다. 우리 팀은 두 리뷰어가 모두 동의한 피드백은 100% 반영합니다. 코드 리뷰는 원래 사람과 에이전트가 함께 일하는 멀티플레이어 앱 같은 성격이라 매우 유용하지만, 피드백 루프를 느리게 만들고 때로는 노이즈도 생깁니다.

그래서 loop를 만들었습니다. claude와 codex를 tmux 안에서 나란히 띄우고, 둘이 서로 대화할 수 있도록 브리지를 붙인 아주 단순한 CLI입니다. 이 방식은 피드백 루프를 더 빠르고 자연스럽게 만들고, 반복 과정에서 컨텍스트도 유지해 줍니다. 특히 에이전트끼리의 상호작용이 더 자연스러워지기 때문에, 두 에이전트가 더 능동적으로 움직일 수 있다는 점이 흥미롭습니다. 모델이 더 좋아질수록 이 장점도 더 커질 거라고 봅니다. 또 loop는 인터랙티브 TUI를 그대로 실행하기 때문에, 사람이 중간에 계속 개입하면서 방향을 조정하고, 질문에 답하고, 필요하면 바로 후속 대응도 할 수 있습니다.

앞으로의 agentic workflow는 마법 같은 자동화라기보다, 익숙한 팀워크에 더 가까운 모습이 될지도 모릅니다. 그리고 이 페어 프로그래밍 워크플로에도 적용해 볼 만한 관찰들이 꽤 많다고 생각합니다. 예를 들면 사람이 최종적으로 넘겨받는 순간이나 PR 리뷰를 더 쉽게 만들려면 이런 질문들이 남습니다.

• 작업을 여러 PR로 나눠야 할까?

• PLAN.md는 git에 넣는 게 좋을까, 아니면 PR 설명에 담는 게 좋을까?

• 작업 증빙으로 스크린샷이나 영상 녹화를 함께 남겨야 할까?

에이전트끼리 계속 loop를 돌리게 하면 예상보다 변경 범위가 커질 수 있는데, 대체로 반가운 변화이긴 해도 사람 입장에서는 리뷰가 더 어려워집니다.

지금도 많은 사람들이 여러 agent harness를 다양한 이유로 함께 쓰고 있습니다. 벤더 락인을 피하려고, 오픈소스 프로젝트를 직접 쓰고 기여하려고, 구독 한도를 최대한 활용하려고, 혹은 서로 다른 관점과 강점, 결과를 얻고 싶어서입니다. 앞으로 멀티 에이전트 harness 앱은 agent-to-agent communication을 일급 기능으로 다뤄야 할 것 같습니다. 이런 방향을 더 많은 도구가 채택하면 좋겠습니다.

https://github.com/axeldelafosse/loop

반응들:

• 멀티 에이전트 구성이 실제로 얼마나 효과적인지, 아직은 체계적으로 검증된 데이터보다 사례 중심 얘기가 많음

  • 지금 단계에서는 “된다”는 경험담은 많지만, 얼마나 안정적으로 좋아지는지는 더 측정이 필요함

• Claude가 작업하고 Codex가 리뷰하는 조합은 꽤 잘 맞음

  • 특히 Claude가 왜, 어디를, 어떻게 바꿨는지 문서까지 남기면 Codex가 문제를 더 잘 잡음

• 실제로는 Claude가 완전히 끝낸 것처럼 보여도, Codex가 보면 이슈를 찾는 경우가 꽤 많음

• 운영 업무 쪽 agent-to-agent 협업도 가능함

  • 예를 들면 한 에이전트가 DB 이상 징후를 감지하고, 다른 에이전트가 자동 복구하는 식의 흐름

  • 다만 그런 운영 자동화는 “한 문제를 둘이 같이 푸는 페어 작업”과는 조금 다른 문제임

    • Agent detect -> agent solve -> agent review -> agent deploy 같은 워크플로는 이미 다른 축에서 기회가 큼

• 전반적으로 멀티 에이전트에 대해서는 더 실험이 필요하다고 느낌

• 지금 구현은 open-source인 Codex App Server 위에 잘 얹혀 있지만, Claude Code Channels 쪽은 다소 hacky함

  • 그래도 단순히 한 에이전트가 다른 에이전트를 호출하고 기다리거나, 공유 .md 파일을 읽고 쓰는 방식보다는 훨씬 좋음

• 여러 agent harness 전반에서 통할 수 있는 공통 방식으로 발전하면 좋겠음

• 실무에서는 코드 작성과 리뷰를 여러 라운드로 돌리는 방식이 큰 기능 작업에 꽤 효과적임

  • 버그를 줄이기 위해 10~15번 정도 fix/review를 반복하기도 함

• 프롬프트를 더 타이트하게 잡고, 중간에 plan review를 넣으면 반복 횟수를 많이 줄일 수 있음

  • 계획 단계 검토가 실제 품질에 중요한 영향을 줌

• Codex는 생성보다 리뷰, 감사, 꼬치꼬치 따지는 역할에 더 잘 맞고 Claude는 초안 생성이나 창의적인 작업 쪽에 더 강함

• 같은 모델로 self-review만 돌려도 차이가 큼

  • 첫 결과물이 생각보다 완성도가 낮음

이미 OpenCode, OpenClaw나 이런 류의 Agent SDK들이 많이 있어요.

잘 만들어진거 쓰거나 환경에 맞는거 쉽게 만들어서 쓰는 세상이지만…

자기 환경에 맞는 모델을 조합 + 라우팅해서 쓰는게 좋은거 다들 알고 있는데…

그만큼 시간과 돈을 투자해야하는 일이죠. (돈ㅇ….)

차세대 모델

OpenAI는 스퍼드(Spud)

Anthropic은 미토스(Mythos)

출시 소식들이 있는데, 결국 또 한 번 기준점이 바뀔 가능성이 크니 흐름을 놓치지 않는게 중요한 것 같네요.