Claude Code effort 비교: low부터 max까지 30번 돌려 본 결과

게시 읽는 시간 약 7분 비교·선택

effort를 max로 올리면 결과가 더 좋아질까 싶어서, 같은 코딩 과제를 low부터 max까지 다섯 단계로 세 번씩 돌려 봤습니다. 과제 두 개, 모두 30번입니다.

30번 중 29번이 채점 테스트를 전부 통과했어요. 틀린 한 번은 low였고, max는 같은 결과를 내는 데 low보다 출력 토큰을 20~40배 쓰고 시간도 18~32배 걸렸습니다.

그래서 저는 effort를 기본값 그대로 두고, 함정이 많은 일에만 한 단계 올리길 권합니다. Opus 5.5의 기본값은 medium입니다. xhigh와 max는 정말 어려운 문제에 아껴 쓰는 쪽이 맞더라고요.

2026년 10월 22일 Windows 11 테스트 환경에서 Claude Code 2.1.296과 Opus 5.5로 직접 실행한 결과이고, 단계별 설명과 설정 방법은 같은 날 확인한 공식 문서 기준입니다.

확인한 버전·환경

  • Claude Code 2.1.296 · Opus 5.5 · Windows 11 · 확인일 2026-10-22

두 과제를 다섯 단계로 세 번씩

과제는 둘입니다. 규칙을 README에 적어 두고 함수 하나를 구현하게 했어요.

  • 줄바꿈: 한글과 영문이 섞인 문장을 터미널 폭에 맞춰 줄을 나누는 wrap(text, width). 한글은 2칸, 영문은 1칸으로 세고, 폭보다 긴 단어는 글자 단위로 쪼갭니다. 규칙 7개.
  • 계산식: -2^2, 2^3^2, 2*-3 같은 식을 계산하는 evaluate(expr). 단항 마이너스와 거듭제곱의 우선순위, 오른쪽 결합, 문법 오류 처리처럼 틀리기 쉬운 규칙을 일부러 넣었습니다.

핵심은 아래처럼 --effort만 바꾼 명령입니다. 파일을 고치고 테스트를 돌릴 권한은 미리 허용해 뒀어요.

claude -p "README.md의 규칙대로 wrap.js의 wrap 함수를 구현하세요. 다 되면 node --test로 확인하세요." --effort low --output-format json

Claude에게는 예시 테스트 세 개만 보여 주고, 채점은 따로 준비한 테스트(줄바꿈 23개, 계산식 35개)로 했습니다. 토큰과 시간, 비용은 --output-format json 결과에 찍히는 값을 그대로 옮겼어요.

한눈에 보면: 결과는 평평하고 토큰은 절벽

effort 단계별 평균 출력 토큰 막대그래프. 줄바꿈 과제는 low 2.5k, medium 4.0k, high 5.1k, xhigh 17k, max 101k이고, 계산식 과제는 low 3.1k, medium 3.3k, high 3.6k, xhigh 12k, max 66k다. 채점은 계산식 low의 한 번을 빼고 모든 단계가 세 번 모두 만점이고, 시간은 아래 표에 있다.
막대가 아무리 높아져도 아래의 만점 횟수는 거의 그대로입니다.

그래프에서 먼저 볼 것은 막대 아래 줄입니다. effort를 다섯 단계로 바꾸는 동안 채점 결과는 거의 움직이지 않았어요. 30번 중 29번이 만점이었습니다.

토큰은 반대로 계단이 아니라 절벽처럼 오릅니다. low에서 high까지는 1.2~2.1배로 완만하고, high에서 xhigh로 넘어가면 3.2~3.3배, xhigh에서 max로 가면 다시 5.6~6.1배가 됩니다.

그래서 이번 실측에서 고를 자리는 high와 xhigh 사이였습니다. high까지는 거의 공짜로 꼼꼼해지고, 그 위부터는 같은 결과에 값을 크게 치르게 됩니다.

줄바꿈 과제: 다섯 단계 모두 만점

세 번 모두 23개를 전부 통과했습니다. 차이는 결과가 아니라 쓴 양에서 났어요. 아래는 세 번의 평균입니다.

effort 통과(3회) 시간 출력 토큰 턴 비용(보고값)
low 23·23·23 29초 2,465 4.3 $0.16
medium 23·23·23 45초 4,014 4.0 $0.19
high 23·23·23 54초 5,137 5.3 $0.23
xhigh 23·23·23 2분 25초 16,527 10.0 $0.58
max 23·23·23 15분 38초 101,135 28.3 $3.40

high까지는 완만하게 오르다가 xhigh에서 한 번, max에서 크게 뜁니다. max는 세 번이 12분, 15분, 20분으로 편차도 컸어요.

비용은 Claude Code가 결과에 적어 주는 값으로, API 단가로 환산한 숫자입니다. 구독으로 쓰면 이만큼 청구되지는 않지만, 그만큼 사용량 한도를 쓴다고 보면 됩니다.

계산식 과제: low에서 한 번 틀렸다

함정을 넣은 과제였는데도 결과는 비슷했습니다. 15번 중 14번이 35개를 모두 맞혔어요.

effort 통과(3회) 시간 출력 토큰 턴 비용(보고값)
low 34·35·35 37초 3,082 7.3 $0.19
medium 35·35·35 37초 3,270 6.0 $0.19
high 35·35·35 42초 3,589 5.7 $0.20
xhigh 35·35·35 1분 53초 11,732 10.7 $0.45
max 35·35·35 11분 23초 66,082 17.7 $2.12

틀린 한 번은 low의 첫 실행이었습니다. 계산하기 전에 식에서 공백을 전부 지워 버려서, 1 2를 오류 대신 12로 계산했더라고요. README에는 “숫자 두 개가 붙은 식은 오류”라고 적어 뒀고, 보여 준 예시 테스트에는 이 경우가 없었어요.

같은 low도 나머지 두 번은 이 함정을 피했습니다. 그러니 “low는 틀린다”기보다 “low는 가끔 규칙 한 줄을 놓친다”에 가깝습니다. 계산식 과제에서 medium 이상은 모두 맞혔어요.

max는 그 시간에 무엇을 했나

결과가 같은데 max가 15분을 쓴 이유가 궁금해서 남긴 코드와 보고를 열어 봤습니다.

줄바꿈 과제에서 max는 README에 없는 경우까지 파고들었습니다. 국기 이모지나 U+FE0F가 붙은 이모지는 유니코드 표에서 넓은 문자가 아닌데도 터미널에서는 2칸으로 그려진다며 따로 처리했어요. wrap('', 1)이 빈 문자열 규칙과 폭 검사 중 무엇을 먼저 따라야 하는지도 따져 봤고요.

틀린 판단은 아닙니다. 다만 이번 과제에서는 채점에 영향이 없는 고민이었고, 그 값이 토큰 10만 개였습니다. 공식 문서도 max는 효과가 줄어들 수 있고 과하게 생각하기 쉬우니 넓게 쓰기 전에 시험해 보라고 적고 있습니다.

반대로 low와 medium은 규칙에 없는 부분을 스스로 정하고, 정한 내용을 끝에 짧게 알려 줬습니다. “탭도 공백으로 봤다”처럼요. 결과를 바로 확인할 수 있는 상황이면 이쪽이 오히려 편했습니다.

effort 바꾸는 법

세션 안에서는 /effort, 시작할 때는 --effort입니다.

/effort high
/effort status
claude --effort high
  • /effort만 치면 슬라이더가 열립니다. Enter로 고르면 그 모델의 기본값으로 저장되고, s를 누르면 이번 세션에만 적용돼요.
  • 환경 변수 CLAUDE_CODE_EFFORT_LEVEL로도 정할 수 있습니다. --effort·/effort와 함께 설정 파일보다 먼저 적용돼요.
  • max는 환경 변수로 정하지 않는 한 그 세션에만 적용되고 저장되지 않습니다.
  • 정하지 않으면 모델 기본값을 씁니다. Opus 5.5·Sonnet 5.5·Haiku 5.5는 medium, Opus 4.7은 xhigh, 나머지 effort를 지원하는 모델은 high입니다.

예전 설정 파일에 최상위 effortLevel을 적어 뒀다면, 사용자 설정에 있는 그 값은 Opus 5.5에 적용되지 않습니다. Opus 5.5는 /effort로 따로 골라야 해요.

저는 이렇게 고릅니다

상황 effort
이름 바꾸기, 초안, 결과를 바로 보고 고칠 일 low
범위가 분명한 일상 구현(대부분) 기본값 medium
기존 코드의 버그 수정, 규칙이 많고 예외가 잦은 일 high
혼자 오래 돌려야 하는 어려운 문제 xhigh부터 시험
보안 점검처럼 끝까지 파고들어야 하는 일 max, 결과를 꼭 비교

이번 두 과제 기준으로는 high가 medium보다 10초 안쪽으로 더 걸렸을 뿐입니다. 함정이 걱정되는 일이면 high까지는 부담 없이 올려도 되지만, xhigh부터는 토큰이 3배 넘게 뛴다는 걸 감안하세요.

한 가지 짚어 둘 점이 있습니다. 이번 과제는 README에 규칙이 다 적혀 있는 문제였어요. 규칙을 스스로 찾아야 하거나 여러 파일을 엮어 판단해야 하는 일에서는 단계별 차이가 더 날 수 있으니, 자주 하는 일 하나로 직접 비교해 보는 게 가장 정확합니다.

돌려 보고 나서

effort를 올리면 더 똑똑해질 거라고 막연히 생각했는데, 규칙이 분명한 일에서는 똑똑함보다 꼼꼼함의 차이였습니다. 높은 단계는 규칙 밖까지 살피고, 낮은 단계는 빨리 끝내고 남은 판단을 사람에게 넘기더라고요.

평소에는 기본값으로 쓰다가, 결과에서 놓친 규칙이 보이면 그때 한 단계 올리는 쪽을 권합니다. 모델 자체를 바꾸는 방법은 Claude Code 모델 변경 5가지 방법에, effort 말고 토큰을 줄이는 방법은 직접 재 본 토큰 절약 8가지에 정리해 뒀습니다.

같은 과제를 Opus·Sonnet·Haiku에 effort별로 맡겼을 때 비용이 얼마나 갈리는지는 모델과 effort 조합을 108번 돌려 본 글에 이어서 정리했습니다.

참고한 공식 자료

2026년 10월 22일에 확인했습니다.

  • Model configuration — 모델별 effort 단계와 기본값, 적용 순서(환경 변수·--effort·/effort → 설정 → 모델 기본값), max가 세션에만 적용되는 점, 단계별 권장 용도