프로토콜이란 무엇인가?

두 사람이 대화할 때, 끊임없이 즉흥적으로 대응하게 된다. 상대방이 웅얼거리면 다시 말해달라고 한다. 어떤 단어가 두 가지 의미를 가지더라도 문맥이 그것을 명확하게 해준다. 상대방이 혼란스러워 보이면 다르게 표현한다. 인간은 모호함 속에서도 의사소통할 수 있다. 실시간으로 적응할 수 있기 때문이다.

기계는 이것을 할 수 없다.

데이터를 수신하는 컴퓨터에는 직관이 없다. 당신이 아마 무엇을 의미했는지 추측할 수 없다. 전송 중간에 명확한 질문을 할 수도 없다. 비트 하나가 손상되어 도착하면, 기계는 그것이 무엇이었어야 했는지 알 방법이 없다. 모든 가능한 상황—모든 예외적인 경우, 모든 실패 방식, 모든 모호함—이 미리 예측되고 명시되어야 한다.

이러한 명세들을 프로토콜이라고 한다. 즉흥적으로 대응할 능력이 없는 기기들 사이에서 통신을 가능하게 하는 극도로 상세한 규칙들이다.

기계에 명확한 규칙이 필요한 이유

완벽하게 문자 그대로 지시를 따르지만 판단력은 전혀 없는 사람과 협력한다고 상상해보자. "파일을 보내줘"라고는 말할 수 없다. 다음을 일일이 명시해야 한다: 어떤 형식으로? 어느 크기의 조각으로 나눠서? 조각 하나가 유실되면 어떻게 되나? 수신자는 더 받을 준비가 됐다는 신호를 어떻게 보내나? 두 기기가 동시에 전송하려 하면 어떻게 되나? 전송이 완료됐다는 것은 무엇으로 나타내나?

프로토콜은 이 모든 질문들에 답한다—수천 가지도 더—통신이 시작되기 전에. 그래야만 한다. 데이터가 흐르기 시작하면 "잠깐, 그게 무슨 뜻이었어?"라고 물을 여지가 없기 때문이다.

그래서 프로토콜은 거의 편집증에 가까울 만큼 정밀하게 설계된다. 정확한 바이트 위치, 정확한 타임아웃 시간, 정확한 메시지 순서를 명시한다. 이 정밀함은 관료적인 부담이 아니다. 공유된 직관이 없는 기계들이 서로를 이해할 수 있는 유일한 방법이다.

프로토콜이 실제로 해결하는 것

상호운용성은 가장 명백한 이점이다. 당신의 스마트폰이 다른 나라의 서버에서 웹페이지를 불러올 수 있는 것은 두 기기 모두 동일한 HTTP 명세를 구현하기 때문이다. 다른 제조사, 다른 운영 체제, 다른 하드웨어—양쪽이 프로토콜을 따르는 한 그 어느 것도 문제가 되지 않는다.

신뢰성은 네트워크가 끊임없이 실패한다는 불편한 진실을 다룬다. 대규모 인터넷 환경에서는 케이블이 잘리고, 패킷은 손상된 채로 도착하고, 라우터는 전송 중간에 다운된다. TCP 같은 프로토콜은 모든 것이 잘못될 수 있다고 가정하고, 문제를 감지하고 복구하는 메커니즘을 내장한다: 체크섬이 손상을 감지하고, 순서 번호가 누락된 데이터를 탐지하며, 확인 응답이 수신을 확인한다. 이 편집증적인 태도에는 충분한 이유가 있다.

효율성은 명백한 낭비를 방지한다. 큰 파일을 하나의 취약한 덩어리로 보내는 대신, 프로토콜은 데이터를 패킷으로 분할하여 각기 다른 경로로 전송하고 목적지에서 재조립한다. 패킷 하나가 유실되면 그 패킷만 재전송하면 된다—전체 파일이 아니라.

조율은 공유 자원의 문제를 해결한다. 여러 기기가 네트워크를 공유할 때, 모두가 동시에 전송하는 것을 막을 무언가가 필요하다. 프로토콜은 언제 누가 보낼 수 있는지, 충돌 시 무슨 일이 일어나는지, 기기들이 어떻게 서로에게 양보하는지를 정의한다.

프로토콜 스택: 계층적 구조

단일 프로토콜이 모든 것을 처리하지는 않는다. 대신 프로토콜은 계층으로 구성되며, 각 계층은 한 가지 범주의 문제를 해결하고, 자신이 제공하지 않는 서비스는 하위 계층에 의존한다.

TCP/IP 스택은 네 개의 계층으로 이루어져 있다:

링크 계층은 가장 직접적인 물리적 현실을 처리한다: 비트가 어떻게 전기 신호가 되는지, 같은 회선에 연결된 기기들이 어떻게 번갈아 전송하는지, 기기가 통신 상대를 어떻게 식별하는지. 유선 네트워크에서는 이더넷이 지배적이며, 무선에서는 Wi-Fi가 그 역할을 한다.

인터넷 계층은 네트워크를 넘나드는 주소 지정과 라우팅을 담당한다. 인터넷 프로토콜(IP)은 논리적 주소를 할당하고 패킷을 목적지로 전달하지만 어떠한 보장도 하지 않는다. 패킷이 순서 없이 도착할 수 있다. 아예 도착하지 않을 수도 있다. IP는 그저 최선을 다할 뿐이다.

전송 계층은 애플리케이션이 필요로 하는 보장을 더한다. TCP는 IP의 신뢰할 수 없는 서비스 위에 신뢰할 수 있는 순서 보장 전달을 구축한다—연결을 수립하고, 수신된 내용을 추적하고, 유실된 것을 재전송한다. UDP는 완전성보다 속도가 더 중요한 애플리케이션을 위해 신뢰성을 생략한다.

애플리케이션 계층에는 특정 목적을 위한 프로토콜이 담겨 있다: 웹 콘텐츠를 위한 HTTP, 이메일을 위한 SMTP, 도메인 이름을 IP 주소로 변환하는 DNS. 각각은 아래의 전송 계층이 전달을 처리해준다고 가정한다.

이 분리에는 실질적인 이점이 있다: 모든 것을 다시 작성하지 않고도 계층을 교체할 수 있다. HTTP를 사용하는 웹 애플리케이션은 오늘 TCP 위에서 실행되다가 내일 QUIC 위에서 실행될 수 있으며, 애플리케이션 코드 한 줄도 바꿀 필요가 없다.

요청이 스택을 통과하는 과정

웹사이트를 방문할 때, 프로토콜은 모든 계층에서 작동한다.

브라우저는 먼저 DNS를 사용하여 도메인 이름을 IP 주소로 변환한다. 이 쿼리는 UDP로 전송되는데, 크기가 작고 단순히 재시도할 수 있는 조회에는 보장된 전달보다 속도가 더 중요하기 때문이다.

IP 주소를 확보한 후, 브라우저는 TCP 연결을 수립한다: 양측이 시작 순서 번호와 버퍼 크기에 합의하는 3-way 핸드셰이크다. 이 준비가 완료된 후에야 실제 데이터가 흐르기 시작한다.

TCP 연결을 통해 브라우저는 HTTP 요청을 전송한다—요청 라인, 메타데이터를 담은 헤더, 그리고 경우에 따라 본문으로 구성된 정밀하게 형식화된 메시지다. 서버는 HTTP 규칙에 따라 이것을 파싱하고 같은 형식으로 응답을 돌려보낸다.

사이트가 HTTPS를 사용한다면, TLS가 HTTP와 TCP 사이에 위치하여 TCP가 전송하기 전에 HTTP 메시지를 암호화한다. 이것은 프로토콜이 위아래 계층의 변경 없이 스택에 삽입되어 새로운 기능을 추가할 수 있는 방법을 잘 보여준다—이 경우에는 보안이다.

이 모든 과정에서 이더넷이나 Wi-Fi가 로컬 네트워크에서 비트의 실제 이동을 처리하며, 각 패킷은 출발지와 목적지를 식별하는 MAC 주소가 포함된 적절한 프레임 형식으로 감싸져 있다.

프로토콜의 진화 방식

프로토콜은 개방된 절차를 통해 표준화된다. 인터넷 엔지니어링 태스크 포스(IETF)는 대부분의 인터넷 프로토콜을 RFC—의견 요청서(Request for Comments)—로 발행한다. 이름은 잠정적으로 들리지만, 이 문서들이 바로 권위 있는 공식 명세다. TCP, IP, HTTP, DNS—모두 RFC에 정의되어 있다.

IETF 프로세스는 이론적 우아함보다 실제로 동작하는 코드를 중시한다. 종이 위에만 존재하는 프로토콜은 표준화될 수 없다. 이 실용주의 덕분에 인터넷 프로토콜은 현실과 동떨어지지 않을 수 있었다.

IEEE는 물리 및 링크 계층 표준을 담당한다—이더넷과 Wi-Fi는 그들의 802 명세에 속한다. W3C는 웹 관련 표준을 관리한다.

프로토콜은 기존 기기와의 호환성을 유지하면서 발전해야 하기 때문에, 협상 메커니즘을 내장하고 있다. TLS 연결이 시작될 때, 클라이언트와 서버는 지원하는 버전 목록을 교환하고 양쪽이 이해하는 가장 높은 버전에 합의한다. 덕분에 이전 시스템과의 통신을 끊지 않으면서도 점진적으로 개선 사항을 도입할 수 있다.

프로토콜에 관한 자주 묻는 질문

TCP와 UDP의 차이는 무엇인가?

TCP는 신뢰할 수 있는 순서 보장 전달을 제공한다—데이터가 완전하고 순서대로 도착하는 것을 보장하며, 유실된 것은 재전송한다. UDP는 보장 없이 빠르고 연결 없는 전달을 제공한다. 정확성이 중요할 때는 TCP를 사용하라(웹 페이지, 파일 전송). 완전성보다 속도가 더 중요할 때는 UDP를 사용하라(영상 통화, 게임).

하나의 프로토콜이 아닌 왜 이렇게 많은 프로토콜이 존재하는가?

문제마다 다른 해결책이 필요하기 때문이다. 신뢰할 수 있는 파일 전송에 최적화된 프로토콜은 실시간 비디오에는 낭비적일 것이다. 물리적 신호 타이밍을 처리하는 프로토콜이 웹 페이지 형식을 신경 쓸 이유는 없다. 계층화된 접근 방식 덕분에 각 프로토콜이 한 가지 일을 잘 할 수 있다.

프로토콜에 버그나 보안 취약점이 있으면 어떻게 되나?

표준화 기관이 업데이트를 발행하고 구현에 패치가 적용되어야 한다. 이것이 보안 업데이트가 중요한 이유 중 하나다—종종 프로토콜 수준의 취약점을 수정하기 때문이다. 프로토콜에 내장된 협상 메커니즘도 도움이 된다: 취약점이 알려지면 해당 취약 버전을 거부하도록 시스템을 구성할 수 있다.

나만의 프로토콜을 만들 수 있나?

물론이다. 하지만 통신하고자 하는 모든 상대방이 그것을 구현해야 한다. 표준화된 프로토콜의 가치는 바로 모두가 이미 같은 언어를 사용한다는 데 있다. 커스텀 프로토콜은 모든 엔드포인트를 직접 제어할 수 있는 통제된 환경에서만 의미가 있다.