• Claude Code에는 두 개의 독립된 다이얼이 있다: **모델 선택(model)**과 effort level(노력 수준).
    • 모델 선택: 고정된 가중치 집합을 고르는 것. 훈련이 끝난 뒤 정해진 능력 범위를 결정한다.
    • effort level: 한 요청에 Claude가 전반적으로 얼마나 일할지를 조절한다. 읽는 파일 수, 사용하는 도구 수, 밟는 단계 수, 그리고 한 턴에 생성하는 토큰 양이 여기에 달려 있다.
  • 흔한 오해: effort는 “생각하는 시간"이 아니다. 검증을 얼마나 하고 다단계 작업을 얼마나 밀어붙일지를 정하는 작업량 다이얼이다.

effort level의 동작

  • effort 값은 요청에 실려 모델로 전달되고, 모델은 각 노력 수준에서 어떻게 행동할지 학습되어 있다.
  • 높은 effort:
    • 더 많은 파일을 읽는다.
    • 검증하고 이중 확인한다.
    • 다단계 작업을 더 멀리까지 밀어붙인다.
    • 높은 신뢰도를 얻으려 약 7배 많은 토큰을 생성한다.
  • 낮은 effort:
    • 스스로 풀기보다 추가 문맥을 요청하는 쪽을 택한다.
    • 검증 단계가 줄어든다.
  • 무조건 정해진 단계를 다 밟는 게 아니다. 중간 결과를 받고 진행 상황을 평가한 뒤 필요 없는 단계는 건너뛴다. 그래서 단순 작업에서 인위적으로 과잉 검증하지 않는다.
  • 대부분의 작업은 모델의 기본 effort를 그대로 쓰는 게 맞다. effort는 작업별로 매번 바꾸기보다, 도메인·작업 유형에 맞춘 일반적 선호도로 조정한다.

지원 모델과 비유

  • 각 모델은 “경험의 깊이"로 비유된다.
  • Fable: 가장 큰 모델. 거의 아무도 못 본 문제까지 겪어본 전문가. 낮은 effort에서도 남들이 놓치는 걸 본다.
  • Opus 4.8 / 4.7: 전문가(the expert). 깊은 경험과 패턴 인식. 4.8은 같은 토큰을 쓰고도 4.7보다 나은 결과를 낸다.
  • Sonnet: 뛰어난 제너럴리스트. 주어진 코드를 철저히 이해하지만 “이 문제를 전에 정확히 본 적 있다"는 인식은 약하다.
  • Haiku: 가장 작은 모델.

모델을 올릴까 effort를 올릴까

  • 판단 기준 한 줄: “충분히 노력하지 않은 건가, 충분히 알지 못한 건가?” (Did it not try hard enough, or did it not know enough?)
  • 더 큰 모델로 올릴 신호:
    • Claude가 분명히 시도했는데도 실패했다.
    • 관련 문맥을 다 줬는데도 여전히 틀린다.
    • 문제 자체가 진짜 어렵다(genuinely hard).
  • effort를 올릴 신호:
    • 파일을 건너뛴다.
    • 테스트를 실행하지 않는다.
    • 작업을 중간에 포기한다.
    • 지금 effort가 기본값보다 낮게 설정돼 있다.
  • 올리기 전에 먼저 점검할 것: 프롬프트가 모호하진 않은가, 올바른 도구에 연결돼 있는가, 적절한 스킬을 갖고 있는가. 원인이 여기 있으면 effort를 올려도 낭비다.

모델별 선택 기준

  • Opus: 기본 전문가 티어. Fable을 꺼낼 만큼 극단적으로 어렵진 않지만 Sonnet엔 버거운, 깊은 경험과 패턴 인식이 필요한 대부분의 작업. 특별히 위나 아래로 내릴 이유가 없으면 여기서 시작한다.
  • Fable: 미묘한 버그, 낯선 도메인, 아키텍처 결정 같은 어려운 문제. 작은 모델이 어떤 effort로도 실패하는 경우. 긴 다단계 작업에 특히 효과적이다.
  • Sonnet: 정확히 기술할 수 있는 수정, 기계적 변경 같은 루틴 작업. 이미 문맥에 들어와 있는 코드에 대한 질문.
  • Sonnet으로 루틴 작업만 오래 한다면 비용 절감을 위해 더 작은 모델로 낮추는 것도 고려한다. 반대로 더 큰 모델은 낮은 effort로도 작은 모델의 높은 effort보다 나을 수 있다.

비용·토큰 트레이드오프

  • 루틴 작업: 두 모델 모두 같은 effort에서 성공한다면, 큰 모델은 검증 때문에 토큰을 더 쓰고 토큰당 가격도 높다 → 작은 모델이 유리.
  • 어려운 다단계 작업: 작은 모델은 능력 한계까지 반복하며 토큰을 많이 태운다. 큰 모델은 같은 품질을 더 적은 단계로 달성한다 → 토큰당 가격은 높아도 총비용은 낮을 수 있다.
  • Fable은 토큰당 가격이 가장 높지만 긴 작업에서 효과가 가장 커서, 결과적으로 총비용이 더 낮아질 수 있다.

응답 길이를 직접 조절하는 수단

  • effort와 별개로 출력량을 자르는 방법도 있다.
  • max_tokens: 응답을 그냥 끊어버리는 무딘 도구(blunt instrument).
  • task budget: 토큰 한계 근처에서 작업을 마무리하도록 유도하는 더 부드러운 제어.
  • 프롬프트로 “간결하게 해달라(keep it brief)“고 직접 지시하는 방법.

정리

  • 원칙: 기본값에서 시작하고, 실패 원인을 진단한 뒤 필요한 다이얼만 조정한다(Start with the defaults, then reach for the dials).
  • “몰라서 실패"면 모델을, “덜 노력해서 실패"면 effort를 올린다. 그 전에 프롬프트·도구·스킬부터 점검한다.

참고 자료