서론

안녕하세요.

최근 2주 정도 사이에 코딩에 사용할 수 있는 모델이 단번에 늘어났습니다.

Anthropic에서는 Fable 5가 출시되었고, GPT-5.6은 Sol, Terra, Luna의 3단계 체제로 등장했으며, 심지어 티어(tier)마다 reasoning effort 설정까지 포함되어 있습니다.

어떤 것을 사용하면 좋을지, Fable과 Sol 중 어느 쪽이 더 강력한지에 대한 비교 기사를 수없이 보았고, 저 또한 상당히 고민해 왔습니다[1].

비교 기사의 결론은 대개 "최강을 하나 고르는 것이 아니라, 용도에 따라 구분해서 사용하자"로 귀결됩니다.

그 자체는 맞는 말이라고 생각하지만, 그렇다면 손에 든 개발 작업의 어느 부분에 어떤 모델을 배치해야 하는지는 결국 우리에게 맡겨진 채로 남아 있습니다.

이 기사에서는 그 "어떻게 구분해서 사용할 것인가"에 대한 저만의 답으로서, 개발 업무를 역할별로 나누고 역할마다 적합한 모델을 하나씩 할당하는 자체 제작 템플릿 customizable-agent-teams를 소개합니다.

Claude Code와 Codex를 Lead, Manager, 구현, 리뷰, 조사와 같은 11개의 역할로 나누어, tmux 위에서 동시에 구동하는 프로젝트 템플릿입니다.

인간이 대화하는 상대는 Lead 한 명뿐이며, 태스크 할당부터 진척 관리까지 팀 내부에서 완결됩니다.

다만, 이 구분법은 모델 비교에서 시작된 것이 아닙니다.

출발점은 한 대의 에이전트에게 모든 것을 시켰을 때 잘 되지 않았던 경험입니다.

따라서 먼저 그 실패로부터 이야기를 시작하여, 팀의 형태, 역할별 모델 배분, 분담을 지키게 하는 메커니즘 순으로 설명하겠습니다.

마지막으로 이 팀에게 프로덕트를 하나 만들게 한 실측 기록도 실려 있습니다.

한 대에게 전부 시키면 왜 멈추는가

Claude Code나 Codex와 같은 코딩 에이전트에게 어느 정도 규모가 큰 기능을 통째로 맡겨보았다가, 도중에 속도가 줄어든 경험이 있으신가요?

요건 확인부터 설계, 구현, 리뷰, 릴리스 판단까지 모든 것을 하나의 에이전트가 하나의 컨텍스트 (context) 안에서 수행하려고 하면, 어딘가에서 놓치는 부분이 섞이거나 자신이 작성한 코드를 스스로 관대하게 리뷰하게 됩니다.

하나의 컨텍스트가 가진 한계에는 에이전트를 만드는 측도 부딪히고 있습니다.

Anthropic은 Claude의 Research 기능을 Lead 한 대와 여러 개의 서브 에이전트(sub-agent) 팀으로 구성하여, 단일 Claude Opus 4를 사내 평가에서 90.2% 상회했다고 보고했으며[2], Claude Code에도 여러 팀원을 협력시키는 Agent Teams가 실험적 기능으로 도입되었습니다[3].

하지만 팀으로 구성하기만 하면 잘 된다는 이야기도 아닙니다.

실제로 제가 처음 구성한 팀도 병렬화나 비용과는 별개의 지점에서 걸림돌이 있었습니다.

구성한 방식은 똑똑한 모델 한 대를 "Lead"로 세우고, 그 아래에 여러 명의 Worker를 매다는 구조였습니다.

Lead가 태스크를 나누고, 전략을 세우고, 구현을 Worker에게 배분하며, 올라온 결과물을 검수하고, 릴리스까지 판단합니다.

언뜻 보기에는 제대로 분업이 이루어지는 것처럼 보이지만, 실제로 구동해 보니 거의 아무것도 앞으로 나아가지 못했습니다.

가장 큰 문제는 해야 할 일이 Lead로부터 누락된다는 점입니다.

Worker의 보고나 인간의 추가 요청이 도착할 때마다, Lead는 현재의 사고를 중단하고 다른 태스크의 문맥(context)으로 전환합니다.

전략을 짜는 도중에 검수가 끼어들고, 검수 도중에 다음 요청이 도착합니다.

이렇게 되면 검수 대기 중인 태스크가 방치되거나, 보냈던 지시의 팔로업(follow-up)이 사라지거나, "나중에 인간에게 확인하겠다"라고 했던 논점이 다시는 나오지 않는 등의 누락이 쌓여가게 됩니다.

정보 자체는 컨텍스트에 모두 남아 있음에도 불구하고, 불어난 이력 속에서 지금 떠올려야 할 것을 찾아내지 못하게 되는 것입니다.

이는 현재 상태에서 더 똑똑한 모델로 바꾼다고 해결될 문제가 아닙니다.

컨텍스트가 길어질수록 그 안에서 필요한 정보를 떠올리는 능력은 정도의 차이는 있을지언정 모든 모델에서 떨어지기 마련입니다.

이를 막으려면 모델을 바꾸는 것이 아니라, 한 대에게 지우는 업무량을 줄이는 수밖에 없습니다.

여기서 도출한 설계 방침은 단순합니다.

한 대에게 여러 책임을 맡기지 않고, 책임마다 별도의 에이전트를 세우며, 각각에 전용 컨텍스트를 부여한다.

이것이 customizable-agent-teams에서 가장 중시한 "책임의 분산"입니다.

책임을 분산하면, 부산물로서 역할마다 가장 적합한 도구와 모델을 선택할 수 있게 됩니다.

인간과의 접점에는 조작성이 높은 Claude Code를, 대량의 작업을 수행하는 구현에는 저렴하고 빠른 GPT를 배치하는 방식으로, Claude Code와 Codex, Claude와 GPT의 장점만을 결합하는 것을 동시에 달성할 수 있습니다.

팀의 형태와 그 이유

팀의 형태는 이전 장에서 Lead에게 쌓여 있던 책임을 해체하는 것부터 결정했습니다.

과거 Lead 혼자 담당하던 업무 중, 태스크 분해 및 할당, 진행 상태 관리, 완료 판정은 Manager로, 원인 조사 및 선택지 비교는 Strategist로, 기술 방침 판단은 Architect로, 사실 조사(Fact-finding)는 Research Worker로 옮겼습니다.

Lead에게 남긴 것은 인간과의 대화뿐이며, 의뢰를 성공 조건으로 번역하는 입구와 완성물을 확인하여 인간에게 보고하는 출구에만 전념합니다.

여기에 구현 측의 분담을 더하여, 팀은 전체적으로 11개의 역할로 구성되었습니다.

이렇게 하면 이전 장에서 놓쳤던 부분들에 대해 각각 전담 담당자가 붙게 됩니다.

검수 대기 상태의 방치나 지시 사항의 팔로업(Follow-up) 누락은 진행 상태만을 주시하는 Manager가 포착하며, "나중에 인간에게 확인하겠다"라고 말했던 논점은 대화 업무만 수행하는 Lead의 손을 떠나지 않습니다.

구현을 담당하는 Worker에게 반드시 고정된 리뷰어(Supervisor)를 붙이는 이유는, 구현 당사자는 자신의 변경 사항에 관대해지기 쉬워 종종 타협하기 때문입니다.

작성하는 사람과 검토하는 사람을 별도의 에이전트로 분리함으로써, 스스로 작성하고 스스로 승인하는 상황을 구조적으로 제거했습니다.

구현 중의 상담도 정해진 경로를 통해 흐릅니다. Worker는 먼저 고정된 Supervisor에게 상담하며, 거기서 해결되지 않는 논점만이 Manager, Strategist, Architect로 전달됩니다.

여기까지가 의뢰의 일반 레인(Normal Lane)이며, 태스크 설계, 할당, 리뷰, 수락이라는 다단계 공정이 품질을 보장합니다.

다만, 요약 행을 한 줄 추가하는 정도의 의뢰에까지 동일한 공정을 거치게 하면 대기 시간이 효율적이지 않습니다.

그렇다고 작은 변경 사항만을 인간이 팀 외부에서 직접 수정하게 두면, 리뷰와 기록을 거치지 않은 변경 사항이 섞여 들어가게 됩니다.

그래서 작은 의뢰를 위한 빠른 경로로서, Manager를 거치지 않는 express 레인을 마련해 두었습니다.

어느 경로를 이용할지는 Lead가 판단합니다.

기준은 파일 수가 아니라 "의뢰의 본질이 하나의 변경으로서 완결되는가"입니다. 수정하는 파일이 하나뿐이라도 설계 판단이 필요한 의뢰가 있기 때문에, 망설여진다면 Supervisor가 포함된 일반 레인으로 배정합니다.

완료 단계에도 게이트(Gate)를 설치했습니다.

에이전트의 "모두 끝났습니다"라는 자기 보고를 그대로 신뢰할 수 없기 때문입니다.

Manager가 완료를 보고하려고 하면, 그 전송 시점에 검증 명령 세트가 통합된 HEAD에서 자동으로 실행되며, 통과하지 못하면 전송 자체가 실패합니다.

통과된 보고를 받은 Lead가 사용자에게 보이는 동작을 확인한 후에야 인간에게 완료를 알립니다.

역할을 11개로 나누더라도 운영 비용은 머릿수에 비례하지 않습니다.

계속 움직이는 것은 Worker와 그 Supervisor 정도이며, 나머지 역할은 의뢰나 상담이 왔을 때만 움직이고, 움직이지 않는 역할은 토큰을 소비하지 않기 때문입니다.

역할별 모델 변경

이 팀은 역할에 따라 CLI, 모델, 그리고 effort(추론의 깊이)를 각각 다르게 할당합니다.

접점인 Lead만은 비용보다 정밀도

Lead는 Claude Code의 Fable 5 (xhigh)입니다.

인간이 유일하게 접하는 접점에는 조작성 측면에서 Claude Code가 다루기 쉬우며, 모호한 의뢰를 하나씩 확인하며 성공 조건으로 번역하는 대화에는 모델로서도 Claude 계열이 적합합니다.

Fable 5는 팀에서 가장 높은 모델이지만, 접점은 주고받는 양이 적기 때문에 비용이 크게 불어나지 않는 자리입니다.

반대로 Lead가 의도를 잘못 파악하면 팀 전체가 그대로 잘못된 방향으로 달려가게 됩니다.

정밀도에 투자할 가치가 가장 큰 역할이기에, 이곳만 비용보다 정밀도를 우선시합니다.

그렇다면 Worker도 Fable 5로 설정하면 되지 않느냐고 할 수 있지만, 그것은 지양했습니다.

1태스크당 $1.29와 323초는 Sol xhigh($0.35, 144초)보다 거의 4배 비싸고 2배 이상 느리며, 병렬로 많은 양을 처리해야 하는 역할에는 허용할 수 없는 수준이기 때문입니다[4].

정액제 플랜으로 운영하고 있는 상황도 있어, 소비가 많은 Fable 5를 병행시키면 usage limit (사용 한도)에 금방 도달하게 됩니다.

Fable 5를 Lead 1개로 한정한 것은 품질의 배분인 동시에, 한도액의 배분이기도 합니다.

물량을 소화하는 계층은 저렴함과 속도로 선택한다

통상적인 구현을 담당하는 General Worker, 조사를 수행하는 Research Worker, express의 Express Worker는 GPT-5.6 Luna (high)입니다.

Luna는 3개 티어 중 가장 저렴하고 빠른 구간으로, Coding Index 63에 대해 비용은 태스크당 $0.03입니다. 동일한 high 등급인 Sol (77, $0.23)에게 능력은 양보하지만, 비용은 7분의 1 수준입니다 [5].

구현이나 조사는 1개의 절대적인 똑똑함보다, 저렴하고 빠르게 많은 양을 처리할 수 있는 것이 중요한 경우가 많기 때문에 이 구간에 배치했습니다.

이렇게 저렴한 티어에 맡길 수 있는 이유는, 품질 보증을 Worker 단독에게 책임지게 하지 않기 때문입니다.

General Worker의 구현은 한 단계 능력이 높은 별도 모델의 리뷰를 거쳐야만 done (완료) 상태가 됩니다.

리뷰는 별도의 계통을 가진 모델로 한 단계 높게

그 General Reviewer는 Sol의 low입니다.

여기에는 시행착오가 있었습니다.

처음에 배치했던 중위 티어인 Terra는, Terra/high가 Luna/xhigh에 비해 능력, 비용, 속도 모두 뒤처져서 제외했습니다.

다음으로 Worker와 동일한 Luna를 xhigh로 올리는 방안도 검토했지만, 같은 모델을 사용하면 Worker가 놓치는 습관을 리뷰어도 공유하게 됩니다.

Sol을 low로 돌리면 Coding Index 70으로 Worker인 Luna (63)보다 한 단계 높고, 비용은 $0.06, 속도는 Worker와 거의 비슷합니다.

별도의 계통을 가진 모델에 의한 리뷰를 비용과 속도의 악화 없이 추가할 수 있는 자리가 바로 Sol/low였습니다 [5:1].

어려운 판단이 나오면 리뷰어는 혼자 안고 가지 않고, Sol xhigh인 중추로 에스컬레이션 (escalation)합니다.

난제와 중추는 프론티어급으로, 화면 리뷰는 Claude로

어려운 디버깅을 담당하는 Hard Task Worker, 화면을 만드는 Frontend Worker, 판단의 중추인 Manager, Strategist, Architect는 Sol (xhigh)입니다.

Coding Index 78로 Luna를 명확히 상회하는 만큼 비용은 10배가 들기 때문에, 차분한 추론이 필요한 역할에만 비용을 지불합니다 [5:2].

Frontend Critic만은 GPT가 아닌 Claude Code의 Opus 4.8입니다.

프론트엔드의 좋고 나쁨은 테스트의 Green (통과)만으로는 측정할 수 없으며, visual hierarchy (시각적 계층 구조)나 조작감은 실제 화면을 보고 나서야 비로소 판단할 수 있습니다.

개인적으로 Claude 계열이 프론트엔드 센스가 Codex보다 좋다고 느끼기 때문에, 뷰 (view) 설계나 화면을 확인하는 리뷰어로서 이곳만 특별히 Opus를 배치했습니다.

이 배분은 Pareto 프론티어 위에 있는가

실제 구성을 Artificial Analysis의 수치로 나열하면 다음과 같습니다.

가로축을 비용, 세로축을 Coding Index로 잡으면, 그 능력을 가장 저렴하게 낼 수 있는 경계 (Pareto 프론티어)를 그릴 수 있습니다.

Worker, Reviewer, 난제의 세 가지 선택은 모두 이 선 위에 놓여 있으며, 예를 들어 Terra/high를 사용하는 방안이나 Luna를 xhigh로 끌어올리는 방안은 선 아래 (비용 대비 성능이 최적화되지 않은 영역)로 떨어집니다.

이는 하나의 지표에 대한 이야기이므로, Artificial Analysis 이외의 독립적인 4개 벤치마크 (benchmark)에서도 순위를 확인했습니다.

어떤 벤치마크에서도 Luna는 Sol의 92~97% 수준을 보여주고 있으며, 태스크 단가가 7분의 1이라는 점을 고려하면 물량을 소화하는 역할에 Luna를 배치하는 것은 이치에 맞습니다 [6].

다만 주의할 점으로서, Luna는 긴 문맥 (Long Context) 회상 능력이 약하며, 큰 리포지토리 (Repository)를 깊게 추적하는 작업에서는 명확한 약점이 나타납니다.

여러 코드 패스 (Code Path)를 계속해서 추적해야 하는 태스크 (Task)는 Luna Worker에게 끈기 있게 맡기지 말고, 처음부터 Sol xhigh의 Hard Task Worker에게 할당합니다.

모델은 설정 파일 1개로 변경 가능

이러한 배분은 .agents/config/agent-team.yaml에 정리되어 있으며, model과 effort를 수정하는 것만으로 교체할 수 있습니다.

- id: general-worker-1
role: general-worker
cli: codex
...

예산이 엄격하다면 전체를 Luna 위주로, 품질이 최우선이라면 구현 단계까지 Sol 위주로 조정하는 작업을 파일 하나로 끝낼 수 있습니다.

역할 구성은 유지한 채 모델만 교체할 수 있다는 점이 이름의 유래입니다.

분담은 약속이 아니라 구조로 지킨다

책임을 나누고 모델을 할당하더라도, 그 분담이 실제로 지켜지지 않는다면 의미가 없습니다.

에이전트 (Agent)는 긴 지시 사항을 아무렇지 않게 잊어버리기 때문에, 문서에 적어두고 "지켜줘"라고 부탁하는 것만으로는 분담이 반드시 무너지게 됩니다.

그래서 역할 간의 연락은 모두 검증이 포함된 하나의 입구를 통하게 했으며, 경계를 침범하는 송신은 명령 단위로 실패하도록 설계했습니다.

구현 Worker는 Supervisor를 건너뛰고 상담할 수 없으며, 최종 리뷰 요청은 보고서와 커밋 (Commit)이 갖춰져 있지 않으면 보낼 수 없습니다.

메시지도 결과물도 모두 파일로서 git에 남기 때문에, 중간에 멈추더라도 상태를 읽을 수 있고 누가 무엇을 판단했는지 나중에 추적할 수 있습니다.

사용법

기동은 2단계입니다.

make bootstrap으로 Lead를 실행하여 무엇을 만들지 대화로 요건을 결정하면, make bootstrap-team으로 나머지 역할들을 한꺼번에 실행합니다.

그 후에는 Lead의 pane에서 진행 상황을 지켜보며, 질문을 받으면 답변하기만 하면 됩니다.

필요한 것은 git, make, bash, tmux, direnv 그리고 사용하는 코딩 에이전트의 CLI입니다.

실제로 돌리면 어떻게 작동하는가

이 기사의 원고는 Claude Code 위에서 동작하는 Fable 5와 함께 작성했습니다.

마무리 단계로, 그 Fable 5에게 dogfooding 운전을 통째로 맡겼습니다.

이 항목은 실제로 Agent Team을 이용한 Fable 5 스스로가 작성한 보고입니다.

프로덕트를 하나 만들어 보았다

템플릿을 리포지토리째로 clone 하고, 정규 Quick Start 절차에 따라 시작하여, Lead의 "무엇을 만들까요?"라는 질문에 "Zenn의 기사를 관리하는 CLI tool"이라고 답했습니다.

팀이 만든 것은 zenn-manager라는 Python 기반의 CLI입니다.

기사 목록 표시, 신규 생성, frontmatter 검증, 이미지 참조 검증의 4가지 기능이 통상 태스크 7개와 express 태스크 2개로 구현되었으며, 테스트는 초기 5개에서 130개까지 늘어났습니다.

인간이 작성한 코드는 단 한 줄도 없습니다.

frontmatter 검증의 판정과 문구가 Zenn 공식 validator와 동일한 이유는, 구현 전에 Research Worker가 공식 구현 코드를 조사했고, 그 조사 결과가 태스크 지시서에 구현 근거로 인용되었기 때문입니다.

기능 추가 1개 분량에 42분

4가지 기능 중 마지막으로 추가한 "이미지 참조 검증"은, 저자가 요청을 입력한 시점부터 완료가 commit 될 때까지 실측 결과 42분이 걸렸습니다.

전반부 23분 동안에는 구현 (Implementation) 구간이 없습니다.

팀은 조사와 설계, 그리고 인간에게 질문하는 데 시간을 쓰고 있습니다.

조사 과정에서 "zenn-editor는 기사 본문의 생 HTML을 이스케이프 (Escape)하므로, <img>는 Zenn 상에서 렌더링되지 않는다"라는 사실이 밝혀지자, Manager는 이것이 구현 단계에서 임의로 결정해도 되는 문제가 아니라고 판단하여 태스크를 보류한 채 질문을 Lead에게 올렸습니다.

Lead가 이를 조사 commit을 근거로 한 선택지로 구성하여 인간에게 제시하고, 저자가 "렌더링되지 않는 참조는 대상에서 제외"라고 답하기까지 3분이 걸렸습니다.

답변이 설계 노트와 기계 판독 가능한 기록으로 남은 후에야 비로소 구현이 시작되었습니다.

그대로 두었다면 재작업 (Rework)이 되었거나, 아무도 알아채지 못한 채 사양 (Specification)으로 굳어졌을 법한 허점이 구현 전에 인간에게 전달된 것입니다.

역할을 나눈 효과를 가장 크게 느낀 순간은 바로 이 장면이었습니다.

태스크가 완료(done)된 후에도 완료 게이트(completion gate)를 통과합니다.

완료 보고를 전송할 때 검증(verification) 명령 세트가 HEAD에서 자동으로 실행되며, 보고를 받은 Lead는 fixture와는 별개의 임시 리포지토리(temporary repository)를 직접 생성하여 실제 CLI의 동작을 확인한 뒤에야 인간에게 완료를 보고해 왔습니다.

완료 커밋(commit) 직후에 저자가 보낸 "validate에 요약 행 1줄, README에 설명 1줄을 추가해달라"는 작은 요청은 Lead가 express(즉시 처리 가능)로 판단하였고, 테스트와 README를 포함한 3개의 파일이 6분 만에 돌아왔습니다.

마치며

가장 효과가 컸던 설계 판단은 Lead로부터 책임을 분리한 것이었습니다.

그리고 책임을 분리했기에 역할마다 모델을 선택할 수 있습니다.

창구 역할은 Fable 5, 양적인 구현과 조사는 Luna, 난제와 중추는 Sol, 일반적인 리뷰는 별도의 Sol low를, 화면을 보는 리뷰만 Opus를 사용합니다.

"어떤 모델이 최강인가"라는 질문은 모델이 늘어날 때마다 어려워지지만, "이 역할에는 어떤 모델이 적합한가"라는 질문이라면 수치와 운영을 통해 답을 낼 수 있습니다.

역할을 나누는 것은 모델 선택을 용이하게 만드는 방법이기도 합니다.

템플릿을 공개하고 있으니, 우선 직접 사용해 보신다면 기쁘겠습니다.

예를 들어 Vellum의 해설이나 Fable 5와 GPT-5.6의 비교 기사. Simon Willison은 reasoning (추론) 토큰의 양이 모델마다 너무 달라서, 토큰 단가만으로는 더 이상 비교할 수 없다고 기술했다. ↩︎

How we built our multi-agent research system (Anthropic, 2025년 6월). 토큰 소비가 일반적인 채팅의 약 15배에 달한다는 점과, 코딩은 연구만큼 병렬화할 수 없다는 점에 대한 주의사항도 해당 기사에서 확인 가능. ↩︎

Claude Code의 Agent Teams 문서. 2026년 7월 시점에서는 실험적 기능. ↩︎

Artificial Analysis의 Claude Fable 5 페이지 참조 (Coding Index 76, $1.29, 323초). SWE-Bench Pro에서는 Fable 5가 큰 차이로 1위(80 대 64.6)를 차지했으나, OpenAI가 측정 방식에 의문을 제기하고 있다. ↩︎

GPT-5.6 각 티어(tier)별 effort에 따른 Coding Index와 비용은 Artificial Analysis의 각 모델 페이지(Sol, Terra, Luna) 참조. ↩︎ ↩︎ ↩︎

SWE-Bench Pro, Terminal-Bench 2.1, DeepSWE v1.1, Agents' Last Exam의 티어별 스코어는 kingy.ai와 Vellum에서 참조. ↩︎

Discussion