Claude Opus 5.5, 캐시와 작업량으로 비용을 낮추다

발표의 핵심: 단가 인하와 사용량 감소를 함께 주장

Anthropic은 9월 22일 Claude Opus 5.5 공식 발표에서 새로운 5.5 제품군의 첫 모델을 공개했다. 회사는 다수 업무에서 Fable 5.1 수준의 성능을 제공하며, 기본 설정의 일반적인 워크로드에서 Opus 5보다 비용이 40% 적게 든다고 설명했다. 이 수치는 회사 내부 평가에 기반한 주장이고 고객별 절감 보장은 아니다.

확인 가능한 가격 변화는 더 구체적이다. 100만 토큰당 입력 가격은 5달러에서 4달러, 출력은 25달러에서 20달러로 내려간다. 캐시 읽기는 0.50달러에서 0.20달러다. 입력·출력의 인하율은 20%지만 캐시 읽기는 60%이므로, 이전 대화와 저장소 문맥을 많이 재사용하는 에이전트는 비용 구조가 다르게 바뀔 수 있다.

표는 공식 발표에 실린 일반 가격이며 세금·별도 서비스 비용을 합산한 견적이 아니다. Fast mode는 별도 단가가 적용된다. 최신 조건은 Claude 가격 안내와 모델 문서를 확인할 필요가 있다.

왜 캐시가 중요한가: 같은 저장소를 다시 읽는 비용

코딩 에이전트는 답변을 한 번 생성하고 끝나지 않는다. 파일을 읽고 수정하며 테스트 결과를 다시 해석한다. 긴 공통 문맥이 반복되는 구조에서는 새 입력의 단가만큼 캐시 재사용률도 중요하다. 하지만 프롬프트 앞부분을 자주 바꾸거나 도구 출력을 무질서하게 붙이면 기대했던 캐시 이점이 줄 수 있다.

따라서 40%라는 전체 절감 주장은 가격표의 20% 인하와 모순되는 것이 아니다. 캐시 구성과 작업당 토큰 수 감소가 더해질 수 있기 때문이다. 반대로 캐시가 거의 없는 짧은 호출에서는 같은 절감 폭을 기대하기 어렵다. 실제 비용을 비교할 때는 새 입력, 캐시 쓰기, 캐시 읽기, 출력 사용량을 분리해 보아야 한다.

또 하나의 변수는 에이전트가 같은 문제를 몇 단계 만에 해결하는가다. 공식 발표는 호출과 토큰을 줄인 고객 사례를 소개하지만, 성공 사례만으로 전체 작업 분포를 알 수는 없다. SWE-2의 비용 경쟁 분석에서처럼 평균 호출비보다 재작업 없이 끝난 업무 한 건의 비용이 더 실용적인 지표다.

벤치마크를 읽을 때: 추론 강도와 대체 모델까지 확인

Anthropic의 표에는 Terminal-Bench 4.0에서 Opus 5.5의 66.4%가 제시된다. 그러나 각주는 일반적인 최대 추론 설정과 달리 이 항목에 xhigh를 사용했고, 모델별 비교 수치의 설정도 다름을 밝힌다. 회사가 표시한 표준오차 역시 함께 고려해야 한다. 점수의 소수점 차이만으로 현장 우위를 단정하는 방식은 적절하지 않다.

특히 공식 발표는 보호 장치가 개입한 일부 사이버보안 과제를 Opus 4.8, 생물학과 프런티어 LLM 개발 과제를 Opus 5로 대체해 수행했다고 명시한다. 이는 평가 환경의 구성 요소다. 한 모델이 모든 과제를 동일한 방식으로 풀었다고 요약하면 독자에게 다른 인상을 준다. 연구·금융·일반 코딩처럼 업무 유형에 따라 평가 방법을 다시 읽어야 한다.

성능 경쟁은 OpenAI와의 최고점 비교만이 아니다. 이전 모델을 계속 쓰는 비용, 다른 모델로 라우팅하는 비용, 자체 호스팅의 유지보수 비용도 비교 대상이다. Real-SWE와 사내 코드 평가가 중요한 이유는 공개 문제를 잘 푸는 능력과 기업의 비공개 의존성을 이해하는 능력이 같지 않기 때문이다.

안전성 개선이 권한 확대를 의미하지는 않는다

Anthropic은 행동 감사와 프롬프트 주입 방어가 개선됐다고 설명하고 Opus 5.5 시스템 카드를 제시했다. 이는 검토할 중요한 자료지만, 모델이 외부 문서에 포함된 모든 악성 지시를 거절한다는 보증은 아니다. 모델의 확률적 방어와 시스템의 확정적인 접근 제어는 다른 역할을 맡는다.

한국 개발팀은 읽기 전용 분석에서 시작해 코드 수정, 테스트 실행, 외부 반영을 단계별 권한으로 나누는 편이 좋다. 에이전트 보안과 샌드박스 분석처럼, 비밀 값과 외부 발송 권한을 모델의 자연어 판단에만 맡기지 않는 설계가 필요하다.

실제 전환 시험은 동일한 저장소 스냅샷, 동일한 테스트, 동일한 최대 실행 예산으로 진행해야 한다. 변경이 작아 보이는 버그 수정뿐 아니라 오래된 라이브러리, 한국어 주석, 다중 서비스 호출을 포함한 사례를 넣는다. 비용이 줄어도 결함이 늘면 출시하지 않고, 통과율이 같아도 검토 시간이 늘면 그 이유를 분석한다. 가격 개선을 제품 생산성으로 바꾸는 마지막 단계는 이 운영 검증이다.

FAQ

모든 토큰 가격이 40% 내려갔나?

아니다. 입력·출력은 20%, 캐시 읽기는 60% 인하다. 40%는 회사가 제시한 일반 워크로드 비용 감소 주장이다.

Fast mode도 같은 가격인가?

아니다. 공식 발표는 입력 8달러, 출력 40달러의 별도 100만 토큰당 가격을 안내한다.

벤치마크에서 이겼으니 사내 코드도 더 잘 고치나?

그렇게 단정할 수 없다. 사내 의존성, 테스트 품질, 추론 설정과 도구 환경을 맞춘 별도 평가가 필요하다.

안전성 향상은 사람 검토를 없애도 된다는 뜻인가?

아니다. 외부 반영과 민감한 데이터 접근은 모델 성능과 별개로 권한 통제가 필요하다.

가장 먼저 계측할 지표는 무엇인가?

캐시별 토큰 사용량, 성공 건당 비용, 재시도 횟수, 사람의 검토·수정 시간을 함께 기록하면 좋다.