Fable 5.1 토큰을 아끼는 방법: Anthropic 팁 10가지 핵심 정리 | DAKER 커뮤니티

토큰은 빠르게 줄어드는데 결과는 기대에 못 미칠 때가 있습니다. 이럴 때는 모델을 바꾸기보다 프롬프트와 설정을 조금 손보는 편이 더 효과적일 수 있습니다.

코드팩토리 채널의 「앤트로픽이 직접 말아주는 Fable 5.1 지리게 잘 사용하는 법」은 Anthropic이 정리한 Claude Fable 5.1 사용 팁을 열 가지로 풀어 설명합니다. 여기서는 그중에서도 바로 적용하기 쉬운 내용만 추려 정리합니다.

핵심만 먼저 보면

거절, 낭비, 되묻기를 줄이는 짧은 프롬프트와 effort 조절만으로도 Fable 5.1을 더 싸고 빠르게 쓸 수 있습니다.

영상은 Anthropic 가이드를 기준으로 설명하며, 아래 내용은 영상 자막에서 가져온 요약입니다.

코딩 요청이 거절될 때 먼저 바꿔볼 표현

코딩 작업이 막힐 때는 요청 문장을 바꾸는 것만으로도 차이가 납니다. 영상에서는 「오류 없이 컴파일돼」보다 「이 코드에 버그가 있어」처럼 문제를 직접 짚는 표현이 더 낫다고 설명합니다.

잘 알려지지 않은 언어를 다룰 때는 문법 문서를 함께 붙이는 것이 좋습니다. 또 도구가 base64를 반환한다면 그 부분은 빼고 넘기는 편이 낫다고 합니다. 정상적인 요청도 base64 때문에 거절될 수 있기 때문입니다.

Effort는 high를 기준으로 비교해 보는 편이 좋습니다

작은 모델을 높은 effort로만 쓰기보다, Fable 5.1의 low effort와 비교해 보라는 점도 영상에서 강조합니다. Anthropic 기준으로는 작업당 비용이 Opus·Sonnet과 비슷하면서 평가 점수가 더 높은 경우가 많다고 소개합니다.

실제로는 기본 high에서 같은 작업을 medium, low로도 돌려 보고, 충분한 결과가 나오면 낮추는 방식이 적절합니다.

다만 low는 검색을 덜 합니다. 최신 정보가 꼭 필요하다면 「알고 있는 내용이라도 최신 정보는 무조건 검색해서 확인해 줘」를 붙이면 됩니다.

반대로 X-high·Max는 긴 문서를 thinking에 통째로 써서 느려질 수 있습니다. 이때는 생각 단계에서 구조와 핵심만 정하고, 최종 문서는 최종 답변에서 작성하도록 유도하는 문장이 도움이 됩니다.

작은 숫자와 과한 비유를 다루는 방법

빽빽한 차트는 실제 확대가 중요합니다

빽빽한 차트는 「확대해서 봐」라는 말만으로는 부족할 수 있습니다. 영상에서는 AI가 고른 영역을 실제로 잘라 확대하는 크롭 툴, 또는 OpenCV 같은 도구를 함께 쓰면 읽기 정확도가 올라간다고 설명합니다.

글이 추상적으로 흐르면 직접적으로 풀어 쓰게 합니다

문장이 지나치게 추상적이거나 멋을 부리는 방향으로 흐를 때는 Please remove all manopros를 프롬프트에 넣는 방식을 권합니다. 멋부린 표현을 줄이고 뜻을 직접 설명하게 만드는 한 줄입니다.

서브에이전트와 작업 범위를 함께 관리해야 합니다

서브에이전트에 일을 넘긴 뒤에도 메인 에이전트가 바로 다음 일을 하도록 두면, 품질과 비용은 비슷하면서 완료 시간은 줄어든다고 합니다. 직렬 처리가 꼭 필요한 경우가 아니라면 병렬로 움직이도록 유도하는 편이 낫습니다. 메인 에이전트가 기다리기만 한다면 스티어링으로 밀어 주는 방식이 소개됩니다.

작업 범위를 벗어나는 수정도 함께 막아야 합니다. 예를 들어 로그인 오류만 고쳐 달라고 했는데 다른 화면까지 건드린다면, 「요청과 관련 없는 문제는 수정하지 말고, 끝난 뒤 알려줘」를 붙이는 방식이 효과적이라고 합니다.

테스트 역시 수정한 기능만 대상으로 하고, 파일 전체가 아니라 필요한 부분만 고치도록 유도하는 것이 좋습니다.

되묻기를 줄이고 진행 상황은 짧게 받는 편이 좋습니다

나는 작업 중에 답할 수 없어. 다시 묻지 말고 진행해

이미 맡긴 일을 두고 「진행할까요?」라고 멈추는 경우에는 이런 문장을 시스템 프롬프트에 넣는 방법이 소개됩니다. 여기에 「요청한 작업은 끝까지 완료해 줘」를 함께 두면 되묻기를 더 줄일 수 있습니다.

다만 삭제나 범위 변경처럼 되돌리기 어려운 일만 먼저 묻게 두는 편이 적절합니다.

예전에 넣어 둔 금지문도 다시 볼 필요가 있습니다. 「굵은 글씨 쓰지 마」, 「목록 쓰지 마」처럼 서식을 제한하는 문장은 Fable 5.1이 서식을 덜 쓰는 특성과 맞물려 불필요해질 수 있습니다. 필요할 때만 묻게 바꾸거나 정리하는 편이 낫습니다.

반대로 진행 설명이 너무 없으면 「시작 전 한 줄 → 진행 짧게 → 끝나면 정리」처럼 원하는 흐름을 지정하면 됩니다.

인용 규칙과 thinking 블록은 따로 챙겨야 합니다

영상에 따르면 요약할 때 원문 인용 표시를 빠뜨리는 경우가 이전보다 많다고 합니다. 그래서 시스템 프롬프트에 올바른 답변 예시를 넣고, 문서에서 그대로 가져온 표현은 따옴표로 표시하며 요약과 직접 인용을 구분하라고 적어 두는 방식이 권장됩니다.

API로 대화를 이어갈 때는 thinking 블록 전체를 받은 그대로 보내고, 앞쪽 대화를 고쳐 쓰지 말아야 한다고 설명합니다. 대화가 길어져 compact가 필요하면 요약 메시지와 새 요청으로 바꾸고, 이전 thinking 블록은 같이 보내지 않는 방식이 적절합니다.

정리

Fable 5.1은 effort, 검색, 서식, 인용, thinking 블록 규칙에서 이전과 조금 다른 점이 있습니다. 영상에서 소개한 Anthropic의 열 가지 팁을 따라가면 토큰을 아끼면서도 거절과 헛수정을 줄이는 데 도움이 됩니다.

같은 작업이라도 프롬프트 한두 줄과 effort 설정만 바꾸면 비용과 속도, 완성도가 함께 달라질 수 있습니다.

자세한 문장과 예시는 원본 영상을 보면 됩니다.

참고 자료

유튜브: 앤트로픽이 직접 말아주는 Fable 5.1 지리게 잘 사용하는 법 · 채널 코드팩토리

평소 Fable 5.1을 쓸 때 가장 자주 막히는 지점은 어디인지 궁금합니다.