문제 상황

서비스에 실시간 채팅 기능이 필요했습니다.

사용자 간 메시지를 거의 즉시 반영할 수 있어야 했고, 빠르게 프로토타이핑이 가능한 기술이 필요했습니다.
특히 초기 개발 단계였기 때문에, 인프라 구축에 많은 리소스를 들이기 어려운 상황이었습니다.

기술 선택 배경

Kafka, RabbitMQ 등 다양한 메시징 시스템을 고려했지만,

Kafka는 높은 내구성과 대규모 데이터 처리에 적합한 반면, 초기 세팅이 복잡하고 운영 리소스가 많이 들었고

RabbitMQ는 안정적이지만 실시간성에서는 Redis보다 느릴 수 있다고 판단했습니다.

이에 따라 속도와 단순성이 최우선이었던 상황에서 Redis Pub/Sub을 선택하게 되었습니다.

Redis Pub/Sub 선택 이유

1. 매우 낮은 지연 시간
   Redis는 인메모리 기반이기 때문에, 메시지 발행과 구독 간 지연이 거의 없습니다.

2. 간편한 설정과 빠른 개발
   별도의 브로커나 클러스터 구성 없이 Redis만으로 손쉽게 Pub/Sub 기능을 구현할 수 있습니다.

3. 실시간 알림에 최적화
   알림, 채팅 등 실시간 반응이 중요한 기능에 Redis Pub/Sub은 매우 잘 어울립니다.

문제 발생

Redis Pub/Sub은 Publisher가 채널로 메시지를 송신하고, Subscriber가 채널을 구독해 수신하는 구조입니다. 이러한 구조는 매우 빠르고 단순하지만, 실시간 채팅 시스템에 적용했을 때 다음과 같은 문제가 발생했습니다.

• 메시지 영속성 없음
  Redis Pub/Sub은 메시지를 메모리에만 저장하며, 별도의 보관 기능이 없습니다.
  이로 인해 사용자가 채팅방을 나갔다 다시 들어올 경우, 이전 메시지를 조회할 수 없습니다.

• 구독자 부재 시 메시지 유실
  만약 A 사용자가 B에게 메시지를 보냈을 때, B가 해당 채널을 구독 중이지 않았다면 메시지는 전달되지 않고 유실됩니다.

이러한 한계는 Redis Pub/Sub의 구조적인 특징에서 비롯된 것으로, 실제 운영 과정에서 해당 문제를 직접 경험하게 되었습니다.

해결방법

변경 프로세스

Redis Pub/Sub은 인메모리 기반 구조로 인해, 다음과 같은 문제가 있었습니다:

• 사용자가 채팅방을 나갔다가 다시 들어오면 기존 채팅 내역을 조회할 수 없음
• 상대방이 채널을 구독하지 않은 상태에서는 메시지가 전달되지 않고 유실됨

이를 해결하기 위해, 모든 채팅 메시지를 PostgreSQL에 저장하는 구조로 개선했습니다.

변경 방식

1. 메시지 수신 시 PostgreSQL에 저장
   • 채팅 메시지를 Redis Pub/Sub로 수신한 뒤, 백엔드에서 이를 즉시 PostgreSQL에 기록
2. 사용자가 채팅방 입장 시, 해당 방의 메시지를 DB에서 조회
   • 이를 통해 과거 대화 내역을 로딩 가능하게 함
3. 방 정보 또한 DB에 저장
   • 어떤 유저가 어떤 방에 참여하고 있었는지 관리 가능

개선 효과

• 사용자 간 실시간 채팅은 유지하면서도,
• 이전 대화 내역 확인 및 메시지 유실 문제를 해결

여기서 생길 수 있는 문제

처음에는 Pub/Sub만으로 충분할 것이라 생각했습니다. 하지만 실제 운영 중 다음과 같은 문제가 반복적으로 발생하며,
기존 구조의 한계를 절감하게 되었습니다.

• 메시지가 간헐적으로 순서가 어긋남
• 채널 미구독으로 인한 유실 발생

이 경험을 통해 단순한 Pub/Sub만으로는 서비스 품질을 보장할 수 없다는 것을 깨달았고,
이후 Redis List와 PostgreSQL 기반 구조로 확장하게 되었습니다.

이 구조의 장점

항목	변경 전 (Pub/Sub 단독)	변경 후 (List 병행 구조)
실시간 처리	✅ 빠름	✅ 유지됨
순서 보장	❌ 없음	✅ Redis List로 보장
메시지 유실	❌ 구독 안 하면 유실	✅ Redis List에 저장됨
영속 저장	🔶 PostgreSQL만 의존	✅ 병렬 저장으로 안정성 증가