REST vs GraphQL vs gRPC — 각각 언제 선택하는가?

Question

IT Interview Practice · Accepted Answer

이 셋은 서로 다른 세 가지 API 패러다임으로, 각각 다른 제약에 최적화되어 있다. 보편적 승자는 없다 — 올바른 선택은 **소비자, 데이터 형태, 네트워크**에 달려 있다.

## 한눈에 보는 셋

```text
           REST                 GraphQL              gRPC
Style      resources + HTTP     single query graph   RPC (call methods)
Transport  HTTP/1.1, JSON       HTTP, JSON           HTTP/2, Protobuf (binary)
Fetching   fixed endpoints      client picks fields  fixed methods
Schema     optional (OpenAPI)   strong, typed        strong, .proto
Browser    native, cacheable    needs client lib     limited (needs proxy)
```

## REST

평범한 HTTP 위의 리소스 지향. public API, CRUD 서비스, 그리고 HTTP caching·보편성·단순함에서 이득을 보는 모든 것에 **선택하라**. 약점은 **over-fetching**(필드 하나만 필요해도 `/users/42` 전체를 받음)과 **under-fetching**(`N+1` 문제: user를 가져온 뒤 각 order를 가져오려 반복).

```http
GET /users/42            → the whole user
GET /users/42/orders     → a second round trip
```

## GraphQL

**client가 원하는 것을 정확히 지정**하는 단일 엔드포인트로, 한 query에서 over/under-fetching을 해결한다. 풍부한 프런트엔드(특히 round trip이 비싼 모바일)와 여러 client가 같은 데이터의 다른 형태를 필요로 할 때 **선택하라**.

```text
POST /graphql
query { user(id: 42) { name orders { total } } }   ← one round trip, exact fields
```
트레이드오프: HTTP caching이 더 어렵고(모든 것이 `/graphql`로의 `POST`), 순진한 resolver는 비싼 `N+1` 데이터베이스 query를 숨길 수 있다.

## gRPC

**HTTP/2** 위에서 **Protobuf**를 쓰는 계약 우선(contract-first) RPC. 이진이며 다중화되어 빠르고 컴팩트하며 streaming을 지원한다. 성능과 엄격한 타이핑이 중요한 마이크로서비스 백엔드의 **내부 service-to-service** 통신에 **선택하라**. 약점: 브라우저 지원이 나쁘고(grpc-web 같은 proxy 필요) 사람이 읽을 수 없다.

## 선택하기

```text
Public API, CRUD, caching, wide reach   → REST
Complex/varied frontend data needs      → GraphQL
High-performance internal microservices → gRPC
(Real systems mix them: REST/GraphQL at the edge, gRPC between services.)
```

## 왜 중요한가

senior 수준에서 면접관은 정의보다 당신이 **제약에 맞춰 선택을 정당화**할 수 있는지에 관심이 있다 — 이 질문은 사실 "hype를 좇는 대신 기술을 문제에 맞출 수 있는가?"이다. 가장 강한 답은 각각이 해결하는 고통에 닻을 내린다: GraphQL은 까다로운 프런트엔드를 위해 over/under-fetching을 죽이려 존재하고, gRPC는 내부 service 호출을 빠르고 강타입으로 만들려 존재하며, REST는 HTTP caching·도구·보편적 친숙함이 public·CRUD 스타일 API에 엄청난 실무적 이점이라 여전히 기본값이다. 결정적으로, senior 엔지니어는 이것이 **양자택일이 아님**을 짚는다 — 흔한 아키텍처는 public 경계에 REST나 GraphQL, 백엔드 마이크로서비스 사이에 gRPC다 — 그리고 구체적 트레이드오프(GraphQL의 caching과 `N+1` 위험, gRPC의 약한 브라우저 이야기)를 든다. 기능을 읊는 능력이 아니라 적합성과 비용에 대한 그 추론이 신호다.

한눈에 보는 셋

REST

GraphQL

gRPC

선택하기

왜 중요한가

관련 질문