Claude API rate limits 상향: Sonnet·Haiku 처리량이 Opus와 맞춰졌다
Claude API rate limits 공개, 핵심은 Sonnet과 Haiku의 API 처리량 기준이 Opus와 같아진 변화였다
한눈에 보기
- 발표 내용: Anthropic이 Claude API 전반의 rate limits를 상향하고 usage tier를 정리했다.
- 핵심 변화: Claude Sonnet과 Claude Haiku의 rate limits가 모든 usage tier에서 Claude Opus와 같아졌다.
- 한 줄 결론: Claude API로 제품을 운영하는 팀에게는 모델 선택과 스케일링 계산이 조금 더 단순해진 업데이트다.
이번 발표, 뭐가 나왔나
Anthropic은 2026년 6월 26일 Claude Platform release notes를 통해 Claude API의 rate limits 상향을 공지했다. 핵심은 Claude Sonnet과 Claude Haiku의 rate limits가 모든 usage tier에서 Claude Opus와 같아졌다는 점이다. 동시에 usage tier는 Start, Build, Scale 세 단계로 통합됐다.
공식 설명에 따르면 대부분의 조직은 더 높은 tier로 이동하고, 이전보다 낮은 limits를 받는 조직은 없으며, 별도 조치는 필요 없다. 현재 tier와 limits는 Claude Console에서 확인할 수 있다.
핵심 변화 3가지
1. Sonnet·Haiku 처리량 기준이 Opus와 같아졌다
이전에는 모델별로 처리량 한도를 따로 따져봐야 하는 부담이 컸다. 이번 업데이트 이후에는 Claude Sonnet과 Claude Haiku의 rate limits가 Claude Opus와 같은 기준으로 맞춰졌다.
개발자 입장에서는 꽤 실용적인 변화다. 빠른 응답이 필요한 곳에는 Haiku, 균형형 작업에는 Sonnet, 더 무거운 작업에는 Opus를 쓰는 식으로 모델을 나누더라도, 기본 처리량 계산이 덜 복잡해진다.
2. usage tier가 Start, Build, Scale로 정리됐다
Anthropic은 usage tier를 Start, Build, Scale 세 단계로 통합했다. 각 tier에는 월별 spend cap도 붙어 있다. 공식 문서 기준 Start는 500달러, Build는 1,000달러, Scale은 200,000달러다.
이 변화는 단순히 이름만 바뀐 것이 아니다. API를 쓰는 팀이 지금 어느 규모에 있는지, 다음 단계로 가려면 어떤 limits가 필요한지 확인하기 쉬워진다.
3. RPM·ITPM·OTPM 기준을 봐야 한다
Claude API rate limits는 요청 수만 보는 구조가 아니다. 공식 문서에는 Messages API의 rate limits가 RPM, ITPM, OTPM으로 측정된다고 설명돼 있다. 각각 분당 요청 수, 분당 입력 토큰 수, 분당 출력 토큰 수다.
예를 들어 Start tier에서 Opus 4.x, Sonnet 4.x, Haiku 4.5는 1,000 RPM, 2,000,000 ITPM, 400,000 OTPM으로 표기된다. Build tier는 5,000 RPM, 5,000,000 ITPM, 1,000,000 OTPM, Scale tier는 10,000 RPM, 10,000,000 ITPM, 2,000,000 OTPM이다.
그래서 실제로 뭐가 달라지나
일반 사용자 기준
일반 사용자가 Claude 앱에서 바로 체감할 업데이트는 아니다. 이번 내용은 Claude API를 쓰는 개발자와 조직을 위한 플랫폼 변경에 가깝다. 다만 기업 서비스 뒤에서 Claude API를 쓰고 있다면, 더 안정적인 처리량 확보로 간접적인 품질 개선이 이어질 수 있다.
개발자 기준
개발자에게는 모델별 rate limit 계산이 단순해진다. Sonnet이나 Haiku를 대량 호출하는 서비스라면 기존 한도 때문에 생기던 병목이 줄어들 수 있다. 다만 실제 처리량은 프롬프트 길이, 출력 길이, 캐시 사용 여부, 워크스페이스 limits에 따라 달라지므로 직접 모니터링이 필요하다.
창업자/업무 활용 기준
AI 기능을 제품에 붙이는 팀이라면 tier와 spend cap을 같이 봐야 한다. Start, Build, Scale로 이름이 단순해진 건 좋지만, 월별 spend cap에 닿으면 API 사용이 멈출 수 있다. 제품 출시 전에는 예상 RPM, 입력 토큰, 출력 토큰, 월 예산을 같이 잡는 편이 안전하다.
좋은 점
- Sonnet과 Haiku의 rate limits가 Opus와 맞춰져 모델 선택 계산이 단순해졌다.
- Start, Build, Scale 세 단계로 usage tier 구조가 이해하기 쉬워졌다.
- 대부분 조직은 더 높은 tier로 이동하고 별도 조치가 필요 없다고 공지됐다.
아쉬운 점
- 실제 체감 처리량은 워크로드마다 달라 공식 수치만으로 속도 개선을 단정하기 어렵다.
- monthly spend cap에 닿으면 API 사용이 멈출 수 있어 비용 계획이 여전히 중요하다.
- 워크스페이스별 제한, 캐시 효율, 모델별 동시 사용 방식은 운영자가 직접 확인해야 한다.
내 생각
이번 업데이트는 화려한 모델 공개는 아니지만, API를 실제 서비스에 붙이는 팀에게는 더 현실적인 뉴스다. 모델 성능이 좋아도 rate limit이 낮으면 제품에서는 바로 병목이 생긴다. 특히 고객 요청이 몰리는 시간대에는 RPM보다 ITPM이나 OTPM이 먼저 막히는 경우도 생길 수 있다.
좋게 보면 Anthropic이 Claude API를 더 제품 운영 친화적으로 다듬는 중이다. Sonnet과 Haiku limits를 Opus와 맞춘 것도 그 방향이다. 가볍고 빠른 모델을 많이 호출하는 구조에서 한도 때문에 설계를 우회해야 하는 부담이 줄어들 수 있다.
다만 이것만으로 비용 문제가 사라지는 건 아니다. tier별 spend cap과 토큰 사용량을 함께 봐야 한다. 결국 개발팀이 챙겨야 할 질문은 "어떤 모델이 제일 좋나"가 아니라 "우리 제품의 피크 시간에 어떤 모델 조합과 캐시 전략이 버티나"에 가깝다.
결론
Claude API rate limits 상향은 Sonnet과 Haiku를 많이 쓰는 팀에게 특히 의미 있는 업데이트다. Start, Build, Scale로 tier가 정리되고, Opus와 같은 처리량 기준이 적용되면서 API 운영 계산이 더 명확해졌다.
한 줄 평: "모델 성능 경쟁만큼, API 처리량과 운영 한도 경쟁도 중요해지고 있다."
Claude API를 제품에 붙인다면 가장 먼저 막히는 부분이 RPM인지, 입력 토큰인지, 출력 토큰인지 댓글로 남겨줘도 좋겠다.