💡 REST vs gRPC 시리즈
- gRPC의 이해 — REST와 무엇이, 왜 다른가 (현재 글)
- 실제 gRPC 도입을 위한 PoC 과정과 결국 REST를 결정한 이유 (작성 예정)
이 시리즈는 사내에서 gRPC 도입을 검토하며 직접 벤치마크를 돌려본 경험을 바탕으로 합니다. 이번 글에서는 개념을 다지고, 다음 글에서 실제 PoC 과정과 최종적으로 REST를 선택하게 된 이유를 다룹니다.
들어가며
"gRPC가 REST보다 빠르다"는 말을 자주 듣습니다. 하지만 막상 도입을 검토하다 보면 이 문장은 반쪽짜리라는 걸 알게 됩니다. gRPC가 빠른 건 특정 조건에서이고, 그 조건이 무엇인지 이해하지 못하면 오버엔지니어링으로 이어지기 쉽습니다.
결국 두 방식의 차이는 직렬화 방식과 전송 프로토콜이라는 두 개의 층에서 발생합니다. 이 글에서는 이 두 층을 하나씩 뜯어보며 gRPC의 이득이 "어디서" 나오는지를 직관적으로 이해해 보겠습니다.
1. 두 방식의 스택 비교
REST와 gRPC를 비교할 때 흔히 "REST vs gRPC"로 대립시키지만, 정확히는 각각이 사용하는 기술 스택의 조합을 비교하는 것입니다. 이 글에서는 아래와 같은 전형적인 조합을 기준으로 이야기합니다.
| 계층 | REST (전형) | gRPC |
|---|---|---|
| 인터페이스 정의 | 문서 / OpenAPI (느슨) | .proto 스키마 (엄격, 코드 생성) |
| 직렬화 | JSON (텍스트) | Protocol Buffers (바이너리) |
| 전송 | 주로 HTTP/1.1 | HTTP/2 (필수) |
| 스트리밍 | 별도 (SSE / WebSocket) | 네이티브 (서버 / 클라 / 양방향) |
| 사람이 읽기 | 쉬움 (curl) | 어려움 (바이너리) |
| 브라우저 | 기본 지원 | gRPC-Web 프록시 필요 |
즉 우리가 "REST vs gRPC 성능"을 이야기할 때 실제로 비교하는 건 JSON/HTTP1.1 vs Protobuf/HTTP2입니다. 그래서 성능 차이의 상당 부분은 "직렬화"와 "전송" 두 요인이 합쳐진 결과라는 점을 기억해야 합니다.
2. 직렬화 — JSON vs Protobuf
gRPC가 "작다"고 할 때 그 이득의 핵심은 필드명을 반복하지 않는다는 데 있습니다. 같은 상품 데이터 하나를 두 방식으로 인코딩해 보면 차이가 분명해집니다.
먼저 JSON입니다.
{"id":42,"name":"Product-42","price":41.99,"inStock":true,"category":"BOOKS"}JSON은 id, name, price, inStock, category라는 필드명과 따옴표·콜론·중괄호가 레코드마다 매번 반복됩니다. 상품이 1,000개라면 이 라벨도 1,000번 실려 나가는 셈입니다.
반면 Protobuf는 필드명 없이 "번호 + 값"만 담습니다. 개념적으로 표현하면 아래와 같습니다.
[08 2A] // 필드1(id) = 42
[12 0A] Product-42 // 필드2(name)
[19 ..] 41.99 // price
[20 01] // inStock = true필드명이 아예 없습니다. 08, 12 같은 1바이트 태그(필드번호 + 타입)만 붙을 뿐입니다. 이 "라벨 제거"가 바로 크기 이득의 원천입니다.
핵심 직관: 이득은 필드명이 반복되는 정도에 비례한다. 필드가 많고 레코드가 많을수록 JSON의 낭비가 커지고, 그만큼 Protobuf가 유리해진다.
3. 전송 — HTTP/1.1 vs HTTP/2
gRPC는 HTTP/2 위에서만 동작합니다. 두 프로토콜의 가장 큰 차이는 멀티플렉싱입니다.
HTTP/1.1은 요청마다 커넥션이 필요하거나 커넥션을 순차적으로 재사용합니다. 대신 큰 응답은 여러 커넥션에 병렬로 나눠 처리할 수 있습니다. 반면 HTTP/2는 단일 커넥션에서 여러 스트림을 동시에 다중화하고 헤더도 압축합니다. 다만 큰 응답은 flow-control window에 걸릴 수 있다는 함정이 있습니다.
멀티플렉싱은 작은 요청이 많을 때 큰 이득입니다. 반대로 거대한 응답을 동시에 많이 보내면, 단일 커넥션이 오히려 병목이 될 수 있습니다. 이 부분은 다음 글의 실험에서 직접 관찰하게 됩니다("HTTP/2로 바꿨더니 오히려 느려진" 역전 현상).
4. 가장 헷갈리는 부분 — 구조화 데이터 vs blob
여기서 가장 흔한 오해를 짚고 넘어가야 합니다. "데이터가 크면 무조건 gRPC가 유리하다"는 틀린 말입니다. 기준은 크기가 아니라 그 바이트가 무엇으로 채워졌는가입니다.
이미지·동영상·zip 같은 blob(불투명한 덩어리) 은 이미 최종 바이트 형태라 직렬화할 구조 자체가 없습니다. 두 프로토콜 모두 그냥 바이트를 복사할 뿐이라 Protobuf의 이득이 거의 없습니다. 오히려 JSON에 base64로 실으면 크기가 약 33% 늘어나고, 이런 데이터는 Range 요청·캐싱·CDN을 쓸 수 있는 REST나 "스토리지 + URL" 방식이 더 유리합니다.
반대로 필드명과 타입이 붙은 객체가 수천 개인 구조화 데이터는 같은 데이터를 여러 방식으로 인코딩할 수 있고, JSON은 필드명을 매번 반복해 낭비합니다. 여기서 Protobuf는 라벨 제거로 크기와 CPU를 모두 절감하며, 그 이득은 레코드 수에 비례합니다.
한 줄 판별법: 텍스트 에디터로 열었을 때
"id":,"name":처럼 같은 필드명이 계속 반복되면 구조화 데이터(→ gRPC 유리), 알아볼 수 없는 덩어리면 blob(→ 프로토콜 무관)이다. 참고로 CSV는 필드명을 헤더에 한 번만 쓰므로 이미 효율적이라 blob에 가깝다.
정리하며
gRPC의 이득은 마법이 아니라 두 가지 구조적 선택에서 나옵니다. 하나는 Protobuf가 반복되는 필드명을 제거한다는 것, 다른 하나는 HTTP/2가 작은 요청을 멀티플렉싱한다는 것입니다. 그래서 gRPC의 이득은 payload가 크고 구조화될수록, 그리고 트래픽이 높을수록 커집니다.
바꿔 말하면, 소형 메시지에 저트래픽 환경이라면 REST(JSON/HTTP1.1)로도 충분한 경우가 많습니다. 그리고 blob성 데이터에는 gRPC의 이득이 거의 없습니다. "빠르다더라"는 소문만으로 도입하면 오버엔지니어링이 되기 쉬운 이유입니다.
다음 글에서는 이 개념들을 실제로 검증하기 위해 진행한 PoC 과정을 다룹니다. Spring Boot와 Docker, k6로 직접 벤치마크를 돌려 payload 크기별 처리량, 압축의 반전, 서비스 간 통신에서의 CPU 효율, 그리고 HTTP/2 역전 현상까지 측정한 결과를 공유하고, 그럼에도 우리가 최종적으로 REST를 선택하게 된 이유를 이야기하겠습니다.
