서론

주식회사 GENDA 개발부 엔지니어 오쿠야마입니다.

얼마 전, Claude Code와 Codex를 herdr의 별도 페인(pane)에서 조합하는 오케스트레이션(orchestration)을 baton이라는 플러그인(plugin)으로 분리한 이야기를 썼습니다.

그 baton을 실운용하며 개선하는 과정에서, 모델의 배치를 크게 변경했습니다.

지금까지 오케스트레이터(orchestrator) 역할로 할당했던 Fable 5를 제외하고, investigator라는 조사와 추론을 담당하는 새로운 자리로 다시 배치하는 변경입니다.

run 전체를 총괄하는 자리에 가장 좋은 모델을 둔다는 단순한 배치를 재검토하게 된 흐름을 기록해 두려 합니다.

baton의 좌석 구성

지난 기사의 2층 구성에서 구현층을 herdr의 페인 위임(pane delegation)에 가깝게 조정하여, 좌석이 늘어났습니다.

이번 변경 전에는 1 스코프(scope) 분량을 추출하면 다음과 같았습니다.

your current workspace
└─ tab orch
└─ orchestrator ───── buddy
...

orchestrator: 요구사항을 받아 스코프로 분할하고, 각 scope orchestrator를 총괄한다. 1 run 당 1석 -
scope orchestrator: 1 스코프를 가지며, 구현을 chunk라는 단위로 나누어 worker에게 위임한다 -
worker: chunk 단위의 구현 담당 -
buddy: 각 오케스트레이터에 붙는 독립적인 상담역 (다른 벤더의 모델)

모두 herdr의 페인 위에서 동작하는 실제 CLI 세션이며, 상호작용은 파일과 페인 간 메시지로 수행합니다.

각 좌석의 모델은 다음과 같이 할당되어 있었습니다.

오케스트레이터의 고비용 문제

지금까지 orchestrator와 scope orchestrator에는 Claude Fable 5를 할당했습니다.

run 전체를 총괄하는 자리이므로 가장 좋은 모델을 배치한다는 단순한 발상입니다.

한편으로, 이 2개 좌석의 비용이 높다는 점은 인지하고 있었습니다.

Claude 측 좌석은 구독형(subscription)으로 이용하고 있지만, statusline에 API 이용 시의 환산 비용을 표시하도록 했습니다.

오케스트레이터는 읽기와 쓰기를 계속하므로, 그곳에 최상위 모델의 단가가 반영되어 환산 비용이 눈에 띄게 쌓여갑니다.

저는 baton에 넘기기 전에 별도 세션의 Fable에게 요구사항을 다듬게 하여 Issue를 여러 개 만들게 한 뒤, 그것을 한꺼번에 baton에 넘기는 방식으로 운용하고 있습니다.

"무엇을 해야 하는가"를 생각하는 공정은 사전에 완료되어 있으므로, run 중의 오케스트레이터에게 남아 있는 업무는 "받은 정보를 적절한 담당자에게 할당하는 것"이 중심입니다.

• plan을 chunk로 분해하여 worker에게 전달한다.
• worker로부터의 보고를 읽고 다음 지시를 결정한다.
• consult에 판단을 반환한다.

모두 중요한 업무이지만, 최상위 모델의 지능이 항상 필요한 것은 아닙니다.

이 전제라면 비용 절감의 방안을 찾을 수 있을 것 같습니다.

Claude 모델 단가는 대략 이 비율입니다 (공식 요금 페이지 기준, input/output 모두 per MTok).

이 비용 구조의 정리는 이전 별도 기사에서도 작성했습니다.

그렇다고 해서 교체할 결정적인 계기는 없었기에 그대로 두었습니다.

Opus 5라는 선택지

그때 Opus 5가 출시되었습니다.

Fable의 절반 가격이며, 서열상 Fable 다음가는 모델입니다.

오케스트레이터 역할을 이것으로 교체하면 비용은 절반이 됩니다.

우선 그것을 시도했습니다.

하지만 실제로 orchestrator / scope orchestrator에 배치해 보니, 판단 실수뿐만 아니라 조사나 파악의 누락도 눈에 띄었습니다.

baton뿐만 아니라 평소 작업에서 사용하고 있어도, 기존의 Opus와 비교했을 때 실수나 오인이 많은 것처럼 느껴집니다.

이는 어디까지나 제 환경과 사용 방식에서의 체감일 뿐, 측정에 기반한 평가는 아닙니다.

그럼에도 불구하고 총괄역(orchestrator)의 판단 실수는 worker에게 전달하는 작업 지시서(spec)의 형태로 흘러 들어가, 구현 전체에 파급됩니다.

간과할 수 없습니다.

결과적으로 이 시점에서의 선택지는 기존처럼 Fable을 계속 사용할 것인지, Opus 4.8을 사용할 것인지, 아니면 높은 effort를 들여 Sonnet 5를 구동할 것인지의 세 가지였습니다.

참고로, Opus 5에는 기존 모델과 동작이 달라진 점을 프롬프트 측에서 조정하기 위한 공식 가이드가 마련되어 있습니다.

위에서 언급한 체감 문제가 프롬프트 조정을 통해 해소될 가능성이 있으므로, 이를 바탕으로 한 조정은 별도로 진행하고 있습니다.

사고(thinking)만을 분리하기

세 가지 선택지는 모두 오케스트레이터의 지능을 통째로 올리거나 내리는 이야기입니다.

모델을 낮추면 비용과 함께 어려운 국면에서의 사고(thinking)의 질도 떨어집니다.

여기서 발상을 전환했습니다.

오케스트레이터의 업무 중 어려운 사고(thinking)만을 별도의 자리로 분리하여, 그곳에 최상위 모델인 Fable을 배치하는 것입니다.

오케스트레이터 본체는 할당(allocation)에 전념하므로, Opus나 Sonnet으로도 충분할 것입니다.

이렇게 새로 설치한 것이 investigator입니다.

scope orchestrator 옆에 상주하는 read-only 페인(pane)으로, 조사와 추론을 전문적으로 담당합니다.

오케스트레이터에 남기는 업무: 분해, spec 작성, 보고 판정, 할당. 정형도가 높아 Sonnet 클래스로도 충분히 수행 가능할 것으로 예상
investigator에 넘기는 업무: 코드베이스 탐색, 원인 분석, 아키텍처 선택지 및 트레이드오프(trade-off) 정리. 이 부분이 결과물의 정밀도를 좌우함

즉, 모델의 투자처를 '직책'이 아니라 '실제로 어려운 사고를 하고 있는 자리'에 맞추는 배치입니다.

thinking boundary의 도입

자리를 만드는 것만으로는 사고(thinking)가 옮겨가지 않습니다.

이에 따라 baton의 역할 정의에 thinking boundary라는 규칙을 추가했습니다.

scope orchestrator의 경계는 원래 '구현은 직접 하지 않고 worker에게 위임한다(편집하지 마라)'뿐이었으나, 거기에 '조사나 분석도 직접 하지 않고 investigator에게 위임한다(직접 찾아보러 가지 마라)'를 추가한 형태입니다.

investigator에 대한 의뢰는 파일 경유의 probe라는 단위로 수행합니다.

probe-<n>-spec.md scope orchestrator가 작성: 배경, 번호가 매겨진 질문, 조사 범위, (추론을 요청할 경우) 입력 경로
probe-<n>-findings.md investigator가 작성: 질문에 대응하는 번호가 매겨진 ...

probe에는 두 종류가 있습니다.

discovery probe: 무엇이 어디에 있는가. 호출부 추적, 계약(contract) 형태 확인 등
reasoning probe: 입력값은 알고 있는 상태에서 그 바탕 위에서의 사고(thinking)를 요청. 원인 분석, 설계 선택지 비교 등

Fable을 배치하게 된 동기는 후자입니다.

reasoning probe의 findings는 "먼저 입장, 그 아래에 이유, 기각한 선택지는 한 줄씩"이라는 형태로 반환받으며, scope orchestrator는 이를 판단 재료로 소비합니다.

이 배치는 실제로 상담(consultation)이 발생해야만 의미를 갖습니다.

오케스트레이터 측에서 "이 정도는 직접 찾아보는 게 빠르겠다"라고 판단하여 상담을 중단해 버리면, 겉보기 구성은 그대로 유지된 채 어려운 사고(thinking)만 저렴한 모델로 수행되는 상태로 조용히 되돌아갑니다.

따라서 진척 보고에 probe 발행 수를 포함시켜, 상담이 실제로 발생하고 있는지를 외부에서 확인할 수 있도록 했습니다.

Claude 공식의 advisor 패턴

사실 이 "저렴한 모델이 움직이고, 상위 모델은 상담을 받았을 때만 생각한다"라는 구조는 Claude 공식 문서에도 "advisor tool"로 기재되어 있습니다.

API 레벨의 기능으로서, 저렴한 executor 모델이 생성 도중에 상위의 advisor 모델에게 전략적인 조언을 구하는 방식입니다.

The advisor tool lets a faster, lower-cost

executor 모델이 생성 중간 단계에서 더 빠르고 비용이 저렴한 advisor 모델에게 전략적인 조언을 구할 수 있게 합니다. advisor는 전체 대화 내용을 읽고 계획이나 수정 방향을 생성하며, executor는 그에 따라 작업을 계속합니다.

목적 또한 동일합니다. 토큰 생성의 대부분을 executor의 단가로 처리하면서도, advisor 단독 사용에 가까운 품질을 목표로 한다고 명시되어 있습니다.

토큰 생성의 대부분이 executor 모델의 비용으로 이루어지는 동안, advisor 단독 사용에 가까운 품질을 얻을 수 있습니다.

— 상동

문서에는 "Sonnet을 복잡한 태스크에 사용하고 있다면, 상위의 advisor를 추가하라. Fable를 사용한다면 품질 향상 폭이 최대가 된다"라는 활용 방식까지 적혀 있습니다.

공식적으로 권장하는 배치 방식이라는 점이 이번 판단에 힘을 실어주었습니다.

차이점도 있습니다.

advisor tool은 1개의 요청 내에서 완결되는 서버 사이드(server-side) 메커니즘으로, advisor는 집행역의 transcript를 전달받아 조언을 반환할 뿐입니다.

baton의 investigator는 상주 페인(resident pane)이므로, probe를 거치며 컨텍스트(context)가 축적되고 스스로 파일을 읽으러 갈 수 있습니다.

반면, 왕복 과정이 파일을 통해 이루어지므로 레이턴시(latency)는 크며, 이 점에서는 advisor tool이 더 가볍습니다.

마치며

run 전체를 총괄하는 자리에 가장 좋은 모델을 배치한다는 서두의 배치는 저의 운영 방식에서는 옳지 않았습니다.

비용을 의식하고, Opus 5로의 교체를 시도해 보고, 체감상 보류하는 과정을 거치며 멀리 돌아온 끝에 도달한 결론은 "상위 모델은 지휘가 아닌 상담을 받는 측에 배치한다"라는 구성입니다.

사전에 Issue 분해를 마친 뒤 전달하는 운영 방식이라면, 지휘역의 업무는 할당이 중심이 됩니다.

최상위 모델은 그 자리가 아니라, 어려운 사고를 수행하는 자리에 배치하는 것이 더 효과적이라는 것이 이번의 배움입니다.

모델 라인업이 바뀔 때마다 좌석 배치도를 재검토할 가치가 있다고 느낍니다.

Discussion