메시징 시스템 (Messaging System)

메시징 시스템이란

메시징 시스템(Messaging System) 은 서비스나 애플리케이션이 메시지를 통해 비동기적으로 통신하도록 만드는 인프라 계층입니다. 요청을 즉시 처리하지 않고 큐나 로그에 적재한 뒤 나중에 소비할 수 있기 때문에, 생산자와 소비자의 실행 시점을 분리할 수 있습니다.

메시징 시스템은 특히 다음 상황에서 자주 등장합니다.

주문 생성 후 결제, 재고, 알림을 순차 또는 병렬로 처리할 때
트래픽 스파이크를 즉시 DB로 보내지 않고 버퍼링할 때
로그, 이벤트, 클릭스트림을 실시간 파이프라인으로 흘릴 때

왜 메시징 시스템을 쓰는가

비동기 처리: 요청 경로에서 오래 걸리는 작업을 분리해 응답 시간을 줄일 수 있습니다.
결합도 완화: 생산자는 소비자의 내부 구현이나 처리 속도를 몰라도 됩니다.
버퍼링: 갑작스러운 트래픽 증가를 큐나 로그가 흡수할 수 있습니다.
확장성: 소비자 인스턴스를 늘려 병렬 처리량을 높일 수 있습니다.
재처리: 일부 시스템은 이미 저장된 메시지를 다시 읽어 분석이나 복구에 활용할 수 있습니다.

메시징 시스템은 단순히 “큐 하나 추가”가 아니라, 동기 호출을 비동기 이벤트 흐름으로 바꾸는 설계 선택입니다.

핵심 구성 요소

Producer: 메시지를 생성해 브로커나 토픽으로 보냅니다.
Consumer: 메시지를 읽고 실제 비즈니스 처리를 수행합니다.
Broker: 메시지를 저장, 라우팅, 전달하는 서버입니다.
Queue: 주로 작업 분산과 순차 처리를 위한 저장 단위입니다.
Topic: 이벤트 스트림이나 pub/sub 구독의 중심 단위입니다.
Consumer Group: 여러 컨슈머가 메시지를 나누어 처리하는 단위입니다. Kafka에서 특히 중요합니다.¹

대표 메시징 패턴

Point-to-Point

한 메시지를 한 소비자만 처리하는 모델입니다.

적합한 경우: 작업 큐, 이미지 리사이징, 메일 발송, 배치 작업
핵심 포인트: 메시지 분배와 재시도 전략이 중요합니다.

Publish/Subscribe

하나의 이벤트를 여러 소비자가 각자 처리하는 모델입니다.

적합한 경우: 주문 생성 후 결제 서비스, 알림 서비스, 통계 서비스가 각각 반응할 때
핵심 포인트: 소비자 간 독립성을 확보하기 좋지만, 중복 처리 대비가 필요합니다.

Event Streaming

이벤트를 일정 기간 저장해 두고, 여러 소비자가 오프셋 기준으로 읽는 모델입니다.¹

적합한 경우: 로그 수집, CDC, 실시간 분석, 이벤트 소싱
핵심 포인트: 메시지 단순 전달보다 “이벤트 로그 보존과 재소비”에 강합니다.

이 문서는 메시징 패턴의 큰 그림에 집중합니다.
window, watermark, stateful processing, Spark/Flink 비교처럼 “이벤트를 받아 실제 계산을 지속적으로 수행하는 모델”은 스트림 처리 (Stream Processing) 문서와 같이 보면 경계가 더 분명합니다.

브로커 기반과 스트리밍 기반의 차이

항목	브로커 기반 메시징	스트리밍 기반 메시징
대표 제품	RabbitMQ, ActiveMQ, SQS	Kafka, Pulsar
핵심 모델	큐에 넣고 전달	파티션 로그에 기록하고 읽기
주 사용처	작업 큐, 라우팅, 비동기 업무 처리	이벤트 파이프라인, 로그, 실시간 분석
메시지 소비 방식	처리 후 ack 중심	오프셋 기반 재소비 가능
강점	유연한 라우팅, 낮은 지연, 작업 분배	높은 처리량, 재처리, 스트림 처리

실무에서는 둘 중 하나만 정답인 경우보다, 업무 처리 큐는 RabbitMQ, 이벤트 파이프라인은 Kafka처럼 역할을 분리하는 경우가 많습니다.

Kafka와 RabbitMQ

Apache Kafka

Kafka 는 분산 이벤트 스트리밍 플랫폼입니다. 토픽은 여러 파티션으로 나뉘고, 각 파티션은 순서가 보장되는 append-only log처럼 동작합니다.¹

강점: 높은 처리량, 파티션 기반 확장, 이벤트 재처리, 스트림 파이프라인
핵심 개념: topic, partition, offset, consumer group
적합한 경우: 로그 수집, CDC, 이벤트 버스, 실시간 분석, 데이터 파이프라인

Kafka를 설명할 때 중요한 포인트는 다음입니다.

같은 파티션 안에서는 순서가 보장됩니다.
consumer group 안에서는 각 파티션이 한 consumer에 할당됩니다.¹
메시지를 읽은 뒤에도 보존 기간 동안 다시 읽을 수 있습니다.

Kafka의 ISR, acks, offset commit, rebalance, lag 같은 운영 꼬리질문은 Kafka (Apache Kafka) 문서에서 더 깊게 다룹니다.

RabbitMQ

RabbitMQ 는 AMQP 기반 메시지 브로커로, 큐와 exchange를 이용해 메시지를 유연하게 라우팅하는 데 강합니다.

강점: 작업 큐 처리, 복잡한 라우팅, 상대적으로 쉬운 업무용 메시징
핵심 개념: exchange, queue, binding, consumer acknowledgement, publisher confirm
적합한 경우: 비동기 업무 처리, 이메일 발송, 주문 후속 작업, 백그라운드 잡

RabbitMQ를 설명할 때 중요한 포인트는 다음입니다.

exchange가 메시지를 적절한 queue로 라우팅합니다.
consumer acknowledgement와 publisher confirm을 통해 신뢰성을 높일 수 있습니다.²³
기본 모델은 exactly-once가 아니라, 설정에 따라 at-most-once 또는 at-least-once에 가깝습니다.³

Kafka와 RabbitMQ 비교

항목	Kafka	RabbitMQ
핵심 성격	이벤트 스트리밍 플랫폼	메시지 브로커
저장 모델	파티션 로그	큐
재처리	보존 기간 동안 재소비 가능	일반적으로 전달/ack 중심
강점	높은 처리량, 이벤트 파이프라인	유연한 라우팅, 작업 큐
순서 보장	파티션 단위	큐/소비 패턴에 따라 달라짐
대표 사용처	로그, CDC, 분석, 이벤트 버스	업무 처리, 비동기 잡, 알림

선택 기준은 “누가 더 좋나”가 아니라 “무엇을 저장하고, 어떻게 소비할 것인가”입니다.

전달 보장과 운영 시 주의점

메시징 시스템 면접에서 자주 나오는 주제는 전달 보장입니다.

At-most-once: 중복은 적지만 손실 가능성이 있습니다.
At-least-once: 손실을 줄이지만 중복 가능성이 있습니다.
Exactly-once: 특정 제품과 시나리오에서 제한적으로 구현할 수 있지만, 시스템 전체 수준에서 항상 쉽게 얻어지는 속성은 아닙니다.

운영에서는 다음을 같이 봐야 합니다.

중복 처리: 컨슈머는 idempotency를 준비해야 합니다.
재시도와 DLQ: 반복 실패 메시지를 어디로 보낼지 정해야 합니다.
백프레셔: 소비 속도가 생산 속도를 못 따라갈 때 지연이 누적됩니다.
순서 보장 범위: 전역 순서는 어렵고, 보통 파티션이나 큐 단위 순서를 다룹니다.
관측성: lag, unacked 메시지 수, 처리 시간, 실패율을 모니터링해야 합니다.

면접 포인트

메시징 시스템의 목적은 비동기화, 결합도 완화, 버퍼링입니다.
Kafka는 이벤트 로그와 스트리밍, RabbitMQ는 작업 큐와 라우팅에 강하다고 설명하는 편이 안전합니다.
RabbitMQ를 exactly-once로 설명하면 안 됩니다.
Kafka의 순서 보장은 토픽 전체가 아니라 파티션 단위입니다.
실무에서는 전달 보장보다 idempotency, retry, DLQ 설계까지 함께 말해야 답변이 강해집니다.