💭 Claude Code effort 사용법

💭 Claude Code effort 사용법

토큰, 시간, 돈 아끼려면 꼭 읽어보시길..

Low로 할까, High로 할까.. 매번 고민되는 그 선택.

Claude Code 팀 Thariq의 "Using Claude Code" 아티클은 여러 도움이 됩니다.

Fable 5.1, Opus 5.5는 effort를 바꿔도 프롬프트 캐시가 깨지지 않아서, 이제 대화 중간에도 /effort로 자유롭게 바꿀 수 있거든요.

그런데 "effort가 정확히 뭔데요? 언제 뭘 써야 해요???" 라는 질문이 많았다고 하네요.

그래서 Thariq가 직접 eval을 파고들고, 평소 작업에서도 effort별로 테스트해봤어요.

한 줄 요약부터 하면..

effort는 Claude가 검증과 엣지 케이스 테스트를 얼마나 하고, 자기 판단을 얼마나 쓸지를 바꾸는 스위치!

↓

What is effort?

effort는 이 작업에 컴퓨트를 얼마나 쓰길 원하는지를 모델에게 알려주는 신호예요.

Thariq의 비유가 좋아요.

누가 "이거 12시간 꼬박 해줘"라고 하면, 아 정말 공들여서 해달라는 거구나 하고 받아들이죠.

같은 일을 "1시간 안에 해줘"라고 하면, 요구사항을 맞추는 최선의 버전을 먼저 건네고 거기서부터 같이 다듬어갈 거라고 생각할 거예요.

아니면 "이건 최소 3시간은 필요해요" 하고 3시간을 채워서 가져올 수도 있고요.

effort도 똑같아요. 어느 레벨이든 Claude는 합리적으로 일을 해내려고 하지만, effort가 높을수록 판단과 검증을 스스로 더 많이 해요.

↓

Building with effort

같은 작업을 Opus 5.5에서 effort만 바꿔가며 돌려봤대요.

1️⃣ 스펙이 거의 없는 작업 : "개인 운동 기록 앱 만들어줘"

Low에서는 로그랑 간단한 그래프 정도. effort를 올릴수록 디테일이 붙고, Max에서는 히트맵까지 나와요.

대신 Claude가 중간에 내리는 결정도 그만큼 많아짐..

2️⃣ 스펙이 가벼운 디자인 작업 : Claude Code /config 메뉴 리디자인

방향은 매번 비슷했어요 (서브메뉴 + 더 나은 검색).

Low는 1분 만에 아이디어를 전하는 인터랙티브 스케치를, Max는 28분 동안 실제 Claude Code 같은 목업에 여러 흐름별 워크스루까지 만들었어요.

3️⃣ 스펙이 자세한 작업 : 인터뷰로 만든 상세 스펙을 넘겼을 때

모델과 effort가 달라도 결과가 꽤 비슷해졌어요.

Max에서는 오히려 몇몇 디테일을 단순하게 정리하는 데 시간을 썼고요.

Thariq는 /config 리디자인 같은 작업은 Low로 Claude의 비전을 먼저 보는 쪽이 더 좋았대요. 빨리 보고, 빨리 피드백 주고...

스펙이 자세할수록 effort에 따른 결과 차이가 줄어든다는 점이 중요한 듯!

↓

Interview → Low → Review → High

그래서 Thariq가 요즘 새 기능 개발에 쓰는 루프는 이래요.

1. Claude에게 스펙을 주고, 빠진 디테일이 있으면 나를 인터뷰하게 하기

2. Low effort로 구현

3. 큰 방향이 맞는지 리뷰하고, 필요하면 Low로 계속 반복

4. 마지막 검증과 테스트는 High effort로

중요한거 = "내가 얼마나 루프 안에 있고 싶은가"

Low는 빠르게 출발점을 주고, High는 일을 더 많이 해주지만 그만큼 나 대신 가정도 더 많이 해요.

↓

Terminal-Bench 3.0 > 어려운 작업에서는?

앞의 예시들은 어느 effort에서든 Claude가 해내는 작업이었죠.

그럼 effort에 따라 성공과 실패가 갈리는 작업은 어떨까요?

그래서 커뮤니티가 만든 벤치마크 Terminal-Bench 3.0을 들여다봤대요. 문제들이 꽤 야심참!

• Hardware : Verilog로 작은 FPGA에 들어가는 8비트 게임 콘솔 만들기

• Science : Lean 4로 Takens 임베딩 정리 형식 증명하기

• ML : MoE 체크포인트 16개 샤드를 하나로 합쳐서 레퍼런스 logits 재현하기

• Operations : 회사의 월말 EU 무역 통계 신고를 처음부터 끝까지 처리하기

• Media : 포스터 이미지를 편집 가능한 레이아웃 파일로 다시 만들기

평소 우리가 하는 일보다 훨씬 복잡한 작업들이에요.

↓

Higher effort = 숨은 엣지 케이스가 많을 때

벤치마크 결과를 보고 Thariq가 내린 가장 큰 결론이에요.

html-js-filter가 깔끔한 예시인 듯.

페이지에 JavaScript를 몰래 넣는 모든 경로를 막는 HTML sanitizer를 만드는 과제인데,,

Fable 5.1이 Low에서 1/5, xhigh에서 5/5를 기록했어요.

⬇️ Low (약 2분)

필터를 거의 한 번에 쓰고, 손으로 쓴 페이지 하나로만 테스트

⬆️ High (약 33분)

첫 초안을 적대적으로 리뷰 → 설치된 파서 소스를 직접 읽으며 버그 확인 → 정상 입력이 그대로 나올 때까지 테스트 반복 → 표준 XSS 테스트 스위트 실행 → 마지막엔 랜덤 문서 fuzzer까지 작성

HTML sanitizer처럼 엣지 케이스투성이인 작업이라면 이 정도 노력은 충분히 값어치가 있는 듯..

성능 최적화나 보안 리뷰처럼 프로덕션 요구 수준이 높은 작업도 마찬가지고요.

다만 한 가지 짚고 가요.

effort를 올리면 엣지 케이스를 놓쳐서 생기는 실패는 줄지만, 접근 방식 자체가 틀린 실패는 고쳐주지 않아요.

↓

When to use which effort

자, 이렇게 갑시다!

• Low : 루프 안에서 빠르게 주고받고 싶을 때. 브레인스토밍, 스케치, 쉬운 수정

• Medium : 대부분의 일반적인 소프트웨어 엔지니어링. 새 기능 구현 같은 일

• High : 검증이 중요하거나 엣지 케이스가 많은 일. 브라운필드 코드베이스 버그 수정 같은 일

• Max : Claude가 완전히 자율적으로 어려운 문제를 풀어야 할 때. 앱을 처음부터 끝까지 만들고 검증하기, 중요한 소프트웨어의 보안 취약점 찾기

작업에 따라, 혹은 대화 중간에라도 /effort로 바꿔보면서 내 감각과 맞는지 확인이 필요합니다.

💭

effort는 품질 슬라이더라기보다는, 내가 얼마나 루프 안에 있을지를 정하는 선택에 가까워요.

내가 옆에서 같이 보고 있으면 Low로 빠르게 주고받는 게 낫고, 내가 없는 동안 Claude가 알아서 검증까지 끝내야 한다면 High 이상이 맞고요.

무조건 Max로 두는 것도, 무조건 Low로 아끼는 것도 답이 아니에요.

인터뷰 → Low 구현 → 리뷰 → High 검증.. 이 루프는 바로 따라 해볼 만해요.

노력도 결국 어디에 쓸지 고르는 것.