OpenAI API 사용량 티어가 Build·Launch·Grow 셋으로 줄었습니다, Grow는 누적 500달러입니다 | DAKER 커뮤니티

OpenAI API로 서비스를 올리는 팀은 요금 한도보다 먼저 사용량 티어(RPM·TPM)에 막히는 경우가 많습니다. OpenAI는 2026년 10월 6일 개발자 Changelog에서 유료 API 사용량 티어를 다섯 단계에서 Build·Launch·Grow 세 단계로 단순화했다고 공지했습니다. 조직은 누적 크레딧 구매액이 각 임계값에 도달하면 자동으로 올라갑니다. 2026년 10월 14일 공식 Rate limits 가이드에서 확인한 자격·월 사용 한도·표준 RPM/TPM을 정리합니다.

Build·Launch·Grow 자격

공식 Rate limits 문서의 Usage tiers 표에 따르면 Free는 허용 지역 사용자에 월 100달러, Build는 누적 크레딧 구매 5달러에 월 사용 한도 500달러, Launch는 100달러 구매에 월 5,000달러, Grow는 500달러 구매에 월 200,000달러입니다. Changelog는 이전 다섯 티어를 세 티어로 줄였다고만 적고, 세부 숫자는 Rate limits 가이드를 보라고 안내합니다. 상위 티어로 가려면 콘솔 Settings → Organization → Limits의 Upgrade tier를 쓰라고 합니다.

Grow는 누적 API 결제 500달러면 최고 티어에 오를 수 있고, 월 사용 한도는 200,000달러로 안내됩니다.

표준 RPM·TPM과 실무 영향

Standard rate limits 표 기준 Build에서 Astra·Sol·Terra는 분당 요청 5,000·분당 토큰 1,000,000이고 Luna는 같은 RPM에 TPM 2,000,000입니다. Launch는 Astra·Sol·Terra 10,000 RPM·4,000,000 TPM, Luna 10,000·10,000,000입니다. Grow는 Astra·Sol·Terra 15,000·40,000,000, Luna 30,000·180,000,000입니다. Ultrafast 한도와는 다르다고 명시합니다. 한국에서 GPT-6.1 Sol·Astra로 에이전트를 돌리는 팀은 Build에 머물면 TPM 100만에서 일찍 막힐 수 있어, 누적 결제 100달러·500달러 구간을 미리 계획하는 편이 안전합니다.

공식 출처와 다음 확인

원문은 https://developers.openai.com/api/docs/changelog의 October 6 항목과 https://developers.openai.com/api/docs/guides/rate-limits입니다. Spend alert와 Hard spend limit은 티어 월 한도와 별개 제어로, Hard는 도달 시 429를 돌려줍니다. 트래픽이 분당 100만 입력 토큰을 넘긴 뒤에는 15분마다 50% 이상 올리지 말라는 램프 가이드도 같은 문서에 있습니다. 조직 콘솔에서 현재 티어 이름과 모델별 RPM/TPM이 Build·Launch·Grow 표와 일치하는지 먼저 확인하면 됩니다.

한도와 에러 코드 운영

Rate limits는 조직·프로젝트 단위이며 모델마다 다릅니다. 긴 컨텍스트 모델은 별도 long-context 한도가 콘솔에 표시될 수 있고, 일부 모델 패밀리는 shared limit로 토큰을 같이 씁니다. 벡터 스토어 파일 업로드는 스토어 ID당 분당 300요청 한도가 있다고 적혀 있습니다. 빠른 트래픽 증가는 429 slow_down, 모델 과부하는 503 server_is_overloaded로 구분되며 Retry-After가 있으면 그 이상 기다린 뒤 재시도하라고 안내합니다. SDK는 적격 429·503을 자동 재시도하지만, 서버가 요청한 지연이 SDK 설정보다 길면 재시도를 멈추고 요청을 미루라고 합니다.

한국 스타트업이 Build에서 Launch·Grow로 올라갈 때는 누적 결제액만 보지 말고, 콘솔의 모델별 RPM/TPM이 표와 같은지, Ultrafast를 쓰는 Sol 트래픽이 Standard 표와 섞여 오해되지 않는지 함께 확인해야 합니다. Batch API는 동기 한도와 별도 큐 한도이므로 대량 야간 작업은 Batch로 빼 두는 구성이 Changelog·가이드 모두에서 권장되는 패턴입니다. 월 사용 한도(티어)와 조직이 설정하는 Hard spend limit을 혼동하면 429 원인을 잘못 짚을 수 있으니, 장애 런북에 두 값을 나란히 적어 두는 편이 좋습니다.

티어를 Grow로 올린 뒤 Sol·Astra 실측 한도가 어떻게 변했는지 공유해 주시면 다음에 표로 모아 보겠습니다.