Claude Code를 쓰다 보면 다이얼이 두 개 있다는 걸 알게 됩니다. 모델을 고르는 다이얼, 그리고 effort 레벨을 고르는 다이얼이죠. 둘 다 “더 좋은 답”을 만들어줄 것처럼 보여서, 흔히 이렇게 생각합니다. 큰 모델을 쓰면 더 똑똑한 답이 나오고, effort를 높이면 더 오래 생각해서 답이 나온다고요.

앞쪽 가정은 맞습니다. Fable 5 같은 큰 모델이 벤치마크에서 더 뛰어난 건 사실이니까요. 문제는 뒤쪽입니다. effort는 “생각하는 시간”보다 훨씬 많은 걸 결정합니다.

Anthropic이 최근 공식 블로그에서 이 두 설정이 각각 무엇을 통제하는지, 그리고 답이 잘못 나왔을 때 어느 쪽을 조정해야 하는지를 정리했습니다. 결론부터 말하면, 모델은 “무엇을 아는지”를 정하고 effort는 “얼마나 확인하는지”를 정합니다. 완전히 다른 두 축이라는 거죠.

출처: Choosing a Claude model and effort level in Claude Code – Claude by Anthropic

모델 설정은 고정된 지식 창고를 바꾸는 일

엔터를 누르는 순간, Claude Code는 프롬프트와 시스템 프롬프트, 툴 정의, CLAUDE.md, 대화 기록, 컨텍스트에 있는 파일들을 모두 묶어 하나의 API 요청으로 보냅니다. 모델은 이걸 텍스트 그대로 받지 않습니다. 서버에서 가장 먼저 하는 일은 토큰화입니다. 텍스트를 잘게 쪼개서 각 조각을 정해진 어휘 목록의 숫자로 바꾸는 작업이죠.

이후 모델이 하는 일은 단순합니다. 다음에 올 토큰의 확률을 어휘 전체에 걸쳐 계산하고, 가장 높은 확률의 것을 고르는 겁니다. 이 확률을 만들어내는 게 가중치입니다. 학습 과정에서 정해진 수십억 개의 숫자 뭉치인데, 모델이 “아는 것”은 전부 여기 들어 있습니다.

중요한 건 이 가중치가 요청을 처리하는 시점엔 이미 고정돼 있다는 점입니다. 프롬프트도, CLAUDE.md도, 컨텍스트에 넣은 문서도 가중치 자체를 바꾸지 못합니다. 프롬프트에 최신 라이브러리 문서를 넣으면 그 답변에서는 활용하지만, 모델이 그 지식을 영구히 습득하는 건 아닙니다. Anthropic은 이걸 “가르치는 게 아니라 방향을 제시하는 것”이라고 표현합니다.

그러니 모델 설정이 바꾸는 건 딱 하나, 어떤 고정된 가중치 세트가 요청을 처리하느냐입니다. 그리고 그 선택이 토큰 하나당 비용도 함께 정합니다. 반대로 모델 설정이 정하지 않는 게 있습니다. 몇 개의 토큰을 생성할지, 얼마나 많은 작업을 할지는 여기서 결정되지 않습니다.

effort는 얼마나 확인하고 끝낼지를 정하는 다이얼

Claude Code가 작업할 때 만들어내는 토큰은 크게 세 종류입니다. 화면에 흘러나오는 사고 과정, Read나 Edit 같은 툴 호출, 그리고 사용자에게 보여주는 계획과 요약입니다. 이 셋은 전부 같은 루프에서 나오는 평범한 출력 토큰이고, 같은 요금으로 청구됩니다.

effort 레벨은 프롬프트와 나란히 요청에 함께 실려 갑니다. 모델은 학습 단계에서 이미 각 effort 수준에서 어떻게 행동해야 하는지를 배웠고, 그 행동 패턴이 가중치 안에 녹아 있습니다. 요청이 들어오면 effort는 프롬프트 텍스트와 마찬가지로 모델이 반응하는 또 하나의 입력값이 됩니다. 얼마나 철저해야 하고, 얼마나 확신이 서야 작업을 끝난 걸로 볼지를 이 값이 정하는 셈입니다.

effort가 높을수록 Claude는 파일을 더 많이 읽고, 테스트를 더 자주 돌리고, 다시 확인하는 횟수를 늘립니다. effort가 낮으면 스스로 알아내려 하기보다 사용자에게 컨텍스트를 더 요청하는 쪽을 택합니다. 다만 이 계획은 고정돼 있지 않습니다. 세 가지 가설 중 첫 번째에서 버그를 찾으면, 나머지 두 가설을 확인하는 단계는 건너뛰기도 합니다. Claude Code에서 작업 목록이 실행 중 수정되는 걸 본 적이 있다면 바로 이 장면입니다.

답이 틀렸을 때, 무엇을 조정해야 할까

원문이 제시하는 판단 기준은 명확합니다. 충분한 맥락을 주었는데도 Claude가 틀렸다면, 시도는 제대로 했는데 몰라서 못 푼 건지, 아니면 시도 자체가 부족했는지를 구분하라는 겁니다.

파일을 하나 빼먹었거나, 테스트를 안 돌렸거나, 리팩터링을 하다 말았다면 effort 부족 신호입니다. 반대로 맥락도 충분했고 시도도 제대로 했는데 낯선 도메인이나 미묘한 버그 앞에서 계속 틀렸다면, 그건 모델이 감당하기엔 문제가 어려웠다는 뜻입니다.

Anthropic은 이 관계를 비유로 설명합니다. Fable은 비슷한 문제를 이미 여러 번 풀어본 전문가, Opus는 깊이 있는 전문가, Sonnet은 뛰어난 제너럴리스트라는 겁니다. effort는 이 셋 각각에게 얼마만큼의 시간을 줄지를 결정합니다. Opus를 낮은 effort로 쓰는 건 전문가에게 5분만 훑어보게 하는 것과 비슷하고, Sonnet을 높은 effort로 쓰는 건 뛰어난 제너럴리스트에게 오후 시간을 통째로 내주는 것과 비슷합니다. 둘 다 나쁘지 않지만, 얻는 게 다릅니다.

일상적인 작업이라면 대부분 기본 effort 수준으로 충분합니다. 조정은 특정 작업 하나하나가 아니라, 평소 업무 성격에 대한 일반적인 선호로 접근하는 게 낫습니다. 그리고 정말 어려운 문제일수록, 모델을 바꾸는 것과 effort를 바꾸는 것 중 무엇이 필요한지부터 구분하는 게 먼저입니다.