Claude Opus 5 출시: 개발팀이 effort 설정과 비용 기준을 다시 잡아야 하는 이유

Claude Opus 5가 공개되면서 모델 선택 기준이 단순히 ‘가장 똑똑한 모델을 쓴다’에서 ‘업무별 effort와 비용을 어떻게 배치할 것인가’로 옮겨가고 있습니다. Anthropic의 공개 설명에 따르면 Opus 5는 Opus 4.8과 같은 가격대에서 성능을 끌어올렸고, Frontier-Bench, CursorBench, OSWorld, Zapier AutomationBench 같은 코딩·지식 작업 평가에서 비용 대비 성능을 강조합니다.

개발팀 입장에서 중요한 포인트는 모델 이름이 하나 더 늘었다는 사실이 아닙니다. 이제 Claude 계열을 쓰는 서비스는 요청마다 같은 모델을 같은 강도로 호출하는 구조를 유지하기 어려워졌습니다. 간단한 분류, 문서 요약, PR 코멘트 초안, 복잡한 버그 수정, 장기 리팩터링은 필요한 추론 깊이가 다릅니다. Opus 5가 effort 설정을 통해 지능과 토큰 사용량 사이의 균형을 조절할 수 있다는 점은 이 차이를 제품 설계에 반영하라는 신호에 가깝습니다.

이번 업데이트에서 봐야 할 핵심

Anthropic은 Opus 5를 ‘일상적으로 쓰기 좋은 강한 모델’로 설명합니다. 이전 세대보다 더 철저하게 검증하고, 긴 작업에서 스스로 반복하며, 코딩과 분석 업무에서 안정성이 좋아졌다는 메시지를 냈습니다. 특히 공개된 고객 사례를 보면 단순 질의응답보다 실제 개발 프로세스에 가까운 사례가 많습니다. 브랜치 확인, 테스트 영향 검토, 루트 원인 분석, 화면을 직접 열어 모바일 문제를 확인하는 식의 작업입니다.

이런 사례는 마케팅 문구로만 보면 위험합니다. 하지만 운영 관점에서는 힌트가 됩니다. Opus 5를 도입할 때는 ‘정답률이 몇 % 올랐다’보다 ‘어떤 작업에서 재시도 횟수와 사람 검토 시간이 줄어드는가’를 먼저 봐야 합니다. AI 비용은 토큰 가격만으로 계산하면 틀립니다. 한 번에 맞춰서 사람 시간을 줄이는 모델이 있고, 싸지만 세 번 돌려야 하는 모델이 있습니다. 개발 조직에서는 후자를 싸다고 보기 어렵습니다.

왜 effort 라우팅이 중요해졌나

모델 API를 운영하다 보면 대부분의 비용은 극단적인 일부 요청에서 나옵니다. 간단한 Q&A나 코드 설명은 작은 모델로 충분하지만, 코드베이스 전체를 읽고 설계를 바꾸는 작업은 실패 비용이 큽니다. Opus 5의 effort 설정은 이 둘을 같은 정책으로 처리하지 말라는 뜻입니다.

예를 들어 사내 코드 리뷰 봇을 만든다고 가정해보겠습니다. 모든 PR에 최고 effort를 쓰면 비용이 빠르게 늘어납니다. 반대로 모든 PR에 낮은 effort를 쓰면 위험한 변경을 놓칠 수 있습니다. 현실적인 방식은 PR을 먼저 분류하는 것입니다. 변경 파일 수, 핵심 경로 포함 여부, 테스트 삭제 여부, 인증·결제·권한 코드 변경 여부를 기준으로 위험도를 계산합니다. 낮은 위험도 PR은 낮은 effort, 중간 위험도는 표준 effort, 높은 위험도는 Opus 5 높은 effort로 보내는 식입니다.

이 구조는 사용자용 챗봇에도 적용됩니다. FAQ 답변, 문서 검색, 로그 요약은 저렴한 경로로 처리하고, 장애 원인 분석이나 배포 전 변경 검토는 강한 모델로 승격합니다. 중요한 건 라우팅 기준을 감으로 두지 않는 것입니다. 요청 길이, 실패 시 손실, 외부 시스템 접근 여부, 코드 실행 여부, 보안 민감도 같은 기준을 명시해야 합니다.

개발팀이 바로 점검할 항목

첫째, 현재 Claude 호출 로그를 작업 유형별로 나눠야 합니다. ‘chat completion 10만 건’처럼 보면 아무것도 결정할 수 없습니다. 최소한 요약, 코드 작성, 코드 리뷰, 장애 분석, 고객지원, 에이전트 실행처럼 분류해야 합니다.

둘째, 모델별 성공 기준을 다시 정의해야 합니다. 단순히 사용자가 좋아요를 눌렀는지보다 더 구체적인 지표가 필요합니다. 코드 작업이면 테스트 통과율, 수정 후 리뷰 코멘트 수, 되돌림 발생률, 사람 개입 횟수를 봐야 합니다. 문서 작업이면 재작성 횟수, 사실 오류, 누락된 조건을 기록해야 합니다.

셋째, effort별 비용 한도를 둬야 합니다. 예를 들어 한 요청에서 높은 effort를 쓰더라도 최대 출력 토큰, 도구 호출 횟수, 재시도 횟수는 제한해야 합니다. 강한 모델은 일을 더 잘하지만, 제한 없이 두면 긴 작업에서 비용이 예상보다 커질 수 있습니다.

도입 시 흔한 실수

가장 흔한 실수는 ‘기존 모델 이름만 Opus 5로 바꾸기’입니다. 이렇게 하면 장점은 일부만 얻고 비용은 그대로 늘어날 수 있습니다. Opus 5의 장점은 어려운 작업에서 더 좋은 판단을 한다는 데 있으므로, 어려운 작업을 구분하는 라우터가 없으면 투자 대비 효과를 측정하기 어렵습니다.

두 번째 실수는 벤치마크 점수를 제품 성능으로 착각하는 것입니다. Frontier-Bench나 OSWorld 결과는 참고자료일 뿐입니다. 우리 코드베이스, 우리 고객 질문, 우리 장애 로그에서 잘하는지는 별도로 봐야 합니다. 작은 내부 eval 세트를 만드는 편이 더 낫습니다. 최근 30개 장애 티켓, 실패했던 PR 30개, 고객지원 난제 50개처럼 실제 데이터를 익명화해 평가해야 합니다.

세 번째 실수는 사람 검토 단계를 없애는 것입니다. Opus 5가 이전보다 더 조심스럽게 검증한다는 설명은 ‘검토자 없이 배포해도 된다’는 뜻이 아닙니다. 오히려 강한 모델일수록 더 큰 변경을 시도할 수 있으므로, 배포 권한·파일 쓰기 권한·외부 API 호출 권한은 별도 정책으로 묶어야 합니다.

추천 운영 구조

실무에서는 3단계 라우팅이 가장 단순합니다. 기본 경로는 빠르고 저렴한 모델입니다. 중간 경로는 정확도가 필요한 일반 업무입니다. 최고 경로는 Opus 5 높은 effort처럼 비용은 크지만 실패 비용이 더 큰 작업에만 씁니다.

라우팅 전에는 요청을 분류합니다. 라우팅 후에는 결과를 평가합니다. 평가 결과는 다시 라우팅 정책에 반영합니다. 예를 들어 낮은 effort에서 코드 리뷰 누락이 많다면 해당 조건을 중간 effort로 올립니다. 높은 effort를 써도 사람이 계속 고친다면 프롬프트나 도구 설계를 고쳐야지 모델만 믿으면 안 됩니다.

로그에는 최소한 task_type, model, effort, input_tokens, output_tokens, tool_calls, latency_ms, human_interventions, final_status를 남기는 것이 좋습니다. 이 정도만 있어도 다음 달 비용 회의에서 ‘왜 비싼 모델을 쓰는가’를 설명할 수 있습니다.

실행 체크리스트

• Claude 호출을 작업 유형별로 분류한다.
• 실패 비용이 큰 작업과 작은 작업을 나눈다.
• Opus 5를 전체 교체가 아니라 고위험 작업 라우트로 먼저 붙인다.
• effort별 최대 토큰, 도구 호출, 재시도 횟수를 제한한다.
• 최근 PR·장애·지원 티켓으로 내부 eval 세트를 만든다.
• 비용 지표와 품질 지표를 같은 대시보드에서 본다.
• 모델 업그레이드 전후를 최소 1~2주 A/B로 비교한다.

Claude Opus 5 업데이트의 핵심은 새 모델을 쓰느냐가 아닙니다. 개발팀이 AI 작업을 작업 유형, 위험도, 비용, 검증 기준으로 쪼개서 운영할 준비가 되었느냐입니다. 그 준비가 되어 있다면 Opus 5는 단순한 모델 교체보다 더 큰 운영 개선으로 이어질 수 있습니다.