2027년까지 Agentic AI 프로젝트의 40%가 취소될 것이다: 거버넌스 프레임워크(Governance Frameworks)가 그들을

Gartner의 예측은 나쁜 모델에 관한 것이 아닙니다. 그것은 누락된 인프라 계층(infrastructure layer)에 관한 것입니다. Gartner는 2027년까지 Agentic AI 프로젝트의 40% 이상이 취소될 것이라고 예측합니다. 그 이유로 비용, 낮은 ROI(투자 대비 수익), 그리고 취약한 거버넌스(governance)를 꼽았습니다. 대부분의 팀은 "취약한 거버넌스"라는 말을 들으면 프레임워크를 찾습니다. 그들은 정책을 작성합니다. 검토 위원회를 구성합니다. 허용 가능한 출력(outputs)을 문서화합니다. 컴플라이언스(compliance) 보고서를 제출합니다. 하지만 이 중 그 어떤 것도 실제로 프로젝트를 죽이고 있는 실패 모드(failure mode)를 방지하지 못합니다.

아무도 말하지 않는 실패 모드
실제 운영 환경(production)에서 전형적인 Agentic AI의 실패는 다음과 같은 모습입니다: 파이프라인(pipeline)이 실행됩니다. 출력(output)은 합리적으로 보입니다. 예외(exceptions)가 발생하지 않습니다. 경고(alerts)도 울리지 않습니다. 세 단계 전, 에이전트(agent)가 해당 단계의 조건을 충족하지 못하는 상태(state)를 전달받았습니다. 그럼에도 불구하고 에이전트는 실행되었습니다. 그 결과 그럴듯해 보이지만 유효하지 않은 토대 위에 구축된 출력을 생성했습니다. 두 단계 후, 또 다른 에이전트가 그 출력에 따라 행동했습니다. 최종 결과가 나타날 때쯤이면, 오류는 추적할 수 없는 상태가 됩니다. 이것은 정책적인 의미에서의 거버넌스 실패가 아닙니다. 정책은 존재했습니다. 모델은 정렬(aligned)되어 있었습니다. 가드레일(guardrails)도 설치되어 있었습니다. 이것은 집행(enforcement)의 실패입니다. 에이전트가 제어권을 갖기 전에 상태(state)가 유효한지 아무도 확인하지 않았습니다.

거버넌스 프레임워크(Governance Frameworks)가 실제로 다루는 것
대부분의 AI 거버넌스 프레임워크는 두 가지 수준에서 작동합니다:
설계 시점 거버넌스(Design-time governance): 시스템이 무엇을 할 수 있는지에 대한 정책, 데이터 처리 요구 사항, 인간의 감독(human oversight) 요구 사항, 문서화 표준.
출력 시점 거버넌스(Output-time governance): 모델이 반환하는 내용에 대한 가드레일, 콘텐츠 필터링, 출력 검증(output validation).
두 가지 모두 필요하지만, 어느 것도 충분하지는 않습니다. 프레임워크가 지속적으로 놓치고 있는 세 번째 수준이 있습니다: 단계 경계에서의 런타임 집행(runtime enforcement) — 각 에이전트 단계로 진입하는 상태가 유효한지, 그리고 에이전트가 취하려는 행동이 현재의 런타임 컨텍스트(runtime context)를 고려했을 때 허용되는지를 확인하는 것입니다.

설계 시점 거버넌스(Design-time governance)는 "에이전트는 제한된 관할 구역(restricted jurisdictions)의 데이터를 처리해서는 안 된다"라고 말합니다. 출력 시점 거버넌스(Output-time governance)는 "제한된 관할 구역을 참조하는 출력을 표시(flag)하라"라고 말합니다. 런타임 강제 실행(Runtime enforcement)은 "이 에이전트가 실행되기 전에, 해당 관할 구역이 제한되어 있지 않은지 확인하라. 만약 제한되어 있다면 — 행동을 차단하고, 상태(state)를 보존하며, 감사 항목(audit entry)을 기록하라"라고 말합니다. 앞의 두 가지는 정책(policy)입니다. 세 번째는 강제 실행(enforcement)입니다. 강제 실행이 없는 정책은 문서에 불과합니다.

프로젝트가 취소되는 이유
40%의 취소율은 조직에 정책이 부족해서 발생하는 것이 아닙니다. 에이전틱 AI(agentic AI) 단계에 도달한 대부분의 조직은 이미 거버넌스 정책을 갖추고 있습니다. 프로젝트가 취소되는 데에는 세 가지 구체적인 이유가 있습니다:

1. 실패가 파멸적이기 전까지는 보이지 않습니다. 에이전트 파이프라인(agent pipelines)은 조용히 실패합니다. 공유 가능한 가변 상태(Shared mutable state)가 여러 번의 LLM 호출을 거치며 전달되는데, 각 호출은 정상적인 출력처럼 보이는 방식으로 해당 상태를 저하시킬 수 있습니다. 실패가 눈에 보일 때쯤이면, 이미 시스템 전체로 전파된 후입니다.

2. 재구성이 비용이 많이 들거나 불가능합니다. 멱등성(idempotency) 없는 재실행(Replay)은 위험합니다. 파이프라인이 실행 중간에 실패하면, 팀은 두 가지 선택에 직면합니다. 처음부터 다시 시작하여 부수 효과(side effects, 중복 API 호출, 이중 결제, 반복된 쓰기 작업 등)를 재실행할 위험을 감수할 것인지, 아니면 수동으로 조사할 것인지입니다. 대규모 환경(scale)에서는 어느 쪽도 용납될 수 없습니다.

3. 감사 추적(Audit trails)은 강제 실행을 증명하지 못합니다. 규제 기관과 컴플라이언스(compliance) 팀은 점점 더 "시스템이 무엇을 했는가"뿐만 아니라 "시스템이 행동하기 전에 제약(constrained)을 받았음을 증명할 수 있는가"를 묻고 있습니다. 출력을 로깅(logging)하는 것은 첫 번째 질문에 답할 뿐입니다. 두 번째 질문에는 답하지 못합니다.

누락된 계층
이러한 실패를 방지할 수 있는 인프라는 전통적인 소프트웨어에는 존재합니다. 다만 에이전트 파이프라인에 적용되지 않았을 뿐입니다.

전제 조건(Pre-conditions): 에이전트 단계가 실행되기 전에, 상태(state)가 요구되는 조건을 충족하는지 확인합니다. 충족하지 않는다면 — 단계를 거부하고, 상태를 보존하며, 전체 컨텍스트(context)를 포함한 구조화된 실패 이벤트(structured failure event)를 기록합니다.

정책 게이트(Policy gates): LLM 호출 전에, 현재의 런타임 컨텍스트(runtime context)를 고려했을 때 해당 행동이 허용되는지 평가합니다.

출력된 이후가 아니라, 호출(call) 이전에 수행해야 합니다. 만약 관할권(jurisdiction)이 제한되어 있다면, 모델은 실행조차 되지 않습니다. 토큰(tokens)이 소비되지 않으며, 부수 효과(side effects)도 발생하지 않습니다. 체크포인트(Checkpoints): 각 단계가 완료된 후, 상태(state)를 체크포인트에 기록합니다. 파이프라인이 실행 도중 실패하면, 마지막 체크포인트부터 재실행(replay)합니다. 이미 완료된 단계는 멱등성 키(idempotency keys)를 통해 건너뛰므로, 중복 실행이 발생하지 않습니다. 구조화된 감사 추적(Structured audit trail): 단순히 모델이 무엇을 반환했는지에 대한 로그뿐만 아니라, 각 단계가 실행될 때 어떤 조건이 참이었는지, 어떤 정책(policies)이 평가되었는지, 그리고 그것들이 통과했는지 혹은 실패했는지에 대한 기록을 포함합니다.

실제 적용 사례
무언가 잘못되었을 때, 강제 집행(enforcement) 기능이 내장된 파이프라인은 다르게 동작합니다:
[intake] ✓ pre: observation_present
[intake] ✓ post: normalized
[taxonomy] ✓ pre: normalized
[taxonomy] ✕ post: species_identified → ContractViolation → 실패 지점에서 상태 보존(state preserved) → DLQ(Dead Letter Queue) 항목 기록
stage: taxonomy
predicate: species_identified
context: { ...전체 상태 스냅샷... }
→ replay 가능 지점: taxonomy

실패는 발생한 정확한 지점에서 포착됩니다. 상태는 보존됩니다. 감사 항목(audit entry)에는 진단에 필요한 모든 정보가 포함됩니다. 실패 지점부터 재실행하더라도 이미 완료된 단계는 다시 실행되지 않습니다. 이를 표준적인 실패 모드와 비교해 보십시오: 운영 환경에서의 예외(exception) 발생, 로그에 남은 스택 트레이스(stack trace), 처음부터 다시 시작, 그리고 부수 효과가 문제를 일으키지 않기를 바라는 상황 말입니다.

거버넌스 프레임워크(Governance Frameworks)는 필요하지만 충분하지는 않다
이것은 거버넌스 프레임워크에 반대하는 논거가 아닙니다. EU AI 법(EU AI Act) 준수, 내부 감사 요구사항, 책임감 있는 AI(responsible AI) 정책 등 이 모든 것은 중요하며 반드시 필요합니다. 핵심 논점은 거버넌스 프레임워크가 40%의 취소율을 야기하는 실패 모드를 방지하기에는 잘못된 계층(layer)에서 작동한다는 것입니다. 정책 문서(Policy documents)는 에이전트 단계(agent steps) 이전에 실행되지 않습니다. 검토 위원회(Review committees)는 런타임 상태(runtime state)를 평가하지 않습니다. 컴플라이언스 보고서(Compliance reports)는 유효하지 않은 상태가 파이프라인에 진입하는 것을 막지 못합니다. 40%의 실패 그룹에 속하지 않을 팀은 가장 포괄적인 거버넌스 정책을 가진 팀이 아닙니다.

그들은 사전 조건(pre-conditions), 정책 게이트(policy gates), 체크포인트(checkpoints), 구조화된 감사 추적(structured audit trails)과 같은 강제 집행(enforcement) 기능을 사후 고려 사항이 아닌, 일급 기본 요소(first-class primitives)로서 파이프라인 자체에 구축한 팀들입니다. 거버넌스(Governance)는 무엇이 허용되는지를 알려줍니다. 강제 집행(Enforcement)은 허용된 것만이 실제로 일어나도록 보장합니다. 이 두 가지 사이의 간극이 바로 40%의 실패가 발생하는 지점입니다. 만약 당신이 에이전틱 AI (Agentic AI) 파이프라인을 구축하고 있으며 강제 집행 계층(enforcement layer)을 고민하고 있다면, DEED는 Python 에이전트 파이프라인을 위한 런타임 계약 엔진(runtime contract engine)입니다: 사전/사후 조건(pre/post conditions), 정책 게이트(policy gates), 체크포인트/재생(checkpoint/replay) 기능을 제공합니다. 의존성 없음(Zero dependencies). Python 3.10+ 지원. github.com/Deadly-Reiter/deed · pip install deed-runtime