도대체 왜 Claude Sonnet 5를 쓰는 거지?

Sonnet 5는 도구 사용 루프에도 엄청 좋음. Opus보다 훨씬 비용 효율적임. 난 회사에서 주요 모델들을 다 쓸 수 있고 수많은 통합과 내부 MCP가 연결된 "LLM-허브"를 구축했는데, 그 시나리오에서 Sonnet 5는 4.6에서 엄청나게 업그레이드된 모델임. 대부분 단순한 사용자 질문들이지만, 어떤 도구를 어떤 순서로 써야 할지, 데이터를 어떻게 올바르게 처리해서 사용자의 문제를 해결할지 이해해야 하거든.

완전 동감. 나도 Claude랑 Cursor composer 모델로 비슷한 거 함. 내 워크플로우를 인코딩하는 커스텀 플러그인이지.

• Claude Opus로 계획 짜기.
• Plannotator 플러그인으로 검토하고 피드백 받기.
• 계획 완료 훅에서 실행되는 커스텀 디스패치 스킬인데, 선택지를 줌: 1) 계획을 로컬에만 저장. 2) Composer 서브 에이전트로 디스패치하고 Opus가 오케스트레이션 및 결과 검증. 3) Cursor 클라우드로 넘기기.

진짜 잘 돌아감. 20달러짜리 Claude 플랜으로 아무 문제 없이 쓰는 중.

계획은 교체하는 거임…

ㅋㅋ. 쉬운 작업에는 훨씬 싼 옵션이 널렸지. 그게 Sonnet 5의 문제야. 어떤 카테고리로 비교해도 가성비가 꽝임.

근데 같은 가격대라면 Opus가 항상 더 나음. 거의 항상 더 싸고 더 정확하거든. 그래서 다시 원점으로 돌아오는데, 도대체 누가 이걸 쓴다는 거임?

내가 방금 언급한 것 같은 사용 사례들 때문에 쓰지. 모델 크기마다 다 쓸모가 있음. 폰에서 돌아가는 아주 작은 LLM들도 분류나 간단한 문맥 생성 같은 용도로 쓰이잖아. 완벽하거나 높은 정확도가 필요 없는 작업들 말이야. 결국 다 사용 사례 나름임. 코딩 작업에는 Sonnet 쓸 일이 별로 없겠지만, 에이전트 작업이라는 더 넓은 세상에는 엄청나게 다양한 사용 사례가 있고, 전부 다 그렇게 엄격한 기준이 필요한 건 아니거든.

맞는데, 이건 Opus보다 더 비싸면서 모든 입력값에 대해 결과물도 더 구리잖아. 모든 크기의 모델이 쓰일 곳이 있다는 건 인정하지만, 그렇다고 이 모델이 쓰일 곳이 있다는 뜻은 아님.

확실히 4.6보다 가격이 높긴 함. 그리고 Sonnet 모델은 항상 Opus보다 결과가 안 좋게 나오는데, 그건 더 작은 모델이 가지는 태생적인 한계임. Sonnet이 네 사용 사례에 안 맞으면 안 쓰면 그만임. 그렇다고 다른 사람들도 쓰면 안 된다는 건 아니지.

잠깐, 더 비싸고 성능도 구린데 도대체 왜 쓰는 거임? 사용자 입장에서 얻는 이득이 뭔데? 난 모델 크기가 뭔지는 관심 없고, 비용이랑 성능이 중요하다고.

내가 말을 좀 더 명확하게 했어야 했네. Sonnet 5는 이전에 나왔던 Sonnet 버전인 4.6보다 가격이 높게 책정됐어. 난 이전 Sonnet 릴리즈랑 가격을 비교하고 있었던 거야.