Claude Code 활용법: effort, 어떻게 쓸 것인가

최신 Claude 모델의 가장 큰 장점 중 하나는 Claude Code에서 프롬프트 캐시를 깨뜨리지 않고도 effort에 따라 반응이 달라진다는 점입니다. 그런데 이와 관련해 사용자분들께 질문을 많이 받았습니다. effort란 정확히 무엇이고, 단계별로 언제 무엇을 써야 할까요? 애초에 왜 effort가 필요할까요?

이 질문에 답하려고 평가(eval) 결과를 깊이 분석하고, 일상적인 작업에서 effort를 바꿔 가며 직접 테스트해 봤습니다.

큰 그림에서 보면, effort는 Claude가 검증과 엣지 케이스 테스트를 얼마나 하고 자체 판단을 얼마나 활용할지 조절하는 좋은 수단이었습니다. 검증과 엣지 케이스 테스트가 특히 중요한 하드웨어, 코드 리뷰, 보안 같은 분야에서는 effort를 높일수록 결과가 더 좋았습니다.

일반적인 소프트웨어 엔지니어링에서는 다음과 같은 순환 과정을 씁니다. 먼저 모델이 저에게 인터뷰하게 하고, low effort로 구현한 뒤, 결과물을 리뷰하고, high effort로 검증을 돌립니다.

effort란 무엇인가

큰 틀에서 effort는 모델에게 이 작업에 컴퓨팅을 어느 정도 쓰길 원하는지 알려 주는 대략적인 신호입니다. 작업 난이도를 어떻게 보느냐와도 어느 정도 관련이 있습니다.

이렇게 생각해 보세요. 누군가 12시간 안에 어떤 일을 해 달라고 하면, 아마 일단 해내는 게 중요하고 최선을 다해 달라는 뜻으로 받아들일 겁니다. 같은 일을 1시간 안에 해 달라고 하면, 요구 사항을 충족하는 가장 좋은 버전을 먼저 내놓고 거기서부터 다듬어 가리라 예상하겠죠.

아니면 이 일은 최소한 3시간은 걸린다고 맞받아치고, 3시간 동안 작업해서 결과물을 내놓을 수도 있습니다.

effort도 같은 방식으로 이해하면 됩니다. Claude는 어떤 경우에도 작업을 합리적으로 수행하려 하지만, effort가 높을수록 판단과 검증을 위해 더 주체적으로 움직입니다.

effort 곡선

Fable 5.1과 Opus 5.5의 effort 곡선은 지금까지 나온 것 중 가장 좋습니다. 단계를 한 칸 올릴 때마다 벤치마크 점수와 토큰 소비량이 함께 늘어납니다.

그렇다면 실제로는 어떤 의미일까요? 이를 확인하려고 여러 작업을 effort 단계별로 시도해 보고, 벤치마크 결과도 꼼꼼히 살펴봤습니다.

effort별로 만들어 보기

모델의 동작 방식을 이해하는 가장 좋은 방법은 직접 실험해 보는 것입니다. Opus 5.5에서 같은 작업을 여러 effort 단계로 시켜 보며 어떤 일을 하는지 확인했습니다. 다양한 작업으로 실험했지만, 여기서는 간단한 예시 몇 가지만 소개합니다.

요구 사항이 모호한 개발 작업

Claude에게 "개인용 피트니스·운동 기록 앱을 만들어 줘"라고 하면, effort에 따라 앱의 완성도가 크게 달라지고, 그만큼 Claude가 중간에 내리는 선택도 많아집니다. low effort에서는 기록 목록과 간단한 그래프만 있는 앱이 나옵니다. effort가 높아질수록 앱이 복잡해지고 세부 요소가 늘어나며, max effort에서는 히트 차트까지 들어갑니다.

반복 개선의 출발점으로 삼을 간단한 기반이 필요하다면 low effort로 충분합니다. Claude가 한 번에 낼 수 있는 최고의 결과물을 원한다면 max effort를 쓰면 됩니다.

요구 사항이 일부만 정해진 디자인 작업

이미 어느 정도 정해진 작업이지만 Claude와 함께 탐색해 보고 싶다면 어떨까요? 예시로 Claude Code의 /config 메뉴를 다시 디자인해 달라고 요청해 봤습니다. 어느 단계에서든 서브메뉴를 쓰고 검색을 개선한다는 발상은 대체로 같았습니다.

low effort(1분 소요)에서는 아이디어는 전달되지만 Claude Code와는 그다지 닮지 않은 인터랙티브 스케치가 나왔습니다.

max effort(28분 소요)에서는 Claude Code와 매우 흡사한 목업에 더해 여러 흐름별 워크스루까지 받았습니다.

피드백을 주고받으며 다듬는 게 목적이라면 low effort가 훨씬 빠릅니다. 반면 max effort는 처음부터 훨씬 완성도 높은 결과물을 줍니다. 이번 작업에서는 Claude가 그리는 방향을 파악하는 용도로 low effort가 더 낫다고 생각했습니다.

요구 사항이 구체적인 개발 작업

Claude에게 세부 사항을 많이 알려 주면 어떨까요? 먼저 Claude에게 피트니스 앱에 대해 저를 깊이 있게 인터뷰하게 한 다음, 그렇게 만든 스펙을 여러 모델과 effort 단계에서 구현하게 해 봤습니다.

이 스펙을 주자 모델들의 동작이 훨씬 비슷해졌습니다. 디자인도 구현도 꽤 비슷했고 세부 사항만 조금씩 달랐습니다. max effort에서는 Claude가 시간을 들여 일부 세부 사항을 단순화하기도 했습니다.

핵심 정리

일반적인 소프트웨어 엔지니어링, 특히 신규 기능 개발에서는 작업 과정에 제가 얼마나 관여하고 싶은지에 따라 effort 단계가 크게 달라집니다. low effort에서는 Claude가 출발점을 빠르게 내놓습니다. effort가 높을수록 더 많은 작업을 끝내지만, 그만큼 Claude가 제 몫으로 가정하는 부분도 많아집니다.

기능 개발에서 특히 효과가 좋았던 순환 과정은 다음과 같습니다.

• Claude에게 스펙을 주고, 빠뜨린 세부 사항은 저에게 인터뷰로 물어보게 합니다
• low effort로 구현합니다
• 핵심을 제대로 파악했는지 리뷰하고, 필요하면 low effort로 반복해서 고칩니다
• high effort로 검증과 테스트를 진행합니다

어려운 작업에서 effort 단계가 결과에 미치는 영향

하지만 이런 예시는 Claude가 충분히 해낼 수 있는 간단한 것들입니다. Claude가 작업을 완수하느냐 못 하느냐가 갈리는 상황에서는 어떨까요?

이런 어려운 문제를 찾으려면 벤치마크를 봐야 합니다. 그래서 제가 좋아하는 커뮤니티 기반 벤치마크인 Terminal-Bench 3.0을 살펴봤습니다.

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): Takens 임베딩 정리를 Lean 4로 형식 증명하기
• ML(mp-checkpoint-consolidation): mixture-of-experts 체크포인트의 샤드 16개를 하나의 파일로 병합해 기준 logits를 그대로 재현하기
• 운영(intrastat-meldung): 회사의 월말 EU 무역 통계 신고를 처음부터 끝까지 수행하기
• 미디어(layout-config-recreation): 포스터 이미지를 편집 가능한 레이아웃 파일로 재구성하기

엣지 케이스가 많을수록 높은 effort가 도움이 된다

Terminal-Bench 3.0 결과를 읽고 얻은 가장 큰 교훈은 숨은 엣지 케이스가 많은 작업일수록 높은 effort가 효과적이라는 점이었습니다.

html-js-filter이 대표적인 예입니다. 페이지에 JavaScript를 몰래 심는 모든 방법을 걸러 내는 HTML 새니타이저를 만드는 Terminal-Bench 3.0 과제입니다. Fable 5.1은 low에서 1/5였던 성공률이 xhigh에서는 5/5로 올랐습니다.¹

low effort에서는 시도 한 번에 보통 2분쯤 걸립니다. 각 시도는 필터를 거의 한 번에 작성한 뒤, 직접 쓴 페이지 하나로만 테스트했습니다.

high effort 실행은 약 33분 만에 끝납니다. 제가 추적한 실행에서는 먼저 초안을 적대적 관점에서 리뷰했고, 설치된 파서의 소스를 읽어 버그를 확인했습니다. 이어서 정상 입력이 출력과 똑같이 나올 때까지 깨끗한 테스트 케이스를 여러 번 돌렸고, 표준 XSS 테스트 스위트를 실행했으며, 마지막에는 임의 문서를 생성하는 퍼저까지 직접 작성했습니다.

HTML 새니타이저처럼 엣지 케이스가 많은 작업에서는 이 정도 추가 노력이 충분히 값어치를 합니다. 성능 최적화나 보안 리뷰처럼 프로덕션 요구 수준이 높은 복잡한 작업에서도, 토큰을 더 써서 꼼꼼히 확인하는 것이 합리적입니다.

하지만 모든 작업에 이 정도 effort가 필요한 것은 아닙니다.

아래 다이어그램은 모델과 effort 단계별 Terminal-Bench 3.0 결과 전체와 실패 원인을 보여 줍니다. 전반적으로 effort를 높이면 엣지 케이스를 놓쳐서 생기는 실패(보라색 블록)는 줄어드는 경향이 있지만, 모델이 접근 방식 자체를 잘못 잡은 경우(파란색 블록)는 해결되지 않습니다.

effort가 도움이 되는 문제 영역

이 모델들을 Terminal-Bench 3.0으로 평가하면서 가장 흥미로웠던 점은, 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-simplex: Python으로 작성한 CLI 선형계획법 솔버를 요구하는 Terminal-Bench 3.0 과제입니다. Opus 5.5는 low에서 0/5였던 성공률이 high에서는 5/5로 올랐습니다.

low 시도에서는 솔버를 한 번에 작성하고, 작은 문제 몇 개로 확인한 뒤 10k 토큰 안팎에서 멈췄습니다. 마지막 메시지에서 Claude는 큰 문제에서는 느릴 수 있다고 경고했지만, 실제로 확인하지는 않았습니다.

high 시도에서는 Claude가 별도의 브루트 포스 솔버와 비교하며 무작위 문제로 솔버를 테스트했습니다. 그다음 더 큰 문제의 실행 시간을 측정하다가, 실행이 지나치게 오래 걸리거나 크래시가 나는 경우를 만나 탐색 방식을 다시 짰습니다.

gsea-proteomics: 프로테오믹스 데이터로 유전자 집합 농축 분석(GSEA)을 수행해, 8가지 처치 중 어떤 것이 목표 조직과 유사한지 찾아내는 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를 작업에 맞게, 심지어 대화 도중에도 바꿔 보세요. 그리고 제 경험과 비슷한지 알려 주세요.

¹ 수치에 관한 참고 사항: 이 수치는 자체 내부 실행 결과로, 과제당 5회 시도했으며 Fable 5.1은 프로덕션 안전 개입 기능을 끈 상태에서 실행했습니다. Claude 제품에서는 Fable 5.1의 안전 장치가 일부 보안 관련 요청을 Opus로 넘깁니다. 보안 과제는 인터넷 접속 없이 실행했기 때문에, 여기 나온 과제별 횟수는 공개 리더보드나 출시 게시물의 수치와 맞지 않을 수 있습니다. 사례로 든 예시는 개별 실행 결과이며, 일부는 중간 단계의 effort 설정에서 나온 것입니다.