1000. 클라우드 네이티브 네트워크 (CNI)

핵심 인사이트 (3줄 요약)

본질: CNI(Container Network Interface)는 쿠버네티스(Kubernetes) 같은 클라우드 네이티브 환경에서, 수시로 생성되고 사라지는 컨테이너(Pod)들에게 네트워크 IP를 할당하고 연결해주는 표준화된 인터페이스다.

가치: 특정 네트워크 벤더에 종속되지 않고, 관리자가 플러그인(Flannel, Calico, Cilium 등)만 갈아 끼우면 오버레이(VXLAN), BGP 라우팅, 혹은 eBPF 기반의 고성능 네트워크 등 원하는 통신 환경을 즉시 구현할 수 있다.

판단 포인트: 클러스터 규모가 작다면 설치가 쉬운 Flannel을 쓰지만, 규모가 커지고 마이크로 세그멘테이션 보안과 트래픽 가시성이 필요해지면 성능 오버헤드가 적은 eBPF 기반의 Cilium CNI를 채택하는 것이 클라우드 아키텍트의 핵심 판단이다.

Ⅰ. 개요 및 필요성

클라우드 환경이 가상 머신(VM)에서 컨테이너(Container)로 진화하면서 네트워크에도 큰 문제가 생겼다. VM은 한번 켜지면 IP가 거의 바뀌지 않지만, 쿠버네티스 환경의 Pod(컨테이너 그룹)는 하루에도 수백 번씩 죽고 살아나며 그때마다 IP 주소가 바뀐다. 이렇게 동적인 환경에서는 전통적인 라우터나 고정된 IP 설정 방식으로는 통신을 유지할 수 없다.

이 혼란을 잠재우기 위해 CNCF(Cloud Native Computing Foundation)가 주도하여 만든 표준이 바로 **CNI(Container Network Interface)**다. "컨테이너가 생성될 때 어떻게 네트워크에 연결할 것인가"에 대한 규칙만 정의해 두고, 실제 작동은 다양한 서드파티 플러그인들이 알아서 하도록 책임을 분리(Decoupling)한 것이다.

📢 섹션 요약 비유: 매일 수십 번씩 텐트를 쳤다 접었다 하는 유목민 캠핑장(쿠버네티스)에서, 텐트를 칠 때마다 즉석에서 수도관과 전기선을 표준 규격으로 딱 맞게 꽂아주는 만능 어댑터가 CNI다.

Ⅱ. 아키텍처 및 핵심 원리

쿠버네티스 클러스터에서 CNI 플러그인은 Kubelet(노드 관리자)의 지시를 받아 작동한다. 주요 역할은 **IP 주소 할당 (IPAM: IP Address Management)**과 네트워크 인터페이스(veth pair) 생성 및 라우팅 설정이다.

┌───────────────────────────────── [ Kubernetes Node ] ─────────────────────────────────┐
│                                                                                       │
│  ┌─────────────────────────┐               ┌───────────────────────────────────────┐  │
│  │       Pod A (App)       │               │              Pod B (DB)               │  │
│  │  ┌───────────────────┐  │               │  ┌─────────────────────────────────┐  │  │
│  │  │  eth0 (10.0.1.2)  │  │               │  │         eth0 (10.0.1.3)         │  │  │
│  │  └─────────┬─────────┘  │               │  └────────────────┬────────────────┘  │  │
│  └────────────┼────────────┘               └───────────────────┼───────────────────┘  │
│               │ (veth pair)                                    │ (veth pair)          │
│  ┌────────────┴────────────────────────────────────────────────┴────────────┐         │
│  │                          CNI Plugin (e.g., Calico)                         │         │
│  │                      [ IPAM / Routing / Network Policy ]                   │         │
│  └────────────┬─────────────────────────────────────────────────────────────┘         │
│               │                                                                       │
│        [ 물리 NIC (eth0) ] ────────────────────────▶ 외부 네트워크 / 다른 노드        │
└───────────────────────────────────────────────────────────────────────────────────────┘

Pod 생성 시: Kubelet이 컨테이너 런타임을 통해 Pod를 띄우면, CNI 플러그인을 호출한다. CNI는 가상 랜선(veth pair)을 만들어 한쪽은 Pod 안(eth0)에, 한쪽은 호스트 네트워크에 연결하고 IP 대역 대장에서 IP를 하나 꺼내 부여한다.
오버레이 vs 라우팅: 플러그인의 성격에 따라, 노드 간 통신 시 패킷을 다시 포장하는 오버레이(Overlay, 예: Flannel의 VXLAN) 방식을 쓰거나, 패킷 포장 없이 실제 BGP 라우팅(예: Calico)을 사용하여 다른 노드의 Pod와 통신하게 만든다.

📢 섹션 요약 비유: 아파트(Node)에 새 입주자(Pod)가 이사 오면, 관리사무소(Kubelet)가 통신사 기사님(CNI)을 불러 새 공유기 선(veth)을 깔아주고 임시 전화번호(IP)를 달아주는 과정이다.

Ⅲ. 비교 및 연결

시중에는 다양한 CNI 플러그인이 존재하며, 각기 다른 트레이드오프(Trade-off)를 가진다.

CNI 플러그인	통신 방식	네트워크 정책(보안)	주요 특징 및 권장 환경
Flannel	오버레이 (VXLAN)	지원 안 함 (불가)	설정이 가장 단순함. 보안 정책이 필요 없는 소규모 클러스터.
Calico	BGP 라우팅 (비오버레이)	완벽 지원	성능이 뛰어나며, 상세한 L3/L4 방화벽 룰 적용 가능. 표준적인 엔터프라이즈 환경.
Cilium	eBPF (커널 레벨 최적화)	L7/API 레벨까지 지원	iptables를 우회하여 압도적인 성능과 가시성 제공. 최신 대규모 클라우드 네이티브 환경.
AWS VPC CNI	클라우드 네이티브 라우팅	Security Group 연동	AWS의 실제 사설 IP(ENI)를 Pod에 직접 할당. AWS EKS 환경에 최적화.

최근 CNI 생태계의 트렌드는 리눅스 커널의 네트워크 스택(iptables 등)이 너무 무겁고 느려지는 문제를 피하기 위해, 커널 내부에서 패킷을 직접 처리하는 eBPF(extended Berkeley Packet Filter) 기반의 Cilium으로 급격히 이동하고 있다.

📢 섹션 요약 비유: 이삿짐을 나를 때 우편배달부(Flannel)를 쓸지, 고속도로 직통 화물차(Calico)를 쓸지, 아예 순간이동 마법(Cilium, eBPF)을 쓸지 상황에 맞게 골라 쓰는 것이 CNI 플러그인 선택이다.

Ⅳ. 실무 적용 및 기술사 판단

실무 적용 시나리오: 마이크로서비스 아키텍처(MSA)에서는 수십 개의 서비스가 서로 통신한다. 이때 결제 Pod에서만 DB Pod로 접근할 수 있게 막는 '네트워크 폴리시(Network Policy)' 구현이 필수다. Flannel 같은 기본 CNI는 이를 지원하지 못하므로, 실무에서는 100% Calico나 Cilium을 선택하여 마이크로 세그멘테이션(Micro-segmentation) 방화벽을 구축한다.

기술사 판단 포인트 (Trade-off): CNI를 선택할 때는 '네트워크 성능'과 'IP 자원 고갈' 문제를 동시에 봐야 한다.

AWS VPC CNI처럼 클라우드 업체의 실제 IP를 Pod에 주면 성능은 최고(오버레이 캡슐화 없음)지만, 가용 IP 개수 제한에 걸려 Pod를 더 이상 띄우지 못하는 치명적 장애가 발생할 수 있다.
반대로 오버레이(VXLAN)를 쓰면 IP 고갈 문제는 없지만, 패킷을 쌌다 풀었다 하는 CPU 오버헤드와 MTU(Maximum Transmission Unit) 파편화로 인해 네트워크 성능이 10~20% 저하된다.

📢 섹션 요약 비유: 진짜 주소(클라우드 IP)를 나눠주면 배달은 빠르지만 주소판이 모자랄 수 있고, 임시 주소(오버레이)를 쓰면 무한대로 살 수 있지만 매번 주소록을 뒤져야 해서 배달이 느려지는 딜레마를 겪게 된다.

Ⅴ. 기대효과 및 결론

CNI는 쿠버네티스가 인프라의 제왕으로 군림할 수 있게 해준 숨은 일등 공신이다. 네트워크의 복잡성을 플러그인이라는 인터페이스 뒤로 숨김으로써, 개발자는 인프라 구성에 신경 쓰지 않고 애플리케이션 배포에만 집중할 수 있는 진정한 클라우드 네이티브(Cloud Native) 환경이 완성되었다.

앞으로는 AI 통신과 엣지 컴퓨팅을 위해 네트워크 가시성(Observability)과 초저지연이 더욱 중요해진다. 따라서 CNI 기술은 단순한 IP 할당 수준을 넘어, eBPF 기반으로 서비스 메시(Service Mesh) 기능까지 흡수하며 클라우드 네이티브 네트워크 데이터 플레인의 절대적인 핵심으로 진화해 나갈 것이다.

📢 섹션 요약 비유: 전기 플러그(CNI 표준) 모양을 통일해 놓으니, 사용자는 뒤에서 화력발전소를 쓰든 태양광(각종 플러그인)을 쓰든 신경 쓰지 않고 그냥 코드만 꽂아서 가전제품(앱)을 편하게 쓸 수 있게 된 것이다.

📌 관련 개념 맵

상위 개념: Cloud Native Architecture, Kubernetes
하위 개념: Flannel, Calico, Cilium, IPAM, eBPF
연결 개념: SDN (Software-Defined Networking), Overlay Network, Service Mesh

👶 어린이를 위한 3줄 비유 설명

수천 개의 레고 블록(컨테이너)으로 커다란 성을 지을 때, 블록들끼리 전화를 할 수 있게 전화선을 연결해 줘야 해요.
CNI는 레고 블록이 새로 조립될 때마다 알아서 전화선(가상 네트워크)을 딱딱 꽂아주고 전화번호(IP)를 나눠주는 만능 로봇이에요.
이 로봇 덕분에 블록을 하루에 백 번 부수고 다시 만들어도 전화가 끊기지 않고 잘 연결된답니다!