짧은 질문을 많이·싸게 던지고 싶다 → Sonnet(중간 티어)이나 생각 깊이를 낮춘 설정부터.
결과물의 "취향·완성도"가 최우선 → Fable 5(더 비싼 상위 모델).
공격용 해킹·초고위험 보안 연구 → Opus 5가 아니라 특화 모델 쪽(글 11장).
상황
지금 고를 것
이유 (짧은 버전)
여러 단계 코딩·터미널 작업을 오래 돌릴 때
Opus 5
코딩을 끝까지 해내는 시험에서 잘 나옴. 스스로 확인하고 고친다는 쪽 강조
문서·표·업무 정리 같은 지식 작업
Opus 5
업무·지식 작업 시험에서 상위권 (공식 성적표)
Opus 4.8 사용자, 단가 인상 걱정
Opus 5로 이전 검토
요금 단가는 4.8과 같음. Claude Max면 기본 모델이 이쪽으로 바뀜
최고 난도·"결과물 취향"이 중요
Fable 5
회사도 "Fable을 이겼다"가 아니라 "거의 가깝다"고 함. 취향 면에서는 Fable 이야기가 많음
짧은 요청을 많이, 돈 아끼고 싶을 때
Sonnet 5 또는 effort 하향
단가가 같아도 작업 1건 총비용이 커질 수 있음 (실제 후기 있음)
사람이 화면 앞에서 기다리는 반복 수정
Opus 5 + Fast mode 검토
대략 2.5배 속도, 가격은 2배. API 쪽에서 쓰는 옵션
공격용 해킹 도구·고위험 보안 연구
Mythos 5 (해당 시)
취약점 찾기는 되지만, 공격 코드 쪽은 일부러 약하게 둔 편
예전에 만들어 둔 스킬·자동화 도구를 많이 쓸 때
전면 전환 전 한 갈래만 시험
안 맞는다는 후기 있음. "마지막에 검증해" 같은 옛 지시도 빼 볼 것
2. 뭐가 나왔나, 스펙부터
공식 발표의 첫 문장을 보면, 이 모델이 어떤 포지션을 목표로 했는지 이해가 된다.
Claude Opus 5 is available today. It's a thoughtful and proactive model that comes close to the frontier intelligence of Claude Fable 5 at half the price. (Claude Opus 5가 오늘부터 쓸 수 있다. 신중하고 능동적인 모델이며, Claude Fable 5의 프론티어급 지능에 근접하면서 가격은 절반이다.)
최상위는 여전히 Fable 5에 두고, Opus 5는 "그 근처까지 가는데 값은 절반"이라는 자리를 잡은 셈이다.
가격표 기준으로 실제 절반이 맞으니 과장은 아니다. 그렇다고 지능 자체가 Fable 5를 넘었다는 말도 아니다. 같은 페이지에 자기 한정도 같이 적혀 있다.
Anthropic은 Opus 5를 새로운 SOTA라고 하면서도, 사이버보안 과제에서는 Mythos 5보다 뒤처진다고 못을 박았다.
제조사가 자기 모델의 약점을 발표문에 직접 적는 경우는 흔치 않아서, 이 부분도 눈에 밟힙니다.
성능이 못 미쳐서라기보다 정책적 선택에 가깝다. 자세한 내용은 나중에(11번 섹션) 다룬다.
2.1 API로 보는 기본 스펙
문서에 적힌 기본 정보를 표로 보면 이렇다.
항목
값
모델 ID
claude-opus-5
컨텍스트 윈도우
1M 토큰 (기본값이자 최댓값, 더 작은 변형 없음)
최대 출력 토큰
128k
thinking
기본 켜짐
effort 기본값
high (Claude API·Claude Code 기준)
기본 가격
입력 100만 토큰당 5달러 / 출력 25달러
Fast mode 가격
입력 10달러 / 출력 50달러
배포 상태
Active, 은퇴 예정일 2027-07-24 이전 아님
여기서 컨텍스트 줄이 의외로 중요하다.
"1M이 기본값이자 최댓값이고 더 작은 변형이 없다"를 뒤집으면, 컨텍스트를 줄여서 단가를 아끼는 선택지가 없다.
개인적으로 목적에 따라 20만 토큰짜리 컨텍스트 모델을 일부러 골라 쓸 때도 있었다.
Context Window 크기가 크다고 좋기만 한 건 아닌 것 같았기 떄문이다. 이젠 좀더 clear, compact를 의도적으로 잘 활용 해야겠다.
2.2 요금제별
공식 계정이 정리한 내용을 보면 단순하다.
모든 유료 플랜과 API에서 쓸 수 있고, Claude Max에서는 기본 모델, Claude Pro에서는 고를 수 있는 가장 강한 옵션이다.
2.3 같이 나온 베타 기능 둘
모델 이야기와 별개로, API 쪽에 기능 두 개가 베타로 붙었다.
대화 중간에 도구 바꾸기 대화 턴 사이에 도구를 추가하거나 제거하면서도 프롬프트 캐시를 유지한다.
지금까지는 도구 목록을 바꾸면 캐시가 통째로 무효화돼 앞부분을 다시 계산해야 했다.
도구를 상황에 따라 갈아 끼우는 에이전트라면 비용 구조가 바뀔 수 있는 변화다.
막히면 다른 모델로 넘기기 fallbacks 파라미터에 "default" 모드가 생겼다.
거부 카테고리별로 Anthropic이 권장하는 대체 모델을 자동 적용하는 방식이라, 직접 관리하던 대체 모델 목록을 유지보수하지 않아도 된다.
두 기능 모두 "모델이 똑똑해졌다"와는 결이 다르다.
에이전트를 오래 돌려본 쪽이 실제로 아팠던 지점 — 캐시 무효화와 거부 처리 — 을 손본 셈이다.
개인이 채팅으로 쓸 때보다, 자동화를 굴리는 쪽에서 먼저 와닿을 변화다.
여담 — 모델을 바꾸면 파이프라인도 손봐야 한다. 이 부분을 정리하면서 저도 한 가지 확인하게 됐다.
이전 모델에 맞춰 촘촘하게 다듬어 둔 자동화 틀이, 더 좋은 모델에서 오히려 발목을 잡을 수 있다는 점 이.
예전 모델이 잘 못하던 걸 대신해 주려고 넣어 둔 장치들이 새 모델에서는 중복이 되기도 한다는 것 같다.
이젠 새 모델로 갈아탈 때 에는, 그 위에 얹어 둔 루프와 파이프라인도 같이 점검하는게 좋지 않을까?
3. 가격·역할로 모델 비교
먼저 가격표부터 살펴보자.
주요 모델의 입력·출력 단가와 회사가 붙인 역할만 담았고, 성능 점수는 다음 장(4장)에서 따로 다루려 한다.
단가만 놓고 보면 Opus 5는 입력이 GPT-5.6 Sol과 같고, 출력은 오히려 5달러 싸다.
그런데 뒤에서 볼 실비 비교는 정반대로 나온 결과도 공유 되고 있다.
단가표에는 토큰당 가격만 나와 있고, 그 일을 끝내는 데 토큰을 몇 개나 쓰는지는 안 나오기 때문이다.
3.1 Anthropic 라인업 전체 가격
Opus 5만 놓고 보면 감이 잘 안 오니, 같은 표에 있는 나머지도 함께 보자.
모델
입력 (100만 토큰)
출력 (100만 토큰)
Opus 5 대비 입력 배율
Claude Fable 5
$10
$50
2배
Claude Opus 5
$5
$25
1배 (기준)
Claude Sonnet 5
$3
$15
0.6배
Claude Haiku 4.5
$1
$5
0.2배
Sonnet 5는 2026년 8월 31일까지 도입가 2달러/10달러가 적용된다고 되어 있다.
Fable 5의 절반이고 Sonnet 5의 1.67배다.
위 가격은 모두 2026년 7월 24~25일 기준이다. 요금 체계는 예고 없이 바뀔 수 있으니 실제 결제 전에는 공식 가격 페이지를 다시 확인한다.
4. 벤치마크
4.1 성적표, 중요한 내용만
벤치마크 표는 보다 보면 금방 눈이 피로해진다. 그래서 이 장은 표 하나에 그림 몇 장만 보고 넘어가려 한다. 시험 이름을 외울 필요는 전혀 없다.
비교 대상은 Opus 5 / 직전 Opus 4.8 / 더 비싼 Fable 5 / OpenAI GPT-5.6 Sol 네 모델이다. 출처는 Anthropic 공식 성적표(2026-07-24)다.
한 가지 전제를 깔고 봐야 한다. 이 점수들은 대부분 생각 깊이를 최대(max)로 올린 상태에서 잰 값이다. 쉽게 말해 각 모델을 최대한 오래 고민시켜 놓고 붙인 결과다.
그러니 평소 쓰던 설정에서 이 점수가 그대로 나오길 기대하면 곤란하다. 벤치마크 점수는 어디까지나 최상의 조건에서 나온 값이라고 보는 편이 안전하다.
무슨 시험?
Opus 5
4.8
Fable 5
GPT-5.6 Sol
터미널에서 끝까지 코딩 (FrontierBench)
43.3
21.1
33.8
34.4
PC 화면 보고 조작 (OSWorld)
70.6
55.7
66.1
62.6
문서·업무 산출 (GDPval, 높을수록 좋음)
1861
1593
1747
1736
업무 자동화 통과율 %
26.0
17.0
17.4
18.1
처음 보는 퍼즐 (ARC-AGI-3)
30.2
1.5
—
7.8
실제 저장소 코딩 (SWE-bench Pro)
79.2
69.2
80
64.6
긴 코딩 에이전트 (DeepSWE)
68.8
59.0
69.7
72.7
굵은 숫자 = 그 줄 1등. 출처: Anthropic 공식 성적표(Table 8.1.A). 나머지 줄(웹 검색 등)은 같은 문서에 더 있다.
표만 훑어보면 위쪽 다섯 줄(터미널·PC·문서·자동화·퍼즐)은 Opus 5가 1등이다. 아래 두 줄(저장소 코딩·긴 에이전트)은 Fable 5 또는 GPT-5.6 Sol이 위다.
"전 영역 압도"가 아니라 "오래 맡기는 쪽에 강하고, 일부 코딩은 접전"정도로 해석할 수 있지 않을까?
4.2 그림에는 비용까지 나온다
위 표에는 점수만 있다. 그런데 회사가 같이 공개한 그림을 보면 가로축이 작업당 비용이다. 개인적으로는 이 그림들이 표보다 훨씬 쓸모 있다고 느꼈다.
축이 하나 늘었을 뿐인데 질문 자체가 달라지기 때문이다. 표는 "누가 더 똑똑한가"를 묻는데, 그림은 "같은 돈을 쓰면 누가 더 잘하나"를 묻는다. 돈 내고 쓰는 입장에서는 뒤쪽이 훨씬 현실적인 질문이다.
아래 그림들, 읽는 법은 하나다 전부 같은 형식이라, 한 번만 익혀 두면 나머지는 그냥 보인다.
가로(→)는 돈이다. 오른쪽으로 갈수록 작업 하나에 돈이 더 들었다는 뜻이다.
세로(↑)는 점수다. 위로 갈수록 잘한 것이다.
그래서 왼쪽 위에 있는 선이 좋은 것이다. 싸게, 잘했다는 뜻이니까.
선 위의 점 하나하나는 생각 깊이(effort)를 한 칸씩 올려 본 결과다. 오른쪽 점일수록 더 오래 고민시킨 것이고, 그만큼 돈도 더 나갔다.
터미널 코딩 — 빨강 선이 노랑 선보다 왼쪽 위에 있다 빨강이 Opus 5, 노랑이 Fable 5다. 빨강이 계속 왼쪽 위를 지나간다는 건, 같은 점수를 더 적은 돈으로 낸다는 뜻이다.
여기서 더 재미있는 건 두 선의 오른쪽 끝이다. 빨강은 43~44%까지 올라가는데 노랑은 약 34%에서 더 못 올라가고 멈춘다. 가로축이 돈이니까, 이건 Fable 5에 돈을 더 부어도 저 위로는 안 간다는 말이 된다. 싸다는 것보다 오히려 이쪽이 더 중요한 이야기 같다.
한 가지만 덧붙이면, 이 그림은 Anthropic이 자체 기준으로 잰 값이라 앞 표의 외부 평가(33.8)와 0.1 정도 차이가 난다. 결론이 흔들릴 정도는 아니다.
IDE 코딩 — "가격은 절반"이 눈에 보이는 그림 앞 표에서 빠져 있던 CursorBench다. 표에 없다고 자료가 없는 건 아니고, 그림에는 나온다.
두 선의 꼭대기를 보면 Opus 5가 약 70.1, Fable 5가 약 70.4다. 사실상 붙어 있다. 공식 발표가 말한 "0.5% 이내"가 눈으로는 이렇게 보인다.
그러니까 차이는 위아래가 아니라 좌우에서 난다. 그 점수에 닿기까지 Opus 5는 약 $8, Fable 5는 약 $18을 쓴다. 결과물은 거의 같은데 값은 두 배인 셈이다. 이 글 앞에서 계속 나오던 "가격은 절반"이라는 말이, 결국 이 그림 한 장에 다 들어 있다.
이 한 장은 성격이 다르다 — 파는 쪽이 잰 게 아니다 앞의 두 장은 결국 Anthropic이 자기 모델을 잰 자료였다. 그래서 조금 걸러 볼 여지가 있었다. 이건 Artificial Analysis라는 외부 평가 기관이 잰 값이다.
여기서도 빨강(Opus 5)이 노랑(Fable 5)보다 왼쪽 위에 있다. 만드는 회사가 아닌 곳에서 재도 결론이 뒤집히지 않았다는 것 — 이 그림을 볼 이유는 사실상 이것 하나다.
다만 회색 선도 같이 보자. GPT-5.6 Sol인데, 비싼 구간으로 가면 빨강과 거의 겹친다. 이걸 보면 Opus 5가 이겼다고 정리하기엔 아직 이르지 않나 싶다.
4.3 표의 나머지 줄 + SNS의 "100%" 조심
앞 표에 있던 자동화·PC 조작·문서 업무 줄도 같은 형식의 그림으로 공개돼 있다. 읽는 법은 위와 똑같다. 왼쪽 위일수록 좋다.
그림을 보기 전에 하나만 짚고 넘어가려 한다. 자동화 시험을 두고 SNS에 "100% 1위"라는 말이 돌았는데, 이게 좀 헷갈리게 퍼졌다. 같은 시험 이름을 달고 있어도 말하는 범위가 서로 다르다.
한 시험, 네 가지 말
공식 문장: 같은 비용이면 통과율이 약 1.5배.
공식 성적표: 전체 통과율 Opus 5 26.0% (Fable 17.4%).
발표 페이지 고객 인용: 특정 시나리오 하나에서 "이전 모델 실패, Opus 5는 100%".
SNS: 그 100%를 벤치 전체 점수로 키워 말함.
넷 다 거짓말은 아니다. 다만 마지막 줄에서 범위가 무너진 셈이다. 이 글은 1.5배와 26%를 기준으로 쓰고, 100%는 "특정 사례 하나"로만 남겨 두려 한다.
SNS에서 벤치마크 숫자를 봤을 때 확인할 건 두 가지면 충분하다. 공식 성적표에 그 숫자가 실제로 있는가, 그리고 전체 점수인가 사례 하나인가.
업무 자동화 — 방금 말한 그 "100%" 시험이다 곡선 꼭대기가 26% 근처다. 앞 표의 26.0과 같은 값이고, SNS에 돌던 100%와는 자릿수 자체가 다르다.
26%라고 하면 낮아 보인다. 그런데 여기서 볼 건 그 숫자가 아니다. 모든 모델의 선이 다 아래쪽에 깔려 있다는 점을 봐야 한다. 원래 아무도 잘 못 푸는 어려운 시험이라는 뜻이다.
그 안에서 Opus 5 선이 같은 비용대의 다른 선들보다 위에 있다는 것 — 요점은 이쪽이다. 점수가 낮아서 나쁜 모델인 게 아니라, 시험이 원래 어려운 것이다.
PC 조작 — AI에게 마우스와 키보드를 맡기면 사람이 하듯 화면을 보고 마우스와 키보드를 움직여서 일을 끝내는 시험이다. 앞 표에 있던 70.6이 이 곡선 꼭대기 근처의 값이다.
RPA처럼 컴퓨터 조작 자체를 AI에게 맡기는 자동화를 검토 중이라면, 이 글에 실린 그림 중 이 한 장이 가장 직접적인 근거다.
사무 업무 — 여기 숫자만은 퍼센트가 아니다 문서 작성이나 표 정리 같은 사무 업무를 재는 시험이다. 주의할 게 하나 있다.
1861 같은 값은 퍼센트가 아니라 상대 점수(ELO)다. 체스 랭킹 점수를 떠올리면 쉽다. 서로 비교할 때만 의미가 있는 숫자라서, "1861점이면 만점에 얼마지?"로 읽으면 안 된다.
여기서는 누가 위에 있는지, 격차가 큰지 작은지만 보면 된다.
숫자 함정, 세 가지만 기억
표 점수 vs 그림 곡선 — 측정 주체·조건이 조금만 달라도 0.1 단위로 어긋날 수 있습니다 (예: Fable 33.8).
100% vs 26% — 사례 하나와 전체 통과율은 아예 다른 얘기다.
1861 — 퍼센트가 아니라 ELO(상대 점수)다.
4.4 이 두 숫자만 기억해도 된다
① 터미널 작업 점수 43.3 — 직전 세대가 21, Fable 5가 약 34였으니 두 배 넘게 뛴 셈이다. "가격이 더 싼 모델이 오래 돌리는 코딩에서 제일 잘한다"는 이야기라, 이번 세대에서 가장 눈에 띄는 줄이 아닐까 싶다.
② 처음 보는 퍼즐 약 30% — 종전 최고 점수가 8%대였다고 하니 격차가 크다. 시험을 만든 ARC Prize 쪽에서도 따로 점수를 공개했는데, 푸는 과정을 되돌려 본 분석이 더 화제였다. 도형이 어떻게 뒤집히는지를 직접 수식으로 적어 놓고 풀었다는 것이다 (참고: @arcprize).
ARC-AGI는 처음 보는 규칙을 스스로 알아내는 시험이다. 개인적으로 이 시험에서 마음에 드는 점이 하나 있는데, 점수만 내놓지 않고 작업당 비용까지 같이 공개한다.
덕분에 잘 푸는 것과 싸게 푸는 건 다른 문제라는 감각을 바로 얻을 수 있다. 아래 카드 두 장을 나란히 놓고 보자. 무슨 말인지 금방 보인다.
ARC-AGI-1 — 거의 다 맞힌다. 대신 공짜는 아니다 점수가 약 97.5%니 사실상 다 맞힌 수준이다.
그런데 카드 옆의 작은 숫자를 보면 문제 하나 푸는 데 약 $0.70이 들었다. 잘 푸는 것과 싸게 푸는 게 별개라는 걸 이 카드 한 장이 같이 보여 주는 셈이다.
ARC-AGI-2 — 앞 카드와 나란히 놓고 보면 무섭다 난이도가 올라간 버전이다. 점수는 97.5%에서 90.4%로 7포인트쯤 내려간다. 여기까진 그러려니 싶다.
문제는 비용이다. $0.70에서 $2.06으로 세 배 가까이 뛴다. 점수는 7% 내려가는데 비용은 200% 오른 셈이다.
정리하면 어려워질수록 점수보다 비용이 먼저, 그리고 훨씬 크게 뛴다는 이야기다. 이걸 염두에 두고 6장(가격)을 읽으면 "단가는 같은데 청구서는 왜 다르지?"가 훨씬 쉽게 이해되는 것 같다.
4장에서 가져갈 것
확실히 앞서는 쪽 — 오래 돌리는 터미널, PC 조작, 업무 문서, 자동화, 처음 보는 유형의 퍼즐.
접전·밀리는 쪽 — 일부 코딩에서 Fable 5가 아주 약간 위, DeepSWE는 GPT-5.6 Sol이 위.
표는 점수만, 그림은 점수와 비용을 같이 보여 준다. 도입을 검토 중이라면 그림 쪽이 더 쓸모 있다.
SNS에서 본 숫자는 전체 점수인지 사례 하나인지부터 확인하면 웬만한 오해는 걸러진다.
차트는 공식 발표 페이지에 더 있다. 다만 축 숫자를 하나하나 옮기는 건 이 글에서 할 일이 아니라, 4장은 여기서 마무리한다.
5. 체감으로 뭐가 나아졌나
이 장 순서 4장이 점수와 비용 이야기였다면, 5장은 회사가 말하는 실제로 나아진 점이다. 이런 순서로 간다.
① 스스로 검증·반복 → ② 효율 숫자 (비교 상대는 전부 4.8이다) → ③ 캐시가 쉬워진 것 → ④ 프롬프트에서 빼야 할 것 → ⑤ 기억에 남는 장면 넷
점수 말고 "실제로 뭐가 나아졌나"를 회사 설명 기준으로 보면 크게 네 갈래다. 스스로 확인하고 고치기, 일을 덜 헤매기, 토큰 아끼기, 특정 분야 성적. 하나씩 보자.
5.1 스스로 검증하고 반복한다
공식 발표가 이번 세대의 핵심으로 내세운 문장이 있다.
Claude Opus 5 is much stronger at verifying its work and iterating carefully until it succeeds. (Claude Opus 5는 자신의 작업을 검증하고, 성공할 때까지 신중히 반복하는 능력이 훨씬 강해졌다.)
— Anthropic 공식 발표, 2026-07-24
에이전트 코딩에서 가장 흔한 실패가 "코드를 써 놓고 그냥 넘어가는 것"이다.
실행을 안 해 보니 깨졌는지도 모르고, 그 위에 다음 작업을 쌓으면 뒤가 전부 어긋난다. 숙련된 개발자라면 당연히 한 번 실제로 돌려 보고 검증해볼텐데.
Opus 5는 그걸 시키지 않아도 알아서 하겠다는 이야기다. 다만 이 문장은 뒤에 나올 프롬프트 정리 권고(5.4절)와 묶어서 읽어야 뜻이 온전해진다. 모델이 알아서 검증한다면, 이전 모델용으로 넣어 둔 "검증하고 진행하라"는 지시는 이제 중복이 되기 때문이다.
5.2 공식 효율 지표 (비교 상대는 전부 4.8)
공식이 내놓은 효율 숫자를 표로 모았다.
표를 보기 전에 한 가지만 짚고 가자. 비교 기준 열이 전부 Opus 4.8이다.
Fable 5나 GPT-5.6 Sol 대비 효율 수치는 공개되지 않았다. 그러니까 이건 같은 회사 직전 모델보다 나아졌다는 표이지, 경쟁사를 이겼다는 표는 아니다. 이 구분을 놓치면 뒤에서 헷갈린다.
참고로 발표 페이지에는 직접 만져 볼 수 있는 데모도 두 개 있다. 풍동 시각화(Aeolus)와 세포 일러스트(Sectio) 두 가지인데, 벤치마크 숫자와는 결이 다른 "눈에 보이는 결과물" 쪽을 확인하고 싶다면 열어 볼 만하다.
5장에서 가져갈 것
스스로 검증하고 반복하는 능력이 이번 세대의 핵심이다.
효율 숫자는 전부 4.8과 비교한 값이다. 경쟁사와 비교한 게 아니다.
캐시 기준이 512로 내려온 건 성능보다 요금에 먼저 반영될 변화다.
느려졌다고 느끼면 이전 세대용 검증 지시부터 지워 보는 게 순서다.
생각 깊이는 올릴수록 좋은 게 아니다. medium이 꼭대기인 시험도 있었다.
이어지는 6장에서는 이 이야기를 가격과 토큰 쪽으로 끌고 간다.
6. 가격·고속 모드, 언제 이득인가
6.1 단가는 그대로다
Opus 5 기본 요금은 입력 100만 토큰당 5달러, 출력 25달러로 직전 Opus 4.8과 같다. 모델이 새로 나왔는데 단가가 안 올랐다. 솔직히 이게 제일 반가운 대목이다.
여기에 고속 모드(Fast mode) 옵션이 붙었다. 속도는 대략 2.5배인데 값은 정확히 2배다. 숫자만 보면 솔깃한데, 실무에서는 이야기가 조금 달라진다.
구분
입력 (100만 토큰)
출력 (100만 토큰)
속도
제공 범위
기본
$5
$25
기준
모든 유료 플랜, Claude API, 클라우드 파트너
Fast mode
$10
$50
약 2.5배
Claude API 전용 (리서치 프리뷰), Claude Code는 extra usage 소모
계산만 보면 나쁘지 않다. 속도 2.5배에 값은 2배니까 "시간당 단가"로 따지면 오히려 이득인데, 대부분 개발 작업에서 병목은 모델 응답 속도가 아니다. 모델이 2.5배 빨라져도 내가 결과를 검토하고 다음 지시를 쓰는 시간은 그대로다. 그래서 Fast mode는 켜기 전에 한 번 더 따져 보는 게 좋다.
Fast mode는 클라우드 파트너 경로에서 못 쓴다 문서에 적힌 제약이다. Fast mode는 Claude API에서만 제공되고, Amazon Bedrock·Google Cloud·Microsoft Foundry에서는 현재 지원되지 않는다. 사내 규정 때문에 클라우드 마켓플레이스 경유로만 모델을 쓰는 조직이라면, 이 옵션 자체가 선택지에서 빠진다.
이전에 Opus 4.8로 만들었던 프로젝트를 같은 extra effort 설정으로 다시 만들어 봤더니 토큰은 약 50%만 썼고, Fast mode에서 약 3배 빨랐으며 결과물도 눈에 띄게 나았다는 기록이다.
두 반응이 충돌한다기보다 작업 유형이 다른 쪽에 가깝다.
대화형으로 붙어 앉아 반복 수정하는 작업이면 속도가 돈값을 하고, 돌려 놓고 나중에 확인하는 작업이라면 2배 요금은 그냥 손해다.
결국 "내 작업이 어느 쪽인가"에 답이 달려 있다.
6.3 토큰 단가와 작업 1건 총비용은 다르다
가격 이야기에서 제일 헷갈리는 지점이 여기다.
단가표에 적힌 건 토큰당 가격이고, 실제로 결제되는 건 작업 하나를 끝낼 때까지 쓴 총액이다.
한 사용자가 이 지점을 정확히 짚었다. 토큰당 가격이 같아도, Opus 5가 좋은 결과를 내겠다고 더 오래 생각하면 출력이 늘어난다.
그러면 단가가 같은 게 무슨 의미냐는 지적이었다.
실제 측정치를 보니 괜한 걱정이 아니었다. 숫자만 추리면 아래 표다.
모델
동일 테스트 실비
Opus 5 대비
완료 상태
Claude Opus 5
$20.07
1배 (기준)
유일하게 완전히 완료
GPT-5.6 Sol
$3.27
약 0.16배
완전 완료 아님
K3
$1.33
약 0.07배
완전 완료 아님
같은 테스트에서 Opus 5가 약 15배 비쌌지만, 끝까지 마친 것은 Opus 5뿐이었다는 기록이다 (참고: @melvynx 실비 비교, 2026-07-25). 이 표는 어느 쪽에 무게를 두느냐에 따라 결론이 달라진다.
15배를 보면 비싸고, "유일하게 완료"를 보면 나머지는 비용이 0에 수렴해도 쓸모가 없는 셈이다. 개인적으로는 후자부터 보는 편이다.
단가표만 보고 예산을 잡으면 어긋난다 입력 단가는 GPT-5.6 Sol과 같고, 출력은 오히려 5달러 싸다.
그런데 실측 총액은 6배 이상 벌어졌다.
차이는 전부 소비 토큰량에서 나온다.
도입을 검토 중이라면 단가 비교표를 만들기 전에, 대표 작업 하나를 양쪽에서 실제로 돌려 총액을 재 보는 편이 훨씬 정확하다.
반대 방향의 목소리도 있다 GPT-5.6 Sol의 max 설정이 Opus 5의 high보다 훨씬 똑똑하면서도 Opus 5의 max보다 저렴하다는 반론이 나왔다.
설정 조합에 따라 비교 결과가 뒤집힌다.
effort 레벨을 고정하지 않은 비교는 서로 다른 것을 재고 있을 가능성이 높다.
같은 표라도 손잡이 위치를 맞추지 않으면 비교 자체가 성립하지 않는다.
여기 적힌 가격은 2026년 7월 24~25일 기준이다. 커뮤니티 실비 수치는 개인이 자기 환경에서 측정한 값이라, 다른 환경에서 그대로 재현된다는 보장은 없다. 최신 요금은 공식 가격 페이지에서 확인한다.
6.4 토큰은 덜 쓰나? 청구서와 구독 한도는 별개
여기까지 읽으면 솔직히 헷갈릴 수 있다. 앞에서는 "실비가 15배 나왔다"는 사례를 봤고, 공식은 "토큰 26% 절감"이라고 하며, 커뮤니티에는 "토큰을 절반만 썼다"는 후기도 있다. 전부 맞는 말일 수 있다. 재는 대상이 다를 뿐이다. 표로 나눠 보면 바로 보인다.
누가 무엇을 쟀나
결과
비교 대상
공식 — 같은 성능을 낼 때 생성 토큰
평균 26% 감소
Opus 4.8 (같은 회사 직전 모델)
사용자 — 같은 프로젝트 재구현
토큰 약 50%만 사용
Opus 4.8 (같은 작업, 같은 설정)
사용자 — 같은 테스트 실비
$20.07 (약 15배)
다른 회사 모델 (GPT-5.6 Sol, K3)
차이가 보인다. Opus 4.8과 비교하면 토큰이 줄고, 다른 회사 모델과 비교하면 늘어난다. 앞 세대보다 효율적이라는 것과 경쟁사보다 저렴하다는 것은 다른 얘기인데, 공식이 말한 건 앞쪽뿐이다. 이 구분만 잡으면 6.4절 이야기는 거의 끝난 셈이다.
구독 한도 쪽에서는 체감이 뚜렷했다는 후기 Max 플랜을 두 개 쓰며 월 400달러를 낸다는 사용자가 이렇게 적었다. "하루 종일 돌렸는데 한도 근처에도 못 갔다. 몇 주 만에 처음으로 이 돈이 합리적으로 느껴진다." (참고: @matthewmillerai, 2026-07-24)
API로 쓰면 15배가 나온 그 모델이, 구독으로 쓰면 한도가 남아돈다. 모순처럼 보이지만 같은 일을 다른 자로 재고 있을 뿐이다. 참고로 이 사용자는 같은 글에서 속도와 완성도에 대해서는 불만을 적었는데, 그 대목은 12.1절에서 따로 본다.
초보자를 위한 정리 — 두 개의 지갑 토큰 이야기가 어렵게 느껴진다면, 지갑이 두 개라고 생각하면 쉽다.
· 구독(Max/Pro) 지갑 — 월정액을 내고 정해진 한도만큼 쓴다. 여기서 "토큰을 덜 먹는다"는 곧 더 오래 쓸 수 있다는 뜻이다. 위 후기가 이 경우다.
· API 지갑 — 쓴 만큼 청구된다. 여기서는 토큰 소비량이 곧 돈이니, 다른 회사 모델과 총액을 비교하는 게 의미가 있다. 6.3절의 15배 사례가 이 경우다.
같은 "토큰" 이야기라도, 어느 지갑을 말하는 후기인지 확인하고 읽으면 모순이 사라진다. 개인적으로는 이 구분부터 보는 편이다.
6.5 같은 주, 정반대 증언이 나온 이유
여기서 재미있는 일이 벌어집니다. 출시 다음 날 레딧을 살펴보면 정반대 제목의 글 두 개가 동시에 올라와 있거든요.
① "Opus 5 토큰 사용량 놀랍다" (추천 292개) "리셋 전에 남은 10%를 일부러 다 쓰려고 하는 중인데, 토큰 카운터가 거의 안 움직이는 느낌이다. 같은 작업을 Fable로 했을 때는 Max x20 사용량이 상당히 깎였다." 3시간 뒤 덧붙인 말이 더 재밌다. "업데이트: 95%. 낭비 없이 딱 결승선에 미끄러져 들어가겠네." (참고: r/ClaudeAI, u/Meme_Theory, 2026-07-25)
② "Opus 5가 5시간 한도를 10배 빨리 태운다" "몇 달째 같은 유형의 프로젝트를 하고 있어서 평소 사용량이 얼마나 빨리 닳는지 기준이 잡혀 있다. Opus 4.8로는 보통 6시간에 한도에 닿았다. Opus 5로 바꾸고 나서는 2시간이 안 돼서 닿았다. 워크플로도 프롬프트도 프로젝트 복잡도도 바뀐 게 없다." (참고: r/ClaudeCode, u/Automatic-Rise1221, 2026-07-25)
같은 모델, 같은 주, 정반대 결론이다. 둘 중 하나가 거짓말을 하는 걸까? 그럴 필요 없다. 같은 스레드 안에 반대 경험도 달렸다. 두 번째 글 밑에는 "저는 멀쩡한데요. Max 20x로 Opus 5 max 걸고 한 시간 돌렸는데 4%밖에 안 썼습니다"라는 댓글이 붙었다. 이런 엇갈림이 오히려 흥미롭다.
6.6 논쟁을 정리해 주는 숫자 하나
후기는 계속 엇갈렸는데, 한 사용자가 직접 API로 재 본 수치를 올리면서 그림이 선명해졌다. 같은 작업을 두 모델 × 세 가지 생각 깊이로 돌린 기록이다. 숫자만 추리면 아래 표다.
모델 · 생각 깊이
걸린 시간
출력 토큰
비용
Opus 5 · low
163.7초
16,527
$0.415
Opus 5 · medium
311.1초
32,000 (상한)
$0.802
Opus 5 · high
325.7초
32,000 (상한)
$0.802
Opus 4.8 · low
91.9초
8,338
$0.210
Opus 4.8 · medium
199.5초
17,545
$0.441
Opus 4.8 · high
225.5초
19,287
$0.484
표가 복잡해 보이지만 볼 곳은 두 군데다. 아래 두 박스로 나눠 읽으면 된다.
첫째 — 같은 눈금에서 Opus 5는 약 2배를 쓴다 low끼리 비교하면 16,527 대 8,338. 딱 2배다. 생각 깊이 손잡이를 같은 자리에 놔도 Opus 5는 더 오래 생각하고 더 많이 쓴다. 6.5절의 "10배 빨리 탄다"는 후기가 나온 이유가 여기 있다. 모델만 갈아 끼우고 설정을 그대로 뒀다면, 청구서는 올라간다.
둘째 — 그런데 여기가 진짜 실용적인 발견이다 Opus 5의 low(16,527토큰 · $0.415)와 Opus 4.8의 high(19,287토큰 · $0.484)를 나란히 보자. 거의 같은 자리다. 오히려 Opus 5 쪽이 조금 싸다.
작성자 결론이 명쾌하다. "그러니까 — 한 단계 낮춰라(drop a notch)."
바꿔 말하면 이전에 high로 쓰던 작업은 Opus 5에서 low로 내려도 비슷한 값이 나온다. 모델이 좋아진 만큼 손잡이를 낮출 여유가 생긴 게 아닐까 싶다.
이 숫자를 과신하지 말 것 (작성자 본인의 단서) 글쓴이가 직접 붙여 둔 조건이다. "단서: n=1이고, 작업 유형 하나뿐이며, 결과물 품질은 아직 채점하지 않았다."
한 번씩만 돌린 결과다. 방향을 잡는 데는 충분하지만 직원은 아니다. 또 하나 — medium과 high가 똑같이 32,000에서 멈춘 건 글쓴이가 걸어 둔 상한에 부딪힌 것이라, 실제로는 더 쓰려 했다는 의미다. 저 두 줄의 비용은 바닥값으로 봐야 한다.
이 표는 이 글 10.4절 생각 깊이 조정 가이드와 바로 이어진다. "느리다"고 느낄 때 가장 먼저 해 볼 일이 왜 effort 한 단계 낮추기인지 — 숫자로 보여 주는 근거다. 가격 이야기에서 챙길 건 여기까지다.
7. 새로 생긴 기능 셋 (도구 바꾸기·대체 넘기기·생각 깊이)
채팅 앱만 쓰면 이 장은 건너뛰어도 됩니다 여기서 다루는 건 주로 API·자동화 에이전트 쪽 변화다. Claude 웹/앱에서 대화만 한다면 다음 장(8. 어디서 쓸 수 있나)으로 넘어가도 된다. 개발 중이라면 7.3 생각 깊이 제약(400 에러)만은 눈여겨볼 만하다.
7.1 대화 중 도구 교체
에이전트를 운영해 봤다면 알 만한 문제다. 도구 목록을 한 번 바꾸면 프롬프트 캐시가 통째로 날아간다. 도구 정의는 프롬프트 앞쪽에 놓이기 때문에, 뒤에 아무리 긴 대화가 쌓여 있어도 앞이 바뀌면 전부 다시 계산된다. 돈도 시간도 같이 늘어난다.
Opus 5부터는 대화 턴 사이에 도구를 추가·제거하면서도 프롬프트 캐시를 유지할 수 있다. 베타 기능이라 요청에 베타 헤더를 넣어야 한다. 헤더 값은 아래 두 줄이다.
# 공식 문서에 표기된 베타 헤더 값
mid-conversation-tool-changes-2026-07-01 # 대화 중 도구 변경
server-side-fallback-2026-07-01 # fallbacks "default" 모드
두 값은 공식 문서에 적힌 그대로다. 헤더 키 이름과 요청 본문 형식까지는 이 글에서 확인하지 않았으니, 실제 연동 때는 공식 이전 가이드 예제를 그대로 따르는 편이 안전하다.
7.2 자동 폴백
fallbacks 파라미터에 "default" 모드가 추가됐다. 이전에는 거부 상황에 대비해 대체 모델 목록을 직접 관리해야 했는데, 이제는 거부 카테고리별로 Anthropic이 권장하는 대체 모델이 자동 적용된다. 운영 입장에서는 손이 줄어드는 변화다.
한국 커뮤니티에서 이 기능이 먼저 체감됐다 루리웹 뉴스 게시판에 "페이블로 돌리고 있던 프로젝트가 강제로 opus로 바뀌어서 뭐지 했는데 납득"이라는 댓글이 올라왔다. 사용자가 모델을 바꾸지 않았는데 라우팅이 바뀌는 경험은 낯설다. 자동 라우팅을 켤 때는 로그에 실제 사용 모델을 남겨 두는 편이 낫다. 어느 요청이 어느 모델로 갔는지 모르면 비용 분석도, 품질 회귀 추적도 어려워진다.
7.3 생각 깊이(effort), 조용히 깨지는 조합
생각 깊이(effort)는 low → medium → high → xhigh → max 다섯 단계, 기본값은 high다. 회사 권고는 단순하다. 기본값에서 시작해, 품질이 유지되는 선까지 내려 보고, 정말 어려운 일에만 올린다. 6장에서 본 "한 단계 낮춰라"와 같은 방향이다.
문제는 여기다. Opus 4.8에는 없던 제약이 하나 생겼다.
thinking을 끈 채 effort를 xhigh·max로 두면 400 에러가 난다 thinking은 여전히 끌 수 있다. 단 effort가 high 이하일 때만이다. thinking: {type: "disabled"}와 effort xhigh 또는 max를 함께 보내면 400이 반환된다. Opus 4.8에는 없던 조합 제약이라, 두 값을 설정 파일에서 따로 관리하는 코드라면 조용히 깨질 수 있다.
effort: low | medium | high | xhigh | max # 기본값 high
thinking: {type: "disabled"} # effort high 이하에서만 허용
# 생각 깊이 xhigh 또는 max와 함께 보내면 400
위 조합은 옮길 때 가장 먼저 확인해야 한다. 특히 "속도를 위해 thinking을 끄고, 품질을 위해 effort를 올린다"는 식의 설정은 이제 안 된다.
7.4 빠진 기능 두 가지
Opus 5는 Opus 4.8이 지원하던 기능 대부분을 그대로 지원한다. 1M 컨텍스트, 128k 출력, adaptive thinking, 프롬프트 캐싱, 배치 처리, Files API, PDF, vision, tools — 전부 포함된다. 예외가 둘 있다. 표로 보면 이렇다.
항목
Opus 4.8
Opus 5
영향
web fetch
지원
미지원
모델이 직접 URL을 받아오던 흐름은 외부 도구로 대체해야 한다
Priority Tier
지원
미지원
처리 우선순위를 돈으로 사던 경로가 없다
Fast mode
해당 없음
Claude API 전용
클라우드 파트너 경로에서는 사용 불가
최소 캐시 길이
1,024 토큰
512 토큰
짧은 프롬프트도 캐시 대상이 된다
thinking 비활성 조건
제약 없음
effort high 이하에서만
설정 조합에 따라 400 발생
표의 요지는 하나다. 성능은 올라갔는데 운영 옵션은 오히려 줄었다. web fetch나 Priority Tier에 기대고 있는 자동화라면, 벤치마크 점수를 보기 전에 이 두 줄에서 먼저 걸린다. 기능 목록만 보고 그대로 옮기다가 막히는 게 대개 이 지점이다.
8. 어디서 쓸 수 있나
8.1 채널별 사용처
채널마다 접근 방법과 Fast mode 지원 여부가 갈린다. 표로 보면 이렇다.
사용 경로
Opus 5 접근 방법
Fast mode
effort 기본값
Claude Max
기본 모델이라 별도 조작 없음
확인하지 못함
공식 표기 없음
Claude Pro
모델 선택기에서 최상위 옵션으로 선택
확인하지 못함
공식 표기 없음
Claude Code
모델 선택에서 지정
extra usage 소모로 사용 가능
high
Claude API
모델 ID claude-opus-5 지정
리서치 프리뷰로 제공
high
Amazon Bedrock · Google Cloud · Microsoft Foundry
각 플랫폼 모델 카탈로그
미지원
확인하지 못함
Fast mode 제공 조건은 공식 쪽에서 정리해 둔 글이 있다 (출처: @ClaudeDevs Fast mode 안내, 2026-07-24). Claude Platform과 Claude Code에서 extra usage를 소모하며 쓰는 구조다. 클라우드 파트너 경로에서는 못 쓴다는 점만 먼저 기억하면 된다.
claude.ai의 effort 기본값은 공식 표기에서 빠졌다 Opus 4.8은 Claude API, Claude Code, claude.ai 모든 표면에서 effort 기본값이 high였다. Opus 5는 공식 비교표에 Claude API와 Claude Code만 적혀 있고, claude.ai는 언급되지 않는다. 웹에서 쓸 때 어떤 effort가 적용되는지는 이 문서만으로 확정할 수 없다. API 결과와 웹 결과가 다르게 느껴진다면 이 차이부터 의심해 보면 된다.
8.2 은퇴 일정, 언제까지 옮겨야 하나
모델을 도입할 때 같이 볼 것이 은퇴 일정이다.
문서에 적힌 상태를 추리면 아래와 같다. 당장 손이 가야 하는 건 맨 아래 Deprecated 한 줄이다.
Opus 4.1을 아직 쓰고 있다면 시간이 얼마 없다 Claude Opus 4.1은 2026년 8월 5일에 은퇴한다. 이 글을 쓰는 시점 기준으로 2주 남짓이다. 문서는 은퇴 전에 Opus 5로 옮기라고 안내한다. 코드에 모델 ID를 하드코딩해 둔 프로젝트가 있다면 지금 확인하는 편이 낫다.
가장 빨리 써 보는 경로 Claude Max 구독자라면 이미 기본 모델이 Opus 5라 아무 대화나 열면 그게 Opus 5다. Pro라면 모델 선택기에서 최상위 옵션을 고른다. API로 확인하고 싶다면 기존 요청의 모델 ID만 claude-opus-5로 바꿔서 한 번 보내 보면 된다. 다만 프롬프트에 검증 지시가 들어 있다면 그것부터 지우고 보내는 편이 결과가 정확하다.
9. 이 블로그로 직접 돌려본 기록
이 장은 이 블로그를 만드는 자동 파이프라인 로그다. (내가 조사한 context들을 기반으로 초안을 작성하는데, 기존 model에 최적화 해두어서 그런지 이번 모델에서는 토큰 사용량이 꽤 증가 한 것 같았다.)
시간이 없으면 아래 초록 박스 한 줄만 읽고 10장으로 넘어가도 된다.
초보용 한 줄 공식이 말한 "토큰 26% 절감"을 그대로 믿고 요금을 계산하면 어긋난다. 캐시를 많이 쓰는 구조라면 절감 폭이 훨씬 작아지기 때문이다.
아래 로그가 그런 경우다. (26%가 무엇에 대한 26%인지는 6.4절에서 정리했다.)
이 글에서 내 얘기를 할 수 있는 부분은 여기뿐이다. 제품 후기가 아니라, 블로그 글을 뽑아내는 자동화를 Opus 5로 돌리면서 쌓인 운영 기록이다. 그래서 숫자도 포장 없이 적었다.
9.1 뭘 재고 있나
이 블로그 글의 초안은 직접 만든 자동화로 뽑는다.
리서치, 초안 작성, 평가, HTML 변환을 서브에이전트가 하나씩 나눠 맡고, 단계마다 토큰 사용량이 로그에 남는다.
지금 읽고 있는 이 글도 그 자동 흐름을 거쳐 나왔다.
먼저 서브에이전트를 37번 호출하면서 쓴 토큰이 어떻게 나뉘는지 보자. 거의 전부가 캐시다.
토큰 종류
비중
성격
cache_read
94.0%
이미 캐시된 프롬프트를 다시 읽는 분량
cache_creation
5.2%
캐시를 새로 만드는 분량
output
0.8%
모델이 실제로 생성한 분량
9.2 "토큰 26% 절감"을 내 로그에 넣어 보면
공식 발표 문장은 "generating 26% fewer tokens"였다.
생성 토큰, 그러니까 출력 기준이다.
그런데 이걸 내 로그에 넣어 보면 얘기가 완전히 달라진다.
계산해 보면 이렇다 내 경우 출력이 전체 토큰의 0.8%다. 그 출력이 26% 줄어 봐야 전체로 보면 0.8 × 0.26, 즉 0.2 퍼센트포인트밖에 안 줄어든다. 반면 캐시 최소 길이가 1,024에서 512로 내려간 건, 전체의 94%를 차지하는 cache_read를 건드리는 변화다. 내 구조에서는 이쪽이 요금을 훨씬 크게 좌우한다.
공식 수치를 반박하려는 건 아니다. 26%는 사실일 테고, 벤치마크 조건에서는 그렇게 나왔을 것이다. 다만 그 문구를 내 작업에 그대로 옮겨 놓으면 기대가 어긋난다. 결국 얼마나 아끼느냐는 내 토큰이 어떻게 구성돼 있느냐에 달렸다. 공식 수치보다 이게 훨씬 중요하다.
다만 이 수치를 일반화하면 안 된다 cache_read 94%는 어디까지나 내 자동화의 특성이다. 같은 지시 파일과 기준 문서를 서브에이전트마다 반복해서 읽히다 보니 캐시 재사용률이 극단적으로 높다. 채팅으로 짧게 주고받거나 긴 글을 뽑아내는 작업이라면 비중이 전혀 다르게 나온다.
결국 확인할 방법은 하나다. 자기 로그를 직접 집계해 보는 것.
9.3 단계별 토큰 분포
단계별 median 토큰은 아래와 같다. 실행 로그 13건을 모아 낸 값이라(2026-07-25 기준, 단계별 표본 8~9건) 이 글 한 편의 수치는 아니다. 실행이 쌓이면 조금씩 달라지는데, 어디가 비싼지는 분명하게 보인다.
단계
median 토큰
하는 일
writer
248,365
초안 작성
publisher
149,326
HTML 변환
evaluator
147,058
품질 검증
researcher
120,365
근거 수집
초안 쓰는 단계가 자료 모으는 단계의 2배를 먹는다. 자료 조사가 제일 비쌀 줄 알았는데 아니었다. 이유는 단순하다. writer는 스타일 기준 문서, 스키마, 근거 파일, 참고 예시를 전부 올려 둔 채로 긴 글을 써야 한다. 읽을 게 많은 단계가 비싼 단계인 셈이다.
9.4 컨텍스트를 줄여 봤다
그래서 이번에는 참고용 예시 글을 원본 HTML 대신 축약본으로 바꿔 넣어 봤다. 구조와 콜아웃 빈도, 말투만 남기고 인라인 CSS와 본문은 걷어낸 형태다. 결과는 숫자로 보는 게 빠르겠다.
항목
크기
비고
원본 참고 HTML
96,114 바이트
인라인 CSS와 본문 전문 포함
축약본
4,806 바이트
구조·콜아웃 분포·말투 대표 문장만
감소율
95.0%
결정론 스크립트로 변환, 검증 완료
모델을 바꾸는 것보다 컨텍스트를 줄이는 게 빠를 때가 있다 96KB를 5KB로 줄이면, 그 차이가 첫 호출로 끝나지 않고 이후 모든 턴의 cache_read에 계속 따라붙는다. 서브에이전트 토큰의 94%가 cache_read인 구조라면 여기가 지렛대다. "26% 적은 토큰"을 기다리느니 컨텍스트에 올리는 파일부터 줄이는 게 확실하다.
여기 수치는 전부 내 내부 로그에서 나온 값이라 남이 재현할 수 없다. 그래서 결론으로 내세우지 않고 "이런 구조에서는 이렇게 나오더라" 정도의 사례로만 남겨 둔다. 다만 공식 발표의 효율 주장을 자기 환경에 맞춰 따져 보는 방식 자체는 그대로 쓸 수 있다. 자기 로그를 열어 보는 게 그 시작이다.
10. 써 볼 만한 사례와 프롬프트
공식이 밀어 올린 강점은 두 가지다. 스스로 검증하고 반복하는 능력, 그리고 여러 단계를 알아서 밟는 에이전트 작업. 커뮤니티 성공 사례를 훑어봐도 묘하게 그 근처에 몰려 있다.
10.1 커뮤니티에서 반복된 패턴 셋
버그 일괄 탐지 한 사용자는 테스트 프로젝트 버그 22개를 Opus 5가 한 패스로 전부 찾아냈다고 적었다. Opus 4.8과 같은 가격인데 코딩에서는 Fable 5를 앞선다는 평가도 덧붙였다 (참고: @joenjenga_ 실사용 후기, 2026-07-24).
기존 작업 재구현으로 세대 비교 Opus 4.8로 만들었던 프로젝트를 같은 extra effort 설정으로 다시 만들어, 토큰 사용량과 소요 시간을 직접 비교한 사례다. 토큰 약 50%, Fast mode에서 약 3배 속도, 결과물 품질 개선 — 세 가지를 한 번에 확인했다 (참고: @vinopaljiri 재구현 비교, 2026-07-25).
다른 모델이 놓친 이슈 찾기 모바일 앱 디버깅에서 Fable 5와 Opus 4.8이 못 찾은 문제를 Opus 5가 잡아냈다는 후기가 있다. 다만 같은 글에서 "최신 Claude 모델들은 지금 너무 느리다"는 불만도 같이 적었다. 한 후기 안에서 장단이 갈리는, 흔히 보이는 형태다.
셋을 겹쳐 보면 결이 비슷하다. 한 번에 끝나는 질문이 아니라 여러 단계를 스스로 돌아야 하는 작업이다. (반대로 "프롬프트 한 방"으로 던졌을 때 어땠는지는 12.1절에 따로 모았다.) 검증·반복이 강해졌다는 공식 이야기와 실사용 후기가 여기서 만난다. 한 문장 답변이나 짧은 코드 조각에서는 이 강점이 드러날 자리가 없다.
10.2 세대 비교용 프롬프트
새 모델이 나올 때마다 벤치만 읽기보다, 자기 작업으로 한 번 재 보는 편이 빠르다. 위 두 번째 사례 방법을 그대로 따라 하면 된다.
[이전 세대에서 만들었던 작업 설명을 그대로 붙여넣는다]
위 작업을 처음부터 다시 수행한다.
- effort 설정은 이전과 동일하게 둔다
- 완료 후 다음을 보고한다: 사용한 총 토큰, 소요 시간, 수정한 파일 수
이 프롬프트의 목적은 품질 평가가 아니라 소비량을 재는 일이다. 같은 작업, 같은 설정, 다른 모델 — 이 조건이 맞아야 비교가 된다. 품질은 결과물만 보면 되지만, 토큰과 시간은 적어두지 않으면 그냥 사라진다.
10.3 옛 프롬프트 점검하기
이전 모델용 프롬프트를 그대로 가져와 두고 "느려졌다"고 느끼는 경우가 많다. 5.4절 권고를 손으로 실행하는 방법이다. 아래 명령을 그대로 붙여 넣으면 된다.
아래는 이전 모델용으로 작성한 시스템 프롬프트다.
Opus 5는 지시 없이도 스스로 작업을 검증한다는 전제에서,
중복이 되는 검증·자기점검 지시를 찾아 목록으로 제시한다.
제거 시 위험한 항목은 따로 표시한다.
[시스템 프롬프트 전문]
명령을 돌리면 검증 관련 지시가 어디에 얼마나 쌓여 있는지 목록이 나온다. 지우기 전에 목록만 먼저 보는 이유? 검증 지시 중 일부는 모델의 자체 검증과 성격이 다른 도메인 규칙일 수 있어서다.
10.4 effort, 어느 단계로 둘까
공식 권고는 간단하다. 기본값 high로 시작해서, 품질이 유지되는 선까지 낮춰 보라는 것이다. 커뮤니티 관찰을 얹으면 표로 보면 이렇다.
작업 유형
권장 effort
근거
반복적 코드 수정, 포맷 정리
low ~ medium
한 팀이 medium·low에서 더 잘 작동했다고 보고. API 실측에서도 Opus 5 low ≈ Opus 4.8 high (6.6절)
에이전트 코딩 벤치 (FrontierCode 계열)
medium 우선 검토
공식 기술 문서: medium에서 피크 (Main 53.4%)
일반 개발 작업
high (기본값)
공식 권고 시작점
아키텍처 설계, 난도 높은 디버깅
xhigh ~ max (가장 깊게)
공식이 최고 난도 작업에 상향을 권고
thinking을 꺼야 하는 저지연 경로
high 이하
xhigh·max와 함께 쓰면 400 에러
표의 첫 줄은 공식 권고가 아니라 커뮤니티 관찰이다. 그 점만 구분해서 읽으면 된다. 공식 기술 문서 단서를 하나 더 얹으면, FrontierCode 1.1에서는 medium이 피크였다(Main 53.4% / Extended 63.6%). 코딩 에이전트 작업에서 max로 올리는 습관이 있다면, 같은 작업을 medium으로 한 번 더 재 보는 편이 비용 대비 나을 수 있다. Opus 5 불만 중 상당수가 "생각을 너무 오래 한다"인데, 솔직히 그 대부분은 effort를 낮추면 풀리는 종류다.
느리다고 느껴질 때 순서 첫째, 시스템 프롬프트에서 검증 지시를 지운다. 둘째, effort를 한 단계 낮춘다. 셋째, 그래도 느리면 Fast mode 비용을 감수할 가치가 있는 작업인지 판단한다. 순서를 지키는 이유? 세 번째부터 가면 프롬프트 문제까지 돈으로 덮게 되기 때문이다.
두 번째 단계를 그냥 넘기지 말자. 6.6절 실측을 보면 Opus 5를 low로 내려도 이전 세대 high 수준이 나왔다. 낮추는 게 손해가 아니라, 모델이 좋아진 만큼 낮춰도 되는 여유가 생긴 것에 가깝다.
11. 안전·보안, 잘된 점과 일부러 막아 둔 점
11.1 회사가 내세운 숫자 둘
지표
값
의미
전반적 misaligned behavior
2.3점
최근 모델 중 가장 낮음 (낮을수록 정렬이 잘 됨)
안전 분류기 개입 빈도
약 85% 감소 예상
Fable 5 대비
그림. Automated behavioral audit (공식 발표 페이지). 본문 수치 overall misaligned 2.3은 이 그래프 계열의 요약값이다. 축 눈금까지 이미지에서 옮겨 적지는 않았다.
참고로 공식 기술 문서에는 정렬 점수와 별도로 "답을 30번 바꿨다" 같은 복지·불확실성 트랜스크립트도 있다. 5.5절 에피소드 ③이 그 장면이다.
둘 중 실제로 손에 잡히는 건 두 번째 숫자다. 안전 필터가 끼어들면 멀쩡한 질문도 막히거나 답이 중간에 잘린다. 그게 85%쯤 줄어든다면 보안이나 취약점처럼 민감한 주제를 다룰 때 덜 헛돌게 된다.
다만 회사도 "예상"이라고 적었으니, 확정된 측정치로 읽지는 않는 게 좋겠다.
11.2 보안, 일부러 막아 둔 부분
공식 계정 서술이 꽤 분명하다. 그대로 읽어 보자.
Opus 5 is stronger than Opus 4.8 on cybersecurity tasks. But it remains substantially behind Mythos 5 at developing exploits. Its safeguards are designed to allow developers to identify and fix software vulnerabilities, while blocking high-risk uses. (사이버보안 과제에서 Opus 5는 Opus 4.8보다 강하다. 다만 익스플로잇 개발에서는 Mythos 5에 상당히 뒤처진다. 안전장치는 개발자가 소프트웨어 취약점을 찾아 고치는 것은 허용하되, 고위험 사용은 막도록 설계됐다.)
읽어 보면 층이 세 개다. Opus 4.8보다는 강하고, Mythos 5보다는 꽤 약하며, 그 약함이 안전장치 설계의 결과라는 뜻이다.
취약점을 찾고 고치는 건 허용하되, 익스플로잇 개발은 막겠다는 경계선이 분명하게 그어져 있다.
커뮤니티는 이것을 "의도적 상한"으로 읽었다 한 사용자는 이 격차가 훈련의 한계가 아니라 일부러 걸어 둔 천장이라고 해석했다.
장기 자율 생물학 연구 역시 여전히 Mythos 전용으로 라우팅된다는 관찰도 같이 적었다 (참고: @sudeepsriv 해석, 2026-07-25). 공식이 "의도적"이라는 단어를 직접 쓰지는 않았으니, 회사 문장 그대로가 아니라 사용자 쪽 해석으로 구분해 둔다.
한국어로 정리된 자료에서도 같은 구도가 보인다. 역대 가장 정렬이 잘 된 모델이라는 서술과, 생물학·공격적 사이버 영역에서는 Mythos 5에 뒤진다는 서술이 늘 한 세트처럼 붙어 다닌다.
보안 업무에 쓰려는 경우의 판단 기준 취약점 스캔, 코드 리뷰, 패치 작성은 설계상 허용 범위 안에 있다. 반면 익스플로잇 작성이나 공격 시나리오 자동화는 Opus 5에서 일부러 약하게 둔 영역이다. 이 구분을 모르고 후자를 시도하면 "모델이 못 한다"가 아니라 "모델이 안 하도록 설계됐다"를 만나게 된다. 여기서 헷갈리는 사람이 많다.
12. 사람들 반응, 좋은 말과 아쉬운 말
12장에 오면 그 엇갈림이 본격적으로 드러난다. 같은 날, 같은 모델을 두고 칭찬과 불만이 동시에 쏟아졌다. 아래는 X에서 모은 후기를 방향만 나눠 정리한 표다.
한 가지만 먼저 밝혀 두면, 아래 표는 X와 Threads에서 모은 것이라 출시 후 24~48시간 구간에 몰려 있다. 레딧·유튜브 반응은 12.1절과 12.4절에 따로 모아 뒀다. 어느 쪽이든 출시 직후의 첫인상이지 몇 주 써 본 뒤의 평가는 아니라는 점만 감안하고 보면 되겠다.
방향
반응 내용
출처 핸들 · 날짜
긍정
테스트 프로젝트 버그 22개를 한 패스로 전부 탐지
@joenjenga_ · 2026-07-24
긍정(과소비 인정)
"one-shotted" 수준으로 생산성 폭증, 하루 토큰 2B 개인 최고 기록
@TheAaryanKapoor · 2026-07-26
긍정
같은 작업 재구현에서 토큰 약 50%, Fast mode 약 3배 속도
@vinopaljiri · 2026-07-25
긍정
처음엔 실망했으나 에이전트 스택으로 쓰는 법을 익힌 뒤 daily driver로 전환
@_MaxBlade · 2026-07-25
긍정
GPT-5.6 Sol 선호 입장을 철회, 워크플로에서는 Opus 5가 앞선다고 재평가
@diogoalmeida0h · 2026-07-25
부정
출시 시점 속도가 때때로 고통스러울 만큼 느림
@matthewmillerai · 2026-07-24
부정
무언가 하기 전에 오래 생각해서 다른 모델보다 훨씬 느리게 느껴짐
@gen_z_mind · 2026-07-24
혼합(장문 리뷰)
"Flashes of brilliance, frustrating in practice" — medium/low가 덜 거슬린다는 관찰
Every vibe check · @danshipper · 2026-07-24
부정(대화 체감)
벤치는 올랐지만 대화가 "GPT 같은 티켓 응대"로 느껴진다는 장문 비판
@Dr1090a · 2026-07-26
부정
작성 품질 혹평, "Claude writing slop" 지적
@jdjohnson · 2026-07-24
부정
지시에 반박하고 작업 완료 전에 멈춤, 기존 스킬·플러그인과 충돌
@danshipper · 2026-07-24
중립
성실하지만 오래 걸리고, Fable 5가 더 많이 아는 느낌
@argofowl · 2026-07-25
중립
빠르고 싸서 좋은 것이지 더 똑똑하다는 느낌은 아님
@0xxmemo · 2026-07-25
표를 보면 이런 식으로 갈립니다. 결과물 품질을 말할 때는 칭찬이, 기다리는 시간을 말할 때는 불만이 나온다. 두 축을 섞어 놓으면 "좋다"와 "나쁘다"가 동시에 성립하니, 후기가 엇갈리는 게 아니라 서로 다른 걸 재고 있는 셈이다. 이런 엇갈림이 오히려 흥미롭다.
12.1 "프롬프트 한 방"으로 시험한 사람들
벤치 표만 보면 감이 잘 안 온다. 반면 프롬프트 하나 던져 놓고 뭐가 나오는지 보는 방식은 누구나 이해할 수 있다. 출시 직후 이런 후기가 여러 건 나왔는데, 결과가 한 방향이 아니었다는 점이 오히려 재미있다. 아래는 후기만 요약하지 않고, 실제로 쓴 프롬프트 원문을 그대로 옮긴다. 같은 조건으로 따라 해 볼 수 있게 하려는 목적이다.
따라 해보기 전에
아래 사례는 대부분 Claude Code(에이전트)에서 돌린 결과다. 웹 채팅 한 방에 게임을 기대하면 체감이 다르다.
생각 깊이(effort)는 원 후기 기준 Extra / xhigh 쪽이다. 기본 high보다 오래 돌고 토큰도 더 쓴다.
A안은 이미 있는 2D 프로젝트가, B·C안은 /assets 폴더(이미지·스프라이트 등)가 있어야 조건이 비슷해진다. 없으면 자기 작은 데모 프로젝트를 두고 같은 문장만 바꿔 쓰면 된다.
결과는 보장되지 않는다. 후기 그대로 재현되지 않아도 정상이다. 비교할 때는 모델·effort·프롬프트를 고정하자.
A. 두 줄 프롬프트로 2D 시뮬레이터를 3D로 — 레딧 원문 레딧 r/ClaudeCode 사례다. 자동차가 정해진 경로를 달리며 연료를 관리하는 2D 시뮬레이터를 3D로 바꿔 달라고, Opus 5와 Fable 5에 똑같이 한 번씩 던졌다. 원 작성자 말로는 둘 다 effort Extra였다.
따라 할 조건: 프로젝트 루트에 2D 코드가 있는 상태 → Claude Code에서 아래 영문 프롬프트를 그대로 붙여넣기 (한 번만).
영문 원문 (복붙용)
transform this project into a nice good looking 3d version. feel free to add all changes you want to make it robust and interesting. you can start making now changes non-stop
한국어 뜻 "이 프로젝트를 보기 좋은 3D 버전으로 바꿔라. 견고하고 흥미롭게 만들기 위해 원하는 변경은 마음대로 추가해도 된다. 지금부터 멈추지 말고 작업을 시작해라."
결과에 대한 글쓴이의 평. "Opus 5 결과물이 꽤 인상적이다. 마천루, 조명, 자동차, 지도 — 한 방(one shot) 작업치고는 전부 정말 괜찮아 보인다." (참고: r/ClaudeCode, u/techdrumboy, 2026-07-24. 프롬프트 원문은 게시글 본문 그대로)
B. 유튜브 리뷰어가 카메라 앞에서 잰 시간 — 44분 (Mario 데모) 글로만 보면 감이 안 오니, 실제로 화면에 띄워 놓고 기다린 기록도 보자. Tonbi's AI Garage 리뷰어가 예전에 Fable 5에 줬던 것과 같은 과제를 Opus 5에 다시 던졌다. 에셋 폴더를 건네고 횡스크롤 데모 한 스테이지를 시켰다.
따라 할 조건: 작업 폴더에 게임 에셋(스프라이트 등)이 있는 상태 → Claude Code + Opus 5 → 아래 영문을 한 번만 실행. 리뷰어 실측 소요 시간은 약 44분이었다.
영문 원문 (복붙용)
please review the assets in that folder. You are to make a side scrolling Mario like game just one level as a demo using these assets.
한국어 뜻 "그 폴더의 에셋을 검토하라. 이 에셋을 써서 마리오 같은 횡스크롤 게임을 데모용 한 스테이지만 만들어라."
결과를 보고 남긴 말. "이건 상세한 계획서가 아니다. 두 줄짜리 프롬프트인데 저걸 다 뽑아냈다." Fable 5와 비교해서는 "솔직히 Fable로 얻은 것보다 확실히 앞에 두겠다. 훨씬 완성도 있게 살이 붙은 게임이다"라고 했다. 리뷰어 표현으로는 "확실히 아주 끈질긴(persistent) 모델로 보인다." (참고: 유튜브 "First Look at Claude Opus 5", Tonbi's AI Garage, 2026-07-25, 18분 41초. 프롬프트는 자막·설명 기준으로 확인)
C. 같은 영상 두 번째 과제 — Three.js 판타지 월드 (19분) 같은 리뷰어가 이어서 빈 디렉터리 + /assets만 주고 3D 판타지 월드를 시켰다. 걸린 시간은 약 19분. 영상 설명에 프롬프트 전문이 올라와 있어, 여기도 그대로 옮긴다. A·B보다 길고 요구사항이 많다. "한 방"이 짧을 필요는 없다는 비교용으로 보면 된다.
따라 할 조건: 빈 폴더 + fantasy/game 에셋이 든 /assets → Claude Code에서 아래 전체를 한 번에 붙여넣기.
영문 원문 (복붙용)
You are in a fresh empty directory.
Create everything needed yourself. Do not assume a starter repo, existing package.json, existing components,
existing data files, or preinstalled app framework.
You may choose the stack, but the result must run locally with simple commands.
Do not ask clarifying questions. Make reasonable assumptions and ship.
Prioritize:
1. working local run
2. the core goal
3. instruction compliance
4. visual quality
5. clean handoff
At the end, return only the requested final response format.
Challenge: Three.js Fantasy World
You are in a fresh empty directory. The only supplied material is an /assets folder containing fantasy/game
assets.
Build a small explorable 3D fantasy scene using Three.js.
Core Goal
Make a tiny world that is fun to walk around for 30 seconds.
Requirements
1. Create the full project from scratch.
2. Use Three.js.
3. Load and use at least some assets from /assets.
4. Create a coherent fantasy scene with:
- ground
- lighting
- atmosphere/fog
- placed props or structures
5. Add movement controls:
- WASD + mouse/look, or
- orbit/explore controls if easier
6. Include 3 points of interest.
7. Add 1 animated element or effect.
8. Let the user click or inspect at least 1 object.
9. Include a small controls/help overlay.
10. The app must run locally with clear commands.
Avoid
- Do not make a 2D game.
- Do not make a dashboard.
- Do not use only cubes/placeholders if usable assets exist.
- Do not spend effort on menus, login, inventory, quests, or combat.
Success Criteria
A judge can run the app, move around, see a coherent fantasy scene, and tell that the provided assets were used.
Final Response
Return only:
- run command
- what you built
- assets used
- known issues
- files changed You may use what is in the assets folder
한국어 요약 빈 디렉터리에서 Three.js로 30초쯤 돌아다닐 수 있는 작은 판타지 월드를 처음부터 만든다. 지면·조명·안개·구조물, 이동 조작, 관심 지점 3곳, 애니메이션 1개, 클릭 가능한 오브젝트 1개, 조작 안내 오버레이, 로컬 실행 명령을 요구한다. 대시보드·로그인·전투 메뉴는 만들지 말 것.
(참고: 같은 영상 설명란 "3D World Prompt" 전문. 결과물 이름: The Hollow of Ember Watch)
여기서 초보자가 챙길 포인트 "두 줄 프롬프트로 게임이 나온다"에 놀라기 전에, 44분이라는 숫자를 같이 보시면 좋습니다. 채팅창에서 답이 툭 떨어지는 것과는 다른 종류의 사용법입니다.
맡겨 놓고 다른 일 하다가 돌아오는 방식이고, 그 시간 동안 모델은 계속 토큰을 씁니다. 앞의 6.6절 표에서 본 "생각을 오래 할수록 비용이 붙는다"가 실제로 벌어지는 장면이 바로 이겁니다.
따라 해 볼 때는 결과 스크린샷보다 소요 시간·토큰(또는 구독 한도 체감)·한 번에 끝났는지 세 가지만 메모해 두면 12.1 후기와 바로 대조할 수 있습니다.
"Fable은 한 방에, Opus는 한 번 더" 가장 자주 나온 관찰이다. "Fable 5처럼 한 방에 끝내지 못한다. Fable이 첫 시도에 맞히는 작업을 Opus 5는 한 번 더 돌린다" (참고: @matthewmillerai, 2026-07-24).
10.1절에서 본 "버그 22개를 한 패스에" 사례와 모순처럼 보이지만, 작업 성격이 다르다. 버그 찾기처럼 답이 정해져 있고 검증도 쉬운 작업은 한 번에 되고, 뭘 만들어 달라는 열린 작업은 한 번 더 돌아야 한다는 쪽에 가깝다.
"내가 잘못 쓰고 있었다" — 실망에서 daily driver까지 이 장에서 가장 써먹을 만한 후기일 수 있다. 처음엔 "정말 실망했다. 터무니없이 느리고 결과물도 인상적이지 않았다"고 적었던 사용자가 결론을 뒤집었는데, 그 이유가 구체적이다.
"내가 잘못 쓰고 있었다. Fable 5는 엉망인 프롬프트를 줘도 금을 뽑아 주지만, 대신 토큰을 다 태운다. Opus는 정반대다. 루프, 그래프, 리뷰어, 오케스트레이터, 그리고 병렬로 도는 에이전트를 써라." 마무리는 "Opus 5는 진짜 daily driver다"였다 (참고: @_MaxBlade, 2026-07-25).
용어가 낯설 수 있으니 짧게 풀면 — 루프는 조건이 맞을 때까지 같은 작업을 반복시키는 것, 리뷰어는 결과를 검사하는 역할을 따로 두는 것, 오케스트레이터는 그 역할들을 지휘하는 상위 역할이다. 한마디로 프롬프트 한 방에 기대지 말고, 일을 여러 역할로 쪼개서 맡기라는 조언이다.
이 후기들을 겹쳐 보면 그림이 잡힌다. Opus 5는 "한 방"으로 승부하는 모델이 아니라, "여러 번 돌리는 구조"에 넣었을 때 강한 모델이다. 공식이 내세운 검증·반복 강화와 방향이 맞고, 5.4절의 "검증 지시를 지우라"는 권고와도 맞물린다.
여기서 12.2절 혹평을 다시 읽으면 결이 조금 달라진다. Every 팀이 지적한 "지시에 반박하고 중간에 멈춘다"는 현상도, 한 방을 기대하고 던졌을 때 가장 크게 체감되는 종류이기 때문이다. 그래서 더 세게 들린다.
다만, 이 후기들을 읽을 때의 주의 전부 개인이 자기 환경에서 한두 번 돌려 본 결과다. 같은 프롬프트를 반복 실행한 것도, 조건을 통제한 것도 아니다. 방향을 참고할 근거는 되지만, "이렇게 하면 이렇게 된다"는 보장으로 읽으면 안 된다. 확인 방법은 하나뿐이다 — 10.2절 프롬프트로 자기 작업을 직접 재 보는 것이다.
12.2 제일 센 비판
Every 팀이 일주일 테스트한 뒤 남긴 평가는, 이 글에 인용한 것 중 가장 세다. 읽어 두면 좋다.
It's a poor man's Fable. It has many of Fable's personality quirks without Fable's genius. (가난한 사람의 Fable이다. Fable의 성격적 특질은 많이 갖고 있지만, Fable의 천재성은 없다.)
"Fable의 개성은 물려받았는데 천재성은 못 물려받았다"는 평가다. 같은 게시물에서 지시에 반박하고, 작업이 끝나기 전에 멈추며, Compound Engineering 같은 기존 스킬·플러그인과 잘 맞지 않았다고 구체적으로 적었다. 앞서 본 프롬프트 정리 권고를 감안하면 이 중 일부는 세대 차이에서 온 것일 수 있다. 다만 일주일을 붙들고 테스트한 팀의 결론이라, 전부 프롬프트 탓으로 넘기기는 어렵다.
작성 품질 혹평도 있었다. 한 사용자는 "Claude의 writing slop이 이 시점에서 4o 수준으로 나쁘다"고 적었다 (참고: @jdjohnson 첫인상, 2026-07-24). 코딩 성능과 글쓰기 품질이 같이 가지 않는다는 지적인데, 문서·기획 작업에 모델을 쓰는 쪽이라면 참고할 만하다.
벤치에 안 잡히는 불만: "대화가 GPT처럼 느껴진다" 하루 9시간 이상 쓰는 헤비 유저 한 명은 벤치마크는 올랐는데 사람처럼 말하는 감각이 줄었다고 길게 적었다. 입력을 티켓 확인하듯 되풀이하는 화법, 비판을 받으면 대화를 빨리 닫는 습관, 맥락 없는 "개선 계획" 나열 등을 예로 들었다. 한 줄 요약은 "Chat is not Code"였다 (참고: @Dr1090a, 2026-07-26). 코딩 에이전트 점수와 채팅 체감이 갈리는 축이라, 용도가 대화·브레인스토밍이라면 따로 재 볼 만하다.
12.3 느리다고 느끼는 이유
속도 관련 후기는 표현이 제각각이지만, 원인은 대략 두 갈래로 갈린다.
증상 표현
추정 원인
대응
"출시 시점이라 느리다"
초기 트래픽 집중
시간이 해결하는 영역, 제어 불가
"하기 전에 오래 생각한다"
기본 effort가 high, thinking 기본 켜짐
effort 하향 조정
"지시에 반박하고 중간에 멈춘다"
이전 세대용 검증 지시 중복
프롬프트에서 검증 지시 제거
"high effort일수록 더 성가시다"
강화된 자체 검증과 사용자 지시의 충돌
medium·low로 낮춰 비교
첫 줄만 사용자가 손댈 수 없고, 나머지 셋은 설정으로 바뀐다. 출시 직후 "느리다"는 후기를 볼 때 이 넷 중 어느 경우인지 구분하지 않으면, 모델 탓으로 오해하기 쉽다.
12.4 레딧이 갈린 축, 코더냐 지휘자냐
"코딩은 잘하는데 맡겨 두기가 불안하다" 토큰·속도 말고도 반복해서 나온 평가가 있다. 손이 빠른 것과 알아서 방향을 잡는 것은 다르다는 지적이다.
한 사용자는 "코드는 짤 줄 안다. 그런데 추론해서 옳은 결론에 도달하는 능력은 Fable보다 한참 아래고, 정작 중요한 건 그쪽이다"라고 적었다. 다른 글은 제목부터 "Opus 5는 훌륭한 코더이자 정말 괴로운 오케스트레이터"였고, 본문에 "Fable이 무리 없이 해내던 장기 작업에서 Opus 5는 쓰기가 놀랄 만큼 어렵다"고 썼다.
여기서 나온 절충안이 재미있다. "Fable에게 계획을 시키고, Opus에게 구현을 시킨다"는 조합이다. 한 사용자는 "Fable은 프로즈(계획 문서)만 쓰게 하고, 편집·테스트 반복 같은 삽질은 전부 Opus 할당량으로 태운다"고 운영 방식을 공개했다.
단, 이 조합도 공짜는 아니다. "몇 단계 지나고 나면 구현이 원래 계획에서 확연히 벗어나 있다"는 보고도 같은 기간에 올라왔다.
(참고: r/ClaudeCode u/ShaneeNishry · r/ClaudeAI u/Veraticus · r/ClaudeAI u/tonyromero, 2026-07-24~26)
초보자용 한 줄 "오케스트레이터"라는 말이 낯설다면 — 일 시키는 사람과 일 하는 사람을 떠올리면 됩니다. 레딧 평을 요약하면 Opus 5는 일은 잘하는데 지휘는 서툴다는 쪽입니다. 혼자 다 시키기보다 계획을 사람이 잡아 주거나 다른 모델에 맡기는 편이 낫다는 이야기고, 이는 12.1절의 "여러 번 돌리는 구조에 강하다"와 같은 결론에 닿습니다.
12.5 한국어권에서 나온 이야기
한국어권에서 나온 논점 중 가장 눈에 띈 것은 성능 이야기가 아니었다. GeekNews에 달린 이 한 줄이다.
여기서 핵심은 절대 성능보다 조직이 30일 데이터 보관 의무 없이 Fable급 모델을 쓸 수 있게 됐다는 것임 Opus 5는 이전 Opus처럼 일반 접근에 데이터 보관 요건이 없으며, Fable에 ARC-AGI 점수가 없는 이유도 이 보관 정책 때문임
"데이터 보관 의무"가 뭔가요? (초보자용) AI 회사가 내가 보낸 내용을 자기 서버에 며칠 동안 보관하는 것을 말합니다. 오·남용을 잡기 위한 안전장치인데, 조직 입장에서는 이야기가 달라집니다.
예를 들어 고객 개인정보나 미공개 소스코드를 다루는 회사라면, "우리 데이터가 외부 서버에 30일 남는다"는 조건 자체가 계약이나 사내 규정에 걸립니다. 성능이 아무리 좋아도 검토 대상에서 아예 빠지는 것입니다.
그래서 이 댓글의 요지는 이렇습니다. 어떤 조직에게는 벤치마크 43.3점보다 "보관 의무 없음" 한 줄이 결정적이라는 것. 앞의 4장에서 본 점수표가 도입 판단의 전부가 아니라는 뜻이기도 합니다.
참고로 rev 이전 판에서는 이 인용의 정확한 문구를 확정하지 못해 "확인 필요"로 남겨 두었는데, 이번에 원문 페이지를 다시 열어 위 문구가 실제 댓글 그대로임을 확인했다. 다만 이 댓글은 해외 커뮤니티 의견을 요약·중계하는 성격이고, 한국 개발자들이 직접 토론한 스레드는 그 한 건이 전부였다.
그럼 한국어권 실사용 후기는 어떨까. 출시 사흘째 기준으로 다시 훑어봤다. 짧은 것들 위주다.
있다 — 다만 짧다 · "Opus 5 모델로 LogcatOn 프론트를 업데이트 하였다. 이게 1시간 작업 결과물이라니.. Opus 5 토큰 사용량도 괜찮고, 최고다!!" — 실제 공개 프로젝트를 갱신한 기록이다. 1시간이라는 시간과 토큰 만족도가 같이 언급된 몇 안 되는 사례다. (X @qwerfunch, 2026-07-27)
· 앱 개발자의 관찰. "전에는 직접 발견해서 버그를 찾았는데, 실제 사용 워크플로우에서 일어날 법한 가정으로 디버깅을 해주네요." — 앞의 12.1절 "버그 찾기에 강하다"는 흐름과 겹친다. (X @brewmasterlim32, 2026-07-26)
· 글쓰기 쪽은 평가가 갈렸다. "글쓰기 / 윤문을 시켜봤는데 한국어는 여전히 opus 4.6이 잘 합니다. 이유를 모르겠음" — 코딩 성능과 한국어 문장력이 같이 가지 않는다는 지적으로, 12.2절의 "writing slop" 혹평과 방향이 같다. (X @ascoeur9, 2026-07-27)
한국어권에서도 토큰 증언은 정면으로 갈렸다 6.5절에서 본 레딧의 대립이 한국어권에서도 그대로 다시 나왔다.
· "opus 4.8 쓰다가 오늘부터 5로 변경했는데 단위시간당 토큰 소모량이 훨씬 높아진 것 같아요. 체감상 거의 2배 정도?"(클리앙 댓글, 2026-07-25) · 반대편: "토큰 먹는 것도 확 줄고, 속도도 엄청 빠르고. 체감은 일단 좋음."(에펨코리아 댓글, 2026-07-25)
여기서 클리앙 쪽 "체감상 2배"가 재미있다. 6.6절의 API 실측(같은 눈금에서 약 2배)과 숫자가 맞아떨어지기 때문이다. 감으로 느낀 것과 계측한 것이 같은 값을 가리켰다.
없다 — 그리고 이게 이 절의 결론이다 출시 사흘이 지났는데도 한국어권에는 "이 레포를 며칠 돌렸고, 얼마가 나왔고, 뭐가 깨졌다" 수준의 장문 개발 후기가 거의 없다.
확인된 반응은 커뮤니티 짧은 글과 X 단문이 대부분이다.
Velog·OKKY·요즘IT에서는 Opus 5 실사용 글을 찾지 못했고, 네이버 블로그도 마찬가지였다. 티스토리에 비교 분석 글이 몇 있었지만, 대부분 공개 수치를 재정리한 것이지 본인이 돌려 본 기록은 아니었다.
X에서 "오푸스5 후기는 별로 안 나오나 보네, 탐라에 안 보임"이라는 말이 나올 정도다.
그러니 지금 한국어로 제대로 된 실사용 기록을 남기면, 그게 꽤 희소한 자료가 된다.
12.6 Threads와 프롬프트 인젝션 저항
Threads 쪽에서는 X와 결이 조금 달랐다. 벤치 순위 논쟁보다 보안 이야기가 먼저 눈에 띄었다.
그 유명한 보리스 체르니가 직접 남긴 글이 그중 하나다.
시스템 카드에 묻혀 있던 지점 "Opus 5 is our least prompt injectable model yet. It is a bit buried in the system card, but across PI evals and red teaming, Opus 5 is very hard to prompt inject successfully."
(Opus 5는 지금까지 나온 모델 중 프롬프트 인젝션에 가장 강한 편이다. 시스템 카드에 다소 묻혀 있지만, 인젝션 평가와 레드팀 테스트 전반에서 성공시키기 매우 어렵다.)
이어지는 글에서는 모델 정렬·프롬프트 인젝션 탐지·Claude Code의 Auto Mode를 겹쳐 쌓으면 인젝션 공격 성공률이 "~0"에 수렴한다고 했다 (참고: @boris_cherny Threads, 2026-07-25 기준 1일 전). 벤치마크 점수표에는 안 나오지만, 에이전트를 외부 입력에 물려 돌리는 쪽에는 점수보다 이 항목이 더 중요할 수 있다.
다만 이 발언은 모델을 만든 팀 소속이라는 점을 감안해서 읽어야 한다. 제3자 레드팀 결과가 아니라 자체 평가 요약이다. 그 점은 분명히 해 둔다.
한국어 게시물도 여러 건 확인했는데, 대체로 가격 동결에 대한 호응과 짧은 출시 공유가 많았다.
실사용 후기라 부를 만한 깊이의 한국어 글은 출시 직후 시점에 찾지 못했다.
13. 일 종류별로 고르는 모델
앞에서 본 내용을 선택표 하나로 압축했다. 근거가 회사 자료인지, 사용자 후기인지도 같이 적어 두었다. 표를 보면 용도별로 갈린다.
작업 유형
우선 검토 모델
근거
근거 층
에이전트 코딩, 터미널 작업
Opus 5
FrontierBench 43.3 대 Fable 5 33.8
공식 절대 수치
새 유형 문제 해결
Opus 5
ARC-AGI-3 30.2% 대 종전 최고 7.8%
벤치마크 주관처 발표
장시간 자율 반복 작업
Opus 5
검증·반복 강화, 턴 3분의 1 감소
공식 서술
최고 난도 과제, 결과물 "취향"
Fable 5
다수 후기가 Fable 5 우위를 언급
커뮤니티
문서·기획 등 작성 품질 중심
별도 검증 필요
writing slop 혹평 존재
커뮤니티
익스플로잇 개발, 장기 자율 생물 연구
Mythos 5
Opus 5는 설계상 상한
공식 서술
속도·비용 최우선 범용 작업
대안 모델 검토
동일 테스트 실비 15배 차이 사례
사용자들이 직접 재 본 결과
클라우드 마켓플레이스 경유 필수
Opus 5 기본 모드
Fast mode는 해당 경로 미지원
공식 문서
표 전체를 한 줄로 줄이면 이렇다. Opus 5는 "한 번 맡기고 오래 돌려야 하는 일"에 강하고, "짧게 여러 번 부르는 일"에는 비싸다. 벤치 순위보다 이 구분이 실제 청구서를 훨씬 잘 설명한다. 개인적으로는 이 구분부터 보는 편이다.
모델을 하나만 고르지 않는 선택지 한 사용자는 같은 리서치 작업에서 Grok이 253초에 12개 이상 사이트를 훑었고, Opus 5는 413초에 6개 사이트를 봤지만 요청하지 않은 통찰까지 잡아냈다고 기록했다. 결론은 "빠른 것과 예리한 것은 다르다"였고, 지금은 작업별로 라우팅해서 Opus가 계획하고 Grok이 실행한다고 했다 (참고: @reprynttAI 병렬 비교, 2026-07-25). 단일 모델 선택 문제로만 보면 놓치는 구성이다.
비용 효율 축에서는 다른 순위도 보고됐다. FrontierCoder 0.3 기준으로 Grok 4.5가 가장 비용 효율적이고, Opus 5가 원시 성능에서 가장 강하다는 정리다. 성능 1위와 비용 효율 1위가 다른 모델이라는 구도인데, 예산이 정해진 팀이라면 이 구분이 순위표보다 실질적이다. 솔직히 여기가 더 와닿는다.
14. 오늘·이번 주에 할 일
출시 직후 모델을 바꿀 때는 순서가 있다. 이 글에서 확인한 범위 안에서, 오늘 바로 해 볼 수 있는 것만 골랐다.
오늘 확인할 것 (5분)
지금 쓰는 요금제에서 Opus 5가 어디에 있는지 확인한다. Max면 이미 기본 모델이고, Pro면 모델 선택기 최상위 옵션이다.
코드에 모델 ID를 하드코딩해 둔 곳이 있는지 검색한다. claude-opus-4-1-20250805가 남아 있으면 2026년 8월 5일에 멈춘다.
시스템 프롬프트에서 "검증하고 진행", "double-check", "마지막에 확인" 류 지시를 찾는다. Opus 5에서는 중복 작업이 된다.
이번 주에 판단할 것
대표 작업 하나를 골라 Opus 4.8과 Opus 5에서 각각 돌리고 총 토큰과 총 소요 시간을 기록한다. 단가표만 봐서는 작업 1건 총비용을 알 수 없다.
같은 작업을 Opus 5의 effort를 한 단계 낮춰서 한 번 더 돌린다. 실측 사례에서는 낮춘 쪽이 이전 세대 최고 설정과 비슷한 값을 냈다(6.6절). 품질이 유지되면 그 설정을 기본값으로 삼으면 된다.
Fast mode를 켤 만한 작업이 어떤 것인지 정리해 둔다. 사람이 붙어 앉아 반복 수정하는 작업이면 값을 하고, 배치로 던져 놓는 작업이면 2배 가격이 그냥 손해다.
기존 스킬·플러그인·커스텀 워크플로를 하나씩 돌려 본다. 호환성 문제 보고가 실제로 있었으니, 전면 전환 전에 확인한다.
클라우드 마켓플레이스 경유로 모델을 쓰는 조직이라면, Fast mode가 선택지에 없다는 점을 미리 공유한다.
web fetch와 Priority Tier에 의존하는 코드가 있는지 확인한다. Opus 5에서는 둘 다 지원되지 않는다.
14.1 공식 가이드에 없는 것
공식 발표와 문서는 잘 정리돼 있지만, 한국에서 실제로 도입할 때 부딪히는 지점 중 상당수는 그 문서 밖에 있다. 여기가 좀 답답한 부분이다.
공식 문서가 답해 주지 않는 네 가지
작업 1건 총비용: 공식이 주는 건 토큰 단가와 "작업당 비용이 절반" 같은 배수 표현뿐이다. 내 작업에서 실제로 얼마가 나가는지는 직접 재는 수밖에 없다.
출시 초기 체감 속도: 공식은 60% 적은 시간을 말하지만, 출시 시점 후기 다수는 반대로 느리다고 적었다. 트래픽 상황은 문서에 없다.
기존 워크플로 호환성: 스킬·플러그인 충돌은 공식 문서에 없다. 이전 가이드가 다루는 것은 API 파라미터 수준이다.
한국에서의 결제·구독 조건: 이 글에서는 확인하지 않았다. 요금제 가입 가능 여부와 결제 수단은 공식 페이지에서 직접 확인하는 게 안전하다.
네 가지 모두 환경에 따라 달라진다. 그래서 문서에 쓸 수 없고, 각자 자기 환경에서 재 봐야 한다. 위 체크리스트는 그 측정을 시작하는 최소 절차다.
출시 직후라는 시점을 감안한 세 가지 팁
전면 전환을 미룬다: 기존 자동 흐름의 기본 모델을 통째로 바꾸기 전에, 새 작업 한 갈래에서만 먼저 돌려 본다. 되돌릴 수 있는 범위로 시작한다.
속도 불만을 판단 근거로 삼지 않는다: 출시 직후 속도는 트래픽 영향이 크다. 며칠 지난 뒤 다시 재는 편이 정확하다.
퍼져 있는 벤치마크 숫자를 한 번 더 확인한다: 타임라인에서 본 숫자가 발표 페이지 본문이나 공식 성적표에 실제로 있는지 찾아본다. 고객 사례의 100%와 리더보드의 26.0%처럼, 같은 시험 이름을 달고도 범위가 전혀 다른 숫자가 섞여 돈다.
15. FAQ와 마무리
Q1. Sonnet 5와 Opus 5는 무엇이 다른가? 가격만 보면 Sonnet 5는 입력 3달러·출력 15달러, Opus 5는 5달러·25달러다. Opus 5가 입력 기준 약 1.67배다. 이 글에서 두 모델 성능을 직접 비교한 벤치마크는 확인하지 못했다. 다만 Opus 5는 Claude Max의 기본 모델이자 Claude Pro 최상위 옵션으로 배치돼 있어, 라인업상 위에 있다는 점은 분명하다.
Q2. Fast mode를 꼭 켜야 하나? 꼭 켤 필요는 없다. 속도가 약 2.5배가 되는 대신 가격이 정확히 2배다. 사람이 화면 앞에서 결과를 기다리는 작업이면 값을 할 수 있고, 배치로 돌려 놓고 나중에 확인하는 작업이면 그냥 비용만 2배다. 작업 형태부터 보면 된다. 게다가 Claude API 전용이라 Amazon Bedrock·Google Cloud·Microsoft Foundry 경유로는 쓸 수 없다.
Q3. 지금 당장 전부 옮겨야 하나? Opus 4.1을 쓰고 있다면 급하다. 2026년 8월 5일에 은퇴한다. Opus 4.8을 쓰고 있다면 급하지 않다. 은퇴 예정일이 2027년 5월 28일보다 이르지 않다고 문서에 적혀 있다. 다만 Opus 5가 같은 가격이니 미룰 이유도 적다. 옮길 때는 모델 ID만 바꾸지 말고, 검증 지시부터 정리하자.
Q4. "Opus 5가 벤치마크 100%를 찍었다"는 글을 봤는데 사실인가? AutomationBench를 두고 그런 말이 돈다. 층을 나눠 보면, 공식 기술 문서의 비공개 문제 리더보드 절대 통과율은 26.0%이고, 발표 본문은 같은 비용 기준 약 1.5배 통과율이다. 같은 발표 페이지의 Zapier 인용은 churn-prevention 특정 시나리오 하나(고객 이탈 방지 흐름)에서 "hit 100%"라고 말한다. 100%를 벤치 전체 점수로 읽으면 범위가 무너진다. 확인하려면 공식 성적표와 인용 문장의 주어를 같이 보면 된다. 주어를 놓치면 범위가 바로 무너진다.
Q5. 모델만 바꿨는데 갑자기 400 에러가 난다. 먼저 이 조합부터 확인한다 — thinking을 끈 상태에서 effort를 xhigh나 max로 보내고 있는가? Opus 5부터 이 조합은 400을 반환한다. Opus 4.8에는 없던 제약이라, 두 값을 서로 다른 설정 파일에서 관리하는 코드는 모델 ID만 바꿔도 깨진다. thinking을 꼭 꺼야 한다면 effort를 high 이하로 내리면 된다. 모델 ID만 바꾸고 넘어가면 여기서 걸린다.
Q6. 커뮤니티 후기가 서로 반대인데 뭘 믿어야 하나? 후기를 축으로 나눠 읽으면 모순이 줄어든다. 품질·버그 탐지 축에서는 긍정이 우세하고, 체감 속도·작업 1건 총비용 축에서는 부정이 우세하다. 두 축을 섞은 문장은 "좋다"와 "나쁘다"가 동시에 성립한다. 내 작업이 둘 중 어디에 해당하는지 먼저 정하고 후기를 읽는 편이 낫다.
Q7. "토큰을 덜 쓴다"와 "토큰을 두 배 쓴다"가 같이 보이는데, 뭐가 맞나? 둘 다 맞다. 재는 대상이 다를 뿐이다.
· 같은 생각 깊이로 맞추면 Opus 5가 4.8의 약 2배를 쓴다 (6.6절 실측). 모델만 바꾸고 설정을 그대로 두면 청구서가 오르는 이유다.
· 같은 결과물을 기준으로 하면 덜 쓴다. Opus 5의 low가 4.8의 high와 비슷한 자리에 온다. 즉 손잡이를 낮출 여유가 생긴 것이다.
· 구독 한도는 또 다른 이야기다. 한도가 잘 안 줄어든다는 후기와 10배 빨리 탄다는 후기가 같은 주에 같이 나왔다 (6.5절).
한 줄로 말하면, 옮긴 직후 소모가 늘었다면 모델을 탓하기 전에 effort를 한 단계 내려서 다시 재 보시라.
15.1 한 줄로 맺으면
출시 직후 시점에서 확실히 말할 수 있는 것과 아닌 것을 다시 갈라 보면 이렇다.
확실한 쪽은 가격과 자리매김이다. Opus 5는 4.8과 같은 단가이고, Claude Max에서는 기본 모델이 됐다.
4.8을 쓰던 사람이 옮길 이유는 충분하다.
공식 성적표에서도 올라간 방향은 분명하다. 여러 단계를 스스로 밟는 작업(FrontierBench), 컴퓨터 조작(OSWorld), 지식 노동(GDPval-AA), 처음 보는 문제(ARC-AGI-3) — 이 네 축에서 앞선다.
불확실한 쪽은 비용과 체감이다.
토큰 단가가 같아도 작업 1건 총비용은 다르게 나올 수 있고, 실제로 15배 차이가 기록된 사례가 있다.
체감 속도 후기는 정면으로 갈렸다.
게다가 이 글이 모은 반응은 출시 후 이틀 안쪽의 첫인상이라, 며칠 더 써 본 뒤의 평가는 또 다를 수 있다.
그래서 개인적으로는 판단 기준을 벤치 순위가 아니라 작업 형태에 두는 게 맞다고 본다.
한 번 던져 놓으면 오래 돌아야 하는 작업, 여러 단계를 스스로 검증하며 반복해야 하는 작업이라면 Opus 5 쪽이 유리하다.
짧은 요청을 많이 던지는 구조라면, 작업 1건 총비용부터 재 보고 결정하면 된다.
오늘 할 수 있는 가장 확실한 한 가지는 이것이다.
지금 쓰는 대표 파이프 라인, 루프를 하나 골라 Opus 4.8과 Opus 5에서 각각 한 번씩 돌리고, 총 토큰과 소요 시간을 기록해 보자.
벤치마크 43.3%보다 그 숫자 두 개가 훨씬 많은 걸 알려 준다.
여유가 되면 하나 더 — Opus 5의 생각 깊이를 한 단계 낮춰서 같은 작업을 한 번 더 돌려 보시길 권한다.
