벤치마크는 잘못된 이야기입니다

Anthropic은 이번 주 Claude Opus 4.8을 출시했습니다. 여러분은 아마 화요일에 발표 게시물을 보고, 수요일에는 X(구 트위터)에 몰려든 벤치마크(benchmarks)들을 보았으며, 목요일 아침에는 누군가가 큐레이션한 "SWE-bench Verified의 새로운 SOTA(State-of-the-Art)" 리더보드를 보았을 것입니다. 금요일이 되자 모두가 이미 다른 곳으로 관심을 옮겼습니다. 이것이 2026년 모델 출시의 일반적인 형태입니다.

하지만 이것은 잘못된 이야기입니다. 4.7에서 4.8로의 벤치마크 차이는 실재하지만 핵심적인 문제는 아닙니다. 핵심적인 이야기는 바로 달력입니다. Opus 4.6은 2월 말에 출시되었습니다. Opus 4.7은 4월에 출시되었습니다. Opus 4.8은 이번 주, 즉 6월 초에 출시되었습니다. 4개월 안에 세 번의 Opus 세대가 출시된 것입니다. 헤드라인 숫자가 코딩, 에이전트 추론(agentic reasoning), 또는 장기 도구 사용(long-horizon tool use)에 대해 무엇이라 말하든, 운영상의 현실은 이미 여러분의 발밑에서 변했습니다. 만약 여러분이 고정된 모델 버전(fixed model pin)으로 프로덕션 에이전트(production agent)를 실행하고 있다면, 여러분은 이제 6주에서 10주마다 마이그레이션 비용(migration tax)을 지불하고 있는 셈입니다. 지금 이를 인지하고 리팩토링(refactor)을 할 것인지, 아니면 Opus 4.9가 출시되어 고객 대면 에이전트가 올해 들어 세 번째로 퇴보할 8월 말에 인지할 것인지 선택해야 합니다.

이 포스트는 두 번째 이야기입니다. 저는 벤치마크 요약은 건너뛰고 — 모델 카드(model card)를 읽어보시기 바랍니다 — 다음 출시가 이루어지기 전에 여러분이 무엇을 해야 하는지 말씀드리겠습니다.

Anthropic이 출시한 것

anthropic.com의 발표 게시물은 세 가지를 확인했으며 네 번째를 암시했습니다. 확인된 세 가지는 다음과 같습니다:

1. Opus 4.8은 새로운 기본 Opus 티어 모델이며, ID는 claude-opus-4-8입니다. 이전 기본 모델들(4.7 및 4.6)은 명시적인 핀(pin) 설정을 통해 최소 90일 동안 계속 접근할 수 있습니다.
2. Fast mode(빠른 모드)는 4.7에서 출시되었던 것과 동일한 방식으로 4.8에서도 사용할 수 있습니다. 즉, 동일한 모델 가중치(model weights)를 사용하며, 처리량(throughput)이 더 높은 추론 경로(inference path)를 사용하되 품질 저하는 없습니다. 이것이 중요한 이유는 많은 워크로드에서 Opus와 Sonnet의 실질적인 차이가 이제 원시 능력(raw capability)이 아닌, Fast mode의 가용 여부에 달려 있기 때문입니다.
3. 모델 카드(model card)는 긴 문맥 일관성(long-context coherence), 에이전트 도구 호출(agentic tool dispatch), 그리고 거부 보정(refusal calibration) 측면에서 유의미한 개선이 있었다고 주장합니다. 벤치마크 결과는 6주 주기에 기대할 수 있는 수준인, 완만하지만 실질적인 개선 정도를 뒷받침합니다.

암시된 네 번째 사항이 흥미로운 부분입니다. 출시 주기 패턴 — 약 57주마다 하나의 Opus 버전이 출시되고, 46주마다 하나의 Sonnet 버전이 교차로 출시되는 패턴 — 이 이제 지난 세 세대 동안 유지되었습니다. 이것은 더 이상 우연이 아닙니다. 이것이 Anthropic이 모델 프로그램을 운영하는 주기이며, 게시물의 어디에서도 이 주기가 느려질 것이라는 신호는 보이지 않습니다. 오히려 모든 새로운 세대에서 Fast mode를 명시적으로 지원한다는 점은 추론(inference) 팀과 품질(quality) 팀이 이제 더 느려지는 것이 아니라 더 빠르게 출시할 수 있을 만큼 충분히 결합되어 있음을 시사합니다.

한편, OpenAI는 같은 주에 GPT-5.4 포인트 릴리스(point release)를 출시했고, Google은 3일 뒤 Gemini 업데이트를 출시했습니다. 출시 주기의 압축은 업계 전반에서 일어나고 있습니다. 만약 여러분이 파운데이션 모델(foundation models)을 기반으로 구축하고 있다면, 이제 여러분의 스택에서 가장 느린 부분은 모델 연구소의 출시 능력이 아니라, 여러분의 마이그레이션(migration) 능력입니다.

작년에는 그렇지 않았던 것이 왜 지금 중요해졌는가

2024년에는 모델 출시가 이벤트 중심적이었으며 대략 분기별로 이루어졌습니다. 분기에 한 번 업그레이드하고, 평가(eval)를 한 번 돌리고, 하나의 설정 파일에서 모델 핀(model pin)을 업데이트하면 오후 안에 작업이 끝났습니다. 모델 업그레이드 비용은 제한적이었습니다. 스프린트(sprint)의 절반 정도라고 할 수 있으며, 주로 평가 장비(eval rig)를 소유한 사람의 업무량에 달려 있었습니다.

마이그레이션(migration)이 일 년에 네 번 발생할 때는 그 비용이 합리적이었습니다. 하지만 일 년에 여덟 번에서 열 번씩 발생한다면 이야기가 달라집니다. 마이그레이션당 비용은 동일한데 빈도는 두 배가 되었고, 에이전트 군단(agent fleet)을 활용해 다른 일을 할 수 있는 팀의 역량은 정확히 절반으로 줄어들었습니다.

대부분의 팀은 아직 이를 알아차리지 못했습니다. 자동 업그레이드 핀(claude-opus-latest)을 사용 중이거나, "4.7 버전도 괜찮았으니 나중에 처리하자"며 4.6 버전에 고정(pinned)되어 있기 때문입니다. 이제 두 전략 모두 실패 모드(failure modes)가 되었습니다. 자동 업그레이드는 새로운 모델이 출시될 때마다 회귀(regression) 현상이 프로덕션(production) 환경에 영향을 미쳐 새벽 3시에 장애 상황을 초래할 수 있음을 의미합니다. 버전에 고정되어 있는 것은 결국 마이그레이션을 수행할 때 폭발적으로 늘어날 기술 부채를 축적하는 것을 의미합니다. 세 가지 버전의 행동 드리프트(behavior drift)가 누적되어, 아무도 감당할 수 없는 규모의 단일 마이그레이션으로 터져 나오게 됩니다.

세 번째 옵션이 있습니다. 이것이 바로 이 글의 주제입니다.

프로덕션 에이전트를 운영 중이라면, 당신은 여기에 해당합니다

네 가지 대략적인 원형(archetypes)이 있습니다. 본인과 가장 유사한 것을 선택하십시오.

• 고객용 챗봇(chatbot)이나 코파일럿(copilot)을 출시했습니다. 모델 핀(model pin)은 백엔드 설정(backend config)에 있습니다. 고객이 불만을 제기할 때, 벤치마크(benchmark)가 변할 때, 혹은 이전 버전이 지원 종료(deprecated)될 때 반응적으로 업그레이드합니다. CFO(최고재무책임자)는 추론(inference) 비용이 상승하는 것을 눈치채고 질문을 던지기 시작했습니다.
• 내부 에이전트 군단(internal agent fleet)을 운영합니다. 코드 리뷰 에이전트, 지원 라우팅(support routing) 에이전트, 운영 자동화(ops automation) 등이 포함됩니다. 각 에이전트는 마지막으로 작업한 사람이 설정한 고유의 핀을 가지고 있습니다. 마이그레이션 순서를 관리하는 책임자가 없으며, 지난 6개월 동안 조정된 업그레이드(coordinated upgrade)를 수행한 적이 없습니다.
• 에이전트 플랫폼을 판매합니다. 고객이 직접 모델을 선택합니다. 당신은 곧 Opus 4.6, 4.7, 4.8, Sonnet 4.5, 4.6, 그리고 Haiku 4.5를 동시에 지원하는 것이 평가 범위(eval surface)의 폭발적인 확장을 의미하며, 지원 부담이 품질의 문제가 아닌 일정(calendar)의 문제로 변한다는 사실을 깨닫게 될 것입니다.
• 1인 또는 소규모 팀의 창업자입니다. 빠르게 제품을 출시했습니다. 프로덕션에 에이전트 하나를 배포했으며, 모델 핀은 하드코딩되어 있고 평가 스위트(eval suite)는 없습니다. 다음 회귀(regression) 현상은 추적조차 불가능한 고객 이탈(churn) 데이터로 나타날 것입니다.

여러분 네 명 모두 동일한 근본적인 문제를 안고 있습니다. 마이그레이션 역량(migration capacity)은 고정되어 있는데, 출시 주기(release cadence)는 가속화되고 있으며, 이 두 수치 사이의 격차는 분기마다 복리로 커지고 있습니다. 이를 6월에 알아차린 팀은 근육을 키울 수 있는 3개월의 시간을 갖게 됩니다. 하지만 9월에 알아차린 팀은 패닉에 빠지게 됩니다.

만약 지금 당장 여러분의 프로덕션 스택(production stack)에 고정된 모든 모델 핀(model pin)과 각 모델이 마지막으로 변경된 시점을 나열할 수 없다면, 읽는 것을 멈추고 가서 확인하십시오.

메커니즘 — 왜 빠른 출시 주기가 고정된 워크플로우를 망가뜨리는가

모델 출시 주기가 분기 단위에서 6주 단위로 압축될 때, 여러분의 에이전트 군단(agent fleet)에서 변화하는 네 가지 구체적인 사항이 있습니다. 이 중 어느 것도 발표 게시물(announcement post)만 보고는 명확히 알 수 없습니다. 그리고 이 모든 것들은 단 한 번의 출시 주기(release cycle) 내에 타격을 입힙니다.

평가 세트(Eval set)의 부식(decay)이 가속화됩니다. 여러분의 평가 스위트(eval suite)는 Opus 4.6의 실패 모드(failure modes)에 맞춰 설계되었습니다. Opus 4.7은 그중 일부를 해결했고 새로운 실패 모드를 도입했습니다. Opus 4.8은 4.7의 일부를 해결했고 또다시 새로운 것을 도입했습니다. 이제 여러분의 평가 세트는 더 이상 존재하지 않는 문제들을 테스트하고 있는 동시에, 실제로 존재하는 문제들은 놓치고 있습니다. 만약 여러분의 평가 세트가 90일 동안 업데이트되지 않았다면, 그것은 현재 마이그레이션 리스크(migration risk)에 대해 여러분에게 거짓말을 하고 있는 것입니다.

해결책은 단순히 "평가 세트를 더 자주 업데이트하는 것"이 아닙니다. 해결책은 구조적이어야 합니다. 평가 스위트를 두 개의 계층으로 분리하십시오. 한 계층은 모델과 상관없이 비즈니스 로직(business logic)을 테스트하며, 이 테스트들은 몇 분기 동안 안정적으로 유지되어야 합니다. 다른 계층은 알려진 모델별 실패 모드(model-specific failure modes)를 테스트하며, 이 테스트들은 매 출시마다 교체되어야 합니다. 만약 기존 테스트 중 어떤 것이 어느 범주에 속하는지 구분할 수 없다면, 여러분은 평가 스위트를 가진 것이 아닙니다. 여러분은 그저 스냅샷(snapshot)을 가지고 있을 뿐입니다.

프롬프트 드리프트 (Prompt drift)가 문제를 악화시킵니다. Opus 4.6에 맞춰 튜닝한 프롬프트는 4.7이 이미 올바르게 처리하는 동작을 과도하게 지정(over-specify)하거나, 4.8이 다르게 처리하는 동작을 불충분하게 지정(under-specify)하게 됩니다. 시간이 흐름에 따라 여러분의 프롬프트는 6개월 전 모델 실패의 화석 기록이 되며, 매 턴마다 토큰 비용으로 그 대가를 치르게 됩니다. 이 비용은 "우리 에이전트 비용이 마땅히 있어야 할 수준보다 2.5배 높다"라는 형태로 나타나며, 팀은 실제 원인이 화석화된 프롬프트 스캐폴딩 (prompt scaffolding)임에도 불구하고 컨텍스트 비대화 (context bloat)를 탓하게 됩니다.

도구 스키마 (Tool schemas)의 호환성 드리프트가 발생합니다. 새로운 모델 세대가 나올 때마다 도구 호출 (tool calling)을 처리하는 능력이 조금씩 향상됩니다. 4.6에서 작동하기 위해 장황한 설명과 예시 딕셔너리 (example dictionaries)가 필요했던 스키마들이 4.7에서는 절반의 서술만으로도 작동합니다. 장황한 버전을 계속 배포하는 것은 호출할 때마다 토큰을 낭비하는 결과를 초래합니다. 반대로 간결한 버전을 계속 배포하는 것은 여전히 4.6에 고정되어 있는 고객들에게 회귀 (regression) 위험을 안겨줍니다. 이러한 드리프트의 비용은 누군가가 버전 간 태스크당 토큰 사용량 (token-per-task) 분석을 실행하여, 동일한 태스크가 이전 고정 버전에서 1.8배 더 많은 비용이 든다는 사실을 발견하기 전까지는 보이지 않습니다.

비용 모델 (Cost models)이 노후화됩니다. Anthropic은 새로운 세대를 출시하며 가격을 조정합니다. Opus 4.8의 가격은 이미 발표되었습니다. 하지만 여러분의 재무 팀이 가진 비용 모델은 4.6이 출시되었을 때의 것입니다. 예상 지출과 실제 지출 사이의 격차는 매달 커지며, 누군가 정산 (reconciliation)을 실행하여 불쾌한 Slack 스레드가 생성될 때까지 계속됩니다.

# 최소한의 모델 버전 레지스트리 (model-version registry) — 이를 에이전트 프레임워크에 포함시키고
# 모든 에이전트가 지원하는 버전을 명시적으로 선언하게 하세요.

...

이것은 고작 50줄짜리 코드입니다. 별도의 서비스가 필요하지 않습니다. 여러분의 팀이 월요일 아침에 볼 수 있는 어딘가에 존재하기만 하면 됩니다.

반대 의견: "그냥 안정적인 버전에 고정하고 소음은 무시하세요"

위의 모든 내용에 대한 가장 강력한 반박은 다음과 같습니다: 모델 출시는 벤더(vendor)의 소음일 뿐입니다. 당신의 업무는 제품을 출시하는 것입니다. 작동하는 모델 버전을 선택하여 고정(pin)하고, 릴리스 노트(release notes) 읽기를 중단하며, 지원 종료(deprecation) 일정으로 인해 강제되는 시점에만 연 단위로 고정된 버전을 재검토하십시오. 모든 릴리스 주기(release cycle)에 집착하는 팀은 제품을 출시하는 팀이 내지 않는 세금을 지불하고 있는 것입니다.

이 말은 절반은 맞으며, 그 맞은 절반의 내용은 인정할 가치가 있습니다.

단 하나의 프로덕션 에이전트(production agent)를 보유하고, 평가 범위(evaluation surface)가 낮으며, 고객에게 노출되는 모델 선택 기능이 없는 팀에게는 공격적으로 버전을 고정하고 출시 주기(cadence)를 무시하는 것이 옳습니다. 이번 주에 4.8로 마이그레이션(migration)할 필요는 없습니다. 아마 8월에 4.9로 마이그레이션할 필요도 없을 것입니다. Anthropic의 조건에 맞춰 지원 종료(deprecation) 주기를 수용하고, 일 년에 두 번 정도 하루치 마이그레이션 비용을 지불하며 상황을 마무리할 수 있습니다. 대부분의 소규모 팀 프로덕션 배포는 이 범주에 속합니다. 이러한 팀들에게 지금 읽고 있는 글은 과한 내용입니다.

하지만 규모가 커지면 이 논리는 무너집니다. 프로덕션 에이전트가 대략 3개를 넘어서거나, 어떤 형태든 멀티 테넌트(multi-tenant) 모델 선택 기능이 있거나, 고객이 지연 시간(latency)과 비용에 대해 질문하기 시작하면, 고정 후 무시하는 전략은 더 이상 작동하지 않습니다. 마이그레이션 부채(migration debt)가 복리로 쌓입니다. 평가 범위(eval surface)가 너무 커져서 단 한 번의 오후 시간만으로는 마이그레이션할 수 없게 됩니다. 오래된 프롬프트(stale prompts)는 실제 비용 손실을 초래합니다. 출시 주기를 6개월 동안 무시했던 팀은 이제 분기 단위의 마이그레이션 프로젝트를 마주하게 되지만, (마이그레이션) 근육을 키워온 팀은 이미 두 번의 마이그레이션을 마친 상태일 것입니다.

또한 고려해 볼 만한 미묘한 반론이 있습니다. 어쩌면 출시 주기 (cadence)가 느려질 수도 있다는 것입니다. 아마도 Opus 4.9가 11월에 출시되어 다시 분기별 주기로 돌아갈지도 모릅니다. 저는 그렇게 믿지 않습니다. Anthropic, OpenAI, 그리고 Google에서 나오는 모든 신호는 그 반대 방향을 가리키고 있습니다. 하지만 이것이 반대편에 걸린 베팅이라는 점은 알고 있어야 합니다. 만약 출시 주기가 분기별로 되돌아갈 것이라고 생각한다면, 아래의 모든 플레이북 (playbook)은 헛수고가 될 것입니다. 저는 제 베팅을 확정하겠습니다. 출시 주기 압축 (cadence compression)은 2026년까지 계속될 것이며, 지금 마이그레이션 근육을 키워온 팀들이 연말쯤 되면 명백히 옳았음이 증명될 것입니다. 12월에 다시 이야기해 봅시다.

플레이북 (The playbook): Opus 4.9가 출시되기 전 다섯 가지 단계

이것은 여러분이 이번 달에 수행해야 할 작업입니다.

1. 출시되는 모든 모델 고정 (model pin) 항목을 전수 조사하십시오

저장소 (repos)에서 하드코딩된 모델 ID를 grep으로 검색하십시오. 설정 파일 (config files), 환경 변수 (environment variables), 폴백 경로 (fallback paths), 에러 핸들러 (error handlers), 개발 도구 (dev tools), 그리고 가장 은밀한 곳인 테스트 픽스처 (test fixtures)를 확인하십시오. 테스트 픽스처는 누군가 작성할 당시의 최신 모델로 고정되어 있는 경우가 거의 대부분이며, 거의 업데이트되지 않습니다.

전수 조사 결과는 다음과 같은 평면 리스트 (flat list) 형태로 작성하십시오:

agent_name | model_pin | last_changed | owner | env (prod/staging/dev)

만약 owner를 채울 수 없다면, 새로 지정하십시오. 담당자가 지정되지 않은 모델 고정 항목은 최악의 타이밍에 퇴보 (regress)하게 될 것입니다.

2. 평가 스위트 (eval suite)를 레이어별로 태깅하십시오

기존의 모든 평가 (eval) 항목을 검토하십시오. 각 항목에 business-logic 또는 model-behavior 중 하나로 라벨을 붙이십시오. 비즈니스 로직 (business-logic) 평가는 뒤에 어떤 모델이 있든 상관없이 에이전트가 해당 도메인에 대해 올바른 일을 수행하는지 테스트합니다. 모델 동작 (model-behavior) 평가는 특정 모델 버전에서 관찰된 구체적인 실패 모드 (failure modes)를 테스트합니다.

비즈니스 로직 레이어는 마이그레이션 시 변경되어서는 안 됩니다. 모델 동작 레이어는 매 마이그레이션 시마다 검토되어야 하며, 새로운 세대의 모델이 기존의 실패 모드를 해결함에 따라 교체되어야 합니다. 만약 평가 항목을 하나의 범주로 깔끔하게 분류할 수 없다면, 아마도 두 가지를 모두 테스트하고 있는 것일 겁니다. 그러면 분리하십시오.

3. 각 고정 항목(pin)당 45일의 평가 주기 (eval cadence)를 설정하십시오

모든 프로덕션 모델 고정(pin) 항목에 대해 45일 간격으로 반복적인 평가 패스(eval pass)를 예약하십시오. 이는 의도적으로 릴리스 주기(release cadence)보다 짧게 설정된 것입니다. 만약 Opus 4.9가 6주 차에 출시되었는데 마지막 평가가 5주 차에 이루어졌다면, 마이그레이션 결정(migration call)을 내릴 때 데이터가 전혀 없는 대신 1주일 분량의 최신 데이터를 확보할 수 있기 때문입니다.

평가 패스가 정교할 필요는 없습니다. 최소한으로 유용한 패스는 다음과 같습니다: 현재 고정된 모델(current pin), 그다음으로 최신인 모델(next-newer pin), 그리고 그 이전의 최신 모델(previous-newer pin)을 대상으로 상위 20개 태스크(top-20 tasks)를 실행하고, 각 모델의 통과율(pass rate)과 토큰 비용(token cost)을 기록하십시오. 인프라가 제대로 갖춰져 있다면 30분 정도의 작업이면 충분합니다.