Circuit Breaker 패턴의 정의
Circuit Breaker(서킷 브레이커)는 마이크로서비스나 외부 API 호출처럼 네트워크를 통해 다른 시스템과 통신할 때, 특정 서비스에 장애가 발생했을 때 그 장애가 전체 시스템으로 번지는 것을 막아주는 설계 패턴입니다. 이름 그대로 집 안의 두꺼비집(차단기)에서 아이디어를 가져왔습니다. 전기 회로에 과부하가 걸리면 차단기가 회로를 끊어서 화재를 방지하듯, 소프트웨어에서도 특정 서비스가 계속 실패하면 호출 자체를 차단해서 장애가 다른 서비스까지 퍼지는 것을 막는 것입니다.
만약 이런 안전장치가 없다면 어떤 일이 벌어질까요? A 서비스가 B 서비스를 호출하는데 B가 응답 지연이나 타임아웃을 계속 일으킨다고 가정해봅시다. A는 B의 응답을 기다리느라 스레드와 커넥션을 계속 점유하게 되고, 결국 A 서비스 자체도 느려지거나 다운될 수 있습니다. 이렇게 하나의 장애가 도미노처럼 번지는 현상을 ‘장애 전파(Cascading Failure)’라고 부르며, Circuit Breaker는 바로 이 문제를 해결하기 위해 등장했습니다.
동작 원리: 세 가지 상태
Circuit Breaker는 보통 세 가지 상태를 오가며 동작합니다.
Closed(닫힘): 정상 상태로, 요청이 그대로 대상 서비스에 전달됩니다. 이때 실패율을 계속 모니터링합니다.Open(열림): 실패율이 설정한 임계치(예: 10초간 요청의 50% 실패)를 넘으면 회로가 열리며, 이후 요청은 실제 서비스로 보내지 않고 즉시 실패 응답이나 대체 응답(Fallback)을 반환합니다.Half-Open(반열림): 일정 시간이 지나면 회로가 반쯤 열려 일부 요청만 실제 서비스로 보내봅니다. 이 요청들이 성공하면 Closed 상태로 복귀하고, 다시 실패하면 Open 상태로 돌아갑니다.
예를 들어 결제 서비스가 응답하지 않는 상황에서 Circuit Breaker가 Open 상태가 되면, 이후 요청들은 결제 서비스에 부담을 주지 않고 곧바로 ‘일시적으로 이용이 어렵습니다’라는 안내를 반환합니다. 덕분에 결제 서비스는 회복할 시간을 벌고, 호출하는 쪽도 무한정 대기하지 않게 됩니다.
실무에서 왜 쓰는가
Circuit Breaker는 특히 마이크로서비스 아키텍처(MSA)에서 필수적으로 고려되는 패턴입니다. 서비스 수가 많아질수록 서비스 간 의존성도 복잡해지기 때문에, 하나의 장애가 전체 시스템 마비로 이어지는 것을 막아야 합니다. Java 진영에서는 Netflix가 만든 Hystrix가 이 개념을 대중화시켰고, 현재는 Resilience4j 같은 경량 라이브러리가 널리 사용됩니다. Spring Cloud Circuit Breaker처럼 프레임워크 차원에서 통합 지원하는 경우도 많습니다.
결국 Circuit Breaker는 ‘실패를 빠르게 인정하고 시스템 전체를 지키는’ 전략입니다. 무조건 재시도하거나 무한정 기다리는 대신, 실패가 반복되면 잠시 손절하고 대체 로직으로 넘어가는 것이 전체 서비스의 안정성을 높이는 핵심 원리입니다.