서킷 브레이커 패턴이란 무엇인가요?
한 줄 답변
서킷 브레이커는 Closed→Open→Half-Open 3단계 상태 머신으로 외부 서비스 장애를 격리해, 연쇄 장애(Cascading Failure)를 방지하는 분산 시스템 복원력 패턴이다.
핵심 개념 정리
서킷 브레이커(Circuit Breaker) 패턴은 마이크로서비스 환경에서 특정 서비스의 장애가 호출 체인 전체로 번지는 '연쇄 장애(Cascading Failure)'를 막기 위한 안정성 패턴이다. Netflix가 Hystrix로 대중화했지만 2018년 유지보수가 종료됐고, 현재는 Resilience4j 2.x가 사실상 표준이다. Spring Boot 3.x 기반 프로젝트라면 spring-cloud-starter-circuitbreaker-resilience4j 의존성 하나로 통합된다.
상태 머신은 세 단계로 작동한다. Closed 상태에서는 요청이 정상 통과하며, 슬라이딩 윈도우 내 실패율이 설정한 임계값(예: 50%, 최소 10회 이상 호출 기준)을 초과하면 Open으로 전환된다. Open 상태에서는 외부 서비스를 호출하지 않고 즉시 fallback 로직을 실행해 응답한다. waitDurationInOpenState(기본 60초)가 경과하면 Half-Open으로 진입하고, 허용된 소수의 프로브 요청 결과에 따라 Closed 또는 다시 Open으로 결정된다.
Resilience4j의 핵심 설정 항목은 slidingWindowType(COUNT_BASED 또는 TIME_BASED), slidingWindowSize, failureRateThreshold, slowCallRateThreshold, slowCallDurationThreshold다. slowCallDurationThreshold를 2,000ms로 지정하면 느린 호출도 실패로 간주해 스레드 고갈을 선제적으로 차단한다. 결제 외부 API 응답이 3초 이상 지연되던 운영 장애에서 이 설정이 핵심 방어선 역할을 한 사례가 실무에서 자주 보고된다.
서킷 브레이커 단독으로는 충분하지 않다. 실무에서는 Retry, Bulkhead, TimeLimiter를 계층적으로 조합한다. Bulkhead는 서비스별로 스레드 풀이나 세마포어를 분리해 외부 API 하나의 지연이 전체 스레드를 소진하지 못하게 막는다. Retry는 반드시 서킷 브레이커 바깥 레이어에 배치해야 하며, 안쪽에 두면 Open 상태에서도 재시도가 반복돼 불필요한 대기가 발생한다.
비교 정리
| 항목 | Resilience4j | Hystrix (Netflix OSS) |
|---|---|---|
| 유지보수 상태 | 활발히 개발 중 (v2.2+) | 2018년 유지보수 종료 |
| 반응형 지원 | Project Reactor, RxJava 2/3 네이티브 지원 | RxJava 1.x 한정 |
| 의존성 무게 | 경량 모듈식: 필요한 것만 추가 | 단일 FAT JAR, 무거운 전이 의존성 |
| 설정 방식 | application.yml + @CircuitBreaker 어노테이션 | @HystrixCommand + Archaius 설정 |
| 메트릭 연동 | Micrometer 통해 Prometheus/Grafana 기본 제공 | Hystrix Dashboard 별도 구성 필요 |
면접에서 이렇게 답하세요
면접에서 '서킷 브레이커를 왜 쓰나요?'라는 질문엔 먼저 문제(연쇄 장애)를 정의하고, 상태 전환 흐름(Closed→Open→Half-Open)을 말하세요. 이론 나열만 하면 주니어 답변으로 받아들여집니다. 차별화 포인트는 실제 수치를 언급하는 것입니다. '결제 서비스 연동 시 failureRateThreshold=50, slowCallDurationThreshold=2s, waitDurationInOpenState=30s로 설정했고, fallback으로 캐시된 최근 성공 응답을 반환해 UX를 유지했다'처럼 설정값과 결과를 함께 말하면 설득력이 높아집니다. Bulkhead 패턴과 조합해 설명하면 시스템 복원력 설계를 폭넓게 이해하고 있다는 인상을 줍니다.
자주 묻는 추가 질문
Q. Retry와 서킷 브레이커를 함께 쓸 때 순서가 왜 중요한가요?
Retry를 서킷 브레이커 바깥에 두어야 한다. 안쪽에 배치하면 Open 상태에서도 재시도가 반복돼 fallback이 여러 번 호출되거나 불필요한 대기 시간이 발생한다.
Q. Half-Open에서 허용할 프로브 요청 수는 어떻게 정하나요?
permittedNumberOfCallsInHalfOpenState를 트래픽 규모에 맞게 설정한다. 초당 1,000 TPS 서비스라면 5~10개로 짧게 검증하는 것이 일반적이며, 검증이 길수록 복구 지연 비용이 커진다.
Q. 서킷 브레이커 상태를 운영 환경에서 어떻게 모니터링하나요?
Resilience4j를 Micrometer에 노출하면 resilience4j.circuitbreaker.state 메트릭이 생성된다. Grafana에서 Open 전환 빈도와 fallback 호출 비율을 시각화하고 알람 임계값을 설정한다.
커뮤니티 하이라이트
“결제 외부 API가 간헐적으로 느려질 때 slowCallRateThreshold 설정을 빠뜨려서 스레드가 전부 물려버린 적 있어요. Closed 상태에서도 타임아웃 보호는 반드시 필요합니다.”
“면접에서 Hystrix 언급하면 Resilience4j 마이그레이션 이유를 바로 물어봐요. 유지보수 종료와 반응형 지원 한계 두 가지를 간결하게 답하면 충분합니다.”
34명의 개발자가 이 질문에 참여했습니다
관련 면접 질문
앱에서 직접 답변해보세요
매일 3개의 면접 질문에 답변하고,
다른 개발자들의 답변을 비교해보세요.