최신 Claude 모델의 가장 좋은 점 중 하나는 Claude Code의 프롬프트 캐시를 무효화하지 않으면서 effort 설정에 따라 동작을 달리한다는 것입니다. 하지만 사용자들에게 이와 관련한 질문을 많이 받았습니다. effort란 정확히 무엇이며, 각 수준은 언제 사용해야 할까요? 애초에 effort가 왜 필요할까요?
이 질문에 답하기 위해 평가 결과를 깊이 살펴보고, 일상적인 작업에서도 effort에 따른 차이를 직접 실험해 보기로 했습니다.
참고: 이 글에 관한 더 많은 인터랙티브 도표와 설명은 https://claude.dev/blog/spending-your-effort/에서 볼 수 있습니다.
전반적으로 effort는 Claude가 검증과 예외 사례 테스트를 얼마나 수행하고, 자체적인 판단을 얼마나 활용할지 조절하는 데 매우 유용했습니다.
하드웨어, 코드 리뷰, 보안처럼 검증과 예외 사례 테스트가 더 유용한 분야에서는 effort를 높였을 때 더 좋은 결과를 얻었습니다.
반면 작업을 빠르게 처리하고 Claude와 계속 상호작용하기에는 low와 medium이 아주 적합했습니다.
일반적인 소프트웨어 엔지니어링에서는 이제 모델이 저를 인터뷰하게 한 다음, low나 medium으로 구현하고, 구현 결과를 검토한 뒤, high로 검증하는 과정을 반복하고 있습니다.
effort란 무엇인가?
대체로 effort는 모델이 작업에 어느 정도의 연산 자원을 쓰기를 원하는지 대략적으로 알려주는 설정입니다. 작업의 난이도를 어떻게 판단하느냐와도 어느 정도 관련이 있습니다.
이렇게 생각해 보세요. 누군가 어떤 일을 12시간 동안 쉬지 않고 해달라고 하면, 그저 그 일을 완수하기 위해 최선을 다해달라는 뜻이라고 받아들일 수 있습니다. 같은 일을 1시간 안에 해달라고 한다면, 요구를 충족하는 범위에서 가장 좋은 결과를 내고, 그 결과를 바탕으로 개선을 반복할 것이라고 생각할 것입니다.
또는 그 일에는 적어도 3시간이 필요하다고 이의를 제기하고, 3시간 동안 작업해서 결과를 전달할 수도 있습니다.
effort도 같은 방식으로 생각하면 됩니다. Claude는 언제나 작업을 합리적으로 수행하려고 하지만, effort가 높아질수록 판단과 검증을 위해 더 독립적으로 행동합니다.
effort 곡선
Fable 5.1과 Opus 5.5의 effort 곡선은 지금까지 나온 모델 중 가장 좋습니다. effort 수준이 올라갈 때마다 벤치마크 점수와 토큰 사용량이 함께 증가합니다. 아래 그래프는 이 글을 위해 제가 직접 평가하면서 측정한 effort별 Terminal Bench 3.0 점수입니다.
그렇다면 실제 작업에서는 어떤 의미가 있을까요? 이를 평가하기 위해 여러 작업을 서로 다른 effort 수준으로 수행하고 벤치마크 결과를 꼼꼼히 살펴봤습니다.
effort를 조절하며 만들기
모델의 동작을 이해하는 가장 좋은 방법은 실험하는 것입니다. Opus 5.5가 어떤 작업을 수행하는지 이해하기 위해 같은 작업을 여러 effort 수준에서 시도했습니다. 다양한 작업으로 실험했지만, 여기서는 몇 가지 간단한 예시로 설명하겠습니다.
요구사항이 구체적이지 않은 개발 작업
Claude에게 “개인용 피트니스 및 운동 기록 앱을 만들어줘”라고 요청하면, effort에 따라 앱이 얼마나 구체적으로 구현되는지가 크게 달라집니다. 동시에 Claude가 구현 과정에서 내리는 결정도 많아집니다. low에서 피트니스 앱은 기록 기능과 간단한 그래프만 제공합니다. effort를 높이면 세부 기능이 추가되면서 앱이 더 복잡해집니다. max에서는 히트맵도 생깁니다.
반복해서 개선할 간단한 초기 구현이 필요하다면 low면 충분합니다. Claude가 한 번에 최선의 결과를 내기를 원한다면 max를 선택할 것입니다.
요구사항을 어느 정도 제시한 디자인 작업
작업의 요구사항이 이미 꽤 정해져 있지만 Claude와 함께 가능성을 탐색하고 싶다면 어떨까요? 예를 들어 Claude Code의 /config 메뉴를 다시 디자인해 달라고 요청했습니다. 모든 시도에서 하위 메뉴와 개선된 검색 기능을 사용한다는 대체로 비슷한 아이디어가 나왔습니다.
low에서는 1분이 걸렸고, 아이디어를 전달하는 인터랙티브 스케치를 얻었습니다. 하지만 Claude Code와는 별로 닮지 않았습니다.
max에서는 28분이 걸렸고, Claude Code와 아주 비슷한 목업을 얻었습니다. 여러 사용 흐름을 설명하는 자료도 다수 제공했습니다.
제 목표가 피드백을 주고받으며 반복해서 개선하는 것이라면 low가 훨씬 빠릅니다. 하지만 max는 처음부터 훨씬 더 다듬어진 결과를 줍니다. 이 작업에서는 Claude가 구상한 방향을 이해하기 위해 low를 사용하는 편이 더 좋다고 생각합니다.
요구사항을 상세히 제시한 개발 작업
Claude에게 세부사항을 많이 알려주면 어떨까요? 피트니스 앱에 관해 저를 심층적으로 인터뷰해 달라고 요청한 다음, 그렇게 만든 명세를 서로 다른 모델에 주고 여러 effort 수준에서 구현하게 했습니다.
이 명세를 제공하자 모델들의 동작이 훨씬 비슷해졌습니다. 디자인은 상당히 비슷했고 구현도 유사했지만, 세부사항에는 차이가 있었습니다. max에서는 Claude가 시간을 들여 일부 세부사항을 단순화했습니다.
얻은 교훈
일반적인 소프트웨어 엔지니어링, 특히 새로운 기능을 개발하는 작업에서는 제가 과정에 얼마나 관여하고 싶은지에 따라 적절한 effort 수준이 크게 달라집니다. low에서는 Claude가 빠르게 출발점을 제시합니다. effort를 높이면 더 많은 작업을 수행하지만, 그만큼 저를 대신해 더 많은 가정을 하기도 합니다.
최근 기능 개발에서 특히 좋은 효과를 보고 있는 반복 과정은 다음과 같습니다.
- Claude에게 명세를 주고, 빠뜨린 세부사항이 있다면 저를 인터뷰해 달라고 요청합니다.
- low로 구현합니다.
- 핵심 의도를 제대로 이해했는지 검토하고, 필요하면 low로 개선을 반복합니다.
- high로 검증하고 테스트합니다.
어려운 작업에서 effort 수준이 결과에 미치는 영향
물론 앞서 든 사례들은 Claude가 충분히 완수할 수 있는 간단한 예시입니다. 그렇다면 effort에 따라 작업의 성공과 실패가 갈리는 경우는 어떨까요?
이런 어려운 문제를 찾으려면 벤치마크를 봐야 합니다. 그래서 제가 좋아하는 커뮤니티 기반 벤치마크인 Terminal Bench 3를 깊이 살펴봤습니다.
Terminal-Bench 3.0의 문제는 크게 보안, 하드웨어, 머신러닝, 과학, 소프트웨어, 운영, 미디어 등의 범주로 나눌 수 있습니다. 전체 문제는 https://github.com/harbor-framework/terminal-bench/releases/tag/v3.0.0에서 볼 수 있습니다. 커뮤니티에서 수집한 문제이므로 누구나 기여할 수 있습니다.
모델들이 어떤 종류의 문제에 직면하는지 감을 잡으려면 한번 읽어볼 만합니다. 저는 많은 작업의 범위와 목표 수준을 보고 놀랐습니다. 제가 평소에 접하는 보통의 작업보다 훨씬 복잡했습니다.
예를 들면 다음과 같은 작업이 있었습니다.
- 하드웨어(retro-console-soc): 소형 FPGA에 들어가며 테스트 ROM을 실행해 화면에 결과를 출력하는 8비트 게임 콘솔을 Verilog로 만듭니다.
- 과학(takens-embedding-lean): Lean 4에서 타켄스의 매장 정리를 형식적으로 증명합니다.
- 머신러닝(mp-checkpoint-consolidation): 전문가 혼합 모델 체크포인트의 샤드 16개를 기준 로짓을 재현하는 하나의 파일로 병합합니다.
- 운영(intrastat-meldung): 기업의 월말 EU 무역 통계 신고를 처음부터 끝까지 수행합니다.
- 미디어(layout-config-recreation): 포스터 이미지를 편집 가능한 레이아웃 파일로 재구성합니다.
예외 사례가 많을 때는 높은 effort가 도움이 됩니다
Terminal Bench 3 결과를 읽고 얻은 가장 큰 교훈은 숨겨진 예외 사례가 많은 작업에 높은 effort가 가장 적합하다는 것이었습니다.
명확한 사례는 Terminal-Bench 3.0의 html-js-filter입니다. 페이지에 JavaScript를 몰래 삽입하는 모든 방식을 차단하는 HTML 정화기를 만드는 작업입니다. Fable 5.1의 성공 횟수는 low에서 5회 중 1회였지만, xhigh에서는 5회 중 5회로 늘었습니다.
low에서 일반적인 시도는 약 2분이 걸립니다. 각 시도에서는 대체로 한 번에 필터를 작성한 뒤, 직접 작성한 페이지 하나로 테스트했습니다.
high에서는 실행을 완료하는 데 약 33분이 걸립니다. 제가 추적한 실행에서 모델은 첫 구현의 취약점을 적극적으로 찾는 방식으로 검토했습니다. 그런 다음 설치된 파서의 소스 코드를 읽어 버그를 확인하고, 정상적인 테스트 사례를 다수 실행하면서 입력과 출력이 같아지는지 확인했습니다. 이어서 표준 XSS 테스트 모음을 실행하고, 마지막으로 무작위 문서를 생성하는 퍼저를 작성했습니다.
HTML 정화기처럼 예외 사례가 많은 작업이라면 이렇게 effort를 더 쓰는 것이 충분히 가치 있습니다. 성능 최적화나 보안 리뷰처럼 프로덕션 요구 수준이 높은 복잡한 작업에서도, 철저한 검증을 위해 더 많은 토큰을 쓰는 것은 합리적입니다.
하지만 모든 작업에 이 정도의 effort가 필요한 것은 아닙니다.
아래 도표는 여러 모델과 effort 수준에서 얻은 Terminal-Bench 3.0의 모든 결과와 실패 원인을 보여줍니다. 전반적으로 effort를 높이면 예외 사례를 놓쳐 발생하는 실패를 나타내는 보라색 블록은 줄어드는 경향이 있습니다. 하지만 파란색 블록으로 표시된, 모델이 잘못된 접근법을 택해서 발생하는 실패는 해결하지 못합니다.
effort가 도움이 되는 문제 분야
TerminalBench로 모델들을 평가하면서 특히 흥미로웠던 점은, 다른 분야보다 effort의 효과가 더 큰 문제 분야가 있다는 것이었습니다. 다음 도표에서 분야별 결과를 볼 수 있습니다.
이를 설명하기 위해 Terminal Bench 3.0의 여러 분야에서 Opus 5.5가 low에서는 실패했지만 high에서는 성공한 문제를 몇 가지 골랐습니다. 대부분 예외 사례를 테스트하고 고려했기 때문에 성공한 경우였습니다.
mvcc-lsm-compaction: 크래시 보고서를 바탕으로 저장 엔진의 버그를 수정하되, 컴팩션 기능을 손상하지 않아야 하는 Terminal-Bench 3.0 작업입니다. Opus 5.5의 성공 횟수는 low에서 5회 중 0회였지만, xhigh에서는 5회 중 4회로 늘었습니다.
low에서는 시도마다 약 1분이 걸렸습니다. Claude는 빌드하거나 재현 코드를 실행하기 전에 코드를 수정했고, 새로 작성한 테스트가 원래 버그를 잡아낼 수 있었는지도 확인하지 않았습니다.
xhigh에서는 약 11분이 걸렸습니다. Claude는 먼저 크래시를 재현한 뒤, 컴팩션을 전혀 수행하지 않는 기준 구현과 비교하는 무작위 테스트를 작성했습니다. 또한 수정이 불완전한 상태에서 테스트가 실패하는지도 확인했습니다.
cli-2ph-simple: Python으로 CLI 선형계획법 솔버를 작성하는 Terminal-Bench 3.0 작업입니다. Opus 5.5의 성공 횟수는 low에서 5회 중 0회였지만, high에서는 5회 중 5회로 늘었습니다.
low에서는 솔버를 한 번에 작성하고, 몇 가지 작은 문제로 확인한 다음, 약 1만 토큰을 사용한 시점에 작업을 마쳤습니다. 마지막 메시지에서 Claude는 큰 문제에서는 느릴 수 있다고 경고했지만, 실제로 확인하지는 않았습니다.
high에서는 무작위 문제를 풀어 얻은 결과를 별도의 완전 탐색 솔버로 얻은 결과와 비교하며 테스트했습니다. 그런 다음 더 큰 문제의 실행 시간을 측정하다가 지나치게 오래 걸리거나 크래시가 발생하는 사례를 발견했고, 탐색 방식을 다시 구현했습니다.
gsea-proteomics: 단백질체 데이터에 유전자 집합 농축 분석(GSEA)을 수행하여, 8가지 처리 조건 중 어느 조건이 목표 조직과 유사한지 찾아내는 Terminal-Bench 3.0 작업입니다. Opus 5.5의 성공 횟수는 low에서 5회 중 0회였지만, high에서는 5회 중 4회로 늘었습니다.
low에서 Claude는 타당해 보이는 데이터 전처리 방법을 골라, 그 방법으로만 분석한 뒤 결과를 보고했습니다.
high에서는 두 가지 전처리 방법을 시도했습니다. 유의미한 처리 조건의 목록이 달라진다는 점을 발견하고, 올바른 방법을 선택하기 전에 그 이유를 자세히 조사했습니다.
사용자가 과정에 참여했다면 Claude가 사용자에게 문제를 어떻게 설정할지 물었을 수도 있습니다. 하지만 사용자가 참여하지 않는 상황에서는 high가 더 좋은 결과를 냅니다.
Claude Code에서 각 effort 수준을 사용하기 좋은 때
제가 각 effort 수준을 선택할 때 사용하는 대략적인 기준은 다음과 같습니다.
- Low: 브레인스토밍, 스케치, 간단한 변경처럼 제가 과정에 참여하면서 빠른 응답을 원할 때 사용합니다.
- Medium: 새로운 기능 구현처럼 일상적인 소프트웨어 엔지니어링 작업 대부분에 사용합니다.
- High: 기존 코드베이스의 버그 수정처럼 검증이 중요하거나 예외 사례가 있는 작업에 사용합니다.
- Max: 앱을 처음부터 끝까지 개발하고 검증하거나 중요한 소프트웨어의 보안 취약점을 찾는 것처럼, Claude가 완전히 자율적으로 어려운 문제를 해결하기를 원할 때 사용합니다.
Claude Code의 /effort를 사용해 작업에 따라 Opus 5.5와 Fable 5.1의 effort를 바꿔 보세요. 대화 중간에도 바꿀 수 있습니다. 여러분의 직관과도 맞는지 알려주세요.
Deep Dive
2026-09-26
toy-crane/skills의 작업 단계에 적용하기
이번 논의에서는 원문의 effort 선택 기준을 toy-crane/skills의 제품 개발 파이프라인에 적용했다. Nexus의 저장·분류 스킬이 아니라, 제품 정의부터 구현과 검증까지 이어지는 개발 단계가 대상이다. 검토한 저장소는 당시 원격 main과 로컬 체크아웃이 일치했던 e2545e645782d2c78b6e8d5a4e4beaf22009ee08이다.
아래 표는 스킬이 요구하는 판단을 분석해 제안한 운영 가설이다. 동일 작업을 여러 effort로 실행해 비교한 결과나 저장소에 적용된 설정은 아니다. 수준 이름은 원문에서 사용한 Claude 기준이며, 다른 모델에서 같은 이름을 사용하더라도 성능이 같다고 가정하지 않는다.
| 단계 | 권장 기본값 | 판단 근거와 조정 조건 |
|---|---|---|
define-product |
medium | 사용자·상황·문제·핵심 사용 과정을 질문하고 답을 반영하는 단계다. 사용자가 제공해야 할 정보를 모델의 추가 추론으로 대체할 수는 없다. 기존 제품의 방향과 새 요구가 복잡하게 충돌하면 high를 검토한다. |
shape-idea |
high | 사용자 의도를 구현 가능한 계약으로 구체화하면서 실패·복구·권한·상태 전이의 누락을 찾아야 한다. 단순한 선택지를 보여주고 반응을 받는 순간에는 medium으로 낮출 수 있다. |
build-prototype |
medium | 화면을 보고 수정하는 반복 속도가 중요하다. 작은 배치나 표현 비교는 low, 복잡한 상태와 기준 화면의 정밀한 일치 검증은 high가 적합하다. |
split-into-tasks |
high | 명세 전체를 빠짐없이 포함하면서 독립적으로 전달 가능한 최소한의 작업으로 나눠야 한다. 의존성과 검증 시점의 오류는 후속 구현 비용을 키운다. |
implement의 구현 작업 |
medium | 명세와 작업 경계가 정해져 있으면 한 동작을 구현하고 테스트하는 데 집중할 수 있다. 변경이 작고 기존 패턴이 분명하면 low를 검토한다. |
implement의 통합 검증 |
high | 개별 테스트의 성공을 넘어 명세 전체, 기존 동작, 실제 사용자 과정까지 충족하는지 확인한다. 예외와 회귀를 찾는 데 추가 추론을 쓴다. |
human-review |
medium | 사람이 결과와 근거를 이해하고 판단하도록 돕는다. 보안이나 데이터 손실처럼 복잡한 쟁점을 설명할 때는 high를 검토한다. |
commit → pr → merge |
low 또는 medium | 변경 범위와 검사 결과가 분명하면 정형 절차의 비중이 크다. 충돌 해결이나 실패한 CI의 원인 분석이 필요하면 high로 올린다. |
shape-idea와 split-into-tasks에 high를 권하는 목적은 문서를 길게 쓰는 것이 아니다. 후속 작업 전에 “저장에 실패하면 화면과 데이터는 어떤 상태로 남는가?”, “이 작업은 독립적으로 출시할 수 있는가?”, “권한 검증을 마지막에 하면 이미 만든 기능을 다시 수정해야 하는가?” 같은 누락을 찾는 데 추론을 투자하는 것이다.
implement는 내부 작업에 따라 effort의 가치가 달라진다
implement는 단순한 코드 작성뿐 아니라 기존 결정과의 충돌 확인, 중단된 작업의 상태 복원, 실행 검증, 리뷰 결과 판단까지 맡는다. 따라서 원문의 “낮은 effort로 구현한다”는 제안을 스킬 전체에 일괄 적용하기보다, 범위가 명확한 구현 단계에 적용하는 편이 적절하다.
| 내부 작업 | 권장 effort |
|---|---|
| 명세·기존 결정·현재 코드의 충돌과 재개 상태 확인 | high |
| 명확한 한 동작을 구현하는 TDD 반복 | medium |
| 이미 정해진 테스트·빌드 명령 실행 | low |
| 실패 원인 분석과 테스트가 놓친 조건 탐색 | high |
| 리뷰 지적을 재현하고 실제 결함인지 판단 | high |
| 수정 후 실제 사용자 과정과 회귀 확인 | high |
실행 도중 수준을 바꾸기 어렵고 /implement 전체에 하나만 선택해야 한다면, 명세가 명확한 작은 기능은 medium, 기존 코드 여러 영역을 건드리는 기능은 high를 시작점으로 삼는다. 재현이 어려운 동시성·보안·성능 문제에서는 xhigh를 검토하되, max를 기본값으로 지정하는 단계는 두지 않는다는 제안이다. 이 구분 역시 실제 작업에서 검증해야 한다.
추론 강도와 스킬의 완료 기준을 구분한다
effort를 낮추더라도 원래 요구한 테스트, 실제 실행 검증, 명세 대조를 생략해서는 안 된다. 낮은 effort가 빠르더라도 사용자가 다시 지적해야 하는 누락과 수정 횟수가 늘면 전체 작업 비용은 오를 수 있다.
build-prototype의 effort=standard|high는 스킬이 수행할 작업 범위를 정하는 옵션이다. 모델의 추론 강도와 같은 설정이 아니다. standard에서도 요구된 화면·상태·상호작용을 구현하고 검증해야 하며, high는 기준 화면과의 정밀한 비교를 추가한다.
자동 코드 리뷰의 모드도 따로 판단한다. 검토 당시 implement는 특별한 근거가 없으면 Claude Code의 code-review medium을 선택하도록 되어 있었다. 구현 에이전트의 추론 강도가 high라는 이유만으로 리뷰 모드까지 high로 올릴 필요는 없다. 리뷰 모드가 바꾸는 검사 범위와 방식은 모델의 추론 강도와 구분해야 한다.
후속 관리와 글쓰기 단계에도 같은 기준을 적용한다
babysit-specs와 maintain-project-context에는 high를 권했다. 최신 코드에 맞춰 문구를 바꾸는 것뿐 아니라, 기존에 승인된 의미를 보존하는 수정인지 사용자가 다시 결정해야 하는 변경인지 구분해야 하기 때문이다.
글쓰기 파이프라인에서는 define-publication을 medium, define-piece를 high로 시작하고, draft-piece는 medium으로 작성한 뒤 high로 논리·사실·독자 이해를 검증하는 구성을 제안했다.
Key Insight
effort는 스킬 이름보다 그 순간 필요한 판단과 검증에 맞춰 배분한다. 사람의 반응을 받으며 방향을 정하고 명확한 내용을 구현할 때는 medium을 시작점으로 삼고, 후속 작업에 영향을 미치는 누락·의존성·예외·회귀를 찾을 때는 high에 투자한다. 강도를 낮춰도 완료 기준은 유지하고, 효과는 실행 시간과 재작업을 함께 측정해 판단한다.
References
- toy-crane/skills의 검토 당시 파이프라인: 각 단계의 역할과 산출물을 확인한 근거다.
- implement: 구현뿐 아니라 상태 복원, 계약 대조, 리뷰 판단, 실행 검증까지 포함하는 범위를 확인했다.
- build-prototype: 스킬의 작업 범위 옵션과 모델의 추론 강도를 구분한 근거다.
- Claude 공식 effort 안내: 작업과 모델에 따라 적절한 수준을 선택하고 품질을 평가해야 한다는 설명을 참고했다.