OSI 7계층은 역할을 나눠 이해하는 참조 모델입니다. 실제 인터넷 프로토콜 묶음은 응용·전송·인터넷·링크처럼 더 적은 층으로 설명하기도 합니다. 이 데모는 두 관점을 나란히 놓되, 핵심 아이디어 하나만 택배에 비유합니다.
보낼 물건을 상자에 넣고, 송장을 붙이고, 배송 트럭에 싣는다. 받는 쪽은 반대로 한 겹씩 뜯는다.
이 데모는 그 한 가지 과정만 보여줍니다.
명령 하나가 서버까지 가는 길
예제 메시지는 Redis 랩에서 다룬 것과 이어지는
SET user:1 kim 명령입니다. 이 짧은 명령 하나도 서버에 닿으려면 겹겹이
포장됩니다.
- 응용 계층(L7) — 명령이 규격에 맞는 바이트로 변환됩니다.
- 전송 계층(L4) — TCP 헤더가 붙습니다. 목적 포트 6379가 "서버의 어느 프로그램이 받을지"를 정합니다.
- 네트워크 계층(L3) — IP 헤더가 붙습니다. 출발·목적 IP 주소로 먼 길을 찾습니다.
- 데이터링크 계층(L2) — 이더넷 헤더가 붙습니다. MAC 주소로 바로 옆 장비까지, 문 앞 배달을 맡습니다.
- 물리 계층(L1) — 전체가 0과 1의 신호가 되어 선로를 타고 이동합니다.
이렇게 포장을 더하는 과정을 캡슐화, 받는 쪽에서 한 겹씩 뜯는 과정을 역캡슐화라고 합니다. 서버의 응답도 똑같은 왕복을 거칩니다.
계층이 나뉘어 있는 이유
역할이 나뉘어 있기 때문입니다. 먼 길 찾기(주소)는 IP가, 문 앞 배달은 MAC이, 받을 프로그램 구분은 포트가 맡습니다. 덕분에 와이파이를 유선으로 바꿔도 위 계층은 그대로 동작하고, 문제가 생기면 층을 따라가며 원인을 좁힐 수 있습니다.
이 예제의 TCP/IP 메시지에는 세션(L5)·표현(L6)을 가리키는 독립 헤더가 없습니다. 인터넷 프로토콜 묶음은 응용 계층을 OSI처럼 세분하지 않기 때문에, 데모에서는 두 층을 흐리게 표시했습니다. 이것이 두 층의 역할 자체가 사라진다는 뜻은 아닙니다.
증상에서 확인할 층을 좁히기
계층 모델은 이름을 외우는 표보다 장애 범위를 나눌 때 더 유용합니다.
| 보이는 증상 | 먼저 확인할 곳 | 이유 |
|---|---|---|
| 와이파이 연결 자체가 끊김 | 링크·물리 계층 | 신호와 바로 옆 장비까지의 연결 문제 |
| IP 주소를 못 받음 | 링크·네트워크 계층 | 같은 망 연결과 주소 설정을 확인해야 함 |
| IP에는 닿지만 특정 포트만 거절 | 전송 계층과 서버 프로세스 | 목적지는 맞지만 받을 프로그램이 없을 수 있음 |
| 연결은 되지만 명령 형식 오류 | 응용 계층 | 바이트는 도착했고 프로그램의 규칙에서 거부됨 |
실제 장애가 반드시 한 층에만 머무는 것은 아닙니다. 예를 들어 DNS 이름이 안 풀리는 증상도 로컬 네트워크 단절 때문에 생길 수 있습니다. 아래층부터 연결 여부를 확인한 뒤 위층으로 올라가면 같은 설정을 반복해서 뒤지는 일을 줄일 수 있습니다.
봉투가 붙었다 벗겨지는 걸 따라가 보세요
아래 파란 버튼만 누르세요
내용에 주소표를 붙여 보내는 5장면
- 1내용 준비
- 2주소 포장
- 3신호 전송
- 4포장 열기
- 5내용 도착
아래 ‘포장 시작’을 누르면 복잡한 네트워크 과정을 다섯 장면으로 보여드려요.
이유 세 가지만
계층을 나눠 놓은 이유
먼 길 찾기는 IP 주소가, 문 앞 배달은 MAC 주소가, 프로그램 구분은 포트가 맡아요.
와이파이를 유선으로 바꿔도(L1·L2) 그 위의 IP·TCP·프로그램은 그대로 동작해요.
선이 빠졌는지, 주소가 틀렸는지, 프로그램이 죽었는지 층을 따라가며 찾을 수 있어요.
데모만 따로 보려면 전체 화면으로 열기.
타이핑할 필요가 없습니다.
- 보낼 명령을 고르고 포장 시작을 누릅니다.
- 화면 위의 다섯 장면만 따라갑니다: 내용 → 포장 → 전송 → 열기 → 도착.
- 포트·IP·MAC 같은 이름과 값이 궁금할 때만 기술 이름과 실제 값 보기를 펼칩니다.
한 장면씩 넘기기가 귀찮다면 자동 재생을 누르면 됩니다. 응답도 같은 과정을 반대로 한 번 더 거칩니다.
봉투값은 얼마나 될까
"헤더가 한 겹씩 붙는다"는 말은 곧 보내지도 않은 바이트를 회선에 흘린다는 뜻입니다. 얼마나 되는지 계산해 보면 이 구조의 대가가 보입니다.
이 글을 쓰는 노트북의 네트워크 카드를 확인하니 MTU가 1500이었습니다. 한 번에 실어 보낼 수 있는 IP 패킷의 최대 크기입니다. 표준 헤더 크기는 이렇습니다.
| 층 | 붙는 것 | 크기 |
|---|---|---|
| 전송(L4) | TCP 헤더 | 20바이트 |
| 인터넷(L3) | IP 헤더 | 20바이트 |
| 링크(L2) | 이더넷 헤더 + 검사값 | 14 + 4 = 18바이트 |
그래서 1500바이트짜리 IP 패킷에 실제로 담기는 내 데이터는
1500 − 20(IP) − 20(TCP) = 1460 바이트1460바이트입니다. 이 값이 TCP의 MSS로 자주 등장하는 그 숫자입니다.
작게 보낼수록 손해가 커집니다
여기서 중요한 게 나옵니다. 봉투 크기는 내용물과 상관없이 거의 고정입니다. 그래서 조금만 보낼수록 비율이 나빠집니다.
| 보내려는 데이터 | 붙는 헤더 | 회선에 실제로 나가는 양 | 헤더 비중 |
|---|---|---|---|
| 1,460바이트(가득) | 58바이트 | 1,518바이트 | 3.8% |
| 100바이트 | 58바이트 | 158바이트 | 37% |
5바이트(hello) | 58바이트 | 63바이트 | 92% |
마지막 줄을 보세요. hello 다섯 글자를 보내는 데 63바이트가 나갑니다.
내용은 8%뿐이고 나머지는 전부 봉투입니다.
이게 실무에서 왜 중요하냐면, 작은 요청을 자주 보내는 프로그램은 데이터가 아니라 봉투로 회선을 쓰기 때문입니다. 여러 값을 한 번에 묶어 보내라는 조언, 연결을 재사용하라는 조언이 전부 이 표에서 나옵니다.
데모에서 짧은 명령 하나가 층을 내려가며 점점 두꺼워지는 장면이 바로 이 계산입니다. 마지막 줄에서 껍데기가 알맹이보다 훨씬 커지는 것을 확인해 보세요.
세 주소가 각각 가리키는 것
내려갈 때 헤더가 한 겹씩 붙고(캡슐화), 받는 쪽에서 한 겹씩 벗겨집니다(역캡슐화). 그 봉투에 적히는 세 주소는 서로 다른 것을 가리킵니다. 이 구분 하나만 잡아 두면 다음 편들이 훨씬 수월합니다.
| 주소 | 가리키는 것 | 바뀌는 시점 |
|---|---|---|
| 포트 | 그 컴퓨터 안의 프로그램 | 끝까지 그대로 |
| IP | 최종 목적지 컴퓨터 | 끝까지 그대로 |
| MAC | 바로 다음 장비 | 홉을 넘을 때마다 |
일부러 뺀 것
TLS 암호화, 3-way handshake, 라우팅 경로 선택, 패킷 손실과 재전송은 이번 데모에서 다루지 않습니다. 처음 보는 사람도 캡슐화 하나만 확실히 이해할 수 있도록 뺐습니다.
데모의 TCP 헤더에 있던 "순서 번호"가 어디서 시작되는지 궁금하다면, 연결이 만들어지는 순간을 다루는 TCP 3-way handshake 랩에서 이어서 눌러볼 수 있습니다. IP 헤더의 목적 IP와 TTL이 실제로 어떻게 쓰이는지는 라우팅 랩에서 지도 위에 펼쳐 보여드립니다.
실제 패킷 캡처가 아닙니다
데모는 TCP·IP·이더넷 규격의 헤더 구성을 따라 만든 시뮬레이션입니다. 순서 번호나 체크섬 같은 계산 필드는 고정 예시값이고, IP·MAC 주소도 사설 대역의 예시값입니다. 실제 패킷이 궁금하다면 Wireshark 같은 캡처 도구로 확인할 수 있습니다.