“우리 프로젝트에는 어떤 API 통신 방식이 가장 적합할까?”
REST, gRPC, GraphQL은 각각 다른 철학과 구조를 가진 API 통신 방식이다.
이번 글에서는 지금까지의 내용을 바탕으로 프론트엔드 개발자 입장에서 어떤 상황에 어떤 API를 쓰면 좋은지 비교 정리해보도록 하자.
🧩 세 가지 API 방식 요약
| 항목 | REST API | gRPC | GraphQL |
|---|---|---|---|
| 핵심 특징 | 리소스 중심 | 고성능, 이진 전송 | 쿼리 기반 데이터 요청 |
| 구조 | URL + 메서드 | 메서드 호출 (.proto) | 쿼리 언어 |
| 전송 형식 | JSON (text) | Protocol Buffers (binary) | JSON |
| 장점 | 범용성, 쉬운 사용 | 빠름, 경량화 | 필요한 데이터만 요청 가능 |
| 단점 | 오버/언더페칭 | 브라우저 사용 제한 | 학습 곡선, 캐싱 어려움 |
| 스트리밍 | ❌ 없음 | ✅ 양방향 가능 | ✅ 단방향 가능 (subscription) |
| 브라우저 지원 | 완전 지원 | gRPC-Web 필요 | 완전 지원 |
🛠 실무 적용 시 고려 포인트
✅ REST를 선택할 때
- 범용적인 웹 서비스 (대부분의 SaaS, CMS, CRUD 중심 앱)
- 브라우저 호환성 & 캐싱 활용이 중요한 경우
- 단순하고 직관적인 API 설계가 우선일 때
✅ gRPC를 선택할 때
- 서버 간 통신(Microservice), 모바일/IoT 등 성능이 중요한 경우
- 실시간 양방향 통신이 필요한 시스템 (ex. 채팅, 스트리밍)
- 브라우저에서 사용 시 gRPC-Web + Envoy 설정 가능
✅ GraphQL을 선택할 때
- 프론트엔드 중심의 UI/UX가 복잡하고 유동적인 경우
- 화면마다 필요한 데이터가 다양하고 조합이 자유로운 경우
- 한 번의 요청으로 여러 자원을 가져오고 싶을 때
💡 선택 가이드 – 상황별 추천
| 상황 | 추천 방식 | 이유 |
|---|---|---|
| 일반적인 CRUD 웹 서비스 | REST | 단순하고 빠른 구현 가능 |
| 모바일 앱 or IoT 기기 | gRPC | 데이터 소형화, 속도 중요 |
| 복잡한 대시보드, 피드 기반 UI | GraphQL | 오버페칭 최소화, 쿼리 자유도 |
| 백엔드 간 통신 | gRPC | 고속, 타입 안정성, 멀티 서비스 연동 |
| 외부 API 제공 (공공, SDK 등) | REST or GraphQL | 문서화 편의성 / 유연한 응답 설계 |
| 데이터 보안 + 성능이 핵심 | gRPC + TLS | Protocol Buffers + HTTP/2 + TLS 적용 |
✅ 프론트엔드 개발자를 위한 실전 팁
- GraphQL은 UI 요구사항에 맞춘 API 설계에 특히 유리
- REST는 브라우저 친화적 캐싱과 도구 지원이 가장 풍부
- gRPC는 브라우저에서 직접 사용 시 gRPC-Web + 프록시 구조 필요
- 혼합 사용도 가능: REST + GraphQL, REST + gRPC 등 상황에 따라 조합 가능
✍️ 마무리 요약
REST, gRPC, GraphQL은 각각 다른 강점을 가진 API 통신 방식이다.
프로젝트의 성격, 팀 구성, 퍼포먼스 요구사항에 따라 유연하게 선택하고 조합하는 것이 핵심이다.
okorion's Tech Study Blog.