에이전트 워크플로우의 거버넌스 장벽: RAG 이후 우리는 왜 정체되어 있는가?
governance wall in agentic workflows. why are we stuck past rag?
핵심 요약
에이전트가 단순 정보 검색을 넘어 실제 작업을 수행할 때 발생하는 권한 관리 문제를 어떻게 해결할지 논의함.
- 권한 관리 문제 — 에이전트가 여러 시스템을 다룰 때 최소 권한 원칙을 적용하기가 매우 까다로움.
- 도구 수준 거버넌스 — 에이전트 단위가 아닌 도구별로 권한(자동/확인/차단)을 설정하는 방식이 대안으로 제시됨.
- 범위 좁히기 전략 — 보안 검토를 피하고 실무에 적용하기 위해 범용 에이전트보다 특정 목적의 에이전트를 선호함.
- 오케스트레이션 필요성 — 여러 에이전트를 관리할 수 있는 효율적인 오케스트레이션 계층의 부재가 성장을 가로막음.
에이전트 프로젝트 전반에서 똑같은 패턴이 계속 보임. 정보를 찾는 에이전트를 만드는 건 잘하지만, 실제로 뭔가를 하라고 시키는 순간(CRM 업데이트, 결제 트리거, 운영 데이터베이스 수정 등) 일이 멈춰버림.
에이전트가 여러 시스템을 건드릴 때 범위가 지정된 권한(scoped permissions)을 어떻게 처리하고 있음? HR 조회부터 DevOps 티켓까지 모든 걸 다루는 범용 에이전트를 만들면, 최소 권한 매핑이 금방 엉망이 되어버림.
혹시 소규모 팀을 넘어서면 넓은 '수평적' 에이전트를 안전하게 만드는 게 사실상 불가능하다고 느끼는 사람 있음? 아니면 그냥 수십 개의 작고 초세부적인 에이전트를 만들고, 누군가 쓸만한 오케스트레이션 계층을 내놓길 바라는 현실을 받아들여야 하는 걸까?

