[Network] OSI 7계층과 TCP/IP 4계층 모델 실무적 관점 분석

서버에 배포한 서비스가 갑자기 안 된다는 신고가 들어왔습니다. 어디서부터 확인해야 할까요? 서버 자체가 살아있는지, 포트가 열려있는지, 애플리케이션이 응답하는지 — 순서 없이 여기저기 찔러보다가 시간만 가는 상황을 막으려면 계층별 사고 프레임이 필요합니다. OSI 7계층 모델이 바로 이 프레임입니다.

확대

건물에 비유하면, 전기가 들어오는지(L1), 인터폰이 작동하는지(L2), 주소를 찾아오는지(L3), 문이 열리는지(L4), 안에 사람이 있는지(L7) — 각 층을 차례로 확인하면 어디가 문제인지 빠르게 좁혀집니다. 네트워크 장애 대응이 정확히 이 방식으로 이루어집니다.

OSI(Open Systems Interconnection) 모델은 ISO가 1984년에 정의한 네트워크 통신의 표준 참조 모델입니다. 네트워크 통신을 7개의 계층으로 나누어, 각 계층이 하는 역할을 명확하게 정의했습니다.

실제 구현에서는 TCP/IP 모델을 사용하지만, 장애 진단과 개념 설명에서는 OSI 7계층이 훨씬 세밀하기 때문에 지금도 표준 언어로 사용됩니다.

L7  애플리케이션 계층  (Application)   HTTP, HTTPS, DNS, SMTP, FTP
L6  표현 계층        (Presentation)   TLS/SSL, 인코딩, 압축
L5  세션 계층        (Session)        세션 관리, 인증
L4  전송 계층        (Transport)      TCP, UDP — 포트 번호
L3  네트워크 계층    (Network)        IP — 라우팅, 논리 주소
L2  데이터링크 계층  (Data Link)      Ethernet, MAC 주소
L1  물리 계층        (Physical)       케이블, 광섬유, 전기 신호

계층의 핵심 원칙: 각 계층은 자신의 역할만 담당하고, 위아래 계층에 서비스를 제공합니다. 데이터는 송신 측에서 L7→L1 방향으로 **캡슐화(Encapsulation)**되고, 수신 측에서 L1→L7 방향으로 **역캡슐화(Decapsulation)**됩니다.

계층을 표로 외웠어도, curl 한 줄이 실제로 케이블에 나가는 과정을 그리지 못하면 tcpdump 캡처나 MTU·방화벽 문제에서 "지금 어느 계층 헤더를 보고 있는지" 감이 안 옵니다. 데이터는 보낼 때 위(L7)에서 아래(L1)로 내려가며 각 계층이 자기 헤더를 덧씌우고(캡슐화), 받을 때는 아래에서 위로 올라가며 한 겹씩 벗깁니다(역캡슐화). 이 흐름과 TCP 연결이 맺어지는 순서를 알면 장애가 어느 계층에서 났는지 한눈에 좁혀집니다.

① 보낼 때 — 계층을 내려가며 헤더를 덧씌운다(캡슐화):

[송신 호스트]  curl → HTTP 요청 바이트
   │
  L7 응용     HTTP 메시지 생성                     [ HTTP 데이터 ]
   │  ↓
  L4 전송     TCP 헤더 부착(출발/목적 포트, seq)    [ TCP | 데이터 ]        = 세그먼트
   │  ↓
  L3 네트워크  IP 헤더 부착(출발/목적 IP), 경로 결정  [ IP | TCP | 데이터 ]   = 패킷
   │  ↓ (다음 홉 MAC이 필요 → ARP로 조회)
  L2 링크     이더넷 헤더/트레일러 부착(MAC)        [ ETH | IP | TCP | 데이터 | FCS ]  = 프레임
   │  ↓
  L1 물리     비트(전기/광 신호)로 링크에 송출       1010111000...
   ▼
[네트워크]  스위치(L2)·라우터(L3)를 거쳐 목적지로 → 수신 측은 L1→L7로 역캡슐화(헤더를 거꾸로 벗김)

② 연결을 맺고 끊는 순서 — TCP 3-way handshake와 상태 변화:

클라이언트                                   서버 (LISTEN)
   │  SYN (seq=x)              ─────▶          접속 요청
   │  (SYN-SENT)                               (SYN-RCVD)
   │            ◀─────  SYN-ACK (seq=y, ack=x+1)   응답 + 승인
   │  ACK (ack=y+1)           ─────▶          승인 확정
   │  ===== 양쪽 ESTABLISHED : 데이터 송수신 =====
   │  ...HTTP 요청/응답...
   │  FIN                     ─────▶          종료 요청
   │            ◀─────  ACK, 이어서 FIN            종료 승인
   │  ACK                     ─────▶
   │  (TIME-WAIT: 잔여 패킷 대기)                (CLOSED)

각 계층이 붙이는 것과, 막히면 나타나는 증상:

즉 "패킷이 나갔다"는 L7의 바이트가 TCP·IP·이더넷 헤더로 세 겹 감싸여 프레임으로 송출됐고, 수신 측이 역순으로 벗겨 앱까지 올렸다는 뜻입니다. tcpdump로 보는 것이 바로 이 헤더들입니다. 연결이 어디서 막혔는지는 ss -tan으로 소켓 상태를 보면 드러납니다 — LISTEN은 서버가 대기 중, SYN-SENT가 쌓이면 내 SYN에 상대가 응답을 안 하는 것(L3/L4 경계, 방화벽 DROP·서버 미기동), ESTABLISHED면 핸드셰이크 성공, TIME-WAIT 폭증은 짧은 연결을 너무 자주 여닫는다는 신호(능동 종료 측이 2MSL 동안 잔여 패킷을 기다림)입니다. 그래서 "포트가 안 열린다"는 신고는 ss로 상태부터 보고, SYN 단계(L4 핸드셰이크)에서 멈췄는지 그 위(L7 앱)에서 멈췄는지를 먼저 가릅니다.

OSI 7계층을 외웠는데 실제 코드나 문서에서는 "인터넷 계층", "전송 계층"이라는 말이 나옵니다. 팀원이 "L4에서 막힌 것 같다"고 할 때 OSI 기준인지 TCP/IP 기준인지 헷갈립니다. 두 모델을 자유롭게 오가며 매핑할 줄 알아야 문서를 읽고 장비 설정을 이해할 수 있습니다.

실제 인터넷 구현에 사용되는 모델입니다. OSI 7계층을 실용적으로 단순화하여 4계층으로 표현합니다.

확대

실무에서 OSI와 TCP/IP를 모두 알아야 하는 이유:

• 장비/제조사 문서, RFC, 교재 → OSI 계층 용어 사용
• 실제 프로토콜/코드 이해 → TCP/IP 모델
• 두 모델 간 매핑을 자유롭게 할 수 있어야 합니다.

계층 사다리(ping→nc→curl)는 '아래가 되면 아래는 배제한다'는 전제로 돌아갑니다. 그런데 이 전제는 각 테스트가 같은 경로·같은 크기의 패킷을 검사할 때만 참입니다. ping과 nc가 통과했는데도 큰 데이터만 멈추는 순간, 그 전제가 무너집니다.

• 테스트마다 패킷 크기가 다릅니다: ping은 기본적으로 작은(56바이트) 패킷을 보내고, nc -z는 TCP 핸드셰이크만 하고 페이로드를 보내지 않습니다. 둘 다 'MSS로 꽉 찬 큰 세그먼트'를 한 번도 보내지 않으므로, 큰 패킷에서만 나는 문제를 원리적으로 못 잡습니다.
• MTU와 MSS: 이더넷 링크의 MTU는 보통 1500바이트입니다. TCP는 핸드셰이크에서 로컬 MTU를 기준으로 MSS를 협상합니다. 그런데 경로 중간에 MTU가 더 작은 링크(VPN·터널·PPPoE 등)가 있으면, 로컬 기준으로 만든 큰 세그먼트가 그 링크를 통과하지 못합니다.
• PMTU 블랙홀: 원래는 그 라우터가 ICMP 'Fragmentation Needed'(Type 3 Code 4)로 '더 작게 보내라'고 알려주고(Path MTU Discovery), 송신자가 세그먼트를 줄입니다. 하지만 방화벽이 이 ICMP를 막으면 송신자는 영영 모른 채 큰 세그먼트만 반복 재전송하다 멈춥니다 — 이것이 PMTU 블랙홀입니다.
• 그래서 증상이 '크기 의존적'입니다: 핸드셰이크·작은 API 응답은 통과하고, 큰 본문·파일 다운로드·업로드만 멈춥니다. '하위 계층 OK'로 보이지만 실제로는 L3/L4 경계의 MTU 문제입니다.

정리하면, 계층 진단 사다리에 크기를 인식하는 테스트(큰 패킷 ping, 큰 객체 curl)를 한 칸 더 두어야 ping·nc가 숨기는 MTU 문제를 드러낼 수 있습니다.