🧠 gRPC란? 개념부터 자세히 보기
gRPC는 Google에서 만든 오픈소스 RPC(Remote Procedure Call) 프레임워크입니다.
다른 서버의 함수를 로컬처럼 호출할 수 있게 해주는 기술로, 고속 통신과 양방향 스트리밍에 최적화되어 있습니다.
🔁 RPC란?
- RPC(Remote Procedure Call)는 다른 서버의 함수를 마치 내 코드처럼 호출할 수 있는 개념입니다.
- 예:
userService.getUser(1)호출 시 실제로는 다른 서버에서 동작하지만 로컬 함수처럼 보임
🧾 Protocol Buffers (protobuf)
- gRPC는 데이터를 JSON이 아닌 Protocol Buffers 형식으로 주고받습니다.
.proto파일로 메시지 및 서비스 정의 → 자동으로 서버/클라이언트 코드 생성
syntax = "proto3";
service UserService {
rpc GetUser (UserRequest) returns (UserResponse);
}
message UserRequest {
int32 id = 1;
}
message UserResponse {
string name = 1;
string email = 2;
}⚡ HTTP/2 사용
- gRPC는 HTTP/2 기반으로 동작해 다음과 같은 성능 이점을 가짐:
- 다중 요청/응답 처리 (Multiplexing)
- 헤더 압축
- 양방향 스트리밍 지원
🔄 gRPC 통신 방식 4가지
| 방식 | 설명 |
|---|---|
| Unary | 일반적인 요청-응답 1:1 |
| Server Streaming | 서버가 여러 응답을 스트리밍 |
| Client Streaming | 클라이언트가 여러 요청을 스트리밍 |
| Bi-directional | 양방향 실시간 통신 지원 |
🧠 REST vs GraphQL vs gRPC - 언제, 왜, 무엇을 선택할까?
개발을 하다 보면 클라이언트와 서버 간 통신을 위해 어떤 방식을 사용할지 선택해야 할 때가 많습니다. REST가 익숙하지만, GraphQL이나 gRPC 같은 신기술이 계속해서 주목받고 있죠. 그렇다면 이 세 가지 API 통신 방식은 어떻게 다르고, 언제 어떤 것을 써야 할까요?
✅ 간단 요약 비교표
| 항목 | REST | GraphQL | gRPC |
|---|---|---|---|
| 전송 방식 | HTTP/JSON | HTTP/JSON | HTTP/2 + Protocol Buffers |
| 엔드포인트 | 여러 개 | 단일 (/graphql) | 여러 개 (RPC 메서드) |
| 요청 데이터 | 고정된 응답 | 원하는 데이터만 지정 | 명시적 메시지 정의 |
| 성능 | 보통 | 효율적 | 가장 빠름 |
| 학습 난이도 | 쉬움 | 중간 | 높음 |
| 브라우저 호환 | 매우 좋음 | 좋음 | 제한적 (gRPC-web 필요) |
| 스트리밍 | 제한적 | 불가 | 가능 (양방향) |
🌐 REST란?
- 전통적인 HTTP API 방식
- URL과 HTTP 메서드(GET, POST 등)를 사용
- JSON 기반 응답
장점:
- 단순하고 익숙함
- 테스트와 디버깅이 쉬움 (Postman 등)
단점:
- 오버페칭/언더페칭 문제
- 여러 자원을 얻기 위해 다수의 요청 필요
🔍 GraphQL이란?
- Facebook에서 만든 쿼리 언어 기반 API
- 하나의
/graphql엔드포인트로 모든 요청 처리 - 원하는 필드만 선택적으로 요청 가능
장점:
- 필요한 데이터만 가져올 수 있어 효율적
- 복잡한 UI에 적합 (모바일, 대시보드 등)
단점:
- 쿼리 언어 학습 필요
- 캐싱, 인증 처리 복잡
⚡ gRPC란?
- Google에서 만든 고성능 RPC 프레임워크
.proto파일로 서비스, 메시지, 메서드 정의- HTTP/2 + Protocol Buffers 사용
장점:
- 매우 빠름 (바이너리 기반)
- 타입 안전성 높음
- 양방향 스트리밍 지원
단점:
- 브라우저 직접 사용 어려움 (gRPC-Web 필요)
- 디버깅 복잡 (바이너리 응답)
- 도입 및 설정 난이도 높음
❗ gRPC가 무조건 좋은 건 아닐까?
gRPC는 확실히 기술적으로 강력합니다. 하지만 현실에서는 단점도 분명 존재합니다:
-
웹 브라우저에서 직접 사용 어려움
- REST나 GraphQL은 fetch/axios로 쉽게 사용 가능
- gRPC는 중간 proxy(gRPC-Web + Envoy 등) 필요
-
디버깅, 로그 확인 불편
- JSON이 아닌 바이너리라 사람이 보기 힘듦
- Postman으로 테스트 불가
-
학습 곡선이 큼
- .proto 작성 → 컴파일 → 코드 생성 등 설정 많음
-
언제나 빠른 게 중요한 건 아님
- 단순 CRUD는 REST나 GraphQL로 충분
🤔 언제 무엇을 써야 할까?
| 상황 | 추천 기술 |
|---|---|
| 단순한 웹/앱 API | REST |
| 다양한 데이터 조합 필요 (모바일 등) | GraphQL |
| 고성능 마이크로서비스 통신 | gRPC |
| 양방향 스트리밍, 실시간 처리 | gRPC |
📌 결론
기술은 "좋다/나쁘다"보다 언제, 왜 사용하는지가 더 중요합니다.
- 빠르게 만들고 익숙한 방식이 필요하다면 REST
- 프론트에서 유연한 데이터 요청이 중요하다면 GraphQL
- 마이크로서비스, 고성능, 실시간 처리가 목적이라면 gRPC
INTJ