OSI 7계층 — HTTP 요청 하나가 상대 서버에 닿기까지

브라우저에서 엔터를 누르면 HTTP 요청이 서버에 전달된다. 당연하게 느껴지지만, 이 과정에서 실제로 무슨 일이 일어나는지 설명하려고 하면 막막해진다. OSI 7계층은 이 과정을 역할별로 나눠서 설명하는 표준 모델이다.

왜 계층으로 나눠야 하는가

HTTP가 데이터를 어떤 경로로 전달하는지 알 필요는 없다. TCP가 HTTP 내용이 뭔지 알 필요도 없다. 각자 자기 역할만 알면 된다. 이게 계층을 나누는 이유다.

이 독립성이 실제로 어떤 의미를 가지는지는 변경 사례를 보면 명확해진다. HTTP가 HTTPS로 바뀌어도 아래의 TCP는 손대지 않았다. HTTP/3이 UDP를 쓰기로 해도 IP 계층은 그대로다. 계층끼리 인터페이스만 맞추면 되기 때문에, 한 계층의 구현이 바뀌어도 다른 계층에 영향이 없다.

7개 계층이 하는 일

계층	이름	역할	대표 프로토콜
7	Application	사용자가 직접 쓰는 프로토콜	HTTP, FTP, DNS
6	Presentation	데이터 형식 변환, 암호화	SSL/TLS
5	Session	연결 세션 유지/종료	-
4	Transport	포트 기반으로 어느 프로세스에게	TCP, UDP
3	Network	IP 기반으로 어느 컴퓨터로	IP, ICMP
2	Data Link	같은 네트워크 안에서 MAC 기반 전달	Ethernet, Wi-Fi
1	Physical	전기 신호로 비트를 전송	케이블, 광섬유

계층 구조에서 핵심은 3, 4, 7계층이다. 3계층은 "전 세계 어느 컴퓨터로"를 결정하고, 4계층은 "그 컴퓨터 안의 어느 프로세스(포트)로"를 결정하며, 7계층은 그 프로세스가 데이터를 어떻게 해석할지를 정의한다. 데이터의 최종 목적지는 결국 IP + 포트의 조합이다.

데이터는 보낼 때 7→1 순서로 각 계층이 헤더를 추가하며 포장되고, 받을 때 1→7 순서로 하나씩 벗겨지며 해석된다. 이를 캡슐화(Encapsulation)라고 한다.

[HTTP 데이터]
[TCP 헤더 | HTTP 데이터]
[IP 헤더  | TCP 헤더 | HTTP 데이터]
[MAC 헤더 | IP 헤더  | TCP 헤더 | HTTP 데이터]  ← 전선으로 나감

IP는 목적지, MAC은 구간

IP 주소가 있는데 MAC 주소가 왜 또 필요한가.

IP는 최종 목적지 컴퓨터를 가리킨다. 출발지부터 목적지까지 내내 바뀌지 않는다. 반면 MAC은 현재 구간에서 다음 장비가 누구인지를 나타낸다. 라우터를 하나 거칠 때마다 교체된다.

구간 1 (내 노트북 → 라우터A)
  src MAC: 내 노트북 MAC  /  dst MAC: 라우터A MAC
  src IP:  내 IP           /  dst IP:  목적지 IP  ← 안 바뀜

구간 2 (라우터A → 목적지 서버)
  src MAC: 라우터A MAC    /  dst MAC: 목적지 서버 MAC  ← 교체됨
  src IP:  내 IP           /  dst IP:  목적지 IP

라우터는 IP만 보고 다음에 어디로 보낼지 결정한다. MAC은 그 결정이 내려진 후, 지금 이 구간에서 실제로 프레임을 전달하기 위한 주소다. IP가 end-to-end라면, MAC은 hop-to-hop이다.

같은 LAN 안에서 MAC을 모를 때 — ARP

IP 주소는 알지만 MAC 주소를 모를 때는 어떻게 할까. 같은 LAN 안의 모든 장비에게 브로드캐스트로 물어본다. "이 IP 가진 장비 MAC 주소 알려줘." 해당하는 장비가 MAC 주소로 응답하면, 그 결과를 ARP 캐시에 저장해두고 이후 통신에 사용한다. 이 프로토콜을 ARP(Address Resolution Protocol)라고 한다.

도메인 이름을 IP로 바꾸는 일 — DNS

IP 주소를 외우는 대신 google.com처럼 도메인으로 요청할 수 있는 건 DNS(Domain Name System) 덕분이다. DNS는 도메인 이름을 IP 주소로 변환해주는 계층 구조 시스템이다.

브라우저에 도메인을 입력하면 아래 순서로 IP를 찾는다.

브라우저 캐시 → OS 캐시 → /etc/hosts → ISP DNS → Root DNS → TLD DNS → Authoritative DNS

앞쪽 세 군데는 이전에 조회한 결과를 재사용하는 캐시다. 여기서 못 찾으면 DNS 서버 계층으로 올라간다. Root DNS는 전 세계 13개가 있으며 .com, .kr 같은 TLD를 담당하는 DNS 서버 주소를 알고 있다. TLD DNS는 google.com의 실제 DNS 서버 주소를 알고 있고, 그 Authoritative DNS가 최종 IP를 응답한다. 각 단계의 결과는 TTL(Time To Live) 동안 캐싱되어, 매번 전체 계층을 거치지 않아도 된다.

개발 중 DNS를 바꿨는데 반영이 안 된다면 OS DNS 캐시를 지워주면 된다.

sudo dscacheutil -flushcache  # Mac
ipconfig /flushdns             # Windows

TCP/IP 4계층 — 실제로 쓰는 모델

현실에서는 OSI 5, 6, 7계층을 하나의 Application 계층으로 합친 TCP/IP 4계층 모델을 더 많이 쓴다.

OSI 7계층           TCP/IP 4계층
7. Application  ┐
6. Presentation ├──▶  Application
5. Session      ┘
4. Transport    ───▶  Transport
3. Network      ───▶  Internet
2. Data Link    ┐
1. Physical     ┘──▶  Network Access

OSI 7계층은 이론적 표준 모델이고, TCP/IP 4계층은 실제 인터넷 구현 기준이다. SSL/TLS를 "6계층"이라고 말하기보다 "4계층과 7계층 사이에서 동작한다"고 설명하는 것이 더 정확한 이유도 여기에 있다.

실무에서 이 개념이 쓰이는 곳

계층 구조를 이해하면 네트워크 문제를 진단할 때 어느 계층에서 문제가 발생했는지 범위를 좁힐 수 있다. 핑(ping)은 3계층(IP)까지 확인하고, telnet이나 curl은 4계층(TCP)과 7계층(HTTP)까지 확인한다. "IP는 닿는데 포트가 안 열려" 같은 표현이 3계층과 4계층을 구분해서 말하는 것이다.

서버에서 8080 포트로 listen한다는 건 4계층에서 8080번으로 오는 데이터를 해당 프로세스로 올려달라는 의미다. 로드밸런서가 L4, L7 방식으로 나뉘는 것도 어느 계층의 정보를 기준으로 트래픽을 분배하느냐의 차이다.