Claude Opus 4.8 살펴보기

오늘 새벽 두 시에 갑자기 Claude Opus 4.8이 출시됐다. 요새 클로드의 모델 업데이트 주기가 부쩍 빨라졌다. 작년만 해도 프론티어 모델의 업데이트는 최소 세 달을 간격으로 진행했었는데, 올해 들어서는 Opus 4.6에서 4.7로 약 두 달, 4.7에서 4.8로는 그보다 짧은 한 달 조금 넘는 기간이었다. 4.7을 출시일부터 사용한 사람으로서는 체감상 빠른 주기였다.

출시일 간격이 훨씬 좁았던 걸 볼 수 있다.

이제 Opus 4.8이 4.7에 비해 어떤 부분이 개선되었는지 Anthropic 공식 문서를 통해 살펴보자.

Opus 4.8의 핵심#

Anthropic이 소개하는 Opus 4.8의 핵심적인 내용이다.

Claude Opus 4.7을 기반으로 개발된 Opus 4.8은 이전 버전인 4.7에 비해서 작성한 코드의 결함을 놓치고 넘어가는 경우가 약 4배 적다고 한다. 또한 Anthropic Alignment 팀은 이번 모델이 "사용자 자율성 지원 및 사용자의 최선의 이익을 위한 행동과 같은 친사회적 특성 측정에서 SOTA에 도달했다"고 결론지었다고 한다. 뿐만 아니라 지난 모델보다 훨씬 낮은 비율의 'misaligned behavior'(기만, 꼼수 등 정렬의 의도와는 맞지 않는 행동) 패턴을 보였으며, 그 유명한 Claude Mythos Preview와 유사한 수준임을 보였다고 한다.

Anthropic이 말하는 Misaligned behavior#

Misaligned behavior: 인간의 오용에 동조하는 것부터 모델이 자의적으로 취하는 바람직하지 않은 행동에 이르기까지, 중간 및 높은 위험을 수반하는 다양한 시나리오 전반에서 발생하는 여러 형태의 우려되는 행동을 총칭하는 포괄적 용어다. (출처: System Card: Claude Opus 4.8, p. 94)

모델 벤치마크#

출처: Anthropic, System Card: Claude Opus 4.8, p. 193

각 벤치마크가 무엇을 측정하는가

표에 약어가 많아 헷갈리기 쉬워, 항목별로 무엇을 평가하는지 짧게 정리한다. (출처: System Card: Claude Opus 4.8, §8.2~8.13)

코딩·소프트웨어 엔지니어링

• SWE-bench Verified: 실제 GitHub 이슈를 고치는 과제. 사람이 "풀 수 있다"고 검증한 500문제 부분집합.
• SWE-bench Pro: 더 어려운 변형. 활발히 유지보수되는 저장소에서 뽑은, 여러 파일에 걸친 큰 diff 문제(정답 유출 없음).
• SWE-bench Multilingual: 같은 형식을 9개 프로그래밍 언어 300문제로 확장.
• SWE-bench Multimodal: 이슈 설명에 스크린샷·디자인 목업 등 시각 정보를 더한 버전.
• Terminal-Bench 2.1: 터미널·명령줄 환경에서의 실제 작업 수행 능력.

지식·추론

• GPQA Diamond: 전문가는 맞히지만 비전문가는 못 맞히는 대학원 수준 과학 객관식(Diamond 198문제).
• Humanity's Last Exam (HLE): 인간 지식의 최전선을 묻는 멀티모달 문제 2,500개. 도구 없이/도구 써서 두 조건으로 측정.

에이전트 검색·도구 사용

• BrowseComp: 웹에서 찾기 어려운 정보를 에이전트가 검색해 알아내는 능력.
• MCP-Atlas: MCP(Model Context Protocol)로 알맞은 도구를 찾아 호출하고 결과를 종합하는 다단계 워크플로 수행.
• Automation Bench: 47개 앱의 REST API가 있는 가상 회사에서, 자연어 지시 하나로 비즈니스 워크플로를 끝까지 자동 수행(Zapier).
• Finance Agent v2: 상장사의 SEC 공시를 조사·분석하는 과제(Vals AI).
• GDPval-AA: 문서·슬라이드·스프레드시트 등 실제 직무 산출물 220개 과제. 결과물을 블라인드 쌍대 비교해 ELO로 채점(그래서 점수가 1890처럼 큰 값이다).

멀티모달·화면 조작(GUI)

• ChartQAPro: 다양한 실제 출처의 차트를 보고 질문에 답하는 차트 이해 능력.
• ScreenSpot-Pro: 전문 데스크톱 앱의 고해상도 스크린샷에서 지시한 UI 요소의 위치를 정확히 짚는 GUI 그라운딩.
• OSWorld-Verified: 실제 Ubuntu 가상머신을 마우스·키보드로 조작해 문서 편집·웹 브라우징·파일 관리 같은 컴퓨터 작업 수행.

장문맥(Long context)

• GraphWalks BFS: 컨텍스트를 16진수 해시 노드의 방향 그래프로 채우고, 한 노드에서 너비 우선 탐색(BFS)을 시키는 다중 홉 추론. (256K·1M은 컨텍스트 크기)
• GraphWalks Parents: 같은 그래프에서 특정 노드의 부모 노드를 찾게 하는 과제.

새로운 기능#

Anthropic 공식 문서는 아래와 같이 Opus 4.8의 새로운 다섯 기능을 소개한다.

1. 대화 중 시스템 메시지 삽입(Mid-conversation system messages)
2. 프롬프트 캐싱 최소 기준 하향(Lower prompt cache minimum)
3. 기본 노력값 설정(Effort defaults)
4. 거절 중단 세부 정보(Refusal stop details)
5. 고속 모드(Fast mode)

대화 중 시스템 메시지 삽입#

LLM API에 요청을 보낼 때 system 지시가 들어갈 수 있는 자리는 원래 하나뿐이었다. 요청 본문 최상위의 system 필드다. 이 자리는 모든 메시지보다 앞에 놓인다.

문제는 prompt caching과 부딪힐 때 생긴다. 캐싱은 요청의 앞부분(prefix)을 tools → system → messages 순서로 해싱해서, 이전 요청과 byte 단위로 일치하는 지점까지를 캐시에서 읽어온다. 그런데 system 필드는 이 prefix의 거의 맨 앞에 있다. 대화 도중 이 필드에 문장 하나만 덧붙여도 해시가 바뀌고, 그 뒤에 캐시돼 있던 system과 모든 메시지가 통째로 무효화(cache miss)된다. 수십 턴이 쌓인 긴 에이전트 세션에서 제약 하나 추가하자고 전체 히스토리를 다시 처리하게 되는 셈이다.

Opus 4.8의 mid-conversation system messages는 이 틈을 메운다. 최상위 system 필드를 건드리는 대신, messages 배열 안에 {"role": "system"} 메시지를 새 지시가 필요해진 바로 그 지점에 끼워 넣는다(append).

messages=[
    {"role": "user", "content": "process() 성능 리뷰해줘"},
    {"role": "assistant", "content": "..."},
    {"role": "user", "content": "이제 호출부도 리뷰해줘"},
    # 여기서 새 정책이 필요해짐 → 앞 턴들은 byte 단위로 그대로 유지됨
    {"role": "system", "content": "지금부터 모든 제안에 명시적 타입 주석을 포함할 것"},
]

핵심은 덮어쓰기가 아니라는 점이다. 기존 system은 그대로 살아있고, 새 system 메시지가 그 뒤에 더해진다. 충돌하면 나중 것이 이긴다 — 나중 system 메시지가 앞선 것보다, mid-conversation system 메시지가 최상위 system 필드보다 우선한다(공식 문서 기준). 즉 "덮어쓰기"가 아니라 "누적 + 후순위 우선" 구조다.

배치에는 제약이 있다. system 메시지는 messages의 첫 항목이 될 수 없고(처음부터 적용할 지시는 최상위 system 필드를 쓴다), 반드시 user 턴 바로 뒤에 와야 하며, 그 뒤는 assistant 턴이거나 배열의 끝이어야 한다. 연속된 system 메시지도 허용되지 않는다. 그리고 문서가 분명히 짚는데, 이건 보안 경계가 아니다. system 권한을 부여할 뿐, 신뢰할 수 없는 콘텐츠를 신뢰 가능하게 만들지는 않는다.

같은 내용을 그냥 user 메시지에 넣어도 모델은 따르긴 한다. 하지만 user 콘텐츠는 "해석해야 할 데이터"로, system 메시지는 "system 권한을 가진 지시"로 취급된다. 이 권한을 유지하면서 캐시 비용을 안 내는 것이 이 기능의 본질이다.

Claude Code에서도 적용될까?#

문서만 읽으면 여기서 끝이다. 그런데 마침 이 글을 쓰는 환경이 Opus 4.8을 쓰는 Claude Code다. 직접 확인해봤다.

먼저 짚어둘 게 있다. Claude Code가 남기는 세션 로그(.jsonl)를 까보면 메시지 role은 user와 assistant 둘뿐이고 system은 메시지가 아니라 별도의 내부 이벤트로만 존재한다. 하지만 이건 클라이언트가 남긴 로그일 뿐, API에 실제로 나간 요청 본문(wire)이 아니다. 실제로 매 턴 주입되는 <system-reminder> 같은 맥락도 이 로그에는 저장돼 있지 않았다. 그래서 로그로는 답을 낼 수 없다.

와이어를 직접 봐야 한다. mitmproxy를 Claude Code와 api.anthropic.com 사이에 중간자로 끼우고(HTTPS_PROXY), Claude Code가 mitmproxy의 인증서를 신뢰하게 만든 뒤(NODE_EXTRA_CA_CERTS), TLS를 복호화한 실제 요청 JSON을 그대로 떴다.

claude -p "..." 한 줄을 Opus 4.8로 흘려보내자, 요청 본문의 messages 배열 끝에 role: system 메시지가 실제로 붙어 있었다. 담긴 내용은 그 시점에 동적으로 로드 가능한 도구 목록이었다 — 자주 바뀌는, 그래서 캐시된 prefix 뒤에 두기 딱 좋은 정보다.

// Opus 4.8 요청 (mitmproxy로 캡처한 실제 본문, 값은 축약)
{
  "model": "claude-opus-4-8",
  "system": [ /* 정적 시스템 프롬프트 블록들 — cache_control로 캐시됨 */ ],
  "messages": [
    { "role": "user",   "content": [ /* <system-reminder> + 실제 프롬프트 */ ] },
    { "role": "system", "content": "...로드 가능한 도구 목록..." }  // ← mid-conversation system message
  ]
}

여기까지는 "있다"는 관찰일 뿐이다. 우연이 아님을 보이려면 대조군이 필요하다. 그래서 다른 조건은 전부 고정하고 모델만 4.7로 바꿔 같은 호출을 다시 떴다.

같은 클라이언트, 같은 프롬프트, 바뀐 건 모델 하나. 4.8에선 role: system 메시지가 붙었고, 4.7에선 사라졌다. 그리고 4.8에서 system 메시지에 담겼던 그 도구 목록은, 4.7에선 user 메시지 안의 텍스트로 흡수돼 있었다. 똑같은 내용이 모델에 따라 자리와 role을 바꾼 것이다.

결론은 두 가지다. 첫째, Claude Code는 모델을 인지해서 4.8에서만 mid-conversation system message를 쓰고, 미지원 모델에선 같은 내용을 user 텍스트로 fallback시킨다. 둘째, 이건 "같은 내용도 어느 role에 넣느냐가 별개의 선택"이라는 걸 눈으로 보여준다. 지시를 XML 태그로 감싸 user 메시지에 넣는 것과 진짜 system 메시지는 다른 메커니즘이다.

덧붙이면, 이 캡처는 claude -p 헤드리스 단일 호출 기준이다. 인터랙티브 다중 턴에서 system 메시지가 어떻게 누적되는지는 또 다른 관찰이 필요하다. 다만 4.8이 이 기능을 쓰느냐 아니냐는 사실 자체는 이 대조만으로 충분히 드러난다.

프롬프트 캐싱 최소 기준 하향#

프롬프트 캐싱에는 최소 토큰 문턱이 있다. 프롬프트가 이 길이보다 짧으면 cache_control을 붙여도 캐시되지 않는다(에러도 없이 그냥 무시된다). Opus 4.8은 이 문턱을 낮췄다.

공식 문서의 표현은 이렇다.

The minimum cacheable prompt length on Opus 4.8 is 1,024 tokens, lower than on Claude Opus 4.7. Prompts that were too short to cache on Claude Opus 4.7 can now create cache entries with no code changes.

즉 4,096 → 1,024로 4배 낮아졌다. 4.7에서는 너무 짧아 캐싱되지 못하던 프롬프트가, 코드 수정 없이 캐시 대상이 된다.

문턱은 켜고 끄는 스위치가 아니라 바닥(floor)이다. 프롬프트가 문턱 미만이면 캐싱이 통째로 일어나지 않는다. 그래서 이번 하향의 수혜자는 짧은 프롬프트 — system 프롬프트와 도구 정의가 작은 가벼운 에이전트, 초반 턴이 짧은 대화다. 이미 4,096을 넘던 긴 프롬프트는 4.7에서도 캐싱됐으니 달라질 게 없다.

캐싱이 됐는지는 응답의 usage로 확인한다. cache_creation_input_tokens와 cache_read_input_tokens가 둘 다 0이면 캐시되지 않은 것이고, 문턱 미달이 흔한 원인이다.

앞의 대화 중 시스템 메시지 삽입과 묶어 보면 방향이 같다. 둘 다 에이전트 루프에서 반복되는 입력을 더 싸게 처리하려는 변화다 — 하나는 캐시를 깨지 않고 지시를 덧붙이게 하고, 다른 하나는 더 짧은 프롬프트까지 캐시 혜택을 넓힌다.

고속 모드#

고속 모드(fast mode)는 같은 Opus 모델을 더 빠르게 출력하도록 돌리는 설정이다. 더 작은 모델로 낮추는 게 아니다. 동일한 Opus가 그대로, 출력 속도만 최대 2.5배 빨라진다. 품질과 능력은 변하지 않는다.

한 가지만 짚으면, 빨라지는 건 "초당 생성되는 토큰 수"이지 "첫 글자가 나오기까지의 시간"이 아니다.

사실 고속 모드 자체는 Opus 4.6에서 처음 나왔다. 그러니 4.8만의 새 기능은 아니다. 4.8에서 달라진 핵심은 가격이다.

빨라지는 대신, 토큰 단가가 오른다#

먼저 오해 하나를 짚자. 고속 모드는 토큰을 더 많이 쓰는 게 아니다. 토큰 1개당 값이 비싸지는 것이다. 같은 작업이면 소모하는 토큰 수는 똑같고, 단가만 오른다.

(표준 Opus 4.8은 입력 $5/출력$25)

바로 여기가 4.8의 실질적 개선점이다. 4.6·4.7에서 표준의 6배였던 가격이 4.8에서는 2배로 내려왔다. 같은 속도 향상을 3분의 1 값에 쓰는 셈이다.

Claude Code에서는 어떻게 쓰나#

/fast로 켜고 끈다(Tab으로 토글). 켜면 자동으로 Opus로 전환되고, 프롬프트 옆에 ↯ 아이콘이 뜬다.

과금 방식이 조금 특이하다.

즉 "한도를 두 배로 빨리 소진"하는 구조가 아니라, 한도 바깥에서 추가로 돈이 나가는 구조다. API 키로 쓸 때는 위 표의 단가가 그대로 적용된다.

캐싱과 엮이는 주의점#

대화 도중에 고속 모드를 켜면 그때까지 쌓인 프롬프트 캐시가 무효화된다. 속도가 다른 요청끼리는 캐시를 공유하지 않기 때문이다. 그러면 지금까지의 전체 컨텍스트를 고속 단가로 다시 처리하게 되어 비싸진다. 그래서 공식 문서도 세션을 시작할 때 켜 두라고 권한다. 앞의 두 캐싱 이야기와 그대로 이어지는 대목이다.

마지막으로, 고속 모드는 아직 research preview라 가격과 가용성은 바뀔 수 있다. 그리고 Opus 4.6의 고속 모드는 4.8 출시 약 30일 뒤 사라질 예정이다.

Opus 4.7에 비해 개선된 내용#

1. Context 압축 처리 성능이 향상되고 장기적인 컨텍스트 품질이 개선되어 모델이 압축 후에도 탈선 없이 작업을 유지한다.
2. 적응형 사고를 통해서 동일한 노력 수준에서 낭비되는 사고 토큰이 줄어들었다.
3. 자주 발생했던 문제인 모델이 작업에 필요한 도구 호출을 건너뛰는 현상이 줄어들었다.

---

Anthropic의 다음 계획#

• Opus와 동일한 기능을 더 저렴한 가격으로 제공하는 모델을 개발 및 출시할 예정
• Opus보다 훨씬 더 높은 지능을 가진 새로운 등급의 모델을 출시할 계획
• 향후 몇 주 안에 모든 고객에게 Mythos급 모델을 제공할 수 있을 것으로 예상

주관적인 생각 및 사용 후기#

4.7은 4.6에 비해서 훨씬 좋은 성능 벤치마크를 보여줬지만, 좋지 않은 이야기들이 나왔던 건 사실이다. 프론티어 모델을 극한으로 사용했던 건 아니지만, 그래도 4.7과 한 달이 조금 넘는 시간 동안 상호작용하면서 꽤 답답한 부분이 있다고 느꼈다.

예를 들어서, Claude가 AskUserQuestion tool을 호출할 때, 그 이후로 한글이 깨지는 현상이 잦았다. 문법적으로 허용되지 않는 글자들이 튀어나온다든지 그런 경우가 종종 있었다.

글자 깨지는 것도 문제지만, 가독성이 너무 안 좋았다. Native English로 시작한 세션이 많지 않았기에 영어가 적절하게 사용됐는지는 잘 못 봤지만, 한글은 가독성이 너무 안 좋았다. Claude가 내뱉은 말들을 이해하는 데 평소보다 더 많은 시간을 할애했던 것 같다.

그리고 Skill을 직접 명시하는 게 아니면 능동적으로 사용하는 일이 적었다. 이건 오히려 사용자가 의도하지 않은 Skill, Tool 사용(False Positive)을 줄이는 좋은 사례가 될 수도 있다. 하지만 반대로 사용자가 의도한 요청까지 놓칠 수 있다는 뜻이기도 하다.

Opus 4.7에서의 가장 큰 변화는 새로운 tokenizer를 사용했다는 것이다. 사실 이건 꽤 큰 변화이다. Token은 LLM이 단어를 이해하는 최소 단위이며, 그 최소 단위의 기준을 어떻게 잡는지(BPE 등)에 따라서 LLM이 세상의 말을 더 잘 이해하거나 효율적으로 학습할 수 있게 된다.

아무튼, 그 기준으로 Token을 만드는 Tokenizer는 자연어처리에서 중요할 수밖에 없다. Anthropic이 사용했던 단위가 존재했을 텐데, 그 단위를 건드렸다는 점에서 꽤 큰 도전을 했을 수도 있겠다는 생각이 들었다. 정말 주관적인 생각이지만, 이런 관점에서는 Opus 4.7이 문제가 많았다는 게 충분히 이해가 되는 것 같다.

사용 후기#

금일 오전 10시부터 지금 글을 작성하고 있는 오후 10시 37분까지 하루 종일 Opus 4.8을 사용해보고 느낀, 지극히 경험적인 후기를 작성해보려고 한다.

가장 크게 체감되었던 부분은 어떤 작업이든지 간에 Opus 4.8이 자가 검증을 정말 많이 했다는 것이다. 자기 자신이 작업한 내용, 그리고 자기 자신이 떠올린 생각을 객관적으로 바라보려고 노력하는 게 세션 내내 보였다.

적어도 오늘 하루는 Anthropic이 언급했던 정직성이라는 키워드가 충분히 와닿았다.

또한 모델이 출력하는 말들의 가독성이 훨씬 좋아진 게 체감됐으며, 한글 깨짐 이슈가 전혀 없었다. AskUserQuestion 도구 호출에도 전혀 깨짐이 없었다.

또한 Context가 Opus 4.7 기준으로 200K만 넘어가도 Long Term Dependency 측면에서 성능이 좋지 않은 경우가 많았는데, Opus 4.8은 200K가 넘어가도 성능이 잘 나오는 듯한 느낌이 들었다.

그리고 도구 호출이다. Opus 4.7는 도구명, 스킬명을 명세해야 잘 호출했었는데, Opus 4.8은 그러지 않아도 Context 상 필요한 도구를 자연스럽게 호출했다.

마지막으로 본문에서는 언급하지 않았지만, Claude Code에 workflow라는 기능을 새롭게 출시했다. 단일 세션에서 시작해 사용자의 요청에 대한 작업을 Multi-Agent를 꾸려 수행해내는 워크플로다. 굉장히 강력한 기능인 것 같지만, 토큰 사용량이 그만큼 많으며, 관리 감독 차원에서는 어려울 수 있을 것 같다. 해당 기능은 조금 더 사용해보고, 공부해서 글을 올려볼 계획이다.

결론#

새로운 모델이 나온 당일은 모델의 성능에 심취하게 되는 경우가 많은 것 같다. 정말 모델이 좋아져서인 것도 있겠지만, 단순 벤치마크 및 모델 카드에 대한 좋은 내용들을 보고 나서 사용하게 되는 것 때문일까? 하지만 오늘 하루만큼은 Opus 4.8이 정말 만족스러웠다.

안 그래도 독보적이었던 Claude의 코딩 시장 점유율은 적어도 몇 주 동안은 더 불타오르지 않을까.

참고 자료#

• Introducing Claude Opus 4.8: https://www.anthropic.com/news/claude-opus-4-8
• System Card: Claude Opus 4.8 (벤치마크 정의 §8): https://cdn.sanity.io/files/4zrzovbb/website/c886650a2e96fc0925c805a1a7ca77314ccbf4a6.pdf
• What's new in Claude Opus 4.8: https://platform.claude.com/docs/en/about-claude/models/whats-new-claude-4-8
• adaptive-thinking: https://platform.claude.com/docs/ko/build-with-claude/adaptive-thinking
• prompt-caching: https://platform.claude.com/docs/en/build-with-claude/prompt-caching
• mid-conversation-system-messages: https://platform.claude.com/docs/en/build-with-claude/mid-conversation-system-messages#limitations

사진#

• 출처: https://www.anthropic.com/news/claude-opus-4-8