“gRPC가 빠르다는데, 프론트엔드 개발자는 왜 REST만 쓰고 있지?”
REST API는 웹 개발의 기본이 되었지만, 성능이 중요해진 최근에는
gRPC라는 새로운 방식이 주목받고 있다.
이번 글에서는 REST와 gRPC의 철학과 구조 차이, 그리고 프론트엔드 개발자 입장에서 왜 gRPC를 알아야 하는지를 정리해보자.
🌍 REST API의 기본 개념
REST는 자원을 URL로 표현하고, HTTP 메서드(GET, POST, PUT, DELETE 등)를 사용해 조작하는 웹 API의 표준 방식이다.
REST의 특징
- URL이 곧 자원의 주소 (
/users/123) - 상태 코드로 응답 의미를 명확하게 표현 (200, 201, 404, 500 등)
- JSON을 주고받으며, 사람이 읽기 쉬움
- 프론트엔드에서 사용하기 쉬움
🚀 gRPC란 무엇인가?
gRPC는 구글이 만든 고성능, 범용 API 통신 프레임워크이다.
내부적으로 Protocol Buffers(프로토콜 버퍼) 라는 이진 데이터 포맷을 사용해 속도와 효율을 극대화한다.
특징 요약
- HTTP/2 기반 + 바이너리 전송
- 인터페이스 정의는
.proto파일로 작성 - 다양한 언어에서 코드 자동 생성 (gRPC-codegen)
- 양방향 스트리밍 / 실시간 요청 처리 지원
📦 Protocol Buffers란?
JSON처럼 key-value 구조지만, 바이너리 포맷으로 훨씬 작고 빠르게 전송된다.
예시 (user.proto)
message User {
string name = 1;
int32 age = 2;
}이 정의를 통해 gRPC는 타입 안정성 있는 API를 자동 생성한다.
🆚 REST vs gRPC 주요 차이점
| 항목 | REST API | gRPC |
|---|---|---|
| 전송 포맷 | JSON (text) | Protocol Buffers (binary) |
| 통신 프로토콜 | HTTP/1.1 | HTTP/2 |
| 메시지 구조 | 유연 (key-value) | 엄격한 schema 기반 |
| 성능 | 느림 (파싱, 헤더 많음) | 빠름 (바이너리 + 멀티플렉싱) |
| 개발 편의성 | 쉽고 직관적 | 초기 설정 복잡, 자동화 필요 |
| 브라우저 호환 | 완전 지원 | 직접 사용 어려움 (추가 Proxy 필요) |
⚡️ 왜 gRPC는 고속 통신에 유리할까?
- HTTP/2 기반의 멀티 스트림 처리: 하나의 연결로 여러 요청을 동시에 처리 가능
- 헤더 경량화: REST보다 훨씬 적은 오버헤드
- 바이너리 직렬화(Protocol Buffers): 텍스트 기반 JSON보다 수십 배 빠름
- 스트리밍 지원: 단일 연결로 실시간 데이터 송수신 가능 (chat, 실시간 분석 등)
❓ 프론트엔드에서 gRPC를 쓸 수 있을까?
✅ 가능은 하지만, 브라우저는 gRPC-native를 직접 지원하지 않음.
→ 대신 gRPC-Web이라는 별도 패키지를 사용해야 함.
gRPC-Web 구조
[브라우저]
↓ gRPC-Web (JavaScript)
[Envoy Proxy] ← gRPC 변환
↓
[gRPC 백엔드 서버]- 브라우저 → HTTP/1.1 방식으로 요청
- Envoy 같은 프록시가 → gRPC 포맷으로 변환 후 백엔드에 전달
즉, gRPC는 직접 쓰기보다 백엔드와의 연결에서 Proxy 방식으로 연동하는 구조가 많다.
✅ 프론트엔드 개발자를 위한 실전 팁
- REST API는 여전히 대부분의 웹 프로젝트에 적합하고 범용적이다
- 성능 최적화가 중요한 프로젝트(대규모 실시간 데이터, 모바일, IoT)에서는 gRPC도 고려해볼 수 있다
- 브라우저 환경에서는 gRPC-Web + Envoy Proxy를 통해 제한적으로 연동 가능하다
- gRPC를 사용할 경우 프론트엔드도 코드 자동 생성, 타입 기반 요청/응답 처리가 필요하다 (→ TypeScript 통합 가능)
✍️ 마무리 요약
REST API는 웹 개발의 표준이지만, gRPC는 고성능 실시간 통신에 최적화된 새로운 방식이다.
프론트엔드에서도 그 구조를 이해하고, 어떤 프로젝트에서 쓰이는지 감 잡는 것이 중요하다.
okorion's Tech Study Blog.