gRPC와 REST: 작은 호출은 빠르고 큰 응답은 격차 축소

짧은 요청을 자주 주고받는 내부 마이크로서비스라면 gRPC를 우선 검토할 만하다. 브라우저와 여러 외부 개발자가 이용할 공개 API라면 HTTP 기반 REST API가 출발점으로 적합한 경우가 많다. KTH의 마이크로서비스 비교 연구에서는 gRPC 구현이 작은 메시지에서 앞섰지만, 큰 요청을 되돌려 보내는 시험에서는 REST 구현과의 성능 격차가 줄었다. 이는 연구에 사용된 구현과 로컬 시험 환경의 결과다.

양쪽이 연결을 유지하며 메시지를 주고받아야 한다면 gRPC의 양방향 스트리밍이 선택을 바꿀 수 있다. 반대로 큰 응답이 주된 작업이라면 작은 호출에서 얻은 속도 차이를 그대로 기대하기 어렵다. 호출자의 환경, 메시지 크기, 계약 변경 방식과 장애를 추적하는 방법을 함께 놓고 판단해야 한다.

네 가지 사용 상황에서 무엇을 고를까

외부 공개 API: 호출자가 다양하고 브라우저 접근이 중요하다면 REST API를 기본안으로 두는 편이 실용적이다. HTTP 요청과 응답을 외부에 설명하기 쉽고, 이용자가 생성 클라이언트를 반드시 받아들일 필요도 없다.
작은 내부 단항 호출: 짧은 요청과 응답을 반복하고 호출 양쪽의 코드를 함께 관리할 수 있다면 gRPC가 유력하다. 성능뿐 아니라 메서드와 메시지 형식을 공유하는 계약도 선택 이유가 된다.
양방향 스트리밍: 클라이언트와 서버가 같은 논리적 흐름에서 각자 메시지를 계속 보내야 한다면 gRPC가 그 통신 형태를 직접 제공한다. 브라우저가 참여하는 경우에는 별도의 접근 경로를 고려해야 한다.
큰 메시지: 요청과 응답의 본문이 커지면 짧은 호출의 벤치마크만으로 이득을 예측하기 어렵다. 실제 데이터 크기와 서버 처리 시간을 반영한 측정이 필요하다.

이 분류는 서로 배타적인 시스템 설계를 뜻하지 않는다. 공개 경계에는 REST API를 두고 내부 서비스 사이에는 gRPC를 사용할 수 있다. 그 경우 외부 HTTP 계약과 내부 메서드 계약을 연결하는 계층이 생기므로, 변환 규칙과 오류 전달을 함께 관리해야 한다. 한쪽의 속도만 비교하면 이 운영 비용을 놓치기 쉽다.

작은 내부 호출에는 계약을 함께 배포할 수 있는가

gRPC는 원격 메서드의 인자와 반환값을 서비스 정의에 명시하는 방식이다. gRPC 핵심 개념 문서는 기본 인터페이스 정의에 Protocol Buffers를 사용하며, 서비스 정의에서 클라이언트와 서버 코드를 생성하고 단항 호출과 여러 스트리밍 호출 형태를 제공한다고 설명한다. 호출 양쪽이 같은 정의를 사용하면 필드 이름과 자료형을 계약으로 공유할 수 있다.

단항 호출은 요청 하나에 응답 하나를 받는다. 예를 들어 주문 서비스가 재고 서비스에 상품 상태를 묻는 상황을 가정하면, 양쪽에서 같은 메시지 정의에 맞춘 코드를 배포할 수 있다. 이때 생성 코드의 이점은 요청을 보내는 코드가 짧아지는 데 그치지 않는다. 어떤 메서드가 어떤 데이터를 받고 돌려주는지 서비스 사이에서 명시적으로 맞출 수 있다.

대신 서비스별 배포 시점이 다르면 계약 변경 절차가 중요해진다. 새 필드를 추가하거나 메서드를 바꿀 때 기존 호출자가 어떤 정의를 쓰는지 알아야 하고, 생성 코드를 언제 갱신할지도 정해야 한다. 서로 다른 언어로 작성된 내부 서비스가 많을수록 이 공통 계약의 가치는 커질 수 있지만, 정의 파일의 배포와 호환성 관리는 실제 운영 업무로 남는다.

속도 측면에서도 통신에 쓰는 시간이 전체 요청의 어느 부분인지 구분해야 한다. 데이터베이스 조회나 외부 서비스 대기가 대부분을 차지한다면 메시지 직렬화 시간을 줄여도 전체 지연은 조금만 달라질 수 있다. 반면 짧은 본문을 높은 빈도로 주고받는 경로라면 전송과 직렬화의 차이가 더 잘 드러날 수 있다. 두 경우를 같은 ‘내부 API’라는 이름으로 묶어 결론 내리기는 어렵다.

큰 응답에서 성능 격차를 어떻게 해석할까

KTH 연구는 같은 상품 정보 기능에 서로 다른 API 인터페이스를 붙여 비교했다. 짧은 설명 문자열을 되돌리는 호출과 매우 긴 설명 문자열을 되돌리는 호출이 포함됐으며, REST 구현은 JSON을 사용했다. 큰 메시지 시험에서는 요청에 담긴 긴 설명이 응답에도 실렸기 때문에, 결과를 ‘큰 응답만 보낸 시험’으로 좁혀 읽어서는 안 된다. 연구의 결론은 이 구성에서 gRPC가 앞서되 메시지가 커질수록 우위가 감소했다는 것이다.

그 차이를 곧바로 Protocol Buffers와 JSON만의 차이로 돌릴 수도 없다. 연구에는 각 방식의 서버와 클라이언트 구현, 직렬화, 전송 방식, 부하 생성기가 함께 들어간다. 로컬 환경에서 단순한 상품 정보 기능을 반복 호출한 결과이므로, 인증 경로와 네트워크가 다른 서비스에 같은 수치를 적용하기 어렵다. 그렇지만 큰 본문을 다루는 API의 도입 근거로 작은 본문 시험만 제시해서는 부족하다는 점은 분명하다.

큰 응답이 많은 서비스에서는 서버가 결과를 만드는 시간, 직렬화된 본문의 크기, 압축 여부와 전송 대기 시간을 나눠 보는 편이 유용하다. 예를 들어 결과 생성이 오래 걸리는 서비스라면 통신 방식을 바꾸기 전에 그 시간이 전체 지연에서 차지하는 비중을 알아야 한다. 결과를 한꺼번에 받아야 하는지도 중요하다. 순서대로 소비할 수 있는 데이터라면 스트리밍 설계가 첫 결과를 받는 시점을 바꿀 수 있지만, 그것은 단항 호출의 속도 비교와는 다른 질문이다.

공개 API와 브라우저에서는 접근 경로가 달라진다

공개 HTTP API 접근 경로와 gRPC-Web을 거쳐 내부 gRPC 서비스에 연결되는 경로의 차이

공개 API는 불특정 이용자가 계약을 이해하고 자신의 도구로 호출할 수 있어야 한다. OpenAPI 명세는 HTTP API의 기능을 사람과 도구가 이해할 수 있는 언어 독립적 설명으로 정의한다. 경로와 작업, 요청과 응답을 기계가 읽을 수 있는 계약으로 전달할 수 있다는 점은 외부 개발자에게 API를 공개할 때 유용하다. OpenAPI가 곧 JSON 전송을 강제하는 것은 아니므로, 계약 형식과 메시지 본문 형식은 구별해야 한다.

브라우저 이용자가 있다면 서버끼리 쓰는 gRPC 호출 경로를 그대로 전제해서는 안 된다. gRPC-Web 브라우저 사용 예제는 별도 클라이언트 코드를 생성하고 Envoy 프록시를 거쳐 백엔드 gRPC 서비스에 요청을 전달한다. 이 경로를 택하면 프록시 구성과 브라우저의 교차 출처 요청 설정도 배포 범위에 들어온다.

외부 파트너가 제한돼 있고 모두 생성 클라이언트를 사용할 수 있다면 gRPC 공개 API도 검토할 수 있다. 다만 파트너별 언어와 실행 환경, 계약 갱신 주기를 함께 맞춰야 한다. 반대로 호출자가 다양하고 간단한 HTTP 요청을 기대한다면 REST API가 통합 부담을 낮출 가능성이 높다. 선택의 핵심은 어느 방식이 더 현대적인지가 아니라 이용자가 실제로 접근할 수 있는 경로와 계약을 제공하는지다.

양방향 스트리밍에는 어떤 운영 조건이 붙는가

gRPC 양방향 스트림에서 메시지가 오가고 추가 호출이 대기할 수 있는 연결 구조

클라이언트와 서버가 서로 독립적인 순서로 메시지를 보내는 작업에는 gRPC 양방향 스트리밍이 맞는다. 예를 들어 내부 처리 상태를 계속 전달하면서 제어 메시지를 받는 상황을 가정할 수 있다. 서버가 결과만 차례로 보내면 서버 스트리밍으로 충분할 수 있고, 요청 하나에 결과 하나만 필요하다면 단항 호출이 더 단순하다. 반복 호출이라는 이유만으로 모두 스트림으로 바꿀 필요는 없다.

gRPC 성능 권장 사항은 오래 지속되는 데이터 흐름에 스트리밍을 사용하되, 시작된 스트림은 부하 분산을 다시 적용하기 어렵고 장애를 디버깅하기도 까다롭다고 설명한다. 같은 연결에서 활성 스트림의 한도에 도달하면 추가 호출이 클라이언트에서 대기할 수도 있다. 따라서 스트림이 오래 유지되는 서비스는 단순한 평균 응답 시간만으로 상태를 파악하기 어렵다.

운영 중에는 호출의 시작과 종료뿐 아니라 취소, 장시간 대기, 중간 실패를 구분해 관측할 필요가 있다. 오류가 스트림 도중에 발생했는지, 새 호출이 연결의 수용 한도를 기다리는지에 따라 대응이 달라지기 때문이다. 내부 단항 호출의 속도, 공개 API의 접근성, 지속 연결의 운영 난도는 각각 다른 비용이다. 이 비용을 실제 호출 형태에 맞춰 비교해야 프로토콜 선택이 서비스의 요구와 맞아떨어진다.

함께 읽기: