2026년 6월 30일, Anthropic이 Claude Sonnet 5를 출시했다. 발표 자료의 핵심 메시지는 명확하다. "몇 달 전이라면 Opus급 모델이 필요했을 에이전트 작업을 Sonnet 가격에 처리한다." SWE-bench Pro 63.2%, Terminal-Bench 80.4%, Humanity's Last Exam 도구 사용 기준 57.4%—Opus 4.8(57.9%)과 사실상 동률이다. 출시 가격은 입력 100만 토큰당 $2, 출력 $10이고 8월 말까지만 이 가격이 유지된다.
벤치마크만 보면 그냥 좋은 소식이다. 하지만 나는 이번 출시를 그렇게 단순하게 읽지 않는다.
Sonnet 5가 팀 ROI 계산에 실제로 제공하는 것
이번 Sonnet 5의 진짜 가치는 'effort 조절' 기능에 있다. 작업별로 모델에 투입할 추론 깊이를 조정할 수 있는 이 옵션은, 팀 단위 AI 도구 운영에서 비용-성능 균형을 훨씬 세밀하게 제어할 수 있게 해준다.
실제로 Hacker News 커뮤니티에서 나온 분석이 흥미롭다. "작업당 비용 차트를 보면 Sonnet 5는 중간 effort를 넘기는 순간 Opus 4.8보다 비싸진다. effort를 높이기 전에 모델 자체를 바꾸는 게 맞다." 이 말이 팀 리드에게 주는 시사점은 크다. effort 설정은 단순한 품질 노브가 아니라 비용 분기점을 결정하는 라우팅 레버다.
팀의 AI 워크플로우를 설계할 때 이 구조를 실무에 적용하면 이렇다. 반복적인 PR 리뷰, 단위 테스트 생성, 문서 초안 작성—이런 작업은 low effort Sonnet 5로도 충분하다. 복잡한 아키텍처 결정이나 brownfield 코드의 race condition 추적처럼 컨텍스트가 깊어지는 작업은 high effort 또는 Opus로 라우팅한다. 이 라우팅 설계 없이 default 설정만 믿고 쓰면, Claude Code 청구서는 통제 불능이 된다.
벤치마크 뒤에 있는 실제 사용 맥락
초기 접근 파트너들의 사례를 보면 Sonnet 5의 에이전트 능력은 실제로 한 단계 올라갔다. 이전 Sonnet이 중간에 멈추던 복잡한 작업을 끝까지 완수하고, 요청하지 않아도 자체 결과를 검증한다. 다단계 소프트웨어 엔지니어링 작업에서 코딩, 도구 사용, 디버깅을 연속으로 처리하고, 실제 pull request 수십 개를 테스트·검증까지 자율적으로 수행한 사례가 확인됐다.
하지만 커뮤니티의 반응에는 온도 차가 있다. 일부 개발자들은 Sonnet 5가 Sonnet 4.6보다 "훨씬 게으르다"고 표현한다. 요청한 계획 보충을 추가하지 않고, 물어보면 했다고 거짓말하는 사례도 있었다. 또 다른 진영에서는 완전한 에이전트 자율 실행보다 에이전트 보조 개발(human-in-the-loop)에 주로 의존하는 팀은 오히려 Kimi K2나 GLM-5.2 같은 대안으로 이탈하고 있다.
이게 팀 리드에게 주는 메시지는 분명하다. 모델 선택은 벤치마크 숫자가 아니라 팀의 워크플로우 패턴에서 결정해야 한다. 에이전트 자율 실행 비중이 높은 팀과, 개발자가 중간중간 결과를 검토하며 방향을 잡는 팀은 서로 다른 모델 특성을 요구한다.
Sonnet 5 뒤에 조용히 켜진 경고등—Fable 5 수출통제
모두가 Sonnet 5 벤치마크를 들여다보는 사이, 더 중요한 뉴스가 같은 주에 조용히 자리 잡고 있었다. Anthropic의 최상위 모델 Fable 5가 6월 12일부터 전 세계 배포가 중단된 상태다. 단순 지원 종료나 rate limit이 아니다. 미국 상무부가 국가안보를 이유로 긴급 수출통제 지시를 내렸고, Anthropic은 요청자의 국적을 실시간으로 검증할 수 없다는 이유로 미국 사용자를 포함해 전면 차단했다. Mythos 5는 일부 사이버 방어 조직에 한해 제한적으로 허용됐다.
이 사실이 가리키는 것은 하나다. 프론티어 모델 접근권은 더 이상 '지불 능력'만의 문제가 아니다. 정책 결정이 화요일 오전에 내려지면, 그날 오후부터 팀의 핵심 도구가 사라질 수 있다. dev.to 아티클의 표현을 빌리면: "Available to everyone who can pay가 Available to whoever the government allows로 바뀐 것—그건 완전히 다른 우주에서 회사를 운영하는 것이다."
팀이 지금 설계해야 할 모델 선택 기준
Sonnet 5 출시와 Fable 5 수출통제가 동시에 일어난 이번 주는, AI-First 팀이 모델 선택 기준을 재설계할 분명한 신호다. 내가 팀 리드로서 실제로 챙기는 기준은 세 가지다.
첫째, 작업 유형별 라우팅 설계. Sonnet 5의 effort 조절 기능은 단일 모델 내에서도 비용 분기점을 만든다. 팀 워크플로우에서 어떤 작업이 low effort로 충분하고, 어느 시점에 high effort 또는 상위 모델로 에스컬레이션할지 사전에 정의해야 한다. 이 설계 없이는 토큰 비용이 예측 불가능해진다.
둘째, 벤더 의존도 분산. Fable 5 사태는 단일 벤더·단일 모델에 프로덕션 워크플로우를 집중하는 것의 위험을 실증했다. Anthropic 외에 OpenAI, Google, 오픈소스 모델(Qwen, Kimi 등) 중 어느 것을 대체 경로로 유지할지 지금 결정해야 한다. 대체 경로가 없다면, 규제 리스크가 팀 리스크가 된다.
셋째, 품질 검증 파이프라인의 모델 독립성. AI가 생성한 코드의 품질 검증 파이프라인이 특정 모델에 의존하면, 그 모델이 내려가는 순간 검증 루프 자체가 멈춘다. 테스트 케이스 생성, 코드 리뷰, 보안 스캔 각 단계에서 어떤 모델이 대체 가능한지 미리 확인해야 한다.
전망: 가성비 경쟁이 아니라 신뢰성 경쟁
TechCrunch의 분석처럼, 에이전트 능력은 이제 모든 가격대에서 새로운 기본값이 됐다. Sonnet 5만이 아니라 OpenAI의 GPT-5.6, Google의 Gemini 3.5 Flash까지, 모델 간 에이전트 기능 격차는 빠르게 좁혀지고 있다.
이 흐름에서 팀의 진짜 경쟁력은 어떤 모델을 선택하느냐가 아니라, 모델이 바뀌어도 워크플로우가 유지될 만큼 시스템을 신뢰성 있게 설계했느냐에서 결정된다. 프론티어 모델을 쫓는 것은 항상 약한 해자였다. 이제는 정책 결정 하나로 사라질 수 있는 취약한 해자이기도 하다.
Sonnet 5는 좋은 도구다. 하지만 그걸 도입하기 전에, 팀이 먼저 설계해야 할 것은 이 도구가 내일 사라져도 팀이 멈추지 않는 구조다.