먼저 결론
수정할 파일과 성공 조건이 분명한 업무라면 Sonnet 5.5부터 시작하는 편이 합리적이다. 여러 시스템의 규칙을 함께 해석하거나, 잘못 고쳤을 때 손실이 큰 변경이라면 Opus 5.5에 검토를 맡길 이유가 생긴다. 모델 이름보다 먼저 정할 것은 작업의 범위와 검수 방법이다.
예를 들어 팀에서 쓰는 제작 요청 관리 도구에 ‘납품 형식’ 항목을 추가한다고 해보자. 입력 화면에 선택칸을 만들고, 저장 값과 엑셀 내보내기에 같은 항목을 넣는 일이다. 손댈 위치와 완료 기준을 설명할 수 있으니 비교적 범위가 좁다.
반면 요청 상태, 담당자 권한, 알림 발송 규칙을 한꺼번에 바꾸는 일은 다르다. 어느 규칙이 먼저 적용되는지 파악해야 하고 기존 기록을 망가뜨리지 않는지도 확인해야 한다. 이때는 단순히 코드를 빨리 만드는 것보다 빠뜨린 조건을 찾는 능력이 중요해진다.
Sonnet 5.5는 범위가 정해진 수정에 맞춰 나왔다
Anthropic은 2026년 9월 28일 Sonnet 5.5를 공개하며 버그 수정, 문서·슬라이드·스프레드시트 제작처럼 범위가 명확한 일상 업무에 적합하다고 설명했다. 공식 발표 기준으로 Sonnet 5.5는 Sonnet 5보다 출력 속도가 30% 이상 빠르고, 같은 작업에서 비용이 최대 30% 낮아질 수 있다. 다만 이 수치는 Anthropic의 자체 측정이며 모든 프로젝트에서 그대로 재현된다고 볼 수는 없다.
가격은 입력 100만 토큰당 2달러, 출력 100만 토큰당 10달러다. Opus 5.5는 각각 4달러와 20달러다. 단가만 보면 Sonnet이 절반이지만, 복잡한 문제를 여러 번 다시 시키면 실제 비용 차이는 줄어든다. 처음 선택을 가격표 하나로 끝내면 안 되는 이유다.
| 업무 조건 | 먼저 써볼 모델 | 이유 |
|---|---|---|
| 수정 파일과 완료 조건이 분명하다 | Sonnet 5.5 | 빠른 반복과 낮은 단가가 유리하다 |
| 원인을 아직 찾지 못한 복합 장애다 | Opus 5.5 | 여러 가설과 영향 범위를 함께 검토해야 한다 |
| 대량의 비슷한 문서·표를 만든다 | Sonnet 5.5 | 반복 작업에서 속도와 비용 차이가 누적된다 |
| 권한·결제·개인정보 규칙을 바꾼다 | Opus 5.5 + 사람 검수 | 빠른 출력보다 누락된 위험을 찾는 일이 중요하다 |
모델을 바꾸기 전에 요청서부터 좁혀야 한다
“요청 관리 도구를 개선해줘”라고만 쓰면 어느 모델이든 추측할 부분이 많아진다. 다음 네 항목을 먼저 적으면 Sonnet으로 처리할 수 있는 범위가 넓어진다.
- 현재 문제: 엑셀 내보내기에서 납품 형식이 빠져 담당자가 원문을 다시 연다.
- 바꿀 범위: 입력 화면, 저장 필드, 내보내기 열만 수정한다.
- 건드리지 않을 범위: 기존 상태값과 알림 발송 규칙은 유지한다.
- 확인 방법: 새 요청과 기존 요청을 각각 저장한 뒤 내보낸 파일의 열과 값을 비교한다.
이 정도로 조건을 좁혔는데도 수정 범위가 계속 커지거나, 테스트를 통과하지 못한 채 원인 설명이 바뀐다면 그때 Opus로 넘기는 편이 낫다. 처음부터 비싼 모델을 선택하는 것보다 전환 조건을 미리 정하는 방식이 비용을 관리하기 쉽다.
추론 강도를 높이면 항상 결과가 좋아지는 것은 아니다
Anthropic은 Claude 앱과 Claude Code에서 기본 추론 강도를 Medium으로 두고, 더 높은 설정에서는 모델이 오래 생각하고 검토한다고 안내한다. 여기서도 ‘높을수록 좋다’고 단정하면 안 된다.
Sonnet 5.5 발표의 각주에는 Max 설정에서 코드 검토용 하위 에이전트가 늘어나면서 제한 시간을 넘기거나 요청 범위 밖의 수정이 생긴 사례가 적혀 있다. 간단한 필드 하나를 추가하는데 여러 검토 역할을 붙이면 확인할 변경만 늘어날 수 있다는 뜻이다.
업무 도구 수정은 결과 화면보다 변경 범위를 확인한다
모델이 화면을 멀쩡하게 만들었다고 작업이 끝난 것은 아니다. 실제 운영 전에는 변경 파일, 데이터 구조, 기존 기록, 실패했을 때 되돌리는 방법을 확인해야 한다.
- 요청한 파일 외에 예상하지 못한 설정 파일까지 바뀌지 않았는가
- 새 필드가 비어 있는 기존 기록도 정상적으로 열리는가
- 저장·수정·내보내기 세 경로에서 같은 값이 유지되는가
- 테스트 실패나 경고를 모델이 임의로 숨기지 않았는가
- 문제가 생겼을 때 이전 버전으로 되돌릴 수 있는가
정리하면 Sonnet 5.5는 ‘성능이 낮은 대신 싼 모델’이라기보다 범위를 설명할 수 있는 반복 업무에 먼저 투입할 모델이다. Opus 5.5는 요구사항 자체가 모호하거나 판단 비용이 큰 일을 맡길 때 의미가 있다. 어느 쪽을 쓰든 완료 기준과 사람의 검수 지점이 없으면 모델 차이보다 요청 방식의 문제가 더 크게 남는다.
출시 내용과 가격, 추론 강도별 차이는 Anthropic의 Sonnet 5.5 공식 발표에서 확인할 수 있다. 국내에서 같은 프롬프트로 여러 작업을 비교한 영상은 CodeFactory의 Sonnet 5.5 비교 영상을 참고했다. 영상 결과는 실험 환경이 다르므로 이 글의 직접 성능 측정치로 사용하지 않았다.
확인일: 2026-09-29. 공식 발표와 공개 영상을 대조한 선택 가이드이며, 같은 저장소에서 Sonnet 5.5와 Opus 5.5를 실행한 벤치마크는 아니다. 작성: 노트지기.

답글 남기기