Claude Code에서 Claude 모델과 effort 수준 고르기

https://claude.com/blog/claude-model-and-effort-level-in-claude-code

핵심 요약:

• Claude 모델 선택은 고정된 가중치 집합, 즉 모델의 전반적인 능력 범위를 고르는 일입니다. 모델에 컨텍스트를 주거나 원하는 방향으로 유도할 수는 있지만, 모델이 가진 지식과 능력 자체는 이미 정해져 있습니다.
• Effort는 단순한 "생각 시간"이 아닙니다. 읽는 파일 수, 사용하는 도구, 사용자에게 다시 확인을 구하기까지 밟는 단계 수를 포함해, Claude가 요청 하나에 들이는 일의 양 전체를 조절합니다.
• 뻔하고 반복적인 작업에는 작은 모델을, 복잡하거나 모호한 작업에는 큰 모델을 고르세요. effort는 각 모델의 기본값으로 시작하고, 작업마다 바꾸기보다는 자신이 하는 일의 성격에 맞춘 전반적인 취향으로 조정하세요.
• 필요한 컨텍스트가 다 있고 Claude가 분명히 애를 썼는데도 틀렸다면, 더 뛰어난 모델을 골라야 한다는 신호입니다. 파일을 건너뛰거나, 테스트를 안 돌리거나, 리팩토링을 하다 말아서 틀렸다면 effort 수준을 높이세요.

Claude Code의 effort 수준과 모델 선택

Claude Code에는 "답을 더 좋게 만들어줄 것 같은" 설정이 두 가지 있습니다. 모델 설정과 effort 수준입니다. Claude Fable 5 같은 큰 모델이 Claude Sonnet보다 더 똑똑한 결과를 내고, effort 수준이 높으면 Claude가 답하기 전에 더 오래 생각한다고 짐작하기 쉽습니다.

첫 번째 짐작은 맞습니다. 업계 표준 벤치마크 기준으로, 가장 큰 모델이 실제로 더 뛰어납니다.

하지만 effort는 단순한 "생각 시간"이 아닙니다. effort 수준은 Claude가 요청 하나에 들이는 일의 양 전체를 조절합니다. 여기에는 모델이 생각하는 시간도 포함되지만, 그 외에도 다음을 좌우합니다.

• 파일을 몇 개나 읽을지
• 얼마나 검증할지
• 여러 단계짜리 작업을 사용자에게 확인받기 전에 어디까지 밀고 나갈지

effort가 높으면 Claude는 사용자에게 돌아오기 전에 이런 행동(예: 파일 읽기, 테스트 실행, 재확인)을 더 많이 합니다. effort가 낮으면 토큰을 써가며 스스로 알아내기보다는 사용자에게 컨텍스트를 더 달라고 묻는 쪽을 택합니다.

모델 선택은 어떻게 동작하나

엔터를 누르면 Claude Code는 사용자의 메시지를 시스템 프롬프트, 도구 정의, CLAUDE.md, 대화 기록, 컨텍스트에 있는 파일들과 하나로 묶습니다. 이 전부가 하나의 요청으로 API에 전송됩니다.

Claude Code가 가진 모든 것이 API 요청 하나에 담깁니다. 서버에서는 텍스트가 모델에 도달하기 전에 먼저 토큰화됩니다.

그런데 모델은 이것을 일반 텍스트 그대로 보지 않습니다. 서버에서 가장 먼저 일어나는 일이 토큰화입니다. 텍스트를 조각으로 쪼개고, 각 조각을 모델이 학습할 때 쓴 고정 어휘집의 정수 하나에 대응시킵니다. const는 1978에, await는 4293에 대응되는 식입니다. 이 시점부터 프롬프트는 정수 배열입니다.

토크나이저는 텍스트를 조각으로 쪼개 각 조각을 고정 어휘집의 정수에 대응시킵니다. 윗줄의 각 조각이 아랫줄의 토큰 ID가 됩니다. 그림의 ID는 예시입니다.

모델이 하는 일은 이 배열을 받아 다음에 올 토큰을 예측하는 것입니다. 어휘집의 모든 토큰에 대해 확률을 계산하고 상위권에서 고르는 방식입니다. const x = await 다음이라면, 잘 학습된 모델은 fetch에는 높은 확률(매우 그럴듯함)을, banana에는 0에 가까운 확률(전혀 그럴듯하지 않음)을 매깁니다.

모델의 예측은 어휘집의 모든 토큰에 매긴 확률입니다. 1순위 후보와 엉뚱한 토큰 사이의 격차는 어마어마합니다.

입력 토큰을 그 확률로 바꿔주는 것이 가중치(파라미터라고도 부릅니다)입니다. 커다란 행렬들로 정리된 수십억 개의 숫자죠. 토큰 하나를 예측하기 위해 모델은 입력을 그 행렬들, 즉 긴 행렬 곱셈의 연쇄에 통과시키고 맨 끝에서 확률을 읽어냅니다. 모델이 "아는" 모든 것이 이 가중치 안에 들어 있습니다.

각 모델의 가중치는 학습 중에 정해지며, 사용자가 요청을 보낼 시점에는 읽기 전용입니다. 프롬프트, CLAUDE.md, 컨텍스트 그 무엇도 가중치를 바꾸지 못합니다. (추론(inference)이라는 단어를 접해봤다면, 그 뜻이 바로 이것입니다. 학습이 끝난 뒤 가중치가 고정된 상태로 모델을 사용하는 것.)

프롬프트가 들어가면 확률이 나옵니다. 그 사이에 있는 가중치는 변하지 않습니다.

Claude가 아는 TypeScript, 유명 프레임워크, 관용적인 Go 코드, 그 밖의 모든 일반 프로그래밍 지식은 학습 시점에 이 가중치에 새겨진 것입니다.

프롬프트와 컨텍스트로 예측을 원하는 쪽으로 *유도(steering)*할 수는 있습니다(실제 코드를 Claude 앞에 놓아주는 것이 바로 유도이고, 아주 잘 통합니다). 하지만 가중치 자체에 무언가를 더하지는 못합니다.

모델이 학습될 때 없었던 라이브러리는 가중치에 없습니다. 문서를 컨텍스트에 넣어주면 Claude가 활용하긴 하지만, 그건 유도이지 가르치기가 아닙니다. 그 요청에 한해서만 응답에 영향을 줄 뿐, 모델 자체가 그 정보를 기억하게 되는 것은 아닙니다.

그래서 Claude가 존재하지 않는 API를 자신 있게 호출한다면(환각), 그것은 조회에 실패한 것이 아니라 가중치가 학습 패턴상 그럴듯해 보이는 토큰 열을 만들어낸 것입니다.

그렇다면 모델을 바꾸면 실제로 무슨 일이 일어날까요? 요청을 처리할 고정 가중치 세트를 다른 것으로 갈아 끼우는 것입니다.

모델은 답변 전체를 한 번에 만들지 않습니다. 토큰 하나를 예측해 시퀀스에 붙이고, 다음 토큰을 얻기 위해 전체 계산을 다시 돌립니다. 200토큰짜리 응답은 가중치를 200번 따로 통과한 결과입니다. 대기 시간과 출력 비용의 대부분이 이 루프에서 나옵니다.

시퀀스는 한 단계에 정확히 토큰 하나씩 자랍니다. 모델은 다음 토큰을 예측하기 위해 매번 배열 전체를 다시 읽습니다.

정리하면 모델 설정은 요청을 어느 가중치가 처리할지를 정하고, 출력 토큰 하나의 가격도 함께 정합니다.

다만 토큰이 몇 개나 생성될지는 정하지 않습니다. 같은 프롬프트라도 Claude가 일을 얼마나 하기로 하느냐에 따라 그 수는 크게 달라질 수 있습니다.

바로 이것을 effort 수준이 조절합니다. 각 턴에서 Claude가 얼마나 많은 일을 하기로 할지 말이죠.

Effort는 어떻게 동작하나

Claude Code가 작업을 수행할 때 생성하는 토큰은 몇 가지 범주로 나뉩니다.

• 생각(thinking): 행동 전과 행동 사이에 스트리밍으로 보이는 추론 과정.
• 도구 호출: Read나 Edit 같은 도구 이름과 인자를 담은 구조화된 블록. Claude Code가 이를 파싱해 실행합니다.
• 사용자에게 보내는 텍스트: 계획, 진행 상황 업데이트, 마지막 요약.

이것들은 모두 같은 루프에서 나오는 평범한 출력 토큰이고, 같은 단가로 과금됩니다. 예를 들어 생각 토큰도 다른 출력 토큰과 똑같은 방식으로 생성되며, 그 턴이 끝날 때까지 컨텍스트에 남습니다.

Claude가 코드를 쓰는 단계로 넘어가면, 앞서 했던 추론도 이미 읽은 파일과 똑같이 입력의 일부가 됩니다.

Claude의 출력은 전부 토큰입니다. 생각, 도구 호출, 사용자에게 보내는 텍스트 모두 같은 루프에서 생성됩니다.

그럼 effort는 여기서 무엇을 바꿀까요? effort 수준은 프롬프트와 나란히, 요청의 일부로 모델에 전달됩니다. 모델은 각 effort 수준에서 어떻게 행동해야 하는지를 학습했고, 그렇게 익힌 행동 방식은 고정된 가중치에 새겨져 있습니다.

요청이 도착하면 effort 수준은 모델이 반응하는 또 하나의 입력이 됩니다. 프롬프트 텍스트에 반응하는 것과 같은 방식이죠. 이것이 작업을 끝났다고 판단하기 전에 얼마나 꼼꼼해야 하고 얼마나 확신해야 하는지, Claude의 행동 기준을 정합니다.

이 기준은 매 턴 반영되며, 더 확신 있는 답을 만들기 위해 더 많은 토큰을 쓰는 결과로 이어집니다.

같은 프롬프트, 두 가지 effort 수준. 높은 effort 경로는 더 확신 있는 답에 도달하기 위해 대략 7배 많은 토큰을 생성합니다.

effort 수준이 높으면 Claude는 계획을 세우는 것으로 시작하는 경우가 많고, effort 수준은 그 계획의 깊이와 폭에 영향을 줍니다. 다만 계획이 한번 세워지면 그대로 굳는 것은 아닙니다. 행동의 결과가 돌아올 때마다 Claude는 진척 상황과, 쌓인 결과를 얼마나 확신할 수 있는지를 갱신합니다.

그래서 가설 세 개짜리 디버깅 계획의 1단계에서 버그를 찾으면, "가설 2와 3 조사"는 더 이상 필요한 행동이 아닐 수 있습니다. Claude는 보통 "첫 번째 확인에서 찾았으니 나머지 확인은 필요 없습니다"라고 명시적으로 말하고 건너뜁니다. Claude Code에서 작업 목록이 실행 도중 수정되는 게 바로 이 장면입니다.

effort 수준이 높을수록 Claude는 추가 가설을 재확인하거나 정확성을 검증하는 쪽으로 기울지만, effort가 높다고 해서 단순한 작업에서 사용량을 인위적으로 부풀리지는 않습니다. 실제로 저희 팀은 모델 학습 과정에서 "과잉 사고(overthinking)"를 예의주시합니다. 효과를 떨어뜨리기 때문입니다.

Effort 수준 고르기

저희의 권장 사항은 대부분의 작업에서 모델의 기본 effort 수준을 쓰라는 것입니다. 기본값은 대다수 사람이 그 작업에 쓰고 싶어 할 만한 양에 맞춰 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가 충분히 애쓰지 않았다

파일을 건너뛰거나, 테스트를 안 돌리거나, 자기 작업을 재확인하지 않아서 틀렸다면 effort 수준을 높이세요. 모델 기본값보다 낮은 effort 수준을 골라둔 경우에 특히 해당하는 이야기입니다.

Fable vs. Opus vs. Sonnet: 스페셜리스트, 전문가, 제너럴리스트

두 설정의 관계를 제가 즐겨 떠올리는 방식은 이렇습니다. Fable은 남들이 거의 못 본 문제까지 겪어본 스페셜리스트, Opus는 전문가, Sonnet은 아주 유능한 제너럴리스트입니다. effort 수준은 이들 중 누구든 당신의 작업에 시간을 얼마나 쓸지를 정합니다.

낮은 effort의 Opus는 당신과 비슷한 문제를 깊이 다뤄본 전문가와 5분 면담하는 것과 같습니다. 코드베이스 어디에도 없는 지식, 그러니까 전에 봤던 패턴, 확인해야 할 함정 같은, 비슷한 문제를 많이 풀어봐야만 생기는 것들을 가져다줍니다. 다만 5분만 준다는 건 코드를 꼼꼼히가 아니라 빠르게 훑어본다는 뜻입니다.

높은 effort의 Sonnet은 아주 유능한 제너럴리스트에게 오후를 통째로 내주는 것과 같습니다. 전부 읽고, 이것저것 실행해보고, 자기 작업을 재확인해서 결국 당신의 코드를 속속들이 이해하게 됩니다. 대신 "이거 전에 똑같은 걸 본 적 있다"는 알아봄은 상대적으로 부족합니다.

Fable은 낮은 effort로도, 모두가 막혀 있는 문제를 슬쩍 보고는 아무도 못 짚었을 지점을 짚어내는 그 스페셜리스트입니다. 가장 비싼 값을 치르는 게 바로 이 알아봄이니, 정말 필요한 작업을 위해 아껴둘 가치가 있습니다.

이 중 어느 것도 언제나 더 낫지는 않습니다. 모델 설정은 대략 얼마나 뛰어난가, effort 설정은 대략 얼마나 꼼꼼한가입니다. 실제 작업 대부분은 둘 다 어느 정도씩 필요합니다.

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

그럼 모델 선택, effort, 토큰 소비량은 서로 어떻게 얽힐까요? 작업에 따라 다릅니다.

뻔한 작업에서는 effort 수준이 같다면 두 모델 모두 대체로 맞게 해냅니다. 큰 모델은 검증 단계를 더 거치느라 토큰을 더 쓰는데, 토큰 단가도 더 비쌉니다. 그래서 뻔한 작업이 이어지는 구간에서 작은 모델로 내려가면 품질 손해 없이 돈이 실제로 절약됩니다.

곡선은 이해를 돕기 위한 예시일 뿐이며, 두 모델 모두 빠르게 끝낼 수 있을 만큼 단순한 작업 하나를 가정한 것입니다. 실제 벤치마크 데이터가 아닙니다.

더 어렵고 여러 단계를 거치는 작업에서는 계산이 달라집니다. 작은 모델은 반복을 거듭 태워가며 능력의 한계까지 몰아붙여야 하는 반면, 큰 모델은 더 적은 단계로 같은 품질 기준에 도달합니다.

큰 모델은 토큰당 값이 더 나가지만, 작은 모델이 정말로 버거워하는 작업이라면 작업당 총비용은 오히려 더 낮게 나올 수 있습니다. 더 중요한 건, 작은 모델이 effort를 최고로 올려도 못 해내는 작업을 큰 모델은 해낼 수 있다는 점입니다.

이 차이가 가장 두드러지는 게 Fable입니다. 길고 여러 단계를 거치는 작업에서 가장 멀리 앞서갑니다. 저희 테스트에서는 Opus와 Sonnet이 어떤 effort 수준으로도 도달하지 못한 일을 Fable이 끝까지 해냈습니다. 토큰당 비용도 가장 비싸니, 그럴 만한 일에 아껴 써야 할 또 하나의 이유이기도 합니다.

곡선은 이해를 돕기 위한 예시일 뿐이며, 두 모델 모두에게 버거울 만큼 어려운 작업 하나를 가정한 것입니다. 실제 벤치마크 데이터가 아닙니다.

위 그래프의 핵심은, effort 수준은 Claude가 곡선을 따라 어디까지 갈 의향이 있는지를 정할 뿐이라는 점입니다. 다시 말하지만, 작업을 끝내는 데 실제로 그만큼 멀리 가야 한다는 뜻은 아닙니다.

한 가지 더 짚자면, effort는 토큰 소비량을 좌우하긴 해도 제한하지는 않습니다. 시스템에서 유일한 강제 상한은 max_tokens로, 도달하는 순간 응답을 스트리밍 도중에 잘라버립니다. 무딘 도구라서 주로 API 개발자에게나 의미가 있습니다. 작업 예산(task budget)이나 프롬프트에서 짧게 해달라고 요청하는 것 같은 부드러운 제어 수단이 더 쓸모 있습니다. 이런 수단은 모델이 따르도록 학습된 지침으로 작동해서, 한도에 가까워지면 모델이 알아서 작업을 마무리하려 합니다. 부딪히고 마는 벽이 아니라요.

기본값으로 시작하고, 그다음에 다이얼에 손을 대세요

대부분의 경우 두 설정 모두 신경 쓸 필요가 없어야 정상입니다. 결과가 기대에 못 미치면 "Claude가 충분히 알지 못했나, 아니면 충분히 애쓰지 않았나?"를 묻고 필요한 쪽을 조정하세요.

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