Gemini API 장애로 전체 파이프라인이 멈췄을 때: 서킷 브레이커 패턴으로 자동 발행 시스템 마비 막기

Gemini API를 이용해 콘텐츠 생성부터 CMS 업로드, SNS 공유까지 자동으로 처리하는 발행 파이프라인을 구축해 본 개발자라면 한 번쯤 식은땀을 흘린 경험이 있을 것입니다. 평소에는 몇 초 만에 수월하게 응답을 주던 LLM API가 갑자기 응답을 멈추거나 지연을 일으킬 때, 그 여파는 단순히 ’글 하나가 제때 안 올라갔다’에서 끝나지 않습니다.

외부 API의 지연은 파이프라인 상류에서부터 웹훅 타임아웃을 유발하고, 차례대로 웹 서버의 작업 스레드를 잠식하며, 결국 전체 자동 발행 시스템을 마비시키는 연쇄 장애(Cascading Failure)로 이어집니다. 본 글에서는 Gemini API 장애 상황에서 시스템 전체가 함께 쓰러지지 않도록 방어하는 서킷 브레이커(Circuit Breaker) 패턴의 적용 원리와 실무 전략을 다룹니다.

외부 API 장애가 전체 시스템을 무너뜨리는 과정

자동 발행 파이프라인에서 가장 흔히 발생하는 비극은 ’단순한 대기’에서 시작됩니다. Gemini API 요청을 처리하는 웹훅 엔드포인트가 있다고 가정해 봅시다.

실제로 이런 장애를 겪게 되면, 평소 모니터링 대시보드에서 대기 중인 스레드 수와 발행 지연 시간이 얼마나 치솟는지 직접 추적해 두는 것이 좋습니다. 장애 전후 수치를 비교해 보면 커넥션 풀이 얼마나 빠르게 고갈되는지, 그리고 서킷 브레이커 도입이 얼마나 시급한지 가늠할 수 있습니다.

장애가 발생했을 때 백엔드 내부에서는 다음과 같은 순서로 시스템이 붕괴됩니다.

  1. 응답 지연 발생: Gemini API 서버의 과부하로 인해 텍스트 생성 응답 시간이 기존 2~3초에서 30초 이상으로 급증합니다.
  2. 웹훅 접속 대기 및 커넥션 고갈: 웹훅 요청을 받는 파이프라인 서버는 Gemini API의 응답을 기다리며 소켓 커넥션을 계속 유지합니다. 새로운 발행 요청이 들어올 때마다 커넥션 풀(Connection Pool)의 스레드가 하나씩 동결됩니다.
  3. 타임아웃 폭발: 클라이언트나 게이트웨이(Nginx, API Gateway 등)에 설정된 웹훅 타임아웃 주기가 도달하면서 커넥션이 강제로 끊깁니다.
  4. 재시도 폭주(Thundering Herd Problem): 실패를 감지한 파이프라인이 즉시 재시도(Retry) 요청을 쏟아붓습니다. 이미 과부하 상태인 Gemini API와 자원이 고갈된 자체 서버 양쪽에 더 큰 과부하를 더하게 됩니다.
  5. 전체 파이프라인 다운: 자동 발행 시스템 내부의 다른 무관한 서비스(이미지 최적화, DB 저장 등)까지 작업 스레드를 얻지 못해 시스템 전체가 응답 불능 상태에 빠집니다.

이러한 연쇄 반응을 끊어내기 위해서는 ’실패하는 외부 호출을 빠르게 포기하고 격리하는 기술’이 필수적입니다.

서킷 브레이커 패턴: 전기 차단기처럼 시스템 보호하기

누전이 발생했을 때 집안의 전원 차단기가 내려가 전체 화재를 막는 것처럼, 소프트웨어 분야의 서킷 브레이커 역시 외부 서비스 장애 시 호출을 즉시 차단하여 내 시스템의 자원을 보호합니다.

Gemini API 연동 구간에 서킷 브레이커를 도입하면 시스템은 다음 3가지 상태(State) 변화를 거치며 스스로를 방어합니다.

      [ 정상 작동 ]
        Closed
       /      ^
      /        \ (성공 확인)
 (오류 지속)   (부분 성공)
    /            \
   v              \
 Open ----------> Half-Open
      (쿨다운 시간 만료)

1. Closed (닫힘 - 정상)

모든 요청이 Gemini API로 정상 전달됩니다. 서킷 브레이커는 내부적으로 호출 성공률과 실패율, 혹은 타임아웃 발생 횟수를 계속 통계로 집계합니다.

2. Open (열림 - 차단)

특정 시간 동안 지정된 비율 이상의 타임아웃이나 오류가 발생하면, 차단기가 즉시 ‘Open’ 상태로 전환됩니다. 이 상태에서는 Gemini API로 요청을 아예 보내지 않고, 즉시 에러를 반환하거나 준비된 대안(Fallback) 로직을 실행합니다. 이를 통해 웹훅 타임아웃을 방지하고 스레드 자원을 0.001초 만에 회수할 수 있습니다.

3. Half-Open (반열림 - 탐색)

지정된 쿨다운(Cooldown) 시간이 지나면 차단기는 ‘Half-Open’ 상태가 됩니다. 이때 들어오는 소수의 요청만 Gemini API로 보내 상태가 회복되었는지 테스트합니다. 성공하면 차단기는 다시 Closed로 돌아가고, 여전히 응답이 없거나 타임아웃이 나면 Open 상태로 돌아가 쿨다운 시간을 재설정합니다.

방어 전략 비교: 재시도, 타임아웃, 서킷 브레이커

시스템 방어 체계를 구축할 때 세 가지 개념을 혼동하기 쉽습니다. 차이점을 정확히 이해해야 올바른 아키텍처를 설계할 수 있습니다.

구분 단순 재시도 (Naive Retry) 타임아웃 단독 설정 (Timeout Only) 서킷 브레이커 적용 (Circuit Breaker)
Gemini 장애 시 동작 성공할 때까지 반복 요청 설정한 시간(예: 10초) 동안 무조건 대기 후 실패 장애 감지 시 요청 자체를 즉시 차단 (Fail-Fast)
자원 소모량 매우 높음 (스레드 및 API 쿼터 고갈) 높음 (타임아웃 시간만큼 스레드 점유) 매우 낮음 (차단 상태에서는 자원 소모 거의 없음)
타 파이프라인 영향 전면 마비 유발 부분적 지연 및 스레드 고갈 장애 영향 범위 완벽 격리
복구 방식 수동 조치 또는 API 자체 회복 대기 대기 후 개별 요청 단위 처리 Half-Open 상태를 통한 자동 감지 및 회복
권장 적용 상황 일시적인 네트워크 튐 현상 독립적인 단발성 요청 지속적인 외부 API 연동 파이프라인

회복력 있는 자동 발행 파이프라인 구축 체크리스트

실제 파이프라인에 서킷 브레이커를 적용할 때 반드시 점검해야 할 핵심 구성을 모듈별로 정리했습니다.

서킷 브레이커를 도입한 뒤에는 도입 전후의 웹훅 응답 속도와 CPU 자원 사용량을 직접 비교해 보는 것이 좋습니다. 차단 상태에서는 외부 호출 자체가 생략되므로 응답 속도와 자원 소모 모두 눈에 띄게 개선되는 것을 체감할 수 있습니다.

1. 타임아웃의 세분화 (Connect vs Read Timeout)

단순히 timeout = 30s 형태로 통틀어 설정하지 마세요.

2. 임계값(Threshold) 모니터링 수치 정의

서킷을 열어버릴 조건(Open Condition)을 명확히 정의합니다.

3. Fallback(대체 경로) 및 큐(Queue) 연동

Gemini API 호출이 차단(Open)되었을 때 처리할 비상 로직을 마련해야 합니다.

실무적인 주의점: 서킷 브레이커 도입 시 빠지기 쉬운 함정

서킷 브레이커를 도입했다고 해서 모든 장애가 자동으로 해결되지는 않습니다. 실제 운용 환경에서 자주 발생하는 부작용과 대비책은 다음과 같습니다.

첫째, Half-Open 상태에서의 폭주입니다. 차단기가 닫힐 수 있는지 테스트하는 Half-Open 상태에서 너무 많은 트래픽을 한꺼번에 보낼 경우, 회복 중이던 Gemini API에 다시 과부하를 주어 영원히 Open과 Half-Open을 오가는 진동 현상이 발생할 수 있습니다. 반열림 상태에서는 정확히 1~2개의 테스트 요청만 허용하도록 동시 요청 수를 제한해야 합니다.

둘째, 웹훅 수신 측의 재시도 정책과의 충돌입니다. 만약 GitHub, Shopify, 혹은 자체 프론트엔드에서 웹훅을 발송할 때 재시도 간격을 지수 백오프(Exponential Backoff) 없이 짧게 가져간다면, 서킷 브레이커가 빠르게 에러를 반환하더라도 웹훅 요청 자체의 폭주로 인해 게이트웨이가 마비될 수 있습니다. 웹훅 발송 측에도 반드시 지수 백오프와 지터(Jitter) 알고리즘이 적용되어 있는지 확인해야 합니다.

외부 API 인프라는 우리가 제어할 수 없는 영역입니다. Gemini API와 같은 고성능 AI 모델이라 할지라도 데이터센터 네트워크 이슈, 서비스 과부하, 모델 업데이트 과정에서 지연 및 장애는 언제든 발생할 수 있습니다.

핵심은 외부 API가 100% 멀쩡할 것이라는 가정을 버리는 데 있습니다. 타임아웃을 타이트하게 쥐고, 이상 징후 발생 시 서킷 브레이커를 통해 신속하게 차단막을 치며, 백그라운드 큐로 작업을 안전하게 이관하는 설계야말로 24시간 끊김 없는 자동 발행 파이프라인을 유지하는 가장 확실한 방파제입니다.

연관 글