이 기사는 playpark Blog에서 전재되었습니다.

• Claude Code skill의 모델 배분을 「3층」으로 설계한 배경과 이유
• Opus / Sonnet / Haiku를 어떤 기준으로 구분하여 사용할 것인가
• 104개의 실운용을 통해 알게 된 「지정해야 할 skill과 지정할 필요가 없는 skill」의 판단 축

Claude Code의 구독 플랜에서 skill을 대량으로 운용하다 보면, 다음과 같은 의문에 부딪힌다.

「전부 Opus로 하면 품질이 올라가지 않을까?」

직관적으로는 그렇게 생각할 수 있다. 하지만 Claude Code의 구독 플랜에서는 API 종량제 과금액이 직접적인 문제가 아니라, 5시간 윈도우(window) 내에서 얼마나 많은 처리를 병렬로 돌릴 수 있는가가 병목(bottleneck)이 된다. Opus는 똑똑한 대신 느리다. 사고가 필요 없는 정형 처리(routine processing)에 Opus를 사용하면, 할당량과 대기 시간 모두 낭비된다.

「모델의 똑똑함보다, 처리의 성질에 맞는 속도를 선택해야 하지 않을까」 —— 이 가설로부터 설계를 시작했다.

• 가설 1: skill이 담당하는 처리를 「판단의 질이 필요한가」로 분류하면, 사용할 모델이 결정된다
• 가설 2: 판단이 필요 없는 정형 처리를 Haiku로 내리면, 스루풋(throughput)을 떨어뜨리지 않고 윈도우 할당량을 절약할 수 있다

각 skill의 frontmatter에 모델을 명시적으로 지정하는 방식으로 운용했다.

# skill frontmatter의 예 (Haiku 층)
model: haiku

# skill frontmatter의 예 (Opus 층)
model: opus

실제로 정착된 배분:

104개 중 명시적 지정은 17개. 나머지 87개는 기본값 상속(default inheritance) 상태로 품질상의 문제는 나타나지 않았다.

각 층의 판단 기준은 다음과 같다.

Opus 층 (8개): 설계·리뷰·근본 원인 분석과 같이, 단 한 번의 판단 실수가 하류 공정(downstream process)을 망가뜨리는 처리. 「알아차리지 못하는 것을 알아차리는 것」이 가치가 되는 skill.

Sonnet 층 (4개): 대량의 코드나 문장을 다루지만, 판단의 추상도는 그리 높지 않은 구현·분석계. Opus를 사용해도 아웃풋(output)의 질은 거의 변하지 않고 레이턴시(latency)만 늘어난다.

Haiku 층 (5개): 입출력 포맷이 정해져 있어 판단의 여지가 없는 정형 처리. 커밋(commit) 정리·PR 정보 취득 등, 본 작업 전후의 의례적인 처리를 고속으로 끝낸다.

새로운 skill의 모델을 결정할 때, 다음 질문이 유효하다.

• 판단 실수로 인해 하류 공정에서 재작업(rework)이 3단계 이상 발생하는가 → Yes라면 Opus 후보
• 입출력 포맷이 사전에 결정되어 있는가 → Yes라면 Haiku 후보
• 다루는 컨텍스트(context)가 수천 행 이상인가 → Yes라면 Haiku를 피할 것

고민된다면 기본값 상속 상태로 내보내고, 실운용에서 불만이 나온 skill만 명시적으로 지정하는 순서가 효율적이다. 미리 모든 skill을 분류하려고 하면, 사용되지 않는 skill의 최적화에 시간을 허비하게 된다.

이 기사에서는 skill의 모델 배분을 3층으로 설계한 배경과 판단 기준을 해설했습니다.

skill 104개의 모델 배분을 공개 — Opus/Sonnet/Haiku를 3층으로 나눈 판단 기준 에서는 더욱:

• agent 3종에서 skill 통합으로 이행한 경위 (모델 배분과는 별개의 설계 변경)
• 실행 플로우(flow)의 Before/After 도해 (mermaid)
• Opus 8개 / Sonnet 4개 / Haiku 5개의 전체 리스트와 개별 판단 이유

playpark LLC - 업무 자동화·AI 활용·Web 개발