요약(TL;DR)— 대부분의 프로덕션 AI 팀은 콘텐츠 중재 (content-moderation) 사고 모델을 사용하여 안전 계층을 구축합니다: 입력을 분류하고, 출력을 분류하며, 차단하거나 통과시키는 방식입니다. 하지만 실제로 프로덕션 환경에서 AI 시스템을 무너뜨리는 사고들은 분산 시스템 (distributed-systems)의 장애와 유사합니다—잘못된 상태를 증폭시키는 재시도 (retries), 에이전트 단계 전반에 걸친 연쇄 오류 (cascading errors), 롤백 경로가 없는 조용한 드리프트 (silent drift) 등이 그것입니다. 가드레일은 신뢰 및 안전 (trust-and-safety) 팀이 아니라 SRE (Site Reliability Engineering)로부터 배워야 합니다.

팀에게 프로덕션 환경에서 AI 안전을 어떻게 처리하는지 물어보면 거의 매번 똑같은 답변을 듣게 될 것입니다: 입력 분류기, 출력 분류기, 그리고 아마도 옆에 덧붙여진 중재 API (moderation API) 정도입니다. 이것이 콘텐츠 중재 (content-moderation) 사고 모델입니다—나쁜 것을 걸러내고, 나쁜 것을 내보내는 방식이죠. 이는 스팸 필터와 남용 탐지기를 구축하는 데 10년을 보낸 신뢰 및 안전 (trust-and-safety) 팀으로부터 통째로 빌려온 모델입니다.

하지만 이는 프로덕션 환경에서 실제로 AI 시스템을 망가뜨리는 대부분의 문제에 대해 잘못된 모델입니다. 새벽 2시에 당신을 호출하는 사고들은 분류기를 통과한 탈옥 (jailbreak) 같은 모습인 경우는 드뭅니다. 그것들은 분산 시스템 (distributed-systems)의 장애처럼 보입니다: 잘못된 도구 호출 (tool call)을 증폭시키는 재시도 루프 (retry loop), 모든 다운스트림 단계를 오염시키는 환각 (hallucinated)된 중간 결과, 고객이 3주 후에 불만을 제기할 때까지 아무도 알아차리지 못하는 출력 분포의 조용한 변화 등이 그것입니다. 이것들은 콘텐츠 문제가 아닙니다. 이것들은 시스템 문제이며, 시스템적인 솔루션이 필요합니다.

탈옥이 아닌 연쇄 반응 (The Cascade)

전형적인 에이전트 파이프라인을 생각해 보십시오: 컨텍스트 검색, 계획을 위한 모델 호출, 도구 호출, 합성을 위한 모델 재호출, 그리고 도구 실패 시 루프 실행 등이 있습니다. 각 단계에는 0이 아닌 오류율이 존재합니다. 단일 호출 챗봇의 경우, 그 오류율이 전체 리스크 표면 (risk surface)입니다. 하지만 5단계 에이전트 체인에서는 오류가 복합적으로 작용하며, 더 나쁜 것은 오류가 비선형적으로 복합화된다는 점입니다. 실패한 단계가 종종 재시도 (retries)를 트리거하고, 상태가 있는 동작 (stateful action)에 대한 재시도는 공짜가 아니기 때문입니다.

도구 인자 (tool argument)를 환각 (hallucinate)하는 모델은 단지 하나의 잘못된 출력만을 생성하는 것이 아닙니다. 이는 다음 단계가 마치 사실인 것처럼 추론하게 만드는 잘못된 상태 (bad state)를 생성합니다. 만약 그 다음 단계가 또 다른 LLM 호출이라면, 해당 모델은 문맥 (context) 내에 _이 전제가 조작되었다_라고 말해주는 것이 아무것도 없기 때문에, 오류를 지적하기보다는 그 오류를 바탕으로 자신 있게 논리를 쌓아 나갈 것입니다. 이는 마이크로서비스 아키텍처 (microservices architecture)에서의 재시도 폭풍 (retry storm)과 동일한 실패 형태입니다. 단일 구성 요소가 치명적으로 고장 난 것은 아니지만, 구성 요소 간의 상호작용이 작은 오류를 거대한 오류로 변질시킨 것입니다.

입력과 출력 경계에 위치한 가드레일 분류기 (Guardrail classifiers)는 이 과정을 전혀 보지 못합니다. 이들은 단일 턴 (turn)을 고립된 상태로 평가합니다. 이들에게는 상태 (state)에 대한 개념도, 폭발 반경 (blast radius)에 대한 개념도, "이 동작은 이제 되돌릴 수 없다"라는 개념도 없습니다. 모든 단계에서 완벽하게 규정을 준수하는 출력 분류기 (output classifier)를 갖추고 있더라도, 완전히 망가진 다단계 결과물을 내놓을 수 있습니다. 왜냐하면 실패는 단일 응답이 아니라 구성 (composition) 과정 속에 존재하기 때문입니다.

가드레일 또한 확률적입니다 — 그리고 아무도 이에 대한 예산을 세우지 않습니다

이 밑바닥에는 더 조용한 문제가 있습니다. 가드레일 분류기 그 자체도 오탐 (false positive) 및 미탐 (false negative) 비율을 가진 확률적 모델 (probabilistic models)이라는 점입니다. 팀들은 이를 통과(pass) 아니면 차단(block)이라는 이진 게이트 (binary gate)로 취급하지만, 실제로는 파이프라인 내의 또 다른 확률적 구성 요소 (stochastic component)이며, 그 오류 특성은 다른 모든 요소와 결합하여 증폭됩니다.

입력 필터 (input filter), 정책 모델 (policy model), 출력 필터 (output filter)와 같이 세 개의 분류기를 직렬로 쌓으면, 단순한 직관으로는 시스템이 세 배 더 안전해졌다고 생각하기 쉽습니다. 하지만 실제로 이 분류기들이 상관관계가 있는 사각지대 (correlated blind spots)를 공유한다면 (이들은 종종 유사한 데이터로 학습되거나, 말 그대로 프롬프트만 다른 동일한 베이스 모델인 경우가 많습니다), 여러분이 얻는 한계 안전 이득 (marginal safety gain)은 지불한 한계 지연 시간 (marginal latency) 및 비용보다 훨씬 작습니다. 설상가상으로, 오탐 (false positive)이 정당한 사용자 흐름을 망가뜨릴 수 있는 지점이 세 곳 더 늘어났으며, 자체적인 모니터링, 드리프트 추적 (drift tracking), 그리고 자체적인 온콜 런북 (on-call runbook)이 필요한 구성 요소가 세 개 더 추가된 셈입니다.

솔직한 프레임워크를 제시하자면: 가드레일(guardrail)은 벽이 아니라, 알려진 오류율(error rate)을 가진 센서입니다. 이 점을 명확히 인지하는 순간, 엔지니어링 질문은 "가드레일을 추가했는가"에서 "이 파이프라인 전체에 걸친 우리의 복합적인 미검출률(false-negative rate)은 얼마이며, 그 수치가 시간이 지나도 안정적인가"로 바뀝니다.

SRE가 이미 해결한 것들

사이트 신뢰성 공학 (Site Reliability Engineering, SRE)은 확률적 구성 요소 (probabilistic components), 연쇄 장애 (cascading failures), 부분적 성능 저하 (partial degradation)와 같은 바로 이 부류의 문제를 해결하기 위한 어휘와 도구를 구축하는 데 20년을 소비했습니다. 모델을 블랙박스 (black box)로 취급하는 것을 멈추고 불안정한 의존성 (flaky dependency)으로 취급하기 시작한다면, SRE의 대부분은 AI 시스템에 직접적으로 적용됩니다.

• 서킷 브레이커 (Circuit breakers): 만약 에이전트의 도구 호출 (tool-call) 성공률이 이동 평균 윈도우 (rolling window) 내에서 임계값 아래로 떨어지면, 에이전트가 자율적으로 재시도하는 것을 중단하고 사람에게 에스컬레이션하거나 안전한 폴백 경로 (fallback path)로 전환하십시오. 고장 난 단계가 계속해서 예산을 소모하고 상태 (state)를 악화시키도록 방치하지 마십시오.
• 폭발 반경 제한 (Blast radius containment): 단일 에이전트 동작이 영향을 미칠 수 있는 범위를 제한하십시오. 이메일 초안을 작성할 수 있는 모델과 만 명에게 이메일을 보낼 수 있는 모델은, 단지 동일한 프롬프트 템플릿 (prompt template)을 공유한다는 이유만으로 동일한 권한 경계 (permission boundary)를 공유해서는 안 됩니다.
• 카나리 평가 (Canary evaluation): 새로운 모델 버전이나 프롬프트 변경 사항을 트래픽의 100%에 배포하지 마십시오. 소수의 비율만 라우팅하여, 백엔드 배포 시 사용하는 것과 동일한 통계적 테스트를 통해 기존 모델과 출력 분포 (output distributions)를 비교한 다음 승격시키십시오.
• 세션 단위가 아닌 기능 단위의 킬 스위치 (Kill switches per capability, not per session): 재배포 없이 모든 세션에 걸쳐 특정 도구 또는 동작 유형을 즉시 비활성화할 수 있는 능력은, 프롬프트 기반의 거부 (prompt-based refusal) 계층을 하나 더 추가하는 것보다 훨씬 가치 있습니다.

이 중 그 어떤 것도 콘텐츠 모더레이션 (content moderation)을 대체하지는 않습니다. 불법적이거나 명백히 유해한 출력은 여전히 경계에서 차단되어야 하며, 이 비유의 그 부분은 유효합니다. 하지만 이는 실제 신뢰성 표면 (reliability surface)의 아주 작은 부분일 뿐입니다. 콘텐츠 모더레이션을 전체 표면으로 취급하는 것이 바로 팀들이 분류기 (classifier)가 결코 잡아낼 수 없었던 사고들에 계속해서 놀라는 이유입니다.

위반 사항뿐만 아니라 드리프트 (Drift)를 위한 관측 가능성 (Observability)

모더레이션 (Moderation) 로깅은 얼마나 자주 무언가를 차단했는지는 알려줍니다. 하지만 시스템의 정상적인 동작이 조용히 변화했는지에 대해서는 아무것도 알려주지 않습니다. 모델 업데이트, 컨텍스트 길이 (context length) 변경, 새로운 검색 소스(retrieval source) 등—이 중 어떤 것이든 안전 분류기 (safety classifier)를 전혀 자극하지 않는 방식으로 출력 분포를 변화시킬 수 있으며, 이는 품질을 저하시키거나 미묘하고 새로운 실패 모드 (failure modes)를 유발할 수 있습니다.

이는 모델 동작에 적용되는 통계적 공정 제어 (statistical process control)를 요구합니다. 출력 길이 분포, 도구 호출 (tool-call) 패턴, 거부율 (refusal rates), 그리고 신뢰도 프록시 (confidence proxies)를 시간에 따라 추적하고, 지연 시간 백분위수 (latency percentile)가 상승할 때 경고를 보내는 것과 동일한 방식으로 분포 변화 (distributional shift)에 대해 경고를 보내야 합니다. 드리프트 (Drift)는 안전 문제로 변하기 훨씬 전부터 신뢰성 문제이며, 그것이 안전 문제가 되었을 때는 이미 몇 주 동안 조용히 누적되어 온 경우가 대부분입니다.

진정한 변화

성숙한 단계의 AI 안전 공학 (AI safety engineering)은 더 거대한 분류기 스택을 쌓는 모습이 아닙니다. 그것은 당신이 모델이라고 부르는, 신뢰할 수 없고 확률적인 의존성 (dependencies)의 집합에 적용되는 SRE (Site Reliability Engineering) 규율의 모습에 가깝습니다. 맹목적인 재시도 (retries) 대신 서킷 브레이커 (Circuit breakers)를, 세션 범위 (session scope) 대신 폭발 반경 (Blast radius)을, 빅뱅 방식의 롤아웃 (big-bang rollouts) 대신 카나리 (Canaries)를, 위반 횟수 (violation counts) 대신 분포 모니터링 (Distributional monitoring)을 사용하는 것입니다.

콘텐츠 모더레이션 (Content moderation)은 실제 문제를 해결했지만, 동작하고, 체이닝 (chain)하며, 재시도하는 시스템을 위해 설계된 적은 없었습니다. 에이전트형 AI (agentic AI)를 위한 프로덕션 안전은 신뢰 및 안전 (trust-and-safety)의 가면을 쓴 분산 시스템 (distributed-systems) 문제입니다. 일단 그렇게 바라보기 시작하면, 가드레일 (guardrails)이 충분한지를 묻는 대신, 구성 요소 중 하나가 실패할 때—'만약'이 아니라 '언제' 실패하더라도—시스템이 우아하게 성능을 저하시키는지 (degrades gracefully)를 묻기 시작하게 될 것입니다.