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

모델 선택은 비용과 품질 사이의 트레이드오프라는 말을 자주 한다. 우리 팀도 Sonnet 4.6 과 Opus 4.7 을 함께 쓰면서 “어디에 무엇을 쓰는 게 맞는가”를 꽤 오래 실험했다. 지금 우리가 정착한 분포를 공유한다.

모델 선택의 기준

처음에는 단순하게 “비싼 것 = 어려운 작업, 저렴한 것 = 쉬운 작업”으로 나눴다. 실제로는 이 기준이 항상 맞지 않았다.

Sonnet 4.6 이 예상보다 잘하는 영역이 있었다. 코드 자동완성, 짧은 요약, 분류, 단순 질의응답처럼 명확하게 정의된 작업에서는 Sonnet 4.6 이 Opus 4.7 과 체감 품질 차이가 거의 없었다. 반면 비용은 의미 있게 차이가 난다.

Opus 4.7 이 확실히 더 좋은 영역도 있다. 복잡한 추론이 필요한 작업, 긴 문서를 읽고 핵심을 종합하는 작업, 코드 아키텍처 설계처럼 “판단”이 중요한 작업에서는 Opus 4.7 의 응답이 실질적으로 더 유용했다.

지금 우리의 사용 분포

대략적으로 정리하면 이렇다:

• Sonnet 4.6: 코드 초안 생성, PR 리뷰 보조, 반복성이 높은 배치 작업, 문서 초안
• Opus 4.7: 설계 검토, 복잡한 버그 분석, 중요한 의사결정이 필요한 문서

호출 건수 기준으로는 Sonnet 4.6 이 전체의 70~80% 를 차지하고, 비용 기준으로는 Opus 4.7 비중이 훨씬 높다. 호출 수와 비용 분포가 뒤집히는 구조다.

자동 라우팅을 시도했다가

처음에는 요청을 분류해서 자동으로 모델을 배정하는 로직을 만들었다. 키워드나 요청 길이를 보고 라우팅하는 방식이었다. 결론은 “그냥 사람이 판단하는 것이 더 낫다”였다.

자동 라우팅은 분류 실패 케이스가 예상보다 많았고, 잘못된 모델로 라우팅됐을 때 결과가 기대 이하면 재시도하게 되어 오히려 비용이 더 들었다. 지금은 작업 특성을 사람이 판단해서 모델을 명시적으로 선택하는 방식으로 돌아왔다.

앞으로

모델 능력이 빠르게 발전하고 있어서 지금의 분포가 6개월 뒤에도 유효하다고 보기 어렵다. Sonnet 이 더 좋아지면 Opus 를 쓰던 영역을 넘어오고, Opus 가 더 저렴해지면 분기 자체가 의미 없어질 수도 있다. 주기적으로 다시 평가하는 것이 필요하다.

— by mings