API 아키텍처 비교 [REST API vs GraphQL vs gRPC]

서론

근래 취업을 준비함에 있어 다양한 회사들의 기술 스택들을 살펴보았다.

이 과정에서 GraphQL, gRPC 등 들어본 적은 있으나 사용한 적은 없던 API 아키텍처들이 빈번하게 사용되고 있음을 발견하였다.

 

'B'사 모집요강 중 일부

 

그러나 필자는 REST API에만 익숙했기에 다른 API 아키텍처에 대한 이해가 부족하다고 판단하였다.

이에 본 글에서는 REST API, GraphQL, gRPC의 주요 특징과 장단점을 중심으로 비교하고자 한다.

 

본 글에선 각 아키텍처 간의 '비교'를 중점적으로 다룰 것이기에 각 아키텍처들에 대해 이론적인 설명이 부족할 수 있으니 양해 바란다.

 

---

 

본론

여김 없이 전지전능하신 ChatGPT님께 자문을 구하였다.

REST API는 HTTP 프로토콜과 URL을 기반으로 동작하며 간단하고 표준화된 방식으로 브라우저 친화적이다.
그러나 Over-fetching과 Under-fetching 문제가 발생할 수 있다.

GraphQL은 클라이언트가 원하는 데이터를 쿼리 형태로 요청해 필요한 데이터만 반환받을 수 있어 효율적이고 유연하지만,
서버 성능에 영향을 줄 수 있고 캐싱이 어렵다.

gRPC는 HTTP/2와 Protobuf를 기반으로 빠르고 효율적인 바이너리 통신을 제공하며,
양방향 스트리밍과 비동기 통신이 가능하다. 하지만 설정과 디버깅이 복잡하고 브라우저와 직접 연동하기 어렵다.

REST는 간단한 API에,
GraphQL은 유연성이 중요한 데이터 중심 API에,
gRPC는 성능과 실시간 처리가 중요한 서비스에 적합하다.

출처 | OpenAI. (2024). ChatGPT (4o Version) [Large language model]. https://chat.openai.com

 

 

REST(Representational State Transfer) API

REST(Representational State Transfer)는 HTTP URI와 HTTP 메서드를 조합하여 자원의 상태를 주고받는 대표적인 아키텍처이다.

 

이에 대해 잘 설명해 둔 다른 글이 있어 일부를 인용하고자 한다.

REST(REpresentational State Transfer)의 약자로 자원을 이름으로 구분하여 해당 자원의 상태를 주고받는 모든 것을 의미합니다.

즉 REST란
1. HTTP URI(Uniform Resource Identifier)를 통해 자원(Resource)을 명시하고,
2. HTTP Method(POST, GET, PUT, DELETE, PATCH)를 통해
3. 해당 자원(URI)에 대한 CRUD Operation을 적용하는 것을 의미합니다.

출처 : 히진쓰의 서버사이드 기술 블로그, [네트워크] REST API란? REST, RESTful이란?

 

즉, REST API의 핵심은 URI와 Method를 조합하영 원하는 정보를 취득하거나 조작하는 거라 할 수 있다.

클라이언트 측에서 사전에 정의해 둔 API 명세서를 기반으로 요청을 보내면, 그에 상응하는 응답이 가는 구조이다.

 

다만 이러한 구조적 한계로 인해 지나치게 많은 데이터를 받거나(오버페칭), 정작 필요한 데이터를 못 받는 상황(언더페칭)이 발생하기도 한다.

 

니가 뭘 좋아할지 몰라서 다 준비해봤어 ❘ 출처 : https://swagger.io/tools/swagger-ui/

 

이러한 REST API 아키텍처는 아래와 같은 장, 단점을 갖는다.

 

장점

1. 표준화된 프로토콜 : HTTP 표준을 기반으로 설계되어 직관적이고 명확함
2. 단순성 : JSON, XML 같은 직관적인 데이터 포맷을 사용해 설계화 구현이 간단함
3. 캐싱 지원 : HTTP의 기본 캐싱 메커니즘을 활용해 성능 최적화가 용이함
4. 확장성 : URL과 HTTP 메서드를 사용해 새로운 기능이나 엔드포인트를 쉽게 추가할 수 있음

단점

1. 오버페칭 : 클라이언트가 필요하지 않은 데이터까지 반환하여 비효율이 발생할 수 있음
2. 언더페칭 : 클라이언트가 정작 필요한 데이터를 모두 가져오지 못해 추가 요청이 발생할 수 있음
3. 복잡한 엔드포인트 관리 : 엔드포인트가 많아질수록 관리와 유지보수가 어려워질 수 있음
4. 비효율적인 데이터 전송 : JSON, XML 형식으로 인해 대용량 데이터 전송 시 비효율적임
5. 실시간 통신 부적합 : Request - Response 모델로 인해 실시간 스트리밍이나 양방향 통신에 부적합

 

추가로 엔드포인트가 늘어남에 따라 클라이언트 개발자의 이해와 개발을 돕기 위해 연관된 하이퍼링크를 제공하는 HAL 방식도 존재한다.

다만 필자의 생각으론 오히려 오버페칭이 심해지고 이에 따른 성능 저하가 발생할 것 같은데, 뭐가 옳은지는 잘 모르겠다.

HAL | API Guidelines

 

 

GraphQL

GraphQL은 Facebook에서 개발한 쿼리 언어로, 클라이언트가 원하는 데이터의 구조를 지정해 서버에 요청할 수 있는 API 기술이다.

즉, API를 호출하는 클라이언트 측에서 원하는 데이터를 취사선택 하게 함으로써 오버페칭, 언더페칭을 해결한 것이다.

 

( 뷔페처럼 골라먹는 REST API와는 달리 사용자가 원하는 것만 주문하는 셈이다 )

 

또한 수많은 엔드포인트를 제공하는 REST API와는 달리 단일 엔드포인트만을 제공한다는 특징이 있다.

 

REST API vs GraphQL 비교 ❘ 출처 : https://tech.kakao.com/posts/364

 

GraphQL은 장점만 있는 것 같지만, 무엇보다 치명적인 단점으로 '적용하기 어렵다'라는 단점이 존재한다. 

 

우선 클라이언트 측에선 URL을 호출하면 되는 REST API 방식과는 달리, 직접 쿼리를 작성해야 한다.

{
  user(id: 1) {
    name
    posts {
      title
    }
  }
}

 

위 쿼리문은 ID가 1인 사용자의 이름과 작성한 Post들의 제목을 가져오는 쿼리이다.

이것만 보면 쉬워 보이지만, 아래와 같은 쿼리는 어떨까? 판단은 개인의 몫에 맡기겠다.

{
  user(id: 1) {
    name
    email
    address {
      city
      state
      country
    }
    posts {
      title
      content
      tags {
        name
        description
      }
      comments {
        content
        author {
          name
          email
        }
      }
    }
  }
}

 

위는 클라이언트 측의 어려움이었으나, 서버 측도 마찬가지로 어려움이 존재한다.

 

우선적으로 가장 큰 문제점은 클라이언트 측의 요청을 예측할 수 없다는 점에서 기인한다.

{
  user(id: 1) {
    friends {
      posts {
        comments {
          author {
            name
          }
        }
      }
    }
  }
}

 

위와 같은 쿼리가 요청으로 올 경우, 중첩된 데이터로 인해 N+1 문제가 발생할 가능성이 농후하다.

(user → friends → posts → comments → author에 대해 여러 번 요청)

 

또한 사용자가 원하는 데이터만 골라먹는 GraphQL의 특성상 캐싱하기 까다롭다는 특성도 존재한다 (불가능한 건 아니다).

이로 인해 서버는 클라이언트의 매 요청마다 쿼리를 실행해야 하므로 성능 부담이 커질 수 있다.

 

또한 아래 쿼리처럼 클라이언트 측에서 악의적으로 서버에 부하를 줄 수 있는 요청도 가능하다 (물론 서버 측에서 방지할 순 있다).

{
  users(limit: 10000) {
    id
    name
    posts {
      title
      comments {
        content
      }
    }
  }
}

 

물론 위에서 언급한 문제점들을 해결하고 적절히 적용할 수만 있다며 GraphQL 또한 매우 매력적인 아키텍처라고 생각이 든다.

다만 언급한 대로 REST API에 비해 적용하기까지 다수의 난관이 존재하기에 러닝커브가 매우 높을 것 같다.

 

 

gRPC (google Remote Procedure Call)

gRPC는 Google에서 개발한 고성능 원격 프로시저 호출(Remote Procedure Call, RPC) 프레임워크이다.

 

이름에서 유추할 수 있듯이, RPC(Remote Procedure Call)을 근간에 둔다.

RPC는 네트워크로 연결된 다른 서버 상의 프로시저를 원격으로 호출하기 위한 도구로, 언어의 제약을 뛰어넘게 해 준다.

 

사실 gRPC는 클라이언트 - 서버 환경에서 사용하기엔 다소 부적합하다. 

 

gRPC는 HTTP/2.0 기반의 프레임워크로, 전송 속도 향상을 위해 프로토콜 버퍼(Protocol Buffer)를 사용하여 통신한다.

프로토콜 버퍼는 JSON과 같은 구조화된 데이터를 직렬화하는데, 이로 인해 사람이 알아보기 힘들어 디버깅하기 어렵다는 특징이 있다.

프로토콜 버퍼 구조 ❘ 출처 : https://martin.kleppmann.com/2012/12/05/schema-evolution-in-avro-protocol-buffers-thrift.html

 

또한 HTTP/2 기반의 gRPC를 지원하지 않는 브라우저의 경우 통신을 위해 gRPC-Web 같은 추가 라이브러리가 필요한 경우도 있다.

 

이러한 특징으로 인해 gRPC는 MSA 기반 서비스에서 각 서버들 간의 통신에 자주 사용되는 편이다.

 

앞에서 간단히 언급하였듯이 gRPC는 특정 서버의 언어에 구속되지 않는다 하였는데,

이는 프로토콜 버퍼를 직렬화/역직렬화하기 위해 스텁(Stub)을 사용하기 때문이다.

 

스텁은 클라이언트와 서버 간의 네트워크 통신, 데이터 직렬화/역직렬화, 요청 및 응답 처리를 추상화하여,

개발자가 네트워크 세부 사항을 신경 쓰지 않고 서비스를 호출할 수 있게 해주는 역할을 수행한다.

 

( 개인적인 생각으론 사용자의 HTTP 요청을 Python 객체로 변환해 주는 WSGI와 다소 유사한 것 같다. )

스텁(Stub) 기반 통신 예시 ❘ 출처 : https://grpc.io/docs/what-is-grpc/introduction/

 

 

결론

지금까지 내용을 정리해보자면 REST API, GraphQL, gRPC는 각기 다른 장단점과 용도를 가지고 있으며,

프로젝트의 요구 사항에 따라 선택이 달라질 수 있다.

• REST API는 간단한 데이터 조회나 웹 친화적인 API에 적합하다.
• GraphQL은 유연성과 효율성이 중요한 데이터 중심의 애플리케이션에서 빛을 발한다.
• gRPC는 실시간 통신 및 성능이 중요한 MSA 환경에서 강력한 도구로 작용한다.

 

---

 

참고자료

[네트워크] REST API란? REST, RESTful이란?

REST API에 HAL(Hypertext Application Language) 적용하기

HAL | API Guidelines

GraphQL 개념잡기 - tech.kakao.com

GraphQL(그래프 QL)란? 개념과 필수 용어 알아보기

gRPC 란?

이 얼마나 쉽고 빠른 gRPC?! (1) Concept

gRPC와 REST 비교 - 애플리케이션 설계의 차이 - AWS

Protocol Buffer 란?