프런트엔드 AX 설계기 10편 - 단가가 아니라 실패비용으로 모델을 고른다

"모든 command가 opus를 쓰는데, command별로 다른 model을 쓰게 할 수 있나?" 한 세션에서 이 질문으로 시작했다.

 

슬래시 command마다 하는 일이 다른데 전부 최상위 모델을 태우는 게 낭비처럼 보였다. 답은 기술적으로 "된다"였다. slash command frontmatter에 model:만 박으면 command별로 티어가 갈린다. 그래서 나눴다.

 

그리고 한 달 뒤 되돌렸다.

 

이 글은 그 왕복의 기록이다. AI 에이전트를 여러 개 굴리는 팀이라면 언젠가 "이건 싼 모델로 충분하지 않나?"를 마주한다. 나는 command 단위로 한 번 싸게 내려봤다가 철회했고, 반대로 특정 에이전트 하나는 측정을 거쳐 opus로 올렸다. 결론부터 말하면, 모델 선택의 축은 토큰 단가가 아니었다.

 

command 재실행, 사람이 붙어 검수, 잘못된 산출물이 하류로 흘러가 터지는 사고. 출력 변동성은 같은 입력에도 결과가 흔들리는 정도. 이 둘의 곱이 크면 비싼 모델이 값을 하고, 작으면 단가 절감이 이긴다. (이 시리즈에서 말하는 AX는 사람이 아니라 에이전트가 상대하는 인터페이스를 설계하는 일이다. 어떤 모델을 태울지 고르는 것도 그 인터페이스의 일부다.)

큰 그림은 두 판단으로 갈린다. 위쪽은 "어디에 비싼 모델을 쓰나"를 실패비용 축에 늘어놓는 일이고, 아래쪽은 그 판단을 감이 아니라 측정으로 내리는 루프다.

싸게 내렸다가, 한 달 만에 되돌렸다

처음엔 이렇게 갈랐다. commit 메시지 뽑는 command는 haiku, PR 계열은 sonnet. 로직은 깔끔했다 — 짧고 정형화된 작업엔 싼 모델. 그런데 돌려보니 싼 모델의 출력이 들쭉날쭉했다. commit 메시지 하나가 어긋나면 다시 돌리고, 다시 돌린 command가 또 어긋나면 사람이 손으로 고친다. 그 재실행·수정 비용이 아낀 토큰값을 금방 넘어섰다.

게다가 나는 구독제(Max)를 쓴다. 토큰을 아껴도 청구서가 줄지 않는다 — 절감 인센티브 자체가 얇다. 그래서 commit 모델을 haiku에서 sonnet으로 되돌리고, 결국 override를 통째로 걷어냈다.

# before — command마다 티어를 박았다
---
description: commit 메시지 생성
model: haiku      # ← 싸게. 하지만 재실행 비용이 절감액을 삼켰다
---

# after — override 제거 → 전부 기본(상위) 티어로 원복
---
description: commit 메시지 생성
# model 라인을 지운다. frontmatter가 티어를 강제하지 않게
---

 

여기서 첫 교훈. 구독·Max 환경에서 일괄 티어 다운의 ROI는 낮다. 종량제라면 계산이 다르겠지만, 한도가 시간 단위로 리셋되는 구독제에선 "싸게"의 이득이 얇고 실패비용이 판을 지배한다.

정반대로 — 딱 한 에이전트만 opus로 올렸다

그런데 반대 방향의 아크도 있었다. 다른 세션에서 이런 질문을 받았다. "sonnet 쓰는 부분 있나? librarian은 뭐 하는 에이전트고, opus면 퀄리티 차이가 얼마나 나?"

librarian은 외부 문서를 가져와 콘텍스트에 붙이는 에이전트다. 여기서 환각은 곧 잘못된 출처다. 없는 문서를 지어내거나 링크를 틀리면, 그 위에 쌓는 판단이 전부 무너진다. 실패비용이 큰 자리다. 그래서 이번엔 내릴지가 아니라 올릴지를 측정했다. sonnet과 opus에 같은 작업을 시키고 점수를 매겼다.

 

여기서 비 자명한 게 튀어나왔다. 바꿨더니 opus인데도 점수가 떨어지는 회차가 나온 것이다. 직관과 정반대다. 나는 결론을 내리기 전에 평가 자체를 의심했다. "계속 결과가 달라지는데, 이게 실제로 효과 있는 건가?" 0.5점 차이가 실질인지 심판의 분산(노이즈)인지부터 따졌다. 측정값을 곧이곧대로 믿지 않는 것, 이게 두 번째 교훈이다.

감이 아니라 측정으로: 블라인드 A/B 테스트

그 "따지는" 방법이 블라인드 A/B 테스트이다. 같은 입력을 두 후보 모델에 주고, 어느 쪽 출력인지 모르는 제3의 심판이 채점한다. 게이트 채점을 어떤 모델로 할지도 같은 방식으로 정했다. 얼개는 이렇다.

# model-ab.yaml — 판단 워크로드 모델을 블라인드 A/B로 고르는 하네스
inputs: corpus/*.json          # 같은 입력 셋을 두 후보에 동일하게 먹인다
candidates:
  A: sonnet
  B: opus
constraints:
  token_parity: [0.99, 1.01]   # 토큰 동률: 한쪽이 장황해서 유리해지는 걸 차단
judge:
  model: fable                 # 제3의 심판
  blind: true                  # 어느 출력이 어느 모델인지 가린다
  rubric: [사실_정확도, 출처_타당성, refuted_라벨_일치]
  repeat: 5                    # 같은 쌍을 여러 번 — 분산을 보려고
report:
  # 평균만 보지 말 것. 표준편차가 점수차보다 크면 '동률'로 판정
  flag_if: stdev >= abs(mean_A - mean_B)

핵심은 세 줄이다. token_parity로 출력 길이를 맞춰 "장황한 쪽이 유리"를 막고, blind: true로 심판이 브랜드를 모르게 하고, repeat로 같은 쌍을 여러 번 돌려 분산을 본다. 마지막 flag_if가 함정을 잡는 가드다 — 표준편차가 두 모델 점수차보다 크면 그 차이는 노이즈로 보고 동률 처리한다. "opus인데 점수가 떨어지는" 역설의 대부분은 여기서 걸러진다.

 

이 하네스로 실제 나온 숫자(개인 벤치 기준): 사실 정확도 9.18 대 8.18, refuted 라벨이 엇갈린 4건은 뜯어보니 전부 한쪽 판정이 타당했다. 0.5점이 아니라 1점 차에 라벨 불일치까지 한 방향으로 쏠렸으니, 이건 분산이 아니라 실질이다. 그래서 librarian은 opus로 올리고 환각 억제 프로토콜을 함께 강화했다. 모델 라인업은 빠르게 바뀌니, 저 숫자보다 방법을 가져가는 게 낫다.

실패비용이 큰 자리만, 그리고 한도에 밀릴 때

같은 잣대를 auditor(룰 스캔 에이전트)에도 대봤다. 결과는 승격 보류. 룰 스캔은 정해진 규칙을 훑는 일이라 환각 민감도가 낮다 — 실패비용이 작으니 opus로 올릴 값이 안 나온다. 실패비용이 큰 에이전트만 opus. 이 비대칭이 요점이다.

"전부 싸게"도 "전부 비싸게"도 답이 아니었다.

 

에지 케이스가 하나 더 있다. 측정으로 상위 티어를 정해놨는데 한도에 걸려 강제로 다운그레이드되는 순간이다. "측정 없는 다운그레이드 금지"가 내 원칙인데, 한도는 그걸 안 봐준다. 여기서 원칙을 깨는 대신 복귀 조건을 미리 박아뒀다 — 한도가 회복되면 재측정 후 원래 티어로 되돌리는 earn-back 룰. 강등은 임시고, 복귀는 반드시 측정을 거친다. 팀이라면 요금제 한도 편차(상위 Max와 그보다 낮은 팀원 한도)까지 변수로 넣어 "팀 전체가 감당 가능한 선"으로 티어를 잡는다.

 

모델 선택의 축은 토큰 단가가 아니라 실패비용 × 출력 변동성이다. 전부 싸게도 전부 비싸게도 아니고, 실패비용이 큰 자리만 골라 측정을 거쳐 올린다. 그리고 측정값은 분산부터 의심하고, 한도에 밀려 내려야 하면 복귀 조건을 미리 정해둔다.

 

지금 당신의 에이전트를 실패비용 순으로 한 줄로 세워 보라. 맨 위 하나만 블라인드 A/B로 재보고, 값이 나오면 그것만 올려라.

 

2026.07.01 - [AI 엔지니어링] - 프런트엔드 AX 설계기 9편 - 외부 이슈 트래커 write 도구를 권한 경계 안에 가두기