최근 개인 프로젝트를 진행하며 무료 이미지 생성 API인 Pollinations API를 아주 유용하게 사용하고 있었다. 빠르고 간편하게 이미지를 얻을 수 있어 만족스러웠는데, 어느 날 청천벽력 같은 에러를 마주했다. 이미지 3장을 연속으로 생성하는 과정에서 HTTP 429 Too Many Requests 오류가 화면을 채운 것이다.

알고 보니 짧은 시간 내에 너무 많은 요청을 보내서 서버로부터 차단을 당한 상태였다. 무료로 서비스를 제공하는 고마운 API인 만큼 엄격한 속도 제한이 걸려 있는 것은 당연한 일인데, 나의 대처가 너무 안일했다는 생각이 들었다. 문제를 해결하기 위해 곧바로 코드 분석과 수정 작업에 착수했다.

속도 제한의 벽, 4초의 지연 시간이 남긴 에러 로그

원인을 분석해보니 기존 코드에 설정되어 있던 이미지 생성 간 딜레이가 겨우 4초에 불과했다. 이미지 하나를 만들고 4초 뒤에 바로 다음 이미지를 요청하니, 서버 입장에서는 악성 디도스 공격이나 매크로 요청으로 판단하기 딱 좋은 패턴이었던 셈이다.

연속으로 3장을 뽑아낼 때 두 번째나 세 번째 이미지 요청에서 여지없이 429 에러가 터져 나왔다. Pollinations API 429 오류를 해결하려면 단순히 요청 속도를 늦추는 것뿐만 아니라, 오류가 발생했을 때 서버에 부담을 주지 않으면서 우아하게 재시도하는 전략이 절실했다.

지수 백오프와 대기 시간 재설계로 우회하기

가장 먼저 손을 댄 부분은 요청 간 기본 딜레이 시간이었다. 기존의 너무 짧았던 4초의 대기 시간을 15초로 대폭 늘렸다. 연속 요청 시 서버가 숨을 고를 수 있는 충분한 최소한의 시간을 확보해 주기 위함이었다.

다음으로 재시도 전략을 전면 수정했다. 기존에는 에러 발생 시 재시도 횟수가 2회에 불과했고, 대기 시간도 각각 20초와 40초로 다소 획일적이었다. 이를 극복하기 위해 재시도 횟수를 3회로 늘리고, 대기 시간을 지수 백오프 개념을 도입해 30초, 60초, 90초로 차등화했다.

여기에 결정적인 안전장치를 하나 더 추가했다. API 요청 중 실제로 HTTP 429 응답 코드를 감지하면, 즉시 다음 재시도 단계로 넘어가기 전에 무조건 30초의 추가 대기 시간을 갖도록 별도 분기 처리를 구현했다. 이렇게 하면 일시적인 트래픽 폭주 상황에서도 안전하게 대기한 뒤 재시도를 수행할 수 있다.

세 개의 코드 파일에 동일한 처방 내리기

이번에 수정한 rate limit 대처 로직은 특정 한 곳에만 적용해서는 의미가 없었다. 내가 관리하는 프로젝트 중 Pollinations API를 연동하여 동작하는 KidStory, 이슈로그, JinsLab까지 총 3개의 파일에 이 새로운 재시도 및 대기 시간 공식인 지수 백오프 알고리즘을 동일하게 적용했다.

각 파일의 통신 모듈을 열어 딜레이와 재시도 카운트, 그리고 추가 대기 분기문을 꼼꼼하게 삽입했다. 하나의 파일만 고쳤다가 다른 곳에서 에러가 재발하면 전체 시스템의 신뢰도가 떨어지기 때문에, 동일한 구조를 가진 세 군데의 코드를 일관성 있게 업데이트하는 과정이 필수적였다.

안정적인 API 연동을 마치며

작업을 모두 완료한 뒤 수십 번의 테스트를 거쳐 이미지 3장을 연속으로 생성해 보았다. 가끔 서버 혼잡도가 높을 때 429 에러가 감지되기도 했지만, 새롭게 설계한 지수 백오프와 추가 대기 시간 분기 처리 덕분에 프로그램이 멈추지 않고 안전하게 대기했다가 모든 이미지를 성공적으로 받아왔다.

무료 API를 가져다 쓸 때는 항상 제공자의 정책을 존중하고 방어적인 코드를 작성해야 한다는 기본을 다시금 뼈저리게 느꼈다. 4초에서 15초로 늘어난 시간만큼 대기 시간은 조금 길어졌을지 몰라도, 프로그램이 도중에 뻗어버리는 일 없이 끝까지 작업을 완수하는 신뢰성 높은 시스템을 갖추게 되어 뿌듯하다.