Claude Code에서 Opus 5.5와 Sonnet 5.5, 어떤 작업에 써야 할까

Opus 5.5가 예상보다 빠르다면 반복 작업까지 모두 맡기는 편이 나을까? Sonnet 5.5 출시로 이 질문은 성능보다 작업당 비용과 검토 시간의 문제가 됐다. Claude Code에서 두 모델을 어떻게 나눠 쓰고 무엇을 같은 조건에서 비교해야 하는지 살펴본다.

Opus 5.5가 빨라졌어도 Sonnet과의 역할은 다르다

Anthropic은 Opus 5.5에 더 낮은 지연의 Fast mode를 제공한다. 모델 문서에서는 Opus 5.5의 상대적 지연을 ‘보통’, Sonnet 5.5를 ‘빠름’으로 분류한다. 이전 Opus를 쓰던 사람은 속도 향상을 느낄 수 있다. 그렇다고 그 체감만으로 Sonnet보다 빠르다고 단정할 수는 없다. (anthropic.com)

커뮤니티에서는 Opus 5.5의 응답이 Astra나 Fable보다 경쾌하다는 의견이 여러 차례 나왔다. Fable 5.1과 결과물의 차이가 크지 않다는 평가도 있었다. 두 평가는 각자의 작업과 설정에서 나온 인상이지 모든 과제에 적용되는 순위는 아니다.

공식 모델 안내는 Opus 5.5를 장시간 코딩과 지식 작업의 출발점으로 제시한다. 더 어려운 추론이 필요하고 Opus의 높은 effort로도 부족하면 Fable 5.1을 고려하라고 한다. Sonnet 5.5는 속도와 성능의 조합을 앞세운다.

어느 모델이 좋은지는 답변 한 번의 속도보다 수정과 확인을 마칠 때까지 걸리는 시간에 달려 있다. (platform.claude.com)

Sonnet 5.5의 절반 가격이 절반의 작업비는 아니다

Anthropic이 공개한 API 정가는 입력·출력 100만 토큰당 Opus 5.5가 각각 4달러·20달러, Sonnet 5.5가 2달러·10달러다. 같은 양의 비캐시 토큰을 쓴다면 Sonnet의 가격은 절반이다. 하지만 에이전트가 파일을 다시 읽거나 도구를 여러 번 호출하면 두 모델의 총 토큰량부터 달라진다. (anthropic.com)

Sonnet을 반복 작업용 워커로 쓰겠다는 커뮤니티 의견은 그래서 설득력이 있다. 아직 그 기대가 모든 저장소에서 검증된 결과는 아니다. Anthropic은 자체 평가에서 Sonnet 5.5의 코딩 성능이 Sonnet 5보다 올랐고 일부 평가에서는 Opus 5.5에 근접했다고 발표했다. 공개된 평가 과제와 내 프로젝트의 실패 비용은 별개다. (anthropic.com)

써본 사람들 사이에서는 토큰 단가보다 재시도 횟수를 먼저 보자는 반응도 있다. 짧은 수정 열 건을 저렴하게 끝내는 경우와 중요한 변경 한 건을 되풀이하는 경우의 계산은 다르다. 개인 개발자에게는 월간 호출 수보다 검토를 통과한 변경 한 건의 비용이 더 쓸모 있는 단위다.

장시간 Opus를 사용하고도 표시된 사용량이 적었다는 경험 역시 흥미롭다. 다만 그 비율을 API 비용이나 다른 계정의 잔여 사용량으로 옮겨 계산할 수는 없다. Claude 도움말은 구독 사용량과 API 키의 종량제 청구를 구분하며 API 사용자는 /cost로 현재 세션의 토큰과 비용을 확인하도록 안내한다. (support.claude.com)

Claude Code에서는 주 작업과 워커의 모델을 따로 고를 수 있다

가령 작은 팀이 여러 파일에 걸친 기능 변경을 한다고 하자. 주 작업에는 Opus로 변경 범위와 위험을 검토하고 범위가 정해진 파일 점검은 Sonnet 워커에 맡길 수 있다. Claude 도움말도 어려운 설계·디버깅에는 Opus, 일상적인 코딩에는 Sonnet을 권하며 계획과 실행에서 모델을 바꾸는 방식을 소개한다. (support.claude.com)

Claude Code 안에서 /model을 실행하면 현재 모델과 선택 가능한 모델을 확인하고 바꿀 수 있다. 전용 워커가 필요하다면 프로젝트의 .claude/agents/code-reviewer.md 같은 파일에 역할을 적는다. YAML 머리말에 name, description, 허용할 tools, model: sonnet을 지정하고 본문에는 검사 범위와 보고 형식을 쓴다. 공식 하위 에이전트 문서는 이 파일 구성을 예시로 제공한다. (support.claude.com)

입력은 검토할 변경 파일과 통과 기준이다. 워커의 산출물은 지적 사항과 근거가 되고 주 작업은 수정 여부를 판단한다. 워커가 곧바로 더 싸고 정확해지는 것은 아니다. 사용 도구를 읽기 중심으로 제한한 뒤 같은 변경을 Opus 단독 작업과 비교해야 분업의 이득을 볼 수 있다. (code.claude.com)

모델 이름도 실행 환경에 따라 확인해야 한다. Claude Code 문서에 따르면 Anthropic API에서는 sonnet이 Sonnet 5.5를 가리키지만 일부 다른 제공자에서는 이전 Sonnet을 가리킨다. 버전을 고정할 필요가 있다면 모델 목록과 전체 모델명을 먼저 확인하는 편이 정확하다. (code.claude.com)

effort를 맞추지 않으면 속도와 비용을 잘못 읽는다

모델을 비교할 때는 어떤 effort로 실행했는지 함께 기록해야 한다. Anthropic 문서에 따르면 effort는 사고뿐 아니라 설명과 도구 호출에 쓰는 토큰에도 영향을 준다. 낮추면 대체로 빠르고 간결해지지만 어려운 작업에서 검증이 줄 수 있다. Claude Code에서는 /effort로 세션 설정을 바꿀 수 있다. (platform.claude.com)

다만 ‘같은 medium’도 모델 사이의 동일한 계산량을 보장하지 않는다. Anthropic은 effort 척도가 모델별로 보정된다고 명시한다. Claude Code 문서상 Opus 5.5와 Sonnet 5.5의 기본값은 medium이지만 Sonnet 5.5의 Claude Platform 기본값은 high다. 실행 경로만 달라도 기본 비교 조건이 바뀔 수 있다. (code.claude.com)

Artificial Analysis의 비교 페이지에서는 Opus 5.5 medium과 GPT-6 Sol high가 각각 지능 지수 51점과 43점이다. 반면 그 평가의 평균 작업당 비용은 각각 1.34달러와 0.38달러다. 한 모델의 품질 점수만 가져오거나 다른 effort의 가격만 가져오면 엉뚱한 결론이 나온다. 이 수치는 평가기관의 과제 묶음에서 나온 값이며 Claude Code의 실제 청구액은 아니다. (artificialanalysis.ai)

커뮤니티에서 Gemini 결과를 Opus로 다시 만들었을 때 품질 차이가 컸다는 후기도 있었다. 앱 오류나 Astra의 빠른 토큰 소모에 대한 불만도 나왔다. 각각의 경험은 비교 과제를 정하는 단서가 되지만 서비스 전체의 품질이나 결함을 입증하지는 않는다.

최종 선택은 통과한 결과물로 가려진다

비교에는 실제로 끝내야 할 변경 한 건이면 충분하다. 같은 시작 코드와 요청을 복제해 Opus 5.5와 Sonnet 5.5에 각각 맡긴다. 실행 경로, effort, 허용 도구, 완료 기준을 기록하고 테스트 통과 여부와 사람이 고친 부분을 함께 남긴다. 그다음 /cost와 소요 시간을 나란히 본다. (support.claude.com)

빠른 첫 답변이 완성 시간을 줄인다는 보장은 없다. 반대로 Sonnet의 낮은 단가도 여러 번의 재작업 앞에서는 장점이 작아질 수 있다. 설계 판단이 어려운 변경과 범위가 좁은 반복 작업을 구분해야 하는 이유다.

Opus의 속도 향상은 모든 작업을 한 모델로 몰아줄 근거라기보다 이전에는 비싸다고 피했던 작업을 다시 시험할 기회다. Sonnet 5.5가 워커로 적합한지도 기대가 아닌 통과한 변경으로 판별할 수 있다. 두 모델의 경계는 벤치마크 순위가 아니라 내 저장소에서 사람이 다시 손대지 않아도 되는 지점에 그어진다.