지휘는 상위 모델, 손은 하위 모델 — 에르메스단이 나눈 오케스트레이터·워커 배분법

26일 저녁 6시가 되기 조금 전, 한 참여자가 방에 구성 하나를 물었다. 클로드와 코덱스를 따로 두고 역할을 나눠 쓰는 사람이 있는지, 아니면 다른 도구로 묶는 편이 나은지였다.

혹시 그냥 순정으로 클로드랑 코덱스 두개를 기획이나 구현 검증 이렇게나눠서 하시는 분 있으신가요? 아님 오픈코덱스로하는게좋을까요

질문의 초점은 어느 모델이 더 좋으냐가 아니었다. 기획과 구현과 검증이라는 단계를 누구에게 맡기느냐, 곧 분업의 설계였다.

지휘하는 모델과 일하는 모델

2분 뒤 다른 참여자가 자신의 구성을 소개했다. 아스트라나 페이블(혹은 오푸스)을 오케스트레이터로 두고, 실제 일은 워커로 부른 하위 모델에게 맡기는 방식이다.

아스트라나 페이블(혹은 오푸스)이 오케스트레이션으로 잡고

이 구성에서 상위 모델의 몫은 직접 손을 움직이는 것보다 판을 짜고 일을 나누는 쪽에 가깝다. 질문자가 떠올린 단계별 분업을, 모델의 급에 따른 위아래 분업으로 바꿔 답한 셈으로 보인다.

같은 모델로 끝까지 돌릴까

밤 11시 무렵에는 결이 비슷한 고민이 다시 올라왔다. 한 참여자는 설계를 잘 짠 모델로 실행까지 이어 가야 결과가 더 낫지 않겠느냐고 물었다.

뭔가 설계도를 잘 만들어도 그것을 실행하는데 같은 모델로 돌리면 더 좋은 결과물? 나올 것 같아서 고민했습니다

돌아온 답은 절충이었다. 토큰이 한정적이니 계획서를 먼저 뜯어보고, 가벼운 모델로 충분한 구간만 골라 넘기라는 것이다.

계획서를 분석해서 루나로 돌려도 되는 구간을 찾아서 그것만 루나로 돌리고 나중에 리뷰 하면됩니다.

effort 설정도 같은 논리

OMP의 effort auto 설정을 두고서도 비슷한 태도가 보였다. 한 참여자는 서브에이전트에만 auto를 걸고 메인은 미리 정해 둔다고 했다.

개인적으로는 서브에이전트만 auto 두고 메인은 미리 세팅하고 씁니다

판단의 중심은 사람이 고정해 두고, 주변부의 일만 자동에 맡기는 방식으로 읽힌다. 자동 설정의 편의는 누리되, 결과를 좌우하는 자리는 손에서 놓지 않겠다는 선택이다. 오케스트레이터와 워커를 나누는 발상과 같은 선 위에 있다.

시사점

이날 오간 답들은 한 가지 방향으로 모인다. 비싼 모델은 계획과 판단과 리뷰에 쓰고, 반복되는 실행은 싼 모델에 넘기되 결과를 다시 확인한다는 것이다. 한정된 토큰이 이 배분을 밀어붙이는 조건으로 보인다.

다만 어느 구간이 하위 모델로 충분한지 가르는 기준은 대화 안에서 구체적으로 제시되지 않았다. 같은 모델로 끝까지 돌리는 편이 나은지에 대한 물음도 비교 결과 없이 조언으로만 정리됐다. 배분법이 경험칙의 단계에 머물러 있다는 점을 시사한다.