💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

프롤로그 — "메시지 큐 쓸까요?" 라는 질문이 이상해진 시대

2026년 어느 팀의 설계 회의.

주니어: "이벤트는 Kafka로 보내면 되죠?"

시니어: "트래픽 얼마야?"

주니어: "초당 100건이요."

시니어: "...왜 Kafka야?"

이 짧은 대화에 2026년의 모든 게 들어있다. 한쪽에는 **"메시징 = Kafka"** 라는 거의 종교적 신념이 있고, 다른 한쪽에는 **"카프카 안 써도 되는 일에 카프카를 쓰지 마라"** 는 베테랑의 한숨이 있다. 그리고 그 사이를 NATS, Redpanda, Pulsar, RabbitMQ 4, RocketMQ, WarpStream, Buf Stream이 채우고 있다.

2026년 현재, 분산 메시징은 **세 개의 패러다임**으로 갈라진다. 전통적 메시지 큐(RabbitMQ), 로그 기반 스트리밍(Kafka 계열), 그리고 클라우드 네이티브 pub/sub(NATS, Pulsar). 그리고 그 위에 **운영 모델**의 두 축이 겹친다 — 디스크 기반 vs 오브젝트 스토리지 기반(WarpStream, Kafka tiered storage), 자가 운영 vs 매니지드.

이 글은 그 전체 지형을 한 번에 정리한다. Kafka 3.9의 KRaft 전환부터, WarpStream의 S3 위 Kafka, NATS의 단일 인프라 야망, Pulsar Functions, RabbitMQ 4의 Khepri 전환, 그리고 한국·일본 빅테크가 무엇을 어떻게 쓰는지까지.

1장 · 2026년 분산 메시징 지도 — Pub/Sub / Queue / Stream 3 패러다임

먼저 용어부터. 메시지 시스템은 보통 세 가지로 묶인다.

| 패러다임 | 의미 | 대표 | 메시지 보존 |

| --- | --- | --- | --- |

2026년에는 경계가 흐려졌다. Kafka는 queue 흉내(static membership, share groups)를 내고, RabbitMQ는 stream(Streams 플러그인)을 추가했고, NATS는 JetStream으로 persistent stream을 가졌고, Pulsar는 처음부터 둘 다였다.

그래도 **선택의 출발점은 패러다임**이다. 다음 의사결정 트리를 권한다.

1. **"한 작업을 한 컨슈머가 처리하고 끝"**인가? → Queue (RabbitMQ, SQS).

2. **"같은 이벤트를 여러 시스템이 봐야"** 하는가? → Stream (Kafka, Pulsar) 또는 Pub/Sub (NATS).

3. **"이벤트를 며칠~몇 년 보관하고 재처리"** 해야 하는가? → Stream + 긴 보존 (Kafka + tiered storage, Pulsar tiered).

4. **"트래픽이 초당 수십~수백건이고, 단순"** → RabbitMQ 또는 NATS Core.

5. **"멀티 테넌트, 멀티 리전, 짧은 P99"** → NATS 또는 Pulsar.

6. **"AWS만 쓰고 S3 비용으로 끝내고 싶다"** → WarpStream.

Kafka가 망치라면 모든 문제가 못이 된다. 2026년의 베테랑은 "초당 100건이면 RabbitMQ로 충분하다, 운영이 10배 쉽다" 라고 말한다.

2장 · Kafka 3.9 (KRaft default, ZooKeeper 제거) → 4.0 전망

2024년 Kafka 3.7에서 KRaft가 production-ready로 선언됐고, 2024년 말 Kafka 3.9는 **KRaft가 기본**이 되었으며 ZooKeeper 기반 모드는 deprecated 됐다. 그리고 2025년 Kafka 4.0이 출시되면서 **ZooKeeper 코드 자체가 제거**됐다.

이 변화의 의미는 운영에 직접 닿는다.

| 항목 | ZK 시대 | KRaft 시대 |

| --- | --- | --- |

| 클러스터 코디네이션 | 외부 ZooKeeper 앙상블 | Kafka 내부 Raft (KRaft) |

| 부트스트랩 | broker + 3~5 ZK | broker(controller 역할 겸임/분리) |

| 메타데이터 저장 | ZK znode | Kafka 내부 토픽 (__cluster_metadata) |

| 메타데이터 한계 | 약 200K 파티션 | 수백만 파티션 |

| 시작 시간 | 수십 초~분 | 수 초 |

| 운영 복잡도 | 두 시스템 | 한 시스템 |

KRaft 클러스터를 띄우는 가장 단순한 방식.

Kafka 3.9, single-node KRaft (개발용)

export KAFKA_HOME=/opt/kafka_2.13-3.9.0

$KAFKA_HOME/bin/kafka-storage.sh random-uuid

출력: yzs8XK6oR1qV3R-... (CLUSTER_ID)

$KAFKA_HOME/bin/kafka-storage.sh format \

-t $CLUSTER_ID \

-c $KAFKA_HOME/config/kraft/server.properties

$KAFKA_HOME/bin/kafka-server-start.sh \

$KAFKA_HOME/config/kraft/server.properties

production 권장 구성은 controller와 broker를 **분리** (`process.roles=controller` vs `process.roles=broker`). 3 controller + N broker가 표준.

2026년 현재 핵심 KIP들.

- **KIP-405 — Tiered Storage**: 오래된 세그먼트를 S3/GCS/HDFS로 자동 오프로드. hot은 로컬 SSD, cold는 오브젝트 스토리지. 저장 비용 1/5~1/10.

- **KIP-848 — Next Gen Consumer Rebalance**: 컨슈머 그룹 리밸런스를 서버 사이드로 옮김. stop-the-world 시간 단축.

- **KIP-932 — Queues for Kafka (Share Groups)**: 4.0의 빅 피처. Kafka 위에 **queue 시맨틱**(같은 토픽을 여러 컨슈머가 경쟁 소비, ack/timeout/redelivery)을 정식 지원. RabbitMQ의 영역을 침범.

- **KIP-1102 — Transactions v2**: 트랜잭션 코디네이터 안정성 개선.

KRaft + tiered storage + share groups의 조합으로, Kafka 4.0은 "stream도, queue도, 장기 저장도 한 시스템"을 노린다.

3장 · Confluent Cloud vs Aiven vs Redpanda — Kafka 매니지드

Kafka를 직접 운영하는 팀은 점점 줄어든다. 매니지드 옵션이 성숙했기 때문.

| 제공자 | 호환성 | 가격 모델 | 특징 |

| --- | --- | --- | --- |

2026년 현실적 선택 가이드.

- **풀 스택 통합 + 엔터프라이즈 지원**: Confluent Cloud.

- **순수 OSS Kafka, 멀티 클라우드**: Aiven.

- **AWS 락인 ok, MSK Serverless로 단순화**: MSK.

- **운영 단순함 + 절반 노드**: Redpanda Cloud.

- **저장 비용 최소화, 클라우드 데이터 egress 최소화**: WarpStream.

가격에서 가장 큰 변수는 **클라우드 inter-AZ 전송 비용**이다. Kafka가 3 AZ 복제를 기본으로 하면, replica 트래픽이 AZ를 넘으며 GB당 0.01~0.02달러가 발생. 처리량 큰 워크로드에서 이 비용이 클러스터 비용보다 커진다. WarpStream과 KIP-392(fetch from follower)가 이 비용을 줄이는 핵심.

4장 · Redpanda — C++ 기반 Kafka 호환

Redpanda는 2019년 Vectorized(현재 Redpanda Data)가 시작했다. 한 줄 요약: **JVM 없이 C++로 다시 쓴 Kafka**. ScyllaDB의 시아스타(Seastar) thread-per-core 모델을 가져왔다.

핵심 차이.

- **No JVM, no GC pause**: P99 지연이 안정적.

- **No ZooKeeper from day 1**: Kafka보다 먼저 자체 Raft 사용.

- **단일 바이너리**: broker = controller, 1~3 노드부터 운영 가능.

- **Kafka wire 호환**: client·connector·UI 그대로 사용.

- **Tiered storage 내장**: S3/GCS로 cold 데이터.

- **WASM transforms**: Redpanda Data Transforms (broker 내부에서 WASM 코드 실행).

성능 주장은 "동일 하드웨어에서 Kafka 대비 2~5배 처리량, 1/3 노드". 벤치마크는 항상 워크로드에 따라 다르지만, **노드 수가 줄어 운영 부담이 작아진다**는 점은 실제 경험과 일치.

Docker로 single-node 띄우기.

docker run -d --name redpanda \

-p 9092:9092 -p 9644:9644 \

redpandadata/redpanda:v24.3.1 \

redpanda start --smp 1 --memory 1G --reserve-memory 0M \

--overprovisioned --node-id 0 --check=false

Kafka 클라이언트로 그대로 연결.

docker exec -it redpanda rpk topic create test

docker exec -it redpanda rpk topic produce test

> hello

> ^D

docker exec -it redpanda rpk topic consume test --num 1

2026년 Redpanda 포지셔닝은 "**JVM/ZK 운영이 싫고, Kafka 호환은 필요한 팀**" 이다. 게임·금융·IoT처럼 지연 일관성이 중요한 곳에서 채택이 늘었다.

5장 · WarpStream (Confluent 인수 2024) — S3 위의 Kafka

WarpStream은 2023년 등장해 2024년 9월 Confluent에 인수됐다. **Kafka wire 호환 + 저장은 S3** 라는 한 줄 아이디어가 본질.

전통적 Kafka의 비용 구조.

1. broker 인스턴스 비용 (EC2/EBS).

2. AZ 간 복제 트래픽 ($0.01/GB).

3. EBS 저장 비용.

4. 컨슈머가 다른 AZ에 있으면 fetch 비용.

WarpStream 구조는 다르다.

1. **상태 없는 Agent** 가 Kafka wire 프로토콜을 받아 S3에 직접 쓴다.

2. 메타데이터는 WarpStream 컨트롤 플레인(또는 BYOC 모드의 자체 컨트롤러).

3. 디스크가 없다 → AZ 간 복제 트래픽 없음.

4. 모든 데이터가 S3 → 11 9's durability를 클라우드가 보장.

5. 컴퓨트(Agent)와 스토리지(S3) 완전 분리 → 둘 다 독립 스케일.

대가는 **지연 시간**. 전통적 Kafka는 P99 produce가 5~50ms 인 반면, WarpStream은 200~500ms (S3 PUT latency 때문). 그래서 "low-latency 실시간"에는 안 맞고, "고처리량 + 비용 최소 + 1초 정도 지연 OK" 워크로드에 맞다. 데이터 레이크 인제스션, 로그/메트릭 파이프라인, CDC sink가 대표 케이스.

Confluent 인수 후 방향성은 "Confluent Cloud의 한 deployment 유형"으로 통합. Confluent Cloud Freight Cluster가 사실상 WarpStream 엔진.

6장 · NATS + JetStream + KV + ObjectStore

NATS는 2011년 등장한 가벼운 pub/sub 시스템이다. 2018년 Synadia가 회사로 분사, 2018년 CNCF에 기증. 핵심 철학은 "단순함과 속도".

NATS의 진화.

| 시기 | 기능 |

| --- | --- |

| 2011 | Core NATS — fire-and-forget pub/sub |

| 2018 | NATS Streaming (deprecated) |

| 2020 | JetStream — persistent stream, KV, ObjectStore |

| 2024 | NATS 2.10 — domains, leaf node 보안 |

| 2025 | NATS 2.11 — Pull consumer 개선, ADR 통합 |

2026년 NATS 한 노드(자체 클러스터링이 단순).

JetStream 활성화

nats-server -js -sd /data/nats

스트림 만들기.

nats stream add ORDERS \

--subjects "orders.>" \

--storage file --retention limits \

--max-msgs=1000000 --max-age=24h

KV 사용.

nats kv add config

nats kv put config feature.new-checkout '{"enabled":true}'

nats kv get config feature.new-checkout

ObjectStore (S3-like).

nats object add my-bucket

nats object put my-bucket large.zip ./large.zip

nats object get my-bucket large.zip > out.zip

NATS의 강점은 **단일 인프라**다. queue + pub/sub + stream + KV + 오브젝트 + 분산 락 + leader election을 한 바이너리로 한다. 마이크로서비스가 많고 멀티 리전/에지가 있는 곳에서 NATS는 "Kafka 하나, Redis 하나, Consul 하나, MinIO 하나"의 합 보다 단순하다.

약점은 생태계. Kafka의 거대한 connector 생태계, Schema Registry, Stream Processing(ksqlDB·Flink) 같은 게 NATS에는 약하다.

7장 · Apache Pulsar 4.0 + Pulsar Functions

Apache Pulsar는 야후가 2016년 오픈소스화, 2018년 Apache 졸업. 핵심 차별점은 **컴퓨트와 스토리지 분리** (broker = stateless, BookKeeper = storage).

Pulsar 4.0(2025년 초)의 핵심.

- **Lakehouse Tiered Storage**: 오래된 데이터를 Parquet로 S3/GCS에 저장, Trino/Spark이 직접 쿼리.

- **Pulsar Functions 안정화**: 스트림 위에서 lambda 같은 함수 실행, function mesh로 워크플로.

- **Topic Compaction 개선**.

- **WebSocket·HTTP·MQTT 프로토콜 게이트웨이 통합**.

Pulsar의 구조적 장점.

| 항목 | Kafka | Pulsar |

| --- | --- | --- |

| broker 상태 | stateful (디스크) | stateless |

| 저장 | broker 디스크 | BookKeeper bookie |

| 노드 추가 시 리밸런스 | 데이터 이동 필요 | 거의 즉시 |

| 멀티 테넌시 | 클러스터 단위 | 1 클러스터에 tenant/namespace/topic |

| 지역 복제 | MirrorMaker 2 | Geo-replication 내장 |

Pulsar의 약점은 **운영 복잡도**. broker + bookie + ZooKeeper(2026년에도 Pulsar는 ZK 사용)의 세 컴포넌트가 별도 운영 필요. 게다가 한국·일본에서는 인지도가 낮아 운영 인력 구하기 어렵다.

2026년 Pulsar는 "**대규모 멀티 테넌트 SaaS**" 영역에서 강세. Splunk·Yahoo·Tencent·Streamnative 같은 곳에서 수십만 토픽을 단일 클러스터로 운영한다.

8장 · RabbitMQ 4.0 — Khepri (Raft) + Streams 플러그인

RabbitMQ는 2007년부터 있던 AMQP 0.9.1 구현체로, "메시지 큐의 표준" 같은 위치. 2024년 RabbitMQ 4.0이 큰 전환이었다.

핵심 변화.

- **Mnesia → Khepri**: 클러스터 메타데이터 저장을 Erlang Mnesia(고전적 분산 DB)에서 Khepri(Raft 기반 자체 DB)로 교체. split-brain 회복이 깔끔해졌다.

- **Streams 플러그인 GA**: Kafka 같은 append-only log를 RabbitMQ 내부에 통합 (Stream Queue Type). 처리량 100만 msg/s 가능.

- **Quorum Queue 기본화**: 클래식 큐 대신 Raft 기반 Quorum Queue를 권장.

- **MQTT 5 / AMQP 1.0 강화**.

RabbitMQ가 여전히 잘 맞는 곳.

- **job queue**: Celery, Sidekiq, Resque 등 워커 시스템.

- **RPC 패턴**: request-reply with reply-to queue.

- **fanout / topic routing**: 라우팅 키 기반 복잡한 분기.

- **백오피스 작업**: 이메일 발송, PDF 생성, 결제 처리.

Quorum Queue 예시.

큐 선언 (CLI)

rabbitmqadmin declare queue name=tasks queue_type=quorum

Java 클라이언트로 publish.

ConnectionFactory factory = new ConnectionFactory();

factory.setHost("rabbitmq");

try (Connection conn = factory.newConnection();

Channel ch = conn.createChannel()) {

ch.queueDeclare("tasks", true, false, false,

Map.of("x-queue-type", "quorum"));

ch.basicPublish("", "tasks",

MessageProperties.PERSISTENT_TEXT_PLAIN,

"hello".getBytes());

}

RabbitMQ를 Kafka로 대체하려는 시도는 항상 후회로 끝난다. **초당 수천~수만건의 작업, 복잡한 라우팅, 짧은 보존**이면 RabbitMQ가 훨씬 단순하고 싸다.

9장 · Apache RocketMQ (Alibaba) — 중국 스케일

RocketMQ는 알리바바가 2012년 만들고 2017년 Apache 졸업. 알리바바 더블 일레븐(11/11)의 핵심 인프라로, **초당 수십억 메시지 규모**에서 검증된 시스템.

특징.

- **순서 보장 모드**: 파티션이 아니라 메시지 그룹 단위 순서 (FIFO Topic).

- **트랜잭션 메시지**: half-commit / commit / rollback 3단계 — DB 트랜잭션과 메시지 발행의 원자성.

- **스케줄 메시지·딜레이 메시지** 내장.

- **dashboard·tracing** 완성도 높음.

- **Rocketmq 5.0+** (2023~): 컴퓨트/스토리지 분리, 클라우드 네이티브.

한국·일본·서구에서는 거의 안 쓰이지만, 중국·동남아에서는 Kafka 대안으로 매우 흔하다. 알리바바 클라우드의 메시지 서비스가 사실상 RocketMQ.

트랜잭션 메시지 패턴 예 (Java).

TransactionMQProducer producer = new TransactionMQProducer("group");

producer.setTransactionListener(new TransactionListener() {

public LocalTransactionState executeLocalTransaction(Message msg, Object arg) {

// 1) DB 트랜잭션 실행

// 2) 성공 → COMMIT, 실패 → ROLLBACK, 모름 → UNKNOWN

return LocalTransactionState.COMMIT_MESSAGE;

}

public LocalTransactionState checkLocalTransaction(MessageExt msg) {

// 브로커가 미해결 메시지 재확인

return LocalTransactionState.COMMIT_MESSAGE;

}

});

RocketMQ를 새 프로젝트에 쓸 한국 팀은 거의 없지만, 알리바바 클라우드/Tencent 클라우드에 배포한다면 매니지드 RocketMQ가 자연스럽다.

10장 · NSQ / Memphis (Superstream)

NSQ

NSQ는 bitly가 2013년 오픈소스화한 분산 메시지 시스템. Go로 작성. 철학은 "**중앙 브로커 없는, 토폴로지가 단순한 시스템**".

- **단일 바이너리 (nsqd)** 가 각 호스트에 배포 → 메시지가 호스트 로컬에서 발행.

- nsqlookupd가 발견을 담당.

- 클러스터링 없음 (각 노드 독립).

- 메모리 우선, overflow시 디스크.

NSQ는 단순함이 무기다. 큰 회사가 안 쓴다는 인식이 있지만 IRC bot·도메인 인덱싱·간단한 작업 큐 같은 곳에서 여전히 좋은 선택. 그러나 2026년 새 프로젝트라면 NATS가 거의 모든 기능을 더 잘한다.

Memphis → Superstream

Memphis는 2022년 등장한 Kafka 대체 시도였다. "개발자 친화적 Kafka" 를 표방하며 GUI·schema management·DLQ를 기본 제공했다. 2024년 회사가 **Superstream**으로 리브랜드, 방향을 "**Kafka 위의 cost optimization 레이어**" 로 전환했다.

2026년 Superstream의 포지셔닝은 흥미롭다.

- Kafka를 **대체하지 않고** AI 기반 컨피그 튜닝, 자동 압축, partition balancing을 한다.

- Confluent Cloud / MSK / Aiven 위에 얹어서 비용 30~50% 절감을 약속.

- 인기 패턴: 잘못 잡힌 batch.size·linger.ms·compression.type을 워크로드 기반으로 재추천.

"Kafka는 그대로 두되 비용을 깎는다" 는 컨셉으로, 매니지드 Kafka 비용이 부담되는 팀이 도입하고 있다.

11장 · Buf Stream — gRPC streams의 새 시도

Buf은 Protocol Buffers 도구 회사로 유명하다. 2024년 **Buf Stream**을 발표하며 메시징에 진입.

핵심 아이디어.

- **Schema-first 메시징**: 모든 토픽이 Protobuf 스키마. 잘못된 메시지는 발행 자체가 거부.

- **Kafka API 호환**: 기존 Kafka client 그대로.

- **Buf Schema Registry**와 통합 — 스키마 진화 규칙 강제.

- **stateless 아키텍처**: WarpStream과 비슷하게 S3/오브젝트 스토리지를 1차 저장.

Buf Stream의 가치 제안.

- "잘못된 데이터가 토픽에 들어가는 일을 컴파일/배포 단계에서 막는다."

- "Buf CLI로 스키마 변경 lint, 호환성 체크, breaking change 차단."

- "Kafka client 그대로 — 인프라 교체만."

2026년 현재 Buf Stream은 적은 회사들이 production에서 쓰지만, **schema governance가 핵심 가치인 조직**(금융·헬스케어·B2B SaaS)에서 관심을 받고 있다. Confluent Schema Registry + Kafka 의 "두 시스템"을 한 시스템으로 묶는 시도.

12장 · 이벤트 소싱 / CQRS / Outbox / Saga 패턴

메시징 시스템은 도구일 뿐, **어떻게 쓰느냐**가 진짜다. 2026년에도 변치 않는 핵심 패턴 4개.

1) 이벤트 소싱 (Event Sourcing)

상태를 직접 저장하지 않고 **상태를 만든 이벤트의 시퀀스**를 저장. 현재 상태는 이벤트를 fold해서 얻는다.

// 주문 상태 = 이벤트들의 fold

function orderState(events) {

return events.reduce((state, e) => {

switch (e.type) {

case 'OrderCreated': return { id: e.id, status: 'PENDING', items: e.items };

case 'OrderPaid': return { ...state, status: 'PAID', paidAt: e.at };

case 'OrderShipped': return { ...state, status: 'SHIPPED', tracking: e.tracking };

default: return state;

}

}, null);

}

- 장점: 감사·시간 여행·새 view 재구축.

- 단점: 쿼리가 어려움 → CQRS와 함께.

2) CQRS (Command Query Responsibility Segregation)

쓰기 모델과 읽기 모델을 분리. 이벤트 스트림에서 read model을 비동기로 빌드.

3) 트랜잭션적 Outbox

가장 흔히 틀리는 패턴: "DB 트랜잭션 → 이벤트 발행" 을 따로 하면 둘 사이에 장애가 나면 불일치. Outbox는 같은 DB 트랜잭션에 `outbox` 테이블 INSERT를 묶고, **별도 프로세스가 outbox를 읽어 Kafka로 발행**. Debezium CDC 또는 자체 poller.

BEGIN;

INSERT INTO orders (id, user_id, total) VALUES (...);

INSERT INTO outbox (aggregate_id, event_type, payload)

VALUES ('order-123', 'OrderCreated', '{"...":"..."}');

COMMIT;

-- 다른 프로세스가 outbox를 폴링/CDC해서 Kafka로

4) Saga

여러 서비스에 걸친 트랜잭션의 분산 버전. 각 단계마다 보상 트랜잭션을 정의.

- 결제 → 재고 차감 → 배송 예약. 어느 단계에서 실패하면 앞 단계를 보상(환불·재고 복구).

- 구현 방식 두 가지: 오케스트레이션(중앙 코디네이터, Temporal·AWS Step Functions) vs 코레오그래피(각 서비스가 이벤트 보고 반응).

이 네 패턴 없이 분산 메시징을 production에서 운영하는 건 데이터 불일치의 시한폭탄이다.

13장 · 한국/일본 도입 — 카카오, 토스, 라인, Mercari, ZOZO, CyberAgent

카카오

카카오는 **Kafka를 사내 매니지드 서비스화**해 운영한다. 카카오톡 메시지 흐름·검색 인덱싱·로그 파이프라인이 Kafka 위에 올라간다. KRaft 전환은 2025년부터 단계적으로 진행 중. 일부 팀은 RabbitMQ를 백오피스 워커에 사용.

토스(Toss)

토스의 데이터 엔지니어링은 Kafka 중심으로 알려져 있다. 결제 이벤트·CDC·실시간 ML 피처 스토어가 Kafka 위. 작년부터 일부 워크로드에 **WarpStream/Tiered Storage** 검토. 사내 컨퍼런스 SLASH에서 Kafka 운영 노하우 공유 다수.

라인(LINE)

라인은 메시지 인프라 자체가 **자체 개발 큐(LMQ)** + Kafka 하이브리드. 트래픽이 글로벌이고 메시지 순서가 중요해 자체 솔루션을 유지. 광고·로그·메트릭 영역은 Kafka. Java 진영이 강한 만큼 ZooKeeper 시절부터의 운영 경험이 자산.

Mercari

Mercari는 GCP 중심으로 **Pub/Sub + Dataflow** 가 메인이지만, 결제·재고 같은 곳에서 Kafka도 사용. Mercari 엔지니어링 블로그에 Pub/Sub vs Kafka 비교 글 다수.

ZOZO

ZOZO는 검색·추천 파이프라인에 Kafka 채택. 패션 카탈로그 변경 → 검색 인덱스 업데이트의 거의 모든 흐름이 Kafka. 사내에서 Schema Registry 운영 사례 공유.

CyberAgent / AbemaTV

AbemaTV의 라이브 스트리밍 메타데이터, 광고 입찰 파이프라인에 Kafka. CyberAgent 그룹사들이 NATS·Pulsar도 부분 도입 — 일본 컨퍼런스 발표가 늘었다.

공통점: **2026년에는 "Kafka 한 가지로 통일" 보다 "워크로드별 적정 도구" 로 가는 흐름**이다. 결제·CDC는 Kafka, 마이크로서비스 통신은 NATS, 작업 큐는 RabbitMQ, 데이터 레이크 인제스션은 WarpStream/MSK Tiered. 한 회사 안에 3~4개의 메시징이 공존하는 게 표준이 됐다.

14장 · 의사결정 체크리스트 — 우리 팀은 뭘 쓸까

마지막으로 한 페이지 결정표.

| 상황 | 1순위 | 대안 |

| --- | --- | --- |

| 초당 100건 이하, job queue | RabbitMQ | NATS JetStream, SQS |

| 초당 1만~수십만, 멀티 컨슈머, 이벤트 로그 | Kafka (KRaft) | Redpanda, Pulsar |

| 멀티 리전, P99 1ms 목표 | NATS | Pulsar |

| AWS only, 저장 비용 핵심 | WarpStream | MSK + Tiered Storage |

| 멀티 테넌트 SaaS, 수십만 토픽 | Pulsar | Kafka with KRaft + careful partition mgmt |

| 운영 인력 0~1명 | 매니지드 (MSK Serverless, Confluent Cloud, NATS Synadia Cloud) | - |

| 중국 시장 | RocketMQ / Aliyun MQ | Kafka |

| schema-first, 강한 거버넌스 | Buf Stream | Kafka + Confluent Schema Registry |

| 단순 pub/sub, 초소형 | NATS Core | Redis Pub/Sub |

| 이미 Kafka 쓰는데 비용 절감 | Superstream + WarpStream | 직접 튜닝 + Tiered Storage |

운영 관점에서 잊지 말 것.

- **모니터링**: Prometheus + Kafka Exporter / Burrow(컨슈머 lag), JMX 메트릭, Datadog/Grafana.

- **schema 관리**: Confluent Schema Registry / Buf / Karapace. 스키마 없이 production 토픽 만들면 6개월 뒤 후회.

- **백업/DR**: MirrorMaker 2 (Kafka), Geo-replication (Pulsar), JetStream mirrors (NATS).

- **권한**: SASL/OAuth, ACL — production에서 익명 발행이 가능하면 안 된다.

- **컨슈머 lag 알람**: 컨슈머 lag 30분 이상이면 페이지. 가장 흔한 incident 원인.

에필로그 — 메시지는 인프라가 아니라 계약이다

2026년 분산 메시징의 진짜 교훈은 도구가 아니라 **계약**이다. 시스템과 시스템 사이의 계약 — 어떤 이벤트가, 어떤 스키마로, 어떤 보장(at-least-once·exactly-once·순서·지연) 안에서 흐르는가.

도구는 바뀐다. 5년 전엔 ZooKeeper 운영하던 사람이 오늘은 KRaft를 운영하고, 내년엔 S3 위의 Kafka를 운영할 수 있다. 그러나 **계약을 잘 설계한 팀은 도구를 바꿔도 살아남는다**. 잘못 설계한 팀은 도구를 바꿔도 같은 문제를 겪는다.

다음 글 후보: **Outbox 패턴 깊게 — Debezium CDC + Kafka로 만드는 가장 안전한 이벤트 발행**, **컨슈머 lag을 0으로 만드는 법 — KIP-848 / partition assignment / 백프레셔**, **NATS 멀티 리전 — leaf node로 진짜 전 세계 분산 만들기**.

> "메시지 큐를 고르는 일은 두 시스템 사이의 계약을 디자인하는 일이다. 도구는 그 뒤에 온다."

— 분산 메시징 2026, 끝.

참고 / References

- [Apache Kafka 3.9 release notes](https://kafka.apache.org/39/documentation.html)

- [KIP-833 — Mark KRaft as Production Ready](https://cwiki.apache.org/confluence/display/KAFKA/KIP-833%3A+Mark+KRaft+as+Production+Ready)

- [KIP-405 — Kafka Tiered Storage](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage)

- [KIP-848 — Next Generation Consumer Rebalance Protocol](https://cwiki.apache.org/confluence/display/KAFKA/KIP-848%3A+The+Next+Generation+of+the+Consumer+Rebalance+Protocol)

- [KIP-932 — Queues for Kafka (Share Groups)](https://cwiki.apache.org/confluence/display/KAFKA/KIP-932%3A+Queues+for+Kafka)

- [Confluent Cloud](https://www.confluent.io/confluent-cloud/)

- [Aiven for Apache Kafka](https://aiven.io/kafka)

- [AWS MSK](https://aws.amazon.com/msk/)

- [Redpanda Documentation](https://docs.redpanda.com/)

- [Redpanda GitHub — redpanda-data/redpanda](https://github.com/redpanda-data/redpanda)

- [WarpStream Documentation](https://docs.warpstream.com/)

- [Confluent acquires WarpStream (2024)](https://www.confluent.io/blog/confluent-acquires-warpstream/)

- [NATS Documentation](https://docs.nats.io/)

- [NATS JetStream](https://docs.nats.io/nats-concepts/jetstream)

- [NATS GitHub — nats-io/nats-server](https://github.com/nats-io/nats-server)

- [Apache Pulsar Documentation](https://pulsar.apache.org/docs/)

- [Pulsar Functions](https://pulsar.apache.org/docs/functions-overview/)

- [RabbitMQ 4.0 release notes](https://www.rabbitmq.com/release-information)

- [RabbitMQ Khepri](https://www.rabbitmq.com/docs/metadata-store)

- [RabbitMQ Streams](https://www.rabbitmq.com/docs/streams)

- [Apache RocketMQ](https://rocketmq.apache.org/)

- [NSQ Documentation](https://nsq.io/)

- [Superstream — formerly Memphis](https://superstream.ai/)

- [Buf Stream](https://buf.build/product/bufstream)

- [Debezium — CDC platform](https://debezium.io/)

- [Confluent Schema Registry](https://docs.confluent.io/platform/current/schema-registry/index.html)

- [LINE Engineering Blog](https://engineering.linecorp.com/en/blog)

- [Mercari Engineering](https://engineering.mercari.com/en/blog/)

- [ZOZO TECH BLOG](https://techblog.zozo.com/)

- [CyberAgent Developers Blog](https://developers.cyberagent.co.jp/blog/)

- [Toss SLASH conference](https://toss.tech/slash)