REST vs GraphQL vs gRPC
선택 기준
| 항목 | REST | GraphQL | gRPC |
|---|---|---|---|
| 포맷 | JSON | JSON | Protobuf |
| 데이터 선택권 | 서버 | 클라이언트 질의 | 서버(스키마) |
| 스키마 | 선택(OpenAPI) | 필수 | 필수(.proto) |
| 스트리밍 | 제한적 | subscription | 양방향 기본 |
| HTTP 캐시 | 활용 가능 | 별도 구현 | 별도 구현 |
| 브라우저 직접 호출 | 가능 | 가능 | 프록시 필요 |
언제 무엇을
- REST: 공개 API, 캐시 이득이 큰 조회, 단순 CRUD
- GraphQL: 화면마다 필요한 필드가 다른 클라이언트가 여럿일 때. 과다와 과소 조회 해소
- gRPC: 내부 서비스 간 통신, 낮은 지연과 높은 처리량, 스트리밍
실무 포인트
- GraphQL의 실제 비용은 N+1 조회와 쿼리 복잡도 폭주다. 배칭과 깊이, 복잡도 제한이 사실상 필수
- gRPC는 브라우저에서 직접 호출이 어렵다. 엣지는 REST, 내부는 gRPC 조합이 흔하다
- 세 방식은 배타적이지 않다. 한 시스템에서 계층별로 나눠 쓴다
- 전환 판단 기준은 취향이 아니라 클라이언트 수, 필드 요구 편차, 지연 예산이다