Claude·Codex·Gemini를 한 팀으로 쓰는 AI 개발 하네스 — 멀티 에이전트 코딩 운영법
AI 코딩의 다음 단계는 “모델 하나를 더 오래 붙잡는 것”이 아니라, 역할을 나눠 컨텍스트를 분리하는 운영 설계다. 팬다스 스튜디오의 데모 영상은 Claude Code를 PM·코더, Gemini를 리서처, Codex를 리뷰어로 두고 로그 파일을 공유 메모리로 쓰는 실전형 하네스를 보여준다.
1. 영상이 보여준 구조: AI 개발팀을 “하네스”로 묶는다
영상의 출발점은 단순하다. Claude Code 하나에 계속 일을 시키면 처음에는 편하지만, 작업이 길어질수록 리서치, 코드 변경, 리뷰, 이전 대화가 한 세션 안에 섞인다. 비용은 늘고, 컨텍스트는 무거워지고, 본인이 만든 코드를 본인이 평가하는 구조가 된다. 그래서 데모는 세 가지 에이전트를 하나의 개발팀처럼 배치한다.
백로그를 읽고 작업을 분배한다. 필요한 경우 코드를 직접 수정하고, Gemini·Codex의 결과 로그를 읽어 다음 행동을 결정한다.
버전 변경, 의존성, 문서 기반 리서치를 맡는다. 프로덕션 코드를 직접 고치지 않고 조사 결과를 남긴다.
변경 사항을 별도 컨텍스트에서 점검한다. 치명적 버그, 주요 이슈, 선택적 개선 사항을 등급화한다.
공유 메모리는 대화창이 아니라 파일 로그다. 각 에이전트가 자기 역할의 결과를 로그로 남기고, Claude Code가 그 로그를 읽어 전체 상황을 통제한다. 이 구조는 사람 개발팀의 PM·리서처·리뷰어 분업을 터미널 환경에 옮긴 것에 가깝다.
2. 왜 단일 AI 세션은 점점 무거워지는가
AI 코딩 도구는 긴 대화를 잘 이어가는 것처럼 보이지만, 개발 작업은 성격이 다른 정보가 빠르게 섞인다. 요구사항, 코드베이스 탐색, 공식 문서 요약, 임시 추론, 이전 실패, 테스트 로그, 코드 리뷰 지적이 같은 컨텍스트에 쌓이면 모델은 무엇이 최신 사실이고 무엇이 폐기된 가정인지 구분하기 어려워진다.
이전 작업의 임시 판단이 뒤의 의사결정에 남아 간섭한다. 특히 마이그레이션·리팩터링처럼 조건이 많은 작업에서 흔하다.
같은 세션이 만든 코드를 같은 세션이 평가하면, 놓친 전제를 그대로 공유한다. 리뷰가 형식적으로 흐를 위험이 있다.
모든 정보를 한 모델에 몰아넣으면 입력 토큰이 늘고, 간단한 리서치나 리뷰까지 비싼 메인 세션이 처리하게 된다.
따라서 멀티 에이전트 하네스의 본질은 “AI를 많이 띄우기”가 아니라 각 작업에 필요한 정보만 들고 들어가는 작은 컨텍스트를 여러 개 운영하는 것이다.
3. 역할 분담은 이렇게 잡는 것이 합리적이다
영상의 배치는 꽤 현실적이다. Claude Code는 코드베이스를 읽고 명령을 실행하며 파일을 수정하는 메인 작업자에 적합하다. Gemini CLI는 터미널에서 ReAct 루프와 도구를 써서 리서치·문제 해결·태스크 관리를 수행할 수 있다는 점에서 조사 역할에 맞다. Codex CLI는 로컬 저장소를 읽고 수정·실행할 수 있는 코딩 에이전트이며, 별도 에이전트로 코드 리뷰를 돌릴 수 있다는 점에서 리뷰어 역할과 잘 맞는다.
| 역할 | 맡길 일 | 금지할 일 | 산출물 |
|---|---|---|---|
| PM·코더 | 백로그 해석, 작업 분배, 코드 수정, 최종 판단 | 공식 문서 확인 없이 추정으로 마이그레이션 결정 | 변경 요약, 테스트 결과, 다음 액션 |
| 리서처 | 공식 문서·변경 로그·이슈 조사, 대안 정리 | 프로덕션 코드 직접 수정, 코드 품질 판정 | 근거 링크, 변경 포인트, 적용 후보 |
| 리뷰어 | diff 점검, 버그·보안·호환성 이슈 등급화 | 요구사항 재정의, 리서치 전제 임의 변경 | 치명/주요/경미/선택 이슈 목록 |
역할을 잘게 쪼갤수록 중요한 것은 “누가 무엇을 하지 말아야 하는지”까지 정하는 것이다. 리서처가 코드를 고치고, 리뷰어가 요구사항을 다시 쓰기 시작하면 분업의 장점은 사라진다.
4. 데모의 운영 포인트: 로그 파일이 팀의 공용 작업일지가 된다
데모는 tmux 멀티 페인을 이용해 왼쪽에는 Claude Code, 오른쪽 위에는 Gemini 리서치 대시보드, 오른쪽 아래에는 Codex 리뷰 대시보드를 둔다. 겉으로는 화면 구성처럼 보이지만, 핵심은 각 에이전트의 실행 결과가 로그 파일에 남고 그 로그가 다음 판단의 입력이 된다는 점이다.
메인 에이전트가 작업 번호와 코드베이스를 읽고 필요한 리서치·리뷰 범위를 결정한다.
Gemini가 문서와 변경 사항을 조사하고, 적용해야 할 패턴과 주의점을 로그로 남긴다.
Claude Code가 리서치 결과를 반영해 실제 파일을 고치고, 변경 이유를 정리한다.
Codex가 별도 컨텍스트에서 diff를 확인하고, 이슈를 등급화해 보고한다.
메인 에이전트가 리뷰 지적을 수용하거나 반려하고, 필요하면 추가 리뷰를 요청한다.
이 흐름은 특히 의존성 업그레이드, 프레임워크 마이그레이션, 보안 패치, 대규모 리팩터링처럼 조사와 구현과 리뷰가 분리되어야 하는 작업에 적합하다.
5. 장점은 분명하지만, 작은 작업에는 과하다
멀티 에이전트 패턴은 모든 작업을 자동으로 개선하지 않는다. 버튼 문구 수정, CSS 한 줄 변경, 단순 파일 정리까지 세 모델을 호출하면 비용과 시간이 낭비된다. 반대로 실수 비용이 큰 작업에서는 효과가 커진다.
- 라이브러리·프레임워크 버전 업그레이드
- API 변경 대응과 마이그레이션
- 보안·권한·데이터 손실 위험이 있는 변경
- 테스트가 실패했지만 원인이 복합적인 버그
- 새 기능 설계와 기존 코드 영향 분석
- 문구·주석·작은 스타일 수정
- 이미 원인이 명확한 단일 파일 변경
- 테스트 없이 결과를 판단할 수 없는 실험성 요청
- 로그 포맷이 없어 결과를 재사용하기 어려운 작업
- 승인 절차가 너무 잦아 흐름이 끊기는 작업
도입 기준은 “AI가 몇 개냐”가 아니라 “실수 비용이 분업 비용보다 크냐”다. 개발팀에서 코드 리뷰를 생략하면 위험한 작업이라면 멀티 에이전트 구조를 고려할 만하다.
6. 실제로 도입하려면 네 가지 규칙부터 정해야 한다
영상의 패턴을 그대로 따라 하기 전에, 팀 또는 개인 프로젝트의 운영 규칙을 먼저 정리해야 한다. 이 규칙이 없으면 에이전트가 많아질수록 결과가 더 흩어진다.
| 규칙 | 정해야 할 내용 | 실무 기준 |
|---|---|---|
| 호출 기준 | 언제 Gemini와 Codex를 부를지 | 문서 확인이 필요하면 리서처, diff 위험이 있으면 리뷰어 호출 |
| 로그 포맷 | 각 에이전트가 어떤 형식으로 남길지 | 요약, 근거, 변경 파일, 위험, 다음 액션을 고정 필드로 둔다 |
| 권한 경계 | 누가 코드를 수정하고 누가 읽기만 할지 | 리서처는 읽기 전용, 리뷰어는 diff 중심, 메인만 수정 권한 |
| 재리뷰 조건 | 어떤 지적 후 다시 리뷰를 돌릴지 | 치명·주요 이슈 수정 후에는 재리뷰 또는 테스트를 필수화 |
가장 중요한 것은 권한 경계다. 에이전트가 모두 파일을 고치면 책임 소재가 흐려진다. 처음에는 “메인만 수정, 서브는 읽기·보고”로 시작하는 편이 안전하다.
7. 리스크: 자동화가 늘수록 실패도 자동화된다
따라서 하네스에는 최소한 세 가지 방어선이 필요하다. 첫째, 공식 문서나 원문 링크를 로그에 남긴다. 둘째, 리뷰어에게는 전체 저장소가 아니라 관련 diff와 요구사항을 명확히 제공한다. 셋째, 최종 병합 전에는 테스트·타입체크·빌드 같은 기계적 확인을 반드시 거친다.
또 하나의 현실적 리스크는 비용이다. 세 모델을 병렬 또는 순차로 호출하면 단일 세션보다 호출 수가 늘어난다. 다만 리서치·리뷰를 더 저렴하거나 더 적합한 모델에 맡겨 메인 세션의 토큰 누수를 줄이면, 복잡한 작업에서는 총비용이 오히려 관리될 수 있다.
8. 결론: AI 개발팀은 “역할 설계”가 성패를 가른다
이번 데모의 의미는 Claude, Codex, Gemini 중 무엇이 더 우월한지 비교하는 데 있지 않다. 서로 다른 모델의 강점을 역할로 분리하고, 파일 로그를 통해 협업 가능한 형태로 묶었다는 점이 중요하다. 단일 모델을 만능 작업자로 쓰는 단계에서, AI 에이전트를 작은 개발 조직처럼 운영하는 단계로 넘어가는 사례다.
실무적으로는 다음 순서가 좋다. 먼저 단일 프로젝트에서 “리서치 전용 에이전트”와 “리뷰 전용 에이전트”만 붙인다. 그 다음 로그 포맷을 고정한다. 마지막으로 반복되는 백로그 유형에만 자동 호출 규칙을 둔다. 처음부터 완전 자동 팀을 만들기보다, 실수 비용이 큰 작업부터 제한적으로 적용하는 편이 성과가 빠르다.