OSI 7계층과 TCP/IP 4계층 정리: 네트워크 통신을 비유로 이해하기

요즘의 네트워크는 전 세계에 분산된 수많은 컴퓨팅 장치들이 거미줄처럼 얽혀 있는 거대한 분산 시스템이다. 사용자가 웹 브라우저를 열어 Google에 검색을하거나 미디어 파일을 전송할 때 등의 상황에서 복잡하고 정교한 네트워크 처리 작업이 계속 일어난다. 이처럼 거대한 글로벌 네트워크가 혼란 없이 정확하게 데이터를 송수신할 수 있는 근본적인 이유는, 전 세계의 하드웨어 제조사와 소프트웨어 개발자들이 철저하게 합의하고 준수하는 견고한 '통신 표준과 아키텍처 모델'이 존재하기 때문이다.

컴퓨터와 컴퓨터가 대화하는 통신 과정은 본질적으로 물리적 매체(구리선, 광케이블, 무선 전파)를 타고 흐르는 전기적 혹은 광학적 신호의 이동에 불과하다. 그런데 이런 물리적 계층의 아날로그 신호가 논리적인 디지털 데이터로 변환되고, 최종적으로 운영체제와 애플리케이션을 거쳐 사용자가 이해할 수 있는 정보로 화면에 출력되기까지는 수많은 데이터의 변환, 압축, 암호화, 라우팅, 그리고 흐름 제어 단계가 요구된다. 이 복잡한 일련의 과정을 논리적으로 체계화하고 모듈화하여 설명하는 핵심 이론이 바로 'OSI 7 Layer'와 'TCP/IP 4계층' 모델이다.

이번 포스팅에선 현대 네트워크 설계의 근간을 이루는 이 두 가지 모델의 철학적 배경과 실무적 차이를 깊이 있게 분석해보려고 한다. 단순 이론 뿐만아니라 원리 이해부터 최종적으로는 큰 용량의 실제 파일이 전송되는 구체적인 시나리오를 통해 이해해보려고 한다.

1. 네트워크 모델의 두 축: 개념(Ideal)과 실체(Real)

네트워크 아키텍처의 구조를 명확히 이해하기 위한 첫걸음은 현재 정보통신 분야에서 지배적으로 사용되는 두 가지 모델 간의 상관관계를 파악하는 것이다. 많이 들어봤을 법한 통신 시스템의 이상적인 설계를 설명하는 이론적 구조인 OSI 7 Layer와, 실제 전 세계 인터넷 인프라를 실질적으로 구동하는 구현체인 TCP/IP 4계층이 있다. 이 두 모델은 상호 보완적인 성격을 지니며, '개념(Ideal)'과 '실체(Real)'라는 명확한 대응 관계를 맺고 있다.

네트워크를 공부하다 보면 종종 이런 말을 듣게 된다.

“OSI 7계층은 이론이고, 실전에서는 TCP/IP 4계층을 봐야 한다.”

이 말은 두 모델의 역할 차이에서 나온다. AI에게 비유를 부탁해보았는데 직관적인 이유인듯 해서 이 관계는 요리 레시피와 실제 요리 과정에 비유하면 이해하기 쉽다.

요리 레시피에는 재료 준비, 손질, 조리, 플레이팅처럼 단계가 체계적으로 나뉘어 있다. 하지만 실제 주방에서 요리를 할 때는 이러한 단계가 정확히 나뉘어 진행되기보다는 상황에 따라 동시에 이루어지거나 일부 과정이 합쳐지기도 한다.

네트워크에서 OSI Model은 이런 레시피와 같은 개념적 모델이다. 네트워크 통신이 어떤 기능 단위로 나뉘어 동작해야 하는지를 이상적으로 설명하기 위해 만들어졌다. 반면 실제 인터넷에서 동작하는 구조는 TCP/IP Model이다. 이는 레시피를 참고해 실제로 요리를 만드는 과정처럼, 현실적인 환경에 맞게 단순화된 구조로 구현되어 있다.

그래서 대부분의 네트워크 교재에서는 네트워크 통신의 실제 동작을 설명할 때 OSI 모델보다는 TCP/IP 4계층 모델을 중심으로 설명하는 경우가 많다. 결국 OSI 모델은 네트워크를 이해하기 위한 레시피이고, TCP/IP 모델은 실제 인터넷을 움직이는 요리 과정이라고 볼 수 있다.

이론적 레퍼런스, OSI 7 Layer

OSI 7 Layer는 네트워크 통신 과정을 7개의 계층으로 나누어 설명하는 개념적 표준 모델이다. 핵심 목적은 복잡한 통신 과정을 역할별로 분리해, 각 계층이 자신에게 할당된 기능만 수행하도록 만드는 데 있다.

이처럼 계층을 나누는 이유는 모듈화와 관심사의 분리때문이다. 하나의 거대한 통신 시스템을 단일 구조로 다루면, 특정 기술의 변화나 문제 하나가 전체 시스템에 영향을 줄 수 있다. 반면 계층 구조로 분리하면 각 계층은 독립적인 역할을 수행하고, 상하위 계층과는 정해진 방식으로만 상호작용하게 된다.

이 구조는 네트워크를 설계하고 이해하는 데 큰 장점을 준다. 예를 들어 물리적인 전송 매체가 바뀌더라도, 그 영향은 주로 하위 계층에 머물고 상위 계층의 동작 원리 자체는 유지된다. 또한 장애가 발생했을 때도 물리 계층부터 응용 계층까지 단계적으로 확인하면서 문제를 좁혀갈 수 있다. 즉, OSI 모델은 네트워크 통신을 체계적으로 설명하고, 구조적으로 분석하기 위한 기준 틀이라고 볼 수 있다.

정리하면 OSI 7 Layer는 실제 인터넷을 그대로 구현한 모델이라기보다는, 네트워크를 이해하고 설명하고 진단하기 위한 이론적 레퍼런스에 가깝다.

현대 인터넷의 실질적 분리, TCP/IP 4계층

실제 인터넷과 운영체제의 네트워크 스택은 OSI 7계층이 아니라 TCP/IP 모델을 기반으로 동작한다. 따라서 개발자와 인프라 엔지니어가 실무에서 네트워크를 다룰 때는 TCP/IP 4계층 관점이 훨씬 직접적이고 현실적이다.

TCP/IP 4계층은 OSI 7계층의 기능을 실무적으로 재구성한 모델이다. OSI가 통신 과정을 세밀하게 7단계로 나눈 반면, TCP/IP는 실제 구현과 운용에 맞게 이를 4개 계층으로 통합해 다룬다. 이 때문에 이론 학습에서는 OSI가 설명에 유리하고, 실제 통신 흐름을 이해하거나 네트워크 프로그래밍을 할 때는 TCP/IP가 더 자연스럽게 사용된다.

OSI 모델에서는 세션 계층과 표현 계층이 별도로 존재하지만, 현대 시스템에서는 이 기능들이 독립된 계층으로 분리되어 운영체제에 제공되기보다는 응용 프로그램이나 라이브러리 수준에서 처리되는 경우가 많다. 예를 들어 세션 관리나 암호화 (OSI- L5), 데이터 직렬화(OSI- L6),같은 기능은 애플리케이션(OSI-L7)이 직접 구현하거나 외부 라이브러리를 통해 처리하는 것이 일반적이다. (그래서 TCP/IP 모델은 L5,L6,L7을 애플리케이션 계층으로 통일해둠)

결국 TCP/IP 모델이 실무에서 중심이 되는 이유는 단순하다. 현대 인터넷이 실제로 이 구조 위에서 동작하기 때문이다. 그래서 네트워크를 설명할 때는 OSI의 언어를 활용해 큰 그림을 잡고, 실제 구현과 운영, 트러블슈팅에서는 TCP/IP의 관점으로 접근하는 방식이 가장 자연스럽다.

2. 애플리케이션에서 하드웨어까지: 통신의 연결고리와 작동 원리

네트워크 통신의 본질적인 목적은 단 하나로 생각한다. 바로 "내가 생성한 데이터를, 수많은 라우터와 스위치가 얽힌 광활한 네트워크망을 통과하여, 지구 반대편?이나 어쨋든 보내고자 하는 정확한 목적지의 올바른 프로그램에 온전히 전달하는 것"이다. 이 목적을 성공시키기 위해 네트워크 모델의 각 계층은 자신만의 고유한 식별자(Identifier) 체계를 운영한다. 네트워크 식별자의 체계는 현실 세계의 글로벌 물류 및 택배 배송 시스템과 매우 유사한 논리를 갖는다.

택배 기사가 물건을 배송하기 위해서는 국가를 찾고, 도시를 찾고, 도로명 주소를 따라 특정 아파트 건물에 도착한 뒤, 정확한 동호수를 찾아가 최종 수령인에게 물건을 전달해야 한다. 이와 마찬가지로 데이터 패킷 역시 네트워크 인프라를 통과하며 점진적이고 세밀한 주소 탐색 과정을 거치게 된다.

택배 이야기는 3번 캡슐화에서 종일 다룰것이니 넘어가고 우선, TCP/IP 4계층에서 각각 사용하는 식별자에 대해 자세히 알고 있다는 가정하게 진행하겠다. 한 줄로 정리하자면 아래와 같다.

L2의 식별자 : MAC 주소 (하드웨어/NIC 식별자) - 물리적인 주소이다.
L3의 식별자: IP 주소 (호스트/PC 식별자) - 논리적인 주소이다.
L4의 식별자: Port 번호 (프로세스 식별자) - 프로세스(어떤 APP인지) 식별자이다.

User Mode와 Kernel Mode, 그리고 하드웨어(H/W)

<이미지 출처 : witestalb.poly.edu/blog/tcp-ip-protocol-stack>

운영체제(OS)는 시스템의 핵심 자원을 보호하고 안정성을 유지하기 위해 권한 수준을 유저 모드(User Mode)와 커널 모드(Kernel Mode)로 엄격히 분리하여 운영한다. (TMI로 UDP,TCP는 운영체제 깊은곳에 하드코딩 되어있어서 전세계에 퍼져있는 OS들의 호환성을 위해 수정할 수 없다. HTTP3.0이 UDP기반으로 개발된것은 TCP코드를 수정할 수 없어서 UDP위에 QUIC라는 TCP처럼동작하는 프로토콜을 별도로 정의해 사용하는것이다.)

L7 (Application Layer): 유저 공간(User Space)에서의 동작

사용자가 직접 실행하고 다루는 크롬 웹 브라우저, 게임 클라이언트, 혹은 백엔드 서버에서 구동되는 Nginx, Apache와 같은 웹 서버 애플리케이션은 모두 낮은 권한을 가진 유저 모드에서 동작한다. 유저 모드의 프로세스는 PC의 네트워크 인터페이스 등 하드웨어 자원에 직접 접근할 권한이 완전 차단되어 있다. 따라서 애플리케이션이 네트워크를 통해 데이터를 외부로 보내거나 수신하려면, 반드시 운영체제에게 권한을 위임해 달라고 요청하는 '시스템 콜(System Call)'을 발생시켜야 한다.

L3 ~ L4 (Network & Transport Layer): 커널 영역(Kernel Space)에서의 처리

IP 주소를 해석하여 라우팅 경로를 판단하는 로직(L3)과, 데이터의 순서를 보장하고 손실을 복구하며 Port 번호를 통해 프로세스를 식별하는 TCP/UDP 로직(L4)은 모두 운영체제의 심장부인 커널 영역(TCP/IP Stack)에 소프트웨어 형태로 구현되어 있다. 유저 영역의 애플리케이션이 생성한 데이터는 시스템 콜을 통해 커널 영역으로 넘어가며, 커널 내부의 네트워크 스택을 거치면서 캡슐화 과정을 겪는다.

이런 복잡한 기능을 커널이 중앙 집중적으로 전담하는 이유는 명확하다. 만약 사용자 애플리케이션이 직접 IP 주소를 조작하거나 TCP 패킷을 만들 수 있다면, 악의적인 프로그램이 시스템의 IP를 마음대로 변조하여 치명적인 해킹 공격을 감행하거나 네트워크 자원을 독점하여 시스템을 마비시킬 수 있기 때문이다. 운영체제는 커널을 통해 다수의 프로세스가 제한된 네트워크 자원을 안전하게 공유(Multiplexing)할 수 있도록 중재한다.

L1 ~ L2 (Physical & Data Link Layer): 하드웨어 영역(Hardware / NIC)

최종적으로 캡슐화가 완료된 패킷이 커널을 벗어나면(3. 캡슐화에서 자세히 다루자), 하드웨어 영역으로 진입한다. 목적지 MAC 주소를 확인하고, 에러를 검출하는 프레임 체크 시퀀스(FCS)를 덧붙이며, 디지털 데이터를 아날로그인 전기적/광학적 신호로 변환하여 케이블로 흘려보내는 물리적 계층의 작업은 컴퓨터의 메인보드나 슬롯에 장착된 하드웨어인 네트워크 인터페이스 카드(NIC)와 그 내부에서 독립적으로 처리된다. 하드웨어 계층은 소프트웨어의 처리 속도 한계를 극복하고 네트워크 망의 극도의 전송 속도를 맞추기 위해, 규격화된 작업을 칩셋 레벨에서 병렬로 고속 처리한다.

데이터가 물리적인 랜 케이블을 타고 하드웨어(NIC)를 거쳐, 운영체제 커널의 엄격한 검증을 통과해 TCP/IP 스택까지 무사히 도착했다면 가장 어려운 물리적 전송은 끝난 셈이다.

그러나 아직 마지막 과제가 남아있다. 커널의 메모리 공간에 쌓인 이 데이터를, 유저 공간에서 기다리고 있는 수많은 애플리케이션 중 정확한 주인을 찾아 넘겨주는 것이다. 이 애플리케이션과 네트워크 인프라 사이의 최종 연결고리 역할을 완벽하게 수행하는 추상적 개념이 바로 Port 번호와 소켓(Socket)이다.

Port 번호: 내 컴퓨터 안의 수많은 프로그램 중 누구?

<이미지 출처 : coding-factory.tistory.com/1002>

Port 번호는 16비트(2바이트) 정수로 구성된 프로세스 식별자다. IP 주소가 수신측 호스트인 '아파트 건물 전체'를 지정한다면, Port 번호는 그 호스트 내에서 특정 네트워크 서비스를 구동하고 대기 중인 프로세스, 즉 '아파트의 특정 동호수'를 가리킨다. 운영체제는 이 16비트의 Port 번호 공간을 무질서하게 사용하지 않고, 그 역할과 목적에 따라 크게 세 가지 구간으로 나누어 엄격하게 관리한다.

잘 알려진 포트 (0 ~ 1023): 국제 기관에서 특정 범용 서비스용으로 엄격하게 예약해 둔 번호다. 전 세계 어떤 컴퓨터든 HTTP 기반의 웹 서버는 80번, HTTPS 기반의 암호화 웹 서버는 443번, 파일 전송을 위한 FTP 서버는 21번, 도메인 네임 해석을 위한 DNS는 53번 포트를 사용하도록 표준화되어 있다. 이 구간의 포트를 열기 위해서는 운영체제의 관리자(Root) 권한이 필수적이다.
등록된 포트 (1024 ~ 49151): 벤더나 특정 소프트웨어 애플리케이션들이 자신들의 서비스를 위해 등록하여 사용하는 포트다. 데이터베이스인 MySQL이 3306번을, 톰캣(Tomcat) WAS 서버가 8080번을 기본적으로 사용하는 것이 대표적인 예다.
동적/사설 포트 (49152 ~ 65535): 서버가 아닌 클라이언트(예: 사용자의 웹 브라우저)가 서버에 접속을 시도할 때, 데이터를 되돌려 받기 위해 운영체제의 커널에 의해 임시로 무작위 자동 할당되는 포트 구간이다. 통신 세션이 종료되면 해당 포트 번호는 즉시 반환되어 다른 프로세스가 재사용할 수 있게 된다.

서버의 랜카드를 통해 데이터가 수신되면, 커널 내부의 TCP/IP 스택은 수신된 데이터 덩어리(세그먼트)의 헤더 부분을 뜯어 목적지 Port 번호를 확인한다.

만약 확인된 목적지 Port가 80번이라면, 커널은 "이 데이터는 현재 80번 포트를 점유하고 소켓을 열어둔 채 대기 중인 Nginx 웹 서버 프로세스가 처리해야 할 데이터다"라고 정확히 판단한다. 이처럼 하나의 IP 주소라는 단일한 파이프라인으로 수신된 막대한 양의 데이터를 여러 애플리케이션으로 안전하고 정확하게 분배하는 과정을 네트워크 용어로 '역다중화(Demultiplexing)'라고 하며, 여러 애플리케이션의 데이터를 모아 하나의 IP로 송출하는 것을 '다중화(Multiplexing)'라고 부른다.

네트워크 통로 : 소켓(Socket)

<이미지 출처 : blog.skby.net/소켓-socket/>

Port 번호가 외부에서 내부 프로세스를 찾아오기 위한 논리적인 식별표라면, 소켓(Socket)은 그 식별표를 기반으로 커널 스택과 애플리케이션이 실질적으로 데이터를 밀어 넣고 빼오는 '통로'이자 프로그래밍 언어 레벨에서 제공되는 '추상화된 인터페이스'다.

응용 계층(L7)에서 동작하는 애플리케이션을 개발하는 소프트웨어 엔지니어는 커널 내부에서 패킷이 어떻게 조각나고, IP 주소가 어떤 라우팅 알고리즘을 거쳐 찾아가는지 등의 그 하위 계층의 복잡한 구현 세부 사항을 알 필요가 없다. 개발자는 그저 운영체제가 제공하는 표준 네트워크 API를 호출하여 '소켓'을 생성하고, 그 소켓이라는 문(Door)을 통해 데이터를 밀어 넣거나 꺼내오기만 하면 된다. 소켓이 네트워크의 복잡성을 완벽하게 은닉해 주기 때문이다.

소켓의 가장 중요한 특징은 유닉스의 "모든 것은 파일이다"라는 철학을 네트워크 통신에도 그대로 적용했다는 점이다. 하드 디스크의 파일을 다룰 때 운영체제는 파일 디스크립터라는 번호를 주고, 개발자는 read(), write(), close() 같은 함수를 통해 파일을 읽고 쓴다.

네트워크 소켓도 운영체제 입장에서는 이와 비슷한 '특별한 파일'이다. 개발자가 socket()을 호출하면 운영체제는 네트워크 통신용 파일 디스크립터를 하나 만들어 준다. 이후 애플리케이션은 그 소켓에 send()나 write()로 데이터를 보내고, recv()나 read()로 데이터를 받는다. 즉, 개발자는 복잡한 TCP/IP 내부 동작을 직접 다루지 않고도, 파일을 입출력하듯 네트워크 통신을 처리할 수 있다. (소켓도 파일이니 네트워크 과정을 File I/O로 처리한다)

결국 소켓은 유저 영역의 애플리케이션이 커널의 TCP/IP 스택과 연결되는 입출력 창구라고 볼 수 있다. 그리고 각각의 소켓은 출발지/목적지 IP, 출발지/목적지 Port, 프로토콜(TCP/UDP) 정보를 조합한 5-Tuple로 구분되며, 이를 통해 두 프로세스 사이의 통신 세션이 식별된다.

3. 캡슐화와 데이터 단위(PDU)의 변화

유저 영역의 애플리케이션이 소켓을 통해 통신 데이터를 커널로 밀어 넣으면, 데이터는 네트워크 모델의 하위 계층을 차례대로 통과하며 전송에 가장 적합하고 안전한 형태로 지속적으로 가공된다. 이 과정에서 각 계층이 자신의 역할을 수행하기 위해 필요한 제어 정보(식별자, 오류 검출 코드, 통신 옵션 등)가 데이터의 앞부분인 헤더(Header)에 덧붙여지게 되는데, 이러한 포장 과정을 기술 용어로 **캡슐화(Encapsulation)**라고 한다.

마트에서 물건을 사면 비닐에 담고, 택배를 보내기 위해 종이 상자에 넣은 뒤, 취급 주의 스티커를 붙이는 포장 과정과 완벽히 일치한다. 캡슐화 과정을 거칠 때마다 데이터의 구조적 형태와 성격이 변하기 때문에, 네트워크 엔지니어들은 각 계층에서 다루는 데이터의 단위를 명확히 구분하여 부르는데 이를 프로토콜 데이터 단위(PDU, Protocol Data Unit)라고 부른다.

Stream(L7) -> Segment(L4) -> Packet(L3) -> Frame(L2)

이론적으로 보면 캡슐화는 각 계층이 자신의 제어 정보를 덧붙이며 데이터를 아래로 넘기는 과정이다. 하지만 이 설명만으로는 다소 어렵게? 느껴질 수 있다. 그래서 나는 공부할때 “20페이지로 구성된 소설 1화를 독자에게 배송하는 과정”이라고 생각했었다. 여기서 주의할 점은, 실제 소설 한 페이지가 곧 세그먼트 하나라는 뜻은 아니고, 이해를 돕기 위해 전송 단위를 페이지처럼 비유하는 것이다.

L7 (응용 계층) - Data / Message / Stream:

사용자 애플리케이션(ex: 브라우저)에서 생성된 순수한 원본 데이터의 상태다. TCP 소켓 통신을 사용할 경우 데이터는 시작과 끝의 명확한 경계가 없는 연속된 바이트의 흐름이므로 이를 '스트림(Stream)'이라고 부른다.

먼저 응용 계층(L7)에서는 웹소설 서버가 사용자가 요청한 소설 1화 전체 원고를 준비한다. 이 시점의 데이터는 아직 네트워크 전송용 포장이나 주소가 전혀 붙지 않은 순수한 콘텐츠일 뿐이다. 즉, 작가가 완성한 20페이지짜리 원고 뭉치를 책상 위에 올려둔 상태와 같다.

L4 (전송 계층) - Segment (세그먼트):

응용 계층의 거대한 스트림 데이터가 소켓을 통해 커널의 TCP 스택으로 내려오면, 네트워크 상태에 맞춰 신뢰성 있는 전송을 보장하기 위해 데이터를 적절한 크기의 덩어리로 분할한다. 이렇게 분할된 데이터 블록의 맨 앞에 출발지 Port 번호, 목적지 Port 번호등이 포함된 20바이트 크기의 'TCP 헤더'가 덧붙여진다. 이처럼 TCP 헤더가 결합된 상태의 데이터 단위를 세그먼트(Segment)라고 부른다. (만약 신뢰성보다 속도를 중시하는 UDP 프로토콜을 사용한다면 헤더의 구성이 달라지며, 이때는 데이터그램(Datagram)이라고 부른다 ).

방대한 20페이지 분량의 소설을 순서대로 나누고 전달하기 위해 몇 장씩 나누는 과정이다. 그리고 각 페이지 앞에는 “이것은 몇 번째 페이지(조각)인지” 등의 정보가 붙는다. 예를 들어 “이 조각은 1페이지”, “최종 목적지는 80번 포트(아파트 호수)”와 같은 정보가 기록되는 셈이다. 이렇게 데이터 조각에 TCP 헤더가 붙은 상태가 세그먼트(Segment)다.

L3 (네트워크 계층) - Packet (패킷):

완성된 세그먼트는 다시 하위 계층인 IP 스택으로 전달된다. IP 스택은 거대한 네트워크망에서 길을 찾기 위해 출발지의 IP 주소, 목적지의 IP 주소, TTL(생존주기) 등이 포함된 20바이트 크기의 'IP 헤더'를 세그먼트 앞에 추가로 결합한다. IP 헤더까지 씌워진 이 상태의 데이터를 네트워크의 기본 라우팅 단위인 패킷(Packet)이라 부른다.

페이지별로 조각난 원고 묶음을 그냥 보내는 것이 아니라 받는 사람의 집 주소와 보내는 사람 주소가 적힌 택배송장(IP 헤더)을 붙여 상자에 담는 과정이다. 순서표가 붙은 소설 페이지들을 목적지 주소가 적힌 택배상자에 넣은 상태가 패킷(Packet)이라고 한다.

L2 (데이터 링크 계층) - Frame (프레임):

패킷이 운영체제 커널의 소프트웨어 영역을 완전히 빠져나와 물리적 하드웨어인 네트워크 인터페이스 카드(NIC)로 전달되면, 인접한 노드 간의 물리적인 전송을 준비한다. NIC는 목적지와 출발지의 물리적 주소를 담은 'MAC 헤더'를 패킷의 가장 앞에 붙인다. 데이터 링크 계층의 독특한 점은 헤더뿐만 아니라, 전송 중 케이블 노이즈 등으로 인해 발생할 수 있는 물리적 데이터 변조 오류를 검출하기 위해 패킷의 가장 끝단에 'FCS(Frame Check Sequence) 트레일러'를 추가한다는 것이다. 이처럼 앞뒤로 헤더와 트레일러가 모두 덧붙여져 데이터가 완전히 밀봉된 상태를 프레임(Frame)이라 부른다.

최종 목적지까지 한 번에 가는 것이 아니라 바로 다음 전달 지점까지 안전하게 옮기기 위한 포장이 이루어진다. 택배 시스템으로 비유하면, 상자 자체에는 최종 배송지 주소가 적혀 있지만, 실제 이동은 현재 물류센터에서 다음 허브, 다음 배송 차량으로 넘겨지는 식으로 진행된다. 이때 필요한 것은 “지금 당장 어느 허브로 보낼 것인가”에 대한 정보인데, 네트워크에서는 이것이 MAC 주소다.

이해를 돕기위해 MAC주소에 대한 추가 예시를 준비해보았다.

위 이미지는 내가 택배를 시키고 배송조회를 한 과정의 일부이다. 여기서 연제 hub, 곤지함 hub등을 Host들의 MAC주소라고 볼 수 있다. 내가 서버에 요청을 보낼 때 다이렉트로 서버 PC로 이동하지 않는다. 라우팅 테이블을 통해 다음 목적지를 정하고, (극단적으로 패킷이 내PC에서 공유기로 이동한다고 생각하면 쉽다) 이 과정을 반복해서 최종 목적지 MAC주소를 조회한다.

이렇게 만들어진 프레임은 다시 0과 1의 신호로 유선 혹은 무선으로 물리적 신호로 바뀌어 전송된다. 이흐름은 비트 스트림이라고 한다.

이처럼 캡슐화 과정은 계층을 한 단계씩 내려갈 때마다 데이터에 프로토콜의 특성을 담은 두꺼운 '포장'을 겹겹이 입히는 것에 비유할 수 있다. 반대로 수신측 컴퓨터에서는 케이블을 통해 들어온 신호를 바탕으로 이와 정확히 반대되는 순서로 하위 계층에서 상위 계층으로 올라간다. MAC 헤더를 벗기고, IP 헤더를 벗기고, TCP 헤더를 분석하여 제거하는 역캡슐화(Decapsulation) 과정(택배 언박싱과정)을 반복하며 최종적으로 원본 데이터를 응용 프로그램으로 복원해 낸다.

데이터를 쪼개는 기준: MTU와 MSS

앞선 전송 계층의 캡슐화 과정 설명을 보면, 응용 계층의 거대한 데이터(예: 2MB 용량의 동영상 파일)가 커널로 내려올 때 "적절한 크기로 분할된다"고 언급했다. 네트워크 통신은 물리적인 케이블 대역폭의 한계와 각 라우터 스위치 장비들의 메모리 버퍼 한계로 인해 무한히 큰 데이터를 한 번에 통째로 전송할 수 없도록 설계되어 있다. 반드시 시스템이 수용 가능한 정해진 규격에 맞춰 데이터를 잘게 쪼개어 보내야 하는데, 이 분할의 절대적인 기준이 되는 두 가지 핵심 지표가 바로 MTU와 MSS다.

MTU (최대 전송 단위):
MTU는 네트워크 장비(특히 데이터 링크 계층인 L2 수준)가 하드웨어적으로 한 번에 끊기지 않고 전송할 수 있는 패킷의 최대 크기를 의미한다. 전 세계 로컬 네트워크의 지배적인 표준인 이더넷(Ethernet) 환경에서 MTU의 기본값은 암묵적인 룰로 1500 바이트(bytes)로 고정되어 있다. 이는 L3의 IP 헤더, L4의 TCP 헤더, 페이로드 데이터를 모두 합친 전체 덩어리의 크기가 절대로 1500 바이트를 넘어서는 안 된다는 물리망의 절대적 제약 사항이다.
MSS (최대 세그먼트 크기): MTU가 네트워크 하위 계층이 감당할 수 있는 '전체 상자'의 크기라면, MSS는 순수하게 애플리케이션이 생성한 '원본 데이터(Payload)'가 한 번의 TCP 세그먼트 안에 실릴 수 있는 최대 알맹이 크기를 말한다. MSS는 L4 전송 계층에서 데이터를 얼마나 쪼갤지 결정하는 기준이 되며, 하단의 MTU 값을 기준으로 역산하여 수학적으로 결정된다.
- 물리망의 최대 한계인 MTU = 1500 bytes
- 기본적인 IP 헤더의 크기 = 20 bytes
- 기본적인 TCP 헤더의 크기 = 20 bytes
- 따라서 남는 공간, MSS = 1500 - 20 - 20 = 1460 bytes가 된다.

결과적으로, 전송 계층에 위치한 TCP 스택은 유저 영역으로부터 2MB 크기의 파일 스트림이 소켓을 통해 마구마구 쏟아져 내려오면, 이 거대한 데이터를 무조건 1460 바이트 이하의 덩어리(MSS) 단위로 철저하게 토막 낸다. 토막을 낸 뒤에야 비로소 각각의 조각에 20바이트짜리 TCP 헤더를 붙여 세그먼트로 만들기 시작한다.

추가로 아래 이미지가 캡슐화와 역캡슐화 과정의 핵심을 잘 표현했다고 생각해서 가져와봤다.

<이미지 출처 : https://jerecord.tistory.com/139>

reference

image made by gemini nano banana2

https://jerecord.tistory.com/139

https://soeun2537.tistory.com/16

https://insengnewbie.tistory.com/334

https://innovation123.tistory.com/251

https://www.nossi.dev/06936fc0-eb03-4a53-8e4f-2e5dc71508dd