Spring RSocket 마스터 — RSocket vs gRPC vs WebSocket

이 글은 Spring RSocket 마스터 노트 시리즈의 마지막 아홉 번째 편입니다. 1~8편이 RSocket 자체였다면, 이번엔 선택의 자리 — gRPC·WebSocket과의 결정적 차이.

비슷해 보이는 3 프로토콜. 하지만 백프레셔·Reactive·메시지 모델·생태계가 다릅니다. 어느 것을 어디에 쓸지가 핵심.

처음 비교가 어렵게 느껴지는 이유

처음 이 단원이 어렵게 느껴지는 이유는 두 가지예요. 첫째, 세 프로토콜 모두 양방향이라 비슷해 보입니다. 둘째, 선택 기준이 막연합니다. 무엇으로 결정?

해결법은 한 가지예요. "3 축으로 묶기" — 1) 백프레셔 지원, 2) 언어 비종속, 3) 메시지 모델. 이 3 축에서 각자 강점·약점이 명확. 이 표만 잡으면 선택이 쉬워집니다.

3 프로토콜 한 줄 정리

프로토콜	한 줄 정의
RSocket	Reactive Streams 위 양방향 메시징 (백프레셔 표준)
gRPC	HTTP/2 위 RPC + Protobuf (성능·생태계)
WebSocket	양방향 TCP·HTTP 부속 (브라우저 친화)

핵심 비교표

측면	RSocket	gRPC	WebSocket
백프레셔	O (표준)	부분 (HTTP/2 flow control)	X
Reactive Streams	표준	부분 (Reactive Stub)	X
언어 비종속	O	O (강력)	O
양방향	O	O (4 모드)	O
메시지 의미	4 Models	4 RPC 모드	없음 (raw bytes)
스키마	자유 (JSON·Protobuf 등)	Protobuf 강제	없음
브라우저	WebSocket transport	gRPC-Web (한정)	네이티브
공개 API	약함	강함 (Cloud Native)	약함
내부 마이크로서비스	강함	강함	약함
HTTP 인프라 호환	약함 (TCP)	O (HTTP/2)	O (HTTP)
학습 곡선	중간	중간	낮음

백프레셔 — RSocket의 결정적 차별화

RSocket

flux.flatMap(handler, 4)
// 자동으로 REQUEST_N(4) → 서버 4개씩만 보냄

표준. Reactive Streams spec 그대로.

gRPC

StreamObserver는 onNext / onCompleted / onError
백프레셔는 HTTP/2 flow control (수동 제어 어려움)

부분 지원. Reactive 흐름은 별도 어댑터.

WebSocket

ws.onmessage = (event) => {
  // 메시지 빠르게 도착, 처리 못 따라가도 모름
  process(event.data);
};

X. 클라이언트가 처리 못해도 서버가 계속 보냄.

여기서 정말 중요한 시험 함정 — 백프레셔가 결정적이면 RSocket. 무한 스트림·느린 처리·메모리 안전이 핵심이면 다른 선택지 없음.

4 Interaction Models 비교

RSocket

Request-Response / Fire-and-Forget / Request-Stream / Channel
명확한 4 모델, 메시지 의미 있음

gRPC

Unary RPC / Server Streaming / Client Streaming / Bidirectional Streaming
RSocket과 거의 동일 (1:1 매핑)

WebSocket

양방향 raw 메시지만 — 4 모델 같은 의미 X
사용자가 직접 구현해야

여기서 시험 함정이 하나 있어요. gRPC = RSocket 모델 거의 같음. 차이는 백프레셔·Reactive 친화·생태계.

성능 비교

TPS (작은 메시지 1KB)

프로토콜	TPS (1 client)
RSocket (TCP)	~150,000
gRPC (HTTP/2)	~120,000
WebSocket	~200,000 (메시지만)
HTTP/1.1	~10,000

지연 (단일 호출)

프로토콜	평균 지연
RSocket	~0.5ms
gRPC	~0.7ms
WebSocket	~0.3ms (raw)

여기서 시험 함정이 하나 있어요. 벤치마크는 시나리오 의존. 작은 메시지 = WebSocket이 가장 빠름. 메시지 의미·백프레셔 = RSocket. 강력한 스키마 = gRPC.

언어·생태계

gRPC — 가장 강력

공식 지원 — Java·Go·Python·C++·C#·Node·Rust·Ruby·...
도구 — Buf·grpcurl·BloomRPC
인프라 — Envoy·Istio·Linkerd 네이티브 지원

CNCF 표준 마이크로서비스 통신.

RSocket — 모던, 선별적

공식 — Java·JS·Go·Kotlin·.NET·Python (제한적)
도구 — RSocket CLI·rsc
인프라 — Spring Cloud Gateway 통합

Reactive 환경 특화.

WebSocket — 브라우저 표준

모든 언어·프레임워크 지원
브라우저 네이티브 (window.WebSocket)
인프라 — NGINX·CloudFlare 등 광범위 지원

브라우저 친화 1위.

스키마·직렬화

gRPC — Protobuf 강제

service UserService {
  rpc GetUser (UserRequest) returns (User);
}

message UserRequest { string id = 1; }
message User {
  string id = 1;
  string name = 2;
}

장점:

• 매우 컴팩트 (바이너리)
• 강력한 타입 안전
• 자동 코드 생성 (모든 언어)
• 스키마 진화 (필드 추가·삭제)

단점:

• Protobuf 의존 강제
• 디버깅 어려움 (바이너리)

RSocket — 자유

JSON·Protobuf·Avro·CBOR 다 OK. 인코더 등록.

WebSocket — 없음

Raw bytes. JSON·Protobuf 직접 처리.

시나리오별 선택

1. 공개 API (외부 노출)

→ gRPC (또는 HTTP)

이유 — 강력한 스키마·생태계·도구. RSocket은 외부 친화 X.

2. 내부 마이크로서비스 (HTTP 대체)

→ RSocket 또는 gRPC

Reactive 환경 (WebFlux) → RSocket
일반 (Spring MVC) → gRPC

3. 양방향 + 백프레셔

→ RSocket (다른 선택지 X)

4. 브라우저 ↔ 서버 양방향

→ WebSocket (네이티브 지원)

브라우저 → WebSocket → 게이트웨이 → RSocket (내부)

같이 쓰는 패턴.

5. IoT·모바일

→ RSocket (Resumability·백프레셔)

6. 단순 Pub/Sub

→ WebSocket (간단함)

함께 사용하는 패턴

패턴 1 — 외부 gRPC + 내부 RSocket

[External Client] → gRPC → [Gateway]
                          ↓ RSocket
                   [Internal Microservices]

장점 — 외부 표준·내부 Reactive.

패턴 2 — 브라우저 WebSocket + 내부 RSocket

[Browser] → WebSocket → [Frontend Server]
                       ↓ RSocket
                 [Backend Microservices]

브라우저 친화 + 내부 백프레셔.

패턴 3 — RSocket WebSocket Transport

[Browser] → RSocket over WebSocket → [Server]

브라우저에서 RSocket. WebSocket transport.

여기서 정말 중요한 시험 함정 — 하나만 선택할 필요 X. 시나리오별·계층별 다르게 사용. 마이크로서비스 = 보통 2~3 프로토콜 혼용.

gRPC에서 RSocket으로 마이그레이션

[Phase 1] gRPC stub → Reactive 어댑터 추가
[Phase 2] Reactive Stream 사용 시작
[Phase 3] 새 서비스는 RSocket
[Phase 4] 점진적 전환 또는 둘 유지

급할 필요 X. 둘 다 운영 가능.

RSocket의 단점

- 생태계 작음 (gRPC 대비)
- 도구 부족
- 학습 곡선 (Reactive)
- 외부 노출 친화 X
- Protobuf 같은 강력한 스키마 도구 X

여기서 시험 함정이 하나 있어요. RSocket이 만능 X. 단점도 명확. 적합한 자리에만.

RSocket 적합 / 부적합 정리

적합

✓ Reactive 환경 (Spring WebFlux)
✓ 양방향 + 백프레셔
✓ 마이크로서비스 사이 (내부)
✓ IoT·모바일 (Resumability)
✓ 실시간 스트리밍 + 백프레셔
✓ 채팅·협업

부적합

X 공개 REST API
X 단순 CRUD
X 강력한 외부 도구 필요
X 비-Reactive 환경
X 다양한 클라이언트 언어 (Protobuf 강력함 필요)

시리즈 마무리 — 9편 종합

1편부터 9편까지의 흐름:

편	주제	한 줄
1	기본·프레임	RSocket = Reactive 위 양방향 메시징
2	4 Interaction Models	RR·FNF·Stream·Channel
3	Spring 서버	@MessageMapping·라우팅·예외
4	Spring 클라이언트	RSocketRequester·연결 관리
5	메타데이터	Composite·MIME·라우팅·인증
6	보안	Spring Security RSocket·JWT·TLS·mTLS
7	로드 밸런싱	클라이언트 사이드 LB·Service Discovery
8	테스트	StepVerifier·Embedded Server
9	비교	gRPC·WebSocket 차이·선택 기준

RSocket의 거의 모든 운영 패턴을 한 번에 통찰할 토대.

시험 직전 한 번 더 — 자주 헷갈리는 함정 모음

여기까지가 9편의 핵심입니다. 시험 직전 또는 실무에서 헷갈릴 때 다시 펼쳐 볼 수 있게 압축 노트로 마무리할게요.

• 3 프로토콜 — RSocket (Reactive·양방향·백프레셔) / gRPC (HTTP/2·Protobuf) / WebSocket (브라우저·raw)
• 백프레셔 = RSocket의 결정적 차별화
• gRPC는 부분, WebSocket은 X
• 4 Interaction Models = RSocket 4개 ≈ gRPC 4 모드
• WebSocket은 모델 의미 X (raw)
• 공개 API = gRPC (생태계·도구)
• 내부 마이크로서비스 = RSocket (Reactive) 또는 gRPC
• 브라우저 양방향 = WebSocket (네이티브)
• IoT·모바일 = RSocket (Resumability)
• 백프레셔 결정적 = RSocket (다른 선택지 X)
• gRPC = Protobuf 강제 (강력한 스키마·자동 코드 생성)
• RSocket = 자유 (JSON·Protobuf·Avro)
• 함께 사용 패턴 — 외부 gRPC + 내부 RSocket / 브라우저 WebSocket + 내부 RSocket
• 한 환경에 여러 프로토콜 OK
• RSocket 단점 — 생태계 작음·도구 부족·학습 곡선
• RSocket 만능 X — 적합한 자리에만
• gRPC = CNCF 표준 마이크로서비스 통신
• 마이그레이션 = 점진적, 급할 필요 X

시리즈 다른 편 (시리즈 마지막)

• 1편 — 기본 개념·프레임
• 2편 — 4 Interaction Models
• 3편 — Spring RSocket 서버
• 4편 — Spring RSocket 클라이언트
• 5편 — 메타데이터·Composite Metadata
• 6편 — 보안·Spring Security RSocket·TLS
• 7편 — 로드 밸런싱·확장
• 8편 — 테스트
• 9편 — RSocket vs gRPC vs WebSocket (현재 글, 시리즈 마지막)

공식 문서: RSocket / gRPC / WebSocket 에서 더 깊이.

Spring RSocket 마스터 시리즈는 여기서 마무리. 1편부터 9편까지의 흐름이 머리에 남으면 마이크로서비스 통신의 거의 모든 선택지를 손에 잡고 시작할 토대가 됩니다.