최종 프로젝트에 채팅구현이 메인 기능으로 들어가서 이를 구현하기 전에 핵심적으로 알아야할 개념들에 대해서 정리하려고 한다.
Polling (Short polling)
개념
- 클라이언트가 일정 간격으로 서버에 HTTP 요청을 보내 “새로운 데이터 있나요?” 라고 묻는 방식
- 구현이 단순(클라이언트 타이머 + GET 요청)하고 방화벽/프록시 등에서 특별한 설정이 필요 없음
장단점
- 구현이 단순함
- 일반적인 HTTP 인프라 그대로 사용함
- 응답이 없는 요청(서버에 새 데이터 없음)이 많아 네트워크/서버 비용이 큼
- 지연 시간도 poll 주기에 의존
Long Polling
개념
- 클라이언트가 요청을 보내면 서버는 즉시 응답하지 않고 새 데이터가 생길 때까지(또는 타임아웃까지) 연결을 열린 상태로 유지
- 새 데이터가 생기면 서버가 즉시 응답을 보내고, 클라이언트는 응답을 받고 곧바로(또는 약간의 딜레이 후) 다시 같은 요청을 보냄
- 전통적으로 HTTP 환경에서 “서버 → 클라이언트 푸시” 효과를 흉내내는 기법이라고 함
장단점
- 짧은 지연으로 실시간성 향상
- 불필요한 요청 수 감소(짧은 주기의 폴링보다 효율적)
- 서버는 다수의 열린 요청을 관리해야 하고(리소스/커넥션 수 관리 필요)
- 웹 서버/프록시의 타임아웃 정책에 따라 실패할 수 있음
- 대규모 연결에서는 복잡도/비용 증가
➡️Polling vs Long Polling
Polling
- 주기적으로 묻는다 → 많은 빈 응답(낭비)
- 지연시간은 폴링 간격과 동일
Long Polling
- 묻고 기다린다 → 서버에 업데이트 발생 시 즉시 응답
- 지연이 상대적으로 작다
- 사실상 푸시서버를 체감함
WebSocket
개념
- 브라우저와 서버 사이에 단일의 지속적인 TCP 연결을 열어, 양방향(풀-듀플렉스)으로 메시지를 주고받을 수 있게 해주는 표준(프로토콜 + API)
- 한 번 연결을 설정하면 HTTP 헤더 오버헤드 없이 자유롭게 메시지를 교환
특징
- 양방향(서버→클라이언트, 클라이언트→서버)
- 낮은 오버헤드
- 실시간 통신에 적합
- HTTP(S) 업그레이드 핸드셰이크(WebSocket 프로토콜로 업그레이드)로 시작하므로 기존 인프라와도 연동 가능
- 채팅, 실시간 게임, 가격 시세 푸시, 협업툴 등 지연(latency)이 매우 중요한 실시간 양방향 통신에 주로 사용
한계/운영 이슈
- 연결 수가 많아지면 서버(또는 프록시)에서 커넥션 관리/스케일링(로드밸런서, 커넥션 프록시, 클러스터링)이 중요
- 방화벽/프록시 구현마다 차이 때문에 테스트 필요
Publish / Subscribe (Pub/Sub) 패턴
개념
- 발행자(Publisher)는 메시지를 특정 주제(topic) 또는 채널에 발행하고, 구독자(Subscriber)는 관심 있는 주제의 메시지를 받음
- 발행자와 구독자는 서로 직접 알 필요가 없고, 중간에 메시지 브로커(메시지 라우팅·저장·전달 담당)가 들어감
- 채팅 구현에서는 sub = 채팅방, pub = 메시지 로 볼 수 있음
주요 속성
- 느슨한 결합(loose coupling): 시간적으로나 공간적으로 발행자와 구독자가 분리됨
- 브로드캐스트 성격: 같은 토픽에 여러 구독자가 있을 때 메시지를 여러 소비자에게 배포할 수 있음 (단체 채팅)
메시지 브로커 (Message Broker)
개념
- 시스템 간 메시지를 중개하고 라우팅, 큐잉, 영속성, 재시도, 라우팅 규칙(교환/exchange 등)을 제공하는 소프트웨어
- 예: RabbitMQ, ActiveMQ, Redis(일부 용도), Kafka(이벤트 스트리밍 플랫폼)
주요 역할
- 메시지 수신(Producer) → 라우팅(Exchange/Topic) → 큐(Queue) 또는 토픽에 저장 → 소비자(Consumer)에게 전달
간략한 특성 비교
-
RabbitMQ / 전통 브로커
- 큐 기반 메시지 브로커 모델
- 다양한 교환 타입(direct, topic, fanout)·풍부한 라우팅 옵션
- 신뢰성(ack/nack) 중심
-
Kafka
- 높은 처리량(throughput)·이벤트 스트리밍(로그 중심)
- 파티션을 통한 병렬 처리와 장기 저장(토픽에 로그처럼 append)
- 소비자는 오프셋을 관리해서 읽음
- 오픈소스 분산 이벤트 스트리밍 플랫폼이자 메시지 브로커
- 데이터를 디스크에 저장하기 때문에 데이터 유실이 적음(데이터 영속성)
- 핵심 개념: 토픽(topic) → 파티션(partition)(병렬성) → 오프셋(offset)(컨슈머가 읽은 위치를 관리)
-
Redis
- 데이터를 RAM(메모리)에 저장하는 인메모리 데이터 구조 서버로서 pub/sub을 지원
- 전통적인 데이터베이스보다 훨씬 빠른 읽기/쓰기 성능을 제공
- 메모리 용량에 따라 저장할 수 있는 데이터 양이 제한됨
- 따라서 메시지 내구성(영속성/재전송)과 복잡한 라우팅은 브로커 전용 제품보다 약함
STOMP (Simple (or Streaming) Text Oriented Messaging Protocol)
개념
- 텍스트 기반의 경량 메시징 프로토콜
- 메시지를 전송하는 간단한 프레임(연결, SEND, SUBSCRIBE, UNSUBSCRIBE, ACK 등)을 정의
- STOMP 자체는 “토픽/큐” 같은 구체적 브로커 구조를 규정하지 않고, destination(목적지 문자열)를 사용
- 메시지 브로커(RabbitMQ, Apollo 등)가 STOMP 프레임을 내부 구조(토픽·큐)로 매핑
- 한 마디로 Stomp 프로토콜은 WebSocket 위에서 동작하는 프로토콜로써 클라이언트와 서버가 전송할 메세지의 유형, 형식, 내용들을 정의하는 매커니즘
특징/사용 이유
- 구현이 쉽고 디버깅이 간단(텍스트 기반)
- 웹 클라이언트→브로커 통신에서 WebSocket 위에 STOMP를 얹어 사용하는 경우가 많음
🔹 오늘의 나는 무엇을 잘했는지 (성취)
stomp를 이용한 채팅 실습 구현을 해봤다.
구현을 하기 전에는 개념이 낯설고 막막했지만, 직접 공부하면서 조금씩 감을 잡으니 한결 친숙하게 느껴졌다.
🔹 어떤 문제를 겪었고, 어떻게 해결할지 (개선)
stomp, redis, kafka, 메시지 브로커 등 처음 듣는 용어들이 많아 기능의 동작 흐름을 이해하는 데 어려움이 있었다.
또한 중간중간 잊고 있던 CS 지식을 다시 복습하느라 시간이 오래 걸렸지만,
정리해야 할 개념들의 순서를 스스로 정하고 하나씩 채워나가며 문제를 해결해 나갔다.
🔹 오늘 배운 것 (학습)
채팅 기능을 구현하는 과정에서 stomp, 메시지 브로커, redis, kafka 등의 개념을 구체적으로 이해할 수 있었다.
아직 데이터베이스 연결까지는 하지 못했지만, 로컬 환경에서 채팅이 어떻게 동작하는지 전체적인 플로우를 파악할 수 있었다.
🔹 나만의 팁 or 복습 방법
아주 작은 단위부터 실습을 시작하는 것이 가장 효과적이었다.
처음에는 너무 쉬워 보이는 단위라도 직접 구현해보면 이해가 빠르고,
그 위에 하나씩 기능을 덧붙이면서 자연스럽게 구조를 확장할 수 있었다.
반대로 처음부터 완벽한 프로젝트를 만들려 하면 너무 방대해서 지치기 쉽다.
그래서 “작은 단위부터 차근히 쌓아가는 공부법”을 추천한다.
