세 가지 주요 선택지는 REST(HTTP/JSON), gRPC(HTTP/2 + Protobuf), 그리고 메시지 큐(Kafka/RabbitMQ)입니다. REST와 gRPC는 동기이고, 큐는 비동기입니다.
세 가지 주요 선택지는 REST(HTTP/JSON), gRPC(HTTP/2 + Protobuf), 그리고 메시지 큐(Kafka/RabbitMQ)입니다. REST와 gRPC는 동기이고, 큐는 비동기입니다.
| 측면 | REST | gRPC | 메시지 큐 |
|---|
| 스타일 | 동기 | 동기 | 비동기 |
| 페이로드 | JSON(텍스트) | Protobuf(바이너리) | 임의(종종 바이너리) |
| 성능 | 양호 | 높음 | 높은 처리량 |
| 계약 | OpenAPI(느슨) | .proto(엄격) | 스키마/이벤트 |
| 스트리밍 | 제한적 | 네이티브(양방향) | 발행/구독 |
| 적합한 용도 | 공개 API, 브라우저 | 내부 핫 경로 | 분리, 이벤트 |
service OrderService {
// 강타입 RPC, 클라이언트 + 서버 스텁 자동 생성
rpc GetOrder (OrderId) returns (Order);
}
message OrderId { string id = 1; }
message Order { string id = 1; double total = 2; }
Order Service ─발행→ [ "OrderPlaced" topic ] ─▶ Inventory
└────▶ Notifications
(생산자는 소비자를 알지도 기다리지도 않음)
모든 곳에 동기 gRPC/REST를 쓰면 강한 결합이 재현되고, 사용자의 즉각적 읽기에 비동기를 쓰면 불필요한 지연이 추가됩니다.
전송 방식 선택은 각 상호작용의 결합도와 성능 상한을 정하므로, 전역이 아니라 사용 사례별로 선택하는 것이 시스템을 빠르고 복원력 있게 유지합니다.
성숙한 시스템은 의도적으로 세 가지를 모두 혼합합니다. 내부 핫 경로에는 gRPC, 엣지에는 REST, 워크플로에는 큐를 사용합니다.