Tansu로 보는 상태 비저장 Kafka 호환 브로커와 레이크하우스 통합

Kafka 호환성은 남기고 브로커 상태를 없앤 설계

Tansu는 100% 안전한 비동기 Rust로 작성된 Kafka 호환 오픈소스 메시지 브로커다. 2026년 QCon London에서 2년간의 개발 결과로 공개됐으며, 리더 없는 스케일-투-제로 구조를 중심에 둔다.

설계의 출발점은 Kafka 프로토콜 호환성을 보존하되, 운영 복잡성을 만드는 복제, 리더 선출, 브로커의 영구 상태를 브로커 밖으로 옮기는 데 있다. 내구성은 외부 스토리지가 담당하고, 브로커는 완전히 상태 비저장으로 동작한다.

Apache 라이선스로 제공되며 단일 바이너리로 배포한다. Python과 Java 등을 포함한 기존 Kafka 클라이언트 라이브러리는 코드 변경 없이 사용할 수 있는 드롭인 호환성을 목표로 한다.

리더를 두지 않는 브로커와 외부 합의 지점

전통 Kafka에서는 파티션별 리더가 읽기와 쓰기를 처리하고, 팔로워가 복제한다. 리더에 장애가 나면 ZooKeeper 또는 KRaft를 통해 새 리더를 선출해야 한다. 클러스터 운영에서 복잡한 지점이 되는 이유다.

⤢✕

Tansu에는 파티션 리더십이 없다. 모든 브로커는 같은 역할을 하며 교체 가능하고, 영구 상태를 저장하지 않는다. 분산 합의는 외부 스토리지의 조건부 쓰기(conditional write)로 처리한다. S3를 사용할 때는 별도 코디네이터 없이 S3의 조건부 쓰기로 경쟁 조건을 해결한다.

그 결과 단일 장애점이 사라진다. 특정 브로커에 장애가 발생해도 다른 브로커가 즉시 역할을 이어받을 수 있다.

유휴 시간에는 브로커를 없앨 수 있는 이유

Tansu 브로커의 레지던트 메모리 사용량은 약 20MB이고, 시작 시간은 약 10밀리초다. 이 경량성이 스케일-투-제로의 기반이다.

전통 Kafka는 브로커를 계속 실행해야 하며, 클러스터 축소에는 파티션 재배치, 리더 재선출, 데이터 이동이 따라온다. 반면 Tansu는 브로커가 상태를 갖지 않으므로 인스턴스를 완전히 제거해도 데이터는 외부 스토리지에 남는다. 트래픽이 없을 때 브로커 수를 0으로 낮추고, 요청이 생기면 10밀리초 내에 다시 시작할 수 있다.

이 방식은 이벤트 드리븐 아키텍처, 클라우드 네이티브 배포, 비용 최적화와 맞닿아 있다. AWS Free Tier의 t3.micro 인스턴스에서 Tansu와 SQLite를 조합해 소규모 프로덕션 워크로드를 운영할 수 있을 정도로 가볍다.

URL로 바꾸는 스토리지 백엔드

스토리지 백엔드는 URL 파라미터 하나로 선택하며, 전환을 위해 코드를 수정할 필요가 없다.

⤢✕

S3와 오브젝트 스토리지는 11-9(99.999999999%) 내구성을 제공하는 클라우드 스토리지를 백엔드로 사용한다. 여러 브로커가 같은 S3 버킷을 공유할 수 있고, AWS S3뿐 아니라 Tigris와 Cloudflare R2 같은 S3 호환 서비스도 지원한다. 디스크 없는 클라우드 네이티브 배포에 적합하지만, 네트워크 지연이 있어 처리량이 높지 않은 경우에 맞는다.

SQLite는 Tansu 바이너리에 직접 포함되는 임베디드 데이터베이스다. 데이터베이스 파일 하나로 환경을 재현하기 쉽고 단일 브로커 배포에서만 사용할 수 있다. 개발 환경에서 테스트 사이의 상태를 초기화해야 할 때 유용하며, 매우 빠른 성능을 제공한다.

PostgreSQL은 여러 브로커가 하나의 데이터베이스를 공유 스토리지로 쓰는 방식이다. 토픽 데이터는 작은 물리적 청크로 파티셔닝된다. SQL로 메시지 데이터에 직접 접근할 수 있어 스트리밍 데이터가 데이터베이스에 바로 착지하는 통합 패턴을 만들 수 있다. produce는 INSERT, fetch는 SELECT가 되므로 트랜잭션 아웃박스 패턴이 불필요해진다.

스키마 검증을 프로듀서 밖으로 옮길 때

전통 Kafka에서는 스키마 검증이 선택적인 클라이언트 측 처리에 머물며, 별도 Schema Registry 인프라가 필요하다. Tansu는 AVRO, JSON, Protocol Buffer 스키마 검증을 브로커 내부에 넣는다.

레코드는 쓰기 전에 검증되고 유효하지 않은 데이터는 브로커 수준에서 거부된다. 클라이언트 구현에 관계없이 데이터 일관성을 유지할 수 있고, 별도 Schema Registry 인프라가 필요 없다는 운영상 이점이 있다.

대신 레코드마다 압축 해제와 검증이 일어나므로 Kafka의 패스스루 방식보다 처리 속도가 느리다. 지원되는 스키마 타입 가운데 Protocol Buffer는 내장된 하위 호환 스키마 변경 메커니즘 때문에 가장 권장된다. Iceberg·Delta Lake 통합에서도 Protocol Buffer 스키마가 최적의 호환성을 제공한다.

메시지 수집과 레이크하우스 적재를 연결하는 싱크 토픽

Tansu의 싱크 토픽(sink topic)은 메시지 브로커가 데이터 레이크하우스 테이블에 직접 쓰도록 구성하는 기능이다.

⤢✕

싱크 토픽으로 설정된 Tansu 토픽은 일반 스토리지를 거치지 않고 Iceberg, Delta Lake, Parquet 같은 오픈 테이블 포맷에 직접 기록한다. 자동 테이블 생성과 프로듀서 스키마 변경에 따른 메타데이터 업데이트도 내장돼 있다. 별도 ETL 프로세스 없이 데이터가 즉시 분석 가능한 컬럼 포맷으로 도착한다.

이는 스트리밍과 배치의 경계를 브로커에서 없애는 접근이다. Kafka Connect나 별도 스트림 프로세서 없이, 프로듀서가 메시지를 전송하는 시점에 분석 가능한 형태로 데이터 레이크에 기록된다. 기존의 Kafka → Kafka Connect → Flink/Spark → 데이터 레이크 흐름은 Kafka 프로토콜 → Tansu → 데이터 레이크로 단순화될 수 있다.

Kafka와 비교해 달라지는 운영 지점

항목	전통 Kafka	Tansu
브로커 상태	로컬 영구 상태	완전 상태 비저장
리더 선출	ZooKeeper / KRaft	없음
복제	내장 복제	외부 스토리지 위임
메모리 사용	수백 MB~GB	~20MB
시작 시간	수십 초	~10ms
스케일-투-제로	불가	가능
스키마 검증	외부 Schema Registry	브로커 내장
데이터 레이크 직접 쓰기	별도 Connector 필요	싱크 토픽으로 내장
스토리지 유연성	로컬 디스크	S3 / SQLite / PostgreSQL
운영 복잡성	높음	낮음
클라이언트 호환성	완전	완전 (동일 프로토콜)

Tansu가 모든 Kafka 배포를 대체하는 것은 아니다. 수백만 TPS의 초고처리량, 서브밀리초 지연이 필요한 환경이나 Kafka Streams·KSQL 같은 Kafka 생태계 도구에 깊이 의존하는 환경에서는 전통 Kafka가 더 적합하다. Tansu의 강점은 운영 단순성, 비용 효율, 데이터 레이크 통합에 있다.

선택이 맞는 운영 환경

이벤트 드리븐 마이크로서비스에서는 스케일-투-제로 덕분에 유휴 시간 비용을 없앨 수 있다. 간헐적인 트래픽 패턴을 가진 서비스에 특히 어울린다.

Iceberg나 Delta Lake로 이벤트 스트림을 직접 적재하려는 팀은 별도 ETL 레이어를 두지 않아도 된다. 파이프라인의 복잡성과 운영 비용을 낮추려는 경우에 유용하다.

개발·테스트 환경에서는 SQLite 스토리지로 완전한 Kafka 호환 브로커를 20MB 메모리로 로컬에서 실행할 수 있다. 테스트 사이의 상태 초기화도 파일 삭제만으로 가능하다.

소규모 프로덕션 배포라면 AWS Free Tier t3.micro 인스턴스에서 SQLite 기반 실제 서비스 운영도 가능하다. 기존 Kafka 클러스터는 최소 3대의 브로커와 ZooKeeper가 필요하지만, Tansu는 단일 인스턴스에서 시작할 수 있다.

PostgreSQL을 공유 스토리지로 선택하면 비즈니스 데이터 변경과 메시지 큐잉을 같은 데이터베이스 트랜잭션에서 원자적으로 처리하는 아웃박스 패턴을 단순화할 수 있다.