Claude Fable 5는 미국의 수출 통제로 인한 3주간의 중단 이후 7월 1일에 강력하게 복귀했습니다. 48시간 이내에 반응은 두 개의 명확한 진영으로 나뉘었습니다.

첫 번째 진영은 인생의 LAN 파티 단계를 결코 벗어나지 못한 성인들로, Rocket League 클론 게임을 한 번에 만들어내거나 재건된 Hogwarts를 날아다닙니다. 한 데모는 플레이 가능한 프로토타입을 제작하는 데 4번의 프롬프트(prompt)와 173달러 상당의 토큰(token)이 필요했다고 보고되었습니다.

두 번째 진영은 점심 식사 전에 한 달 치 크레딧을 다 써버리지 않으면서, 어떻게 동일한 모델을 실제 수익으로 전환할 수 있을지 고민하고 있습니다. 저도 제가 바로 두 번째 진영에 속한다고 말하고 싶지만, 그렇지 않았습니다. 저는 도대체 무엇이 화제인지 확인하기 위해 Ultracode를 켰고, 범위(scope)가 거의 없는 작업을 부여했다가 단 몇 분 만에 제 월간 할당량(monthly quota)이 녹아내리는 것을 지켜보았습니다. 극적인 'You Died' 화면은 없었습니다. 그저 사용량 대시보드에 조용히 0%가 떠 있을 뿐이었습니다.

그래서 Claude Fab(ulous?)를 실제로 가장 잘 활용하는 방법은 다음과 같습니다.

Ultracode가 실제로 하는 일

Ultracode는 API의 노력 수준(effort level)이 아닙니다. 이것은 Claude Code 전용 설정이며, 이 둘을 혼동한 것이 제가 이 상황에 처하게 된 정확한 이유입니다.

문제가 된 프롬프트는 다음과 같았습니다: "결제 흐름(checkout flow)을 정리해 줘, 엉망이야." 어떤 파일인지에 대한 언급도 없었습니다. "정리(clean up)\

API의 경우, Fable 5는 입력 토큰 100만 개당 $10, 출력 토큰 100만 개당 $50의 비용이 발생하며, 이는 Opus 4.8 비용의 대략 2배 수준입니다. 단일 모델이 작업을 수행할 때는 이러한 프리미엄(premium)이 괜찮을 수 있습니다. 하지만 Ultracode가 사용자의 작업을 처리하기 위해 소규모 군단이 필요하다고 판단하여, 단 1개의 요청을 12개의 병렬 요청으로 조용히 전환해 버릴 때는 더 이상 괜찮지 않습니다.

제 할당량을 태워버린 정확한 메커니즘(매우 높은 추론(xhigh reasoning) 및 비감독 하의 서브 에이전트 생성(unsupervised subagent spawning))은, 이미 범위가 정해진 실제 작업에서 Ultracode가 프리미엄을 지불할 가치가 있게 만드는 바로 그 메커니즘과 동일합니다. 40개 파일에 걸친 지저분한 리팩터링(refactor)이나 전체 코드베이스 감사(audit)를 생각해 보십시오. Ultracode는 위임(delegating)을 통해 실패한 것이 아닙니다. 제가 Ultracode에게 무엇을 위임해도 되는지 알려주지 않았기 때문에 실패한 것입니다.

저는 이전에 4시간 동안 비감독 상태로 실행되도록 방치했던 Claude Code 세션을 통해, 비싼 대가를 치르며 이 교훈을 배웠습니다. 범위 이탈(scope drift)을 방지하는 3가지 핵심 요소는 1개의 루프(loop)에서나 12개의 서브 에이전트가 병렬로 실행될 때나 똑같이 중요하다는 사실이 밝혀졌습니다.

저만 그런 것이 아니었습니다

API 할당량 소모: 세 가지 플랜이 서로 다른 한계치에 도달함

동일한 48시간 동안 Hacker News와 r/ClaudeAI를 살펴보니 저와 비슷한 처지의 사람들이 아주 많았습니다.

이것들은 측정된 평균값이 아니라 포럼 스레드에서 수집된 흩어진 일화들일 뿐이며, 통제된 벤치마크(benchmark)는 아닙니다. 하지만 모든 사례에서 일정한 패턴이 나타났습니다. 불만 사항은 출력 품질에 관한 것이 아니었습니다. 작업이 이미 완료된 후에도 계량기가 계속 돌아가고 있다는 점이 문제였습니다.

그럼에도 불구하고, 이 정도 규모의 할당량 소모는 단순한 오차 범위가 아닙니다. Max 플랜의 경우, 일주일 할당량의 20%가 하루 만에 사라진다는 것은 다음 리셋이 오기 훨씬 전에 할당량이 바닥난다는 것을 의미합니다. Pro 플랜의 경우, 10분 만에 한도에 도달하면 남은 하루 동안 모델을 전혀 사용할 수 없게 됩니다.

다른 진영: 비디오 게임을 원샷(One-Shotting)하기

나의 할당량 바(quota bar)가 실시간으로 줄어드는 동안, 인터넷의 나머지 사람들은 훨씬 더 즐거운 오후를 보내고 있었습니다.

Rocket League 클론은 평소 AI 데모를 보며 눈을 굴리던 사람들로부터조차 찬사를 받았습니다. 재구성된 Hogwarts의 한 조각과, 앞서 언급했던 4개의 프롬프트(prompt)와 173달러 상당의 토큰(token)으로 만들어진 게임도 마찬가지였습니다. 1 widely watched test에서는 Fable 5와 Opus 4.8을 정확히 동일한 프롬프트로 정면 대결시켰습니다. 또 다른 사례는 한계치가 어디인지 확인하기 위해 단 한 번의 Ultracode 세션에 100달러를 태우기도 했습니다.

(저의 Rocket League 시대는 Diamond 랭크 근처에서 정점을 찍었습니다. 배포(deploy) 작업이 예전에 랭크 게임 대기열에 머물며 보내던 시간들을 잡아먹기 시작하기 전의 일입니다. 그 반사 신경이 그립지는 않습니다. 다만 무엇인가를 위해 방해받지 않는 40분을 가질 수 있었던 그때가 그립습니다.)

이러한 데모 중 일부는 진심으로 인상적이며, 2년 전이라면 소규모 팀이 프로토타입(prototype)을 만드는 데 한 스프린트(sprint)가 걸렸을 법한 수준입니다. 저의 문제는 캠프 1의 취향이 아니었습니다. 문제는 작동하는 게임 프로토타입과 유료 고객은 매우 다른 결과물(deliverable)이며, 다음 달 인보이스(invoice)에 비용이 아닌 매출로 찍히는 것은 오직 후자뿐이라는 점입니다.

지시의 역설 (The Instruction Paradox)

패닉이 가라앉은 후 제가 가장 먼저 알아차린 것은 Fable 5는 당신에게 더 많은 것을 요구하는 것이 아니라, 더 적은 것을 원한다는 사실이었습니다.

이전의 모든 Claude 모델은 더 길고 상세한 프롬프트에 보상을 주었습니다. 더 많은 컨텍스트(context), 더 많은 제약 조건(constraints)이 더 나은 출력(output)을 만든다는 것이 지난 2년간의 경험칙이었습니다. Fable 5는 이 규칙을 깨뜨립니다. 초정밀 지시 사항, 단계별 제약 조건, 사전에 명시된 예외 케이스(edge cases)로 프롬프트를 가득 채우면, 출력 결과는 더 좋아지기는커녕 오히려 나빠지는 경우가 많습니다. 모델이 눈앞의 실제 문제를 해결하는 대신, 당신이 작성한 모든 조항을 만족시키는 데 최적화(optimizing)되기 시작하기 때문입니다.

이는 프로젝트 전체에 Ultracode를 켤 것인지에 대한 거시적인 결정이 아니라, 세션 중간에 단일 지시사항을 어떻게 표현하느냐와 같은 일상적인 문제입니다. 이는 또한 Anthropic의 자체 프롬프팅 (prompting) 문서에서 모델에 대해 설명하는 내용과도 일치합니다. 즉, 더 짧고 명확한 지시사항이 철저하고 방대한 지시사항보다 더 나은 성능을 보이는 경향이 있다는 것입니다. 제가 3주간의 세션을 지나치게 깊게 해석하는 것일 수도 있지만, 모델은 세부 사항(detail)에 대한 보상보다 신뢰(trust)에 더 큰 보상을 주는 것처럼 느껴집니다.

Anthropic이 말하는 것 (그리고 내가 건너뛴 것)

노력 수준 (effort levels)에 대한 Anthropic의 자체 문서는 이 점에 대해 매우 직설적입니다. 낮음(low) 또는 중간(medium) 노력 수준으로 실행되는 Fable 5가 매우 높음(xhigh) 수준으로 실행되는 이전 모델들을 빈번하게 능가한다는 것입니다. 공식적인 권장 사항은

Ultracode가 그 가치를 완전히 증명했던 단 한 가지 작업은 2년 동안 방치되었던 파트너 API 연동(integration)을 감사(auditing)하는 것이었습니다. 수십 개의 엔드포인트(endpoints), 일관성 없는 에러 처리(error handling), 그리고 3개의 서로 다른 모듈에 중복되어 있는 재시도 로직(retry logic)까지. 저는 먼저 범위를 설정(scoped)했습니다. 관련된 모든 파일, 모든 제약 조건, 웹훅 시그니처(webhook signatures)는 건드리지 말 것, 재시도 타임아웃(retry timeouts)은 변경하지 말 것, 결제 데이터에 접근하는 모든 부분은 직접 수정하는 대신 플래그(flag)를 표시할 것 등을 정의했습니다. 그런 다음 Ultracode를 풀어놓았습니다.

15분 후, 저는 3개의 서브에이전트(subagents)를 병렬로 실행하고 있었습니다. 하나는 모든 엔드포인트를 실제 파트너 사양(spec)과 매핑(mapping)하고, 하나는 중복된 재시도 로직을 하나의 공유 모듈로 재작성하며, 하나는 코드 자체를 건드리지 않고 요청이 결제 데이터에 접근하는 모든 지점에 플래그를 표시했습니다. 이전과 마찬가지로 토큰(tokens) 소모는 빨랐습니다. 하지만 이번에는 그 소모가 실질적인 결과물을 가져다주었습니다. 연동 과정의 모든 불일치(inconsistency)에 대한 전체 지도, 우선순위가 지정된 수정 목록, 그리고 제가 커피를 다 마시기 전에 이미 3개의 수정 사항이 배포(shipped)되었습니다.

Ultracode는 모든 것에 적용해야 하는 설정도 아니고, 그렇다고 피해야 할 대상도 아닙니다. 이 도구는 정확히 한 가지 범주의 작업에서 그 가격만큼의 가치를 해냅니다. 즉, 이미 범위(scope)가 정해져 있고, 파일 하나하나를 순차적으로 씹어 삼키는 하나의 모델보다 12개의 병렬 서브에이전트가 더 효율적인, 충분히 규모가 큰 프로젝트입니다.

그보다 작은 작업이나 일상적인 업무라면, 높은 노력과 짧은 프롬프트(prompt)만으로도 충분합니다. Ultracode는 그것이 대신 해줄 수 없는 단 한 가지 작업, 즉 무엇이 실제로 범위(scope)에 포함되는지를 결정하는 일을 위해 아껴두십시오.

남은 크레딧 (Credits to Spare)

진정한 테스트는 결코 모델의 문제가 아니었습니다. 그것은 Ultracode를 클릭 한 번으로 실행할 수 있는 상황에서 키보드 앞에 앉아 있는 사람의 절제력(discipline)에 달려 있습니다.

작업에 손을 대기 전에 범위를 설정하십시오. 75%의 할당량을 낭비하느냐, 아니면 스스로 비용을 충당하는 프로젝트를 만드느냐의 차이는 바로 그 하나의 결정에서 갈립니다. 결정을 제대로 내리면 한 달을 마치고도 크레딧이 남게 될 것이며, 이는 캠프 1(camp 1)에서는 좀처럼 보기 힘든 일입니다.

그래서 저는 남은 크레딧으로 저의 이탈리안 게임(Italian Game) 오프닝을 연습하기 위한 작은 앱을 만들고 있습니다.

결국 어떤 노력 설정도 잘못된 체스 오프닝을 고쳐주지는 못하더군요. 🤓

출처 (Sources)

• Fable 5 가격 책정 및 내보내기 제어 타임라인: Claude Fast, Fable 5 사용 크레딧 가이드
• 공식 노력 수준 (Effort level) 문서: Claude Platform Docs, Effort
• Ultracode 메커니즘: Claude Code Docs, 모델 설정 (model configuration)
• Hacker News 및 Reddit에서 보고된 할당량 소모 사례: Claude Fast, Claude Code에서의 Ultracode
• 노력 (Effort) 기본값에 대한 Anthropic의 안내: Developers Digest, Fable 5 노력 수준 설명

이 포스트에는 제휴 링크가 포함되어 있을 수 있습니다. 링크를 클릭하시면 저에게 소정의 수수료가 지급될 수 있습니다 (사용자에게는 비용이 발생하지 않으며, 제가 매일 여러분의 즐거운 독서를 위해 양질의 기사를 계속 발행하는 데 도움이 됩니다).