다음 프로젝트를 위해 선택할 것 [2023]

API 설계의 두 가지 주요 방식: REST와 gRPC

API를 개발할 때 REST와 gRPC는 자주 마주치는 두 가지 주요 접근 방식입니다. REST는 오랜 기간 동안 API 분야에서 주도적인 역할을 해왔지만, gRPC 역시 강력한 경쟁자로 자리매김하고 있습니다.

REST와 gRPC는 API를 설계하는 데 있어 서로 다른 원칙과 방법을 제시합니다. API는 서로 다른 시스템 간의 통신을 가능하게 하는 중요한 다리 역할을 하며, 이러한 시스템은 서로 다른 컴퓨터에 존재하거나 다른 프로그래밍 언어로 작성될 수 있습니다.

본 글에서는 REST와 gRPC를 소개하고, 이들의 유사점과 차이점을 비교 분석하여 각 기술이 어떤 상황에 적합한지 알아보겠습니다.

REST란 무엇인가?

REST(Representational State Transfer)는 소프트웨어 구성 요소 간의 데이터 교환 방식을 정의하는 아키텍처 스타일입니다. REST는 웹의 표준 프로토콜인 HTTP를 기반으로 합니다.

REST 아키텍처 스타일을 따르는 모든 API를 RESTful API라고 하며, REST 아키텍처 설계 원칙을 준수하는 웹 서비스를 RESTful 웹 서비스라고 부릅니다.

REST 아키텍처 스타일은 다음과 같은 원칙을 따릅니다.

• 균일한 인터페이스: 서버는 데이터를 표준화된 형식으로 전송해야 합니다. 이때 전송되는 데이터 형식은 서버 애플리케이션 내부의 리소스 표현 방식과 다를 수 있습니다.
• 상태 비저장: 서버는 이전 요청에 의존하지 않고 모든 클라이언트 요청을 독립적으로 처리해야 합니다. 클라이언트의 리소스 요청은 순서에 상관없이 이루어질 수 있으며, 각 요청은 다른 요청과 격리되어 처리됩니다.
• 계층화된 시스템: 서버와 클라이언트 사이에 인증된 중개자 계층을 둘 수 있습니다. 클라이언트는 이러한 중개자와 연결하더라도 서버로부터 응답을 받을 수 있습니다.
• 캐시 가능성: 일부 응답은 성능 향상을 위해 중개자나 클라이언트에 저장될 수 있습니다.
• 주문형 코드: 서버는 클라이언트 기능을 맞춤화하거나 확장하기 위해 프로그래밍 코드를 클라이언트로 전송할 수 있습니다.

REST의 장점

• 확장성: REST API는 클라이언트-서버 간 상호작용을 최적화하여 높은 확장성을 제공합니다. 캐싱과 상태 비저장 특성은 서버 부하를 줄이는 데 기여합니다.
• 유연성: RESTful API는 클라이언트와 서버의 완전한 분리를 가능하게 합니다. 이로 인해 다양한 서버 구성 요소가 독립적으로 발전할 수 있으며, 서비스 구조가 간소화됩니다.
• 독립성: API 설계에 영향을 주지 않고 서로 다른 프로그래밍 언어로 서버와 클라이언트 애플리케이션을 개발할 수 있습니다.

REST의 활용 사례

• 웹 API
• 웹 서비스
• 마이크로서비스 아키텍처

gRPC란 무엇인가?

gRPC는 다양한 환경에서 실행될 수 있는 RPC(원격 프로시저 호출) 프레임워크입니다. 오픈 소스인 이 프레임워크는 데이터 센터 내부 및 전반에서 서비스 간 연결을 효율적으로 관리할 수 있도록 설계되었습니다.

클라이언트 앱은 마치 로컬 객체처럼 다른 시스템의 서버 앱에서 메서드를 호출할 수 있습니다. gRPC를 사용하면 서비스를 정의하고, 메서드 매개변수와 반환 유형을 지정하여 원격으로 호출할 수 있는 메서드를 구성할 수 있습니다.

gRPC는 연결 상태 확인, 인증, 부하 분산 및 추적 기능을 기본적으로 제공합니다. 데이터 전송에는 HTTP/2와 프로토콜 버퍼를 사용하며, 리소스 URL 대신 프로시저를 호출하여 데이터를 교환합니다.

gRPC의 장점

• 확장성: gRPC는 간단한 명령을 통해 런타임 환경을 설정하고 초당 수백만 건의 RPC를 처리할 수 있을 정도로 확장성이 뛰어납니다.
• 간단한 서비스 정의: 프로토콜 버퍼를 사용하여 서비스를 간편하게 정의하고 실행할 수 있습니다.
• 플랫폼 호환성: 다양한 플랫폼과 언어에 대해 최적화된 클라이언트 및 서버 스텁을 생성하여 플랫폼 간 호환성을 제공합니다.
• 양방향 스트리밍 및 통합 인증: 양방향 스트리밍을 지원하며, 통합 인증 기능을 제공하여 보안을 강화할 수 있습니다.

gRPC의 활용 사례

• 웹 API
• 웹 서비스
• 스트리밍 애플리케이션
• 마이크로서비스 간 통신

REST와 gRPC의 유사점

• 데이터 교환 메커니즘: 두 아키텍처 모두 서버와 클라이언트 간의 데이터 교환을 가능하게 하지만, 교환되는 데이터는 특정 규칙에 따라 공유됩니다.
• 확장 가능한 분산 시스템에 적합: REST와 gRPC 모두 비동기 통신 및 상태 비저장 설계를 통해 API를 쉽게 확장할 수 있습니다.
• HTTP 기반 통신 사용: 두 방식 모두 웹에서 널리 사용되는 통신 프로토콜인 HTTP를 사용합니다.
• 유연성: 다양한 프로그래밍 언어 및 기술과 함께 REST와 gRPC를 사용할 수 있습니다.

REST와 gRPC 심층 비교 분석

REST와 gRPC 서비스는 다음과 같은 주요 차이점을 가지고 있습니다.

데이터 교환

REST API에서 데이터는 JSON 형식으로 표현되며, JSON은 데이터 교환을 위해 직렬화 및 프로그래밍 언어로 변환되어야 합니다. REST API는 HTML 및 XML과 같은 다른 데이터 형식도 교환할 수 있습니다.

gRPC는 기본적으로 프로토콜 버퍼 형식을 사용하며, JSON 형식도 지원합니다. 프로토콜 버퍼는 사람이 읽을 수 없는 이진 형식이며, 데이터 구조는 프로토콜 버퍼 인터페이스 정의 언어를 사용하여 정의됩니다. gRPC는 데이터 구조를 이진 형식으로 직렬화한 후, 지정된 프로그래밍 언어로 역직렬화합니다.

통신 모델

REST에서 클라이언트는 서버에 단일 요청을 보내고, 서버는 응답을 반환합니다. 클라이언트는 서버 응답을 기다린 후 작업을 계속합니다. 이는 요청-응답 모델입니다.

gRPC에서 클라이언트는 단일 또는 다중 서버 요청을 보낼 수 있으며, 각 요청에 대해 단일 또는 다중 응답을 받을 수 있습니다. 연결은 일대일, 일대다, 다대일, 다대다 모델을 지원합니다. gRPC는 클라이언트-응답 통신 모델을 사용합니다.

코드 생성

gRPC는 서버 및 클라이언트 측 코드 생성 기능을 제공하며, 프로토콜 버퍼 컴파일러를 통해 다양한 언어로 코드를 생성할 수 있습니다. gRPC는 proto 파일에서 구조를 정의한 후 서버 및 클라이언트 코드를 생성합니다.

REST는 내장 코드 생성 기능을 제공하지 않지만, 필요한 경우 타사 도구를 사용할 수 있습니다.

HTTP 프로토콜

REST API는 HTTP/1.1을 사용하며, 리소스 URL을 통해 요청을 보냅니다. HTTP/1.1은 컴퓨터와 웹 서버 간의 정보 교환을 담당합니다. REST 서비스의 리소스 URL은 클라이언트에 노출되며, API 설계자가 리소스 URL 구조를 제어합니다.

gRPC는 HTTP/2를 사용합니다. HTTP/2는 2015년에 도입된 최신 버전으로, Internet Explorer, Safari, Chrome과 같은 브라우저에서 사용됩니다. HTTP/1.1이 모든 것을 일반 텍스트로 유지하는 반면, HTTP/2는 이진 형식 캡슐화를 활용하여 더 많은 데이터 전송 옵션을 제공하고 처리 속도를 높입니다.

페이로드 데이터 구조

REST는 XML 또는 JSON을 사용하여 데이터를 전송하고 받습니다. JSON은 유연하며 별도의 구조를 요구하지 않기 때문에 REST에서 동적 데이터 전송에 가장 많이 사용됩니다. JSON 데이터는 사람이 읽을 수 있다는 장점이 있지만, 전송 중에 직렬화 및 변환 과정을 거치므로 속도가 빠르지 않다는 단점이 있습니다.

gRPC는 프로토콜 버퍼를 사용하여 페이로드 데이터를 직렬화합니다. 프로토콜 버퍼는 메시지 데이터 크기를 줄이는 고도로 압축된 형식이며, 클라이언트와 서버에서 사용하는 프로그래밍 언어로 자동 변환합니다.

브라우저 지원

REST는 HTTP/1.1을 사용하므로 모든 브라우저에서 지원됩니다. 따라서 웹 서비스 및 API 개발에 적합한 선택입니다.

gRPC는 HTTP/2를 기반으로 하므로 브라우저 지원이 제한적입니다. 모든 브라우저를 지원하려면 gRPC-web을 프록시 계층으로 추가해야 합니다. 이러한 이유로 gRPC는 주로 내부 시스템에 많이 사용됩니다.

클라이언트-서버 결합

REST는 느슨하게 결합된 아키텍처입니다. 클라이언트와 서버는 서로의 구현 세부 사항을 알 필요가 없습니다. 따라서 서버 정의가 변경되더라도 클라이언트 코드를 변경할 필요가 없어 시간이 지남에 따라 RESTful API를 보다 쉽게 발전시킬 수 있습니다.

gRPC는 서버와 클라이언트가 동일한 proto 파일에 의존하는 긴밀하게 결합된 프레임워크입니다. proto 파일이 변경되면 서버와 클라이언트 모두 업데이트해야 합니다.

REST vs gRPC 비교

REST 사용 시점

RESTful API와 웹 서비스는 광범위하게 사용됩니다. RESTful 서비스는 구현이 쉽고, 데이터 구조화가 유연하며, 읽기 쉽다는 장점을 가지고 있습니다. REST는 다음과 같은 경우에 유용합니다.

• 웹 기반 아키텍처: 웹, 모바일, 멀티플랫폼 API를 REST 아키텍처를 사용하여 개발할 수 있습니다.
• 간단한 데이터 통신: REST는 사람이 읽기 쉬운 데이터 형식인 JSON을 사용합니다.
• 공용 API: 대중에게 데이터를 제공하거나 API를 공개해야 하는 경우, 가독성이 뛰어난 REST가 좋은 선택입니다.

gRPC 사용 시점

gRPC는 RESTful 서비스만큼 대중적이지는 않지만, 다음과 같은 고유한 기능을 가지고 있습니다.

• 다중 언어 시스템: gRPC는 다양한 프로그래밍 언어로 작성된 마이크로서비스 아키텍처에 적합하며, API 변경 가능성이 적은 경우에 유용합니다.
• 마이크로서비스 연결: 양방향 스트리밍, 낮은 브라우저 지원 특성으로 인해 내부 API에 적합합니다.
• 실시간 스트리밍 네트워크: 대용량 데이터 처리, 실시간 스트리밍을 요구하는 내부 서비스에 적합합니다.

저자의 의견

gRPC는 사물 인터넷(IoT)과 같은 특정 애플리케이션에서 REST를 능가할 수 있는 강점을 가지고 있지만, 가독성, 유연성, 폭넓은 채택률 때문에 REST가 더 보편적으로 사용되고 있습니다. gRPC의 제한적인 브라우저 지원은 웹 서비스를 개발하려는 개발자에게는 큰 단점으로 작용합니다.

RESTful 서비스는 보편적인 지원을 제공하므로 웹 및 마이크로서비스 통합에 이상적인 API 아키텍처 스타일입니다.

결론

REST와 gRPC는 API를 구축할 때 선택할 수 있는 여러 API 아키텍처 스타일 중 일부입니다. 최종 선택은 개발하고자 하는 제품의 요구 사항에 따라 달라집니다. RESTful 서비스는 공용 API를 구축할 때 유용하며, gRPC는 브라우저 지원이 필요하지 않은 모바일 애플리케이션과 같은 서비스에 적합합니다.

다음으로, Java를 사용하여 gRPC를 처음부터 구축하는 방법에 대한 글을 읽어보시길 권합니다.