Kafka의 디스크는 어디로 가고 있나: Object Storage로 옮겨지는 Streaming Storage

Kafka를 클라우드에서 크게 운영하다 보면 storage가 단순한 구현 세부사항이 아니라 비용과 운영성을 좌우하는 설계 축이 됩니다.

전통적인 Kafka는 broker가 partition replica의 local log를 갖고, replication으로 durability를 만듭니다. 이 모델은 강력하고 익숙합니다. 하지만 cloud block storage, cross-AZ replication, broker replacement, partition reassignment, long retention이 겹치면 비용과 운영 부담이 급격히 커집니다.

그래서 최근 Kafka 생태계에는 비슷한 질문이 반복해서 등장합니다.

Kafka protocol과 ecosystem은 유지하면서,
durable storage는 broker-local disk 밖으로 뺄 수 없을까?

WarpStream, AutoMQ, Apache Fluss, 그리고 Apache Kafka의 KIP-1150 Diskless Topics는 모두 이 질문 주변에 있습니다. 하지만 같은 답은 아닙니다.

먼저 가져갈 결론

바쁘다면 이 정도로 정리할 수 있습니다.

• object storage를 쓴다고 모두 같은 architecture는 아닙니다.
• Kafka Tiered Storage는 주로 오래된 segment를 remote tier로 보내는 모델입니다.
• WarpStream과 AutoMQ는 Kafka-compatible interface를 유지하면서 storage layer를 object storage 중심으로 다시 설계한 쪽에 가깝습니다.
• Apache Fluss는 Kafka replacement라기보다 Flink/lakehouse를 겨냥한 lakehouse-native streaming storage입니다. Kafka protocol compatibility는 문서상 아직 개발 중입니다.
• KIP-1150 Diskless Topics는 Apache Kafka community가 diskless 방향을 받아들였다는 중요한 신호지만, 그 자체가 완성된 production feature는 아닙니다.

이 흐름의 핵심은 “Kafka가 S3에 저장할 수 있느냐”보다 “streaming system에서 broker가 얼마나 많은 durable state를 직접 소유해야 하느냐”입니다.

왜 지금 이런 움직임이 커졌나

이 변화는 단순히 “S3가 싸니까”만으로 설명하기 어렵습니다. 여러 압력이 동시에 커졌습니다.

첫 번째는 cloud cost입니다. Kafka는 data를 오래 보관하고 여러 zone에 복제할수록 block storage와 network 비용이 함께 커집니다. 특히 cross-AZ replication traffic은 cloud Kafka 운영비에서 눈에 잘 띄지 않다가 규모가 커질수록 큰 비중을 차지합니다.

두 번째는 elasticity입니다. Kubernetes와 cloud autoscaling에 익숙한 팀에게 “broker를 줄이려면 partition reassignment를 오래 기다려야 한다”는 모델은 점점 어색해졌습니다. compute는 빨리 늘리고 줄이고 싶은데, broker가 가진 local data가 그 움직임을 붙잡습니다.

세 번째는 Kafka protocol의 네트워크 효과입니다. Kafka client, Connect, Streams, Schema Registry, 운영 도구, 조직의 개발 습관은 쉽게 바뀌지 않습니다. 그래서 새 시스템들은 “Kafka를 버리자”보다 “Kafka protocol은 유지하되 storage layer를 바꾸자”는 방향을 택합니다.

네 번째는 object storage의 성숙입니다. S3 같은 object storage는 이미 lakehouse, backup, analytics, ML pipeline의 기본 저장소가 되었습니다. 비용과 durability는 매력적이고, throughput도 충분히 커졌습니다. 남은 문제는 Kafka의 append/fetch semantics에 맞게 latency, ordering, metadata, cache, failure recovery를 설계하는 일입니다.

마지막으로 lakehouse와 AI workload가 streaming storage를 다르게 요구하기 시작했습니다. 실시간 이벤트는 Kafka에 있고, 장기 분석과 학습 데이터는 Iceberg/Paimon 같은 lakehouse에 있습니다. 두 세계를 계속 connector와 복제 파이프라인으로만 이어 붙이면 비용, freshness, governance가 흔들립니다. Fluss 같은 시도는 이 지점에서 stream과 table 사이의 간격을 줄이려 합니다.

정리하면, 지금의 움직임은 Kafka가 갑자기 낡아서가 아닙니다. Kafka protocol은 너무 성공했기 때문에 유지하고 싶고, broker-local storage model은 cloud economics와 lakehouse 시대의 요구를 모두 만족시키기 어려워졌기 때문입니다.

먼저 사실관계부터 정리하기

몇 가지 최근 사건은 이 흐름이 단순한 실험이 아니라 시장과 upstream Kafka 모두에서 중요해졌다는 신호입니다.

Confluent는 2024년 9월 9일 WarpStream 인수를 발표했습니다. 공식 발표에서 WarpStream은 Apache Kafka-compatible data streaming platform으로 소개되었고, BYOC 환경에서 대규모이면서 latency 요구가 상대적으로 느슨한 logging, observability, data lake feeding 같은 workload에 적합하다고 설명되었습니다.

IBM은 2026년 3월 17일 Confluent 인수 완료를 발표했습니다. 2025년 12월 “인수 예정”이 아니라, 2026년 6월 현재는 “완료”가 맞습니다.

Apache Kafka 쪽에서는 KIP-1150: Diskless Topics가 Accepted 상태입니다. 이 KIP는 Diskless Topics의 방향과 요구사항을 잡는 umbrella 성격의 KIP입니다. 세부 public interface나 구현은 follow-up KIP에서 다뤄질 예정입니다.

Apache Fluss는 공식 사이트에서 lakehouse-native streaming storage로 소개됩니다. message broker, online KV store, stream-processing state backend, lakehouse cold store를 하나의 foundation으로 묶겠다는 방향입니다. Fluss 문서에는 Kafka protocol compatibility가 있지만, configuration 문서에서는 아직 개발 중이며 기본값은 disabled라고 명시되어 있습니다.

왜 local disk가 부담이 되나

Kafka의 기본 storage model은 broker-local log입니다.

producer
  -> leader broker local log
  -> follower broker local logs
  -> consumer fetch

이 모델은 데이터센터와 commodity hardware 맥락에서 매우 잘 맞았습니다. broker가 가진 disk가 곧 partition replica이고, ISR replication이 durability와 availability를 만듭니다.

클라우드에서도 이 모델은 여전히 잘 동작합니다. 문제는 비용과 탄력성입니다.

• replication traffic이 zone을 넘으면 네트워크 비용이 커집니다.
• EBS 같은 block storage 비용과 Kafka replication 비용이 겹칩니다.
• broker를 줄이거나 바꾸려면 partition data movement가 필요합니다.
• long retention을 위해 broker disk를 크게 잡으면 compute와 storage가 함께 커집니다.
• consumer backfill이나 replay가 serving broker bandwidth를 잡아먹을 수 있습니다.

그래서 object storage가 매력적으로 보입니다. S3 같은 object storage는 durability, capacity elasticity, pay-as-you-go 측면에서 좋습니다. 다만 Kafka log를 그냥 S3 object로 바꾼다고 끝나지는 않습니다.

Kafka는 append order, fetch latency, offset, transactions, consumer group, compaction, retention, failure recovery를 모두 맞춰야 합니다. object storage는 durable하지만, write latency와 IOPS 특성이 local disk와 다릅니다. 그래서 진짜 질문은 “S3에 저장할 수 있나”가 아니라 “Kafka semantics를 유지하면서 object storage의 약점을 어떻게 가릴 것인가”입니다.

네 가지 패턴을 구분해서 보기

Object storage와 Kafka가 만나는 방식은 크게 네 가지로 나눠볼 수 있습니다.

패턴	object storage의 위치	의미
export sink	Kafka 밖 downstream	Kafka topic을 lake로 복제하거나 적재합니다.
tiered storage	오래된 segment의 remote tier	active write path는 여전히 broker-local log 중심입니다.
shared/diskless storage	durable stream layer	broker-local disk의 역할을 크게 줄이고 object storage를 primary durability path에 넣습니다.
streaming lakehouse	stream과 table storage의 통합	Kafka transport보다 analytics, table, state, lakehouse 통합을 더 크게 봅니다.

이 구분이 중요합니다. “Kafka data가 S3에도 있다”와 “Kafka의 active durable storage가 S3 중심이다”는 다릅니다.

Tiered Storage는 classic Kafka에 자연스럽게 붙는 확장입니다. 오래된 segment를 remote tier로 보내 retention 비용을 낮추고 broker disk pressure를 줄입니다. 하지만 active segment와 ISR replication의 기본 구조는 크게 바뀌지 않습니다.

WarpStream이나 AutoMQ 같은 shared-storage 계열은 더 과감합니다. Kafka-compatible API를 제공하되, broker-local disk를 durable source of truth로 두는 모델을 벗어나려 합니다.

Fluss는 또 다릅니다. Fluss는 Kafka-compatible protocol을 목표로 하지만, 프로젝트의 중심은 Kafka broker replacement보다 Flink와 lakehouse를 위한 streaming storage substrate에 가깝습니다.

WarpStream: Kafka-compatible, object-storage-first BYOC

WarpStream은 “brokerless” 또는 “diskless” Kafka-compatible platform으로 알려졌습니다. 운영 관점에서 매력적인 지점은 compute agent를 stateless에 가깝게 두고, customer cloud의 object storage를 durable layer로 사용하는 방향입니다.

Confluent의 인수 발표는 이 방향의 시장 신호로 볼 수 있습니다. Confluent는 이미 fully managed Confluent Cloud와 self-managed Confluent Platform을 갖고 있었고, WarpStream을 BYOC 선택지로 추가했습니다. 발표문에서도 WarpStream이 high-scale workload 중 relaxed latency requirement를 가진 logging, observability, data lake feeding에 적합하다고 설명합니다.

여기서 “relaxed latency”라는 단어가 중요합니다. Diskless/shared-storage architecture는 비용과 elasticity에서 매력적이지만, 모든 workload에 더 빠른 모델은 아닙니다. 특히 low-latency transactional event flow와 high-throughput observability pipeline은 다른 기준으로 봐야 합니다.

AutoMQ: Kafka storage layer를 S3Stream으로 바꾸는 접근

AutoMQ는 자신을 Kafka-compatible shared storage architecture로 설명합니다. 공식 architecture 문서에서는 Kafka의 storage layer를 cloud storage로 offload하여 broker를 stateless하게 만들고, WAL storage와 object storage를 함께 사용한다고 설명합니다.

핵심은 이 조합입니다.

Kafka protocol-facing broker
  -> WAL / cache layer
  -> S3-compatible object storage

Object storage만으로는 Kafka write path의 latency와 IOPS 요구를 그대로 만족하기 어렵습니다. 그래서 AutoMQ는 WAL storage layer를 둬 write efficiency를 높이고, data를 near real-time으로 object storage에 저장하는 식으로 설명합니다.

이 모델의 매력은 scale-out, scale-in, partition reassignment를 data movement 문제가 아니라 metadata 중심 문제로 바꾸려는 데 있습니다. 하지만 그만큼 storage engine, WAL durability, metadata coordination, cache miss behavior, object layout, failure recovery를 모두 새로 신뢰해야 합니다.

Apache Fluss: 비슷한 방향이지만 같은 문제를 푸는 것은 아니다

사용자 질문에서 가장 조심해야 할 부분이 Fluss입니다.

“Apache Fluss도 Kafka protocol을 지원하면서 AutoMQ와 유사한 저장 모델을 쓰나?”라고 물으면, 제 답은 “일부 닮은 지점은 있지만 같은 분류로 묶으면 오해가 생긴다”입니다.

Fluss의 공식 포지셔닝은 Apache Kafka replacement가 아니라 lakehouse-native streaming storage입니다. Fluss는 message broker, online KV store, stream-processing state backend, lakehouse cold store를 하나로 묶는 방향을 말합니다. architecture 설명에서도 Coordinator Server, Tablet Server, hot tier, Tiering Service, Paimon/Iceberg/Lance 같은 lakehouse cold tier가 중심에 있습니다.

또한 Fluss의 configuration 문서에는 Kafka protocol compatibility가 아직 개발 중이라고 표시되어 있고, kafka.enabled 기본값도 false입니다. 따라서 2026년 6월 현재 기준으로 “Kafka client를 그대로 붙이면 AutoMQ처럼 Kafka-compatible shared-storage cluster로 쓴다”고 말하기는 이릅니다.

다만 비슷한 흐름은 있습니다.

• broker/log 중심 시스템을 storage substrate 관점에서 다시 봅니다.
• local disk 하나만이 아니라 remote object storage와 lakehouse tier를 설계에 넣습니다.
• replay/backfill/analytics read path를 serving node와 분리하려 합니다.
• Kafka protocol compatibility를 migration 또는 ecosystem 연결 포인트로 봅니다.

즉 AutoMQ가 “Kafka protocol을 유지하고 storage layer를 바꾸자”에 가깝다면, Fluss는 “stream과 table을 함께 다루는 storage substrate를 만들고 Kafka/Flink/lakehouse ecosystem과 연결하자”에 더 가깝습니다.

KIP-1150: upstream Kafka도 방향을 인정했다

KIP-1150 Diskless Topics가 Accepted 상태가 된 것은 중요한 사건입니다. Kafka community가 object storage를 inactive segment archive 이상의 대상으로 보기 시작했다는 뜻이기 때문입니다.

KIP-1150의 motivation은 분명합니다. Kafka protocol은 성공적인 기반이 되었지만, Apache Kafka implementation은 low-durability block storage와 direct replication을 중심으로 설계되었습니다. 반면 cloud hyperscaler 환경에서는 high-reliability object storage가 있고, equivalent workload에서 block storage보다 cost-effective할 수 있습니다.

KIP-1150은 기존 topic을 없애자는 제안이 아닙니다. per-topic 선택에 가깝습니다. 기존 low-latency topic은 여전히 필요하고, diskless topic은 latency와 cost tradeoff가 다른 topic type입니다.

또 하나 중요한 점은 compatibility 목표입니다. KIP는 Diskless Topics가 기존 Kafka API와 external semantics를 유지하는 방향을 말합니다. ordering, idempotency, transactions, consumer groups, share groups, tiered storage 같은 항목을 의미적으로 교환 가능하게 만들겠다는 목표입니다.

하지만 Accepted는 GA가 아닙니다. KIP-1150 자체는 새 public interface를 제안하지 않고, 세부 사항은 sub-KIP에서 다룬다고 되어 있습니다. 운영자가 지금 판단해야 하는 것은 “Kafka 4.x에 Diskless Topics를 켜면 된다”가 아니라 “upstream Kafka도 diskless 방향을 공식 roadmap으로 받아들였다”입니다.

적용 기준: 무엇을 어디에 써야 하나

이 흐름을 선택할 때는 기술 이름보다 workload를 먼저 봐야 합니다.

workload	먼저 볼 모델
low-latency event processing	classic Kafka, carefully tuned broker storage
long retention with occasional replay	Kafka Tiered Storage
observability/logging/data lake feeding at high volume	shared-storage Kafka-compatible systems, WarpStream-like BYOC
Kafka compatibility plus cloud elasticity	AutoMQ-like shared storage architecture
Flink 중심 real-time analytics와 lakehouse 통합	Apache Fluss 같은 streaming lakehouse storage
upstream Kafka 표준 방향 추적	KIP-1150 Diskless Topics and follow-up KIPs

여기서 중요한 판단 기준은 latency입니다. object storage 중심 모델은 cost와 elasticity를 주지만, hot path latency와 tail behavior는 반드시 따로 봐야 합니다.

두 번째 기준은 ownership입니다. 운영팀이 Kafka semantics는 그대로 기대하면서 완전히 다른 storage engine을 받아들일 준비가 되어 있는지 봐야 합니다.

세 번째 기준은 observability입니다. broker disk가 source of truth였던 시절에는 disk usage, under-replicated partitions, ISR, flush, page cache를 봤습니다. shared storage 모델에서는 WAL pressure, object upload latency, cache hit ratio, remote fetch latency, metadata coordinator 상태, object store error budget이 같이 중요해집니다.

Kafka storage를 object storage로 옮기는 흐름은 결국 운영 신호를 새로 읽는 문제이기도 합니다. Konduo는 Kafka 같은 클러스터형 리소스를 플러그인으로 연결해 broker, topic, consumer group, metric evidence, alert response를 하나의 운영 흐름에서 확인할 수 있도록 설계된 통합 관리 운영 플랫폼입니다.

체크리스트

새로운 storage 모델을 검토할 때는 다음 질문을 먼저 던지는 편이 좋습니다.

• 이 workload는 p99 latency에 민감한가, 아니면 처리량과 비용이 더 중요한가?
• producer와 consumer가 cross-AZ traffic 비용을 얼마나 만들고 있는가?
• retention 때문에 broker disk를 과하게 잡고 있지는 않은가?
• replay와 backfill이 serving broker를 방해하고 있지는 않은가?
• partition reassignment 시간이 운영 병목인가?
• Kafka protocol compatibility만 필요한가, Kafka implementation semantics까지 그대로 필요한가?
• object store outage, throttling, eventual consistency, request cost를 어떻게 관측할 것인가?
• WAL이나 cache layer가 생긴다면 그 계층의 durability와 failure mode를 이해하고 있는가?
• compacted topics, transactions, exactly-once, ACL, quotas, Connect, Streams workload가 같은 방식으로 동작하는지 검증했는가?
• upstream Kafka의 KIP-1150을 기다릴 것인지, Kafka-compatible alternative를 먼저 실험할 것인지 결정했는가?

제 기준은 이렇습니다.

Object storage는 Kafka storage의 미래 중 하나가 맞다.
하지만 "S3를 쓴다"는 말만으로 architecture를 판단하면 안 된다.

WarpStream, AutoMQ, Fluss, KIP-1150은 모두 Kafka 이후의 streaming storage를 상상하게 만듭니다. 다만 어떤 것은 Kafka-compatible broker의 storage layer를 바꾸고, 어떤 것은 lakehouse-native streaming substrate를 만들고, 어떤 것은 upstream Kafka의 future direction을 정의합니다.

이 차이를 구분해야 다음 질문을 제대로 할 수 있습니다.

우리는 Kafka를 더 싸게 운영하고 싶은가?
더 쉽게 늘리고 줄이고 싶은가?
stream과 lakehouse를 하나로 읽고 싶은가?
아니면 upstream Kafka 표준 안에서 기다릴 것인가?

디스크가 사라지는 것이 핵심이 아닙니다. 핵심은 durable stream의 소유권이 어디로 이동하고, 그 이동이 우리 workload의 비용, 지연, 복구, 관측 방식을 어떻게 바꾸는가입니다.

함께 읽기 좋은 글

이 글의 관점과 이어지는 주제를 더 보려면 아래 글도 함께 읽어볼 수 있습니다.

• Kafka가 잘하는 대용량과 보내면 안 되는 대용량 - 큰 payload를 Kafka로 직접 보낼 때 생기는 비용을 설명합니다.
• Kafka는 메모리가 남아 있는데 왜 OOM이 났을까 - heap 밖 direct buffer까지 포함해 Kafka broker 메모리를 다시 봅니다.
• Kafka Broker가 느려졌지만 Kafka가 원인은 아니었다 - Kafka 증상 뒤에 숨어 있던 storage path와 I/O 문제를 추적합니다.