기업용 AI 에이전트에도 이제 컨트롤 플레인(Control Plane)이 생겼습니다

생성 비용은 저렴하지만, 관리 비용은 비쌉니다.

Microsoft 365, Google Cloud, ServiceNow, Slack, 데이터 웨어하우스(data warehouses), 지원 대기열(support queues), 그리고 커스텀 애플리케이션에 추가되면서, 기업용 AI 에이전트는 시장이 운영하고자 하는 하나의 운영 자산(operating estate)이 되었습니다. 따라서 시장은 이제 채팅에서 에이전트가 응답하게 만드는 작은 기술보다는 에이전트의 운영 측면에 점점 더 집중하고 있습니다. 저는 방금 통합 레지스트리를 통해 에이전트를 관찰, 거버넌스 및 보안 측면에서 관리하도록 설계된 Microsoft Agent 365에 대해 읽었습니다. Google은 구축, 확장, 거버넌스 및 최적화를 위한 Gemini Enterprise Agent Platform을 발표했습니다. ServiceNow는 AI Control Tower에 대해 이야기하고 있습니다. LangChain은 소유권, 인증, 감사, 공유 및 권한을 위한 관리 계층으로서 LangSmith Fleet을 설명합니다.

우리가 주목해야 할 계층은 빌더(builder) 상단의 컨트롤 플레인(control plane)입니다.

빌더 계층만으로는 더 이상 충분하지 않습니다

기업용 AI의 첫 번째 단계에서는 비즈니스용 AI 에이전트를 빠르게 구축하는 데 초점을 맞췄습니다. 플랫폼 팀은 몇 분 만에 벤더 인테이크(vendor intake) 워크플로우 에이전트를 만들 수 있었습니다. 데이터 팀은 클릭 한 번으로 웨어하우스에서 데이터를 읽는 에이전트를 만들 수 있었습니다. 컨설팅 팀은 오후 안에 리서치 에이전트를 만들어 몇 분 만에 Slack에 배포할 수 있었습니다. 이제 초점은 누가 에이전트를 소유하는지, 시스템에 액세스하기 위해 누구의 자격 증명(credentials)을 사용하는지, 어떤 시스템을 건드리는지, 그리고 소유자가 떠나거나, 워크플로우가 변경되거나, 프롬프트가 드리프트(drift)되거나, 비용이 급증하거나, 에이전트가 구축된 도구가 폐기(deprecated)될 때 어떤 일이 발생하는지로 이동하고 있습니다.

에이전트 생성이 저렴해짐에 따라, AI 에이전트 관리라는 시급한 문제는 저절로 해결되지 않습니다. 비즈니스 팀은 워크플로 (workflow)를 정의합니다. 플랫폼 팀은 Jira 액션 (action)을 래핑 (wrap)합니다. 데이터 팀은 데이터 웨어하우스 (warehouse)에 대한 읽기 권한을 부여합니다. 컨설팅 팀은 Slack 리서치 봇을 구축합니다. 지난 분기까지만 해도 어려워 보였던 일들이 이제는 팀이 점심 식사 전에 요청할 수 있는 일이 되었습니다.

에이전트의 소유권은 누구에게 있습니까?

어떤 자격 증명 (credentials)을 사용합니까?

어떤 시스템에 접근할 수 있습니까?

소유자가 퇴사하거나, 워크플로 (workflow)가 변경되거나, 프롬프트 (prompt)가 드리프트 (drift)되거나, 비용이 급증하거나, 도구가 폐기 (deprecated)될 때 어떤 일이 발생합니까?

결과적으로, 에이전트 프로그램은 일반적인 애플리케이션 (applications)보다는 반자율적인 작업자 (semi-autonomous workers)에 더 가깝습니다. 이들은 메모리 (memory)와 운영 지침 (operating instructions)을 가지고 있습니다. 이들은 API를 통해 데이터에 접근하고 이를 조작합니다. 이들은 인간과의 협업 인터페이스 (collaboration surfaces)를 통해 작동하며, 이는 에이전트의 행동이 애플리케이션의 상태 (app state), 권한 (permissions), 승인 (approvals), 그리고 프론트엔드 런타임 표면 (frontend runtime surfaces)을 가로지르고 확산된다는 것을 의미합니다. 우리는 이전에 엔터프라이즈 에이전트가 서버를 떠나는 현상에 대해 작성한 바 있습니다. 동일한 문제가 한 단계 더 높은 수준에서 나타납니다. 기업에는 운영 중인 에이전트의 이름을 지정하고, 관리하고, 거버넌스 (govern)를 적용하며, 모니터링하고, 궁극적으로 은퇴(retire)시킬 수 있는 단일한 장소가 필요합니다.

컨트롤 플레인 (control plane)은 에이전트 생성이 운영 모델 (operating model)로 전환되는 지점입니다.

시장은 이미 이 누락된 계층의 이름을 붙였습니다

컨트롤 플레인 (Control Plane)을 바라보는 또 다른 관점은, 이를 기업용 AI 에이전트 집합을 위한 관리 인터페이스(administrative surface)로 보는 것입니다. 즉, 레지스트리 (registry), 소유자 (owner), ID (identity), 정책 (policy), 그리고 그 뒤를 따르는 모든 지루한 요소들을 포함하는 영역입니다. Microsoft의 Cloud Adoption Framework에 따르면 모든 에이전트는 관찰 가능해야 하며, 거버넌스 (governed)가 적용되어야 하고, 보안 (secure)이 유지되어야 합니다. 리더들은 조직 내의 AI 에이전트가 무엇인지, 누가 소유하고 있는지, 무엇을 하는지, 그리고 어떤 에이전트를 중단시켜야 하는지를 반드시 알아야 합니다. 이것은 프롬프트 엔지니어링 (prompt-engineering) 체크리스트이기 이전에 하나의 운영 모델 (operating model)입니다.

Agent 365는 이러한 아이디어들을 에이전트를 관리하기 위한 인터페이스로 구현합니다. 등록 (Register), 관리 (Manage), 권한 (Permissions), 정책 (Policies), 검토 (Reviews), Entra, Purview, Defender. 에이전트의 빌더 (builder) 또한 Agent 365의 관리 인터페이스에 의해 기업 내부에서 관리되는 또 다른 객체가 됩니다.

Google은 Vertex AI를 동일한 광범위한 컨트롤 플레인 관점으로 이동시키고 있습니다. Gemini Enterprise Agent Platform 발표에서는 에이전트 ID (Agent Identity), 에이전트 레지스트리 (Agent Registry), 에이전트 게이트웨이 (Agent Gateway), 런타임 (runtime), 메모리 (memory), 샌드박싱 (sandboxing), 런타임 모니터링 (runtime monitoring), 그리고 거버넌스 (governance)를 상세히 다룹니다. 빌드 (Build)와 연결 (connect)이 인터페이스에 위치한다면, 거버넌스 (govern), 최적화 (optimize), 모니터링 (monitor)은 이를 기업용 플랫폼으로 만드는 동사들입니다.

ServiceNow는 운영 (operations) 관점에서 이 문제에 접근합니다. 섀도 AI (Shadow AI), 도입 문제, 규모 확장에 따른 비효율성, 그리고 파편화된 데이터 문제를 모두 해결해야 합니다. AI 거버넌스 벤더가 AI 관리 방법까지 설명하는 것은 놀라운 일이 아닙니다. AI Control Tower를 통해 IT 및 비즈니스 리더들은 무엇이 배포되었는지 확인하고, 모델 및 관련 스킬의 사용 현황을 검토하며, 해당 작업이 회사의 전략과 일치하는지 질문할 수 있습니다.

LangChain의 Fleet 포스트는 에이전트 프로그램 제작이 쉬워지면서 발생하는 혼란에서 시작됩니다. 진짜 어려운 문제는 누가 어떤 에이전트를 소유하는지, 도구(tools) 간에 어떻게 인증(authenticate)하는지, 누가 에이전트의 활동을 감사(audit)할 수 있는지, 그리고 우수한 에이전트를 어떻게 안전하게 공유할 것인지에 관한 것입니다. 다시 한번 같은 형태가 반복됩니다. 레지스트리(Registry), ID(Identity), 권한(Permissions), 감사(Audit), 공유(Sharing). 빌더 계층(builder layer)이 마침내 임계 질량(critical mass)에 도달했기 때문에 컨트롤 플레인(control plane)이 등장하고 있습니다.

확산(Sprawl)은 실패 모드입니다

저는 기업용 AI가 도구 접근 권한을 가진 채 모호한 목적, 확장되는 범위, 그리고 방치된 소유자를 가진 반자율적(semi-autonomous) 작업자로서 관리되지 않는 작업자 자산(worker estate)이 될 때 실패한다고 주장합니다. 이러한 기업용 AI 에이전트들은 공유된 ID를 가지고, 감사 추적(audit trails)이 거의 없거나 아예 없으며, 비용이 조용히 증가하고, 업무가 중복되며, 은퇴시키거나 폐기(decommission)할 명확한 방법이 없습니다. 챗봇의 당혹스러운 말실수 하나는 모두가 보게 되지만, 도구 접근 권한을 가진 관리되지 않는 작업자 자산은 반드시 거버넌스(governance)를 통해 관리되어야 하는 대상입니다.

한 거버넌스 성숙도 논문은 이를 에이전트 확산(agent sprawl): 비즈니스 기능 전반에 걸쳐 중복되고, 관리되지 않으며, 충돌하는 에이전트들이라고 부릅니다. 헬스케어 라이프사이클(lifecycle) 논문은 규제 대상 버전을 다음과 같이 설명합니다: 중복된 에이전트, 불분명한 책임 소재, 일관되지 않은 통제, 원래 사용 사례를 넘어 지속되는 도구 권한, 그리고 자격 증명(credential) 취소 및 감사 로깅(audit logging)과 연계된 폐기(decommissioning). 두 영역 모두를 관통하는 컨트롤 플레인 계층은 다음과 같은 유용한 요소들입니다: ID 레지스트리(identity registry), 중재(mediation), 경계 컨텍스트(bounded context), 런타임 정책(runtime policy), 라이프사이클(lifecycle), 폐기(decommissioning), 자격 증명(credentials), 감사 로깅(audit logging).

거버넌스(Governance)는 실행 경로(execution path)를 따릅니다. 이전 내용이 중요한 이유는, 명문화된 정책만으로는 벤더 도입(vendor-intake) AI가 새로운 도구를 통해 방금 이메일 권한을 얻었다는 사실을 결코 알 수 없기 때문입니다. 3개월 전의 출시 승인은 다른 지역에서 동일한 영업 조사(sales-research) 에이전트를 사용하고 있다는 사실을 알지 못합니다. 정적인 스프레드시트는 두 팀이 서로 다른 점수 산정 방식을 사용하여 갱신 리스크(renewal risk)를 계산하는 에이전트를 구축했다는 사실을 결코 알 수 없습니다.

에이전트는 경로를 통해 동작합니다. 따라서 컨트롤 플레인(control plane)은 반드시 해당 경로 근처에 존재해야 합니다.

모든 기업용 AI 문제를 해결하기 위해 단일한 거대 플랫폼을 구축하는 대안으로서, 컨트롤 플레인은 이미 주변에 존재하는 기본적인 데이터 구조와 운영 체제들로부터 조립될 수 있습니다: 신원(identity), 레지스트리(registry), 게이트웨이(gateway), 관찰 가능성(observability) 데이터, CI 프로세스, 런타임 정책(runtime policy), 그리고 기존의 플랫폼 관리 데이터가 그것입니다. 기업은 이를 Microsoft, Google, ServiceNow, LangSmith 또는 자체 내부 플랫폼 내에서 실행할 수 있습니다. 중요한 점은 조직 내 누군가가 컨트롤 플레인, 에이전트 인벤토리(inventory of agents), 그리고 해당 인벤토리에 대한 액션 경계(action boundary)를 소유해야 한다는 것입니다.

신원(Identity)은 관리를 실시간 작업으로 전환합니다

에이전트 신원(Agent identity)은 대화가 구체화되기 시작하는 지점입니다.

Microsoft의 Agent 365 문서 공유 상세 내용에 따르면 세 가지 형태의 액세스가 기술되어 있습니다: 위임된 액세스(delegated access), 앱 에이전트 액세스(app agent access), 그리고 자체 사용자 신원을 가진 에이전트입니다. 세 번째 방식은 매우 까다롭습니다. 자체 신원을 가진 에이전트는 Teams, Outlook, Office 문서, SharePoint 및 OneDrive에 추가될 수 있습니다. 가드레일(guardrails)이 존재하지 않는 한, 에이전트는 시간이 지남에 따라 권한을 축적할 수 있으며 에이전트가 가진 전체 액세스 권한을 기반으로 응답을 받게 됩니다.

이것이 바로 런타임 경계(runtime boundary)입니다.

지속적인 정체성(persistent identity)을 가진 에이전트는 워크로드처럼 관리되어야 하는 1인 규모의 노동력입니다. 에이전트는 목적, 소유자, 범위, 라이프사이클(lifecycle)을 거쳐야 하는 자격 증명(credentials), 그리고 에이전트가 유용하거나 멍청한 행동을 한 뒤에 답변이 필요한 지루한 감사 질문들을 가지고 있습니다. 누가 변경을 수행했는가? 누가 에이전트를 호출했는가? 어떤 정책이 도구 호출(tool call)을 허용했는가? 에이전트가 어떤 데이터에 접근할 수 있었는가? 에이전트가 해당 결정에 도달한 과정을 보여주는 트레이스(trace)는 무엇인가? 새벽 2시에 작동시킬 수 있는 킬 스위치(kill switch)는 무엇인가?

또한 기업 내부의 AI를 바라보는 우리의 관점에서 핵심적인 것은 정책이 실행 경계(action boundary)에서 실행되어야 한다는 개념입니다. 행동 이후에 실행되는 정책은 팀이 사후 분석(post mortem)을 수행하게 만듭니다. 티켓 상태 변경, 파일 이동, 결제 작업, 데이터베이스 쿼리, 또는 고객 이메일이든 관계없이, 잠금 장치는 쓰기 작업(write operation)이 발생하기 전에 걸려 있어야 합니다.

다른 워크로드와 마찬가지로 AI 에이전트를 진정으로 관리한다는 것은 에이전트가 수행하는 작업에 대해 정체성(identity)부터 실행(action), 그리고 증거(evidence)까지 관리하는 것을 의미합니다.

라이프사이클은 생성보다 더 깁니다

컨트롤 플레인(Control plane)은 생성 이후의 모든 과정을 가시화합니다.

생성 이후의 작업은 지루해져야 합니다. 에이전트 등록, 소유자 할당, 목적 결정, 정체성 결합, 도구 및 데이터 소스 승인, 알려진 관리된 배포 경로를 통한 에이전트 배포, 런타임 환경에서의 동작 관찰, 비용 및 사용량 검토, 변경 사항에 대한 증거 업데이트, 에이전트가 잘못된 행동을 할 때의 일시 중단, 워크플로우가 사라질 때의 은퇴, 그리고 자격 증명 회수 등이 이에 해당합니다. 지루함이 핵심입니다. 지루함이 성장을 견뎌낼 것입니다.

생성(Creation)은 쉬운 단계입니다. 컨트롤 플레인(Control Plane)은 그 외의 나머지 생명주기(Lifecycle)를 관리합니다.

Microsoft의 manage-agents 가이드는 '생성'과 '등록'을 기업용 용어인 통합(integrate), 관리(manage), 운영(operate), 표준화(standardize), 보안(secure), 준수(comply), 폐기(retire)로 변환합니다. 에이전트는 배포, 운영, 표준화, 비용 관리, 보안, 준수 및 폐기를 갖춘 관리형 자산으로 전환되어, 고립된 파일럿 단계에서 벗어나야 합니다. 이러한 감독이 없다면, Microsoft는 섀도 AI(Shadow AI)의 확산, 예산 초과, 그리고 사용되지 않는 에이전트로 인한 공격 표면(Attack Surface)의 확대를 경고합니다.

이러한 패턴은 AI 이전부터 존재했습니다. 클라우드(Cloud), SaaS, RPA, 그리고 Kubernetes도 유사한 생명주기를 따릅니다. 처음에는 가속기를 갖게 된 초기 설렘이 있습니다. 하지만 이후 청구서가 도착하면, 그 속도감은 명명(naming), 소유자(owners), 정책(policies), 액세스(access), 모니터링(monitoring), 사고 대응(incident response), 그리고 생명주기 관리(lifecycle management)로 대체됩니다. 에이전트는 여기에 더 까다로운 요소를 추가합니다. 즉, 관리되는 객체(managed objects)가 작업에 대해 추론하고, 도구(tools)를 호출하며, 작업 간의 컨텍스트(context)를 유지할 수 있다는 점입니다.

AI를 위한 신비롭고 새로운 거버넌스(Governance) 규율이 필요한 것은 아닙니다. 런타임(Runtime) 환경에서 새로운 유형의 행위자(Actor)가 등장했을 뿐이며, 일반적인 운영 규율(Operating discipline)만으로도 충분합니다.

내가 살펴볼 것들