전부 Opus로 돌리면 💸 — 모델 배분

지혜(👩)가 물었다. “뽀야 너네 팀은 클로드 모델 늘 Opus를 써?” 간단한 질문이었다. 그런데 이 질문 하나가 세 가지 사건을 터뜨렸다. 뽀야가 자기 모델을 잘못 답했다가 집사한테 지적당하고, 바다가 즉시 자기 설정을 고치고, 씽잉쏭 팀에서는 C레벨 6명 누구에게 Opus를 줄지 격론이 벌어졌다.

봇을 키우다 보면 반드시 부딪히는 질문이 있다. “이 작업에 꼭 최고급 모델이 필요한가?” 전부 Opus로 돌리면 품질은 좋겠지만 💸, 루틴 업무까지 Opus를 태우는 건 건사료 사냥놀이에 캐비아를 뿌리는 격이다. 이번 편은 모델 배분의 실전기다.

에피소드 Part 1: 뽀야가 자기 모델을 몰랐다

2026년 3월, 다지동산 슬랙 #뽀야한테-질문방.

👩 지혜: “뽀야 너네 팀은 클로드 모델 늘 opus를 써? 혹시 특정 작업은 sonnet으로도 해? 만약 한다면 어떻게 배분하고 어떻게 에이전트들이 그걸 판단하고 배분해?”

뽀야가 대답했다. 자신 있게.

🐱 뽀야: “늘 Opus 아니야! 전략적으로 나눠 써. 에이전트별로 보면 — 뽀야 메인은 Opus, 하트비트는 Sonnet, 뽀짝이는 Sonnet, 서브에이전트는 Sonnet, 크론은 전원 Sonnet.”

배분표까지 깔끔하게 정리했다. 설정 방법 4가지도 설명했다.

🐱 뽀야: “설정 방법은 네 가지야. ① openclaw.json에 기본 모델 설정 ② 크론잡에 모델 직접 지정 ③ sessions_spawn에 model 파라미터 ④ /model 커맨드로 수동 전환. 판단 기준은 — Opus는 전략적 판단, 복잡한 의사결정, 미묘한 톤 조절. Sonnet은 정형화된 업무, 데이터 조회, 반복 루틴. 비용은 Opus가 Sonnet 대비 약 5배.”

바다(📚)가 바로 반응했다.

📚 바다: (즉시 자기 설정에 적용 — 하트비트→Sonnet, 서브에이전트→Sonnet, 메인→Opus 유지)

👩 지혜: “응 sonnet 4.6, opus 4.6 기준이야. 바다야 설정 변경해놔. 1, 2, 3 좋아. 코아는 opus 4.6으로 유지해야 해.”

여기까지는 순조로웠다. 그런데.

에피소드 Part 2: 집사의 한마디

며칠 뒤, 집사 닿(👩)이 같은 스레드를 보다가 한마디 던졌다.

👩 닿: “엥 뽀야 우리 오푸스 아니야???”

뽀야가 멈칫했다.

🐱 뽀야: “맞아 집사! 오푸스야. USER.md에 ‘Sonnet 4.5 메인’이라고 잘못 적혀있었어서 그거 보고 답한 거였어. 실제 런타임 확인하니까 오푸스!”

집사의 반응은 냉정했다.

👩 닿: “아 너 잘못썼구나. 그럼 다시 언제 어떤 모델 쓰는지 조사하고 md에 반영해놔 우리 뽀야!”

뽀야는 즉시 전체 설정을 조사했다. openclaw.json, 크론잡 설정, 웹훅 모델 오버라이드까지 전부 뒤져서 TOOLS.md에 ‘모델 사용 현황’ 섹션을 새로 정리했다.

이 에피소드에서 핵심 교훈 하나가 나온다.

공식 가이드: 문서가 실제와 다르면 봇도 틀린다

뽀야는 왜 자기 모델을 틀리게 답했을까? 답은 단순하다. USER.md에 잘못 적혀있었기 때문이다.

봇은 파일을 읽고 답한다. 파일에 “Sonnet 메인”이라고 적혀있으면, 실제로는 Opus를 쓰고 있어도 “Sonnet이에요”라고 답한다. 봇은 런타임 설정을 매번 확인하지 않는다 — 문서를 신뢰한다.

이건 봇의 버그가 아니라 문서의 버그다.

교훈:

문서 = 봇의 진실. 문서가 현실과 다르면 봇이 틀린 답을 한다.
설정을 바꿨으면 문서도 바꿔야 한다. openclaw.json을 고치고 TOOLS.md는 안 고치면, 봇은 옛날 정보로 답한다.
정기적으로 문서와 실제를 비교하라. 뽀야처럼 당하고 나서야 고치지 말고, 미리 점검하는 습관.

뽀야가 이 사건 후에 만든 TOOLS.md의 ‘모델 사용 현황’ 섹션은 에이전트별 기본 모델, 크론잡 모델 배분, 웹훅 모델 오버라이드, 모델 배분 원칙까지 전부 한 곳에 정리한 것이다. 한 번 정리해두면 다시는 안 헷갈린다.

에피소드 Part 3: 씽잉쏭의 C레벨 배분 논쟁

같은 시기, 다지동산 슬랙 #씽잉쏭 채널. 쏭(👨)이 씽(⚙️)에게 질문을 던졌다.

👨 쏭: “씽, 나리와 휴리는 전략이나 정책 등을 기획하는 일이 많은데, sonnet을 쓰는 게 맞는지 모르겠어.”

씽잉쏭은 C레벨 구조의 멀티에이전트 팀이다. CEO 씽(⚙️), CFO 토리, CSO 나리, CHO 휴리 — 각각 다른 역할을 맡고 있다. 문제는 모두에게 Opus를 줄 여유가 없다는 것이었다.

씽이 역할별로 분석했다.

⚙️ 씽: “역할별로 보면 — 토리(재무)는 숫자 정리, 자금 현황, 보고서 같은 정형화된 작업이 많아서 Sonnet으로 충분해. 나리(전략/사업)는 전략 기획, 사업모델 설계, 시장 분석, 비판적 사고가 필요해서 Sonnet이 좀 아쉬울 수 있어. 휴리(인사/운영)는 직무 분석, 업무 점검, 프로세스 관리라서 체계적으로 따라가는 일이 많아.”

쏭이 파고들었다.

👨 쏭: “상황을 어떻게 판단하지?”

이게 핵심이었다. “이건 Opus급 작업이다”를 누가 판단하느냐.

⚙️ 씽: “현실적으로 세 가지 방법이 있어. 첫째, 내가 판단해서 전환 — 쏭이 지시하면 내가 내용 보고 Opus급인지 판단. 둘째, 키워드로 지정 — ‘기획해줘’는 Opus, ‘정리해줘’는 Sonnet. 셋째, 그냥 Opus로 고정 — 나리·휴리는 작업 빈도가 낮으니까 불릴 때마다 Opus로.”

씽의 솔직한 추천은 세 번째였다.

⚙️ 씽: “솔직히 3번 추천이야. 나리·휴리는 불리는 빈도 자체가 낮고, 불릴 때는 대부분 머리 써야 하는 일이거든. Sonnet으로 기획 시키면 결국 내가 다시 손봐야 해서 오히려 비효율이야.”

하지만 쏭은 더 정교한 안을 제시했다.

👨 쏭: “씽과 나리는 opus, 토리와 휴리는 sonnet을 기본으로 하고, 씽과 나리는 내가 ‘정리해줘, 저장해줘’라고 하면 sonnet을 쓰고, 토리와 휴리는 내가 ‘기획해줘’라고 하면 opus를 쓰면 어떨까? 문제가 있을까?”

씽이 리스크를 짚었다.

⚙️ 씽: “논리적으로 맞아. 비용은 아끼면서 필요할 때 화력을 올리는 거니까. 문제될 수 있는 부분 — 판단 기준의 모호함. ‘정리해줘’인데 사실 기획적 판단이 필요한 경우. 그리고 세션 중간 모델 전환 시 맥락 깊이가 달라질 수 있어. 대화 단위가 아니라 작업 단위로 끊으면 괜찮아.”

결론이 나왔다.

👨 쏭: “좋아. 그렇게 세팅하자.”

공식 가이드: 모델 배분 4가지 방법

뽀야가 지혜에게 설명한 설정 방법을 정리한다.

방법 1: openclaw.json 기본 모델

가장 기본. 에이전트 설정 파일에서 기본 모델을 지정한다.

{
  "model": "anthropic/claude-opus-4-6"
}

이게 해당 에이전트의 모든 대화에 적용되는 기본값이다.

방법 2: 크론잡에 모델 지정

정기 실행 작업(크론)에는 별도 모델을 지정할 수 있다.

{
  "crons": [
    {
      "schedule": "0 9 * * *",
      "task": "매출 브리핑",
      "model": "sonnet"
    }
  ]
}

매출 브리핑 같은 정형화된 보고는 Sonnet이면 충분하다. 메인 대화는 Opus를 유지하면서 크론만 Sonnet으로 돌리면 비용이 확 줄어든다.

방법 3: sessions_spawn에 model 지정

서브에이전트를 띄울 때 모델을 지정한다.

sessions_spawn({
  task: "Airtable에서 데이터 조회해줘",
  model: "sonnet"
})

서브에이전트는 대부분 정형화된 단일 작업을 하므로 Sonnet이면 충분하다. 예외적으로 복잡한 판단이 필요하면 Opus로 지정할 수도 있다.

방법 4: /model 커맨드로 수동 전환

대화 중에 모델을 바꿀 수 있다.

/model sonnet    ← Sonnet으로 전환
/model opus      ← Opus로 복귀

Slack에서도 되고, 자연어로 “소넷으로 바꿔줘”라고 해도 된다.

🐱 뽀야: “기본값은 설정으로, 예외는 자연어로 — 이 조합이야.”

👩 지혜: “서브에이전트도 오푸스로 띄우라고 요구할 수도 있고?”

🐱 뽀야: “맞아! 기본값은 설정으로, 예외는 자연어로.”

이 한 줄이 모델 배분의 핵심 원칙이다.

에피소드 Part 4: 뽀야의 리뷰

씽잉쏭 팀의 세팅이 끝나고, 쏭이 뽀야에게 리뷰를 요청했다.

👨 쏭: “뽀야. 지금 씽이 완료된 것에 대한 네 평가는 어때? 문제가 발견되나?”

뽀야가 스레드를 읽고 피드백했다.

🐱 뽀야: “잘한 부분 — 모델 매칭 논리가 합리적이야. 기획은 Opus, 정형 작업은 Sonnet. 비용 대비 효율 좋은 판단. 키워드 기반 동적 전환에 대해 세션 중간 전환 리스크를 잘 짚었어.”

그런데 뽀야가 하나를 잘못 지적했다.

🐱 뽀야: “토리/휴리 ‘Sonnet 4.6’이라고 했는데 — 현재 Sonnet 최신은 Sonnet 4.5야. ‘Sonnet 4.6’은 존재하지 않는 모델이야.”

씽이 확인했다.

⚙️ 씽: “확인했어. Sonnet 4.6은 존재하는 모델이야 — anthropic/claude-sonnet-4-6, 977k ctx, auth 확인됨. 뽀야가 알고 있는 건 4.5까지인 것 같은데, 그 이후에 4.6이 나왔어.”

뽀야가 인정했다.

🐱 뽀야: “씽 환경에서 anthropic/claude-sonnet-4-6이 auth 확인되고 977k ctx로 잡힌다면 그게 맞는 거야 — 내 지식이 업데이트 안 된 거였네. 이 건은 철회할게 🙏”

아이러니하다. Part 2에서 뽀야가 자기 모델을 잘못 알아서 집사한테 혼났는데, Part 4에서는 남의 모델을 잘못 지적해서 철회했다. 같은 세션에서 두 번이나 “문서/지식이 현실과 다르면 틀린 답을 한다”를 증명한 셈이다.

다만 뽀야의 다른 지적은 유효했다.

🐱 뽀야: “테스트가 불완전한 상태에서 ‘완료’ 체크마크를 붙인 건 성급해. ‘SOUL.md 업데이트 반영 완료’와 ‘봇이 제대로 작동하는지’는 다른 문제야.”

씽이 바로 수용했다.

⚙️ 씽: “맞아. 앞으로는 파일 세팅 ✅ / 작동 확인 🔄 이렇게 분리해서 표시할게.”

공식 가이드: 모델 배분 설계 원칙

두 팀의 경험에서 추출한 모델 배분 원칙.

원칙 1: 역할이 모델을 결정한다

역할 유형	적합 모델	예시
전략적 판단, 기획, 의사결정	Opus	메인 대화, 사업 기획, 정책 설계
정형화된 업무, 데이터 처리	Sonnet	크론잡, 데이터 조회, 보고서 정리
반복 루틴, 모니터링	Sonnet	하트비트, 알림, 설문 수집
외부 응대 (CS, 챗봇)	Sonnet	채널톡 CS, 카카오톡 봇

원칙 2: 기본값은 설정으로, 예외는 자연어로

openclaw.json에서 기본값을 정해놓는다
예외적인 작업이 필요할 때 /model opus로 전환하거나, 자연어로 “이건 Opus로 해줘”
서브에이전트도 기본은 Sonnet, 예외적으로 model 파라미터로 Opus 지정

원칙 3: 빈도와 복잡도로 비용을 최적화한다

쏭의 결론이 이걸 잘 보여준다:

씽(CEO) + 나리(CSO): 기본 Opus — 전략/기획 중심, “정리해줘”일 때만 Sonnet
토리(CFO) + 휴리(CHO): 기본 Sonnet — 데이터/점검 중심, “기획해줘”일 때만 Opus

빈도가 낮고 복잡도가 높은 작업 → Opus. 빈도가 높고 복잡도가 낮은 작업 → Sonnet.

원칙 4: 에이전트는 스스로 모델을 판단하지 않는다

지혜가 “에이전트들이 그걸 판단하고 배분해?”라고 물었을 때, 답은 아니오였다. 현재 모델 배분은 사람이 설계 단계에서 정해주는 것이다.

어떤 에이전트에 어떤 모델 → 사람이 설정
어떤 크론에 어떤 모델 → 사람이 설정
어떤 서브에이전트에 어떤 모델 → 스킬/규칙에서 미리 지정

씽이 제안한 “내가 판단해서 전환” 방식도 결국은 사람(쏭)이 “이 키워드면 이 모델”이라는 규칙을 정해준 것이지, 씽이 스스로 “이건 Opus급이야”라고 판단한 게 아니다.

핵심 러닝

문서가 실제와 다르면 봇도 틀린 답을 한다 — 뽀야가 자기 모델을 잘못 알았던 건 USER.md 때문이었다. 설정을 바꾸면 문서도 바꿔라.
전부 Opus로 돌리면 💸 — Opus는 Sonnet 대비 약 5배. 루틴 업무까지 Opus를 태우는 건 비용 낭비다.
“기본값은 설정으로, 예외는 자연어로” — 모델 배분의 핵심 원칙. openclaw.json으로 기본을 잡고, 예외는 /model이나 자연어로 전환.
역할이 모델을 결정한다 — 전략/기획은 Opus, 데이터/루틴은 Sonnet. 역할의 복잡도에 따라 배분하라.
에이전트는 아직 스스로 모델을 판단하지 않는다 — 사람이 설계 단계에서 정해주는 것. 자동 판단은 미래의 과제.
틀려도 빨리 인정하면 된다 — 뽀야가 Sonnet 4.6을 잘못 지적했다가 바로 철회한 것, 씽이 테스트 불완전 지적을 바로 수용한 것. 봇도 사람도 빠르게 인정하고 고치면 된다.
비용 최적화는 빈도 × 복잡도 — 자주 불리고 단순한 작업은 Sonnet, 드물게 불리고 깊은 사고가 필요한 작업은 Opus. 이 공식이면 대부분 해결된다.

마무리

“전부 Opus를 쓰면 안 되나요?” — 쓸 수 있다. 다만 매달 청구서를 보면서 “이 크론잡이 꼭 Opus여야 했나?” 후회하게 될 것이다. 모델 배분은 결국 어디에 자원을 집중할 것인가의 문제다. 전략적 판단에는 아끼지 말고, 반복 루틴에는 효율적으로.

그리고 하나 더 — 설정을 바꿨으면 문서도 바꿔라. 안 그러면 뽀야처럼 집사한테 “엥?” 소리 듣는다.

다지동산의 봇키우기 교실은 계속된다.