기업 연계 프로젝트 - 채팅도메인 : 실시간 채팅

개요

여러 서비스를 보다보면 실시간성이 중요한 서비스들이 있습니다. 상대방과 함께 겨루는 게임이나, 주식이나 경매 등등 여러가지를 떠올릴 수 있는데요. 그중에 우리에게 친숙한 서비스로는 채팅 서비스가 있습니다. 한 대화 방에서 서로 서로 주고 받는 메세지를 바로바로 주고 받아야하는게 중요한 채팅도 실시간성이 중요하죠!

 

 

상품의 가격제안

 

저희 프로젝트에서는 양도 판매 상품에 대한 네고기능이 있었고, 이런 네고를 하기 위해 채팅 서비스 도입이 필요하다고 느꼈습니다.

가격 제안하기를 누르면 1대1 채팅방이 생기고 가격 네고를 할 수있는 채팅이 가능해지죠.

채팅 도메인에 대한 설계는 아래 블로그를 참고해 주시고, 오늘은 실시간 채팅을 어떻게 구현했는지에 대한 이야기를 해보겠습니다.

https://programmer-may.tistory.com/189 

야놀자 테크스쿨 파이널 프로젝트 - 채팅 도메인 설계(안 읽은 메시지 수, 채팅방 삭제, 채팅 메

 

HTTP 를 이용한 실시간 서비스

제가 개발한 실시간 채팅 서비스를 말씀드리기 앞서 실시간 기술들에 대해 공부했던 내용을 공유해드리겠습니다.

API 만드는 백엔드 개발자로서 실시간성을 흉내내는 HTTP 기술로 풀링을 많이 알고 있을 겁니다. 하지만 풀링 말고도 더 있죠!

HTTP 프로토콜을 활용한 실시간 기술은 풀링 말고도 롱풀링, 스트리밍, SSE 가 있습니다.

 

❇️ 단방향 통신

1️⃣ 풀링

풀링(Polling) 기술은 전통적인 AJAX 애플리케이션에서 사용되던 방식으로, 주기적으로 HTTP 요청을 서버에 날려서 데이터를 받아오는 방식입니다. 즉, 일정 간격마다 요청이 이뤄지며, 클라이언트는 새로운 데이터가 있든 없든 응답을 받고 일정 시간 기다렸다가 다음 요청을 날리고 응답받고, 또 기다렸다가 다음 요청을 날리고 응답받고 …와 같은 방식으로 동작합니다.

간단한 만큼 오버헤드도 큰데요. 만약 서버에서 데이터 업데이트가 이루어지지 않았다면 쓸데없는 요청이 계속 생기는 것이고 이는 불필요한 트래픽을 계속 만들어내는 것이라고도 할 수 있습니다.

• 단점: 서버에 받아야할 새로운 데이터가 없더라도 주기적인 요청이 발생하기 때문에 불필요한 네트워크 트래픽과 서버 부하를 초래할 수 있습니다.

 

일정 간격을 갖고 요청을 보내는 걸로 구현이 간단한 대신 이 일정간격에 대한 트레이드오프가 있습니다.

• 실시간성을 최대화하고자 요청을 보내는 간격을 줄이자니 요청 수가 많아져서 서버에 부담이 가게 됩니다. 특히 요청을 보낼 때 HTTP 헤더 또한 같이 전송되므로 클라이언트가 요청 간격을 줄이게 되면 그만큼 서버가 받는 부하가 커지게 됩니다.
• 반대로 서버 부담을 덜고자 간격을 늘리게 되면 실시간성이 떨어지는 문제가 있습니다.

 

2️⃣ 롱풀링

롱 폴링(Long-polling) 기술 또한 기본적으로 폴링 방식과 유사하게 HTTP 요청을 주기적으로 날려서 데이터를 받아오는 방식입니다. 하지만 폴링과 달리 롱 폴링의 경우 서버에 요청을 날렸을 때 응답해줄 데이터가 없다면 일정 시간 기다리다가 데이터가 생기면 그때서야 응답해주는 방식입니다 (혹은 타임아웃이 발생하면 빈 응답을 보낼 수도 있습니다). 그리고 응답을 받은 클라이언트는 일반적으로 곧장 다음 요청을 서버에 보냅니다. (물론 일정 시간 기다린 이후에 보낼 수도 있습니다)

 

• 지연된 응답: 서버는 데이터가 준비될 때까지 응답을 지연시킵니다.
• 즉시 재요청: 클라이언트는 응답을 받으면 즉시 새로운 요청을 보냅니다.
• 실시간성 향상: 폴링보다 실시간성 측면에서 더 효율적입니다.

 

 

롱 폴링의 경우, 폴링과 마찬가지로 어쨌든 HTTP 요청을 계속해서 날리는 것이므로 HTTP 헤더에 의한 오버헤드가 존재합니다. 데이터가 빈번하게 업데이트되는 상황에선 폴링방식과 별다른 차이가 없게 됩니다. 데이터 업데이트가 빈번한 경우 클라이언트는 요청 즉시 응답을 받게 되고, 바로 이어서 다시 요청을 보내 응답을 받게 되고, 또 바로 이어서 다시 요청을 보내 응답을 받고 … (무한 반복)와 같은 상황이 발생하기 때문입니다.

또한 다수의 클라이언트가 서버로 접속을 시도한다면 서버의 부담이 커지게 됩니다.

 

3️⃣ 스트리밍

HTTP 스트리밍(HTTP Streaming) 방식은 요청에 대한 응답을 완료하지 않은채(즉, 서버에서 요청을 계속해서 열어둔채로) 데이터를 계속해서 클라이언트로 푸시하는 방식입니다. 매번 응답을 할 때마다 곧 이어 다시 요청해야 하는 (롱)풀링 방식에 비해 효율적이며, 서버의 상태 변경이 잦은 경우에 유리한 방식입니다.

주로 서버에서 클라이언트로 대용량 데이터(예: 비디오, 오디오)를 순차적으로 전송하는 데 사용됩니다.

Streaming 방식을 사용하면 Long Polling과 다르게 응답 후 연결을 끊지 않아 HTTP 요청에 의한 재연결 과정이 없어 서버에 부담이 덜어집니다. 하지만 이때 서버가 일방적으로 클라이언트에게 Response를 전달할 뿐 클라이언트에서 서버로의 데이터 송신은 어렵다는 단점과 구현이 Polling, Long Polling보다 더 복잡하다는 단점이 있습니다.

• 단점: 서버가 일방적으로 클라이언트에게 Response를 전달할 뿐 클라이언트에서 서버로의 데이터 송신은 어렵다(단 방향통신)는 점. Polling, Long Polling보다 더 복잡하다는 점.

 

4️⃣ SSE

단방향 통신 기술인 SSE(Server Sent Events)는 처음부터 효율적으로 설계되었습니다. SSE 또한 HTTP를 기반으로 동작하는 기술이지만, 폴링·롱 폴링과는 달리, SSE는 서버가 원할 때 언제든 클라이언트로 데이터를 보낼 수 있습니다. 여기서 “서버가 원할 때”는 일반적으로 새로운 데이터가 생겼을 때, 즉 이벤트가 발생됐을때를 말합니다. 

서버가 클라이언트로 실시간 메시지나 업데이트를 전송하는 경우에 사용됩니다. 이 기술은 주로 텍스트 기반 데이터를 전송하는 데 최적화되어 있으며, 클라이언트가 서버에 지속적으로 새로운 데이터를 요청하지 않아도 서버로부터 자동으로 데이터를 받을 수 있습니다. 실시간 알림 서비스에 주로 사용됩니다.

 

• 자동 재연결: 연결이 끊어질 경우 자동으로 재연결을 시도합니다.( 클라이언트측에서 EventSource 객체 사용 )
• 텍스트 기반: 주로 텍스트 데이터를 전송합니다.
• 단점 : 클라이언트는 서버로부터 지속적으로 데이터를 받을 수 있지만, 클라이언트에서 서버로의 데이터 전송은 별도의 요청을 통해 이루어져야 합니다.(단방향 통신)

비교요약

방식	연결 지속성	데이터 전송 주체	실시간성
폴링	지속적이지 않음	클라이언트	낮음
롱 폴링	지속적이지 않음	클라이언트	중간
스트리밍	지속적임	서버	높음
SSE	지속적임	서버	높음

 

 

 

🪄 문제해결

이렇게 HTTP 를 이용한 실시간 기술은 단방향 통신에 각각의 단점이 있어, 실시간 채팅 기술로 쓰기에 애매했습니다.

 

풀링, 롱풀링 :  불필요한 지속적 요청이 있을 수 있기에 심한 트래픽과 오버헤드를 초래할 수 있습니다.

스트리밍, SSE : 연결을 맺고난 뒤엔 불필요한 데이터 전송 없이 실시간으로 서버한테서 데이터를 수신할 수 있지만, 단방향 통신이라 클라이언트에서 서버도 데이터 전송시엔 새로운 요청을 보내야합니다.

 

이러한 문제점을 해결하기 위해서 다른 방법을 찾아 보았고, 웹소켓 기술을 찾아, 공부하고 적용하게 됐습니다.

 

❇️ 양방향 통신

웹소켓

웹소켓은 진정한 의미의 양반향 통신이 가능합니다. 먼저 초기 핸드셰이크 과정에서 HTTP 프로토콜을 사용하지만 이후의 데이터 전송은 HTTP 프로토콜을 사용하지 않고 독립적인 양방향 통신 채널을 통해 이루어집니다.

 

1. 초기 핸드셰이크: 웹소켓 연결은 HTTP/HTTPS 요청을 통해 시작됩니다. 클라이언트는 서버에 HTTP 요청을 보내고, 이 요청은 Upgrade 헤더를 포함하여 웹소켓 프로토콜로의 업그레이드를 요청합니다.
2. 서버 응답 : 서버가 이 요청을 승인하면, HTTP 응답으로 업그레이드를 확인하고 웹소켓 연결을 수립합니다.
3. 데이터 전송 : 핸드셰이크가 완료되면, 웹소켓 연결이 열리고, 클라이언트와 서버는 독립적인 양방향 통신 채널을 통해 데이터를 주고받습니다. 이 단계부터는 HTTP 프로토콜이 아닌 웹소켓 프레임을 사용하여 통신합니다.
   이때 데이터는 텍스트와 바이너리만을 보낼 수 있고 해당 데이터 해독은 애플리케이션에 맡기게 됩니다.
4. 연결 종료 : 그 후 한쪽의 Close 신호를 통해 웹소켓 연결을 끊게 됩니다.

웹소켓의 특징

• 양방향 통신(전이중 통신): 웹소켓은 클라이언트와 서버가 실시간으로 데이터를 주고받을 수 있는 양방향 통신을 지원합니다. 이는 채팅, 실시간 게임, 실시간 업데이트 등이 필요한 애플리케이션에 매우 적합합니다.
• 지속적인 연결: 웹소켓 연결은 명시적으로 닫히기 전까지 열려 있으며, 클라이언트와 서버 간의 지속적인 데이터 스트림을 제공합니다.
• 낮은 오버헤드: HTTP 요청/응답 모델에 비해 웹소켓은 데이터 프레임의 오버헤드가 낮아, 더 효율적인 통신이 가능합니다.
• 초기 핸드셰이크: HTTP 프로토콜을 사용하여 연결을 수립합니다.
• 데이터 전송: HTTP가 아닌 웹소켓 프레임을 사용하여 데이터를 주고받습니다.

하지만 이런 웹소켓에도 단점은 있습니다. HTTP는 널리 사용하고, 규약이 정해져 있기 때문에 통신을 하게 되면 누구나 해석이 가능합니다. 하지만 웹소켓은 형식이 정해져 있지 않아 주고받는 주체 간에 따로 약속을 한 게 아니라면 애플리케이션에서 쉽게 해석하기가 어렵습니다. 또한 웹소켓은 문자열을 주고받을 뿐 그 이상의 일은 해주지 않습니다.

 

 

STOMP

웹소켓의 주고 받는 데이터의 형식을 알 수 없다라는 단점을 위해서 보조 프로토콜인 STOMP 가 있습니다. 

STOMP는 클라이언트와 서버가 서로 통신하는 데 있어 메시지 형식, 내용 등을 정의해 줍니다. 따라서 이를 사용하면 애플리케이션에서 웹소켓 메시지를 어떻게 해석해야 할지, 어떤 포맷으로 오는지 등에 대한 관리를 하지 않아도 되어 편리하죠. 메시징 패턴을 보다 쉽게 구현할 수 있도록 돕습니다.

 

STOMP의 주요 특징

1. 텍스트 기반 프로토콜: STOMP는 단순한 텍스트 기반 프로토콜로, 사람이 읽기 쉽게 설계되었습니다.
2. 메시징 패턴 지원: Pub/Sub(발행/구독) 패턴, 큐잉, 트랜잭션 등의 다양한 메시징 패턴을 쉽게 구현할 수 있습니다.
3. 멀티 프로토콜 지원: STOMP는 웹소켓 외에도 TCP, WebSocket, HTTP 등을 통해 사용할 수 있습니다.
4. 중앙 메시지 브로커 사용: RabbitMQ, ActiveMQ 같은 메시지 브로커와 쉽게 통합할 수 있습니다.

 

웹소켓과 STOMP의 결합

웹소켓과 STOMP를 결합하면, 웹소켓의 실시간 양방향 통신 기능을 활용하면서도 STOMP의 메시징 패턴을 쉽게 구현할 수 있습니다. 이는 특히 채팅 애플리케이션에 유용합니다.

 

• 웹소켓: 실시간 양방향 통신을 가능하게 합니다.
• STOMP: 메시지 구조와 패턴을 표준화하여 쉽게 구현할 수 있도록 돕습니다.

 

스프링에서 웹소켓과 STOMP 기술 활용

이처럼 각 기술의 장점과 단점을 생각하여, 최종적으로 웹소켓과 STOMP를 활용하여 채팅 서비스를 만들기로 하였습니다. 특히나 스프링 프레임워크에선 이를 쉽게 적용할수 있는 모듈을 제공해주는데요. WebSocketMessageBrokerConfigurer 구현하여 기술을 접목시킬 수 있습니다. WebSocketMessageBrokerConfigurer 은 스프링 내부적으로 메세지 브로커를 만들어 주고, 메시지 브로커 설정, 엔드포인트 구성, 메시지 매핑 등을 포함한 WebSocket 관련 설정을 커스터마이징할 수 있는 다양한 메서드를 제공합니다.

 

아래는 제가 커스텀한 웹소켓 컨피그입니다.

package kr.co.fastcampus.yanabada.common.config;

import kr.co.fastcampus.yanabada.common.handler.StompHandler;
import lombok.RequiredArgsConstructor;
import org.springframework.context.annotation.Configuration;
import org.springframework.messaging.simp.config.ChannelRegistration;
import org.springframework.messaging.simp.config.MessageBrokerRegistry;
import org.springframework.web.socket.config.annotation.EnableWebSocketMessageBroker;
import org.springframework.web.socket.config.annotation.StompEndpointRegistry;
import org.springframework.web.socket.config.annotation.WebSocketMessageBrokerConfigurer;

@Configuration
@RequiredArgsConstructor
@EnableWebSocketMessageBroker
public class WebSockConfig implements WebSocketMessageBrokerConfigurer {

    private final StompHandler stompHandler;

    @Override
    public void configureMessageBroker(MessageBrokerRegistry config) {
        config.enableSimpleBroker("/sub");
        config.setApplicationDestinationPrefixes("/pub");
    }

    @Override
    public void registerStompEndpoints(StompEndpointRegistry registry) {
        registry.addEndpoint("/ws-stomp").setAllowedOriginPatterns("*");
    }

    @Override
    public void configureClientInboundChannel(ChannelRegistration registration) {
        registration.interceptors(stompHandler);
    }
}

 

 

• enableSimpleBroker("/sub"): 메시지 브로커를 활성화하고, 클라이언트가 메시지를 구독할 수 있는 경로를 설정합니다. 여기서는 /sub 경로가 구독 경로로 설정됩니다.
• setApplicationDestinationPrefixes("/pub"): 클라이언트가 서버로 메시지를 보낼 때 사용하는 경로의 접두사를 설정합니다. 여기서는 /pub 경로가 설정됩니다.
• addEndpoint("/ws-stomp"): WebSocket 엔드포인트를 등록합니다. 클라이언트는 이 엔드포인트를 통해 WebSocket 연결을 시작합니다.
• setAllowedOriginPatterns("*"): CORS 설정을 통해 특정 도메인에서의 접근을 허용을 설정할 수 있습니다.  개발 및 테스트 환경에서 모두를 허용하는 것이 유용하지만, 프로덕션 환경에서는 보안상의 이유로 특정 도메인만 허용하는 것이 좋습니다.

 

다음은 제가 만든 채팅 도메인 컨트롤러 일부입니다.

@RestController
@RequestMapping("/v1/chats")
@RequiredArgsConstructor
public class ChatController {

    @Value("${chatroom.topic.prefix}")
    private String chatroomTopicPrefix;

    private final ChatService chatService;

    private final SimpMessagingTemplate messagingTemplate;

    @MessageMapping("/message")
    public void message(ReceivedChatMessage message) {
        messagingTemplate.convertAndSend(
            chatroomTopicPrefix + message.chatRoomCode(),
            chatService.saveChatMessage(message)
        );
    }
}

 

 

• @MessageMapping("/message"): STOMP 프로토콜을 통해 클라이언트에서 /{설정 경로}/message 경로로 전송된 메시지를 처리합니다. 여기서  /{설정 경로} 은 WebSockConfig에서 설정된 setApplicationDestinationPrefixes 값에 따라 자동으로 추가됩니다.(저 같은 경우 /pub 이 추가됩니다.)
• messagingTemplate.convertAndSend(...): SimpMessagingTemplate을 사용하여 받은 메시지를 특정 주제로 다시 전송합니다. (구독 주체에게 전송)

➡️ 메세지 발행 (※ 주의 판매자 -> 구매자 메세지 송신이 아닌, 클라이언트 -> 서버 입니다.)

채팅 메세지 발행과 구독 경로에 대해선 채팅 도메인 프론트엔드 개발자 분과 협의하여 결정하였습니다.

따라서 클라이언트에서 메시지를 발행할 때는

wss://{서버 엔드포인트}/ws-stomp

로 웹소켓 연결을 맺은 후,

/pub/message

경로로 메시지를 보내면 메세지를 발행할 수 있게 됩니다.

 

⬅️ 메세지 구독 (※ 주의 판매자 -> 구매자 메세지 수신이 아닌, 서버-> 클라이언트 입니다.)

환경변수에 /sub/chatroom 을 명시해 놨기 때문에 chatroomTopicPrefix 로 받고, 전송된 채팅방 룸 코드를 이용하여,

/sub/chatroom/{chatRoomCode}

경로로 채팅방에 내가 보낸 그리고 상대방이 보낸 메세지를 실시간으로 구독하여 받을 수 있습니다.

물론 이 경우도 웹소켓 연결이 선행 되어야 합니다!

이렇게 하면 {chatRoomCode} 를 가진 채팅 방에서 내가 보낸 그리고 상대방이 보낸 메세지를 실시간으로 발행 및 구독을 통해 확인할 수 있습니다.

 

✨ 결과물

 

✍️ 정리

1. 요구사항 정의서를 통해서, 실시간 채팅의 필요성을 느꼈습니다.
2. 스프링 MVC는 기본적으로 HTTP 기반으로 돌아가기 때문에 HTTP 활용한 실시간 기술을 탐색해 보았습니다.
3. 하지만 각각의 기술들은 실시간 채팅 서비스의 기술로 쓰기에는 치명적인 단점들이 있었습니다.
4. 다른 기술을 찾으며 웹소켓 과 STOMP를 알게 되었고, Spring에서도 이 기술을 지원해준다는 걸 알게 됐습니다.
5. 웹소켓 + STOMP 를 통해 진정한 양방향 통신과 메시지 구조와 패턴을 표준화하여 실시간 채팅 서비스를 개발할 수 있었습니다.

🧑‍💻 마무리하며

채팅 도메인을 담당하게 되면서 실시간 채팅 서비스를 만들며, 정말 많은 네트워크 지식을 배워가게 되는 계기가 됐습니다. 각각에 유형에 맞는 프로토콜이 존재하며 그에 따른 장단점이 있기에 그것을 잘 고려하여 활용해야, 사용자 뿐 아니라 서버까지 생각하는 개발자가 될 수 있다는 걸 몸소 깨달았습니다.

HTTP 프로토콜과 HTTP 를 활용한 실시간 기술, 웹소켓, STOMP를 공부하며 막연하게 기술을 도입하는 것이 아닌, 이 기술을 왜 써야하는지, 어떤 이점이 있는지 잘 설명할 수 있는 개발자가 된 것 같아 매우 뿌듯하고 기뻤습니다.