• 목록

외부 서비스를 호출하다가 실패하면 다시 보내는 방법을 먼저 떠올리기 쉽습니다. 일시적인 문제라면 재시도가 도움이 될 수 있지만 계속 실패하는 대상에 요청을 쌓으면 내 서비스도 기다리는 작업으로 붐빌 수 있습니다.

서킷 브레이커는 이런 상황에서 호출을 잠시 차단하고 회복을 확인하는 역할을 합니다. 재시도와 어떤 질문이 다른지, 기본 상태와 운영에서 확인할 조건을 정리합니다.

AI 생성 삽화 · 개념 이해를 위한 AI 연출 이미지이며 실제 시스템 구성도나 측정 결과가 아닙니다.

핵심 정리
재시도는 같은 작업을 다시 시도할지 정하고, 서킷 브레이커는 실패가 이어지는 대상에 호출을 보내도 될지 정합니다. 두 기능을 함께 쓸 때도 요청 수와 실패 처리 정책을 따로 설계해야 합니다.

1. 실패한 한 요청과 대상의 반복 실패를 구분합니다

재시도는 개별 작업이 실패했을 때 다시 실행할지 판단하는 규칙으로 이해할 수 있습니다. 서킷 브레이커는 일정한 관측 조건에서 실패가 이어지는 의존 대상에 새 호출을 계속 보낼지 제어합니다.

가상의 배송 조회 서비스에서 한 번의 통신 오류와 외부 조회 서비스 전체가 응답하지 않는 상황은 대응이 다를 수 있습니다. 모든 오류를 같은 방식으로 반복하면 요청량만 늘어날 수 있습니다.

먼저 어떤 오류가 일시적일 수 있고 어떤 경우에는 다시 보내도 결과가 달라지기 어려운지 정합니다. 이 글의 예시는 동작을 설명하기 위한 가상 상황이며 특정 서비스에 적용할 횟수나 대기 시간을 권장하는 것은 아닙니다.

2. 정상 호출을 통과시키는 상태를 이해합니다

서킷 브레이커의 대표적인 설명에서는 Closed 상태에서 호출을 통과시키며 결과를 관찰합니다. 여기서 닫혔다는 말은 요청이 막혔다는 뜻이 아니라 전기 회로 비유에서 흐름이 이어진 상태를 가리킵니다.

실패 판단 기준과 관측 구간은 구현에 따라 설정해야 합니다. 가상의 테스트에서는 성공과 실패를 정해진 순서로 반환하는 가짜 서비스를 만들어 어떤 시점에 상태가 바뀌는지 볼 수 있습니다.

실제 운영 기준은 트래픽과 오류 특성에 맞춰 검증해야 하므로 문서의 예제 숫자를 그대로 쓰는 것만으로 충분하지 않습니다. 정상 상태에서도 관측하는 이유는 최근 결과를 바탕으로 다음 호출의 처리 방향을 정하기 위해서입니다.

3. 차단 상태는 실패 가능성이 큰 호출을 빠르게 거절합니다

Open 상태에서는 보호 대상에 호출을 보내지 않고 빠르게 실패를 반환하는 방식이 대표적입니다. Microsoft의 패턴 문서는 이런 차단이 회복 중인 대상과 호출 측의 자원을 보호하는 데 도움을 줄 수 있다고 설명합니다.

하지만 차단 자체가 상대 서비스의 문제를 수리하는 것은 아닙니다. 가상의 화면에서는 배송 정보를 즉시 보여 줄 수 없다는 상태를 처리해야 합니다.

실패를 빠르게 받았다고 정상 데이터를 받은 것처럼 표시해서는 안 됩니다. 사용자에게 어떤 메시지를 보여 줄지와 나중에 다시 확인할 경로를 애플리케이션에서 정해야 합니다.

차단은 호출 제어이고 업무 결과의 대체 정책은 별도 설계입니다.

4. 회복 확인에는 제한된 시도가 사용될 수 있습니다

대표적인 Half-Open 상태에서는 일부 호출을 허용해 회복 여부를 살펴봅니다. 결과에 따라 정상 통과 상태로 돌아가거나 다시 차단할 수 있으며 구체적인 정책은 구현마다 다릅니다.

Microsoft 공식 설명은 회복 중인 서비스에 요청이 한꺼번에 몰리지 않도록 제한된 확인을 사용하는 취지를 설명합니다. 가상의 실습에서는 일정 시간 뒤 한정된 요청을 허용하고 성공과 실패 각각에서 상태가 어떻게 바뀌는지 기록할 수 있습니다.

이때 테스트 성공을 실제 외부 서비스의 완전한 회복 보장으로 해석하지 않습니다. 상태 전환을 언제 관측했고 어떤 요청이 허용되었는지 기록해야 동작을 설명하기 쉽습니다.

5. 재시도와 조합하면 실제 호출 수를 계산합니다

애플리케이션과 SDK, 프록시가 각각 재시도하면 사용자의 한 요청이 여러 실제 호출로 늘어날 수 있습니다. 서킷 브레이커를 어디에 두는지에 따라 관측하는 실패와 통과하는 시도 수의 의미도 달라질 수 있습니다.

가상의 구성도를 그려 사용자 요청부터 외부 호출까지 각 계층의 재시도 설정을 적어 보면 숨은 중복을 찾기 쉽습니다. 차단 상태에서 재시도를 반복하는 정책이 의도한 동작인지도 확인합니다.

수정 작업이라면 멱등성과 중복 실행의 영향도 따로 검토해야 합니다. 서킷 브레이커를 추가했다는 사실만으로 재시도 설계가 올바르게 바뀌는 것은 아니며 실제 호출 흐름을 기준으로 검증해야 합니다.

6. 실패 분류와 적용 범위를 명확히 합니다

모든 응답 오류를 외부 서비스의 장애로 볼지 생각해야 합니다. 사용자의 잘못된 입력과 대상의 일시적인 응답 실패는 다른 의미일 수 있습니다.

어떤 오류를 상태 판단에 넣는지와 어떤 호출들이 같은 브레이커를 공유하는지 문서화합니다. 가상의 예로 상품 조회의 실패 때문에 관련 없는 알림 기능까지 차단되면 적용 범위가 의도와 다를 수 있습니다.

반대로 너무 세분화하면 관측량이 적어 판단이 어려워질 수 있습니다. 특정 분류가 항상 정답이라고 정하기보다 실제 의존 관계와 트래픽을 보고 기준을 검토합니다.

테스트에는 오류 종류별 결과와 서로 다른 기능에 대한 영향 범위를 포함할 수 있습니다.

7. 대체 응답과 오래된 데이터의 의미를 정합니다

차단 중에 캐시를 보여 주거나 일부 기능만 제공하는 설계를 선택할 수 있지만 데이터의 성격에 맞는 판단이 필요합니다. 오래된 값이 허용되는 조회와 즉시 정확한 결과가 필요한 작업은 조건이 다릅니다.

가상의 상품 설명 화면은 일부 안내를 계속 보여 줄 수 있어도 재고 확정 같은 다른 작업은 같은 정책으로 처리하기 어려울 수 있습니다. 대체 값이라는 사실과 확인 시점이 중요하면 사용자에게 그 상태를 전달해야 합니다.

실패를 숨기기 위해 빈 값을 정상 결과처럼 내보내면 업무 판단이 어긋날 수 있습니다. 브레이커 상태와 애플리케이션의 응답 정책을 구분해 기록하면 장애 중에도 어떤 결과를 제공했는지 이해할 수 있습니다.

8. 상태 전환과 차단된 요청을 함께 관측합니다

외부 호출 오류뿐 아니라 브레이커가 열리고 닫힌 시점, 차단한 요청 수, 회복 확인 결과를 살펴봅니다. 외부 서비스가 회복했는데 차단이 오래 유지되는지, 상태가 너무 자주 바뀌는지도 확인할 수 있습니다.

학습용 실습에서는 정상, 반복 실패, 제한된 회복, 재실패 순서를 만들어 상태 기록과 실제 호출 수를 대조합니다. 이 실습의 기준은 운영 권장값이 아니라 코드가 의도한 흐름으로 움직이는지 확인하기 위한 것입니다.

실제 설정을 바꿀 때는 적용 날짜와 이유, 관측 결과를 남깁니다. 서킷 브레이커는 오류를 없애는 기능보다 실패가 이어질 때 시스템이 어떻게 행동할지를 정하는 도구로 이해하는 편이 정확합니다.

9. 자주 묻는 질문

Q1. 서킷 브레이커가 재시도를 대신하나요?

두 기능은 판단하는 대상이 다릅니다. 재시도는 다시 실행할지, 브레이커는 대상에 호출을 통과시킬지 제어합니다.

함께 사용할 때는 계층별 실제 호출 수와 실패 정책을 확인해야 합니다.

Q2. Open 상태가 요청을 허용한다는 뜻인가요?

대표적인 회로 비유에서는 반대입니다. Open은 흐름을 끊어 호출을 차단하고 Closed는 통과시키는 상태로 설명합니다.

사용하는 라이브러리의 상태 정의도 함께 확인합니다.

Q3. 기능을 추가하면 외부 장애가 해결되나요?

상대 서비스 자체를 수리하지는 않습니다. 실패 가능성이 큰 호출을 제어하고 회복을 관측하는 데 목적이 있습니다.

대체 응답과 사용자 안내는 애플리케이션에서 별도로 설계합니다.

Q4. 예제의 횟수와 시간을 그대로 사용해도 되나요?

실제 트래픽과 오류 특성에 맞는 검증이 필요합니다. 작은 예제 숫자는 상태 전환을 이해하기 위한 조건일 수 있습니다.

적용 범위와 관측 결과를 기록하며 조정합니다.

참고 자료

• Microsoft: Circuit Breaker 패턴