SDN 핵심 개념 4가지– 네트워크 자동화 현장 경험기

VXLAN 기술 완벽 분석

스위치 콘솔에 시리얼 케이블을 꽂고 IOS 명령어를 외워서 VLAN을 설정하던 시절이 있었다. 장비 30대를 바꾸려면 하루 종일이 걸렸다. SDN이라는 개념을 처음 접했을 때 반갑기도 하고 반신반의하기도 했다. 지금은 현장에서 직접 써보고 나서, 이게 단순한 유행어가 아니라는 걸 확실히 알게 됐다.

핵심 개념 1. 제어 평면과 데이터 평면의 분리 – 사령부와 전투병의 분업

전통적인 네트워크 장비는 생각하는 기능(제어 평면)과 패킷을 전달하는 기능(데이터 평면)이 한 몸에 들어 있다. 마치 한 병사가 작전 계획도 짜고 직접 전투도 하는 것과 같다. SDN은 이 둘을 분리해서, 사령부(컨트롤러)는 전체 그림을 보면서 경로를 결정하고 전투병(스위치·라우터)은 명령만 받아 패킷을 처리한다. 어린 학생에게 비유하자면, 선생님(컨트롤러)이 수업 계획을 짜고 학생(장비)들은 그 계획대로만 움직이는 구조다.

이렇게 분리하면 컨트롤러가 전체 네트워크 지도를 보고 있어서 특정 경로에 트래픽이 몰리기 전에 미리 다른 길로 돌릴 수 있다. 기존 장비는 자기 주변밖에 모르지만, 컨트롤러는 전체를 본다는 게 가장 큰 차이다.

# 특정 IP에서 오는 트래픽을 포트 2로 보내는 규칙
ovs-ofctl add-flow br0 \
  "priority=100,ip,nw_src=10.0.0.1,actions=output:2"

# 특정 MAC에서 오는 트래픽을 플러딩
ovs-ofctl add-flow br0 \
  "priority=50,dl_src=00:11:22:33:44:55,actions=flood"

# 플로우 규칙 확인
ovs-ofctl dump-flows br0

# 특정 플로우 삭제
ovs-ofctl del-flows br0 "ip,nw_src=10.0.0.1"

✅ 장점

컨트롤러 하나에서 수백 대 장비의 정책을 동시에 변경할 수 있다. 정책 변경이 소프트웨어 배포처럼 관리되고, 버전 관리와 롤백도 가능하다. 네트워크에 CI/CD 개념이 적용된다.

⚠️ 단점

컨트롤러가 단일 장애점이 된다. 컨트롤러가 멈추면 전체 네트워크 제어가 마비될 수 있다. 클러스터링 이중화 설계 자체도 복잡하다.

팀에서 처음 SDN을 파일럿으로 구성할 때, 컨트롤러 서버 하나에 모든 걸 올렸다가 서버가 다운되는 순간 스위치들이 기존 플로우 규칙으로만 동작하거나 아예 신규 정책을 못 받는 상황이 발생했다. 단순히 "컨트롤러가 죽으면 좀 불편한 거 아닌가?"라고 생각했던 게 얼마나 순진한 발상이었는지 그때 알았다. 분리의 장점이 클수록 분리된 부분의 장애가 미치는 범위도 크다는 걸 직접 경험했다. 이중화 설계는 선택이 아니라 필수다.

핵심 개념 2. SDN 컨트롤러 – 오케스트라 지휘자의 역할

SDN 컨트롤러는 전체 네트워크의 두뇌다. 오케스트라 연주자들이 각자 열심히 연주해도 지휘자가 없으면 박자가 맞지 않는 것처럼, 스위치들도 컨트롤러 없이는 서로 따로 논다. 컨트롤러는 위쪽으로는 Northbound API를 통해 응용 프로그램과 대화하고, 아래쪽으로는 OpenFlow 같은 Southbound API를 통해 장비들에게 지시를 내린다.

오픈소스로는 OpenDaylight, ONOS, Ryu가 있고, 상용으로는 VMware NSX가 대표적이다. 개발자 입장에서는 네트워크를 API로만 다룰 수 있어서 네트워크 내부 동작을 몰라도 정책을 만들 수 있다는 점이 매력이다.

# Ryu 설치 및 기본 앱 실행
pip install ryu
ryu-manager ryu.app.simple_switch_13

# Ryu 커스텀 컨트롤러 (Python)
from ryu.base import app_manager
from ryu.controller import ofp_event
from ryu.controller.handler import CONFIG_DISPATCHER, set_ev_cls
from ryu.ofproto import ofproto_v1_3

class SimpleSwitch13(app_manager.RyuApp):
    OFP_VERSIONS = [ofproto_v1_3.OFP_VERSION]

    def __init__(self, *args, **kwargs):
        super(SimpleSwitch13, self).__init__(*args, **kwargs)
        self.mac_to_port = {}

    @set_ev_cls(ofp_event.EventOFPSwitchFeatures, CONFIG_DISPATCHER)
    def switch_features_handler(self, ev):
        datapath = ev.msg.datapath
        ofproto = datapath.ofproto
        parser = datapath.ofproto_parser
        match = parser.OFPMatch()
        actions = [parser.OFPActionOutput(ofproto.OFPP_CONTROLLER,
                                          ofproto.OFPCML_NO_BUFFER)]
        self.add_flow(datapath, 0, match, actions)

✅ 장점

API로 네트워크 정책을 코드로 관리할 수 있다. 쿠버네티스처럼 파드가 수시로 바뀌는 환경에서 수동 설정은 사실상 불가능하고, 컨트롤러 자동화가 해결책이 된다.

⚠️ 단점

컨트롤러 운영이 곧 또 하나의 시스템 관리다. 업그레이드, 백업, 모니터링을 따로 챙겨야 하고, 오픈소스 컨트롤러 러닝커브가 상당하다.

Ryu 컨트롤러를 도입하고 나서 가장 힘들었던 건 "이걸 나 말고도 누가 운영할 수 있나"라는 문제였다. 파이썬 코드로 된 컨트롤러를 다른 팀원이 열어보면 당황하는 게 당연했다. 결국 팀 내 스터디를 두 달 진행하고 나서야 공동 운영이 가능해졌다. 컨트롤러 도입이 기술 문제가 아니라 팀 역량 문제라는 걸 그때 배웠다. 기술은 준비됐어도 사람이 준비 안 되면 도입 효과보다 혼란이 더 크다.

핵심 개념 3. OpenFlow 프로토콜 – 컨트롤러와 장비가 말하는 공통 언어

컨트롤러가 지휘자라면 OpenFlow는 악보다. 악보가 없으면 아무리 훌륭한 지휘자도 연주자들에게 정확한 지시를 내릴 수 없다. OpenFlow는 컨트롤러와 장비 사이에서 "이 조건의 패킷이 오면 이렇게 처리해라"는 규칙을 주고받는 표준 언어다. 제조사가 달라도 OpenFlow를 지원하면 같은 컨트롤러로 제어할 수 있다는 게 핵심이다.

플로우 테이블은 출발 IP, 목적지 IP, 포트, MAC 주소 등 다양한 조건을 조합해서 만들 수 있고, 행동은 포워딩, 드롭, 수정, 컨트롤러 전송 등이 있다. 마치 도서관 사서가 책 분류 규칙에 따라 책을 배치하는 것과 비슷하다.

# OVS 설치 및 브리지 구성
apt-get install openvswitch-switch
ovs-vsctl add-br br-sdn
ovs-vsctl add-port br-sdn eth0
ovs-vsctl add-port br-sdn eth1

# 컨트롤러 연결 및 OpenFlow 1.3 설정
ovs-vsctl set-controller br-sdn tcp:192.168.1.100:6633
ovs-vsctl set bridge br-sdn protocols=OpenFlow13

# 플로우 테이블 확인
ovs-ofctl -O OpenFlow13 dump-flows br-sdn

# VLAN 10 트래픽 → 포트 3 포워딩
ovs-ofctl -O OpenFlow13 add-flow br-sdn \
  "priority=200,dl_vlan=10,actions=output:3"

# 특정 포트 패킷 드롭
ovs-ofctl -O OpenFlow13 add-flow br-sdn \
  "priority=300,in_port=2,actions=drop"

✅ 장점

벤더 종속성에서 벗어날 수 있다. 여러 제조사 장비를 하나의 컨트롤러로 통합 관리하는 게 가능해진다.

⚠️ 단점

장비별 OpenFlow 구현 수준이 다르다. 스펙엔 지원이라 나와도 실제 성능이 다를 수 있다. 반드시 실제 장비에서 충분한 사전 검증이 필요하다.

어떤 스위치가 OpenFlow 1.3을 지원한다고 해서 도입을 결정했는데, 실제로 써보니 레이어4 포트 매칭이 하드웨어가 아닌 소프트웨어(CPU)로 처리됐다. 대용량 트래픽에서 스위치 CPU가 치솟아서 통신이 지연됐다. 문서와 현실의 차이를 그때만큼 크게 느낀 적이 없었다. 그 이후로 OpenFlow 기능 검증은 소규모 파일럿 환경에서 실제 트래픽을 흘리며 직접 확인하는 절차를 반드시 거친다. 스펙 문서는 출발점이지 도착점이 아니다.

핵심 개념 4. 네트워크 프로그래밍과 자동화 – 인프라도 이제 코드로 쓴다

SDN의 최종 목표는 네트워크를 코드처럼 다루는 것이다. 요리 레시피에 비유하면 이해가 쉽다. 레시피(코드)가 있으면 누가 만들어도 같은 결과가 나오고, 이력이 남고, 실수가 줄어든다. Ansible, Terraform, Netmiko 같은 도구들이 그 레시피를 작성하는 도구들이다.

특히 VXLAN(RFC 7348)처럼 가상 오버레이 네트워크 기술이나 BGP(RFC 4271) 기반 라우팅 정책도 코드로 선언하고 자동화하는 방향으로 발전하고 있다. OSPF(RFC 2328) 같은 전통 프로토콜도 자동화 도구 안에서 설정된다.

# Ansible VLAN 자동화 - inventory.yaml
all:
  hosts:
    switch1:
      ansible_host: 192.168.1.10
      ansible_network_os: ios
      ansible_user: admin
      ansible_password: password123
      ansible_connection: network_cli

# playbook.yaml
- name: VLAN 설정
  hosts: switch1
  gather_facts: no
  tasks:
    - name: VLAN 100 생성
      ios_vlan:
        vlan_id: 100
        name: PROD_SERVERS
        state: present
    - name: 인터페이스에 VLAN 할당
      ios_l2_interface:
        name: GigabitEthernet0/1
        mode: access
        access_vlan: 100
        state: present

ansible-playbook -i inventory.yaml playbook.yaml

# Netmiko로 장비 대량 설정
from netmiko import ConnectHandler

devices = [
    {"host": "192.168.1.10", "device_type": "cisco_ios"},
    {"host": "192.168.1.11", "device_type": "cisco_ios"},
]

commands = [
    "interface GigabitEthernet0/1",
    "description PROD_SERVER",
    "switchport mode access",
    "switchport access vlan 100",
    "no shutdown"
]

for device in devices:
    device.update({"username": "admin", "password": "password123"})
    conn = ConnectHandler(**device)
    output = conn.send_config_set(commands)
    print(f"{device['host']}: {output}")
    conn.disconnect()

✅ 장점

수십 대 장비를 수 분 만에 동일하게 설정할 수 있다. 오타로 인한 장애를 예방하고, 변경 이력을 Git으로 관리할 수 있다.

⚠️ 단점

잘못된 스크립트는 피해도 자동화한다. 스테이징 환경 테스트와 롤백 플랜은 선택이 아닌 필수다.

운영 환경에서 Ansible 플레이북을 실행하면서 --limit 옵션을 빠뜨려서 전체 스위치에 테스트용 설정이 들어간 적이 있다. 다행히 롤백 플레이북을 미리 만들어뒀기 때문에 10분 안에 복구했지만, 그날 이후로 플레이북 실행 전 --check 드라이런은 팀 필수 절차가 됐다. 자동화가 주는 속도와 편의성은 분명하지만, 그 속도가 실수의 전파 속도도 높인다는 걸 잊으면 안 된다.

마치며 – SDN은 기술이 아니라 사고방식의 변화다

SDN 도입에서 가장 크게 느낀 건 기술이 아니라 일하는 방식이 바뀐다는 거다. 명령어 치는 엔지니어에서 코드 짜는 엔지니어로의 전환. 처음엔 어색했고 저항감도 있었다. 하지만 새벽 긴급 변경 요청이 와도 스크립트 하나로 해결되는 순간, 옛날 방식으로 돌아가고 싶지 않아진다. 그 전환점을 넘기는 게 SDN 도입에서 가장 어려운 부분이다.

출처 및 참고

• RFC 7348 - VXLAN: https://www.rfc-editor.org/rfc/rfc7348
• RFC 2328 - OSPF Version 2: https://www.rfc-editor.org/rfc/rfc2328
• RFC 4271 - BGP-4: https://www.rfc-editor.org/rfc/rfc4271
• Cisco VXLAN EVPN 문서: https://www.cisco.com/...