gRPC vs REST: API 통신, 무엇을 언제 쓰나

REST가 기본이지만, gRPC가 필요한 순간

공개 API를 만들 때 REST는 여전히 좋은 기본값입니다. 사람이 읽기 쉽고, 브라우저에서 바로 부를 수 있고, 도구도 풍부하니까요. 그런데 서비스가 잘게 쪼개지고 그들 사이의 호출이 폭발적으로 늘면, 텍스트를 주고받되 하나의 연결로 요청을 동시에 흘려보내기 어려운 방식의 비용이 커집니다. 이 지점에서 gRPC가 등장합니다.

둘은 우열의 문제가 아닙니다. 누가 이 API를 부르는가, 그리고 무엇을 주고받는가에 따라 답이 갈립니다. 브라우저나 외부 개발자가 부른다면 REST가, 내부 서비스들이 빠르게 주고받아야 한다면 gRPC가 어울립니다. 먼저 각각이 무엇인지부터 보겠습니다.

gRPC: HTTP/2와 계약 우선

gRPC는 고성능 RPC(원격 프로시저 호출) 프레임워크로, 다른 머신의 서버 메서드를 마치 로컬 함수처럼 호출하게 해 줍니다. 핵심 특징은 세 가지입니다.

• HTTP/2 기반: HTTP/2의 멀티플렉싱과 스트림 위에서 동작합니다. 하나의 연결로 여러 요청을 동시에 처리하고, 단일 요청부터 서버·클라이언트·양방향까지 네 가지 방식을 제공합니다.

• Protocol Buffers(protobuf): 기본 직렬화로 사용하며, 데이터를 사람이 읽는 텍스트가 아니라 바이너리로 다룹니다. 공식 설명대로 JSON과 비슷하되 더 작고 빠릅니다.

• 계약 우선(contract-first): .proto 파일에 서비스와 메시지를 먼저 정의하면, 거기서 여러 언어의 클라이언트·서버 코드를 생성합니다. 서로 다른 언어로 짜인 서비스도 같은 계약으로 맞물립니다.

이 조합 덕분에 gRPC는 여러 언어가 섞인 내부 서비스들이 빠르게, 그리고 엄격한 규격으로 통신해야 하는 환경에 강합니다. 참고로 gRPC는 구글이 사내 마이크로서비스를 잇던 인프라에서 출발했습니다.

REST: 자원 기반 스타일

REST는 프레임워크가 아니라 아키텍처 스타일(설계 제약의 집합)입니다. 데이터를 자원으로 보고 URL로 표현하며, HTTP 메서드로 다룹니다. 여기서 한 가지 오해를 짚겠습니다. REST와 JSON은 같은 말이 아닙니다. JSON은 REST에서 흔히 쓰는 데이터 형식일 뿐, REST 자체는 형식을 규정하지 않습니다. 또 HTTP API라고 해서 모두 REST 제약을 지키는 것도 아닙니다.

REST의 강점은 보편성입니다. 사람이 읽기 쉬운 텍스트를 주고받고, 브라우저에서 바로 호출할 수 있으며, 캐시와 도구 생태계가 폭넓습니다. 그래서 외부에 공개하는 API, 브라우저가 직접 부르는 인터페이스에 잘 맞습니다.

가장 큰 갈림길은 브라우저

표에서 하나만 꼽으라면 브라우저 접근입니다. gRPC는 브라우저에서 곧바로 호출할 수 없습니다. 브라우저에는 HTTP/2 프레임을 그대로 제어할 API가 없어서, gRPC의 규격을 브라우저에서 그대로 구현할 수 없기 때문이죠. 그래서 gRPC-Web이라는 변형과 이를 변환해 주는 프록시(기본값은 Envoy)를 함께 둬야 합니다. 반면 REST는 브라우저의 fetch로 아무 준비 없이 바로 부를 수 있습니다.

정리하면 이렇습니다. 내부 서비스들 사이의 빠른 통신이 목표라면 gRPC의 바이너리·스트리밍·계약이 빛나고, 브라우저와 외부가 부르는 공개 인터페이스라면 REST의 보편성과 편의가 앞섭니다. 실제로 많은 시스템이 둘을 함께 씁니다. 바깥은 REST로 열어 두고, 안쪽 서비스끼리는 gRPC로 잇는 식이죠. 성능 차이는 데이터와 환경에 따라 달라지므로, "무조건 빠른 쪽"이 아니라 "누가 부르는가"부터 보는 것이 실용적입니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)