네트워크 7계층 완벽 정리

OSI Model · 캡슐화 · 라우터 · 보안 · 방화벽 · VPN · Proxy까지

1. OSI 7계층 개요

네트워크 통신은 추상화 계층(상위)부터 물리 계층(하위)까지 7개의 층으로 나뉩니다. 위에서 만들어진 데이터는 아래로 내려가며 헤더가 덧붙고, 최종적으로 전기/광 신호가 되어 전송됩니다.

1.1 7계층 한눈에 보기

Layer	이름	PDU	일반적 크기	대표 프로토콜/장비
L7	Application	Data	제한 없음 (수 KB~MB)	HTTP, HTTPS, FTP, DNS
L6	Presentation	Data	제한 없음	TLS/SSL, JPEG, UTF-8
L5	Session	Data	제한 없음	TLS, RPC, NetBIOS
L4	Transport	Segment / Datagram	TCP ~1460 B / UDP ~1472 B	TCP, UDP
L3	Network	Packet	~1500 B (MTU)	IP, ICMP, 라우터
L2	Data Link	Frame	64 B ~ 1518 B	Ethernet, 스위치
L1	Physical	Bit	1 bit	케이블, 광섬유, 무선파

TCP/IP 4계층 모델과의 대응

현실에서는 TCP/IP 4계층 모델도 많이 쓰입니다.

Application (L5~L7) — 응용
Transport (L4) — 전송
Internet (L3) — 인터넷
Network Access (L1~L2) — 네트워크 접근

1.2 핵심 단위 크기 — MTU와 MSS

각 계층의 크기는 아래 계층의 제약에 맞춰 정해집니다. 핵심 개념 두 가지:

MTU (Maximum Transmission Unit)

한 프레임에 실을 수 있는 L3 패킷의 최대 크기입니다.

일반 Ethernet: 1500 bytes (사실상 표준)
점보 프레임: 9000 bytes (데이터센터)
Wi-Fi: 보통 1500 bytes
PPPoE (일부 ISP): 1492 bytes

MSS (Maximum Segment Size)

TCP 세그먼트의 데이터 부분 최대 크기입니다.

TCP: MTU(1500) - IP헤더(20) - TCP헤더(20) = 1460 bytes
UDP: MTU(1500) - IP헤더(20) - UDP헤더(8) = 1472 bytes

크기 누적 예시 — 1460 bytes의 HTTP 데이터를 보낼 때

[L7] HTTP 데이터: 1460 B [L4] + TCP 헤더(20 B) → 세그먼트: 1480 B [L3] + IP 헤더(20 B) → 패킷: 1500 B ← MTU 한계 [L2] + Ethernet 헤더(14 B) + FCS(4 B) → 프레임: 1518 B [L1] 비트로 변환 → 1518 × 8 = 12,144 bits

크기로 본 직관

1 패킷 ≈ 1.5 KB — 인터넷의 기본 운반 단위
1 MB 파일 → 약 700개의 패킷으로 쪼개짐
4K 영상 1초(약 5 MB) → 약 3,500개 패킷
카톡 "안녕" → 1 패킷도 못 채우고 그대로 전송

2. 캡슐화 — 데이터의 여정

2.1 캡슐화 흐름

소프트웨어가 만든 데이터는 계층을 내려가며 헤더(header)가 덧붙여집니다. 받는 쪽은 거꾸로 헤더를 벗기며(역캡슐화) 앱까지 데이터를 전달합니다.

2.2 A ↔ B 쌍둥이 빌딩 — PC 두 대를 직접 연결

가장 단순한 경우를 상상해봅시다. PC A와 PC B를 LAN 케이블 하나로 직접 연결(또는 무선 P2P)한 상태에서, 브라우저나 앱으로 통신합니다. 라우터·인터넷·중계서버 같은 것은 없습니다. 이때 두 PC는 각자 7개 층을 갖는 쌍둥이 빌딩처럼 마주서고, 맨 아래 물리계층(L1)끼리만 케이블로 연결됩니다.

핵심 통찰 — "Peer-to-Peer" 통신의 환상

A의 L4(TCP)는 B의 L4(TCP)와 "같은 언어로 대화"합니다. A의 L3는 B의 L3와 대화하고요. 마치 동일 계층끼리 직접 연결된 것처럼 보입니다.

하지만 실제 데이터는 항상 L7→L1로 내려갔다가 케이블을 건너 L1→L7로 올라옵니다. 각 계층의 헤더는 그 계층끼리만 "이해하는 메모"인 셈입니다.

이 모델 덕분에 각 계층을 독립적으로 교체할 수 있습니다. 예: 케이블을 Wi-Fi로 바꿔도(L1 변경) 위 계층들은 그대로. HTTP를 HTTPS로 바꿔도(L6 변경) L4 이하는 그대로.

실제 사례 — 같은 공유기에 물린 두 PC의 파일 전송

A: 192.168.0.10, B: 192.168.0.20 — 같은 서브넷
A에서 http://192.168.0.20:8000으로 접속 (B가 간이 웹서버 실행 중)
같은 서브넷이므로 L3에서 "라우터 거칠 필요 없음" 판정 → ARP로 B의 MAC 알아냄
이후 7계층 전체가 위 그림처럼 동작

3. 라우터란 무엇인가

3.1 정의와 역할

라우터 (Router)

서로 다른 네트워크를 연결하고, 패킷을 올바른 방향으로 전달하는 장치입니다. OSI L3(네트워크 계층)에서 동작하며, IP 주소를 보고 "어디로 보낼지" 결정합니다.

위 쌍둥이 빌딩 예시(A↔B 직접 연결)에서는 라우터가 필요 없습니다. 같은 네트워크에 있기 때문이죠. 하지만 다음과 같은 상황이 되는 순간 라우터가 등장합니다:

"내 PC(192.168.0.10)"에서 "구글 서버(142.250.207.36)"로 가야 할 때 → 서로 다른 네트워크
회사 본사망에서 지사망으로 → 다른 사설망
Wi-Fi에서 인터넷으로 나갈 때 → 공유기(라우터의 일종)

라우터가 하는 4가지 일

경로 결정 (Routing): 라우팅 테이블을 보고 "이 IP는 어느 방향으로?" 결정
패킷 전달 (Forwarding): 결정된 방향(인터페이스)으로 패킷을 내보냄
L2 헤더 재작성: 다음 홉 라우터의 MAC으로 Ethernet 헤더 갱신, TTL −1
(가정용) NAT: 사설 IP(192.168.x.x)를 공인 IP로 바꿔 외부로 내보냄

3.2 허브 · 스위치 · 라우터 — 비슷하지만 다른 친구들

장치	동작 계층	판단 기준	특징
허브 (Hub)	L1 (물리)	없음 — 전체 브로드캐스트	모든 포트에 그대로 전송. 옛날 장치, 거의 도태됨
스위치 (Switch)	L2 (데이터링크)	MAC 주소	같은 네트워크 안의 PC들끼리 연결. 정확한 포트로만 보냄
라우터 (Router)	L3 (네트워크)	IP 주소	서로 다른 네트워크를 연결. 인터넷의 핵심
L3 스위치	L2 + L3	MAC + IP	대규모 사내망에서 라우팅 + 스위칭 동시에

집 공유기 = 다 합친 만능 장치

가정용 "공유기"는 한 박스에 라우터 + 스위치 + Wi-Fi AP + 방화벽 + DHCP 서버 + NAT가 다 들어있는 통합 장치입니다. 그래서 어떤 기능인지 헷갈리기 쉽습니다.

3.3 라우팅 테이블 — 라우터의 두뇌

라우터는 각자 라우팅 테이블(Routing Table)을 가지고 있습니다. "어떤 목적지 IP를 어느 방향으로 보낼지" 적힌 도로 표지판 같은 것입니다.

목적지 IP 범위 다음 홉(Next Hop) 나가는 인터페이스 ───────────────────────────────────────────────────────────────── 192.168.0.0/24 직접 연결 eth0 (내부망) 10.0.0.0/8 10.1.1.1 eth1 (지사망) 0.0.0.0/0 (기본 경로) 203.250.1.1 eth2 (인터넷) ↑ "위의 어느 규칙에도 안 맞으면 이쪽으로 보내" — Default Route

라우터끼리는 라우팅 프로토콜(OSPF, BGP 등)로 서로 경로 정보를 주고받아 자동으로 테이블을 갱신합니다. 인터넷은 결국 "전 세계 라우터들이 끊임없이 길을 알려주는 거대한 GPS 시스템"인 셈입니다.

PC에서도 라우팅 테이블이 있다

윈도우: route print / 맥·리눅스: netstat -rn 또는 ip route

대부분 두 줄 정도가 핵심: "같은 서브넷은 직접" + "그 외 모든 것은 공유기로(Default Gateway)"

3.4 라우터들은 어떻게 길을 알아내나? — "알음알음 알려주기"가 정답

💡 그 직관이 맞습니다

"라우터들끼리 저기로 가! 아니 여기 말고 저기로! 이러면서 알려주는 거야?" — 네, 정확히 그렇게 동작합니다. 인터넷에는 "중앙 안내 데스크" 같은 게 없습니다. 대신 전 세계 라우터들이 서로 끊임없이 대화하며 길 정보를 주고받습니다. 이를 라우팅 프로토콜(Routing Protocol)이라고 부릅니다.

라우팅 테이블이 채워지는 3가지 방법

방법	설명	쓰이는 곳
직접 연결 (Direct)	"내 인터페이스가 직접 붙어있는 네트워크는 그냥 안다" — 자동 추가	모든 라우터의 기본 항목
정적 (Static)	관리자가 직접 "X로 가려면 Y로 보내" 입력	작은 네트워크, 보안망
동적 (Dynamic)	라우팅 프로토콜로 이웃 라우터와 자동 정보 교환	인터넷 전체, 대규모 회사망

동적 라우팅의 원리 — 이웃과 수다 떨기 (Gossip)

모든 라우터는 자기 옆에 직접 연결된 이웃 라우터들이 있습니다. 라우팅 프로토콜은 이 이웃끼리 정해진 형식으로 메시지를 주고받게 합니다:

Hello 메시지: "나 살아있어, 이쪽으로 연결 가능해" (몇 초마다 주기적으로)
경로 광고(Advertisement): "나는 192.168.5.0/24 네트워크 알고 있어, 나를 거쳐서 가면 돼"
광고 전파: 받은 정보를 다시 자기 이웃에게 알림 → 마치 소문 퍼지듯 전 세계로 확산
경로 비교: 같은 목적지로 가는 길이 여러 개면 가장 짧은 것 선택
변경 감지: 링크가 끊어지면 이웃에게 즉시 통보 → 다른 길로 우회 (수렴, Convergence)

두 가지 대표 프로토콜 — OSPF와 BGP

라우팅 프로토콜은 범위에 따라 두 가지로 나뉩니다.

구분	OSPF (Open Shortest Path First)	BGP (Border Gateway Protocol)
사용 범위	한 조직 내부 (회사망, 학교망, ISP 내부)	조직 간 (ISP끼리, 국가 간)
동작 방식	각 라우터가 "전체 지도"를 만들고 Dijkstra로 최단 경로 계산	이웃 AS와 "경로 목록(AS Path)"을 교환
판단 기준	대역폭·지연 등 객관적 비용	정책·비즈니스 관계·계약 우선
수렴 속도	빠름 (수 초)	느림 (수십 초~분)
비유	도시 내 지도 앱	국가 간 항공편 시간표

왜 두 종류로 나누나?

OSPF 같은 "전체 지도" 방식은 큰 범위에서 비현실적. 전 세계 수천만 라우터의 지도를 매번 계산할 수 없음
그래서 인터넷은 계층으로 나뉨: 같은 회사 안에서는 OSPF로 "내부 길" 찾고, 회사끼리는 BGP로 "큰 줄기" 찾기
이게 다음 절에서 다루는 AS(Autonomous System) 개념입니다

한 번씩 일어나는 "BGP 사고"

BGP는 신뢰 기반이라, 한 ISP가 잘못된 경로를 광고하면 전 세계 트래픽이 엉뚱한 곳으로 빨려갑니다.

2008년 파키스탄이 유튜브 차단하려다 잘못 광고 → 전 세계에서 유튜브 몇 시간 다운
2024년에도 한국에서 카카오·네이버 일시 장애 등 BGP 사고는 종종 발생

라우팅이 "알음알음"인 만큼, 한 명이 잘못 말하면 다 같이 헷갈리는 구조이기도 합니다.

3.5 인터넷의 큰 그림 — AS, ISP 계층, BGP

인터넷은 평평한 한 덩어리가 아니라 "독립적인 네트워크들의 네트워크(Network of Networks)"입니다. 각 독립 네트워크를 AS라고 부릅니다.

ISP (Internet Service Provider, 인터넷 서비스 제공자)

우리에게 인터넷을 제공해주는 회사입니다. 매달 통신비를 내는 그 회사가 바로 ISP. 우리 집까지 광케이블·통신선을 깔아 주고, 그 회선이 ISP의 거대한 자체 망과 연결되며, 그 ISP 망은 또 다른 ISP들과 서로 연결되어 결국 전 세계 인터넷이 됩니다.

한국: SK Broadband, KT, LG U+ (가정용 3대 ISP)
미국: Comcast, AT&T, Verizon, Spectrum
일본: NTT, KDDI, SoftBank

한 ISP는 보통 자기 AS 번호(또는 여러 개)를 가진 거대한 AS입니다. 우리 집 공유기는 ISP가 깔아준 회선을 거쳐 ISP의 라우터로 연결되고, 그 라우터가 더 큰 인터넷으로 패킷을 흘려보냅니다.

AS (Autonomous System, 자율 시스템)

하나의 조직이 통제하는 라우터·네트워크 묶음입니다. 전 세계적으로 유일한 AS 번호(ASN)를 받습니다. ISP는 대표적인 AS의 예시이고, 그 외 구글·페이스북·은행 같은 큰 조직도 자체 AS를 가집니다.

SK Broadband: AS9318
KT: AS4766
LG U+: AS3786
Google: AS15169
Cloudflare: AS13335
AWS: AS16509

현재 약 11만 개의 AS가 인터넷에 등록되어 있습니다.

ISP와 AS는 같은가? — 헷갈리지 않게

ISP = 비즈니스 개념. "인터넷 회선 파는 회사"
AS = 기술 개념. "고유 번호를 가진 라우터 네트워크 묶음"
모든 ISP는 하나(또는 여러 개)의 AS를 운영. 그래서 실무에선 거의 같은 의미로 쓰이지만, 구글·아마존 같은 회사도 자체 AS를 가지지만 ISP는 아님

ISP의 3단 계층 — Tier 1, 2, 3

인터넷에서 "BGP는 계층 간 연결을 담당하는 공용 언어"입니다. AS끼리 "우리 AS로 오면 우리 통해 이 AS·저 AS로 갈 수 있다"는 정보를 BGP로 광고합니다.

한 패킷의 여정 — Tier 단위로 보면

시나리오: 한국 집 PC에서 미국 Google 서버로 가는 패킷 한 개

내 PC → 집 공유기 (Tier 3 내부)
공유기 → SK Broadband 라우터 (Tier 3 → Tier 2 진입, AS9318)
SK Broadband 라우터의 BGP 테이블 조회: "AS15169(Google)로 가려면 어느 이웃 AS로?"
SK Broadband → NTT 백본 (Tier 2 → Tier 1, 태평양 광케이블 진입)
NTT 라우터의 BGP: "AS15169는 다음 홉인 AS A로" → 또 다음 홉 → 미국 도착
NTT → Google AS15169 (Tier 1 → Google AS 진입)
Google AS 내부에서는 OSPF로 정확한 서버까지 라우팅 (지역 분산 LB 등)
도착! 응답은 정확히 반대 경로(또는 BGP가 알려주는 또 다른 경로)로 돌아옴

실측 — 거치는 AS 보기

mtr --aslookup google.com 또는 traceroute -a google.com 실행
각 홉마다 거치는 AS 번호가 같이 표시됨 — Tier 3 → Tier 2 → Tier 1 → Google 흐름이 실제로 보임
웹: bgp.he.net에 IP 넣으면 그 IP가 속한 AS와 BGP 광고 내역 조회 가능

🎯 처음 질문에 대한 최종 답

"IP만으로 어떻게 다른 PC로 갈 수 있나?"

중앙 안내 서버 같은 건 없음. 인터넷은 분산 시스템
대신 전 세계 라우터들이 BGP(외부)·OSPF(내부) 프로토콜로 끊임없이 길 정보를 교환합니다
한 라우터가 "AS15169(Google)는 내 옆 AS9318(SK)로 가면 도달 가능" 같은 광고를 받아 자기 테이블에 적어둠
패킷이 도착하면 라우팅 테이블 보고 다음 홉으로 던짐 — 각자 한 발짝씩만 알면 충분
이 한 발짝짜리 지식이 전 세계적으로 누적되어 "IP만 있으면 어디든 가는" 인터넷이 작동

즉, 직관 그대로 "라우터들끼리 알음알음 알려주는" 거대한 분산 GPS가 인터넷의 정체입니다.

4. 예시 1 — `www.google.com` 접속하기

브라우저 주소창에 https://www.google.com을 입력하고 엔터를 누르는 순간, 7계층 전체가 동시에 움직이기 시작합니다.

4.1 DNS 조회

브라우저 캐시 → OS hosts 파일 → 로컬 DNS 서버(보통 ISP 또는 8.8.8.8) 순으로 조회
DNS 서버가 www.google.com → 142.250.207.36 같은 IP 응답
이 DNS 조회 자체도 UDP 패킷으로 L4~L1을 거쳐 다녀옴

4.2 TCP 3-way Handshake

PC와 구글 서버가 신뢰할 수 있는 연결을 수립합니다.

PC ── SYN (출발: 54321 / 도착: 443) ──→ Google PC ←──── SYN+ACK ───────────────────── Google PC ───── ACK ────────────────────────→ Google ✓ 연결 완료

4.3 TLS Handshake (HTTPS의 'S')

평문 HTTP가 아니라 암호화된 채널을 먼저 만듭니다.

PC가 ClientHello 전송 (지원 암호 스위트, 랜덤 값)
구글이 ServerHello + 인증서(Certificate) 전송
PC가 인증서를 신뢰된 CA 목록과 검증 — "이게 진짜 구글 맞는가?"
키 교환 (보통 ECDHE) → 양쪽이 동일한 세션 키 보유
이후 모든 데이터는 이 세션 키로 대칭 키 암호화(AES 등)

4.4 라우터 통과 — 가장 헷갈리는 부분

중요

라우터는 한 번이 아니라 여러 번 거칩니다.

실습 팁

터미널에서 traceroute www.google.com (윈도우는 tracert)을 실행하면 실제로 거치는 라우터들을 볼 수 있습니다.

5. 예시 2 — 친구에게 카카오톡 메시지 보내기

카카오톡은 P2P(직접 통신)가 아닙니다. 반드시 카카오 서버를 거칩니다.

항목	구글 접속	카카오톡
연결 방식	요청 시 TCP 연결	앱 실행 중 영구 연결 유지
통신 방향	요청-응답 (Pull)	양방향 푸시 (Push)
대상	웹 서버	중계 서버 → 다른 사용자
프로토콜	HTTPS (표준)	카카오 자체 프로토콜 + TLS

6. 전체 네트워크 경로 시각화 — 7계층 × 라우터 × 서버

지금까지 따로 본 조각들(7계층, 캡슐화, 라우터)을 하나의 그림으로 합쳐봅시다. 앞 장의 쌍둥이 빌딩 모델을 확장해서, 사이에 끼어드는 모든 장치(공유기·ISP 라우터·백본 라우터·DNS·서비스 서버)까지 한 줄로 펼쳐 보겠습니다.

그림 읽는 법

풀스택 장치 (내 PC, DNS 서버, 구글/카카오 서버): 7개 계층 모두 색칠 — "데이터를 끝까지 처리"
라우터 장치 (공유기, ISP 라우터, 백본 라우터): L1~L3까지만 색칠 — "지나가는 패킷의 IP를 보고 다음으로 넘김"
맨 아래 L1 박스끼리 굵은 선으로 이어진 것 = LAN 케이블/광섬유/Wi-Fi 신호
각 라우터에서는 데이터가 "L1→L2→L3까지 올라갔다가 다시 L2→L1로 내려가" 다음 장치로 나감 (그림의 ↻ 아이콘)

6.1 구글 접속의 전체 경로

구글 접속은 두 단계로 나뉩니다. ① 도메인을 IP로 바꾸는 DNS 조회 → ② 그 IP로 가는 HTTPS 본 요청. 둘 다 같은 PC에서 출발하지만 거치는 서버가 다릅니다.

① DNS 조회 — UDP로 짧게 다녀오는 사전 작업

⏱️ Phase 1과 Phase 2의 관계 — 순서대로, 따로 일어남

네, DNS를 먼저 갔다 와야 합니다. Phase 1과 Phase 2는 같은 PC에서 출발하지만 다른 시점에, 다른 서버로 가는 별도의 통신입니다. PC는 DNS 응답을 받아 IP를 알기 전까지는 Phase 2를 시작조차 할 수 없습니다.

DNS 응답이 PC에 도착하면, 같은 TCP 연결을 재사용하는 게 아니라 새로운 TCP 연결을 142.250.207.36:443으로 새로 엽니다. 그래서 두 다이어그램이 분리되어 있는 것입니다.

🔍 핵심 정리 — DNS와 HTTPS의 관계

도착지 IP가 다르다: Phase 1은 8.8.8.8로, Phase 2는 142.250.207.36으로. 완전히 다른 서버로 가는 별도 통신
프로토콜이 다르다: Phase 1은 UDP:53(짧고 빠른 1패킷 왕복), Phase 2는 TCP:443(연결 수립 + 암호화 + 본 요청)
중간 라우터는 공유함: 공유기 → ISP까지는 같은 길. ISP 라우터에서 도착지 IP를 보고 "DNS 서버로 갈지 / 구글로 갈지" 분기
의존성: Phase 1이 끝나지 않으면 Phase 2를 못 시작함. 그래서 DNS가 느리면 웹페이지 로딩도 느려짐 → "DNS 캐싱"이 중요한 이유
실제로는 한번 더: Phase 2 시작할 때 ARP 같은 짧은 통신이 또 일어나지만 (다음 홉 MAC 찾기) 보통 무시

② HTTPS 본 요청 — 받은 IP로 TCP+TLS 연결

실측 — traceroute로 확인

터미널에서 traceroute www.google.com (윈도우: tracert)을 실행하면 위 그림의 ②~④ 사이에 있는 실제 라우터들의 IP가 줄줄이 보입니다. 보통 10~20개 라우터를 거칩니다.

6.2 카카오톡 메시지의 전체 경로

카카오톡은 친구에게 직접 가는 게 아니라 카카오 서버를 거쳐 갑니다. 그래서 그림이 거의 좌우대칭입니다. 양 끝의 사용자 PC, 양쪽의 공유기/라우터들, 한가운데 카카오 서버.

구글 접속과의 결정적 차이

구글: PC ↔ 구글 서버 1회 왕복. 그림이 좌우 비대칭(요청-응답)
카카오: PC A ↔ 카카오 서버 ↔ PC B의 2회 왕복. 가운데 카카오 서버가 풀스택으로 메시지를 한 번 받아서 다시 보냄. 좌우 거의 대칭
그래서 카카오톡은 친구가 오프라인이어도 메시지가 사라지지 않음 — 가운데 서버가 보관

7. 포트(Port)란? — 프로세스와 헷갈리지 않게

"포트가 프로세스인가? 아닌 것 같기도 하고…" 헷갈리기 좋은 개념입니다. 둘은 다른 것이지만 짝꿍처럼 같이 다닙니다.

7.1 한 줄 정의와 비유

포트 (Port)

한 컴퓨터 안에서 어느 프로그램에게 데이터를 전달해야 하는지 가리키는 16비트 정수(0~65535). OSI 모델에서는 L4(전송 계층)의 TCP/UDP 헤더에 들어 있습니다.

아파트 비유 — 한 줄 외우기

IP 주소 = 아파트 단지 주소 (어느 건물?) — L3
포트 번호 = 동·호수 (그 안의 어느 집?) — L4
프로세스 = 그 집에 사는 사람 (실체) — OS 안의 실행 단위

패킷이 컴퓨터에 도착하면 "IP로 건물 찾고, 포트로 호실 찾고, 그 호실에 등록된 프로세스에게 배달"됩니다.

7.2 포트 vs 프로세스 — 진짜 차이

같이 다니지만 본질이 다른 두 개념입니다.

항목	포트 (Port)	프로세스 (Process)
본질	0~65535 사이 정수	실행 중인 프로그램 인스턴스
식별자	포트 번호	PID (Process ID)
관리 주체	OS의 네트워크 스택 (커널)	OS의 프로세스 스케줄러
존재 위치	TCP/UDP 헤더 안 (패킷에 적힘)	OS 메모리 안 (CPU에서 실행)
1:N 관계	1 포트 ↔ 1 프로세스 (보통)	1 프로세스 ↔ N 포트 (가능)
비유	호실 번호 (주소)	그 집에 사는 사람 (실체)
네트워크에서 보임?	O — 패킷에 직접 표시됨	X — PID는 다른 PC에서 알 수 없음

핵심: 포트는 "주소", 프로세스는 "사람"

프로세스가 OS에게 "내가 80번 포트 받을게(bind(80))"라고 등록해두면, 그 PC로 들어오는 도착 포트가 80인 모든 패킷이 그 프로세스에게 배달됩니다.

한 포트는 한 프로세스가 "찜"하면 다른 프로세스는 못 가져갑니다 (Address already in use 에러). 반대로 한 프로세스가 여러 포트를 동시에 듣는 건 자유입니다 (예: nginx가 80과 443 동시에).

7.3 자주 쓰이는 포트 번호

포트 번호는 IANA가 정한 표준이 있습니다. 3구간으로 나뉩니다:

구간	범위	용도
Well-Known	0 ~ 1023	표준 서비스용. 관리자(root) 권한 필요
Registered	1024 ~ 49151	특정 앱이 IANA에 등록해 쓰는 번호
Ephemeral	49152 ~ 65535	클라이언트가 임시로 쓰는 출발 포트 (OS 자동 배정)

외워두면 좋은 표준 포트

포트	프로토콜	용도
22	SSH	원격 셸 접속
25	SMTP	메일 보내기
53	DNS	도메인 조회 (UDP/TCP 둘 다)
80	HTTP	웹 (평문)
110 / 143	POP3 / IMAP	메일 받기
443	HTTPS	웹 (TLS)
3306	MySQL	관계형 DB
5432	PostgreSQL	관계형 DB
6379	Redis	인메모리 DB
8080	HTTP-alt	개발 시 자주 쓰는 대체 포트
27017	MongoDB	문서 DB

7.4 5-튜플 — 같은 서버에 수십 개 탭이 동시 접속되는 비밀

"브라우저에서 google.com을 동시에 10개 탭으로 열면 다 같은 IP:443으로 가는 거 아닌가? 어떻게 구분하지?" 답은 출발 포트가 다르기 때문입니다.

5-튜플 (5-Tuple) — 연결을 유일하게 식별하는 5개 값

(프로토콜, 출발 IP, 출발 포트, 도착 IP, 도착 포트)

OS는 이 5개의 조합으로 "이 패킷은 어느 연결의 것"인지 구분합니다. 5개 중 하나라도 다르면 다른 연결.

예시 — 한 PC에서 구글 3개 탭을 동시에 열었을 때

탭1: (TCP, 192.168.0.10, 49152, 142.250.207.36, 443) 탭2: (TCP, 192.168.0.10, 49153, 142.250.207.36, 443) 탭3: (TCP, 192.168.0.10, 49154, 142.250.207.36, 443) ↑ ↑ (도착은 모두 동일) IP 같음 출발 포트만 다름

구글 서버에서 응답이 돌아올 때, 도착 포트가 49152/49153/49154 중 무엇이냐로 어느 탭의 응답인지 OS가 구분합니다.

송신 측 포트는 누가 정하나? — Ephemeral Port

클라이언트(브라우저 등)는 도착 포트만 지정합니다 (예: HTTPS → 443)
출발 포트는 OS가 49152~65535 중 비어있는 번호를 자동 배정
그래서 같은 PC에서 같은 서버로 여러 연결을 동시에 만들 수 있음
연결이 끝나면 OS가 그 포트를 회수 → 재사용

실습 — 내 PC의 포트 상태 보기

macOS/Linux: lsof -i -P -n 또는 netstat -tunlp
Windows: netstat -ano (PID도 같이 표시) → tasklist로 PID 확인
출력에 192.168.0.10:54321 → 142.250.207.36:443 ESTABLISHED 같은 줄이 보이면, 그게 5-튜플의 실제 모습

자주 만나는 에러

Address already in use / EADDRINUSE — 그 포트를 다른 프로세스가 이미 잡고 있음. lsof -i :3000으로 PID 찾아서 kill
Permission denied — 1024 미만 포트를 일반 사용자가 잡으려 할 때 (root 필요)
방화벽이 막은 경우 — 포트는 열려있지만 외부에서 접근 불가. 라우터/공유기 포트포워딩 + 호스트 방화벽 설정 필요

8. HTTP vs HTTPS · TLS · 네트워크 인증서

8.1 HTTP vs HTTPS — 자물쇠 아이콘의 정체

HTTP (HyperText Transfer Protocol)

웹 브라우저와 웹 서버 사이에서 HTML, 이미지, JSON 등을 주고받는 L7 응용 계층 프로토콜. 기본 포트 80. 평문(plain text)으로 통신하므로 중간에서 누가 보면 다 보입니다.

HTTPS (HTTP Secure)

HTTP + TLS. 평문 HTTP 메시지를 TLS로 한 번 감싸서 암호화한 것. 기본 포트 443. 브라우저 주소창의 🔒 자물쇠 아이콘이 바로 HTTPS의 표시.

항목	HTTP	HTTPS
포트	80	443
암호화	없음 (평문)	TLS로 암호화
서버 신원 확인	없음 — 가짜 서버 가능	인증서로 보증
위변조 탐지	없음	HMAC으로 탐지
속도	약간 빠름	약간 느림 (암호화 비용)
브라우저 표시	"안전하지 않음" 경고	🔒 자물쇠 아이콘
SEO	구글 검색 페널티	가산점
HTTP/2, HTTP/3	실질적으로 사용 불가	사용 가능

현재(2026년) 웹의 현실

거의 모든 사이트가 HTTPS로 전환되었습니다. 브라우저(크롬·사파리·파이어폭스)는 HTTP 사이트에 접속하면 "안전하지 않음" 빨간 경고를 표시하고, 일부는 아예 차단합니다. Let's Encrypt 같은 무료 인증서가 보급되며 HTTPS가 표준이 되었습니다.

8.2 TLS/SSL이란 무엇인가

HTTPS의 'S'를 만드는 게 바로 TLS입니다. HTTP뿐 아니라 FTP·SMTP·DNS 같은 거의 모든 평문 프로토콜을 보호하는 데 사용되는 인터넷 표준 보안 레이어입니다.

TLS (Transport Layer Security)

두 컴퓨터가 인터넷으로 대화할 때 ① 내용 도청 방지, ② 중간 위변조 탐지, ③ 상대방이 진짜인지 확인 — 이 세 가지를 동시에 보장하는 표준 보안 프로토콜입니다.

SSL과 TLS의 관계 — 같은 것의 옛 이름과 새 이름

SSL = 1995년 Netscape가 만든 원조 (SSL 2.0/3.0). 보안 결함 발견되어 폐기
TLS = SSL의 후속 표준 (1999년 TLS 1.0부터). 현재는 TLS 1.3 (2018)이 최신
관습상 여전히 "SSL 인증서", "SSL/TLS"라고 부르지만 실제로 동작하는 건 모두 TLS

TLS는 어느 계층에 있나? — "L5와 L6 사이의 어딘가"

TLS는 OSI 7계층에 깔끔하게 매핑되지 않습니다. 정확히는 L4(TCP) 위 + L7(HTTP) 아래에 끼어드는 별도의 보호막 레이어입니다. 책마다 L5(세션) 또는 L6(표현)으로 부르지만, "L5~L6 사이"가 가장 정확합니다.

이름 함정 — "Transport" Layer Security지만 L4가 아님

이름이 헷갈리지만 TLS는 OSI L4(Transport, TCP) 자체가 아니라 그 위에 있습니다. 이름의 'Transport'는 "전송되는 데이터를 보호한다"는 뜻이지, "L4에서 동작한다"는 뜻이 아닙니다.

TLS가 하는 일 — 3가지 보안 보장

보장 항목	막는 위협	기술
① 기밀성 (Confidentiality)	도청 — 중간에서 패킷 들여다보기	대칭 키 암호 (AES, ChaCha20)
② 무결성 (Integrity)	위변조 — 중간에서 내용 바꿔치기	HMAC, AEAD (GCM 등)
③ 인증 (Authentication)	가짜 서버 / 중간자 공격(MITM)	X.509 인증서 + CA 서명 검증

이 세 가지를 동시에 해결하는 게 TLS의 본질입니다. 하나만 빠져도 보안이 무너집니다 — 예: 암호화는 되는데 인증이 없으면? → 가짜 사이트에 비밀번호를 암호화해서 친절히 보내는 꼴.

먼저 이해: 대칭키와 비대칭키 — 암호의 두 가족

TLS가 두 가지 암호를 결합한다고 하는데, 그 전에 "키(key)"가 뭐고, 대칭/비대칭이 정확히 어떤 차이인지 먼저 잡고 가야 합니다.

키 (Key)

암호화·복호화에 필요한 "비밀 숫자". 보통 128비트(16글자), 256비트(32글자) 정도의 무작위 바이트 덩어리. 같은 평문이라도 키가 다르면 완전히 다른 암호문이 됩니다. 키만 있으면 풀 수 있고, 키가 없으면 (이론적으로) 절대 못 품.

대칭키 암호 (Symmetric Key Cryptography)

같은 키 하나로 암호화도 하고 복호화도 하는 방식. 양쪽 모두 그 키를 알고 있어야 통신 가능. 우리가 쉽게 떠올리는 "비밀 자물쇠와 그 열쇠 1개" 그림이 정확히 이 경우입니다.

대표 알고리즘: AES-256, ChaCha20, DES(옛것)
속도: 매우 빠름 (CPU에 AES-NI 같은 전용 하드웨어 명령어가 있음)

비대칭키 암호 (Asymmetric / Public-Key Cryptography)

한 쌍의 짝지어진 키(공개키 + 비밀키)를 사용. 하나로 잠그면 오직 다른 하나로만 풀 수 있고, 그 반대 방향으로는 풀 수 없습니다. 공개키는 누구에게나 공개해도 안전, 비밀키는 본인만 가지고 있어야 합니다.

대표 알고리즘: RSA, ECC (Elliptic Curve), ECDHE
속도: 느림 (큰 소수의 거듭제곱 같은 수학적으로 복잡한 연산)

왜 이런 장단점이 생기나? — 수학과 회로의 차이

관점	대칭키 (AES)	비대칭키 (RSA, ECC)
수학적 본질	비트 단위 XOR + 치환의 반복	큰 소수의 곱셈/거듭제곱 (예: 2048비트 정수 연산)
한 번 연산 비용	몇 사이클 — 매우 가벼움	수만~수십만 사이클 — 매우 무거움
하드웨어 가속	CPU에 AES-NI 명령어 내장 (Intel·AMD·ARM 모두)	전용 가속기 거의 없음, 보통 SW로 처리
속도 비율	1배 (기준)	대칭 대비 100~1000배 느림
키 분배 방법	"같은 키"를 어떻게든 양쪽에 줘야 함 ✗	공개키는 인터넷에 공개해도 안전 ✓
큰 데이터 처리	아무리 커도 OK (4K 영상도 실시간 가능)	비현실적 (1MB 암호화에 분 단위)

왜 비대칭이 그렇게 느린가?

RSA는 "두 거대한 소수의 곱은 빠르게 계산되지만, 그 곱을 다시 두 소수로 인수분해하는 건 사실상 불가능하다"는 수학적 성질에 기반합니다. 보안의 강도가 곧 연산의 무거움이에요.

예: 2048비트 RSA 키 한 번 사용 = 2048비트 정수의 거듭제곱 모듈러 연산. 이건 64비트 CPU 하나로는 수만 번 곱셈/나눗셈을 거쳐야 합니다. AES-256은 그냥 16바이트씩 묶어서 XOR과 표 치환만 빠르게 반복해서 끝.

TLS의 영리한 트릭 — 대칭 + 비대칭 결합

TLS는 두 종류의 암호를 결합해 씁니다. 각각의 약점을 다른 쪽이 보완하는 구조입니다.

구분	대표 알고리즘	속도	키 분배	TLS에서의 역할
비대칭 (Asymmetric)	RSA, ECDSA, ECDHE	느림 (수십~수백 배)	공개키만 미리 알면 됨 ✓	Handshake에서 키 교환 + 서명 검증에만
대칭 (Symmetric)	AES-256, ChaCha20	빠름	같은 키를 양쪽이 가져야 함 ✗	본 데이터 본격 암호화

왜 둘 다 써야 하나? — 각자의 한계

대칭만 쓰면: 빠르지만 "같은 키를 어떻게 안전하게 양쪽에 줄 거냐?"가 풀리지 않음. 인터넷으로 키를 보내면 도중에 도청당함
비대칭만 쓰면: 키 분배는 안전하지만 데이터 양이 많을 때 너무 느림. 동영상 한 편이면 며칠 걸릴 수도
TLS의 해법: "비대칭으로 일회용 대칭 키를 안전하게 합의 → 그 뒤엔 대칭으로 빠르게 본 통신". Handshake 한 번만 비싸고, 본문은 빠름

TLS Handshake 4단계 (TLS 1.3 기준)

Cipher Suite — TLS 알고리즘 조합의 이름표

서버 인증서를 보면 TLS_AES_256_GCM_SHA384 같은 문자열이 보일 겁니다. Cipher Suite로, 이번 연결에 어떤 알고리즘 조합을 쓸지 명시합니다.

TLS_AES_256_GCM_SHA384 │ │ │ │ │ │ │ └─ SHA-384 (해시 함수 — 키 도출에 사용) │ │ └───── GCM (운영 모드 — 인증 + 암호화 동시) │ └───────────── AES-256 (대칭 암호 — 본 데이터 암호화) └─────────────────── TLS 1.3 cipher suite임을 표시

TLS 1.2까지는 키 교환과 인증 알고리즘도 이름에 포함되어 더 길었습니다 (예: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384). TLS 1.3에서는 키 교환은 ECDHE로 고정, 인증은 인증서에서 결정되므로 짧아졌습니다.

HTTP와 TLS의 관계 — 한 문장 요약

HTTPS = HTTP over TLS

HTTP 자체는 변하지 않습니다. HTTP 메시지가 TLS 레코드 안에 통째로 들어가, 그 TLS 레코드가 TCP로 운반될 뿐입니다. 받는 쪽은 거꾸로 TCP→TLS 복호화→원래 HTTP로 복원.

TLS는 HTTP 전용이 아니다 — 거의 모든 평문 프로토콜에 덧씌울 수 있음

평문 프로토콜	+ TLS = ?	포트
HTTP	HTTPS	443
SMTP (메일 송신)	SMTPS	465 / 587(STARTTLS)
IMAP (메일 동기화)	IMAPS	993
POP3 (메일 수신)	POP3S	995
FTP (파일 전송)	FTPS	990
DNS (도메인 조회)	DoT (DNS over TLS)	853
MQTT (IoT 메시징)	MQTTS	8883

패턴은 동일: 평문 프로토콜 메시지를 TLS로 통째로 감싸고, 별도 포트로 통신. TLS는 응용 프로토콜의 종류를 안 가립니다.

한 문단 요약 — TLS/SSL의 본질

TLS는 L4(TCP)와 L7(HTTP) 사이에 끼어드는 보안 레이어입니다. HTTP가 만든 평문 메시지를 통째로 받아 ① 암호화 ② 무결성 검증 ③ 상대 신원 인증 세 가지를 입혀 TCP로 넘깁니다. 비대칭 암호로 키를 안전하게 합의하고, 그 다음부터는 대칭 암호로 빠르게 본 통신을 합니다.

"HTTPS"는 별도 프로토콜이 아니라 단지 "HTTP + TLS"의 조합 이름. SMTP·FTP·DNS 등 다른 평문 프로토콜도 같은 방식으로 TLS를 덧씌워 보안을 입힐 수 있습니다.

8.3 네트워크 인증서란?

SSL/TLS 인증서 (X.509 Certificate)

"이 서버가 진짜 google.com이 맞다"는 것을 증명하는 디지털 신분증입니다. 신뢰할 수 있는 제3자(인증 기관, CA)가 서명해서 발급합니다. 정식 이름은 X.509 인증서.

여권을 생각하면 됩니다. 본인이 "나 김철수임"이라고 주장하는 것보다, 국가가 발급한 여권을 보여주는 게 훨씬 신뢰가 가죠. 인증서가 바로 그 여권 역할입니다.

인증서에 들어있는 내용

주체(Subject): 도메인 이름 (예: www.google.com)
공개 키(Public Key): 서버의 RSA/ECDSA 공개키
발급자(Issuer): 누가 이 인증서를 발급했나 (예: DigiCert, Let's Encrypt)
유효 기간: 보통 90일 ~ 1년
디지털 서명: 발급자(CA)가 자신의 비밀키로 서명한 값 — 이게 신뢰의 핵심
일련번호, 알고리즘 정보 등 메타데이터

인증서 검증 — 왜 가짜 서버를 막을 수 있나?

브라우저는 전 세계의 신뢰할 만한 Root CA 목록을 미리 갖고 있음 (OS·브라우저 내장)
서버가 보낸 인증서의 서명을 Root CA의 공개키로 검증 → "이거 진짜 그 CA가 서명한 거 맞네"
인증서의 도메인이 실제 접속 URL과 일치하는지 확인
유효 기간 / 폐기(Revocation) 여부 확인
모두 통과해야 🔒 표시. 하나라도 실패하면 빨간 경고

가짜 서버가 인증서를 위조하면?

만들 수는 있지만 "신뢰된 CA가 서명한 인증서"는 못 만듭니다. CA의 비밀키가 없으니까요. 자체 서명한 인증서(self-signed)는 브라우저가 즉시 "신뢰할 수 없는 인증서" 경고를 띄웁니다.

인증서의 종류 (검증 수준)

종류	검증 수준	표시	가격
DV (Domain Validation)	도메인 소유만 확인	🔒 자물쇠	무료 (Let's Encrypt)
OV (Organization Validation)	회사 실재성 확인	🔒 자물쇠	유료
EV (Extended Validation)	엄격한 회사 검증	옛날엔 회사명 표시	비쌈

8.4 인증서는 네트워크 통신 어디에서 동작하나?

인증서는 TLS Handshake 단계에서 사용됩니다. OSI 모델로는 L5/L6 경계에서 작동합니다. 정확히 어디 끼어드는지 보겠습니다:

인증서의 위치를 한 문장으로

인증서는 TCP 연결 직후, HTTP 요청 직전에 일어나는 TLS Handshake에서 "서버가 진짜인지" 확인할 때 사용됩니다. OSI 모델로는 L5/L6, TCP/IP 모델로는 응용 계층 바로 아래에 위치한 TLS 레이어에 속합니다.

실습 — 인증서 직접 보기

브라우저 주소창의 🔒 클릭 → "인증서 보기"
커맨드: openssl s_client -connect google.com:443 -showcerts
구글 인증서를 발급한 중간 CA, Root CA까지 체인 전체가 보임

9. 계층별 보안 — 보안은 한 곳이 아니다

보안은 계층마다 다른 위치에 존재합니다. 각자 다른 위협을 막습니다.

계층	보안 기술/장치	막는 위협
L1 물리	Wi-Fi 암호화 (WPA2/WPA3), 케이블 차폐, 데이터센터 출입통제	물리적 도청, 신호 가로채기
L2 데이터링크	MAC 필터링, 포트 보안, VLAN, 802.1X	로컬 네트워크 무단 접속
L3 네트워크	방화벽, IPsec, NAT	외부 침입, IP 기반 공격
L4 전송	포트 차단, TCP SYN flood 방어	포트 기반 공격, DDoS
L5/L6 ⭐	TLS/SSL — HTTPS의 핵심	중간자(MITM) 공격, 도청
L7 응용	로그인, OAuth, 2FA, E2EE, 입력 검증	인증 우회, SQL Injection, XSS

TLS vs E2EE — 가장 중요한 차이

TLS는 "PC ↔ 서버" 구간만 보호. 서버는 내용을 봄.
E2EE(End-to-End Encryption)는 "PC ↔ 친구 PC" 전 구간 보호. 서버도 못 봄.

10. 방화벽 · 보안 프로그램 · 보안 장비의 위치

보안 솔루션은 "어느 계층의 정보를 보고 판단하느냐"로 분류합니다. 위로 갈수록 똑똑하지만 느리고 비쌉니다.

10.1 방화벽의 3세대 진화

1세대 — 패킷 필터링 방화벽 (L3~L4)

판단 기준: 출발/도착 IP, 포트 번호
예: "192.168.x.x에서 들어오는 22번 포트는 차단"
한계: 패킷 하나하나만 봄. 이전 통신 맥락 모름

2세대 — 상태 기반 방화벽 (Stateful Firewall, L4)

판단 기준: TCP 연결 상태 추적 (SYN, ACK, ESTABLISHED)
예: "내가 먼저 보낸 요청의 응답은 허용, 외부에서 갑자기 들어온 패킷은 차단"
거의 모든 현대 라우터/공유기에 내장됨

3세대 — 차세대 방화벽 NGFW (L7)

판단 기준: 앱 종류, URL, 파일 내용, 사용자 ID
예: "회사에서 유튜브는 차단, GitHub은 허용", "이 PDF에 악성코드 있음 → 차단"
기술: DPI (Deep Packet Inspection) — 제품: Palo Alto, FortiGate, Cisco Firepower

10.2 보안 토폴로지 — 어디에 무엇이 있나

이 절의 그림은 물리 배선도가 아니라 논리적 구조입니다. 실제로는 한 박스에 여러 기능이 통합되거나(가정 공유기·UTM), 클라우드에서 가상으로 구현되기도 합니다. 그림의 화살표는 트래픽의 방향을 나타냅니다 — 단말마다 외부와의 관계가 달라서 방향이 다릅니다.

먼저 이해 — 세 종류의 단말은 역할이 다르다

웹 서버 (DMZ) = 서버. 외부 사용자에게 회사 웹사이트를 제공. 트래픽이 외부 → 안으로(inbound) 들어옴
내부 PC = 회사 직원 단말. 사무실에서 직원이 외부 인터넷에 접속. 트래픽이 안 → 외부로(outbound) 나감
원격 직원 PC = 외부에 있는 직원 단말 (예: 재택근무자). VPN 터널을 만들어 회사 내부망에 진입. 트래픽이 외부 → 안으로(inbound via VPN)

"인터넷"은 회사 입장에선 외부(Untrusted Zone)이고, 경계 방화벽 안쪽이 내부(Trusted Zone). 그래서 외부 사용자도 원격 직원도 모두 "인터넷 쪽"에서 출발합니다.

SIEM/SOAR란? — 점선이 의미하는 것

SIEM (Security Information & Event Management)은 회사 안의 모든 보안 장비(방화벽·IDS·WAF·EDR 등)가 만들어내는 로그·이벤트를 한곳에 모아 분석하는 별도의 시스템입니다. SOAR (Security Orchestration, Automation & Response)는 그 분석 결과에 따라 자동으로 대응(IP 차단·계정 잠금 등)합니다.

그림의 점선(⋯)은 실제 트래픽이 아니라 로그 메타데이터의 흐름입니다. 예: 방화벽이 "10.0.0.5에서 외부 1.2.3.4로 차단됨" 같은 기록을 SIEM에 전송
SIEM은 이 로그들을 묶어 패턴 분석: "같은 IP가 5분 안에 100번 로그인 실패 → 무차별 대입 공격으로 판단"
SOAR가 이를 받아 자동 대응: "그 IP를 즉시 방화벽에 차단 추가, 계정 잠금"

대표 제품: Splunk, IBM QRadar, Microsoft Sentinel, Elastic Security

"논리적 구조"란?

이 그림은 "트래픽이 어떤 보안 장비를 어떤 순서로 거치는지"를 보여주는 논리적 흐름도입니다. 실제 물리 배선과는 다음과 같이 다를 수 있습니다:

가정·소규모 회사: 공유기 1대에 방화벽·라우터·VPN·DHCP가 모두 통합 (UTM)
중규모 회사: 그림처럼 각 기능별로 별도 박스
클라우드 (AWS·GCP·Azure): 모두 가상 어플라이언스 — 실제 박스가 아니라 가상머신·서비스로 구현
Zero Trust 아키텍처: "경계"라는 개념 자체를 없애고 매 요청마다 검증 (최신 트렌드)

단말의 역할 — 최종 클라이언트 vs 서버

웹 서버는 최종 클라이언트가 아니라 서버입니다. 외부 사용자(=실제 클라이언트)에게 페이지를 응답해주는 종착지. 그래서 트래픽이 외부 → 안으로 들어옴
내부 PC와 원격 직원 PC는 클라이언트 단말. 사람이 직접 사용하는 PC로, 외부 서비스에 접속하거나 내부망 자원에 접근하는 출발지
같은 회사 안에서도 서버 단말(들어오는 트래픽 받음)과 클라이언트 단말(나가는 트래픽 생성)이 함께 존재 — 그래서 보안 구조도 양방향 모두 다룸

10.3 보안 장비/프로그램 한눈에 보기

장비	위치	계층	역할
① 경계 방화벽	네트워크 입구 / 집 공유기	L3~L7	외부↔내부 트래픽 통제, NAT 포함
② IDS / IPS	방화벽 안쪽	L3~L7	침입 탐지(IDS) / 자동 차단(IPS)
③ WAF	웹 서버 바로 앞	L7 전용	SQL Injection, XSS, CSRF 방어
④ AV / EDR	PC/서버 안 (프로그램)	호스트	악성코드·이상행위 실시간 탐지
⑤ 호스트 방화벽	OS 내부 (윈도우/macOS/Linux)	L3~L4	그 컴퓨터로 드나드는 트래픽 통제
⑥ DLP	게이트웨이 / 엔드포인트	L7	민감정보(주민번호 등) 유출 방지
⑦ Proxy	PC ↔ 인터넷 사이	L7	대신 요청·검사·로깅·캐싱
⑧ VPN	회사망 입구	L3 or L7	외부에서 내부망 암호화 접속
⑨ SIEM/SOAR	별도 서버	관제	모든 보안 장비 로그 수집·자동 대응

일반 PC 사용자가 google.com 한 번 클릭에 거치는 보안 계층

11. VPN이란?

11.1 개념

VPN (Virtual Private Network, 가상 사설망)

공용 인터넷 위에 가상의 전용 회선(터널)을 만들어, 마치 같은 사설망 안에 있는 것처럼 통신할 수 있게 해주는 기술입니다. 모든 트래픽은 암호화된 터널을 통해 흐릅니다.

11.2 VPN의 종류

종류	계층	특징	대표 예
IPsec VPN	L3	IP 패킷 전체 암호화. 회사용 표준	Cisco AnyConnect
SSL/TLS VPN	L7	웹 브라우저로 접속. 클라이언트 설치 간단	Pulse Secure, Cisco
WireGuard	L3	차세대 — 가볍고 빠름	Tailscale, Mullvad
OpenVPN	L4 위 (UDP/TCP)	오픈소스, 유연. 옛 표준	OpenVPN 커뮤니티
L2TP/PPTP	L2	옛날 VPN. 보안 약해 사용 자제	(레거시)

11.3 VPN의 실제 사용 사례

사용 사례 ① — 재택근무 / 출장 (가장 흔한 용도)

회사 내부망에만 있는 사내 시스템(ERP, Wiki, Git 서버)에 외부에서 접속해야 할 때.
→ 노트북에 회사 VPN 클라이언트 설치 → 접속 → 마치 사무실 PC처럼 내부망 자원 이용

사용 사례 ② — 공용 Wi-Fi 보호

카페·공항·호텔 Wi-Fi는 다른 사용자가 패킷을 가로챌 수 있습니다.
→ VPN을 켜면 모든 트래픽이 암호화되어 안전. HTTPS가 아닌 사이트도 보호됨.

사용 사례 ③ — 지역 우회 (Geo-bypass)

미국 서버 VPN 사용 → 인터넷 입장에서 내 IP는 미국으로 보임 → 미국 전용 컨텐츠 접근.
주의 Netflix 등은 VPN IP를 차단하기도 하고, 서비스 약관 위반일 수 있음.

사용 사례 ④ — 검열 우회 / 익명성

중국의 만리방화벽(GFW)을 우회하거나, 본인의 IP/위치를 ISP·정부에 숨기는 용도.
중요 VPN 사업자 자체는 내 트래픽을 볼 수 있음 → "No-log" 정책인 신뢰할 만한 사업자 선택 필요.

사용 사례 ⑤ — 사이트 간 연결 (Site-to-Site VPN)

서울 본사와 부산 지사의 사무실 네트워크를 VPN으로 묶음.
→ 직원 입장에서 "같은 회사망"처럼 보이지만 실제로는 인터넷을 통해 연결됨.

VPN의 한계

VPN 서버 사업자는 내 트래픽을 볼 수 있음 (TLS 안에서는 못 보지만 어디로 접속하는지는 앎)
속도 저하 — 모든 트래픽이 VPN 서버를 거치므로
VPN 서버가 해킹되면 전체 사용자 영향
회사 VPN은 "강제 풀 터널"이라 개인 트래픽도 회사 인프라를 거침 → 사생활 노출

11.4 HTTPS와 무엇이 다른가 — "처음부터 암호화"의 진짜 의미

흔히 "HTTPS는 DNS 때문에 한 번 평문화된 뒤에 보안이 시작되고, VPN은 처음부터 다 암호화된다"고 알려져 있는데, 절반만 맞는 설명입니다. 정확히 풀어보면 두 가지가 다릅니다.

먼저 짚어둘 것 — HTTPS가 "평문화 후 보안"이 아닌 이유

DNS 조회는 HTTPS 통신의 일부가 아닙니다. 4장에서 본 것처럼, DNS는 HTTPS와 별개의 사전 통신(UDP/53)이고, 끝난 뒤에야 HTTPS(TCP/443)가 시작됩니다. "HTTPS가 DNS를 위해 평문화한다"는 표현은 정확하지 않습니다.
다만 DNS 자체가 기본적으로 평문이라, 어떤 도메인을 찾는지는 ISP/Wi-Fi가 그대로 볼 수 있습니다. (DoH·DoT를 쓰면 이것도 암호화됨)
HTTPS 본 통신에서도 완전히 다 가려지는 것은 아닙니다. 다음 표 참고.

HTTPS에서 무엇이 가려지고 무엇이 노출되나

요소	HTTPS에서	VPN 터널 내부에서
HTTP 본문/헤더 (L7)	🔒 암호화	🔒 암호화 (이중)
도착지 IP (L3)	👀 평문 — 라우터가 봐야 길을 잡음	🔒 가려짐 (밖에서는 VPN 서버 IP만 보임)
도착지 포트 (L4)	👀 평문 — 443인 게 보임	🔒 가려짐
접속할 도메인 이름 (SNI)	👀 TLS Handshake의 ClientHello에 평문 노출 (ECH 미적용 시)	🔒 가려짐
DNS 질의 (도메인)	👀 사전 단계에서 평문 (DoH/DoT 미사용 시)	🔒 가려짐 (VPN 너머의 DNS 서버를 쓰면)

정리하면 HTTPS는 "내용물(L7)은 가리지만 봉투의 주소(L3/L4/SNI)는 가리지 않는" 보안입니다. 라우터가 어디로 보낼지 알아야 하니까요. 도청자는 "당신이 누구와 무슨 대화를 하는지"는 못 봐도 "당신이 google.com에 접속했다"는 사실은 알 수 있습니다.

그럼 VPN은 어떻게 "처음부터" 다 가리나 — TUN 가상 NIC의 비밀

VPN의 핵심은 OS의 네트워크 스택에 가짜 NIC(가상 인터페이스, 보통 TUN)를 끼워 넣는 것입니다. PC에서 만들어진 패킷이 진짜 NIC(Wi-Fi 카드)로 나가기 전에, 가상 NIC가 먼저 채가서 통째로 암호화·재포장한 뒤 진짜 NIC로 내보냅니다.

왜 "처음부터" 암호화가 가능한가

두 가지 트릭이 합쳐진 결과입니다.

① 라우팅 테이블 하이재킹: VPN 클라이언트는 OS의 라우팅 테이블에 "0.0.0.0/0 → TUN 인터페이스" 같은 규칙을 박아 둡니다. 그 순간부터 PC가 만드는 모든 패킷은 진짜 NIC 대신 가상 NIC로 흘러갑니다.
② 패킷 통째로 캡슐화: TUN으로 들어온 원본 패킷(L3 IP 헤더 + L4 TCP/UDP + L7 데이터)은 전체가 페이로드 취급되어 암호화됩니다. 그 위에 "출발: 내 IP, 도착: VPN 서버 IP"라는 새 IP 헤더만 평문으로 붙입니다. 원래 가려고 했던 google.com IP는 페이로드 안에 묻혀버립니다.

그래서 Wi-Fi 도청자가 봐도 "이 사람이 VPN 서버와 잡음을 주고받는다"는 사실만 보이지, 그 안에 들어 있는 "google.com:443"은 보이지 않습니다.

비유 — 봉투 두 개 vs 봉투 한 개

HTTPS = 편지지만 잠긴 봉투

편지 내용은 자물쇠로 잠가서 못 읽지만, 봉투 겉면의 받는 사람 주소(IP)와 사서함 번호(포트)는 우체국이 보라고 평문입니다. 우편 분류기(라우터)가 주소를 봐야 다음 우체국으로 보낼 수 있으니까요.

VPN = 잠긴 편지를 다시 큰 봉투에 넣어 익명 사서함으로 보내기

잠긴 편지(HTTPS 패킷)를 통째로 두 번째 봉투에 넣고, 그 봉투에는 "받는 사람: VPN 서버"라고만 적습니다. 우체국은 이 봉투를 VPN 서버까지만 배달하고, VPN 서버가 큰 봉투를 뜯어 안에 있는 진짜 편지를 꺼내서 원래 목적지(google.com)로 다시 보내줍니다. 돌아올 때도 같은 방식.

즉 VPN은 새로운 보안 기술이라기보다는 "라우팅 + 캡슐화"의 결합입니다. 안에 들어가는 트래픽은 여전히 일반 HTTPS·HTTP·DNS·게임 패킷 그대로지만, 바깥쪽 봉투가 한 겹 더 둘려 있어 도청자는 "안쪽 봉투 = 진짜 목적지"를 영영 보지 못합니다.

"이 사람 VPN 쓰네" — 그 사실 자체는 다 들킨다

맞습니다. 바깥쪽 봉투에는 "받는 사람: VPN 서버 IP"가 평문으로 적혀 있어야 하니까, ISP·Wi-Fi 운영자·중간 라우터는 누구든 그 IP를 볼 수 있습니다. 그리고 NordVPN·ExpressVPN 같은 상용 VPN 서버 IP들은 이미 공개 목록으로 돌아다닙니다. 즉:

VPN이 가리는 것 vs 가리지 못하는 것

🔒 가림: 내가 어디로(google? Netflix? 회사망?) 무슨 내용으로 통신하는지
👀 못 가림: 내가 VPN을 쓰고 있다는 사실 자체, 그리고 어떤 VPN 사업자를 쓰는지(IP로 추정)

그래서 ISP·회사 네트워크 관리자·국가 검열 시스템은 "VPN 사용자"를 식별하는 게 어렵지 않습니다. 식별 방법은 보통 이런 식으로 누적됩니다.

탐지 방법	원리	예
알려진 IP 블록	상용 VPN 사업자의 서버 IP 대역은 공개·수집됨. 도착지 IP가 그 대역에 있으면 끝.	Netflix가 NordVPN 차단
포트/프로토콜 시그니처	WireGuard(UDP/51820), OpenVPN(UDP/1194), IPsec(UDP/500·4500) 등 기본 포트가 특징적	방화벽 룰로 일괄 차단
DPI (Deep Packet Inspection)	포트를 443으로 위장해도, 패킷 길이 분포·핸드셰이크 패턴으로 "이건 TLS가 아니라 OpenVPN" 판별	중국 만리방화벽
트래픽 양상	한 IP로 모든 트래픽이 몰리고, 24시간 일정한 양의 암호화 트래픽이 흐르면 의심	기업 보안 솔루션

그럼 VPN을 왜 쓰나 — "내용 비밀" vs "사용 비밀"의 분리

VPN이 제공하는 익명성은 "나라는 사람의 존재"를 숨기는 게 아니라, "나와 목적지의 연결"을 끊는 것입니다. 이걸 게시판 비유로 보면 명확합니다.

비유 — 익명 사서함의 위력

마을에 "사서함 #42"가 있고 모두가 그게 누구 것인지는 모릅니다. 내가 거기로 편지를 보내는 모습은 동네 사람 다 보지만, 그 편지가 사서함을 거쳐 최종적으로 누구한테 갔는지는 아무도 모릅니다. VPN의 익명성은 정확히 이 구조입니다.

ISP가 아는 것: "이 사람이 NordVPN 서버 한 대와 통신했다"
ISP가 모르는 것: "이 사람이 그 안에서 무엇을 검색했고 어느 사이트에 갔는지"
목적지 서버(google)가 아는 것: "NordVPN 서버 IP에서 누군가 접속했다"
목적지 서버가 모르는 것: "그 누군가가 한국 어디의 누구인지"

→ ISP와 목적지가 가진 정보를 합쳐도 "내가 google에 갔다"는 연결은 만들어지지 않습니다. 이게 VPN의 본질입니다.

정리 — 들키는 것과 안 들키는 것

"VPN 쓴다" → 들킴. 숨길 수 없음(난독화 기능 켜도 DPI에 잡힐 수 있음)
"무엇을 위해 쓰는지(어느 사이트·무슨 내용)" → 안 들킴. 이게 VPN의 핵심 가치

그래서 검열 국가에서는 ① "VPN을 쓴다" 자체가 처벌 사유가 되거나(중국·이란 등), ② VPN을 모두 차단해 버리는 식으로 대응합니다. 이런 환경에서는 일반 VPN 위에 다시 난독화 레이어(Shadowsocks·V2Ray·obfs4)를 덧씌워 "이건 그냥 평범한 HTTPS 트래픽이에요"로 위장하는 도구를 추가로 씁니다.

"내가 직접 VPN 서버를 세우면 들키지 않을까?" — 절반의 정답

좋은 직관입니다. AWS·DigitalOcean에 인스턴스 하나 띄우고 WireGuard를 직접 설치해서 거기로 트래픽을 보낸다고 해봅시다. "NordVPN을 쓴다"는 안 들킵니다 — 그 IP는 어떤 공개 VPN 목록에도 없으니까요. 하지만 "VPN 같은 무언가를 쓴다"는 여전히 들킵니다. 이유는 세 가지입니다.

탐지 단서	왜 들키나
① IP 평판 (ASN)	AWS·GCP·DigitalOcean의 IP 대역은 "데이터센터/클라우드"로 분류됨. 일반 가정용 사용자가 그런 IP로 모든 트래픽을 보내는 건 부자연스러움 → 클라우드 IP라는 것만으로도 의심 신호
② 트래픽 패턴	한 IP·한 포트로 유튜브 영상, 메신저, 게임, 웹서핑이 다 섞여서 24시간 흘러감. 정상적인 단일 서비스(예: 회사 웹서버)는 절대 이런 패턴이 안 나옴 → "이거 터널이네"
③ DPI 시그니처	WireGuard·OpenVPN은 핸드셰이크 첫 패킷의 길이·바이트 패턴이 특징적임. 포트를 443으로 바꿔도 패킷 내용을 들여다보면 "이건 TLS가 아니라 WireGuard" 식별 가능

그래서 "누구의 VPN을 쓰는지"는 숨길 수 있어도, "VPN을 쓴다"는 트래픽의 모양 때문에 거의 항상 추정됩니다. 다만 탐지의 강도는 상황마다 다릅니다.

상황별 — 어디까지 들킬까

일반 ISP·카페 Wi-Fi: 굳이 분석하지 않음. "어떤 IP와 암호화 통신했다" 정도만 로그. 사실상 안 들킨다고 봐도 됨.
회사 방화벽(차단 정책): "알려진 VPN 포트 + 데이터센터 IP" 룰로 차단. 자작 VPN을 443 포트로 위장하면 통과될 수도 있음.
Netflix 같은 서비스: IP가 데이터센터 ASN(AWS 등)이면 그 사실만으로 차단. "이게 VPN인가?"까지 분석하지 않고, "주거용 IP가 아니다" → 차단.
중국 만리방화벽·이란 검열망: 실시간 DPI + 능동 프로빙(의심스러운 서버에 직접 연결을 시도해 응답 패턴 확인). 자작 WireGuard도 며칠~몇 주 안에 IP째로 블랙홀 처리됨. 그래서 검열망 대응 도구(V2Ray·obfs4·Shadowsocks)는 트래픽을 "평범한 HTTPS 웹서버"처럼 보이게 위장하는 데 집중함.

한 줄 정리

자작 VPN 서버를 두면 "어떤 사업자를 쓰는지"는 안 들키지만(애초에 사업자가 없으니), "VPN 같은 터널을 쓴다"는 트래픽 패턴·IP 평판·DPI로 드러납니다. 완전한 위장을 원하면 VPN만으로는 부족하고, "정상 웹서버처럼 보이게" 만드는 난독화 레이어를 추가로 얹어야 합니다.

오해 정리

"HTTPS는 DNS 때문에 평문화된다" — ❌ DNS는 HTTPS 이전의 별도 통신입니다. HTTPS 자체는 평문화 단계가 없습니다.
"HTTPS는 다 암호화된다" — ❌ 본문(L7)만. IP/포트/SNI는 평문입니다.
"VPN을 쓰면 완전히 익명이다" — ❌ VPN 사업자는 내 진짜 IP와 접속 목적지를 모두 봅니다. 도청자를 한 명에서 한 명(=VPN 사업자)으로 옮긴 것일 뿐.
"VPN을 켜면 HTTPS는 필요 없다" — ❌ VPN 서버를 나가는 순간 다시 일반 인터넷입니다. VPN 서버~목적지 구간은 HTTPS가 있어야 보호됩니다.

12. Proxy란?

12.1 개념

Proxy (프록시)

클라이언트와 서버 사이에서 요청을 대신 전달해주는 중간 서버입니다. "대리인"이라는 뜻 그대로, 내 PC가 직접 목적지 서버에 가지 않고, Proxy에게 부탁하면 Proxy가 다녀와서 결과를 전해줍니다.

12.2 Forward Proxy vs Reverse Proxy

방향에 따라 두 종류로 나뉩니다. 같은 "Proxy"라는 이름이지만 역할이 정반대입니다.

항목	Forward Proxy	Reverse Proxy
위치	클라이언트 쪽 네트워크 안	서버 쪽 네트워크 앞
누구를 숨김?	클라이언트 IP를 숨김	서버 구조를 숨김
주 용도	접속 차단·필터링·캐싱·로깅	부하 분산·SSL 종료·WAF·CDN
대표 예	회사 사내 Proxy, Squid	Nginx, Cloudflare, AWS ALB

12.3 Proxy의 사용 사례 + VPN과의 차이

Proxy 사용 사례 ① — 회사 인터넷 통제 (Forward)

모든 직원의 인터넷 트래픽을 사내 Proxy로 강제. 페이스북·게임 차단, 어떤 사이트 접속했는지 로그 기록.

Proxy 사용 사례 ② — 캐싱으로 성능 향상 (Forward)

같은 사이트를 여러 직원이 접속 → Proxy에 이미 캐시된 페이지를 즉시 응답. 트래픽·시간 절약.

Proxy 사용 사례 ③ — 부하 분산 (Reverse, Load Balancer)

네이버 같은 큰 서비스는 단일 서버로 못 버팀. Reverse Proxy가 사용자 요청을 수십~수백 대 서버에 골고루 분배.

Proxy 사용 사례 ④ — CDN (Reverse)

Cloudflare, Akamai는 전 세계에 Reverse Proxy를 두고 사용자와 가까운 곳에서 응답 → 빠른 속도.

Proxy 사용 사례 ⑤ — SSL 종료 (Reverse)

Reverse Proxy가 TLS 복호화를 담당. 뒤의 실제 서버는 평문 HTTP만 처리 → 서버 부담 감소.

VPN vs Proxy — 헷갈리는 두 개념 비교

항목	VPN	Proxy (Forward)
동작 계층	L3 (또는 L7 SSL VPN)	L7 (앱별 설정)
적용 범위	PC의 모든 트래픽	설정한 특정 앱만 (보통 브라우저)
암호화	강제 암호화 (필수)	HTTPS면 암호화, HTTP면 평문
속도	약간 느림 (전체 암호화)	상대적으로 빠름
IP 숨김	완전 숨김	HTTP 헤더로 누설 가능
주 용도	보안·내부망 접속	접근 제어·캐싱·필터링
설치	OS 레벨 클라이언트 필요	브라우저 설정만으로 가능

한 줄로 외우기

VPN = OS 전체를 감싸는 암호화 터널 (보안 강함)
Forward Proxy = 앱이 부탁하는 인터넷 대리인 (관리·필터링)
Reverse Proxy = 서버 앞에 서서 외부를 받는 문지기 (확장성)

13. 한 줄 요약

전체 요약

데이터는 위에서 아래로 내려가며 헤더가 덧붙고(캡슐화), 물리 신호로 변환되어 전송된다. 도중에 라우터들이 L2 헤더만 갈아끼우며 다음 홉으로 넘긴다. 받는 쪽은 거꾸로 헤더를 벗기며(역캡슐화) 앱까지 데이터를 전달한다.

보안은 한 계층이 아니라 여러 계층에 동시에 존재한다. Wi-Fi 암호화(L1), 방화벽(L3), TLS(L5/L6), 로그인/E2EE(L7)가 각자 다른 위협을 막는 Defense in Depth 구조.

같은 네트워크 안의 두 PC는 라우터 없이 7계층을 위→아래→케이블→아래→위로 거치며 직접 대화한다(쌍둥이 빌딩). 다른 네트워크로 갈 때는 반드시 L3 라우터를 거치며 MAC 헤더만 바뀌고 IP 헤더는 유지된다.

HTTPS는 HTTP에 TLS를 덧씌운 것. TLS Handshake에서 인증서로 서버 신원을 확인하고 세션 키를 교환한 뒤, 그 키로 모든 통신을 암호화한다.

VPN은 공용망 위에 암호화 터널을 만들어 사설망처럼 쓰는 것, Proxy는 클라이언트나 서버를 대신해 요청을 처리하는 중간 서버다. 둘 다 "중간에 끼어든다"는 점은 같지만 목적이 다르다.

더 알아보면 좋은 키워드

traceroute, tcpdump, Wireshark — 실제 패킷 분석
nslookup, dig — DNS 조회
TCP vs UDP, HTTP/2 vs HTTP/3 (QUIC), TLS 1.3
Zero Trust Architecture (제로 트러스트)
NGFW, WAF, EDR, XDR, SIEM, SOAR
DPI (Deep Packet Inspection)
SD-WAN, ZTNA

작성일: 2026-05-13 (최종 수정: 2026-05-14)
관련 문서: 클라우드 · VM · 도커