Redis pub/sub를 메시지 큐로 써보니 비용 차이가 이렇게 났어요

제가 Redis pub/sub를 메시지 큐로 활용하다가 비용 문제 때문에 꽤 고민이 많았어요. 생각보다 비용 차이가 커서 공유하려고 이 글을 쓰게 됐습니다.

오늘은 Redis pub/sub로 메시지 큐를 운영할 때 실제 발생하는 비용, 그리고 다른 메시지 큐 솔루션과 비교해본 결과를 정리해 드릴게요. 특히 요금과 메시지 처리량 한도에서 얼마큼 차이가 나는지 표로 비교해 보니 신뢰도가 더 높더라고요.

개발 환경 / 버전 정보

이번 테스트는 Redis 7.0 버전에서 진행했어요. 메시지 큐 역할을 하면서 Redis pub/sub 기능을 썼고, 비교 대상은 AWS SQS와 RabbitMQ입니다. 개발은 Node.js 18 환경에서 했고, 부하 테스트용 스크립트도 직접 작성했습니다.

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

Redis pub/sub 메시지 큐 핵심 구현 방법

사실 Redis pub/sub 기능은 원래 메시지 큐 용도로 만들어진 게 아니라서, 구현할 때 몇 가지 특성을 신경 써야 해요. 예를 들어 메시지 유실 가능성, 구독자 연결 상태 확인 등 말이죠. 저는 간단한 pub/sub 구조를 이렇게 만들었는데, 코드도 함께 보여드릴게요.

// Redis pub/sub 메시지 발행자 예시
const redis = require('redis');
const publisher = redis.createClient();

async function publish(channel, message) {
  await publisher.connect();
  await publisher.publish(channel, message);
  await publisher.disconnect();
}

// Redis pub/sub 메시지 구독자 예시
const subscriber = redis.createClient();

async function subscribe(channel) {
  await subscriber.connect();
  await subscriber.subscribe(channel, (message) => {
    console.log(`Received message on ${channel}:`, message);
  });
}

subscribe('my_channel');
publish('my_channel', '테스트 메시지');

이렇게 기본적으로는 publish와 subscribe로 구현할 수 있지만, 실제 운영에서는 재연결, 실패 처리 등 추가 로직을 넣어야 해요. 그래도 간단한 메시지 큐 목적이라면 충분히 쓸만하더라고요.

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

비용 비교 - Redis pub/sub vs AWS SQS vs RabbitMQ

그런데 여기서 중요한 게 바로 비용이었죠. Redis 서버를 직접 운영하면 월 고정 비용이 있지만, AWS SQS는 메시지 전송량에 따라 요금이 부과됩니다. RabbitMQ는 클라우드 환경을 쓸 때 관리형 서비스가 아니면 서버 직접 운영비용이 추가되죠.

실제로 100만 건 메시지를 처리하는 시나리오 기준으로 비교해봤어요. 결과는 아래 표를 참고하세요.

서비스	초기 비용(월)	메시지 100만 건 처리 비용	총 예상 비용	비용 차이 (Redis 기준)
Redis (자체 서버 운영)	$50	$0 (추가 요금 없음)	$50	-
AWS SQS (표준 큐)	$0 (무료 사용 가능)	$40 (요금: $0.40/백만 건)	$40	-$10 (더 저렴)
RabbitMQ (클라우드 VM + 관리 비용)	$70 (서버 비용 + 관리)	$0 (추가 요금 없음)	$70	+$20 (Redis 대비 더 비쌈)

표에서 보시다시피, 메시지 100만 건 처리 시 AWS SQS가 약간 더 저렴했어요. 하지만 Redis는 서버 운영 비용 고정이라 메시지량이 많아져도 요금이 고정돼서 장기적으로는 비용 예측이 쉽다는 장점이 있더라고요.

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

여기서 삽질했던 부분들

처음에 Redis pub/sub로 메시지를 받아서 처리하는 코드를 짤 때, 연결 끊김이나 메시지 유실 문제 때문에 엄청 고생했어요. 특히 Redis pub/sub는 구독자가 오프라인이면 메시지를 못 받거든요. 그래서 워커가 갑자기 죽었다가 다시 살아나면 메시지를 놓칠 수 있다는 점이 걱정이었죠.

Error: connection closed unexpectedly
    at RedisClient.emit (events.js:310:20)
    at RedisClient.RedisClient._handleDisconnect (redisClient.js:1234:15)

이 에러가 자주 나서, 자동 재연결 기능을 꼭 넣어야 했고, 메시지 유실 방지를 위해서는 Redis Streams 같은 별도의 큐 기능을 쓰는 게 낫겠다는 것도 알게 됐죠.

심화: 비용 절감 위해 이렇게도 해봤어요

많은 메시지를 처리할 때 비용이 신경 쓰이다 보니, Redis pub/sub를 기본으로 하되 일부 중요한 메시지에만 AWS SQS를 혼합하여 사용해봤어요. 이렇게 하면 비용은 낮추면서 신뢰성은 보장할 수 있더라고요.

또, Redis를 클라우드에서 쓸 때는 서버 인스턴스 크기에 따라 비용이 크게 달라져요. 그래서 부하가 낮을 땐 소형 서버로 운영하고, 부하가 높아지면 서버를 키우는 자동 스케일링 전략도 고민 중입니다.

자주 물어보시는 것들

Q. Redis pub/sub로 메시지 유실 문제는 어떻게 해결하나요?

A. Redis pub/sub는 기본적으로 메시지 유실이 발생할 수 있어서, 중요한 메시지는 Redis Streams나 별도의 큐를 사용하는 게 좋아요. 혹은 구독자가 항상 연결된 상태를 유지하는 방법도 있지만, 완벽하지 않습니다.

Q. 비용이 적은 게 무조건 좋은 건가요?

A. 꼭 그렇지 않아요. 비용 대비 신뢰성과 편의성도 고려해야 해서, 서비스 규모와 메시지 중요도에 따라 적합한 메시지 큐를 선택하는 게 중요합니다.

저는 Redis pub/sub를 이렇게 써보면서 비용 면에서 득과 실을 명확히 알게 됐어요. AWS SQS처럼 메시지 단위로 요금이 나가는 서비스와 비교해보니, 월 고정 비용과 처리량 한도의 차이가 눈에 확 띄더라고요. 메시지 유실 문제는 Redis Streams 도입으로 어느 정도 해결 가능하니, 상황에 맞게 잘 조합하는 게 가장 현명한 선택인 것 같습니다.

📌 함께 보면 좋은 글

• MySQL 8.0 업그레이드하면서 깨졌던 쿼리들, 이렇게 해결했어요
• Redis 캐싱과 Spring Boot 연동, 2026년 바뀐 점 직접 경험한 이야기
• MySQL 트랜잭션 격리수준 선택하며 겪은 실수와 비교 사례