지연 13분의 1로…AI 시대엔 TCP 대신 호마?

TCP는 웹과 클라우드를 떠받치는 통신 프로토콜이지만 AI 데이터센터 통신에는 맞지 않는다는 주장이 나왔다. 존 오스터하우트(John Ousterhout) 스탠퍼드대 명예교수는 전송 프로토콜 호마(Homa)로 옮겨가야 한다고 주장했다. 호마는 짧은 메시지를 먼저 처리해 통신 지연을 줄이는 구조를 갖췄고 기존 TCP와 나란히 도입할 수 있다.

TCP는 보낸 데이터가 상대에게 도착했는지 확인하며 통신을 이어가는 방식으로 웹을 비롯해 폭넓은 분야에서 쓰인다. 신뢰도 높은 통신을 보장하지만 연결마다 상태를 관리하고 데이터를 보낸 순서대로 늘어선 바이트스트림으로 다룬다는 특징이 있다.

◇ AI 클러스터에 TCP 안 맞는 이유=TCP는 일반 인터넷 통신에서 오랫동안 제 몫을 해왔다. 하지만 데이터센터에서는 물리적으로 가까운 컴퓨터 여러 대가 잘게 쪼갠 요청을 대량으로 주고받는다. 그래서 연결 관리와 전송 순서 보장에 드는 처리가 통신 시간에서 차지하는 비중이 커진다.

대규모 AI 클러스터에서는 모델 가중치나 기울기 같은 대용량 데이터 전송과 KV 캐시 검색이나 메타데이터 조정 같은 짧은 통신이 같은 네트워크를 오간다. 크고 작은 통신을 각각 관리해 지연을 최소로 줄이는 게 중요하다. 오스터하우트 교수는 핵심은 지연 시간이라며 1밀리초 지연만으로도 값비싼 GPU가 처리를 기다리는 시간이 생긴다고 지적했다.

TCP에서는 송신 측이 네트워크 혼잡도를 추정하며 전송량을 조절한다. 수신 측에서 돌아오는 응답 등을 단서로 속도를 낮추는 구조여서 개별 송신 측은 다른 송신원을 포함해 수신 측에 통신이 얼마나 몰렸는지 파악하기 어렵다. 그만큼 혼잡 대응이 늦어지기 쉽다. 또 TCP는 데이터를 하나로 이어진 스트림으로 다루기 때문에 짧은 메시지와 긴 메시지를 구분해 짧은 쪽을 먼저 보내는 구조도 없다.

웹에서도 같은 문제가 예전부터 지적됐다. TCP 위에서 돌아가는 HTTP/2는 패킷이 사라지면 뒤따르는 데이터가 기다려야 하는 HOL 블로킹(Head-of-Line Blocking)이 생긴다. 웹 분야에서는 TCP 대신 QUIC을 쓰는 HTTP/3가 등장했다.

◇ 메시지 단위로 짧은 것부터=호마는 데이터센터용 통신 자체를 새로 설계해 TCP 문제를 풀려 한다. 호마 연구는 2018년 발표 논문으로 거슬러 올라간다. 베남 몬타제리(Behnam Montazeri)와 오스터하우트 교수 등은 짧은 메시지 저지연과 높은 네트워크 사용률을 함께 잡는 프로토콜로 호마를 제안했다.

호마는 TCP 같은 스트림형이 아니라 메시지형으로 통신한다는 점이 가장 큰 특징이다. 호마는 다른 컴퓨터의 처리를 호출하는 원격 프로시저 호출(RPC)을 전제로 해 보낼 메시지 길이를 처음부터 알 수 있다. 수신 측은 남은 데이터 양을 파악할 수 있어 빨리 받아낼 수 있는 메시지를 먼저 처리한다.

호마는 혼잡 제어 주도권도 수신 측에 넘겼다. 수신 측은 도착 예정 메시지 양을 확인하고 어느 송신자가 데이터를 얼마나 보내도 되는지 그랜트(GRANT)라는 통지로 지정한다. 서버 1대에 통신이 한꺼번에 몰려도 수신 측이 도착 순서를 조정하기 쉬워진다.

짧은 메시지가 정체에 휘말리지 않도록 네트워크 장비의 우선순위 큐도 활용한다. 연구팀이 2018년 공개한 호마는 수신 완료까지 남은 데이터가 적은 통신일수록 우선순위를 높이는 방식을 택했다. 대용량 전송 뒤에 작은 요청이 줄 서서 기다리는 시간을 줄이려는 의도다.

오스터하우트 교수가 제시한 비교 결과를 보면 100Gbps에 네트워크 사용률 80% 조건에서 짧은 메시지 99퍼센타일 지연은 TCP가 1.2밀리초였고 호마는 92마이크로초였다. TCP의 13분의 1 수준이다. 그는 긴 메시지에서도 호마가 TCP보다 2배 수준 성능을 냈다고 주장했다.

2021년 공개된 리눅스(Linux) 커널용 호마 구현 논문에서도 호마는 기기 40대를 쓴 시험에서 모든 메시지 크기에 걸쳐 TCP와 DCTCP보다 낮은 지연을 기록했다. 짧은 메시지 99퍼센타일 지연은 TCP의 19분의 1에서 72분의 1 수준이었고 DCTCP 대비로는 7분의 1에서 83분의 1 수준이었다.

◇ TCP와 함께 쓰며 단계적 전환=호마로는 단계적으로 옮겨갈 수 있어 기존 TCP 통신을 한꺼번에 없앨 필요가 없다. 공개된 리눅스 커널 모듈을 클라이언트와 서버에 설치하면 호마와 TCP를 나란히 쓸 수 있어 애플리케이션을 차례로 호마로 옮기면 된다. 오스터하우트 교수는 두 프로토콜을 함께 쓸 때 성능을 높이는 작업도 하고 있다. 깃허브(GitHub)에는 2026년 1월 둘을 공존시킬 때 통신 제어를 개선하는 homa_qdisc가 추가됐다.

호마는 연구에 머물지 않고 표준화와 리눅스 도입도 추진하고 있다. 인터넷할당번호관리기관(IANA)은 호마에 IP 프로토콜 번호 146을 이미 배정했고 오스터하우트 교수는 호마를 리눅스 본체에 넣기 위한 패치를 꾸준히 제출하고 있다.

깃허브 구현도 개발이 이어지고 있다. 2026년 3월에는 레드햇 엔터프라이즈 리눅스(Red Hat Enterprise Linux) 8과 9.5로 백포트가 이뤄졌고 같은 해 9월에는 데이터 전송 허가 구조가 바뀌었다.

웹에서는 TCP 문제를 피하려고 QUIC이 퍼졌지만 호마가 겨냥하는 건 데이터센터 내부 RPC다. 오스터하우트 교수는 국제인터넷표준화기구(IETF) 표준화를 위한 문서 작성과 리눅스 통합 작업을 진행하면서 대형 금융서비스 기업과도 호마 시제품을 만들고 있다. 반세기 가까이 네트워크 주역을 맡아온 TCP를 당장 몰아내는 게 아니라 AI 클러스터처럼 지연에 민감한 곳부터 호마를 넓혀간다는 구상이다.

데이터센터용으로는 RDMA 같은 다른 저지연 통신 기술도 쓰이고 있다. 관련 내용은 이곳에서 확인할 수 있다.