왜 네트워크 프로토콜은 이렇게 나뉘었는가

현재 사용되고 있는 네트워크 프로토콜의 수는, 커스텀 프로토콜을 제외하더라도 약 300~500개 수준으로 알려져 있습니다.
이를 웹 영역으로 한정하더라도, 브라우저와 서버 간 통신을 중심으로 약 15~20개의 프로토콜이 실제로 사용되고 있습니다.
흥미로운 점은, 이 중에서도 웹의 핵심 동작을 책임지는 프로토콜은 8~10개 내외에 불과하다는 사실입니다.

여기서 자연스럽게 하나의 의문이 생깁니다. 왜 이렇게까지 많은 종류의 프로토콜이 필요했을까요?
단순히 신호를 보내고, 받고, 응답하는 방식만으로는 충분하지 않았을까요?

조금 더 근본적인 질문도 던져볼 수 있습니다. 프로토콜은 정말 "필요하니까" 즉흥적으로 만들어진 결과물일까요?
아니면, 각각의 프로토콜은 서로 다른 문제를 해결하기 위한 명확한 선택의 결과일까요?

이 질문에 답하기 위해서는, 프로토콜을 "통신 규칙의 나열"로 보는 관점에서 벗어나
네트워크가 어떤 문제를 안고 있었고, 각 프로토콜이 무엇을 포기하고 무엇을 선택했는지를 함께 살펴볼 필요가 있습니다.

이 글에서는 왜 하나의 범용 프로토콜이 모든 문제를 해결하지 못했는지,
그리고 TCP, UDP, QUIC처럼 서로 다른 프로토콜들이 대체가 아닌 공존의 형태로 남게 된 이유를 정리해보려 합니다.

왜 이렇게까지 많은 종류의 프로토콜이 필요했을까?

처음 네트워크를 배울 때는 이렇게 생각하기 쉽습니다. 데이터는 보내고, 받으면 끝나는 것 아닌가?
요청 하나, 응답 하나만 존재해도 충분하지 않을까?

실제로 초기 네트워크는 이런 단순한 모델로 시작했을지도 모릅니다. 아주 적은 수의 패킷이, 제한된 환경 안에서 오가는 상황이라면
서로 소통하는 방식은 하나의 약속만으로도 충분했을 것입니다.

만약 네트워크 세계에 단 두 개의 패킷만 존재한다면, 이 둘이 소통하는 방식은 하나면 충분합니다.
하지만 패킷의 수가 10개, 100개, 1000개로 늘어난다면 상황은 달라집니다. 모든 통신이 같은 목적과 같은 조건을 가질 수는 없습니다.
어떤 통신은 정확히 전달되는 것이 가장 중요하고, 어떤 통신은 빠르게 도착하는 것이 더 중요할 수 있으며,

또 어떤 통신은 가능한 한 많은 데이터를 처리하는 것이 목적일 수 있습니다.
여기에 더해, 전달해야 할 데이터의 성격 자체도 서로 다릅니다. 누군가는 파일을 전송하고,
누군가는 음성을 실시간으로 전달하며, 또 다른 누군가는 웹 문서를 요청합니다.
이쯤 되면 이런 생각이 들 수 있습니다. "이 모든 요구사항을 하나의 범용 프로토콜로 만들면 되지 않을까?"

이론적으로는 불가능한 이야기는 아닙니다. 하지만 현실에서 그렇게 설계된 범용 프로토콜은
수많은 조건 분기와 예외 처리를 포함할 수밖에 없습니다. 결과적으로 하나의 신호에는
자신에게는 필요하지 않은 정보들까지 함께 실려야 합니다.

이는 곧 헤더의 비대화, 처리 비용 증가, 성능 저하로 이어집니다. 즉, 범용성을 얻는 대신 효율성과 단순성을 잃게 됩니다.
이러한 이유로 네트워크는 하나의 만능 프로토콜을 선택하지 않았습니다.
대신, 각 통신이 무엇을 가장 중요하게 여기는지에 따라 서로 다른 약속을 가진 프로토콜들이 분화되는 방향을 선택했습니다.
그래서 오늘날 우리는 수백 개의 프로토콜이 공존하는 네트워크 환경을 마주하게 된 것입니다.

그렇다면,  어떤 프로토콜이 인기가 있을까?

위에서 프로토콜이 많은 이유에 대해 이야기를 해봤습니다. 하지만 모든 프로토콜을 알고 있는것은 생각보다 쉽지 않을겁니다. 
ByteByteGo에서는 8가지 네트워크를 소개하고 있습니다.
기본적으로 네트워크 프로토콜은 네트워크에서 두 시스템 간에 데이를 전송하는 핵심적인 역할을 합니다.

출처: https://blog.bytebytego.com/p/ep195-common-network-protocols-every

TCP(전송 제어 프로토콜)

TCP는 신뢰성 있는 데이터 전송을 책임지는 전송 계층 프로토콜입니다.
TCP가 해결하려 했던 핵심 요구사항은 단순합니다.

데이터를 보냈다면, 반드시 순서대로, 빠짐없이 전달되었음을 보장하는 것입니다.

이를 위해 TCP는 연결을 먼저 맺고, 데이터의 순서를 관리하며 유실된 데이터는 재전송하고 수신여부를 확인합니다.
즉, TCP의 목표는 속도보다는 정확성과 안정성입니다.

UDP(사용자 데이터그램 프로토콜)

UDP는 속도와 단순성을 우선시하는 전송 계층 프로토콜입니다.
UDP가 해결하려 했던 핵심 요구사항은 다음과 같습니다.

데이터를 최대한 빠르게 전달하는 것, 설령 일부 데이터가 유실되더라도 지연을 최소화하는 것입니다.

이를 위해 UDP는 연결을 맺지 않고 순서를 보장하지 않으며 재전송이나 수신 확인을 하지 않습니다.
즉, UDP의 목표는 정확성보다 지연을 줄이는 것입니다.

이러한 특성 때문에 UDP는 실시간 스트리밍, 음성 통화, 게임과 같이 속도가 중요한 통신에서 사용됩니다.

FTP(파일 전송 프로토콜)

FTP는 파일 전송을 목적으로 만들어진 프로토콜입니다.
그렇다면 FTP의 핵심 요구사항은 무엇일까요?

FTP가 해결하려 했던 문제는 명확합니다. 큰 파일을 중간에 끊기지 않게, 서버와 클라이언트 간에 정확하게 전달하는 것입니다.

즉, FTP의 최우선 목표는 속도나 실시간성이 아니라 신뢰성 있는 전달이었습니다.

이러한 요구사항 때문에 FTP는 자연스럽게 TCP 기반으로 설계되었습니다.

HTTP(하이퍼텍스트 전송 프로토콜)

HTTP는 웹에서 리소스를 주고받기 위해 만들어진 응용 계층 프로토콜입니다.
HTTP가 해결하려 했던 핵심 요구사항은 다음과 같습니다.

불특정 다수의 클라이언트와 서버가, 표준화된 방식으로 문서와 데이터를 주고받는 것입니다.

이를 위해 HTTP는 요청(Request)과 응답(Response)이라는 단순한 모델을 사용하고
상태를 서버에 유지하지 않는 Stateless 구조를 선택했습니다.

즉, HTTP의 목표는 속도나 실시간성보다는 확장성과 범용성이었습니다.

이러한 선택 덕분에 HTTP는 서버 확장이 쉽고 캐시가 가능하며 다양한 환경에서 동일하게 동작할 수 있었습니다.

그래서 웹은 실시간 통신이나 파일 전송처럼 특수한 요구사항이 있음에도 불구하고,
기본 통신 프로토콜로 HTTP를 중심에 두는 구조를 선택하게 되었습니다.

HTTP/3(QUIC)

HTTP/3는 기존 HTTP가 가지던 성능 한계를 해결하기 위해 등장한 프로토콜입니다.
HTTP/3가 해결하려 했던 핵심 요구사항은 명확합니다.

웹 통신에서 발생하는 지연을 줄이고, 연결 복구에 강한 구조를 만드는 것입니다.

이를 위해 HTTP/3는 TCP가 아닌 UDP 기반의 QUIC 프로토콜 위에서 동작합니다.
QUIC은 전송 계층 수준에서 연결 설정 비용을 줄이고 스트림 단위 전송을 지원하며
패킷 손실 시 전체 연결이 막히는 문제를 완화합니다.

즉, HTTP/3의 목표는 기능을 늘리는 것이 아니라, 웹 환경에서의 체감 성능을 개선하는 것이었습니다.

이러한 이유로 HTTP/3는 기존 HTTP를 대체하기보다는,
HTTP/1.1과 HTTP/2를 보완하는 선택지로 공존하고 있습니다.

HTTPS(보안 HTTP)

HTTPS는 HTTP 통신을 안전하게 보호하기 위해 등장한 프로토콜입니다.
HTTPS가 해결하려 했던 핵심 요구사항은 분명합니다.

웹 통신 내용을 제3자가 볼 수 없도록 보호하고, 통신 상대가 신뢰할 수 있는 대상임을 보장하는 것입니다.

이를 위해 HTTPS는 HTTP 자체를 바꾼 것이 아니라,
TLS(Transport Layer Security) 를 통해 통신 내용을 암호화하는 방식을 선택했습니다.

즉, HTTPS의 목표는 웹의 구조나 동작 방식을 바꾸는 것이 아니라,
기존 HTTP의 장점을 유지한 채 보안만 강화하는 것이었습니다.

이러한 설계 덕분에 HTTPS는 데이터 도청 방지, 위·변조 방지, 서버 신원 검증
을 가능하게 했고, 오늘날 웹에서는 사실상 기본 전제가 되었습니다.

SMTP(단순 메일 전송 프로토콜)

SMTP는 이메일을 전송하기 위해 설계된 프로토콜입니다. SMTP가 해결하려 했던 핵심 요구사항은 다음과 같습니다.

메시지를 즉시 전달하지 못하더라도, 중간 서버를 거쳐 최종 수신자에게 반드시 전달하는 것입니다.

즉, SMTP의 최우선 목표는 실시간성이 아니라 신뢰성과 전달 보장입니다.
이를 위해 SMTP는 서버 간 릴레이 구조를 사용하고 실패 시 재시도를 전제로 하며 TCP 기반으로 안정적인 전송을 선택했습니다.
이러한 특성 때문에 SMTP는 웹처럼 즉각적인 응답이 필요한 통신보다는, 비동기 메시징에 적합한 프로토콜로 자리 잡았습니다.

WebSocket

WebSocket은 웹 환경에서 실시간 양방향 통신을 위해 등장한 프로토콜입니다.
WebSocket이 해결하려 했던 핵심 요구사항은 다음과 같습니다.

클라이언트와 서버가 연결을 유지한 채, 서로 필요할 때 즉시 데이터를 주고받는 것입니다.

기존 HTTP는 요청이 있어야만 응답할 수 있는 구조이기 때문에,
실시간 알림이나 채팅과 같은 요구사항을 자연스럽게 처리하기 어려웠습니다.

이를 해결하기 위해 WebSocket은 HTTP 요청으로 연결을 시작한 뒤 연결을 전이중(Full-Duplex) 통신 채널로 전환합니다.
즉, WebSocket의 목표는 HTTP를 대체하는 것이 아니라, HTTP가 해결하지 못한 실시간 통신 영역을 보완하는 것이었습니다.
이러한 특성 덕분에 WebSocket은 채팅, 실시간 알림, 실시간 대시보드와 같은 즉각적인 반응이 필요한 웹 기능에서 사용됩니다.

그래서 말하고자하는게 무엇인가?

8가지의 프로토콜을 살펴보았다. 전달하고자 하는 자원이 같음에도 그 자원을 어떻게 활용하는지에 따라 프로토콜이 다른것을 확인 할 수 있었습니다.(ex.TCP,UDP) 또한 동일한 프로토콜로 시작하였지만, 각자 놓여진 환경에 따라 변화가 되어진사실도 알았습니다. 마지막으로 하나의 프로토콜을 보완하기 위해 다른 프로토콜을 통해 해결하는것도 확인되었습니다. 어떻게 보면 하나의 프로토콜로 해결할 수 있을수 도 있습니다. 하지만 프로토콜의 선택은 기존 프로토콜을 유지한채, 그것을 보완할 수 있는 프로토콜을 만드는 것을 결정했습니다. 이는 혼란을 막기위한 해결책이라고 생각합니다.

즉, 프로토콜이 다양해진 이유는 기술이 복잡해졌기 때문이 아니라, 서로 다른 문제를 하나의 규칙으로 해결하지 않기 위한
설계적 선택의 결과라고 볼 수 있습니다.

출처
https://blog.bytebytego.com/p/ep195-common-network-protocols-every