How to never one-shot your Fable usage limits again

🖼️ 인포그래픽

How to never one-shot your Fable usage limits again 내용을 설명하는 본문 이미지

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Fable usage limits를 한 번에 소진하지 않으려면 모델 성능을 낮추기보다 컨텍스트, 도구 호출, 로그 읽기, thinking budget을 의도적으로 제한해야 한다.

📌 핵심 요점

Fable 같은 고지능 모델은 긴 컨텍스트와 반복 도구 호출 때문에 비용이 빠르게 커지며, 영상은 품질 저하를 크게 만들지 않으면서 사용량을 50% 이상 줄이는 전략을 목표로 제시한다.
RTK처럼 도구 입력·출력을 압축하면 반복 문구와 불필요한 구조를 줄일 수 있고, 사례상 612줄·36,700자를 4줄·177자로 줄인 극단적 절감도 가능했다.
시스템 프롬프트, 메모리 파일, Claude.md 같은 상시 컨텍스트 문서는 의미를 유지한 채 짧게 압축하는 것이 누적 토큰 비용을 줄이는 핵심 수단이다.
대용량 로그·CSV·데이터 파일은 전체를 읽기보다 SQLite, 검색 스크립트, 샘플링, sed 같은 표적 조회 방식으로 필요한 줄과 필드만 가져오는 것이 효율적이다.
기본값은 낮은 thinking으로 두고, 영어 프롬프트와 컨텍스트 절약 규칙을 함께 적용하면 숨은 컨텍스트와 과도한 사고 토큰으로 인한 비용 증가를 줄일 수 있다.

🧩 배경과 문제 정의

Fable 같은 고지능 모델은 성능이 높지만, 긴 컨텍스트, 반복적인 출력, 잦은 도구 호출이 결합되면 사용량과 비용이 매우 빠르게 증가한다.
발표자는 Fable 사용 비용이 짧은 시간 안에 크게 늘어난 사례를 출발점으로 삼아, 고성능 모델을 “더 많이 쓰는 법”이 아니라 “같은 품질을 더 적은 토큰으로 얻는 법”을 문제로 정의한다.
핵심 목표는 모델의 답변 품질을 크게 낮추지 않으면서 시스템 프롬프트, 메모리 파일, 로그 읽기, 대용량 파일 탐색, 언어 선택, thinking budget 같은 숨은 비용 요인을 줄이는 것이다.
단순히 프롬프트를 짧게 쓰는 수준을 넘어, 컨텍스트에 무엇을 넣을지, 큰 데이터를 어떻게 검색할지, 도구 정의와 로그를 어떻게 압축할지, 추론 강도를 언제 낮출지까지 운영 전략으로 관리해야 한다.
특히 Fable처럼 기본 지능이 높은 모델에서는 모든 작업에 높은 thinking이나 adaptive thinking을 켜는 것이 항상 효율적이지 않으며, 단순 작업에는 낮은 설정으로도 같은 결과를 얻을 수 있다는 점이 비용 최적화의 핵심 논지다.

🕒 시간순 섹션별 상세정리

Fable 비용 폭증과 RTK 기반 도구 호출 압축

Fable 재출시 직후 4시간 동안 1,400달러 이상이 쓰였고, 이후 24시간 동안 약 1,000달러가 추가로 쓰였다는 사례를 통해 고지능 모델의 비용 문제가 먼저 제기된다 [00:03]
발표자는 이런 비용 폭증이 모델 성능 자체보다 사용 방식, 특히 긴 컨텍스트와 도구 호출 구조에서 비롯될 수 있다고 본다 [00:18]
토큰 절감 전략의 목표는 품질을 거의 희생하지 않으면서 전체 토큰 사용량과 사용 한도를 최소 50% 이상 줄이는 것이다 [00:29]
이후 내용은 시스템 프롬프트 압축, 로그 처리 방식 변경, 대용량 파일 검색, 언어 선택, 컨텍스트 점검, thinking 설정 조정으로 계속된다 [00:44]
의미 압축은 문장의 핵심 의미를 유지하면서 단어 수를 최대한 줄이는 방식이며, 장황한 시스템 프롬프트나 프로젝트 지시문에서 특히 효과가 크다 [02:27]
모델에게 반복적으로 주입되는 규칙, 메모리 파일, 프로젝트 설명은 한 번 길어지면 매 요청마다 비용으로 누적되므로 우선 압축 대상이 된다 [02:42]
감사 인사, 완곡한 표현, 불필요한 설명처럼 정보 가치가 낮은 문장은 제거해도 지시문의 실제 의미는 유지될 수 있다 [03:04]
예를 들어 긴 설명을 “프로젝트 지침”처럼 짧은 표현으로 바꾸면 모델이 이해해야 할 핵심은 남기면서 컨텍스트 비용을 줄일 수 있다 [03:19]

로그와 표 형식 데이터는 텍스트 읽기 대신 DB 검색으로 처리하기

로그를 직접 읽는 방식이 모든 경우에 문제는 아니지만, Claude가 대용량 로그 전체를 읽어야 하는 상황에서는 큰 토큰 낭비가 발생한다 [04:24]
특히 로그나 표 형식 데이터처럼 구조화 가능한 정보는 원문 전체를 컨텍스트에 넣기보다 검색 가능한 형태로 바꾸는 편이 효율적이다 [04:39]
발표자는 로그를 SQLite 같은 압축된 데이터베이스 형태로 옮기고, 필요한 조건만 조회할 수 있도록 검색 명령을 추상화하는 방식을 제안한다 [04:54]
이렇게 하면 모델은 거대한 텍스트 전체를 읽는 대신 필요한 시간대, 키워드, 조건, 위치만 조회하고 판단에 필요한 결과만 받게 된다 [05:09]

대용량 파일은 전체 읽기보다 샘플링과 표적 검색으로 다루기

큰 리소스는 처음부터 끝까지 통째로 읽을 필요가 없으며, 검색 함수나 절차적 탐색을 활용하면 모델은 탐색 자체보다 필터 설계와 판단에 집중할 수 있다 [05:53]
이 접근은 모델이 모든 원문을 컨텍스트에 보관하는 방식이 아니라, 필요한 부분을 찾기 위한 검색 전략을 세우는 방식에 가깝다 [06:08]
618KB, 20,000줄짜리 데이터 파일은 한 번에 읽기에는 위험한 크기이며, 전체를 읽기 전에 파일의 구조를 먼저 파악하는 것이 안전하다 [06:26]
발표자는 앞부분과 끝부분을 샘플링해 구조와 패턴을 확인한 뒤, 필요한 조건에 맞춰 표적 검색을 수행하는 방식을 더 효율적인 처리법으로 제시한다 [06:41]

영어 프롬프트와 컨텍스트 절약 규칙으로 기본 사용량 낮추기

영어는 일본어, 프랑스어, 독일어 같은 언어보다 정보 밀도가 높은 편이라 같은 내용을 표현할 때 전체 토큰 사용량을 20~80%까지 줄일 수 있다고 드러난다 [07:21]
따라서 비용을 줄이는 목적이라면, 사용자가 꼭 다른 언어 출력을 요구하지 않는 한 내부 지시나 프롬프트를 영어로 두는 것이 유리할 수 있다 [07:36]
간단한 질의 기준으로 영어는 51토큰, 이탈리아어는 87토큰, 독일어는 118토큰, 일본어는 74토큰이 사용된 예시가 드러난다 [07:52]
이 비교에서 독일어는 영어 대비 2.31배까지 토큰이 늘어났고, 언어 선택만으로도 사용량 차이가 크게 벌어질 수 있다는 점을 보여준다 [08:07]

컨텍스트 점검과 사고량 제한으로 숨은 비용 통제하기

/context 점검은 현재 컨텍스트를 차지하는 숨은 요소를 확인하는 습관으로 소개되며, 보이지 않는 비용 원인을 찾는 데 도움이 된다 [10:12]
예를 들어 여러 Chrome MCP 인스턴스가 동시에 전체 컨텍스트를 싣는 상황은 비용을 키울 뿐 아니라 모델이 참조해야 할 정보도 혼란스럽게 만들 수 있다 [10:27]
Sonnet 5 예시에서는 약 100만 토큰 컨텍스트 중 시스템 프롬프트가 약 10,000토큰, 도구가 16,400토큰, 메모리 파일이 10,700토큰, 스킬이 7,000토큰을 차지했다 [10:43]
이 수치는 사용자가 직접 입력한 본문 외에도 도구 정의, 메모리, 스킬, 시스템 지시가 상당한 컨텍스트 비용을 만든다는 점을 보여준다 [10:58]

Adaptive thinking 대신 낮은 thinking을 기본값으로 둔다

모델은 루프를 돌며 더 많은 토큰을 투입할수록 문제를 더 명확히 보고 더 나은 해법에 가까워질 수 있지만, 그만큼 비용도 함께 증가한다 [12:01]
발표자는 이를 천 단어로 브레인스토밍할 때가 열 단어로 생각할 때보다 더 선명해지는 것과 비슷한 비용 구조로 보여준다 [12:16]
Claude의 adaptive thinking은 thinking budget을 자동으로 정하지만, 실제 필요보다 훨씬 많은 추론 토큰을 쓰는 경향이 있다고 지적된다 [12:31]
Fable처럼 기본 지능이 높은 모델에서는 모든 작업에 adaptive thinking을 맡기기보다 낮은 thinking을 기본값으로 두고, 필요한 경우에만 올리는 방식이 더 효율적이라는 논지로 계속된다 [12:46]

같은 결과라도 높은 모드는 더 많은 토큰과 비용을 쓴다

단순한 버그 찾기 작업에서 low effort 설정은 위에서 아래로 코드베이스를 읽으며 7턴, 1,028 output token, 18초, 총 16센트로 같은 버그를 찾아냈다 [12:50]
이 예시는 낮은 추론 강도라도 작업 난도가 단순하면 충분히 정확한 결과를 낼 수 있음을 보여주는 비교 사례로 사용된다 [13:05]
extra high 모드는 가장 똑똑한 설정에 가깝지만 9턴, 1,363 output token, 21초를 사용했고, 같은 결과를 위해 약 3센트를 더 지출했다 [13:19]
결론적으로 발표자는 같은 결과를 얻는 작업이라면 기본적으로 낮은 effort와 낮은 thinking을 사용하고, 복잡하거나 실패 비용이 큰 작업에서만 더 높은 모드를 선택하는 것이 Fable 사용 한도와 비용을 아끼는 실전 전략이라고 정리한다 [13:34]

Adaptive thinking은 수동 기준보다 토큰을 더 쓰는 쪽으로 기울 수 있다

같은 버그 찾기에서도 extra high는 문제별 thinking 조절 능력이 있었지만 턴 수를 줄이지 않고 더 많은 턴으로 같은 결과에 도달했다 [13:35]
두 방식 모두 같은 버그를 찾았지만 extra high는 output token을 약 1.3배 썼고, 반복하면 차이가 1.5배에 가까운 경우가 많다고 보여준다 [13:45]
발표자는 기본 설정을 low로 두고 특정 비즈니스 기능에 명시적으로 필요할 때만 high로 올리라고 다시 강조한다 [13:58]
adaptive thinking은 유용하지만 토큰 사용량을 늘리는 방향으로 기울 수 있으며, Anthropic도 총 사용 토큰에서 수익을 얻는 구조라고 덧붙인다 [14:04]

무료 자료와 Maker School 안내로 마무리한다

발표자는 영상 제작이 즐거웠다고 말하며, 앞서 언급한 리소스는 설명란에서 무료 다운로드와 무료 가입으로 받을 수 있다고 안내한다 [14:19]
cloud code 실력을 수익화해 첫 고객을 얻고 싶다면 Maker School을 확인하라고 보여준다 [14:28]
Maker School은 AI 서비스의 첫 고객을 얻는 과정을 day-by-day 로드맵으로 안내하는 프로그램이라고 보여준다 [14:33]
AI 서비스는 cloud code로 만든 시스템, codex로 만든 웹사이트, Naden과 드래그앤드롭 빌더로 만든 백엔드 자동화 등을 포함하며, 좋아요와 댓글 질문을 요청하며 끝낸다 [14:40]

🧾 결론

이 영상의 핵심은 “더 싼 모델을 쓰라”가 아니라, 고지능 모델을 그대로 쓰되 모델이 읽고 생각하고 호출하는 범위를 줄이라는 운영 전략이다.
토큰 절감의 가장 큰 지점은 사용자가 직접 입력한 프롬프트보다 도구 출력, 시스템 프롬프트, 메모리, 스킬, 로그, 대용량 파일처럼 반복적으로 컨텍스트에 들어오는 요소들이다.
전체 파일을 읽는 습관은 비용 폭증의 주요 원인이 될 수 있으므로, 먼저 구조를 파악하고 검색·필터링·DB 조회로 필요한 부분만 읽게 만드는 방식이 중요하다.
Adaptive thinking이나 extra high 모드는 더 좋은 결과를 낼 가능성이 있지만, 영상의 예시에서는 같은 문제 해결에도 더 많은 턴과 출력 토큰을 사용했다.
따라서 기본 운영 원칙은 “낮은 사고량, 짧은 지시문, 제한된 파일 읽기, 압축된 도구 출력, 필요한 부분만 조회”로 정리할 수 있다.

📈 투자·시사 포인트

AI 사용량 비용은 모델 가격뿐 아니라 컨텍스트 설계와 도구 호출 구조에 크게 좌우되므로, 고성능 모델 도입 조직은 프롬프트보다 운영 레이어 최적화에 투자필요가 있다.
로그, CSV, 스프레드시트, 대형 문서처럼 반복적으로 조회되는 데이터는 텍스트 전체를 모델에 넘기기보다 검색 가능한 데이터베이스나 전용 쿼리 도구로 바꾸는 편이 비용 효율적이다.
시스템 프롬프트와 프로젝트 지침은 길수록 안정적이라는 보장이 없으며, 의미 압축과 규칙 정리를 통해 비용 절감과 응답 간결성을 동시에 얻을 수 있다.
thinking budget은 성능 옵션이면서 동시에 비용 레버이므로, 기본값은 낮게 두고 복잡한 문제에서만 명시적으로 높이는 방식이 더 합리적이다.
검증이 필요한 지점: 영상의 절감률 수치와 비용 개선 폭은 제시된 사례와 환경에 기반하므로, 실제 팀이나 서비스에 적용할 때는 자체 로그, 모델별 과금 구조, 작업 유형별 성공률을 따로 측정해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

영상에서 언급된 Fable 재출시 직후 비용 폭증 수치, 즉 4시간 1,400달러 이상과 이후 24시간 약 1,000달러 추가 사용은 발표자의 사례로 보이며, 실제 청구 내역이나 사용 조건은 별도 확인이 필요하다.
RTK가 도구 입력·출력을 99%까지 줄였다는 예시는 특정 출력 사례에 기반한 것으로 보이며, 일반적인 환경에서는 영상에서도 평균 30~50% 절감으로 낮춰 설명하므로 실제 프로젝트별 절감률 측정이 필요하다.
영어 프롬프트가 다른 언어보다 20~80% 토큰을 줄일 수 있다는 설명은 간단한 질의 예시에 기반하므로, 한국어 작업·다국어 문서·전문 용어가 많은 환경에서도 같은 절감률이 나오는지는 검증해야 한다.
자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

시스템 프롬프트, 메모리 파일, 프로젝트 지시문에서 감사 표현·완곡한 문장·반복 지시처럼 의미 대비 토큰 비용이 큰 문장을 줄인다.
로그, CSV, Google Sheet처럼 큰 텍스트 데이터를 그대로 읽기보다 SQLite, 필터링 스크립트, 검색 명령으로 필요한 행과 필드만 조회하는 경로를 만든다.
큰 파일을 다룰 때는 전체 읽기 전에 head/tail 샘플링, grep/glob 검색, sed 범위 지정 같은 표적 탐색 절차를 기본값으로 둔다.
에이전트 지시문에 “직접 관련 파일만 읽기”, “범위 확장 전 확인”, “생성 파일·잠금 파일·fixture는 명시 요청 없이는 제외” 같은 컨텍스트 절약 규칙을 추가한다.

❓ 열린 질문

현재 사용하는 에이전트 환경에서 RTK 같은 도구 호출 압축 레이어를 적용할 수 있는지, 적용한다면 어떤 도구 출력부터 압축하는 것이 가장 효과적인가?
프롬프트와 메모리 파일을 의미 압축했을 때, 지시문의 명확성이나 모델의 작업 품질이 어느 지점부터 눈에 띄게 떨어지는가?
한국어 중심 작업에서 영어 프롬프트로 전환하면 토큰은 줄어도 결과 품질, 뉘앙스, 편집 정확도에 어떤 영향이 생기는가?