Redis를 단순히 ‘캐시’로만 쓰고 계신가요? 사실 Redis는 백엔드 엔지니어의 도구 상자에서 가장 다재다능한 ‘메시지 브로커’ 이기도 합니다. 별도의 무거운 MQ(Message Queue)를 설치하기엔 부담스럽고, 속도는 포기할 수 없을 때 Redis는 최고의 선택지가 됩니다.

Go 언어를 이용해 Redis의 두 가지 핵심 메시징 패턴인 Pub-SubWorker Queue를 구현하는 방법을 정리해 보았습니다.


1. 왜 Redis 메시지 큐인가?#

RabbitMQ나 Kafka는 훌륭하지만, 운영 오버헤드가 큽니다. 반면 Redis는 이미 많은 프로젝트에서 캐시용으로 사용 중이며, 다음과 같은 장점이 있습니다.

  • 극도의 단순함: 인프라 추가 없이 기존 Redis를 활용 가능합니다.
  • 성능: 메모리 기반으로 동작하여 수십만 TPS를 거뜬히 처리합니다.
  • 유연성: 실시간 알림(Pub-Sub)과 비동기 작업(Worker Queue)을 모두 지원합니다.

2. 실시간 브로드캐스트: Pub-Sub#

Pub-Sub 패턴은 “발행자가 메시지를 던지면, 현재 듣고 있는 모든 구독자가 받는” 방식입니다. 실시간 채팅이나 공지사항 전파에 적합합니다.

Go 구현 코드 (go-redis/v9)#

// Pub-Sub: 1:N 메시지 전송
func handlePubSub(ctx context.Context, rdb *redis.Client) {
    channel := "notifications"

    // 구독자(Subscriber)
    go func() {
        pubsub := rdb.Subscribe(ctx, channel)
        defer pubsub.Close()

        for {
            msg, _ := pubsub.ReceiveMessage(ctx)
            fmt.Printf("[Sub] 새 알림 수신: %s\n", msg.Payload)
        }
    }()

    // 발행자(Publisher)
    time.Sleep(time.Second) 
    rdb.Publish(ctx, channel, "서버 점검이 10분 뒤 시작됩니다.")
}

주의: Pub-Sub은 메시지를 보관하지 않습니다. 메시지가 발행될 때 구독 중이지 않았던 사용자는 그 메시지를 영영 받을 수 없습니다.


3. 확실한 작업 처리: Worker Queue (List)#

Worker Queue는 “작업을 큐에 쌓아두면, 여러 워커 중 하나가 가져가서 처리하는” 방식입니다. 이메일 발송, 이미지 리사이징 등 비동기 작업에 필수적입니다.

Go 구현 코드 (go-redis/v9)#

// Worker Queue: 1:1 작업 처리
func handleWorkerQueue(ctx context.Context, rdb *redis.Client) {
    queue := "task_limit"

    // 워커(Worker)
    go func() {
        for {
            // BRPOP: 데이터가 들어올 때까지 블로킹 대기 (효율적 리소스 사용)
            result, _ := rdb.BRPop(ctx, 0, queue).Result()
            fmt.Printf("[Worker] 작업 처리 중: %s\n", result[1])
        }
    }()

    // 프로듀서(Producer)
    rdb.LPush(ctx, queue, "Email_Task_#1024")
    rdb.LPush(ctx, queue, "Image_Process_#2048")
}

4. 어떤 것을 선택해야 할까?#

특성 Pub-Sub Worker Queue (List)
전달 방식 1:N (Broadcast) 1:1 (Competing Consumers)
데이터 보존 없음 (휘발성) 처리 전까지 Redis에 보존
적합한 사례 채팅, 실시간 대시보드 비동기 백그라운드 작업
주요 명령어 PUBLISH, SUBSCRIBE LPUSH, BRPOP

5. 마치며#

Redis를 MQ로 사용하는 것은 “비용 대비 효율” 측면에서 매우 뛰어난 전략입니다. 다만, 데이터 손실이 절대 용납되지 않는 아주 중요한 금융 거래나 거대 스트리밍 데이터라면 Redis Streams나 NATS, Redpanda 같은 전문 솔루션을 검토해 보시는 것이 좋습니다.

하지만 일반적인 웹 서비스의 백그라운드 처리라면? Redis 하나면 충분합니다.


더 읽어볼 거리: