Claude Code에 '엣지 케이스도 고려해'라고 쓰는 것을 그만두자: 504회 실측으로 비용만 134% 증가
요약
본 기사는 Claude Code를 활용한 버그 수정 과정에서 '엣지 케이스 고려' 등의 지시가 비용만 크게 증가시키고 실제 테스트 통과율 개선에는 미미했음을 504회 실측으로 입증했습니다. 특정 프롬프트 추가는 Haiku 5.5의 경우 1회당 비용을 +134% 높였으며, 버그 수정 시 기본 조건 유지가 중요함을 강조합니다.
핵심 포인트
- '엣지 케이스' 지시는 비용만 증가시키고 테스트 통과율 개선 효과는 미미했습니다.
- Haiku 5.5가 Opus 5.5보다 약 87% 저렴하며, 기본 조건에서 좋은 성능을 보였습니다.
- 버그 수정 시 과도한 `effort` 설정은 비용만 높일 뿐 품질 향상으로 이어지지 않습니다.
- 모델이 보고서에 언급되지 않은 케이스를 스스로 떠올리는 데는 한계가 있습니다.
Claude Code로 버그를 수정할 때, 이런 한 마디를 추가하고 계시지는 않나요?
"엣지 케이스도 전부 고려해"
"먼저 테스트 코드를 작성해"
혹은 effort 수준을 높이는 것입니다. 저 역시 그랬습니다. 과연 이것이 정말 효과가 있는지, 504회에 걸쳐 직접 측정했습니다.
결론: 돈만 더 많이 들었습니다.
Haiku 5.5: '엣지 케이스' + '기존 테스트를 먼저 읽어라'는 지시로 1회당 비용이 +134% 증가 -
Opus 5.5: '엣지 케이스'라는 문구만으로도 +60% 증가 -
effort high: Haiku +60%, Opus +22% 증가 -
버그 보고서에 언급되지 않은 케이스의 통과율: 어떤 조건에서도 4포인트 이상 움직이지 않았습니다. effort high는 두 모델 모두 오히려 약간 하락했습니다.
2026년 8월부터 10월 사이에 실제로 수정된 OSS(Open Source Software) 버그 21건(cachetools, zod, marked, js-yaml, anyio, undici, fastify 등 12개 프로젝트). Claude Code 2.1.295의 헤드리스 모드를 사용하여 Haiku 5.5와 Opus 5.5에 각각 4가지 조건으로 3회씩 수정하게 했습니다. 총 21×2×4×3 = 504회입니다.
| 조건 | 변경한 사항 |
|---|---|
| 기본 | 증상・재현・기대 결과만 남긴 버그 보고서 |
| ... |
평가는 해당 버그를 수정한 유지보수자(maintainer)의 테스트로 진행했습니다. 테스트 케이스마다 '보고서에 나오는 케이스'와 '나오지 않는 케이스'를 최초 실행 전에 분리하여 sha256과 함께 GitHub에 사전 등록했습니다. 이는 결과를 보고 나서 기준을 움직일 수 없도록 하기 위함입니다. 효과가 있다고 인정할 기준은 20포인트 이상의 차이입니다.
보고서에 언급되지 않은 케이스의 통과율(버그별 평균):
| 조건 | Haiku 5.5 | Opus 5.5 |
|---|---|
| 기본 | 84% | 88% |
| ... |
1회당 API 비용:
| 조건 | Haiku | Opus |
|---|---|
| 기본 | US$0.050 | US$0.51 |
| ... |
1회 소요 시간의 중앙값 역시 Haiku는 121초 → 299초, Opus는 120초 → 271초로 늘어났습니다. 지시대로 케이스를 나열하고 테스트까지 작성하게 했지만, 이것이 수정 품질로 이어지고 있지는 않습니다.
간단한 버그는 말하지 않아도 대응했습니다. 21건 중 12건은 어떤 조건에서도 두 모델 모두 모든 케이스를 통과했습니다. 발전할 여지가 없었습니다. -
어려운 버그는 요구해도 대응하지 못했습니다. js-yaml의 '스트림 내 각 문서의 시작 부분에 BOM이 있는' 케이스는 504회 중 0회였습니다. '쓰여지지 않은 변형을 제시하라'고 해도, 그 변형을 떠올릴 수 없었습니다. -
테스트를 먼저 읽게 하는 것이 역효과일 때도 있습니다. Python-Markdown의 백틱(backtick) 버그에서 Opus는 기본 조건으로 3회 중 2회 통과했지만, '테스트를 먼저 읽어라'를 추가하자 3회 모두 실패했습니다.
'엣지 케이스'가 아니라, 빠뜨릴 것 같은 케이스를 구체적으로 작성해야 합니다. 보고서에 나오는 케이스는 두 모델 모두 94% 이상 통과했습니다. 모델이 지시를 따르지 못하는 것이 아니라, 쓰여지지 않은 것을 떠올리지 못하는 것입니다. -
버그 수정 시 effort는 기본값으로 유지해야 합니다. 이번 high 설정은 비용만 올렸을 뿐입니다. -
기본적으로는 Haiku가 좋습니다. 각 252회 평균 기준으로 1회당 Haiku는 0.088달러, Opus는 0.69달러였습니다. 약 87% 저렴합니다. Opus가 몇 포인트 더 높고 다른 테스트를 망가뜨리는 횟수는 적었기 때문에, 대규모 코드베이스의 어려운 버그에서는 Opus에 가치가 있습니다.
버그 21건, 각 조건별로 3회씩 진행했습니다. 20포인트 효과는 부정할 수 없지만, 몇 포인트의 작은 효과까지도 부정할 수는 없습니다. 프롬프트 문구 역시 조건별로 단 하나만 사용했습니다.
504회의 실행에 따른 점수・비용・시간은 CSV 파일로 공개합니다(CC BY 4.0). 사전 등록 문서와 채점 코드도 있습니다.
- 데이터 (DOI): https://doi.org/10.5281/zenodo.23796306
- 사전 등록: https://github.com/johnisking/token-cost-by-language/blob/main/claude-report-edge-cases/PREREG.md
여러분들이 Claude에 붙이고 있는 '효과가 있었던 한 마디'가 있다면 댓글로 알려주세요. 다음 실측에서 시험해 보겠습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기