Anthropic은 6월 30일에 Claude Sonnet 5를 출시했습니다. 그들의 프레임워크는 "지금까지 중 가장 에이전트적(agentic)인 Sonnet 모델"입니다. 만약 당신이 Sonnet 라인을 계속 지켜봐 왔다면, 이 주장은 파헤쳐 볼 가치가 있는 특정한 맥락을 가지고 있습니다.

Sonnet 3.5는 개발자들이 도구 사용(tool use)과 코딩에 주목하게 만든 첫 번째 버전이었습니다. 3.6과 3.7은 그 방향으로 계속 밀어붙였습니다. 4.6은 에이전트적 성능(agentic performance)에서 눈에 띄는 도약을 보여주었습니다. 하지만 지난 몇 달 동안, 가장 인상적인 에이전트적 이득은 Opus 티어에 집중되어 있었습니다. Sonnet은 유능하게 느껴졌지만 완전히 그 수준에 도달하지는 못했습니다. Sonnet 5는 Opus 수준의 자율적 실행(autonomous execution) 능력을 Sonnet의 가격대로 가져오려는 Anthropic의 시도입니다.

수치들이 이야기의 일부를 말해줍니다. Sonnet 5는 BrowseComp(자율 웹 검색 평가)와 OSWorld-Verified(컴퓨터 사용 평가)에서 Opus 4.8에 근접합니다. Opus 4.8은 일반적인 능력 측면에서 여전히 Anthropic의 상한선으로 남아 있습니다. API 가격은 백만 토큰당 입력 $2 / 출력 $10로 시작하며, 8월 31일 이후에는 $3/$15로 변경됩니다. 안전성 측면에서 Sonnet 5는 악의적인 요청을 거부하고 프롬프트 주입(prompt injection) 공격에 저항하는 데 있어 4.6보다 뛰어난 성능을 보입니다. 환각(Hallucination) 및 아첨(sycophancy) 비율도 더 낮습니다. Anthropic은 또한 사이버 보안 특화 테스트(Firefox 브라우저 익스플로잇 개발)를 실시했으며, Sonnet 5가 완전한 작동 익스플로잇을 한 번도 완성하지 못했다는 것을 발견했습니다. 이는 Opus 4.8 및 Mythos 5와의 명확한 격차를 보여줍니다. 그들은 이를 의도적인 제한이라기보다 사이버 보안 작업에 대한 학습이 이루어지지 않았기 때문이라고 설명합니다.

벤치마크는 별개의 문제입니다. 초기 사용자(early adopters)들이 보고하는 내용이 더 중요합니다.

한 팀은 Sonnet 5에게 버그 조사를 요청했습니다. 어떻게 진행해야 할지 알려주지 않았음에도 불구하고, 모델은 재현 테스트 케이스를 작성하고, 수정 사항을 구현한 다음, 수정 사항이 없을 때 버그가 재현되는지 확인하기 위해 변경 사항을 따로 보관했습니다. 단계별 안내 없이 한 번의 연속적인 패스로 수행되었습니다.

또 다른 사례는 더 비즈니스 지향적입니다. 두 부분으로 구성된 연속 작업입니다: Salesforce에서 고객 등급을 업데이트한 다음, 기업 연락처에 제품 출시 공지를 보내는 것입니다. 이전 Sonnet 버전들은 중간에 멈추곤 했습니다. Sonnet 5는 이를 처음부터 끝까지 완수했습니다.

Lovable의 피드백은 직설적이었습니다: "출력 품질은 동일하지만, 그 결과에 도달하기까지의 단계가 줄어들었습니다." 그들은 또한 Sonnet 5가 안전하지 않은 요청을 깔끔하게 거부한다는 점에 주목했습니다. 수백만 명의 개발자에게 서비스를 제공하는 플랫폼에게는, 언제 '아니오'라고 말해야 하는지를 아는 모델이 어떻게 구축해야 하는지를 아는 모델만큼이나 중요합니다.

보험 워크플로우(접수, 사고 최초 통지, 손실 보고서)를 운영하는 Pace는 컴퓨터 사용 (computer-use) 에이전트를 위해 Sonnet 5를 사용합니다. 그들의 설명은 다음과 같습니다: "일관되게 올바른 조치를 취하며 빠르게 수행합니다." ClickHouse는 실시간 데이터 탐색에서 더 정교해진 추론 (reasoning) 단계를 보고했으며, 사용자들은 속도 차이를 체감했습니다. 법률 분야의 Eve는 Sonnet 5가 법률 조사 및 분석 작업에 있어 자신들의 파레토 프런티어 (Pareto frontier)에 도달했다고 말하며, 가성비 측면에서 마이그레이션 결정을 내리기 쉬웠다고 밝혔습니다.

이 사례들을 종합해 보면, 세 가지 구체적인 개선 사항이 눈에 띕니다.

가장 명백한 것은 작업 완료 (Task completion) 능력입니다. 이전의 Sonnet 모델들은 복잡한 다단계 작업 중에 중간에 멈춰서 확인이나 추가 지침을 기다리곤 했습니다. Sonnet 5는 다음에 무엇을 할지 스스로 결정하고 누군가 지켜보지 않아도 계속해서 진행합니다.

자기 검증 (Self-verification) 또한 또 다른 변화입니다. 모델은 별도의 요청을 받지 않고도 작업을 완료한 후 자신의 출력을 스스로 확인합니다. 재현 가능한 테스트를 작성하고, 코드를 수정하고, 수정을 검증하는 패턴은 숙련된 엔지니어가 일하는 방식과 매우 유사합니다.

다음은 비용 곡선 (cost curve) 입니다. 이전에는 Opus 급의 가격 책정이 필요했던 것과 동일한 수준의 에이전트 역량을 이제는 Sonnet 급의 가격으로 실행할 수 있습니다. 고빈도 에이전트 시나리오의 경우, 이는 운영 비용을 실질적으로 절감해 줍니다.

Anthropic은 자사의 블로그에서 이러한 트렌드를 다음과 같이 요약했습니다: "Sonnet 5가 격차를 좁히고 있습니다." Sonnet과 Opus 사이의 역량 차이가 줄어들고 있습니다. 노력 수준 (effort-level) 제어를 통해, 개발자들은 Sonnet 5와 Opus 4.8 사이에서 자신만의 비용 대비 성능 최적점 (sweet spot)을 찾을 수 있습니다.

더 넓은 패턴은 에이전트 실행 능력 (agent execution capability)이 플래그십 모델에서 미드티어 (mid-tier) 모델로 이동하고 있다는 점입니다. Sonnet 5는 그 곡선 위의 새로운 데이터 포인트입니다. 여기서 어디로 향할지, 그리고 얼마나 빠르게 이동할지는 예측하기 어렵지만, 방향은 명확합니다.

Sonnet 5는 실행 계층 (execution layer)에서 문제를 해결합니다. 이는 에이전트를 더 자율적이고, 더 신뢰할 수 있으며, 더 저렴하게 만듭니다. 하지만 실행 능력은 에이전트가 실제로 프로덕션 (production) 환경에서 작동하기 위해 필요한 요소 중 하나일 뿐입니다.

터미널에서 코드를 작성하기 위해 Sonnet 5를 사용하는 한 개발자의 사례를 들어보겠습니다. 모델이 단계를 계획하고, 도구 (tools)를 호출하며, 결과를 출력하면, 개발자는 이를 훑어보고 제출하거나 다시 수행할 것을 요청합니다. Sonnet 5는 이를 잘 처리합니다. 이는 "에이전트가 자율적으로 업무를 수행할 수 있는가"라는 문제를 해결합니다.

팀 시나리오로 전환하면 상황이 달라집니다. 하나의 프로젝트에서 세 명의 에이전트가 병렬로 실행됩니다. 한 명은 경쟁사 조사를 수행하고, 한 명은 기술 제안서를 작성하며, 한 명은 자동화된 테스트를 실행합니다. 프로젝트 리더는 지난번에 어떤 에이전트가 가장 좋은 결과물을 냈는지, 어떤 에이전트가 두 번이나 반려되었는지, 어떤 에이전트가 어떤 종류의 작업에 능숙한지 알고 싶어 합니다. 기존의 협업 도구에서는 이러한 정보가 전혀 보이지 않습니다. 에이전트에게는 정체성도, 기록도, 성능 이력도 없습니다. 모든 에이전트는 동일한 서비스 계정 아바타 (service account avatar)일 뿐입니다. 그들이 그룹 채팅에 결과를 게시하면, 사흘 뒤에는 새로운 메시지 아래에 묻혀버립니다.

이것은 Sonnet 5가 해결할 수 있는 문제가 아닙니다. 모델 벤더 (model vendors)는 에이전트가 더 잘 작동하도록 만듭니다. 하지만 에이전트의 실행이 끝난 후, 누가 에이전트에게 워크스테이션 (workstation)을 제공하고, 누가 에이전트가 수행한 일을 기록하며, 누가 결과물의 품질을 관리할까요? 그것은 모델 계층 (model-layer)의 문제가 아닙니다.

Mininglamp는 이 간극을 메우기 위해 Octo를 오픈 소스로 공개했습니다. Octo는 에이전트 팀을 위해 특별히 설계된 협업 플랫폼입니다. 이는 Sonnet 5와는 완전히 다른 포지셔닝을 가집니다. Sonnet 5가 에이전트의 두뇌라면, Octo는 에이전트의 워크스테이션이자 관리 시스템입니다.

Octo는 세 가지 일을 수행합니다.

첫째, 모든 에이전트에게 정체성(identity)을 부여합니다. Octo에서 에이전트는 봇(Bot)이라고 불립니다. 각 봇은 역량 태그(코딩, 분석, 테스트), 작업 이력(완료된 작업, 반려된 횟수, 생성자, 소속 등)이 포함된 에이전트 카드(AgentCard)를 가집니다. 이 정보는 협업 과정에서 지속적으로 업데이트됩니다. 프로젝트 리더는 봇이 무엇을 시도해 보게 하거나 추측하는 대신, 이 데이터를 참조하여 작업을 할당할 수 있습니다. 봇은 OpenClaw, Hermes, Codex, Claude Code를 포함한 여러 런타임(runtimes)을 지원합니다. 즉, 특정 모델 벤더에 종속되지 않습니다. Sonnet 5 기반의 봇과 GPT-4o 기반의 봇이 동일한 Octo 인스턴스 내에서 협업할 수 있습니다.

둘째, 매터(Matter)라고 불리는 체계를 통해 에이전트의 산출물(deliverables)을 관리합니다. 작업이 완료되면 에이전트의 출력물은 단순히 채팅 스트림에 머물지 않습니다. 이는 소유자, 산출물, 승인 결론, 피드백 기록을 포함하는 구조화된 매터(Matter)로 추출됩니다. 산출물은 새로운 메시지에 의해 휩쓸려 사라지지 않습니다. 승인 결정(승인 또는 반려)은 기록으로 남습니다. 피드백은 캡처되어 다음 작업에 자동으로 주입됩니다. 매터의 전체 라이프사이클(lifecycle)에는 브리프(brief), 논의 과정, 출력물, 인간의 피드백, 그리고 최종 승인 결론이 모두 한곳에 포함됩니다. 에이전트가 3개월 전에 왜 반려되었는지 찾기 위해 채팅 기록을 뒤질 필요가 없습니다.

셋째, 6가지 협업 모드(collaboration modes)를 통해 여러 에이전트 간의 정보 흐름을 제어합니다. 어떤 작업은 중복 작업을 피하기 위해 에이전트들이 정보를 공유해야 합니다 (라운드테이블 모드 (Roundtable mode), 모두가 모든 것을 확인). 어떤 작업은 품질 게이트(quality gates)가 필요합니다 (비평가 모드 (Critic mode), 승인 또는 반려 전에 출력이 독립적인 검토를 거침). 어떤 작업은 순차적 의존성(sequential dependencies)을 가집니다 (파이프라인 모드 (Pipeline mode), 정보가 단계별로 흐름). 대규모 작업은 분해(decomposition)가 필요합니다 (분할 모드 (Split mode), 작업을 나누어 병렬로 처리한 뒤 결과를 병합). 창의적인 작업은 여러 옵션이 필요합니다 (스웜 모드 (Swarm mode), 여러 에이전트가 동일한 문제에 달려들고 인간이 최선의 것을 선택). 작업 특성에 따라 모드를 선택하세요. 시스템이 누군가가 수동으로 관리하는 대신 정보 라우팅(information routing)을 처리합니다.

Sonnet 5는 에이전트 실행 능력(execution capability)과 비용 효율성(cost-effectiveness)의 지표를 변화시켰습니다. 하지만 실행 능력은 "에이전트가 업무를 수행할 수 있는가"에 답합니다. 협업 인프라(collaboration infrastructure)는 "에이전트가 수행한 업무가 실제로 사용될 수 있는가"에 답합니다. 모델은 에이전트를 빠르고, 정확하며, 저렴하게 만듭니다. 플랫폼은 에이전트의 정체성을 추적 가능하게 하고, 결과물을 관리 가능하게 하며, 협업을 제어 가능하게 만듭니다. 이 두 가지가 결합되어야 에이전트가 단순한 똑똑한 채팅 어시스턴트에 머물지 않고 생산성 도구(productivity tool) 범주로 진입할 수 있습니다.

Octo는 GitHub에서 Apache 2.0 라이선스로 오픈 소스로 공개되어 있습니다: https://github.com/Mininglamp-OSS/octo-server