얼마전 프로젝트 진행 시, RESTful의 엔드포인트에 대해서 문제가 생겼었다. 구현상에 문제는 없지만 Addressability를 보장해야 하는 DX관점에서의 문제였다.

지금이야 REST로 API를 만들어서 제공하지만, 상황에 따라 gRPC 혹은 GraphQL을 사용해야 할 경우도 생기기에 각 표준에 대해서 정리하고자 한다.

통신 방식의 비교

이미지 출처: https://www.sensedia.com/post/apis-rest-graphql-or-grpc-who-wins-this-game

기술별 특성 비교

이미지 출처: https://www.sensedia.com/post/apis-rest-graphql-or-grpc-who-wins-this-game

REST

REST는 현재 가장 많이 사용되는 API 아키텍처이다. HTTP Method를 사용하여 리소스를 제공한다.

REST에서 사용되는 HTTP Method

• POST: 새 리소스를 생성한다.
• PUT: 리소스가 존재하는 경우 업데이트하거나 리소스가 없으면 생성한다.
• DELETE: 리소스를 삭제한다.
• PATCH: 기존 리소스를 부분적으로 업데이트 한다.
• GET: 리소스를 쿼리한다.

REST의 장점은 아래와 같다.

• 성능 - 빠른 반복 및 HTTP 표준 표현이 필요한 시스템에 가장 적합하다.
• 확장성 - 많은 수의 구성 요소와 구성 요소 간의 상호 작용을 지원한다.
• 단순성 - REST에는 아키텍처를 단순화하고 분리하는 균일한 인터페이스가 존재한다.

이미 오래전부터 사용되었기에 대부분의 개발자가 익숙하다는 장점이 있다. REST는 HTTP 프로토콜 디자인과 매우 밀접하게 브라우저 및 기타 HTTP 클라이언트는 기본적으로 REST API를 이해하고 있다.

하지만, REST는 만병 통치약이 아니고 유일한 API 아키텍처가 아니다. REST의 경우 리소스가 복잡할 수록 여러 API를 사용하거나 응답이 무거울 수 있다. 따라서 GraphQL로 대체되거나 gRPC를 사용하는 경우가 생기기도 한다. 그리고 REST에 대한 표준을 만들어야 한다. API를 만들때에 가장 중요한 것은 API를 사용하는 청중의 입장에서 설계하고 제공해야 한다. API 엔드포인트로 리소스를 제공하기에 하나의 API만 보면 안되고, 전체의 API의 엔드포인트를 보면서 문맥 및 의미하는 바가 잘 표현되었는지 확인해야 한다. 이 작업은 매우 어려운 작업이기에 매끄럽게 만들기가 어렵다. 이번에 발생한 것도 이 부분에서 문제가 발생한 것이다.

다른 API를 아키텍처를 사용할 이유가 없다면 REST가 가장 적합한 옵션이다. GraphQL, gRPC는 고유한 요구 사항이 있는 상황에 적합할 수 있다. 그리고 REST에 비해 학습 곡선이 가파르다.

범용적인 API가 필요할 경우 REST를 사용하면 좋다.

gRPC

gRPC는 Google에서 설계, 개발한 Google Remote Procedure Call이다. 데이터를 가볍고 빠르게 요청하기 위해 고려되었다. gPRC는 일반적인 원격 프로시저 호출보다 진화된 형태이다. gRPC를 사용하면 클라이언트는 원격 시스템이 마치 로컬인 것처럼 직접 메소드를 호출할 수 있다. gRPC는 프로토콜 버퍼(Protobufs)를 사용하여 데이터 전송을 위해 텍스트 기반의 JSON, XML이 아닌 바이너리로 직렬화된 데이터로 인터페이스를 정의한다. 또한 HTTP/1보다 더 안정적이고 빠른 HTTP/2를 사용하게 된다.

REST는 표준화된 용어를 통해 상호 작용을 정리하고 GraphQL은 생성된 스키마에 대해 요청을 실행하며 필요한 것을 가져오게 된다.

gRPC는 서버와 클라이언트 간의 관계에 의해 동작이 정의된다. 대부분의 권한은 클라이언트측에 의존하는 반면 처리 및 계산은 리소스를 제공하는 원격 서버에서 진행된다. 이점은 아래와 같다.

• 가벼우며 클라이언트측의 리소스가 거의 필요하지 않다. 따라서 전력이 매우 부족한 상황에서 편리하게 이용할 수 있다.
• 효율적이다. gRPC는 통신을 직렬화하는데 중점을 둔 구조화된 데이터 직렬화 방법인 protobufs를 사용한다.
• 오픈소스 이며 자유롭게 사용, 수정 또는 분기할 수 있다.

gRPC는 정해진 양의 데이터 또는 클라이언트가 저전력이거나 리소를 보존하려는 시스템에 적합하다. 가장 좋은 예는 음성 컨트롤러, 스마트 조명 스위치, 화재 경보기, 잠금 장치 및 카메라와 같이 널리 사용되는 IoT 장치에 적용하면 장점을 최대한 이용할 수 있다.

GraphQL

GraphQL은 정확한 요청에 초점을 맞추고 필요한 것을 정확히 전달하기 위한 방식이다. GraphQL을 다른 API와 차별화하는 것은 클라이언트 중심의 접근 방식이다. 주요 이점은 아래와 같다.

• 적응성 - 클라이언트가 원하는 데이터, 원하는 방식 및 형식을 결정한다.
• 효율성 - 과도하게 가져오지 않고 클라이언트가 요청한 것을 정확하게 전달한다.
• 유연성 - GraphQL은 크로스 플랫폼이며 12개 이상의 언어(Java, Perl, Python.,)을 지원한다.

GraphQL 사용 사례중 가장 많이 알려진 것은 Github이다. 확장성과 유연성 두 가지 주요 이유로 2016년에 전환했다. REST는 원하는 데이터를 얻기 위해 여러 요청을 해야 하고 각 요청에서 데이터를 과도하게 가져와야 하는 경우가 많다. Github의 급속한 성장과 수천만 명의 사용자를 보면 이것이 얼마나 부담되는 일인지 알 수 있다. GraphQL은 클라이언트가 특정 용도를 위해 특정 형식의 데이터를 요청할 수 있다는 점에 초점을 뒀기 때문에 Github의 Needs를 정확히 제공했다.

끝으로

각각의 기술은 고유한 장점과 단점이 존재한다. 목표가 무엇인지에 따라 어떤 것을 선택할지 결정되게 된다. 각 기술을 이해하고 현재 프로젝트에 가장 적합한 것이 무엇인지 판단하고 선택했으면 좋겠다.

References

• https://medium.com/devops-dudes/graphql-vs-rest-vs-grpc-411a0a60d18d
• https://konghq.com/blog/rest-vs-grpc-vs-graphql
• https://www.sensedia.com/post/apis-rest-graphql-or-grpc-who-wins-this-game