언제 REST 대신 GraphQL을 선택하고, 언제 선택하지 않겠습니까?

Question

IT Interview Practice · Accepted Answer

**누가 API를 소비하고 그들의 데이터 요구가 얼마나 다양한지**를 기준으로 선택하세요 — 유행이 아니라. 다양한 클라이언트가 각자 데이터를 형태 잡아야 할 때는 GraphQL이 이기고; 요청이 균일하고 캐시 가능하며 단순할 때는 REST가 이깁니다.

## GraphQL을 선택할 때

- **요구가 다른 여러 클라이언트** — web, iOS, Android가 각각 같은 엔티티에서 서로 다른 필드를 원합니다. GraphQL은 over/under-fetching을 없애 화면마다 새 endpoint를 출시하지 않아도 됩니다.
- **깊게 연관된/graph 형태의 데이터** — 하나의 쿼리가 N번의 REST round trip 대신 관계(`user -> posts -> comments`)를 순회합니다.
- **빠른 제품 반복** — 덧붙이는 schema 진화 덕분에 프론트엔드 팀이 새 백엔드 endpoint나 버전을 기다리지 않고 필드를 추가할 수 있습니다.
- **마이크로서비스 집계** — federated gateway가 여러 서비스 위에 하나의 graph를 제시합니다(BFF 패턴).

## REST를 선택할 때

- **단순하고 균일한 리소스**로 접근이 예측 가능한 경우 — 모든 클라이언트가 같은 형태를 원하는 CRUD.
- **HTTP 캐싱 / CDN이 가장 중요한** 경우 — REST의 URL + `GET` 모델은 모든 계층에서 손쉽게 캐시됩니다; GraphQL은 근접하려면 persisted query가 필요합니다.
- **파일 업로드/다운로드, 바이너리, 또는 공개 API**로 폭넓은 도구, 상태 코드, 단순함이 이기는 경우.
- **소규모 팀 / 낮은 복잡성** — GraphQL의 서버 측 비용(resolver, N+1 제어, query-cost 제한, schema 도구)은 endpoint 몇 개에는 그만한 가치가 없습니다.

## 솔직한 trade-off 표

| 고려 사항 | GraphQL | REST |
|---|---|---|
| Over/under-fetching | 설계상 해결됨 | 흔한 문제 |
| HTTP/CDN 캐싱 | 어려움(작업 필요) | 기본 제공, 쉬움 |
| Query-cost/DoS 제어 | 직접 추가해야 함 | 본질적으로 제한됨 |
| 클라이언트 유연성 | 높음 | 낮음 |
| 서버 복잡성 | 더 높음 | 더 낮음 |

이 둘은 배타적이지도 않습니다 — 많은 시스템이 공개/캐시 가능한 endpoint에는 REST를, 풍부한 내부 클라이언트에는 GraphQL을 노출합니다.

## 왜 중요한가

senior 면접관은 **충성심이 아니라 판단력**을 시험합니다. 강한 답은 축들 — 클라이언트 다양성, 캐싱 요구, 팀 성숙도, DoS 표면 — 을 짚고, GraphQL을 보편적으로 더 낫다고 파는 대신 그 실제 비용(캐싱과 query-cost 제어)을 인정합니다.

고려 사항	GraphQL	REST
Over/under-fetching	설계상 해결됨	흔한 문제
HTTP/CDN 캐싱	어려움(작업 필요)	기본 제공, 쉬움
Query-cost/DoS 제어	직접 추가해야 함	본질적으로 제한됨
클라이언트 유연성	높음	낮음
서버 복잡성	더 높음	더 낮음

GraphQL을 선택할 때

REST를 선택할 때

솔직한 trade-off 표

왜 중요한가

관련 질문