Claude Opus 5 effort 라우팅 운영법: 비싼 모델을 필요한 요청에만 쓰는 방법

Claude Opus 5 같은 고성능 모델을 도입할 때 가장 위험한 방식은 모든 요청을 새 모델로 바꾸는 것입니다. 성능은 좋아질 수 있지만 비용 구조가 흐려지고, 어떤 요청에서 효과가 있었는지 설명하기 어려워집니다. 실무에서는 모델 업그레이드보다 effort 라우팅 설계가 먼저입니다.

여기서 effort 라우팅은 요청의 위험도와 난도에 따라 모델과 추론 강도를 다르게 배정하는 방식입니다. 낮은 난도는 저렴하고 빠른 경로로 보내고, 실패 비용이 큰 작업만 Opus 5의 높은 effort로 보냅니다. 이렇게 해야 비용을 통제하면서도 중요한 작업에서 모델 성능을 활용할 수 있습니다.

1단계: 요청을 작업 유형으로 나누기

라우팅의 출발점은 분류입니다. 대부분의 팀은 처음에 model=claude처럼 단일 호출 로그만 남깁니다. 이 상태에서는 비용이 늘어도 원인을 찾기 어렵습니다. 최소한 다음 수준으로 나눠야 합니다.

• 문서 요약
• 고객지원 답변 초안
• 코드 설명
• 코드 생성
• 코드 리뷰
• 장애 원인 분석
• 에이전트 자동 실행
• 보안·권한 관련 검토

작업 유형은 프롬프트 앞에 사람이 붙여도 되고, 작은 분류 모델이 먼저 판단해도 됩니다. 초기에는 규칙 기반으로 충분합니다. 예를 들어 입력에 diff가 있고 변경 파일이 10개 이상이면 코드 리뷰, 로그와 에러 스택이 있으면 장애 분석, auth, payment, permission 같은 경로가 포함되면 고위험 검토로 분류합니다.

2단계: 위험도 점수 만들기

작업 유형만으로는 부족합니다. 같은 코드 리뷰라도 README 수정과 결제 로직 수정은 다릅니다. 그래서 위험도 점수를 붙이는 편이 좋습니다. 복잡한 머신러닝 모델이 필요하지 않습니다. 실무에서는 가중치 합산이 더 운영하기 쉽습니다.

예시 기준은 다음과 같습니다.

• 핵심 경로 변경: +3점
• 인증·권한·결제·개인정보 코드 포함: +4점
• 삭제된 테스트 존재: +2점
• 변경 파일 20개 이상: +2점
• 마이그레이션 포함: +3점
• 외부 API 호출 권한 포함: +2점
• 사용자가 ‘배포 전 검토’라고 명시: +2점

합계가 02점이면 낮은 effort, 36점이면 표준 effort, 7점 이상이면 높은 effort로 보낼 수 있습니다. 중요한 것은 점수 기준을 코드로 남기고, 운영 중 수정할 수 있게 하는 것입니다.

3단계: 비용 한도와 중단 조건 정하기

강한 모델은 작업을 오래 붙잡고 더 깊게 파고들 수 있습니다. 장점이지만 비용 위험이기도 합니다. 따라서 라우팅만큼 한도 설정이 중요합니다.

요청별로 최대 입력 토큰, 최대 출력 토큰, 도구 호출 횟수, 재시도 횟수, 전체 실행 시간을 제한해야 합니다. 예를 들어 코드 리뷰는 최대 2회 도구 호출, 장애 분석은 로그 검색 5회까지, 리팩터링 계획은 출력 4,000토큰까지처럼 정합니다.

중단 조건도 필요합니다. 모델이 같은 파일을 세 번 반복해서 읽거나, 같은 테스트 실패를 반복 설명하거나, 확실한 근거 없이 결론을 바꾸면 중단하고 사람에게 넘기는 편이 낫습니다. AI 비용은 토큰만이 아니라 기다리는 시간과 잘못된 변경을 되돌리는 비용까지 포함됩니다.

4단계: 내부 eval 세트 만들기

라우팅 정책은 감으로 고치면 안 됩니다. 작아도 내부 eval 세트가 있어야 합니다. 최근 한 달간 실제로 어려웠던 요청을 모읍니다.

• 실패했던 PR 리뷰 30건
• 운영 장애 로그 20건
• 고객지원 난제 50건
• 사람이 많이 고친 문서 초안 30건
• 보안 검토가 필요했던 변경 20건

각 항목에는 기대 결과를 붙입니다. 코드 리뷰라면 잡아야 할 위험, 장애 분석이라면 실제 원인, 고객지원이라면 반드시 포함해야 할 조건을 적습니다. 이후 낮은 effort, 표준 effort, 높은 effort를 같은 세트에 돌려 비교합니다.

비교 기준은 정답률 하나로 끝내지 않습니다. 평균 비용, p95 지연시간, 재시도 횟수, 사람 수정 시간, 위험 누락률을 같이 봐야 합니다. 특히 보안·결제·권한 영역에서는 평균 성능보다 최악의 누락이 중요합니다.

5단계: 프로덕션 로그 설계

운영 로그에는 최소한 다음 필드가 필요합니다.

task_type
risk_score
model
effort
input_tokens
output_tokens
tool_calls
latency_ms
retry_count
human_override
final_status
user_feedback

이 로그가 있어야 다음 결정을 할 수 있습니다. 예를 들어 높은 effort 요청의 70%가 사람이 수정 없이 통과한다면 좋은 신호입니다. 반대로 낮은 effort 요청에서 사람 수정이 계속 많다면 싸게 처리한 것이 아니라 품질 부채를 만든 것입니다.

로그 설계에서 주의할 점은 개인정보와 코드 보안입니다. 원문 프롬프트를 그대로 저장하지 말고, 필요한 경우 해시나 익명화된 메타데이터만 남깁니다. 장애 로그나 고객 데이터가 포함될 수 있다면 보존 기간도 정해야 합니다.

6단계: fallback과 승격 경로 만들기

처음부터 완벽하게 분류할 수는 없습니다. 그래서 fallback이 필요합니다. 낮은 effort가 답변을 냈지만 confidence가 낮거나, 테스트 실패를 설명하지 못하거나, 사용자가 재질문하면 표준 effort로 승격합니다. 표준 effort에서도 해결하지 못하면 Opus 5 높은 effort로 보내고, 그래도 실패하면 사람에게 넘깁니다.

이때 같은 프롬프트를 그대로 다시 보내지 않는 것이 중요합니다. 승격할 때는 이전 시도 결과, 실패 이유, 추가로 필요한 근거를 함께 넘겨야 합니다. 그래야 높은 모델이 같은 실수를 반복하지 않습니다.

간단한 정책 예시

if task_type in [summary, faq] and risk_score <= 2:
  use fast_model, low_effort

elif task_type in [code_review, incident_analysis] and risk_score <= 6:
  use balanced_model, medium_effort

elif risk_score >= 7 or touches_security_or_payment:
  use claude_opus_5, high_effort

if retry_count >= 2 or tool_calls_exceeded:
  escalate_to_human

실제 구현에서는 모델명과 effort 값이 사용하는 API에 맞게 달라집니다. 핵심은 정책을 코드로 명시하고, 로그로 검증하며, 매주 조금씩 조정하는 것입니다.

실행 체크리스트

• AI 요청을 최소 6개 이상 작업 유형으로 분류한다.
• 변경 범위, 민감 영역, 실패 비용으로 위험도 점수를 만든다.
• 낮은·중간·높은 effort 경로를 분리한다.
• 각 경로에 토큰, 시간, 도구 호출 한도를 둔다.
• 실제 데이터 기반 내부 eval 세트를 만든다.
• 프로덕션 로그에 task_type, risk_score, effort, final_status를 남긴다.
• 실패 시 같은 요청 반복이 아니라 정보가 추가된 승격을 수행한다.

Claude Opus 5 effort 라우팅의 목표는 비싼 모델을 아끼는 것이 아닙니다. 비싼 모델이 필요한 순간을 정확히 찾아서 쓰는 것입니다. 이 구조가 잡히면 모델 업그레이드는 비용 폭탄이 아니라 품질과 운영 효율을 같이 올리는 선택지가 됩니다.