스위치 콘솔에 시리얼 케이블을 꽂고 IOS 명령어를 외워서 VLAN을 설정하던 시절이 있었다. 장비 한 대의 설정을 바꾸려면 SSH로 접속해서 명령어를 치고, 다음 장비로 가서 또 치고, 전체 30대면 하루 종일 걸리는 작업이었다. SDN이라는 개념을 처음 접했을 때 "소프트웨어로 네트워크를 제어한다"는 말이 반갑기도 했고 반신반의하기도 했다. 지금은 현장에서 SDN을 직접 써보고 나서, 이게 단순한 유행어가 아니라는 걸 확실히 알게 됐다. 네 가지 핵심 개념으로 나눠서 경험한 이야기를 풀어본다.
핵심 개념 1. 제어 평면과 데이터 평면의 분리 – 사령부와 전투병의 분업
전통적인 네트워크 장비는 생각하는 것(제어 평면)과 패킷을 전달하는 것(데이터 평면)이 한 장비 안에 묶여 있다. 예를 들어 학교 선생님이 수업 계획도 직접 짜고, 교단에 서서 강의도 하고, 숙제 채점까지 혼자 다 하는 것과 비슷하다. 물론 가능하긴 한데, 학생 수가 수백 명으로 늘어나면 감당이 안 된다. 선생님(제어 평면)과 보조 강사(데이터 평면)를 역할별로 분리하는 게 SDN의 핵심 아이디어다.
사령부(SDN 컨트롤러)는 전체 네트워크 지도를 들고 최적 경로를 결정하고, 전투병(스위치, 라우터)은 사령부의 명령만 받아서 패킷을 빠르게 처리한다. 덕분에 특정 링크에 트래픽이 몰릴 것 같으면 컨트롤러가 미리 다른 경로로 트래픽을 돌려버릴 수 있다. 장비 혼자서는 절대 할 수 없는 일이다.
# OpenFlow 기반 SDN에서 플로우 규칙 추가 예시 (OVS - Open vSwitch)
# 특정 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"핵심 개념 2. SDN 컨트롤러 – 오케스트라 지휘자의 역할
SDN 컨트롤러는 전체 네트워크의 두뇌다. 오케스트라 비유가 딱 맞는다. 바이올린, 첼로, 트럼펫 연주자들이 각자 악보를 보며 연주하면 소리는 나지만 화음이 맞지 않는다. 지휘자가 있어야 박자와 화음이 맞아 아름다운 음악이 된다. SDN 컨트롤러는 각 스위치와 라우터가 제때 제대로 패킷을 처리하도록 지시하고 조율하는 지휘자다.
대표적인 오픈소스 컨트롤러로는 OpenDaylight, ONOS, Ryu가 있고, 상용으로는 VMware NSX가 가장 많이 쓰인다. 컨트롤러는 위로는 Northbound API로 응용 프로그램과 통신하고, 아래로는 Southbound API(OpenFlow 등)로 실제 장비를 제어한다. 덕분에 애플리케이션 개발자는 네트워크 내부 구조를 몰라도 API 호출 몇 줄로 네트워크 정책을 바꿀 수 있다.
# Ryu SDN 컨트롤러 설치
pip install ryu
# L2 스위칭 기본 앱 실행
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
from ryu.controller.handler import 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)핵심 개념 3. OpenFlow 프로토콜 – 컨트롤러와 장비가 말하는 공통 언어
SDN 컨트롤러가 지휘자라면, OpenFlow는 악보다. 아무리 훌륭한 지휘자라도 악보 없이는 연주자들이 따를 수가 없다. OpenFlow는 컨트롤러와 네트워크 장비 사이에서 플로우 규칙을 주고받는 표준 프로토콜이다. 장비를 만든 회사가 달라도 OpenFlow를 지원하면 같은 컨트롤러로 제어할 수 있다는 게 핵심이다.
플로우 테이블은 쉽게 말해 "이 조건의 패킷이 오면 이 행동을 해라"는 규칙 목록이다. 조건은 출발 IP, 목적지 IP, 포트 번호, MAC 주소 등을 자유롭게 조합할 수 있고, 행동은 특정 포트로 보내기, 버리기, 패킷 내용 수정, 컨트롤러로 전송 등이 있다. 마치 빠른 배달 정렬 센터처럼, 패킷이 들어오면 규칙표를 보고 즉시 어디로 보낼지 결정한다.
# Open vSwitch 설치 (Ubuntu)
apt-get install openvswitch-switch
# OVS 브리지 생성 및 포트 추가
ovs-vsctl add-br br-sdn
ovs-vsctl add-port br-sdn eth0
ovs-vsctl add-port br-sdn eth1
# OpenFlow 컨트롤러 연결 설정
ovs-vsctl set-controller br-sdn tcp:192.168.1.100:6633
# OpenFlow 버전 설정 (1.3 권장)
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"핵심 개념 4. 네트워크 프로그래밍과 자동화 – 인프라도 이제 코드로 쓴다
SDN의 최종 목표는 네트워크를 코드처럼 다루는 것이다. 요리 레시피에 비유하면 딱 맞다. 요리사가 매번 즉흥적으로 요리하면 맛이 달라지지만, 레시피(코드)가 있으면 누가 만들어도 같은 맛이 난다. 네트워크도 마찬가지다. 사람이 CLI에서 직접 명령어를 치는 대신 코드로 정의해두면 환경을 몇 번이든 동일하게 재현할 수 있다. 실수도 줄고, 기록도 남는다.
Ansible, Terraform, 파이썬 스크립트 등 다양한 도구가 SDN 자동화에 쓰인다. 특히 Ansible의 네트워크 모듈은 Cisco, Juniper, Arista 등 주요 장비를 지원해서 현장에서 가장 많이 선택된다.
# 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 - VLAN 설정 자동화
- 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"},
{"host": "192.168.1.12", "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"})
connection = ConnectHandler(**device)
output = connection.send_config_set(commands)
print(f"{device['host']}: {output}")
connection.disconnect()마치며 – SDN은 기술이 아니라 사고방식의 변화다
SDN을 도입하면서 가장 크게 느낀 건 기술 자체보다 일하는 방식이 바뀐다는 거다. 네트워크 엔지니어가 장비 앞에서 명령어를 치는 사람에서 코드를 짜는 사람으로 역할이 바뀐다. 처음엔 어색하고 저항감이 생기는 게 자연스럽다. 오래 해온 방식을 버리는 건 쉽지 않다.
그런데 직접 써보고 나면, 새벽에 긴급 네트워크 변경 요청이 와도 SSH 30번 붙어다닐 필요가 없어진다. 스크립트 하나 돌리면 된다. 그 전환점을 넘기는 게 SDN 도입에서 가장 어려운 부분이고, 동시에 가장 보람 있는 순간이다.
'IT적응기' 카테고리의 다른 글
| 컨테이너 네트워크 5가지 핵심 통신 방법– 현장 엔지니어의 실전 기록 (0) | 2026.04.17 |
|---|---|
| SDN 핵심 개념 4가지– 네트워크 자동화 현장 경험기 (0) | 2026.04.17 |
| VPC(Virtual Private Cloud)클라우드 안에 네트워크 만드는 법! (0) | 2026.04.16 |
| 기초 보안의 ACL(Access Control List)로 특정 IP 차단 설정법 (0) | 2026.04.16 |
| 트래픽 병목 현상 LACP(Link Aggregation)로 대역폭을 확장방법 (0) | 2026.04.15 |
