AI 컨트롤 플레인(AI Control Plane)이 새로운 섀도우 IT(Shadow IT)가 되고 있다

섀도우 IT (Shadow IT)는 과거에 승인 절차를 거치지 않고 구매한 SaaS 구독을 의미했습니다. 이에 대한 해결책은 조달 정책과 소프트웨어 카탈로그였습니다. 이는 거버넌스 계층 (governance-layer)의 솔루션으로 해결할 수 있는 애플리케이션 계층 (application-layer)의 문제였습니다. 현재 AI 도구에서 일어나고 있는 일은 그런 문제가 아닙니다. 이것은 전혀 조달의 문제가 아닙니다. **AI 컨트롤 플레인 (AI control plane)**이 조직 전반에 퍼지고 있는 이유는 아무도 이를 인프라 (infrastructure)로 분류하지 않았기 때문입니다. 그리고 아무도 인프라로 인식하지 못하는 인프라를 막을 수 있는 승인 워크플로우 (approval workflow)도 존재하지 않습니다.

대부분의 조직은 이미 AI 컨트롤 플레인을 배포했습니다. 단지 그것을 인프라로 분류하지 않았을 뿐입니다.

이것은 모델 거버넌스 (model governance)의 문제가 아닙니다. 이것은 인프라 권한 (infrastructure authority)의 문제입니다. 모델 거버넌스는 적절한 목적을 위해 적절한 모델이 실행되고 있는지를 묻습니다. 인프라 권한은 해당 모델이 실행되는 런타임 계층 (runtime layer)을 누가 소유하는지 — 누가 라우팅 (routing)을 관리하고, 누가 장애 도메인 (failure domain)을 정의하며, 새벽 2시에 보이지 않는 추론 계층 (inference layer)이 고장 났을 때 누가 복구 경로 (recovery path)를 소유하는지를 묻습니다.

섀도우 IT는 언제나 운영 권한의 문제였다

초기 섀도우 IT의 실패는 결코 조달에 관한 것이 아니었습니다. 그것은 운영 권한 (operational authority)에 관한 것이었습니다. 한 팀이 창고에 자체 파일 서버를 운영했을 때, 문제는 구매 주문서가 아니라 업데이트 주기, 백업, 액세스 모델 (access model), 또는 장애 대응 (failure response)을 책임지는 주체가 아무도 없었다는 점이었습니다.

통제되지 않는 인프라의 역사는 세 세대에 걸쳐 일관된 패턴을 따릅니다. 온프레미스 (on-premises) 시대의 섀도우 IT (Shadow IT): IT 부서 외부에서 조달되어 애플리케이션 계층 (application layer)에 존재하며, 폭발 반경 (blast radius)이 해당 팀의 워크플로로 제한되었습니다. 하이브리드 (hybrid) 시대의 클라우드 확산 (cloud sprawl): 승인된 카탈로그 외부에서 프로비저닝 (provisioned)된 인프라로, 프로비저닝 계층 (provisioning layer)에 존재하며, 폭발 반경이 비용과 보안 태세 (security posture)까지 확장되었습니다. 현재 시대의 AI 컨트롤 플레인 (AI control plane) 확산: 운영 권한 (operational authority) 외부에서 배포된 추론 런타임 (inference runtime)으로, 인프라 계층 (infrastructure layer)에 존재하며, 이에 접촉하는 모든 시스템에 걸쳐 구조적으로 복합되는 폭발 반경을 가집니다.

각 세대는 통제되지 않는 표면을 스택 (stack)의 한 계층 더 깊은 곳으로 이동시켰습니다. 각 세대는 이전 세대의 거버넌스 (governance) 모델이 포착하도록 설계되지 않은 실패 모드 (failure mode)를 생성했습니다. 조달 정책 (procurement policies)도 클라우드 거버넌스 프레임워크 (cloud governance frameworks)도 AI 컨트롤 플레인 확산을 포착하지 못하는데, 그 이유는 배포되고 있는 것이 카탈로그에 있는 도구가 아니기 때문입니다. 그것은 보이지 않는 인프라입니다.

"AI 도구를 배포한다"는 것이 실제로 배포하는 것

플랫폼 팀, 애플리케이션 팀, 또는 제품 팀이 "AI 도구를 배포할" 때, 실제로 프로덕션 (production)에 들어가는 것은 인프라 결정 사항들의 스택이며, 이 중 대부분은 명시적으로 결정된 적이 없습니다:

모델을 선택하고, 폴백 체인 (fallback chains)을 관리하며, 비용 계층 (cost-tier) 로직을 적용하는 추론 라우팅 계층 (inference routing layer). 추론 계층이 무엇에 접근할 수 있는지, 그리고 누구를 대신하여 접근하는지를 결정하는 인증 및 인가 경계 (authentication and authorization boundary) — 또는 그러한 경계의 부재. 추론 텔레메트리 (inference telemetry)를 캡처하거나 혹은 캡처하지 않는 관측성 파이프라인 (observability pipeline). 상태 유지 세션 로직 (stateful session logic), 검색 증강 (retrieval augmentation), 그리고 컨텍스트 윈도우 (context window) 동작을 처리하는 프롬프트 및 컨텍스트 관리 계층 (prompt and context management layer). 에이전트 기반 배포 (agentic deployments)에서는 도구 호출 (tool calls)을 체이닝하고, 실행 순서를 관리하며, 다음에 무엇을 실행할지 결정하는 에이전트 오케스트레이션 런타임 (agent orchestration runtime). 비용 및 할당량 강제 계층 (cost and quota enforcement layer) — 또는 그러한 계층의 부재. 부분적 장애 상황에서의 동작을 규정하는 재시도 및 폴백 모델 (retry and fallback model).

이 각각은 인프라 결정 사항입니다. 이들을 총칭하여 AI 컨트롤 플레인 (AI control plane)이라 부릅니다. 즉, 추론 인프라가 무엇을 하는지, 어떻게 변화하는지, 그리고 변화를 일으킬 권한이 누구에게 있는지를 결정하는 계층입니다. 이 중 그 어느 것도 조달 카탈로그 (procurement catalog)에는 나타나지 않습니다. 하지만 이 모든 것들이 프로덕션 (production) 환경에서 실제로 작동하고 있습니다.

차원 (Dimension)	섀도우 IT (과거)	섀도우 AI 컨트롤 플레인 (현재)
거버넌스 범위 (Governance surface)	소프트웨어 조달 카탈로그	추론 런타임, 라우팅 및 오케스트레이션 계층
...

폭발 반경 (blast radius) 열은 이 비유가 가장 명확하게 들어맞는 지점이자, 이해관계가 가장 급격하게 갈라지는 지점입니다. 섀도우 SaaS의 장애는 국지적이었습니다. 하지만 AI 컨트롤 플레인의 장애는 구성적 (compositional)입니다. 하나의 고장 난 라우팅 계층은 모델 선택 로직을 오염시키고, 인가 동작을 변경하며, 다운스트림 자동화의 지연 시간 (latency)을 급증시키고, 장애 발생 시간 동안의 관측성을 제거하며, 재구성하는 데 며칠이 걸리는 비용 이상 (cost anomalies)을 동시에 발생시킬 수 있습니다.

AI 컨트롤 플레인(AI Control Plane) 프레이밍이 중요한 이유

컨트롤 플레인(Control Plane)은 인프라가 무엇을 수행할지, 어떻게 변경될지, 그리고 변경을 수행할 권한이 누구에게 있는지를 결정하는 계층입니다. 이 정의는 Kubernetes API 서버에 적용됩니다. vCenter에도 적용됩니다. CI/CD 파이프라인에도 적용됩니다. 그리고 운영 환경(production)에서 AI 워크로드(workloads)를 관리하는 추론 라우팅(inference routing), 오케스트레이션(orchestration), 정책 계층인 AI 컨트롤 플레인(AI control plane)에도 동일한 아키텍처적 힘으로 적용됩니다.

운영 소유권(operational ownership) 없이 추론 라우팅 계층이 배포되면, 이는 단순히 티켓(ticket)이 없는 도구에 그치지 않습니다. 이는 권한 모델(authority model)이 없는 컨트롤 플레인입니다. 모든 인프라 플랫폼에 영향을 미치는 '섀도우 컨트롤 플레인으로서의 콘솔(console-as-shadow-control-plane)' 문제는 여기서도 강력하게 작용합니다. 즉, 시스템 동작을 결정하는 표면(surface)이 거버넌스 경계(governance boundary)가 없는 실행 환경(execution environment)에 넘겨진 것입니다.

대부분의 AI 컨트롤 플레인은 인프라 팀이 관리하지 않는 비인간 신원 체인(non-human identity chains)에도 의존합니다. 서비스 간에 중개되는 API 키, 모델 제공업체 간의 위임된 권한 부여(delegated authorization), 에이전트 실행 시퀀스를 통해 전달되는 토큰 체인(token chains), 그리고 어떤 인간도 검토하지 않은 추론 권한을 가진 머신 신원(machine identities) 등이 이에 해당합니다. 이러한 신원 표면(identity surface)은 AI 컨트롤 플레인에 인접한 것이 아니라, 그 내부에 내장되어 있습니다.

세 가지 보이지 않는 인프라 표면

런타임 권한 진공(The Runtime Authority Vacuum) — 추론 인프라가 운영상으로는 활성화되어 있지만 거버넌스(governance), 관측성(observability), 연속성(continuity) 또는 장애 책임(failure ownership)에 대한 정의된 권한 모델이 없는 상태 — 은 다음 세 가지 표면에서 가장 눈에 띄게 나타납니다:

추론 라우팅 (Inference routing). 각 요청을 어떤 추론 엔드포인트(inference endpoint)가 처리할지 결정하는 모델 선택, 폴백 체인(fallback chain), 그리고 비용 계층 라우팅(cost-tier routing) 로직입니다. 이 계층은 일반적으로 애플리케이션 코드에 작성되어 제품 팀(product team)이 소유하며, 인프라 검토 없이 배포됩니다. 이것이 조용히 실패할 경우, 비용 라우팅 폴백(cost-routing fallback)은 경고, 신호, 또는 장애 기록(incident record) 없이 운영 환경에서 모델의 동작을 변경해 버립니다.

에이전트 오케스트레이션 (Agent orchestration). 도구 호출(tool calls)을 체이닝하고, 컨텍스트 윈도우(context windows)를 관리하며, 다음에 무엇을 실행할지 결정하는 런타임(runtime)입니다. 오케스트레이션 계층이 서킷 브레이커(circuit breaker) 없이 다운스트림 API에 대해 재시도(retries)를 반복하면, 체인 내의 모든 API에 걸쳐 연쇄적인 실행 동작을 일으킵니다. 이는 실행 추적(execution trace)을 수동으로 재구성하기 전까지는 상류(upstream) 부하처럼 보이는 지연 시간(latency) 및 비용 급증을 초래합니다. 그리고 현재 대부분의 배포 환경에서 이러한 실행 추적은 존재하지 않습니다.

관측 가능성 (Observability) — 또는 그 부재. 거버넌스가 갖춰진 추론 관측 가능성 계층이 없다면, AI 인프라 스택은 장애 발생 시 장애 신호(failure signal), 비용 신호(cost signal), 그리고 보안 신호(security signal)를 전혀 갖지 못합니다. 무언가 고장 나면, 장애 대응(incident response)은 모든 인프라 팀이 두려워하는 질문과 함께 시작됩니다:

AI 컨트롤 플레인(AI control plane)의 확산(sprawl)에 대한 아키텍처적 해결책(architectural remediation)을 위해서는 네 가지 개입이 필요합니다: 각 추론 컨트롤 플레인(inference control plane) 접점에 대해 운영 책임자(operational owner)를 지정할 것, 프로덕션 환경에서 의존하기 전에 라우팅(routing) 및 에이전트(agent) 계층에 관측성(observability)을 구축할 것, 첫 장애가 발생하여 질문을 던지게 만들기 전에 장애 도메인(failure domains)을 명시적으로 정의할 것, 그리고 프롬프트(prompt) 및 컨텍스트(context) 관리를 애플리케이션 설정(application configuration)이 아닌 상태 저장 인프라(stateful infrastructure)로 취급할 것입니다.

AI 에이전트가 의사결정을 내리고, 도구를 호출하며, 다운스트림 워크플로(downstream workflows)를 트리거하는 실행 계층(execution layer)이 될 때, AI 컨트롤 플레인은 더 이상 단순한 추론 인프라(inference infrastructure)가 아닙니다. 그것은 운영 인프라(operational infrastructure)이며, 프로덕션 상태(production state)를 수정할 수 있는 에이전트 시스템(agentic system)의 권한 모델(authority model)은 모델 거버넌스(model governance)의 문제가 아니라 인프라 권한(infrastructure authority)의 문제입니다.

AI Gravity & Placement Engine — 현재 AI 인프라에 내장된 배치(placement) 및 라우팅(routing) 로직을 모델링하십시오.

아키텍트의 판결 (Architect's Verdict)

조직들은 AI 도구의 문제를 겪고 있는 것이 아닙니다. 그들은 런타임 권한 진공(Runtime Authority Vacuum) 상태에 있습니다. 즉, 거버넌스, 관측성(observability), 연속성(continuity) 또는 장애 책임(failure ownership)에 대한 정의된 권한 모델이 없는, 운영적으로 활성화된 AI 컨트롤 플레인을 보유하고 있는 것입니다. 도구는 실재합니다. 인프라는 실재합니다. 하지만 권한은 부재합니다.

이 문제가 섀도우 IT(shadow IT)보다 해결하기 어려운 이유는 기술적 복잡성 때문이 아닙니다. 통제되지 않는 접점(surface)이 기본적으로 보이지 않기 때문입니다. 섀도우 SaaS(Shadow SaaS)는 송장, 브라우저 기록, 네트워크 트래픽에서 확인할 수 있었습니다. 하지만 AI 컨트롤 플레인 — 라우팅 계층(routing layer), 오케스트레이션 런타임(orchestration runtime), 프롬프트 관리 로직(prompt management logic), 비인간 ID 체인(non-human identity chain) — 은 그 어디에서도 나타나지 않습니다. 그것은 무언가 고장 나고, 장애 대응(incident response) 팀이 무엇이 일어났는지 재구성할 수 없다는 사실을 발견했을 때에만 비로소 드러납니다. 왜냐하면 관측성 계층(observability layer)이, 아무도 인프라로 분류하지 않은 인프라를 위해 구축된 적이 없기 때문입니다.

운영 소유권(operational ownership)이 없는 AI 컨트롤 플레인(AI control plane)은 혁신이 아닙니다. 그것은 관리되지 않는 인프라(unmanaged infrastructure)이며, 관리되지 않는 인프라는 정책(policy)만으로 관리되는 인프라가 되지 않습니다. 누군가가 권한 모델(authority model)을 정의하고, 관측성 계층(observability layer)을 구축하며, 페이저(pager, 장애 알림)를 책임질 때 비로소 관리되는 인프라가 됩니다.

추가 리소스

• The Console Is the Shadow Control Plane — Auth Layer 2: 통제되지 않는 실행 환경이 사실상의 컨트롤 플레인으로 나타나는 현상
• Agentic AI Has a Control Plane Problem — AI 에이전트가 운영 인프라 권한을 획득할 때 발생하는 문제
• Inference Observability: Why You Don't See the Cost Spike Until It's Too Late — 추론(inference) 사고를 복구 불가능하게 만드는 텔레메트리(telemetry) 격차
• The Model Answered. Nobody Asked Who Authorized That. — LLM 실행 경계에서의 권한 부여(authorization)
• Your CI/CD Pipeline Is Your Real Infrastructure Control Plane — 배포 계층에 적용된 컨트롤 플레인 프레임워크
• Cisco's acquisition of Astrix Security — 신흥 인프라 거버넌스로서의 비인간 정체성(non-human identity) 및 AI 에이전트 보안

원문은 rack2cloud.com에 게시되었습니다.