OAuth 요청 한도, 백필 스크립트로 우회하다
목차
대량 초기 데이터를 로드할 때 OAuth 요청 한도에 자꾸 부딪혀서, 자동화 스크립트로 문제를 우회하는 방식을 택했다.
API 한도의 현실
외부 API를 의존하는 서비스라면 rate limit은 피할 수 없는 문제다. OAuth 엔드포인트도 마찬가지인데, 특히 시스템 초기화나 대량 데이터 마이그레이션 단계에서는 일시적으로 많은 요청이 몰린다. 우리 팀도 비슷한 상황에 직면했다. 새 환경을 세팅하거나 테스트 데이터를 준비할 때마다 OAuth 한도에 걸려서 작업이 중단되곤 했다.
문제의 근본은 간단하다. 11개 팀의 번역 데이터와 81개의 뉴스 항목을 인라인으로 채워넣으려면, 각 리소스마다 인증 토큰이 필요하고, 이를 위해 여러 번의 OAuth 요청을 거친다. 순차적으로 처리하면 누적 요청 수가 한도를 초과할 가능성이 높아진다. 단순히 "잠깐 기다렸다가 재시도"하면 되지 않을까 싶겠지만, 개발 환경에서는 seed 작업이 자주 반복되므로 기다리는 것이 곧 개발 생산성 저하로 이어진다.
두 가지 백필 스크립트로 분할
접근 방식은 이랬다. 일단 작업을 둘로 나눠서 처리하기로 했다.
| 작업 | 용도 | 데이터 규모 |
|---|---|---|
_fill_11_i18n.py |
11개 팀의 다국어 번역 리소스 초기화 | 팀 수 기준 (11건) |
_fill_news_inline.py |
뉴스 항목 인라인 데이터 백필 | 뉴스 건수 기준 (81건) |
스크립트를 분리하면 몇 가지 이득이 생긴다. 첫째, 한 번에 처리하는 요청 수가 줄어들어 OAuth 한도를 덜 자극한다. 둘째, 특정 작업만 다시 실행하거나 부분 복구가 필요할 때 해당 스크립트만 골라 돌릴 수 있다. 셋째, 각 스크립트의 목적이 명확해져서 나중에 유지보수할 때도 수정 범위를 좁힐 수 있다.
한도 우회 전략
스크립트가 동작하려면 OAuth 토큰을 어떻게 확보할 것인지가 핵심이다. 직접 각 팀과 뉴스 리소스마다 토큰을 따로 요청하면 또다시 한도에 걸린다. 그래서 먼저 캐싱이나 배치 처리 방식을 고민했다. 예를 들어:
- 토큰을 미리 한 번에 따로 받아서 저장한 뒤, 스크립트에서 재사용
- 요청 사이에 지연을 두고 서서히 처리 (throttling)
- 서버 측에서 지원하는 벌크 엔드포인트가 있다면 활용
- 이미 발급된 토큰의 유효 기간을 최대한 활용
구체적인 방법은 환경과 외부 API의 특성에 따라 달라지겠지만, 핵심은 "일단 스크립트로 자동화하고, 그 과정에서 필요한 토큰 관리 로직을 깔끔하게 설계한다"는 것이다. 수동으로 curl이나 postman을 여러 번 두드릴 때보다, 스크립트가 지능적으로 handle 해줄 여지가 훨씬 크다.
회고: 왜 이 우선순위?
팀원들이 "그냥 OAuth 한도 올려달라고 API 제공자한테 요청하면 안 되나"라고 물어볼 수 있다. 물론 그것도 방법이다. 하지만 우리는 일단 스크립트 자동화를 먼저 택했다. 이유는:
- 즉시성 — API 제공자 응답을 기다리지 않아도 지금 당장 seed 작업을 진행할 수 있다
- 재사용성 — 한 번 만들어둔 스크립트는 new environment, staging, testing 등 여러 곳에서 재사용 가능
- 제어권 — 우리 시스템 안에서 요청 흐름을 관리할 수 있다
- 학습 — 팀원들이 대량 데이터 처리와 API 요청 관리에 대해 배울 기회
물론 장기적으로는 제공자에게 한도 증대를 요청하거나, 다른 방식의 초기화 경로를 협의하는 것도 병행할 만하다. 하지만 그것도 우리 자동화 스크립트가 있으면 더 안정적으로 진행할 수 있다.
마치며
seed 작업 같은 인프라 업무는 한 번 잘 만들어두면 그 효과가 크다. 특히 팀 규모가 늘거나 뉴스/콘텐츠가 증가해도 스크립트는 그대로 재사용할 수 있다. 다음번에 같은 문제를 만나는 팀원이 있으면 이 스크립트들이 좋은 참고가 되길.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.