Claude Code에서 모델과 effort level 선택하는 법

핵심 요약:

• Claude 모델 선택은 고정된 가중치(weight) 집합, 즉 모델의 전반적인 능력 범위를 결정합니다. 컨텍스트를 제공하거나 방향을 유도할 수는 있지만, 모델의 전반적인 지식 기반과 능력 자체는 고정되어 있습니다.
• Effort는 단순히 "생각하는 시간"이 아닙니다. Claude가 요청에 얼마나 많은 작업을 수행할지를 전반적으로 제어하며, 여기에는 읽는 파일 수, 사용하는 툴, 그리고 다시 확인하기 전까지 진행하는 단계 수가 모두 포함됩니다.
• 일상적인 작업에는 소형 모델을, 복잡하거나 모호한 작업에는 대형 모델을 선택하세요. 각 모델의 기본 effort level부터 시작하고, 매 작업마다 조정하기보다는 주로 하는 작업 유형에 맞춰 전반적인 기본값으로 조정하세요.
• 관련 컨텍스트를 모두 제공했고 분명히 시도했음에도 여전히 틀렸다면, 더 뛰어난 모델로 전환할 신호입니다. 반면 파일을 건너뛰거나, 테스트를 실행하지 않거나, 리팩토링 도중 멈추는 등의 이유로 실패했다면 effort level을 높이세요.

Claude Code의 effort level과 모델 선택

Claude Code에는 "결과를 더 좋게 만들어 준다"고 여겨지는 두 가지 설정이 있습니다. 바로 모델 설정과 effort level입니다. Claude Fable 5 같은 대형 모델이 Claude Sonnet보다 더 뛰어난 출력을 내고, effort level을 높이면 Claude가 더 오래 생각한 뒤 답한다고 기대할 수 있습니다.

첫 번째 가정은 맞습니다. 저희의 대형 모델은 업계 표준 벤치마크 기준으로 더 높은 성능을 보입니다.

하지만 effort는 단순히 "생각하는 시간" 이상을 의미합니다. Effort level은 Claude가 요청에 얼마나 많은 작업을 전반적으로 수행할지를 제어합니다. 여기에는 모델이 생각하는 시간도 포함되지만, 그 외에도 다음이 포함됩니다:

• 읽는 파일의 수;
• 검증하는 양; 그리고
• 다시 확인하기 전까지 멀티스텝 작업을 얼마나 진행하는지.

effort가 높을수록 Claude는 다시 돌아오기 전에 더 많은 동작(파일 읽기, 테스트 실행, 재확인 등)을 수행합니다. effort가 낮을수록, 스스로 토큰을 소비해 파악하려 하기보다 추가 컨텍스트를 요청하는 쪽을 택합니다.

모델 선택의 작동 방식

엔터 키를 누르면, Claude Code는 사용자 메시지에 시스템 프롬프트, 툴 정의, CLAUDE.md, 대화 기록, 그리고 컨텍스트에 포함된 모든 파일을 하나로 조합합니다. 이 모든 내용이 단일 API 요청으로 전송됩니다.

하지만 모델은 이를 일반 텍스트로 보지 않습니다. 서버에서 가장 먼저 일어나는 일은 토큰화(tokenization)입니다. 텍스트가 여러 조각으로 나뉘고, 각 조각은 모델이 학습할 때 사용한 고정된 어휘에서 정수로 매핑됩니다. 예를 들어 const는 1978, await는 4293에 매핑될 수 있습니다. 이 시점부터 프롬프트는 정수 배열이 됩니다.

모델의 역할은 해당 배열을 받아 다음에 올 토큰을 예측하는 것입니다. 어휘에 있는 모든 토큰에 대해 확률을 계산하고, 상위 후보 중에서 선택합니다. const x = await 다음에는, 잘 학습된 모델이 fetch에 높은 확률을, banana에는 거의 0에 가까운 확률을 부여합니다.

입력 토큰을 확률로 변환하는 것이 바로 가중치(파라미터라고도 함)입니다. 이는 수십억 개의 숫자로 구성된 대규모 행렬들입니다. 하나의 토큰을 예측하기 위해 모델은 입력을 그 행렬들을 통해 실행하는데, 긴 행렬 곱셈 체인을 거쳐 최종적으로 확률을 읽어내는 과정입니다. 모델이 "알고 있는" 모든 것은 이 가중치 안에 담겨 있습니다.

각 모델의 가중치는 학습 중에 설정되며, 요청을 보낼 시점에는 읽기 전용입니다. 프롬프트, CLAUDE.md, 컨텍스트 중 어느 것도 가중치를 변경하지 않습니다. (추론(inference)이라는 단어를 접한 적 있다면, 그 의미가 바로 이것입니다. 학습이 완료된 후 가중치가 고정된 상태에서 모델을 사용하는 것을 뜻합니다.)

TypeScript, 주요 프레임워크, 관용적인 Go 코드 등 Claude가 알고 있는 모든 일반적인 프로그래밍 지식은 학습 시점에 가중치에 인코딩된 것입니다.

프롬프트와 컨텍스트는 여전히 예측을 유도할 수 있습니다(실제 코드를 Claude 앞에 놓는 것도 유도에 해당하며 매우 효과적입니다). 하지만 가중치 자체에 무언가를 추가하지는 않습니다.

모델이 학습될 당시 존재하지 않던 라이브러리는 가중치에 없습니다. 해당 문서를 컨텍스트에 넣으면 Claude가 활용하겠지만, 그건 유도이지 학습이 아닙니다. Claude의 응답은 해당 요청에 한해서만 영향을 받으며, 기반 모델은 그 정보를 기억하지 않습니다.

Claude가 존재하지 않는 API를 자신 있게 호출하는 경우(환각), 이는 가중치가 학습 패턴을 바탕으로 그럴듯해 보이는 토큰 시퀀스를 생성한 결과이지, 잘못된 검색의 결과가 아닙니다.

그렇다면 모델을 변경하면 실제로 무엇이 달라질까요? 요청을 처리하는 고정된 가중치 집합이 바뀌는 것입니다.

모델은 전체 답변을 한 번에 생성하지 않습니다. 토큰 하나를 예측하고, 이를 시퀀스에 추가한 뒤, 다음 토큰을 얻기 위해 전체 연산을 다시 실행합니다. 200개의 토큰으로 이루어진 응답은 가중치를 통해 200번의 별도 연산을 수행하는 것입니다. 대기 시간과 출력 비용의 대부분은 이 루프에서 발생합니다.

결국 모델 설정은 요청을 처리하는 가중치를 결정하고, 출력 토큰당 비용도 결정합니다.

하지만 모델 설정이 결정하지 않는 것이 있습니다. 바로 생성되는 토큰 수입니다. 이 수는 동일한 프롬프트에서도 Claude가 얼마나 많은 작업을 수행하기로 결정하느냐에 따라 크게 달라질 수 있습니다.

이를 제어하는 것이 바로 effort level입니다. 매 턴마다 얼마나 많은 작업을 수행할지를 결정합니다.

Effort의 작동 방식

Claude Code가 작업을 처리할 때 생성되는 토큰은 크게 몇 가지로 분류됩니다:

• 생각(Thinking): 동작 전후로 스트리밍되어 나타나는 추론 과정입니다.
• 툴 호출(Tool calls): Read나 Edit 같은 툴의 이름과 인수를 명시하는 구조화된 블록으로, Claude Code가 이를 파싱하고 실행합니다.
• 사용자에게 전달하는 텍스트: 계획, 진행 상황 업데이트, 마지막 요약 등입니다.

이 모두는 동일한 루프에서 생성되는 일반 출력 토큰으로, 동일한 요율로 과금됩니다. 예를 들어, 생각 토큰은 다른 출력 토큰과 똑같이 생성되며 해당 턴의 나머지 과정 동안 컨텍스트에 유지됩니다.

Claude가 코드 작성으로 넘어갈 때, 앞서 진행한 추론은 읽어들인 파일과 마찬가지로 입력의 일부가 됩니다.

그렇다면 effort는 이 과정에서 어떻게 작용할까요? Effort level은 프롬프트와 함께 요청의 일부로 모델에 전달됩니다. 모델은 각 effort level에서 어떻게 동작해야 하는지를 학습했으며, 그 동작은 고정된 가중치에 내재되어 있습니다.

요청이 도착하면, effort level은 모델이 반응하는 또 하나의 입력이 됩니다. 프롬프트 텍스트에 반응하는 것과 마찬가지입니다. 이를 통해 Claude가 작업을 완료로 간주하기 전까지 얼마나 철저하고 확신에 차게 행동해야 하는지가 결정됩니다.

이는 매 턴마다 반영되며 더 높은 신뢰도의 답변을 생성하기 위해 더 많은 토큰을 사용합니다.

높은 effort level에서 Claude는 보통 계획을 먼저 수립하는 것으로 시작하며, effort 수준은 그 계획의 깊이와 폭에 영향을 미칩니다. 하지만 계획이 고정되어 있는 것은 아닙니다. Claude는 동작을 수행하며 결과를 받아들이는 과정에서 진행 상황을 업데이트하고, 누적된 결과에 대한 확신도를 조정합니다.

예를 들어, 세 가지 가설을 세운 디버깅 계획의 1단계에서 버그를 발견했다면, "가설 2, 3을 조사한다"는 더 이상 필요한 작업이 아닐 수 있습니다. Claude는 보통 이를 명시적으로 밝히며("첫 번째 확인에서 발견했으니 나머지 확인은 필요 없습니다") 건너뜁니다. Claude Code에서 작업 목록이 실행 도중 수정되는 것을 볼 수 있는데, 이 때문입니다.

높은 effort level에서는 추가 가설을 재확인하거나 정확성을 검증하는 경향이 강해지지만, 단순한 작업에서 사용량을 인위적으로 부풀리지는 않습니다. 실제로 저희 팀은 효과를 떨어뜨리는 "과도한 생각(overthinking)"을 모델 학습 과정에서 면밀히 관리합니다.

Effort level 선택하기

저희가 권장하는 것은, 대부분의 작업에서 모델의 기본 effort level을 사용하는 것입니다. 기본값은 대부분의 사용자가 해당 작업에 소비하고자 하는 수준에 맞게 Claude가 토큰 사용량을 조정하는 수준입니다.

Effort는 Claude가 얼마나 열심히, 그리고 얼마나 오래 작업하는지를 수동으로 조정하는 수단으로 생각하세요. 도메인이나 주로 하는 작업 유형에 따라 철저함이나 속도에 대한 강한 선호가 있을 때 의식적으로 선택하세요. 매 작업마다 조정하기보다는 전반적인 기본 설정으로 접근하는 편이 좋습니다.

Claude Opus 4.8 출시 이후 참고할 만한 실용적인 인사이트가 있습니다. 내부 테스트 결과, Opus 4.8의 기본 effort 설정을 사용하면 동일한 작업에서 Opus 4.7의 기본 effort 설정 대비 비슷한 토큰 수로 더 나은 결과를 보였습니다.

Claude가 틀렸을 때 무엇을 바꿀까

Claude가 실수를 했을 때, 즉각적으로 설정을 조정하려 하기보다는 먼저 제공한 컨텍스트를 점검해야 합니다. 프롬프트가 너무 모호하지는 않았나요? Claude가 올바른 툴에 연결되어 있나요? 필요한 스킬을 갖추고 있나요?

사실 effort를 높일 필요가 없는 작업에서 effort를 높이고 있다면, 해결책은 보통 컨텍스트, CLAUDE.md, 또는 작업의 범위 설정 등 상위 단계에 있습니다.

충분한 컨텍스트를 제공했음에도 Claude가 여전히 실수를 한다면, 스스로에게 물어보세요. 충분히 노력하지 않은 것인가요, 아니면 충분히 알지 못하는 것인가요?

모델: 문제가 너무 어려운 경우

문제가 실제로 어렵다면 더 큰 모델을 선택하세요. 미묘한 버그, 익숙하지 않은 도메인, 아키텍처 결정 같은 경우가 해당됩니다. 아무리 많은 컨텍스트를 제공해도 소형 모델이 자신 있게 틀린 답을 내놓는 상황에서는 더 큰 모델이 도움이 됩니다.

또한 대형 모델은 모호성을 처리하는 능력이 더 뛰어납니다. 반면 소형 모델에서는 실행을 지시하는 구체적인 지침이 성공의 더 좋은 방법입니다.

작업이 반복적이라면 소형 모델을 선택하세요. 정확하게 설명할 수 있는 수정, 기계적인 변경, 또는 이미 컨텍스트에 있는 코드에 대한 질문 등이 이에 해당합니다. 작업에 필요하지 않은 성능에 비용을 지불할 이유가 없습니다.

관련 컨텍스트를 모두 제공했고 분명히 시도했음에도 여전히 틀렸다면, 더 큰 모델로 전환할 신호입니다. 큰 모델을 사용 중이고 한동안 작업이 반복적이었다면, 하위 모델로 내려가면 품질 저하 없이 속도가 빨라지고 비용이 줄어드는 경우가 많습니다.

Effort: Claude가 충분히 노력하지 않은 경우

Claude가 파일을 건너뛰거나, 테스트를 실행하지 않거나, 작업 결과를 재확인하지 않아서 실수했다면 effort level을 높이세요. 특히 모델 기본값 이하의 effort level을 선택한 경우에 해당됩니다.

Effort, 모델, 그리고 토큰 소비

그렇다면 모델 선택, effort, 토큰 소비는 어떻게 상호작용할까요? 작업에 따라 다릅니다.

같은 effort level에서의 반복적인 작업이라면, 두 모델 모두 대체로 올바른 결과를 냅니다. 더 큰 모델은 추가적인 검증 단계를 거치면서 더 높은 토큰당 단가로 더 많은 토큰을 소비합니다. 그래서 반복적인 작업에서는 소형 모델을 사용하면 품질 저하 없이 실질적인 비용 절감이 됩니다.

더 어렵고 멀티스텝 작업에서는 양상이 달라집니다. 소형 모델은 능력의 한계에 도달하기 위해 여러 번의 반복을 소모하는 반면, 대형 모델은 더 적은 단계로 동일한 품질 기준에 도달합니다.

대형 모델의 토큰당 비용이 더 높지만, 소형 모델에 실질적인 부담을 주는 작업에서는 작업당 총 비용이 오히려 낮아질 수 있습니다. 더 중요한 것은, 대형 모델은 가장 높은 effort 설정에서도 소형 모델이 달성할 수 없는 작업을 완수할 수 있다는 점입니다.

이 차이는 Fable에서 가장 두드러집니다. 길고 복잡한 멀티스텝 작업에서 가장 큰 격차를 보입니다. 내부 테스트에서 Opus와 Sonnet이 어떤 effort level에서도 완수하지 못하는 작업을 Fable이 완료했습니다. 토큰당 비용도 가장 높으므로, 꼭 필요한 작업을 위해 아껴두어야 하는 또 다른 이유입니다.

위 그래프에서 핵심은, effort level이 Claude가 곡선을 따라 얼마나 멀리 나아가려 하는지를 결정하지만, 그렇다고 Claude가 작업을 완료하기 위해 실제로 그만큼 나아가야 한다는 의미는 아닙니다.

한 가지 더 고려할 점은, effort가 토큰 소비를 형성하지만 제한하지는 않는다는 것입니다. 시스템의 유일한 hard cap은 max_tokens으로, 이 값에 도달하면 응답을 중간에 잘라버립니다. 주로 API 개발자에게 관련된 거친 수단입니다. task budget이나 프롬프트에서 간결하게 유지해달라고 요청하는 것처럼 더 부드러운 제어 방법이 훨씬 유용합니다. 이는 모델이 따르도록 학습된 가이드라인으로 작동하며(한계에 가까워지면 작업을 마무리하려 합니다), 부딪히는 벽이 아닙니다.

기본값에서 시작해, 필요할 때 조정하세요

대부분의 경우 두 설정을 의식할 필요가 없습니다. 결과가 기대에 미치지 못할 때, "Claude가 충분히 알지 못한 건지, 아니면 충분히 노력하지 않은 건지"를 스스로에게 물어보고 그에 맞게 조정하세요.

이 글은 Claude Code 팀의 기술 스태프 멤버인 Lydia Hallie가 작성했습니다.