effort는 똑똑함이 아니라 확인에 쓸 시간과 노력이다: Claude Code 레벨 고르는 법

Claude Code의 effort를 높였더니 더 오래 기다리게 됐는데 결과도 그만큼 좋아진 걸까요? effort는 작업에 계산 자원을 얼마나 쓸지 모델에게 알려 주는 설정입니다. “높을수록 좋겠지” 하고 쓰기 전에, 추가로 쓴 시간이 구현과 검증 중 어디에 쓰였는지 살펴볼 필요가 있습니다. 이 글은 같은 요청을 여러 설정에서 실행한 Thariq Shihipar의 실험을 설명합니다.

한눈에 보기

• effort를 올리면 모델이 스스로 확인하고 결정하는 데 더 많은 자원을 쓸 수 있습니다. 그만큼 시간과 토큰 사용량도 늘어날 수 있습니다.
• 드물지만 놓치면 문제가 되는 입력이나 상황을 엣지 케이스라고 합니다. 보안, 하드웨어, 코드 리뷰처럼 이런 경우가 많은 작업에서 효과가 컸습니다.
• 요구사항을 잘못 이해한 채 작업하면 effort를 올려도 잘 해결되지 않습니다.
• 저자는 Claude에게 질문을 시켜 요구사항을 채우고, low로 구현한 뒤 결과를 검토합니다. 방향이 맞으면 high로 검증합니다.

원문 소개

Thariq Shihipar가 2026년 9월 25일 claude.dev 블로그에 올린 글입니다. Opus 5.5 로 같은 과제를 여러 effort 에서 돌린 실험과, 커뮤니티 벤치마크 Terminal-Bench 3.0 의 Fable 5.1, Opus 5.5 결과를 함께 다룹니다. 벤치마크는 정해진 과제로 모델의 결과를 비교하는 시험입니다. effort를 언제 바꿔야 할지 감이 없는 Claude Code 사용자에게 맞습니다.

effort는 작업에 쓸 자원의 수준

effort는 이 작업에 자원을 “얼마나 쓸 거냐” 를 모델에게 알려 주는 신호로 이해하면 됩니다.

저자는 마감에 빗댑니다. 12시간이 주어지면 여러 방법을 비교하고 꼼꼼히 확인할 수 있지만 1시간이면 필요한 기능부터 완성하려 할 것입니다. effort도 이와 비슷하게 설명합니다. 낮은 설정에서 일을 대충 하라는 뜻은 아니며, 높은 설정에서는 스스로 검증하고 결정하는 범위가 넓어집니다.

low, medium, high, max는 effort 수준을 나타내는 이름입니다. 대화 중 /effort로 바꿀 수 있습니다. 저자는 최신 모델에서 이 설정을 바꿔도 프롬프트 캐시가 깨지지 않는 점을 장점으로 꼽습니다. 프롬프트 캐시는 앞서 보낸 동일한 입력을 재사용하는 기능으로, 긴 대화의 반복 입력 비용을 줄이는 데 도움이 됩니다.

간단한 예제 과제에서 보인 차이

Opus 5.5 로 같은 과제를 low, medium, high, max 에서 돌렸습니다.

• 무엇을 만들지 덜 정한 요청: 운동 기록 앱을 만들어 달라고만 했을 때 low 1.5분, medium 4분, high 11분, max 67분이 걸렸습니다. low는 기록과 단순 그래프를 만들었고 max는 활동 강도를 색으로 표시하는 히트 차트까지 만들었습니다. 시간이 늘면서 기능도 늘었지만 사용자가 정하지 않은 선택을 Claude가 더 많이 했습니다.
• 디자인 방향이 정해진 요청: /config 메뉴 개편에서 low(1분)는 아이디어를 보여 주는 스케치를, max(28분)는 실제 Claude Code 화면과 닮은 목업을 내놨습니다. 목업은 동작을 완성하기 전에 모양을 확인하는 화면 시안입니다. 아이디어를 확인하려는 목적이라면 저자는 low가 낫다고 봤습니다.
• 요구사항을 자세히 정한 요청: Claude가 사용자에게 질문하는 인터뷰를 거쳐 스펙, 즉 구현할 기능과 조건을 정했습니다. 이후 시간은 low 16분, medium 22분, high 33분, max 79분으로 벌어졌지만 디자인과 구현은 비슷했고 세부만 달랐습니다.

요구가 모호한 과제에서는 결과물의 모양이 바뀌었고 스펙이 촘촘한 과제에서는 주로 시간과 세부가 달라졌습니다.

여기서 인터뷰는 Claude가 빠진 요구사항을 사용자에게 묻는 과정입니다. 만들려는 기능과 예상 결과를 먼저 정하고 low로 구현합니다. 검토에서 방향이 틀렸다면 요구사항을 보완해 다시 구현하고 방향이 맞을 때 high로 올려 놓친 오류를 확인합니다. 처음부터 오래 검증해도 만들려는 것과 다르면 그 시간을 되돌릴 수 없기 때문입니다.

어려운 과제에서는 무엇이 달라지나

어려운 과제에서는 추가 검증이 성공 여부를 바꾸기도 했습니다. html-js-filter는 HTML에 몰래 끼워 넣은 JavaScript가 실행되지 않도록 걸러 내는 과제입니다. Fable 5.1은 low에서 5번 중 1번, high보다 높은 단계인 xhigh에서 5번 중 5번 통과했습니다.

low는 약 2분 만에 코드를 작성하고 직접 만든 페이지 하나로 시험했습니다. 저자가 따로 추적한 high 시도 한 건은 약 33분 동안 초안에 공격용 입력을 넣어 보고, HTML 구조를 읽는 파서의 소스 코드도 분석했습니다. 악성 스크립트가 실행되는 XSS 공격을 막는 표준 테스트를 돌리고, 무작위 문서를 만들어 놓친 입력을 찾는 퍼저까지 만들었습니다. 더 오래 생각한 결과가 실제로 어떤 검증으로 이어졌는지 보여 주는 사례입니다.

low 는 한 번 짜고 한 군데에서만 확인하고 끝냈고, high 는 초안을 여러 방향에서 검증했습니다.

Opus 5.5의 과제에서도 차이가 났습니다. 아래의 긴 이름은 벤치마크 과제명입니다. 통과 횟수에서 0/5는 다섯 번 실행해 한 번도 통과하지 못했다는 뜻입니다.

원문은 주된 차이를 엣지 케이스 검증에서 찾습니다. 높은 설정에서는 무작위 테스트, 더 큰 입력, 전처리 방식 비교를 통해 스스로 문제를 찾았습니다. 과제명의 기술적 의미보다, 낮은 설정이 어떤 확인을 생략했는지를 보면 실험의 뜻을 이해하기 쉽습니다.

전체 실험에서 Fable 5.1은 설정마다 370번씩 시도했습니다. low는 140번, max는 214번 통과했습니다. 대신 시도당 토큰 사용량의 중앙값은 73k에서 222k로 늘었습니다. 토큰은 모델이 읽고 생성하는 텍스트를 세는 단위이며 k는 천 단위입니다. 중앙값은 사용량을 순서대로 놓았을 때 가운데 있는 값입니다.

실패 종류를 보면 주의할 점도 있습니다. 빠뜨린 케이스 때문에 실패한 건은 59건에서 24건으로 줄었지만 요구사항을 잘못 해석해 엉뚱한 방향으로 진행한 실패는 25건에서 47건으로 늘었습니다. 검증을 더 많이 한다고 작업의 방향까지 항상 맞는 것은 아닙니다.

분야별 수치는 가장 낮은 두 설정과 가장 높은 세 설정을 각각 합쳐 비교한 값입니다. 하드웨어 분야인 Hardware는 34%에서 75%, 보안 분야인 Security는 64%에서 87%로 올랐습니다. 운영 작업인 Operations는 12%에서 22%에 그쳤습니다. 원문 차트는 정해진 규칙이나 매뉴얼을 따르는 작업에서 개선 폭이 작다고 설명합니다. 이 숫자는 내부 실행 기준이어서 과제별 통과 횟수가 공개 순위표인 리더보드와 맞지 않을 수 있습니다.

그림 1. 가로축은 시도당 토큰 사용량의 중앙값, 세로축은 통과율입니다. 점 옆의 low~max는 effort 설정입니다. 원문 도형과 수치를 유지하고 축과 설명만 한글화했습니다. 출처: 원문 .

가로축은 로그 눈금이라 눈금 사이의 간격이 같은 토큰 수의 증가를 뜻하지 않습니다. 오른쪽으로 갈수록 토큰을 더 썼고, 위로 갈수록 통과율이 높았습니다. 분야별 비교에서는 Hardware의 개선 폭이 가장 컸습니다.

저자의 레벨 선택 기준

• Low: 곁에서 보며 빠르게 주고받을 때. 브레인스토밍, 스케치, 쉬운 수정.
• Medium: 평소의 소프트웨어 작업. 새 기능 구현.
• High: 검증이 중요하거나 엣지 케이스가 많을 때. 기존 코드의 버그 수정.
• Max: 사람 없이 어려운 문제를 끝까지 풀게 할 때. 앱 전체 구축과 검증, 핵심 소프트웨어의 보안 취약점 찾기.

인사이트

여기서부터는 원문이 아니라 이 블로그의 해석입니다.

1. effort를 높이면 결과가 맞는지 확인하는 데 더 많은 시간과 계산 자원을 쓸 수 있습니다. 이 글에서 말하는 “확인에 쓸 시간과 노력"도 이 뜻입니다. effort가 검증만 조절하는 설정은 아니지만 원문의 실험에서는 추가 자원을 테스트와 여러 방법의 비교에 썼을 때 효과가 뚜렷했습니다. 데이터베이스 조회문인 SQL을 만드는 작업에서도 결과가 맞는지 확인할 방법이 있다면 높은 effort를 활용해 볼 만합니다.

2. 확인을 오래 하는 것보다 무엇을 만들어야 하는지 먼저 정하는 일이 필요합니다. 요구사항을 잘못 이해한 상태에서는 테스트를 늘려도 원하는 결과와 멀어질 수 있습니다. 원문에서도 Claude가 질문하며 요구사항을 구체화한 뒤에는 effort 설정이 달라도 결과물이 비슷해졌습니다. 이 결과는 요구사항부터 정리하자는 해석을 뒷받침합니다.

3. 사용자가 작업 중 질문에 답하고 중간 결과를 확인할 수 있는지도 설정을 고르는 기준이 됩니다. 원문도 사용자가 응답할 수 있었다면 Claude가 분석에 앞서 데이터를 어떻게 정리할지 물어봤을 수 있다고 설명합니다. 사용자의 개입 없이 진행하는 작업은 높은 effort로 에이전트가 여러 방법을 비교하게 하고, 사용자가 함께 확인하며 진행하는 작업은 low로 빠르게 주고받는 방식을 고려할 수 있습니다.

바로 해볼 것

• 다음 기능 작업을 맡길 때 Claude에게 빠진 요구사항부터 질문해 달라고 요청합니다. 답을 주고 low로 구현하게 한 뒤 원하는 방향인지 확인합니다. 방향이 맞으면 /effort로 high를 선택해 놓친 오류를 찾아보게 합니다.
• 해결하지 못한 버그 하나를 골라 같은 설명으로 medium과 high에서 각각 시도합니다. 각 시도에서 버그를 어떻게 재현했고 어떤 테스트로 수정 결과를 확인했는지 비교합니다.
• 사용자 개입 없이 진행한 자동화가 실패했다면 기록을 읽어봅니다. 드문 입력이나 상황을 놓친 것인지, 요구사항 자체를 잘못 이해한 것인지 구분합니다. 놓친 입력이나 상황은 테스트에 추가하고 요구사항을 잘못 이해했다면 요청 내용을 구체화하는 데 참고할 수 있습니다.

원문: Using Claude Code: Spending your effort