📌 백엔드 (Backend)

REST vs GraphQL vs gRPC

언제 어떤 방식을 선택해야 하는가

1. 서론: API 통신의 진화

백엔드와 프론트엔드, 혹은 서비스 간의 통신을 위해 가장 중요한 요소는 API 설계 방식입니다.
오늘날 대표적으로 사용되는 방식은 다음 세 가지입니다.

REST (Representational State Transfer)
GraphQL
gRPC (Google Remote Procedure Call)

각각은 다른 철학과 설계 원칙을 가지고 있으며, 서비스 규모와 요구사항에 따라 적합성이 달라집니다.

2. REST (Representational State Transfer)

개념

2000년대 초반부터 널리 사용된 아키텍처 스타일
**리소스(자원)**를 중심으로 한 설계 (/users, /posts/:id 등)
HTTP 메서드(GET, POST, PUT, DELETE)를 활용

장점

단순하고 직관적 → 학습 비용이 낮음
HTTP 표준 기반 → 인프라 친화적
캐싱, 로깅, 보안 등 다양한 에코시스템 지원

단점

Over-fetching: 필요 없는 데이터까지 불필요하게 가져옴
Under-fetching: 원하는 데이터를 얻기 위해 여러 번 호출 필요
대규모 API 스펙 관리 어려움

사용 사례

CRUD 기반 서비스 (게시판, 전자상거래)
빠른 프로토타이핑 및 범용 API

3. GraphQL

개념

2015년 Facebook에서 공개
클라이언트가 필요한 데이터 구조를 직접 정의해서 요청 가능
단일 엔드포인트(/graphql)에서 다양한 쿼리 처리

장점

Over-fetching / Under-fetching 문제 해결
스키마 기반 → 강력한 타입 시스템 제공
API 문서화 및 개발자 경험(DX) 향상 (GraphiQL, Playground)

단점

서버 구현 복잡도 증가
캐싱이 어렵고, N+1 쿼리 문제 발생 가능
단순한 API에는 오히려 과한 선택

사용 사례

복잡한 UI를 가진 프론트엔드 (대시보드, SNS)
다양한 클라이언트(Web, iOS, Android)에서 동일 API 활용

4. gRPC (Google Remote Procedure Call)

개념

Google에서 개발한 고성능 RPC 프레임워크
Protocol Buffers (protobuf) 기반 직렬화 사용
HTTP/2 기반 → 멀티플렉싱, 스트리밍 지원

장점

빠른 직렬화/역직렬화 → 성능 우수
양방향 스트리밍 가능 → 실시간 서비스에 적합
명확한 인터페이스 정의(IDL) → 타입 안정성 보장

단점

디버깅 및 테스트 도구 부족 (REST만큼 친숙하지 않음)
브라우저 직접 지원 제한 (프록시 필요)
초기 학습 및 인프라 설정 부담

사용 사례

마이크로서비스 간 통신
실시간 스트리밍 서비스 (채팅, IoT, 게임)
대규모 트래픽이 요구되는 백엔드 시스템

5. 비교 정리

구분 REST GraphQL gRPC

철학 리소스 기반 클라이언트 주도 쿼리 함수 호출 기반

전송 HTTP/1.1 HTTP/1.1 (대부분) HTTP/2 + Protobuf 프로토콜

성능 보통 보통~좋음 매우 우수

학습 낮음 중간 높음 난이도

캐싱 용이 어려움 상대적으로 어려움

적합 사례 범용 API, 간단한 복잡한 UI, 다양한 마이크로서비스, CRUD 클라이언트 지원 실시간 스트리밍

6. 선택 기준 (Best Practice)

REST
- 소규모 프로젝트, 단순 CRUD, 빠른 개발이 필요한 경우\
- 캐싱 및 HTTP 친화성이 중요한 경우
GraphQL
- 다양한 클라이언트에서 세밀한 데이터 제어가 필요한 경우\
- 복잡한 UI/대시보드, 모바일 최적화가 필요한 경우
gRPC
- 마이크로서비스 아키텍처, 내부 서비스 간 통신\
- 대규모 트래픽, 낮은 지연시간이 중요한 경우\
- 실시간 스트리밍 서비스(채팅, IoT, 게임)

7. 심화 관점: 전문가 토론 포인트

보안
- REST/GraphQL: OAuth 2.0, JWT와 친화적\
- gRPC: TLS 기반 보안은 기본이지만 세션 기반 인증은 직접 구현 필요
모니터링 및 운영
- REST는 성숙한 툴이 많음 (APM, 로깅, API Gateway)\
- GraphQL은 Observability가 상대적으로 미흡 → Federation 필요\
- gRPC는 분산 트레이싱(Jaeger, OpenTelemetry)과 잘 어울림
아키텍처 트렌드
- 단일 서비스 → REST 권장\
- 대규모 프론트엔드/모바일 지원 → GraphQL 권장\
- 마이크로서비스/실시간 처리 → gRPC 권장

8. 결론

API 설계에는 정답이 없습니다.
서비스의 성격, 팀의 역량, 운영 환경에 따라 최적의 선택이 달라집니다.

빠른 개발과 범용성: REST
클라이언트 친화적 데이터 제어: GraphQL
고성능·실시간·마이크로서비스: gRPC

👉 결국 중요한 것은 **기술 자체보다 “문제를 해결하는 적합성”**입니다.