Redpanda 26.1: 하나의 클러스터로 네 가지 스트리밍 모드를 선택하는 Adaptable Streaming Engine

요약

스트리밍 인프라를 운영하다 보면 서로 다른 요구사항이 충돌한다. 관측성 파이프라인은 저비용 대규모 처리량을 원하고, 결제 이벤트는 강한 내구성을 요구하며, AI 피처 파이프라인은 빠른 지연을 필요로 한다. 전통적인 해법은 용도별로 별도 클러스터를 구축하는 것이었다.

Redpanda 26.1(2026년 3월 31일 발표)은 이 문제를 다르게 접근한다. "Adaptable Streaming Engine"이라는 이름 아래, 단일 클러스터 안에서 토픽 수준으로 스트리밍 모드를 전환할 수 있는 4가지 옵션을 제공한다.

Write Caching: 디스크 쓰기 없이 인메모리 확인만으로 응답 → 최저 지연
Tiered Storage: 로컬 NVMe 먼저, 이후 오브젝트 스토리지로 자동 이전 → 균형형
Iceberg Topics: Tiered Storage 위에 Apache Iceberg 테이블 뷰 추가 → 제로 ETL 분석
Cloud Topics: 첫 바이트부터 S3/GCS에 직접 쓰기 → 90% 크로스-AZ 네트워크 비용 절감

Redpanda는 Kafka 프로토콜과 호환되므로 기존 프로듀서·컨슈머 코드 변경 없이 토픽 설정 하나로 전환 가능하다.

참고: 이 릴리스는 2026년 3월 31일(발표 기준 약 138일 전)로, 90일 기준 바깥이지만 180일 폴백 윈도 안에 있다. 90일 내에 동등한 아키텍처적 전환을 보여주는 다른 데이터 플랫폼 릴리스가 없어 폴백 정책에 따라 선택했다.

문제: 스트리밍 스프롤

같은 메시징 플랫폼으로 다른 요구사항을 처리할 때의 한계

Kafka 클러스터 하나로 관측성, 트랜잭션 이벤트, 머신러닝 피처 피드를 모두 처리하다 보면 트레이드오프가 충돌한다.

관측성 로그: 수십 TB/일, 단기 보존, 소비자 몇 개, 비용이 가장 중요
결제 이벤트: 낮은 볼륨이지만 데이터 유실은 절대 안 됨, acks=all, 복제본 3개
ML 피처 파이프라인: 빠른 피처 계산을 위해 지연이 낮아야 하지만, 처리 완료 후에는 Iceberg 테이블로 접근해야 함

이 세 워크로드를 단일 클러스터에 넣으면 가장 보수적인 설정(acks=all, 로컬 복제 3개, 높은 IOPS)이 모든 토픽에 적용된다. 클러스터를 분리하면 운영 복잡도가 선형적으로 증가한다.

Redpanda 26.1이 말하는 "Streaming Sprawl"이 이것이다: 요구사항이 늘수록 특수 목적 클러스터가 증식하는 현상.

4가지 스트리밍 모드

Redpanda Adaptable Streaming Engine: 4가지 모드의 내구성·비용·지연 트레이드오프

기술 심화: Cloud Topics 쓰기 경로

Cloud Topics의 핵심은 패스스루 쓰기 모델(pass-through write model)이다. Tiered Storage와 근본적으로 다르다.

Tiered Storage vs Cloud Topics 쓰기 경로

Tiered Storage:

Producer → 브로커 수신 → 로컬 NVMe 쓰기 → ACK 반환
                                  ↓ (비동기, 데이터가 오래되면)
                           S3/GCS로 오프로드

Cloud Topics:

Producer → 브로커 수신 → 메타데이터만 로컬 NVMe → ACK 반환
                  ↓ (동기 pass-through)
           S3/GCS에 페이로드 직접 쓰기

Cloud Topics에서 실제 메시지 페이로드는 로컬 디스크에 쓰이지 않는다. 브로커는 S3나 GCS의 쓰기 API를 직접 호출한다. Raft 합의와 메타데이터 추적은 여전히 로컬 NVMe에서 이루어지지만, 데이터 본체는 오브젝트 스토리지에만 존재한다.

왜 크로스-AZ 비용이 90% 절감되는가

전통적인 Kafka/Redpanda 클러스터는 복제본 3개를 다른 AZ에 분산한다. 10 GB/s 처리량이라면, 원본 1배 + 복제본 2배 = 총 30 GB/s의 데이터가 AZ 간 네트워크를 통과한다. AWS 등 주요 클라우드에서 크로스-AZ 전송 비용은 GB당 유료다.

Cloud Topics에서는 브로커가 S3에 한 번 쓴다. 복제본은 S3 자체의 내구성(11 nines) 메커니즘이 담당한다. 크로스-AZ 복제 트래픽이 사라진다. 10 GB/s 처리량이라면 네트워크 비용이 30 GB/s → 10 GB/s의 1/3이 아니라, S3 직접 쓰기 1회로 줄어 약 90% 절감 주장의 근거가 여기에 있다.

단, 읽기 지연은 증가한다. 소비자가 메시지를 읽을 때 S3에서 가져오는 왕복 시간이 발생한다. 즉각적인 읽기가 필요 없는 AI 학습 데이터 피드, 로그 아카이빙, 배치 관측성 스트림에 적합하다.

기술 심화: Iceberg Topics 분석 경로

Iceberg Topics는 Tiered Storage 위에 Apache Iceberg 테이블 뷰를 자동으로 생성하는 기능이다.

동작 방식

프로듀서가 메시지를 토픽에 보내면 정상적인 Kafka 쓰기처럼 동작한다.
Redpanda는 메시지를 로컬 NVMe에 쓰고 ACK를 반환한다.
백그라운드에서 세그먼트가 S3에 오프로드될 때, Redpanda가 Parquet 포맷으로 변환하고 Iceberg 테이블 메타데이터(manifest, snapshot)를 커밋한다.
Trino, Spark, DuckDB 같은 쿼리 엔진이 해당 S3 버킷을 Iceberg REST 카탈로그로 가리키면 스트리밍 데이터를 SQL로 즉시 쿼리할 수 있다.

ETL 파이프라인 제거

전통적인 구조:

Kafka → Spark Streaming/Flink → S3 Parquet → Iceberg 카탈로그 → Trino 쿼리

Iceberg Topics를 쓰는 구조:

Redpanda → (내장 변환) → S3 Parquet + Iceberg 메타데이터 → Trino 쿼리

별도의 스트리밍 처리 잡 없이 스트리밍 토픽이 곧 Iceberg 테이블이 된다. ML 피처 스토어나 실시간 대시보드 원본으로 쓰는 경우 인프라 복잡도가 크게 줄어든다.

주의 사항: Iceberg Topics는 Tiered Storage가 활성화된 상태에서만 동작한다. 또한 현재 시점에서 Iceberg Topics는 메시지 키와 값의 스키마가 정의된 경우(Avro, Protobuf)에 가장 잘 작동하며, 스키마 없는 바이너리 메시지는 Parquet 변환 시 타입 추론이 제한될 수 있다.

운영 가이드: 어떤 모드를 언제 쓸 것인가

모드 선택 결정 트리

요청 지연 < 1ms가 필수인가?
  └─ YES → Write Caching (단, 프로세스 재시작 시 미확인 메시지 유실 위험 수용)
  └─ NO  → 소비자가 데이터를 즉시 쿼리(SQL)해야 하는가?
              └─ YES → Iceberg Topics (Tiered Storage 선제 활성화 필요)
              └─ NO  → 처리량이 매우 크고(수십 GB/s) 읽기 지연 허용 가능한가?
                          └─ YES → Cloud Topics (크로스-AZ 비용 절감)
                          └─ NO  → Tiered Storage (균형형 기본값)

토픽 수준 설정

# Write Caching (acks=all이지만 디스크 쓰기 없이 인메모리 과반 확인)
rpk topic alter-config my-topic \
  --set write.caching=true

# Tiered Storage 활성화
rpk topic alter-config my-topic \
  --set redpanda.remote.write=true

# Iceberg Topics (Tiered Storage 먼저 활성화 필요)
rpk topic alter-config my-topic \
  --set redpanda.remote.write=true \
  --set redpanda.iceberg.mode=value_schema_id_prefix

# Cloud Topics (오브젝트 스토리지 직접 쓰기)
rpk topic alter-config my-topic \
  --set redpanda.remote.write=true \
  --set redpanda.cloud.storage.enabled=true

주의사항과 한계

Write Caching 내구성 위험: 브로커가 ACK 후 장애나면 인메모리의 미기록 메시지가 유실된다. Exactly-once 시맨틱이 필요한 결제, 주문, 트랜잭션 이벤트에는 사용하면 안 된다.

Cloud Topics 읽기 지연: 소비자의 초기 읽기는 S3에서 데이터를 가져와야 하므로 수십 ms 지연이 발생한다. 고빈도 소비자(초당 수백 번 읽기)에는 부적합하다.

Iceberg Topics 스키마 의존성: Avro/Protobuf Schema Registry 설정 없이는 Parquet 변환 품질이 제한된다. 스키마 없는 레거시 토픽에 즉시 적용하기 전에 데이터 타입 매핑을 먼저 검증하라.

단일 클러스터 내 혼합 운영: 모드가 다른 토픽이 같은 브로커를 공유한다. Cloud Topics 토픽의 S3 쓰기 지연이 로컬 Write Caching 토픽의 브로커 처리를 간접적으로 영향줄 수 있는지 부하 테스트로 확인해야 한다.

스트리밍 플랫폼 선택 관점에서

Redpanda 26.1은 Kafka의 분산 아키텍처를 그대로 유지하면서, 오브젝트 스토리지를 1등 시민으로 만든다는 방향성을 선명히 했다.

Kafka 4.3이 KRaft 정착과 Share Groups 성숙에 집중하는 동안, Redpanda는 오브젝트 스토리지 통합 깊이에서 차별화를 시도하고 있다.
S3를 스트리밍 원본으로 쓰는 패턴은 AWS S3 Express One Zone, Google GCS Rapid 같은 저지연 오브젝트 스토리지 클래스의 등장으로 점점 실용적이 되고 있다.
Iceberg Tables를 스트리밍 출력으로 직접 생성하는 아이디어는 Apache Kafka용 Iceberg Sink Connector 대비 운영 단순성에서 강점이 있다.

요점 정리

Redpanda 26.1 Adaptable Streaming Engine의 핵심 아이디어는 "스트리밍 인프라를 분할하지 말고, 토픽 수준에서 설정을 분리하라"다.

4가지 모드는 스펙트럼을 형성한다. Write Caching은 내구성을 양보하고 지연을 최소화하고, Cloud Topics는 지연을 일부 양보하고 비용을 대폭 줄인다. 중간 단계인 Tiered Storage와 Iceberg Topics는 각각 비용 최적화와 분석 통합이라는 부가 가치를 얹는다.

실용적인 도입 순서는 이렇다. 먼저 현재 클러스터에서 크로스-AZ 네트워크 비용이 큰 비율을 차지하는 관측성/로그 토픽을 Cloud Topics로 전환해 비용 절감을 먼저 확인한다. 다음으로, ETL 파이프라인이 복잡한 분석 토픽에 Iceberg Topics를 시범 적용해 운영 단순화 효과를 측정한다. 이 두 단계를 검증한 후 전사적으로 전환 기준을 수립하면 된다.

References

Redpanda 26.1 블로그 — "Redpanda 26.1 delivers the industry's first adaptable streaming engine": https://www.redpanda.com/blog/26-1-r1-cloud-topics
Redpanda Cloud Topics 공식 문서: https://docs.redpanda.com/streaming/current/develop/manage-topics/config-topics/
Redpanda Iceberg Topics 문서: https://docs.redpanda.com/streaming/current/manage/iceberg/about-iceberg-topics/
BusinessWire 발표 (2026-03-31): https://www.businesswire.com/news/home/20260331750230/en/Redpanda-Streaming-Delivers-Industrys-First-Adaptable-Streaming-Engine
TechTarget — "Redpanda launches streaming engine optimized for AI": https://www.techtarget.com/searchdatamanagement/news/366640882/Redpanda-launches-streaming-engine-optimized-for-AI
Redpanda Cloud Topics 아키텍처 개요: https://www.redpanda.com/data-streaming/cloud-topics-write-to-object-storage