한 줄 정의
네트워크는 노드들이 패킷을 주고받는 체계이고, IP 주소·NAT·VPN·전송 프로토콜은 그 패킷을 목적지까지 안전하게 보내기 위한 기초 장치입니다.
쉽게 말하면
인터넷을 도시 전체의 택배망, 패킷을 소포라고 생각해 봅시다.
공인 IP는 전국에서 유일한 도로명 주소이고, 사설 IP는 아파트 단지 안의 동·호수입니다. 옆 단지에도 101동 101호는 있지만(다른 네트워크의 같은 사설 IP), 단지 안에서만 유일하면 배달에 문제가 없습니다.
NAT는 단지 경비실입니다. 입주민이 소포를 보낼 때는 발신인 주소를 단지 대표 주소로 바꿔 내보내고(SNAT), 단지 앞으로 도착한 소포는 동·호수를 찾아 안으로 배달합니다(DNAT). 덕분에 세대마다 도로명 주소를 받을 필요가 없어졌고, 이것이 IPv4 주소가 아직 고갈되지 않은 이유입니다.
DNS는 “네이버”라고 이름만 대면 주소를 찾아 주는 주소록이고, 라우터는 소포를 다음 물류 허브로 넘기는 중간 거점입니다. VPN은 두 단지 사이에만 뚫려 있는 전용 보안 통로입니다.
배송 방식도 고를 수 있습니다. TCP는 수령 확인과 순서 보장이 되는 등기, UDP는 빠르지만 분실을 감수하는 일반 우편, QUIC은 등기의 보장은 유지하면서 접수 절차를 확 줄인 신형 배송 서비스입니다.
왜 중요한가?
서버에서 외부 업체 API에 연결이 안 되는 사고가 있었습니다. 코드의 API 주소, 방화벽 아웃바운드 설정, 제공자 측 인바운드 허용 정책까지 전부 확인했는데 모두 이상이 없었습니다.
원인은 IP였습니다. 그 서버는 공인 IP 2개와 연결되어 있었는데, 하나는 외부에서 서버로 들어올 때 쓰는 IP고 다른 하나는 서버에서 외부로 나갈 때 쓰는 IP였습니다. 업체에 공유해야 할 것은 후자였는데 전자를 알려줘서 접속 허용 목록에 엉뚱한 IP가 등록된 것입니다.
서버 개발자가 네트워크 엔지니어만큼 깊이 알 필요는 없습니다. 하지만 네트워크 지식이 전무하면 이렇게 쉽게 해결할 수 있는 문제도 오랫동안 처리하지 못하게 됩니다.
핵심 내용
노드, 네트워크, 라우터
- 노드(node): 데이터를 송수신하는 모든 장치 (휴대폰, 노트북, 서버 장비)
- 네트워크(network): 노드들이 데이터를 주고받기 위해 연결된 시스템 (예: 집 공유기에 연결된 장치들)
- 패킷(packet): 노드가 전송하는 데이터 단위. 발신자·수신자 정보를 담은 헤더 와 데이터를 담은 페이로드 로 구성되며, 데이터는 일정 크기의 여러 패킷으로 나뉘어 전송됩니다
- 라우터(router): 서로 다른 네트워크에 속한 노드는 직접 패킷을 주고받을 수 없으므로, 라우터가 네트워크 간에 패킷을 전달합니다
서울에서 부산까지 가는 고속도로 경로가 여러 개이듯 두 노드 간 라우터 경로도 여러 개이며, 각 라우터는 목적지 주소를 보고 알맞은 다음 라우터를 선택합니다.
IP 주소와 도메인
IP 주소 는 네트워크에서 각 노드를 구분하는 주소입니다. 현재 일반적으로 쓰는 IPv4 주소는 223.130.192.248처럼 1바이트(0~255) 숫자 블록 4개로 구성됩니다.
IPv6가 있는데도 여전히 IPv4를 쓰는 이유
32비트 IPv4는 약 43억 개뿐이라 1990년대 초부터 고갈이 예측됐고, 그래서 128비트 IPv6 가 만들어졌습니다. 그런데도 여전히 IPv4가 주력인 것은 사설 IP와 NAT 덕분에 실제로 필요한 공인 IP 개수가 크게 줄었기 때문입니다.
도메인 이름(Domain Name) 은 기억하기 어려운 IP 주소에 붙이는 이름이고, 도메인 이름을 IP 주소로 변환하는 체계가 DNS(Domain Name System) 입니다. 일종의 인터넷 전화번호부입니다.
도메인 계층 구조
점(.)으로 구분하며 오른쪽이 상위 계층입니다.
| 구분 | 최상위 도메인 | 주요 이름 위치 | 예 |
|---|---|---|---|
| 일반 최상위 | com, org, net, gov, app 등 | 2차 도메인 (회사·브랜드명) | naver.com, google.com |
| 국가 최상위 | kr, jp, au 등 (2계층까지 예약: ac.kr, co.kr) | 3차 도메인 | gasapp.co.kr |
이름이 IP로 바뀌는 과정
브라우저에 www.naver.com을 입력하면 브라우저가 DNS 서버에 IP를 물어보고, 응답받은 IP로 패킷을 전송합니다.
- hosts 파일: 호스트 이름 → IP 매핑을 정의한 로컬 파일 (리눅스는
/etc). DNS 서버보다 우선 적용되며, localhost 매핑도 이 파일에 있습니다 - localhost = 127.0.0.1: 자기 자신을 참조하는 루프백(loopback) 주소
- 한 도메인 이름에 IP를 여러 개 매핑할 수 있고(
nslookup으로 확인 가능), DNS 서버가 등록된 IP를 번갈아 응답해 부하 분산 에 활용합니다
고정 IP와 동적 IP
동일 네트워크에서 각 노드는 서로 다른 IP를 가져야 하며, 겹치면 IP 충돌이 발생합니다.
| 방식 | 할당 | 대표 사례 |
|---|---|---|
| 고정 IP | 노드에 직접 지정 | 서버 |
| 동적 IP | 네트워크 연결 시마다 DHCP 서버가 IP·게이트웨이·서브넷 마스크·DNS 서버 주소를 제공 | 가정 공유기 |
동적 IP라고 매번 IP가 바뀌는 것은 아니고, DHCP 서버에 따라 일정 시간 동일한 IP를 할당하기도 합니다.
공인 IP와 사설 IP
| 공인(public) IP | 사설(private) IP | |
|---|---|---|
| 적용 범위 | 인터넷 전체 | 특정 네트워크 내부 |
| 외부 접근 | 가능 (방화벽으로 막지 않았다면 누구나) | 불가 |
| 유일성 | 전 세계에서 유일 | 소속 네트워크 안에서만 유일하면 됨 |
| 사용처 | 홈페이지·공개 API 등 인터넷 서비스 제공 대상 | 공유기에 연결된 기기, 서버 네트워크 내부 노드 |
사설 IP로 쓸 수 있는 대역은 세 가지로 정해져 있습니다: 192.168.x.x, 10.x.x.x, 172.16.x.x ~ 172.31.x.x. 가정 공유기는 주로 192.168 대역을 쓰며, ifconfig(리눅스)나 ipconfig(윈도우)로 할당된 IP를 확인할 수 있습니다.
인터넷 초창기처럼 모든 기기가 공인 IP를 썼다면 IPv4는 한참 전에 고갈됐을 것입니다. 서버 네트워크·회사·가정이 사설 IP를 쓰는 덕에 필요한 공인 IP 개수가 적습니다.
NAT
NAT(Network Address Translation) 는 내부에서 쓰는 사설 IP와 인터넷에서 쓰는 공인 IP 간의 변환을 담당하며, 주로 인터넷에 연결된 라우터 같은 네트워크 장비가 수행합니다.
| 종류 | 변환 대상 | 방향 |
|---|---|---|
| SNAT(Source NAT) | 소스 IP: 사설 → 공인 | 내부 네트워크에서 인터넷으로 나갈 때 |
| DNAT(Destination NAT) | 목적지 IP: 공인 → 사설 | 공인 IP로 들어온 패킷을 내부 서버로 보낼 때 |
flowchart LR N["내부 노드<br/>(사설 IP 192.168.1.10)"] -- "나갈 때 SNAT<br/>소스: 사설 → 공인" --> G["NAT 장비<br/>(공인 IP 보유)"] G -- "들어올 때 DNAT<br/>목적지: 공인 → 사설" --> N G <--> I(("인터넷"))
DNAT는 서버를 구성할 때 사용됩니다. 보안·이중화를 고려해 서버 노드는 사설 IP만 갖고, 공인 IP는 네트워크 연결을 관리하는 장비(라우터·방화벽)에 할당합니다. 이 장비가 공인 IP로 들어온 패킷을 DNAT로 사설 IP 서버 노드에 전달합니다.
내 공인 IP 확인
SNAT로 변환된 공인 IP는 https://ifconfig.me 접속 또는
curl ifconfig.me명령어로 확인할 수 있습니다.
VPN
서버를 운영하면 서버 노드에 SSH로 접속하거나 DB에 접속해 SQL을 실행할 일이 생기는데, 서버 네트워크의 노드는 사설 IP라 외부에서 직접 접근할 수 없습니다. NAT로 공인 IP를 열어 주는 방법은 노드가 많으면 공인 IP를 전부 매핑할 수 없고, 가능하더라도 모든 노드가 공인 IP로 노출되는 보안 문제가 생깁니다.
VPN(Virtual Private Network) 은 인터넷 같은 공용 네트워크 위에서 서로 다른 네트워크 간에 암호화된 연결을 제공합니다. 두 네트워크가 마치 하나의 사설 네트워크에 있는 것처럼 연결되므로, 허용된 사용자만 안전하게 서버 네트워크에 접근할 수 있습니다.
- 사무실 ↔ 서버 네트워크: 양쪽에 둔 VPN 장비 간에 통신을 암호화합니다
- 집·카페 같은 외부 공간: 노트북의 VPN 클라이언트 로 서버 네트워크의 VPN 장비에 연결합니다
프로토콜과 TCP, UDP, QUIC
프로토콜(protocol) 은 두 노드가 데이터를 주고받기 위해 정의한 규칙입니다. 네트워크는 여러 계층으로 구성되고 계층마다 사용하는 프로토콜이 있습니다.
| TCP/IP 모델 계층 | 주요 프로토콜 |
|---|---|
| 애플리케이션 | HTTP, FTP, SMTP |
| 전송 | TCP, UDP |
| 네트워크 | IP |
| 데이터 링크 / 물리 | — |
개발자가 주로 다루는 것은 전송 계층과 애플리케이션 계층입니다.
TCP — 신뢰성
TCP(Transmission Control Protocol) 는 연결 기반 프로토콜입니다. 전화를 걸고 상대가 받은 뒤에 대화하듯, 두 노드가 3-Way Handshake(SYN → SYN-ACK → ACK)로 먼저 연결을 맺고 데이터를 주고받습니다.
패킷 순서를 보장하고 유실되면 재전송하므로 안정적입니다. HTTP, SMTP 같은 애플리케이션 계층 프로토콜이 TCP 기반으로 동작하는 이유입니다.
대신 시퀀스 번호·확인 응답·재전송이 붙으면서 UDP 대비 느립니다. 특히 일부 패킷이 유실되면 해당 패킷이 도착할 때까지 이후 패킷을 처리하지 못하는 HOL 블로킹(Head-of-Line Blocking) 이 전체 전송 속도를 떨어뜨립니다.
UDP — 속도
UDP(User Datagram Protocol) 는 연결 과정 없이 바로 데이터를 전송합니다. 정상 전송 여부도 순서도 보장하지 않으므로, UDP를 쓰는 애플리케이션은 데이터 유실이 발생할 수 있다고 가정하고 개발해야 합니다. 응답 확인·패킷 정렬이 없어 빠르기 때문에 DNS, VoIP, 게임처럼 속도가 중요하거나 일부 유실이 허용되는 통신에 쓰입니다.
QUIC — 빠르면서 신뢰성 있게
TCP는 신뢰성이 있지만 느리고, UDP는 빠르지만 신뢰성이 없습니다. 둘을 합치려는 목적으로 개발된 프로토콜이 QUIC 입니다.
- UDP 기반 + 연결 관리: 데이터에 연결 ID(Connection ID) 를 포함시켜 두 노드 간 연결을 유지하고, 혼잡 제어·패킷 유실 복구도 QUIC 프로토콜 수준에서 제어합니다
- TLS 통합: QUIC 패킷은 기본적으로 암호화됩니다. TCP 기반 HTTPS는 3-Way Handshake와 TLS Handshake를 각각 거쳐 여러 차례 통신한 뒤에야 연결되지만, QUIC은 TLS를 통합해 이 과정을 단축했습니다
- 멀티플렉싱: 한 연결에서 여러 스트림을 동시에 처리하므로 한 스트림에서 HOL 블로킹이 발생해도 다른 스트림에 영향을 주지 않습니다. HTTP/2도 멀티플렉싱을 지원하지만 TCP 자체의 HOL 블로킹은 피할 수 없습니다
HTTP/3이 QUIC을 기반으로 합니다.
| HTTP/1.1·HTTP/2 스택 | HTTP/3 스택 |
|---|---|
| HTTP/2 · HTTP/1.1 | HTTP/3 |
| TLS | QUIC (TLS 통합) |
| TCP | UDP |
| IP | IP |
크롬·엣지·사파리 등 주요 브라우저와 구글·페이스북, 아카마이·클라우드플레어·AWS 클라우드프론트 같은 주요 CDN이 이미 HTTP/3을 지원합니다. 브라우저 개발자 도구에서 Protocol 값이 h3이면 HTTP/3 연결입니다.
TCP 연결은 65,535개가 한계가 아닙니다
포트 번호가 부호 없는 16비트 정수(최대 65535)라서 생기는 오해입니다. TCP 연결은 (로컬 IP, 로컬 포트, 원격 IP, 원격 포트) 조합으로 구분되므로, 로컬 IP가 고정이어도 이론상 2^16 × 2^32 × 2^16 = 2^64(약 1,844경) 개까지 가능합니다. 65,535는 하나의 로컬 IP에서 특정 원격 IP의 1개 포트에 연결할 수 있는 개수일 뿐입니다. 실제 한계는 OS 설정(파일 디스크립터 개수, 포트 범위 등)이 결정합니다.
비교 / 트레이드오프
| TCP | UDP | QUIC | |
|---|---|---|---|
| 연결 | 3-Way Handshake | 없음 | 연결 ID로 유지 |
| 신뢰성 (순서·재전송) | 보장 | 없음 | QUIC 수준에서 보장 |
| 속도 | 상대적으로 느림 | 빠름 | 빠름 (핸드셰이크 단축) |
| 암호화 | TLS 별도 수행 | 별도 수행 | TLS 통합 (기본 암호화) |
| HOL 블로킹 | 있음 | — | 스트림 간 전파 없음 |
| 대표 용도 | HTTP, SMTP | DNS, VoIP, 게임 | HTTP/3 |
내 생각
- “우리 서버의 IP”는 방향에 따라 다릅니다. 외부 업체에 방화벽 허용을 요청할 때는 서버에서
curl ifconfig.me로 확인한 아웃바운드 공인 IP를 줘야 합니다. 인바운드용 IP를 주는 실수가 도입부 사고의 정확한 재현입니다. - DB 접속이 안 되면 코드보다 접속 경로를 먼저 봅니다. 서버 네트워크 노드는 사설 IP라는 전제를 기억하면, “로컬에서는 되는데 서버에서는 안 되는” 문제의 상당수를 VPN·망 문제로 좁힐 수 있습니다.
- gRPC·HTTP/2를 써도 TCP HOL 블로킹은 남아 있습니다. 멀티플렉싱이 애플리케이션 계층에만 있으면 패킷 유실 순간에는 전 스트림이 같이 멈춥니다. 지연에 민감한 서비스라면 HTTP/3 지원 CDN·LB를 검토할 근거가 됩니다.
- 연결 개수의 실제 한계는 포트가 아니라 FD입니다. 65,535 오해를 걷어내고 나면 남는 병목은 파일 디스크립터와 포트 범위 설정입니다.
관련 개념
- Ch04 외부 연동이 문제일 때 살펴봐야 할 것들 — 외부 API 연동 장애의 원인 진단
- Ch09 최소한 알고 있어야 할 서버 지식 — nc·netstat·ifconfig를 이용한 네트워크 상태 확인과 FD 제한 관리
- C10K Problem — 대량 동시 연결 처리의 한계와 해법