gRPC 기본 개념: Protocol Buffers, HTTP/2, REST 차이

gRPC는 Protocol Buffers로 서비스 계약을 정의하고 HTTP/2 기반으로 서버 간 호출을 처리하는 RPC 프레임워크입니다.

이 글은 gRPC가 REST와 어떻게 다르고, 성능과 타입 안정성을 얻는 대신 어떤 복잡성이 생기는지 정리합니다.

 

핵심 정리

gRPC는 먼저 proto 파일로 서비스 메서드와 메시지 타입을 정의하고, 이를 바탕으로 클라이언트와 서버 코드를 생성하는 방식으로 동작합니다. JSON 중심 REST보다 사람이 바로 읽기는 어렵지만, 바이너리 직렬화와 HTTP/2의 장점을 활용해 서버 간 통신에서 성능과 계약 안정성을 얻기 쉽습니다. 반대로 브라우저 직접 호출, 디버깅, 운영 도구 측면에서는 REST보다 복잡하게 느껴질 수 있습니다.

• Protocol Buffers는 서비스 요청과 응답의 타입을 정의하는 계약 역할을 합니다.
• gRPC는 계약을 기준으로 클라이언트와 서버 코드를 생성합니다.
• HTTP/2 기반이라 스트리밍과 다중화 같은 통신 방식과 잘 맞습니다.
• REST는 단순하고 브라우저 친화적인 반면 gRPC는 서버 간 통신에 강점이 있습니다.
• 바이너리 포맷은 성능에 유리하지만 사람이 직접 읽고 디버깅하기는 어렵습니다.
• 원문에 있는 최신 버전 숫자는 2023년 기준 정보이므로 실제 설치 전에는 공식 릴리즈를 다시 확인해야 합니다.

기존 글에는 장단점과 REST 비교가 이미 있었지만, 제목이 너무 짧고 최신 버전 표기가 시점성 정보라는 점이 드러나지 않았습니다. 이번 보강은 gRPC의 핵심 판단 기준을 앞에 두고, 오래된 버전 숫자를 그대로 믿지 않도록 안내했습니다.

이어서 볼 글

• Spring에서 gRPC연동하기 - Protocol Buffers와 stub 개념을 Spring 구현으로 옮긴 글이다.

 

개요

gRPC는 Google이 개발한 고성능, 오픈 소스 및 범용의 원격 프로시저 호출(RPC) 프레임워크입니다. 

효율적인 프로토콜로, 서버 간 통신에 아주 적합하며, Protocol Buffers를 사용하여 타입을 정의하고, 강력한 타입 검사와 높은 성능을 제공합니다.
이는 서로 다른 시스템 간에 통신을 가능하게 하며, 다양한 환경과 언어에서 작동합니다. 

gRPC는 2015년 3월에 Google이 Stubby의 다음 버전을 개발하고 오픈 소스로 만들기로 결정했을 때 처음 생성되었습니다. gRPC의 최초 릴리스는 2016년 8월에 이루어졌습니다​. 현재 gRPC의 최신 버전은 1.59.1(2023년 10월 6일기준)

장점:

• 기존의 REST등 텍스트 기반 프로토콜보다 더 효율적인 바이너리 프로토콜을 제공하여, 데이터 전송의 오버헤드를 줄이고 성능을 향상시킵니다.   
• 컨트랙트 첫 접근 방식: 서비스의 인터페이스와 메시지를 먼저 정의하고, 이를 기반으로 코드를 생성합니다.
  (Protocol Buffers를 사용하여 데이터를 직렬화하고 역직렬화하여, 높은 성능을 제공합니다.)
• 스트리밍 및 빠른 통신: 양방향 스트리밍과 빠른 통신을 지원하여, 실시간 애플리케이션에 이상적입니다.
• 비동기 콜도 지원하는 것 같다.
  
  

단점:

• 복잡성: gRPC는 설정과 디버깅이 복잡할 수 있으며, 새로운 사용자에게 진입 장벽을 제공할 수 있습니다.
• 텍스트 기반 포맷의 부족: gRPC는 바이너리 프로토콜을 사용하므로, 텍스트 기반 프로토콜보다 디버깅이 어려울 수 있습니다.
• 브라우저 지원: gRPC-Web을 통해 브라우저에서 gRPC를 사용할 수 있지만, 네이티브 gRPC 클라이언트보다 기능이 제한적일 수 있습니다.

vs REST

REST는 HTTP/1.1을 기반으로 하며, 텍스트 기반의 JSON 또는 XML을 사용하여 데이터를 전송합니다. 이에 비해 gRPC는 HTTP/2를 기반으로 하며, 바이너리 기반의 Protocol Buffers를 사용합니다.
gRPC는 REST보다 더 높은 성능과 더 낮은 데이터 오버헤드를 제공하지만, REST는 더 단순하고 더 넓게 지원됩니다.

spring과 연동하기

여기 참조

TMI

굳이 protobuf를 별도 포맷으로 했는데(yml, json, xml등을 사용하지 않고), verbose하지 않고 간결한 것이 장점인 것 같다. (다른 이유는 굳이 없는듯)

gRPC는 일반적으로 REST와 별개 포트로 구성(graphQL은 REST와 같은 포트로 보통하는듯)