Anthropic은 Opus 5.5가 출시된 지 6일 만인 9월 28일에 Claude Sonnet 5.5를 출시했습니다. 입력 토큰 100만 개당 2달러, 출력 토큰 100만 개당 10달러로, Opus 5.5의 4달러 및 20달러와 비교하면 절반 가격입니다. 게다가 출시 페이지를 보면 대부분의 항목에서 Opus 5.5와 불과 몇 점 차이밖에 나지 않으며, Anthropic이 자체 진행한 벤치마크인 Terminal-Bench 4.0에서는 오히려 Opus 5.5를 앞섰습니다. 여러 코딩 에이전트를 운영하는 팀이라면 모든 Agent를 Sonnet으로 전환해 비용 차액을 아끼고 싶은 유혹을 느낄 만합니다.
하지만 같은 페이지에 있는 노력 수준(effort)별 차트를 살펴보면 이야기가 달라집니다. 화제가 된 Terminal-Bench 점수는 Sonnet의 최고 effort 설정에서 기록된 것으로, 시도당 12.54달러가 듭니다. 하루 종일 지속해서 실행할 만한 현실적인 설정에서는 순위가 뒤바뀝니다. Opus 5.5는 medium 설정에서 2.94달러로 57.6%를 기록한 반면, Sonnet 5.5는 high 설정에서 1.94달러로 43.0%에 그쳤습니다. Sonnet이 Opus(medium)를 넘어서는 것은 xhigh 설정에서 5.30달러를 들여 61.5%를 기록했을 때뿐입니다.
요약(TL;DR)
범위가 명확히 정의된 작업은 기본적으로 Sonnet 5.5(medium)에 맡기세요. 길거나 모호하거나 여러 영역에 걸친(cross-cutting) 작업은 Sonnet의 설정을 xhigh로 올리기보다는 Opus 5.5로 보내는 것이 좋습니다. Anthropic이 공개한 세 가지 effort별 코딩 차트 모두에서 Opus(high)는 Sonnet(xhigh)과 비슷하거나 더 저렴한 비용으로 더 높은 점수를 기록했습니다. 이를 누군가의 머릿속에만 있는 선호도가 아니라 Agent 규칙으로 명문화하세요. 모델 및 effort 티어당 하나의 Agent를 두고, 명확한 에스컬레이션 조건과 완료의 정의(definition of done)를 지정하는 방식입니다. Sharkly는 모델이나 effort를 직접 선택하지 않습니다. 어떤 Agent가 Task에서 무엇을 수행했는지 기록을 관리할 뿐입니다.
출시 지표가 실제로 뒷받침하는 것
각 수치 뒤에 적용된 effort 설정과 테스트 주체를 함께 정리한 출시 벤치마크 표는 다음과 같습니다.
| 벤치마크 | 보고 주체 | Sonnet 5.5 | Opus 5.5 |
|---|---|---|---|
| Terminal-Bench 4.0 | Anthropic | 70.6% (max) | 66.4% (xhigh) |
| FrontierCode 1.1 | Cognition | 52.1% (xhigh), 46.2% (max) | 54.4% (max) |
| CursorBench 4.0 | Cursor | 55.5% (max) | 57.8% (max) |
| SWE-Bench Pro | Anthropic 시스템 카드, max effort | 81.3 | 89.9 |
| HLE, with tools | Anthropic | 64.5% | 67.7% |
| OSWorld 2.1 | Anthropic | 80.1% | 81.8% |
Terminal-Bench 결과에는 두 가지 주의할 점이 있습니다. 시스템 카드에 따르면 플래그가 지정된(flagged) 요청이 Sonnet 5.5에서는 테스트의 1.5%에만 영향을 미친 반면, Opus 5.5에서는 10%에 영향을 미쳤습니다. 또한 Artificial Analysis의 자체 테스트에서는 Sonnet 5.5가 70.6%가 아닌 63.6%로 측정되었습니다. 한편 SWE-Bench Pro에서는 Opus가 8.6점 차이로 우위를 보였습니다. Anthropic의 포지셔닝 역시 이러한 결과와 일치합니다. Sonnet 5.5는 범위가 명확한 일상적인 작업과 버그 수정에 적합하며, Opus 5.5는 "복잡하고 개방적인 작업에서 여전히 확실히 더 강력하다"는 설명입니다.
또한 대표 수치들에는 라우팅 규칙을 수립할 때 꼭 필요한 정보, 즉 실제로 설정할 만한 effort 수준에서의 태스크당 점수와 비용(세 가지 코딩 벤치마크 기준)이 가려져 있습니다.
| 벤치마크 | Sonnet 5.5 medium | Sonnet 5.5 high | Sonnet 5.5 xhigh | Opus 5.5 medium | Opus 5.5 high |
|---|---|---|---|---|---|
| Terminal-Bench 4.0 | 28.8%, $0.83 | 43.0%, $1.94 | 61.5%, $5.30 | 57.6%, $2.94 | 64.2%, $3.88 |
| CursorBench 4.0 | 39.2%, $0.70 | 47.8%, $1.67 | 53.1%, $3.88 | 52.5%, $2.91 | 56.0%, $3.97 |
| FrontierCode 1.1 | 36.5%, $0.24 | 49.4%, $0.42 | 52.1%, $1.59 | 54.6%, $0.80 | 54.0%, $1.09 |
Sonnet 5.5는 medium과 high에서 시도당 비용이 가장 저렴하지만, 그만큼 점수도 가장 낮습니다. high를 넘어서는 순간 교차점이 발생합니다. Sonnet(xhigh)은 세 벤치마크 모두에서 Opus(medium)보다 비용이 더 많이 들며, 비슷하거나 더 적은 비용이 드는 Opus(high)에 세 항목 모두 뒤처집니다. 저렴한 모델에 비싼 모델처럼 동작하기를 요구하는 바로 그 순간, 더 이상 저렴하지 않게 되는 것입니다. CursorBench에서 Sonnet의 비용은 Anthropic의 추정치이며, 이 태스크들 중 어느 것도 여러분의 실제 코드베이스가 아니므로, 이러한 역전 현상은 직접 검증해 보아야 할 가설로 받아들이는 것이 좋습니다.
라우팅 규칙의 명문화
이전 글에서는 Agent 역할에 맞춰 모델을 매칭하고, 작업의 성격에 따라 어떤 에이전트에 작업을 할당할지 결정하며, 티어를 규칙으로 명문화해야 한다고 강조한 바 있습니다. Sonnet 5.5의 등장은 여기에 새로운 열을 하나 더 추가했습니다. Terminal-Bench에서 동일한 모델이라도 medium과 max 설정 간 시도당 비용 차이는 0.83달러 대 12.54달러로 약 15배에 달합니다. 따라서 effort를 명시하지 않은 "Sonnet으로 라우팅하라"는 지침은 온전한 규칙이라 할 수 없습니다.
| 작업 유형 | Agent(런타임 모델) | Effort | 선정 이유 |
|---|---|---|---|
| 재현 경로와 지정된 테스트가 있는 버그 수정 | Sonnet 5.5 | medium | Anthropic의 프롬프팅 가이드에서 요구사항이 명확한 작업의 에이전틱 코딩에 medium을 권장함 |
| 테스트 스캐폴딩, 문서화, 체인지로그, 의존성 업데이트 | Sonnet 5.5 | medium | 범위가 한정되어 있고 검증 비용이 낮으며, 세 차트 모두에서 태스크당 1달러 미만 |
| 단일 모듈 내의 한정된 기능 구현, 명확한 인수 조건 | Sonnet 5.5 | high | 모든 차트에서 Opus(medium)보다 여전히 저렴함. Sonnet이 실질적으로 유용한 상한선 |
| 야간 대량 트리아지(triage) | Sonnet 5.5 | low 및 검증 단계 추가 | 실행당 비용이 가장 저렴하지만, low 설정에서는 테스트를 실행하지 않고 완료로 보고할 수 있음 |
| 길거나 모호한 리팩터링, 마이그레이션, 여러 영역에 걸친 변경 | Opus 5.5 | medium 또는 high | high 설정 시 비슷하거나 더 낮은 비용으로 세 차트 모두에서 Sonnet(xhigh)을 앞섬 |
| 기획: 모호한 요구사항을 구체적인 Task로 구체화 | Opus 5.5 | high | 복잡하고 개방적인 작업은 Anthropic에 따르면 Opus가 지속적으로 우위를 점하는 영역임 |
| 다른 Agent의 결과물 리뷰 | Opus 5.5 후 사람 | high | 두 번째 모델이 근거를 검증하고, 사람이 최종 결과를 승인 |
규칙의 진가가 드러나는 지점은 바로 에스컬레이션 기준입니다. Sonnet Agent가 작업 처리에 어려움을 겪을 때 반사적으로 effort를 높이기 쉽습니다. 하지만 지표에 따르면 모델 자체를 바꾸는 것이 맞습니다. 여러 데이터를 볼 때 Sonnet(xhigh)이 필요한 Task라면 애초에 Opus(high)를 맡겨야 할 Task입니다. 조직에 맞는 조건을 설정해 보세요. 다음은 그 예시입니다.
- 동일한 검증이 두 번 실패함: 사람이 로그를 첨부하여 Task를 Opus Agent로 이동하며, 상위 티어에서 묵시적으로 재시도하지 않도록 합니다.
- 작업에 워커 허용치(예: 8개) 이상의 파일이 필요하거나, Task에 명시되지 않은 경로를 수정함.
- Agent가 Task의 문구에 대한 질문이 아니라 설계에 관한 질문을 던짐.
- 특정 유형의 Task가 Sonnet high 초과 설정에서만 통과함: 다음 스프린트에서 해당 유형의 작업을 Opus Agent로 이전합니다.
역방향도 마찬가지입니다. 적은 diff로 한 번의 시도만에 계속해서 완료되는 Opus Task라면 한 티어 낮춰 배정해야 합니다.
각 모델이 리뷰 대기열에 미치는 영향
모델과 effort만 지정하는 규칙은 반쪽짜리 규칙입니다. 나머지 절반은 '완료(done)'의 기준을 정의하는 것입니다. 티어마다 리뷰어에게 넘겨주는 결과물이 완전히 다르며, 두 모델이 출시되기 전부터 이미 리뷰는 병목 구간이었습니다. 실행 비용이 낮아진다고 해서 리뷰어의 시간이 늘어나는 것은 아니며, diff만 늘어날 뿐입니다.
Anthropic의 Sonnet 5.5 프롬프팅 가이드는 리뷰어가 마주하게 될 상황을 명확하게 설명합니다.
- low 및 medium 설정에서는 장기 에이전틱 작업 중에 조기에 확인(check-in)을 요청합니다. 보드 위에서 새벽 2시에 사람의 답변을 기다리며 멈춰 있는 Task가 그 예입니다. 한 Hacker News 댓글 작성자는 커스텀 벤치마크 점수가 7.4%에 그친 이유(Sonnet 5는 17.8% 기록)가 바로 이 조기 확인 때문이라고 지적하기도 했습니다.
- low 설정에서는 검증 단계를 건너뛸 수 있습니다. 테스트를 실행하지 않고도 코드가 완료되었다고 보고할 수 있는 것입니다. 검증 출력 결과가 없다면 트리아지 Agent의 '완료'는 아무런 의미가 없습니다.
- 모든 effort 설정에서 요청하지 않은 테스트, 문서, 자잘한 파일들을 추가합니다. 일부는 반가운 변경일 수 있지만, 결과적으로 모두 리뷰어가 읽어야 할 diff를 늘립니다.
- xhigh 및 max 설정에서는 리뷰 라운드나 리뷰어 서브에이전트(subagent)를 추가합니다. 출시 페이지에 따르면 Sonnet 5.5가 FrontierCode에서 max 설정일 때 xhigh보다 낮은 점수를 받은 이유가 바로 이것입니다. 여러 서브에이전트로 분산 실행되는 Claude Code의 코드 리뷰 스킬을 더 빈번하게 실행했고, Cognition이 조사한 두 건의 사례에서는 이것이 타임아웃이나 작업 범위를 벗어난 수정을 유발했습니다. 작업 범위를 벗어난 수정은 사람이 한 줄 한 줄 찾아내야 하므로 리뷰어에게 가장 큰 부담이 됩니다.
Opus 5.5는 대기열에 또 다른 종류의 부담을 줍니다. Anthropic에 따르면 Opus 5.5는 최대 12만 8천 개의 출력 토큰을 사용하며 18시간 이상 작업에 집중할 수 있으므로, 노이즈보다는 방대한 '규모' 자체가 부담이 됩니다. 따라서 리뷰어에게 필요한 핸드오프 패킷이 Opus에도 마찬가지로 필수적입니다.
따라서 완료의 정의는 워커 Agent의 지침(instructions)에 포함되어야 하며, Sharkly는 모든 실행마다 이를 포함합니다.
Agent: sonnet-worker (Claude Code, claude-sonnet-5-5, effort medium)
Done means:
- The checks named in the Task ran. Paste each command and its exit
code. "Tests pass" without output is not done.
- Changes stay inside the paths the Task names. List every file you
created that the Task did not ask for, and why.
- New tests are welcome. New docs files only if the Task asks.
Keep working on long Tasks. Ask only when two readings of the Task
would produce different code; otherwise proceed and record the
assumption in your report.
Stop and return to the Task, without retrying, when a check has failed
twice, the change needs more than 8 files, or the question is about
design rather than the Task's wording.
Sharkly에서 두 티어 운영하기
Sharkly는 모델을 직접 선택하지 않으며 effort를 설정하지도 않습니다. Agents 공식 문서에 명시되어 있듯이, "Agent는 Runtime의 기본 모델을 따릅니다. 특정 모델명을 보장하거나 표시하지 않습니다. 모델 변경은 Agent가 아니라 Runtime 또는 Computer 도구 설정에서 수행해야 합니다." Agent에는 사고 깊이(thinking-depth) 조절 기능도 없습니다. 티어는 Computer에 설정된 Claude Code 구성이며, Agent는 팀이 해당 구성에 작업을 할당하는 방식입니다.
따라서 티어당 하나의 Agent를 구성해야 합니다. sonnet-worker는 Claude Code가 claude-sonnet-5-5로 설정된 Computer에서 실행되고, opus-lead는 claude-opus-5-5로 설정된 Computer에서 실행됩니다. Computer는 컨테이너 형태일 수 있으므로 두 번째 티어를 만든다고 해서 노트북이 한 대 더 필요한 것은 아닙니다. 티어가 이름에 걸맞게 정확히 동작하는지는 Claude Code의 모델 설정 문서에 나오는 세 가지 세부 사항에 따라 결정됩니다.
- 전체 식별자(full id)를 고정하세요:
sonnet별칭(alias)은 Anthropic API에서만 Sonnet 5.5를 가리키며(Bedrock 및 Google Cloud에서는 여전히 Sonnet 4.5로 해석됨), Sonnet 5.5를 사용하려면 Claude Code v2.1.284 이상이 필요합니다. - Claude Code의
default모델은 Pro, Max, Team, Enterprise 및 API에서 Opus 5.5이므로, 별도로 설정하지 않은 Computer는 이미 Opus 티어로 동작합니다. - Claude Code에서 Sonnet 5.5의 기본 effort는 위에서 언급한 워커 티어인 medium입니다. 이 설정을 변경하는 것은 Agent가 아니라 Computer에서 이루어집니다.
Sharkly는 Runtime이 어떤 모델을 사용하고 있는지 안정적으로 파악할 수 없으므로, Agent 이름에 티어를 명시하고 이름과 설정을 함께 변경하세요. 구체적인 단계는 Sonnet 5.5 설정 가이드에서 확인할 수 있습니다.
하나의 Task에서 두 티어가 모두 필요한 작업에는 Crew를 사용하세요. Crew는 하나의 리더 Agent가 조율하는 사용자와 Agent들의 재사용 가능한 그룹입니다. opus-lead를 리더로 두고 Sonnet 워커들을 멤버로 배치하면, 리더가 Task를 읽고 직접 처리하거나 특정 부분을 멤버에게 멘션하여 위임하며, 멤버들은 동일한 Task에 작업 결과를 추가합니다. 이는 Hacker News 댓글 작성자들이 제안했던 'Opus 오케스트레이터' 형태이며, 인수인계 과정이 사람이 읽을 수 있는 형태로 투명하게 남습니다. 작고 명확하게 정의된 작업이라면 Crew를 거치지 않고 sonnet-worker에 직접 할당하면 됩니다.
Claude Code의 opusplan 별칭은 한 세션 내에서 이러한 방식을 일부 구현합니다. 즉, 플랜 모드에서는 Opus를, 실행에는 Sonnet을 사용합니다. 단, 여기서 Sonnet 부분은 Anthropic API에서만 Sonnet 5.5를 의미하며, Bedrock, Google Cloud 또는 Foundry에서는 이전 버전의 Sonnet으로 연결됩니다. 한 사람이 세션을 직접 실행하고 리뷰할 때는 이 방식을 사용하고, 누가 계획하고 누가 실행했는지를 다른 사람이 명확히 확인해야 할 때는 두 개의 Agent를 분리해 사용하세요.
티어 간에 절대 공유되지 않는 것이 하나 있습니다. 바로 추론(reasoning) 과정입니다. Sonnet 5.5의 thinking 블록은 해당 모델과 대화 세션에 종속됩니다. 다른 모델은 이를 읽을 수 없으며, Sonnet 5.5 역시 Opus 5.5의 thinking 블록을 읽을 수 없습니다. Crew의 디렉터리 재사용 기능은 파일을 공유할 뿐, 이전 Agent의 세션을 공유하는 것이 아닙니다. 리더가 결정한 내용은 Task에 명시적으로 기록되어야만 워커에게 전달되며, 이 내용은 별도의 게시글에서 자세히 다룹니다.
이 중 어떤 것도 작업의 최종 승인 주체를 바꾸지는 않습니다. Agent는 조사하고, 실행하고, 테스트하고, 보고합니다. 방향을 설정하고, 권한을 부여하며, 최종 결과를 승인하는 것은 사람의 몫입니다. 모델 사용은 해당 도구에 설정된 구독이나 API 키를 통해 계속 발생하므로 앞서 언급한 비용은 사용자의 제공업체 청구서에 청구됩니다. 다음 분기에 어떤 모델이 선두를 차지하든 할당 내역, 실행 로그, 질문, 결과 및 사람의 리뷰는 Task에 그대로 축적되며, Sonnet 5.5와 GPT-6 Sol 비교에서 알 수 있듯이 이러한 논리는 여러 벤더 전반에 동일하게 적용됩니다. 특정 생태계 하나에 얽매이지 않고 여러 코딩 에이전트를 유연하게 활용하고자 한다면, Sharkly는 바로 이러한 과제를 해결하기 위해 설계된 도구입니다.
