저는 보통 아주 평범한 방식으로 새로운 AI 모델들을 테스트합니다.

벤치마크 프롬프트(benchmark prompts)를 사용하지도 않고, "한 번의 메시지로 회사를 만들어줘" 같은 요청을 하지도 않습니다. 대신 제 일주일 중 지루한 부분들에 모델들을 던져 넣습니다. 오디오 스템(audio stems)의 이름을 변경하는 스크립트를 정리하거나, 작은 FFmpeg 래퍼(wrapper)를 수정하거나, 프로덕션 노트(production notes)를 작은 대시보드로 변환하거나, 혹은 왜 Node 도구가 제 노트북에서는 작동하는데 스튜디오 머신에서는 깨지는지 설명하게 하는 식입니다.

이것이 제가 Claude Sonnet 5와 Fable 5를 바라보는 관점입니다.

Anthropic은 2026년 6월 30일에 Claude Sonnet 5를 발표하며, 지금까지 중 가장 에이전트적(agentic)인 Sonnet 모델이라고 불렀습니다. 비슷한 시기에 Fable 5는 수출 통제 안전장치(export-control safeguards)와 관련된 짧은 제한 기간을 거쳐 돌아왔습니다. 따라서 질문은 단순히 "어떤 모델이 더 똑똑한가?"가 아닙니다. 더 나은 질문은 이것입니다: "실제 개발자 워크플로우(developer workflow) 내부에서 어떤 모델을 진정으로 신뢰할 수 있는가?"

요약하자면: Sonnet 5는 일상적인 용도로 더 흥미로운 모델입니다.

Sonnet 5가 절대적으로 가장 강력한 Claude 모델이기 때문은 아닙니다. 그렇지 않습니다. Fable 5는 더 높은 성능을 가진 모델로 포지셔닝되어 있으며, 더 무거운 추론(reasoning)과 에이전트적 작업에는 여전히 Opus 4.8이 Sonnet보다 상위에 있습니다. 하지만 Sonnet 5는 많은 개발자가 실제로 매일 사용할 모델처럼 보입니다. 더 저렴하고, 충분히 빠르며, 이전 Sonnet 라인보다 훨씬 강력하고, 다단계 코딩 작업(multi-step coding tasks)을 지속하는 데 능숙합니다.

마지막 부분이 중요합니다. 많은 모델이 괜찮은 첫 번째 답변을 만들어낼 수 있습니다. 하지만 지저분한 레포지토리(repo) 전체에서 컨텍스트(context)를 유지하고, 자신이 유발한 테스트 실패를 인지하며, 터미널(terminal)을 적절히 사용하고, 단지 "도움이 되고 싶다"는 기회가 보였다고 프로젝트의 절반을 다시 써버리는 일을 피할 수 있는 모델은 드뭅니다.

저에게 Sonnet 5가 가장 흥미로운 지점은 이러한 중간 무게의 작업들입니다: 헬퍼 모듈(helper module) 리팩토링, 테스트 케이스 작성, 취약한 스크립트 디버깅, 작은 내부 도구 생성, 또는 모호한 노트를 실제로 실행 가능한 무언가로 변환하는 작업 등입니다.

하지만 주의 깊게 살펴볼 만한 마이그레이션(migration) 세부 사항들이 있습니다.

모델 이름은 간단합니다: claude-sonnet-5. 하지만 만약 Sonnet 4.6에서 전환하는 것이라면, 단순히 모델 문자열만 교체하고 끝내지는 않을 것입니다.

첫째, 적응형 사고 (adaptive thinking)가 이제 기본 동작의 일부가 되었습니다. 이전 요청에 사고 (thinking) 필드가 포함되어 있지 않았다면, Sonnet 5는 더 많은 추론 노력 (reasoning effort)을 언제 투입할지 스스로 결정할 수 있기 때문에 이전과 다르게 동작할 수 있습니다. 이는 일반적으로 에이전트적 작업 (agentic work)에는 유익하지만, 지연 시간 (latency)과 토큰 사용량 (token usage)을 변화시킬 수 있습니다.

둘째, 수동 확장 사고 (manual extended thinking)는 더 이상 동일한 방식으로 처리되지 않습니다. 만약 귀하의 앱이 여전히 고정된 사고 예산 (thinking budget)을 전송한다면, 오류가 발생할 수 있습니다. 최신 패턴은 모델이 적응형 사고 (adaptive thinking)를 사용하도록 하거나, 지원되는 파라미터를 통해 추론 노력 (reasoning effort)을 구성하는 것입니다.

셋째, 기본값이 아닌 샘플링 제어 (sampling controls) 기능이 더 제한적입니다. temperature, top_p, 또는 top_k를 설정하는 데 익숙하다면, 귀하의 요청을 확인해 보십시오. 샘플링 설정에 의존하는 대신 스타일 제어를 시스템 프롬프트 (system prompt)로 옮겨야 할 수도 있습니다.

조용히 진행되는 마이그레이션 이슈는 토큰화 (tokenization)입니다. Anthropic은 동일한 입력이라도 Sonnet 4.6과 비교했을 때 더 많은 토큰을 생성할 수 있다고 밝히고 있습니다. 이는 기존 프롬프트의 비용이 더 많이 들거나, 한계치에 더 빨리 도달하거나, 긴 문맥 워크플로 (long-context workflows)에서 약간 다르게 동작할 수 있음을 의미합니다. 리포지토리 요약, 도구 지침 (tool instructions), 가드레일 (guardrails)로 가득 찬 대규모 프롬프트 템플릿을 사용 중이라면 다시 측정해 보십시오.

그렇다면 Fable 5는 어디에 해당할까요?

Fable 5는 사람들이 제한된 모델을 논할 때 때때로 암시하는

그것이 Fable을 쓸모없게 만든다는 뜻은 아닙니다. 단지 "Fable 5가 돌아왔다"는 말이 모든 컨텍스트에서 모든 기능이 사용 가능하다는 의미는 아니라는 뜻입니다.

만약 제가 사용 용도를 나눈다면 다음과 같이 분류하겠습니다:

Sonnet 5는 일반적인 개발 작업용입니다. 반복적으로 수행하는 작업들 말이죠. 디버깅 (Debugging), 코드 리뷰 (Code review), 테스트 (Tests), 리포지토리 탐색 (Repo navigation), 소형 에이전트 (Small agents), 도구 사용 (Tool use), 프로젝트 스캐폴딩 (Project scaffolding), 그리고 실용적인 자동화 (Practical automation) 등이 이에 해당합니다.

Opus 4.8은 더 어려운 엔지니어링 판단 (Engineering judgment)을 위한 것입니다. 작업이 미묘하거나, 실패 비용 (Failure cost)이 높거나, 모델이 아키텍처 (Architecture)와 트레이드오프 (Trade-offs) 전반에 걸쳐 추론해야 할 때 사용합니다.

Fable 5는 비용과 잠재적인 안전장치 (Safeguards)를 정당화할 만큼 깊은 역량이 중요하게 작용하는 고가치 작업 (High-value work)을 위한 것입니다. 긴 계획 세우기 (Long planning sessions), 복잡한 분석 (Complex analysis), 창의적인 기술적 탐색 (Creative technical exploration), 또는 더 강력한 모델을 정말로 원하면서도 더 많은 제약 사항을 감수할 수 있는 작업들이 여기에 속합니다.

가격 또한 여기서 중요한 부분입니다. Sonnet 5는 2026년 8월 31일까지 입력 토큰 100만 개당 2달러, 출력 토큰 100만 개당 10달러의 출시 기념 API 가격으로 출시되었습니다. 그 이후에는 입력 3달러, 출력 15달러로 변경됩니다. 반면 Fable 5는 입력 100만 개당 10달러, 출력 100만 개당 50달러로 훨씬 더 비쌉니다.

그 격차는 아키텍처 (Architecture)에 영향을 미칠 만큼 큽니다. 제품의 경제성 (Product economics)이 매우 관대하지 않은 한, 저는 모든 작은 요청을 Fable로 보내지는 않을 것입니다.

더 나은 패턴은 라우팅 (Routing)입니다. 기본적으로 Sonnet 5를 사용하되, 작업이 그럴만한 가치가 있을 때만 Opus나 Fable로 에스컬레이션 (Escalate)하고, 에스컬레이션이 실제로 도움이 되었을 때를 이해할 수 있도록 충분한 메타데이터 (Metadata)를 기록하십시오.

AWS 액세스 (AWS access) 또한 명확하게 분리할 가치가 있습니다.

AWS 상의 Claude Platform이 있으며, 이는 AWS 결제(Billing), IAM, CloudTrail을 통해 Anthropic의 네이티브 플랫폼에 대한 액세스 (Access)를 제공합니다. 그다음으로는 Amazon Bedrock 상의 Claude가 있는데, 이는 관리형 AWS 모델 서비스 경로입니다. Anthropic의 문서에 따르면 Sonnet 5는 AWS 상의 Claude Platform과 Amazon Bedrock 상의 Claude를 통해 사용할 수 있지만, 오래된 Bedrock 레거시 API (Legacy APIs)를 통해서는 사용할 수 없습니다.

만약 기존의 통합 (Integration) 환경을 사용 중이라면, 모델을 사용할 수 없다고 가정하기 전에 엔드포인트 (Endpoint)와 API 스타일을 먼저 확인하십시오. 이것이 바로 오후 시간을 통째로 낭비하게 만들 수 있는 지루한 플랫폼 세부 사항의 전형적인 예입니다.

중국 액세스 (China access) 문제는 더 민감하며, 주의가 필요합니다.

2026년 7월 3일 기준으로, Anthropic의 지원 국가 페이지에는 Claude.ai 또는 직접적인 상업용 API 액세스에 대해 중국 본토, 홍콩 또는 마카오가 나열되어 있지 않습니다. 대만은 나열되어 있습니다. 따라서 누군가 "Claude Sonnet 5를 중국에서 사용할 수 있나요?"라고 묻는다면, 직접적인 답변은 다음과 같습니다: 중국 본토에서의 일반적인 Claude.ai 또는 직접적인 Anthropic API 액세스를 통해서는 공식적으로 불가능합니다.

저는 비공식적인 계정 우회 방식 (Workarounds)을 기반으로 중요한 것을 구축하지 않을 것입니다. 그것들이 한동안은 작동할 수 있지만, 취약하며 최악의 순간에 실패하는 경향이 있기 때문입니다. 만약 중국 기반의 액세스 요구 사항이 있는 팀을 위해 구축하고 있다면, 공식 클라우드 제공업체의 가용성, 계정 자격, 컴플라이언스 (Compliance) 요구 사항 및 지역적 제약 사항을 확인하십시오. 또한 필요할 때 제공업체를 전환할 수 있도록 모델 레이어 (Model layer)를 충분히 추상화하여 유지하십시오.

릴리스 노트 (Release notes)를 모두 읽고 난 후의 저의 실제 견해는 간단합니다: Sonnet 5가 아마도 제가 가장 먼저 테스트할 모델일 것입니다.

그것은 가장 화려한 옵션은 아닙니다. 모든 어려운 문제에 제가 선택할 모델도 아닙니다. 하지만 실무적인 개발 작업에 적합한 위치에 자리 잡고 있습니다: 실제 에이전트적 작업 (Agentic tasks)을 처리할 수 있을 만큼 충분히 유능하고, 반복 작업 (Iterate)을 수행하기에 충분히 저렴하며, 많은 팀이 이미 사용 중인 인터페이스 전반에서 사용할 수 있습니다.

Fable 5는 트랙에 정말로 필요할 때 불러오는 값비싼 세션 연주자 (Session player)와 같습니다. 매우 유용하지만, 모든 패스 (Pass)에 사용되지는 않습니다. Sonnet 5는 하루 종일 방 안에 계속 두는 작업용 모델입니다.

“이 모델이 모든 것을 바꾼다”라는 말보다는 덜 극적으로 들릴 수도 있지만, 솔직히 유용한 도구들은 대개 그런 방식으로 찾아옵니다. 번개처럼 갑작스럽게 나타나는 것이 아니라, 여기서 20분, 저기서 1시간을 아껴주고, 어쩌면 피곤한 목요일 밤의 잘못된 배포 (deploy) 한 번을 막아줌으로써, 생각하기도 전에 자연스럽게 손이 가게 되는 무언가와 같습니다.