gRPC와 REST, 언제 무엇을 써야 할까

REST와 gRPC란 무엇인가

REST는 HTTP 프로토콜 위에서 URL과 메서드(GET, POST 등)로 자원을 주고받는 통신 방식입니다. 데이터는 보통 JSON으로 표현되며, 사람이 읽기 쉽고 브라우저에서 바로 테스트할 수 있어 웹 API의 표준처럼 자리 잡았습니다.

gRPC는 구글이 만든 원격 프로시저 호출(RPC) 프레임워크로, HTTP/2 위에서 동작하며 데이터를 Protocol Buffers라는 이진 포맷으로 직렬화합니다. 함수를 부르듯 getUser(id) 형태로 서버의 메서드를 직접 호출하는 느낌을 줍니다.

동작 원리와 차이 예시

비유하자면 REST는 ‘편지 봉투에 정해진 양식의 문서를 넣어 보내는 것’과 비슷합니다. 봉투(HTTP 요청)를 열고 문서(JSON)를 파싱해야 내용을 알 수 있죠. 반면 gRPC는 ‘미리 정해둔 규격의 부품을 조립 라인에서 바로 넘기는 것’에 가깝습니다. .proto 파일로 메시지와 서비스 구조를 미리 정의하면, 이를 기반으로 클라이언트와 서버 코드가 자동 생성되어 타입 안정성이 높아집니다.

또한 gRPC는 HTTP/2의 멀티플렉싱을 활용해 하나의 연결로 여러 요청을 동시에 처리하고, 스트리밍(양방향 실시간 데이터 전송)도 기본 지원합니다. REST는 일반적으로 요청-응답 한 번에 하나의 작업을 처리하는 구조라 실시간 스트리밍에는 추가적인 기술(WebSocket 등)이 필요합니다.

실무에서는 언제 무엇을 선택할까

  • REST: 외부에 공개하는 API, 브라우저에서 직접 호출해야 하는 서비스, 팀 간 문서화와 디버깅이 중요한 경우
  • gRPC: 내부 마이크로서비스 간 통신처럼 빠른 속도와 낮은 지연이 중요한 경우, 실시간 스트리밍이 필요한 경우, 여러 언어로 작성된 서비스 간 타입 안정성을 확보하고 싶은 경우

예를 들어 넷플릭스나 우버 같은 대규모 마이크로서비스 아키텍처에서는 내부 통신에 gRPC를 쓰고, 외부 개발자나 프론트엔드와의 접점에는 REST(또는 GraphQL)를 함께 쓰는 하이브리드 전략이 흔합니다. 결국 선택 기준은 ‘누가 이 API를 호출하는가’와 ‘성능이 얼마나 중요한가’에 달려 있습니다.

댓글 남기기