서킷 브레이킹은 반복 호출을 중단하고 제어된 결과를 반환하며, 정상 트래픽을 복원하기 전에 복구 여부를 확인함으로써 장애가 발생한 외부 도구를 격리합니다.
로컬 에이전트는 클라우드 모델, 검색 API, 알림 서비스 또는 원격 스마트홈 브리지에 의존하는 동시에 워크플로의 나머지 부분은 정상적으로 실행할 수 있습니다. 격리 경계가 없으면 하나의 느린 종속성이 에이전트의 시간 예산을 소진하고 추가 재시도를 유발할 수 있습니다. 서킷 브레이커는 이 불확실한 원격 상태를 오케스트레이터가 판단할 수 있는 명시적인 로컬 상태로 변환합니다.
브레이커는 도구 선택과 외부 실행 사이에 위치합니다
에이전트는 일반적으로 도구를 선택하고 인수를 검증한 다음 실행기에 호출을 전달하며, 서킷 브레이킹은 이 마지막 경계에 상태를 유지하는 래퍼를 추가합니다. 모델이 요청한 내용 자체를 변경하는 것이 아니라, 실행기가 종속성에 연결해야 하는지, 로컬에서 시도를 거부해야 하는지, 제한된 복구 프로브를 허용해야 하는지를 결정합니다.
래퍼는 완료된 호출을 관찰하고 성공, 시간 초과, 전송 실패, 속도 제한 또는 구성된 기타 실패 신호와 같은 결과를 분류합니다. 일반적인 서킷 브레이커 패턴은 원격 호출을 감싸고 실패를 추적하며 임계값에 도달하면 회로를 열고 이후 테스트 요청을 허용하여, 종속성 상태를 모델의 프롬프트 수준 판단과 분리합니다.
따라서 즉시 반환되는 결과는 단순한 도구 예외가 아닙니다. 여기에는 브레이커 상태, 실행 시도 여부, 계속 진행할 수 있는 경로가 포함된 구조화된 오케스트레이션 결과가 담깁니다.
최근 실패는 상태 전환으로 압축됩니다
닫힌 상태에서 브레이커는 호출을 통과시키고 정책과 관련된 결과만 기록하므로, 단 한 번의 시간 초과가 유용한 도구를 반드시 비활성화하지는 않습니다. 구현에서는 일반적으로 최근 실패 횟수, 비율 또는 시간 창을 평가하며, 로컬 증거가 구성된 실패 또는 느린 호출 임계값을 넘어설 때만 회로를 엽니다.
임계값은 수많은 잡음 섞인 이벤트를 하나의 안정적인 제어 결정으로 변환합니다. 오류율 임계값은 네트워크 장애 중 연결이 계속 생성되는 상황을 제한하여, 요청된 모든 작업이 또다시 실패할 연결을 만들지 않도록 할 수 있습니다.
무엇을 실패로 간주할지는 도구의 계약에 맞아야 합니다. 인증 거부, 잘못된 인수, 영구적으로 존재하지 않는 리소스는 일반적으로 지연 시간, 일시적 사용 불가 또는 속도 제한과 다르게 처리해야 합니다.
백분율 임계값도 의미 있는 결과를 내려면 충분한 관측값이 필요합니다. 한 번의 실패 후 회로를 열면 사용 빈도가 낮은 도구가 불안정해지고, 반대로 큰 표본을 기다리면 자주 실패하는 종속성이 너무 오래 활성 상태로 남을 수 있습니다. 따라서 샘플링 창과 최소 호출 요건은 언어 모델이 아니라 브레이커 정책에 속해야 합니다.
열린 회로는 원격 대기를 로컬 실패로 전환합니다
브레이커가 열린 후 실행기는 명시적인 냉각 시간 동안 해당 종속성에 연결하지 않으므로, 새로운 시도는 또 다른 원격 시간 초과를 기다리는 대신 로컬에서 즉시 실패합니다. 정상적인 로컬 도구, 검색 단계 및 추론 과정은 장애가 발생한 종속성의 지연 시간을 물려받지 않고 계속 진행할 수 있습니다.
이 빠른 실패 경로는 지연뿐 아니라 리소스 압박도 억제합니다. 반복적인 원격 호출은 대기하는 동안 소켓, 작업자 슬롯, 메모리 또는 대기 중인 작업을 점유할 수 있기 때문입니다. 외부 호출 용량을 더 할당하기 전에 작업을 거부하면 지속적인 장애 중 리소스 고갈을 줄일 수 있습니다.
격리는 전역이 아니라 선택적으로 적용됩니다. 브레이커는 일반적으로 하나의 종속성에, 경우에 따라 하나의 작업 유형에 범위를 지정해야 합니다. 읽기와 쓰기는 실패 비용이 서로 다를 수 있기 때문입니다.
재시도와 시간 초과는 브레이커가 관찰하는 내용을 바꿉니다
재시도는 일시적이라고 판단되는 실패를 처리하는 반면, 서킷 브레이커는 실패가 지속되어 시도를 중단해야 할 정도가 되었음을 기억합니다. 따라서 두 기능의 배치 순서는 브레이커가 관찰하는 증거를 바꿉니다. 보호된 하나의 실행 내부에서 발생한 재시도는 하나의 논리적 호출로 계산될 수 있지만, 브레이커 외부의 재시도는 각각 또 하나의 실패 표본을 추가할 수 있습니다.
시간 초과는 느린 호출이 언제 실패 표본이 되는지도 정의합니다. 복원력 패턴에서 시간 초과, 재시도 및 서킷 브레이커를 분리하는 이유는 각 제어 기능이 서로 다른 실패 경계를 담당하기 때문입니다.
이러한 분리는 도구에 멱등성이 없는 부작용이 있을 때 특히 중요합니다. 동일한 반복적인 도구 호출 루프는 모델의 결정이나 모델 아래 계층의 재시도에서 발생할 수 있으며, 브레이커만으로는 시간 초과된 쓰기 작업이 외부 시스템을 이미 변경했는지 확인할 수 없습니다.
따라서 안전한 실행 경로는 재시도 예산과 브레이커 상태를 별도로 기록해야 합니다. 이를 통해 오케스트레이터는 작업이 전혀 시도되지 않았는지, 한 번 시도되었는지, 반복된 종속성 실패 후 차단되었는지를 설명할 수 있습니다.
폴백은 도구가 작동한 척하지 않으면서 워크플로의 의미를 보존합니다
회로를 여는 것은 기본 도구를 실행해도 되는지만 결정할 뿐이며, 오케스트레이터에는 여전히 사용자의 의도를 보존할 계속 진행 정책이 필요합니다. 작업에 따라 부분 결과를 반환하거나, 캐시된 읽기 데이터를 사용하거나, 다른 제공업체로 전환하거나, 작업을 대기열에 넣거나, 사람의 검토를 요청하거나, 작업을 중단할 수 있습니다.
폴백은 원래 결과인 것처럼 위장하지 말고 성능 저하 메타데이터를 포함해야 합니다. 다운스트림 단계는 오래된 캐시 콘텐츠나 대체된 증거를 기반으로 작동할 때 영향이 큰 작업을 제한할 수 있습니다.
일부 호출에는 안전한 폴백이 없습니다. 알림은 대기열에 넣을 수 있지만, 도어 제어 명령을 추측한 상태로 대체해서는 안 되며, 캐시된 인벤토리를 바탕으로 백업 삭제를 추론해서도 안 됩니다.
반개방 프로브는 재시도 폭주를 풀지 않고 액세스를 복원합니다
외부 도구가 복구할 수 있으므로 열린 회로가 영원히 트래픽을 차단한 채로 있을 수는 없습니다. 따라서 냉각 시간이 지나면 브레이커는 소수의 시험 호출만 허용합니다. 해당 프로브가 종속성이 다시 트래픽을 안전하게 수용할 수 있다는 증거를 제공할 때까지 정상 작업은 계속 차단됩니다.
프로브가 성공하면 브레이커는 닫힌 상태로 전환되고, 실패하면 회로를 다시 열어 대기 시간을 재시작합니다. 서킷 브레이커 상태를 모니터링하면 반복되는 개방과 긴 복구 기간을 도구 오류 속에 묻지 않고 확인할 수 있습니다.
성공적인 상태 확인 프로브가 이전 쓰기 작업을 안전하게 재실행할 수 있다는 뜻은 아닙니다. 종속성이 읽기 확인에는 응답하더라도 이전 부작용의 결과가 여전히 불명확할 수 있으므로, 멱등성 키, 체크포인트, 조정 및 승인 경계에 따라 중단된 작업을 재개할 수 있는지 결정해야 합니다.
프로브 허용 범위는 의도적으로 정상 트래픽보다 좁습니다. 수백 개의 대기 중인 요청이 한꺼번에 종속성에 도달하면 복구 증거의 유용성이 떨어지기 때문입니다. 동시 프로브 수를 제한하면 브레이커 자체가 급증을 만들어 새로 복구된 도구를 다시 비정상으로 보이게 하는 상황을 방지할 수 있습니다.
기술 및 AI 허브
더 읽어보기

홈 어시스턴트의 런타임 상태와 영구 상태: 재시작 후에도 무엇이 유지되어야 할까요?
Home Assistant는 모든 실시간 값을 영구 저장하지 않습니다. 구성, 레지스트리, 선택적으로 복원되는 상태, 기록, 배포 데이터는 재시작 시 서로 다른 역할을 합니다.

Home Assistant는 로컬 및 원격 세션을 어떻게 인증하나요?
로컬 및 원격 Home Assistant 세션은 동일한 서버 측 ID 모델을 사용합니다. 원격 액세스는 경로와 TLS 경계를 변경할 뿐, 핵심 토큰 흐름은 변경하지 않습니다.

Recorder 데이터가 늘어날수록 Home Assistant 기록 쿼리가 느려지는 이유는 무엇인가요?
요청한 범위가 더 많은 행에 걸쳐 있거나 캐시 미스가 증가하거나 스토리지 및 인덱스 작업이 느려지면 레코더의 증가로 인해 기록 조회 비용이 상승할 수 있습니다.

