네트워크 계층과 프로토콜

게시 2026/03/28

By Jinhyeok Ko

조회 29 분읽는 시간

네트워크 계층과 프로토콜

전송계층(L4)이 애플리케이션 프로세스 간의 논리적 통신(End-to-End)을 책임졌다면, 네트워크 계층은 “서로 다른 네트워크 망(LAN과 LAN)을 가로질러 출발지 호스트에서 목적지 호스트까지 패킷을 어떻게 길을 찾아 전달할 것인가(Host-to-Host)” 라는 문제를 해결합니다.

네트워크 계층은 데이터를 네트워크를 통해 목적지까지 전달하는 역할을 수행하며, 라우팅을 통해 최적의 경로를 선택하고, IP 주소를 기반으로 패킷을 전달하는 것이 핵심 기능입니다.

네트워크 계층의 2대 핵심 기능

라우터(Router)

라우터는 서로 다른 네트워크(Subnet)를 논리적으로 연결하고, 패킷(Packet)이 목적지까지 갈 수 있도록 길을 열어주는 3계층(L3) 장비입니다.

라우터 안으로 패킷이 들어오면 라우터는 꽤 많은 연산을 수행해야 합니다. 패킷의 IP 헤더를 열어보고, 수명을 나타내는 TTL(Time To Live) 값을 1 깎고, 헤더가 변했으니 체크섬(Checksum) 을 다시 계산해야 합니다.

이 과정 덕분에 인터넷 망에서 길을 잃은 패킷이 영원히 떠도는 브로드캐스트 스톰(Looping)을 방지할 수 있지만, 2계층 스위치(MAC 주소만 보고 바로 튕겨냄)에 비해 엄청난 소프트웨어적 처리 오버헤드(Processing Delay)가 발생합니다. 라우터의 CPU 성능이 네트워크 전체의 병목(Bottleneck)이 될 수 있습니다.

이러한 병목을 극복하기 위해 라우터의 역할을 ‘매우 빠르게 처리해야 하는 기계적인 일(포워딩)’과 ‘천천히 고민해도 되는 지능적 일(라우팅)’로 분리되어 있습니다.

포워딩(Forwarding / Data Plane: 데이터 평면)

라우터 내부에서 일어나는 지역적(Local)이고 기계적인 패킷 전달 과정입니다.

라우터의 특정 입력 포트(Input Link)로 들어온 패킷을, 목적지 IP 주소에 맞춰 적절한 출력 포트(Output Link)로 밀어내는 작업입니다.

라우터 내부에 있는 포워딩 테이블(Forwarding Table) 을 참조합니다. 매우 빠른 속도가 생명이기 때문에, 현대의 라우터는 이를 소프트웨어(CPU)가 아닌 하드웨어 칩셋(ASIC, TCAM 등) 단에서 나노초 단위로 처리합니다.

최장 일치 규칙(Longest Prefix Match, LPM)

라우터가 포워딩 테이블에서 목적지 IP 주소를 찾을 때, 단순한 $O(1)$ 해시 테이블 매칭을 쓰지 못합니다. 인터넷에는 수십억 개의 IP가 있기 떄문에 테이블에 모든 IP를 기록할 수 없어, IP를 서브넷 대역(192.168.1.0/24) 단위로 묶어서 저장하기 때문입니다.

들어온 패킷의 IP가 테이블의 여러 대역과 중복해서 매칭될 경우 서브넷 마스크가 가장 길게(구체적으로) 일치하는 경로를 최우선으로 선택하여 패킷을 보냅니다. 이를 빠르게 처리하기 위해 고가의 특수 메모리인 TCAM을 사용합니다.

라우팅(Routing / Control Plane: 제어 평면)

네트워크 전체를 아우르는 전역적(Global)이고 지능적인 경로 계산 과정입니다.

송신지부터 수신지까지 수많은 라우터를 거쳐야 하는데, 그중 어떤 경로가 가장 빠르고 막히지 않는 최적의 경로인지 수학적으로 계산하는 작업입니다.

소프트웨어 레벨(CPU)에서 라우팅 프로토콜(OSPF, BGP 등) 이라는 복잡한 알고리즘이 백그라운드에서 끊임없이 돌아가며 라우터들끼리 네트워크 지도를 교환합니다. 이 라우팅 계산의 최종 결과물이 바로 앞서 말한 ‘포워딩 테이블’을 갱신하는 데 사용됩니다.

SDN(Software-Defined Networking)

과거에는 구형 라우터 하나 안에 포워딩(Data Plane)용 칩과 라우팅(Control Plane)용 CPU가 강하게 결합되어 있었습니다. 하지만 AWS, GCP 같은 거대한 현대 클라우드 데이터센터에서는 이 구조가 한계에 부딪혔습니다.

이를 해결하기 위해 개별 라우터에서 뇌(라우팅 로직)를 아예 뽑아내어, 중앙의 거대한 중앙 컨트롤러(소프트웨어 서버)로 합쳤습니다.

중앙 서버가 전체 네트워크 지도를 한눈에 보며 최적의 길을 계산하고, 밑바닥에 깔린 수만 대의 장비(스위치/라우터)들에게는 오직 “포워딩(데이터 전달)”만 지시합니다. 이로 인해 클라우드 가상 네트워크(VPC)를 클릭 몇 번으로 구성할 수 있게 되었습니다.

IP(Internet Protocol)

전 세계 수많은 라우터 장비(시스코, 주니퍼 등)와 운영체제(윈도우, 리눅스)가 서로 다름에도 불구하고 패킷을 정확히 목적지까지 전달할 수 있는 이유는, 이들이 모두 IP라는 단일 프로토콜 표준을 따르고 있기 때문입니다.

IP의 가장 중요한 본질은 철저한 최선형 서비스(Best-Effort Service) 라는 점입니다.

비신뢰성(Unreliability) : IP는 패킷이 목적지에 100% 도달할 것이라고 보장하지 않습니다. 중간 라우터의 버퍼가 꽉 차면 패킷을 가차 없이 버리며(Drop), 데이터가 깨져도 복구하지 않고, 도착 순서가 뒤죽박죽이 되어도 신경 쓰지 않습니다.
비연결형(Connectionless) : TCP처럼 통신 전에 미리 경로를 확보(Handshake)하지 않습니다. 각 패킷은 완전히 독립적인 개체로 취급되어 제각기 다른 경로로 날아갑니다.

왜 이렇게 설계했을까?
이는 ‘종단 간 원칙(End-to-End Principle)’ 을 적용하기 때문입니다. 전 세계의 중심 트래픽을 감당하는 코어 라우터들이 패킷의 상태를 추적하고 에러를 고치느라 CPU를 낭비하게 두면 인터넷은 확장이 불가능합니다.
따라서 IP는 “무조건 빠르고 단순하게 목적지를 향해 던지는 일(Routing)” 에만 집중하여 네트워크망의 하드웨어 비용을 낮추고, 잃어버린 패킷을 다시 요청하는 무거운 책임은 양 끝단의 전송계층(TCP) 소프트웨어에게 떠넘긴 것입니다.

IP 패킷의 구조

IP 프로토콜이 데이터를 어떻게 포장하는지 그 뼈대(Header)를 살펴보면, 네트워크의 동작 원리를 알 수 있습니다.

IPv4 헤더는 보통 20바이트로 구성됩니다.

Source / Destination IP Address (각 32비트) : 출발지와 목적지의 논리적 주소입니다.
TTL (Time To Live - 수명) : 패킷이 영원히 네트워크를 떠도는 ‘무한 루프(Routing Loop)’를 막기 위한 장치입니다. 라우터를 하나 거칠 때마다 이 값이 1씩 감소하며, 0이 되면 라우터는 패킷을 즉시 폐기하고 출발지에게 ICMP(Time Exceeded) 에러 메시지를 보냅니다. (이 원리를 이용한 것이 바로 traceroute 명령어입니다.)
Protocol : 상위 계층(L4)에 어떤 프로토콜이 기다리고 있는지 알려줍니다. (TCP는 6, UDP는 17)

IPv4 (Internet Protocol version 4)

32비트 주소 체계로 약 43억($2^{32}$) 개의 주소를 가지며, 점(dot)으로 구분된 4개의 10진수(192.168.1.0)로 표현합니다.

헤더 길이가 가변적이며, 불필요한 옵션 필드와 체크섬(Checksum) 검사 때문에 라우터가 패킷을 처리할 때마다 CPU 연산을 많이 소모합니다.

주소가 부족하여, 사설 IP를 공인 IP로 바꾸는 NAT 기술에 의존하며, 종단 간 원칙이 훼손되는 주원인 입니다. 현재 IPv6로 전환 중이지만, 여전히 IPv4가 주로 사용됩니다.

IPv6 (Internet Protocol version 6)

128비트 주소 체계로 $2^{128}$개의 무한에 가까운 주소를 가지며, 콜론(colon)으로 구분된 8개의 16진수로 표현합니다.

라우터의 부담을 줄이기 위해 헤더를 40바이트 고정 크기로 단순화했습니다. IPv4에 있던 라우터 단의 ‘체크섬 검사’와 ‘단편화(Fragmentation)’ 기능을 제거했습니다. 덕분에 라우터는 패킷을 열어보지 않고 기계적으로 빠르게 포워딩만 수행할 수 있습니다.

NAT 없이 모든 기기가 공인 IP를 가질 수 있어 완벽한 P2P 통신과 종단 간 원칙이 복원됩니다.

단편화(Fragmentation)의 책임 전가

패킷이 너무 클 때 누가 그것을 쪼갤지에 대한 IPv4와 IPv6의 기술적 차이입니다.

IPv4의 방식 : 전송 중인 패킷이 특정 링크의 최대 전송 단위(MTU)보다 크면, 중간에 있는 라우터가 알아서 패킷을 여러 조각으로 쪼갭니다(단편화). 이는 라우터의 CPU를 혹사시키는 오버헤드입니다.
IPv6의 방식(Path MTU Discovery) : IPv6 라우터는 패킷을 쪼개지 않고, 패킷이 너무 크면 그냥 버리고 송신자에게 “너무 커서 버렸으니 네가 작게 쪼개서 다시 보내”라는 에러(ICMPv6 Packet Too Big)를 보냅니다. 즉, 단편화의 무거운 책임을 라우터에서 양 끝단의 단말(End Node) 로 떠넘겨 네트워크 중심부의 처리 속도를 극대화했습니다.

IP 주소의 계층화(Hierarchical Routing)

IPv4 주소는 총 32비트로 이루어져 있습니다. 이 32비트를 어떻게 쪼개느냐를 결정하는 것이 바로 서브넷 마스크입니다. 라우터는 들어온 IP 주소와 서브넷 마스크를 비트 단위 논리곱(Bitwise AND) 연산하여 목적지 네트워크를 찾아냅니다.

네트워크 부분 비트(Network ID) : 해당 IP가 속한 네트워크를 식별하며, 라우터가 라우팅할 때 사용됩니다.
호스트 부분 비트(Host ID) : 네트워크 내 개별 장치(호스트)를 식별하며, 스위치가 최종 목적지를 찾을 때 사용됩니다.

CIDR(Classless Inter-Domain Routing) 표기법

서브넷 마스크를 255.255.255.0처럼 길게 쓰지 않고, 네트워크 비트의 개수를 슬래시(/)뒤에 표기합니다.

192.168.1.0/24 : 앞에서 24비트가 네트워크 부분, 나머지 8비트가 호스트 부분이라는 뜻입니다.

예약된 주소와 유효 호스트

하나의 서브넷(Subnet)을 쪼개어 만들면, 호스트 부분의 비트($H$) 조합에 따라 총 $2^{H}$ 개의 IP를 얻을 수 있습니다. 하지만 이 IP들을 PC나 서버에 전부 할당할 수는 없습니다. 네트워크의 동작 원리상 반드시 예약되어야 하는 2개의 특수 주소가 존재하기 때문입니다.

네트워크 주소(Network Address) : 호스트 부분의 비트가 모두0인 주소입니다. 해당 서브넷(네트워크 망) 자체를 대표하는 식별자입니다. 라우팅 테이블에 기록되는 주소이며, 특정 기기에 할당할 수 없습니다.
브로드캐스트 주소(Broadcast Address) : 호스트 부분의 비트가 모두1인 주소입니다. 해당 서브넷에 연결된 모든 기기에게 동시에 데이터를 전송할 때(1:All) 사용하는 주소입니다. ARP 요청 등이 이 주소를 통해 전송되므로, 특정 기기에 할당할 수 없습니다.
유효 호스트(Usable/Valid Hosts) : PC, 서버, 라우터 포트 등에 실제로 부여할 수 있는 가용 IP의 범위입니다. 전체 호스트 개수에서 특수 주소를 뺀 값입니다. ($2^{H} - 2$)

NAT(Network Address Translation)

IPv4의 주소가 고갈되는 상황에서 모든 기기에 공인 IP를 할당할 수 없어졌습니다. 이를 해결하기 위해 로컬 망에서는 공인 IP(Public IP) 대신 사설 IP(Private IP)를 사용하게 하고 외부와 통신할 때만 공인 IP를 빌려 쓰게 하는 기술을 고안했습니다.

공인 IP(Public IP) : 전 세계 인터넷 망에서 유일하게 식별되는 진짜 주소입니다. 통신사(ISP)로부터 할당받습니다.
사설 IP(Private IP) : 인터넷 밖으로는 나갈 수 없고, 오직 로컬 네트워크(공유기 안쪽)에서만 유효한 주소입니다.

동작 원리: NAPT(Network Address Port Translation)

공유기는 IP만 변환하는 단순한 NAT이 아니라, 포트 번호까지 함께 변환하는 NAPT(또는 PAT) 방식을 사용합니다. 하나의 공인 IP로 수십 대의 내부 기기가 동시에 인터넷을 쓸 수 있게 합니다.

요청(내부 → 외부) : 내부 장치(사설 IP : 192.168.0.5, 출발지 포트 : 10001)이 외부 서버로 HTTP 요청을 보냅니다.
변환(공유기/NAT 장비) : 패킷이 공유기를 통과할 때, 공유기는 패킷의 헤더를 까서 출발지 IP를 자신의 공인 IP(203.0.113.1)로, 출발지 포트를 자신이 임의로 생성한 포트(50001)로 바꿉니다.
기록(NAT Table) : 공유기는 이 변환 기록(192.168.0.5:10001 $\leftrightarrow$ 203.0.113.1:50001)을 자신의 메모리인 NAT Table에 기록합니다.
응답(외부 → 내부) : 외부 서버는 요청이 203.0.113.1:50001에서 온 것으로 확인하고 그곳으로 응답을 보냅니다.
역변환 : 패킷이 공유기에 도착하면, 공유기는 NAT 테이블을 확인한 후 패킷 헤더의 목적지 주소를 사설 IP로 다시 바꿔서 내부 장치로 전달해 줍니다.

NAT의 장점과 한계

IP 주소 절약 : 1개의 공인 IP로 이론상 약 6만 개(포트 개수 한계)의 내부 연결을 처리할 수 있습니다.
방화벽 효과 : 외부 인터넷에서는 공유기의 공인 IP만 보일 뿐, 그 안쪽에 내부 장치가 무엇인지, 사설 IP가 무엇인지 확인할 수 없습니다. 외부에서 내부 사설 IP로 직접 들어오는 해킹 시도를 차단하는 보안 격리(Security Isolation) 효과를 제공합니다.
한계점 : 네트워크 중심부의 라우터는 패킷의 내용(IP/Port)을 건드려서는 안된다는 종단 간 원칙을 훼손합니다. 공유기가 패킷 헤더를 매번 까보고 수정해야 하므로 장비의 CPU 오버헤드가 발생하며, P2P 통신에 장애를 유발합니다.

DHCP(Dynamic Host Configuration Protocol)

과거에는 네트워크 관리자가 모든 PC를 돌아다니며 일일이 고정 IP(Static IP)를 입력해야 했습니다. 이는 막대한 휴먼 에러(IP 충돌)를 유발했고, 관리가 불가능했습니다. DHCP는 이 문제를 두 가지 핵심 원리로 해결합니다.

동적 할당(Dynamic Allocation) : 네트워크에 접속하는 기기에게 IP 주소, 서브넷 마스크, 기본 게이트웨이(Default Gateway), DNS 서버 주소 등 네트워크 통신에 필요한 모든 설정값을 한 번에 자동으로 묶어서 제공합니다.
임대(Lease) 메커니즘 : IP를 영구적으로 주는 것이 아니라 ‘일정 기간 빌려주는(Lease)’ 방식을 택했습니다. 기기가 네트워크를 떠나면 해당 IP를 회수하여 다른 기기에게 재할당함으로써, IP 주소의 낭비를 막아냅니다.

동작 원리: 4단계 DORA 프로세스

기기가 처음 네트워크에 연결되어 IP를 할당받는 과정은 4번의 패킷 교환으로 이루어지며, 이를 각 단계의 앞 글자를 따서 DORA라고 부릅니다. 이 과정은 TCP가 아닌 속도가 빠르고 브로드캐스트가 가능한 UDP(서버 포트 67, 클라이언트 포트 68)를 기반으로 동작합니다.

Discover(탐색 - 클라이언트 → 서버) : 단말기는 아직 자신의 IP도 모르고, DHCP 서버의 IP도 모릅니다. 따라서 목적지 IP를 255.255.255.255(브로드캐스트)로 설정하여 네트워크 전체에 메시지를 전송합니다.
Offer(제안 - 서버 → 클라이언트) : 메시지를 들은 DHCP 서버(들)는 자신의 IP 풀에서 남는 IP 하나를 골라, 임대 시간(Lease Time) 등의 설정값과 함께 제안합니다. (클라이언트가 아직 IP가 없으므로 MAC 주소를 기반으로 전송합니다.)
Request(요청 - 클라이언트 → 서버) : 여러 대의 DHCP 서버가 동시에 제안했을 수 있으므로, 클라이언트는 그 중 하나를 선택하여 공식적으로 사용을 요청합니다. 이때도 네트워크 전체에 알려 다른 서버들이 자신이 제안했던 IP를 다시 거둬들이게 하기 위해 브로드캐스트로 전송합니다.
Acknowledge(확인 - 서버 → 클라이언트) : 서버가 최종적으로 IP 임대를 승인(ACK)하고, 클라이언트는 이때부터 해당 IP를 자신의 랜카드에 세팅하여 통신을 시작합니다.

IP 갱신(Renewal) 메커니즘
임대 시간(Lease Time)이 만료되기 전에 기기는 IP를 연장해야 합니다.
기기는 임대 시간의 절반(50%)이 지났을 때, IP를 빌려준 서버에게 유니캐스트(Unicast)로 연장 요청(DHCP Request)을 보냅니다.
DHCP Relay Agent(IP Helper)
브로드캐스트 트래픽은 라우터(L3)를 넘어갈 수 없다는 것이 네트워크의 대원칙입니다. 회사의 부서(VLAN)가 10개로 쪼개져있다면, 라우터를 넘지 못하는 DHCP의 특성상 부서마다 DHCP 서버를 설치해야합니다.
이 비용 낭비를 막기 위해 DHCP Relay Agent 기능이 고안되었습니다. 라우터나 L3 스위치에 이 기능을 설정해두면, 클라이언트의 브로드캐스트(Discover)를 라우터가 대신 받아 이를 유니캐스트로 변환한 뒤 중앙에 있는 단 1대의 통합 DHCP 서버로 전송합니다.

DHCP는 완벽한 Plug and Play를 지원하며, 대규모 엔터프라이즈 환경에서 중앙 집중적인 IP/네트워크 관리가 가능합니다.

하지만 다음과 같은 단점이 있습니다.

Single Point of Failure(SPOF, 단일 장애점) : DHCP 서버가 다운되면, 새롭게 연결된 기기는 IP를 받지 못해 사내 망이 마비됩니다. (이를 막기 위해 DHCP 다중화/Failover 구성을 합니다.)
보안 취약점 : 누구나 브로드캐스트를 통해 IP를 요구할 수 있으므로, 해커가 가짜 MAC 주소로 무수히 많은 Discover를 날려 서버의 IP 풀을 고갈시키는 DHCP Starvation 공격에 취약합니다. 또한, 해커가 몰래 가짜 DHCP 서버를 띄워 잘못된 게이트웨이(해커의 PC)를 할당받게 만드는 DHCP Spoofing 공격의 위험도 존재합니다. (L2 스위치의 DHCP Snooping 기능으로 방어해야 합니다.)

네트워크