최신 Claude 모델의 가장 큰 장점 중 하나는 Claude Code 에서 프롬프트 캐시를 깨지 않으면서도 effort(노력) 수준에 따라 유연하게 반응한다는 점입니다. 하지만 이 부분에 대해 사용자분들로부터 정말 많은 질문을 받았습니다. effort 란 정확히 무엇이며, 어떤 상황에서 어떤 effort 레벨을 사용해야 할까요?そもそも effort 가 왜 필요할까요?
이 질문에 답하기 위해 저는 eval(평가) 데이터를 깊이 파고들어, 실제 일상적인 업무에서 effort 를 직접 테스트해 보기로 했습니다.
참고: 이 글과 관련된 인터랙티브 다이어그램 및 추가 설명은 https://claude.dev/blog/spending-your-effort/ 에서 확인하실 수 있습니다.
크게 보면, effort 는 Claude 가 검증과 엣지 케이스 테스트를 얼마나 수행할지, 그리고 자체적인 판단력을 어느 정도 활용할지를 조절하는 훌륭한 방법이라는 것을 알게 되었습니다.
추가적인 effort 를 투입했을 때 하드웨어, 코드 리뷰, 보안처럼 검증과 엣지 케이스 테스트가 중요한 영역에서 더 나은 결과를 얻을 수 있었습니다.
반면 low 나 medium effort 는 작업을 빠르게 처리하고 Claude 와 긴밀하게 협업하며 진행 상황을 파악하기에 완벽했습니다.
일반적인 소프트웨어 엔지니어링 작업의 경우, 저는 이제 모델을 먼저 저와 인터뷰하게 만든 뒤 low/medium effort 로 구현하고, 결과물을 검토한 다음 high effort 로 검증을 실행하는 루프를 사용하고 있습니다.
effort 란 무엇인가요?
큰 틀에서 effort 는 모델에게 해당 작업에 얼마나 많은 컴퓨팅 자원을 쏟을지에 대한 대략적인 가이드라인을 제공합니다. 이는 여러분이 생각하는 작업의 난이도와 어느 정도 연관이 있습니다.
이렇게 생각해 보세요. 누군가 여러분에게 12 시간 내내 쉬지 않고 무언가를 해달라고 부탁한다면, 그냥 묵묵히 최선을 다해 해내길 바란다고 생각할 것입니다. 반면 같은 작업을 1 시간 안에 끝내달라고 한다면, 요구사항을 충족하는 최선의 버전을 빠르게 만들어 보여주고 이후 피드백을 받으며 수정해 나갈 것이라 기대하겠죠.
아니면 "이 작업은 최소한 3 시간은 걸립니다"라고 반박하고, 실제로 3 시간 동안 작업해서 결과물을 전달할 수도 있습니다.
effort 도 이와 똑같이 생각하시면 됩니다. Claude 는 항상 여러분의 작업을 합리적으로 수행하려 노력하지만, effort 가 높아질수록 Claude 가 스스로 판단하고 검증하기 위해 독립적으로 행동하는 비중이 커집니다.
Effort 곡선
Fable 5.1 과 Opus 5.5 의 effort 곡선은 지금까지 나온 것 중 최고입니다. 각 레벨마다 벤치마크 점수와 소모된 토큰 수가 함께 상승합니다. 아래는 이 글을 작성하기 위해 제가 eval 을 실행하면서 측정한, effort 별 Terminal Bench 3.0 점수 그래프입니다.
그렇다면 실제 환경에서는 이것이 어떤 의미일까요? 이를 평가하기 위해 여러 effort 레벨에서 다양한 작업을 시도해 보고 벤치마크를 꼼꼼히 분석했습니다.
Effort 를 활용한 개발
모델이 어떻게 작동하는지 이해하는 가장 좋은 방법은 직접 실험해 보는 것입니다. 저는 Opus 5.5 에서 동일한 작업을 여러 effort 레벨로 수행해 보며 모델이 어떤 식으로 일하는지 파악해 보았습니다. 다양한 종류의 작업으로 테스트했지만, 여기서는 이해를 돕기 위해 몇 가지 간단한 예시로 설명하겠습니다.
요구사항이 불명확한 빌드 작업
Claude 에게 "개인 피트니스 및 운동 트래커 앱을 만들어 줘"라고 요청하면, effort 에 따라 앱의 완성도가 극적으로 달라지며 동시에 Claude 가 중간중간 내리는 결정의 수도 늘어납니다. low effort 에서는 피트니스 앱이 단순한 기록 로그와 기본적인 그래프 하나에 불과합니다. effort 레벨이 올라갈수록 앱은 더 복잡해지고 세부 사항이 추가됩니다. max effort 에서는 히트 차트까지 포함됩니다.
반복 개선(iteration)을 위한 간단한 기초가 필요하다면 low effort 로 충분합니다. max effort 는 Claude 가 단번에 내놓을 수 있는 최고의 결과물이 필요할 때 적합합니다.
요구사항이 약간 명시된 디자인 작업
이미 어느 정도 구체화된 작업이지만, Claude 와 함께 다양한 시도를 탐색해 보고 싶다면 어떨까요? 예시로 Claude Code 의 /config 메뉴를 재디자인해 달라고 요청해 보았습니다. 모든 시도에서 서브메뉴를 활용하고 검색 기능을 개선한다는 대략적인 아이디어는 동일했습니다.
low effort (1 분 소요) 에서는 아이디어를 잘 전달하지만 Claude Code 와는 거리가 먼 인터랙티브 스케치를 얻었습니다.
max effort (28 분 소요) 에서는 Claude Code 와 매우 흡사한 목업과 함께 다양한 흐름(flow)에 대한 상세한 설명을 받을 수 있었습니다.
목적이 피드백을 주며 반복 개선하는 것이라면 low effort 가 훨씬 빠르게 도달할 수 있습니다. 하지만 max effort 는 처음부터 훨씬 세련된 결과물을 제공합니다. 다만 이 특정 작업의 경우, 저는 Claude 의 구상을 파악하기 위해 low effort 를 사용하는 것이 더 좋다고 생각합니다.
요구사항이 명확한 빌드 작업
Claude 에게 아주 구체적인 세부 사항을 제공하면 어떨까요? 저는 Claude 에게 피트니스 앱에 대해 심층 인터뷰를 하도록 요청한 뒤, 그 명세(spec)를 바탕으로 서로 다른 모델들이 각기 다른 effort 레벨로 구현하도록 했습니다.
이렇게 명세가 주어지자 모델들의 행동이 훨씬 비슷해진다는 것을 발견했습니다. 전반적으로 유사해 보이는 디자인과 비슷한 구현 방식이 나왔지만 세부 사항은 달랐고, max effort 에서는 Claude 가 일부 세부 사항을 단순화하는 데 시간을 들였습니다.
핵심 요약
일반적인 소프트웨어 엔지니어링, 특히 새로운 기능 개발 작업에서는 제가 얼마나 개입하고 싶은지에 따라 effort 레벨이 크게 달라집니다. low effort 는 Claude 가 출발점을 빠르게 제시하게 해주며, 높은 effort 레벨은 더 많은 작업을 처리하지만 대신 Claude 가 저를 대신해 더 많은 가정을 하게 됩니다.
제가 기능 개발에 유용하게 사용하고 있는 루프는 다음과 같습니다.
- Claude 에게 명세를 제공하고 누락된 세부 사항에 대해 저와 인터뷰하도록 요청
- low effort 로 구현
- 핵심 내용을 올바르게 파악했는지 검토하고, 필요시 low effort 로 반복 개선
- high effort 로 검증 및 테스트
어려운 작업에서 effort 레벨이 결과물에 미치는 영향
물론 위의 예시들은 Claude 가 충분히 해낼 수 있는 간단한 것들이었습니다. 그렇다면 Claude 가 작업을 완수하느냐 마느냐의 갈림길에 서 있는 상황에서는 어떨까요?
이런 까다로운 문제를 찾기 위해서는 벤치마크를 살펴봐야 합니다. 그래서 제가 좋아하는 커뮤니티 기반 벤치마크인 Terminal Bench 3 를 파고들었습니다.
Terminal-Bench 3.0 의 문제들은 크게 보안, 하드웨어, ML, 과학, 소프트웨어, 운영, 미디어 등의 카테고리로 나눌 수 있습니다. 모든 문제는 여기서 확인할 수 있습니다: https://github.com/harbor-framework/terminal-bench/releases/tag/v3.0.0. 커뮤니티에서 수집된 것이므로 누구나 기여할 수 있습니다.
이 모델들이 직면하는 문제 유형을 파악하려면 한번쯤 읽어볼 가치가 있습니다. 저는 이 작업들의 범위와 야심 찬 목표에 꽤 놀랐습니다. 제가 평소에 마주치는 일반적인 작업보다 훨씬 복잡했습니다.
예를 들어 다음과 같은 작업들이 포함되어 있었습니다.
- 하드웨어 (retro-console-soc): 소형 FPGA 에 맞고 테스트 ROM 을 렌더링하는 8 비트 게임 콘솔을 Verilog 로 구축.
- 과학 (takens-embedding-lean): Lean 4 에서 Takens 임베딩 정리를 형식적으로 증명.
- ML (mp-checkpoint-consolidation): mixture-of-experts 체크포인트의 16 개 샤드를 참조 logit 을 재현하는 단일 파일로 병합.
- 운영 (intrastat-meldung): 기업의 월말 EU 무역 통계 신고를 처음부터 끝까지 처리.
- 미디어 (layout-config-recreation): 포스터 이미지를 편집 가능한 레이아웃 파일로 재구성.
엣지 케이스가 많을 때는 높은 effort 레벨이 유리합니다
Terminal Bench 3 결과를 분석하며 얻은 가장 큰 인사이트는 숨겨진 엣지 케이스가 많은 작업에는 높은 effort 가 최적이라는 점이었습니다.
대표적인 예로 html-js-filter 가 있습니다. 이는 페이지에 JavaScript 를 몰래 삽입(smuggling)하는 모든 방법을 차단하는 HTML 새니타이저를 요구하는 Terminal-Bench 3.0 작업입니다. Fable 5.1 은 low 에서 1/5 였던 점수가 xhigh 에서 5/5 로 올랐습니다.
low effort 에서의 일반적인 시도는 약 2 분이 걸렸습니다. 각 시도는 대략 한 번의 패스로 필터를 작성한 뒤, 손으로 작성한 단일 페이지로만 테스트했습니다.
high effort 실행은 약 33 분이 소요되었습니다. 제가 추적한 실행에서 모델은 자신의 초안을 적대적 관점으로 검토하고, 설치된 파서의 소스 코드를 읽어 버그를 확인했으며, 입력과 동일한 출력이 나올 때까지 수많은 정상 테스트 케이스를 실행하고, 표준 XSS 테스트 스위트를 돌린 뒤 마지막으로 랜덤 문서 퍼저(fuzzer)를 작성했습니다.
HTML 새니타이저처럼 엣지 케이스가 중요한 작업이라면 이러한 추가 effort 는 충분히 가치가 있습니다. 철저함을 위해 더 많은 토큰을 소모하는 것은 성능 최적화나 보안 리뷰처럼 프로덕션 요구사항이 높은 복잡한 작업에서도 타당합니다.
하지만 모든 작업에 이 정도의 effort 가 필요한 것은 아닙니다.
아래 다이어그램은 다양한 모델과 effort 레벨에 걸쳐 모든 Terminal-Bench 3.0 결과와 실패 원인을 보여줍니다. 전반적으로 effort 를 높이면 엣지 케이스 누락으로 인한 실패(보라색 블록)는 줄어드는 경향이 있지만, 모델이 잘못된 접근 방식을 취했을 때(파란색 블록)는 해결되지 않습니다.
Effort 가 도움이 되는 문제 영역
TerminalBench 에서 이 모델들을 평가하며 제가 얻은 가장 흥미로운 결론 중 하나는, effort 의 혜택을 유독 많이 받는 문제 영역이 따로 있다는 점이었습니다. 다음 다이어그램에서 세부 내역을 확인할 수 있습니다.
이를 설명하기 위해 Terminal Bench 3.0 의 여러 영역에서 Opus 5.5 가 low effort 에서는 실패했지만 high effort 에서는 성공한 문제들을 골라보았습니다. 대부분 엣지 케이스를 테스트하고 고려했기 때문이었습니다.
mvcc-lsm-compaction: 크래시 리포트를 기반으로 스토리지 엔진 버그를 수정하되 컴팩션을 망가뜨리지 않아야 하는 Terminal-Bench 3.0 작업입니다. Opus 5.5 는 low 에서 0/5 였으나 xhigh 에서 4/5 로 향상되었습니다.
low (시도당 약 1 분) 에서는 Claude 가 코드를 빌드하거나 재현기를 실행하기 전에 먼저 코드를 수정했고, 새로 작성한 테스트가 원래 버그를 잡아낼 수 있었는지 확인하지 않았습니다.
xhigh (약 11 분) 에서는 Claude 가 먼저 크래시를 재현하고, 절대 컴팩션하지 않는 참조 구현을 대상으로 무작위 테스트를 작성한 뒤, 절반만 완료된 수정본에서 테스트가 실패하는지 확인했습니다.
cli-2ph-simple: Python 으로 작성된 CLI 선형 계획법(linear-program) 솔버를 요구하는 Terminal-Bench 3.0 작업입니다. Opus 5.5 는 low 에서 0/5 였으나 high 에서 5/5 를 달성했습니다.
low 시도에서는 한 번의 패스로 솔버를 작성하고 몇 가지 작은 문제로 확인한 뒤 약 10k 토큰 부근에서 멈췄습니다. 마지막 메시지에서 Claude 가 큰 문제에서는 느릴 수 있다고 경고했지만, 실제로 확인하지는 않았습니다.
high 시도에서는 별도의 브루트 포스(brute-force) 솔버를 기준으로 무작위 문제에 대해 솔버를 테스트하고, 더 큰 문제의 실행 시간을 측정했으며, 지나치게 오래 걸리거나 크래시가 발생하는 사례를 발견하여 검색 방식을 재설계했습니다.
gsea-proteomics: 8 가지 치료법 중 어느 것이 대상 조직과 유사한지 찾기 위해 프로테오믹스 데이터에 대한 유전자 집합 농축 분석(GSEA)을 요구하는 Terminal-Bench 3.0 작업입니다. Opus 5.5 는 low 에서 0/5 였으나 high 에서 4/5 로 향상되었습니다.
low effort 에서 Claude 는 그럴듯해 보이는 데이터 준비 방법을 선택해 한 가지 방식으로만 분석을 실행하고 결과를 보고했습니다.
high 에서는 두 가지 방법으로 데이터를 준비해 보았고, 유의미한 치료법 목록이 달라지는 것을 발견한 후 올바른 방법을 선택하기 전에 그 이유를 깊이 파고들었습니다.
사용자가 개입하는 상황이었다면 Claude 가 문제 설정 방법에 대해 사용자에게 질문했을 수도 있지만, 사용자가 없는 상황에서는 high effort 가 더 나은 결과를 냅니다.
Claude Code 에서 effort 레벨을 언제 사용해야 할까
어떤 effort 레벨을 언제 사용해야 하는지에 대한 저만의 경험칙은 다음과 같습니다.
- Low: 브레인스토밍, 스케치, 간단한 변경 등 긴밀히 소통하며 빠른 응답을 원할 때
- Medium: 새로운 기능 구현 등 대부분의 일반적인 소프트웨어 엔지니어링 작업
- High: 검증이 중요하거나 엣지 케이스가 존재하는 작업 (예: 브라운필드(brownfield) 코드베이스의 버그 수정)
- Max: 어려운 문제를 해결하기 위해 Claude 가 완전히 자율적으로 작동하기를 원할 때 (예: 앱의 처음부터 끝까지 구축 및 검증, 핵심 소프트웨어의 보안 취약점 탐색)
Claude Code 에서 /effort 명령어를 사용해 작업에 따라, 또는 대화 중간에도 Opus 5.5 와 Fable 5.1 의 effort 를 자유롭게 조절해 보고, 여러분의 직관과 일치하는지 알려주세요.
