GPT-OSS 무료 티어 제한 준수: 콘텐츠 자동화 과정에서 저장소 호출 간 15초 지연 추가하기

요약 (TL;DR):

무료 티어의 요청 제한을 준수하기 위해 src/main.py 내의 연속적인 GPT-OSS 호출 사이에 15초의 일시 정지(pause)를 추가했습니다. 이 간단한 변경을 통해 간헐적인 429 에러를 제거하였고, 모든 저장소에 대해 콘텐츠 생성 파이프라인(content-generation pipeline)을 안정화했습니다.

문제 상황

우리의 content-automation 파이프라인은 조직 내의 모든 저장소(repository)에서 데이터를 가져와 GPT-OSS-20B 모델에 입력하고, 생성된 마크다운(markdown) 파일을 디스크에 다시 기록합니다.

저장소의 수가 30개를 넘어가면서 스크립트에서 다음과 같은 에러가 발생하기 시작했습니다:

HTTPError: 429 Too Many Requests

또는 어떤 경우에는 모델 서비스가 소켓(socket)을 닫아버려 ConnectionResetError가 발생하기도 했습니다.

GPT-OSS 무료 티어는 IP 주소당 15초당 1회 요청을 허용합니다. 기존 루프(loop)는 요청을 연속해서 보냈기 때문에, 거의 즉시 제한에 걸렸습니다.

몇 명의 워커(worker)를 사용하면 실행 속도가 빨라질 것이라 생각하여 호출을 병렬화하기 위해 ThreadPoolExecutor를 추가해 보기도 했습니다. 하지만 이는 서비스가 우리를 더욱 강력하게 제한(throttle)하게 만들어 문제를 악화시켰을 뿐입니다.

처음 시도했던 방법들

1. 지연 없음, 병렬 처리 없음 – 기본 스크립트는 가능한 한 빠르게 요청을 보냈습니다.
2. ThreadPoolExecutor – 모델에 병렬로 접근하기 위해 4개의 워커를 생성했습니다.
3. 429 발생 시 백오프 (Back-off) – 429 에러가 발생하면 30초간 sleep한 후 재시도했습니다.
4. 타임아웃(timeout) 증가 – requests 타임아웃을 120초로 조정했습니다.

이러한 접근 방식 중 어느 것도 근본적인 문제를 해결하지 못했습니다. 무료 티어는 IP당 엄격한 속도 제한(rate limit)을 적용하며, 이를 준수하는 유일하고 신뢰할 수 있는 방법은 요청 속도 자체를 조절(throttle)하는 것이었습니다.

구현 내용

저는 가장 간단한 해결책을 선택했습니다: 각 저장소 호출 사이에 time.sleep(15)를 추가하는 것입니다.

변경 사항은 src/main.py에 적용되었습니다. 관련 diff는 다음과 같습니다:

@@
-    for repo_info in all_repos:
+    for i, repo_info in enumerate(all_repos):
...

작동 원리

• 결정론적 페이싱 (Deterministic pacing) – 서비스 제한에 맞춰 15초마다 최대 한 번의 요청만 이루어지도록 보장합니다.
• 단순성 (Simplicity) – 외부 라이브러리나 복잡한 지수 백오프 (back-off) 로직이 필요하지 않습니다.
• 투명성 (Transparency) – print 문을 통해 스크립트가 대기(sleep)하는 시점을 로그로 남기므로, 페이싱을 감사하기 쉽습니다.

소규모 리팩토링 (Minor refactor)

지연 시간을 추가하면서, 명확성을 위해 루프 변수 이름(i, repo_info)을 소규모로 리팩토링했습니다. 스크립트의 나머지 부분은 변경되지 않았습니다.

핵심 요약 (Key Takeaway)

속도 제한 (rate-limited) API를 사용할 때 가장 신뢰할 수 있는 전략은 재시도 로직 (retry logic)이나 동시성 (concurrency)에 의존하는 대신, 직접 요청 속도를 조절 (throttle)하는 것입니다. 고정된 대기 간격 (fixed sleep interval)은 의존성 없이 구현할 수 있으며, 파이프라인이 서비스의 제약 조건 내에서 유지되도록 합니다.

이 패턴은 다음과 같이 폭넓게 적용 가능합니다:

• 엄격한 제한이 있는 모든 제3자 AI 서비스 (OpenAI, Cohere, Anthropic).
• IP당 속도 제한을 강제하는 공개 API (GitHub, Twitter).
• 엄격한 할당량 (quota)이 있는 내부 서비스.

다음 단계 (What's Next)

1. 지수 백오프 (Exponential back-off) – 고정된 15초 대기 대신, 실제 할당량 사용량에 따라 적응하는 지터 (jittered) 백오프 알고리즘을 사용할 수 있습니다.
2. 큐 시스템 (Queue system) – 저장소 목록을 메시지 큐 (예: RabbitMQ)로 옮기고, 워커 (worker)가 내장된 속도 제한 기능을 통해 작업을 처리하도록 합니다.
3. 모니터링 (Monitoring) – Prometheus에 메트릭 (metrics)을 추가하여 요청 횟수와 대기 시간을 추적함으로써, 제한에 다시 도달할 경우 알림을 받을 수 있도록 합니다.

현재로서는 15초의 지연 시간이 파이프라인을 원활하게 실행하며, 로그를 통해 임계값을 초과하지 않음을 확인할 수 있습니다.

Tags: #vibecoding #buildinpublic #python #gpt #rate‑limiting #automation

Part of my Build in Public series — sharing the real process of building SaaS projects from Playa del Carmen, México.

Repo: zaerohell/content-automation · 2026-07-30

#playadev #buildinpublic