본문으로 바로가기
구독

Kafka Producer와 Consumer를 실제 택배 흐름으로 이해하기

3분 읽기JK최종 수정 2026.08.22

결론부터 말하면, Producer는 이벤트를 Kafka 토픽에 쓰고 Consumer는 그 토픽에서 자기 읽기 위치를 기준으로 이벤트를 가져간다. Producer가 Consumer에게 직접 택배를 전달하는 구조가 아니다.

택배에 비유하면 Producer는 접수 창구, Broker는 분류·보관 센터, Topic은 목적별 보관 선반, Consumer는 선반에서 물건을 가져가는 수령 시스템에 가깝다. 이 사이를 분리하기 때문에 Consumer가 잠시 멈춰도 보관 기간 안의 이벤트를 다시 읽을 수 있다.

2026-08-22에 Apache 공식 apache/kafka:4.3.1 이미지를 일회성 컨테이너로 실행했다. practical-notes 토픽에 세 메시지를 발행한 뒤 --from-beginning으로 같은 순서의 세 메시지를 소비했고, 컨테이너는 시험 직후 제거했다.

이 글로 해결할 수 있는 것

  • Producer, Broker, Topic과 Consumer의 역할을 구분한다.
  • 메시지를 소비해도 즉시 사라지는 구조로만 이해하면 안 되는 이유를 안다.
  • 단일 브로커 실습과 운영 클러스터의 차이를 설명할 수 있다.

실행 환경

  • 이미지: apache/kafka:4.3.1
  • 이미지 digest: sha256:77e3df…32837
  • 토픽: practical-notes
  • 파티션 1, 복제 계수 1
  • 증거: content/evidence/kafka_4_3_1_20260822.json

1단계: 토픽을 만든다

kafka-topics.sh --create \
  --topic practical-notes \
  --bootstrap-server localhost:9092 \
  --partitions 1 \
  --replication-factor 1

토픽은 이벤트를 분류하는 논리적 이름이다. 파티션이 실제 순서와 병렬 처리 단위가 된다. 이 실습은 파티션이 하나라 한 파티션 안의 순서를 쉽게 확인할 수 있다.

2단계: Producer가 세 이벤트를 쓴다

lesson-started
error-fixed
result-verified

콘솔 Producer에 위 세 줄을 입력했다. Kafka의 콘솔 도구에서는 각 줄이 하나의 이벤트가 된다. Producer는 어느 Consumer가 읽을지 기다리지 않고 Broker의 토픽 파티션에 이벤트를 보낸다.

3단계: Consumer가 처음부터 읽는다

kafka-console-consumer.sh \
  --bootstrap-server localhost:9092 \
  --topic practical-notes \
  --from-beginning \
  --max-messages 3

실제 출력은 lesson-started, error-fixed, result-verified 순서였고 도구는 총 3개 메시지를 처리했다고 보고했다.

offset은 읽은 위치다

Consumer는 파티션의 어느 위치부터 읽을지 offset으로 관리한다. 같은 이벤트를 다시 처리해야 하면 이전 위치로 돌아갈 수 있다. 운영에서는 Consumer group의 offset 커밋 시점과 실제 외부 작업 완료 시점이 어긋나면 중복 또는 누락처럼 보이는 문제가 생길 수 있다.

한계: 이 실습이 증명하지 않는 것

브로커 하나와 복제 계수 1은 장애 허용 구성이 아니다. 처리량, 여러 파티션의 전체 순서, 인증·암호화, 장애 복구, exactly-once 처리도 검증하지 않았다. 운영에서는 최소 in-sync replica, producer acknowledgement, idempotence, consumer commit과 재처리 전략을 별도로 설계해야 한다.

다음 단계

다음 실습에서는 이 토픽의 이벤트를 Consumer가 읽어 MongoDB에 저장할 때 문서 ID와 offset을 이용해 중복을 어떻게 다룰지 확인한다.

출처와 변경 이력

이어서 읽을 만한 콘텐츠