Claude Code는 모델과 노력 수준이라는 두 가지 설정을 제공하는데, 둘 다 "답변을 더 좋게 만드는" 것처럼 보입니다. 하지만 이것들이 실제로 출력에 어떤 영향을 미칠까요? 그리고 더 큰 모델을 사용해야 할지, 아니면 노력 수준만 변경하면 될지 어떻게 알 수 있을까요?
Fable 같은 더 큰 모델을 선택하면 Sonnet보다 더 똑똑한 출력을 얻을 수 있고, 더 높은 노력 수준은 단순히 Claude가 답변하기 전에 더 오래 생각한다는 의미라고 생각하기 쉽습니다.
첫 번째 가정은 사실입니다. 업계 표준 벤치마크에 따르면 가장 큰 모델이 더 뛰어납니다.
하지만 노력은 단순한 "생각하는 시간" 이상을 의미합니다. 노력은 Claude가 요청 전체에 대해 수행하는 작업량을 제어합니다. 여기에는 생각하는 시간도 포함되지만, 다음과 같은 요소도 포함됩니다:
- 읽는 파일 수
- 확인하는 정도
- 여러 단계로 구성된 작업을 진행하기 전에 얼마나 멀리 나아가는지
높은 노력 수준에서는 Claude가 사용자에게 결과를 보여주기 전에 더 많은 작업(파일 읽기, 테스트 실행, 재확인)을 수행합니다. 낮은 노력 수준에서는 토큰을 소모하여 스스로 해결하기보다는 사용자에게 더 많은 컨텍스트를 요청하는 편을 선택합니다.
모델 선택의 작동 방식
모델 설정이 실제로 무엇을 제어하는지 이해하려면, Enter 키를 누르는 순간부터 처음부터 시작하는 것이 도움이 됩니다.
Claude Code는 사용자의 메시지를 시스템 프롬프트, 도구 정의, CLAUDE.md, 대화 기록, 그리고 컨텍스트에 있는 모든 파일과 함께 조합합니다. 이 모든 것이 하나의 요청으로 API로 전송됩니다.
Claude Code가 가진 모든 것은 하나의 API 요청에 담깁니다. 서버에서는 텍스트가 모델에 도달하기 전에 토큰화됩니다.
하지만 모델은 이 모든 것을 일반 텍스트로 보지 않습니다. 서버에서 가장 먼저 일어나는 일은 토큰화입니다: 텍스트가 조각으로 분할되고, 각 조각은 모델이 학습한 고정된 어휘집의 정수에 매핑됩니다. const는 1978에 매핑되고, await는 4293에 매핑될 수 있습니다. 이 시점부터 프롬프트는 정수 배열입니다.
토크나이저는 텍스트를 조각으로 분할하고 각 조각을 고정된 어휘집의 정수에 매핑합니다. 위쪽 행의 각 청크는 토큰 ID(아래쪽 행)가 됩니다. 표시된 ID는 예시입니다.
모델의 역할은 해당 배열을 가져와서 다음에 올 토큰을 예측하는 것입니다. 이를 위해 어휘집에 있는 모든 토큰에 대한 확률을 계산하고 상위에서 선택합니다. "const x = await" 다음에 잘 훈련된 모델은 "fetch"에 높은 확률을 부여하고(매우 가능성 높음), "banana"에는 거의 0에 가까운 확률을 부여합니다(거의 가능성 없음).
모델의 예측은 어휘집에 있는 모든 토큰에 대한 확률입니다. 최상위 추측과 관련 없는 추측 사이의 차이는 엄청납니다.
입력 토큰을 이러한 확률로 변환하는 것은 가중치(파라미터라고도 함)입니다: 큰 행렬로 구성된 수십억 개의 숫자입니다. 하나의 토큰을 예측하기 위해 모델은 이러한 행렬을 통해 입력을 실행하고(긴 행렬 곱셈 체인) 끝에서 확률을 읽습니다. 가중치는 모델이 "알고" 있는 모든 것이 저장된 곳입니다.
각 모델의 가중치는 훈련 중에 설정되며, 사용자가 요청을 보낼 때쯤이면 읽기 전용입니다. 프롬프트, CLAUDE.md 또는 컨텍스트의 어떤 것도 가중치를 변경하지 않습니다. 추론이라는 단어를 접해본 적이 있다면, 그것이 바로 이것을 의미합니다: 훈련이 완료된 후 가중치가 고정된 상태에서 모델을 사용하는 것입니다.
프롬프트가 입력되면 확률이 출력됩니다. 중간의 가중치는 변경되지 않습니다.
Claude가 TypeScript, 인기 프레임워크 또는 기타 일반적인 프로그래밍 지식에 대해 알고 있는 모든 것은 훈련 시간에 해당 가중치에 인코딩되었습니다.
프롬프트와 컨텍스트는 여전히 예측을 유도할 수 있습니다. 실제 코드를 Claude 앞에 두는 것은 유도이며, 매우 효과적입니다. 그러나 이것은 가중치 자체에 아무것도 추가하지 않습니다.
라이브러리가 모델 훈련 시점에 존재하지 않았다면, 가중치에 없습니다. 문서를 컨텍스트에 넣으면 Claude가 사용하겠지만, 그것은 유도일 뿐 학습이 아닙니다. Claude의 응답은 해당 요청에 대해서만 영향을 받지만, 기본 모델은 아무것도 유지하지 않았습니다.
Claude가 존재하지 않는 API를 자신 있게 호출하는 경우(환각), 이는 가중치가 훈련 패턴에서 그럴듯해 보이는 토큰 시퀀스를 생성하는 것이지, 실패한 조회가 아닙니다.
그렇다면 모델을 변경하는 것은 실제로 무엇을 할까요? 요청을 처리하는 고정된 가중치 세트를 교체하는 것입니다.
모델은 한 번에 전체 답변을 생성하지 않습니다. 하나의 토큰을 예측하고, 시퀀스에 추가한 다음, 전체 계산을 다시 실행하여 다음 토큰을 얻습니다. 200 개 토큰 응답은 가중치를 통한 200 번의 개별 통과입니다. 이 루프가 대기 시간(및 출력 비용)의 대부분을 차지하는 곳입니다.
시퀀스는 단계당 정확히 하나의 토큰씩 증가합니다. 모델은 다음에 올 것을 예측하기 위해 매번 전체 배열을 다시 읽습니다.
모델 설정은 어떤 가중치가 요청을 처리할지 결정하고, 각 출력 토큰의 비용도 결정합니다.
결정하지 않는 것은 생성되는 토큰 수입니다. 이 숫자는 동일한 프롬프트에 대해서도 Claude가 수행하기로 결정한 작업량에 따라 크게 달라질 수 있습니다.
이것이 바로 노력이 제어하는 것입니다.
노력의 작동 방식
Claude Code가 작업을 수행하는 동안 생성되는 토큰은 몇 가지 범주로 나뉩니다:
- 생각: 작업 전후에 스트리밍되는 추론
- 도구 호출: Read 또는 Edit와 같은 도구와 해당 인수를 지정하는 구조화된 블록으로, Claude Code가 이를 구문 분석하고 실행합니다.
- 사용자에게 전달하는 텍스트: 계획, 진행 상황 업데이트, 마지막 요약
이 모든 것은 동일한 루프에서 나오는 일반적인 출력 토큰이며, 동일한 요율로 청구됩니다. 예를 들어 생각 토큰은 다른 출력 토큰과 정확히 동일하게 생성되며, 해당 턴의 나머지 부분 동안 컨텍스트에 유지됩니다.
Claude가 코드 작성을 진행할 때쯤이면, 이전의 추론은 마치 읽은 파일과 마찬가지로 입력의 일부가 됩니다.
Claude의 모든 출력은 토큰입니다. 생각, 도구 호출, 사용자에게 전달하는 텍스트는 모두 동일한 루프에서 생성됩니다.
그렇다면 노력은 이것을 어떻게 변경할까요? 노력 수준은 프롬프트와 함께 요청의 일부로 모델에 전송됩니다. 모델은 각 노력 수준에서 어떻게 행동해야 하는지 이해하도록 훈련되었으며, 이 학습된 행동은 고정된 가중치에 내장되어 있습니다.
요청이 도착하면 노력은 프롬프트 텍스트에 반응하는 것과 같은 방식으로 모델이 반응하는 또 하나의 입력이 됩니다. Claude가 작업이 완료되었다고 간주하기 전에 필요한 철저함과 확신의 정도를 설정합니다. 이는 모든 턴에서 평가되며, 더 높은 신뢰도에 도달하려면 더 많은 토큰이 필요합니다.
동일한 프롬프트, 두 가지 노력 수준. 높은 노력 경로는 더 높은 신뢰도의 답변에 도달하기 위해 약 7 배 더 많은 토큰을 생성합니다.
높은 노력 수준에서 Claude는 종종 계획을 세우는 것으로 시작하며, 노력 수준은 해당 계획의 깊이와 범위에 영향을 미칩니다. 그러나 계획은 고정되어 있지 않습니다. Claude가 작업에서 결과를 받으면, 진행 상황과 축적된 결과에 대한 확신 정도에 대한 그림을 업데이트합니다.
세 가지 가설을 조사하는 디버깅 계획의 1 단계에서 버그를 찾으면 "가설 2 와 3 을 조사"하는 것이 더 이상 필요하지 않을 수 있습니다. Claude는 일반적으로 이를 명시적으로 언급하고(예: "첫 번째 확인에서 찾았으므로 나머지 확인은 필요하지 않습니다") 건너뜁니다. 작업 목록이 실행 중에 수정될 때 Claude Code에서 이를 볼 수 있습니다.
높은 노력은 Claude가 찾은 답변을 확인하거나 건너뛸 수 있었던 가설을 계속 조사하는 등 재확인할 가능성을 높입니다. 그러나 일반적으로 노력 수준이 높아졌다고 해서 단순한 작업에서 인위적으로 사용량을 늘리지는 않습니다. "과도한 생각"은 모델 훈련 중에 우리 팀이 특히 주의를 기울이는 부분으로, 효과성을 저하시킵니다.
노력 수준 선택하기
대부분의 작업에서는 모델의 기본 노력 수준을 사용하세요. 기본값은 Claude가 대부분의 사람들이 작업에 사용하고 싶어하는 수준으로 토큰 사용량을 조정하는 수준입니다.
노력을 작업의 난이도와 시간에 대한 수동 오버라이드로 생각하세요. 자신의 도메인이나 수행하는 작업 유형에 따라 철저함 또는 속도에 대한 강한 선호도가 있을 때 의도적으로 사용하고, 작업별 결정이 아닌 일반적인 선호도로 취급하세요.
Opus 4.8 출시 이후 실용적인 참고 사항: 테스트 결과, Opus 4.8 의 기본 노력 설정은 동일한 작업에서 Opus 4.7 의 기본 노력 설정과 거의 동일한 토큰 양으로 더 나은 결과를 생성합니다.
Claude가 잘못했을 때 변경할 사항
Claude가 무언가를 잘못했을 때, 첫 번째 본능은 설정을 변경하는 것이 아니라, 제공한 컨텍스트를 살펴보는 것입니다. 프롬프트가 너무 모호한가요? Claude가 올바른 도구에 연결되어 있나요? 올바른 기술을 가지고 있나요?
필요하지 않은 작업에서 노력을 높이고 있다면, 해결 방법은 일반적으로 상위 단계에 있습니다: 컨텍스트, CLAUDE.md 또는 작업 범위를 확인하세요.
하지만 명확한 컨텍스트를 제공했는데도 Claude가 계속 틀린다고 가정해 보겠습니다. 스스로에게 물어봐야 할 질문은 다음과 같습니다: 충분히 시도하지 않았습니까, 아니면 충분히 알지 못했습니까?
모델: 문제가 너무 어려웠습니다
문제가 실제로 어려운 경우(미묘한 버그, 익숙하지 않은 도메인, 아키텍처 결정) 더 큰 모델을 선택하세요. 더 작은 모델이 아무리 많은 컨텍스트를 제공해도 자신 있게 틀리는 경우에 원하는 것은 더 큰 모델입니다.
더 큰 모델은 모호함을 처리하는 데도 더 뛰어납니다. 더 작은 모델에서는 실행을 지시하는 구체적인 지침이 성공에 더 좋은 방법입니다.
작업이 일상적인 경우(정확하게 설명할 수 있는 편집, 기계적인 변경, 이미 컨텍스트에 있는 코드에 대한 질문) 더 작은 모델을 선택하세요. 작업에 필요하지 않은 기능에 비용을 지불할 이유가 없습니다.
Claude가 모든 관련 컨텍스트를 가지고 명확하게 시도했지만 여전히 틀렸다면, 더 큰 모델을 선택해야 한다는 신호입니다. 그리고 더 큰 모델을 사용 중인데 한동안 작업이 일상적이었다면, 낮추면 속도가 빨라지고 일반적으로 출력 품질에 영향을 주지 않으면서 비용이 절감됩니다.
노력: Claude가 충분히 시도하지 않았습니다
파일을 건너뛰거나, 테스트를 실행하지 않거나, 작업을 재확인하지 않는 등 Claude가 충분히 시도하지 않아서 잘못했다면 더 높은 노력 수준을 선택하세요. 이는 모델의 기본값보다 낮은 노력 수준을 선택한 경우에 가장 관련이 있습니다.
전문가, 베테랑, 그리고 제너럴리스트
제가 두 설정에 대해 생각하는 한 가지 방식은 Fable은 거의 아무도 해결할 수 없는 문제를 처리할 수 있는 전문가이고, Opus는 베테랑이며, Sonnet은 매우 뛰어난 제너럴리스트라는 것입니다. 노력 수준은 이들 각각이 작업에 얼마나 많은 시간을 할애할지 결정합니다.
낮은 노력의 Opus는 사용자와 같은 문제에 대한 깊은 경험을 가진 베테랑과 5 분 동안 상담하는 것과 같습니다. 그들은 코드베이스 어디에도 없는 지식, 즉 이전에 본 패턴, 확인해야 할 함정, 수많은 유사한 문제를 해결한 경험에서만 얻을 수 있는 지식을 가져옵니다. 하지만 5 분은 모든 파일을 주의 깊게 살펴보는 것이 아니라 코드를 빠르게 읽는 것을 의미합니다.
높은 노력의 Sonnet은 오후 내내 시간을 가진 제너럴리스트입니다. 코딩에 능숙하며, 모든 것을 읽고, 실행하고, 작업을 재확인하고, 결국 사용자의 특정 코드를 철저히 이해하게 됩니다.
Fable은 다른 모든 사람이 막혔을 때 부르는 전문가입니다. 낮은 노력에서도 다른 누구도 발견하지 못할 것을 찾아냅니다. 그 인식 자체가 가장 비용을 지불하는 부분이므로, 정말로 필요한 작업을 위해 아껴두는 것이 좋습니다.
이 중 어느 것도 보편적으로 "더 좋은" 것은 아닙니다. 모델 설정은 대략 능력이고, 노력 설정은 대략 철저함입니다. 대부분의 실제 작업은 둘 다 어느 정도 필요합니다.
노력, 모델, 토큰 소비
그렇다면 모델 선택, 노력, 토큰 소비는 어떻게 상호 작용할까요? 작업에 따라 다릅니다.
동일한 노력 수준의 일상 작업에서는 일반적으로 더 큰 모델과 더 작은 모델 모두 올바르게 처리합니다. 더 큰 모델은 추가 확인 단계로 더 많은 토큰을 소비하며, 토큰당 가격도 더 높습니다. 이것이 바로 일상적인 작업에서 더 작은 모델로 낮추면 품질 저하 없이 실제 비용을 절감할 수 있는 이유입니다.
곡선은 설명 목적으로만 표시되었으며, 두 모델이 모두 빠르게 수행할 수 있을 만큼 간단한 단일 작업에 대해 표시되었습니다. 실제 벤치마크 데이터를 나타내지 않습니다.
더 어렵고 여러 단계로 구성된 작업에서는 공식이 뒤집힙니다. 더 작은 모델은 능력의 한계까지 끊임없이 반복해야 하는 반면, 더 큰 모델은 더 적은 단계로 동일한 품질 기준에 도달합니다.
더 큰 모델에 대해 토큰당 더 많은 비용을 지불하지만, 진정으로 더 작은 모델을 확장하는 작업의 경우 작업당 총 비용이 더 낮아질 수 있습니다. 그리고 더 중요한 것은: 더 큰 모델은 가장 높은 노력 설정에서도 더 작은 모델이 완료할 수 없는 작업을 완료할 수 있다는 것입니다.
이것은 Fable에서 가장 두드러집니다. 길고 여러 단계로 구성된 작업에서 가장 앞서 나갑니다. 테스트 결과, Opus와 Sonnet이 어떤 노력 수준에서도 도달할 수 없는 작업을 완료했습니다. 또한 토큰당 비용이 가장 많이 들기 때문에 정말로 필요한 작업을 위해 아껴두는 또 다른 이유이기도 합니다.
곡선은 설명 목적으로만 표시되었으며, 두 모델을 모두 확장할 수 있을 만큼 어려운 단일 작업에 대해 표시되었습니다. 실제 벤치마크 데이터를 나타내지 않습니다.
위 그래프의 핵심 포인트: 노력은 Claude가 곡선을 따라 기꺼이 이동할 거리를 선택합니다. 이것이 Claude가 작업을 완료하기 위해 그만큼 멀리 가야 한다는 것을 의미하지는 않습니다.
마지막으로, 노력은 토큰 소비를 형성하지만, 제한하지는 않습니다. 시스템의 유일한 하드 캡은 max_tokens로, 이에 도달하면 응답을 중간에 자르지만, 이는 무딘 도구이며 주로 API 개발자와 관련이 있습니다. 작업 예산 또는 프롬프트에서 Claude에게 간결하게 요청하는 것과 같은 소프트 제어가 더 유용합니다. 이는 모델이 따르도록 훈련된 지침(한계에 가까워지면 마무리를 시도함)이며, 모델이 부딪히는 벽이 아닙니다.
노력은 Claude가 수행하는 작업량을 변경합니다. 모델은 Claude가 알고 있는 것을 변경합니다.
결과에 만족하지 못할 때는 설정을 건드리기 전에 컨텍스트를 확인하세요: Claude에게 명확한 프롬프트, 올바른 도구와 기술, 그리고 자신의 작업을 확인할 방법을 제공하세요.
Claude가 여전히 틀리다면, 스스로에게 물어보세요: 충분히 알지 못했습니까, 아니면 충분히 시도하지 않았습니까? 충분히 알지 못하는 것은 모델 문제이고, 충분히 시도하지 않은 것은 노력 문제입니다.
이 글은 Claude Code 팀의 기술 스태프인 @lydiahallie가 작성했습니다.
