2026년 GPT Image 2 속도 제한: 개발자가 알아야 할 것

안녕하세요, 여러분. Dora입니다. 3인 제품팀에서 일하는 친구가 5월 초에 GPT Image 2 기능을 출시했습니다. 소프트 런칭으로 약 200명의 사용자를 초대했는데, 90분 만에 기능이 망가졌습니다 — 모델이 실패한 게 아니라, Tier 2였던 상황에서 첫날 오후에 그 사용자들(평균 3~5장씩 이미지를 생성)의 버스트 트래픽이 분당 20장(IPM) 한도를 초과했기 때문입니다.

GPT Image 2 속도 제한의 문제가 바로 이겁니다: 제약이 되기 전까지는 제약처럼 느껴지지 않는다는 거죠. 문서 표에 나온 Tier 번호는 추상적으로 보입니다. 하지만 큐 깊이가 해당 Tier가 분당 처리할 수 있는 양을 초과하는 순간 구체적인 현실이 됩니다. 이 글은 GPT Image 2를 실제 제품에 도입하는 팀을 위한 것이며, 단일 프롬프트를 벤치마킹하는 분들을 위한 게 아닙니다 — OpenAI 이미지 API 속도 제한은 로드 테스트와 개발 환경에서 다르게 나타납니다.

면책 고지: 저는 WaveSpeedAI에서 에이전트 및 이미지 인프라에 대해 글을 씁니다. GPT Image 2가 워크플로우에 적합한지에 대한 모델 평가 질문은 이전 포스트에서 다뤘습니다. 이 글은 여러분이 이미 적합하다고 결정했고, 이제 실제 트래픽을 버텨낼 수 있는지 파악하는 단계라고 가정합니다.

2026년 GPT Image 2 속도 제한 현황

OpenAI 속도 제한 문서와 GPT Image 2 모델 페이지에 따르면, 이 모델은 두 가지 차원으로 측정됩니다: TPM(분당 토큰 수, 이미지 입출력 및 텍스트 토큰 포함)과 IPM(분당 이미지 수, 대부분의 워크플로우에서 더 엄격한 한계).

Tier별 IPM 및 TPM 구조

다음은 2026년 4월 기준으로 공개된 GPT Image 2 제한입니다. Free Tier: 지원되지 않음.

Tier	TPM	IPM	대략적인 자격 요건
Tier 1	100,000	5	$5 결제
Tier 2	250,000	20	$50 결제 + 7일
Tier 3	800,000	50	$100 결제 + 7일
Tier 4	3,000,000	150	$250 결제 + 14일
Tier 5	8,000,000	250	$1,000 결제 + 30일

두 가지 사항을 주목하세요. Tier는 프로젝트나 API 키가 아닌 조직 단위입니다 — 모든 프로젝트가 동일한 GPT Image 2 IPM 예산을 공유합니다. OpenAI는 사전 고지 없이 이 수치를 변경할 수 있으므로, 위 표는 계획 기준선입니다. 아키텍처 결정을 내리기 전에 계정의 제한 대시보드에서 반드시 확인하세요.

이 제한들이 실제로 의미하는 바

Tier 1의 5 IPM 한도는 지속적으로 12초당 이미지 1장입니다. 개인 개발과 소규모 프로토타입은 커버됩니다. 하지만 적당한 동시 접속이 있는 퍼블릭 기능은 커버되지 않습니다. Tier 5의 250 IPM 한도는 높아 보이지만 계산해보면: 250장/분 × 60분 = 시간당 15,000장. 런칭 트윗으로 첫 시간에 5,000명이 가입하고 각 사용자가 이미지 1장을 생성한다면, 완벽한 분산을 가정했을 때(실제로는 절대 그렇지 않지만) 이미 용량의 33%를 사용하는 겁니다.

더 심각한 실패 모드는 버스티(bursty) 트래픽입니다. OpenAI 문서는 제한이 1분보다 짧은 윈도우에서 적용된다고 명시합니다. 20 IPM이 첫 1초에 20장을 보내고 59초 동안 쉬어도 된다는 의미가 아닙니다. 2초 안에 5장을 보내면 분당 평균이 한도를 훨씬 밑돌더라도 스로틀링됩니다.

속도 제한이 프로덕션 계획에 미치는 영향

모델 평가에는 2주가 걸렸습니다. 실제 부하 하에서 운영되도록 인프라를 구축하는 데는 최소 2주가 더 필요합니다. 대부분의 팀이 이를 과소평가합니다.

큐 설계, 배칭, 재시도 결정

세 가지 레이어가 쌓입니다. 대부분의 팀은 두 가지만 구축합니다.

첫째: 클라이언트 측 속도 제한. 동시 진행 중인 요청을 Tier IPM의 약 80%로 제한하고, 분 전체에 걸쳐 분산시킵니다. Tier 3(50 IPM)이라면 지속적으로 약 40개의 동시 이미지를 유지하고, 그 뒤에 큐를 두는 방식입니다.

둘째: 지수 백오프(exponential backoff)를 사용한 재시도. OpenAI 쿡북 권장사항은 429 응답에 대해 지터(jitter)가 있는 지수 백오프를 사용하라고 합니다. 표준 패턴: 랜덤 지터와 함께 1초, 2초, 4초, 8초 대기, 6회 시도 후 중단. 필수입니다. 429에 대한 타이트 루프 재시도는 계정 플래그 처리를 받을 수 있습니다.

셋째 — 팀들이 건너뛰는 부분 — 는 요청 형태 제어입니다. 모든 이미지에 quality: high가 필요한 건 아닙니다. 모든 워크플로우에 동기 응답이 필요한 건 아닙니다. OpenAI의 Batch API는 별도의 쿼터 풀과 50% 할인 가격, 24시간 SLA를 제공합니다. 야간 썸네일 재생성에는 배치가 적합한 도구입니다. 사용자 대면 단일 생성에는 적합하지 않습니다. 대부분의 팀은 두 가지를 혼합해서 같은 방식으로 라우팅합니다. “속도 제한이 문제다”와 “속도 제한은 배경 조건이다”의 차이는 비동기 작업을 동기 IPM 풀에서 분리해 라우팅했는지 여부입니다.

처리 시간과 스파이크에 대한 팀 기대치

이건 아무도 문서화하지 않는 부분입니다. 모델이 아닌 제품팀 및 운영팀과의 대화입니다.

Tier 2(20 IPM)에서 p50 지연 시간은 대략 모델 바운드입니다 — 품질과 추론 모드에 따라 8~25초. 하지만 지속적인 부하 하에서 p99는 큐 대기 시간을 포함합니다. 분당 21번째 요청을 제출한 사용자는 12초가 아닌 60초를 기다립니다. “이미지는 15초 안에 생성됩니다”는 다른 사람이 생성 중이 아닐 때만 사실입니다.

마케팅 캠페인과 런칭의 경우, 계획 질문은 평균 처리량이 아니라 피크 분당 처리량입니다. 캠페인 라이브 후 4시간 동안 평소의 3배 트래픽을 예상한다면, Tier가 그 3배를 흡수할 수 있어야 합니다. 그렇지 않다면 사전 생성하거나 폴백이 필요합니다. 런칭 전에 하나를 선택하세요. 런칭 중에 선택하는 건 항상 잘못됩니다.

속도 제한이 제품 문제가 되는 시점

GPT Image 2 처리량이 인프라 문제에서 제품 문제로 전환되는 임계점이 있습니다. 신호는 일관됩니다: 재시도 큐가 사용자에게 보일 만큼 깊어지면, 인프라 문제가 아닌 제품 문제입니다.

이미 넘어선 징후:

사용자 대면 지연 시간 변동이 허용 범위를 초과할 때 (예: 요청의 80%는 20초 내에 완료되지만, 5%는 버스트 뒤에 큐잉되어 90초 이상 걸림)
Tier 하에 머물기 위해 기능 범위를 줄일 때 — “UI에 배치 생성 없음”은 명백한 신호
단일 악성 사용자나 인기 공유 링크 하나가 분당 용량을 포화시켜 다른 모든 사람에게 영향을 줄 때
Tier 5 신청이 30일 이상 걸리는데 런칭은 14일 후일 때

이에 도달했을 때의 솔직한 답변: 단일 제공업체는 운영 상한선이 있습니다. Tier 5도 상한선입니다. 심각한 볼륨을 운영하는 팀은 사전 생성 및 캐싱, 중요하지 않은 경로에 Tier 압력을 낮추는 대안 모델 라우팅, 또는 제공업체 간 용량을 풀링하는 레이어를 통한 집계/폴백을 고려하기 시작합니다. 각각 엔지니어링 표면을 추가합니다. 각각은 퍼블릭 지연 시간 인시던트보다 저렴합니다.

이 섹션을 쓰면서 잠시 멈췄습니다. WaveSpeed 프레임이 여기서 쉽게 끼어들 수 있기 때문입니다. 솔직한 의견: 집계는 여러 옵션 중 하나입니다. 사전 생성과 캐싱은 사람들이 인정하는 것보다 더 많은 문제를 해결하는 경우가 많고, 비용도 적습니다. 멀티 프로바이더 레이어가 필요한지는 워크로드가 실제로 Tier 5를 초과하는지, 아니면 아직 최적화하지 않은 건지에 달려 있습니다. 아키텍처를 구성하기 전에 진단하세요.

스케일업 전 빌더가 모니터링해야 할 것들

세 가지, 이 순서대로.

평균이 아닌 피크 시점의 실제 IPM. 모든 응답에서 x-ratelimit-remaining-images와 x-ratelimit-remaining-tokens 헤더를 로깅하세요. 평균이 아닌 최솟값을 모니터링하세요. 피크 분당 잔여량이 Tier의 20% 아래로 떨어지면, 트래픽 스파이크 하나로 429가 발생합니다.

실패 모드 분포. 429를 총 요청의 비율로, 시간대별로 분류해 추적하세요. 0.5% 429 비율은 괜찮아 보이지만 마케팅 이메일 발송 시간대에 8%라는 걸 발견할 때까지만입니다. 시간 버킷 메트릭은 이를 포착합니다; 집계 메트릭은 그렇지 않습니다.

Tier 업그레이드까지 걸리는 시간. Tier 5는 $1,000의 지출과 30일의 계정 기간이 필요합니다. 예측이 2개월 내에 Tier 5 필요량에 도달한다면, 지금 지출을 시작하거나 스케일 시작 후 첫 30일이 용량 제한 상태가 될 것을 받아들이세요.

여기서 제 데이터는 끝납니다 — 저는 Tier 2와 Tier 3에서 GPT Image 2를 운영해봤지만 Tier 5는 아닙니다. Tier 5 팀들은 다시 역학이 변한다고 보고합니다. 한계가 IPM이 아닌 요청 형태 효율성이 되는 지점에서요.

FAQ

Tier별 GPT Image 2 속도 제한은 어떻게 되나요?

2026년 4월 기준 OpenAI 문서에 따르면: Tier 1은 100,000 TPM / 5 IPM, Tier 2는 250,000 / 20, Tier 3는 800,000 / 50, Tier 4는 3,000,000 / 150, Tier 5는 8,000,000 / 250입니다. Free Tier는 지원되지 않습니다. 제한은 모든 프로젝트에서 공유되는 조직 단위입니다. OpenAI가 이를 변경할 수 있으므로 계정 대시보드에서 확인하세요.

속도 제한이 대규모 이미지 워크플로우에 어떤 영향을 미치나요?

세 가지: 큐 설계(OpenAI 이전에 클라이언트 측 제한이 필요), 지연 시간 분포(p99는 모델 시간뿐 아니라 큐 대기 시간 포함), 로드맵(흡수할 수 없는 스파이크를 유발하는 기능을 연기할 수 있음). 일반적인 패턴: 팀들이 평균 부하에 맞게 구축한 다음, 피크 부하가 사용자 경험을 결정한다는 걸 발견합니다.

대용량 기능 런칭 전에 팀이 해야 할 일은 무엇인가요?

4단계. 일일 평균이 아닌 피크 분당 생성 볼륨을 추정하세요. Tier가 약 30% 여유를 두고 이를 커버하는지 확인하세요. 지터와 서킷 브레이커가 있는 지수 백오프를 구현하세요. 용량을 소진했을 경우의 폴백을 결정하세요 — 사전 생성, 대안 모델, 또는 우아한 성능 저하. 계획하지 않은 실패 모드가 런칭 당일에는 고칠 수 없는 것입니다.

운영 측면에서 하나의 제공업체로는 충분하지 않은 경우는 언제인가요?

피크 분당 수요가 지속적으로 단일 제공업체 Tier 5 용량을 초과할 때, SLA가 단일 제공업체의 중단 시간을 허용할 수 없을 때, 또는 최적화에도 불구하고 큐 대기로 인한 지연 시간 변동이 사용자에게 계속 보일 때입니다. 대부분의 팀은 이에 도달하지 않습니다. 도달하는 팀들 — 주로 바이럴 패턴의 소비자 제품이나 엄격한 SLA의 엔터프라이즈 파이프라인 — 은 사전 생성, 멀티 프로바이더 라우팅, 또는 둘 다를 추가합니다. 이 결정은 벤더의 마케팅 페이지가 아닌 피크 부하 로그에서 나와야 합니다.

결론

GPT Image 2 속도 제한의 빠른 요약: Tier 1은 5 IPM에서 시작하고, Tier 5는 250 IPM이 상한이며, 버스티 트래픽은 안정적인 상태의 수학이 시사하는 것보다 훨씬 빠르게 이 한도에 부딪힙니다. 느린 요약: 속도 제한은 문서의 각주가 아닌 운영 설계 제약입니다. 큐, SLA, 기능 범위, 런칭 계획 모두에 영향을 미칩니다.

빌더에게 올바른 질문은 “내가 어떤 Tier에 있나”가 아닙니다 — “내 피크 분이 어떤 모습인지, 그리고 Tier가 여유를 두고 흡수할 수 있는지”입니다. 대부분의 팀은 런칭 후에 잘못된 방식으로 답을 발견합니다.

Tier 5에서 GPT Image 2를 운영해보면 더 업데이트하겠습니다. 위의 수치는 OpenAI의 것이고, 프레이밍은 제 것이며, 용량 정책은 블로그 포스트보다 빠르게 업데이트됩니다.

이전 포스트: