RPC는 Remote Procedure Call의 약자이다.
그리고 gRPC는 Google Remote Procedure Call이다.
Google은 생각보다 더 우리의 생활 속에 깊이 들어와 있다.
신기술도 많이 만들고, 새로운 기술의 표준 또한 Google이 만든 것도 많다.
gRPC는 구글이 만든 기술, 규격 중에 하나라고도 볼 수 있다.
gRPC(Google Remote Procedure Call)은 Google에서 만든 오픈소스 프레임워크다.
서버와 클라이언트 간에 함수처럼 통신할 수 있게 해주는 RPC(Remote Procedure Call) 시스템이다.
다른 서버에 있는 함수나 메서드를 로컬에서 호출하듯 쉽게 호출할 수 있도록 도와주는 통신 방식이다.
gRPC는 이 과정에서 Protocol Buffer(프로토콜 버퍼)라는 직렬화 방식을 이용해, 데이터를 작고 빠르게, 효율적으로 전송할 수 있다.
gRPC라는 단어에서 살펴본다면, Procedure를 함수(Function)이나 메서드(Method) 같은 개념으로, 어떤 작업을 수행하는 명령어들의 집합이라고 이해하면 쉽게 이해할 수 있을 것이다.
gRPC는 Protocol Buffer를 사용한다. Protocol Buffers는 JSON 보다도 훨씬 빠른 바이너리(Binary) 형식의 데이터 직렬화 방식을 의미한다.
독특한 특징으로는, 명시된 틀을 넘어서 .proto라는 파일에 인터페이스를 정의하면, C++, Java, Go, Python 등 다양한 프로그래밍 언어로 클라이언트와 서버 코드를 자동 생성할 수 있다는 점도 있다.
또한 텍스트 기반의 HTTP/1.1 기반이 아니라, 구글이 참여하게 되면서 개발이 빨라진 HTTP/2 프로토콜을 사용해 다중 스트림, 헤더 압축, 양방향 스트리밍 등의 기능을 지원한다.
1:1 요청 응답은 물론, 서버가 스트림으로 응답하는 방식, 클라이언트가 스트림으로 전송하는 방식, 양방향으로 스트림 하는 방식 모두 지원하기 때문에 활용 가능성이 무척 높다.
gRPC와 REST API, 전통적인 RPC와 비교를 해보면 아래 표와 같다.
| REST API | gRPC | 전통 RPC | |
| 프로토콜 | HTTP/1.1 | HTTP/2 | TCP, HTTP |
| 형식 | JSON(텍스트) | Protocol Buffers (바이너리) | 바이너리 (언어 환경에 따라 다름) |
| 성능 | 비교적 느림 | 매우 빠름 | 빠름 |
| 호환성 | 높음 | 높음 | 낮음 |
| 스트리밍 | 제한 | 양방향 | 제한 |
| 코드 자동 생성 | 없음 | .proto | 인터페이스 기반 |
| 디버깅 | 쉬움 | 어려움 | 어려움 |
| 브라우저 지원 | 뛰어남 | 제한적 | 없음 |
| 사례 | 외부 API, 웹 서비스 | 마이크로서비스 | 내부 시스템 |
형식의 차이가 가장 크다고 볼 수 있는데, TEXT 기반인 REST API는 모든 언어와 환경에서 동일하기 때문에 호환성이 높고, 디버깅도 쉬우며, 브라우저 지원도 뛰어나다. 그렇기에 외부 서비스를 제공할 때는 지금도 API를 가장 많이 사용한다.
전통 RPC는 바이너리 형식으로 전송하기 때문에 성능이 빠르지만, 환경마다 전송 인터페이스가 달라서 호환성이 낮다. 기술에 따라서는 스트리밍도 가능하며, 코드 자동 생성도 가능하다. 따라서 과거 전통적인 환경에서 RPC를 채택해 기업 내부 시스템 등에서 통신용으로 많이 사용했었다.
gRPC는 HTTP/2라는 텍스트 기반 외 다른 미디어 전송이 효율적으로 확장된 프로토콜을 채택하였기에 속도가 매우 빠르고, 병렬처리가 가능하지만, 그만큼 gRPC를 지원하는 Web이 필요해 브라우저 지원이 제한적이다. 하지만, 표준 프로토콜이기 때문에 제한적이긴 하지만 브라우저 지원이 가능해 기존 RPC에 비해서 확장 가능성이 매우 높아진다. proto 파일을 통해 환경에 영향 없이 호환성이 높으면서도 코드 자동 생성이 가능하고, 양방향 스트리밍도 가능해 속도도 매우 빨라서, 하나의 프로젝트를 다양한 서비스로 분리해 서비스 간 통신에 사용하는 마이크로 서비스에 활용하면 무척 유용한 방식이다.
gRPC는 성능이 매우 뛰어나기 때문에 하나의 프로젝트에서 다양한 서비스를 제공할 때, 내부 통신용으로 사용할 때 최적이다. 위에서 언급한 대로 마이크로 서비스 간 내부 통신이 그 예이다.
대상 장비가 많고, 빠른 속도가 필요한 IoT에서도 활용하기 좋다.
그 외에도 모바일 환경, 채팅, 게임 서버, 실시간 스트리밍 같은 빠르면서도 스트리밍이 필요한 환경에서 채택해서 활용하면 좋을 것이다.
gRPC가 워낙 뛰어나다 보니, 다른 유사 API를 제쳐놓고 gRPC만 쓰면 되지 않을까?
아쉽지만, gRPC도 만능은 아니다. 아무래도 비교적 최신 기술이다 보니, gRPC-Web이 없는 브라우저에서 바로 사용할 수 없다는 단점이 있다.
또 최종적으로 바이너리 형식으로 전송되기 때문에 디버깅이 어렵고, 로그 분석이 복잡할 수 있으며, 일부 방화벽 환경에서는 HTTP/2가 차단될 수 있어서 좀 더 자리 잡을 필요가 있다.
REST API보다 처음에 배우기 어렵다는 점도, 단점이라면 단점이다.
데이터 용량도 작으면서 빠른 속도를 가지고 있으며, 다양한 언어를 지원하면서, 양방향 스트리밍 기능까지 갖춘 gRPC는 마이크로 서비스 환경에서 REST API를 대체할 강력한 옵션으로 떠올랐다. 고성능이 필요한 시스템이나 대규모 서비스에서는 필수 선택지로 자리 잡았다고 볼 수 있다.
하지만, 어디서 어떻게 접근할지 모르며, 미묘한 성능의 차이는 중요하지 않다면, 외부로 나가는 서비스는 REST API를 혼용해서 활용하는 방법도 좋은 선택지가 될 것이다.
#RPC #gRPC #Google #RemoteProcedureCall #API #RESTAPI #마이크로서비스
'IT 정보 > 용어' 카테고리의 다른 글
| 디버깅이란? IT 개발자가 문제를 개선하는 가장 효율적인 방법? (2) | 2025.04.13 |
|---|---|
| 토폴리지란? 장소의 연구, 네트워크에서 많이 쓰이는 용어 (0) | 2025.04.12 |
| 소켓 프로그래밍이란? 네트워크 통신 프로그래밍의 핵심 기본 기술 (2) | 2025.04.10 |
| HTTP HTTPS는 뭘까? 웹의 기본 이해하기 (0) | 2025.04.09 |
| JSON이란? 비동기 통신의 필수 요소? (0) | 2025.04.08 |
