2026년 6월 30일 Anthropic은 Claude Sonnet 5를 공개했다. 이번 발표에서 봐야 할 핵심은 단순한 성능 향상이 아니라, Sonnet급 모델이 브라우저와 터미널을 쓰는 에이전트 작업의 기본 모델로 내려왔다는 점이다.
이게 왜 중요하냐면, AI 도구를 쓰는 사람 입장에서는 이제 질문이 바뀌기 때문이다. “이 모델 똑똑한가?”보다 “이 모델에게 어디까지 일을 맡기고, 어디서 사람이 멈춰 세울 것인가?”가 더 중요해졌다. 예전엔 모델 성능표 보고 와 하고 끝났다면, 이제는 권한표와 비용표도 같이 봐야 한다. 기술 뉴스 보다가 갑자기 회계팀 표정이 떠오르는 구간이다.
자료 기준으로 보면 Sonnet 5는 Sonnet 4.6보다 에이전트 성능, 도구 사용, 코딩, 지식 작업에서 좋아졌고, Opus 4.8에 가까운 성능을 더 낮은 가격대로 제공하는 쪽에 초점이 있다. 다만 새 토크나이저와 API 동작 변화 때문에 기존 워크플로를 그대로 갈아끼우면 비용과 오류가 생길 수 있다.
먼저 봐야 할 기능은 에이전트 실행력이다
Anthropic은 Sonnet 5를 “가장 에이전트다운 Sonnet”으로 설명한다. 공식 발표 기준으로 Sonnet 5는 계획을 세우고, 브라우저와 터미널 같은 도구를 사용하며, 몇 달 전만 해도 더 크고 비싼 모델이 필요했던 수준의 자율 실행을 목표로 한다.
업계어로는 agentic performance라고 부른다. 사람말로 바꾸면 “AI가 말만 잘하는 상담 직원에서, 컴퓨터 앞에 앉아 실제 일을 처리하는 직원으로 조금 더 가까워졌다”는 뜻이다. 물론 아직 신입에게 회사 법인카드를 주고 출장 보내는 느낌이면 곤란하다. 먼저 읽기 권한, 테스트 권한, 배포 권한을 나눠야 한다.
이 변화는 Claude Code 사용자에게 특히 중요하다. 코드 수정, 테스트 실행, 로그 읽기, 문서 업데이트처럼 여러 단계를 이어가는 작업에서 Sonnet 5가 기본 후보가 될 수 있기 때문이다. 기존에는 “중요하면 Opus로 올려야 하나?”를 자주 고민했다면, 이제는 “Sonnet 5로 충분한 단계와 Opus 4.8로 올릴 단계를 어떻게 나눌까?”가 더 현실적인 질문이 된다.
내가 운영한다면 첫 적용 대상은 새 기능 개발 전체 위임이 아니다. 먼저 이슈 재현, 테스트 실패 원인 요약, 린트 수정, 문서-코드 불일치 찾기 같은 낮은 위험 작업부터 붙일 것이다. 에이전트는 똑똑할수록 더 위험한 일을 그럴듯하게 해낼 수 있으니, 첫날부터 배포 버튼 근처에 앉히면 마음이 건강하지 않다.
effort 조절은 비용과 정확도의 손잡이다
Sonnet 5에서 두 번째로 볼 기능은 effort다. Anthropic 발표는 BrowseComp 같은 에이전트 검색 평가와 OSWorld-Verified 같은 컴퓨터 사용 평가에서 Sonnet 5와 Opus 4.8을 effort 수준별로 비교한다. 요지는 간단하다. effort를 높이면 더 깊게 생각하지만, 비용과 지연 시간도 같이 늘어난다.
사람말로 번역하면 effort는 “AI에게 생각을 얼마나 길게 시킬지 정하는 손잡이”다. 간단한 오타 수정에 회의실 예약하고 임원까지 부를 필요는 없다. 반대로 레거시 결제 로직을 건드리는데 3초 생각하고 바로 커밋하겠다고 하면 그건 자신감이 아니라 사고 예고편에 가깝다.
실무에서는 작업을 세 단계로 나누는 게 좋다. 단순 변환, 요약, 작은 수정은 낮은 effort로 둔다. 여러 파일을 읽고 원인을 찾아야 하는 디버깅은 중간 effort로 둔다. 아키텍처 변경, 권한 정책, 보안 영향이 있는 작업은 높은 effort 또는 Opus 계열로 올린다. 모델 선택은 취향 문제가 아니라 위험도 분류표에 가깝다.
이 지점에서 Sonnet 5의 장점은 “항상 최고 모델을 쓰자”가 아니라 “기본 작업의 품질 기준을 올리면서도 비용을 통제할 여지가 생겼다”는 데 있다. 성능이 좋아진 모델일수록 더 많은 일을 맡기고 싶어지는데, 바로 그 순간에 effort와 작업 등급표가 필요하다.
가격은 싸 보이지만 토큰 카운트는 다시 봐야 한다
Anthropic 공식 가격 문서 기준으로 Sonnet 5는 2026년 8월 31일까지 입력 100만 토큰당 2달러, 출력 100만 토큰당 10달러의 프로모션 가격이 적용된다. 2026년 9월 1일부터는 입력 100만 토큰당 3달러, 출력 100만 토큰당 15달러가 표준 가격이다. 이 표만 보면 “오, Sonnet 4.6이랑 같거나 더 싸네?”라고 느끼기 쉽다.
그런데 여기서 새 토크나이저가 등장한다. Anthropic 문서는 Sonnet 5가 새로운 토크나이저를 쓰며, 같은 텍스트가 Sonnet 4.6 이전 모델보다 대략 30% 더 많은 토큰으로 계산될 수 있다고 안내한다. 공식 발표의 주석도 입력 내용에 따라 약 1.0배에서 1.35배까지 달라질 수 있다고 설명한다.
이 말은 단가표만 보고 비용을 판단하면 안 된다는 뜻이다. 예를 들어 기존에 긴 저장소 컨텍스트, 대화 히스토리, 문서 묶음을 한 번에 넣던 팀은 Sonnet 5 전환 전에 실제 token counting을 다시 돌려야 한다. “단가는 같네” 하고 넘어갔다가 청구서에서 모델이 조용히 손 흔들 수 있다. 조용한 손 흔듦은 대체로 비싸다.
그래서 비용 체크는 세 가지로 나누면 된다. 첫째, 기존 대표 프롬프트 10개를 Sonnet 5 기준으로 다시 카운트한다. 둘째, effort 수준별 출력 토큰과 지연 시간을 기록한다. 셋째, Claude Code나 API 자동화에서 재시도 루프가 있는지 본다. 에이전트 비용은 한 번의 요청보다 “실패해서 세 번 더 돈다”에서 커지는 경우가 많다.
API 마이그레이션에서 400 에러를 먼저 확인하자
Sonnet 5는 기존 Sonnet 4.6과 API 동작이 일부 다르다. Anthropic의 “What’s new in Claude Sonnet 5” 문서는 adaptive thinking이 기본으로 켜지고, 수동 extended thinking은 400 에러를 반환하며, temperature, top_p, top_k를 비기본값으로 설정해도 400 에러가 난다고 설명한다.
이건 개발자에게 꽤 현실적인 변화다. 기존 코드에 temperature를 습관처럼 넣어두는 경우가 많기 때문이다. 예전에는 “창의성 조금 낮춰야지” 하고 넣은 설정이, Sonnet 5에서는 요청 자체를 막을 수 있다. 모델이 똑똑해졌는데 내 설정 파일이 문 앞에서 입장 거부당하는 장면이다.
실무 체크는 간단하다. Sonnet 5로 바꾸기 전에 API 래퍼에서 sampling parameter를 어디서 주입하는지 검색한다. manual thinking 설정을 쓰는 코드가 있는지도 확인한다. 그리고 모델별 설정을 분리한다. 모든 모델에 같은 옵션을 뿌리는 방식은 편하지만, 모델 세대가 바뀔수록 작은 설정 하나가 장애가 된다.
특히 사내 자동화나 블로그 발행 파이프라인처럼 백그라운드로 도는 작업은 더 조심해야 한다. 사람이 보는 채팅창이면 에러를 바로 고치지만, 자동화는 실패 로그가 쌓이고 나서야 발견된다. Sonnet 5 전환 첫날에는 production보다 dry-run, staging, 작은 배치부터 보는 게 맞다.
보안과 권한은 더 보수적으로 잡아야 한다
Anthropic은 Sonnet 5가 Sonnet 4.6보다 바람직하지 않은 행동 비율이 낮고, 에이전트 맥락에서 더 안전하게 쓰기 좋다고 설명한다. 동시에 사이버보안 작업 능력은 Opus 계열보다 낮다고도 말한다. 이 부분은 이상하게 들릴 수 있다. 좋아졌는데 보안은 조심하라니, 무슨 양손에 브레이크와 액셀을 같이 쥔 느낌이다.
실무적으로는 모순이 아니다. 모델이 더 안정적이라는 말과, 더 큰 권한을 줘도 된다는 말은 다르다. 브라우저와 터미널을 쓰는 에이전트라면 파일 읽기, 명령 실행, 외부 요청, 배포, 결제, 고객 데이터 접근을 단계별로 제한해야 한다. AI가 “제가 해둘게요”라고 말해도, 회사 시스템은 “어디까지?”라고 물어야 한다.
Sonnet 5를 Claude Code나 내부 에이전트에 붙일 때는 권한을 네 칸으로 나누면 좋다. 읽기 전용, 로컬 수정, 테스트 실행, 외부 변경이다. 처음에는 읽기 전용과 로컬 수정까지만 허용하고, 테스트 실행은 명시 승인 뒤로 둔다. 외부 변경, 배포, 결제, 고객 데이터 작업은 별도 승인 없이는 막아야 한다.
여기서 중요한 기능은 모델 자체보다 운영 방식이다. Sonnet 5가 더 에이전트다워졌다면, 우리의 체크리스트도 더 에이전트다워져야 한다. 즉 프롬프트만 예쁘게 쓰는 게 아니라, 로그, 권한, 롤백, 비용 한도, 사람 승인 지점을 같이 설계해야 한다.
주목 기능 체크표
| 주목할 기능 | 왜 중요한가 | 먼저 볼 체크 |
|---|---|---|
| 에이전트 실행력 | 브라우저, 터미널, 도구 사용 작업의 기본 모델 후보가 됨 | 어떤 작업까지 자율 실행시킬지 권한표 작성 |
| effort 조절 | 정확도, 비용, 지연 시간의 균형을 잡는 손잡이 | 작업 위험도별 effort 기본값 설정 |
| 프로모션 가격 | 2026년 8월 31일까지 입력 $2/MTok, 출력 $10/MTok | 9월 1일 이후 표준 가격으로 비용표 재계산 |
| 새 토크나이저 | 같은 텍스트가 약 30% 더 많은 토큰이 될 수 있음 | 대표 프롬프트 token counting 재실행 |
| API 동작 변화 | temperature/top_p/top_k 비기본값, manual thinking이 400 에러 가능 | API 래퍼와 자동화 설정 분리 |
| 안전성 평가 | Sonnet 4.6보다 안전성 개선, 그래도 권한 제한 필요 | 읽기/수정/실행/외부변경 권한 분리 |
이 표에서 제일 먼저 볼 것은 가격이 아니라 권한과 비용의 조합이다. Sonnet 5는 더 많은 일을 맡길 수 있는 모델처럼 보이지만, 맡길 일이 늘면 비용과 실패 범위도 같이 늘어난다. AI 에이전트는 공짜 인턴이 아니라 사용량이 찍히는 동료다. 일을 잘하면 고맙고, 루프가 돌면 카드 명세서가 성실하게 출근한다.
바로 적용한다면 이렇게 시작하자
첫째, 기존 Sonnet 4.6 워크플로 중 3개만 고른다. 예를 들면 코드 리뷰 초안, 테스트 실패 요약, 문서 업데이트처럼 실패해도 되돌리기 쉬운 작업이 좋다. 여기서 Sonnet 5와 Sonnet 4.6의 결과 품질, 수정 필요 횟수, 토큰 사용량, 총 소요 시간을 비교한다.
둘째, API 설정을 모델별로 분리한다. Sonnet 5에는 비기본 sampling parameter를 넣지 않고, manual thinking 대신 adaptive thinking과 effort 기준으로 바꾼다. 이 작업을 안 하면 모델 성능을 보기도 전에 400 에러와 먼저 친해질 수 있다. 친해져도 별 도움은 안 된다.
셋째, Claude Code 같은 에이전트 도구에서는 승인 경계를 다시 잡는다. 읽기와 분석은 넓게 허용하되, 파일 수정과 명령 실행은 작업 유형별로 나눈다. 외부 서비스 변경, 배포, 결제, 고객 데이터 접근은 사람이 확인하는 단계로 남긴다. Sonnet 5의 장점은 자율성을 키우는 데 있지만, 운영자의 일은 자율성을 안전한 통로에 넣는 것이다.
넷째, 2026년 8월 31일 이전과 이후의 비용을 따로 계산한다. 프로모션 가격 기간에는 실험을 늘릴 수 있지만, 표준 가격 전환 뒤에도 같은 방식으로 돌릴지는 다시 봐야 한다. 새 토크나이저 때문에 단가와 실제 요청 비용이 다르게 느껴질 수 있으니, 팀 단위 사용량은 꼭 로그로 남기는 편이 좋다.
언제 바로 써도 되고 언제 기다려야 하나
Sonnet 5를 바로 써볼 만한 경우는 반복적인 개발 보조, 문서 정리, 테스트 실패 분석, 웹 리서치, 내부 도구 자동화처럼 결과를 사람이 빠르게 검수할 수 있는 작업이다. 특히 Claude Code를 이미 쓰고 있고, Sonnet 4.6에서 “조금만 더 길게 생각했으면 좋겠다”는 장면이 많았다면 테스트 가치가 높다.
반대로 당장 바꾸지 않아도 되는 경우도 있다. API 래퍼가 오래됐고 sampling parameter가 여기저기 박혀 있다면 먼저 정리해야 한다. 비용 로그가 없거나, 에이전트가 실패했을 때 어디서 멈추는지 모른다면 모델 업그레이드보다 운영 장치가 먼저다. 더 똑똑한 모델은 좋은 도구지만, 어두운 방에 더 빠른 드릴을 들여놓는다고 인테리어가 끝나는 건 아니다.
팀에서 쓰는 경우라면 pilot 범위를 작게 잡는 편이 낫다. 예를 들어 1주일 동안 PR 10개, 테스트 실패 10건, 문서 변경 5건만 Sonnet 5로 처리하게 하고 결과를 비교한다. 여기서 봐야 할 지표는 벤치마크 점수보다 사람이 수정한 횟수, 잘못 건드린 파일 수, 재시도 횟수, 토큰 비용이다.
개인 사용자는 더 단순하다. Claude Code에서 작은 저장소 하나를 잡고, “이슈 재현 -> 원인 후보 -> 수정안 -> 테스트 명령 제안”까지만 맡겨보면 된다. 바로 merge까지 맡기지 말고, 사람이 마지막 diff를 읽는 습관을 유지하자. 모델이 좋아질수록 검수는 덜 중요해지는 게 아니라 더 조용히 중요해진다.
FAQ
Q. Claude Sonnet 5에서 제일 먼저 봐야 할 기능은 뭐야?
A. 에이전트 실행력이다. 브라우저와 터미널 같은 도구 사용, 계획 수립, 자율 실행이 핵심 변화로 제시됐다. 다만 기능만 보지 말고 권한표, 비용표, 실패 시 롤백 기준을 같이 봐야 한다.
Q. Sonnet 5가 Opus 4.8을 대체하나?
A. 완전 대체라기보다 기본 작업의 기준선을 올리는 모델에 가깝다. Anthropic 발표 기준으로 Sonnet 5는 Opus 4.8에 가까운 성능을 더 낮은 가격대로 제공하지만, 높은 정확도가 필요한 작업에서는 Opus 4.8이 여전히 선택지로 남는다.
Q. 가격은 Sonnet 4.6보다 싸진 거야?
A. 2026년 8월 31일까지는 입력 $2/MTok, 출력 $10/MTok의 프로모션 가격이 적용된다. 2026년 9월 1일부터는 입력 $3/MTok, 출력 $15/MTok이다. 다만 새 토크나이저 때문에 같은 텍스트가 약 30% 더 많은 토큰으로 잡힐 수 있어 실제 비용은 대표 프롬프트로 다시 계산해야 한다.
Q. 기존 API 코드를 그대로 모델명만 바꾸면 되나?
A. 위험하다. Sonnet 5는 manual extended thinking이 400 에러를 반환하고, temperature, top_p, top_k를 비기본값으로 설정해도 400 에러가 난다. 기존 래퍼에서 이 옵션을 자동으로 넣는지 먼저 확인해야 한다.
Q. Claude Code에서는 바로 Sonnet 5를 써도 될까?
A. 작은 작업부터는 테스트해볼 만하다. 테스트 실패 요약, 린트 수정, 문서 업데이트, 이슈 재현처럼 사람이 빠르게 검수할 수 있는 작업이 좋다. 배포, 외부 서비스 변경, 고객 데이터 접근은 승인 단계를 유지하는 편이 안전하다.
Q. Sonnet 5가 더 안전하다면 권한을 더 줘도 되나?
A. 아니다. 안전성 개선은 좋은 신호지만 권한 확대와 같은 말은 아니다. 에이전트 작업에서는 읽기, 수정, 실행, 외부 변경 권한을 분리하고, 높은 위험 작업은 사람이 확인해야 한다.
공식 출처
- Anthropic – Introducing Claude Sonnet 5
- Claude Platform Docs – What’s new in Claude Sonnet 5
- Claude Platform Docs – Pricing