gRPC란 무엇인가

마이크로서비스 수십 개가 초당 수만 번씩 서로를 호출하는 환경에서는, 통신 한 번의 비용이 시스템 전체의 속도를 좌우한다. 텍스트 기반 JSON을 주고받는 방식이 사람에게는 친절하지만 기계끼리의 고빈도 통신에는 군더더기가 많다는 문제의식, 바로 여기서 gRPC가 출발한다. 구글이 만든 이 고성능 통신 프레임워크는 넷플릭스·우버 같은 대규모 서비스의 내부 통신을 떠받치는 사실상의 표준으로 자리 잡았다. 이 글은 gRPC의 정의와 등장 배경, Protocol Buffers·HTTP/2라는 두 기둥, 네 가지 통신 방식, 그리고 REST·GraphQL과의 차이와 솔직한 한계까지 입문자 눈높이에서 정리한다. 앞서 다룬 REST API란 무엇인가, GraphQL이란 무엇인가 글과 함께 읽으면 세 가지 API 방식의 트레이드오프가 한눈에 잡힐 것이다.

gRPC는 구글이 개발한 고성능 오픈소스 RPC(원격 프로시저 호출) 프레임워크다. 풀어 말하면, 다른 서버에 있는 함수를 마치 내 코드 안의 함수처럼 호출할 수 있게 해 주는 기술이다. gRPC 공식 문서는 이를 “클라이언트 애플리케이션이 마치 로컬 객체인 것처럼 다른 머신의 서버 애플리케이션 메서드를 직접 호출할 수 있어, 분산 애플리케이션과 서비스를 더 쉽게 만들 수 있다”고 정의한다.

이름의 ‘RPC’가 핵심이다. RPC(Remote Procedure Call, 원격 프로시저 호출) 는 네트워크 너머의 함수를 로컬 함수처럼 부르는 오래된 통신 패러다임으로, gRPC는 여기에 현대적인 전송 기술과 직렬화 방식을 결합한 것이다. 흔히 ‘g’가 구글(Google)을 뜻한다고 오해하지만, gRPC 프로젝트는 각 릴리스마다 ‘g’의 의미를 ‘good’, ‘green’, ‘glorious’ 식으로 바꿔 붙이는 농담을 이어 왔다.

gRPC는 2015년 구글이 자사 내부에서 10여 년간 써 온 ‘Stubby’라는 RPC 시스템을 다듬어 오픈소스로 공개하면서 세상에 나왔다. 현재는 리눅스 재단 산하 CNCF(Cloud Native Computing Foundation) 가 호스팅하는 프로젝트로, 특정 기업 소유가 아닌 공개 표준의 성격을 띤다. 공식 문서 기준 C++·C#/.NET·Go·Java·Kotlin·Node·Python·Ruby·Rust·Swift·Dart·PHP·Objective-C 등 다양한 언어를 지원해, 서로 다른 언어로 작성된 서비스끼리도 매끄럽게 통신할 수 있다.

gRPC를 떠받치는 두 기둥 — Protocol Buffers와 HTTP/2

gRPC의 성능은 두 가지 핵심 기술 위에 선다. 데이터를 표현하는 Protocol Buffers, 그리고 그것을 실어 나르는 HTTP/2다.

Protocol Buffers — 계약서이자 직렬화 포맷

gRPC는 기본적으로 Protocol Buffers(줄여서 Protobuf) 를 사용한다. Protocol Buffers 공식 문서는 이를 “언어 중립적·플랫폼 중립적이며 확장 가능한, 구조화된 데이터 직렬화 메커니즘”이라 정의하며 “JSON과 비슷하지만 더 작고 빠르며, 네이티브 언어 바인딩을 생성한다”고 설명한다.

Protobuf의 출발점은 .proto 확장자를 가진 파일이다. 개발자는 여기에 주고받을 데이터의 구조와 서비스 메서드를 한 번만 정의하고, protoc라는 컴파일러로 각 언어용 코드를 자동 생성한다. 이 .proto 파일이 곧 클라이언트와 서버가 공유하는 인터페이스 정의 언어(IDL) 이자 계약서 역할을 한다.

syntax = "proto3";

message User {
  int32 id = 1;
  string name = 2;
  string email = 3;
}

service UserService {
  rpc GetUser (UserRequest) returns (User);
}

핵심은 직렬화 방식의 차이다. REST가 흔히 쓰는 JSON은 사람이 읽을 수 있는 텍스트지만, Protobuf는 데이터를 바이너리(binary) 로 압축해 전송한다. 같은 정보라도 전송량이 작고 파싱 속도가 빨라, 고빈도 내부 통신에서 부담이 줄어든다. 다만 공식 문서도 “메시지가 수 메가바이트를 넘어서면 메모리 문제가 생길 수 있고, 기본적으로 압축되지 않는다”는 한계를 명시하니 만능은 아니다.

HTTP/2 — 멀티플렉싱과 스트리밍의 토대

gRPC는 전송 계층으로 구형 HTTP/1.1이 아닌 HTTP/2를 사용한다. HTTP/2는 하나의 연결(connection) 위에서 여러 요청·응답을 동시에 주고받는 멀티플렉싱(multiplexing), 헤더 압축, 양방향 스트리밍을 지원하는 바이너리 프로토콜이다. MDN의 HTTP/2 설명에 따르면 HTTP/2는 단일 TCP 연결에서 병렬 요청을 처리해 HTTP/1.1의 고질적인 대기 지연(head-of-line blocking)을 크게 완화한다. gRPC가 네 가지 통신 방식, 특히 스트리밍을 구현할 수 있는 것도 바로 이 HTTP/2 덕분이다.

gRPC의 4가지 통신 방식

gRPC가 단순 요청·응답을 넘어 강력한 이유는 네 가지 통신 패턴을 모두 지원하기 때문이다. .proto에 메서드를 어떻게 선언하느냐에 따라 결정된다.

단방향(Unary) RPC: 가장 기본 형태. 클라이언트가 요청 하나를 보내면 서버가 응답 하나를 돌려준다. REST의 일반적인 요청과 가장 닮았다.
서버 스트리밍(Server streaming) RPC: 클라이언트가 요청 하나를 보내면, 서버가 응답을 여러 개 연속으로 흘려보낸다. 대용량 목록이나 실시간 피드 전송에 적합하다.
클라이언트 스트리밍(Client streaming) RPC: 반대로 클라이언트가 데이터를 여러 번 나눠 보내고, 서버가 마지막에 응답 하나로 정리한다. 파일 업로드나 센서 데이터 수집 같은 경우다.
양방향 스트리밍(Bidirectional streaming) RPC: 클라이언트와 서버가 각자 독립적으로 메시지를 주고받는다. 채팅이나 실시간 협업처럼 동시 양방향 통신이 필요한 곳에 쓰인다.

service ChatService {
  rpc Send (Message) returns (Ack);                       // 단방향
  rpc Subscribe (Topic) returns (stream Message);         // 서버 스트리밍
  rpc Upload (stream Chunk) returns (UploadResult);       // 클라이언트 스트리밍
  rpc Chat (stream Message) returns (stream Message);     // 양방향 스트리밍
}

stream 키워드 하나로 통신 방식을 바꿀 수 있다는 점이 Protobuf 기반 설계의 깔끔함을 보여 준다.

gRPC vs REST vs GraphQL — 무엇이 다른가

세 가지 API 방식의 성격을 한눈에 비교하면 다음과 같다. (REST API의 6대 제약, GraphQL의 쿼리 구조는 별도 글에서 자세히 다뤘다.)

구분	gRPC	REST	GraphQL
데이터 포맷	Protobuf(바이너리)	주로 JSON(텍스트)	주로 JSON(텍스트)
전송 프로토콜	HTTP/2	주로 HTTP/1.1	HTTP
계약 정의	`.proto`(강타입)	별도 규약 필요	스키마(강타입)
스트리밍	네 가지 방식 기본	제한적	서브스크립션
브라우저 직접 호출	제한적(gRPC-Web 필요)	자유로움	자유로움
주 사용처	서비스 간 내부 통신	공개 API·웹	복합 프런트엔드

구글 클라우드의 비교 문서는 gRPC가 “내부 마이크로서비스 간 저지연·고처리량 통신에 특히 적합하다”고 정리한다. 핵심은 우열이 아니라 용도다. 외부 개발자가 브라우저로 접근하는 공개 API라면 REST가, 데이터 요구가 복잡한 프런트엔드라면 GraphQL이, 그리고 백엔드 서비스끼리의 빠른 내부 통신이라면 gRPC가 각자의 자리를 갖는다.

gRPC의 한계와 단점

균형을 위해 단점도 분명히 짚어야 한다. gRPC는 모든 상황의 정답이 아니다.

브라우저 직접 지원이 약하다: 웹 브라우저는 HTTP/2의 저수준 기능을 자바스크립트에서 완전히 제어하지 못해, gRPC를 그대로 호출하기 어렵다. 별도의 gRPC-Web 계층이나 프록시가 필요하다. 공개 웹 API로 쓰기엔 부담스러운 지점이다.
사람이 읽기 어렵다: 바이너리 포맷이라 통신 내용을 눈으로 확인하거나 디버깅하기가 JSON보다 까다롭다. 별도 도구(grpcurl 등)가 있어야 편하다.
러닝 커브와 생태계: .proto 정의, 코드 생성 파이프라인, HTTP/2 인프라 등 익혀야 할 요소가 REST보다 많다. Postman의 비교 글도 gRPC의 성능 이점이 학습·운영 비용을 동반한다고 지적한다.
캐싱: REST가 URL과 HTTP 상태 코드로 누리는 브라우저·CDN 캐싱을 그대로 활용하기 어렵다.

정리하면, gRPC가 주는 속도와 강타입 계약의 대가로 도구·인프라 측면의 진입 장벽이 따라온다. 도입 전에 “이 통신이 정말 그만한 성능을 요구하는가?”를 먼저 물어야 하는 이유다.

gRPC, 언제 써야 하나

정리하면, gRPC는 Protocol Buffers의 바이너리 직렬화와 HTTP/2의 멀티플렉싱을 결합해 RPC 통신을 고속·고효율로 끌어올린 프레임워크다. 강타입 .proto 계약과 네 가지 통신 방식이 서비스 간 내부 통신에서 특히 빛을 발한다.

그렇다면 모든 API를 gRPC로 바꿔야 할까? 그렇지 않다. 마이크로서비스끼리 초당 수많은 호출을 주고받는 내부 통신, 실시간 스트리밍, 여러 언어가 섞인 폴리글랏 환경이라면 gRPC의 성능이 비용을 정당화한다. 반대로 외부 개발자가 브라우저로 접근하는 공개 API라면 검증된 REST API가, 화면마다 데이터 조합이 복잡한 프런트엔드라면 GraphQL이 더 무난한 선택이다. 실제로 많은 조직이 외부엔 REST, 내부엔 gRPC를 함께 쓰는 하이브리드 구성을 택한다.

여러분이 지금 설계 중인 통신은 시스템 내부의 고빈도 호출인가, 아니면 외부에 공개하는 자원 조회인가? 도구의 유행이 아니라 통신의 성격을 기준으로 고르는 것이 핵심이다. 기술 환경과 팀 역량에 따라 최적의 선택은 달라질 수 있으니, 본 정리는 판단의 출발점으로 활용하길 권한다.