AI 제품이 이미 실패하고 있는 상황에서도 모델 경로(Model Route)는 여전히 HTTP 200을 반환할 수 있습니다.

지연 시간(Latency)이 증가합니다.

구조화된 출력(Structured output)이 검증(Validation)에 실패하기 시작합니다.

도구 호출(Tool calls)이 신뢰할 수 없게 됩니다.

폴백(Fallbacks) 비용이 비싸집니다.

시스템이 성능이 저하된 동일한 경로로 계속해서 새로운 요청을 보내는 동안 사용자는 기다리게 됩니다.

이것은 재시도(Retry)의 문제가 아닙니다.

이것은 서킷 브레이커(Circuit breaker)의 문제입니다.

재시도가 항상 복구로 이어지는 것은 아닙니다

재시도는 실패가 일시적일 때 유용합니다.

네트워크 연결이 끊어지거나, 제공업체가 일시적인 429 오류를 반환하거나, 요청이 모델에 도달하기 전에 타임아웃(Timeout)이 발생하는 경우입니다.

하지만 경로 자체가 건강하지 않을 때 재시도는 해가 됩니다.

기본 모델 경로로 세 번의 요청을 보내는 코딩 워크플로우(Coding workflow)를 상상해 보세요:

1. 첫 번째 요청이 타임아웃됩니다.
2. 두 번째 요청이 유효하지 않은 JSON을 반환합니다.
3. 세 번째 요청은 시간이 너무 오래 걸려 사용자에게 보여줘야 하는 마감 시간을 놓칩니다.

동일한 경로에 네 번째 요청을 보내는 것은 신뢰성을 높이는 것이 아닙니다.

그것은 단지 더 많은 대기 시간, 더 많은 비용, 그리고 폴백(Fallback)을 위한 더 적은 시간만을 초래할 뿐입니다.

서킷 브레이커(Circuit breaker)가 하는 일

서킷 브레이커는 경로에 세 가지 상태를 부여합니다:

• Closed (닫힘): 요청이 경로를 정상적으로 사용할 수 있습니다.
• Open (열림): 경로가 현재 건강하지 않으므로 새로운 요청이 해당 경로를 피합니다.
• Half-open (반열림): 제한된 테스트 트래픽을 통해 경로가 복구되었는지 확인합니다.

목표는 간단합니다: 국소적인 경로 실패가 제품 전체의 실패로 이어지는 것을 방지하는 것입니다.

브레이커가 열리면, 애플리케이션은 적절한 작업을 승인된 폴백(Fallback) 경로로 보내거나, 긴급하지 않은 작업을 대기열에 추가하거나, 명확하게 성능이 저하되었음을 알리는 응답을 반환할 수 있습니다.

200 응답만으로는 충분하지 않습니다

AI 애플리케이션의 경우, API 성공 응답이 항상 사용자의 성공을 의미하지는 않습니다.

경로가 다음과 같은 결과를 생성할 때 해당 경로는 건강하지 않은 상태일 수 있습니다:

• 워크플로우 시간 예산을 초과하는 응답
• 스키마 검증(Schema validation)에 실패하는 JSON
• 불완전한 도구 호출(Tool calls)
• 저품질의 RAG 답변
• 반복적인 안전성 또는 콘텐츠 필터(Content-filter) 실패
• 비용이 많이 드는 폴백 체인(Fallback chains)
• 하락하는 성공적인 작업 비율(Successful-task rate)

유용한 서킷 브레이커(Circuit breaker)는 단순히 제공자(Provider)의 가동 시간(Uptime)뿐만 아니라, 워크플로(Workflow)에 중요한 영향을 미치는 결과들을 관찰해야 합니다.

브레이커의 범위를 신중하게 설정하세요

전체 제공자를 대상으로 하는 하나의 글로벌 서킷 브레이커(Global circuit breaker)를 열지 마세요.

문제는 다음 중 하나에만 영향을 미칠 수 있습니다:

• 하나의 모델 (one model)
• 하나의 리전 (one region)
• 하나의 API 경로 (one API route)
• 하나의 응답 형식 (one response format)
• 하나의 도구 호출 워크플로 (one tool-calling workflow)
• 하나의 모델 설정 (one model configuration)

예를 들어, 고객 지원 채팅(Support chat)에는 잘 작동하는 경로가 구조화된 추출(Structured extraction) 작업에서만 실패할 수 있습니다.

너무 광범위하게 차단하면 정상적인 용량(Capacity)까지 제거하게 됩니다. 반대로 너무 좁게 차단하면 실제 실패 패턴을 놓치게 됩니다.

적절한 범위는 대개 실제 위험 단위에 가깝습니다:

제공자(Provider) + 모델(Model) + 리전(Region) + 워크플로(Workflow) + 설정(Configuration)

장애 발생 전에 비정상 동작을 정의하세요

서킷 브레이커(Circuit breaker)에는 명시적인 조건이 필요합니다.

예를 들어:

text
다음 조건일 때 이 경로를 개방합니다:
...