웹소켓 vs mq

웹소켓과 MQ는 모두 데이터를 전달하는 통로라는 공통점을 가지고 있습니다. 겉보기에는 둘 다 어떤 큐를 통해 메시지를 주고받는 것처럼 느껴질 수 있습니다. 하지만 실제로는 사용하는 목적도 다르고, 시스템 안에서 맡는 역할도 다릅니다. 보통 웹소켓은 실시간성, MQ는 비동기 처리라고 설명합니다. 물론 틀린 말은 아닙니다. 다만 이렇게 이분법적으로 나누면 두 기술의 차이를 충분히 설명하기에는 다소 부족하다고 느껴졌습니다. 웹소켓도 결국 비동기적으로 동작하고, MQ 역시 상황에 따라 실시간에 가깝게 활용될 수 있기 때문입니다. 따라서 이 글에서는 단순한 특징 비교에 그치지 않고, 웹소켓과 MQ에서 말하는 "큐"를 각각 어떻게 이해해야 하는지에 초점을 맞춰 정리해보겠습니다.

각각의 큐에는 어떤것을 전달 할까?

간단히 웹 소켓이 왜 만들어졌는지 생각해보자.

이것을 이해하기 위해서는 웹소켓이 왜 존재하는지부터 생각해야 합니다. 웹소켓은 기존 HTTP 위에서 동작하도록 만들어진 프로토콜입니다. 그렇다면, 왜 기존 방식을 유지하지 않고 새로운 방식을 만들었을까요?

HTTP는 요청을 전달하고 응답을 반환하면 연결이 종료되는 구조입니다. 이러한 구조에서는 실시간 데이터가 필요한 서비스에서 문제가 발생했습니다. 예를 들어, 채팅이나 실시간 알림과 같은 서비스에서는 데이터의 변화가 발생할 때마다 클라이언트가 지속적으로 요청을 보내야 했습니다. 이 과정에서 불필요한 요청이 반복적으로 발생했고, 요청과 응답 사이클로 인해 지연이 발생했습니다.

결국 다음과 같은 문제가 발생했습니다.

• 지속적인 요청으로 인한 불필요한 네트워크 비용이 발생했습니다.
• 요청-응답 구조로 인해 지연 시간이 증가했습니다.
• 서버와 클라이언트 모두에 부담이 증가했습니다.

이러한 문제를 해결하기 위해 "요청을 반복하지 않고 데이터를 지속적으로 받을 수 있는 방법"이 필요했습니다.
그 결과로 등장한 것이 웹소켓입니다. 웹소켓은 한 번 연결을 맺으면 이를 유지한 채, 서버와 클라이언트가 자유롭게 데이터를 주고받을 수 있도록 설계되었습니다. 즉, 요청과 응답이 반복되는 구조에서 벗어나 데이터가 지속적으로 흐를 수 있도록 만들기 위해 등장한 방식입니다.

웹소켓은 데이터가 지속적으로 흐를 수 있도록 하기 위해 등장한 기술입니다. 즉, MQ에서 말하는 큐의 개념과는 다릅니다.
큐는 말 그대로 대기열입니다. 어떤 작업이나 메시지를 잠시 쌓아두고, 이후에 처리하기 위해 존재합니다.
하지만 웹소켓에서의 통로는 이러한 대기열의 개념이 아닙니다. 데이터를 쌓아두기 위한 공간이 아니라, 흐르게 하기 위한 경로에 가깝습니다. 비유를 하자면 고속도로의 하이패스와 유사합니다. 일반적인 HTTP 요청은 톨게이트에서 매번 멈췄다가 지나가는 구조라면,
웹소켓은 하이패스를 통해 멈추지 않고 계속 흐르는 구조라고 볼 수 있습니다.

즉, 웹소켓은 데이터를 "쌓기 위한 구조"가 아니라 지속적으로 전달하기 위한 통로라고 이해하는 것이 더 적절합니다.

그렇다면 MQ는 어떨까?

MQ는 이름 그대로 메시지를 큐에 적재하여 전달하는 것이 핵심입니다.
간단히 설명하면 MQ는 producer와 consumer로 구성되며, producer에서 발생한 메시지를 consumer가 가져가서 처리하는 구조입니다.

즉, 메시지를 즉시 처리하는 것이 아니라, 큐에 적재해두고 나중에 처리하는 시스템이라고 볼 수 있습니다.

이러한 구조를 사용하는 이유는 요청과 처리를 분리하기 위함입니다.
요청을 받은 시점에서 모든 로직을 처리하지 않고, 메시지만 큐에 넣은 뒤 빠르게 응답을 반환할 수 있습니다.

그 결과로 다음과 같은 이점이 발생합니다.

• 요청 처리 시간이 단축되었습니다.
• 시스템 간 결합도가 낮아졌습니다.
• 트래픽이 몰리더라도 유연하게 대응할 수 있게 되었습니다.

또한 MQ는 메시지를 순서대로 저장할 수 있는 구조를 가지고 있습니다. 하지만 중요한 점은, 빠른 전송의 핵심이 순서 자체에 있는 것은 아니라는 점입니다. 실제로는 메시지를 큐에 적재한 이후, consumer가 이를 비동기적으로 처리하거나 병렬로 처리할 수 있기 때문에 전체적인 처리 효율이 증가하게 됩니다. 즉, MQ는 단순히 메시지를 전달하는 것이 아니라 처리 시점을 뒤로 미루고, 시스템을 분리하기 위한 구조라고 이해하는 것이 더 적절합니다.

누가 보아도 서로 다른 두 기술을 "통로"라는 공통점으로 묶어 비교해보았습니다. 비교를 진행해보니, 언제 웹소켓을 사용하고 MQ를 사용해야 하는지 조금 더 명확하게 보였다고 느꼈습니다. 경우에 따라서는 웹소켓과 MQ를 함께 사용하는 구조도 존재합니다. 이렇게 두 기술을 함께 사용하는 이유는, 웹소켓이 제공하는 통로에서 동시성이 높아질 수 있기 때문입니다. 이로 인해 동일한 자원에 대해 동시에 접근하는 상황이 발생할 수 있으며, 이는 race condition으로 이어질 수 있습니다. 결과적으로 데이터가 의도하지 않은 형태로 처리될 가능성도 존재합니다. 이를 해결하기 위한 방법은 여러 가지가 있지만, 그 중 하나로 MQ를 활용하여 메시지를 큐에 적재하고 순차적으로 처리하는 방식도 고려할 수 있습니다. 앞으로도 이처럼 서로 다른 기술을 비교하고, 그 내부 동작을 깊이 있게 이해한다면 보다 나은 설계를 할 수 있을 것이라 생각합니다.