Redis pub/sub 메시지 큐로 써본 후, 자주 묻는 질문 8가지

저는 최근에 Redis pub/sub 기능을 메시지 큐로 활용해보면서 꽤 삽질도 하고, 여러 가지를 테스트했어요. 이걸 구현하면서 생각보다 헷갈리는 부분이 많더라고요. 그래서 직접 겪은 경험과 실행 결과를 토대로 정리해봤습니다.

이 글에서는 Redis pub/sub를 메시지 큐로 쓸 때 자주 묻는 질문 위주로 답변하면서, 실제 쿼리 작성과 최적화 경험, 그리고 실행 결과를 함께 보여드릴게요.

개발 환경 / 버전 정보

우선 제가 테스트한 환경은 Redis 7.0.11 버전이고, 클라이언트로는 Node.js redis 모듈을 썼어요. 메시지 송수신 테스트는 간단하게 Pub/Sub 구조로 실험했고, 별도 패키지를 쓰지 않고 기본 제공 API로만 진행했습니다.

Redis pub/sub 메시지 큐로 써본 후기 관련 정보

Redis pub/sub를 메시지 큐로 쓸 때 주의할 점

사실 이 부분이 제일 중요해요. Redis pub/sub는 기본적으로 메시지를 영구 저장하지 않아서, 구독자가 없으면 메시지가 사라집니다. 그래서 진짜 메시지 큐처럼 사용하려면 이점이 굉장히 크더라고요.

그래서 일반적인 메시지 큐 시스템처럼 메시지 안정성을 보장하려면 Redis Streams 같은 별도 기능을 써야 하는데, 저는 단순 실시간 알림용도로만 pub/sub를 활용했어요.

Redis pub/sub 메시지 큐로 써본 후기 관련 정보

Q&A: Redis pub/sub 메시지 큐 활용법과 자주 묻는 질문

Q1. Redis pub/sub에서 메시지가 사라지는 이유는 뭔가요?

A. 기본 pub/sub는 메시지가 발행되면 구독자에게 바로 보내고, 구독자가 없으면 메시지를 저장하지 않아요. 그래서 구독자 없이 발행된 메시지는 모두 사라집니다. 이 때문에 pub/sub를 메시지 큐로 쓸 경우에는 메시지 유실 위험이 있습니다.

Q2. 메시지 유실을 막기 위해선 어떻게 해야 하나요?

A. Redis의 메시지 안정성이 필요하면 pub/sub 대신 Redis Streams를 권장합니다. 스탠다드 메시지 큐처럼 메시지를 영구 저장하며, 소비자가 읽은 메시지만 삭제하는 형태라 안전하거든요.

Q3. pub/sub를 단순 알림용도로 써도 괜찮을까요?

A. 네, pub/sub는 실시간 알림, 로그 스트림 전송, 채팅 같은 경우에 아주 적합합니다. 제가 해본 결과 메시지를 즉시 받아 처리하는 용도라면 성능도 빠르고 간단해요.

Q4. pub/sub 구독자가 많으면 성능 저하는 있나요?

A. 구독자가 많아도 Redis 내에서는 효율적으로 처리하지만, 네트워크 부하가 커질 수 있습니다. 실제로 저는 수십 개 구독자로 테스트했는데, 메시지 전송 지연이 체감될 정도는 아니었어요. 다만, 구독자 수가 수백 이상이면 별도 메시지 큐 시스템이 더 낫습니다.

Q5. Redis pub/sub에서 특정 메시지 만 필터링하는 방법 있나요?

A. pub/sub는 채널 단위로 구독을 하기에 메시지 내부 내용으로 필터링하는 건 클라이언트가 직접 해야 해요. 예를 들어, 한 채널에 다양한 메시지를 넣고 필터링하려면 구독 후 클라이언트 코드에서 조건을 검사해야 합니다.

Q6. Redis pub/sub로 보낸 메시지 크기에 제한이 있나요?

A. Redis 자체가 최대 512MB까지 키나 값 크기를 지원하지만, pub/sub 메시지는 너무 크면 네트워크와 Redis 처리에 부담이 커져요. 그래서 실무에서는 수백 KB 이하로 관리하는 게 안전하고, 저도 보통 10KB~100KB 내외로 메시지를 제한해서 사용했습니다.

Q7. 간단한 pub/sub 메시지 송수신 Node.js 코드 예시는?

// Redis 클라이언트 생성
const redis = require('redis');
const publisher = redis.createClient();
const subscriber = redis.createClient();

// 구독자 설정
subscriber.subscribe('news', () => {
  console.log('구독 시작!');
});

subscriber.on('message', (channel, message) => {
  console.log(`채널 ${channel}에서 메시지 수신: ${message}`);
});

// 발행자에서 메시지 발행
setTimeout(() => {
  publisher.publish('news', '안녕하세요, Redis pub/sub 테스트입니다!');
}, 1000);

이 코드는 가장 기본적인 발행/구독 구조예요. 구독자는 'news' 채널을 듣고 있고, 1초 뒤 발행자가 메시지를 보냅니다. 실행하면 곧바로 메시지를 받을 수 있습니다.

Redis pub/sub 메시지 큐로 써본 후기 관련 정보

여기서 삽질했던 부분들

제가 가장 헷갈렸던 건 pub/sub 메시지가 구독자가 없는 상태에서 다 사라지는 문제였어요. 알림이 안 오길래 한참을 확인했거든요. 심지어 구독자가 연결됐다 끊기면 그 사이 메시지 유실이 발생하는 것도 몰랐었고요.

그리고 Node.js Redis 클라이언트가 버전별로 구독자와 발행자 연결이 따로 필요하다는 점도 헷갈렸어요. 한 클라이언트에 subscribe와 publish를 섞으면 제대로 동작하지 않더라고요. 그래서 아래처럼 두 클라이언트를 따로 생성하는 게 필수였습니다.

// 잘못된 구조 예시
const client = redis.createClient();
client.subscribe('channel');
client.publish('channel', 'msg'); // 안 될 수 있음

// 올바른 구조
const subscriber = redis.createClient();
const publisher = redis.createClient();
subscriber.subscribe('channel');
publisher.publish('channel', 'msg');

이런 상황에서는 Redis Streams를 고려하세요

만약 메시지 유실을 절대 용납할 수 없는 상황이라면 Redis Streams가 훨씬 더 나아요. pub/sub는 메시지 전달 보장 기능이 없기 때문에, 시스템 장애 시 복구와 재처리가 힘들거든요.

Redis Streams는 대기열 같은 구조에서 소비자 그룹을 지원하고, 읽은 메시지만 삭제하는 구조라서 신뢰성이 훨씬 높습니다. 실제로 저도 복잡한 메시징 작업엔 Streams를 선호합니다.

자주 물어보시는 것들 마무리 Q&A

Q8. pub/sub를 멀티 인스턴스 환경에서 어떻게 활용하나요?

A. 여러 애플리케이션 인스턴스가 같은 Redis 서버를 구독하면 동일 채널 메시지를 모두 받습니다. 그래서 실시간 알림, 채팅 등 멀티 인스턴스 환경에도 적합해요. 다만, 개별 메시지 처리를 분산하려면 Streams의 소비자 그룹 기능을 써야 하니 상황에 맞게 선택하세요.

저는 이번 경험을 통해 Redis pub/sub가 정말 가볍고 빠른 실시간 메시징에는 최고지만, 메시지 안정성을 요구하는 비즈니스 메시지 큐 용도로는 한계가 뚜렷하다는 걸 알게 됐어요. 앞으로는 Redis Streams와 pub/sub를 목적에 맞게 섞어서 쓰는 게 효율적일 것 같습니다.

📌 함께 보면 좋은 글

• MySQL 8.0 업그레이드 후 깨진 쿼리들, 제가 겪은 실수들
• PostgreSQL vs MySQL 실무에서 선택할 때 이렇게 고민했어요
• MySQL 슬로우 쿼리 잡으면서 알게 된 원인들과 해결책들