본문 바로가기
카테고리 없음

gRPC vs REST vs GraphQL: 지연/페이로드/모바일 효율 비교

0몽글이0 2025. 11. 13. 21:45

gRPC vs REST vs GraphQL 는 같은 도메인 모델이라도 체감 성능·운영 난이도·모바일 배터리까지 전부 달라집니다. 이 글은 세 접근을 지연(latency), 페이로드(payload), 모바일 효율 관점에서 깊게 비교하고, 실무에서 바로 선택·조합할 수 있도록 정리합니다.

1) 핵심 개념 한 줄 요약

  • gRPC: HTTP/2 위 Protocol Buffers(바이너리) 를 사용한 RPC. 양방향 스트리밍, 멀티플렉싱, 작은 헤더로 저지연. 서버/서버, 네이티브 앱과 잘 맞습니다.
  • REST: 리소스 중심의 HTTP 표준(GET/POST/PUT/DELETE) + JSON. CDN/브라우저 캐시·디버깅·호환성 최고. 공개 API의 기본값.
  • GraphQL: 클라이언트가 필요한 필드만 선언적으로 요청. 엔드포인트는 보통 하나, 오버페치/언더페치 완화에 강함. 프론트 주도 개발 속도↑.

2) 지연 성능: 왕복과 연결의 차이

지연은 왕복 횟수(RTT), 연결 수립/재사용, 서버 내부 조합 비용이 좌우합니다.

  • gRPC: HTTP/2의 멀티플렉싱 덕에 하나의 연결에서 동시 호출이 가능하고, HPACK 헤더 압축으로 오버헤드가 작습니다. 서버/클라이언트 스트리밍으로 부분 결과를 먼저 밀어 TTFB를 앞당길 수 있습니다. 대량의 세분 호출을 N→1 연결로 모아 보낼 때 특히 유리합니다.
  • REST: HTTP/1.1 keep-alive 또는 HTTP/2라도 텍스트 헤더가 큼. 엔드포인트가 분산돼 있으면 화면 구성에 다중 요청이 필요하고, CORS·리다이렉트 등 부수 오버헤드가 누적될 수 있습니다. 반면 캐시가 맞으면 응답이 0RTT 수준으로 빨라집니다.
  • GraphQL: 한 번의 호출로 여러 리소스를 묶어 왕복 자체를 줄임. 다만 서버에서 리졸버 체인이 깊거나 N+1 쿼리가 발생하면 서버 내부 지연이 커집니다. DataLoader(배치/캐시), 필드별 타임아웃과 쿼리 복잡도 제한이 필수 운영 팁입니다.

실무 팁: 초저지연(알림/텔레메트리/채팅)은 gRPC, 페이지 최초 로딩은 GraphQL, 정적/캐시 친화 리소스는 REST가 평균적으로 유리합니다.

3) 페이로드 크기와 직렬화 비용

전송량과 (탈)직렬화 CPU는 모바일·서버 비용 모두에 직결됩니다.

  • gRPC(ProtoBuf): 필드 태그 기반 바이너리로 JSON 대비 30~70% 작고 파싱이 빠릅니다. 스키마(필수/옵션/반복)로 엄격한 진화가 가능. 단, 브라우저 직접 호출은 gRPC-web 어댑터가 필요합니다.
  • REST(JSON): 가독성·디버깅 용이. 키 중복·문자열 인코딩으로 바이트가 커지기 쉬우나 Brotli/Gzip로 상당 부분 상쇄됩니다. 숫자·불리언 등 타입 손실·파싱 비용은 고려해야 합니다.
  • GraphQL: 필요한 필드만 선택해 텍스트 총량을 줄일 수 있으나, 중첩 리스트·프래그먼트 남용 시 응답이 급증할 수 있습니다. 서버는 응답 압축 + 쿠키/헤더 다이어트(불필요 헤더 제거)로 바이트를 관리하세요.

정규화 팁: REST/GraphQL 모두 필드 화이트리스트, 페이지네이션(커서 기반), 부분 응답(Fields Mask) 를 쓰면 불필요 전송을 크게 줄입니다.

4) 모바일 효율: 배터리·전송·약한 네트워크

모바일은 라디오 깨움(wakeup) 과 왕복 수가 배터리를 갉아먹습니다.

  • gRPC: 지속 연결 + 멀티플렉싱으로 라디오 깨움 빈도가 줄고, 헤더가 작아 약한 네트워크에서 효율적입니다. 스트리밍으로 서버 푸시·실시간 업데이트가 자연스럽습니다.
  • REST: 엔드포인트가 많으면 화면 1회 렌더에 여러 HTTP 요청이 필요해 배터리 불리. 단, HTTP 캐시가 잘 맞으면 무적.
  • GraphQL: 화면 단위로 필요한 것을 한 번에 가져와 왕복을 최소화합니다. 오프라인 우선 앱은 클라이언트 캐시(Apollo/Relay) 로 사용자 경험을 매끈하게 만들 수 있습니다.

현장 공식: “1회 로딩형 화면(목록+헤더+요약) → GraphQL”, “빈번한 상호작용·양방향(채팅/센서) → gRPC”, “공개·캐시형 자원(상품 이미지/메타) → REST”.

5) 캐싱·오프라인·에지 친화성

  • REST: URL·메서드·Cache-Control로 브라우저·CDN 캐시를 바로 활용. stale-while-revalidate, ETag, Vary 등을 표준대로 쓰면 전송비와 지연이 크게 줄어듭니다.
  • gRPC: 바이너리 프레임이라 전통적 HTTP 캐시 친화성은 낮음. 보통 프록시/서버 캐시(Redis, Memcached)나 CDN 오브젝트 캐시를 별도 운용합니다.
  • GraphQL: 엔드포인트가 단일(/graphql)이라 필드 단위 캐시가 필요. Persisted Query(해시 기반 쿼리 고정), 응답 캐시 키 설계(변수·사용자 컨텍스트 분리)로 캐시 효율을 확보합니다. 클라이언트 캐시가 강력해 오프라인 UX 구성에 유리합니다.

6) 스키마·버전 관리·조직 체계

  • gRPC: .proto가 계약(Contract). 다국어 SDK 생성, 후방/전방 호환 관리가 명확. 플랫폼 팀이 있으면 대규모 마이크로서비스 표준으로 적합.
  • REST: URI(/v2)·헤더 버전·하위 호환 규칙 등 선택지가 자유롭지만, 장기 운영 시 스키마 드리프트 위험. API 문서 자동화(OpenAPI/Swagger)로 통제하세요.
  • GraphQL: 단일 스키마를 점진 진화(필드 @deprecated) 할 수 있어 무중단이 강점. 다만 스키마 거버넌스(리뷰/테스트/권한) 와 게이트웨이(스키마 연합)가 필수입니다.

7) 스트리밍·실시간 알림

  • gRPC: 서버/클라이언트/양방향 스트리밍을 언어/런타임 차원에서 1급 지원. 주가 틱, 위치·센서, 음성·영상 신호 등 실시간에 최적.
  • REST: SSE/WebSocket을 별도 구성해야 하며, 부하 분산·권한·재연결 로직을 추가로 설계해야 합니다.
  • GraphQL: Subscriptions(대개 WebSocket)로 실시간이 가능하지만, 스케일·샤딩·권한 모델이 복잡해집니다. 주기적 폴링 + 클라이언트 캐시 갱신이 현실적인 대안일 때가 많습니다.

8) 보안·관찰성·디버깅

  • REST: 텍스트라 로깅·리플레이·테스트가 쉽고 도구가 풍부합니다. 스코프 단위 OAuth, 키 회전, 레이트리밋을 표준 프록시로 붙이기 쉽습니다.
  • gRPC: 인터셉터로 메트릭/트레이스/리트라이 삽입이 간단. 와이어 디버깅은 어렵지만 서비스 간 관찰성은 오히려 강력합니다.
  • GraphQL: 쿼리 복잡도/깊이 제한, 필드 권한, N+1 탐지가 필수. 스키마·리졸버 레벨의 메트릭(필드 시간/에러율)을 계측해야 병목이 보입니다.

9) 선택 가이드(체크리스트)

  • 지연 최저·실시간 필요 → gRPC: 멀티플렉싱, 스트리밍, 낮은 헤더 오버헤드.
  • 캐싱·에지·호환성 → REST: CDN/브라우저 캐시, 문서화/온보딩 쉬움.
  • 화면 주도·집계형 조회 → GraphQL: 한 번에 필요한 것만, 프론트 생산성↑.
  • 혼합 전략 → 내부 마이크로서비스: gRPC, 외부 파트너/퍼블릭: REST, 앱 UI 데이터: GraphQL. BFF(Backend-for-Frontend) 로 조합을 깔끔히 분리.

10) 비용과 팀 역량도 변수다

기술적 우열보다 조직 구조·역량이 결과를 가릅니다.

  • 프론트 주도/다양한 화면 → GraphQL 로 개발 속도↑, 계약 변경 부담↓.
  • 플랫폼 중심/성능·일관성 중시 → gRPC 로 SDK·성능 표준화.
  • 파트너 생태계·문서 중요 → REST 가 여전히摩擦 최소.
    교육·도구·관찰성(모니터링/로그/분산 추적) 준비가 되지 않으면 이론적 장점이 실제로 나오지 않습니다.

11) 자주 묻는 질문(FAQ)

Q. 모바일에서 가장 배터리 효율적인 건?
화면 단위 데이터는 GraphQL(왕복 최소화), 지속·다중 호출은 gRPC(지속 연결) 가 유리합니다. REST는 캐시가 맞을 때 최고의 체감.
Q. 단순 CRUD·정적 리소스 위주면?
REST 가 구현/운영/문서화 비용이 가장 낮고 CDN 캐시 이점이 큽니다.
Q. 내부 마이크로서비스 표준은?
대체로 gRPC. 스키마 강제, 성능, 스트리밍, 코드 생성이 장점입니다.
Q. GraphQL은 항상 엔드포인트 하나면 충분?
원칙은 하나지만, 권한·지연 요구에 따라 리플리카/BFF 를 나눌 수 있습니다. Persisted Query와 캐시를 함께 설계하세요.

마무리

gRPC vs REST vs GraphQL 은 “하나만 정답”이 아닙니다. 워크로드를 지연/페이로드/모바일 효율로 분류하고, 캐시·스트리밍·스키마 거버넌스까지 묶어보면 선택은 자연스럽습니다. 실무에선 내부 gRPC + 외부 REST + UI GraphQL 같은 혼합 아키텍처가 가장 예측 가능하고 빠릅니다. 먼저 트래픽 상위 1~2개 화면/엔드포인트를 바꿔 지표를 확인하세요. TTFB·LCP·데이터 전송량·배터리가 동시에 개선되는 걸 바로 보게 될 겁니다.

티스토리툴바