― AI 코딩 에이전트를 어떻게 분담·관리할 것인가

1. 서론

Claude Code나 Codex CLI와 같은 AI 코딩 에이전트를 사용하다 보면 다음과 같은 과제가 발생합니다.

• 하나의 에이전트만으로는 해결할 수 없는 문제를 다른 에이전트에게도 조사하게 하고 싶다
• 구현 담당과 리뷰 담당을 나누고 싶다
• 프론트엔드, 백엔드, 테스트를 병렬로 진행하고 싶다
• 여러 에이전트가 어디까지 작업하고 있는지 파악하고 싶다
• 동시 편집으로 인한 파일 덮어쓰기나 Git 충돌을 피하고 싶다

이러한 과제에 대한 접근법으로서, 본 문서에서는 다음 두 가지를 비교합니다.

openai/codex-plugin-cc

Claude Code 안에서 Codex에게 작업을 위임하는 플러그인

Herdr

여러 AI 코딩 에이전트를 하나의 터미널 위에서 병렬 관리하는 도구

두 가지는 용도가 비슷해 보이지만, 실제로는 역할이 다릅니다.

codex-plugin-cc는 "Claude Code에서 Codex로 일을 부탁하는 메커니즘"

Herdr는 "여러 에이전트를 구동하여 감독하는 작업 환경"

따라서 어느 한쪽이 항상 우월한 것은 아닙니다.

개발 규모, 태스크의 분할 용이성, 관리에 투입할 수 있는 비용에 따라 최적의 선택이 달라집니다.

2. 전제가 되는 용어

2.1 AI 코딩 에이전트란

AI 코딩 에이전트란 자연어 지시를 받아 코드베이스를 조사하거나, 파일을 편집하거나, 테스트 및 명령어를 실행하는 AI 도구입니다.

대표적인 예로 다음과 같은 도구들이 있습니다.

• Claude Code
• Codex CLI
• OpenCode
• Gemini CLI

일반적인 채팅 AI와 달리, 단순히 코드 예시를 답변하는 것에 그치지 않고 로컬 프로젝트 내에서 실제로 작업을 진행할 수 있다는 점이 특징입니다.

2.2 Claude Code란

Claude Code는 Anthropic이 제공하는 터미널형 AI 코딩 에이전트입니다.

프로젝트 파일을 조사하고, 코드 변경, 명령어 실행, 테스트, 디버깅 등을 수행할 수 있습니다. 통상적으로 사용자가 Claude Code와의 대화를 중심으로 개발을 진행합니다.

사용자
↓
Claude Code
...

2.3 Codex CLI란

Codex CLI는 OpenAI가 제공하는 터미널형 AI 코딩 에이전트입니다.

Claude Code와 마찬가지로 리포지토리 조사, 코드 변경, 테스트, 리뷰 등을 실행할 수 있습니다.

Claude Code와 Codex는 서로 다른 모델·제품이기 때문에, 동일한 문제에 대해 서로 다른 관점이나 해결 방법을 제시할 수 있습니다. 따라서 한쪽을 구현 담당으로, 다른 한쪽을 리뷰 담당으로 사용하는 방법도 유효합니다.

2.4 터미널 멀티플렉서란

터미널 멀티플렉서(Terminal Multiplexer)란 하나의 터미널 화면 안에 여러 작업 영역을 만들고, 각각에서 별도의 프로세스를 구동하기 위한 도구입니다.

대표적인 도구로는 tmux나 Zellij가 있습니다.

┌─────────────────────────┐
│ Claude Code │
│ 프론트엔드 구현 중 │
...

Herdr는 이 터미널 멀티플렉서를 AI 코딩 에이전트용으로 확장한 도구입니다.

3. openai/codex-plugin-cc란

openai/codex-plugin-cc는 Claude Code 안에서 Codex를 호출할 수 있는 OpenAI 공식 플러그인입니다.

Claude Code를 메인 작업 환경으로 사용하면서, 필요한 상황에서만 Codex에게 작업을 위임할 수 있습니다.

3.1 기본 구조

사용자
↓
Claude Code
...

Claude Code와 Codex를 대등한 작업자로 나열한다기보다, Claude Code를 중심으로 두고 Codex를 전문 담당자나 보조 담당자로 호출하는 구성입니다.

3.2 주요 명령어

일반적인 코드 리뷰

/codex:review

현재 커밋되지 않은 차분(diff)이나 지정한 브랜치와의 차분을 Codex에게 리뷰하게 합니다.

/codex:review --base main

이 리뷰는 읽기 전용이며, 코드를 직접 수정하지 않습니다.

구현 방침을 포함한 엄격한 리뷰

/codex:adversarial-review

단순한 버그 지적뿐만 아니라, 다음과 같은 관점에서 구현을 검증합니다.

• 선택한 설계가 정말 타당한가
• 더 단순하거나 안전한 방법은 없었는가
• 인증, 데이터 손실, 경쟁 상태 (Race Condition) 등의 리스크는 없는가
• 전제 조건이나 트레이드오프 (Trade-off)를 간과하지 않았는가

Codex로의 작업 위임

/codex:rescue 테스트가 실패하는 원인을 조사해 주세요

/codex:rescue

는 Codex에 조사나 수정을 맡기기 위한 명령입니다.

주요 용도는 다음과 같습니다.

• 버그 원인 조사
• 실패하는 테스트 수정
• Claude Code에서 해결하지 못한 문제의 재조사
• 이전 Codex 작업의 계속
• 다른 모델을 이용한 세컨드 오피니언 (Second Opinion)

Claude Code에서 Codex로의 인계

/codex:transfer

Claude Code에서 진행하던 대화 내용을 Codex의 지속 가능한 세션으로 변환합니다.

Claude Code에서 조사를 시작했지만, 그 이후는 Codex 측에서 집중적으로 진행하고 싶을 때 이용할 수 있습니다.

백그라운드 처리 관리

/codex:status
/codex:result
/codex:cancel

장시간 소요되는 리뷰나 조사를 백그라운드에서 실행하고, Claude Code 측에서 다른 작업을 계속할 수 있습니다.

4. codex-plugin-cc의 장점

4.1 Claude Code를 벗어나지 않고 Codex를 이용할 수 있음

별도의 터미널을 열고, Codex를 실행하여 상황을 처음부터 다시 설명할 필요가 없습니다.

일상적으로 Claude Code를 이용하는 팀에서는 조작 방법을 크게 바꾸지 않고 Codex를 도입할 수 있습니다.

4.2 구현과 리뷰를 서로 다른 모델로 나누기 쉬움

예를 들어, 다음과 같은 흐름을 간단히 구축할 수 있습니다.

Claude Code가 구현
↓
Codex가 리뷰
...

동일한 에이전트가 자신의 변경 사항을 셀프 리뷰하는 것보다, 서로 다른 모델에게 확인하게 함으로써 간과하는 부분을 줄일 수 있습니다.

4.3 작은 규모의 위임에 적합함

다음과 같이 범위가 비교적 명확한 태스크와 궁합이 좋습니다.

• CI에서만 실패하는 원인을 조사하기
• 특정 테스트를 수정하기
• 인증 처리의 리스크를 리뷰하기
• 변경 사항(Diff)을 배포 전에 확인하기

4.4 도입 및 학습 비용이 낮음

Claude Code를 중심으로 한 기존 개발 흐름을 유지할 수 있습니다.

Codex는 로컬의 Codex CLI, 인증 정보, 설정, 리포지토리 체크아웃을 이용하므로, 이미 Codex CLI를 이용하고 있다면 설정을 공유할 수 있습니다.

5. codex-plugin-cc의 단점과 주의점

5.1 Claude Code에서 Codex로 이어지는 부모-자식 구조가 기본

기본 구조는 다음과 같습니다.

Claude Code → Codex

Claude Code, Codex, OpenCode 등 여러 에이전트를 대등하게 나열하여 본격적으로 작업을 분담하는 용도로는 적합하지 않습니다.

5.2 실행 중인 화면을 상시 모니터링하는 용도에는 취약함

백그라운드 태스크의 진행 상황은 주로 /codex:status나 /codex:result로 확인합니다.

Codex가 실행 중인 명령어나 대화 화면을 항상 옆에 띄워놓고 모니터링하는 방식으로는 Herdr가 더 적합합니다.

5.3 동일한 리포지토리와 작업 환경을 공유함

codex-plugin-cc는 Claude Code와 동일한 로컬 환경, 동일한 리포지토리 체크아웃을 사용합니다.

따라서 Claude Code와 Codex가 동시에 같은 파일을 편집하면 다음과 같은 문제가 발생할 가능성이 있습니다.

• 변경 사항 덮어쓰기
• 차분(Diff)의 혼재
• 의도하지 않은 수정 사항의 포함
• 테스트 실행 중 상태 변화

여러 쓰기 작업을 동시에 실행할 경우에는 담당 파일을 명확히 나누어야 합니다.

5.4 Claude와 Codex 양쪽의 사용량을 모두 소비함

Claude Code를 구동하면서 Codex 측에서도 별도의 처리를 실행하기 때문에, 각각의 사용량을 소비합니다.

특히 자동 리뷰를 통해 Claude와 Codex가 수정과 재리뷰를 반복하도록 설정한 경우, 사용량이 급격히 늘어날 수 있습니다.

6. Herdr란

Herdr는 여러 AI 코딩 에이전트 (AI Coding Agent)를 하나의 터미널 내에서 관리하기 위한 에이전트용 터미널 멀티플렉서 (Terminal Multiplexer)입니다.

각 에이전트는 각각 독립된 실제 터미널 위에서 동작합니다.

Herdr
├─ Claude Code
│ └─ 프론트엔드 구현
...

Herdr 자체가 코드를 생성하는 것은 아닙니다.

여러 AI 에이전트나 셸 (Shell)을 기동하고, 이들의 상태를 확인·조작하기 위한 실행 기반입니다.

7. Herdr의 주요 특징

7.1 여러 에이전트를 목록으로 확인할 수 있음

각 페인 (Pane)에서 동작 중인 에이전트에 대해 다음과 같은 상태를 확인할 수 있습니다.

• Working: 작업 중
• Blocked: 사용자의 확인 또는 입력 대기
• Done: 작업 완료
• Idle: 대기 중

에이전트를 여러 개 띄웠을 때, 어떤 작업을 확인해야 할지 판단하기 쉬워집니다.

7.2 각 에이전트의 실제 터미널을 표시

Herdr는 에이전트의 출력을 독자적인 채팅 UI로 변환하는 대신, 각 에이전트 자신의 터미널을 표시합니다.

따라서 다음 내용을 직접 확인할 수 있습니다.

• 실행 중인 명령어
• 에러 내용
• 테스트 결과
• 확인 대기 메시지
• 에이전트와의 대화 이력

7.3 세션을 유지할 수 있음

Herdr 화면을 닫거나 SSH 연결이 끊어지더라도, 백그라운드의 세션과 프로세스는 계속됩니다.

나중에 다시 접속하여 동일한 작업 화면으로 돌아갈 수 있습니다.

7.4 SSH 환경에서도 이용 가능

Herdr는 데스크톱 앱이 아니라 터미널 내에서 동작합니다.

따라서 개발 서버나 원격 머신에 SSH로 접속하여, 그 환경 위에서 에이전트를 구동하는 용도로도 적합합니다.

7.5 에이전트나 스크립트로 조작 가능

Herdr에는 CLI 및 Socket API가 준비되어 있어, 에이전트 스스로 다음과 같은 조작을 수행할 수 있습니다.

• 새로운 페인 생성
• 다른 에이전트 기동
• 페인의 출력 읽기
• 다른 태스크의 종료 대기

발전적인 사용법으로는, 하나의 에이전트를 리더 (Leader) 역할로 설정하여 다른 에이전트에게 태스크를 할당하는 구성도 만들 수 있습니다.

8. Herdr의 장점

8.1 독립된 태스크를 본격적으로 병렬 실행 가능

예를 들어, 다음과 같이 담당을 나눌 수 있습니다.

Claude Code
└─ React 로그인 화면 구현
Codex CLI
...

태스크 간의 의존성이 적은 경우, 대기 시간을 줄일 수 있습니다.

8.2 여러 에이전트를 대등하게 취급 가능

Claude Code를 반드시 부모로 만들 필요는 없습니다.

• Claude Code
• Codex CLI
• OpenCode
• 일반 셸 (Shell)
• 테스트 러너 (Test Runner)
• 개발 서버

등을 동일한 워크스페이스 (Workspace)에 배치할 수 있습니다.

8.3 작업 상태를 육안으로 확인하기 쉬움

여러 에이전트에 의한 병렬 작업에서는 처리 속도보다 "어디에서 멈춰 있는지를 발견하는 것"이 중요합니다.

Herdr에서는 입력 대기나 완료 상태를 목록으로 확인할 수 있기 때문에, 장시간 방치되는 태스크를 줄일 수 있습니다.

8.4 장시간 작업이나 원격 작업과 궁합이 좋음

터미널을 닫아도 처리를 계속할 수 있으므로 다음과 같은 용도에 적합합니다.

• 시간이 오래 걸리는 리팩터링 (Refactoring)
• 대규모 테스트
• 원격 서버상의 조사
• 여러 에이전트에 의한 병렬 구현

9. Herdr의 단점과 주의점

9.1 Herdr는 태스크를 자동으로 적절히 분해해주지 않음

Herdr는 에이전트를 실행·감시하기 위한 기반입니다.

다음 내용은 인간 또는 리더 역할의 에이전트가 설계해야 합니다.

• 무엇을 병렬화할 것인가
• 어떤 에이전트에게 맡길 것인가
• 어떤 파일을 편집하게 할 것인가
• 태스크 간의 의존 관계
• 최종적인 통합 방법

태스크 분해가 부적절할 경우, 여러 에이전트를 구동하더라도 개발이 빨라진다고 보장할 수 없습니다.

9.2 컨텍스트 (Context)는 자동으로 공유되지 않음

어느 페인의 Claude Code에 설명한 내용이 다른 페인의 Codex로 자동 공유되는 것은 아닙니다.

공통 인식을 갖게 하려면 다음과 같은 공유 수단이 필요합니다.

AGENTS.md

• 설계 문서
• GitHub Issue
• 태스크별 마크다운 (Markdown) 파일
• API 명세서
• 작업 완료 시의 핸드오프 (Handoff) 메모

9.3 동일한 작업 디렉토리를 동시에 편집하면 충돌이 발생함

페인 (Pane)이 나누어져 있더라도, 파일 시스템 (File System)이 자동으로 분리되는 것은 아닙니다.

여러 에이전트 (Agent)를 동일한 리포지토리 (Repository)에서 구동하면 다음과 같은 문제가 발생할 수 있습니다.

• 동일한 파일의 덮어쓰기
• Git 인덱스 (Index) 충돌
• 브랜치 (Branch) 전환 충돌
• 테스트 결과의 혼재
• 커밋되지 않은 차분 (Diff)의 소유자 불분명

안전하게 병렬 개발을 수행하려면, Git worktree를 통한 분리가 유효합니다.

git worktree add ../worktrees/frontend -b agent/frontend
git worktree add ../worktrees/backend -b agent/backend
git worktree add ../worktrees/tests -b agent/tests

9.4 인간의 인지 부하가 증가함

에이전트의 수를 늘릴수록 다음과 같은 관리가 필요해집니다.

• 누구에게 무엇을 요청했는가
• 어떤 태스크 (Task)가 완료되었는가
• 어떤 변경 사항을 채택할 것인가
• 변경 사항들 사이에 모순이 없는가
• 어떤 브랜치를 어떤 순서로 통합할 것인가

병렬화를 통해 에이전트의 대기 시간은 줄어들더라도, 인간의 확인 시간이 늘어나는 경우가 있습니다.

10. 비교표

11. 어느 것을 선택해야 하는가

11.1 codex-plugin-cc가 적합한 케이스

다음 조건에 해당한다면, codex-plugin-cc가 다루기 쉬운 선택입니다.

• 평소 개발을 Claude Code 중심으로 진행하고 있다
• 필요할 때만 Codex의 의견을 듣고 싶다
• 구현 후의 코드 리뷰 (Code Review)를 Codex에 맡기고 싶다
• Claude Code로 해결할 수 없는 버그만 Codex에 넘기고 싶다
• 여러 에이전트의 관리에 시간을 쓰고 싶지 않다
• 동시에 구동하는 태스크는 1~2개 정도이다

상정되는 플로우 (Flow)는 다음과 같습니다.

Claude Code로 구현
↓
Codex에 리뷰 또는 조사 요청
...

11.2 Herdr가 적합한 케이스

다음 조건에 해당한다면, Herdr의 효과를 보기 쉽습니다.

• 독립된 태스크를 여러 개 동시에 진행하고 싶다
• 프론트엔드 (Frontend), 백엔드 (Backend), 테스트 (Test)를 분담할 수 있다
• Claude Code와 Codex 이외의 도구도 이용하고 싶다
• 각 에이전트의 실행 화면을 상시 확인하고 싶다
• 장시간의 태스크나 SSH 대상의 태스크를 유지하고 싶다
• Git worktree나 브랜치 운용을 설계할 수 있다
• 인간이 전체적인 진행 관리를 수행할 수 있다

상정되는 플로우 (Flow)는 다음과 같습니다.

태스크를 독립된 단위로 분할
↓
에이전트별로 worktree 준비
...

12. 권장하는 단계적인 도입 방법

처음부터 다수의 에이전트를 병렬 실행하면 운용 설계의 부담이 커집니다.

다음과 같이 단계적으로 도입하는 방법이 현실적입니다.

스텝 1: Claude Code 단독으로 작업하기

먼저 하나의 에이전트로 요구사항 정리, 구현, 테스트까지 진행합니다.

스텝 2: codex-plugin-cc로 리뷰와 조사를 분담하기

Claude Code
├─ 메인 구현
├─ /codex:rescue
...

Codex를 리뷰 담당이나 트러블슈팅 (Troubleshooting) 담당으로 추가합니다.

이 단계에서는 관리 대상이 적어 효과를 확인하기 쉽습니다.

스텝 3: 독립 태스크만 Herdr로 병렬화하기

Herdr
├─ worktree/frontend
│ └─ Claude Code
...

모든 작업을 병렬화하는 것이 아니라, 의존 관계가 적은 태스크만 분리합니다.

스텝 4: 필요에 따라 양자를 병용하기

Herdr의 페인 (Pane) 내에서 Claude Code를 기동하고, 해당 Claude Code에서 codex-plugin-cc를 사용하는 것도 가능합니다.

Herdr
├─ Claude Code
│ ├─ 메인 구현
...

이 경우, 역할을 다음과 같이 나눕니다.

• Herdr: 여러 작업 장소, 프로세스, 에이전트를 관리함
• codex-plugin-cc: Claude Code로부터 Codex로 작은 작업이나 리뷰를 위임함

13. 안전하게 운용하기 위한 규칙 예시

여러 에이전트(Agent)를 이용할 경우에는 도구 선택보다 운용 규칙이 더 중요합니다.

13.1 쓰기 담당을 명확히 하기

동일한 파일을 여러 에이전트가 동시에 편집하지 않도록 합니다.

Claude Code: src/frontend/** 만
Codex CLI: src/backend/** 만
테스트 담당: tests/** 만

13.2 1에이전트 1worktree를 기본으로 하기

본격적인 병렬 작업에서는 각 에이전트를 별도의 worktree에서 구동합니다.

이를 통해 브랜치(Branch) 전환이나 미커밋 차분(Uncommitted diff)의 충돌을 방지하기 쉬워집니다.

13.3 태스크의 완료 조건을 먼저 작성하기

각 태스크(Task)에는 다음 정보를 포함합니다.

• 목적
• 편집 가능한 범위
• 편집해서는 안 되는 범위
• 필수 테스트
• 완료 조건
• 작업 결과 보고 형식

13.4 통합 담당을 하나로 결정하기

각 에이전트의 변경 사항을 그대로 자동하여 main 브랜치로 통합하지 않도록 합니다.

사람 또는 통합 담당 에이전트가 차분(Diff), 테스트 결과, 설계 정합성을 확인한 후에 머지(Merge)합니다.

13.5 병렬화하기 전에 의존 관계를 확인하기

다음과 같이 의존 관계가 강한 태스크는 무리하게 병렬화하지 않는 것이 안전합니다.

API 사양 결정
↓
백엔드 구현
...

반면, 다음과 같이 경계가 명확한 태스크는 병렬화하기 쉽습니다.

기존 화면의 접근성(Accessibility) 개선
기존 API의 유닛 테스트(Unit Test) 추가
문서 업데이트

14. 최종 결론

일상적인 개발에서 Claude Code를 중심으로 사용하며, 필요할 때만 Codex에 조사나 리뷰를 의뢰하는 경우에는 codex-plugin-cc가 가장 도입하기 쉽고 관리 부하도 낮은 선택입니다.

한편, 여러 개의 독립적인 태스크를 동시에 진행하며 Claude Code, Codex CLI, 테스트 프로세스 등을 한꺼번에 감독하고 싶다면 Herdr가 적합합니다.

선택 기준을 간결하게 정리하면 다음과 같습니다.

실무에서는 먼저 codex-plugin-cc로 작게 시작하고, 병렬화할 가치가 명확해진 단계에서 Herdr와 Git worktree를 도입하는 방법이 효과와 운용 비용의 균형을 맞추기 쉬울 것으로 생각됩니다.

15. 참고 자료

OpenAI: Codex plugin for Claude Code

https://github.com/openai/codex-plugin-cc -
Herdr 공식 사이트

https://herdr.dev/ -
Herdr GitHub 리포지토리

https://github.com/herdrdev/herdr -
Herdr 문서

Discussion