Circuit Breaker

외부 결제 API가 응답을 5초씩 지연시키는 상황을 생각해 보면, 그 API를 호출하는 서비스의 스레드들이 응답을 기다리느라 묶이기 시작합니다. 요청은 계속 들어오지만 처리 가능한 스레드가 줄어들고, 결국 결제와 관계없는 기능까지 응답이 늦어집니다. 재시도를 붙이면 더 많은 스레드가 대기열에 쌓이고, 타임아웃만 짧게 잡으면 이번엔 실패 요청이 폭증합니다. 느린 의존성 하나가 호출하는 서비스 전체를 점진적으로 멈추게 만드는 이 패턴을 전통적인 재시도와 타임아웃만으로는 막기 어렵습니다.

단일 서버 시절에는 의존성 실패가 곧 그 기능의 실패였고, 그 범위는 명확했습니다. 서비스가 네트워크 너머로 분리되면서 의존성은 많아졌고, 그중 일부는 언제나 느리거나 불안정할 수 있게 되었습니다. 특히 클라우드 환경에서는 외부 API, 타 팀의 서비스, 관리형 데이터 스토어 등 통제할 수 없는 의존성이 늘었습니다. 타임아웃으로 기다리는 시간을 줄이는 것만으로는 부족했고, 이미 실패하고 있는 대상을 아예 잠시 끊고 회복을 기다리는 패턴이 필요해졌습니다. 이 맥락에서 Circuit Breaker는 분산 시스템의 기본 레질리언스 패턴 중 하나로 자리를 잡았습니다.

세 가지 상태로 동작합니다. Closed 상태에서는 모든 호출을 정상 통과시키며 오류율이나 응답 지연을 측정합니다. 오류율이 설정된 임계치(예: 50%)를 초과하면 Open 상태로 전환되어 실제 호출을 막고 즉시 실패 응답이나 대체 응답을 돌려줍니다. Open 상태가 일정 시간 유지되면 Half-Open 상태로 전환되어 소수의 탐침 호출을 허용하고, 이 호출이 성공하면 Closed로 복귀, 실패하면 다시 Open으로 돌아갑니다. 이 세 단계의 전환 덕분에 의존성이 회복됐을 때 자동으로 정상 동작이 재개됩니다.

Circuit Breaker와 비슷하게 언급되는 개념으로 Idempotency와 Saga가 있습니다. Idempotency는 같은 요청이 여러 번 실행돼도 결과가 한 번과 같게 유지되는 속성으로, '호출을 차단할지' 판단이 아니라 '중복 실행이 안전한지'를 다룹니다. Saga는 여러 서비스에 걸친 흐름이 실패했을 때 보상을 통해 상태를 정리하는 패턴으로, Circuit Breaker와 상호 보완적입니다. Observability와 비교하면, Circuit Breaker는 실패 전파를 막는 보호 장치이고 Observability는 어디서 왜 실패가 시작됐는지 추적하는 진단 기반입니다. 셋을 같은 층의 것으로 보기보다, 각자 다른 층에서 시스템을 보호하고 보이게 하는 역할을 한다고 이해하는 편이 낫습니다.

외부 결제 API, 타 팀이 운영하는 내부 서비스, 외부 데이터 스토어처럼 통제 범위 밖에 있거나 가용성이 불안정한 의존성을 호출하는 모든 경로에서 Circuit Breaker는 유용합니다. '특정 의존성이 느려질 때마다 우리 서비스 전체가 같이 느려진다'거나 '재시도가 폭증하면서 장애가 오히려 길어진다'는 신호가 보이면 검토할 만합니다. 대체 응답(fallback)이 가능한 경우 효과가 더 큽니다. 다만 임계치와 복귀 대기 시간은 실제 트래픽과 오류 패턴을 관측한 데이터 없이 감으로 잡으면 정상 호출까지 차단하거나, 반대로 차단이 너무 늦어 의미가 없어질 수 있어 Observability와 함께 운영해야 합니다.