Claude Opus 4.8의 「effort」(low / medium / high / xhigh / max)를 높이면 무엇이 얼마나 변할까? 공식 설명만으로는 알 수 없었기에, 동일한 과제를 **전체 레벨 × 3개 서피스(Claude Code / Cowork / claude.ai 채팅)로 총 27회 실행(run)**하여 실측했다.

결론부터 말하자면:

• 정답률은 한 단계도 변하지 않았다 (전체 27회 실행 모두 정답)
• 출력 토큰은 약 7배, API 처리 시간은 최대 6배로 증가했다
• 변하는 것은 "답의 정확도"가 아니라 **"답을 확인하는 방식과 절차"**였다

검증 방법

• claude-opus-4-8 (1M context) / Claude Max / 2026년 6월 6일 실시
• 1회 실행(run) = 1개의 신규 세션 (컨텍스트 유지 없음)
• 측정: 토큰 = /cost 명령 사용
• 실측값, 응답 시간 = 자체 제작 스테이터스 라인의 턴별 API 처리 시간
• 과제는 채점을 자동화할 수 있는 2가지로 압축했다:
  • Task A: SemVer 2.0.0을 준수하는 semver_compare()를 Python으로 구현. "코드만 반환해줘"라고 지시하고, 작성자 측의 숨겨진 테스트 15개 항목으로 채점 (모델에는 테스트의 존재를 알리지 않음)
  • Task B: 베이즈 정리의 전형적인 문제 (민감도 99% · 위양성 5% · 유병률 1% → 양성 예측도 ≈ 16.7%)를 "수치와 구하는 방법을 150자 이내로" 작성. 수치 · 풀이 과정 · 글자 수의 3가지 포인트를 기계적으로 판정

프롬프트는 모든 실행에서 토씨 하나 틀리지 않고 동일하게 사용했다.

결과 ①: 비용은 확실히 증가한다 (Code 정량 분석)

전제: Task A는 모든 레벨에서 15/15 통과, Task B는 모든 레벨에서 수치와 풀이 과정 모두 정답. 이를 바탕으로:

• out_tok(출력 토큰)는 레벨마다 거의 배로 증가하며, low에서 max로 갈 때 약 7배가 된다.
• 비용(API 환산)은 캐시 읽기/쓰기에 따라 변동되므로 비교 지표로 부적합하다. out_tok와 시간으로 보는 것이 정확하다.
• Max 플랜(정액제)의 실질적인 비용은 **"대기 시간"과 "5시간 사용 한도 소모"**이다.

결과 ②: 150자 제약 준수는 effort에 비례하지 않는다

가장 흥미로웠던 부분이다. Task B의 글자 수 제약(구하는 방법 150자 이내 · 개행 제외) 준수 여부를 3개 서피스에서 비교했다:

• max만이 3개 서피스 모두에서 제약을 준수했다. 게다가 Code의 max는 불렛 포인트를 포기하고 한 문장으로 압축하며 "진양성/위양성"이라는 용어를 사용하여 글자 수를 절약했다. 이는 사고량이 "설명을 덧붙이는 것"이 아니라 "제약을 충족하기 위한 궁리"로 향했음을 의미한다.
• xhigh는 서피스에 따라 양상이 달라진다. Code에서는 2회 연속으로 거의 동일한 위반 폭(182/181자)을 보였으며, 이는 재현성 있는 경향이다. Cowork/Chat에서는 준수했다. low~high는 제각각이다.
• "effort를 높이면 지시를 잘 지킬 것이다"라고 기대하지 않는 것이 좋다. 반드시 지켜야 하는 제약은 프롬프트에서 강조하거나 출력 검증을 시스템화해야 한다.

서피스 차이가 생각보다 크다

• Cowork (에이전트 환경): effort가 높을수록 스스로 품질 보증을 시작한다. xhigh 급에서는 답변 전에 직접 모든 순서 테스트를 실행하고 "검증 완료"라고 선언하며, 코드에도 정규 표현식을 이용한 구문 검증을 포함한다.
• Chat: low~high 단계에서는 수식 블록이 토씨 하나 틀리지 않은 템플릿 답변 형태다 (체감상 모두 5초 소요). 매우 높은 단계에 이르러서야 비로소 동작이 변한다.
• Code: "코드만"이라는 지시에 가장 충실한 순수 구현을 보여준다.

참고: ultracode (xhigh + workflows)

effort가 아닌 별도의 실행 모드다. Task A를 던지면 8개의 서브 에이전트가 2단계로 병렬 실행되었다 (독립 구현 × 3 + 적대적 테스트 × 2를 생성 → 83개 케이스로 실행 검증 및 수렴 확인).

생성된 코드의 숨겨진 테스트 성적은 15/15——low의 1회 실행과 동일함. ultracode가 이기고 있는 것은 '더 나은 코드'가 아니라 **'정확성 검증 프로세스 (verification process)'**임. 숨겨진 버그는 치명적인 상황을 위한 것이며, 일상적인 태스크에는 과잉임.

사용 구분 지침 (실측 기반)

• 사양이 명확한 소~중규모 태스크 →
  low/medium으로 충분 (정답률은 동일, 빠름, 토큰 점유율 낮음) - 고민된다면 기본값인 high 사용
• 지시 준수 (instruction following)를 effort에 기대하지 말 것. 제약 사항은 프롬프트 강조 + 출력 검증으로 처리
• ultracode는 검증 비용에 상응하는 상황에서만 사용

한계

단일 환경, 각 셀 1~2회 실행 (run). 편차는 실제로 존재함 (최대 재실행 시 코멘트 언어가 일어 $\rightarrow$ 영어로 반전, xhigh 재실행 시 사고 토큰 (thinking token)이 절반으로 감소하는 것을 관찰). LLM 출력은 매번 달라진다는 전제하에 해석할 것.

스크린샷 (statusline, /cost, 워크플로우 실행 화면), 그래프, 검증의 상세 절차는 풀 버전에서 확인 가능:

Discussion