에이전틱 컨트롤 플레인: 대규모 AI 에이전트 거버넌스

수십 년 동안 기존 소프트웨어는 사전 정의된 워크플로우를 중심으로 구축되었습니다. 에이전틱 AI는 자율성을 도입하면서 이러한 모델을 복잡하게 만듭니다.

권한이 부여된 엔터프라이즈 시스템에서 AI 에이전트는 위임받은 권한을 가진 행위자처럼 동작합니다. 에이전트는 거버넌스가 적용된 데이터를 읽고, SQL을 생성하고, 워크플로우를 업데이트하고, 기록 시스템을 변경하거나 다른 애플리케이션에서 작업을 트리거할 수 있습니다. 따라서 조직은 애플리케이션이 수행할 수 있는 작업뿐 아니라 에이전트가 데이터, 도구 및 비즈니스 프로세스 전반에서 취할 수 있는 다양한 경로까지 거버넌스해야 합니다.

이러한 제어가 프롬프트, 애플리케이션 설정, 서비스 계정 및 개별 통합에 분산되어 있으면 조직은 이를 일관되게 확인하거나 적용할 방법이 없습니다.

이것이 에이전틱 컨트롤 플레인의 역할입니다. 에이전틱 시스템을 위한 조정 및 거버넌스 계층입니다. Snowflake CEO Sridhar Ramaswamy는 에이전틱 제어 영역을 엔터프라이즈에 필요한 ‘누락된 계층’이라고 설명하며, 이 계층이 ‘지능을 승인된 엔터프라이즈 행동으로 전환’할 수 있다고 말했습니다.

에이전틱 컨트롤 플레인은 조직 전반에서 AI 에이전트를 배포, 운영, 모니터링 및 거버넌스하는 중앙 집중식 계층입니다. 에이전트 ID 관리, 런타임 정책 적용, 행동 관찰, 버전 등록, 거버넌스가 적용된 컨텍스트 제공 및 도구 액세스 제어를 위한 공통 방식을 제공합니다.

공유 거버넌스 계층이 없으면 에이전트는 구축된 환경의 한계를 상속하는 경향이 있습니다. 각 에이전트에는 자체 로그, 액세스 모델, 평가 방법 및 도구 권한이 있을 수 있습니다. 도입이 확산되면 조직에는 수많은 에이전트 런타임이 남지만, 어떤 에이전트가 존재하는지, 어떤 데이터에 액세스했는지, 어떤 작업을 시도했는지 또는 해당 작업에 어떤 정책이 적용되었는지 확인할 일관된 방법은 없습니다.

에이전틱 컨트롤 플레인은 기업이 이러한 에이전트를 연결된 운영 계층으로 거버넌스할 수 있도록 지원합니다. 에이전트 환경 전반에서 ID, 정책, 컨텍스트, 도구 액세스, 실행 및 감사 가능성을 조정합니다.

Ramaswamy는 다음과 같이 에이전틱 컨트롤 플레인의 중요성을 설명합니다. “에이전틱 기술을 효과적으로 활용하려면 기업에 모델과 애플리케이션 이상의 것이 필요합니다. 조직 전반에서 지능, 엔터프라이즈 데이터, 정책 및 실행을 조정해 에이전틱 응집력을 높일 수 있는 조정 계층, 즉 중앙 제어 영역이 필요합니다.”

‘컨트롤 플레인’이라는 용어는 시스템 아키텍처에서 유래했습니다. 한 계층이 작업의 구성 및 거버넌스 방식을 관리하고 다른 계층이 작업을 수행하는 구조를 의미합니다.

분산 시스템에서 데이터 영역은 작업이 수행되는 곳입니다. 요청이 처리되고, 데이터가 이동하며, 함수가 실행되고, 애플리케이션이 응답합니다. 컨트롤 플레인은 해당 작업의 구성 및 관리형 운영 방식을 관리합니다. AI 에이전트의 경우 데이터 영역은 각 에이전트가 추론하고, 도구를 호출하고, 컨텍스트를 검색하고, 출력을 작성하고, 작업을 완료하는 곳입니다. 컨트롤 플레인은 이러한 에이전트 런타임 위에서 작동하며, 에이전트 전반에 ID, 정책, 모니터링 및 수명 주기 제어를 적용합니다.

조직이 서로 다른 모델, 프레임워크 및 배포 방식을 사용하기 시작하면 이러한 분리는 더욱 중요해집니다. 공급업체 애그노스틱 제어 영역은 특정 모델 공급업체나 에이전트 프레임워크에 정책과 감사 가능성을 종속시키는 대신, 이러한 시스템 전반에서 일관된 거버넌스 계층을 엔터프라이즈에 제공합니다.

에이전트는 추론, 검색 및 도구 사용을 결합하므로 제어 영역은 작업이 실행되기 전에 누가 또는 무엇이 행동하는지, 어떤 컨텍스트를 사용할 수 있는지, 어떤 정책이 적용되는지, 언제 사람의 판단이 필요한지, 그리고 이후 결과를 어떻게 기록할지를 조정해야 합니다.

런타임 거버넌스 및 정책 적용

에이전트 정책이 설계 문서나 프롬프트 템플릿에만 존재한다면 그 가치는 제한적입니다. 런타임에서 제어 영역은 에이전트가 테이블을 검색하거나, 외부 도구를 호출하거나, 메시지를 보내거나, 기록을 업데이트하거나, 사람의 검토자에게 에스컬레이션해야 하는지 평가해야 합니다.

이러한 정책은 사용자, 에이전트, 데이터 분류, 호출되는 도구, 요청된 작업 및 워크플로우의 위험 수준에 따라 달라질 수 있습니다. 예를 들어 고객 서비스 에이전트는 승인 없이 사례 기록을 요약할 수 있지만, 환불, 계정 변경 또는 민감 정보 공개에는 추가 확인이 필요합니다. 런타임 거버넌스는 에이전트가 분석에서 행동으로 전환할 때 조직이 에이전트의 행동을 제한할 수 있도록 지원합니다.

에이전트에 검증 가능한 ID 부여

엔터프라이즈 에이전트에는 사용자, 모델 및 에이전트를 호스팅하는 애플리케이션과 분리된 ID가 필요합니다. 이러한 ID가 없으면 기본적인 감사 질문에 답하기 어렵습니다. 어떤 에이전트가 데이터에 액세스했나요? 어떤 사용자가 세션을 승인했나요? 어떤 서비스 계정이 도구를 호출했나요? 어떤 정책이 해당 작업을 허용했나요?

에이전트 ID는 AI 시스템에 Zero Trust 접근 방식을 적용할 수 있도록 지원합니다. 도구나 데이터 세트에 상시 액세스 권한을 부여하는 대신, 조직은 에이전트의 역할, 사용자의 권한, 작업 및 현재 정책 상태에 기반한 적시 액세스를 요구할 수 있습니다. 예를 들어 조달 에이전트는 소싱 워크플로우 중 승인된 공급업체 데이터를 읽을 권한은 가질 수 있지만, 관련 없는 계약 리포지토리에 액세스하거나 승인 없이 구매 주문을 보낼 권한은 가질 수 없습니다.

증명 역시 ID에 따라 달라집니다. 에이전트에 검증 가능한 ID가 있으면 시스템은 해당 ID에 연결된 기록을 생성할 수 있습니다. 이는 인시던트 검토, 규정 준수 보고 및 지속적인 평가에 필수적입니다.

에이전트 수명 주기 전반의 옵저버빌리티 표준화

에이전트 옵저버빌리티는 팀이 에이전트의 행동을 검사하는 데 필요한 트레이스, 지표 및 평가를 제공합니다. 제어 영역은 이러한 텔레메트리를 수집하고 에이전트, 워크플로우 및 환경 전반에 적용합니다.

에이전틱 워크플로우의 트레이스에는 검색 단계, 도구 호출, 중간 추론 Artifacts, 정책 확인, 승인, 재시도, 실패 및 최종 출력이 포함될 수 있습니다. 시간이 지나면 트레이스를 통해 에이전트가 도구를 과도하게 사용하는지, 관련 없는 컨텍스트를 검색하는지, 너무 자주 에스컬레이션하는지 또는 평가에 실패하는 출력을 생성하는지 확인할 수 있습니다.

제어 영역은 이러한 정보를 수집하고 검토하는 방식을 표준화합니다. 각 에이전트 프레임워크가 서로 다른 모니터링 뷰를 생성하는 대신, 엔터프라이즈는 에이전트 수명 주기 전반에서 일관된 행동 기록을 확보합니다. 개발, 테스트, 배포, 런타임 모니터링 및 폐기 단계가 이에 포함됩니다.

수명 주기, 버전 및 거버넌스가 적용된 컨텍스트 관리

도구 스키마, 모델 공급업체, 비즈니스 규칙 또는 데이터 소스가 변경되면 에이전트의 행동도 시간이 지나면서 달라집니다. 수명 주기 관리가 없으면 특히 에이전트가 여러 팀에서 운영될 때 어떤 버전의 에이전트가 실행되었는지, 어떤 컨텍스트를 사용했는지, 제어가 적용되었는지 추적하기가 더 어려워집니다.

제어 영역은 에이전트를 등록하고, 버전을 추적하고, 소유자를 연결하고, 배포 상태를 관리할 수 있는 공간을 제공합니다. 또한 에이전트가 사용하는 컨텍스트를 거버넌스하는 데도 도움이 됩니다. 많은 엔터프라이즈 워크플로우에서 가장 중요한 입력은 고객, 제품, 계정, 정책, 지표 및 프로세스 상태를 정의하는 거버넌스된 비즈니스 컨텍스트입니다.

예를 들어 파이프라인 상태에 대한 질문에 답하는 영업 에이전트에는 적격 파이프라인의 최신 정의, 승인된 계정 데이터에 대한 액세스 권한, 사용자의 권한에 대한 가시성이 필요합니다. 제어 영역을 통해 컨텍스트가 제공되면 에이전트는 임시로 만든 복사본이나 오래된 추출 데이터 또는 사용자가 제공한 파일이 아니라 거버넌스가 적용된 소스를 기반으로 작업할 수 있습니다.

Snowflake의 AI/ML 수석 제품 마케팅 매니저인 Leo Rodriguez는 컨텍스트 문제를 다음과 같이 명확하게 설명합니다. “AI 모델은 지능적입니다. 문제는 AI 모델에 비즈니스가 신뢰할 수 있는 비즈니스 컨텍스트가 자동으로 제공되지는 않는다는 점입니다. 정확한 답변을 얻으려면 모델이 엔터프라이즈 데이터를 대상으로 추론하는 데 필요한 정의, 관계, 권한 및 신뢰할 수 있는 소스를 제공해야 합니다.”

게이트웨이를 통한 모델 제어 및 도구 액세스

에이전트가 모델 및 도구와 상호 작용하면서 게이트웨이는 제어 영역의 실질적인 구성 요소가 됩니다.

• LLM 게이트웨이는 모델에 대한 액세스를 관리합니다. LLM 게이트웨이는 여러 공급업체에 걸쳐 요청을 라우팅하고, 키 및 예산 제어를 적용하며, 가드레일을 적용하고, 사용량을 수집하고, 로깅을 표준화할 수 있습니다. 여러 모델을 사용하는 조직의 경우 이 계층은 모델 액세스가 애플리케이션 전반에 단절된 자격 증명 집합으로 삽입되는 것을 방지합니다.
• MCP 게이트웨이는 에이전트와 도구 간 액세스를 관리합니다. Model Context Protocol(MCP)은 에이전트가 도구 및 외부 시스템에 연결할 수 있는 구조화된 방법을 제공하지만, 이러한 연결성은 정책 적용 범위도 확장합니다. 게이트웨이는 도구에 대한 액세스를 중개하고, 요청된 작업을 검사하며, 권한을 적용하고, 에이전트가 수행하려고 시도한 작업을 기록할 수 있습니다.

이러한 게이트웨이는 추론을 생성하는 모델 호출과 추론을 작업으로 전환하는 도구 호출이라는 에이전트 실행의 양쪽 측면을 제어 영역이 관리하도록 지원합니다.

선도적인 AI 연구자 Andrew Ng가 AI 에이전트와 에이전트형 추론의 부상을 설명하는 영상을 확인해 보세요.

제어 영역, 오케스트레이션 및 옵저버빌리티는 밀접하게 연관되어 있지만 서로 다른 문제를 해결합니다.

• 오케스트레이션은 실행을 조정합니다. 에이전트 워크플로우에서 오케스트레이션은 어떤 에이전트 또는 도구를 어떤 입력과 함께 어떤 순서로, 어떤 분기 로직에 따라 실행할지 결정합니다. 고객 온보딩을 위한 멀티 에이전트 시스템에서는 한 에이전트가 계정 데이터를 검증하고, 다른 에이전트가 규정 준수 요구 사항을 확인하며, 세 번째 에이전트가 킥오프 계획을 작성하도록 할 수 있습니다. 오케스트레이션 계층은 시퀀스와 핸드오프를 관리합니다.
• 옵저버빌리티는 발생한 일을 기록합니다. 옵저버빌리티는 팀이 에이전트 동작을 검사할 수 있도록 트레이스, 지표, 평가, 도구 호출 및 출력을 수집합니다. RAG 워크플로우가 근거가 부족한 답변을 반환하거나 에이전트가 도구를 반복적으로 호출하는 루프에 빠질 때, 옵저버빌리티는 개발자와 운영자에게 문제를 진단하는 데 필요한 증거를 제공합니다.
• 컨트롤 플레인은 두 계층 전반을 관리합니다. 컨트롤 플레인은 어떤 오케스트레이션 프레임워크가 워크플로우를 조정하거나 어떤 옵저버빌리티 시스템이 텔레메트리를 수집하는지에 관계없이 ID, 정책, 감사 가능성, 액세스 및 수명 주기 제어를 관리합니다. 실제로 컨트롤 플레인은 옵저버빌리티 데이터를 사용해 거버넌스 결정을 적용할 수 있으며, 실행 전, 실행 중, 실행 후에 오케스트레이션된 워크플로우에 정책을 적용할 수도 있습니다.

엔터프라이즈 AI 에이전트는 데이터 액세스, 비즈니스 프로세스 및 규정 준수 의무가 이미 존재하는 환경에서 작동하며, 이러한 조건을 준수해야 합니다.

에이전트가 엔터프라이즈 시스템 내부에서 작동한다면 그 위에 얹힌 수동적인 인터페이스가 아니라 해당 시스템의 주체와 마찬가지로 거버넌스의 적용을 받아야 합니다. 예를 들어 인간 분석가는 지역별 매출 데이터는 볼 수 있지만 고객 수준의 재무 조건은 볼 수 없을 수 있으며, 데이터 엔지니어는 개발 환경의 파이프라인을 변경할 수 있지만 검토 없이 이를 프로덕션 환경에 배포할 수는 없을 수 있습니다. 에이전트가 이러한 동일한 워크플로우를 지원하기 시작하면 제어 모델도 작업을 따라야 합니다.

가장 큰 위험은 에이전트가 갑자기 통제를 벗어나는 것이 아닙니다. 많은 경우 즉각적인 위험은 일관성 부족입니다. 한 에이전트는 전체 트레이스를 로깅하는 반면 다른 에이전트는 최종 출력만 저장합니다. 한 워크플로우는 역할 기반 권한을 사용하는 반면 다른 워크플로우는 광범위한 도구 자격 증명을 저장합니다. 시간이 지나면 이러한 차이로 인해 에이전틱 AI를 확신을 가지고 확장하기가 어려워집니다.

Rodriguez는 에이전트가 기업이 전통적으로 별도로 거버넌스를 적용해 온 데이터, 모델 및 서드 파티 도구라는 경계를 넘나들 때 제어 영역이 가장 중요하다고 설명합니다.

“가장 과소평가된 제어 영역의 기능은 데이터 거버넌스와 AI 거버넌스를 통합하는 것입니다. 많은 기업이 데이터 제어 영역과 AI 제어 영역을 서로 다른 경계로 취급합니다. 하지만 에이전트가 동일한 워크플로우에서 엔터프라이즈 데이터, 모델 및 서드 파티 도구를 사용하기 시작하면 이러한 제어 기능을 통합해야 합니다.”

컨트롤 플레인은 조직에 더욱 거버넌스가 적용되기 쉬운 아키텍처를 제공합니다. 새로운 에이전트는 소유자 및 버전과 함께 등록할 수 있습니다. 도구 액세스는 애플리케이션에 삽입하는 대신 중개할 수 있습니다. 프롬프트에 복사하는 대신 런타임에 정책을 적용할 수 있습니다. 감사 기록은 여러 시스템에 걸친 에이전트 활동을 추적할 수 있습니다. 인시던트가 발생하거나 규정 준수 관련 질문이 제기되면 기업은 발생한 일을 재구성할 수 있는 경로를 확보하게 됩니다.

규제 산업에서는 기록 자체가 출력만큼 중요해질 수 있습니다. 규제 대상 조직이 AI 에이전트의 기능을 활용하려면 필요한 경우 컨텍스트, 권한 부여, 정책 적용 및 인간 검토가 이루어졌음을 보여 주는 증거가 필요합니다.

컨트롤 플레인은 거버넌스가 적용된 데이터, 컨텍스트 및 정책과 가까운 곳에 있어야 합니다. 엔터프라이즈 AI의 다음 단계는 인텔리전스를 신뢰할 수 있는 엔터프라이즈 데이터에 연결하고, 업무가 수행되는 시스템 내부에서 이러한 인텔리전스를 여러 단계의 작업으로 전환하는 데 달려 있습니다.

많은 기업은 이미 데이터 파운데이션에 데이터 액세스 제어, 정책, 계보 및 공유 컨텍스트를 연결해 두고 있습니다. 에이전트가 비즈니스 정보에 따라 작업하기 시작하면 컨트롤 플레인은 거버넌스가 적용되지 않은 이동이나 분리된 애플리케이션 계층을 통해 민감한 컨텍스트를 라우팅하는 대신 이러한 제어 기능을 유지해야 합니다.

Snowflake CoWork는 거버넌스가 적용된 질의응답, 여러 단계의 작업 및 도구 기반 작업을 통해 비즈니스 사용자와 지식 근로자를 위한 제어 영역 기반을 제공합니다. Snowflake CoCo는 데이터 엔지니어링, 분석 및 AI 워크플로우를 위한 데이터 네이티브 AI 코딩 에이전트로서 동일한 기반을 빌더에게까지 확장합니다. 개발자, 데이터 엔지니어 및 AI 팀에게 이는 에이전틱 지원이 거버넌스가 적용된 업무가 이미 수행되는 환경의 외부에 존재하는 대신 Snowflake 데이터, 메타데이터, 계정 컨텍스트 및 거버넌스를 인식하며 작동할 수 있음을 의미합니다.

에이전트가 외부 도구 및 시스템에 연결되면서 거버넌스는 프롬프트와 데이터 권한을 넘어 에이전트가 수행하려는 작업까지 확장되어야 합니다. MCP 게이트웨이 및 이와 유사한 제어 지점은 도구 액세스를 중개하고, 권한을 적용하며, 에이전트가 수행하려고 시도한 작업을 기록할 수 있습니다.

엔터프라이즈 AI는 에이전트를 비즈니스 프로세스에 참여하는 거버넌스 대상 주체로 취급할 수 있을 때에만 확장됩니다. 컨트롤 플레인은 인텔리전스와 실행 사이를 연결하는 계층이 되어, 에이전트가 신뢰할 수 있는 비즈니스 컨텍스트에서 권한이 부여된 작업으로 이어지는 일관된 경로를 갖게 합니다.

에이전틱 AI는 엔터프라이즈 거버넌스의 범위를 변화시킵니다. 에이전트는 사용자 요청으로 시작할 수 있지만, 작업은 권한과 감사 가능성이 이미 중요한 거버넌스 적용 데이터, 도구 호출, 워크플로우 변경 및 비즈니스 프로세스를 빠르게 거칠 수 있습니다.

컨트롤 플레인은 데이터, 컨텍스트 및 작업을 거버넌스하는 동일한 기반을 통해 조직이 AI 에이전트 활동을 조정할 수 있도록 지원합니다. ID, 정책, 옵저버빌리티 및 수명 주기 제어는 각 에이전트 경험마다 별도의 검사로 다시 만들기보다 에이전틱 작업이 실행되는 방식의 일부가 됩니다.

에이전트가 늘어날수록 이러한 기반은 더욱 중요해집니다. 단일 어시스턴트는 로컬 애플리케이션으로 검토할 수 있지만, 에이전트 집합에는 각 에이전트가 사용할 수 있는 것과 수행할 수 있는 작업, 그리고 그 작업이 기록되는 방식을 관리할 수 있는 공유 방식이 필요합니다.

컨트롤 플레인 아키텍처를 구축하면 조직은 에이전트를 비즈니스 프로세스에 참여하는 거버넌스 대상 주체로 취급하고, 액세스할 수 있는 항목과 수행할 수 있는 작업, 작업이 추적되는 방식에 명확한 경계를 설정할 수 있습니다.