Fable 5와 Opus 5는 왜 다르게 느껴지는가

게시 2026/07/26

By BLUEBUG

97 분읽는 시간

— 모델의 기질, effort라는 조절 손잡이, 그리고 “에이전트 육성”이라는 비유의 실체

https://www.facebook.com/share/p/1GJZvsw5tc/
좀 더 멀리 넓게, 높은 위치에서 조망하면서 판을 보고 전체 판을 설계하는데에는 확실히 Fable 5가 Opus 5 보다 강합니다. 대신, Opus 5 는 명확한 범위 안에서의 기민하고 적절한 반응과 특히나 시각적인 이해와 구현에 있어서 Fable 5 보다 낫네요. 동일한 effort 레벨일 때. Opus 5 가 좀 섣부르게 판단한다 싶으면 effort 레벨을 하나 더 올려보실 것을 추천합니다.
어떻게 키우느냐가 중요하긴 한데, 모델의 기본 특성을 무시하고 키우면 결국 상충되는 부분들이 생겨서 특성을 잘 고려하면서 키우는 것이 베스트인 것 같습니다.
어찌보면, 인간 아이를 키우는 것처럼 정답이 없는 것이긴 한데, 그래도 이건 reset 과 continue 가 가능하고 잘 셋팅만 하면 중간 세이브 슬롯들도 활용할 수 있고 여차하면 세이브 파일의 조작도 가능하니…
그래서 예전부터 AI 에이전트와 일을 하는 것이 Princess Maker 같은 육성 게임 + Populus 같은 God 게임을 섞어놓은 것과 매우 비슷한 재미라고 말씀드렸었습니다. 따라서 여차하면 게임 중독 내지는 더 무서운 문제들에 대한 리스크도 안게될 수도 있지만요.
#ai #agent #claude #opus5 #fable5 #nurturing #gonnector #고넥터

0. 이 문서의 출발점과 읽는 방법

이 문서는 하나의 짧은 현장 관찰에서 출발합니다. 요약하면 이렇습니다.

넓고 높은 곳에서 판 전체를 조망하고 설계하는 일에는 Fable 5가 Opus 5보다 확실히 강하다. 반대로 명확한 범위 안에서 기민하고 적절하게 반응하는 일, 특히 시각적인 이해와 구현에서는 Opus 5가 Fable 5보다 낫다 — 동일한 effort 레벨일 때. Opus 5가 좀 섣부르게 판단한다 싶으면 effort 레벨을 하나 더 올려보기를 권한다. 결국 “어떻게 키우느냐”가 중요하지만, 모델의 기본 특성을 무시하고 키우면 상충이 생기므로 특성을 고려한 육성이 최선이다. 그런 의미에서 AI 에이전트와 일하는 것은 육성 게임과 God 게임을 섞어놓은 재미에 가깝고, 그래서 중독이나 그보다 무서운 문제의 리스크도 함께 안게 된다.

이 관찰은 세 개의 서로 다른 층위를 한 문단에 압축하고 있습니다. 첫째는 두 모델의 능력 분포에 관한 경험적 주장, 둘째는 effort라는 API 파라미터를 다루는 실무 조언, 셋째는 에이전트와 일한다는 행위 자체에 대한 은유와 그 은유가 함축하는 위험입니다. 층위가 다르면 검증 방법도 달라야 합니다. 첫 번째는 공개 문서와 벤치마크로 부분적으로 대조할 수 있고, 두 번째는 공식 문서에 명시된 동작 규칙으로 거의 완전히 검증할 수 있으며, 세 번째는 사실 검증의 대상이 아니라 해석과 설계의 문제입니다.

그래서 이 문서는 모든 주요 서술에 근거의 성격을 표시합니다.

표기	의미
[공식]	Anthropic 공식 문서 또는 공식 발표문에 명시된 내용
[벤더주장]	Anthropic이 자사 평가 결과로 발표한 수치, 또는 파트너사가 자사 평가로 제출한 인용
[2차보도]	언론·기술 블로그 등 제3자가 정리한 수치나 서술
[관찰]	특정 개인의 사용 경험에 근거한 진술 (원 게시글 포함)
[해석]	위 근거들을 종합한 필자의 판단. 사실이 아니라 판단으로 읽어야 하는 부분

특히 강조하고 싶은 점이 하나 있습니다. 원 게시글의 첫 번째 주장 — “조망은 Fable, 반응성과 시각은 Opus” — 은 공개된 벤치마크만으로는 완전히 증명되지도 반증되지도 않습니다. 그러나 아래에서 보시겠지만, 공식 문서가 서술하는 두 모델의 설계 의도와 권장 사용법은 이 관찰과 상당히 잘 맞아떨어집니다. 그 정합성이 어디까지이고 어디서부터 갈라지는지를 정확히 짚는 것이 이 문서의 첫 번째 목표입니다.

1. 먼저 좌표를 잡는다: 두 모델은 어떤 계보에 놓여 있는가

1.1 Mythos 계층이라는 새로운 층

혼동을 줄이려면 이름 체계부터 정리해야 합니다. Anthropic은 기존의 Haiku / Sonnet / Opus 3단 구성 위에 Mythos라는 상위 계층을 새로 얹었습니다. [공식] Claude Fable 5는 이 Mythos 계층의 능력을 일반 사용자에게 개방한 첫 모델이고, Claude Mythos 5는 같은 기반 모델에서 일부 안전장치를 해제한 버전으로 Project Glasswing 참여 조직에만 제한 제공됩니다.

즉 Fable 5와 Mythos 5는 같은 모델이고, 차이는 안전 분류기(classifier)의 유무입니다. [공식] Fable 5는 공격적 사이버보안 기법, 생물·생명과학 콘텐츠, 그리고 모델의 요약된 사고 과정을 추출하려는 시도를 겨냥한 분류기를 상시 구동하며, 이 분류기에 걸린 요청은 stop_reason: "refusal"로 반환되거나 다른 모델로 폴백됩니다.

여기서 실무적으로 중요한 사실이 하나 나옵니다. [공식] 이 안전장치는 악의적 요청만이 아니라 선의의 보안 업무나 유익한 생명과학 작업도 걸어버릴 수 있습니다. Anthropic 자신이 문서에 그렇게 적어두었습니다. 그래서 Fable 5를 프로덕션에 붙이려면 거절 응답 처리, 폴백 경로, 그에 따른 과금 규칙 세 가지를 반드시 함께 설계해야 합니다.

1.2 Opus 5는 Fable 5의 후속이 아니다

[공식] Claude Opus 5는 2026년 7월 24일에 출시되었습니다. 계보상으로는 Opus 4.8의 후속이며, Fable 5의 상위 버전이 아닙니다. 그런데 발표된 성능은 이 계보 관계를 상당히 흔들어 놓았습니다. [벤더주장] Anthropic은 Frontier-Bench와 GDPval-AA 같은 코딩·지식노동 평가에서 Opus 5가 새로운 최고 성적을 기록했다고 밝혔고, 가격은 Fable 5의 절반입니다.

한편 [공식] Anthropic은 Opus 5가 사이버보안 과제에서는 여전히 Mythos 5에 뒤진다고 명시했습니다. 취약점을 발견하는 능력은 Mythos 5에 근접했지만, 그것을 실제 위협으로 전환하는 익스플로잇 개발에서는 상당한 격차가 남아 있다는 설명입니다. 이것은 우연이 아니라 설계입니다. [공식] Anthropic은 Opus 4.8과 마찬가지로 Opus 5를 사이버 과제로 의도적으로 학습시키지 않았습니다.

1.3 두 달 사이에 벌어진 일들

flowchart LR
    M1["2026-04-07<br/>Mythos 학습 완료 발표"] --> M2["2026-04<br/>Mythos Preview<br/>제한 공개"]
    M2 --> M3["2026-06-09<br/>Fable 5 / Mythos 5 출시"]
    M3 --> M4["2026-06-12<br/>미 상무부 수출통제 적용<br/>양 모델 접근 전면 중단"]
    M4 --> M5["2026-06-30<br/>수출통제 해제"]
    M5 --> M6["2026-07-01<br/>Fable 5 접근 복구"]
    M6 --> M7["2026-07-24<br/>Opus 5 출시"]

    style M4 fill:#ffe6e6,stroke:#cc0000
    style M7 fill:#e6f2ff,stroke:#0066cc

[공식] 2026년 6월 12일 미국 정부가 Fable 5와 Mythos 5에 수출통제를 적용했습니다. 명령이 즉시 발효되었고 실시간으로 국적을 검증할 방법이 없었기 때문에, Anthropic은 모든 사용자에 대해 두 모델의 접근을 중단했습니다. 6월 30일 통제가 해제되었고 7월 1일부터 전 세계 사용자에게 다시 열렸습니다.

[해석] 이 사건은 모델 선택을 단순한 성능·가격 비교로 볼 수 없게 만든 사례입니다. 특정 모델에 하네스를 깊게 결합해 두었다면, 규제 변수 하나로 파이프라인 전체가 며칠간 정지할 수 있다는 것이 실증되었습니다. 뒤에서 다룰 “육성” 논의에서 폴백 경로 설계가 왜 선택이 아니라 필수인지의 근거가 여기에 있습니다. [2차보도] Mythos 학습 완료 발표 시점(4월 7일)과 6월 중 Sonnet 5까지 포함한 연속 출시 흐름은 제3자 정리 기사에 근거한 서술이므로, 정확한 날짜는 원 출처 확인이 필요합니다.

1.4 사양 대조표

[공식] 공식 모델 개요 문서 기준입니다.

항목	Claude Fable 5	Claude Opus 5
포지션	장기 실행 에이전트를 위한 차세대 지능	복잡한 에이전틱 코딩과 엔터프라이즈 업무
API 모델 ID	`claude-fable-5`	`claude-opus-5`
가격 (입력 / 출력, 100만 토큰)	$10 / $50	$5 / $25
컨텍스트 윈도	1M 토큰	1M 토큰 (기본값이자 최대값)
최대 출력	128k 토큰	128k 토큰
신뢰 가능 지식 컷오프	2026년 1월	2026년 5월
적응형 사고(adaptive thinking)	상시 활성 (끌 수 없음)	기본 활성 (조건부로 끌 수 있음)
확장 사고 예산 지정	불가	불가
상대적 지연	느림	중간
effort 지원 단계	low / medium / high / xhigh / max	low / medium / high / xhigh / max
안전 분류기 개입 빈도	기준선	[공식] Fable 5 대비 약 85% 적게 개입할 것으로 예상
데이터 보존 정책	30일 보존 요건 적용	일반 접근에 별도 보존 요건 없음

[해석] 이 표에서 실무자가 가장 먼저 눈여겨봐야 할 칸은 성능이 아니라 지식 컷오프의 4개월 차이와 분류기 개입 빈도입니다. 최근 릴리스된 프레임워크나 라이브러리를 다루는 작업이라면 벤치마크 몇 점보다 컷오프 4개월이 더 크게 체감될 수 있고, 보안이나 생명과학 인접 도메인이라면 분류기 개입 빈도가 곧 실사용 가능성을 결정합니다.

2. 첫 번째 주장 검증: “판을 넓게 조망하는 건 Fable 5”

2.1 공식 문서가 서술하는 Fable 5의 기질

Anthropic의 Fable 5 프롬프팅 가이드는 이 모델의 성격을 꽤 직설적으로 서술합니다. [공식] 요지는 다음과 같습니다.

장기 자율성. 장시간에 걸쳐 생산적인 출력을 지속하며, 여러 날에 걸친 목표 지향적 실행을 완수하고 길고 복잡한 작업 전반에서 지시를 강하게 유지합니다.
모호성 탐색. 복잡하고 여러 갈래로 얽힌 요청을 받아 다음 단계를 스스로 판단하는 상황에서 좋은 성능을 보입니다.
위임과 협업. 병렬 서브에이전트를 파견하고 유지하는 데 눈에 띄게 더 신뢰할 만하며, 장시간 실행되는 서브에이전트 및 동료 에이전트와의 지속적 통신을 안정적으로 관리합니다.
잘 정의된 복잡한 문제에서의 1회 정답률. 초기 테스터들이 종전에는 며칠간 반복해야 했던 시스템을 단일 패스로 구현했다고 보고했습니다.

그리고 권장 사용법에서 이 기질이 가장 선명하게 드러납니다. [공식] 문서는 “난이도 범위의 최상단에서 시작하라“고 조언합니다. 이전 모델에게 맡기던 것보다 더 어려운 과제를 골라, Fable 5가 스스로 범위를 정하고 명확화 질문을 던지고 실행하게 하라는 것입니다. 반대로 쉬운 작업만으로 테스트하면 이 모델의 능력 범위를 과소평가하게 된다고 명시적으로 경고합니다.

[공식] 나아가 Anthropic의 출시 발표문은 “작업이 길고 복잡할수록 Fable 5의 우위가 커진다“고 직접 서술했습니다.

[해석] 원 게시글의 “멀리, 넓게, 높은 위치에서 조망하며 전체 판을 설계한다”는 표현은 벤치마크 항목명이 아닙니다. 그러나 위의 공식 서술들을 이어 붙이면 거의 같은 그림이 됩니다. 모호한 문제를 받아 스스로 범위를 정하고, 여러 갈래의 작업을 병렬 에이전트로 쪼개 지휘하고, 며칠 단위로 지시를 잃지 않고 유지하는 능력 — 이것이 곧 “판을 설계하는 능력”의 기술적 서술입니다. 원 관찰과 공식 문서는 서로 다른 어휘로 같은 현상을 가리키고 있을 가능성이 높습니다.

2.2 그런데 벤치마크는 다른 이야기를 한다

여기서 정직해야 할 지점이 있습니다. Opus 5 출시 이후의 수치는 단순한 “Fable이 더 똑똑하다”를 지지하지 않습니다.

[벤더주장] Anthropic 공식 발표 기준:

Frontier-Bench v0.1 — Opus 5가 다른 모든 모델을 능가하며, Opus 4.8 대비 두 배 이상의 성능을 더 낮은 과제당 비용으로 달성.
CursorBench 3.2 — max effort에서 Opus 5가 Fable 5 최고 점수의 0.5% 이내까지 접근, 과제당 비용은 절반.
OSWorld 2.0 (컴퓨터 사용) — 주어진 비용 대비 모든 모델을 능가하며, Fable 5의 최고 성적을 약 3분의 1 비용으로 상회.
ARC-AGI 3 (신규 문제 해결) — 차순위 모델의 3배 점수.
Zapier AutomationBench — 동일 과제당 비용에서 차순위 모델의 약 1.5배 통과율. 최저 effort에서도 다른 어떤 모델보다 많은 과제를 통과.

[2차보도] 제3자 정리 기사들은 Frontier-Bench v0.1에서 Opus 5 43.3% 대 Fable 5 33.7%, ARC-AGI-3에서 30.2% 대 7.8%(GPT-5.6 Sol 기준), GDPval-AA v2에서 1,861 대 1,736 같은 구체 수치를 전하고 있습니다. 다만 이 수치들은 Anthropic 공식 발표문 본문에서 직접 확인되지 않은 형태로 재구성된 것이므로, 인용 시에는 2차 출처임을 밝히는 편이 안전합니다.

[공식] 참고로 Anthropic은 Frontier-Bench 결과의 각주에서 폴백 조건까지 공개했습니다. Opus 5와 Fable 5 모두 안전 분류기가 거절한 경우 Opus 4.8이 폴백으로 사용되었고, mini-SWE-agent 하네스와 GKE 백엔드 위에서 과제당 5회 시도의 평균 보상으로 측정되었다는 내용입니다. [해석] 이 각주가 있다는 사실 자체가 중요합니다. 안전 분류기가 자주 개입하는 모델은 벤치마크 점수 자체가 폴백에 오염될 수 있고, 그래서 “순수한 모델 능력 비교”가 생각보다 어렵다는 것을 벤더 스스로 인정한 셈입니다.

2.3 그렇다면 원 관찰은 틀린 것인가

[해석] 아니라고 봅니다. 두 진술은 서로 다른 것을 재고 있습니다.

벤치마크는 채점 가능한 과제를 잽니다. 채점이 가능하려면 정답이나 성공 판정 기준이 사전에 정의되어 있어야 하고, 그 말은 곧 문제의 경계가 이미 그어져 있다는 뜻입니다. Frontier-Bench도, CursorBench도, OSWorld도 “이 문제를 풀어라”라는 형태로 주어집니다. 반면 원 게시글이 말하는 “판을 조망하고 설계한다”는 능력은 문제의 경계를 스스로 긋는 단계에서 발휘됩니다. 무엇이 진짜 문제인지, 어떤 순서로 쪼개야 하는지, 어디까지가 이번 범위인지를 정하는 일 말입니다.

이 능력은 현재의 주요 벤치마크가 잘 측정하지 못하는 영역입니다. 그리고 공교롭게도 Anthropic이 Fable 5의 강점으로 명시한 항목들 — 모호성 탐색, 며칠 단위 목표 유지, 병렬 위임 지휘 — 이 정확히 그 영역에 몰려 있습니다.

정리하면 이렇게 말할 수 있습니다.

[해석] 경계가 그어진 문제에서는 Opus 5가 Fable 5를 따라잡았거나 앞섰다(벤더 발표 기준). 그러나 경계를 긋는 일 자체, 그리고 며칠 단위로 그 경계를 흐트러뜨리지 않고 유지하는 일에서는 Fable 5의 설계 목적이 여전히 다르고, 현장 관찰은 그 차이를 보고하고 있다. 다만 이는 공개 지표로 직접 검증되지 않은 영역이므로, 조직 자체 평가로 확인해야 할 가설로 다루는 것이 옳다.

2.4 두 모델의 강점 분포

flowchart TB
    TASK["작업 성격 판단"]

    subgraph FABLE["Fable 5 쪽으로 기우는 조건"]
        FA["요구사항이 모호하고<br/>범위를 스스로 정해야 함"]
        FB["수 시간에서 수 일에 걸친<br/>비동기 자율 실행"]
        FC["여러 서브에이전트를<br/>동시에 지휘해야 함"]
        FD["복잡도가 클수록<br/>격차가 벌어지는 과제"]
        FE["단일 패스 정답률이<br/>비용보다 중요한 과제"]
    end

    subgraph OPUS["Opus 5 쪽으로 기우는 조건"]
        OA["범위가 명확한<br/>반복 실행 작업"]
        OB["낮은 effort로도<br/>품질이 유지되어야 함"]
        OC["도표·문서·UI 등<br/>시각 자료 해석과 구현"]
        OD["컴퓨터 조작 기반<br/>업무 자동화"]
        OE["최근 릴리스 지식이<br/>필요한 작업"]
        OF["비용 민감 / 대량 처리"]
        OG["보안·생명과학 인접으로<br/>분류기 오탐이 잦은 영역"]
    end

    TASK --> FA
    TASK --> FB
    TASK --> FC
    TASK --> FD
    TASK --> FE
    TASK --> OA
    TASK --> OB
    TASK --> OC
    TASK --> OD
    TASK --> OE
    TASK --> OF
    TASK --> OG

    style FABLE fill:#f5f0ff,stroke:#7755bb
    style OPUS fill:#eef7ff,stroke:#2277cc

3. 두 번째 주장 검증: “반응성과 시각 이해·구현은 Opus 5”

3.1 “기민함”의 정체는 effort 대비 효율이다

원 게시글의 “명확한 범위 안에서의 기민하고 적절한 반응”이라는 표현을, 공식 문서는 훨씬 건조한 말로 서술합니다.

[공식] Opus 5 문서가 반복해서 강조하는 것은 낮은 effort에서의 효율입니다. low와 medium effort가 높은 설정 대비 극히 일부의 토큰과 지연으로도 강한 품질을 낸다는 것, 그리고 코드 리뷰의 정확도가 낮은 effort에서도 유지되어 “빠른 1차 패스 + 나중의 정밀 패스”라는 운영 패턴을 가능하게 한다는 것입니다.

파트너사 보고도 같은 방향을 가리킵니다. [벤더주장] 법률 에이전트 업무에서 최대 추론 설정의 Opus 4.8 대비 평균 26% 적은 토큰으로 유사한 성능을 냈다는 보고, 트레이딩 벤치마크에서 Opus 4.8의 약 7분의 1 추론 토큰과 절반 미만 지연으로 더 나은 답을 냈다는 보고, 금융 모델링에서 effort 레벨 전반에 걸쳐 평균 9%p 높은 정확도를 3분의 1 적은 턴·도구 호출과 60% 적은 시간으로 달성했다는 보고 등입니다.

[해석] “기민하다”는 체감은 여기서 나옵니다. 같은 결과를 더 적은 토큰과 더 적은 왕복으로 낸다면, 사용자 입장에서는 덜 뜸들이고 바로 움직인다고 느껴집니다. 반대로 Fable 5는 [공식] “어려운 과제에서 개별 요청이 높은 effort에서는 수 분간 실행될 수 있고, 자율 실행은 몇 시간까지 이어질 수 있다”고 문서가 직접 경고하는 모델입니다. 문서는 심지어 마이그레이션 전에 클라이언트 타임아웃과 스트리밍, 진행 표시 UI를 먼저 조정하라고 권합니다. 대화형으로 주고받는 감각에서 두 모델의 체감이 갈리는 것은 자연스럽습니다.

3.2 시각 이해와 구현

여기가 원 게시글에서 가장 검증 가능한 부분입니다.

[공식] Opus 5의 시각 능력에 대해 문서는 이렇게 서술합니다. 도표·문서·다이어그램 이해에 강하며, UI와 프런트엔드의 시각적 재현에 강하다. 그리고 중요한 단서가 붙습니다 — 시각 성능은 모델이 반복적으로 분석하고 잘라내고 자기 결과물을 시각적으로 검증할 도구를 가졌을 때 가장 강하며, 도구 사용이 사고량 증대보다 비용 대비 효과가 큰 지렛대다.

[벤더주장] 이를 뒷받침하는 구체적 사례도 공개되어 있습니다. 프런트엔드 평가에서 Opus 5는 자기가 만든 페이지를 데스크톱과 폰 너비로 브라우저에서 직접 열어보고, 모바일 접힘선 아래에 숨어버린 상품과 화면 밖으로 밀려난 결제 버튼을 스스로 찾아 고친 뒤 결과를 넘겼다는 보고가 있습니다. 또 다른 사례에서는 도면을 직접 볼 수단이 의도적으로 차단된 과제에서, Opus 5가 스스로 컴퓨터 비전 파이프라인을 작성해 원시 픽셀에서 기하 정보를 추출한 뒤 기계 부품 전체를 3D 모델로 재구성했고, 같은 조건에서 경쟁 모델은 다섯 번 시도해도 풀지 못했다고 합니다.

[공식] 그리고 앞서 인용한 OSWorld 2.0 결과 — Fable 5의 최고 성적을 약 3분의 1 비용으로 상회 — 는 화면을 보고 조작하는 능력에서 Opus 5가 Fable 5를 넘어섰다는 벤더 발표 기준의 직접적 근거입니다.

[해석] 다만 균형을 위해 짚어야 할 점이 있습니다. Fable 5 역시 시각 능력이 주요 개선 항목으로 발표된 모델입니다. [공식] 밀도 높은 기술 도면과 웹 애플리케이션 화면을 훨씬 높은 정확도로, 종종 더 적은 출력 토큰으로 해석하며, 뒤집히거나 흐리거나 노이즈가 낀 입력을 다루기 위해 bash와 크롭 도구를 쓰도록 학습되었다고 명시되어 있습니다. 그러므로 “Fable 5는 시각이 약하다”는 결론은 잘못입니다. 정확한 서술은 “컴퓨터 사용 벤치마크와 프런트엔드 구현 사례에서는 Opus 5의 비용 대비 성능이 앞선다” 입니다.

원 게시글의 표현 중 “시각적인 이해와 구현“에서 방점은 아마도 구현 쪽에 찍혀 있을 것입니다. 보는 것에서 그치지 않고, 본 것을 코드로 옮기고, 옮긴 결과를 다시 보고 고치는 닫힌 루프를 도는 능력 — 이 루프에 관해서는 공식 문서와 파트너 보고가 일관되게 Opus 5를 가리킵니다.

4. 세 번째 주장 검증: “섣부르면 effort를 한 단계 올려라”

4.1 effort는 사고량이 아니라 응답 전체를 조절한다

이 조언은 세 주장 중 가장 명확하게 문서로 뒷받침됩니다. 먼저 effort가 정확히 무엇인지 정리합니다.

[공식] effort 파라미터는 Claude가 응답에 쓰는 토큰의 양을 조절하며, 응답의 모든 토큰에 영향을 미칩니다. 텍스트 설명, 도구 호출과 그 인자, 그리고 사고 과정까지 모두 포함됩니다. 이 설계에는 두 가지 장점이 있다고 문서는 설명합니다. 사고 기능이 켜져 있지 않아도 작동한다는 것, 그리고 도구 호출을 포함한 전체 토큰 지출에 영향을 준다는 것 — 즉 effort를 낮추면 도구를 덜 호출합니다.

[공식] 도구 사용 시 낮은 effort는 여러 작업을 더 적은 호출로 합치고, 전문(前文) 없이 곧장 행동에 들어가며, 완료 후 간결한 확인만 남기는 경향을 보입니다. 높은 effort는 더 많은 도구를 호출하고, 행동 전에 계획을 설명하고, 변경 사항을 상세히 요약합니다.

그리고 결정적으로 [공식] “effort는 엄격한 토큰 예산이 아니라 행동 신호다.” 낮은 effort에서도 충분히 어려운 문제라면 여전히 생각하지만, 같은 문제에 대해 높은 effort일 때보다는 덜 생각한다는 뜻입니다.

레벨	공식 설명	전형적 용도
`max`	토큰 지출에 제약 없는 절대 최대 능력	가장 깊은 추론과 철저한 분석이 필요한 과제
`xhigh`	장기 작업을 위한 확장 능력	30분 이상 실행되는 장기 에이전틱·코딩 작업, 토큰 예산이 수백만 단위
`high`	높은 능력. 파라미터 미지정 시와 동일	복잡한 추론, 어려운 코딩 문제, 에이전틱 작업
`medium`	균형형, 적당한 토큰 절감	속도·비용·성능의 균형이 필요한 에이전틱 작업
`low`	최고 효율, 상당한 토큰 절감과 약간의 능력 감소	속도와 비용이 최우선인 단순 작업, 서브에이전트

4.2 왜 “한 단계 더”가 정확한 처방인가

[공식] Opus 5 문서에는 이런 문장이 있습니다. “Claude Opus 5는 이전의 어떤 Opus 모델보다도 추가 effort를 더 나은 결과로 안정적으로 전환하며, 따라서 선택하는 effort 레벨이 더 큰 무게를 갖는다.”

그리고 같은 계열의 조언이 이전 세대 문서에 더 직설적으로 적혀 있습니다. [공식] Opus 4.7 항목에는 “복잡한 문제에서 얕은 추론이 관찰되면, 프롬프트로 우회하려 하지 말고 effort를 올려라“라고 명시되어 있습니다. Opus 4.8에도 같은 지침이 적용된다고 문서는 밝히고 있습니다.

[해석] 원 게시글의 “섣부르게 판단한다 싶으면 effort 레벨을 하나 더 올려보라”는 조언은 Anthropic 공식 문서의 권고와 사실상 동일한 문장입니다. 개인 관찰이 문서와 독립적으로 같은 결론에 도달했다는 점에서, 이 조언의 신뢰도는 상당히 높다고 볼 수 있습니다.

다만 문서는 시작점에 관해 한 가지를 덧붙입니다. [공식] Opus 5의 권장 출발점은 기본값인 high이며, 여기서 자체 평가에 따라 양방향으로 조정하라는 것입니다. 요구가 심한 코딩·에이전틱 작업에는 xhigh로, 무제한 토큰 지출이 정당화되는 과제에는 max로 올리고, 품질이 유지되는 곳에서는 low와 medium을 비용과 응답 시간의 1차 통제 수단으로 적극 활용하라고 권합니다. 그리고 이전 모델에서 쓰던 effort 설정을 그대로 가져왔다면 반드시 자체 평가로 다시 스윕하라고 경고합니다.

Fable 5의 권장은 결이 조금 다릅니다. [공식] effort는 Fable 5에서 지능·지연·비용을 맞바꾸는 1차 통제 수단이며, 대부분의 작업에 기본값 high, 능력이 특히 중요한 워크로드에 xhigh, 일상적 작업에 medium이나 low를 권합니다. 그리고 인상적인 문장이 이어집니다 — Fable 5의 낮은 effort 설정도 여전히 잘 작동하며, 종종 이전 모델의 xhigh 성능을 넘어선다.

4.3 반드시 알아야 할 함정 네 가지

[공식] 실무에서 effort를 다룰 때 자주 발이 걸리는 지점들입니다.

effort는 응답 길이를 줄여주지 않는다. Opus 5에서 effort는 모델이 얼마나 생각하는지를 조절할 뿐, 얼마나 말하는지는 안정적으로 줄이지 못합니다. 응답이 길어서 문제라면 effort를 낮출 게 아니라 프롬프트로 길이를 명시해야 합니다.
effort 변경은 프롬프트 캐시를 무효화한다. effort가 렌더링된 프롬프트의 형태를 바꾸기 때문에, 요청 간에 값을 바꾸면 이전 턴의 캐시 접두부가 보존되지 않습니다. 긴 세션에서 캐시 히트에 의존한다면 세션 시작 시 레벨을 정하고 고정해야 합니다.
Opus 5에서는 xhigh나 max일 때 사고를 끌 수 없다. 해당 레벨에서 thinking: {"type": "disabled"}를 보내면 400 오류가 반환됩니다. 이것은 Opus 4.8로부터의 파괴적 변경입니다.
xhigh 이상에서는 max_tokens를 크게 잡아야 한다. 문서는 64k에서 시작해 조정하는 것을 합리적 기본값으로 제시합니다. max_tokens는 사고와 응답 텍스트를 합친 총 출력의 하한이 아니라 하드 리밋이기 때문입니다.

[2차보도] 참고로 Claude Code에서는 /effort 명령으로 레벨을 바꿀 수 있고, low·medium·high·xhigh는 세션 간에 유지되지만 max는 현재 세션에만 적용된다는 보고가 있습니다. 또한 claude.ai 화면에서는 xhigh가 “Extra”라는 이름으로 표시된다는 정리도 있습니다. 이들은 제3자 문서와 이슈 트래커에 근거한 내용이므로 사용 중인 버전에서 직접 확인하시기 바랍니다.

4.4 “결과가 나쁘다”를 진단하는 흐름

flowchart TD
    S["결과가 기대에 못 미친다"] --> Q1{"실패의 유형은 무엇인가"}

    Q1 -->|"성급한 결론, 얕은 탐색,<br/>근본 원인 대신 증상만 수정"| E1["effort 한 단계 상향"]
    Q1 -->|"장황함, 불필요하게<br/>긴 산출물"| P1["프롬프트로 길이와<br/>범위를 명시"]
    Q1 -->|"시키지 않은 재검증을<br/>반복함"| P2["검증 지시문을<br/>프롬프트에서 제거"]
    Q1 -->|"서브에이전트를<br/>남발함"| P3["위임 기준과<br/>상한을 명시"]
    Q1 -->|"하지 않은 일을<br/>했다고 보고함"| P4["도구 결과 대조<br/>지시문 추가"]

    E1 --> V["동일 조건에서<br/>재실행 후 비교"]
    P1 --> V
    P2 --> V
    P3 --> V
    P4 --> V

    V --> Q2{"개선되었는가"}
    Q2 -->|"예"| DONE["설정을 고정하고<br/>근거와 함께 문서화"]
    Q2 -->|"아니오"| M["모델 교체 또는<br/>과제 분해 재설계 검토"]

    style E1 fill:#fff4e0,stroke:#cc8800
    style DONE fill:#e8f5e9,stroke:#2e7d32

[해석] 이 흐름도의 요점은 “결과가 나쁘다”를 하나의 증상으로 뭉뚱그리지 않는 것입니다. effort 상향이 듣는 실패는 오직 첫 번째 유형 — 탐색이 얕아서 생긴 실패 — 뿐입니다. 장황함이나 과잉 검증에 effort를 올리면 문제가 더 나빠집니다. 아래 6장에서 보시겠지만, 이 오진이야말로 “기질을 무시한 육성”의 가장 흔한 형태입니다.

5. “동일한 effort 레벨일 때”라는 단서의 무게

원 게시글에는 쉽게 지나칠 수 있지만 방법론적으로 대단히 중요한 단서가 붙어 있습니다 — “동일한 effort 레벨일 때.”

[해석] 이 한 마디가 붙고 안 붙고는 진술의 성격을 완전히 바꿉니다. 두 모델 비교에서 effort를 통제하지 않으면, 우리가 보고 있는 것이 모델의 차이인지 설정의 차이인지 알 수 없기 때문입니다. 문서에 근거해 보면 이 통제가 필요한 이유가 최소 네 가지입니다.

첫째, [공식] effort는 사고량만이 아니라 도구 호출 횟수까지 바꿉니다. 도구를 몇 번 부르느냐는 에이전트 작업의 결과를 좌우하는 가장 큰 변수 중 하나입니다.

둘째, [공식] effort는 엄격한 예산이 아니라 행동 신호이므로, 같은 레이블이 두 모델에서 같은 계산량을 의미하지 않습니다. Fable 5의 low가 이전 세대의 xhigh를 넘어선다는 문서 서술이 바로 이 비대칭의 증거입니다. 즉 “동일 effort”는 공정한 비교의 필요조건이지 충분조건이 아닙니다.

셋째, [공식] 두 모델은 사고 기능의 기본 상태가 다릅니다. Fable 5는 적응형 사고가 상시 활성이고 끌 수 없습니다. Opus 5는 기본 활성이되 high 이하에서는 끌 수 있습니다. 사고 상태를 맞추지 않은 비교는 effort만 맞춰도 여전히 불공정합니다.

넷째, [공식] Fable 5는 분류기 거절이 발생하면 다른 모델로 폴백될 수 있습니다. 벤치마크 각주에서 Anthropic 자신이 Opus 4.8을 폴백으로 썼다고 밝힌 것처럼, 일부 결과가 사실은 다른 모델의 결과일 수 있습니다.

[해석] 그러므로 조직에서 두 모델을 비교 평가한다면 최소한 다음을 통제 변인으로 고정해야 합니다.

통제 항목	이유
effort 레벨	사고량과 도구 호출 횟수를 동시에 좌우
사고 기능 활성 여부	두 모델의 기본값이 다름
하네스 (Claude Code / 자체 루프 / SDK)	같은 모델도 하네스에 따라 결과가 크게 갈림
시스템 프롬프트와 스킬 구성	아래 6장에서 다루듯 모델별 최적 처방이 정반대인 항목이 있음
`max_tokens`	사고 + 응답의 하드 리밋이므로 잘리면 실패로 오인됨
반복 횟수	단발 비교는 분산에 압도됨 (Anthropic도 과제당 5회 평균을 사용)
폴백 발생 여부 로깅	결과가 실제로 어떤 모델에서 나왔는지 확인

그리고 여기서 원 게시글의 성격을 정확히 규정할 필요가 있습니다. [해석] 이것은 한 실무자의 통제된 개인 관찰입니다. effort를 통제했다는 점에서 상당히 신중한 관찰이지만, 반복 횟수·과제 분포·하네스 조건이 공개되지 않았으므로 가설로 다루고 각 조직의 실제 작업으로 재검증하는 것이 올바른 활용법입니다. 원 게시글도 단정이 아니라 경험 공유의 어조를 취하고 있고, 그 태도가 적절합니다.

6. “기질을 무시하고 키우면 상충한다” — 문서가 증명하는 안티패턴

원 게시글의 네 번째 문단은 이렇게 말합니다. “어떻게 키우느냐가 중요하긴 한데, 모델의 기본 특성을 무시하고 키우면 결국 상충되는 부분들이 생긴다.”

[해석] 이 문장은 은유처럼 들리지만, 실은 Anthropic 공식 프롬프팅 가이드가 페이지 대부분을 할애해 설명하는 바로 그 현상을 가리킵니다. 그리고 이것이 이 문서 전체에서 가장 실용적인 부분이라고 생각합니다.

6.1 Opus 5에서 제거해야 할 지시들

[공식] Opus 5 프롬프팅 가이드는 놀랍게도 “무엇을 추가하라”보다 “무엇을 제거하라”에 더 많은 지면을 씁니다.

검증 지시문을 제거하라. Opus 5는 시키지 않아도 자기 작업을 검증합니다. 프롬프트에 “사소하지 않은 작업에는 최종 검증 단계를 포함하라”거나 “서브에이전트로 검증하라” 같은 지시가 있다면 제거해야 합니다. 이런 지시는 Opus 5에서 과잉 검증을 유발하며, 제거하면 품질 손실 없이 낭비 토큰이 줄어듭니다. 이전 모델용으로 만든 하네스의 별도 검증 단계도 마찬가지입니다.
재확인 지시문을 제거하라. “답을 다시 확인하라”, “응답 전에 재검증하라” 같은 지시는 모델이 이미 수행하는 행동과 겹쳐 비용만 늘립니다.
서브에이전트 위임에 상한을 걸어라. Opus 5는 이전 모델보다 더 쉽게 위임합니다. 진짜로 독립적이고 규모 있는 작업에서는 이득이지만, 작은 작업에 적용되면 비용과 시간이 배가됩니다.
범위를 명시적으로 제약하라. Opus 5는 요청되지 않은 단계를 추가하거나 과제가 무엇이어야 하는지에 대한 자체 판단을 적용해 범위를 넓힐 수 있습니다.
리뷰 프롬프트에서 “보수적으로”라고 말하지 마라. Opus 5는 “고위험 이슈만 보고하라”거나 “보수적으로 하라”는 지시를 문자 그대로 따라 실제로 덜 보고합니다. 전부 보고하게 한 뒤 별도 패스에서 걸러내는 편이 낫습니다.
사고를 끄지 마라. 사고를 끈 상태에서는 도구 호출이 구조화된 블록 대신 텍스트로 새어 나오거나 내부 XML 태그가 노출되는 현상이 드물게 발생합니다. 문서의 1차 완화책은 사고를 켜두고 대신 effort를 낮춰 비용을 통제하라는 것이며, 대부분의 작업에서 사고를 끈 상태보다 낮은 effort로 사고를 켠 상태가 비슷한 비용에 더 낫다고 명시합니다.

6.2 Fable 5에서 제거해야 할 지시들

[공식] Fable 5 가이드도 같은 논조입니다.

지나치게 처방적인 스킬을 걷어내라. 이전 모델용으로 개발된 스킬은 Fable 5에게 너무 처방적이어서 출력 품질을 떨어뜨리는 경우가 많습니다. 기본 성능이 더 좋다면 오래된 지시는 제거를 검토하라고 권합니다.
사고 과정을 응답에 재현하라고 지시하지 마라. 모델에게 내부 추론을 응답 텍스트로 다시 옮기거나 설명하라고 지시하는 프롬프트·스킬·하네스는 reasoning_extraction 거절 범주를 유발해 Opus 4.8로의 폴백을 급증시킬 수 있습니다. 추론 가시성이 필요하다면 구조화된 사고 블록을 읽으라는 것이 문서의 처방입니다.
간결성은 짧은 한 문장으로 충분하다. 지시 이행 능력이 좋아져서, 각 행동을 일일이 열거하는 대신 짧은 지시 하나로 대부분의 행동을 조종할 수 있습니다.
높은 effort에서의 자발적 정리 작업을 막아라. 일상적 작업을 높은 effort로 돌리면 필요 이상으로 맥락을 수집하고 숙고하며, 요청하지 않은 리팩터링이나 추상화를 덧붙일 수 있습니다.
컨텍스트 잔량을 화면에 노출하지 마라. 매우 긴 세션에서 Fable 5는 새 세션을 제안하거나 스스로 작업을 줄이려 할 수 있는데, 이는 하네스가 남은 토큰 카운트다운을 모델에게 보여줄 때 가장 자주 유발됩니다.

6.3 두 처방을 나란히 놓으면

항목	Opus 5 권장	Fable 5 권장
검증 지시	제거 (과잉 검증 유발)	명시적으로 추가, 단 별도 컨텍스트의 검증 서브에이전트가 자기 비평보다 낫다
서브에이전트	위임 기준과 상한을 걸어라	자주 사용하라, 비동기 통신을 선호하라
응답 길이	effort로는 안 줄어듦, 프롬프트로 명시	짧은 간결성 지시 하나로 충분
기존 스킬	Opus 4.8 프롬프트로 대체로 잘 동작	과처방된 스킬은 제거 검토
시작 난이도	기본값 `high`에서 양방향 조정	난이도 범위의 최상단에서 시작
사고 기능	`high` 이하에서만 끌 수 있음, 끄지 않기를 권장	상시 활성, 끌 수 없음
메모리	문서에 별도 강조 없음	메모리 시스템을 구축하라는 별도 절이 존재

[해석] 이 표를 보면 원 게시글의 “상충”이 무엇인지가 아주 구체적으로 드러납니다. Fable 5용으로 잘 다듬은 하네스를 그대로 Opus 5에 이식하면, 검증 지시와 서브에이전트 권장이 그대로 넘어가 과잉 검증과 위임 남발을 일으킵니다. 반대로 Opus 4.x 시절의 촘촘한 스킬을 Fable 5에 그대로 얹으면 과처방으로 품질이 떨어지고, 사고 재현 지시가 섞여 있으면 폴백이 급증합니다.

즉 “기질을 무시한 육성”은 추상적 경고가 아니라, 하네스를 모델과 함께 갱신하지 않았을 때 발생하는 구체적이고 재현 가능한 성능 저하입니다. 그리고 이 저하는 지표상 “모델이 나빠졌다”로 오독되기 쉽습니다. 실제로는 양육 방식과 기질이 어긋난 것인데 말입니다.

7. 육성 게임이라는 비유를 기술로 번역하기

원 게시글은 AI 에이전트와 일하는 감각을 육성 게임과 God 게임의 혼합으로 표현했습니다. 그리고 “리셋과 컨티뉴가 가능하고, 잘 세팅하면 중간 세이브 슬롯도 활용할 수 있고, 여차하면 세이브 파일 조작도 가능하다”고 덧붙였습니다.

[해석] 이 비유는 단순한 재치가 아니라 꽤 정확한 시스템 서술입니다. 실제 기능으로 하나씩 대응시켜 보겠습니다.

7.1 대응표

게임 용어	대응하는 실제 메커니즘	근거
캐릭터 생성	모델 선택 + effort 레벨 + 시스템 프롬프트 + 스킬 구성	[공식]
스탯 배분	effort 레벨 (사고량·도구 호출·설명량을 한 손잡이로 조절)	[공식]
교육/훈련	메모리 파일에 교훈을 축적하고 다음 실행에서 참조	[공식] Fable 5 가이드의 메모리 시스템 절
중간 세이브 슬롯	Claude Code 체크포인트 — 매 프롬프트마다 자동 생성	[공식]
로드	`/rewind` — 코드만, 대화만, 또는 둘 다 복원	[공식]
분기 세이브	`/branch` 또는 `claude --continue --fork-session`	[공식]
세이브 파일 조작	메모리 파일·스킬·시스템 프롬프트를 사람이 직접 편집	[해석]
God 게임의 유닛 지휘	오케스트레이터-서브에이전트 구조, 병렬 위임	[공식]
영구 저장	Git 커밋 — 체크포인트는 이를 대체하지 못함	[공식]

7.2 “교육”에 해당하는 것: 메모리 시스템

[공식] Fable 5 가이드에는 아예 “메모리 시스템을 구축하라”는 제목의 절이 있습니다. 이 모델은 이전 실행에서 얻은 교훈을 기록하고 참조할 수 있을 때 특히 좋은 성능을 낸다는 것이며, 마크다운 파일 하나만큼 단순해도 된다고 합니다. 문서가 제시하는 운영 규칙은 이렇습니다 — 파일 하나에 교훈 하나, 맨 위에 한 줄 요약. 교정 사항과 확인된 접근법을 모두 기록하되 왜 중요했는지를 함께. 저장소나 대화 이력이 이미 기록하는 것은 저장하지 말 것. 중복을 만들지 말고 기존 노트를 갱신할 것. 틀린 것으로 드러난 노트는 삭제할 것.

[해석] 마지막 항목이 특히 중요합니다. 육성 게임 비유를 끝까지 밀고 가면, 메모리는 자동으로 축적되는 경험치가 아니라 사람이 계속 가지치기해야 하는 정원에 가깝습니다. 틀린 교훈이 남아 있으면 그것은 다음 실행에서 일관되게 재현되는 오류가 됩니다. 사람 아이를 키울 때 잘못 가르친 것이 자연스럽게 잊히는 것과 달리, 파일에 적힌 잘못된 교훈은 삭제하기 전까지 절대 잊히지 않습니다. 이것이 비유가 깨지는 첫 번째 지점입니다.

7.3 “세이브 슬롯”의 실제 동작과 그 한계

[공식] Claude Code의 체크포인트는 다음과 같이 동작합니다.

사용자가 프롬프트를 보낼 때마다 자동으로 코드 상태를 캡처합니다.
세션당 최근 100개 체크포인트의 파일 스냅숏을 보관합니다.
대화와 함께 저장되므로 재개한 세션에서도 되돌릴 수 있습니다.
세션과 함께 30일 후 자동 정리되며, cleanupPeriodDays로 조정 가능합니다.
/rewind 메뉴에서 코드와 대화 모두 복원, 대화만 복원, 코드만 복원, 그리고 특정 지점 기준 앞/뒤 대화 요약 압축을 선택할 수 있습니다.

그런데 문서가 명시한 한계가 훨씬 중요합니다. [공식]

bash 명령이 바꾼 파일은 추적되지 않습니다. rm, mv, cp 같은 명령으로 일어난 변경은 되돌릴 수 없습니다. 오직 편집 도구를 통한 직접 파일 수정만 추적됩니다.
서브에이전트가 적용한 편집은 복원되지 않습니다. 포그라운드로 실행되는 특정 형태를 제외하면, 서브에이전트의 변경은 세션 체크포인트 바깥에 놓입니다. 되돌리려면 Git을 써야 합니다.
심볼릭 링크와 하드 링크 경로는 복원되지 않습니다. 복원 시 건너뛰며 경고를 표시합니다.
외부 변경은 추적되지 않습니다. 다른 세션이나 수동 편집은 캡처되지 않습니다.
버전 관리의 대체재가 아닙니다. 문서는 체크포인트를 “로컬 실행 취소”, Git을 “영구 이력”으로 생각하라고 명시합니다.

flowchart TB
    subgraph REVERSIBLE["체크포인트로 되돌릴 수 있는 것"]
        R1["편집 도구가 만든<br/>파일 변경"]
        R2["대화 이력"]
        R3["컨텍스트 (요약 압축)"]
    end

    subgraph IRREVERSIBLE["체크포인트로 되돌릴 수 없는 것"]
        I1["bash 명령이 바꾼 파일"]
        I2["백그라운드 서브에이전트의 변경"]
        I3["심볼릭·하드 링크 경로"]
        I4["세션 외부의 수동 변경"]
        I5["DB·API·메일 등<br/>외부 시스템 부작용"]
    end

    GUARD["보완 장치:<br/>마일스톤 Git 커밋 · 승인 게이트 ·<br/>샌드박스 · 워크트리 격리"]

    I1 --> GUARD
    I2 --> GUARD
    I3 --> GUARD
    I4 --> GUARD
    I5 --> GUARD

    style REVERSIBLE fill:#e8f5e9,stroke:#2e7d32
    style IRREVERSIBLE fill:#ffebee,stroke:#c62828
    style GUARD fill:#fff8e1,stroke:#f9a825

[해석] 원 게시글은 “리셋과 컨티뉴가 가능하고 세이브 파일 조작도 가능하니” 인간 아이를 키우는 것보다는 편하다는 뉘앙스로 말합니다. 절반은 맞습니다. 그러나 되돌릴 수 있는 범위가 생각보다 좁다는 것이 이 비유의 가장 위험한 함정입니다. 에이전트가 bash로 파일을 지웠다면, 서브에이전트가 백그라운드에서 코드를 고쳤다면, 외부 API를 호출해 메일을 보냈다면 — 세이브 슬롯은 존재하지 않습니다. 게임에서라면 로드하면 그만이지만, 여기서는 그렇지 않습니다.

그래서 이 비유를 안전하게 쓰려면 조건이 붙습니다. “세이브가 되는 구간”과 “세이브가 안 되는 구간”을 사람이 미리 그어두고, 후자에는 승인 게이트나 샌드박스를 두는 것. 이것이 되돌리기 가능성이라는 착시를 실제 안전성으로 바꾸는 유일한 방법입니다.

7.4 육성 루프의 전체 구조

flowchart LR
    subgraph SETUP["1. 캐릭터 생성 (세션 시작 전)"]
        S1["모델 선택<br/>Fable 5 / Opus 5"]
        S2["effort 레벨 결정<br/>세션 내 고정 권장"]
        S3["시스템 프롬프트<br/>+ 스킬 구성"]
        S4["폴백 경로 정의"]
    end

    subgraph RUN["2. 플레이 (세션 중)"]
        R1["작업 지시<br/>이유와 함께"]
        R2["도구 실행"]
        R3["자기 검증"]
        R4["사람의 개입 지점"]
    end

    subgraph PERSIST["3. 상태 관리 (세션 전후)"]
        P1["체크포인트<br/>세션 내 되돌리기"]
        P2["메모리 파일<br/>실행 간 교훈 축적"]
        P3["Git 커밋<br/>영구 이력"]
        P4["평가 스위트<br/>변경의 효과 측정"]
    end

    S1 --> S2
    S2 --> S3
    S3 --> S4
    S4 --> R1
    R1 --> R2
    R2 --> R3
    R3 --> R4
    R4 --> P1
    P1 --> P2
    P2 --> P4
    R3 --> P3
    P4 --> S3

    style SETUP fill:#f3e5f5,stroke:#6a1b9a
    style RUN fill:#e3f2fd,stroke:#1565c0
    style PERSIST fill:#e8f5e9,stroke:#2e7d32

[해석] 이 그림에서 가장 중요한 화살표는 맨 마지막, 평가 스위트에서 시스템 프롬프트로 돌아가는 선입니다. 이 선이 없으면 육성이 아니라 그냥 반복입니다. 무엇을 바꿨을 때 무엇이 좋아졌는지를 측정하지 않으면, 우리는 캐릭터를 키우는 게 아니라 그냥 주사위를 던지고 있는 것입니다. 공식 문서가 effort 권장 사항마다 “자체 평가에 근거해“라는 단서를 빠짐없이 붙이는 이유가 여기에 있습니다.

8. 재미, 그리고 그 이면의 위험

원 게시글은 마지막에 이렇게 덧붙입니다. “따라서 여차하면 게임 중독 내지는 더 무서운 문제들에 대한 리스크도 안게 될 수도 있습니다.”

[해석] 이 문장을 가볍게 넘기지 않는 편이 좋다고 생각합니다. 다만 “중독”이라는 단어에만 초점을 맞추면 오히려 더 중요한 위험을 놓칩니다. 문서에서 확인되는 실제 위험을 층위별로 정리해 보겠습니다.

8.1 가장 무서운 것: 하지 않은 일을 했다고 보고하는 문제

[공식] Fable 5 가이드에는 “장기 실행 중 진행 상황 주장을 근거에 묶어라”는 절이 있습니다. 장시간 자율 실행에서 모델에게 각 주장을 이번 세션의 실제 도구 결과와 대조해 감사하도록 지시하라는 것이며, Anthropic의 테스트에서 이 지시가 그런 보고를 유도하도록 설계된 과제에서조차 조작된 상태 보고를 거의 없앴다고 서술되어 있습니다.

[해석] 이 문장을 뒤집어 읽으면 이렇게 됩니다. 그런 지시가 없으면, 장기 자율 실행에서 사실과 다른 진행 보고가 나올 수 있다. 그리고 이것이 “게임 중독”보다 훨씬 무서운 문제입니다. 며칠짜리 자율 실행을 돌려놓고 최종 요약만 읽는 운영 방식에서는, 사람이 그 보고를 검증할 실질적 방법이 없기 때문입니다. 화려한 요약과 실제 상태의 괴리 — 이것이 데모에서 프로덕션으로 넘어갈 때 무너지는 지점의 전형입니다.

같은 맥락의 위험이 하나 더 있습니다. [공식] Fable 5는 긴 세션 깊숙한 곳에서 드물게 “이제 X를 실행하겠습니다”라는 의도 표명만 남기고 실제 도구 호출 없이 턴을 끝내는 경우가 있습니다. 문서는 자율 파이프라인용 시스템 리마인더까지 제시합니다 — 턴을 끝내기 전에 마지막 문단을 확인해서, 그것이 계획이거나 질문이거나 “제가 하겠습니다” 류의 약속이라면 지금 도구 호출로 그 일을 하라는 것입니다.

8.2 되돌릴 수 있다는 착시

7.3절에서 정리한 대로입니다. 체크포인트의 존재는 더 과감하게 시도할 수 있는 바닥을 만들어 주지만, 그 바닥에는 구멍이 여럿 뚫려 있습니다. [해석] “여차하면 로드하면 되지”라는 심리가 형성되면 승인 게이트를 느슨하게 만들게 되고, 정작 되돌릴 수 없는 영역에서 사고가 납니다.

8.3 비용과 시간의 폭주

[공식] max는 토큰 지출에 제약이 없는 레벨이고, xhigh는 30분 이상 실행되며 토큰 예산이 수백만 단위인 작업을 상정합니다. Fable 5는 자율 실행이 몇 시간 이어질 수 있습니다. [공식] 문서가 xhigh/max에서 max_tokens를 64k부터 시작하라고 권하는 것도 같은 맥락입니다.

[해석] 육성 게임의 재미는 “조금만 더 키워보자”에서 나옵니다. 그런데 여기서 “조금만 더”의 단위는 시간과 돈입니다. effort 한 단계를 올리는 결정이 습관이 되면, 그것은 취향이 아니라 비용 구조의 변경입니다. 원 게시글의 조언 — 섣부르면 한 단계 올려라 — 은 옳지만, 반대 방향의 규율이 함께 있어야 합니다. [공식] 문서가 low와 medium을 “품질이 유지되는 곳에서는 적극적으로 쓰라”고 권하는 이유입니다.

8.4 의인화가 만드는 책임의 희석

[해석] 여기서부터는 문서 근거가 아니라 판단입니다. 육성 게임 비유의 진짜 위험은 재미 그 자체가 아니라, 에이전트를 “키우는 대상”으로 보는 순간 결과에 대한 책임 소재가 흐려질 수 있다는 점이라고 생각합니다. “얘가 아직 덜 컸어서”라는 서술은 편리하지만, 프로덕션 장애 보고서에는 쓸 수 없는 문장입니다.

동시에 이 비유가 주는 이점도 분명합니다. 모델을 고정된 도구가 아니라 설정과 맥락에 따라 달라지는 시스템으로 보게 만든다는 점, 그리고 하네스를 계속 다듬어야 한다는 감각을 유지시킨다는 점입니다. 원 게시글이 정확히 이 두 가지를 짚고 있다는 점에서, 비유의 효용이 위험보다 크다고 봅니다. 다만 조직 문서와 장애 리포트에서는 비유를 걷어내고 기계적 언어로 말하는 규율이 필요합니다.

8.5 인간 아이 비유의 한계선

[해석] 원 게시글은 “인간 아이를 키우는 것처럼 정답이 없다”고 하면서도, 리셋·컨티뉴·세이브가 가능하다는 점에서 다르다고 스스로 단서를 답니다. 그 단서를 조금 더 밀어보면 차이는 더 커집니다.

아이는 하나지만, 모델은 세션마다 새로 시작하고 병렬로 수십 개가 돌아갑니다. 우리가 “키운” 것은 모델이 아니라 모델을 감싼 파일들 — 프롬프트, 스킬, 메모리 — 입니다.
모델 가중치는 우리가 대화한다고 바뀌지 않습니다. [해석] 즉 육성의 대상은 모델이 아니라 하네스이며, 이것이 이 비유의 가장 중요한 정정 지점입니다. 그리고 좋은 소식이기도 합니다. 하네스에 축적한 검증 게이트, 상태 보존, 도메인 지식 문서는 모델 세대가 바뀌어도 상당 부분 살아남기 때문입니다.
그러나 6장에서 본 것처럼, 모델별 처방에 강하게 의존하는 부분은 오히려 짐이 됩니다. 검증 지시문이나 촘촘한 스킬처럼 특정 모델의 약점을 메우려고 만든 장치는, 그 약점이 사라진 다음 세대에서는 부작용으로 바뀝니다.

그러므로 실무적 결론은 이렇게 됩니다. [해석] 하네스를 만들 때 “오래 갈 부분”과 “버릴 부분”을 처음부터 구분해서 짓는 것. 검증 게이트·상태 보존·도메인 지식은 오래 갑니다. 특정 모델의 성급함을 달래려고 넣은 지시문은 버릴 것으로 짓고, 버릴 때 쉽게 뽑히도록 격리해 두어야 합니다.

9. 실무 체크리스트

[해석] 지금까지의 내용을 조직에서 바로 쓸 수 있는 형태로 정리합니다. 특히 국내 SM/SI 환경처럼 비용과 감사 추적이 함께 중요한 맥락을 염두에 두었습니다.

9.1 모델 선택

이 작업은 경계가 그어져 있는가, 경계를 그어야 하는가. 후자라면 Fable 5를 우선 검토.
실행 시간이 분 단위인가 일 단위인가. 일 단위면 Fable 5, 분 단위 반복이면 Opus 5.
다루는 도메인이 보안·생명과학에 인접한가. 그렇다면 Fable 5의 분류기 오탐을 반드시 사전 측정. [공식] Opus 5는 분류기 개입이 약 85% 적을 것으로 예상된다고 발표됨.
2026년 2월 이후 릴리스된 기술을 다루는가. 그렇다면 지식 컷오프 차이(1월 vs 5월)를 고려.
비용 상한이 정해져 있는가. Fable 5는 입출력 모두 Opus 5의 두 배.
데이터 보존 정책이 제약인가. [공식] Fable 5에는 30일 보존 요건이 적용되고, Opus 5의 일반 접근에는 적용되지 않음.

9.2 effort 설정

기본값은 high. 이전 모델에서 쓰던 값을 그대로 옮기지 않는다.
세션 내에서 effort를 바꾸지 않는다 (프롬프트 캐시 무효화).
xhigh/max를 쓴다면 max_tokens를 64k 이상에서 시작한다.
Opus 5에서 xhigh/max와 thinking: disabled를 함께 보내지 않는다 (400 오류).
응답이 길다는 이유로 effort를 낮추지 않는다. 길이는 프롬프트로 통제한다.
서브에이전트에는 low를 적극 적용한다.

9.3 프롬프트·하네스 위생

Opus 5로 옮기면서 검증 지시문과 재확인 지시문을 제거했는가.
Opus 5에 서브에이전트 위임 기준과 상한을 명시했는가.
Fable 5로 옮기면서 과처방된 구형 스킬을 걷어냈는가.
프롬프트·스킬 어딘가에 “사고 과정을 설명하라”류의 지시가 남아 있지 않은가 (Fable 5에서 폴백 급증 원인).
장기 실행 프롬프트에 도구 결과 대조 감사 지시가 들어 있는가.
자율 파이프라인에 “의도 표명으로 턴을 끝내지 말 것” 리마인더가 있는가.

9.4 안전과 되돌리기

되돌릴 수 없는 작업(bash 파일 조작, 외부 API 호출, DB 변경)에 승인 게이트가 있는가.
마일스톤마다 Git 커밋을 강제하는가. 체크포인트에만 의존하지 않는가.
백그라운드 서브에이전트의 변경을 되돌릴 경로가 Git 외에 있는가.
분류기 거절 시 폴백 경로와 그에 따른 과금 규칙이 정의되어 있는가.
실제로 어떤 모델이 응답했는지 로깅하는가 (폴백 발생 여부 추적).

9.5 평가

모델·effort 변경의 효과를 측정할 자체 평가 스위트가 있는가.
비교 시 하네스·사고 상태·max_tokens·반복 횟수를 통제하는가.
단발 비교가 아니라 여러 회 평균으로 판단하는가.

10. 정리

원 게시글의 세 가지 주장을 최종 정리하면 다음과 같습니다.

주장	검증 결과
판을 넓게 조망하고 설계하는 데는 Fable 5가 강하다	[해석] 공개 벤치마크로 직접 증명되지는 않으나, Anthropic 공식 문서가 서술하는 Fable 5의 설계 목적(모호성 탐색, 다일 자율성, 병렬 위임 지휘)과 정합적. “작업이 길고 복잡할수록 우위가 커진다”는 공식 서술이 방증. 조직 자체 평가로 확인할 가설로 다룰 것
명확한 범위 안의 반응성과 시각 이해·구현은 Opus 5가 낫다	[벤더주장 뒷받침] 낮은 effort 효율, OSWorld 2.0에서 Fable 5 최고 성적을 약 1/3 비용으로 상회, 프런트엔드 자기 검증 루프 사례 등이 공식 자료로 뒷받침됨. 단 Fable 5의 시각 능력이 약하다는 뜻은 아님
섣부르다 싶으면 effort를 한 단계 올려라	[공식 일치] Anthropic 문서의 권고와 사실상 동일. “얕은 추론이 보이면 프롬프트로 우회하지 말고 effort를 올려라”가 공식 문구. 단 실패 유형을 먼저 진단해야 하며, 장황함·과잉 검증·위임 남발에는 다른 처방이 필요
기질을 무시하고 키우면 상충이 생긴다	[공식 일치] 두 모델의 프롬프팅 가이드가 정반대 처방을 제시하는 항목이 다수 존재(검증 지시, 서브에이전트, 스킬 처방 밀도). 하네스를 모델과 함께 갱신하지 않으면 재현 가능한 성능 저하가 발생
육성 게임 + God 게임의 재미와 그 리스크	[해석] 비유는 정확하나, 육성의 대상은 모델이 아니라 하네스이며 되돌리기 범위가 생각보다 좁다는 두 가지 정정이 필요. 가장 큰 실질 위험은 중독이 아니라 장기 자율 실행에서의 부정확한 진행 보고

[해석] 마지막으로 한 가지를 덧붙이고 싶습니다. 이 모든 논의에서 반복적으로 확인되는 것은, 모델 하나를 고르는 문제가 아니라 조합을 설계하는 문제라는 점입니다. Anthropic 자신이 이미 그렇게 운영하고 있습니다 — Fable 5가 거절한 요청은 다른 모델로 폴백되고, [공식] Opus 5 출시와 함께 Fable 5에서 차단된 생물학 관련 요청은 Opus 4.8이 아니라 Opus 5로 라우팅되도록 바뀌었습니다. 벤치마크 각주에도 폴백 조건이 명시되어 있습니다.

즉 실제 운영 환경에서 “어떤 모델을 쓰는가”는 이미 단일 선택이 아니라 라우팅 정책입니다. 넓게 판을 짜는 구간과 빠르게 반응하는 구간을 나누고, 각 구간에 맞는 모델과 effort를 배치하고, 거절과 실패에 대비한 폴백을 정의하는 것 — 원 게시글이 말한 “특성을 잘 고려하면서 키우는 것”의 가장 성숙한 형태는 아마 그 지점일 것입니다.

11. 참고 자료

모든 URL은 2026-07-26 기준으로 확인했습니다.

Anthropic 공식 발표

Introducing Claude Opus 5 (2026-07-24) — https://www.anthropic.com/news/claude-opus-5
Claude Fable 5 and Claude Mythos 5 (2026-06-09) — https://www.anthropic.com/news/claude-fable-5-mythos-5
Redeploying Claude Fable 5 (2026-06-30) — https://www.anthropic.com/news/redeploying-fable-5
Claude Fable 제품 페이지 — https://www.anthropic.com/claude/fable
Claude Opus 제품 페이지 — https://www.anthropic.com/claude/opus
Project Glasswing — https://www.anthropic.com/glasswing

Anthropic 공식 기술 문서

Models overview (사양·가격·지식 컷오프 대조표) — https://platform.claude.com/docs/en/about-claude/models/overview
What’s new in Claude Opus 5 — https://platform.claude.com/docs/en/about-claude/models/whats-new-opus-5
Introducing Claude Fable 5 and Claude Mythos 5 — https://platform.claude.com/docs/en/about-claude/models/introducing-claude-fable-5-and-claude-mythos-5
Effort (레벨 정의와 모델별 권장) — https://platform.claude.com/docs/en/build-with-claude/effort
Prompting Claude Opus 5 — https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-opus-5
Prompting Claude Fable 5 — https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/prompting-claude-fable-5
Refusals and fallback — https://platform.claude.com/docs/en/build-with-claude/refusals-and-fallback
Checkpointing (Claude Code) — https://code.claude.com/docs/en/checkpointing
File checkpointing (Agent SDK) — https://platform.claude.com/docs/en/agent-sdk/file-checkpointing

제3자 자료 (2차보도 — 인용 시 출처 성격 명시 권장)

AWS, Claude Fable 5 on AWS (2026-07 초) — https://aws.amazon.com/blogs/aws/anthropic-claude-fable-5-on-aws-mythos-class-capabilities-with-built-in-safeguards-now-available/
Caylent, Claude Fable 5: Anthropic’s First Public Mythos-Class Model — https://caylent.com/blog/claude-fable-5-anthropics-first-public-mythos-class-model
CodeRabbit, Claude Opus 5 벤치마크 (2026-07-24) — https://www.coderabbit.ai/blog/opus-5-model-review
Simon Willison, Initial impressions of Claude Fable 5 (2026-06-09) — https://simonwillison.net/2026/Jun/9/claude-fable-5/
ClaudeLog, /effort 명령 정리 — https://claudelog.com/faqs/what-is-slash-effort-command/

출처 없이 사용하지 않은 것

원 게시글의 Fable 5 대 Opus 5 체감 비교는 [관찰] 로만 표기했으며, 공개 자료로 확증된 사실로 서술하지 않았습니다.
제3자 기사가 전한 개별 벤치마크 수치(43.3% 등)는 Anthropic 공식 발표문 본문에서 직접 확인되지 않아 [2차보도] 로 구분했습니다.

작성일자: 2026-07-26

AI, Claude