WebSocket & 실시간 통신

WebSocket & 실시간 통신이란?

실시간 통신은 사용자가 새로고침하지 않아도 서버의 변경 사항을 바로 클라이언트에 전달하는 방식이다.

일반적인 HTTP 통신은 클라이언트가 서버에 요청을 보내고, 서버가 그 요청에 응답하는 구조이다.

하지만 알림, 채팅, 주식 가격 변경, 주문 상태 변경 같은 기능은 서버에서 변경이 발생했을 떄 클라이언트가 바로 알아야 한다.

이런 기능을 구현하기 위해 Polling, SSE, Websocket 같은 방식이 사용된다.

 

왜 사용하는가?

일반 HTTP 방식만 사용하면 서버에 새로운 데이터가 생겨도 클라이언트가 다시 요청하기 전까지는 알 수 없다.

예를 들어 새 알림이 생겼더라도 사용자가 새로고침하지 않으면 화면에 바로 표시되지 않는다.

이 문제를 해결하기 위해 실시간 통신 방식을 사용한다.

실시간 통신을 사용하면 다음과 같은 기능을 만들 수 있다.

• 실시간 알림
• 실시간 채팅
• 주식 가격 실시간 변동
• 게임 친구 온라인 여부 확인

Polling

Polling은 클라이언트가 일정 시간마다 서버에 반복적으로 요청을 보내는 방식이다.

구현이 단순하고 기존 HTTP 방식만으로 만들 수 있다는 장점이 있다.

하지만 새로운 데이터가 없어도 계속 요청을 보내기 때문에 서버에 불필요한 부하가 생길 수 있다.

또한 요청 주기에 따라 실시간성이 떨어질 수 있다.

예를 들어 5초마다 요청한다면, 실제 이벤트가 발생해도 최대 5초 뒤에 알 수 있다.

따라서 Polling은 실시간성이 매우 중요하지 않고, 몇초 단위로 상태를 확인해도 되는 기능에 적합하다.

 

SSE

SSE는 Server-Sent Events의 약자이다.

클라이언트가 서버에 연결을 열어두면, 서버가 필요한 순간마다 클라이언트에게 이벤트를 보내는 방식이다.

SSE는 기본적으로 단방향 통신이다.

즉, 서버에서 클라이언트로 데이터를 보내는 데 집중된 방식이다.

예를 들어 알림 기능은 사용자가 서버로 계속 메시지를 보내는 구조가 아니라, 서버가 사용자에게 알려주는 구조이다.

이런 경우에는 SSE가 잘 맞는다.

SSE가 적합한 기능은 다음과 같다.

• 공지사항 전달
• 서버 상태 변경 알림
• 실시간 알림

SSE는 WebSocket보다 구조가 단순하고 HTTP 기반으로 동작하기 때문에 비교적 구현하기 쉽다.

다만 클라이언트가 서버로 실시간 메시지를 계속 보내야 하는 채팅 기능에는 적합하지 않다.

WebSocket

WebSocket은 클라이언트와 서버가 한 번 연결을 맺은 뒤, 그 연결을 계속 유지하면서 데이터를 주고 받는 방식이다.

 

WebSocket은 양방향 통신을 지원한다.

클라이언트도 서버에게 바로 메시지를 보낼 수도 있고, 서버도 클라이언트에게 바로 메시지를 보낼 수 있다.

그래서 채팅처럼 사용자가 메시지를 보내고, 다른 사용자가 바로 받아야 하는 기능에 적합하다.

WebSocket이 적합한 기능은 다음과 같다.

• 실시간 채팅
• 온라인 게임
• 실시간 온/오프라인 확인

WebSocket은 실시간성이 높고 양방향 통신이 가능하다는 장점이 있다.

하지만 연결을 계속 유지해야 하므로 서버 자원 관리가 중요하다.

또한 연결 끊김, 재연결, 인증 처리 같은 부분도 함께 고려해야 한다.

STOMP

STOMP는 Simple Text Oriented Messaging Protocol의 약자이다.

WebSocket을 사용할 때 메시지 구조를 더 체계적으로 관리하기 위해 STOMP를 함께 사용할 수 있다.

WebSocket은 클라이언트와 서버가 실시간으로 데이터를 주고받을 수 있는 연결을 제공한다.

하지만 WebSocket만 사용하면 메시지 타입, 수신 대상, 채팅방 구분 같은 구조를 직접 설계해야 한다.

예를 들어 채팅 기능을 만든다면 다음과 같은 정보를 직접 정해야 한다.

{
  "type": "CHAT",
  "roomId": 1,
  "senderId": 10,
  "message": "안녕하세요"
}

이 방식도 가능하지만 채팅방이 많아지거나 알림, 입장, 퇴장 같은 이벤트가 늘어나면 메시지 구조가 복잡해질 수 있다.

 

STOMP를 사용하면 메시지를 발행하고 구독하는 구조로 관리할 수 있다.

구독: /topic/chat/room/1
발행: /app/chat/message

즉 사용자는 특정 채팅방을 구독하고, 서버는 해당 채팅방을 구독한 사용자들에게 메시지를 전달할 수 있다.

 

STOMP의 기본 구조

STOMP는 보통 발행(Publish)와 구독(Subscribe) 구조로 동작한다.

1. 사용자가 특정 채팅방을 구독한다.
2. 사용자가 서버로 메시지를 보낸다.
3. 서버는 메시지를 처리한다.
4. 서버는 해당 채팅방을 구독중인 사용자들에게 메시지를 전달한다.

예를 들어 1번 채팅방을 기준으로 보면 다음과 같다.

1. 사용자 A → /app/chat/message 로 메시지 전송
2. 서버 → /topic/chat/room/1 구독자들에게 메시지 전달
3. 사용자 B, C → 메시지 수신

여기서 /app은 클라이언트가 서버로 메시지를 보낼 때 사용하는 경로이고, /topic은 여러 사용자들에게 메시지를 전달할 때 사용하는 경로로 볼 수 있다.

Publish와 Subscribe

STOMP를 이해할 때 중요한 개념은 Publish와 Subscribe이다

이 구조는 유튜브로 비유하면 이해하기 쉽다.

유튜브에서 크리에이터가 영상을 올리면, 그 채널을 구독한 사람들에게 영상이 전달된다.

• 크리에이터가 영상 업로드 = publish
• 사용자가 채널 구독 = subscribe
• 구독자에게 영상 전달 = 메시지 전달

STOMP에서도 이와 비슷한 구조로 메시지가 전달된다.

Publish

Publish는 메시지를 발행하는 것이다.

유튜브로 비유하면 크리에이터가 영상을 업로드하는 것과 비슷하다.

채팅에서는 사용자가 채팅 메시지를 서버로 보내는 행위가 Publish에 해당한다.

• 사용자 → 서버로 메시지 전송

예를 들어 사용자가 1번 채팅방에 메시지를 보내면, 서버는 그 메시지를 받아서 처리한다.

Subscribe

Subscribe는 특정 주제를 구독하는 것이다.

유튜브로 비유하면 사용자가 특정 채널을 구독하는것과 비슷하다.

채팅에서는 사용자가 특정 채팅방의 메시지를 받기 위해 해당 채팅방을 구독한다.

• 사용자 → 특정 채팅방 구독

서버는 메시지가 발생했을 때 해당 주제를 구독하고 있는 사용자들에게만 메시지를 전달한다.

예를 들어 1번 채팅방을 구독한 사용자들에게만 1번 채팅방 메시지가 전달된다.

유튜브와 STOMP 비유 정리

크리에이터가 영상 업로드	메시지 Publish
사용자가 채널 구독	Topic Subscribe
구독자에게 새 영상 알림	구독자에게 메시지 전달
유튜브 채널	Topic

 

Topic과 Queue

STOMP에서는 메시지를 전달하는 목적에 따라 Topic과 Queue를 나누어 생각할 수 있다.

Topic

Topic은 여러 사용자에게 같은 메시지를 전달할 때 사용한다.

유튜브에서 하나의 채널에 영상을 올렸을 때, 그 채널을 구독한 여러 사용자에게 영상이 전달되는것과 비슷하다.

예를 들어 1번 채팅방을 구독한 사용자가 있다고 가정해보자.

사용자 A → 1번 채팅방 구독
사용자 B → 1번 채팅방 구독
사용자 C → 1번 채팅방 구독

이 상태에서 누군가 1번 채팅방에 메시지를 보내면, 서버는 1번 채팅방을 구독한 사용자들에게 같은 메시지를 전달한다.

1번 채팅방 메시지 발생
→ 사용자 A, B, C에게 메시지 전달

즉 Topic은 하나의 메시지를 여러 구독자들에게 전달하는 구조이다.

Topic이 적합한 경우

Topic은 여러 사람이 같은 정보를 받아야 하는 기능에 적합하다.

예를 들어 다음과 같은 경우에 사용할 수 있다.

• 채팅방 메시지
• 전체 공지
• 실시간 방송 알림
• 그 외 여러 사용자가 함께 보는 실시간 데이터

채팅방을 예로 들면, 같은 채팅방에 있는 사람들은 모두 같은 메시지를 받아야 한다.

그래서 채팅방 메시지는 Topic 구조와 잘 맞는다.

 

Queue

Queue는 특정 사용자에게 메시지를 전달할 때 사용한다.

Topic이 여러 사용자에게 같은 메시지를 보내는 구조라면, Queue는 특정 사용자에게만 메시지를 보내는 구조에 가깝다.

예를 들어 개인 알림 또는 메시지를생각해 볼 수 있다.

사용자 A에게만 알림 전달
사용자 B에게는 전달하지 않음

이런 경우에는 Topic보다 Queue 구조가 더 적합하다.

Queue가 적합한 경우

Queue는 특정 사용자만 받아야 하는 메시지에 적합하다.

예를 들어 다음과 같은 기능에서 사용할 수 있다.

• 개인 알림
• 1:1 메시지
• 에러 메시지 전달

예를 들어 주문 상태 변경 알림이 들어왔다고 하면 모든 사용자에게 보낼 필요는 없다.

해당 주문을 한 사용자에게만 알림을 보내면 된다.

이런 경우에는 Queue를 사용할 수 있다.

 

Topic과 Queue 비교

목적	여러 사용자에게 전달	특정 사용자에게 전달
구조	1:N	1:1에 가까움
예시 경로	/topic/chat/room/1	/user/queue/notification
적합한 기능	채팅방, 공지, 방송	개인 알림, 1:1 메시지, 에러 응답

정리

실시간 통신 방식은 기능의 성격에 따라 선택해야 한다.

 

Polling은 클라이언트가 일정 시간마다 서버에 요청을 보내는 방식이다.구현은 단순하지만, 새로운 데이터가 없어도 계속 요청을 보내기 때문에 서버에 불필요한 부하가 생길 수 있다.

 

SSE는 서버가 클라이언트에게 이벤트를 보내는 단방향 실시간 통신 방식이다.
알림, 공지, 서버 상태 변경처럼 서버가 사용자에게 알려주기만 하면 되는 기능에 적합하다.

 

WebSocket은 클라이언트와 서버가 연결을 유지하면서 양방향으로 데이터를 주고받는 방식이다.
채팅, 온라인 게임, 실시간 상태 확인처럼 클라이언트와 서버가 서로 데이터를 주고받아야 하는 기능에 적합하다.

 

STOMP는 WebSocket 위에서 메시지를 더 체계적으로 주고받기 위해 사용할 수 있는 메시징 프로토콜이다.
Publish와 Subscribe 구조를 통해 채팅방, 공지, 개인 알림 같은 메시지를 구분해서 전달할 수 있다.

 

핵심은 다음과 같다.

• Polling = 일정 시간마다 계속 확인
• SSE = 서버가 클라이언트에게 전달
• WebSocket = 클라이언트와 서버가 서로 전달
• STOMP = 메시지를 발행/구독 구조로 관리

따라서 실시간 기능을 구현할 때는 무조건 WebSocket을 선택하기보다,
기능이 단방향인지 양방향인지, 여러 사용자에게 보내는지 특정 사용자에게 보내는지를 기준으로 적절한 방식을 선택해야 한다.