Intro
최근에 유튜브를 보다가 정말 재밌는 영상을 찾았습니다. 진격의 거인으로 AWS 네트워킹을 설명한 영상이었는데, 거대한 벽과 거인을 비유로 삼아 네트워킹 개념을 풀어내는 방식이 너무 신선했습니다. 보자마자 “이거 꼭 글로 풀어보고 싶다”는 생각이 들었습니다.
요즘 AI가 워낙 시장을 주도하다 보니 CS의 중요성이 떨어진 것 아니냐는 시각도 종종 보입니다. 하지만 실제로 개발을 하다 보면 막히는 문제의 상당수가 CS 기초 부족에서 비롯되곤 합니다. 특히 네트워크는 눈에 보이지 않는 추상적인 영역이라 더더욱 개념을 제대로 잡기 어려운 것 같습니다.
그래서 이번 글에서는 영상의 비유 속에 숨어 있는 네트워크 CS 개념들을 함께 짚어보며 놓치기 쉬운 네트워크 기초를 되새겨보겠습니다.
1. 네트워크 격리와 LAN
거인을 막는 벽, VPC
네트워크 격리는 신뢰 경계를 만드는 행위입니다. 주소 공간, 전송 경로, 정책을 분리해 멀티 테넌시, 보안을 적용합니다. AWS의 VPC는 이 격리를 소프트웨어 정의 네트워킹 (SDN)으로 구현한 결과물이고, CS 관점에서는 LAN/VLAN/VRF/오버레이 개념이 응축되어 있습니다.
아마도 같은 이미지
-
네트워크 격리?
- 벽이 없으면 거인이 사람 먹방 진행
➡️ 서버를 모두에게 공개된 상태로 열어두게 되면 다양한 공격이 들어와서 서버 먹방 진행 - VPC는 거인을 막기 위한 벽.
- 벽이 없으면 거인이 사람 먹방 진행
-
VPC의 정체
- VPC는 가상 사설망으로 L3 네트워크 계층 격리 도메인
- 즉, 하나의 독립된 라우팅 영역 (사설 주소 공간 + 라우팅 테이블)을 의미
- LAN (Local Area Network) : VPC 그 자체가 하나의 거대한 가상 LAN. 물리적인 케이블 연결 없이도 같은 네트워크 영역에 있는 것처럼 통신할 수 있는 환경 제공
- VLAN (Virtual Local Area Network) : VPC 내에서 서브넷을 나누는 행위가 VLAN과 유사. 하나의 큰 네트워크 (VPC)를 논리적으로 작은 도메인 (서브넷)으로 분할하여 네트워크 트래픽을 효율적으로 관리하고 보안을 강화. (L2 분리)
- VRF (Virtual Routing and Forwarding) : VPC마다 독립적인 라우팅 테이블을 갖는 것이 VRF의 핵심 개념. 각 VPC는 자신만의 가상 라우터를 가지고 있어 다른 VPC의 라우팅 정보와 완전히 격리.따라서 VPC에서 10.0.0.0/16 같은 동일한 사설 IP 대역을 충돌 없이 사용 가능.
-
필수 구성
- 주소 공간 : 이미지 속 10.0.0.0/16 같은 사설 IP 대역 필요
- 세분화 : 이 대역을 서브넷으로 나눔 (이미지 속 10.0.1.0/24 & 10.0.2.0/24)
- 라우팅 : 서브넷 간 통신 경로와 게이트웨이
- 정책 : 누가 어디로 드나들 수 있는지 방화벽 규칙 부여
- 👽 진격의 거인 세상에서
벽 안에 마을에서 사용할 주소 (사설 IP) + 용도에 맞는 땅 분할 (서브넷) + 구역 간 이동하는 길 (라우팅), 도시 밖으로 나가는 문 (게이트웨이) + 법 (정책)
-
EX) 로컬 환경에서 서브넷 2개 만들고 라우터 통해서 통신
# 네임스페이스(가상의 네트워크 공간) 3개: router, host1, host2
sudo ip netns add router
sudo ip netns add host1
sudo ip netns add host2
# 가상 케이블(veth)로 연결: router-host1, router-host2
sudo ip link add veth-h1 type veth peer name veth-r1
sudo ip link add veth-h2 type veth peer name veth-r2
sudo ip link set veth-h1 netns host1
sudo ip link set veth-h2 netns host2
sudo ip link set veth-r1 netns router
sudo ip link set veth-r2 netns router
# IP를 다른 대역으로 부여(서브넷 분리)
sudo ip netns exec host1 ip addr add 10.0.1.10/24 dev veth-h1
sudo ip netns exec router ip addr add 10.0.1.1/24 dev veth-r1
sudo ip netns exec host2 ip addr add 10.0.2.10/24 dev veth-h2
sudo ip netns exec router ip addr add 10.0.2.1/24 dev veth-r2
# 인터페이스 up + 기본 게이트웨이(router)
for ns in host1 host2 router; do sudo ip netns exec $ns ip link set lo up; done
sudo ip netns exec host1 ip link set veth-h1 up
sudo ip netns exec host2 ip link set veth-h2 up
sudo ip netns exec router ip link set veth-r1 up
sudo ip netns exec router ip link set veth-r2 up
sudo ip netns exec router sysctl -w net.ipv4.ip_forward=1 >/dev/null
sudo ip netns exec host1 ip route add default via 10.0.1.1
sudo ip netns exec host2 ip route add default via 10.0.2.1
# host1 -> host2 통신: 라우터를 경유해야만 가능
sudo ip netns exec host1 ping -c 2 10.0.2.102. IP 주소와 서브네팅
성벽 안의 효율적인 도시 계획
벽 안의 도시를 건설해야 합니다. 서브네팅은 벽 내부의 땅을 용도에 맞게 구역을 나누는 계획입니다.
-
IP 주소 : 모든 건물의 고유 번호
- 도시의 모든 건물이 'OO로 OOO-OO'처럼 주소를 갖듯, 네트워크의 모든 장비는 IP 주소를 가짐.
- 우리가 흔히 보는 10.0.12.34는 사실 컴퓨터가 이해하는 32자리 2진수(00001010.00000000...)를 사람이 읽기 쉽게 바꾼 것
- 도시 계획 규칙, CIDR: 10.0.12.34/20 같은 표기법에서 /20이 바로 도시 계획의 핵심 규칙.
"앞 20자리는 이 건물이 속한 구역(네트워크) 주소이고, 나머지 12자리는 구역 내 상세 주소(호스트)야"라고 알려주는 약속. - 네트워크 주소: 구역의 시작 주소 (10.0.0.0)로, '강남구'처럼 특정 구역 전체를 지칭
- 브로드캐스트 주소: 구역의 마지막 주소 (10.0.15.255)로, '강남구 재난 알림'처럼 구역 내 모든 주민에게 소식을 전파할 때 사용되는 특별 주소
-
사용 가능 주소: 한 구역(/20 = 12비트 호스트)에 지을 수 있는 건물의 수는 2^12−2 (구역 대표 주소, 방송 주소 제외) = 4,094개
-
Public IP / Private IP + NAT
- Private IP : 도시 안에서만 사용하는 내부 주소 체계
- 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16
- 인터넷 상에서 라우팅되지 않는 사설 공간 ➡️ 대규모 내부망 설계 시
- Public IP : 전 세계에서 유일한 공식 주소, 인터넷에서 라우팅되는 주소
- NAT : Private ↔️ Public 주소 변환. (후에 자세히 기술)
- AWS에서 Public/Private 서브넷을 가르는 기준은 주소 X, 라우팅 O
- 퍼블릭: 0.0.0.0/0 경로의 다음 홉이 IGW (인터넷 Gateway)
- 프라이빗: 0.0.0.0/0 경로의 다음 홉이 NAT 게이트웨이/인스턴스
- Private IP : 도시 안에서만 사용하는 내부 주소 체계
-
VLSM (Variable Length Subnet Mask) : 효율적인 도시 계획 기술
- 대형 마트, 개인 집 모두 10평씩 나눠 가지면 비효율적 ➡️ 각자 다른 크기로 설정해주자 ➡️ VLSM
- 같은 상위 대역 안에서 서브넷마다 다른 크기로 나눌 수 있게 해줌
- 10.0.0.0/16을 용도별로 자르기
- /20 (웹 트래픽 많음) x 4개
- /22 (중간 규모) x 4개
- /24 (소규모) x 여러 개
- 주소 낭비 최소화 + 집계 용이해서 사용
-
EX) 하나의 /16을 가용영역(AZ) 으로 쪼개기
웹 / 앱 / DB / 관리망을 2개의 가용영역(AZ)에 대칭해서 배치할 때
1. 상위 대역 확보: 10.0.0.0/16
2. AZ별 블록 나누기: AZ-a는 10.0.0.0/17, AZ-b는 10.0.128.0/17
3. 역할별 서브넷(각 AZ에 4개씩): /20(4094호스트) 기준
AZ-a
Web-a: 10.0.0.0/20 (퍼블릭, 0.0.0.0/0 → IGW)
App-a: 10.0.16.0/20 (프라이빗, 0.0.0.0/0 → NAT-a)
DB-a : 10.0.32.0/20 (프라이빗, 외부로 매우 제한)
Mgmt-a: 10.0.48.0/20 (프라이빗, 점프/모니터링만)
AZ-b
Web-b: 10.0.128.0/20
App-b: 10.0.144.0/20
DB-b : 10.0.160.0/20
Mgmt-b: 10.0.176.0/20
AWS 주의: 각 서브넷에서는 일부 IP가 플랫폼 예약(게이트웨이·DNS 등).
Router 설계
Web 서브넷: 0.0.0.0/0 → IGW
App/DB/Mgmt: 0.0.0.0/0 → NAT (AZ별)
내부 통신: VPC 내부 라우팅으로 상호 통과(필요 시 SG/NACL로 통제)3. 방화벽과 접근 제어
벽도 세웠고 도시도 세웠으니 이제 문지기를 세워봅시다. 아무나 특정 구역에 들어가거나, 핵심 건물(서버)에 접근한다면 도시가 불에 탑니다. 이제 도시의 질서를 유지하기 위해 곳곳에 문지기 (방화벽)을 배치해야 합니다. AWS VPC의 문지기는 Security Group과 Network ACL (NACL)이 있습니다.
- Security Group (SG) : 건물을 지키는 경비원
- SG는 각 서버 (EC2 인스턴스)의 문 앞으을 지키는 경비원
- 서버에 들어오고 나가는 모든 트래픽은 SG를 거쳐야함
- 특징
- Stateful : 안으로 들어온 손님..? (Inbound)을 기억함. 해당 손님이 나갔다 올 때 (Outbound) 별도의 검사 없이 들어오기 가능
즉, 나가는 트래픽에 대한 규칙을 따로 설정할 필요가 없음 - Allow 규칙만 사용 : Allow List만 잇고 Deny List가 없음
- Stateful : 안으로 들어온 손님..? (Inbound)을 기억함. 해당 손님이 나갔다 올 때 (Outbound) 별도의 검사 없이 들어오기 가능
- 적용 단위 : 서버(인스턴스)단위로 적용, 웹 서버 경비원, DB 서버 경비원처럼 각 특성에 맞게 개별 배치 가능
- EX) 웹 서버 인스턴스는 전 세계 누구나 웹 서핑 (HTTP/HTTPS 포트)을 위해 들어올 수 있도록 허가
- Network Access Control List (NACL) : 구역을 지키는 검문소
- NACL은 SG보다 더 넓은 범위 담당 ➡️ 서브넷의 입구와 출구를 지킴
- 특징
- Stateless : 각 패킷을 그때그때 새로 판단
➡️ 클라이언트가 밖으로 나가면 돌아오는 응답도 인바운드 규칙에 허용이 있어야 통과 - Allow/Deny 모두 있음
- 규칙 번호 순서로 평가 (번호 작을수록 우선)
- 적용 단위 : 서브넷 단위 (서브넷 내 모든 ENI에 적용)
- Stateless : 각 패킷을 그때그때 새로 판단
- 언제 어떻게 사용??
- 일반적으로 SG 중심으로 세밀한 제어, NACL은 완화/거부 몇 개만 운영해 복잡도/운영 비용을 낮춤
- 명확한 커트라인 (외부 스캔 대역 차단, 특정 포트 차단 등)이 필요할 때 NACL의 Deny를 보조로 사용
4. 주소 변환과 NAT
벽 안에서만 살다보니 거인놈들이 뭐하는지 궁금합니다. 다른 도시에서 새로 개발한 무기 (SW 업데이트)도 있다고 하는데 어떻게 통신할 수 있을까요? 이를 해결해주는 것이 NAT 입니다.
내부 주소(사설 IP)는 도시 안에서만 통용되는 주소입니다. 이 주소로 외부와 통신하기 위해서는 Pulbic IP로 변경해줘야 합니다.
NAT는 사설망의 주소를 밖과 대화할 수 있게 바꿔주는 중간역 (게이트웨이). IPv4 고갈과 보안 경계 유지를 해결
- NAT가 필요한 이유
- IPv4 고갈
IPv4는 32비트 주소 체계로 43억 개의 고유 주소를 표현할 수 있습니다. 하지만 인터넷 세상은 호락호락하지 않아서 43억개로도 부족합니다. - 경계 보안
내부 호스트가 아웃바운드로만 인터넷을 사용하고 인바운드로 임의 유입되는 걸 막아야 합니다. - NAT가 내부(Private IP)와 외부(Public IP) 사이에서 주소를 변환해 통신을 가능하게 합니다.
- IPv4 고갈
- NAT의 종류
- SNAT (Source NAT) : 출발지 주소를 변경
내부 호스트가 외부로 나갈 때 출발지를 Public IP로 치환 - DNAT (Destination NAT) : 목적지 주소를 변경
외부에서 들어오는 트래픽을 내부 서비스로 본래 때 사용 - NPAT / PAT (Port Address Translation)
여러 내부 호스트가 하나의 공인 IP를 포트로 구분해 공유
- SNAT (Source NAT) : 출발지 주소를 변경
- AWS에서의 NAT vs IGW(Internet GateWay)
- IGW
- 퍼블릭 IP를 가진 ENI/인스턴스가 직접 인터넷과 양방향 통신
- 퍼블릭 서브넷 : 0.0.0.0/0 ➡️ IGW 라우트 (인바운드는 SG/NACL 허용시만)
- NAT Gateway (관리형)
- 프라이빗 서브넷이 아웃바운드로 인터넷 리소스 접근 시 사용
- 퍼블릭 서브넷에 배치 + EIP 할당 + 해당 가용공간의 프라이빗 서브넷 라우트
- 인바운드 신규 연결은 불가능. 관리, 확장, 가용성은 AWS가 맡음
- NAT 인스턴스 (Self Managed)
- EC2로 NAT 구성. 유연하고 비용이 적지만 HA, 스케일, 패치 등을 직접 책임짐
- Source/Desk Check 해제 필요, 헬스 체크/오토스케일/멀티AZ 등 이중화 설계 필수
- IPv6에서는 NAT가 아닌 Egress-Only IGW
- IPv6는 퍼블릭 가정이라 NAT 대신 Egress-Only Internet Gateway로 아웃바운드만 허용
- IGW
- EX) Linux로 NAT 만들어보기
내부망 (10.0.0.0/16)이 et1, 외부망(인터넷)이 eth0인 리눅스 라우터에서 SNAT(PAT)로 외부 접근 허용해보기
# 1. 커널 포워딩 켜기
sudo sysctl -w net.ipv4.ip_forward=1
# 2. SNAT (MASQUERADE = 동적 퍼블릭 IP일 때 편함)
sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/16 -o eth0 -j MASQUERADE
# 3. 포워딩 정책(기본 거부 후 필요한 것만)
sudo iptables -A FORWARD -i eth1 -o eth0 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT
sudo iptables -A FORWARD -i eth0 -o eth1 -m state --state ESTABLISHED,RELATED -j ACCEPT
# - DNAT: 목적지를 내부 서버로
sudo iptables -t nat -A PREROUTING -d 203.0.113.5 -p tcp --dport 443 -j DNAT --to-destination 10.0.1.20:443
# - SNAT: 응답이 다시 NAT를 경유하도록 출발지도 NAT의 내부 IP로
sudo iptables -t nat -A POSTROUTING -s 10.0.0.0/16 -d 10.0.1.20 -p tcp --dport 443 -j SNAT --to-source 10.0.1.1(➕) IPv4의 주소 고갈은 IPv6로 해결된 것이 아닌가?
실제로 IPv6 표준 철학이 NAT가 필요 없는 End-to-End 통신 복원입니다.
하지만 IPv6의 보급 지연, 경계 보안 기능 (NAT 자체가 보안을 위한 것은 아니지만 기능이 외부의 임의 접근이 막히는 효과), 주소 은닉 등으로 인해 여전히 NAT가 필요합니다.
5. 트래픽 관리와 고가용성
도시가 잘 되니 방문객도 많아지고 상인도 많아졌습니다. 이렇게 몰리면 결국 제 기능을 못하고 도시가 또 멸망합니다. 이를 해결하기 위해서는 새로운 도시를 세워서 방문객을 분산해야합니다. (영상에서는 몸빵으로 비유)
로드 밸런싱은 연결을 어디로 보낼지 결정
L4 전송 계층은 IP/포트/프로토콜만 보고 분산 (연결 종단 X)
L7 애플리케이션 계층은 HTTP/gRPC 같은 애플리케이션 레빌을 이해해 헤더/경로 기반으로 분산 (연결 종단 O)
- 단일 서버의 처리량/가용성에는 한계가 존재
- 장애 발생 시 전체 중단 위험
- (물론 분산 서버 되어있겠지만) 티켓팅, 수강 신청 등 다양한 이벤트로 서버가 죽음..
- 서버를 늘려서 수평 확장 (Scale-out) + 헬스 체크로 불량 서버 제외
- L4 vs L7
| 구분 | L4 (TCP/UDP) | L7 (HTTP/HTTPS/gRPC) |
|---|---|---|
| 기준 | src/dst IP, src/dst Port, 프로토콜 | URL 경로/메서드/헤더/쿠키/호스트명 |
| 연결 처리 | 패스스루(비종단), 빠름 | 종단(Proxy), 라우팅 유연, 기능 ⬆️ |
| 기능 | 소스 IP 보존 용이, 낮은 지연 | 경로/호스트 기반 라우팅, 헤더 재작성, 쿠키 기반 세션 스티키, WAF 연계, TLS 종료/재암호화 |
| 사용처 | 게임 서버, 메시지 큐, DB 프록시 등 | 웹/모바일 API, gRPC, 다중 도메인/경로 라우팅 등 |
-
분산 알고리즘
- 라운드 로빈 Round Robin
- 가중치 라운드 로빈 Weighted RR
- Least Connections
- Hash
- Consistent Hash
-
헬스 체크
- Active : 로드밸런서가 주기적으로 /health (HTTP) 또는 TCP 핸드셰이크 체크
- Passive : 실제 트래픽 에러, 타임아웃 관찰 후 타깃 제외
- Slow-Start/Outlier Detection : 새로 합류한 서버는 천천히 트래픽 유입, 오류 많은 서버는 자동 격리
- 멀티 AZ/리전 : 헬스 체크는 가까운 곳에서 빠르게, 실패 임계/간격은 서비스 RTO/RPO와 맞추기
-
세션 관리 : 스티키 vs 무상태
- 스티키 세션 : L7 로드밸런서가 쿠키/소스 IP 기반으로 같은 서버에 붙여주는 것
- 장점 : 서버가 메모리에 세션을 저장해도 무방
- 단점 : 서버 증/감, 장애 발생 시 세션 유실/재분산 이슈 발생
- 무상태 권장 : 세션 외부화 (Redis) 또는 토큰 기반 (JWT)
- 스티키 세션 : L7 로드밸런서가 쿠키/소스 IP 기반으로 같은 서버에 붙여주는 것
-
TLS 처리 패턴 (종단 지점 설계)
- LB에서 종료(Termination): LB가 인증서 보유, 백엔드에 HTTP(또는 re-encrypt).
- 장점: 인증서/암복호화 중앙화, WAF/L7 기능 사용 가능.
- 단점: 백엔드까지 평문이라면 경로 보호 필요(프라이빗 전용망, SG/NACL).
- 패스스루(Pass-Through): L4로 그대로 전달(서버가 인증서 보유).
- 장점: 소스 IP 보존/단순
- 단점: 도메인별 라우팅/헤더 조작 불가.
- Re-encryption(종단→재암호화): LB에서 종료 후 백엔드로 다시 TLS.
- 장점: 경로 암호화 유지 + L7 기능 사용.
- mTLS, SNI, ALPN(HTTP/2, gRPC)과의 궁합을 고려.
- LB에서 종료(Termination): LB가 인증서 보유, 백엔드에 HTTP(또는 re-encrypt).
Outro
쓰다보니 진격거는 사라지고 어째 네트워크만 잔뜩 설명된 느낌인데 한번에 쭉 정리해보니 정말......어렵네요. 세부적인 내용을 전부 빼고 정말 AWS 한정으로 봤는데도 방대합니다. 학교에서 배웠을 때는 종이컵 전화기 수준부터 배웠던 것 생각하면 어떻게 다 배웠나 싶습니다. 이제 클라우드는 개발자에게 필수 도구로 자리잡은 만큼 관련된 내용도 많이 올려보겠습니다.
