서드파티 API 장애 대응 방법, 재시도 로직과 Circuit Breaker로 서비스 안정성 높이기

🌐 외부 API 장애가 끼치는 영향

서비스가 외부 API에 의존하는 구조에서는, 해당 API가 일시적으로 장애를 겪을 경우 예상치 못한 연쇄적인 문제가 발생할 수 있습니다.
예를 들어 결제 시스템, 주소 검색, 문자 인증 등 주요 기능이 서드파티 API를 기반으로 작동하는 경우, 장애 시 사용자 경험 자체가 무너질 수 있습니다.
심하면 화면이 멈추거나 아예 응답이 없는 상태로 남기도 하죠.

문제는 단순히 API 호출 실패에서 끝나지 않습니다.
하나의 요청 실패가 반복되면서 전체 서비스의 트래픽이 몰리고, 내부 자원이 고갈되거나 서버까지 다운되는 경우도 발생합니다.
이것이 바로 장애의 전파입니다.
내부 로직이 이러한 상황에 대비하지 않으면 정상적인 사용자까지 영향을 받는 전면 장애로 확산될 수 있습니다.

💬 외부 시스템이 멈췄다고 우리 서비스까지 멈출 이유는 없습니다.
미리 준비된 대응 전략이 있다면, 장애를 겪더라도 사용자에게는 정상처럼 보일 수 있습니다.

이러한 이유로 외부 API에 의존하는 구조를 설계할 때는, 반드시 실패를 전제로 하는 방어적 프로그래밍이 필요합니다.
API 호출이 실패했을 때 어떻게 대응할지에 대한 구체적인 시나리오가 없다면, 전체 서비스 신뢰도에 큰 타격을 줄 수밖에 없습니다.

🔁 자동 재시도(Retry) 로직의 기본

외부 API 호출이 실패했을 때 가장 먼저 고려할 수 있는 방법이 자동 재시도(Retry)입니다.
일시적인 네트워크 지연, 일회성 타임아웃, 간헐적인 서버 오류 등은 단 한 번의 재시도로도 해결되는 경우가 많습니다.
그렇기 때문에 대부분의 클라이언트 라이브러리나 HTTP 클라이언트는 재시도 기능을 기본 제공하거나 설정을 통해 쉽게 추가할 수 있도록 설계되어 있습니다.

🔂 재시도 간격과 최대 횟수 설정

재시도 로직을 구현할 때는 단순히 반복 호출만 하는 것이 아니라 재시도 간격(Interval)과 최대 시도 횟수(Max Attempts)를 반드시 설정해야 합니다.
무한 반복 호출은 오히려 서버에 더 큰 부하를 줄 수 있고, 내부 자원도 낭비하게 됩니다.

• ⏱️기본 재시도 간격은 2초~5초 사이로 설정
• 🔁재시도 횟수는 3회 이하로 제한
• 📉지수 백오프(Exponential Backoff) 적용 권장

⚠️ 재시도는 만능이 아니다

모든 장애 상황에서 재시도가 유효한 것은 아닙니다.
예를 들어 인증 실패(401), 권한 오류(403), 잘못된 요청(400번대 응답)은 재시도를 하더라도 성공하지 않습니다.
이런 경우에는 재시도 대신 즉시 사용자에게 오류 메시지를 전달하거나, fallback 처리를 고려하는 것이 적절합니다.

🧯 장애 전파를 막는 Circuit Breaker

Circuit Breaker는 말 그대로 ‘회로 차단기’처럼 외부 시스템의 장애가 내부 서비스에 영향을 주지 않도록 차단하는 역할을 합니다.
특정 API가 일정 횟수 이상 실패하면, 이후 일정 시간 동안 해당 API 호출을 아예 중단시키고 대체 처리(Fallback)를 실행하는 방식입니다.
이러한 전략은 전체 시스템을 지키기 위한 방어막 역할을 하죠.

🧠 동작 방식 간단 이해

많은 분들이 사용하는 Netflix의 Hystrix나 Resilience4j 같은 라이브러리에서는 이 Circuit Breaker 기능을 기본 제공합니다.
설정만 잘 하면 수십 줄 코드를 한 줄로 줄일 수 있을 만큼 간편하게 구현할 수 있습니다.

🧩 언제 Circuit Breaker를 적용해야 할까?

외부 API의 장애가 전체 트래픽에 영향을 미치는 중요한 경로일 경우, Circuit Breaker는 반드시 필요합니다.
또한 예상 불가한 장애에 대한 보호 수단이 없을 때는 시스템 전체의 ‘안전장치’ 역할을 할 수 있죠.

🛠️ 대체 처리 로직(Fallback) 설계법

Fallback은 외부 API 호출에 실패했을 때, 사용자에게 대체 정보를 제공하거나 최소 기능만 제공해서 서비스의 연속성을 유지하는 전략입니다.
API가 완전히 응답하지 않더라도, 서비스가 멈추지 않도록 만들기 위한 ‘플랜 B’라고 할 수 있습니다.

예를 들어, 실시간 배송조회 API가 실패했을 경우 ‘배송 준비 중’으로 표시하거나, 날씨 API 장애 시 ‘현재 날씨 정보는 잠시 제공되지 않습니다’라는 문구로 대체하는 것이 Fallback입니다.
이러한 대응은 사용자의 불편을 최소화할 수 있으며, 서비스의 신뢰도 유지에도 큰 도움이 됩니다.

🔧 실전 예시로 알아보는 Fallback 처리

// Java + Resilience4j 예시
Supplier<String> fallback = () -> "데이터를 불러올 수 없습니다.";
Supplier<String> result = CircuitBreaker
    .decorateSupplier(circuitBreaker, () -> externalApi.call());
Try<String> response = Try.ofSupplier(result).recover(fallback);

📌 비즈니스 로직에 맞춘 Fallback 설계가 핵심

Fallback은 단순한 예외 처리로 끝나는 것이 아닙니다.
사용자 입장에서 불편하지 않도록 기대하는 서비스 흐름을 유지해야 하며, 업무 로직과 UX에 맞춘 커스터마이징이 중요합니다.

📊 모니터링과 장애 예측의 중요성

API 장애 대응 전략이 잘 마련되어 있더라도, 실제 문제를 인지하지 못하면 대응도 늦을 수밖에 없습니다.
그래서 실시간 모니터링과 장애 예측 시스템은 필수적인 요소입니다.
단순 로그 저장을 넘어, API 응답 시간, 오류 비율, 재시도 횟수 등을 실시간으로 시각화하고 이상 징후를 빠르게 감지할 수 있어야 합니다.

특히 Prometheus + Grafana, Datadog, New Relic, AWS CloudWatch 같은 도구는 외부 API의 상태를 수집하고, 알람을 자동 전송하는 데 매우 유용합니다.
서비스가 사용자의 신뢰를 얻으려면 장애 발생을 줄이는 것도 중요하지만, 빠르게 복구하는 능력도 중요합니다.

📈 어떤 항목을 모니터링해야 할까?

• ⏱️API 응답 속도와 지연 시간
• ❌5xx 오류율 상승 여부
• 🔁재시도 로직의 트리거 빈도
• 📉Circuit Breaker 상태 변화 추적

🧪 예측 기반의 사전 대응 전략

모니터링이 단순 수동 감시로 끝나서는 안 됩니다.
최근에는 이상 징후 감지와 머신러닝 기반 예측으로 장애 발생 전 선제 대응이 가능해지고 있습니다.
트래픽 급증이나 응답 지연이 평소보다 높게 감지될 경우, 사전 알림을 통해 팀이 즉시 대응할 수 있도록 준비하는 것도 중요합니다.

❓ 자주 묻는 질문 (FAQ)