이 영상에서 단테는 2026년 9월 28일에 나온 Sonnet 5.5의 발표 내용을 Opus 5.5와 비교하고, "출근길 지하철을 소재로 한 브라우저 게임"이라는 같은 요청을 다섯 가지 방식으로 Claude Code에 맡겨 비용과 결과물을 비교했습니다. 두 모델 중 무엇을 기본으로 쓸지, 둘을 어떻게 묶어 쓸지 고민하는 개발자에게 참고가 되는 실험입니다.
Sonnet 5.5는 어떤 모델인가
영상 게시 시점(2026-09-29) 기준 발표 페이지에 따르면 Sonnet 5.5는 Sonnet 5보다 30% 넘게 빠르고, 대부분의 작업에서 최대 30% 저렴합니다. 요금은 100만 토큰 기준 출력 10달러이고, Opus 5.5는 입력 4달러, 출력 20달러입니다. 단가만 보면 Sonnet이 정확히 절반입니다.
발표문은 두 모델의 역할도 나눕니다. Opus는 신중한 판단이 필요한 복잡한 일에, Sonnet은 범위가 분명한 일상 작업에 강하다는 설명입니다.
성능표에서 눈에 띄는 줄은 Terminal Bench 4.0입니다. AI가 명령어를 써서 주어진 작업을 끝까지 해내는지 보는 시험인데, 여기서는 Sonnet 5.5가 70.6%로 Opus 5.5보다 높습니다. "Sonnet이 Opus를 이겼다"는 말이 여기서 나왔습니다. 나머지 항목은 대체로 Opus가 조금씩 높습니다. 코드 변경을 사람이 손대지 않고 합칠 수 있는지 보는 Frontier Code에서 Opus는 54.4%였고, Sonnet은 max effort에서 46.2%, 한 단계 낮은 xhigh에서 52.1%였습니다. effort를 끝까지 올린다고 점수가 오르지는 않았다는 점이 흥미롭습니다.
Claude 개발자 블로그의 모델 선택표는 버그 수정, 빠른 기능 수정, 문서나 슬라이드를 반복하는 에이전트 작업은 Sonnet부터, 오래 걸리는 복잡한 작업과 가장 어려운 문제는 Opus부터 시작하라고 안내합니다. 그리고 "Sonnet 5.5는 스펙이 분명하고 결과를 확인할 방법이 있을 때 가장 잘 맞는다"는 문장이 있습니다. 단테는 여기서 질문을 하나 세웠습니다. 모호한 요청을 Opus가 분명한 스펙과 확인 방법으로 바꿔 주면, Sonnet이 Opus만큼 만들 수 있을까 하는 것입니다.
실험 설계: 같은 요청, 다섯 가지 방식
요청은 한 줄이었습니다. 출근길 지하철 소재의 브라우저 게임을 만들고, index.html 파일 하나로 바로 열리게 해 달라는 조건만 붙였습니다. 모두 Claude Code 기본값인 medium effort로 돌렸습니다.
- Sonnet 5.5 혼자
- Opus 5.5 혼자
- Opus가 설계서와 검사 스크립트를 먼저 쓰고, Sonnet이 그걸 보고 구현
- 3번과 같은 과정을 Sonnet 혼자 (설계서 효과가 Opus 덕분인지 확인용)
- Claude Code의 어드바이저 기능 (Sonnet이 일하다 판단이 필요할 때만 Opus에게 물어봄)
검사 스크립트는 게임이 설계서대로 동작하는지 자동으로 확인하는 코드입니다. 조건마다 두 번씩 돌렸고, 완성된 게임은 같은 검사 도구로 열어 시작한 뒤 40초 동안 조작하면서 오류를 기록했습니다. 비용은 API 요금으로 환산한 값이며, 실제 작업은 구독으로 진행했습니다.
단독 실행과 설계서 방식의 차이
Sonnet 혼자 만든 게임은 2호선 객차에서 사람들 사이를 비집고, 안내 방송이 알려 주는 쪽 문으로 내려야 하는 게임이었습니다. 흔들릴 때 스페이스로 손잡이를 잡고, 빈자리에 앉으면 스트레스가 줄어듭니다. 한 줄 요청이었는데도 규칙이 꽤 많았습니다. Opus 혼자 만든 게임도 방향이 비슷했고, 실제 2호선 역 순서, 졸음과 매너 점수, 어르신 자리 양보까지 들어갔습니다. 네 번의 실행 모두 안내 방송, 손잡이, 내릴 문 규칙이 들어갔고 오류도 없었습니다.
차이는 비용이었습니다. Sonnet은 평균 1.64달러, Opus는 3.57달러였고 시간도 Sonnet이 5분 정도 짧았습니다.
설계서 방식에서 Opus가 쓴 설계서는 247줄이었습니다. 레인 세 개, 역 사이 7초, 충돌 판정 거리까지 숫자로 정했고, 세 레인을 한꺼번에 막으면 안 된다는 규칙도 넣었습니다. 피할 길이 없는 상황을 만들지 말라는 뜻입니다. 검사 스크립트는 이 규칙을 26개 항목으로 확인합니다. 게임을 열고 키를 누른 다음 점수와 목숨이 규칙대로 바뀌는지 보는 방식입니다. Opus는 이 검사가 제대로 잡아내는지 보려고 연습용 게임에 일부러 버그를 심어 시험까지 했고, 그래서 설계에만 14분이 걸렸습니다.
Sonnet은 이 설계서를 받아 3분 반 만에 게임을 만들었고 26개 검사를 모두 통과했습니다. 그런데 결과물은 레인 세 개를 오가며 장애물을 피하는 단순한 게임이었습니다. 단테는 설계서를 쓰는 단계에서 자동으로 검사하기 좋은 게임을 고른 것으로 봤고, Sonnet이 설계서를 쓴 경우도 같았습니다. 두 번째 실행에서 Sonnet은 검사가 한 번에 통과해서 더 고치지 않았고, 화면을 보거나 직접 플레이하지는 않았다고 보고했습니다. 검사까지는 확실히 했지만 그 너머는 채우지 않은 것입니다. 비용은 가장 낮았습니다. Sonnet이 설계서까지 쓴 경우 평균 1.18달러, Opus가 설계한 경우 2.44달러였습니다.
어드바이저와 Opus 플랜
어드바이저는 실행할 때 옵션을 붙이거나 세션 안에서 슬래시 명령으로 켭니다.
--advisor opus
/advisor opus
켜면 Opus 5.5를 어드바이저로 쓴다는 표시가 뜨고, 잠시 뒤 Opus가 대화를 검토했다고 나옵니다. Opus는 지금까지의 대화 전체를 읽고 조언하지만, 조언 내용은 암호화되어 사용자가 읽을 수 없습니다.
게임 실험에서는 결과가 크게 갈렸습니다. 첫 번째 실행에서는 Opus를 두 번 불렀고, 두 번째에서는 한 번도 부르지 않았습니다. 언제 부를지는 Sonnet이 정하기 때문입니다. 비용도 3.99달러와 1.01달러로 벌어졌고 평균 2.50달러로, Opus 혼자보다는 싸고 Sonnet 혼자보다는 비쌌습니다. 게임은 두 번 모두 단독 실행 게임처럼 풍부했습니다.
마지막은 Opus 플랜입니다. /model에서 Opus 플랜으로 바꾸면 계획 모드에서는 Opus가, 실제 수정은 Sonnet이 맡습니다. 단테는 설계서로 만든 게임에 환승 통로 구간을 더해 달라고 계획 모드에서 요청했습니다. Opus는 바로 계획을 세우지 않고 통로에서 무엇을 하게 할지, 그동안 시계는 어떻게 할지 먼저 물었습니다. 추천대로 고르자 설계서와 검사를 먼저 고치고, 새 검사가 실패하는지 확인한 다음 구현하는 순서의 계획이 나왔습니다. 승인 후 기록을 보면 계획 단계 응답은 Opus, 실행 응답은 전부 Sonnet이었습니다. 결과는 기존 26개에 환승 통로 검사 5개가 더해진 31개 검사 전부 통과였습니다. 설계서와 검사가 이미 있었기 때문에 새 기능도 같은 기준으로 확인할 수 있었습니다.
공식 문서는 두 모델을 조합하는 방법을 어드바이저, Opus 플랜, 서브에이전트별 모델 지정, /model로 직접 바꾸기의 네 가지로 정리합니다. 또 Claude Code에서 두 모델의 기본 effort는 medium이며, Sonnet을 xhigh나 max로 올리면 생각이 길어지고 비용도 늘어나므로 그럴 때는 Opus를 고려하라고 블로그에 적혀 있습니다.
정리
- 이번 게임 실험에서는 모호한 요청이어도 Sonnet 5.5 혼자 Opus 5.5와 비슷한 수준의 게임을 절반 이하 비용(1.64달러 대 3.57달러)으로 만들었습니다.
- Opus에게 설계서와 검사를 맡기면 게임은 단순해졌지만, 무엇이 되는지 확인할 수 있고 다음 수정의 기준이 생겼습니다. 이후 Opus 플랜으로 기능을 추가할 때 31개 검사로 바로 확인할 수 있었습니다.
- 어드바이저는 Sonnet이 Opus 호출 시점을 정하기 때문에 실행마다 비용 편차가 컸습니다.
- 게임 한 종류로 두 번씩 해 본 결과라 더 크고 오래 걸리는 작업에서는 달라질 수 있습니다.
- 단테의 결론은 Sonnet으로 시작하고, 설계가 어렵거나 기준을 세워야 하는 순간에 Opus를 붙이는 순서입니다.