Datacenter & Cloud - 06. SDN과 네트워크 가상화

네트워크를 소프트웨어로 정의한다 — SDN과 네트워크 가상화

2008년, Stanford 대학의 Martin Casado와 그의 지도교수 Nick McKeown은 — 네트워크 스위치의 "두뇌(컨트롤 플레인)"를 소프트웨어로 분리하는 실험을 했다. 스위치는 — 패킷을 전달하는 "손발(데이터 플레인)"만 남기고 — "어디로 보낼까?"를 결정하는 두뇌를 중앙 컨트롤러로 옮긴 것이다. 이 실험이 OpenFlow로 발전했고, SDN(Software-Defined Networking) 이라는 새로운 패러다임을 만들었다. "네트워크를 하드웨어가 아니라 소프트웨어로 정의한다" — foundations 06의 IaC 철학이 네트워크에 적용된 것이다.

이 글은 SDN — 컨트롤 플레인과 데이터 플레인의 분리, OpenFlow·OVS·OVN, CNI, NFV — 를 다룬다. 이전 글에서 본 오버레이(VXLAN)가 — SDN 기술 위에 구현된다는 점에서, SDN은 클라우드 네트워킹의 기반이다.

컨트롤 플레인과 데이터 플레인 — 네트워크의 두뇌와 손발

전통적 네트워크 장비(스위치·라우터)는 — 두 가지 기능을 하나의 장비 안에 갖는다.

• 컨트롤 플레인(Control Plane) — "결정하는" 층. 라우팅 테이블·MAC 주소 테이블·ACL을 관리하고 — "이 패킷을 어디로 보낼까?"를 결정한다. 두뇌 역할. 느리지만 복잡한 계산(OSPF·BGP)을 수행.
• 데이터 플레인(Data Plane) — "실행하는" 층. 컨트롤 플레인의 결정을 바탕으로 — 패킷을 실제로 받아서 전달(forward)한다. 손발 역할. 빠르지만 단순한 작업(헤더 검사·포트로 전송).

flowchart LR
    subgraph TRADITIONAL["전통적 스위치 (통합형)"]
        CP1["컨트롤 플레인<br/>(OSPF, BGP, MAC 학습)"]
        DP1["데이터 플레인<br/>(패킷 전달)"]
        CP1 --> DP1
    end
    subgraph SDN_MODEL["SDN 모델 (분리형)"]
        CONTROLLER["중앙 컨트롤러<br/>(소프트웨어)"]
        SW1["스위치 1<br/>(데이터 플레인만)"]
        SW2["스위치 2<br/>(데이터 플레인만)"]
        SW3["스위치 3<br/>(데이터 플레인만)"]
        CONTROLLER -->|"OpenFlow"| SW1
        CONTROLLER -->|"OpenFlow"| SW2
        CONTROLLER -->|"OpenFlow"| SW3
    end

SDN의 핵심 통찰은 — 이 두 가지를 분리하는 것이다. 컨트롤 플레인을 — 중앙의 소프트웨어 컨트롤러로 옮기고 — 스위치는 데이터 플레인(패킷 전달)만 담당한다. 비유하자면 — 각 우체국마다 배송 담당자(컨트롤 플레인)를 두는 대신 — 중앙 배송 센터가 모든 우체국(스위치)에 "이 편지는 저쪽으로 보내라"고 지시하는 것.

분리의 이점

• 중앙 제어 — 전체 네트워크를 하나의 소프트웨어에서 관리. 개별 스위치에 하나씩 설정(Telnet·SSH)할 필요 없이 — API로 전체를 제어.
• 프로그래밍 가능 — 컨트롤러가 소프트웨어니 — Python·Java로 네트워크 정책을 코드로 작성. "매주 2시에 트래픽 경로를 변경" 같은 자동화가 가능.
• 데이터 플레인 단순화 — 스위치는 "표(forwarding table)를 보고 전달"만 하면 되니 — 더 싸고 빠른 하드웨어로 만들 수 있다.

OpenFlow — SDN의 첫 번째 프로토콜

OpenFlow(2011년, Open Networking Foundation)는 — SDN 컨트롤러와 스위치 간의 통신 프로토콜이다. 컨트롤러가 스위치에게 — "이 패턴의 패킷은 이 포트로 보내라"는 규칙(flow rule)을 설치하고 — 스위치는 그 규칙대로 패킷을 전달한다.

OpenFlow의 한계는 — 규칙이 너무 세밀하면 — 스위치의 TCAM(Ternary Content-Addressable Memory, 규칙 저장 메모리)이 가득 차고, 성능이 떨어진다. 또한 — 컨트롤러가 죽으면 — 전체 네트워크가 마비되는(SPOF) 위험이 있다. 이런 한계로 — OpenFlow 자체는 학계·소규모 환경에서는 성공했지만 — 대규모 상용 환경에서는 더 실용적인 접근(OVS·OVN·벤더 SDN)으로 대체됐다.

OVS(Open vSwitch) — 소프트웨어 스위치

OVS(Open vSwitch) 는 — Linux에서 동작하는 소프트웨어 기반 가상 스위치다. 2009년 Nicira(현 VMware)가 개발, 현재는 Linux Foundation 프로젝트. 하이퍼바이저(KVM·Xen) 위에서 — VM 간 L2 통신을 담당한다.

OVS는 — 물리 스위치가 하는 일(MAC 학습·VLAN·미러링·QoS·NetFlow)을 — 소프트웨어로 구현한다. OpenFlow 컨트롤러(ODL·ONOS·Ryu)와 연동하면 — 중앙에서 OVS를 제어할 수 있다. OpenStack·Red Hat Virtualization·XenServer가 OVS를 기본 가상 스위치로 쓴다.

# OVS 상태 확인 (OVS가 설치된 호스트)
ovs-vsctl show                    # 브리지·포트 목록
ovs-ofctl dump-flows br0          # 플로우 규칙 (OpenFlow)
ovs-appctl fdb/show br0           # MAC 주소 테이블

OVN — OVS의 관리 계층

OVN(Open Virtual Network) 은 — OVS 위에 얹히는 논리적 네트워크 관리 계층이다. OVS가 "한 호스트 안의 가상 스위치"라면 — OVN은 "여러 호스트에 걸친 논리적 네트워크(논리 스위치·논리 라우터)"를 만든다. Geneve 오버레이를 이용해 — 여러 호스트의 VM을 같은 논리 L2에 묶는다. OpenStack의 기본 네트워킹 백엔드로 채택됐다.

OVN이 해결하는 문제 — OVS만 쓰면 각 호스트의 가상 스위치를 개별적으로 관리해야 한다. "VM-A(호스트 1)와 VM-B(호스트 2)를 같은 논리 네트워크에" — 이걸 각 호스트의 OVS에 수동으로 설정하는 건 불가능하다. OVN이 — 중앙에서 논리적 네트워크를 정의하고 — 각 호스트의 OVS에 자동으로 배포한다. foundations 06의 IaC가 — 네트워크 가상화에 적용된 것이다.

CNI — 컨테이너 네트워크 인터페이스

CNI(Container Network Interface) 는 — 컨테이너 런타임(containerd·CRI-O)과 네트워크 플러그인 사이의 표준 인터페이스다. Kubernetes가 — "이 Pod에게 IP를 할당하고 네트워크에 연결해라"고 CNI 플러그인에게 요청하면 — 플러그인이 Pod의 네트워크를 설정한다.

CNI 플러그인의 종류:

• Calico — BGP 기반 라우팅, 오버레이 없이 L3로 직접 통신. 데이터센터에서 인기.
• Cilium — eBPF 기반, 커널 수준에서 패킷을 처리. 보안 정책(L3~L7)까지 통합.
• Flannel — 간단한 오버레이(VXLAN). 소규모 Kubernetes 클러스터에서 인기.
• Weave Net — 암호화된 오버레이. 간단하지만 기능이 제한적.

CNI는 — Kubernetes의 네트워크를 "교체 가능한 플러그인"으로 만든다. Kubernetes 서브프로젝트에서 깊이 다룬다.

NFV — 네트워크 기능의 가상화

NFV(Network Function Virtualization) 는 — 전용 하드웨어(방화벽 어플라이언스·로드 밸런서 어플라이언스·라우터)를 — 소프트웨어(VM·컨테이너)로 대체하는 기술이다. foundations 04에서 본 가상화가 — "서버 기능"을 가상화했다면, NFV는 "네트워크 기능"을 가상화한다.

예: 전통적 방화벽은 Cisco ASA·Palo Alto 같은 전용 기기였다. NFV 환경에서는 — Linux VM에 iptables/nftables(또는 pfSense·vyos)를 올려서 방화벽으로 쓴다. 물리 기기를 살 필요 없이 — VM으로 "방화벽 기능"을 구현하는 것.

통신사(telecom)가 NFV의 주요 사용자다 — 5G 코어 네트워크·EPC(Evolved Packet Core)를 — 전용 하드웨어 대신 소프트웨어(VM·컨테이너)로 구축한다. ETSI NFV ISG가 표준을 만든다.

SDN과 클라우드 — 벤더의 내부 구현

AWS·GCP·Azure는 — SDN 기술을 내부적으로 쓰지만 — 사용자에게 보여주지 않는다. 사용자가 "VPC 만들기" 버튼을 누르면 — 클라우드 컨트롤 플레인이 — SDN API를 통해 — 가상 스위치(OVS 또는 자체 구현)에 — 새 논리 네트워크(VXLAN VNID)를 설정한다. 사용자는 — SDN이 어떻게 동작하는지 모른다. "버튼 → 가상 네트워크" 사이의 복잡함이 — SDN으로 추상화된다.

AWS Nitro 시스템은 — SDN을 전용 하드웨어(DPU) 로 옮긴 사례다. compute-platforms 영역의 04 글에서 본 것처럼 — Nitro DPU가 네트워크 가상화(VPC·보안 그룹·라우팅)를 처리하고 — 호스트 CPU는 고객의 워크로드에만 집중한다. SDN의 "소프트웨어 정의"를 — 한 단계 더 발전시켜 "하드웨어 가속화된 소프트웨어 정의"로 만든 것이다.

실습 — SDN 관련 상태 확인

1. OVS 상태 (OVS가 설치된 호스트)

# OVS 브리지 목록
ovs-vsctl show 2>/dev/null || echo "OVS 미설치"
# 특정 브리지의 포트
ovs-vsctl list-ports br-int 2>/dev/null
# 플로우 통계
ovs-ofctl dump-flows br-int 2>/dev/null | head -10

확인할 것: 브리지 이름(br-int는 OpenStack의 통합 브리지), 연결된 포트(VM의 tap 인터페이스), OpenFlow 규칙.

2. CNI 플러그인 확인 (Kubernetes 노드)

# 사용 중인 CNI 플러그인
cat /etc/cni/net.d/*.conf 2>/dev/null | head -20
# 또는
ls /opt/cni/bin/ 2>/dev/null
# 노드의 네트워크 인터페이스 (cni0, flannel.1 등)
ip link show | grep -E 'cni|flannel|tunl|cilium'

확인할 것: CNI 설정 파일의 type 필드(calico·cilium·flannel). CNI 바이너리 목록. 노드에 CNI 관련 인터페이스가 있는지.

3. 리눅스 브리지 (단순 가상 스위치)

# Linux 브리지 목록
ip link show type bridge
# 또는
brctl show 2>/dev/null
# 브리지의 MAC 테이블
brctl showmacs br0 2>/dev/null | head -10

확인할 것: 브리지에 연결된 인터페이스(VM의 veth·tap). MAC 학습 테이블. OVS가 없는 환경에서는 Linux 브리지가 가상 스위치 역할을 한다.

미검증: OVS·CNI 명령은 각 환경(OpenStack·Kubernetes·자체 구축)에 설치돼 있어야 동작. 클라우드 EC2에서는 SDN이 벤더에게 숨겨져 있어 직접 확인이 어려움.

SDN은 "네트워크를 코드로"의 실천이다

SDN의 핵심 메시지는 — foundations 06의 IaC와 같다 — "인프라를 소프트웨어로 정의한다". 네트워크가 더 이상 하드웨어 장비에 종속되지 않고, 코드로 정의되고, API로 제어되고, 버전 관리된다. OpenFlow로 시작된 이 패러다임은 — OVS·OVN·CNI·NFV로 확장됐고 — 클라우드의 모든 네트워크(VPC·서브넷·보안 그룹)가 결국 이 SDN 기술 위에 만들어진다.

다음 글에서는 — SDN으로 만든 네트워크 인프라를 코드로 정의하는 도구를 다룬다 — Terraform. foundations 06에서 본 IaC 철학이 — 클라우드 리소스(VPC·EC2·RDS·ELB)를 정의하는 HCL 코드로 실천되는 것.

SDN 컨트롤러 — 네트워크의 "두뇌" 소프트웨어

SDN에서 컨트롤러는 — 전체 네트워크의 결정을 내리는 중앙 소프트웨어다. 여러 컨트롤러가 있다:

컨트롤러	개발사/조직	특징	전형 사례
OpenDaylight (ODL)	Linux Foundation	Java 기반, 모듈식, 대규모	통신사, 엔터프라이즈
ONOS	ON.Lab	통신사용, 고가용성, 분산	5G 코어, SD-WAN
Ryu	NTT	Python 기반, 경량, 연구용	학계, 프로토타입
Floodlight	Big Switch	Java 기반, 오픈소스	캠퍼스 네트워크
Cisco DNA Center	Cisco	상용, 네트워크 자동화	엔터프라이즈 Cisco 환경
VMware NSX	VMware	가상화 네트워크 관리	vSphere 환경

컨트롤러의 핵심 역할 — 전체 네트워크 토폴로지를 파악하고, 각 스위치에 플로우 규칙(flow rule) 을 배포한다. "목적지 MAC이 aa:bb이면 포트 3으로 보내라" 같은 규칙을 — 각 스위치의 데이터 플레인에 설치한다.

SDN vs 전통적 네트워크 — 언제 무엇을

SDN이 항상 전통적 네트워크보다 나은 건 아니다. 각자 적합한 환경이 있다:

전통적 네트워크(분산 컨트롤 플레인)가 유리한 경우:

• 안정성이 최우선인 환경 — 각 스위치가 독립적으로 결정하니 — 중앙 컨트롤러 장애가 전체 네트워크에 영향을 안 줌
• 소규모 네트워크 — 수십 대의 스위치를 중앙 제어할 이득이 없음
• 검증된 안정성 — 수십 년의 운용 경험과 장비 검증

SDN(중앙 컨트롤 플레인)이 유리한 경우:

• 대규모 데이터센터 — 수천 대의 스위치를 중앙에서 관리하면 설정·변경이 단순
• 동적 환경 — VM/컨테이너가 빈번하게 생성·삭제되는 클라우드
• 자동화 요구 — 네트워크 정책을 코드로 작성하고 API로 배포
• 멀티테넌시 — 각 테넌트마다 다른 네트워크 정책을 중앙에서 관리

실제 사례 — 클라우드 벤더의 SDN

Google — 전 세수 데이터센터 네트워크(Jupiter)를 SDN(B4)으로 운영. 중앙 컨트롤러가 전체 트래픽을 보고 — 대역폭을 동적으로 할당. WAN(광역망) 비용을 수십 % 절감했다(SIGCOMM 2013).

AWS — VPC·보안 그룹·라우팅을 Nitro DPU에서 SDN으로 처리. 사용자는 API로 네트워크를 정의하고 — Nitro가 실시간으로 패킷 필터링·라우팅을 수행.

VMware NSX — 데이터센터 네트워크를 완전히 소프트웨어로 가상화. 물리 네트워크는 IP 연결만 제공하고 — 위의 모든 논리 네트워크(방화벽·로드 밸런서·라우팅)를 NSX가 소프트웨어로 구현.

SD-WAN — SDN의 넓은 적용

SD-WAN(Software-Defined WAN) 은 — SDN을 광역 네트워크(WAN)에 적용한 것. 지사와 본사를 연결하는 기존 WAN(전용선·MPLS)을 — 일반 인터넷 + SDN 컨트롤러로 대체한다. 비용이 싸고(MPLS 대비), 동적으로 경로를 변경할 수 있고(인터넷이 막히면 LTE로 우회), 중앙에서 정책을 관리할 수 있다. Cisco SD-WAN·VMware Velocloud·Fortinet이 대표적 제품이다.

SDN은 — 네트워크를 "하드웨어의 영역"에서 "소프트웨어의 영역"으로 옮긴 기술이다. 이 전환 덕분에 — 클라우드에서 API 버튼 하나로 VPC를 만들고, 보안 그룹을 설정하고, 라우팅을 변경할 수 있다. SDN 없는 클라우드는 상상할 수 없다.

SDN의 원리는 단순하다 — 컨트롤 플레인(결정)과 데이터 플레인(실행)을 분리하고, 컨트롤 플레인을 소프트웨어로 만든다. 이 단순한 원리가 — OpenFlow(2008)에서 시작해 OVS·OVN·CNI·NFV·SD-WAN으로 확장됐고, 2026년 현재 클라우드 네트워킹의 모든 층에 스며들어 있다. 다음 글에서는 — SDN으로 만든 클라우드 인프라를 코드로 정의하는 도구를 다룬다 — Terraform. foundations 06의 IaC 철학이 클라우드 리소스(VPC·EC2·RDS·ELB)를 정의하는 HCL 코드로 실천되는 것이다.

OVS 플로우 규칙 — 패킷 처리의 "표"

OVS(또는 OpenFlow 스위치)가 패킷을 처리하는 방식은 — 플로우 테이블(flow table) 이라는 규칙 집합으로 결정된다. 각 규칙은 세 부분으로 구성된다:

Match(매칭) → Action(행동) → Priority(우선순위)

예시 규칙:
1. ip dst=10.0.1.5 → output:3 → priority=100    # 목적지 IP가 10.0.1.5면 포트 3으로
2. arp → output:flood → priority=50              # ARP는 플러딩
3. ip → output:NORMAL → priority=10              # 나머지는 일반 L2 처리
4. * → drop → priority=0                          # 매칭 안 되면 드롭

컨트롤러가 이 규칙을 — OVS에 설치(install)하고 — OVS는 들어오는 패킷을 규칙에 매칭해서 처리한다. 규칙이 없으면 — 컨트롤러에게 "이 패킷 어떡하지?"(packet-in)를 물어보고 — 컨트롤러가 새 규칙을 설치한다. 이 과정이 — 처음에는 느리지만 — 규칙이 캐시(flow cache)되면 — 이후 같은 패턴의 패킷은 — 컨트롤러를 거치지 않고 스위치에서 바로 처리된다.

CNI 플러그인 비교 — Kubernetes 네트워킹의 선택지

Kubernetes 클러스터를 구축할 때 가장 중요한 결정 중 하나가 — CNI 플러그인 선택이다. 각 플러그인이 — 다른 네트워크 모델·성능·보안 기능을 제공한다.

CNI	네트워크 모델	오버레이	보안 정책	성능	적합 환경
Calico	L3 라우팅 (BGP)	VXLAN(옵션)	네트워크 정책 (L3/L4)	높음	데이터센터, 엔터프라이즈
Cilium	eBPF 기반	VXLAN/Geneve	풍부 (L3~L7)	매우 높음	대규모, 서비스 메시 통합
Flannel	L2/L3	VXLAN/host-gw	없음	중간	소규모, 단순 환경
Weave	L2 오버레이	암호화 VXLAN	제한적	중간	소규모, 암호화 필요
Antrea	OVS 기반	VXLAN/Geneve	네트워크 정책	높음	vSphere 환경, OVS 친숙

Cilium이 2026년 가장 주목받는 CNI다 — eBPF로 커널 수준에서 패킷을 처리하니 — kube-proxy(iptables)를 통째로 대체할 수 있다. 성능이 iptables 기반보다 훨씬 좋고 — L7(HTTP 경로) 수준의 보안 정책까지 지원한다. Kubernetes 서브프로젝트에서 깊이 다룬다.

판단 표 — SDN 도입 시점

환경	SDN 필요?	권장 접근
클라우드(AWS/GCP)	이미 쓰고 있음	VPC API로 충분 (내부 SDN은 벤더 관리)
자체 데이터센터 (소규모)	낮음	전통적 네트워크(L2/L3 스위치)로 충분
자체 데이터센터 (대규모)	높음	OVS+OVN 또는 벤더 SDN(Cisco ACI/VMware NSX)
Kubernetes 클러스터	필수	CNI 플러그인(Calico/Cilium)이 SDN 역할
통신사/5G	필수	ETSI NFV + SDN 컨트롤러(ONOS/ODL)
SD-WAN (지사-본사)	권장	SD-WAN 솔루션(Cisco/VMware/Fortinet)

SDN은 "네트워크를 소프트웨어로 정의한다"는 단순한 원리에서 출발했지만 — 그 영향은 클라우드·데이터센터·Kubernetes·통신망까지 확장됐다. 사용자가 "VPC 만들기" 버튼을 누를 때 — 그 버튼 뒤에서 SDN이 동작하고 있다. SDN을 이해하면 — 클라우드 네트워크의 유연성과 자동화가 어디서 오는지가 보인다.

---

참고

• McKeown, N. et al. "OpenFlow: Enabling Innovation in Campus Networks", 2008 — OpenFlow 원논문. 접근 2026-07-21
• Open vSwitch, "OVS Documentation", Linux Foundation — OVS 공식 문서. 접근 2026-07-21. URL: https://docs.openvswitch.org/
• OVN, "OVN Architecture", OVS 프로젝트 — OVN 설계 문서. 접근 2026-07-21
• CNI, "Container Network Interface Specification", CNCF — CNI 표준. 접근 2026-07-21. URL: https://github.com/containernetworking/cni
• ETSI NFV ISG, "Network Functions Virtualisation" — NFV 표준. 접근 2026-07-21
• Casado, M. et al. "Ethane: Taking Control of the Enterprise", SIGCOMM 2007 — SDN 원형. 접근 2026-07-21
• Kreutz, D. et al. "Software-Defined Networking: A Comprehensive Survey", Proceedings of the IEEE, 2015 — SDN 서베이. 접근 2026-07-21
• AWS Nitro, "AWS Nitro System" — SDN 하드웨어 가속화. 접근 2026-07-21
• Pica8, "SDN Controllers Comparison" — ODL vs ONOS vs Ryu 비교. 접근 2026-07-21
• Cilium Project, "Cilium Documentation" — eBPF 기반 CNI. 접근 2026-07-21. URL: https://docs.cilium.io/
• VMware, "NSX-T Documentation" — NSX 데이터센터 SDN. 접근 2026-07-21
• Cisco, "DNA Center Documentation" — 엔터프라이즈 SDN. 접근 2026-07-21
• Cisco, "SD-WAN Documentation" — SD-WAN 솔루션. 접근 2026-07-21
• ONF, "ONOS Controller Documentation" — 통신사용 SDN 컨트롤러. 접근 2026-07-21
• NTT, "Ryu SDN Framework" — Python 기반 컨트롤러. 접근 2026-07-21. URL: https://ryu.sdntutorial.net/
• ONF, "OpenFlow Switch Specification 1.5" — OpenFlow 최신판. 접근 2026-07-21
• Antrea Project, "Antrea Documentation" — OVS 기반 CNI. 접근 2026-07-21
• Google, "B4: Experience with a Globally-Deployed SDN WAN", SIGCOMM 2013 — Google SD-WAN. 접근 2026-07-21
• OpenStack, "Neutron + OVN Integration" — 클라우드 SDN 통합. 접근 2026-07-21