Anthropic은 2026년 9월 22일 Claude Opus 5.5를 발표했습니다. 코드 유지보수, 조사, 내부 문서 작성에 AI 에이전트를 활용하는 기업이라면 같은 업무를 더 확실하게, 합리적인 총비용으로 완료할 수 있는지 확인할 시점입니다.
토큰 단가만으로는 판단하기 어렵습니다. 도구 비용, 재시도, 데이터 접근, 사람의 수정, 실패에 따른 재작업도 포함해야 합니다. Opus 5.5를 새로운 후보로 평가하면서 능력, 비용, 실행 권한을 함께 검토해야 합니다.
이 글은 9월 30일까지 확인한 공식 자료를 바탕으로 긴 작업의 평가, 가격 비교, 기업의 실행 통제를 설명합니다. 아래 AIOS 구성은 아키텍처 제안이며, 특정 제품에 이미 구현된 기능이라는 의미는 아닙니다. 실제 지원 여부는 항목별로 확인해야 합니다.
그림: 모델을 평가한 뒤 작업에 맞는 권한을 부여하고, 검수에 합격한 결과를 기준으로 품질과 비용을 측정합니다.
1. 긴 작업을 다시 평가합니다
Anthropic 발표는 코딩, 지식 업무, 장시간 에이전트 작업을 주요 용도로 설명합니다. 기업에서는 첫 답변뿐 아니라 요구사항을 유지하는지, 필요한 정보를 질문하는지, 검토할 수 있는 결과를 남기는지 확인해야 합니다.
여러 서비스의 라이브러리 업그레이드는 의존성 파악, 코드 변경, 테스트, 차이 설명까지 포함합니다. 조사 보고서는 원자료 확보, 수치 대조, 서로 다른 출처의 충돌 처리도 필요합니다. 짧은 질의응답만 테스트하면 과정에서 발생하는 실패와 사람의 개입을 놓칩니다.
🔗 AI 에이전트 개발은 검수 조건과 도구 피드백까지 설계해야 합니다. 테스트 가능한 유지보수, 출처를 확인할 수 있는 문서 작업, 되돌릴 수 있는 내부 동작부터 시작합니다. 기존 모델도 같은 조건에서 실행해 프롬프트나 검색 개선의 효과를 모델 업그레이드와 혼동하지 않도록 합니다.
2. 업무 비용 40%와 토큰 단가를 구분합니다
일반적인 워크로드 비용이 40% 감소한다는 공식 설명은 Opus 5 대비 공급업체 측정 결과입니다. 모든 기업에 동일한 절감률을 보장하지 않습니다. Claude Platform 가격표의 항목별 단가는 아래와 같습니다. 단위는 토큰 100만 개당 달러이며 빠른 모드, 도구, 플랫폼 차이 등은 포함하지 않습니다.
| 과금 항목 | Opus 5 | Opus 5.5 | 단가 감소율 |
|---|---|---|---|
| 입력 | 5 | 4 | 20% |
| 출력 | 25 | 20 | 20% |
| 캐시 읽기 | 0.50 | 0.20 | 60% |
| 5분 캐시 쓰기 | 6.25 | 5 | 20% |
감소율은 표의 가격으로 계산했습니다. 같은 문맥을 반복하는 긴 세션과 짧은 일회성 요청의 절감 효과는 다를 수 있습니다. 추론 강도와 출력량도 비용을 바꾸므로 이전 청구액에 일괄적으로 0.6을 곱해서 예산을 정하면 안 됩니다.
이 글에서는 모델 요금 + 도구와 인프라 + 사람의 검토와 수정 + 실패 후 재작업을 검수 합격 건수로 나누는 관리 지표를 제안합니다. 공급업체 과금 공식이 아닙니다. 저렴한 응답이라도 담당자가 오랫동안 수정해야 한다면 전체 비용은 높아질 수 있습니다.
🔗 효과적인 GPU 관리와 마찬가지로 에이전트도 자원이 실제 쓸 수 있는 성과로 이어지는지 봐야 합니다. 토큰을 줄이는 것보다 같은 예산으로 합격한 작업을 늘리는 것이 중요합니다.
3. 같은 작업을 같은 조건으로 비교합니다
벤치마크는 후보를 고르는 데 도움이 되지만 기업의 검수를 대신하지 않습니다. 프롬프트, 도구 환경, effort, 시간, 재시도 횟수, 안전 개입은 결과에 영향을 줍니다. 한 모델에만 더 좋은 검색 결과나 더 많은 시도를 제공해서는 공정하게 비교할 수 없습니다.
AWS 모델 카드는 1M 토큰 문맥 창과 조절 가능한 effort를 명시하며 adaptive thinking은 항상 활성화됩니다. 입력 용량이 크다는 사실이 모든 정보를 정확히 이해한다는 보장은 아닙니다.
데이터, 프롬프트, 도구 버전, 검수 조건을 고정하고 effort별 품질과 시간, 비용을 측정합니다. 거절, 시간 초과, 도구 오류는 별도 사유로 기록합니다. 실제 업무에서는 모두 미완료 작업이므로 점수를 높이기 위해 분모에서 제외하면 안 됩니다.
| 작업 | 검수 조건 | 추가 기록 |
|---|---|---|
| 코드 유지보수 | 테스트 통과, 요구 동작 유지, 검토 가능한 변경 | 회귀 오류, 위험 명령, 수정 시간 |
| 조사와 보고서 | 수치의 원출처, 질문에 맞는 결론 | 근거 없는 문장, 충돌 처리, 검토 시간 |
| 내부 업무 | 필수 필드, 정확한 쓰기, 중복 없음 | 권한 위반, 부작용, 복구 시간 |
🔗 RAG 2.0과 같은 검색 경로도 같은 스냅샷을 사용해야 합니다. 평가 도중 자료가 좋아지면 모델 자체의 차이를 보기 어려워집니다. 이 링크는 확인된 영어 자료입니다.
4. 동작별로 권한을 부여합니다
동작을 제안하는 것과 운영 시스템에 적용하는 것은 다른 권한입니다. 티켓 읽기, 초안 저장, 메시지 발송, 고객 정보 수정, 인프라 설정 변경에 같은 무제한 자격 증명을 사용해서는 안 됩니다.
모델은 동작을 제안하고 애플리케이션은 사용자, 데이터 범위, 인수, 승인 기록을 확인합니다. 영향이 작고 되돌릴 수 있는 동작은 제한 조건에서 자동화하고, 중요한 변경은 권한을 가진 사람이 검토합니다. 외부 문서와 도구 결과는 데이터로 다뤄 포함된 문장이 실행 권한을 얻지 않도록 합니다.
🔗 MCP와 AI 에이전트는 도구 연결을 표준화하지만 기업의 허가 정책을 정의하지는 않습니다. 읽기와 쓰기 범위, 실행 출처, 실패 후 보상 처리는 별도로 필요합니다.
고객지원 에이전트에는 읽기와 초안 저장 권한부터 제공하고 발송 경로를 따로 통제할 수 있습니다. 코딩 에이전트는 격리된 환경에서 수정과 테스트를 수행한 뒤 기존 코드 검토에 변경을 제출할 수 있습니다. 모델의 능력을 높이면서 권한은 유지할 수 있습니다.
5. 안전 개입도 운영 증거로 남깁니다
AWS 기술 소개는 새로운 안전 분류기가 더 많은 거절을 만들 수 있다고 설명합니다. 정당한 업무의 데이터 경로가 부적절한 경우와 허용 범위를 벗어난 요청은 다르게 처리해야 합니다.
모델 버전, 라우팅, 도구 동작, 개입 사유, 최종 검수를 기록합니다. 다른 모델로 전환해도 같은 데이터와 권한 정책을 적용하며 운영자에게 실제 경로를 보여줍니다. 제한 없는 fallback으로 완료율을 높이면 위험을 다른 엔드포인트로 옮기는 데 그칠 수 있습니다.
NIST AI Risk Management Framework의 Govern, Map, Measure, Manage를 참고해 용도마다 책임자, 검수 조건, 중단 조건을 정합니다. 모델 구매 시점뿐 아니라 중요한 변경 후에도 재평가하자는 실무 제안입니다.
| 관찰 지표 | 확인 질문 | 업그레이드 후 조치 |
|---|---|---|
| 검수 합격률 | 요구사항을 충족했나요? | 작업과 언어별로 분리 |
| 합격 건당 비용 | 재시도와 수정이 줄었나요? | 도구 요금과 검토 포함 |
| 권한 및 안전 개입 | 무엇이 차단되거나 사람에게 넘어갔나요? | 원인과 허용 대안 확인 |
| P95 완료 시간 | 혼잡할 때 얼마나 기다리나요? | 대기열, 도구, 검토 포함 |
6. AIOS에서 공통 통제를 설계합니다
기업은 대개 여러 모델을 사용합니다. 복잡한 코딩과 조사에는 최첨단 모델을 평가하고 고정 분류, 정해진 형식, 민감한 데이터에는 작은 모델이나 일반 프로그램을 검토할 수 있습니다. 🔗 대형 언어 모델의 원리를 이해해도 데이터 위치, 실행 주체, 검수 방식은 별도로 정해야 합니다.
이 글의 AIOS 설계안은 모델 등록, 데이터 경로, 권한, 일정, 비용 관찰을 공통화합니다. 작업에서 책임자, 모델 버전, 도구 범위, 검수 결과로 돌아갈 수 있어야 합니다. 실제 제품이 이 구성을 지원하는지는 항목별로 확인합니다.
AWS 제공 안내는 Bedrock과 Claude Platform on AWS 경로를 확인합니다. 인증, 지역, 데이터 경로, 기능, 청구 조건을 선택한 플랫폼 기준으로 평가해야 합니다.
🔗 GPU, NPU, TPU, LPU의 차이는 인프라 선택에 도움이 됩니다. 그러나 Opus 5.5를 기업 GPU에 내려받을 수 있는 모델로 설명해서는 안 됩니다. API와 자체 추론을 함께 관리하더라도 배포 방식은 구분해야 합니다.
7. 작업 묶음을 검증한 뒤 자동화를 확대합니다
반복 실행 가능한 사례를 만듭니다
일반 작업, 어려운 입력, 정보 누락, 거절해야 할 요청을 포함합니다. 검수와 실패 비용을 정의하고 같은 도구와 데이터로 비교합니다. 시연하기 좋은 성공 사례만 선택하지 않습니다.
섀도 모드에서 비교합니다
운영 시스템에 쓰지 않고 결과를 생성합니다. 합격률, 총비용, 검토 시간, 권한 위반을 비교해 바꿀 작업을 찾습니다. 일부 업무에는 기존 모델, 규칙, 사람을 유지하는 판단도 가능합니다.
되돌릴 수 있는 동작부터 엽니다
사용자, 데이터, 도구를 제한하고 기존 경로와 중단 수단을 유지합니다. 품질, 비용, 권한 기록이 합의된 조건을 충족할 때 범위를 확대하며 시작 후에도 계속 관찰합니다.
같은 작업을 더 쉽게 검수할 수 있는지, 합격 건당 총비용이 낮아지는지, 새로운 능력이 추적 가능한 권한 안에 있는지 확인합니다. 세 가지가 함께 개선될 때 확대할 근거를 갖출 수 있습니다.
기업 AI 모델, 인프라, 거버넌스에 관한 AI-Stack의 새 글을 구독해 주세요.
