Circuit Breaker란? 계속 실패하는 외부 서비스 요청을 잠시 차단하는 이유 쉽게 이해하기
Circuit Breaker는 외부 서비스가 계속 실패할 때 잠시 요청을 차단하고 Half-Open으로 복구를 확인하는 장애 보호 패턴입니다. Closed·Open·Fail Fast·Fallback·Backoff 비교까지 초보 기준으로 정리합니다.
두꺼비집처럼 요청 흐름을 끊기
결제·문자·이메일·지도·AI처럼 홈페이지는 외부 API를 많이 씁니다. 외부가 이미 장애인데 모든 요청이 계속 호출하면 Thread·Connection·네트워크·Timeout 대기만 소모되고, 우리 서비스까지 느려질 수 있습니다 — 이것이 장애 전파·연쇄 장애(Cascading Failure)입니다. Circuit Breaker(서킷 브레이커)는 실패가 기준을 넘으면 잠시 요청을 막고(Fail Fast), 시간이 지나면 복구 여부를 시험하는 보호 패턴입니다. 집의 차단기가 전기를 끊듯, 회로(Circuit)를 잠시 엽니다.
CLOSED → 요청 통과 실패 누적 → OPEN(차단·즉시 실패) 대기 → HALF-OPEN(소수 Probe) 성공 → CLOSED / 실패 → OPEN
Closed · Open · Half-Open
Closed는 정상 — 스위치가 닫혀 전류가 흐르듯 요청이 외부로 갑니다. 실패율·연속 실패·Sliding Window(최근 N건)가 Threshold를 넘으면 Open — 외부 호출 없이 빠르게 오류(또는 Fallback). Open이 영원히면 복구를 못 하니 일정 시간 뒤 Half-Open에서 Probe 몇 건만 보냅니다. 성공하면 Closed, 실패하면 다시 Open. 표본이 너무 적으면(요청 2건에 실패율 50%) 최소 요청 수를 둡니다. HTTP 200이어도 20초면 Slow Call로 볼 수 있습니다. Timeout은 「한 요청을 얼마나 기다릴지」, Breaker는 「앞으로 잠깐 보낼지」 — 둘을 함께 씁니다. Exponential Backoff는 개별 Retry 간격, Breaker는 서비스 단위 차단입니다.
Timeout = 한 번 대기 한도 Backoff/Retry = 다시 시도할 때 Breaker = 당분간 아예 안 보냄
Fallback · Bulkhead · 운영
Open일 때 추천 API는 인기 상품으로 대체(Graceful Degradation)할 수 있지만, 결제는 「결제 불가」를 명확히 하는 편이 안전합니다 — Fallback이 오래된 환율·재고를 정상처럼 보이게 하면 안 됩니다. 문자·이메일은 Queue로 분리하면 가입 전체가 같이 죽지 않습니다. Open인데 클라이언트가 즉시 Retry만 반복하면 내부 낭비이니 안내·Backoff를 맞춥니다. 상태 코드는 계약에 맞게 — 의존성 불가면 503·HTTP 상태 의미를 정리합니다. Breaker는 장애를 고치지 않으므로 Open 알림·대시보드가 필요합니다. 민감하면 False Open, 둔하면 자원 낭비·Flapping(열림↔닫힘 반복)이 납니다. 모니터링에 CLOSED/OPEN/HALF_OPEN을 올립니다. 그런데 Breaker가 막기 전에 느린 API가 Connection·Worker를 전부 잡아먹으면 결제까지 멈출 수 있습니다 — 기능별 자원 격리인 Bulkhead가 이어집니다. Livelock의 끝없는 Retry와도 맞물립니다.
추천 Open → 인기 상품 Fallback 결제 Open → 명확한 불가 안내 자원 분리 → Bulkhead
자주 묻는 질문
Circuit Breaker란?
외부 서비스가 반복 실패할 때 잠시 요청을 차단하고, 이후 Probe로 복구를 확인하는 장애 보호 패턴입니다.
Closed는 정상인가?
네. 스위치가 닫혀 요청이 외부로 통과하는 상태입니다.
Open / Half-Open은?
Open은 외부 호출 차단, Half-Open은 소수 시험 요청으로 복구 여부를 확인합니다.
Timeout·Retry와 차이는?
Timeout은 한 요청 대기, Retry/Backoff는 재시도, Breaker는 서비스 단위로 당분간 중단입니다. Backoff 가이드를 함께 보세요.
Fallback이란?
원래 기능 대신 안전한 대체(인기 상품·주소 텍스트 등)입니다. 결제처럼 임의 성공 Fallback은 위험합니다.
모든 API에 붙이나?
필수는 아닙니다. 장애·지연이 우리 자원을 오래 잡는 외부·고호출 의존성에 특히 가치가 있습니다.
정리
Circuit Breaker = 계속 실패하는 외부 서비스로 요청을 잠시 막아 장애 확산을 줄이는 패턴입니다. Closed에서 통과 → 실패 누적 시 Open(Fail Fast) → Half-Open Probe → 성공이면 Closed입니다. Timeout·Backoff와 한 세트이고, Fallback은 기능마다 안전하게, Open은 Alert로 봅니다. 그런데 Breaker가 열리기 전에 느린 추천 API가 서버 Connection·Worker를 전부 써버리면 정작 결제가 멈출 수 있습니다. 기능·외부 서비스별로 Thread·Connection·Worker 한도를 나눠 두는 설계가 Bulkhead(벌크헤드)입니다.