무한 리밸런싱의 늪! 카프카(Kafka) 컨슈머 에러 원인과 DLQ 구축 가이드

안녕하세요, 여러분의 든든한 IT 길잡이 데브프리입니다.

 

2026년 현재, 카프카(Apache Kafka)는 주키퍼(ZooKeeper)를 완전히 걷어내고 순수 KRaft 모드로 구동되는 4.3 버전까지 진화했습니다. 백엔드 개발자들의 영원한 단짝인 Spring Kafka 역시 4.1 버전으로 올라오며 Spring Framework 7과 완벽하게 통합되었고, 새로운 큐잉 방식인 'Share Consumer(KIP-932)'까지 도입되며 눈부신 발전을 이뤘죠.

 

하지만 프레임워크가 아무리 발전해도, 실무에서 카프카를 다루는 백엔드 개발자들이 100% 확률로 겪게 되는 공포스러운 에러가 하나 있습니다. 바로 '컨슈머 무한 리밸런싱(Rebalance Storm)'과 '메시지 중복 처리' 문제입니다.

 

오늘은 실무에서 트래픽이 몰릴 때 어김없이 터지는 CommitFailedException의 원인을 아주 객관적으로 분석하고, 이를 근본적으로 해결하기 위한 컨슈머 설정과 DLQ(Dead Letter Queue) 구축 베스트 프랙티스를 짚어드릴게요.

 

1. 실전 트러블슈팅: 잘 돌던 컨슈머가 갑자기 미쳤어요!

새로운 결제 알림 시스템을 만들었다고 가정해 봅시다. 주문이 들어오면 카프카 컨슈머가 메시지를 읽어 외부 API(예: 알림톡 발송 서버)를 호출하고 DB에 저장하는 단순한 로직입니다. 로컬에서는 아주 쾌적하게 동작했습니다.

 

그런데 대규모 할인 이벤트 날, 트래픽이 폭주하기 시작합니다. 이때부터 스프링 부트 콘솔 창에 시뻘건 에러가 폭포수처럼 쏟아집니다.

Java

org.apache.kafka.clients.consumer.CommitFailedException: Commit cannot be completed since the group has already rebalanced and assigned the partitions to another member. This means that the time between subsequent calls to poll() was longer than the configured max.poll.interval.ms, which typically implies that the poll loop is spending too much time message processing.

로그를 자세히 보면 에러만 나는 게 아닙니다. 분명히 고객에게 발송되었던 알림톡이 5분 뒤에 또 발송되고, 10분 뒤에 또 발송되는 끔찍한 '메시지 중복 처리(Duplication)' 현상이 발생하고 있습니다. 식은땀이 흐르기 시작하죠.

왜 터졌을까? (시간제한의 덫)

이 에러 메시지는 카프카 코디네이터가 여러분의 컨슈머를 향해 "너 너무 느려! 죽은 줄 알고 네가 맡은 파티션을 다른 애한테 넘겼어!"라고 소리치는 것과 같습니다.

 

카프카 컨슈머에는 max.poll.interval.ms라는 설정이 있습니다. (기본값 5분, 300,000ms). 한 번 카프카에서 메시지 뭉치(기본값 500개, max.poll.records)를 가져왔으면, 무조건 5분 안에 이 500개의 처리를 다 끝내고 다음 메시지를 가지러 와야 합니다.

 

트래픽이 몰려 외부 알림톡 API 응답이 평소보다 느려졌다고 생각해 보세요. 메시지 1개를 처리하는 데 1초가 걸린다면, 500개를 처리하는 데 500초(8분 20초)가 걸립니다.

5분이 넘어가는 순간 카프카는 이 컨슈머가 죽었다고 판단해버립니다. 그리고 다른 컨슈머에게 파티션을 재할당(Rebalancing)해 버리죠.

 

새로 할당받은 컨슈머는 방금 전 컨슈머가 처리하다가 '완료 보고(Commit)'를 하지 못한 500개의 메시지를 처음부터 다시 처리합니다. 이 과정이 무한 반복되며 리밸런싱 지옥과 중복 발송의 늪에 빠지게 되는 것입니다.

 

⏱️ 카프카 컨슈머 리밸런싱(타임아웃) 위험도 계산기

현재 설정된 카프카 Consumer 옵션과 실제 1건당 처리 시간을 입력해 보세요. max.poll.interval.ms를 초과하여 CommitFailedException이 터질 위험도를 즉시 진단해 드립니다.

1. 한 번에 가져오는 메시지 수 (max.poll.records) * Kafka 기본값은 500개입니다.

2. 메시지 1건당 예상 처리 시간 (밀리초, ms) * 예: 외부 API 호출 및 DB 저장이 포함된 경우 보통 500 ~ 1000ms. (1초 = 1000ms)

3. 컨슈머 타임아웃 제한 시간 (max.poll.interval.ms) * Kafka 기본값은 300,000ms (5분)입니다.

📦 총 예상 처리 시간 (Records × Processing Time)

-

🚨 타임아웃 도달 위험도

-

 

-

 

2. 해결 방법 1: 설정값 튜닝으로 숨통 틔워주기

이 문제를 해결하는 첫 번째 베스트 프랙티스는 컨슈머가 5분 안에 무조건 처리를 끝낼 수 있도록 설정값을 조율하는 것입니다.

• max.poll.records 줄이기: 한 번에 500개씩 욕심내서 가져오지 말고, 50개나 100개로 확 줄이세요.
• max.poll.interval.ms 늘리기: 외부 API 호출이 포함되어 처리가 무거운 로직이라면, 타임아웃 시간을 5분에서 10분(600,000ms) 정도로 넉넉하게 늘려줍니다.

YAML

# application.yml 설정 예시
spring:
  kafka:
    consumer:
      max-poll-records: 50 # 한 번에 50개씩만 가져와서 빠르게 처리하고 커밋!
      properties:
        max.poll.interval.ms: 600000 # 타임아웃을 10분으로 연장

 

3. 해결 방법 2: 멈추지 않는 컨슈머, DLQ(Dead Letter Queue) 구축

 

설정값을 튜닝하더라도 근본적인 문제가 남습니다. 만약 데이터 포맷이 완전히 잘못되었거나, 특정 회원의 DB 상태가 꼬여서 '절대 성공할 수 없는 불량 메시지'가 파티션 맨 앞에 껴있다면 어떻게 될까요?

 

컨슈머는 이 불량 메시지를 처리하려다 에러를 뱉고, 재시도하고, 또 에러를 뱉으며 뒤에 있는 수만 개의 정상 메시지들까지 꽉 막아버립니다. 고속도로 1차선에서 고장 난 차 한 대가 전체 교통을 마비시키는 것과 똑같죠.

장애가 발생한 메시지를 붙잡고 있으면 전체 파티션이 멈춥니다. 문제가 된 메시지는 즉시 DLQ로 우회시켜 파티션의 흐름을 뚫어주어야 합니다.

이럴 때 도입해야 하는 것이 바로 DLQ(Dead Letter Queue, 사서함 큐)입니다.

"3번 정도 재시도해 보고 그래도 안 되면, 이건 불량품이니까 다른 큐(DLQ)로 던져놓고 다음 정상 메시지부터 빨리빨리 처리하자!"라는 실무 최적화 패턴입니다.

Spring Kafka 4.x를 활용한 초간단 DLQ 구현

과거에는 이걸 구현하려면 별도의 프로듀서를 만들고 복잡한 에러 핸들링 코드를 짜야 했지만, 최신 Spring Kafka에서는 @RetryableTopic 어노테이션 하나로 완벽하게 해결됩니다. 특히 최신 4.x 버전부터는 무거운 Spring Retry 라이브러리 의존성을 걷어내고, Spring Framework 7의 코어 재시도 메커니즘을 사용해 훨씬 가볍고 빠릅니다.

Java

import org.springframework.kafka.annotation.RetryableTopic;
import org.springframework.retry.annotation.Backoff;

@Service
public class OrderEventConsumer {

    // 💡 3번 재시도 후 실패하면 자동으로 order-events-dlt 토픽으로 격리합니다!
    @RetryableTopic(
        attempts = "3",
        backoff = @Backoff(delay = 2000, multiplier = 2.0), // 2초, 4초, 8초 대기 후 재시도
        dltTopicSuffix = "-dlt" 
    )
    @KafkaListener(topics = "order-events", groupId = "order-group")
    public void processOrder(String message) {
        // 주문 처리 및 외부 API 호출 로직
        // 여기서 예외(Exception)가 발생하면 자동으로 재시도 후 DLT로 넘어갑니다.
    }
    
    // 격리된 불량 메시지를 처리하는 별도의 리스너 (DB에 에러 로그를 남기거나 슬랙 알림 발송)
    @KafkaListener(topics = "order-events-dlt", groupId = "order-group")
    public void processDlt(String message) {
        log.error("DLQ로 빠진 불량 메시지 처리: {}", message);
    }
}

이렇게 세팅해 두면 외부 API 장애나 불량 데이터가 들어와도, 전체 카프카 시스템이 멈추지 않고 유연하게 흘러가는 아주 견고한 아키텍처를 완성할 수 있습니다.

 

💡 [데브프리의 심층 면접 꿀팁: 에러가 없어도 중복 발송이 된다고요? '멱등성(Idempotency)'으로 방어하세요!]

면접관이 "카프카에서 메시지 중복 처리를 근본적으로 막을 수 있는 방법이 있나요?"라고 묻는다면 완벽한 합격 시그널입니다!

카프카는 태생적으로 네트워크 불안정 등의 이유로 동일한 메시지를 두 번 이상 전달할 수 있는 'At-Least-Once(적어도 한 번 전송)' 시스템입니다. 즉, 설정값을 튜닝하고 DLQ를 만들어도 알림톡이 2번 날아가는 현상을 카프카 레벨에서 100% 막을 수는 없습니다.

따라서 진짜 시니어 개발자는 컨슈머 내부 비즈니스 로직에 '멱등성(Idempotency)'을 반드시 구현합니다. 알림톡을 발송하기 전에 메시지의 고유 ID(eventId)를 DB의 유니크 키(Unique Key)로 잡거나, Redis에 10분간 캐싱하여 "어? 이 이벤트 ID는 아까 처리한 건데?" 하고 쿨하게 무시(Skip)하도록 코드를 짜는 것이 대규모 트래픽을 다루는 백엔드 개발자의 필수 소양이랍니다!

 

4. 시니어 개발자의 팩트 폭격 (Verdict)

카프카(Kafka)와 DLQ, 실무에 언제 도입하고 언제 피해야 할까요?

• 👍 확실한 도입 타이밍:
• MSA(마이크로서비스) 환경에서 서비스 간의 결합도를 낮추고, 대규모 트래픽을 유실 없이 안전하게 받아내야 할 때 카프카는 대체 불가능한 최고의 솔루션입니다. 특히 메시지 처리의 '순서 보장'이 필요하거나, 하나의 이벤트를 여러 개의 컨슈머 그룹이 동시에 소비해야 하는 Event-Driven 아키텍처라면 무조건 도입하세요. 이때 DLQ 설정은 선택이 아닌 필수 생존 전략입니다.
• 🛑 도입을 피해야 할 때:
• "단순히 이메일 발송 작업을 백그라운드로 비동기 처리하고 싶다" 정도의 단순 작업 큐(Job Queue) 용도라면 카프카 도입을 강력히 말립니다. 카프카 4.x에서 KIP-932(Share Consumer)가 나오며 큐잉 기능이 좋아지긴 했지만, 여전히 카프카 클러스터를 운영하고 모니터링하는 인프라 비용은 매우 큽니다. 단순히 순서 상관없이 던져놓고 개별 실패 처리만 하면 되는 작업이라면, RabbitMQ나 AWS SQS, 혹은 Redis의 Pub/Sub을 사용하는 것이 정신 건강과 서버 유지비 측면에서 훨씬 현명한 선택입니다.

카프카는 막강한 처리량을 자랑하지만, 그만큼 컨슈머의 속도와 설정값을 예민하게 맞춰주어야 하는 도구입니다. 오늘 알려드린 max.poll.records 튜닝과 DLQ 구축을 통해 무한 리밸런싱의 악몽에서 벗어나시길 바랍니다.

 

항상 팩트에 기반한 객관적인 실무 가이드로 여러분의 삽질 시간을 줄여드리겠습니다. 다음 포스팅에서도 개발자들에게 유용한 도구 최적화 팁으로 찾아뵙겠습니다!