Sonnet 4.6 과 Opus 4.7 — 우리 팀의 사용 분포

결제·정산 현장에서 모델 선택은 단순한 비용 최적화가 아니다

LLM을 사내 챗봇이나 글쓰기 보조 도구로 쓰는 팀과, 결제 흐름·정산 자동화·이상 거래 분류 파이프라인 한가운데에 LLM을 심어둔 팀은 모델 선택 기준 자체가 다를 수밖에 없다. 우리(HEDVION)는 후자에 해당한다. 매일 수백 건의 정산 처리 흐름이 LLM 호출을 통과하고, 분류 오류 하나가 입금 지연이나 정산 불일치로 이어진다. 이 맥락에서 "더 좋은 모델"이란 질문은 UX 차원이 아니라 운영 신뢰도 차원의 문제다.

비용 이야기를 먼저 꺼낼 수밖에 없는 이유도 여기에 있다. 파이프라인에 LLM을 심으면 호출 건수가 예상보다 빠르게 누적된다. 정산 배치 하나에 수십~수백 번 모델을 호출하는 구조가 자연스럽게 만들어지고, 단가 차이가 월 단위로 쌓이면 인프라 비용 수준으로 느껴진다. Sonnet 4.6과 Opus 4.7의 토큰 단가는 입력 기준 대략 $3/M 대 $15/M, 약 5배 차이다. 배치 작업 전체를 Opus로 돌리면 불필요한 지출이 생기고, 반대로 복잡한 분석을 Sonnet에 맡기면 품질 미달로 재호출이 발생해 오히려 더 비싸진다. 어디에 무엇을 쓸지가 곧 팀의 운영 비용 구조를 결정한다.

"비싼 모델 = 어려운 작업"이라는 직관이 어디서 깨지는가

처음에 우리가 쓴 기준은 단순했다. 복잡해 보이면 Opus, 단순해 보이면 Sonnet. 이 분기가 틀린 건 아니지만, 현장에서 마찰이 생기는 지점은 "복잡함"의 정의가 생각보다 다양하다는 것이었다.

하루치 카드사 정산 파일을 항목별로 분류하고 이상 여부를 플래그하는 작업은 문서 길이만 보면 복잡해 보인다. 그런데 실제로는 패턴이 명확하고 기준이 정형화돼 있다. Sonnet 4.6에 프롬프트를 잘 설계하면 Opus와 체감 품질 차이가 거의 없었다. 반면 "이 정산 건이 왜 불일치가 났는지 추론하고 가능한 원인을 제시하라"처럼 데이터와 맥락 사이의 판단이 필요한 작업은 달랐다. Sonnet은 "다양한 원인이 있을 수 있습니다"류 일반론을 내놓는 경우가 많았고, Opus는 "3일 전 환율 적용 시점 차이로 인한 소수점 반올림 오류 가능성"처럼 데이터를 짚은 구체적 가설을 제시했다. 복잡함이 아니라 판단 포함 여부가 실질적인 분기 기준이었다.

우리의 실제 사용 분포: 호출 수와 비용이 뒤집힌다

현재 우리 팀이 정착한 분포를 공개하면 이렇다.

Sonnet 4.6이 담당하는 영역

정산 파일 항목 분류 및 1차 이상 탐지 (배치, 대량 반복 호출)
코드 초안 생성, PR 리뷰 보조
API 명세·변경 이력 등 반복 문서화
고객 문의 1차 응답 초안

Opus 4.7이 담당하는 영역

정산 불일치 원인 심층 분석 및 가설 제시
복잡한 결제 플로우 설계와 엣지케이스 검토
계약 구조·리스크 판단 등 중요 의사결정 문서
신규 자동화 로직의 논리적 완결성 검증

호출 건수 기준으로는 Sonnet 4.6이 전체의 약 75%를 차지한다. 그런데 비용 기준으로는 Opus 4.7이 전체 LLM 지출의 55~60%를 가져간다. 건수와 비용 분포가 뒤집히는 구조다. 처음에는 직관에 어긋나 보였지만 따지고 보면 합리적이다. Opus를 쓰는 작업은 한 번 호출에 컨텍스트가 길고, 그 답변이 "한 번에 맞아야 하는" 성격이다. 재시도 비용을 포함해 계산하면 Opus 한 번이 Sonnet 두세 번보다 실질 비용이 낮은 경우도 있다.

자동 라우팅을 시도했다가 포기한 이유

사람이 매번 모델을 판단하는 게 비효율적으로 느껴져 자동 라우팅 레이어를 만든 적이 있다. 요청 텍스트의 길이, 특정 키워드 포함 여부(예: "분석", "설계", "검토"), 호출 빈도를 기준으로 자동으로 Sonnet 또는 Opus에 배정하는 방식이었다.

결과는 기대와 달랐다. 분류 실패율이 약 20~25%에 달했다. 짧지만 판단이 중요한 요청("이 정산 정책이 약관 위반에 해당하는가")이 Sonnet으로 내려갔고, 길지만 반복성 높은 배치 작업이 Opus로 올라갔다. 잘못 라우팅된 결과의 품질이 기대 이하면 사람이 다시 판단해 재호출했는데, 재시도 비용을 합산하면 라우팅 전보다 총비용이 오히려 올라갔다. 라우터 자체를 LLM으로 만드는 방법도 실험했지만 라우터 호출 비용이 추가되면서 손익분기점이 나오지 않았다. 결국 사람이 작업 특성을 판단하고 모델을 명시적으로 선택하는 방식으로 돌아왔다. 자동화가 항상 효율적이지 않다는 현장 교훈이다.

실제 적용 시나리오: 정산 불일치 분석 파이프라인의 단계별 모델 배치

구체적인 운영 예시를 하나 공개한다. 우리가 운영하는 일 단위 정산 자동화 파이프라인은 아래 5단계로 구성된다.

수집·파싱: 카드사·PG사 정산 파일을 수집하고 항목별로 파싱 → Sonnet 4.6 (반복성 높음, 패턴 명확)
1차 분류: 항목별 정상/이상 플래그 분류 → Sonnet 4.6 (분류 기준이 규칙화돼 있음)
불일치 탐지: 내부 장부와 정산 금액이 맞지 않는 항목 추출 → 규칙 기반 코드 (LLM 불필요)
심층 분석: 불일치 원인 추론 및 가설 제시 → Opus 4.7 (이 단계만 Opus)
대응 초안: 관련 부서 공유용 설명 문서 생성 → Sonnet 4.6 (정형화된 문서화)

Opus는 4번 단계에만 들어간다. 전체 파이프라인 호출 중 Opus 비중은 510%에 불과하지만, 이 단계의 답변 품질이 전체 처리 시간을 결정한다. 실제로 Opus를 빼고 Sonnet만 썼을 때는 4번 단계에서 모호한 답변이 반복됐고, 담당자가 수동 분석에 3040분을 추가로 썼다. Opus를 4번에만 넣었더니 분석 시간이 평균 10분 이내로 줄었다. 모델 한 단계 교체가 실질적인 운영 효율 개선으로 이어진 케이스다.

지금 당장 써먹을 수 있는 모델 선택 기준 5가지

이론이 아니라 바로 적용 가능한 기준만 정리한다.

1. 분기 기준을 '복잡도'가 아닌 '판단 포함 여부'로 바꿔라. 입출력이 정형화돼 있고 패턴이 반복되면 Sonnet으로 시작한다. "왜", "어떻게 판단해야 하는가"가 핵심이면 Opus로 시작한다. 길이나 도메인 복잡도는 보조 기준일 뿐이다.

2. 파이프라인을 통째로 한 모델에 맡기지 마라. 단계별로 어떤 모델이 적합한지 설계 시점에 명시하라. 대부분의 자동화 파이프라인에서 Opus가 필요한 단계는 전체의 10~20%에 불과하다.

3. 자동 라우팅은 규모가 충분히 클 때만 시도하라. 키워드·길이 기반 분류의 실패율은 생각보다 높다. 재호출 비용과 라우터 운영 비용을 포함해 ROI를 계산하기 전까지는 사람이 명시적으로 판단하는 것이 더 효율적이다.

4. 재시도 비용을 포함해 단가를 비교하라. Sonnet이 저렴하다는 건 재시도 없을 때 얘기다. 작업별 평균 재호출 횟수를 추적하고, Opus로 전환이 합리적인 임계점을 수치로 파악해두면 의사결정이 훨씬 빨라진다.

5. 6개월 주기로 분포를 재평가하는 루틴을 만들어라. 모델 버전은 계속 바뀐다. Sonnet이 Opus 영역을 침범하거나 가격 구조가 바뀌면 지금의 분기가 무의미해진다. 분기 기준을 문서화해두고, 새 버전 출시마다 대표 작업 10~20개를 양쪽 모델로 테스트해 분포를 재조정하는 루틴이 필요하다. "지금 맞다"가 "영원히 맞다"가 아니다.