Claude Fable 5.1 토큰 사용량이 너무 빠른 이유와 줄이는 방법

Thu, 03 Sep 2026 00:00:00 +0900

Claude Code에서 새로운 모델이 나오면 보통 기대하는 것은 비슷합니다.

코딩을 더 잘하고, 복잡한 작업을 더 오래 수행하고, 한 번에 더 많은 일을 끝내는 것입니다.

그런데 최근 공개된 Claude Fable 5.1을 사용한 개발자들 사이에서는 조금 다른 이야기가 나오고 있습니다.

“성능은 좋은데 사용량이 너무 빨리 사라진다.”

실제로 Reddit에서는 Fable 5.1을 사용한 뒤 평소에는 도달하지 않던 사용량 제한에 처음 도달했다는 경험담들이 올라오고 있습니다. 단순히 새 모델이 토큰을 많이 사용하는 걸까요? 공식 문서를 확인해보면 조금 다른 이유가 보입니다.

Fable 5.1을 사용했더니 하루에 5시간 제한을 두 번 채웠다

9월 2일 r/ClaudeCode에 Fable 5.1의 토큰 사용량을 주의해야 한다는 글이 올라왔습니다. 작성자는 Fable 5.1의 성능 자체보다는 작업 방식에 주목했습니다.

댓글에는 곧바로 비슷한 경험담이 이어졌습니다. 한 사용자는 Fable 5.1을 사용하면서 평소 한 번도 채우지 않았던 5시간 사용 제한을 하루 동안 두 번이나 소진했다고 설명했습니다. 또 다른 사용자는 Max 20x 요금제를 사용하면서 하루 만에 주간 사용량의 75%를 사용했다고 했습니다.

반대 경험도 있습니다. 6시간 이상 사용했지만 주간 Fable 사용량이 약 29%였다는 사용자도 있었고, 이전 모델보다 낮은 effort에서도 좋은 결과가 나온다는 의견도 있었습니다.

즉,

1

Fable 5.1 = 무조건 토큰 폭발

이라고 단정하기는 어렵습니다.

그렇다면 사용자별 차이는 왜 이렇게 큰 걸까요?

공식 문서에 힌트가 있습니다

Anthropic의 Fable 5.1 프롬프트 가이드를 보면 꽤 중요한 내용이 나옵니다. Fable 5.1은 작업을 수행하면서 요청받은 부분뿐 아니라 주변 코드까지 같이 수정하거나, 필요하다고 판단하면 요청하지 않은 동작을 확장하거나 테스트 파일을 더 추가할 수 있다고 설명합니다.

개발자 입장에서는 얼핏 좋아 보입니다. 예를 들어 버튼 하나를 수정해달라고 했는데 AI가 관련된 버그까지 발견해서 같이 고쳐준다면 편합니다. 문제는 작업량입니다.

사람이 원한 작업은 이것이었을 수 있습니다.

1

button.css의 padding 수정

그런데 AI가 이렇게 판단할 수 있습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


button.css 수정

↓

관련 컴포넌트 확인

↓

중복 스타일 발견

↓

CSS 구조 정리

↓

관련 테스트 추가

↓

주변 코드 개선

결과물은 더 좋아졌을 수도 있습니다. 하지만 사용한 토큰도 당연히 늘어납니다.

두 줄 수정인데 파일 전체를 다시 쓴다면?

Fable 5.1과 관련해 가장 눈에 띄는 부분 중 하나는 작은 변경에서도 파일 전체를 다시 작성하는 행동입니다. 관련 가이드에서는 작은 수정의 경우 파일 전체를 다시 작성하기보다 필요한 부분만 수정하도록 명시하는 방법을 권장합니다. 예를 들어 1,000줄짜리 파일이 있다고 생각해보겠습니다.

사람이 원하는 변경은:

1

font-size: 20px;

를

1

font-size: 22px;

로 바꾸는 것입니다.

그런데 AI가 파일 전체를 다시 작성한다면 실제 변경은 한 줄이어도 훨씬 많은 출력이 발생합니다. 이런 작업이 여러 번 반복되면

1
2
3
4
5
6
7
8
9


작은 수정
+
파일 전체 재작성
+
추가 설명
+
검증
+
주변 코드 수정

이 쌓입니다. 그러면 사용자는 느끼게 됩니다.

“오늘 별로 한 것도 없는데 왜 사용량이 벌써 끝났지?”

문제는 모델 성능보다 작업 범위일 수 있습니다

Claude Code를 사용할 때 흔히 이런 식으로 요청합니다.

1

이 부분 수정해주세요.

사람끼리는 충분히 이해할 만한 요청입니다. 하지만 에이전트형 AI에게는 상당히 넓은 권한을 주는 문장이기도 합니다.

“이 부분”을 수정하기 위해 관련 코드까지 개선해야 할까요? 테스트도 만들어야 할까요? 기존 문제를 발견하면 같이 해결해야 할까요? 리팩터링까지 해도 될까요? 이 판단을 AI에게 맡긴 것입니다.

Fable 5.1처럼 자율성이 강한 모델에서는 이 차이가 더 크게 나타날 수 있습니다.

그래서 Anthropic도 작업 범위를 명시하라고 합니다

Anthropic 공식 가이드에는 Fable 5.1이 요청하지 않은 주변 작업까지 확장하는 것을 줄이기 위한 프롬프트 예제가 포함되어 있습니다. 핵심을 간단하게 바꾸면 이런 식으로 사용할 수 있습니다.

1
2
3
4
5
6
7


이번 작업에서는 요청한 부분만 수정해주세요.

작업 중 기존 버그나 개선할 부분을 발견해도
현재 요청을 완료하는 데 꼭 필요한 경우가 아니라면
직접 수정하지 마세요.

추가로 발견한 문제는 작업 완료 후 별도로 알려주세요.

이 한 가지 규칙만으로도 작업 범위가 상당히 달라집니다. 예전에는:

1
2


문제 발견
→ 바로 수정

이었다면,

이제는:

1
2
3
4


문제 발견
→ 기록
→ 현재 작업 계속
→ 마지막에 보고

가 됩니다.

작은 수정에서는 “파일 전체를 다시 쓰지 마세요”도 넣을 수 있습니다

특히 HTML이나 CSS, 설정 파일처럼 한두 줄 수정이 자주 발생하는 작업에서는 다음 문장을 추가해볼 수 있습니다.

1
2
3


결과에 영향을 주지 않는다면
파일 전체를 다시 작성하지 말고
필요한 부분만 최소 범위로 수정해주세요.

더 강하게 제한하고 싶다면 이렇게 사용할 수도 있습니다.

1
2
3
4
5
6
7


이번 작업은 최소 수정 원칙으로 진행해주세요.

- 요청한 영역만 수정
- 파일 전체 재작성 금지
- 요청하지 않은 리팩터링 금지
- 관련 없는 코드 정리 금지
- 테스트가 필요한 경우 기존 테스트 우선 사용

이건 토큰 절약뿐 아니라 AI가 예상하지 못한 영역을 건드리는 문제를 줄이는 데도 도움이 됩니다.

퍼블리싱 작업에서는 특히 잘 맞습니다

예를 들어 모바일 CSS를 수정한다고 해보겠습니다. 단순하게:

1

모바일 시안에 맞게 수정해주세요.

라고 할 수도 있습니다. 하지만 이렇게 요청하면 AI가 기존 CSS까지 정리하거나 HTML 구조를 손대는 방향으로 작업 범위를 넓힐 수 있습니다. 조금 더 명확하게 하면:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


640px 이하 모바일 스타일만 수정해주세요.

기존 PC CSS와 HTML 구조는 유지합니다.
기존 클래스명도 변경하지 않습니다.

현재 요청한 영역 외의 스타일은 수정하지 말고,
다른 문제를 발견하면 작업 완료 후 알려주세요.

파일 전체를 다시 작성하지 말고
필요한 CSS 선언만 최소 범위로 수정해주세요.

이렇게 하면 AI가 “더 좋은 코드”를 만드는 것보다 “내가 요청한 코드”를 만드는 데 집중하도록 할 수 있습니다.

CLAUDE.md에도 넣어두면 매번 말할 필요가 없습니다

Claude Code를 계속 사용한다면 이런 규칙을 매 프롬프트마다 반복해서 입력할 필요는 없습니다. 프로젝트의 CLAUDE.md에 작업 원칙으로 넣어둘 수도 있습니다. 예를 들면:

1
2
3
4
5
6
7
8


# Editing Rules

- 요청한 작업 범위만 수정합니다.
- 요청하지 않은 리팩터링은 진행하지 않습니다.
- 기존 문제를 발견해도 현재 작업에 반드시 필요한 경우가 아니라면 수정하지 않습니다.
- 추가 문제는 작업 완료 후 별도로 보고합니다.
- 작은 변경에서는 파일 전체를 다시 작성하지 않고 필요한 부분만 수정합니다.
- 기존 테스트가 있다면 우선 활용하고 불필요한 테스트 파일을 추가하지 않습니다.

특히 작은 수정이 반복되는 프로젝트라면 꽤 잘 맞습니다.

무조건 짧게 시키는 것도 정답은 아닙니다

여기서 한 가지 주의할 점이 있습니다. 토큰을 아끼겠다고 AI에게 무조건 짧은 답변만 요구하면 오히려 결과가 나빠질 수 있습니다.

중요한 것은

1
2
3


생각하지 마
설명하지 마
최대한 짧게 해

가 아닙니다. 필요 없는 작업을 하지 않도록 범위를 줄이는 것입니다.

예를 들어 복잡한 버그를 해결하면서 관련 코드를 충분히 조사해야 한다면 그 작업까지 막으면 안 됩니다. 반대로 CSS 한 줄을 수정하면서 프로젝트 전체를 분석할 필요도 없습니다. 결국 작업마다 필요한 범위를 정해주는 것이 중요합니다.

Fable 5.1에서 바로 써볼 프롬프트

간단한 코드 수정이라면 다음 형태로 시작해볼 수 있습니다.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


현재 요청한 작업만 완료해주세요.

작업 범위를 임의로 확장하지 않습니다.

기존 버그, 코드 개선점, 리팩터링할 부분을 발견하더라도
현재 요청을 완료하는 데 반드시 필요한 경우가 아니라면
수정하지 말고 마지막에 알려주세요.

작은 변경은 파일 전체를 다시 작성하지 않고
필요한 부분만 최소 범위로 수정해주세요.

기존 테스트를 임의로 늘리거나 변경하지 말고
현재 작업 검증에 필요한 기존 테스트를 우선 사용해주세요.

그리고 작업이 끝난 뒤에는:

1
2
3
4
5


이번 작업에서 변경한 파일과 변경 이유를 정리해주세요.

요청 범위를 벗어나 수정한 부분이 있는지도 확인해주세요.

추가로 발견했지만 수정하지 않은 문제도 알려주세요.

라고 하면 됩니다.

Fable 5.1이 토큰을 많이 쓰는 게 꼭 나쁜 것은 아닙니다

Reddit의 반응을 보면 Fable 5.1의 사용량에 불만을 가진 사용자도 많지만 성능 자체에는 긍정적인 평가도 있습니다. 결국 상황에 따라 다릅니다. 대규모 기능 구현이나 복잡한 문제라면 AI가 주변 코드를 충분히 살펴보는 것이 도움이 될 수 있습니다.

반대로

1
2
3
4


CSS 수정
간단한 버그 수정
텍스트 변경
작은 컴포넌트 수정

처럼 범위가 명확한 작업에서는 그 자율성이 오히려 불필요한 토큰 사용으로 이어질 수 있습니다. 그래서 Fable 5.1을 사용할 때 중요한 질문은

“어떻게 토큰을 덜 쓰게 할까?”

보다

“이번 작업에서 AI가 어디까지 판단하도록 허용할까?”

에 가깝습니다. 모델이 똑똑해질수록 AI에게 설명을 덜 해도 되는 것처럼 느껴집니다. 그런데 실제로는 반대인 부분도 있습니다.

능력이 커진 만큼 작업 범위를 더 명확하게 지정해야 할 때가 있습니다.

Fable 5.1의 토큰 사용량이 유독 빠르게 느껴진다면 모델을 바로 바꾸기 전에 먼저 프롬프트에 한 줄을 추가해보는 것이 좋습니다.

1

요청한 범위 밖의 작업은 하지 마세요.

생각보다 이 한 줄이 사용하는 토큰의 양뿐 아니라 AI가 만드는 변경사항의 양 자체를 바꿀 수 있습니다.

Fable 5.1 on 컨트롤 + CCCV