WebSocket/STOMP 선택 이유

HTTP Polling 대신 WebSocket/STOMP를 고른 이유 — ValueHub 실시간 채팅 설계

고가 중고·프리미엄 거래 플랫폼 ValueHub에서 1:1 거래 채팅을 설계하면서, “메시지를 얼마나 자주 가져올 것인가”가 아니라 “연결을 어떻게 유지하고 누구에게 분기할 것인가”를 먼저 정했습니다. 이 글은 Chat-Service가 HTTP Polling을 버리고 WebSocket 위에 STOMP를 올린 이유와, Spring Cloud Gateway · X-Member-Uuid · MongoDB last_message가 한 흐름으로 맞물리는 구조를 정리합니다.

1. 개요 및 배경 (Context & Problem)

• 헤더 오버헤드. 매 폴링마다 TLS 핸드셰이크는 재사용하더라도 HTTP 헤더·쿠키·JWT 검증이 반복됩니다. 대화가 빨라질수록 “빈 응답” 비율이 올라가 실질 페이로드 대비 헤더 비용이 커집니다.

• 서버 부하의 증폭. 활성 방 N개 × 참여자 2명 × 폴링 주기의 역수가 초당 요청 수가 됩니다. 메시지가 없어도 Chat-Service와 Gateway는 살아 있는 대화만큼 일을 합니다.

• 지연의 하한. 폴링 주기를 줄이면 실시간처럼 보이지만 부하가 선형으로 늘고, 늘리면 “보냈는데 상대 화면에 안 뜨는” 거래 신뢰 문제가 됩니다. 고가 직거래에서 이 지연은 UX가 아니라 거래 리스크입니다.

• 목록과 방의 이중 폴링. 방 안 메시지와 /chat 목록 미리보기를 각각 폴링하면 같은 사용자가 연결을 두 벌 유지합니다. 미읽음·last_message 동기화가 어긋나기 쉽습니다.

• 인증 경계의 모호함. REST는 Spring Cloud Gateway가 JWT를 검증한 뒤 X-Member-Uuid를 내려줍니다. 폴링도 REST라서 당장은 편하지만, 나중에 양방향이 필요해지는 순간 인증 모델을 다시 짜야 합니다. 즉 Polling은 “구현이 쉽다”는 이점 외에, 고빈도 1:1 대화와 목록 실시간 패치를 동시에 만족시키기 어려운 구조였습니다.

2. 왜 이 기술을 선택했는가? (Why This Technology?)

• 실시간 양방향 통신: HTTP Polling 대비 헤더 오버헤드를 연결 한 번에 상각한다.

• 서버 부하 감소: 메시지가 있을 때만 프레임이 오가므로, 침묵 구간의 고정 비용이 사라진다. 다만 WebSocket만으로는 부족했습니다. 브라우저가 보내는 것은 “이 방의 텍스트”이고, 서버가 뿌려야 하는 것은 (1) 같은 방 구독자의 말풍선, (2) 상대의 채팅 목록 한 줄, (3) 권한 오류입니다. 이 세 갈래를 소켓 프레임 타입으로 직접 나누면 컨트롤러마다 if (type == LIST_PATCH)가 생깁니다. STOMP를 고른 이유도 라우팅이었습니다.

• Pub/Sub 기반 메시지 분기 로직을 애플리케이션에서 걷어내고, destination으로 옮긴다.

• 메시지 규격화와 Spring 브로커 연동이 쉽다. @MessageMapping("/chat.{roomId}") + @SendTo("/topic/chat.{roomId}")면 방 방송이 끝난다.

• 개인 큐(/user/queue/chat-list, /user/queue/errors)로 목록 패치와 예외를 방 토픽과 분리한다. 의사결정 기준을 한 줄로 줄이면 이렇습니다.

연결 비용(WebSocket)과 분기 비용(STOMP)을 나누고, 인증은 Gateway의 X-Member-Uuid 한 줄에 맞춘다. SSE는 “받기만 하면 되는 알림”에는 맞지만, 보내기를 REST에 남겨 두면 전송 경로와 수신 경로의 인증·에러 모델이 갈라집니다. 순수 WebSocket은 가능했지만, 팀 규모와 Spring 생태계를 생각하면 STOMP가 생산성 대비 위험이 작았습니다. Redis Pub/Sub + 다중 인스턴스 브로커는 트래픽이 인스턴스 경계를 넘을 때 검토하기로 미뤘습니다. 1차 목표는 프로토콜 선택이었습니다.

3. 핵심 아키텍처 및 구현 흐름 (Implementation Flow)

저장소 역할 분담

메시지 전송 6단계

[1] Next.js
      │  동일 출처 프록시 /api/chat/ws-chat
      │  (쿠키 → Authorization: Bearer)
      ▼
[2] Spring Cloud Gateway
      │  JWT 검증, Redis 블랙리스트
      │  X-Member-Uuid 주입, /ws-chat 업그레이드
      ▼
[3] Chat-Service STOMP CONNECT
      │  StompAuthChannelInterceptor
      │  X-Member-Uuid → Principal
      ▼
[4] SEND /app/chat.{roomId}
      │  TEXT | IMAGE | LOCATION
      │  RESERVATION 타입은 거절
      ▼
[5] MongoDB
      │  messages INSERT
      │  rooms.last_message 갱신
      │  참여자 lastRead / unread 계산
      ▼
[6] Broker fan-out
      ├─ /topic/chat.{roomId}        → 방 안 말풍선
      └─ /user/queue/chat-list       → 목록 last_message · unreadCount

1. 핸드셰이크. 브라우저는 WebSocket 헤더에 쿠키를 안정적으로 못 붙입니다. FO가 동일 출처 /api/chat/ws-chat으로 업그레이드하고, 서버가 vh_access_token을 Bearer로 바꿉니다. Gateway 뒤의 실제 엔드포인트는 /ws-chat입니다.

2. CONNECT 인증. StompAuthChannelInterceptor가 STOMP 헤더 또는 핸드셰이크 세션의 X-Member-Uuid를 Principal로 고정합니다. 이후 SEND의 발신자는 바디가 아니라 Principal입니다. 클라이언트가 senderUuid를 위조할 수 없습니다.

3. 구독. 방 상세는 /topic/chat.{roomId}, 목록은 /user/queue/chat-list, 실패는 /user/queue/errors입니다.

4. 전송. @MessageMapping("/chat.{roomId}")이 본문을 받아 SendChatMessageUseCase를 호출합니다. 참여자가 아니면 403에 해당하는 도메인 예외를 개인 에러 큐로 돌립니다.

5. 영속화와 last_message. 메시지 Document를 넣은 뒤 같은 방 Document의 last_message를 갱신합니다. 목록 REST가 메시지 컬렉션을 매번 집계하지 않도록, 미리보기는 방 문서에 둡니다. 이미지·위치는 목록용 문구로 정규화합니다. (사진이 공유 되었습니다., 위치를 공유했습니다.)

6. 방송. @SendTo("/topic/chat.{roomId}")로 방 구독자에게 echo하고, PublishChatListPreviewPort가 참여자별 /user/queue/chat-list에 한 줄 패치를 보냅니다. 보고 있는 상대는 unread를 0으로 맞춥니다. 핵심 컨트롤러는 이 형태입니다.

@MessageMapping("/chat.{roomId}")
@SendTo("/topic/chat.{roomId}")
public ChatMessagePayloadVo send(
    @DestinationVariable String roomId,
    SendChatMessageRequestVo requestVo,
    Principal principal
) {
    ChatMessageItemDto saved =
        sendChatMessageUseCase.send(toCommand(roomId, requestVo, principal));
    return toPayload(roomId, saved);
}

ChatMessage saved = saveChatMessagePort.save(toNewMessage(room.getId(), senderUuid, command));
LastMessage lastMessage = LastMessage.create(preview(saved), saved.getCreatedAt());
updateChatRoomLastMessagePort.updateLastMessage(room.getId(), lastMessage);
publishListPreviews(room, senderUuid, lastMessage);

방 생성은 Kafka 없이 REST입니다. 요청 바디의 상품 정보로 chat_product_posts 스냅샷을 INSERT하고, 방 Document에는 productPostUuid만 둡니다. 거래 상태 동기화는 예약 이벤트 글에서 다룹니다.

4. 트러블슈팅 및 고려했던 점 (Troubleshooting & Deep Dive)

4.1 브라우저 WebSocket은 Gateway JWT를 들고 가지 못한다

4.2 last_message를 메시지 컬렉션에서 그때그때 집계하지 않는다

4.3 클라이언트가 RESERVATION 타입을 직접 보내면 거절한다

4.4 Presence와 미읽음

4.5 단순 브로커의 한계를 알고 넘어갔다

현재는 Spring Simple Broker입니다. 인스턴스가 둘이면 /topic 구독이 프로세스 메모리에 갇힙니다. 지금은 단일 Chat 인스턴스와 Gateway 뒤에서 충분했고, 수평 확장은 Redis 브로커 또는 외부 메시지 브로커로 미뤘습니다. “지금은 필요 없는 인프라를 먼저 올리지 않는다”가 기준이었습니다.

5. 마치며 (Summary)

• HTTP Polling의 고정 부하와 지연 하한을 버리고, 연결 한 번으로 고빈도 1:1 대화를 처리했습니다.

• STOMP destination으로 방 방송·목록 패치·에러 큐를 나눠, 소켓 분기 로직이 유스케이스를 침범하지 않게 했습니다.

• Spring Cloud Gateway의 X-Member-Uuid와 MongoDB last_message를 전송 경로의 인증·미리보기 기준으로 고정해, 실시간성과 목록 일관성을 같은 흐름에서 맞췄습니다.