GraphQL vs. REST: 다음 API가 GraphQL을 선호할 수 있는 이유

발행: (2025년 12월 16일 오후 11:48 GMT+9)
8 min read
원문: Dev.to

Source: Dev.to

GraphQL vs. REST: 다음 API가 GraphQL을 선호할 수 있는 이유에 대한 표지 이미지

소개

안녕하세요 Dev.to 커뮤니티 여러분!

우리는 모두 그런 경험을 해봤습니다. 새로운 애플리케이션을 만들고 있을 때, 프론트엔드가 백엔드와 어떻게 통신할지 결정해야 할 순간이 오죠. 수년 동안 REST는 API 설계의 확고한 왕이었으며, 그 이유도 충분했습니다 – 견고하고, 널리 이해되며, 놀라울 정도로 유연하니까요. 하지만 최근 몇 년 사이에 GraphQL이라는 새로운 경쟁자가 등장했습니다.

REST가 사라지는 것은 아니지만, GraphQL은 개발자들이 API 전략을 진지하게 재고하게 만드는 몇 가지 매력적인 장점을 제공합니다. 다음에서는 왜 GraphQL이 다음 프로젝트에 더 나은 선택이 될 수 있는지 살펴보겠습니다.

REST의 문제점 (때때로)

오해하지 마세요, 저는 REST를 사랑합니다. 많은 사용 사례에 있어서는 정말 훌륭합니다. 하지만 애플리케이션이 복잡해지고 사용자 인터페이스가 더 동적으로 변함에 따라, 특히 두 가지 핵심 영역에서 REST는 한계를 드러내기 시작합니다:

  • 과다 조회
    예를 들어 프로필 페이지에 사용자의 이름과 이메일을 표시해야 한다고 가정해 보세요. REST를 사용할 경우 /users/:id 같은 엔드포인트를 호출하게 됩니다. 그러나 이 엔드포인트는 현재 필요하지 않은 주소, 주문 내역, 선호 설정 등 많은 추가 데이터를 반환할 수 있습니다. 이 불필요한 데이터까지 네트워크를 통해 전송되면서 대역폭을 낭비하고 애플리케이션이 느려질 수 있습니다.

  • 부족 조회
    반대로 사용자의 이름, 최근 3개의 게시물, 그리고 각 게시물에 달린 댓글까지 표시해야 한다면 여러 번의 요청을 해야 할 수도 있습니다: /users/:id/users/:id/posts → 각 게시물마다 /posts/:id/comments. 이른바 “n+1” 문제는 서버와의 왕복 횟수를 늘려 지연 시간을 증가시킵니다.

  • 버전 관리 및 다중 엔드포인트
    애플리케이션이 진화함에 따라 API도 변합니다. 변경 사항을 반영하기 위해 /v1/users를 만들고, 이후 /v2/users를 추가하게 되면, 관리하고 문서화하기 어려운 방대한 엔드포인트 집합이 생겨날 수 있습니다.

GraphQL 소개: 데이터를 요청하는 더 나은 방법

GraphQL, Facebook이 개발한 이 기술은 데이터베이스 기술이 아니라 API를 위한 쿼리 언어이며 기존 데이터를 사용해 해당 쿼리를 수행하는 런타임입니다. 핵심 아이디어는 단순하면서도 강력합니다: 클라이언트가 정확히 필요한 데이터를 지정합니다.

GraphQL의 주요 장점

단일 엔드포인트, 정확한 데이터 가져오기

수많은 REST 엔드포인트 대신, GraphQL API는 일반적으로 하나의 엔드포인트(예: /graphql)만 노출합니다. 클라이언트는 원하는 데이터를 정확히 설명하는 쿼리를 보내고, 서버는 그 데이터만을 응답합니다.

query GetUserAndPosts($id: ID!) {
  user(id: $id) {
    name
    email
    posts {
      title
      content
      comments {
        text
      }
    }
  }
}

서버는 이 쿼리를 받아 구조에 맞는 JSON 객체를 반환합니다. 과다 조회도, 부족 조회도 없으며, 단일 요청으로 효율적인 데이터 검색이 가능합니다!

네트워크 요청 감소

단일 쿼리에서 여러 리소스(예: 사용자, 해당 사용자의 포스트, 포스트에 대한 댓글)를 요청할 수 있기 때문에, 클라이언트가 수행해야 하는 HTTP 요청 수를 크게 줄일 수 있습니다. 이는 모바일 애플리케이션이나 높은 레이턴시 환경에서 큰 변화를 가져옵니다.

강력한 타입 스키마

GraphQL API는 스키마로 정의되며, 이는 클라이언트와 서버 간의 계약 역할을 합니다. 이 스키마는 사용 가능한 모든 데이터 타입과 연산을 명시합니다. 도구들은 이 스키마를 활용하여:

  • 개발 환경에서 자동 완성 및 검증 제공
  • 자동 문서 생성으로 API 문서를 항상 최신 상태로 유지
  • 타입 안전성을 확보해 런타임 이전에 오류를 잡아냄

버전 관리 번거로움 감소 (대부분)

잘 설계된 GraphQL 스키마를 사용하면 새로운 필드와 타입을 추가해도 기존 클라이언트를 깨뜨리지 않을 수 있습니다. 클라이언트는 명시적으로 요청하지 않은 새로운 필드를 단순히 무시합니다. 필드를 폐기(deprecate)하는 과정도 더 깔끔해지며, 전체 API에 파괴적인 변경을 강요하지 않고도 클라이언트에 경고를 전달할 수 있습니다.

실시간 기능 (구독)

GraphQL은 구독(subscription)을 기본 지원하여, 클라이언트가 이벤트에 구독하고 서버로부터 실시간 업데이트를 받을 수 있게 합니다. 이는 채팅 애플리케이션, 실시간 대시보드 및 기타 실시간 기능에 매우 강력합니다.

GraphQL vs REST illustration

Back to Blog

관련 글

더 보기 »

Drupal: Canvas 탐색 (파트 2)

Components 탐색 이전 포스트에서 나는 새로운 module을 익혔고, 좋은 시작을 보였다. 이번 포스트에서는 component를 탐구할 것이다.