잘 만든 AI 에이전트도 실패하는 이유 — 답은 ‘실행 거버넌스’

▲ 이미지: Unsplash (무료 저작권, 상업 이용 가능)

---

오케스트레이션 도구는 넘쳤다 — 그런데 운영이 터진다

2025년부터 2026년 사이 기업 AI 생태계에는 전례 없는 속도로 에이전트 빌딩 블록이 쌓였다. LangChain·LangGraph·CrewAI·Microsoft AutoGen, 그리고 OpenAI와 Anthropic의 자체 프레임워크까지 — 개발자는 이제 며칠 안에 복잡한 다단계 에이전트 워크플로를 구성할 수 있다. 어떤 도구를 어떤 순서로 호출하고, LLM 추론 루프를 어떻게 이어갈지, 멀티 에이전트 간 태스크를 어떻게 분기할지는 이 프레임워크들이 잘 처리한다.

그런데 현장에서 이야기가 달라지기 시작한 것은 “개발을 마친 에이전트를 실 운영 환경에 올렸을 때”다. Gartner는 2026년 6월 기준 전망에서 아젠틱 AI 프로젝트의 40% 이상이 2027년 말까지 취소될 것이라고 예측했으며, 그 핵심 원인으로 부적절한 리스크 컨트롤을 꼽았다(InfoWorld, James Urquhart, 2026-06-23). 취소는 기술 실패가 아니다 — 거버넌스 설계 실패다.

프레임워크가 하지 않는 일 — 아키텍처 차원의 공백

LangGraph의 공식 문서는 자신의 역할을 명확히 규정한다: “에이전트 오케스트레이션에만 집중하는 저수준 런타임”. 실제로 LangGraph가 제공하는 것은 결정론적 단계와 LLM 기반 아젠틱 단계를 혼합한 그래프 실행, 내구성(durable execution), 스트리밍, 체크포인트다. 그런데 공식 문서 어디에도 권한 관리(authorization), 감사 로깅(audit logging), 실행 범위 제한(scope control)은 등장하지 않는다. 유일한 가시성 도구는 외부 플랫폼 LangSmith뿐이며, 이는 LangGraph의 내장 기능이 아니다.

Urquhart가 InfoWorld 칼럼에서 정리한 개념이 바로 이 공백이다: 현재 에이전트 프레임워크는 “어떤 도구를 호출하고 어떻게 시퀀싱할지”는 결정하지만, “어디서, 어떤 조건에서 실행해도 되는가”는 다루지 않는다. 고객지원 트랜스크립트를 에이전트가 요약하는 시나리오를 예로 들면: 그 데이터에 유럽 거주자 정보가 들어 있는가? GDPR이 적용되는가? 어떤 모델이 그 데이터를 처리해도 되는가? 이 결정이 나중에 감사 추적으로 남아야 하는가? — 이 질문에 LangChain도 AutoGen도 기본 답을 주지 않는다.

Anthropic이 표준화를 주도한 MCP(Model Context Protocol)도 마찬가지다. 2025년 11월 버전(2025-11-25)에서 OAuth 2.1 인증 흐름이 공식 명세로 포함되어 원격 서버 인증 기반은 마련됐다. 그러나 Stack Overflow 기술 블로그가 분석한 것처럼 서버 간(server-to-server) 인증은 핵심 명세에서 의도적으로 침묵하고 있고, 스코프 세분화(scope granularity)를 위한 Rich Authorization Request는 아직 커뮤니티 논의 단계다(Stack Overflow, 2026-01-21). InfoWorld의 Isaac Sacolick은 MCP가 “현재 거의 제로에 가까운 내장 보안”을 갖고 있다는 보안 전문가들의 발언을 인용했다.

실행 거버넌스란 무엇인가 — 구체적 요소 4가지

Urquhart는 이 공백을 메우는 개념으로 ‘실행 거버넌스(Execution Governance)’ 레이어를 제안한다. 에이전트 로직과 실제 실행 사이에 위치하는 독립 레이어로, 모든 액션을 조직 정책에 대조해 평가한다. 이 레이어가 다뤄야 할 구체 요소는 다음 네 가지다.

• 맥락적 인가(Contextual Authorization) — 단순히 “사용자 X가 리소스 Y에 접근 가능한가”를 넘어서, 에이전트·태스크·데이터셋·모델·위임 체인을 동시에 평가해야 한다. 동일한 사용자가 동일한 도구를 쓰더라도 에이전트의 목적·위임 경로에 따라 허용 여부가 달라진다.
• 온톨로지 기반 추론(Ontology-Based Reasoning) — “데이터에 PII가 포함돼 있음 → GDPR 적용 → EU 내 처리 필요”처럼, 개체 관계를 이해해 컴플라이언스 요건을 자동 추론하는 능력이 필요하다.
• 결정 출처 추적(Decision Provenance) — EU AI Act 제12조·제17조는 고위험 AI 시스템에 대해 추적 가능한 의사결정 기록을 요구한다. 인가 결정 자체가 감사 추적으로 남아야 한다.
• 최소 권한(Least Privilege) 집행 — 에이전트에게 기능 수행에 필요한 최소한의 권한만 부여하는 원칙. InfoWorld MCP 기사에서 Descope 공동창업자 Meir Wahnon은 이를 “좁은 스코프, 명시적 사용자 동의, 민감 액션의 휴먼-인-더-루프”로 구체화했다.

arXiv에 발표된 aiAuthZ: Off-Host, Identity-Bound Authorization for AI Agents(Kodathala, 2026) 논문은 이 방향의 학술적 접근을 보여준다. 에이전트 실행 환경 외부에서 암호학적 신원에 권한을 결합해 검증하는 구조를 제안하며, 현 프레임워크가 입출력 제어에 집중하다 신원 기반 인가를 놓친다는 점을 지적한다.

데이터가 말하는 현실 — 숫자로 보는 거버넌스 공백

거버넌스 설계 부재는 추상적 위험이 아니다. 실제 수치가 이를 뒷받침한다.

Kiteworks의 2026년 AI 에이전트 보안 사고 보고서에 따르면, 조사 대상 기업의 65%가 지난 1년간 AI 에이전트로 인한 사이버보안 사고를 경험했다. 사고 유형을 보면 민감 데이터 노출(61%), 업무 프로세스의 의도치 않은 행동(41%), 금전적 손실(35%) 순이었다. 더 심각한 것은 역량 공백이다: 63%의 기업이 AI 에이전트에 목적 제한을 강제하지 못하고, 67%는 감사 추적을 갖췄다고 답했지만, 사고를 재구성할 수 있는 증거 수준의 로그를 갖춘 곳은 일부에 불과했다.

OWASP GenAI Security Project가 2025년 12월 발행한 OWASP Top 10 for Agentic Applications 2026은 100명 이상의 전문가·연구자가 검토한 위협 프레임워크다. 10개 위협 중 거버넌스·권한 공백에 직결된 항목만 추려도 세 개가 눈에 띈다: ASI03 신원 및 권한 남용(Identity and Privilege Abuse — 2025~2026 기업 에이전트 사고의 세 번째로 자주 인용된 실패 패턴), ASI07 불안전한 에이전트 간 통신(암호화 무결성 검증 없는 메시지 스푸핑), ASI08 연쇄 장애(단일 보안 실패가 연결된 에이전트·도구를 타고 증폭 — 한 조달 에이전트가 허위 주문 320만 달러를 처리한 사례가 문서화됨).

과도한 권한 부여 문제는 특히 구조적이다. TierZero의 분석에 따르면 접근 범위(scope)는 AI 관련 사고를 가장 강하게 예측하는 변수였다. 최소 권한을 강제한 에이전트의 사고율이 17%에 그친 반면, 광범위한 권한을 가진 에이전트는 76%에 달했다.

중소기업 적용 체크리스트

대형 엔터프라이즈는 별도의 거버넌스 플랫폼을 도입할 수 있다. 중소기업은 자체 인프라 안에서 아래 항목을 직접 설계해야 한다.

• 에이전트별 최소 권한 스코프 정의 — 에이전트가 실제로 필요한 API·DB·파일 접근 목록을 문서화하고, 개발 단계에서 넓게 열었던 권한을 운영 배포 전 반드시 축소한다.
• 도구 호출 입력/출력 전체 로깅 — 모든 도구 호출의 입력·출력·호출 시각·호출 주체를 로그로 남긴다. 사고 발생 시 재구성 가능한 감사 추적이 없으면 원인 분석 자체가 불가능하다.
• 에이전트 신원(Agent Identity) 분리 — 에이전트가 사람 사용자 자격증명을 공유하거나 상속하지 않도록 한다. 에이전트 전용 서비스 계정과 토큰을 별도 발급하고 회전 주기를 설정한다.
• 민감 액션에 휴먼-인-더-루프(HITL) 강제 — 데이터 삭제, 외부 발송, 결제 등 되돌리기 어려운 액션은 에이전트가 단독 실행하지 못하도록 승인 단계를 삽입한다.
• 외부 데이터 처리 시 데이터 레지던시 확인 — 고객 데이터 소재 국가와 처리 서버 위치를 명시적으로 매핑하고, 클라우드 LLM API 호출 시 데이터 잔존 정책을 확인한다.
• MCP 서버 좁게 설계 — MCP 서버를 범용 API 게이트웨이로 만들지 않는다. 부서·기능별로 분리해 노출 범위를 최소화하고, 각 서버에 명시적 인증을 붙인다.
• 이상 행동 모니터링 임계값 설정 — 에이전트가 정해진 도구 이외를 호출하거나, 단위 시간 내 비정상적인 횟수의 액션을 시도할 때 알림이 발생하도록 설정한다.

---