OSI 7계층 읽는 법: 캡슐화와 네트워크 장애 구간 찾기

OSI 7계층은 네트워크 프로토콜을 일곱 칸에 외워 넣기 위한 표가 아니다. 서로 다른 시스템의 통신 기능을 나눠 설명하기 위한 참조 모델이다. 실제 인터넷은 TCP/IP 계열 프로토콜로 동작하고, 어떤 프로토콜은 OSI의 한 계층에 깔끔하게 들어맞지 않는다.

그래도 OSI 모델은 여전히 쓸모가 있다. “문제가 물리 연결에 있는가, IP 전달에 있는가, 전송 연결에 있는가, 애플리케이션에 있는가”를 같은 언어로 나눌 수 있기 때문이다.

OSI 7계층 한눈에 보기

계층	이름	주된 책임	장애를 볼 때의 질문
7	Application	사용자에게 가까운 네트워크 서비스와 메시지 의미	HTTP·DNS 요청과 응답은 정상인가
6	Presentation	데이터 표현, 인코딩, 압축, 암호화에 관한 기능	양쪽이 같은 형식으로 해석하는가
5	Session	대화의 수립·유지·동기화에 관한 기능	대화 상태와 재개 지점은 유지되는가
4	Transport	종단 간 전달, 포트, 신뢰성·흐름 제어	TCP 연결, 재전송, 포트는 정상인가
3	Network	네트워크 사이의 주소 지정과 패킷 전달	IP 주소와 경로가 올바른가
2	Data Link	인접 링크의 프레임 전달과 매체 접근	같은 링크에서 프레임이 오가는가
1	Physical	비트를 전기·광·무선 신호로 전송	케이블·신호·링크 상태가 정상인가

위 표의 사례는 이해를 위한 대표 예다. 예를 들어 TLS를 6계층, ARP를 2계층 또는 3계층이라고 한 칸에 고정하면 오히려 실제 동작을 놓칠 수 있다. 프로토콜의 이름을 어느 칸에 넣느냐보다 어떤 헤더와 상태를 어느 장비가 처리하는가를 보는 것이 중요하다.

7계층부터 1계층까지 무엇을 맡는가

7계층 Application: 애플리케이션이 이해하는 메시지

Application 계층은 최종 사용자의 프로그램이 이용하는 네트워크 기능과 가장 가깝다. HTTP의 method·header·status code, DNS의 query·answer 같은 의미가 여기에 해당한다.

GET /posts/261 HTTP/1.1
Host: chaaany.tistory.com

TCP 연결이 성공했더라도 HTTP가 404나 500을 반환할 수 있다. 이 경우 물리 링크부터 다시 의심하기보다 애플리케이션 라우팅, upstream, 데이터와 로그를 확인해야 한다.

6계층 Presentation: 같은 바이트를 같은 의미로 읽기

Presentation 계층은 데이터 표현의 차이를 다룬다는 개념적 구분이다. 문자 인코딩, 직렬화 형식, 압축, 암호 표현을 떠올릴 수 있다.

실제 인터넷 구현에서는 이 기능이 독립된 계층 제품으로 분리되지 않고 애플리케이션 라이브러리나 프로토콜 안에 함께 들어가는 경우가 많다. JSON 파싱 오류, 잘못된 문자 인코딩, 인증서와 암호화 설정 문제는 “표현과 해석이 일치하는가”라는 질문으로 볼 수 있다.

5계층 Session: 대화 상태를 어떻게 이어 갈까

Session 계층은 통신 대화를 시작하고 유지하며 동기화하는 기능을 설명한다. 하지만 TCP/IP 애플리케이션에서는 session 기능을 애플리케이션이나 라이브러리가 직접 구현하는 경우가 흔하다.

웹 로그인 세션, RPC 연결 관리, 재연결 후 작업 재개를 모두 OSI 5계층 프로토콜이라고 부르는 것은 정확하지 않다. 다만 “연결과 별개로 대화 상태가 어디에 저장되고 어떻게 복구되는가”를 묻는 관점은 유용하다.

4계층 Transport: 프로세스 사이의 종단 간 전달

Transport 계층은 포트 번호를 이용해 목적지 프로세스를 구분하고 종단 간 데이터를 운반한다. TCP는 순서 있는 신뢰적 바이트 스트림을 제공하며, UDP는 연결 수립 없이 datagram을 전달한다.

client 10.0.0.8:51820
      ── TCP ──>
server 203.0.113.10:443

ping이 된다고 HTTPS 접속이 보장되지는 않는다. IP 경로가 살아 있어도 TCP 443이 방화벽에서 차단되거나, server가 listen하지 않거나, 연결 이후 TLS에서 실패할 수 있다.

3계층 Network: 다른 네트워크까지 패킷을 전달

Network 계층은 논리 주소와 네트워크 간 전달을 맡는다. IP 주소, prefix, 라우팅과 TTL·Hop Limit을 생각하면 된다. 라우터는 패킷의 목적지 주소와 포워딩 정보를 보고 다음 홉을 결정한다.

목적지 IP
   ↓ longest-prefix match
다음 홉 또는 출력 interface

IP가 맞아도 route가 없거나 잘못된 gateway를 향하면 목적지에 도달할 수 없다. ip route get, traceroute, cloud route table 같은 정보가 이 구간을 확인하는 단서다.

2계층 Data Link: 바로 옆 장치까지 프레임 전달

Data Link 계층은 하나의 링크에서 프레임을 전달한다. Ethernet의 MAC 주소와 frame, Wi-Fi의 매체 접근 같은 기능이 대표적이다. 스위치는 학습한 MAC 주소를 바탕으로 frame을 적절한 port로 보낸다.

IP 패킷을 다음 홉으로 보내려면 그 링크에서 사용할 주소 정보가 필요하다. IPv4의 ARP는 IP 주소와 링크 계층 주소를 연결하는 역할을 하므로 한 칸짜리 암기표에 억지로 넣기보다 L3 주소를 이용해 L2 전달을 준비하는 경계 프로토콜로 이해하는 편이 낫다.

1계층 Physical: 비트를 신호로 옮기기

Physical 계층은 케이블, 광, 무선 주파수와 신호 수준에서 비트를 운반한다. cable 불량, 광 signal 문제, NIC link down, Wi-Fi signal 약화 같은 문제가 여기에 가깝다.

운영체제에서 interface가 DOWN이거나 switch port가 연결되지 않았다면 상위 계층 설정만 바꿔서는 해결되지 않는다.

캡슐화는 어떻게 일어나는가

송신 측에서는 상위 계층 데이터가 아래 계층으로 내려가며 각 계층에 필요한 제어 정보가 붙는다. 수신 측에서는 반대로 헤더를 해석하며 원래 메시지를 위로 올린다.

HTTP 메시지
└─ TCP header + data                 → segment
   └─ IP header + TCP segment        → packet
      └─ Ethernet header/trailer ... → frame
         └─ bit와 signal

계층별 데이터 단위를 PDU라고 부른다. 수업에서는 흔히 L4 segment, L3 packet, L2 frame, L1 bit로 구분한다. 다만 transport에서 UDP 데이터 단위는 datagram이라고 부르는 등 실제 문맥의 용어가 더 구체적일 수 있다.

캡슐화를 이해하면 packet capture를 읽기 쉬워진다. Wireshark에서 한 frame을 열면 Ethernet, IP, TCP, HTTP 정보가 중첩되어 보이는 이유가 바로 이 구조다.

OSI와 TCP/IP 모델은 같은 표가 아니다

실제 인터넷 설명에는 TCP/IP 모델이 더 직접적이다. 대략적으로 다음처럼 대응시킬 수 있지만 완벽한 일대일 관계는 아니다.

OSI 참조 모델	TCP/IP 관점
7 Application	Application
6 Presentation	Application에 통합되는 경우가 많음
5 Session	Application에 통합되는 경우가 많음
4 Transport	Transport
3 Network	Internet
2 Data Link	Link
1 Physical	Link의 물리적 기반으로 함께 설명되기도 함

OSI는 기능을 세밀하게 분리한 참조 모델이고, TCP/IP는 실제 인터넷 프로토콜 집합을 설명하는 데 가까운 모델이다. 어느 모델이 “정답”인가를 고르기보다 대화의 목적에 맞춰 사용하면 된다.

AWS 구성 요소를 OSI 관점에서 읽는 실전 예시는 AWS 네트워크와 OSI 7계층 기초에서 이어서 볼 수 있다.

장애 분석에서는 아래에서 위로만 볼 필요가 없다

OSI 장애 분석을 “항상 1계층부터 7계층까지 전부 확인한다”로 받아들이면 느리다. 증상에서 가장 가능성이 높은 경계부터 확인하되, 각 확인 결과가 어느 계층을 입증하는지 구분하는 것이 좋다.

웹 서비스에 접속할 수 없을 때

1. 이름 해석: dig example.com
2. 경로 선택: ip route get <IP>
3. 포트 연결: nc -vz example.com 443
4. TLS·HTTP: curl -v https://example.com/
5. local link: ip link, Wi-Fi·switch 상태

• dig가 성공했다고 TCP 443이 열린 것은 아니다.
• TCP 연결이 성공했다고 TLS 인증과 HTTP 응답이 정상인 것은 아니다.
• curl의 HTTP 500은 대체로 L7 쪽 조사로 넘어가야 한다는 신호다.
• 하나의 command 결과만으로 다른 계층 전체를 정상이라고 단정할 수 없다.

계층별로 남길 증거

범위	유용한 증거
L1·L2	link state, error·drop counter, switch port, ARP·neighbor 상태
L3	주소·prefix·route, traceroute, ICMP 오류
L4	listen socket, connection state, retransmission, firewall rule
L5~L7	TLS handshake, HTTP status, application log, trace ID

이렇게 결과를 계층별 증거로 남기면 “네트워크 문제”라는 모호한 표현을 “DNS 응답은 정상이고 IP 경로도 있지만 TCP 443 handshake가 timeout 난다”처럼 바꿀 수 있다. 협업 속도도 훨씬 빨라진다.

외울 것과 외우지 않아도 될 것

계층의 이름과 큰 책임은 익혀 두면 좋다. 다만 프로토콜 이름을 한 계층에 고정하는 표는 예외가 많고 현실의 구현을 단순화한다.

남겨야 할 질문은 다음 세 가지다.

1. 지금 보고 있는 정보는 어느 통신 경계의 것인가?
2. 이 계층이 제공하는 보장과 제공하지 않는 보장은 무엇인가?
3. 다음 계층으로 넘어가기 전에 어떤 증거를 확인했는가?

OSI 7계층의 가장 큰 가치는 암기 시험이 아니라 복잡한 통신을 책임 단위로 나누는 데 있다. 모델을 지도처럼 사용하되, 실제 packet과 protocol 문서를 지형으로 확인하는 습관이 필요하다.

참고 자료

• ISO/IEC 7498-1:1994, OSI Basic Reference Model
• IETF RFC 1122: Requirements for Internet Hosts—Communication Layers
• IETF RFC 9293: Transmission Control Protocol