기술 학습

GraphQL과 비교한 REST API의 한계점

EpicArts 2025. 2. 16. 21:13

1. REST API vs. GraphQL: 무엇이 다를까?

많은 백엔드 개발자들이 REST API를 기본적으로 사용하지만, 점점 더 많은 서비스에서 GraphQL을 도입하고 있습니다.
그렇다면, REST API는 왜 한계를 가질까요? 그리고 GraphQL이 이를 어떻게 해결할까요?

📌 REST API의 특징

  • 리소스 중심 → GET /users, POST /orders 등 리소스를 기반으로 동작
  • 고정된 응답 구조 → 엔드포인트별로 반환되는 데이터 구조가 정해져 있음
  • 다양한 HTTP 메서드 지원 → GET, POST, PUT, DELETE 등을 사용하여 CRUD 수행

📌 GraphQL의 특징

  • 클라이언트가 원하는 데이터만 요청 가능 → users { id, name, email }
  • 단일 엔드포인트 사용 → POST /graphql 하나의 엔드포인트로 모든 요청 처리
  • 서버가 아니라 클라이언트가 응답 구조를 정의

이제 REST API의 주요 한계를 살펴보고, GraphQL이 이를 어떻게 해결하는지 알아보겠습니다.


2. REST API의 주요 한계점

🔹 2.1 과도한 데이터 전송 (Over-fetching)

REST API는 엔드포인트별로 정해진 데이터 구조를 반환하기 때문에, 클라이언트가 필요 없는 데이터를 받는 경우가 많습니다.

📌 예제: 특정 사용자의 정보 요청

http
복사편집
GET /users/1
json
복사편집
{ "id": 1, "name": "John Doe", "email": "john@example.com", "createdAt": "2024-02-10T12:00:00Z", "updatedAt": "2024-02-10T12:30:00Z", "posts": [ { "id": 101, "title": "REST API 설계 가이드" } ] }

사용자는 id, name과 email만 필요하지만, 불필요한 createdAt, updatedAt, posts 데이터까지 포함되어 있음Over-fetching 발생

📌 GraphQL을 사용하면?

graphql
복사편집
query { user(id: 1) { id name email } }
json
복사편집
{ "user": { "id": 1, "name": "John Doe", "email": "john@example.com" } }

필요한 데이터만 받아서 네트워크 사용량 최적화


🔹 2.2 여러 요청을 보내야 하는 문제 (Under-fetching & N+1 문제)

REST API에서는 연관된 데이터를 가져오기 위해 여러 개의 API 요청을 보내야 하는 경우가 많습니다.

📌 예제: 특정 사용자와 해당 사용자의 게시글을 가져오기 위한 요청

http
복사편집
GET /users/1
json
복사편집
{ "id": 1, "name": "John Doe" }
http
복사편집
GET /users/1/posts
json
복사편집
[ { "id": 101, "title": "REST API 설계 가이드" }, { "id": 102, "title": "GraphQL의 장점" } ]

GraphQL을 사용하면?

graphql
복사편집
query { user(id: 1) { id name posts { id title } } }
json
복사편집
{ "user": { "id": 1, "name": "John Doe", "posts": [ { "id": 101, "title": "REST API 설계 가이드" }, { "id": 102, "title": "GraphQL의 장점" } ] } }

한 번의 요청으로 필요한 데이터를 모두 받아옴!


🔹 2.3 엔드포인트 관리의 어려움

REST API에서는 엔드포인트가 많아질수록 관리가 어려워집니다.

  • /users
  • /users/{id}
  • /users/{id}/posts
  • /users/{id}/comments

📌 GraphQL을 사용하면?
GraphQL은 모든 요청을 /graphql 엔드포인트 하나에서 처리합니다.

  • 필요할 때마다 원하는 데이터를 쿼리로 요청하면 되므로, 새로운 API를 추가할 필요 없음

3. REST API vs. GraphQL: 언제 어떤 것을 선택해야 할까?

비교 항목REST APIGraphQL

데이터 요청 방식 정해진 구조 반환 원하는 필드만 요청 가능
엔드포인트 여러 개 필요 단일 엔드포인트
Over-fetching 문제 발생 가능 없음
Under-fetching 문제 추가 요청 필요 한 번의 요청으로 해결
성능 최적화 캐싱 용이 동적 쿼리로 최적화 필요
보안 및 접근제어 엔드포인트별 권한 관리 필드 단위 권한 설정 필요

📌 GraphQL이 적합한 경우

  • 프론트엔드(React, Vue 등)와 백엔드(API) 간 협업이 많을 때
  • 모바일 환경에서 데이터 사용량을 최소화해야 할 때
  • 클라이언트가 다양한 데이터 조합을 필요로 할 때

📌 REST API가 적합한 경우

  • 단순한 CRUD API 제공
  • HTTP 캐싱을 적극적으로 활용해야 할 때
  • 대규모 시스템에서 보안이 중요한 경우

4. 결론: GraphQL이 REST API를 완전히 대체할까?

REST API는 여전히 대부분의 백엔드 개발에서 사용되고 있으며, GraphQL이 이를 완전히 대체하지는 않습니다.
하지만, 데이터 요청 방식의 유연성이 중요한 프로젝트에서는 GraphQL이 강력한 대안이 될 수 있습니다.

정리하자면…

1️⃣ REST API는 전통적인 웹 서비스에서 여전히 강력한 표준
2️⃣ GraphQL은 복잡한 데이터 요구사항이 있는 프로젝트에서 유리
3️⃣ 두 가지 기술을 함께 사용하는 하이브리드 방식도 가능

💡 다음 글에서는 "GraphQL을 실제로 프로젝트에 적용하는 방법"을 다뤄보겠습니다! 🚀