Redpanda 26.1: R1 엔진 완성 — Cloud Topics·Iceberg Topics·계층 스토리지가 하나의 클러스터에서 동작하는 방식

왜 지금 봐야 하나

출처 시점 안내: Redpanda 26.1은 2026년 3월 출시됐다. 현재 시점(2026년 7월 30일)으로부터 약 152일 전으로 90일 기준을 넘지만, 180일 범위에 해당한다. 같은 기간 내 Kafka API 호환 스트리밍 엔진에서 이에 상당하는 아키텍처 변화가 없어 이 릴리스를 선택했다.

Kafka API 호환 스트리밍 플랫폼에서 운영자가 오래 겪어온 문제가 있다. 워크로드마다 클러스터가 따로 필요하다는 것이다. 저지연 OLTP 이벤트는 로컬 디스크 기반 클러스터에, 대용량 텔레메트리는 티어드 스토리지 클러스터에, 분석 쿼리는 Iceberg 익스포트 파이프라인이 붙은 별도 클러스터에 올린다. 클러스터 세 개, 보안 정책 세 벌, 모니터링 설정 세 벌이다.

Redpanda 26.1이 이 구조를 바꾼다. R1(Redpanda One) 아키텍처가 완성됐다. 하나의 클러스터 안에서 토픽마다 스토리지 프로필을 독립적으로 설정한다. 같은 Kafka API, 같은 보안 모델, 같은 rpk 명령으로 네 가지 스토리지 모드를 운영한다.

R1 이전: 클러스터 분산의 비용

"클러스터 동물원" 문제

각 클러스터에는 독립적인 인증 설정, 복제 계수 설정, 리텐션 정책, 알림 임계값이 필요하다. 팀이 늘어날수록 클러스터 수가 늘고, 운영 복잡도가 선형이 아닌 지수로 증가한다.

R1 아키텍처: 네 가지 스토리지 모드

R1은 하나의 클러스터 안에서 토픽 레벨로 스토리지 프로필을 선택하는 구조다. 네 가지 모드가 있다.

네 가지 모드 비교

Iceberg Topics는 독립적인 모드가 아니라 Tiered Storage 위에 Parquet 변환을 자동으로 올린 설정이다.

Cloud Topics: 로컬 디스크 없이 S3에 직접 쓰기

Cloud Topics는 R1의 최종 퍼즐 조각이다. 26.1 이전에는 Tiered Storage가 로컬 디스크를 캐시로 사용하면서 S3에 콜드 데이터를 내리는 방식이었다. Cloud Topics는 로컬 디스크 자체를 제거한다.

작동 원리

1. 프로듀서가 Kafka API로 메시지를 쓴다.
2. Redpanda 브로커가 메시지를 직접 S3(또는 ADLS, GCS)에 기록한다.
3. 컨슈머는 S3에서 직접 읽는다. 브로커는 메타데이터와 버퍼 역할만 한다.

로컬 디스크가 없으므로 교차 가용 영역(cross-AZ) 복제 트래픽이 90% 이상 감소한다. 기존 Tiered Storage에서는 로컬 복제본이 AZ를 넘나들었지만, Cloud Topics에서는 S3 자체의 내구성(99.999999999%)에 의존한다.

적합한 워크로드

Cloud Topics는 지연 요구사항이 낮은(수십~수백 ms 허용) 고처리량 워크로드에 맞다.

• 관측성 스트림 (로그, 메트릭, 트레이스)
• AI/ML 훈련 데이터 파이프라인
• 분석 파이프라인
• 아카이브 목적 데이터 수집

적합하지 않은 경우: OLTP 이벤트 처리, 결제 트랜잭션 스트림처럼 한 자릿수 ms 지연이 필요한 워크로드.

Iceberg Topics: 스트림을 레이크하우스로 직접 연결

Iceberg Topics는 Kafka 스트림과 Apache Iceberg 레이크하우스 사이의 ETL 파이프라인을 제거한다.

기존 방식의 복잡성

기존에는 Kafka 토픽 데이터를 분석 쿼리에 사용하려면:

Kafka 토픽 → Kafka Connect (또는 Spark Streaming) → Parquet 변환 → S3 저장 → Iceberg 테이블 등록 → 쿼리 엔진

각 단계마다 지연이 추가되고, 스키마 진화 처리와 파티셔닝 설계가 별도 작업이 된다.

Iceberg Topics의 작동 방식

Iceberg Topics를 활성화하면 Redpanda가 Tiered Storage 위에서 Parquet 파일을 직접 생성하고 Iceberg 메타데이터를 유지한다.

Kafka 프로듀서 → Redpanda Iceberg Topic → S3 (Parquet + Iceberg 메타데이터)
                                              ↓
                                   Trino / Spark / Athena 직접 쿼리

• AWS Glue Data Catalog 연동: BYOC 클러스터에서 Redpanda 토픽이 Glue 카탈로그에 Iceberg 테이블로 자동 등록된다.
• 스키마 진화: Redpanda Schema Registry와 연동해 스키마 변경이 Iceberg 테이블 메타데이터에 반영된다.
• 파티셔닝: 이벤트 타임스탬프 기반 파티셔닝이 자동 적용된다.

보안: GBAC와 FIPS 140-3

그룹 기반 접근 제어 (GBAC)

26.1은 OIDC 통합을 확장했다. 기존에는 OIDC 토큰으로 사용자를 인증하되 권한은 개별 사용자에게 직접 부여했다. GBAC는 OIDC 공급자가 반환하는 그룹에 직접 권한을 부여한다.

예: sre-team 그룹에 metrics-* 토픽 읽기 권한을 부여하면, OIDC에서 해당 그룹 멤버로 인식되는 모든 사용자에게 자동으로 권한이 적용된다. 팀 구성원이 바뀌어도 Redpanda 권한 정책을 수정하지 않아도 된다.

v26.1.7 이상부터 rpk도 OAUTHBEARER SASL을 지원해 OIDC 액세스 토큰으로 CLI 인증이 가능하다.

FIPS 140-3

암호화 모듈이 FIPS 140-2에서 FIPS 140-3으로 업그레이드됐다. FIPS 전용 Docker 이미지(amd64/arm64)가 제공된다. 미국 연방 규정 준수나 금융·의료 업종의 보안 요구사항을 만족해야 하는 경우 26.1 이상으로 업그레이드하면 FIPS 140-3 인증을 자동으로 상속받는다.

업그레이드와 운영 고려사항

스토리지 모드 전환의 제약

토픽을 생성한 뒤 스토리지 모드를 변경하는 것에는 제약이 있다. Tiered Storage를 켠 토픽을 나중에 끄는 것은 지원되지 않는다. Cloud Topics로 생성한 토픽을 Standard Topics로 변경하는 것도 불가능하다. 모드는 토픽 생성 시 결정해야 한다.

Cloud Topics 사용 전 확인 사항

Iceberg Topics 스키마 설계

Iceberg Topics를 사용할 때 Avro 또는 Protobuf 스키마를 Schema Registry에 등록해야 Parquet 컬럼 타입이 올바르게 매핑된다. JSON 스키마도 지원하지만 타입 추론이 덜 엄격하다.

Open Questions

• Cloud Topics의 정확한 지연 p50/p99 벤치마크 수치는 Redpanda 공식 문서에서 확인하기 전까지 불확실하다.
• Self-managed 배포에서 Iceberg Topics의 카탈로그 통합(Polaris, HMS 등)은 별도 확인이 필요하다.

References

• Redpanda 26.1: The R1 vision delivered (Redpanda Blog)
• About Cloud Topics (Redpanda Docs)
• About Iceberg Topics — Redpanda Streaming
• Redpanda 26.1 R1 Adaptable Streaming Engine (BigDATAwire/HPC Wire)
• v26.1.1 Discussion Notes (GitHub redpanda-data/redpanda)
• What's New in Redpanda Streaming