"gRPC는 TCP를 사용하나요, 아니면 UDP를 사용하나요?"라는 질문은 단 한 단어로 답할 수 있을 것처럼 보입니다. 하지만 실제로는 그렇지 않습니다. 검색창에 grpc udp를 입력해 본 적이 있다면, 아마도 실시간 피드, 텔레메트리(telemetry), 게임 또는 에이전트 간(agent-to-agent) 트래픽을 위해 gRPC가 데이터그램(datagram) 방식의 통신을 수행할 수 있는지 확인하려는 것일 겁니다. 짧게 요약하자면 이렇습니다: gRPC는 HTTP/2를 기반으로 구축되었고, HTTP/2는 TCP를 기반으로 구축되었으므로 gRPC에는 네이티브 UDP 전송(transport) 방식이 없습니다. 하지만 이것이 전부는 아닙니다. HTTP/3와 QUIC를 통한 UDP 경로가 존재하며, gRPC를 전혀 원하지 않는 경우도 있습니다. 스택을 하나씩 살펴보겠습니다.

gRPC가 UDP 위에서 동작할 수 있을까? 짧은 답변

아니요 — 네이티브 방식으로는 불가능하며, 현재 바로 프로덕션(production) 환경에 적용할 수 있는 방식도 아닙니다. gRPC의 전송 계층은 HTTP/2이고, HTTP/2의 전송 계층은 TCP입니다. gRPC 사양은 하단에 신뢰할 수 있고 순서가 보장되는 바이트 스트림(byte-stream) 연결이 있다고 가정합니다. UDP는 이러한 기능들을 전혀 제공하지 않으므로, 단순히 켜기만 하면 되는 "raw UDP 기반 gRPC" 모드는 존재하지 않습니다.

그럼에도 불구하고 이 질문이 계속해서 제기되는 이유는 그 이유를 이해할 가치가 있기 때문입니다. 질문을 하는 사람들은 대개 특정한 것을 원하기 때문입니다: 즉, 스트림당 하나의 TCP 연결을 유지하는 비용 없이 gRPC의 멀티플렉싱(multiplexing) 및 타입화된 계약(typed-contract)의 이점을 얻고 싶거나, 시간에 민감한 데이터를 위해 더 낮은 지연 시간(low-latency)의 전송 방식을 원하는 것입니다.

gRPC가 실제로 스택의 어디에 위치하는가

계층을 그려보면 대부분의 네트워킹 질문은 더 쉬워집니다:

gRPC        ← RPC 계층: protobuf 메시지, 데드라인(deadlines), 상태 코드(status codes)
HTTP/2      ← 프레이밍(framing): 멀티플렉싱된 스트림(multiplexed streams), 헤더(headers), 트레일러(trailers)
TCP         ← 순서가 보장되고 신뢰할 수 있는 바이트 스트림(byte stream)
...

gRPC는 의도적으로 HTTP/2를 선택했습니다. RPC 모델은 많은 인플라이트(in-flight) 호출이 하나의 연결을 공유할 수 있도록 하는 멀티플렉싱된 스트림, 반복되는 메타데이터를 위한 헤더 압축(header compression), 그리고 응답 본문 이후에 상태 코드를 전달하기 위한 트레일러(trailers)가 필요합니다. 이 모든 기능은 HTTP/2 계층에서 작동합니다. 그 아래에서 gRPC는 TCP의 보장 사항에 의존합니다: 바이트가 순서대로 도착하고, 아무것도 조용히 누락되지 않으며, 연결이 작동하거나 혹은 명확하게 실패한다는 점입니다.

UDP는 그 중 어떤 것도 보장하지 않습니다. UDP는 데이터그램 (Datagram) 서비스입니다. 특정 주소로 패킷을 발사하며, 최선형 노력 (Best effort) 방식이고, 순서 보장이 없으며, 혼잡 인지 (Congestion awareness) 기능이 없고, 연결 상태 (Connection state)도 없습니다. 이것이 바로 "gRPC를 그냥 UDP 소켓으로 연결하면 안 될까?"라는 질문이 성립하지 않는 이유입니다. gRPC가 자신의 프로토콜 내부에서 TCP를 재구현해야 하는데, 이는 들리는 것보다 훨씬 더 큰 작업이기 때문입니다.

UDP 경로: QUIC 및 HTTP/3

UDP 경로가 존재하며, 이는 QUIC을 통해 이루어집니다. QUIC은 UDP 위에서 실행되는 전송 프로토콜 (Transport protocol)로, TCP가 제공하는 신뢰성 (Reliability)과 순서 보장 (Ordering)을 다시 추가하면서, 스트림 수준의 독립성 (Stream-level independence), 연결 이동성 (Connection migration), 그리고 더 빠른 연결 설정 (Connection establishment) 기능을 더했습니다. HTTP/3는 QUIC 위에서 동작하는 HTTP이며, HTTP/3 위에서 동작하는 gRPC는 실질적인 의미에서 정확히 "UDP 위에서 동작하는 gRPC"입니다.

문제는 성숙도입니다. gRPC의 HTTP/3 지원은 구현체 전반에 걸쳐 여전히 실험적 (Experimental) 단계입니다. 일부 언어 라이브러리는 프리뷰 전송 (Preview transports) 기능을 제공하지만 (.NET gRPC 스택은 일찍 HTTP/3 구현을 출시했습니다), Go의 gRPC 라이브러리를 포함한 다른 라이브러리들은 이를 네이티브로 전혀 지원하지 않습니다. HTTP/3 전송을 위한 공식 gRPC 사양은 여전히 진행 중입니다. 오늘날 일부 스택에서는 이를 연결할 수 있지만, 실험적인 브랜치와 더 빈약한 생태계에 의존해야 합니다. 즉, gRPC-over-HTTP/3를 이해하는 프록시 (Proxies), 관찰 가능성 미들웨어 (Observability middleware), 로드 밸런서 (Load balancers) 등이 TCP 경로에 비해 훨씬 드뭅니다.

이러한 고충을 감수했을 때 얻을 수 있는 이점은 다음과 같습니다: 스트림 간의 헤드 오브 라인 블로킹 (Head-of-line blocking) 제거 (패킷 하나를 분실해도 연결을 공유하는 모든 RPC가 아닌 해당 스트림 하나만 중단됨), 클라이언트가 네트워크를 전환할 때의 연결 이동성 (Connection migration), 그리고 전체 왕복 (Full round trip)이 필요 없는 핸드셰이크 (Handshake)입니다. 생태계가 따라잡는 날을 위해 준비된, 진정으로 유용한 속성들입니다.

사람들이 실제로 "gRPC Over UDP"라고 말할 때의 의미

grpc udp 뒤에 숨겨진 검색 의도는 몇 가지 뚜렷한 질문으로 나뉘며, 각각에 대한 답변도 다릅니다:

• "gRPC는 TCP를 사용하나요, 아니면 UDP를 사용하나요?" — HTTP/2를 통한 TCP를 사용합니다. 항상 기본값입니다.
• "gRPC가 UDP 위에서 동작할 수 있나요?" — 실험적인 HTTP/3/QUIC 지원을 통해서만 가능하며, 안정적인 네이티브 경로는 존재하지 않습니다.
• "저지연(low latency)을 위한 gRPC vs UDP" — 이러한 검색 대부분의 이면에 깔린 진짜 질문입니다. 만약 저지연, 실시간 시맨틱(semantics)이 필요하다면, gRPC-over-TCP와 순수 UDP(raw-UDP)는 대개 둘 다 적절한 도구가 아닙니다. 당신이 필요로 하는 특정 프로필에 맞춰 설계된 무언가가 필요할 것입니다.

사람들이 진정으로 데이터그램 시맨틱(datagram semantics) — 손실 허용, 메시지당 최소한의 오버헤드, 다수의 수신자로의 팬아웃(fan-out) — 을 원할 때, 그들은 대개 gRPC를 찾는 것이 아닙니다. 그들은 UDP의 프로필을 가지면서 신뢰성(reliability)은 다른 곳에서 처리되는 전송 계층을 찾고 있는 것입니다.

에이전트 간(Agent-to-Agent) 사례: UDP 전송이 실제로 도움이 되는 경우

이 질문이 2026년에 구체화되는 지점은 바로 AI 에이전트입니다. 에이전트들은 하트비트(heartbeats), 작업 위임, 결과 스트리밍 등을 위해 지속적으로 통신하며, 클라우드, 컨테이너, NAT를 가로질러 실행됩니다. 이러한 환경에서는 TCP 연결을 위해 포트 포워딩이나 릴레이(relay)가 필요하고, 웹훅(webhooks)은 타임아웃이 발생하며, 폴링(polling)은 CPU 사이클을 낭비합니다. 만약 UDP의 경량 전송 프로필에 신뢰성과 도달 가능성(reachability)까지 더하고 싶다면, 그것이 바로 오버레이 네트워크(overlay network)가 채워주는 틈새시장입니다.

정직한 사례 중 하나는 Pilot Protocol로, 에이전트에게 영구적인 가상 주소와 암호화된 UDP 터널을 제공하는 오픈 소스 오버레이 네트워크입니다. 전송 계층은 암호화(X25519 키 교환, AES-GCM)를 포함한 UDP이며, 신뢰성은 사용자 공간(userspace)에서 구현됩니다. 즉, 직접 재전송 로직을 작성하지 않고도 데이터그램의 효율성을 얻을 수 있습니다. NAT 트래버설(NAT traversal)은 STUN과 릴레이 폴백(relay fallback)을 포함한 홀 펀칭(hole-punching)을 사용하므로, NAT 뒤에 있는 에이전트도 포트를 열지 않고 도달할 수 있습니다. 신뢰는 주변 환경에 의한 것이 아니라 명시적입니다. 모든 피어(peer) 관계는 상호 핸드셰이크(mutual handshake)로 시작되므로, 네트워크에 참여한다고 해서 자동으로 누군가를 신뢰하게 되지는 않습니다.

# 명령어 하나로 에이전트가 네트워크상의 주소를 갖게 됩니다
curl -fsSL https://pilotprotocol.network/install.sh | sh

또한 에이전트가 유형화된 IPC 서비스(JSON 입력, JSON 출력)로서 기능을 설치할 수 있는 앱 스토어도 함께 제공하며, 이는 네트워크에 이미 존재하는 243k개 이상의 에이전트와 사용자에 의해 발견될 수 있습니다. VPN이나 고정 IP 없이 지속적이고 안전한 연결이 필요한 에이전트 워크로드의 경우, 이는 순수 gRPC나 순수 UDP보다 더 적합한 선택입니다.

그래서: gRPC인가 UDP인가?

무엇을 구축하느냐에 따라 달라집니다:

• 풍부한 스트리밍을 포함한 유형화된 요청/응답(Typed request/response)이 필요하고 엔드포인트를 직접 제어하나요? TCP 기반의 gRPC가 성숙하고, 안정적이며, 올바른 선택입니다.
• 손실이 발생하는 링크(lossy links)에서 최대 처리량(throughput)이 필요하며 신뢰성을 직접 관리할 수 있나요? 순수 UDP에 자체 프로토콜 계층을 추가하십시오.
• TCP의 헤드 오브 라인 블로킹(head-of-line blocking) 없이 멀티플렉싱(multiplexing)을 원하며 실험적인 기술을 수용할 수 있나요? HTTP/3 기반의 gRPC를 주목하십시오.
• NAT 뒤에 있는 많은 머신들이 지속적이고 안전한 연결을 필요로 하나요 — 특히 에이전트의 경우? 연결마다 NAT와 싸우기보다는 사용자 공간 신뢰성(userspace reliability)을 갖춘 UDP 기반의 오버레이(overlay)를 활용하십시오.

FAQ

gRPC는 TCP를 사용하나요, UDP를 사용하나요?
TCP를 사용합니다. gRPC는 TCP 위에서 동작하는 HTTP/2 위에서 실행됩니다.

gRPC가 UDP 위에서 동작할 수 있나요?
네이티브(natively)로는 불가능합니다. 유일한 UDP 경로는 QUIC 기반의 HTTP/3이며, 이는 gRPC 구현체에서 여전히 실험적인 단계로 남아 있습니다.

HTTP/3 기반의 gRPC는 프로덕션 환경에서 사용할 수 있나요?
광범위하게는 아닙니다. 일부 언어 구현체에서 실험적인 지원을 제공하고 있으나, 공식 사양(spec) 작업은 여전히 진행 중입니다.

gRPC 대신 순수 UDP를 언제 사용해야 하나요?
데이터그램 의미론(datagram semantics) — 메시지당 낮은 오버헤드, 손실 허용, 팬아웃(fan-out) — 이 필요하며, 애플리케이션 계층에서 신뢰성을 직접 처리할 의사가 있을 때 사용하십시오.

맺음말

"grpc udp"는 결국 두 가지 질문으로 귀결됩니다: gRPC가 UDP를 사용할 수 있는가 (아니요, 안정적이지 않습니다) 그리고 UDP의 특성이 필요할 때 무엇을 사용해야 하는가 (상황에 따라 다릅니다). 전송 스택에는 단 하나의 정답이 없으며, 정답이 있는 척하는 것은 결국 평생 유지보수해야 하는 맞춤형 신뢰성 프로토콜을 직접 만들게 되는 지름길입니다. 전송 계층에서 실제로 무엇이 필요한지 파악하고, 그것을 제공하는 계층을 선택하십시오.

만약 에이전트 간 시스템 (agent-to-agent systems)을 구축 중이며, 직접 구현하지 않고도 UDP 경로를 사용하고 싶다면, 위에 제공된 설치 명령어가 오버레이 (overlay) 방식을 시도해 볼 수 있는 가장 빠른 방법입니다. 그리고 만약 프로덕션 환경에서 HTTP/3 위로 gRPC를 실행해 보셨다면, 그 결과가 어떠했는지 진심으로 듣고 싶습니다.