클로드 코드(Claude Code)를 쓰다 보면 답이 마음에 안 들 때가 있어요. 그럴 때 손이 가는 설정이 두 개 있습니다. 하나 는 모델(Opus, Sonnet, Fable 중 무엇을 쓸지), 다른 하나는 effort(노력 수준)입니다. 둘 다 "결과를 더 좋게 만드는 것" 같은데, 실제로 뭐가 다른지, 언제 뭘 바꿔야 하는지는 헷갈리기 쉽습니다. 이 글에서 그 차이를 정리했습니다.
모델과 effort는 각각 무엇을 바꾸나
한 문장으로 요약하면 이렇습니다. 모델은 클로드가 무엇을 아는지를 바꾸고, effort는 클로드가 얼마나 많은 일을 하는지를 바꿉니다.
흔한 오해가 두 개 있어요. 첫째, 큰 모델(예: Fable)이 작은 모델(Sonnet)보다 똑똑한 답을 준다. 이건 맞습니다. 더 큰 모델은 업계 표준 벤치마크 기준으로 더 뛰어납니다. 둘째, effort를 올리면 클로드가 답하기 전에 더 오래 "생각한다". 이건 절반만 맞습니다.
effort는 단순히 생각하는 시간이 아니라, 클로드가 요청 전체에 얼마나 많은 작업을 쏟는지를 정합니다. 여기엔 생각하는 길이뿐 아니라 이런 것들이 포함됩니다.
- 파일을 몇 개나 읽는지
- 결과를 얼마나 검증하는지
- 여러 단계짜리 작업을 어디까지 밀어붙인 뒤 사용자에게 확인을 받는지
effort가 높으면 클로드는 사용자에게 돌아오기 전에 이런 행동(파일 읽기, 테스트 실행, 재확인)을 더 많이 합니다. effort가 낮으면 스스로 토큰을 써서 알아내기보다 사용자에게 더 많은 맥락을 물어보는 쪽을 택합니다.
모델 설정은 무엇을 고르는 것인가
모델이 실제로 무엇을 바꾸는지 이해하려면 가중치(weights) 개념을 알아야 합니다.
모델이 다음에 올 단어(토큰)를 예측할 때 쓰는 것이 가중치입니다. 수십억 개의 숫자로 이뤄진 거대한 행렬인데, 모델이 "아는" 모든 것이 여기에 담겨 있습니다. 타 입스크립트 지식이든, 유명 프레임워크 사용법이든, 일반적인 프로그래밍 지식이든 전부 학습 시점에 이 가중치에 새겨집니다.
핵심은 이 가중치가 학습이 끝나면 읽기 전용이라는 점입니다. 여러분의 프롬프트도, CLAUDE.md도, 맥락에 넣은 파일도 가중치 자체를 바꾸지 못합니다. 실제 코드를 클로드 앞에 놓는 건 "조종(steering)"이고 아주 잘 작동하지만, 가중치에 뭔가를 더하는 건 아닙니다.
그래서 학습 시점에 존재하지 않던 라이브러리는 가중치에 없습니다. 문서를 맥락에 넣으면 클로드가 그걸 활용하긴 하지만, 그건 가르치는 게 아니라 조종하는 것이고 그 한 번의 요청에만 영향을 줍니다. 클로드가 존재하지 않는 API를 자신 있게 호출하는 환각(hallucination)도, 학습 패턴상 그럴듯해 보이는 토큰을 가중치가 만들어낸 결과입니다.
정리하면 모델 설정을 바꾸는 건, 여러분의 요청을 처리할 가중치 세트를 통째로 교체하는 것입니다. 그리고 모델은 출력 토큰 하나당 비용도 함께 정합니다. 다만 토큰이 몇 개나 생성되는지는 모델이 정하지 않습니다. 그건 effort의 몫입니다.
effort는 무엇을 바꾸는가
클로드 코드가 작업하는 동안 만들어내는 토큰은 몇 가지로 나뉩니다.
- 생각(thinking): 행동 전후로 흘러나오는 추론
- 도구 호출(tool call): Read, Edit 같은 도구와 인자를 담은 블록
- 사용자에게 보내는 텍스트: 계획, 진행 상황, 마지막 요약
이 셋은 전부 같은 루프에서 나오는 평범한 출력 토큰이고 같은 요율로 과금됩니다. 생각 토큰도 다른 출력 토큰과 똑같이 생성되고, 그 턴 내내 맥락에 남습니다.
effort 수준은 프롬프트와 함께 요청에 담겨 모델에 전달됩니다. 모델은 각 effort 수준에서 어떻게 행동해야 하는지를 학습했고, 그 행동은 가중치에 새겨져 있습니다. effort는 클로드가 작업을 끝났다고 판단하기까지 얼마나 철저하게, 얼마나 확신을 가지고 일해야 하는지를 정합니다. 확신이 높을수록 도달하는 데 더 많은 토큰이 필요합니다.
Photo by Tim Schmidbauer on Unsplash
높은 effort에서 클로드는 종종 계획부터 세웁니다. 하지만 그 계획이 고정되는 건 아닙니다. 행동 결과가 돌아오면 진행 상황과 확신 정도를 갱신합니다. 예를 들어 가설 3개를 확인하는 디버깅 계획에서 1단계가 버그를 찾으면, 남은 2·3단계는 더 이상 필요 없을 수 있습니다. 이때 클로드는 대개 "첫 확인에서 찾았으니 나머지는 불필요"라고 명시하고 건너뜁니다. 클로드 코드에서 작업 목록이 도중에 수정되는 게 이 장면입니다.
한 가지 오해를 덧붙이면, 높은 effort가 무조건 토큰을 낭비하는 건 아닙니다. 간단한 작업인데 effort만 높다고 해서 사용량을 억지로 부풀리지는 않습니다. "과도하게 생각하기"는 효율을 떨어뜨리기 때문에 앤트로픽이 모델 학습 중 특별히 경계하는 항목입니다.
effort 수준은 어떻게 고를까
대부분의 작업에서는 모델의 기본 effort 수준을 그대로 쓰는 게 좋습니다. 기본값은 대부분의 사람이 그 작업에 쓰고 싶어 하는 만큼으로 토큰 사용을 맞춰둔 수준입니다.
effort는 "클로드가 얼마나 세게, 오래 일할지"에 대한 수동 조절 장치라고 생각하면 됩니다. 여러분의 분야나 작업 유형상 철저함 또는 속도에 강한 선호가 있을 때 의도적으로 손대세요. 작업마다 매번 바꾸는 게 아니라 일반적인 성향으로 다뤄야 합니다.
Opus 4.8 관련해 실용적인 팁이 하나 있어요. 앤트로픽 테스트에서, Opus 4.8의 기본 effort 설정은 같은 작업에 대해 Opus 4.7의 기본 effort와 비슷한 토큰으로 더 나은 결과를 냈습니다.
클로드가 틀렸을 때 무엇을 바꿀까
클로드가 틀렸을 때 첫 반응은 설정을 바꾸는 게 아니라 여러분이 준 맥락을 살펴보는 것이어야 합니다. 프롬프트가 너무 모호하지 않은지, 클로드가 올바른 도구에 연결됐는지, 적절한 스킬을 가졌는지 먼저 봅니다.
맥락을 충분히 줬는데도 틀렸다면, 스스로에게 이렇게 물어보세요. 충분히 노력하지 않은 걸까, 충분히 알지 못한 걸까.
- 모델을 키울 때 — 문제가 너무 어려웠다: 미묘한 버그, 낯선 도메인, 아키텍처 결정처럼 진짜 어려운 문제일 때. 맥락을 아무리 줘도 작은 모델이 자신 있게 틀린다면 큰 모델이 답입니다. 큰 모델은 모호함도 더 잘 다룹니다. 반대로 정확히 설명 가능한 수정, 기계적인 변경, 이미 맥락에 있는 코드에 대한 질문 같은 routine 작업이라면 작은 모델로 충분합니다.
- effort를 올릴 때 — 충분히 노력하지 않았다: 파일을 건너뛰거나, 테스트를 안 돌리거나, 검증을 안 한 경우. 특히 기본값보다 낮은 effort를 골라뒀을 때 해당합니다.
전문가, 전문직, 그리고 제너럴리스트
원문의 비유가 직관적입니다. Fable은 거의 아무도 다뤄본 적 없는 문제를 푸는 특수 전문가, Opus는 전문가, Sonnet은 아주 뛰어난 제너럴리스트입니다. effort는 이들 중 누구든 여러분의 작업에 얼마나 시간을 쓸지를 정합니다.
- 낮은 effort의 Opus: 여러분과 비슷한 문제를 깊이 겪어본 전문가와 5분간 만나는 것. 코드베이스 어디에도 없는 지식과 경험을 가져오지만, 5분이라 모든 파일을 꼼꼼히 보진 못합니다.
- 높은 effort의 Sonnet: 오후 내내 시간을 낸 제너럴리스트. 전부 읽고, 실행하고, 검증하며 여러분의 코드를 철저히 이해합니다.
- Fable: 다들 막혔을 때 부르는 특수 전문가. 낮은 effort에서도 아무도 못 보는 걸 짚어냅니다. 그만큼 비용이 가장 높으니 정말 필요한 작업에 아껴 쓰는 게 좋습니다.
어느 것도 무조건 "더 좋은" 건 아닙니다. 모델은 대략 "얼마나 유능한가", effort는 대략 "얼마나 철저한가"입니다. 대부분의 실제 작업은 둘 다 어느 정도 필요합니다.
자주 묻는 질문
클로드 코드에서 effort는 생각하는 시간만 늘리는 건가요?
아니요. effort는 생각 길이뿐 아니라 클로드가 요청에 쏟는 작업량 전체를 조절합니다. 파일을 몇 개 읽을지, 얼마나 검증할지, 여러 단계 작업을 어디까지 밀어붙일지가 모두 effort에 따라 달라집니다.
큰 모델이 항상 토큰을 더 많이 쓰나요?
routine 작 업에서는 큰 모델이 검증 단계를 더 밟아 토큰을 더 쓰고 단가도 높습니다. 하지만 작은 모델이 힘겨워하는 어려운 다단계 작업에서는, 큰 모델이 더 적은 단계로 같은 품질에 도달해 작업당 총비용이 오히려 낮게 나올 수 있습니다.
Opus와 Sonnet 중 뭘 골라야 하나요?
문제가 어렵고(미묘한 버그, 낯선 도메인, 아키텍처 결정) 맥락을 줘도 작은 모델이 자신 있게 틀린다면 Opus 같은 큰 모델을 쓰세요. 정확히 설명 가능한 기계적 수정이나 이미 맥락에 있는 코드 질문이라면 Sonnet으로 충분합니다.
인사이트
이 글에서 놓치기 쉬운 실전 포인트는 "설정을 바꾸기 전에 맥락부터 보라"는 순서입니다. effort를 올려야 할 것 같은 작업 상당수는, 사실 프롬프트나 CLAUDE.md, 작업 범위 설정을 손보면 풀립니다. 한국에서 클로드 코드를 팀으로 도입할 때 특히 그렇습니다. 팀원마다 effort를 제각각 올려 토큰만 태우는 것보다, 잘 쓰는 사람의 CLAUDE.md와 스킬 세팅을 공유하는 게 비용 대비 효과가 훨씬 큽니다.
또 하나, "충분히 알지 못한 것은 모델 문제, 충분히 노력하지 않은 것은 effort 문제"라는 진단 프레임은 클로드 코드에만 국한되지 않습니다. 어떤 AI 도구를 쓰든 결과가 아쉬울 때, 도구를 바꿀지(모델) 더 시키는 게 맞을지(노력)를 나눠서 보는 습관이 시행착오를 크게 줄여줍니다. 무작정 제일 큰 모델과 제일 높은 effort로 올려두는 건, 대부분의 일상 작업에서는 속도와 비용만 갉아먹는 선택이 되기 쉽습니다.
같은 모델·effort 이야기의 스펙과 벤치마크가 궁금하다면 Claude Sonnet 5 vs Opus 4.8 비교 글도 함께 보시면 도움이 됩니다.
원문: Claude Devs — Model and effort in Claude Code: knowing more vs. trying harder