Waylog Blog

REST API vs GraphQL: 언제 무엇을 쓸까?

Backend

백엔드 API를 설계할 때 가장 먼저 부딪히는 난제입니다. "요즘 핫한 GraphQL을 쓸까요, 아니면 국밥 같은 REST를 쓸까요?" 정답은 **"상황에 따라 다르다"**입니다. 하지만 그 '상황'을 판단하는 기준을 명확히 아는 것이 중요합니다.

1. REST API (Representational State Transfer)

리소스(Resource)를 중심으로 디자인된 아키텍처입니다. HTTP 메서드(GET, POST, PUT, DELETE)를 그대로 사용하므로 직관적이고 캐싱이 쉽습니다.

1.1 장점

  • 캐싱(Caching) 용이: HTTP 표준을 따르므로 브라우저나 CDN 레벨에서 캐싱이 자연스럽게 됩니다.
  • 단순함: 별도의 클라이언트 라이브러리 없이 fetch만으로 쉽게 호출할 수 있습니다.
  • 범용성: MSA 환경에서 서비스 간 통신에 표준처럼 쓰입니다.

1.2 단점

  • Overfetching: 사용자 이름만 필요한데, /users/1을 호출하면 주소, 전화번호, 가입일 등 불필요한 정보까지 다 받아옵니다.
  • Underfetching: 필요한 정보를 얻기 위해 여러 번 요청해야 할 수 있습니다. (사용자 정보 + 작성한 글 목록 + 댓글 목록...)

2. GraphQL (Graph Query Language)

페이스북이 만든 쿼리 언어입니다. 클라이언트가 "원하는 데이터의 모양"을 정의해서 요청하면, 서버가 딱 그 모양대로 응답을 줍니다.

2.1 장점

  • 정확한 데이터 패칭: Overfetching과 Underfetching 문제를 완벽하게 해결합니다. 모바일 환경처럼 네트워크 대역폭이 중요한 곳에서 유리합니다.
  • 단일 엔드포인트: /graphql 하나만 관리하면 됩니다.
  • 강력한 타입 시스템: 스키마(Schema)가 명확하게 정의되어 있어, 프론트엔드와 백엔드 간의 소통 오류가 줄어듭니다.

2.2 단점

  • 복잡성: 서버 구현이 복잡하고, 학습 곡선이 높습니다. Apollo Client 같은 무거운 라이브러리가 필요할 수 있습니다.
  • 캐싱의 어려움: 모든 요청이 POST로 오고 엔드포인트가 하나라, URL 기반의 캐싱 전략을 쓸 수 없습니다.

3. 선택 가이드

  • GraphQL 추천:

    • 서로 다른 클라이언트(웹, iOS, Android)가 각기 다른 모양의 데이터를 원할 때
    • 데이터의 관계가 복잡한 그래프 형태일 때 (SNS 등)
    • 프론트엔드 개발자의 생산성이 최우선일 때

  • REST API 추천:

    • 단순한 CRUD 애플리케이션일 때
    • HTTP 캐싱을 적극적으로 활용해야 할 때
    • 공개 API(Public API)를 만들 때 (사용자가 GraphQL을 모를 수 있음)