Effort parameter — Claude Developer Documentation

Caveman, Ponytail, Mandarin. 커뮤니티에서 입소문 난 토큰 절약 프롬프트 기법 5종을 실제 코딩 작업 140회에 적용했더니, 5종 모두 총 토큰이 늘었다는 실측이 올라왔어요. 관사를 빼고 전보식으로 쓴 Caveman은 약 68% 증가, 최소 지시로 줄인 Ponytail은 약 2% 증가했습니다. 프롬프트를 국소적으로 압축하면 모델이 정보를 되찾으려 검색·재확인 턴을 더 돌기 때문이죠. 최적화 단위를 프롬프트 1개가 아니라 작업 1건의 총 궤적으로 잡아야 한다는 게 핵심입니다.

실측 배경과 측정 기준

r/ClaudeAI 커뮤니티에 올라온 실험 결과를 기준으로 합니다. 실제 코딩 작업 10건에 토큰 절약 기법 5종을 적용해 총 140회 런을 돌린 데이터예요. 제가 직접 측정한 게 아니라, 커뮤니티 사용자가 공개한 수치를 검토하고 Claude 공식 문서와 교차 확인했습니다.

저는 다중 에이전트 블로그 파이프라인을 운영하면서 매일 수십 건의 작업을 돌리는데, 프롬프트 압축이 실제로 비용을 줄이는지가 실무적 관심사거든요. 측정 기준은 명확합니다. 작업 1건이 끝날 때까지 소비한 총 토큰 수와 총 비용이에요.

왜 프롬프트 압축이 총 토큰을 늘렸나

Caveman은 관사와 조사를 제거한 전보식 프롬프트예요. 'Read the file and extract the data'를 'Read file extract data'로 줄이는 식이죠. 실측에서 약 68% 토큰이 늘었습니다. Ponytail이나 lazy-engineer는 최소 지시로 줄이는 기법인데, 약 2% 늘었어요. RTK, Context Mode, Mandarin도 모두 총량을 줄이지 못했습니다.

왜 그럴까요? 프롬프트를 짧게 줄이면 모델이 누락된 정보를 되찾으려 도구를 더 많이 호출하거든요. 파일을 읽고, 확인하고, 다시 묻는 턴이 추가로 발생합니다. 절약한 프롬프트 토큰이 늘어난 도구 호출과 재확인 출력에 상쇄되는 거예요.

제가 운영하는 파이프라인에서도 초기엔 프롬프트를 짧게 쓰려 했는데, 에이전트가 맥락을 못 잡고 재확인 턴을 도는 걸 반복적으로 봤습니다. 프롬프트에 파일 경로를 명시적으로 포함하니 턴이 줄었어요.

추론 강도와 캐싱은 어떻게 작용했나

대조적으로, 추론 강도를 높인 설정은 토큰이 약 6% 늘었는데도 비용은 약 49% 줄었다는 결과가 나왔어요. 턴 수가 줄어 전체 궤적이 짧아진 효과입니다. 공식 문서를 보면, effort 설정은 도구 호출 횟수와 턴 수를 함께 바꿔요. 낮은 effort는 도구를 더 적게, 더 통합해서 호출하고 서론과 확인 멘트가 짧아집니다. 즉 생각의 깊이만이 아니라 궤적의 길이를 조절하는 변수예요.

프롬프트 캐싱과의 상호작용도 중요합니다. 캐시는 프리픽스 정확 일치 방식이라, 프리픽스 중간의 1바이트만 바뀌어도 그 이후 전체가 무효화돼요. 프롬프트를 매번 조금씩 압축·변형하는 습관은 캐시를 깨서 오히려 비용을 올립니다. 캐시 읽기는 약 0.1배인데, 정가 1배로 되돌아가는 거죠. 캐시 쓰기는 1.25배이지만 5분 TTL 안에 재사용하면 이득이에요.

같은 프리픽스를 고정해 재사용하는 게 프롬프트를 짧게 쓰는 것보다 절감 효과가 큽니다. 저희 파이프라인에선 시스템 메시지·역할 정의·공통 도구 설명 순으로 프리픽스를 고정했어요. 응답의 cachereadinput_tokens 값으로 확인하면, 프리픽스가 깨지지 않았는지 바로 알 수 있습니다. 0이면 캐시가 무효화된 거예요.

무엇을 버리고 무엇을 취할 것인가

토큰 절약 기법 5종은 버렸어요. 대신 세 가지를 취했습니다. 첫째, 프리픽스 고정으로 캐시 히트율을 올렸어요. 둘째, effort를 medium으로 통일했습니다. 프롬프트 압축으로 번 토큰보다, effort 조절로 줄어든 턴 수가 훨씬 큰 비용 절감을 가져왔거든요. 셋째, 비대화형 대량 작업은 Batch API로 돌립니다. 입력·출력 토큰 50% 정률 할인을 받을 수 있거든요. 프롬프트 기법과 무관한 구조적 절감이지만, 효과는 확실합니다.

구체적으로 어떤 상황에 무엇을 쓸까요? 한 번 실행하고 끝나는 일회성 작업이라면 프롬프트 길이는 신경 쓸 필요 없어요. 차라리 명확하게 쓰는 게 재확인 턴을 줄입니다. 같은 프리픽스로 여러 작업을 반복한다면 캐싱을 활성화하고 프리픽스를 절대 바꾸지 마세요. 프롬프트 압축 습관이 캐시를 깨는 주범이에요. 에이전트 작업처럼 다단계 턴이 발생한다면 effort를 medium 이상으로 올리세요. 프롬프트 토큰이 조금 늘어도, 턴 수 감소가 총 비용을 줄입니다.

측정 단위를 바꾸면 보이는 것

프롬프트 1개를 줄이는 게 아니라 작업 완료까지의 비용 구조를 봐야 합니다. 제가 파이프라인을 2개월 돌리며 깨달은 건, 프롬프트 길이보다 턴 수와 캐시 재사용률이 실제 효율을 좌우한다는 거예요. 커뮤니티 실측은 2026년 7월 기준이며, effort나 캐싱 스펙이 바뀌면 업데이트할 예정입니다.