API 거버넌스(API governance)는 기업이 실제로 제대로 해낸 일 중 하나입니다.

게이트웨이(Gateways), 속도 제한(rate limits), 인증(authentication), 버전 관리된 계약(versioned contracts), 관리되는 라이프사이클(managed lifecycle). 지난 20년 동안 이는 시스템 간 통합을 질서 있고, 안전하며, 관찰 가능하게(observable) 유지하는 임무를 수행해 왔습니다.

그 제어 단위는 API 호출입니다. 질문 또한 명확합니다. '이 클라이언트가 이 자격 증명(credential)을 가지고, 이 속도로, 이 엔드포인트(endpoint)를 호출하는 것이 허용되는가?'

그 질문은 시스템을 위해 만들어졌습니다. 에이전트(agent)는 전통적인 통합 클라이언트가 아니며, 에이전트의 가장 중대한 실패는 그 질문이 감지할 수 있는 수준에서 발생하지 않습니다.

모델이 가정했던 예측 가능성이 사라졌다

전통적인 통합은 상대적으로 안정적이고 선언된 흐름을 중심으로 설계됩니다. 확립된 비즈니스 목적을 위해 예상된 패턴으로 알려진 엔드포인트를 호출합니다. API 거버넌스는 바로 그 예측 가능성을 바탕으로 구축되었습니다.

에이전트는 선언된 역할이나 목표를 가질 수 있습니다. 하지만 에이전트는 실행 시점(runtime)에 자신의 행동 경로를 선택하며, 변화하는 컨텍스트(context)에 대응하여 도구(tools)를 조합합니다.

에이전트가 수행하는 모든 호출은 권한이 부여될 수 있고, 속도 제한 내에 있으며, 개별적으로는 규정을 준수할 수 있습니다. 하지만 그 결과로 조합된 결과물은 기업이 전혀 의도하지 않은 것일 수 있습니다.

그것이 바로 격차(gap)입니다. API 거버넌스는 일반적으로 호출 단위별로 집행됩니다. 에이전트가 초래할 수 있는 피해는 각각의 호출이 허용되는 상황 속에서, 일련의 호출 시퀀스(sequence)를 통해 나타날 수 있습니다.

두 번의 규정 준수 호출, 아무도 승인하지 않은 하나의 결과

고객 기록에 대한 읽기 권한과 이메일 전송 권한을 가진 에이전트를 가정해 봅시다.

두 기능 모두 정당하게 부여되었습니다. 둘 다 업무 수행에 필요할 수 있습니다. 엔드포인트 중심의 게이트웨이(endpoint-centric gateway)는 두 번의 규정을 준수하는 호출을 봅니다.

공유된 작업 컨텍스트(task context)와 시퀀스 상태(sequence state) 없이는, 게이트웨이는 해당 호출들만 보고 왜 두 번째 호출이 첫 번째 호출 뒤에 이어졌는지, 혹은 두 호출이 결합되어 일반적인 접근을 데이터 유출(data exfiltration)로 전환했는지 판단할 수 없습니다.

결여된 질문은 단순히 다음 호출이 허용되는지 여부가 아닙니다. '이 위임된 권한(delegated authority) 하에 이 작업을 수행하는 이 에이전트가, 지금 이 호출을 수행해야 하는가?'가 핵심입니다.

API 거버넌스 (API governance)는 호출이 허용되는지를 묻습니다. 역량 거버넌스 (Capability governance)는 에이전트가 해당 호출을 수행해야 하는지를 묻습니다.

더 정확히 말하면, 이 에이전트가 이미 수행한 작업과 여전히 적용되는 제약 사항을 고려했을 때, 이 작업을 위해 이 역량 (capability)을 행사할 수 있는지를 묻는 것입니다.

제어의 단위가 바뀌어야 합니다

API 거버넌스는 일반적으로 개별 인터페이스와 작업 (operations)에 대한 액세스를 제어합니다. 역량 (capability)은 하나 이상의 API, 도구 (tools), 데이터 소스를 통해 에이전트가 생성할 수 있는 행동 또는 결과입니다.

공격 표면 (attack surface)의 주요 부분은 단일 API가 아닙니다. 그것은 에이전트에게 노출된 도구들의 집합입니다. 왜냐하면 에이전트에게 권한을 부여할 때마다, 에이전트가 이미 보유한 권한을 이용해 설득당하여 수행할 수 있는 작업의 범위가 넓어지기 때문입니다.

최소 권한 (Least privilege) 원칙은 클라이언트가 어떤 API를 호출할 수 있는가의 문제가 아니게 됩니다. 그것은 에이전트가 어떤 작업을 위해, 얼마 동안, 어떤 역량들을 조합 (compose)할 수 있는가의 문제가 됩니다.

단순히 엔드포인트 (endpoint) 규칙을 추가하는 것만으로는 이 문제를 해결할 수 없습니다. 게이트웨이 (gateway)는 전통적으로 채널을 관리합니다. 역량 거버넌스는 위임된 작업, 에이전트가 사용할 수 있는 권한, 이미 취해진 행동, 그리고 제안된 다음 행동을 평가해야 합니다. 이는 실행 (execution) 범위 내에서 이루어지며 런타임 (runtime)에 강제됩니다.

이는 이미 엔터프라이즈 플랫폼에서 나타나고 있습니다

MuleSoft의 경우, Omni Gateway를 API, MCP, LLM 및 에이전트 트래픽을 위한 공통 제어 지점으로 포지셔닝하고 있습니다. 이는 게이트웨이, MCP, API 및 LLM 전반에 걸쳐 정책을 적용하고, 신원 (identity)을 전파하며, 에이전트 체인 (agent chain) 내의 모든 상호작용에 걸쳐 상관관계 ID (correlation IDs)를 전달합니다.

이러한 특성은 게이트웨이를 역량 거버넌스를 위한 실행 가능한 강제 지점 (enforcement point)으로 만듭니다.

하지만 체인을 재구성하는 것이 현재의 작업 상태가 다음으로 조합된 행동을 승인하는지를 결정하는 것과 같지는 않습니다. 제어의 위치가 새롭게 부상하고 있습니다. 거버넌스 모델은 여전히 성숙해져야 합니다.

API 거버넌스 (API governance)는 우리의 시스템들이 서로 안전하게 통신할 수 있도록 유지해 주었습니다. 에이전트 기업 (agentic enterprise)에는 에이전트가 어떤 문을 두드릴 수 있는지뿐만 아니라, 그 시스템들을 통해 작업자가 무엇을 할 수 있도록 허용되는지에 대한 거버넌스가 필요합니다.

이 글은 기업용 에이전트 아키텍처 (Enterprise Agent Architecture) 시리즈의 일부입니다. 이는 에이전트 인력을 비즈니스 (Business), 정보 (Information), 애플리케이션 (Application), 기술 (Technology)과 함께 다섯 번째 아키텍처 도메인으로 취급해야 한다는 논거를 다룹니다.

여기서 시작하세요: https://cognitivethoughtengine.com/eaa/part-1

포지션 페이퍼 (Position paper): Enterprise Agent Architecture: The Case for a Fifth Architecture Domain for the Agentic Enterprise

현재 운영 중인 에이전트 시스템에서 권한 범위 (capability scope)를 강제하는 것은 무엇입니까? 게이트웨이 (gateway)입니까, 에이전트 프레임워크 (agent framework)입니까, 아니면 아직 아무것도 없습니까?