Reddit

Claude Code effort level and model selection | Claude

Claude Code의 effort level과 모델 선택 가이드

Claude Code에서 모델은 고정된 가중치와 전반적인 능력 범위를, effort level은 파일 탐색·도구 호출·검증·추론에 투입할 작업량을 결정합니다. Anthropic은 기본 설정에서 시작한 뒤, 문제가 어려워 지식이 부족하면 더 큰 모델을, 실행이 불충분하면 더 높은 effort를 선택하라고 안내합니다.

AI 요약

Claude Code에는 응답 품질을 조절하는 것처럼 보이는 두 가지 설정이 있습니다. 하나는 model이고 다른 하나는 effort level입니다. 큰 모델이 더 높은 능력을 제공한다는 이해는 대체로 맞지만, effort는 단순히 모델이 답변 전에 더 오래 생각하도록 만드는 설정이 아닙니다. 어떤 모델을 선택하느냐와 얼마나 많은 작업을 수행하게 하느냐가 서로 다른 축으로 작동하므로, 두 설정을 구분해 판단해야 합니다.

■ 모델 선택은 고정된 가중치를 바꾸는 일입니다

Claude Code가 요청을 처리할 때는 사용자의 메시지뿐 아니라 system prompt, tool definitions, CLAUDE.md, 대화 기록, 현재 맥락에 포함된 파일이 하나의 요청으로 조합됩니다. 서버에서는 먼저 이 입력을 token으로 나누고, 각 token을 모델이 학습한 고정 vocabulary의 정수로 바꿉니다. 모델은 입력 token 배열을 바탕으로 vocabulary의 각 token이 다음에 나올 확률을 계산하고, 가장 가능성이 높은 후보군에서 다음 token을 생성합니다.

이 확률을 만드는 핵심이 weights 또는 parameters입니다. 수십억 개의 숫자가 큰 행렬 형태로 구성되어 있으며, 모델이 알고 있는 TypeScript, 주요 framework, 관용적인 Go 코드와 같은 일반적인 프로그래밍 지식이 학습 시점에 이 가중치에 인코딩됩니다. 요청을 보내는 시점에는 이 가중치가 읽기 전용이므로 prompt, CLAUDE.md, 현재 대화의 context가 모델 자체를 새로 학습시키지는 않습니다. 학습 이후에 등장한 library라면 문서를 context에 넣어 해당 요청에서 활용하게 만들 수는 있지만, 이것은 weights를 갱신하는 teaching이 아니라 그 응답을 유도하는 steering입니다.

따라서 존재하지 않는 API를 자신 있게 호출하는 hallucination은 모델이 외부 문서에서 실제 API를 조회하지 못해서라기보다, 학습 패턴을 바탕으로 그럴듯한 token sequence를 생성한 결과로 설명됩니다. model 설정을 바꾸는 것은 이런 요청을 처리하는 고정된 가중치 묶음을 바꾸는 일입니다. 모델은 답변 전체를 한 번에 생성하지 않고 token 하나를 추가한 뒤 전체 계산을 반복하므로, 200-token 응답은 가중치를 통과하는 200회의 별도 생성 과정으로 이루어집니다. 이 반복이 대기 시간과 출력 비용의 대부분을 만들며, 모델 선택은 각 output token의 가격에도 영향을 줍니다.

■ Effort level은 답변의 작업량을 조절합니다

Claude Code가 생성하는 token은 크게 thinking, tool calls, text to you로 나뉩니다. thinking은 작업 전후에 표시되는 reasoning이고, tool calls는 Read나 Edit 같은 도구와 인자를 지정하는 구조화된 출력이며, text to you는 계획·진행 상황·최종 요약입니다. 이들은 모두 같은 생성 loop에서 나오는 일반 output token이고 동일한 요율로 청구됩니다. 앞서 생성한 thinking token도 해당 turn의 context에 남아 이후 코드 작성이나 도구 사용에 영향을 줍니다.

Effort level은 prompt와 함께 요청에 포함되는 입력값입니다. 모델은 학습 과정에서 각 effort level에 맞는 행동 방식을 익혔으며, 요청을 받으면 이 값에 따라 작업을 끝냈다고 판단하기 전에 어느 정도로 철저하고 확신해야 하는지를 조절합니다. 높은 effort에서는 더 깊고 넓은 계획을 세우고, 더 많은 파일을 읽으며, 도구를 더 사용하고, 테스트나 추가 가설을 검증할 가능성이 커집니다. 낮은 effort에서는 스스로 token을 소비해 맥락을 더 조사하기보다 사용자에게 추가 context를 요청하는 쪽을 택할 수 있습니다.

높은 effort가 항상 작업량을 인위적으로 늘리는 것은 아닙니다. 예를 들어 세 가지 가설을 확인하는 debugging 계획에서 첫 번째 단계로 버그의 원인이 발견되면, Claude는 나머지 두 검사가 더 이상 필요하지 않다고 판단하고 계획을 수정해 건너뛸 수 있습니다. Anthropic은 학습 과정에서 이런 overthinking을 주의 깊게 다루며, 단순한 작업을 높은 effort에서 불필요하게 부풀리지 않도록 한다고 설명합니다. 따라서 effort는 생성 token 수를 고정하는 제한값이 아니라, Claude가 문제를 해결하기 위해 얼마나 멀리 진행할지에 대한 행동상의 선호에 가깝습니다.

■ 모델과 effort를 선택하는 기준

Anthropic은 대부분의 작업에서 각 모델의 기본 effort level을 사용하라고 안내합니다. 기본값은 일반적인 사용자가 작업에 지불하고 싶어 하는 수준에 맞춰 token 사용량을 조절하는 지점이며, effort는 task마다 계속 바꾸기보다는 작업 분야나 평소의 철저함·속도 선호를 반영하는 일반적인 설정으로 보는 것이 좋습니다. Opus 4.8의 경우 기본 effort 설정에서 같은 작업의 Opus 4.7 기본 설정과 비교해 대략 비슷한 token 수로 더 나은 결과를 냈다는 내부 테스트 결과도 제시합니다.

Claude가 틀렸을 때는 먼저 설정을 조절하기보다 context를 점검해야 합니다. prompt가 모호하지 않은지, 올바른 도구와 skill에 연결되어 있는지, 작업 범위가 적절하게 나뉘어 있는지를 확인해야 합니다. 필요한 context가 빠졌다면 effort를 높이는 것보다 prompt, CLAUDE.md, 작업 범위를 먼저 고치는 편이 맞습니다.

그 다음에는 Claude가 충분히 시도하지 않은 것인지, 아니면 문제를 해결할 지식과 능력이 부족한 것인지 구분해야 합니다. 관련 context를 모두 제공했고 Claude가 명확히 시도했는데도 실패했다면 더 큰 model을 선택할 신호입니다. 미묘한 버그, 익숙하지 않은 domain, architecture 결정처럼 실제로 어려운 문제나 모호성이 큰 문제에서는 더 큰 모델이 유리합니다. 반대로 정확한 지시로 설명할 수 있는 편집, 기계적인 변경, 이미 context에 들어온 코드에 대한 질문처럼 routine한 작업에는 작은 모델을 사용할 수 있으며, 필요하지 않은 능력에 비용을 지불할 이유가 없습니다.

실패 원인이 파일을 건너뛰었거나, 테스트를 실행하지 않았거나, refactor를 중간에 포기했거나, 결과를 충분히 double-check하지 않은 데 있다면 높은 effort를 선택하는 것이 맞습니다. 이는 특히 현재 모델의 기본값보다 낮은 effort를 고른 경우에 유효합니다. 즉 ‘알지 못해서 실패했는가’가 model을, ‘충분히 시도하지 않아서 실패했는가’가 effort를 조정하는 기준입니다.

■ 작업 난이도와 비용의 관계

같은 effort에서 routine한 작업을 수행하면 작은 모델과 큰 모델 모두 대체로 올바른 결과를 낼 수 있습니다. 이때 큰 모델은 더 많은 검증 단계를 수행하면서 더 높은 token 단가를 적용받을 수 있으므로, 작은 모델로 내려가면 품질 저하 없이 속도와 비용을 줄일 수 있습니다. 반면 여러 단계가 필요한 어려운 작업에서는 작은 모델이 능력의 한계에 도달할 때까지 더 많은 반복을 소비할 수 있습니다. 큰 모델은 token당 가격이 더 비싸도 더 적은 단계로 같은 품질에 도달해 전체 task 비용이 낮아질 수 있으며, 작은 모델이 가장 높은 effort에서도 끝내지 못하는 작업을 수행할 수도 있습니다.

이 차이는 Fable에서 특히 두드러진다고 설명합니다. 긴 multi-step 작업에서 Fable이 가장 크게 앞서며, 내부 테스트에서는 Opus와 Sonnet이 어떤 effort level에서도 완료하지 못한 작업을 Fable이 완료했습니다. 다만 token당 비용도 가장 높기 때문에 실제로 필요한 작업에만 사용해야 합니다. effort는 Claude가 해결 과정에서 얼마나 멀리 진행할지 정하지만, 생성 token 수를 직접 제한하지는 않습니다. 시스템에서 유일한 hard cap은 max_tokens이며, 이 값에 도달하면 응답이 중간에 잘립니다. task budget이나 짧게 답하라는 prompt는 모델이 한도에 가까워질 때 작업을 마무리하도록 유도하는 softer control로 설명됩니다.

■ 커뮤니티에서 제기된 prompt cache 이슈

Reddit 토론에서는 모델과 effort를 대화 중간에 바꿀 때 prompt cache가 무효화될 수 있다는 점이 주요 쟁점으로 제시됩니다. 댓글 작성자들은 Fable 5.1에서는 메시지별 effort 변경에도 cache가 유지되는 예외가 있고, Opus에도 같은 기능이 beta로 제공되고 있다고 설명합니다. 또한 Ultracode는 별도의 effort level이 아니라 xHigh effort에 ‘use workflows’ 지시를 추가한 이름이라고 주장하며, 같은 효과를 원한다면 prompt에 직접 ‘use workflows’라고 쓸 수 있다고 말합니다. Ultrathink는 effort level을 바꾸지 않고 더 깊이 생각하라는 keyword로 설명되지만, 해당 댓글 작성자는 현재는 legacy 성격이 강하므로 혼동하지 말라고 조언합니다.

Subagent가 session의 effort를 상속한다는 점도 토론에서 언급됩니다. 일부 참여자는 subagent의 cache 유지 시간이 5분에 불과해 오래된 session을 재사용하기보다 새로 만드는 편이 저렴할 수 있다고 말합니다. 반대로 다른 참여자는 긴 orchestrator session에서 cache가 사라질 때 비용이 커지는 문제를 지적하며, 설정을 변경하기 전에 UI가 실제 token·비용 추정치를 보여줘야 한다고 요청합니다. 높은 effort로 먼저 계획을 만들고, 그 계획을 새 session의 저렴한 모델에 복사해 실행하는 방식도 제안됩니다. 다만 이 내용은 본문 안내와 별도로 Reddit 참여자들이 공유한 사용 경험과 해석입니다.

결론적으로 기본 model과 기본 effort에서 시작하고, 결과가 빗나갔을 때 context·도구·작업 범위를 먼저 확인해야 합니다. 그 이후에도 문제 자체가 어려워 실패했다면 더 큰 model을, 파일·테스트·검증을 충분히 수행하지 않아 실패했다면 더 높은 effort를 선택하는 방식이 권장됩니다.

■ Reddit 반응

• @u/ClaudeAI-mod-bot — 논의의 합의점은 대화 중간에 effort level을 바꾸면 prompt cache가 무효화되어 token 비용이 크게 늘어난다는 것입니다. Fable 5.1은 예외로 effort를 바꿔도 cache가 유지되며, Opus에도 곧 이 기능이 제공될 예정입니다. Ultracode는 xHigh effort에 ‘use workflows’ 지시를 더한 이름일 뿐이며, 직접 ‘use workflows’라고 말해도 됩니다. Subagent는 session의 effort를 상속하고 cache는 5분만 유지되므로, 오래된 것을 재사용하는 것보다 새로 만드는 편이 저렴한 경우가 많습니다.

• @u/CoamIthra — 긴 대화에서 effort를 바꾸면 prompt cache가 무효화되므로 비용이나 quota를 더 쓰고 싶지 않다면 피해야 합니다. Fable 5.1에서는 대화별 effort 변경에도 cache가 유지되고, Opus에서도 작업 중입니다. Ultracode는 진짜 effort level이 아니라 xHigh와 ‘use workflows’를 조합한 것이며, 이미 xHigh라면 무료로 바꿀 수 있습니다. 저는 혼동을 피하려고 그냥 ‘use workflows’라고 말하겠습니다.

• @u/Far_Idea9616 — 한 시간 안의 prompt는 cache 비용이 10%이고, 한 시간이 지나면 비용이 200%입니다. 긴 orchestrator session에서 Astra CLI가 두 시간 뒤에 결과를 돌려줄 때 느끼는 감정은 정말 대단합니다.

• @u/Morning_Gecko24 — cache 무효화가 여기서 가장 큰 함정처럼 느껴집니다. 사람들이 작업 단계에 따라 effort나 model을 바꿀 때, UI가 cache를 없애기 전에 실제 token·비용 추정치를 보여줘야 합니다. 긴 session에서 높은 effort의 추가 reasoning이 recache 비용을 상쇄하는지 추적한 사람이 있나요?

원문: Claude / 번역·요약: Trawling