클로드 오퍼스 5.5 노력 수준 비교: 낮음·중간·높음·매우 높음·최대, 언제 써야 할까?

코드 한 줄을 고치는데 답변이 길어져 답답했던 적이 있나요? 반대로 장애 원인을 찾으라고 맡겼더니 눈앞의 오류만 수정하고 다른 호출 경로를 놓쳐 다시 일을 시킨 경험도 있을 겁니다. 같은 클로드 오퍼스 5.5라도 답이 나오는 속도와 살펴보는 범위가 다른 이유 중 하나가 바로 ‘노력 수준(effort)’입니다.

설정 이름은 낮음, 중간, 높음, 매우 높음, 최대처럼 단순하지만, 품질을 다섯 칸으로 고정해 놓은 점수표는 아닙니다. 클로드 오퍼스 5.5 노력 수준은 한 번의 작업에서 얼마나 깊게 사고하고, 얼마나 많은 출력과 도구 작업을 수행할지 조절하는 신호에 가깝습니다. 중요한 것은 최고 단계를 무조건 선택하는 일이 아니라, 내 업무를 처음부터 끝까지 처리하는 데 적정한 단계가 어디인지 찾는 것입니다.

먼저 알아둘 기본값과 오해

앤트로픽 노력 수준 공식 문서에 따르면 오퍼스 5.5는 low, medium, high, xhigh, max 다섯 단계를 지원하고 기본값은 medium입니다. 오퍼스 5의 기본값 high와 다릅니다. 예전 모델을 쓰던 코드에서 모델 ID만 바꾸면, 노력 수준을 명시하지 않은 요청은 이전과 다른 조건으로 실행됩니다.

이 설정은 ‘정해진 사고 토큰을 몇 개까지만 사용’하는 하드 캡이 아닙니다. 앤트로픽은 이를 작업 방식에 영향을 주는 행동 신호로 설명합니다. 쉬운 요청은 높은 단계에서도 길게 생각하지 않을 수 있고, 낮은 단계에서도 어려운 요청이라면 사고할 수 있습니다. 동일한 단계의 모델을 바꾸지 않고도 프롬프트, 도구 구성, 캐시 상태, 작업 난도에 따라 실제 토큰과 소요 시간은 달라집니다.

오퍼스 5.5에서는 적응형 사고가 항상 켜져 있습니다. thinking을 비활성화하거나 예전 방식으로 사고 토큰 예산을 직접 지정하는 요청은 허용되지 않습니다. 따라서 ‘빠르게 답해 달라’는 문구만 반복하는 것보다 먼저 노력 수준을 낮춰 시험하는 편이 공식 가이드의 권장 방향과 맞습니다. 낮은 노력 수준은 사고뿐 아니라 설명문, 도구 호출과 그 인수 등 출력 전체에 영향을 줍니다.

다섯 단계 한눈에 비교

표를 읽을 때는 ‘위로 갈수록 무조건 정답률이 일정 비율로 오른다’고 해석하지 마세요. 모델이 더 많은 사고와 도구 호출을 시도할 여지가 커지는 것이지, 성능 증가율이나 토큰 배율이 고정된 것은 아닙니다. 검증 가능한 테스트가 있는 단순 작업에서는 중간 수준으로도 충분하고, 테스트가 없는 난해한 변경에서는 높은 수준으로 올리기 전에 검증 경로부터 만드는 편이 효과적일 수 있습니다.

🔹 낮음: 규칙이 이미 정해졌다면

변수명 일괄 변경, 정해진 형식으로 로그를 요약하기, 이미 합의된 패턴을 다른 파일에 적용하기처럼 판단의 폭이 좁은 작업에 적합합니다. 응답과 도구 사용이 짧아질 수 있지만, ‘짧다’는 이유로 호출부나 테스트 누락이 정당화되지는 않습니다. 파일 여러 개를 건드린다면 변경 대상 목록과 통과해야 할 테스트를 프롬프트에 함께 적으세요.

🔹 중간: 기본값을 출발선으로

기능 하나를 구현하고 테스트까지 확인하는 일상적인 업무라면 먼저 중간으로 시작해 보세요. 오퍼스 5.5 프롬프팅 가이드는 자체 평가에서 오퍼스 5.5의 중간 단계가 오퍼스 5의 높은 단계와 비슷하거나 더 나은 결과를 적은 단계·토큰으로 내는 사례를 제시합니다. 이는 서로 다른 모델의 단계 이름만으로 사고량이 같다고 볼 수 없다는 뜻이지, 모든 조직의 저장소에서 동일한 결과가 나온다는 보장은 아닙니다.

🔹 높음: 한 계층에서 막힐 때

API 필드를 바꾼 뒤 서버 테스트는 통과했지만 프런트엔드 호출부가 여전히 옛 필드를 보내는 상황을 떠올려 보세요. 문제의 경계가 여러 계층에 걸쳐 있다면 높음이 탐색과 판단에 더 많은 여유를 줄 수 있습니다. 다만 바로 단계부터 올리기보다는 프런트엔드까지 통과하는 통합 테스트를 제공하면 중간에서도 빠진 부분을 찾아낼 수 있습니다. 노력 수준은 검증 수단을 대체하지 못합니다.

🔹 매우 높음·최대: 증거가 있을 때만

xhigh는 수십 분 이상 이어지는 복합 코딩이나 에이전트 업무처럼 탐색 범위가 넓을 때 고려합니다. max는 토큰 사용에 사실상 가장 적은 제약을 두고 깊게 분석해야 하는 예외적 세션에 적합합니다. 이때도 최대가 언제나 더 좋은 완성품을 뜻하지는 않습니다. 길어진 실행이 비용과 대기시간을 늘리고, 요구사항이 애매하면 오히려 필요 없는 방향으로 탐색할 수 있기 때문입니다.

실무 작업별로 고르는 팁

표만 봐서는 ‘내 업무가 복잡한 편인가?’ 판단하기 어렵습니다. 파일 수보다 영향 범위가 명확한지, 실행할 수 있는 검증 수단이 있는지, 처음 실패했을 때 어떤 부분이 빠졌는지를 먼저 보세요. 클로드 아카데미의 노력 수준 선택 가이드도 기본값에서 시작해 결과를 본 뒤 한 단계씩 조정하도록 권합니다. 아래는 공식 수치가 아니라 실제 업무에서 적용해 볼 출발점입니다.

1. 낮음 low — 작업 절차가 고정됐을 때

예를 들어 정해진 포맷의 로그를 표로 정리하거나, 승인된 명명 규칙에 따라 파일 몇 개의 변수명을 바꾸는 일입니다. 변경 대상과 기대 출력이 명확하고 결과를 스크립트나 검색으로 금방 검사할 수 있다면 낮음으로 시작하세요. 다만 ‘저장소 전체에서 이 필드를 사용하는 모든 경로를 찾아 안전하게 바꿔라’는 요청은 겉보기에는 이름 변경이어도 조사 범위가 넓습니다. 그때는 최소 중간에서 시작하거나 영향 파일을 먼저 특정하는 별도 단계를 두는 편이 낫습니다.

2. 중간 medium — 완료 조건이 정리된 일상 업무

한두 API에 유효성 검사를 추가하고 테스트를 실행하거나, 익숙한 서비스의 버그를 재현해 수정하고 코드 리뷰에 올리는 상황이라면 기본값이 합리적입니다. ‘파일 A와 B를 수정하고 단위 테스트 C를 통과시켜 줘’처럼 끝나는 조건을 알려 주세요. 기획·설계 회의 자료를 만들 때도 입력 자료와 판단 기준을 제공하고 사람이 검토할 수 있다면 중간에서 먼저 품질을 확인하면 됩니다. 문서의 중요도가 높다는 이유만으로 최대를 켤 필요는 없습니다.

3. 높음 high — 빠진 호출 경로가 드러났을 때

중간 단계의 수정안이 서버 테스트만 통과하고 화면 호출부를 놓쳤거나, 장애 원인 후보를 하나만 확인하고 종료했다면 높음을 시험할 신호입니다. ‘화면→API→배치까지 호출 경로를 추적하고 회귀 테스트 목록을 제출해 줘’처럼 놓친 지점을 구체적으로 보강하세요. 먼저 통합 테스트나 재현 로그를 제공하면 중간에서도 해결될 수 있습니다. 앤트로픽의 모델·노력 수준 안내에 따르면 관련 맥락을 주었는데도 파일을 읽지 않거나 테스트를 건너뛴 경우는 더 높은 노력 수준을 검토할 만하지만, 필요한 지식 자체가 부족한 문제는 설정을 올리는 것만으로 해결되지 않습니다.

4. 매우 높음 xhigh — 긴 탐색이 끝까지 필요한 업무

여러 서비스의 인증 경로를 대조하고 변경 영향도를 정리한 뒤 테스트 계획까지 만들어야 하는 작업, 오랜 시간 무인 실행되는 마이그레이션·복잡한 디버깅처럼 조사와 검증이 여러 차례 반복되는 일에서 후보가 됩니다. 예컨대 인증서 피닝 변경이라면 앱 버전별 동작, 서버 측 갱신 일정, 장애 복구 경로를 자료에 포함하고 ‘영향 목록과 미확인 항목만 제시하고 운영 설정은 변경하지 말 것’이라고 경계를 주세요. 결과 확인 없이 오래 맡겨 두는 것보다 작업 단계마다 검토 지점을 만드는 편이 안전합니다. high에서도 동일한 범위를 충분히 마쳤다면 xhigh는 쓰지 않아도 됩니다.

5. 최대 max — 실패 비용이 큰 난제를 한 세션에서 집중 분석할 때

운영 장애의 원인이 여러 계층에 얽혀 있고 사람의 검토 시간이 제한적이라, 제한된 한 세션에서 가능한 가설을 넓게 검증해야 한다면 최대를 검토할 수 있습니다. 단, ‘최대’는 무제한 승인 권한이 아니라 더 깊게 작업하도록 주는 신호입니다. 조사 범위, 금지 작업, 중단 시점, 예상 비용 한도와 사람이 승인해야 할 변경을 먼저 정하세요. 금융 시스템에서는 운영 데이터 반출·실거래 실행·배포 권한을 별도로 차단하고, 근거 없는 추정을 사실처럼 보고하지 않도록 미확인 항목을 구분해야 합니다. 같은 유형의 과제를 xhigh가 안정적으로 마친다면 최대를 유지할 근거가 없습니다.

📌 결과를 보고 다시 조정하는 법

결과가 짧고 미완성이면 무조건 설정부터 올리지 마세요. 요구사항이 모호했는지, 읽을 파일·도구 접근이 없었는지, 테스트가 마련됐는지를 먼저 확인합니다. 반대로 작은 변경인데 지정하지 않은 일을 벌이거나 불필요한 파일을 대량으로 읽고 오래 걸리면 한 단계 내리세요. 간단한 검색·로그 요약만 맡길 때는 오퍼스의 노력 수준을 낮추는 방법 외에 경량 모델을 분리해 쓰는 선택지도 있습니다. 설정별 성공 여부는 첫 답변의 인상보다 테스트 통과, 누락 건수, 사람의 수정 시간, /usage의 완료 작업당 비용으로 판단하는 것이 정확합니다.

비용과 속도는 어떻게 달라질까

API의 공개 표준 단가는 오퍼스 5.5 기준 입력 100만 토큰당 4달러, 출력 100만 토큰당 20달러, 캐시 읽기 100만 토큰당 0.20달러입니다. 노력 수준을 높인다고 같은 모델의 토큰 단가 자체가 단계별로 오르는 구조는 아닙니다. 사고 토큰도 출력 요금에 포함되므로, 추가 추론과 도구 호출로 사용량이 늘면 최종 비용이 달라집니다. 캐시 쓰기, 공급자별 요금, 구독 한도는 별도로 확인해야 합니다. 최신 단가는 앤트로픽 가격표에서 점검하세요.

계산 감각을 잡기 위한 예를 들어 보겠습니다. 동일한 작업에서 높은 단계가 중간보다 사고 토큰을 2만 개 더 사용했다고 가정하면, 출력 토큰 단가만 적용한 추가분은 약 0.40달러입니다. 이 수치는 실측 평균이 아닌 가정이며 입력 재전송, 캐시 쓰기, 추가 도구 호출 비용은 포함하지 않습니다. 이 차이 덕분에 큰 재시도 한 번을 피한다면 높은 단계가 더 경제적일 수 있고, 중간에서 처음부터 통과했다면 불필요한 지출일 수 있습니다.

이 표에서 핵심은 ‘요청 1회의 가격’보다 완료된 업무 1건의 가격입니다. 클로드 코드에서는 대화와 도구 결과가 여러 차례 모델에 다시 전달되고, 캐시가 적중했는지에 따라 입력 비용이 달라집니다. 앤트로픽의 작업당 비용 설명도 낮은 단계에서 실패해 재시도하면 첫 호출에서 아낀 비용이 사라질 수 있다고 강조합니다. 구독 이용자의 /usage에 표시되는 추정 달러 금액은 API 정가 기준의 참고값이지 곧바로 구독료 청구액을 뜻하지 않습니다.

클로드 코드와 API 설정법

클로드 코드에서는 먼저 /model로 실제 사용 모델을 확인하고, /effort status로 현재 단계를 확인합니다. 오퍼스 별칭이 항상 같은 모델을 뜻한다고 가정하면 안 됩니다. 제공 사업자와 클로드 코드 버전에 따라 연결 모델이 달라질 수 있으므로 오퍼스 5.5를 특정해 비교할 때는 모델 이름을 명시하는 편이 안전합니다. 클로드 코드 모델 설정 문서에 따르면 오퍼스 5.5를 사용하려면 클로드 코드 v2.1.280 이상이 필요합니다.

/model claude-opus-5-5
/effort status
/effort low
/effort medium
/effort high
/effort xhigh
/effort max
/effort auto
/usage

/effort auto는 모델 기본 동작으로 되돌릴 때 사용합니다. max는 환경변수 CLAUDE_CODE_EFFORT_LEVEL로 따로 설정하지 않는 한 현재 세션에만 적용됩니다. 특정 단계로 바꾼 뒤에는 /effort status로 적용 상태를 다시 확인하세요. 조직에서 관리하는 maxEffortLevel 제한이 있으면 그보다 높은 요청은 허용된 상한으로 실행될 수 있으므로, 명령을 입력했다는 사실만으로 최대 단계가 적용됐다고 판단하면 안 됩니다.

API에서는 output_config.effort에 단계 이름을 넣습니다. 아래 예시는 중간 수준을 명시적으로 지정합니다. max_tokens는 최종 답변 글자 수가 아니라 사고와 텍스트를 포함한 출력 토큰의 상한이라는 점에 유의하세요.

import anthropic

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-opus-5-5",
    max_tokens=4096,
    output_config={"effort": "medium"},
    messages=[{"role": "user", "content": "이 코드 변경의 영향 범위와 필요한 테스트를 설명해 줘."}],
)
for block in response.content:
    if block.type == "text":
        print(block.text)

높은 수준에서 긴 에이전트 작업을 시킨다면 max_tokens가 지나치게 작아 사고와 답변이 중간에 잘리지 않는지 살펴보세요. 오퍼스 5.5 마이그레이션 가이드는 xhigh·max에서 64K 토큰을 출발점으로 삼아 조정하도록 안내합니다. 모든 요청에 64K를 지정하라는 뜻은 아니며, 실제 출력·지연·중단 여부를 보고 정하면 됩니다. 예전 코드의 thinking: {"type": "disabled"}나 수동 budget_tokens는 오퍼스 5.5 요청에서 오류가 나므로 제거해야 합니다.

📌 세션 중 바꾸면 캐시는 괜찮을까?

단순히 ‘노력 수준을 바꾸면 언제나 캐시가 유지된다’고 말하면 부정확합니다. API에서 요청의 최상위 output_config.effort를 바꾸면 캐시된 앞부분이 무효화될 수 있습니다. 오퍼스 5.5는 베타 기능인 메시지별 노력 수준 변경으로 앞부분 캐시를 보존할 수 있지만, 베타 헤더와 메시지 구성이 필요합니다. 클로드 코드에서 앤트로픽 API 키 또는 클로드 구독으로 사용하는 경우 중간 변경의 캐시가 유지될 수 있는 반면, 일부 클라우드 제공자나 게이트웨이에서는 캐시가 초기화될 수 있습니다. 긴 세션에서 단계 전환이 잦다면 사용하는 경로별 캐시 적중률을 꼭 확인하세요.

실무에 맞는 선택 순서

금융 IT 변경관리처럼 한 파일의 수정이 화면, API, 배치, 테스트와 승인 절차에 영향을 준다면 단순히 최대 노력을 지정하기보다 완료 기준을 먼저 쓰는 것이 중요합니다. 예를 들어 ‘고객정보는 넣지 말고 샘플로 재현할 것, 호출부와 배치 영향 목록을 낼 것, 기존 테스트와 회귀 테스트를 실행할 것, 운영 반영은 사람 승인 후 진행할 것’처럼 경계를 명확히 적으세요.

• 기본값부터 시작: 범위가 분명한 작업은 medium, 단순 반복 작업은 low로 시작합니다.
• 한 단계만 올려 비교: 같은 실패가 나거나 영향 범위 탐색이 부족하면 high를 시험합니다. 오래 걸리는 복합 작업에서만 xhigh를 후보로 올립니다.
• 최대는 예외로: 난해한 장애 분석이나 설계 판단에서 다른 단계로 해결하지 못했고 추가 비용을 감수할 가치가 있을 때 한 세션에서 사용합니다.
• 검증 조건 고정: 동일한 입력 자료, 저장소 스냅샷, 테스트와 완료 정의로 비교하고 결과물은 사람의 리뷰를 거칩니다.
• 총비용 기록: /usage 또는 API 사용량에서 사고를 포함한 출력 토큰, 캐시 읽기·쓰기, 재시도 횟수, 완료 시간을 함께 남깁니다.

한 번의 시연만으로 우리 팀의 표준 단계를 정하지 마세요. 변경 난도가 다른 대표 작업을 여러 개 고르고, 단계별로 같은 완료 기준을 적용해 반복 비교하면 됩니다. 클로드 오퍼스 5.5 노력 수준의 정답은 가장 높은 설정이 아니라, 우리 업무에서 품질을 지키며 재작업을 최소화하는 설정입니다. 기본인 중간부터 출발해 검증 결과가 필요하다고 말해 줄 때만 한 단계씩 올리는 편이 가장 실용적입니다.

관련 글