階層モデル — それぞれの層が何を決めるのか

한 줄 요약

계층은 각 층이 아래층의 서비스만 쓰고 위층에는 인터페이스만 노출하도록 나눈 설계이며, 장애를 진단할 때는 "어느 층까지 성공했는가"를 묻는 도구가 된다.

왜 이게 필요했나

네트워크는 한 사람이 만들지 않는다. 광케이블을 까는 회사, 라우터를 만드는 회사, 브라우저를 만드는 회사가 다 다르다. 이들이 서로의 구현을 몰라도 함께 동작하려면 경계와 계약이 필요하다.

계층화가 그 계약이다. 아래층은 위층에 서비스를 제공하고, 위층은 아래층이 그 서비스를 어떻게 구현했는지 몰라도 된다. TCP 는 자기 세그먼트가 광케이블로 가든 와이파이로 가든 신경 쓰지 않는다.

어떻게 동작하나

교과서의 OSI 7계층과 실제 인터넷의 TCP/IP 모델은 이렇게 대응한다.

OSI	TCP/IP	이 층이 결정하는 것	데이터 단위
응용, 표현, 세션	응용	무엇을 주고받을 것인가 (HTTP, DNS)	메시지
전송	전송	어느 프로세스에게, 신뢰성 있게 보낼 것인가	세그먼트 / 데이터그램
네트워크	인터넷	어느 호스트로, 어떤 경로로 보낼 것인가	패킷
데이터 링크	링크	같은 네트워크 안 다음 장비까지 어떻게 보낼 것인가	프레임
물리	링크	비트를 어떤 신호로 바꿀 것인가	비트

캡슐화는 위층 데이터에 아래층 헤더를 덧붙이는 과정이다. HTTP 요청에 TCP 헤더가 붙어 세그먼트가 되고, IP 헤더가 붙어 패킷이 되고, 이더넷 헤더가 붙어 프레임이 된다. 받는 쪽은 역순으로 벗긴다.

여기서 자주 오해되는 지점을 짚어야 한다. OSI 7계층은 교육용 모형이지 인터넷의 구현이 아니다. 표현 계층과 세션 계층에 정확히 대응하는 인터넷 프로토콜은 없다. "TLS 는 몇 계층인가" 같은 질문에 딱 떨어지는 답이 없는 이유다. TLS 는 TCP 위에서 동작하며 응용 데이터를 암호화하므로 어디에 놓아도 어색하다. 모델은 이해를 돕는 도구이지 실체가 아니다.

현장에서 만나는 모습

계층 모델의 실전 가치는 진단 순서에 있다. 접속이 안 될 때 다음 순서로 물으면 범위가 빠르게 좁혀진다.

1. 이름이 풀리는가 — getent hosts api.example.com (응용 계층 아래의 이름 해석)
2. 그 주소로 TCP 연결이 되는가 — curl -v --connect-timeout 3 http://주소:포트/
3. 연결은 되는데 응답이 없는가 — 전송 계층은 통과했고 응용 계층 문제다

이 순서를 지키면 "네트워크가 안 돼요"라는 보고를 "3번 단계에서 멈춘다"로 바꿀 수 있다. 참고로 실습 환경처럼 ping 이나 tcpdump 를 쓸 수 없는 곳에서도 ss, curl, dig, getent, /proc/net/* 만으로 위 세 단계는 전부 확인할 수 있다.

증상으로 층을 찾는 표

계층 모델의 실용적 값어치는 증상을 보고 어느 층을 볼지 정하는 것 입니다.

증상	의심할 층	확인 명령
링크가 안 올라온다	L1 물리	ip link, 케이블·SFP
같은 서브넷인데 안 통한다	L2	ip neigh, ARP 응답
다른 대역이 안 통한다	L3	ip route get, traceroute
포트만 안 열린다	L4	nc -zv, 방화벽
이름이 안 풀린다	응용(DNS)	getent hosts, dig
TLS 오류	표현(TLS)	openssl s_client -connect
404·500	응용	애플리케이션 로그

아래에서 위로 올라가는 것 이 기본이지만, 실무에서는 가운데(L3/L4)부터 보는 편이 빠릅니다. 물리 문제는 드물고 응용 문제는 로그가 알려 주기 때문입니다.

캡슐화가 만드는 오버헤드

각 층이 헤더를 붙이므로 실제 데이터는 그만큼 줄어듭니다.

이더넷 프레임 1518 바이트 (MTU 1500)
  − IP 헤더 20
  − TCP 헤더 20
  = 1460 바이트가 실제 데이터 (MSS)

VPN 이나 오버레이 네트워크를 쓰면 여기에 헤더가 더 붙습니다. VXLAN 은 50바이트를 더하므로 실제 MSS 가 1410 이 됩니다. MTU 를 맞추지 않으면 큰 패킷이 조각나거나 버려집니다.

이것이 쿠버네티스에서 "작은 요청은 되는데 큰 응답이 멈춘다" 는 증상의 원인입니다. 경로 MTU 발견(PMTUD)이 ICMP 를 쓰는데, 그 ICMP 가 방화벽에 막히면 송신자가 계속 큰 패킷을 보내고 아무 응답도 못 받습니다(PMTU 블랙홀).

# 조각내지 않고 보낼 수 있는 최대 크기 찾기
ping -M do -s 1472 <대상>      # 1472 + 28(ICMP+IP) = 1500

왜 TCP 와 UDP 를 나누나

	TCP	UDP
연결	3-way 핸드셰이크	없다
순서·재전송	보장	없다(앱이 한다)
흐름 제어	있다	없다
첫 바이트까지	최소 1 RTT 추가	즉시

DNS 가 UDP 를 쓰는 이유 는 질의 하나에 핸드셰이크 3번은 낭비이기 때문입니다. 응답이 512바이트를 넘으면 TCP 로 다시 물어봅니다.

QUIC 은 UDP 위에 신뢰성과 암호화를 다시 만든 것입니다. TCP 의 문제(헤드 오브 라인 블로킹, 커널에 박힌 구현)를 피하면서 신뢰성을 얻으려는 설계입니다.

이어지는 퀴즈에서 확인할 것

각 계층이 무엇을 결정하는지, 캡슐화 순서가 어떻게 되는지, 그리고 OSI 모형을 어디까지 믿어야 하는지 확인한다.