Claude Sonnet 5 가격 변경: 8월 31일 전후 API 비용을 다시 계산해야 하는 이유

Claude API를 제품에 붙여 쓰는 팀이라면 2026년 8월 31일을 비용표에 표시해 둬야 한다. Anthropic 공식 가격 문서에는 Claude Sonnet 5의 소개 가격이 2026년 8월 31일까지 입력 100만 토큰당 2달러, 출력 100만 토큰당 10달러로 적용되고, 2026년 9월 1일부터는 입력 3달러, 출력 15달러로 바뀐다고 안내되어 있다. 숫자만 보면 단순히 50% 인상이다. 하지만 실제 청구서에서는 캐시 쓰기, 캐시 히트, 출력 비중, 에이전트 루프 횟수 때문에 체감 폭이 다르게 나온다.

이번 글의 검색 의도는 명확하다. “Claude Sonnet 5 가격”, “Claude API 비용”, “Sonnet 5 9월 가격 변경”을 찾는 개발자는 마케팅 문구가 아니라 배포 전에 바꿔야 할 계산식과 운영 체크리스트가 필요하다. 아래 내용은 공식 가격표를 기준으로, 실무 개발팀이 바로 점검할 수 있는 항목만 정리했다.

무엇이 바뀌는가: 입력 2달러에서 3달러, 출력 10달러에서 15달러

Anthropic 가격표 기준 Claude Sonnet 5는 2026년 8월 31일까지 소개 가격을 적용한다. 입력 토큰은 100만 토큰당 2달러, 출력 토큰은 100만 토큰당 10달러다. 2026년 9월 1일부터는 표준 가격인 입력 3달러, 출력 15달러가 된다. 입력과 출력 모두 1.5배다.

여기서 중요한 점은 “출력 토큰이 더 비싸다”는 구조다. 많은 팀이 비용을 계산할 때 사용자 질문 길이만 본다. 그러나 실제 청구서에서 큰 비중을 차지하는 것은 모델이 생성한 답변, 도구 호출 계획, 코드 패치 설명, 테스트 결과 요약처럼 출력 쪽인 경우가 많다. 고객 지원 챗봇처럼 짧게 답하는 서비스는 입력 비중이 높을 수 있지만, 코드 생성·리포트 작성·문서 요약 서비스는 출력 비중이 쉽게 커진다.

예를 들어 월간 입력 2억 토큰, 출력 6천만 토큰을 쓰는 서비스를 보자. 소개 가격에서는 입력 400달러, 출력 600달러로 총 1,000달러다. 표준 가격으로 바뀌면 입력 600달러, 출력 900달러로 총 1,500달러가 된다. 단순하지만 무시하기 어려운 차이다. 특히 여러 제품 기능이 같은 워크스페이스나 같은 결제 계정에 묶여 있으면 어느 기능이 비용 증가를 만든 것인지 늦게 발견하기 쉽다.

왜 개발팀은 지금 계산해야 하는가

가격 변경은 재무팀만의 일이 아니다. 모델 비용은 제품 아키텍처와 직접 연결된다. 한 번의 요청에서 검색 결과 20개를 통째로 넣는지, 요약한 상위 5개만 넣는지에 따라 입력 토큰이 달라진다. 답변을 2,000자로 강제하는지, 필요한 경우에만 길게 쓰도록 하는지에 따라 출력 토큰이 달라진다. 같은 기능이라도 프롬프트 구조가 다르면 월 비용이 완전히 달라진다.

또 하나의 이유는 캐시다. Anthropic 가격표는 기본 입력, 5분 캐시 쓰기, 1시간 캐시 쓰기, 캐시 히트, 출력 가격을 따로 보여준다. 반복되는 시스템 프롬프트와 문서 묶음을 캐시에 태우면 비용과 지연시간을 줄일 수 있다. 반대로 사용자별로 매번 조금씩 다른 값을 프롬프트 앞부분에 섞어 넣으면 캐시가 거의 맞지 않는다. 비용 최적화는 “싼 모델로 바꾸기”보다 “같은 모델을 덜 낭비하게 쓰기”에서 먼저 나온다.

9월 1일 이후 가격이 적용되기 전에 해야 할 일은 간단하다. 현재 사용량을 입력·출력·캐시 쓰기·캐시 히트로 분리하고, 기능별로 어떤 요청이 비용을 만드는지 확인해야 한다. 이 작업은 하루 만에 끝날 수도 있지만, 로그가 없으면 몇 주가 걸린다. 그래서 지금부터 계측을 시작해야 한다.

비용 계산 예시: 채팅, 문서 요약, 코딩 에이전트는 다르게 본다

첫 번째 유형은 일반 채팅형 기능이다. 사용자가 짧게 질문하고 모델이 500~1,000자 정도 답한다. 이 경우 출력 비용이 핵심이다. 답변 길이를 제한하거나, “모르면 확인 질문 1개만 한다” 같은 정책을 넣으면 비용과 품질을 함께 잡을 수 있다.

두 번째 유형은 문서 요약이다. 계약서, 리서치 보고서, 회의록처럼 긴 입력을 넣고 짧은 결과를 받는다. 이 경우 입력 비용과 캐시 전략이 중요하다. 같은 문서를 여러 번 물어보는 구조라면 문서 본문을 안정적인 prefix로 두고 질문만 뒤에 붙이는 편이 좋다. 질문을 앞에 두고 문서를 뒤에 붙이면 캐시 히트율이 떨어질 수 있다.

세 번째 유형은 코딩 에이전트다. 코드베이스 요약, 파일 목록, 테스트 로그, 이전 대화가 계속 누적된다. 입력과 출력이 모두 커진다. 특히 에이전트가 여러 번 계획을 세우고, 도구를 호출하고, 실패한 테스트를 다시 읽으면 토큰이 빠르게 늘어난다. 이 영역에서는 모델 가격보다 작업 단위 분해가 더 중요하다. “전체 레포를 읽고 알아서 고쳐줘”보다 “이 파일과 이 테스트를 기준으로 원인을 좁혀줘”가 비용과 성공률 모두에서 낫다.

운영 로그에 반드시 남겨야 할 필드

가격 변경에 대응하려면 로그 필드가 먼저다. 최소한 다음 값은 요청 단위로 남겨야 한다.

• 기능 이름: 예를 들어 support-chat, doc-summary, code-review처럼 구분한다.
• 모델 이름과 버전: Sonnet 5인지, Opus 계열인지, 하위 모델인지 기록한다.
• 입력 토큰, 출력 토큰: 합계만 남기면 원인 분석이 어렵다.
• 캐시 쓰기 토큰, 캐시 히트 토큰: 캐시가 실제로 돈을 아끼는지 확인한다.
• 사용자 또는 테넌트 단위 비용: B2B 서비스라면 고객별 원가가 필요하다.
• 요청 성공 여부와 재시도 횟수: 실패한 요청도 비용을 만든다.
• 지연시간: 비용을 줄였는데 응답 시간이 나빠졌다면 제품 경험이 흔들린다.

이 필드를 저장하면 단순한 비용 절감 이상의 일을 할 수 있다. 어떤 고객이 비정상적으로 긴 문서를 계속 올리는지, 어떤 프롬프트 변경 이후 출력 길이가 늘었는지, 캐시 히트율이 떨어진 배포가 언제였는지 추적할 수 있다. 가격 인상보다 더 위험한 것은 원인을 모르는 비용 증가다.

프롬프트와 제품 정책을 같이 손봐야 한다

비용 최적화를 프롬프트 한 줄로 해결하려 하면 오래 못 간다. 제품 정책과 함께 설계해야 한다. 예를 들어 문서 요약 기능에서는 업로드 원문 전체를 매번 보내지 말고, 문서 ID 기준으로 전처리 요약을 저장한 뒤 질문에 맞는 부분만 넣는 구조가 낫다. 고객 지원 챗봇에서는 검색 결과를 무조건 10개 넣기보다, 점수 기준을 통과한 문서만 넣고 모델에게 “근거가 부족하면 답하지 말라”고 지시해야 한다.

코딩 에이전트에서는 작업 범위를 좁히는 UI가 도움이 된다. 사용자가 파일, 에러 로그, 재현 절차를 선택하도록 만들면 모델이 불필요한 컨텍스트를 읽지 않는다. 운영자가 자주 쓰는 작업은 템플릿화하고, 템플릿의 고정 부분을 캐시 가능한 prefix로 둔다. 이렇게 해야 가격 변경이 와도 비용을 예측할 수 있다.

실행 체크리스트

• Anthropic 공식 가격표에서 현재 사용하는 모델의 입력·출력·캐시 가격을 확인한다.
• 2026년 8월 31일 이전 가격과 9월 1일 이후 가격으로 월 비용을 각각 계산한다.
• 기능별 입력 토큰, 출력 토큰, 캐시 쓰기, 캐시 히트 로그를 분리한다.
• 출력이 긴 기능에는 최대 길이, 요약 단계, 후속 질문 유도 정책을 넣는다.
• 긴 문서를 반복 사용하는 기능은 안정적인 prefix와 prompt caching 구조를 점검한다.
• 코딩 에이전트는 전체 레포 입력을 줄이고 작업 단위, 파일 범위, 테스트 범위를 명확히 한다.
• 가격 변경 전후 2주 동안 기능별 원가 그래프를 따로 본다.
• 출처: Anthropic pricing 문서 https://platform.claude.com/docs/en/about-claude/pricing.