[gRPC] gRPC vs REST

gRPC vs REST

1. RPC(Remote Procedure Call)란?

• 정의: 원격 프로시저 호출. 네트워크로 연결된 다른 서버의 함수/메서드를 마치 로컬 환경의 함수처럼 직접 호출하는 기술
• 특징: 개발자가 소켓 통신, 직렬화/역직렬화 같은 하위 네트워크 계층을 직접 다루지 않고도 원격 메서드를 실행할 수 있도록 추상화 제공

---

2. REST vs gRPC 핵심 개념

REST (Representational State Transfer)

• 웹의 표준 아키텍처 스타일로, 자원(Resource) 중심의 통신 방식
• URI로 자원을 명시하고, HTTP 메서드(GET, POST, PUT, DELETE)를 통해 행위를 정의
• 데이터 포맷으로 주로 사람이 읽기 쉬운 JSON을 사용
• 브라우저 호환성이 뛰어나고 직관적이지만, 텍스트 기반 직렬화/역직렬화 오버헤드가 발생하며 기본적으로 단방향(Request-Response) 통신 위주

gRPC (Google Remote Procedure Call)

• 구글이 개발한 고성능 오픈소스 RPC 프레임워크로, 동작(Action/Procedure) 중심의 통신 방식
• 전송 계층으로 HTTP/2를 채택하여 멀티플렉싱(Multiplexing), 헤더 압축 지원
• 데이터 직렬화에 바이너리 포맷인 Protocol Buffers(Protobuf)를 사용하여 페이로드 크기가 작고 속도가 빠름
• IDL(.proto 파일)을 기반으로 다양한 언어의 통신 코드(Stub/Skeleton)를 자동 생성해 엄격한 타입 안정성(Type-safe) 제공
• 단항(Unary) RPC뿐만 아니라 양방향 스트리밍(Bidirectional Streaming) 지원

---

3. 핵심 비교 요약

비교 항목	REST API	gRPC
중심 설계	자원(Resource) 중심	행위/프로시저(Action) 중심
전송 프로토콜	HTTP/1.1 (일부 HTTP/2)	HTTP/2
데이터 포맷	JSON, XML (텍스트 기반)	Protocol Buffers (바이너리 기반)
통신 패턴	요청-응답 (Request-Response)	단항(Unary), 서버/클라이언트/양방향 스트리밍
인터페이스 정의	OpenAPI/Swagger (선택적)	.proto 파일 (필수, 엄격한 스키마)
코드 생성	서드파티 툴 필요	Protoc 컴파일러를 통한 공식 자동 생성
브라우저 지원	네이티브 지원 (우수)	제한적 (gRPC-Web 프록시 필요)
디버깅 난이도	텍스트 기반이라 도구 없이도 확인 용이	바이너리 데이터로 전용 도구(BloomRPC 등) 필요

---

4. 언제 어떤 기술을 선택해야 할까?

• REST API를 권장하는 경우:

  • 공개 API(Public API), 웹 프론트엔드-백엔드 간 통신처럼 범용적인 클라이언트 호환성이 필요할 때
  • 인프라 설정이 간단하고, 표준 브라우저 환경에서 직접 호출해야 할 때
  • 캐싱(HTTP Caching)을 적극적으로 활용해야 하는 정적/준정적 리소스 중심 서비스

• gRPC를 권장하는 경우:

  • MSA(마이크로서비스 아키텍처) 환경에서 내부 서비스 간의 고성능·저지연 통신이 필수적일 때
  • 대용량 데이터 전송이나 실시간 스트리밍(양방향 데이터 동기화)이 필요할 때
  • Polyglot(다양한 개발 언어 사용) 환경에서 엄격한 스키마 공유와 타입 안정성을 유지하고 싶을 때

---

References

• gRPC Official Documentation
• AWS: What's the Difference Between gRPC and REST APIs?
• GeeksforGeeks: Remote Procedure Call (RPC) in Operating System