이 기사에서 할 일

Claude Code가 계획을 세워 지시를 내리고, Codex가 구현한다. 태스크 전달도, 구현 중 발생하는 질문도 에이전트끼리 직접 주고받습니다. 인간이 하는 일은 처음에 하고 싶은 것을 전달하고, 때때로 상황을 지켜보며 승인이나 사양 판단에 답하는 것 정도입니다.

이 기사의 도달점. leader(Claude Code)의 지시로 coder(Codex)가 구현하고, reviewer(Codex)가 승인을 반환한다. 사이드바에는 2개 프로젝트의 에이전트가 나란히 표시된다.

사용하는 도구는 두 가지뿐입니다. 둘 다 설치는 한 줄로 끝나며, 어려운 설정은 나오지 않습니다. 셸 스크립트(Shell Script)도 작성하지 않습니다.

이야기는 4단계로 진행됩니다.

agmsg로 에이전트가 협업할 수 있다— 리더와 구현 담당 2체로, 지시와 질문이 오가는 것을 확인한다 -
herdr로 협업 상태를 확인하기 쉽다— 누가 일하고 있고, 누가 승인 대기 중으로 멈춰 있는지 한눈에 알 수 있게 한다 -
실시간으로 받을 수 없거나 멈춰버려도 확인이 가능하다— Codex만의 약점과 작동이 멈췄을 때의 대처법을 파악한다 -
팀을 늘려 여러 프로젝트를 동시에 실행한다— 리더 1명 + 역할 분담 팀을 하나 더 구성하여, 2개 안건을 병행하여 진행한다

왜 「Claude가 지시하고, Codex가 구현」하는가

먼저 역할 분담의 이유를 설명하겠습니다.

리더는 Claude Code. 인간의 모호한 의뢰를 파악하여 계획으로 번역하거나, 올라온 성과를 검수하는 '창구' 역할은 대화에 능숙한 Claude 계열이 적합합니다. 리더가 의도를 잘못 파악하면 팀 전체가 잘못된 방향으로 달리게 되므로, 여기에는 가장 신뢰할 수 있는 모델을 배치합니다.

구현은 Codex. 손을 움직이는 작업은 많은 양을 처리해야 하므로, 구현 능력이 있고 구독(Subscription) 소비 한도도 별도로 적용되는 Codex에게 맡깁니다. 구현과 리뷰(검수)를 별도의 모델로 나누면, "자신이 작성한 코드를 스스로 관대하게 체크하는" 문제도 피할 수 있습니다.

이 기사에서 하는 것은, 이 "창구는 Claude, 양을 소화하는 구현은 Codex"라는 역할 분담을 기성 도구 2개만으로 체험할 수 있는 최소 구성입니다.

참고로, 이 조합은 필수 사항이 아닙니다. 사용할 수 있는 모델이나 계약 플랜에 따라 리더와 구현을 교체해도 메커니즘 자체는 그대로 작동합니다.

1. agmsg로 에이전트가 협업할 수 있다

agmsg란

에이전트끼리 메시지를 주고받기 위한 도구입니다. 구조는 단순하며, 컴퓨터 안에 메시지 보관소(SQLite라는 데이터베이스 파일 1개)를 두고 모두가 그곳을 우체통으로 사용하기만 하면 됩니다. 서버도 네트워크 설정도 필요 없습니다. 필요한 것은 bash와 sqlite3뿐입니다.

그리고 중요한 점은, agmsg가 스킬(Skill)(에이전트에게 새로운 능력을 추가하는 메커니즘)로서 들어간다는 것입니다. 설치 후의 조작은 전부 에이전트에 대한 일본어 지시로 끝납니다. Claude Code뿐만 아니라 Codex, Gemini CLI, GitHub Copilot CLI 등 주요 CLI 에이전트에 대응합니다.

셋업(Setup)

설치는 이 한 줄입니다.

npx agmsg

다음으로, 데모용 프로젝트 project-a를 ~/projects 아래에 만듭니다.

mkdir -p ~/projects/project-a && cd ~/projects/project-a

이 프로젝트에 팀 운영 규약을 CLAUDE.md로 한 장 작성합니다.

# 팀 운영 규약(team-a)
이 프로젝트는 leader와 coder의 2개 역할로 협업한다.
자신의 역할은 agmsg에 등록한 이름으로 결정된다. 미참가 시 인간의 지시에
...

포인트는 coder 측의 "불분명한 점은 leader에게 질문한다"라는 문구입니다. 에이전트는 모르는 것이 있으면 추측으로 밀고 나가는 경향이 있으므로, "물어볼 수 있는 상대가 있다"라고 알려주면 재작업(rework)이 크게 줄어듭니다.

규약에 "자신의 역할은 agmsg에 등록한 이름으로 결정된다"라고 적어둔 것도 핵심입니다. 역할마다 파일을 나누지 않아도, 한 장의 규약으로 전원이 자신의 섹션만 읽게 됩니다. 나중에 멤버를 늘릴 때도 이 규약에 섹션을 추가하기만 하면 됩니다.

규약을 작성했다면, 마지막으로 준비 작업을 하나 더 합니다. Claude Code는 CLAUDE.md를, Codex는 AGENTS.md라는 이름의 파일을 프로젝트 지시 파일로 자동 인식하여 읽어들입니다. 방금 작성한 규약을 양쪽 모두에게 읽히고 싶으므로, 심볼릭 링크(Symbolic Link)를 걸어둡니다.

ln -s CLAUDE.md AGENTS.md # 두 에이전트 모두에게 동일한 규약을 읽히기 위함

팀에 참여시키기

Claude Code와 Codex를 각각 하나씩 실행하여, 각각에게 말을 걸어 팀에 참여시킵니다. 이 시점에서는 평범하게 터미널 2개를 띄워두면 됩니다.

Claude Code(leader) 측. 터미널을 하나 열고, project-a에서 claude를 실행한 뒤 다음과 같이 말합니다.

/agmsg 로 team-a 에 leader 로 참여해줘

도중에 "전송 모드" (메시지 수신 방식)를 묻는다면, 그대로 기본값(Default)을 사용해도 좋습니다. Claude Code는 monitor (저장소를 상시 감시하며, 약 5초 내에 도착하는 실시간 수신) 모드가 됩니다.

Codex(coder) 측. 다른 터미널을 하나 더 열고, 동일한 project-a에서 codex를 실행한 뒤 다음과 같이 말합니다.

$agmsg 로 team-a 에 coder 로 참여해줘

이쪽도 전송 모드는 기본값으로 두면 됩니다. Codex는 turn (자신의 작업 단계가 끝날 때마다 우체통을 확인) 모드가 됩니다.

왼쪽이 leader(Claude Code), 오른쪽이 coder(Codex). 각각 기본 전송 모드로 team-a 에 참여한 모습

이 수신 방식의 차이가 제3장의 복선입니다.

우선 통신 확인

갑자기 구현을 요청하기 전에, 메시지가 왕복하는지만 확인해 둡니다.

등장인물은 당신(인간)・leader(Claude Code)・coder(Codex) 총 3명입니다. 당신은 leader에게만 말을 걸며, coder에게 전달되는 연락은 leader가 agmsg를 통해 수행합니다. 이 관계는 이후의 구현 데모에서도 계속 동일하게 유지됩니다.

**leader(Claude Code의 터미널)**에 다음과 같이 말하세요.

coder 에게 "들립니까?"라고 보내고, 답장이 오면 알려줘

leader는 agmsg를 통해 coder에게 메시지를 보냅니다. 하지만 이대로 기다려도 coder는 답장을 하지 않습니다. turn 모드인 Codex는 자신이 움직일 때만 수신함을 확인하기 때문에, 가만히 있는 coder는 메시지가 왔다는 사실 자체를 알아차릴 수 없습니다 (이 문제는 제3장에서 해결합니다).

이번에는 사람이 직접 움직여 주겠습니다. **coder(Codex의 터미널)**에 다음과 같이 말하세요.

agmsg 의 수신함을 확인해줘

coder가 메시지를 인지하고 답장을 보내면, 상시 감시(monitor) 중인 leader는 몇 초 내에 이를 수신하여 당신에게 "답장이 왔습니다"라고 보고합니다. 확인 포인트는 다음 세 가지입니다.

• leader에게 "team 을 확인해줘"라고 요청하면, leader와 coder가 동일한 team-a의 멤버로 표시된다.
• coder의 답장을 leader가 보고해 준다.
• leader에게 "history 를 보여줘"라고 요청하면, 방금 왕복한 2통의 메시지가 남아 있다.

실제로 작동시켜 보기

통신이 확인되었다면, leader에게 구현을 요청해 봅니다. 결과를 맞추기 쉽게 기술 스택까지 지정해 둡니다.

Node.js 와 Express 를 사용하여, 메모리에 저장하는 TODO API 를 만들고 싶어.
POST /todos(추가), GET /todos(목록), PATCH /todos/:id/complete(완료) 이렇게 3개를 만들어줘.
npm test 로 동작을 확인할 수 있는 테스트 코드도 포함해줘.
...

그러면 다음과 같은 흐름으로 진행됩니다.

• leader가 계획을 세우고, agmsg를 통해 coder에게 구현 태스크를 전달한다.
• coder가 구현에 착수한다. 도중에 불명확한 점이 있으면 leader에게 질문한다.
• leader가 약 5초 내에 수신하여 답변한다 (스스로 결정해도 되는 범위라면 결정하고, 사양과 관련된 것이라면 인간에게 확인한다).
• coder가 구현을 마치고 완료 보고를 한다.
• leader가 검수하고, 인간에게 "끝났습니다"라고 보고한다.

계획·지시·질문·답변·보고의 내용은 인간이 단 한 번도 중간에서 전달하지 않습니다. 다만 진행을 위한 트리거(Trigger)는 별개입니다. 통신 확인과 같은 이유로, coder는 새로운 메시지가 온 것을 스스로 알아차릴 수 없습니다. leader가 지시를 보냈는데 coder가 움직이지 않거나, leader가 답변을 했는데 coder가 재개하지 않는 경우에는 그때마다 coder에게 "agmsg의 수신함을 확인해"라고 말하며 진행해 주세요. 이러한 번거로움은 제3장에서 해결할 것입니다.

왼쪽의 leader가 계획을 세워 사양을 보내고, 오른쪽의 coder가 이를 수신하여 구현 방침을 세운 상황. leader의 요청에는 엔드포인트(Endpoint) 사양과 검증 절차까지 작성되어 있다.

이로써 첫 번째 기둥인 "agmsg로 에이전트가 협업할 수 있다"는 것을 확인했습니다. 하지만 터미널 두 개를 왔다 갔다 하며 바라보는 것은 이제 답답하게 느껴질 것입니다.

2. herdr로 협업 상태를 쉽게 확인하기

herdr란

여러 에이전트를 한 화면에 나란히 배치하여 지켜보기 위한 도구입니다. "코딩 에이전트용 tmux"라고 소개되는 경우가 많지만, tmux를 몰라도 괜찮습니다. WezTerm이나 Ghostty 같은 새로운 터미널 앱으로 갈아타는 것이 아니라, 지금 사용 중인 터미널 안에서 herdr를 실행하면 그 안에 에이전트를 나열하는 화면이 펼쳐집니다. 말하자면 **"터미널 안의 터미널"**이라고 생각하면 됩니다.

기쁜 점은 다음 4가지입니다.

• 마우스로 조작 가능: 페인(Pane) 분할 및 이름 변경은 우클릭으로, 워크스페이스(Workspace)나 페인 전환은 클릭으로 할 수 있어, tmux처럼 복잡한 키 조작을 익힐 필요가 없습니다.
• 상태를 색상으로 확인: 각 에이전트의 현재 상태가 사이드바에 색상으로 나열됩니다. 상태는 working(작업 중)/blocked(승인·질문·권한 확인 등 외부로부터의 입력이나 판단 대기)/done(작업을 마쳤으나 인간이 미확인)/idle(대기 중)의 4가지이며, 본 기사에서는 이 명칭을 사용합니다.
• 닫아도 유지됨: 백그라운드에서 서버가 계속 실행되므로, 터미널 화면을 닫아도 에이전트들은 계속 일합니다(단, PC 본체가 절전 모드로 들어가면 멈춥니다).
• 외부에서도 확인 가능: SSH로 접속 가능한 머신에서 herdr를 실행해 두면, 스마트폰에서도 상황을 확인할 수 있습니다.

셋업(Setup)

설치는 이 한 줄이면 충분합니다.

curl -fsSL https://herdr.dev/install.sh | sh

설치가 완료되었다면 평소 사용하는 터미널에서 실행합니다. 이후의 작업은 모두 herdr 화면 안에서 이루어집니다.

herdr

에이전트를 herdr 안에서 다시 실행하기

herdr를 실행한 후 인간이 할 일은 leader를 실행하는 것까지입니다.

• 실행하면 워크스페이스(작업 화면)가 하나 열린 상태이며, 처음에는 홈 디렉토리에 있으므로 cd ~/projects/project-a로 이동합니다.
• claude를 실행하여 "team-a에 leader로서 참여해줘. 미독 메시지와 히스토리(History)도 확인해줘"라고 재참여시킵니다 (팀의 대화 내용은 agmsg의 보관소에 남아 있으므로, 의뢰나 질문의 경위는 그대로 이어집니다).

나머지 페인(구획)을 준비하는 것은 leader에게 맡겨버립니다. herdr는 명령어로 페인 분할·이름 변경·입력을 할 수 있으므로, leader에게 다음과 같이 부탁하기만 하면 됩니다.

herdr pane split으로 오른쪽에 페인을 만들고 codex를 실행해줘.
페인 이름은 너를 leader로, 옆을 coder로 설정해.
codex가 실행되면 "$agmsg로 team-a에 coder로서 참여해"라고 입력해줘,
...

leader가 herdr pane split --direction right로 페인을 만들고, herdr pane run으로 codex를 실행하여 이름을 붙인 뒤, 참여 지시까지 옆 페인에 입력해 줍니다. 인간은 바라보고만 있으면 팀이 herdr 안에서 다시 구성됩니다.

참고로 "참여해"라고 해도 team-a에는 제1장에서 이미 등록되어 있으므로, 멤버가 중복해서 늘어나는 것은 아닙니다. agmsg가 동일한 프로젝트의 등록 정보를 찾아내어, 동일한 leader / coder로서 이어서 참여하는 형태가 됩니다.

페인(pane) 이름은 각 페인의 상단에 표시될 뿐만 아니라, 제3장에서 leader가 상대방의 페인을 찾는 단서가 되기도 하므로, agmsg의 에이전트 이름과 동일하게 설정해 두는 것이 중요합니다.

(물론, 우클릭 메뉴를 통해 수동으로 페인을 분할하거나 이름을 변경할 수도 있습니다)

leader가 직접 페인을 분할하여 codex를 실행하고, herdr 내에서 팀을 다시 구축한 모습. 왼쪽 사이드바에 에이전트 목록이 표시된다.

무엇이 바뀌는가

이번에는 제1장에서 만든 TODO API에 기능 추가를 leader에게 부탁해 보겠습니다.

TODO API에 DELETE /todos/:id(삭제)를 추가하고 싶어.
구현을 coder에게 의뢰하고, 완성될 때까지 관리해 줘.
coder에게 agmsg로 메시지를 보내면, coder의 페인에
...

마지막 문장이 포인트입니다. coder는 turn 모드에서 새로운 메시지를 스스로 알아차릴 수 없기 때문에(제1장의 "알아차리지 못하는 문제"), 메시지만 보내고 끝내는 것이 아니라 페인에 입력을 하여 알려주는 단계까지 leader에게 맡기고 있습니다.

보이는 모습이 다음과 같이 바뀝니다.

• leader에게 지시를 내리면, 사이드바에서 leader가 working 상태로 변경
• leader가 지시를 보내 coder를 깨우면, coder도 working 상태로 변경. 두 에이전트가 나란히 일하고 있는 것을 한눈에 알 수 있음
• coder가 파일 편집 승인을 기다리며 멈추면 blocked 상태로 변경 → 알아챈 사람이 승인하기만 하면 됨
• 대화 내용이 궁금하면 leader에게 "history 보여줘"라고 말하면 팀의 상호작용이 시계열로 나타남

leader가 태스크를 보내고, coder의 페인에 알림 문구를 입력하여 깨운 모습. coder가 메시지를 수신하고 구현을 시작하는 모습까지 한 화면에서 확인할 수 있다.

그리고 밤에 의뢰를 하고 터미널을 닫은 뒤, 다음 날 아침에 다시 연결하면 구현과 검수가 완료되어 있습니다. herdr가 상주해 주는 덕분에 이것이 가능합니다. 단, 계속 동작하는 것은 PC 본체가 켜져 있는 동안뿐입니다. 노트북 덮개를 닫으면 절전 모드로 인해 멈춥니다. 본격적으로 방치하고 싶다면, 절전 모드로 들어가지 않는 상시 가동 머신(원격 서버 등)에서 herdr를 실행합니다. 로컬에서는 SSH로 접속하여 herdr를 재실행하면, 동작 중인 세션에 그대로 연결할 수 있습니다(스마트폰의 SSH 클라이언트에서도 마찬가지입니다).

두 번째 핵심 요소인 "herdr로 협업 상태를 확인하기 쉽다"도 달성했습니다. 여기까지는 순조롭지만, 사실 지금까지의 데모에는 우연히 잘 맞아떨어진 부분이 있습니다.

3. 실시간으로 받지 못하거나 멈춰버려도, 확인이 가능하다

Codex는 "말을 걸어줄 때까지 알아차리지 못할" 때가 있다

제1장의 복선을 회수하겠습니다. 두 에이전트의 수신 방법은 다음과 같이 달랐습니다.

turn 모드의 Codex는 아무것도 하지 않는(idle 상태인) 동안에는 새로운 메시지를 알아차릴 수 없습니다. leader가 지시를 보내도 coder가 한가한 상태로 가만히 있는 상황이 실제로 발생합니다.

(agmsg에는 Codex를 위한 실시간 수신 기능도 베타 버전으로 준비되어 있지만, 공식 README에서도 실험적인 메커니즘에 의존한다고 주의를 주고 있으므로, 본 글에서는 기본 설정인 turn 모드로 진행합니다)

그렇기 때문에 제1장에서는 사람이 매번 coder에게 "수신함을 확인해"라고 말을 걸며 진행했습니다. 에이전트에게 맡기고 있는 것 같지만, 전서구(messenger pigeon) 역할만 사람에게 남아 있는 상태입니다.

해결책: 깨우는 역할도 leader가 수행하게 한다

제2장의 기능 추가에서는 의뢰문에 "coder에게 알려줘"라고 덧붙임으로써 이 문제를 극복했습니다. 하지만 매번 의뢰문에 쓰는 것은 번거롭고, 깜빡하고 쓰지 않으면 거기서 멈춰버립니다. 그래서 이 규칙을 규약에 적어두고, 깨우는 역할은 leader로 고정합니다.

CLAUDE.md의 leader 섹션에 두 줄을 추가합니다.

• agmsg로 메시지를 보냈다면, herdr에서 "agmsg의 수신함을 확인해"라고 입력하여 깨운다
• 상대가 working(작업 중) 또는 blocked(입력 대기) 상태일 때는 아무것도 입력하지 않고 기다린다

규약을 다시 작성했다면, leader에게 "CLAUDE.md를 다시 읽어줘"라고 한마디 건네고(재시작도 OK), 기능을 하나 더 추가해 달라고 요청해 봅니다.

TODO API에 GET /todos/count(건수)를 추가하고 싶어.
coder에게 의뢰해서 완성될 때까지 관리해 줘.

이번에는 coder가 idle 상태로 있더라도 인간이 나설 필요가 없습니다. leader가 지시를 보내고, 페인(pane)의 상태를 확인하며, 스스로 "수신함을 확인해"를 입력하여 깨우는 과정을 관찰할 수 있을 것입니다. 질문에 대한 답변을 보낼 때도 동일한 규칙이 적용되므로, 질문→답변→재개의 왕복 과정도 끊기지 않습니다. 전서구의 역할은 이렇게 leader에게 인계되었습니다.

leader가 스스로 coder를 깨워 "working 상태가 되었으므로 규약에 따라 완료 보고를 기다린다"라고 판단하고 있는 모습. 인간은 아무것도 하지 않음

멈춰버렸을 때의 식별 방법과 대처

또 다른 "멈춤" 역시, 3가지 패턴으로 나누어 생각하면 두렵지 않습니다.

① coder가 한가해 보일 때 (idle 상태인데 할 일이 남아 있는 경우). 깨우는 타이밍을 놓친 것입니다. 메시지는 agmsg의 보관함에 남아 있으므로 사라지지 않았습니다. leader에게 "coder에게 말을 걸어줘"라고 부탁하면 회수할 수 있습니다.

② blocked(입력 대기) 상태로 멈춰 있는 경우. 이는 고장이 아니라 승인, 질문, 권한 확인 등 외부로부터의 입력이나 판단을 기다리고 있는 정상적인 상태입니다. 사이드바에서 이를 발견하면 페인을 들여다보고, 인간의 승인을 기다리는 중이라면 승인하고, leader에 대한 질문이 지체되고 있다면 leader 측의 상황을 살피는 등 대기 대상에 따라 대응합니다. 참고로 blocked 페인에 "수신함을 확인해"를 입력하면 승인 화면에 글자가 흘러 들어가 버리므로, 말을 거는 것은 idle 상태일 때만 합니다.

③ 페인 자체가 다운된 경우. herdr 화면에서 확인할 수 있습니다. 복구도 leader에게 맡길 수 있습니다.

coder의 페인에서 codex를 다시 실행해 줘. 실행되면 team-a에 재참가하고,
읽지 않은 메시지·history·git의 차분(diff) 확인, 그리고 진행 중이던 작업의 재개를 지시해 줘.

팀 간의 상호작용은 agmsg의 보관함에 모두 남아 있으므로, 의뢰·질문·답변의 경위는 그곳에서 복원할 수 있습니다. 다운된 에이전트의 내부 사고 과정까지는 되돌릴 수 없으므로, 실제 작업 상태는 git의 차분이나 테스트 결과로 확인하게 하는 것이 포인트입니다.

이로써 기둥의 세 번째 줄도 갖춰졌습니다. 지시하기·지켜보기·깨우기/재건하기, 이 모든 것이 일본어(텍스트) 지시와 화면 확인만으로 돌아갑니다.

4. 팀을 늘려서 여러 프로젝트를 동시에 실행하기

2대로 돌아가는 것을 확인했다면, 나머지는 같은 방식의 연장선입니다. 마무리로 두 가지를 확장해 보겠습니다.

• 팀 자체를 늘려서 별도의 프로젝트를 병행하여 실행하기
• 멤버를 늘려서 리더 1명 + 역할 분담 팀으로 만들기

project-b: leader / coder / reviewer 3인 팀

다른 프로젝트인 project-b에서 리뷰 담당을 추가한 3인 팀을 구성합니다.

먼저, herdr에서 새로운 워크스페이스를 엽니다. 사이드바의 spaces 항목 아래에 있는 "new"를 클릭하기만 하면 됩니다(project-a의 팀은 그대로 둔 채 작동시킬 수 있습니다). 새로운 워크스페이스가 열리면 프로젝트를 생성하고 이동합니다.

mkdir -p ~/projects/project-b && cd ~/projects/project-b

"new"로 연 두 번째 워크스페이스. project-a의 팀은 백그라운드에서 그대로 돌아가고 있음

나머지는 project-a와 같습니다. 규약을 CLAUDE.md에 작성하고 심볼릭 링크를 겁니다. 공통 규칙은 그대로 유지하면서, reviewer 섹션이 추가되고, 3인 체제로 운영하기 위한 규칙이 조금 더해졌습니다.

팀 운영 규약(team-b)

이 프로젝트는 leader, coder, reviewer의 3가지 역할로 협업한다.
자신의 역할은 agmsg에 등록한 이름으로 결정된다. 미참가 상태라면 인간의 지시에
...

coder와 reviewer의 규칙에 "leader에게도 보고"가 포함되어 있는 것이 포인트입니다. coder도 reviewer도 turn 모드의 Codex이므로, "인지하지 못하는 문제"는 3체가 되어도 마찬가지입니다. 문제를 일으키는 주체(herdr의 pane 조작)는 leader이므로, 당사자 간의 대화에도 보고를 한 번 거침으로써 leader가 "다음에 누구를 깨워야 할지" 알 수 있도록 하고 있습니다. leader 섹션의 "보고를 받으면, 그 수신자도 마찬가지로 깨운다"가 이를 받아주는 규칙입니다.

규약을 작성했다면, project-a와 마찬가지로 링크를 겁니다.

ln -s CLAUDE.md AGENTS.md

이어서 claude를 실행하여, 팀 참여부터 pane 준비까지 한꺼번에 요청합니다.

/agmsg 로 team-b 에 leader 로 참여해줘.
참여가 완료되면 herdr pane split 으로 pane을 2개 만들고, 각각 codex 을 실행해줘.
pane 이름은 자신을 leader, 나머지 2개를 coder와 reviewer로 설정해줘.
...

leader가 자신의 참여를 마치고, pane을 생성하고, codex을 실행하며, 참여 지시까지 입력해 줍니다.

3체 팀의 셋업을 마친 leader의 보고. coder와 reviewer의 pane에서도 team-b 참여가 확인됨

의뢰는 이런 식입니다(project-b는 빈 프로젝트이므로, 주제도 새로 만들게 합니다).

Node.js와 Express로, 기한(due date)이 있는 TODO API를 새로 만들고 싶어.
요건은 태스크 추가·목록·완료와, 기한 등록·기한순 목록이야.
계획을 세워서 coder에게 의뢰하고, 리뷰와 검수까지 진행해줘.

흐름은 다음과 같습니다.