에이전트 간 회로 차단기: 에이전트가 다른 에이전트를 호출할 때 무엇이 바뀌는가

§ 01 · 깨진 가정

재시도 로직, 타임아웃, 회로 차단기(circuit breakers) 같은 표준 신뢰성 도구 키트는 예측 가능한 실패 모드를 가진 API를 호출하는 것을 전제로 설계되었습니다. 429는 속도를 늦추라는 의미입니다. 500은 나중에 다시 시도하라는 의미입니다. 타임아웃은 서비스가 과부하 상태임을 의미합니다. 이러한 로직 중 어느 것도 호출하는 대상 자체가 에이전트일 때 발생하는 상황을 고려하지 않습니다. 즉, 오류 코드를 반환하는 대신 느리고 자신감 있게 실패하며, 잘 구성되었지만 그럴듯하게 틀린 답변을 반환할 수 있는 존재입니다.

── 잘못된 신호 ──

§ 02 · 표준 회로 차단기가 이를 포착하지 못하는 이유

회로 차단기는 오류율(error rate)이나 지연 시간(latency)에 따라 작동합니다. 자신감 있고, 형식이 맞지 않거나, 미묘하게 틀린 결과를 반환하는 에이전트 간 호출은 표준 회로 차단기가 감시하는 모든 메트릭에서 성공처럼 보입니다. 호출 자체가 실패한 것이 아닙니다. 단지 필요한 작업을 수행하지 않았을 뿐이며, 회로 차단기는 잘못된 신호를 보고 있기 때문에 이를 알 방법이 없습니다.

── 패턴 ──

§ 03 · 패턴

표준 오류율 차단기와는 독립적으로 작동하는 두 번째 실패 범주인 '품질 실패(quality failure)'를 추가해야 합니다.

1. 콘텐츠를 신뢰하기 전에 형식을 검증하세요. 외부 에이전트로부터 받은 모든 응답은 다운스트림에서 처리되기 전에 예상 스키마(expected schema)와 비교하여 확인됩니다. 이는 어떠한 의미론적 판단도 필요하기 전에, 품질 실패의 상당 부분을 저렴하게 포착합니다.

2. 스키마만 확인할 것이 아니라 의미론적 표류(semantic drift)를 위해 샘플링하세요. 매번 호출할 필요는 없고, 너무 비싸기 때문에 주기적으로 알려진 좋은 테스트 사례(known-good test case)를 외부 에이전트를 통해 실행하고 그 결과를 예상 답변과 비교합니다. 스키마는 유효하지만 올바른 것에서 벗어난 응답은 형식 검사를 통과하겠지만, 이 샘플링 과정에서는 실패하게 됩니다.

3. 오류뿐만 아니라 품질 실패에 대해서도 차단기를 작동시키세요. 검증이나 샘플링이 잘못된 결과를 감지하면, 회로 차단기 목적상 이를 500 에러와 동일하게 취급하여 백오프(back off)하거나 폴백(fall back)하거나 안전한 방식으로 처리해야 합니다.

4. 한 에이전트의 실패가 다른 에이전트의 사실(fact)처럼 조용히 전파되도록 두지 마십시오. 만약 agent A가 낮은 신뢰도(low-confidence) 또는 유효성 검사 실패 결과를 반환한다면, agent B는 이를 다음 결정을 내리는 데 사용할 근거 진실(ground truth)이 아니라 플래그가 지정된 불확실한 입력으로 받아야 합니다. 이 단계를 건너뛰는 다중 에이전트 시스템은 어떻게 잘못된 합의(false consensus)를 형성하는지 보여줍니다: 여러 에이전트가 각각 '올바르게' 작동하지만, 그 어떤 것도 오류로 플래그 지정하지 않은 나쁜 입력에 기반하여 작동합니다.

5. 실패한 에이전트에 의존하지 않는 폴백(fallback)을 유지하십시오. 캐시된 마지막으로 알려진 좋은 결과(last-known-good result), 더 간단한 결정론적 규칙, 또는 인간의 에스컬레이션 등 '같은 에이전트를 다시 시도하고 기대하는 것' 외의 모든 것이 해당됩니다.

── 복합되는 지점 ──

§ 04 · 이 점이 가장 중요한 곳

위험은 체인에 추가되는 에이전트가 늘어날수록 복합됩니다. 품질 회로 차단기(quality circuit breaker)를 갖춘 단일 에이전트 간 호출은 안전망입니다. 오직 마지막 단계만 무언가를 검증하는 4개 에이전트 파이프라인은 초기, 플래그 지정되지 않은 오류가 각 단계마다 점진적으로 더 확신에 찬 것처럼 보이게 되는 시스템이며, 이는 우리가 실제로 경험한 실패 모드입니다. 이 실패 모드는 체인 내의 어떤 단일 에이전트가 얻은 것보다 더 높은 확실성으로 잘못된 답에 도달하는 생산 다중 에이전트 배포에서 발생했습니다.

── 체크리스트 ──

§ 05 · 체크리스트

[ ] 모든 에이전트 간 호출에서 사용 전에 응답 형태(response shape)를 검증합니까?
[ ] 스키마 유효성(schema validity)뿐만 아니라 의미적 정확성(semantic correctness)을 샘플링합니까?
[ ] 품질 실패가 오류 코드처럼 회로 차단기를 작동시키나요?
[ ] 한 에이전트의 낮은 신뢰도 결과가 사실(fact)이 아닌 불확실한 것으로 하류에 전달되나요?
[ ] 방금 실패한 에이전트에 의존하지 않는 폴백 경로가 있습니까?

── 패턴 끝 ──

◆ 만약 귀하의 회로 차단기가 HTTP 상태 코드만 감시한다면, 이는 다중 에이전트 시스템에서 실제로 비용을 발생시키는 실패 모드를 보지 못하는 것입니다.

ORBIRESEARCH

원래 OrbiResearch Lab에 게시되었습니다. 저희는 orbiresearch.com에서 프로덕션 AI 에이전트를 구축합니다.