LLM 시대에도 변하지 않는 기초: Engineer가 TCP/IP와 HTTP를 알아야 하는 진짜 이유 2편 - TCP/IP 4 Layer vs OSI 7 Layer

LLM 기반 서비스가 보편화된 환경에서도 네트워크는 여전히 그 토대에 있습니다. 우리는 HTTP API를 호출하고, 스트리밍 응답을 받고, 지연 시간을 측정합니다. 그러나 이러한 현상이 어느 계층에서 발생하는 문제인지 명확히 설명하기는 쉽지 않습니다.

 

OSI 7 Layer와 TCP/IP 4 Layer는 네트워크를 이해하기 위한 대표적인 모델입니다. 두 모델은 종종 비교되지만, 실제로는 목적과 출발점이 다릅니다. 이 글에서는 이론적 참조 모델과 실제 구현 모델의 차이를 정리하고, 소프트웨어 엔지니어가 어디까지 이해하면 좋을지 제 경험을 바탕으로 정리해보고자 합니다.

 

---

 

OSI 7 Layer

 

OSI 모델은 International Organization for Standardization에서 정의한 참조 모델입니다. 구체적인 정의는 ISO/IEC 7498-1 문서에 담겨 있습니다.

 

이 모델은 네트워크 통신을 7개의 계층으로 나눕니다. Physical, Data Link, Network, Transport, Session, Presentation, Application 계층입니다.

 

OSI 모델의 설계 의도는 기능 분리입니다. 각 계층은 명확한 책임을 가지며, 상위 계층은 하위 계층의 구현 세부사항을 알지 못해도 동작하도록 설계되었습니다.

 

Physical 계층은 비트 전송을 다룹니다. 전기적 신호, 광 신호 등 물리적 매체를 통한 데이터 전달이 이 계층의 관심사입니다. Data Link 계층은 프레임 단위 전송과 오류 검출을 담당합니다.

 

Network 계층은 논리적 주소 체계를 통해 패킷을 목적지까지 전달하는 역할을 합니다. Transport 계층은 종단 간 통신의 신뢰성, 흐름 제어, 오류 복구 등을 담당합니다.

 

Session과 Presentation 계층은 개념적으로 흥미로운 부분입니다. Session 계층은 세션 관리와 동기화를, Presentation 계층은 데이터 표현 형식 변환과 암호화를 담당한다고 정의됩니다.

 

Application 계층은 사용자 애플리케이션과 직접 상호작용하는 계층입니다.

 

OSI 모델은 네트워크를 분석하기 위한 개념적 틀로 설계되었습니다. 실제 프로토콜이 반드시 이 구조를 그대로 따르는 것은 아닙니다. 이 점을 이해하는 것이 중요하다고 생각합니다.

 

---

 

TCP/IP 4 Layer

 

TCP/IP 모델은 인터넷 프로토콜 스위트를 기반으로 형성된 구조입니다. 표준화는 Internet Engineering Task Force에서 이루어지며, 호스트 요구사항은 RFC 1122와 RFC 1123에 정의되어 있습니다.

 

TCP/IP 모델은 Network Access, Internet, Transport, Application의 네 계층으로 설명됩니다.

 

Network Access 계층은 OSI의 Physical과 Data Link 계층을 포괄합니다. 실제 네트워크 인터페이스와 프레임 전송이 이 계층에 포함됩니다.

 

Internet 계층은 IP 기반 패킷 전달을 담당합니다. 논리적 주소 체계와 라우팅이 이 영역에 속합니다.

 

Transport 계층은 TCP나 UDP를 통해 종단 간 통신을 제공합니다. 신뢰성, 혼잡 제어, 흐름 제어가 이 계층의 주요 책임입니다.

 

Application 계층은 HTTP, SMTP, DNS 등 상위 프로토콜을 포함합니다. OSI 모델에서 Session과 Presentation에 해당하는 기능도 대부분 Application 계층에 포함됩니다.

 

이 모델은 이론적 참조 모델이라기보다, 실제 인터넷 프로토콜의 구현 구조를 반영한 모델이라고 이해하고 있습니다. 운영체제의 네트워크 스택 역시 이 구조를 기반으로 구현됩니다.

 

---

 

왜 현실은 TCP/IP 모델을 따른다고 말하는가

 

인터넷에서 사용되는 주요 프로토콜은 RFC 체계를 통해 정의됩니다. 이 RFC들은 Internet Engineering Task Force를 중심으로 발전해왔습니다.

 

OSI 모델은 ISO 표준 문서에서 정의된 참조 모델입니다. 반면 TCP/IP는 실제 구현과 함께 진화해왔습니다. IP는 RFC 791에서, TCP는 RFC 793에서 정의되었으며, 이후 수많은 보완 문서가 추가되었습니다.

 

현실의 인터넷은 OSI 모델을 그대로 구현한 것이 아니라, RFC 기반 TCP/IP 프로토콜 스위트를 중심으로 발전해왔습니다. 이 때문에 “현실은 TCP/IP 모델을 따른다”는 표현이 사용되는 것 같습니다.

 

이는 우열의 문제라기보다 출발점의 차이로 이해하는 것이 자연스럽다고 생각합니다. OSI는 이상적인 계층 분리를 제시했고, TCP/IP는 실제 동작하는 네트워크를 만들어왔습니다.

 

---

 

계층을 모르면 발생하는 문제

 

계층 개념이 모호해질 때 혼란이 발생합니다. 예를 들어 TLS는 어느 계층에 속하는지 질문을 받곤 합니다. TLS 1.3은 RFC 8446에 정의되어 있습니다.

 

TLS는 전송 계층 위에서 동작하지만, 암호화된 세션을 형성하고 데이터 표현을 보호합니다. OSI 모델로 보면 Presentation 또는 Session 계층과 유사한 역할을 합니다. TCP/IP 모델에서는 일반적으로 Application 계층의 일부로 간주됩니다.

 

HTTP는 명확히 Application 계층 프로토콜입니다. 그러나 HTTPS는 TLS 위에서 동작하기 때문에 계층 경계가 겹쳐 보입니다.

 

WebSocket 역시 HTTP 핸드셰이크를 통해 연결을 시작하지만, 이후에는 별도의 프레임 구조로 양방향 통신을 수행합니다. 이 역시 Application 계층 프로토콜로 분류되지만, 전송 계층 특성에 강하게 의존합니다.

 

이처럼 계층을 단순 암기로 접근하면 실제 문제 상황에서 혼란이 발생합니다. 계층은 문제를 분석하기 위한 관점이라는 점을 이해하는 것이 도움이 됩니다.

 

---

 

LLM 시대에 필요한 계층별 이해 수준

 

LLM API 호출을 예로 들어보겠습니다. Application 계층에서는 HTTP streaming 구조를 이해해야 합니다. 토큰이 어떤 방식으로 전달되는지, 스트림이 어떻게 유지되는지 이해하면 체감 속도를 설명할 수 있습니다.

 

Transport 계층에서는 혼잡 제어와 재전송 메커니즘을 이해할 필요가 있습니다. 패킷 손실이 발생할 때 응답 지연이 왜 증가하는지 설명할 수 있어야 합니다.

 

Network 계층에서는 라우팅을 이해하는 것이 중요합니다. 요청이 어느 경로를 통해 전달되는지에 따라 지연 특성이 달라질 수 있습니다.

 

Link 계층에서는 MTU와 fragmentation을 이해하면 대용량 요청에서 발생하는 문제를 분석하는 데 도움이 됩니다. MTU를 초과하는 패킷은 분할되며, 이 과정에서 성능 저하가 발생할 수 있습니다.

 

모든 계층을 동일한 깊이로 이해할 필요는 없다고 생각합니다. 그러나 각 계층의 책임과 경계를 이해하는 것만으로도 문제 분석의 정확도는 크게 달라집니다.

 

---

 

마무리하며

 

OSI 7 Layer와 TCP/IP 4 Layer는 경쟁 관계라기보다 서로 다른 관점을 제공하는 모델입니다. 하나는 이상적인 기능 분리를 제시하고, 다른 하나는 실제 구현 구조를 반영합니다.

 

계층 모델은 시험을 위한 암기 대상이 아니라, 문제를 구조적으로 바라보기 위한 도구라고 생각합니다. LLM 시대에도 네트워크 계층 이해는 여전히 유효합니다.

 

이 글은 계층 모델을 다시 정리하며 기본기를 점검해본 기록입니다. 복잡한 시스템을 다룰수록 기초 모델을 다시 돌아보는 일이 의미 있다고 생각합니다.