서비스 간 통신을 위한 REST, gRPC, 메시지 큐를 비교하세요.

Question

Accepted Answer

세 가지 주요 선택지는 **REST**(HTTP/JSON), **gRPC**(HTTP/2 + Protobuf), 그리고 **메시지 큐**(Kafka/RabbitMQ)입니다. REST와 gRPC는 동기이고, 큐는 비동기입니다.

## 비교

| 측면 | REST | gRPC | 메시지 큐 |
|---|---|---|---|
| 스타일 | 동기 | 동기 | 비동기 |
| 페이로드 | JSON(텍스트) | Protobuf(바이너리) | 임의(종종 바이너리) |
| 성능 | 양호 | 높음 | 높은 처리량 |
| 계약 | OpenAPI(느슨) | `.proto`(엄격) | 스키마/이벤트 |
| 스트리밍 | 제한적 | 네이티브(양방향) | 발행/구독 |
| 적합한 용도 | 공개 API, 브라우저 | 내부 핫 경로 | 분리, 이벤트 |

## gRPC 계약 예시

```proto
service OrderService {
  // 강타입 RPC, 클라이언트 + 서버 스텁 자동 생성
  rpc GetOrder (OrderId) returns (Order);
}
message OrderId { string id = 1; }
message Order  { string id = 1; double total = 2; }
```

## 메시징 예시

```text
Order Service ─발행→ [ "OrderPlaced" topic ] ─▶ Inventory
                                              └────▶ Notifications
(생산자는 소비자를 알지도 기다리지도 않음)
```

## 선택하기

- **REST** — 외부 클라이언트, 폭넓은 호환성, 사람이 읽기 쉬움.
- **gRPC** — 내부, 저지연, 대용량 호출; 강한 계약; 스트리밍.
- **큐** — 분리, 버퍼링, event-driven 흐름, 장애 생존.

## 함정

모든 곳에 동기 gRPC/REST를 쓰면 강한 결합이 재현되고, 사용자의 즉각적 읽기에 비동기를 쓰면 불필요한 지연이 추가됩니다.

## 왜 중요한가

전송 방식 선택은 각 상호작용의 결합도와 성능 상한을 정하므로, 전역이 아니라 사용 사례별로 선택하는 것이 시스템을 빠르고 복원력 있게 유지합니다.

성숙한 시스템은 의도적으로 세 가지를 모두 혼합합니다. 내부 핫 경로에는 gRPC, 엣지에는 REST, 워크플로에는 큐를 사용합니다.

스타일	동기	동기	비동기
페이로드	JSON(텍스트)	Protobuf(바이너리)	임의(종종 바이너리)
성능	양호	높음	높은 처리량
계약	OpenAPI(느슨)	`.proto`(엄격)	스키마/이벤트
스트리밍	제한적	네이티브(양방향)	발행/구독
적합한 용도	공개 API, 브라우저	내부 핫 경로	분리, 이벤트