노력을 올리면 고쳐지는 실패와 안 고쳐지는 실패
안녕하세요! 재니미입니다.
Claude의 노력(effort) 단계를 올리면 결과가 좋아집니다. 그런데 무엇이 좋아지는지는 잘 이야기되지 않습니다. Anthropic의 Thariq Shihipar가 쓴 Spending your effort에 이 질문에 답하는 자료가 있어서 정리합니다. 요약하면 노력은 검증을 더 하게 만드는 설정이라, 엣지 케이스를 놓친 실패는 크게 줄지만 문제를 잘못 해석한 실패는 줄지 않고 오히려 늘었습니다.
이 글은 Anthropic 블로그 글 Using Claude Code: Spending your effort를 읽고 정리한 것입니다. 수치는 모두 원문에 실린 Anthropic 내부 실행 결과입니다.
노력은 다섯 단계
Opus 5.5와 Fable 5.1의 노력은 낮은 순서대로 낮음(Low), 중간(Medium), 높음(High), 매우 높음(Xhigh), 최대(Max)의 다섯 단계입니다. Opus 5.5의 기본값은 중간입니다. Claude Code에서는 /effort로 대화 도중에도 바꿀 수 있습니다. 아래에 나오는 낮음과 최대는 이 다섯 단계의 양 끝입니다.
노력이 실제로 바꾸는 것
원문은 노력을 모델에게 이 일에 계산을 얼마나 쓰길 원하는지 알려주는 신호라고 설명합니다. 어느 단계에서든 Claude는 작업을 제대로 하려고 하지만, 노력이 높을수록 스스로 판단하고 검증하는 일을 더 많이 합니다.
차이가 잘 보이는 예가 html-js-filter입니다. 페이지에 자바스크립트를 몰래 넣는 모든 방법을 걸러내는 HTML 새니타이저를 만드는 과제인데, Fable 5.1이 낮음에서는 다섯 번 중 한 번, 매우 높음에서는 다섯 번 모두 통과했습니다.
- 낮음 (약 2분): 필터를 한 번에 작성하고 직접 만든 페이지 하나로만 시험했습니다.
- 높음 (약 33분): 첫 초안을 공격자 입장에서 다시 검토하고, 설치된 파서의 소스를 읽어 버그를 확인하고, 표준 XSS 테스트 모음을 돌리고, 마지막에는 무작위 문서를 만드는 퍼저까지 직접 작성했습니다.
더 똑똑한 답을 내는 게 아니라 같은 답을 훨씬 많이 두들겨본 것입니다.
실패 유형별로 보면
원문에는 Terminal-Bench 3.0의 모든 시도를 실패 원인별로 분류한 도식이 있습니다. Fable 5.1을 낮음과 최대로 각각 370번 돌린 결과입니다. 실패 원인은 모델이 판정한 것이라 대략적인 분류입니다.
| 결과 | 낮음 | 최대 | 변화 |
|---|---|---|---|
| 통과 | 140 | 214 | +74 |
| 테스트가 놓친 버그 | 40 | 14 | -65% |
| 틀리거나 불완전한 수정 | 31 | 10 | -68% |
| 요구사항을 잘못 읽음 | 45 | 26 | -42% |
| 분야의 규칙을 잘못 앎 | 32 | 24 | -25% |
| 해석을 잘못 고름 | 25 | 47 | +88% |
테스트가 놓친 버그나 불완전한 수정은 3분의 1 수준으로 줄었습니다. 검증을 더 하면 잡히는 종류라서 그렇습니다. 분야의 규칙을 잘못 아는 실패는 조금 줄어드는 데 그쳤습니다. 모르는 걸 오래 생각한다고 알게 되지는 않으니까요.
눈에 띄는 건 마지막 줄입니다. 문제를 여러 방식으로 읽을 수 있을 때 틀린 쪽을 고른 실패는 거의 두 배가 됐습니다. 다른 실패가 줄면서 남은 시도가 이쪽으로 옮겨 온 영향도 있겠지만, 적어도 노력으로 해결되는 종류가 아니라는 건 분명합니다. 원문도 노력을 올리면 엣지 케이스를 놓친 실패는 줄지만 접근 방식이 틀린 실패는 고쳐지지 않는다고 정리합니다.
해석 문제는 사람이 풀어야 한다
원문의 gsea-proteomics 사례가 이 차이를 잘 보여줍니다. 단백질 데이터로 여덟 가지 처리 중 어떤 것이 목표 조직과 비슷한지 찾는 과제입니다.
- 낮음: 그럴듯한 전처리 방식 하나를 골라 분석하고 결과를 보고했습니다. 다섯 번 모두 실패했습니다.
- 높음: 전처리를 두 가지로 해보고, 유의미한 처리 목록이 달라지는 걸 발견하고, 이유를 파고든 뒤 맞는 쪽을 골랐습니다. 다섯 번 중 네 번 통과했습니다.
여기서 원문은 사용자가 대화에 있었다면 Claude가 문제를 어떻게 설정할지 물어봤을 수도 있다고 덧붙입니다.
제 생각에는 이 부분이 핵심입니다. 노력이 높으면 모델이 여러 해석을 스스로 비교해볼 여유가 생기지만, 어떤 해석이 맞는지는 결국 요청한 사람이 알고 있습니다. 요청이 애매해서 여러 가지로 읽힐 수 있는 작업이라면 노력을 올리기 전에 요구사항을 먼저 분명히 적어주는 쪽이 싸고 확실해 보입니다. 원문에서 요구사항을 자세히 준 작업은 노력 단계와 상관없이 결과가 비슷했다는 관찰도 같은 방향입니다.
그래서 언제 올리나
원문의 분야별 통과율도 같은 이야기를 합니다. Fable 5.1 기준으로 하드웨어는 34%에서 75%로, 보안은 64%에서 87%로 크게 올랐지만 운영은 12%에서 22%로 오르는 데 그쳤습니다. 검증할 거리가 많은 분야일수록 노력이 잘 먹힙니다. 분야별 과제 수가 적어서 원문은 낮은 쪽 두 단계와 높은 쪽 세 단계를 각각 묶어 계산했습니다.
그래서 작업을 두 가지로 나눠볼 수 있습니다.
- 노력을 올릴 때: 엣지 케이스가 많고 결과를 기계적으로 검증할 수 있는 작업입니다. 보안 검토, 파서, 성능 최적화, 기존 코드베이스의 버그 수정이 여기에 해당합니다.
- 노력보다 요구사항이 먼저일 때: 요청이 애매해서 여러 가지로 읽힐 수 있는 작업입니다. 이때는 노력을 올리기보다 무엇을 원하는지 먼저 적어줍니다.
이미 받은 결과가 마음에 안 들 때도 같은 기준을 쓸 수 있습니다. 방향이 엉뚱하면 요구사항을 고치고, 방향은 맞는데 빠진 부분이 있으면 노력을 올립니다.
지난 글 「Effort는 올릴수록 좋은 게 아니다」에서 노력은 올릴수록 좋은 게 아니라고 적었는데, 이번 자료는 그 이유를 실패 유형으로 보여줍니다. 노력은 검증에 쓰는 예산이고, 방향을 잡아주는 건 여전히 사람 몫입니다.
감사합니다.