gRPC vs. REST

인터넷이라는 거대한 지도에서 애플리케이션 프로그래밍 인터페이스(API)는 도시, 마을, 해변 및 기타 목적지를 연결하는 도로입니다. API를 통해 소프트웨어 애플리케이션은 서로 통신하여 데이터, 특징 및 기능을 교환할 수 있습니다. 2023년 Imperva 보고서 에 따르면 인터넷 트래픽의 약 71%가 API 호출로 구성되어 있으며, 이는 이 기술이 최신 애플리케이션과 기업의 작동에 얼마나 중요한지 보여줍니다.

API를 구축하는 방법을 이해하는 것은 대부분의 개발자에게 필수적인 기술입니다. 하지만, 이처럼 중요한 인프라에 걸맞게 다양한 유형이 존재합니다.

비유를 해보자면, 12차선 고속도로가 단일 차선의 일반 도로보다 항상 '더 나은' 것은 아닙니다. 넓은 고속도로는 기존의 도시 지역 구조를 파괴할 수 있고, 좁은 일반 도로는 교통량이 많은 지역에선 재앙과도 같을 것입니다. REST 및 gRPC와 같은 API 구축을 위한 다양한 아키텍처 스타일도 마찬가지입니다. 각각 강점과 약점이 있으며, 이러한 강점과 약점을 이해하는 것은 건강한 인프라를 구축하는 데 필수적입니다.

REST(Representational State Transfer)는 일관된 인터페이스, 클라이언트-서버 결합, 무상태(statelessness), 캐싱 가능성(cacheability), 계층화된 시스템 아키텍처 및 온디맨드 코드(선택 사항)와 같은 일련의 설계 원칙(또는 아키텍처 제약 조건)입니다. 이러한 원칙을 사용하여 구축된 API를 REST API 또는 RESTful API라고 합니다.

REST API는 REST 원칙을 준수하는 경우 다양한 프로그래밍 언어와 데이터 형식을 사용할 수 있습니다. 이는 API를 구성하는 가장 일반적인 방법입니다.

REST API는 GET, POST, PUT 및 DELETE와 같은 HTTP 요청(HTTP 메서드라고도 함)을 사용하여 표준 데이터베이스 기능을 수행합니다. 이러한 작업은 리소스 레코드를 생성, 읽기, 업데이트 및 삭제하는 데 사용되며, "CRUD"라고도 합니다. 서버 측 리소스는 엔드포인트라는 URL로 식별됩니다.

예를 들어 REST API는 GET 요청을 사용하여 레코드를 검색하며, POST 요청은 새 레코드를 생성합니다. PUT 요청은 레코드를 업데이트하고 DELETE 요청은 레코드를 삭제합니다. API 호출에는 모든 HTTP 방식을 사용할 수 있습니다. 잘 설계된 REST API는 HTTP 기능이 내장된 웹 브라우저에서 실행되는 웹 사이트와 같습니다.

리소스 정보는 JSON(JavaScript Object Notation), HTML, XLT, Python, PHP 또는 일반 텍스트를 포함한 다양한 메시징 형식으로 클라이언트에 전달될 수 있습니다. JSON은 사람과 기계가 모두 읽을 수 있고 프로그래밍 언어에 구애받지 않기 때문에 널리 사용됩니다.

REST와 GraphQL에 대해 자세히 알아보기

브라우저 지원: REST API는 HTTP/1.1 및 표준 HTTP 메서드는 물론 XML 및 JSON과 같은 형식을 사용하기 때문에 브라우저와 호환됩니다. 

사용의 용이성: 단순성과 대중성으로 인해 REST는 특히 초보자가 이해하기 쉬운 것으로 널리 알려져 있습니다. GitHub 및 기타 다른 사이트에서 다양한 도구, 튜토리얼 및 가이드가 제공되고 있습니다.

유연성: REST API는 클라이언트와 서버 간의 느슨한 결합(loose coupling)을 특징으로 합니다. 이러한 유연성 덕분에 더 간단하고 빠른 변경이 가능하며, 다른 대상에 변경 없이도 한 대상에 변경이 가능합니다.

에코시스템: REST API는 많은 수의 툴과 광범위한 지원 및 문서를 갖추고 있습니다. 예를 들어 OpenAPI Specification(OAS)은 REST API의 매개변수와 기능에 대한 업계 표준 정의를 제공합니다. OAS의 최신 버전인 OAS 3.1에는 JSON 스키마와의 완벽한 호환성, SPDX 식별자를 사용하는 표준화된 식별 등이 포함되어 있습니다.

HTTP/1.1에 대한 의존성: REST는 HTTP/1.1을 사용하여 범용 브라우저 지원과 헤더의 일부 사용자 맞춤 설정을 제공하지만, REST API로 인해 양방향 스트리밍과 같은 HTTP/2의 일부 새로운 기능을 누리지 못하며, REST는 하나의 요청에 하나의 응답이 발생하는 구조인 단방향(unary) 스트리밍만 지원합니다.

더 느리고 낮은 효율성: HTTP/1.1과 마찬가지로 REST가 XML 및 JSON과 같은 형식에 의존하는 것은 장점과 단점을 모두 가지고 있습니다. 이러한 형식은 사람이 읽기 쉬워 좋지만 비교적 큰 파일 크기 때문에 전송 속도가 느려집니다.

추가 도구 필요: REST 에코시스템은 견고할 수 있지만 일부 기능은 아키텍처에 내장되어 있지 않으므로 반드시 필요합니다. 예를 들어 코드 생성은 REST용 플러그인 형태로 사용할 수 있지만 이는 단계가 추가되는 것이기에 더 복잡해질 수밖에 없습니다.

gRPC는 원격 프로시저 호출(RPC)의 특정 구현체로, 구글이 처음 개발한 오픈소스 프레임워크이며, 현재 CNCF(Cloud Native Computing Foundation)에서 관리하고 있습니다.

gRPC라는 이름은 “Google Remote Procedure Call”을 의미할 수도 있으나, 개발자들은 농담조로 gRPC가 “gRPC Remote Procedure Call”이나 그 밖의 다른 다양한 의미를 가질 수도 있다고 주장합니다. 어쨌든 gRPC는 다른 RPC와 마찬가지로 원격 호출을 로컬 호출처럼 보이게 하고 작동하게 합니다.

클라이언트/서버 상호 작용을 위한 모델로서 RPC는 API 개발에서 자주 사용됩니다. RPC 모델에서 클라이언트는 일반적으로 스텁이라고 하는 중개자와 상호 작용합니다. 이 스텁은 전송할 데이터를 변환하고, 서버로부터 요청된 결과를 받으면 이를 클라이언트의 원래 형식으로 다시 변환합니다. XML-RPC 및 JSON-RPC를 비롯한 다양한 유형의 RPC 프레임워크가 있습니다.

이러한 RPC 프레임워크는 가볍고 비교적 사용이 간편하며 간소화된 개발 및 네트워크 통신 추상화와 같은 이점을 제공합니다. 그러나 마이크로서비스 아키텍처 및 데이터 부하가 높은 시스템과 같은 환경에는 더 높은 성능의 프레임워크가 필요한 경우가 많으며, 이러한 요구 사항을 충족하기 위해 gRPC가 개발되었습니다.

gRPC는 프로토콜 버퍼(Protobuf)라는 인터페이스 정의 언어(IDL)를 사용하여 구조화된 데이터를 바이너리로 직렬화합니다. 바이너리는 JSON이나 XML보다 압축률이 높기 때문에 더 큰 페이로드를 더 빠른 속도로 전송할 수 있습니다.

gRPC는 또한 HTTP/2를 사용하며, 이를 통해 양방향 스트리밍이 가능해집니다. 이로 인해 gRPC는 분산 환경(특히 실시간 통신이 필요한 경우), 마이크로서비스 아키텍처, 스트리밍 애플리케이션, 그리고 사물인터넷(IoT) 장치 연결에 사용되는 API에 있어 적합한 선택입니다.

속도: gRPC는 Protobuf를 통해 Java, Python, Ruby 등 다양한 언어의 데이터를 직렬화 및 역직렬화하여 전송을 위한 바이너리 페이로드로 변환합니다. 이 코드는 가볍기 때문에 gRPC API를 사용하면 데이터 교환의 전송 시간과 지연 시간이 줄어듭니다.

코드 생성: gRPC에는 기본 코드 생성 기능을 제공하는 [protoc]이라는 Protobuf 컴파일러가 포함되어 있습니다. .proto 파일에서 데이터 구조가 정의되면 파일에서 gRPC는 클라이언트 측 코드와 서버 측 코드를 모두 생성할 수 있습니다.

HTTP/2 지원: HTTP/2 전송 프로토콜을 기반으로 하는 gRPC는 다양한 유형의 스트리밍을 지원합니다. 예를 들어 클라이언트 측 및 서버 측 스트리밍 외에도 클라이언트와 서버가 읽기/쓰기 스트림으로 메시지를 독립적으로 보낼 수 있는 양방향 스트리밍을 지원합니다.

인터셉터: gRPC는 기능을 향상시킬 수 있는 인터셉터라는 미들웨어를 지원합니다. 인터셉터를 설치하여 보안, 인증, 지표 분석 등을 구현할 수 있습니다.

취소 및 시간 초과: gRPC는 취소를 지원합니다. 취소는 시간 초과 또는 기한이라고도 하며, 호출이 취소되는 지정된 시간을 말합니다.

신규성과 에코시스템: gRPC에는 코드 생성과 같은 추가 기능이 포함되어 있지만, 2016년에 처음 출시된 비교적 새로운 아키텍처입니다. 이러한 신규성으로 인해 문서화와 지원은 기존 아키텍처 스타일과 비교할 때 제한적입니다.

가파른 학습 곡선: 일부 개발자는 gRPC가 REST에 비해 학습 곡선이 더 가파르다고 생각합니다. 이진 데이터 직렬화는 효율적인 통신을 제공하지만 사람이 읽을 수 없는 형식입니다.

브라우저 지원 부족: 웹 브라우저는 기본적으로 gRPC 프로토콜을 지원하지 않으므로 브라우저 기반 애플리케이션에서 gRPC 서비스를 직접 호출할 수 없습니다. 이 문제를 해결하는 한 가지 방법은 gRPC-Web과 같은 프록시를 사용하는 것입니다. gRPC-Web은 기본적으로 브라우저의 HTTP와 gRPC 프로토콜 간의 변환 계층 역할을 합니다.

REST와 gRPC는 공통점이 많으며 모두 확장 가능한 시스템을 구축하는 데 사용됩니다. 유사점은 다음과 같습니다.

클라이언트/서버 아키텍처: gRPC와 REST는 모두 클라이언트와 서버가 통신하고 데이터를 교환할 수 있도록 하는 요청-응답 형식을 사용하는 클라이언트/서버 아키텍처입니다. 이 아키텍처에서 클라이언트는 요청을 보내고 서버는 요청 데이터를 반환하거나 요청된 작업을 수행하여 응답합니다.

플랫폼 독립성: gRPC와 REST는 서로 다른 플랫폼과 운영 체제를 사용하는 서비스들이 통신할 수 있도록 합니다.

무상태: REST와 gRPC 모두 무상태(stateless)로 간주됩니다. 즉, 각 요청에는 해당 요청을 완료하기 위해 필요한 모든 정보가 포함되며, 서버는 이전 요청에 대한 정보를 저장할 필요가 없습니다.

언어 지원: 두 아키텍처 스타일 모두 언어에 구애받지 않으므로 다양한 프로그래밍 언어로 작성된 애플리케이션에서 해당 API를 사용할 수 있습니다. 이러한 품질 덕분에 두 가지 모두 프로그래밍 환경 간에 이식이 가능합니다.

HTTP 사용: REST와 gRPC 모두 HTTP 기반 통신을 사용합니다. 그러나 gRPC는 HTTP/2를 사용하는 반면 REST는 HTTP/1.1을 사용합니다. 또한 gRPC는 기본 HTTP/2 통신 프로토콜을 추상화하는 반면 HTTP 통신은 REST에서 덜 추상화됩니다.

REST와 gRPC의 주요 차이점은 개발자가 구축 중인 API에 가장 적합한 것을 결정하는 데 도움이 될 수 있습니다. 이러한 차이점에는 다음이 포함됩니다.

데이터 형식: REST API는 주로 JSON 및 XML과 같은 텍스트 기반 형식을 사용합니다. gRPC는 Protobuf를 사용하여 데이터를 이진 형식으로 인코딩합니다.

통신 패턴: REST는 단방향 통신만 지원하며, 이는 한 개의 요청에 이어 한 개의 응답이 따르는 구조를 의미합니다. gRPC는 양방향 스트리밍(클라이언트와 서버가 독립적으로 교환하는 방식), 서버 스트리밍(단일 요청이 다중 응답을 유발하는 방식) 및 클라이언트 스트리밍(다중 요청이 단일 응답을 생성하는 방식)을 포함한 다양한 기능을 지원합니다.

디자인 패턴: gRPC에는 호출 가능한 서버 작업이 서비스 또는 함수로 정의되는 서비스 지향 디자인이 있습니다. REST에서 디자인은 HTTP 메서드를 사용하여 URL로 정의된 엔드포인트를 통해 서버 리소스에 액세스하는 리소스를 중심으로 합니다.

결합: gRPC의 클라이언트와 서버는 긴밀하게 결합되어 있으므로 클라이언트와 서버 모두 동일한 미들웨어 프로토 파일에 액세스할 수 있어야 하며, 하나가 변경되면 다른 하나도 변경되어야 합니다. 반면 REST는 느슨하게 결합되어 있습니다. 이러한 독립성은 한 구성 요소의 변경 사항이 다른 구성 요소에 영향을 미치지 않음을 의미합니다.

코드 생성: gRPC는 기본적으로 코드 생성 기능을 제공하지만, REST는 그렇지 않습니다. 다만 플러그인을 통해 생성은 가능합니다.

구현: REST에는 특정 소프트웨어가 필요하지 않으며 실제로 브라우저를 지원합니다. gRPC를 사용하려면 서버 측과 클라이언트 측 모두에 특정 소프트웨어가 필요합니다.

REST가 대중적인 API 설계 선택지인 이유가 있습니다. 그 단순성, 폭넓은 호환성 및 다용성 덕분에 많은 애플리케이션에 적합합니다. 공용 API의 경우 REST가 더 널리 사용되고 종종 더 쉽게 이해되기 때문에 더 합리적인 선택인 경우가 많습니다. 많은 개발자가 REST에 더 익숙하며 서버, API 관리 도구, 개발 도구 및 다양한 테스트 도구를 포함하여 REST를 위한 중요한 인프라를 보유하고 있을 수 있습니다.

또한 REST는 내장 캐싱, 즉 로컬 또는 프록시를 통해 자주 액세스하는 데이터를 저장하는 기능을 지원합니다. 캐싱은 속도와 효율성을 크게 향상시킬 수 있지만 다양한 검증, 인증 및 만료 정보도 포함해야 합니다.

REST는 HTTP/1.1 지원 및 범용 브라우저 지원으로 인해 일반적으로 웹 서비스 및 웹 API에도 선호됩니다. 일반적으로 더 간단한 데이터 통신을 위해 gRPC보다 선호됩니다. 느슨한 결합과 복잡성 감소는 시스템 아키텍처의 확장성을 향상시키고 시간이 지남에 따라 환경을 보다 유연하게 만드는 데 도움이 될 수 있습니다. 하지만 이러한 적응성에는 성능 저하라는 대가가 따릅니다. 

gRPC는 비교적 새로운 아키텍처로, 개발자들은 점점 더 속도, 효율성 및 내장 툴을 수용하고 있습니다. 분산 시스템에서 성능이 높고 높은 데이터 부하를 처리해야 하는 실시간 스트리밍 애플리케이션과 복잡한 API에 자주 사용됩니다. REST보다 복잡하지만 HTTP/2 및 Protobuf를 사용하면 gRPC의 성능 확장성이 향상됩니다. 

gRPC는 양방향 데이터를 실시간으로 스트리밍할 수 있는 기능을 통해 애플리케이션 내의 다양한 서비스를 동시에 독립적으로 보내고 받을 수 있으므로 마이크로서비스 아키텍처에 매우 적합합니다. 또한 빠르고 컴팩트한 데이터 전송과 모바일 애플리케이션이 브라우저에 의존할 가능성이 적기 때문에 모바일 애플리케이션에서도 지원되고 있습니다.

gRPC는 컴팩트한 페이로드, 짧은 지연 시간 및 고성능 효율성이 저전력 기술과 잘 어울리기 때문에 IoT 항목을 백엔드 API에 연결하는 데에도 이상적입니다.