Claude Opus 5 공개 - 성능, 가격, 프롬프트 가이드 정리(Claude code)

Anthropic이 Claude Opus 5를 공개했습니다. 좋은 성능을 싼값에 쓸 수 있게 만든 모델이라는 특징이 두드러집니다.

그리고 같은 날 올라온 글이 하나 더 있습니다. Anthropic 기술 스태프 Thariq Shihipar가 쓴 "The new rules of context engineering for Claude 5 generation models"인데요. 이 글에서는 Opus 5와 Fable 5 같은 모델을 위해 Claude Code 시스템 프롬프트의 80퍼센트 이상을 제거했고 자사 코딩 평가에서 측정 가능한 손실이 없었다는 겁니다. 벤치마크 차트보다 이쪽이 실무자에게 더 중요할 것 같고 저도 이 글을 좀 더 관심있게 봤습니다. 

 

클로드 모델 중 Opus 5의 라인업

 

앤트로픽의 클로드 모델 중 Opus 5 모델의 라인업을 인지하기 위해서는 앤트로픽(Anthropic)의 최신 모델 라인업을 정리해야 합니다. 현재 Anthropic의 모델은 최근에 굉장히 뜨거웠던 Mythos가 최상위권에 있고, 그 아래가 Opus, 다시 Sonnet과 Haiku로 내려가는 구조입니다. Mythos 계층에는 Claude Mythos 5와 Claude Fable 5가 있는데, Fable 5 쪽에 생물학, 사이버보안, LLM 연구개발 영역의 추가 안전장치가 얹혀 있습니다. Opus 5는 그 바로 아래에서 Opus 4.8을 잇는 후속 모델입니다.

---

벤치마크 성능

원문 글에서는 단순 점수가 아니라 effort 설정에 따라 성능이 어떻게 변하는지, 과제 하나를 처리하는 비용 대비 성능이 어느 정도인지를 함께 보여줍니다. effort는 모델이 얼마나 깊이 생각할지를 정하는 설정값입니다. 점수도 중요하지만, 같은 비용에서 얼마나 효과적인지를 보여줍니다.

 

코딩 쪽은 Frontier-Bench v0.1에서 Opus 5는 43.3%로, 21.1%였던 Opus 4.8의 두 배를 넘겼습니다. 과제당 비용은 오히려 더 낮습니다. CursorBench 3.2에서는 max effort 기준으로 Fable 5의 최고 점수와 0.5% 포인트 이내 차이인데 비용은 절반입니다. AA Coding Agent Index도 같은 결과를 보여줍니다.

코딩 외 영역도 비슷합니다. 처음 보는 문제를 푸는 능력을 측정하는 ARC-AGI 3에서 30.2%를 기록해 2위 모델의 세 배 가까운 점수를 냈고, 업무 과제를 끝까지 처리하는지 보는 Zapier AutomationBench에서는 같은 비용 기준 통과율이 2위의 약 1.5배입니다. 여기서 눈에 띄는 건 가장 낮은 effort로 돌려도 다른 어떤 모델보다 많은 과제를 통과했다는 점입니다.

 

 

컴퓨터 사용을 평가하는 OSWorld 2.0에서는 70.6%로 Fable 5의 66.1%를 넘었는데, 비용은 3분의 1 수준입니다.

과학 분야에서는 구조생물학과 유기화학, 생물정보학 평가 전 항목에서 Opus 4.8을 앞섰습니다. 

 

무엇보다 제가 흥미롭게 본 것은 단순 벤치카밍 점수보다 '도구(tools)'를 만드는 과정이었는데요. Frontier-Bench 과제에서 기계 부품 도면을 FreeCAD 3D 모델로 복원하는 코드를 짜는 문제가 있는데, 모델이 도면을 직접 볼 수 없도록 막아 둔 조건이었습니다. Opus 5는 픽셀에서 기하 정보를 추출하는 컴퓨터 비전 코드를 먼저 만든 다음 부품을 복원했다고 합니다. 우연이 아니라 반복해서 성공했고, 같은 조건에서 다른 모델은 다섯 번을 시도해도 풀지 못했다고 합니다. 오픈소스 패키지 버그 사례에서도 마찬가지로 이 과정이 보였다고 하고요. 이 사례를 보면 직접 코드를 만들어서 본인 스스로 확인할 방법을 만들어서 판단하고 검증했다는 굉장히 흥미로운 사례를 보여줍니다.

---

API 및 기본 개발 설정에서 바뀐 것

이번 Opus 5가 나오면서 API 설정이나, 기본 개발 설정 등에서 변화가 있었습니다.

이를 표로 정리하면 아래와 같습니다.

구분	설명
API 모델 ID	claude-opus-5
context-window	100만 토큰
최대 출력	128,000
thinking	기본 활성화
가격	입력 100만 토큰당 5달러, 출력 100만 토큰당 25달러
low, medium	품질이 유지되는 영역에서 토큰 비용과 응답 시간을 줄이는 1차 수단. (공식 가이드에서는 적극 사용하라고 권장하고 있습니다.)
high	기본값
xhigh	조금 더 고난도 또는 복잡한 에이전트 작업
max	토큰 지출을 제한하지 않을 만한 가치가 있는 과제에만 사용 권장. 오히려 쉬운 과제에서는 과잉 될 수 있음

 

컨텍스트 창 100만 토큰이 기본값이면서 최대값이 되었습니다. 옵션으로 켜고 끄던 기능이 기본 사양이 된 겁니다. 가격은 Opus 4.8과 같습니다.

그리고 thinking이 기본으로 켜집니다. Opus 4.8에서는 명시하지 않으면 thinking 없이 실행됐지만 이제는 켜진 상태로 돌아갑니다. 주의할 점은 max_tokens가 thinking 토큰과 응답을 합친 전체 출력에 걸립니다. 이전 설정을 그대로 옮기면 응답이 잘릴 수 있습니다.

 

큰 특이점은 effort 권장값이 바뀌었습니다. Opus 4.8에서는 코딩이나 자율 작업이라면 xhigh를 지정하라는 것이 공식 권고였는데요. Opus 5에서는 기본값인 high에서 시작해 결과를 보고 조정하라고 안내합니다. low와 medium을 비용 조절 수단으로 적극 쓰라는 겁니다.

그러면, 어떻게 effort를 조정하는가?가 궁금할탠데요. 권장하는 내용은 먼저 기본값 high로 돌려 기준 결과를 만들고, 같은 작업을 medium으로 돌려 비교합니다. 차이가 없으면 낮은 쪽으로 고정하고, 눈에 띄게 나빠지면 high로 돌아가면 됩니다. Opus 5는 낮은 단계의 품질이 많이 올라가서, Opus 4.8이라면 xhigh를 썼을 작업도 high나 medium으로 충분할 것이라고 하네요. (개인적으로는 그냥 high~xhigh를 계속 쓸 것 같긴 합니다.)

이때 주의할 점이 thinking: {"type": "disabled"}는 effort가 high 이하일 때만 허용됩니다. xhigh나 max와 함께 보내면 이제 400 에러가 날 수 있습니다. Opus 4.8에서는 이런 제한이 없었기 때문에 이점 체크해야하고, thinking 자체를 끄는 것은 권장하지 않고 있습니다.

---

클로드 코드의 시스템 프롬프트 80퍼센트를 지운 이유

앞서 Anthropic 기술 스태프 Thariq Shihipar가 쓴 "The new rules of context engineering for Claude 5 generation models" 글도 같이 공개가 되었다고 했었는데요. 이 글에서는 Claude 5 모델을 위한 컨텍스트 엔지니어링의 새로운 규칙에 대한 내용이 작성되어 있습니다. 프롬프트와 달리 컨텍스트는 수많은 요청에 두루 쓰이기 때문에 특정 상황에 딱 맞게 쓸 수가 없고, 그래서 사용자가 무엇을 물어볼지 모르는 상태에서 일반적인 지침을 잘 쓰는 일은 생각보다 까다롭습니다. 요즘은 하네스(harness) 엔지니어링 등으로 확장되서 언급되기도 합니다.

 

 

이 글에서 저자가 말하는 맥락은 기존엔 '과잉 제약'이었다고 말합니다. 시스템 프롬프트와 CLAUDE.md, 스킬 모두에서 Claude Code를 지나치게 옥죄고 있었다는 겁니다. 한쪽에서는 문서화를 적절히 남기라고 하고, 다른 쪽에서는 주석을 절대 달지 말라고 하는 식입니다. 물론 모델은 사용자의 의도를 읽어 대체로 옳은 답에 도달하지만, 그러기 위해 겹치고 충돌하는 지시들을 먼저 정리하는 데 생각을 써야 했습니다. 이 글에서는 이제는 상당수를 지우고 모델이 주변 맥락과 판단력을 쓰도록 두어도 된다고 이야기 합니다. 그렇게 대략 80% 이상 지우게 되었고 코딩 평가에서는 측정 가능한 손실이 없었다고 합니다.

 

정리하자면, 아래와 같이 프롬프트 작성 방식의 변화를 주도록 이야기하고 있습니다.

기존 방식	제안 방식
규칙을 준다	판단에 맡긴다
예시를 준다	인터페이스를 설계한다
전부 앞에 넣는다	필요할 때 불러온다
중요한 건 반복한다	도구 설명을 간결하게 쓴다
CLAUDE.md에 기억을 적는다	메모리에 맡긴다
명세를 문서로 쓴다	코드, 테스트 등 자원을 제공한다

 

그동안 도구(Tools)를 사용할 때 Claude에게 도구를 어떻게 사용하는지 예시를 제공했습니다. 근데 이 글에서는 최신 모델에서는 예시가 오히려 탐색 공간을 특정 범위에 가둬 버린다고 언급합니다. 대신 도구와 스크립트, 파일의 설계에 공을 들이라고 권하고 있죠. Claude가 다룰 파라미터가 무엇이고 그것을 얼마나 더 표현력 있게 만들 수 있는지를 고민하라는 겁니다. 

그리고 실무에서 많이 사용할 법한 내용인데요. Claude Code는 코딩에 초점이 맞춰져 있다 보니 코드 리뷰와 검증을 어떻게 하는지에 대한 상세한 정보가 시스템 프롬프트에 들어 있었습니다. 그런데 이제 Claude Code가 필요한 시점에 필요한 컨텍스트를 불러오는 일을 아주 잘하게 되면서, 검증과 코드 리뷰를 각각 별도의 스킬로 옮겨 선택적으로 호출하는 것이 가능합니다. 이걸 글에서는 점진적 공개(progressive disclosure)라고 말하고 있습니다. 이 점진적 공개는 스킬 뿐만 아니라 tools에도 사용할 수 있습니다. 그리고 CLAUDE.md와 Skill.md에도 적용할 수 있다고 말합니다.

 

정리하자면 CLAUDE.md는 가볍게 유지하라고 권합니다. 예를 들어 검증 방법에 대한 지시가 여러 개 쌓여 있다면, 그걸 검증 스킬로 빼고 CLAUDE.md에서는 참조만 하는 식으로 앞서 말한 점진적 공개 (progressive disclosure) 를 적용하는 것이죠.

스킬은 필요할 때 정보를 찾아가게 해 주는 가벼운 안내서 정도로 생각하라고 합니다. 정말 중요한 영역이 아니라면 지나치게 제약하지 말고, 길어진 스킬은 여러 파일로 쪼개는 편이 낫습니다.

참조 자원은 @ 멘션으로 붙이는데, 가능하면 코드 형태의 파일을 우선하라고 권합니다. Claude가 아주 잘 아는 언어로 명확한 지시를 주는 셈이기 때문입니다. 실제로 디자인을 설명한 문장이나 스크린샷보다 HTML 목업 하나를 붙이는 쪽이 결과가 더 좋습니다.

이걸 일일이 확인하기 번거롭다면 Claude Code에서 /doctor를 실행해 보시는 것도 방법입니다. 이번에 claude doctor 명령이 추가되면서, 그동안 쌓인 스킬과 CLAUDE.md의 크기를 점검하고 적정 수준으로 줄이도록 안내해 줍니다. 

 

프롬프트에서 지워도 되는 것들

 

답변하기 전에 다시 검토하라거나 마지막에 검증 단계를 거치라는 문장은 삭제해도 된다고 말합니다. Opus 5는 시키지 않아도 스스로 검증하기 때문에, 한 번 더 시키면 이미 한 일을 반복하게 되어 시간과 비용만 늘어납니다. 

그리고 흔한 오해가 effort로 답변 길이를 조절할 수 있다는 생각인데요. effort는 모델이 생각하는 양을 조절하는 값이지 말하는 양을 조절하는 값이 아닙니다. 짧은 답을 받고 싶다면 짧게 쓰라고 따로 지시해야 합니다. 시스템 프롬프트가 길다면 맨 끝에 출력을 간결하게 유지하라는 한 줄을 더 넣어 주는 것도 방법입니다.

하위 에이전트도 해당됩니다. Opus 5는 이전 모델보다 위임을 훨씬 적극적으로 한다고 합니다. 규모가 큰 작업에서는 효과적이지만 작은 작업에까지 적용되면 비용과 시간만 늘어납니다. 여러 파일에 걸친 광범위한 조사처럼 독립적이고 병렬 처리가 가능한 작업에만 위임하고, 도구 호출 몇 번으로 끝낼 일은 직접 하라고 지정해 두라고 권하고 있네요.

 

---

마무리

내용이 틀린 부분이 있다면 편하게 피드백 부탁드립니다.

그리고, 가능하다면 원문을 보시는 것을 추천드립니다!

 

- https://www.anthropic.com/news/claude-opus-5

- https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models

 

긴 글 읽어주셔서 감사합니다.