Agentic AI로 Mobile Network를 운영하기 위한 실험 환경

최근 네트워크 운영 환경은 점점 더 복잡해지고 있다.

특히 5G Core Network, RAN, Kubernetes 기반 CNF, Monitoring Stack, 그리고 AI 기반 자동화 시스템이 함께 동작하는 환경에서는 단순히 하나의 컴포넌트를 설치하고 실행하는 것만으로는 충분하지 않다.

 

현재 구축하려는 시스템은 Mobile Network를 관리하는 Agentic AI 기반 Intelligence Plane이다.

사용자가 자연어 기반의 Intent를 입력하면, Agentic AI 시스템이 이를 해석하고, 필요한 작업으로 분해하고, RAN과 Core Network 상태를 확인한 뒤, 적절한 자동화 작업을 수행하는 구조를 목표로 한다.

 

이를 위해서는 먼저 안정적인 실험 인프라가 필요하다. 이 실험 인프라는 크게 다음 요소로 구성된다.

• OAI-RAN
• Free5GC
• Kubernetes Cluster
• Monitoring Stack
• Agentic AI 기반 Intelligence Plane

 

기존 Free5GC Cluster 환경

 

 

기존에는 로컬 PC에 K8s master node를 VirtualBox VM으로 구성하고,

여기에 Free5GC control plane과 user plane 역할을 하는 worker node들을 연결해서 사용하고 있었다.

 

하지만 앞으로 Agentic AI Pod, Monitoring Stack, OpenTelemetry Collector, Prometheus, Grafana, Free5GC, OAI-RAN 연동까지 고려하면 VM 기반 master node는 컴퓨팅 리소스 측면에서 한계가 명확한 상황이었다.

 

그래서 이번 시리즈에서는 기존 VM 기반 Kubernetes control plane을 더 강력한 bare-metal server로 이전하고, 이 위에 Free5GC와 Monitoring Stack, 그리고 최종적으로 Agentic AI 기반 Intelligence Plane을 구축하는 과정을 정리하려고 한다.

 

 

 

Mobile Network에 Agentic AI가 필요한 이유

---

Mobile Network는 단순한 서버 애플리케이션 환경과 다르다.

RAN, CN, Transport, Edge/Cloud, Monitoring, Policy, Subscriber, Session, Traffic 경로가 서로 복잡하게 얽혀 있다.

 

예를 들어 Free5GC만 보더라도 AMF, SMF, UPF, NRF, UDM, UDR, AUSF, PCF 등 여러 Network Function이 존재한다.

여기에 OAI-RAN이 연결되면 RAN 상태, UE 접속 상태, PDU Session, UPF 경로, CNF Pod 상태, Kubernetes Node 상태까지 함께 고려해야 한다.

 

운영자가 원하는 목표, 즉 Intent는 보통 다음과 같은 형태로 표현된다.

 

• “URLLC 서비스를 위한 network slice를 생성해줘.”
• “특정 UE 그룹에 대해 end-to-end latency를 20ms 이하로 보장해줘.”
• “eMBB slice에 대해 최소 throughput을 일정 수준 이상으로 유지해줘.”
• “특정 enterprise customer를 위한 dedicated slice를 생성하고 SLA를 만족하도록 RAN/Core resource를 조정해줘.”
• “트래픽 증가 상황에서도 특정 service slice의 packet loss rate를 지정된 threshold 이하로 유지해줘.”

 

이런 Intent는 단일 명령어 하나로 끝나지 않는다.

예를 들어 “latency를 20ms 이하로 보장해줘”라는 Intent를 수행하려면 RAN 상태, Core Network 상태, UPF 경로, Kubernetes Pod 상태, node resource, traffic load, slice policy, QoS parameter 등을 함께 고려해야 한다.

 

또한 Intent는 한 번 실행하고 끝나는 작업이 아니다.

네트워크 상태는 계속 변하기 때문에, 시스템은 현재 상태가 사용자가 선언한 목표 상태와 계속 일치하는지 모니터링해야 한다.

만약 실제 latency가 20ms를 초과하거나, throughput이 SLA 기준 아래로 떨어지거나, slice resource allocation이 부족해지면 이를 Intent Drift로 판단하고 corrective action을 수행해야 한다.

 

이 지점에서 Agentic AI가 필요해진다.

Agentic AI는 단순히 LLM에게 질문하고 답변을 받는 구조가 아니라, 여러 Agent가 역할을 나누어 작업을 수행하는 구조다.

예를 들어 다음과 같은 Agent들이 존재할 수 있다.

• 사용자의 Intent를 해석하는 Decomposing Agent
• Intent를 달성하기 위한 Sub-Task를 계획하는 Planning Agent
• RAN 또는 Core Network와 직접 상호작용하는 Representative Agent
• 네트워크 상태와 SLA 만족 여부를 지속적으로 관찰하는 Monitoring Agent

 

이러한 Agentic AI가 동작하는 새로운 Plane을 Intelligence Plane라는 새로운 Plane으로 생각할 수 있다.

Intelligence Plane은 네트워크 운영 자동화를 위한 AI 기반 상위 제어 계층이다.

사용자의 Intent를 받아서 Sub-Task로 분해하고, 각 Sub-Task를 실행 가능한 workflow로 계획한 뒤, 실제 네트워크 요소와 상호작용하여 목표 상태를 만족시키도록 네트워크를 조정한다.

 

즉, 목표는 단순히 Kubernetes 위에 Free5GC를 배포하는 것이 아니라,

“서비스 목표를 선언하면, 시스템이 RAN-CN End-to-End 환경을 자동으로 조정하고 SLA를 유지하는 Agentic AI 기반 Mobile Network 관리 시스템”을 만드는 것이다.

 

 

 

전체 실험 환경 개요

---

이번 실험 환경의 중심에는 bare-metal server 기반 Kubernetes cluster가 있다.

기존에는 Kubernetes master node를 VirtualBox VM으로 구성했지만, 이

번 migration 이후에는 bare-metal server가 새로운 Kubernetes control plane 역할을 수행한다.

 

이 Kubernetes cluster는 단순히 Free5GC를 실행하기 위한 플랫폼이 아니라,

Mobile Network 운영 자동화 실험을 위한 공통 실행 환경으로 사용된다.

 

이 위에서 Free5GC, RAN 연동 컴포넌트, Monitoring Stack, 그리고 Agentic AI 기반 Intelligence Plane을 각각 독립된 namespace로 분리하여 관리한다.

 

중요한 점은 이 namespace들이 서로 종속 관계가 아니라는 것이다.

Kubernetes 배포 관점에서 free5gc, ran-ops, monitoring, intelligence-plane은 병렬적으로 존재한다.

 

다만 운영 논리 관점에서는 Intelligence Plane이 RAN과 Core Network의 상태를 관찰하고, 사용자의 Intent를 기반으로 필요한 제어 작업을 수행하는 상위 관리 계층처럼 동작한다.

즉, 배포 구조는 병렬적이고, 제어 논리는 계층적이다.

 

Kubernetes Cluster on Bare-Metal Server
|
+-- namespace: free5gc
|
+-- namespace: ran
|
+-- namespace: monitoring
|
+-- namespace: intelligence-plane

 

 

전체적인 흐름을 살펴보면 아래와 같다.

 

 

 

 

Kubernetes 1.35 이상과 OpenTelemetry를 선택한 이유

---

이번 실험 환경에서 중요한 결정 중 하나는 Kubernetes 버전과 observability stack을 어떻게 가져갈 것인가였다.

단순히 “최신 버전을 쓰자”는 이유만으로 Kubernetes를 올린 것은 아니다.

앞으로 구축하려는 시스템은 Free5GC와 OAI-RAN을 단순히 배포하고 모니터링하는 수준을 넘어서,

Agentic AI 기반 Intelligence Plane이 네트워크 상태를 관찰하고, SLA 위반이나 Intent Drift를 판단한 뒤,

필요한 corrective action을 수행하는 구조를 목표로 한다.

 

이런 구조에서는 Kubernetes가 단순한 container orchestration 플랫폼이 아니라, Mobile Network workload와 Agentic AI workload를 함께 실행하는 공통 제어 기반이 된다.

따라서 Kubernetes 자체가 앞으로의 동적 자원 제어, 관측성, 자동화 실험을 수용할 수 있어야 한다.

 

 

Kubernetes 1.35 이상을 선택한 이유

---

존 환경에서는 Kubernetes 1.28.2 기반의 VM master node를 사용하고 있었다.

이 구성은 Free5GC를 배포하고 기본적인 5G Core 실험을 수행하기에는 충분했지만,

 

이번 실험의 최종 목표는 단순한 Free5GC 배포가 아니라,

Agentic AI 기반 Intelligence Plane이 RAN-CN E2E 환경을 관찰하고 제어하는 구조를 만드는 것이다.

 

특히 Kubernetes 1.35 이상을 선택한 이유는 향후 RAN-side workload의 동적 resource adaptation을 실험하기 위해서다.

여기서 RAN-side workload는 단순히 Free5GC Pod를 의미하는 것이 아니라, OAI-RAN 관련 Docker workload, UE emulator, RAN control component, xApp/rApp, 그리고 이를 제어하는 Agentic AI component까지 포함한다.

 

Mobile Network 환경에서는 RAN 쪽 resource demand가 고정되어 있지 않다.

UE 수가 증가하거나, traffic load가 변하거나, 특정 slice에 latency-sensitive traffic이 몰리거나, xApp이 추가적인 control logic을 수행하는 경우 CPU와 memory 사용량이 동적으로 변할 수 있다.

 

특히 RAN과 가까운 workload는 latency, scheduling delay, packet processing performance에 민감하기 때문에, resource 조정이 SLA 만족 여부에 직접적인 영향을 줄 수 있다.

기존 Kubernetes에서는 Pod나 container에 할당된 CPU, memory를 변경하려면 일반적으로 Pod 재생성이 필요했다.

하지만 RAN-side workload나 xApp처럼 연속적인 제어 루프를 수행하는 component에서는 Pod 재생성이 부담이 될 수 있다.

예를 들어 UE emulator가 동작 중이거나, RAN Docker workload가 실험 시나리오를 수행 중이거나, xApp이 near-real-time control loop를 수행 중이라면 단순한 Pod restart도 실험 결과에 영향을 줄 수 있다.

 

따라서 runtime 중에 CPU와 memory resource를 조정할 수 있다면 다음과 같은 실험이 가능해진다.

- UE 수 증가에 따른 RAN-side workload resource 조정
- RAN Docker container의 CPU/memory request 조정
- xApp/rApp workload의 부하 증가에 따른 resource tuning
- latency-sensitive slice에 대한 resource-aware adaptation
- SLA violation 발생 시 RAN-side component의 vertical scaling
- Agentic AI가 Monitoring Stack의 telemetry를 기반으로 resource pressure를 감지하고 corrective action 수행

 

In-place pod resize matured across four Kubernetes releases. With Kubernetes 1.35, CPU and memory limits can now be adjusted live through the cgroup layer, removing the restart tax for many stateful workloads.

 

 

Kubernetes 1.33에서 In-place Pod Resize는 beta 단계로 올라왔고, Kubernetes 1.35에서 running Pod의 container CPU/memory request와 limit을 Pod 재생성 없이 변경하는 방향의 기능이 본격적으로 실험 가능한 수준으로 발전했다.

 

 

OpenTelemetry를 선택한 이유

---

Monitoring Stack에서도 기존에는 로그 수집을 위해 Loki 기반 구성을 고려했지만,

이번 migration에서는 OpenTelemetry Collector를 중심으로 observability pipeline을 구성하기로 했다.

 

Loki 생태계에서 기존 로그 수집 방식으로 많이 사용되던 Promtail이 EOL 되었고,

Loki Exporter 방식 역시 deprecated 흐름에 있다.

 

Grafana 생태계에서도 OpenTelemetry Collector와 OTLP 기반의 로그 수집 방식을 권장하는 방향으로 이동하고 있다.

따라서 새로 구축하는 실험 환경에서는 처음부터 OpenTelemetry 중심으로 logs, metrics, traces pipeline을 구성하는 것이 더 적절하다고 판단했다.

 

Observability stack

 

 

OpenTelemetry를 선택한 가장 큰 이유는 vendor-neutral observability 표준이라는 점이다.

OpenTelemetry는 traces, metrics, logs를 수집하고 처리하기 위한 표준화된 framework이며, 다양한 backend와 연동할 수 있다. 즉, 특정 logging backend나 dashboard 도구에 강하게 종속되지 않고, telemetry data를 일관된 방식으로 수집할 수 있다.

 

Agentic AI 기반 Mobile Network 운영 환경에서는 observability가 특히 중요하다.

Intelligence Plane은 단순히 사람이 보는 dashboard를 제공하기 위한 목적이 아니라,

Agent가 판단에 사용할 telemetry data를 필요로 한다.

 

예를 들어 Monitoring Agent는 다음과 같은 데이터를 활용해야 한다.

- Kubernetes node/pod/container resource metrics
- Free5GC component 상태
- UPF traffic 관련 metrics
- OAI-RAN 상태 및 성능 metrics
- Agentic AI Pod의 latency, error rate, task processing time
- Intent 처리 흐름의 trace
- corrective action 수행 결과 log

 

이 데이터는 단순 log만으로는 부족하다. 특정 SLA violation이 발생했을 때, 그 원인이 RAN 상태인지, UPF resource 부족인지, Kubernetes node pressure인지, Free5GC control plane component 문제인지, 혹은 Agentic AI workflow 자체의 지연인지 파악해야 한다. 이를 위해서는 metrics, logs, traces를 함께 볼 수 있어야 한다.

OpenTelemetry Collector는 각 component에서 발생하는 telemetry data를 수집하고, 필요한 형태로 가공한 뒤,

Prometheus, Grafana, Tempo, Loki-compatible endpoint 등 다양한 backend로 전달할 수 있다.

 

이번 환경 세팅에서는 Prometheus를 metrics 수집의 중심으로 유지하고,

OpenTelemetry Collector를 logs/traces pipeline의 중심으로 사용하며, Grafana를 visualization layer로 사용한다.