네트워크가 AI 컨트롤 플레인(Control Plane)이 되고 있다

업계는 AI 인프라가 GPU 문제라고 생각합니다. 하지만 이는 사실 AI 컨트롤 플레인 (Control Plane)의 문제이며, 컨트롤 플레인은 네트워크 패브릭 (Network Fabric) 내부로 재배치되고 있습니다. 스케줄링 지능 (Scheduling Intelligence)이 해당 패브릭 계층으로 더 많이 이동할수록, 개별 컴퓨팅 노드 (Compute Node)의 중요성은 낮아지는 반면, 해당 노드의 워크로드 (Workload)가 어디에서 실행될지를 결정하는 계층의 중요성은 더 커집니다. 스케줄링 지능은 권한을 끌어당깁니다. 모든 인프라 시대에 걸쳐 항상 그래왔습니다. 지금의 차이점은 지능을 얻고 있는 계층이 네트워크이며, 네트워크가 흡수하고 있는 결정들이 AI 워크로드에 대한 런타임 (Runtime) 결정이라는 점입니다.

AI 인프라는 새로운 컨트롤 서피스 (Control Surface)를 생성하고 있다

현재 네트워크 패브릭에 내장된 결정들은 단순한 네트워킹 기능이 아닙니다. 그것들은 런타임 결정입니다:

• 추론 라우팅 (Inference routing) — 패브릭 계층의 상태를 기반으로 특정 요청을 처리할 엔드포인트 (Endpoint)를 결정
• 에이전트 통신 경로 (Agent communication paths) — 에이전트 간 트래픽이 인프라를 통해 이동하는 경로
• 모델 배치 (Model placement) — 패브릭 토폴로지 (Topology)와 정책의 영향을 받아 워크로드가 배치되는 위치
• 패브릭 인식 스케줄링 (Fabric-aware scheduling) — 네트워크 제약 조건을 일급 입력값 (First-class inputs)으로 포함하는 워크로드 할당 결정
• 트래픽 스티어링 (Traffic steering) — 노드 전반에 걸쳐 집합 통신 패턴 (Collective communication patterns)이 오케스트레이션되는 방식

이 각각의 요소는 부하 상황에서 AI 시스템이 어떻게 동작할지를 결정합니다. 각각은 운영 권한을 가집니다. 그리고 이제 이 모든 것들은 적어도 부분적으로는 네트워크 계층에서 실행됩니다.

이러한 구분은 중요한데, 이는 네트워킹 (networking)과 런타임 운영 (runtime operations)이 서로 다른 팀, 서로 다른 툴체인 (toolchains), 그리고 서로 다른 조직적 책임 구조 (organizational accountability structures)에 의해 관리되기 때문입니다. 런타임 결정 사항이 역사적으로 인프라 배관 (infrastructure plumbing)으로 취급되어 온 계층으로 이동할 때, 권한 문제는 자동으로 해결되지 않습니다. 무언가 고장 날 때까지 기다릴 뿐입니다.

진단 (Diagnostic): "귀하의 조직에서 누가 AI 라우팅 정책 (AI routing policy)을 승인합니까? 그리고 그들은 그 승인이 어떤 패브릭 수준 (fabric-level)의 결정까지 포함하는지 알고 있습니까?"

지능의 계층은 항상 아래로 이동해 왔다

스케줄링 지능 (scheduling intelligence)이 더 낮은 인프라 계층으로 이동한 것은 이번이 처음이 아닙니다. 이러한 패턴은 기업 인프라의 모든 주요 시대에 걸쳐 일관되게 나타납니다:

시대	권한이 이동한 곳
가상화 (Virtualization)	하이퍼바이저 스케줄러 (Hypervisor Scheduler)
...

가상화 시대에는 워크로드 배치 (workload placement) 권한이 하이퍼바이저 스케줄러로 이동했습니다. Kubernetes 시대에는 하이퍼바이저 스케줄러에서 클러스터 스케줄러 (cluster schedulers)로 다시 이동했습니다. 서비스 메쉬 (service mesh) 시대에는 트래픽 정책 (traffic policy)을 흡수했습니다. 서킷 브레이킹 (circuit breaking), 재시도 동작 (retry behavior), 신원 확인 (identity enforcement), 그리고 라우팅 로직 (routing logic)이 애플리케이션 코드에서 메쉬 계층 (mesh layer)으로 이동했습니다. 각 이동은 동일한 논리를 따랐습니다. 조직도에 무엇이라 적혀 있든 관계없이, 가장 많은 스케줄링 지능을 가진 계층이 가장 많은 운영 권한을 가진 계층이 되었습니다.

"스케줄링 지능은 권한을 끌어당긴다 (Scheduling intelligence attracts authority)"라는 문장은 해당 표의 모든 행을 설명해 줍니다.

인프라 권한 이동 — 프레임워크 #103

인프라 권한 이동 (Infrastructure Authority Migration): 워크로드를 실행하는 계층에서 워크로드 배치를 결정하는 계층으로 운영 의사결정 권한이 이동하는 현상.

권한은 이동할 때 사라지는 것이 아니라, 배치 결정을 내릴 수 있는 지능을 획득한 계층으로 재배치됩니다. 이러한 재배치에 대한 조직적 인식은 기술적 현실보다 수개월 또는 수년 뒤처지는 것이 일상적입니다.

AI 인프라의 경우, 이러한 재배치는 이미 진행 중입니다. 패브릭 계층(fabric layer)은 이제 추론 지연 시간(inference latency), 작업 완료 시간(job completion time), GPU 활용률(GPU utilization), 그리고 에이전트 통신 충실도(agent communication fidelity)를 직접적으로 결정하는 입력값을 보유하고 있습니다. 추론 라우팅(Inference routing)이 가장 명확한 사례입니다. 애플리케이션 계층(application-layer)의 관심사로 시작되었던 것이 이제는 패브릭 계층의 상태(fabric-layer state), 혼잡 정책(congestion policy), 그리고 집합 통신 토폴로지(collective communication topology)에 의해 형성됩니다. 해당 동작을 담당하는 팀들이 인지했는지 여부와 상관없이, 추론 동작에 대한 권한은 이미 이동했습니다.

중요한 질문은 아키텍처에 관한 것이 아닙니다. 그것은 조직에 관한 것입니다: AI 컨트롤 플레인(control plane)이 네트워크 패브릭 내부에 존재할 때, 그 소유권은 누구에게 있는가?

AI 워크로드는 기존 인프라와 다르게 동작한다

**기존 워크로드(Traditional workloads)**는 주로 노스-사우스(north-south) 방식입니다. 애플리케이션 계층이 데이터베이스 계층과 통신합니다. 여기서 네트워크는 전송(transport) 수단입니다.

Kubernetes 워크로드는 이스트-웨스트(east-west) 트래픽을 크게 증가시켰습니다. 클러스터 내의 서비스 간 통신(service-to-service communication)이 외부 트래픽만큼 중요해졌습니다. 네트워크는 정책을 인식(policy-aware)할 수 있어야 했습니다.

AI 워크로드는 이 두 가지 패턴을 모두 따르지 않습니다. 집합 통신(Collective communication)이 지배적입니다: 학습 중의 올-리듀스(all-reduce) 연산, 분산 노드 간의 그래디언트 동기화(gradient synchronization), 모델 샤드(model shards) 간의 파라미터 교환, 서빙 복제본(serving replicas) 간의 추론 스캐터-게더(inference scatter-gather), 멀티 에이전트 파이프라인에서의 에이전트 간 통신(agent-to-agent communication) 등이 이에 해당합니다. 이러한 패턴은 토폴로지에 민감하고(topology-sensitive), 지연 시간에 취약하며(latency-intolerant), 병렬성에 의존적(parallelism-dependent)입니다.

실질적인 결과는 다음과 같습니다: 네트워크 패브릭은 이제 작업 완료 시간, 배치 효율성(placement efficiency), GPU 활용률, 그리고 스케줄링 결정에 직접적인 영향을 미칩니다. 네트워크는 AI 워크로드를 단순히 전송하는 것이 아니라, 그 실행에 참여합니다. 이것이 패브릭 계층에서 발생하는 인프라 권한 이동(Infrastructure Authority Migration)의 기술적 근거입니다.

Cisco, AWS, Google, NVIDIA가 모두 동일한 것을 구축하고 있는 이유

네 개의 벤더, 네 개의 구현 방식, 그러나 하나의 아키텍처 방향성:

Cisco — AgenticOps와 Silicon One G300은 네트워크 패브릭(Network Fabric)을 AI 작업 실행의 능동적인 참여자로 위치시키며, AI 트래픽 패턴을 이해하고 최적화하도록 설계된 지능형 집합 네트워크(Intelligent Collective Networking)를 제공합니다.

NVIDIA — Spectrum-X는 작업 인식형 이더넷(Job-aware Ethernet)을 구현합니다. 여기에는 작업별 혼잡 격리(Per-job congestion isolation), RoCE 최적화, 그리고 AI 집합 통신(AI collective communication)의 의미론을 이해하는 적응형 라우팅(Adaptive routing)이 포함됩니다.

AWS — Elastic Fabric Adapter와 UltraCluster의 토폴로지 인식 배치(Topology-aware placement)는 패브릭 토폴로지를 워크로드 배치 결정의 일급 입력값(First-class input)으로 만듭니다.

Google — Google Cloud Next 2026에서 발표된 에이전트 거버넌스 스택(Agent governance stack)은 네트워크 계층의 라우팅 정책과 관측성(Observability)을 런타임 거버넌스 모델(Runtime governance model)에 내장합니다.

구현 방식은 다르지만 방향은 같습니다. 스케줄링 지능(Scheduling intelligence)이 패브릭 계층으로 이동하고 있습니다.

네트워크 팀은 이를 요청한 적이 없다

역사적으로 네트워크 팀은 연결성(Connectivity), 패킷 손실(Packet loss), 처리량(Throughput), 가동 시간(Uptime)과 같이 정의된 운영 영역을 담당해 왔습니다. 이것들은 인프라 상태 지표(Infrastructure health metrics)입니다. 이 지표들은 워크로드 권한(Workload authority)을 갖지 않습니다.

하지만 이제 벤더들은 동일한 계층에 배치 로직(Placement logic), 스케줄링 인식(Scheduling awareness), 작업별 혼잡 결정(Per-job congestion decisions), 워크로드 우선순위 정책(Workload prioritization policies)과 같은 다른 일련의 기능들을 내장하고 있습니다. 그 결과, 누구도 계획하지 않았던 권한의 전이가 발생하고 있습니다:

• 네트워크 팀은 요청하지도 않은 권한을 상속받습니다.
• 플랫폼 팀은 양도할 의도가 없었던 권한을 상실합니다.
• AI 팀은 자신이 완전히 이해하지 못하는 패브릭 동작 (fabric behavior) 속으로 워크로드 (workloads)를 배포하고 있습니다. 대부분의 조직은 이러한 권한 전이를 알아차리지 못했습니다. 조직도상으로는 명확한 소유권 경계를 가진 세 개의 별도 팀이 나타납니다. 하지만 인프라상으로는 이 세 팀 모두를 가로지르는 결정을 내리는 하나의 계층이 존재합니다.

⚠ 흔한 실수: 대부분의 기업은 조직 내 누구도 관리하도록 요청받지 않은, 스케줄링 지능 (scheduling intelligence)이 더 높은 패브릭 (fabric) 위에서 AI 워크로드를 실행하고 있습니다. 조직도는 깨끗한 소유권 경계를 보여주지만, 인프라는 그렇지 않습니다.

다음 단계: AI 컨트롤 플레인 (Control Plane) 거버넌스 문제

대부분의 조직은 여전히 AI 거버넌스 (AI governance)가 모델을 승인하는 것이라고 생각합니다. 차세대 AI 거버넌스는 AI 컨트롤 플레인 (AI control plane)의 동작을 승인하는 것에 관한 것이 될 것입니다.

이제 질문은 어떤 모델이 승인되었느냐가 아닙니다. 질문은 그 모델이 어디서, 언제, 어떻게 실행될지를 결정하는 패브릭 수준의 결정들 — 추론 라우팅 (inference routing), 에이전트 통신 경로 (agent communication paths), 배치 제약 조건 (placement constraints), 혼잡 정책 (congestion policy), 워크로드 우선순위 지정 (workload prioritization) — 을 누가 제어하느냐입니다. 이러한 결정들은 컴플라이언스 (compliance) 결과, 비용 결과, 그리고 신뢰성 결과에 영향을 미칩니다. 이 중 어느 것도 모델 승인 워크플로 (model approval workflow)에는 나타나지 않습니다.

누가 AI 라우팅 정책 (AI routing policy)을 승인합니까? 플랫폼 정책과 충돌할 때 패브릭 스케줄링 제약 조건 (fabric scheduling constraints)을 설정하는 사람은 누구입니까? 패브릭 계층에서 내려진 스케줄링 결정이 애플리케이션 계층에서 컴플라이언스 격차 (compliance gap)를 발생시켰을 때, 누가 책임을 집니까?

대부분의 기업은 답을 가지고 있지 않습니다. 이는 아무도 질문할 생각을 하지 않았기 때문이 아니라, 거버넌스 모델이 설계되기 전에 인프라가 먼저 배포되었기 때문입니다.

진단: "귀하의 조직에서 패브릭 수준의 AI 스케줄링 정책 (fabric-level AI scheduling policy)에 책임을 지는 사람의 이름을 말할 수 있습니까? 그리고 그 사람이 현재 그 정책이 무엇인지 설명할 수 있습니까?"

권한 문제를 해결하지 못한 채 지나가는 각각의 인프라 갱신 주기 (infrastructure refresh cycle)는 거버넌스 부채 (governance debt)를 가중시킵니다.

설계자의 판결 (Architect's Verdict)

GPU가 AI 컨트롤 플레인 (Control Plane) 권한 모델의 중심에 계속 머물 수는 없었습니다. 모든 인프라 시대는 동일한 패턴을 따랐습니다. 조직도(org chart)가 무엇이라고 말하든 상관없이, 스케줄링 지능 (scheduling intelligence)을 확보하는 계층이 운영 권한 (operational authority)을 갖게 됩니다. 그리고 그 계층은 이제 네트워크 패브릭 (network fabric)입니다.

스케줄링 지능은 권한을 끌어당깁니다. 이를 이해하는 조직들은 이러한 이동을 막으려 하지 않습니다. 대신 그들은 권한이 어디로 이동하고 있는지에 대한 거버넌스 모델 (governance model)을 설계하고 있습니다. 즉, 다음 인프라 갱신 (infrastructure refresh)이 패브릭에 더 많은 지능을 심어버리기 전에 소유권 (ownership), 책임 (accountability), 그리고 정책 승인 (policy approval)을 정의하고 있는 것입니다.

이 흐름을 앞서가는 설계자들은 Silicon One G300의 기능 세트 (feature set)를 잘 아는 사람들이 아닙니다. 그들은 바로 오늘, 그 기능 세트가 내리고 있는 결정들을 누가 소유하고 있는가라는 질문에 답할 수 있는 사람들입니다.

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