기능 플래그 킬 스위치: 반복 오류 후 자동 비활성화 전의 4가지 신호

헬스케어 AI 에이전트는 도구 호출을 재시도할 수 있으므로, 한 번 실패한 폴(poll)만으로는 작업 흐름 전체가 실패했다고 안전하게 말할 수 없습니다. 너무 일찍 비활성화하면 간헐적인 종속성이 유용한 임상 지원 경로를 제거할 수 있고, 너무 늦게 비활성화하면 루프가 지연 시간, 비용, 반복 오류를 계속 누적시킬 수 있습니다. 따라서 선택은 오류 카운터가 아니라 작은 상태 기계(state machine)여야 합니다.

요약: 집계된 건강 스냅샷을 폴하고 네 가지 신호—최소 볼륨, 오류 비율, 연속적인 실패 윈도우, 그리고 지연 시간 또는 비용 가드레일—를 요구하며, 불변의 감사 기록(immutable audit record)과 함께멱등성(idempotent) 비활성화 결정을 제출합니다. 평가와 플래그 변경을 분리해야 합니다. 복구는 종료(shutdown)와 다른 임계값을 가진 의도적이고 관찰 가능한 전환이어야 합니다. 이렇게 하면 롤백이 임상 워크플로우에 충분히 보수적이면서도, 통제 불능의 에이전트 루프를 제한할 수 있습니다.

기능 플래그 킬 스위치는 반복 오류를 어떻게 처리해야 할까요?

단순 카운트는 분모(denominator)를 무시합니다. 완료된 에이전트 실행 6회 중 5회의 오류는 5만 회 중 5회의 오류와 다른 상태를 나타내며, 심지어 동일한 로그 라인 5줄이라도 모두 하나의 재시도 실행에 속할 수 있습니다. 로그 이벤트를 세는 것은 시도(attempt)와 결과(outcome)를 혼동시키기도 하는데, 이는 에이전트가 느린 모델이나 임상 데이터 도구를 한 번 이상 호출하는 경우 정확히 중요하게 구분해야 할 차이점입니다.

agent_run_id와 같은 안정적인 작업 단위(stable unit of work)를 사용하고, 집계하기 전에 최종 결과(terminal outcomes)를 중복 제거해야 합니다. 각 관찰(observation)은 윈도우 경계(window boundary), 코호트 또는 릴리스 식별자(cohort or release identity), 완료된 실행 횟수(completed-run count), 실패한 실행 횟수(failed-run count), 지연 시간 통계(latency statistic), 팀이 선택한 회계 단위의 예상 비용(estimated cost in the accounting unit chosen by the team), 그리고 신선도(freshness)를 포함해야 합니다. 그러면 킬 결정은 두 가지 별개의 질문에 답할 충분한 컨텍스트를 갖게 됩니다: 이 기능이 피해를 주고 있는가, 그리고 그 증거는 믿을 만한가?

네 가지 입력값은 각기 다른 목적을 수행합니다:

1. 최소 볼륨(Minimum volume)은 아주 적은 샘플이 릴리스를 제어하는 것을 방지합니다.
2. 오류 비율(Error ratio)은 완료된 작업으로 실패를 정규화합니다.
3. 연속적인 불량 창(Consecutive bad windows)은 단일 노이즈 간격을 거부합니다.
4. 지연 시간 또는 비용 가드레일(latency or cost guardrail)은 기술적으로는 성공적이지만 운영상으로는 용납할 수 없게 되는 루프를 포착합니다.

이는 유용한 모니터링 규율을 반영합니다: 개별 카운터를 해석하기보다는 트래픽과 함께 오류 및 지연 시간을 관찰하는 것입니다. 의존성 경계(dependency boundary)에서 포화(Saturation) 또한 중요할 수 있지만, 응답이 실제로 동일하지 않은 한 같은 불리언(boolean)에 몰래 넣어서는 안 됩니다. 포화된 워커 풀은 적격성 제어(admission control)를 요구할 수 있고, 안전하지 않은 에이전트 릴리스는 롤백(rollback)을 요구합니다.

이러한 응답들은 분리해야 합니다.

폴러 전에 결정을 모델링하세요 (Model the decision before the poller)

평가기(evaluator)는 순수해야 합니다: 하나의 스냅샷을 입력받아 하나의 결정을 출력합니다. 폴링 스케줄링, 인증, 재시도, 그리고 변형은 그 외부에서 이루어져야 합니다. 이러한 분리는 사고 발생 시 중요합니다. 왜냐하면 운영자가 라이브 제어 평면(live control plane)에 연락할 필요 없이 정확한 증거를 정확한 정책 버전과 비교하여 재생할 수 있기 때문입니다.

다음 Go 예제는 비율과 비용 단위를 정수로 사용하여 제어 경로에서 부동 소수점 비교를 피합니다. 여기에 있는 숫자는 보편적인 임상적 또는 규정 준수 한계가 아닌, 설명적인 정책 입력 값입니다.

package killswitch

import "time"
...

여기에는 의도적인 비대칭성이 있습니다. 오래되었거나 크기가 작은 스냅샷은 누락된 원격 측정(telemetry)을 실패의 증거로 취급하기보다는 비활성화하는 것을 거부합니다. 하지만 침묵이 건강함을 의미하지는 않습니다. 폴러는 스냅샷이 오래되었을 때 별도로 경고해야 합니다. 그렇지 않으면 손상된 측정 경로가 잘못된 확신을 만들어내기 때문입니다.

정책에는 범위(scope)가 필요합니다. 요청을 일관되게 할당할 수 있다면, 가장 좁은 독립적으로 되돌릴 수 있는 코호트—예를 들어 단일 에이전트 배포 또는 단일 워크플로우—를 선호하세요. 전역 스위치는 더 간단하지만 영향을 미치는 범위(blast radius)가 넓어집니다. 코호트 스위치는 운영상의 기록 관리 비용이 더 들지만, 영향을 받지 않은 워크플로우를 보존하고 더 깨끗한 롤백 증거를 생성합니다. 임상 지원 시스템의 경우, 이것이 보통 더 방어 가능한(defensible) 선택입니다.

이 컨트롤러는 명확한 한계가 있습니다: 기능이 기본 워크플로우에서 격리될 수 없거나, 비활성화할 경우 유일하게 안전한 임상 경로를 제거하는 경우, 또는 사용 가능한 원격 측정 데이터(telemetry)로 에이전트 실행과 재시도 시도를 구별할 수 없는 경우에는 부적합합니다. 그러한 경우에는 자동 플래그 변경 대신 입실 제어(admission control), 고정된 저하 모드(fixed degraded mode), 또는 인간의 승인을 선택하세요. 트레이드오프는 증거보다 더 광범위한 영향을 미치는 자동 롤백을 피하는 대신 느린 개입입니다.

비활성화 효과를 정확히 한 번으로 만들기

네트워크는 정확히 한 번(exactly-once)의 전송을 보장하지 않습니다. 실질적인 목표는 정확히 한 번의 효과(effect)입니다: 동일한 결정에 대한 반복 제출은 하나의 비활성화 상태와 하나의 논리적 감사 이벤트로 수렴해야 합니다. 안정적인 결정 식별자—예를 들어 기능, 코호트, 정책 버전 및 위반 창 종료 시점—로부터 비멱등성 키(idempotency key)를 생성하세요. 폴링 시도 시간으로부터 파생시키지 마세요. 왜냐하면 모든 재시도는 새롭게 나타날 것이기 때문입니다.

짧은 타임아웃. 유한한 재시도.

이 변경 인터페이스는 평가자를 플래그 공급업체에 묶지 않으면서 비교 및 설정(compare-and-set) 의미론을 노출할 수 있습니다. 성공적인 응답은 '지금 변경됨'과 '이미 비활성화됨'을 구별해야 하며, 둘 다 수렴으로 간주되어야 합니다. 감사 싱크는 결정 키에 대한 고유성을 강제하고 결정하는 데 사용된 증거를 보존해야 합니다.

package killswitch

import (
...

이 간결한 샘플은 실제 트랜잭션 경계를 보여줍니다. 플래그 스토어가 상태를 변경하고 감사 쓰기(audit write)가 실패하는 경우, 재시도 로직은 기능을 다시 켜지 않으면서 누락된 감사 기록을 복구해야 합니다. 프로덕션 설계에서는 영속적인 결정 레코드와 워커(worker), 또는 결정을 수용하는 동일한 데이터베이스 트랜잭션에 속한 아웃박스(outbox)를 사용하고, 이를 제어 상태(control state) 및 감사 싱크(audit sink) 모두와 대조하여 조정해야 합니다. 두 개의 독립적인 시스템이 원자적으로 커밋된다고 가정하는 것은 더 위험한 예시가 될 것입니다.

감사 기록에는 증거(evidence), 정책 버전, 범위(scope), 행위자 식별자(actor identity), 타임스탬프, 이전 상태(prior state), 요청된 상태(requested state), 그리고 변이 결과(mutation result)가 포함되어야 합니다. 단순히 폴러(poller)에게 해당 필드가 사용 가능했다는 이유만으로 프롬프트, 환자 콘텐츠 또는 원시 도구 페이로드(raw tool payloads)를 포함해서는 안 됩니다. 보존 및 접근 제한은 싱크 주변의 정책에 속해야 합니다. 제어 증거(control evidence)는 두 번째 임상 데이터 저장소가 되지 않으면서 유용할 수 있습니다.

모든 재시도마다 경고하지 말고, 제어 경로에서 경고하기

반복적인 도구 호출 오류(tool-call errors)는 여전히 일반적인 원격 측정(telemetry)을 받을 자격이 있지만, 매 시도마다 페이지를 보내는 것은 노이즈를 만들고 재시도를 별개의 사고처럼 보이게 합니다. 상태 기계가 보류 중인 위반 상태(pending-breach state)에 진입할 때, 비활성화 결정이 수용될 때, 변이가 수렴하지 못할 때, 그리고 원격 측정이 오래되었을 때 경고해야 합니다. 이러한 이벤트는 운영자의 결정과 일치합니다.

메트릭, 구조화된 로그(structured logs), 추적(traces) 전반에 걸쳐 세 가지 식별자—에이전트 실행(agent run), 평가된 창(evaluated window), 그리고 비활성화 결정(disable decision)—를 연결 상태로 유지하십시오. 실행 식별자는 중복 제거를 지원하고; 창 식별자는 계산을 재구성하며; 결정 키는 재시도가 수렴했음을 증명합니다. 높은 카디널리티(high-cardinality)의 환자 또는 프롬프트 값을 메트릭 레이블에 넣는 것을 피하십시오. 상세한 증거는 불투명한 식별자(opaque identifiers)로 연결된 접근 제어 기록에 속해야 합니다.

운영 상태(Operational status)는 또한 에이전트 경계에서 네 가지 황금 신호(golden signals)를 보여줘야 합니다: 완료된 트래픽(completed traffic), 터미널 오류(terminal errors), 종단 간 지연 시간(end-to-end latency), 그리고 리소스 압력(resource pressure). 비용(Cost)은 이 워크로드에 대한 추가적인 가드레일이며, 이러한 신호들을 대체하는 것은 아닙니다. 루프가 모델을 반복적으로 호출하지만 결국 성공으로 돌아온 경우, 오류 비율은 녹색 상태를 유지할 수 있지만 지연 시간과 비용이 정책을 위반할 수 있습니다.

관측 가능성(observability)이 손상되었을 때 롤백(Rollback) 기능은 반드시 유지되어야 합니다. 감사 스트림(audit stream)에 진입하는 액션을 가진 인증된 수동 비활성화 경로를 제공하고, 폴러(poller)에 의존하지 않고 이를 테스트해야 합니다. 자동화는 응답 시간을 단축시키지만, 안전을 위한 유일한 경로가 되어서는 안 됩니다.

컨트롤러 배포 시 맹신해서는 안 된다

섀도우 모드(shadow mode)로 시작하십시오. 라이브 스냅샷(live snapshots)을 평가하고, 제안된 결정을 영구 저장하며, 경고를 발생시키지만 플래그 자체를 변경하지 마십시오. 각 제안을 기본 실행 결과와 비교하여 재시도가 하나의 결정으로 수렴하는지 확인해야 합니다. 이 단계에서는 윈도우 경계(window boundaries), 지연 도착한 결과(late-arriving outcomes), 코호트 할당(cohort assignment)이 컨트롤에 충분히 안정적인지도 밝혀줍니다.

다음으로, 재활성화는 수동으로 유지하면서 하나의 협소하게 범위가 지정된 코호트에 대해 자동 비활성화를 허용하십시오. 프로덕션 환경이 아닌 곳에서 네 가지 경우를 연습해야 합니다: 단일 일시적 오류(transient error), 최소 볼륨을 초과하는 반복적인 잘못된 윈도우, 오래된 원격 측정 데이터(stale telemetry), 그리고 성공적인 비활성화 후 손실된 승인(acknowledgement). 마지막 경우는 행복 경로 로직(happy-path logic)보다는 아이덴티티(idempotency)를 검증합니다.

마지막으로, 모든 수락된 결정이 일치하는 컨트롤 상태와 감사 증거(audit evidence)를 갖는다는 것이 조정(reconciliation)을 통해 입증된 후에만 범위를 확장하십시오. 복구 정책은 별도로 정의해야 합니다: 건강한 윈도우, 운영자 승인, 또는 둘 다를 요구합니다. 자동 재활성화에 종료 임계값(shutdown threshold)을 재사용하는 것은 경계에서 진동(oscillation)을 유발할 수 있으며, 타이머만으로는 배포가 복구되었는지 여부에 대해 아무것도 말해주지 못합니다.

결과로 생성된 컨트롤러는 의도적으로 보수적입니다. 이는 건강하지 않거나 통제 불능 상태인 임상 에이전트 루프를 중단시키고, 왜 그렇게 행동했는지 설명하며, 중복 폴링(duplicate polls)을 견딜 수 있습니다. 동시에 복구 과정은 명시적인 정책 하에 남겨둡니다. 이것이 롤백 메커니즘이 충족해야 할 표준입니다: 제한된 피해(bounded harm), 재현 가능한 증거(reproducible evidence), 그리고 누가 또는 무엇이 프로덕션 상태를 변경했는지에 대한 모호성이 없어야 합니다.

출처 (Sources)

참고문헌 (References):

• Google SRE Book, “Monitoring Distributed Systems”: https://sre.google/sre-book/monitoring-distributed-systems/
• Logback Manual, “Appenders”: https://logback.qos.ch/manual/appenders.html