Kafka 4.0 KRaft로 설계하는 실시간 ML 피처 스토어 파이프라인

KRaft 전환이 바꾸는 스트리밍 ML 파이프라인

Apache Kafka 4.0은 2025년 3월 ZooKeeper를 완전히 제거하고 KRaft(Kafka Raft Metadata)만 지원하는 최초의 메이저 릴리스로 나왔다. Kafka 3.x에서 ZooKeeper 모드로 운영 중인 클러스터는 4.0으로 직접 업그레이드할 수 없다. 먼저 3.x에서 KRaft 마이그레이션을 끝낸 뒤 4.0으로 넘어가야 한다.

이 전환은 실시간 ML 파이프라인에도 영향을 준다. 스트리밍 피처 집계, 온라인 피처 서빙, 이벤트로 시작되는 AI 추론을 분리된 시스템으로 두기보다 하나의 데이터 흐름으로 묶는 설계가 중심이 된다.

Kafka 안에서 관리되는 클러스터 메타데이터

KRaft는 Kafka가 Raft 합의 알고리즘을 자체 구현해 클러스터 메타데이터를 관리하는 방식이다. 컨트롤러 노드는 내부 토픽인 __cluster_metadata에 메타데이터 변경을 로그로 기록하고, 브로커가 이를 팔로우한다.

ZooKeeper 앙상블을 제거하면서 사례 기반으로 인프라 비용은 약 20% 절감되고, 핀테크 팀 보고에서는 클러스터 셋업 시간이 40% 단축됐다. 메타데이터와 데이터 플레인을 하나의 시스템에서 관리할 수 있으며, 메타데이터 로컬 캐시를 통해 컨트롤러 장애 복구 속도도 높아진다.

Kafka 4.0에서 ML 파이프라인과 직접 맞닿는 기능은 다음과 같다.

기능	내용	ML 파이프라인에서의 연결점
Share Groups (KIP-932)	협력적 소비 패턴과 큐 시맨틱 지원	AI 추론 워크로드 분산 처리
Consumer Rebalance Protocol (KIP-848)	Stop-the-world 리밸런싱 제거	피처 집계 컨슈머 안정성 향상
KRaft 단독 모드	ZooKeeper 완전 제거	운영 단순화와 배포 자동화
Tiered Storage	콜드 데이터 저장소 분리	ML 학습 히스토리 데이터 보존

배치 피처를 스트리밍으로 옮길 때의 경로

배치 중심 ML 파이프라인은 시간 또는 일 단위 스케줄로 피처를 집계해 피처 스토어에 적재한다. 스트리밍으로 옮기면 단순히 처리 엔진만 바뀌는 것이 아니라, 피처 신선도와 추론 레이턴시 요구를 다시 정해야 한다.

초기에는 배치 파이프라인을 유지한 채 스트리밍 레이어를 추가할 수 있다. 모델은 배치 피처를 계속 사용하고, 스트리밍 피처는 보조 신호로 활용한다. 이후 스트리밍 집계 결과를 Redis나 Aerospike 같은 온라인 스토어로 실시간 적재하며, Parquet 또는 Hive 기반의 배치 오프라인 스토어와 병존시킨다. 최종 단계에서는 Flink 또는 Kafka Streams로 피처 변환을 정의하고 배치 잡을 제거하며, 오프라인 스토어는 스트리밍 싱크가 맡는다.

⤢✕

Kafka Streams와 Flink가 갈리는 지점

Kafka Streams와 Apache Flink는 모두 Kafka 기반 스트리밍 처리를 지원하지만 운영 방식과 처리 범위가 다르다.

Kafka Streams는 Kafka 클라이언트 라이브러리 형태로 애플리케이션 안에서 실행된다. 별도 클러스터가 필요 없으므로 운영 부담이 낮다. Kafka 토픽 사이의 단순 변환·필터·집계, 처리량이 MB/s 단위인 소규모 피처 파이프라인, 작은 개발팀, RocksDB 수준의 상태 저장소로 충분한 환경에 맞는다.

Flink는 독립적인 분산 스트리밍 처리 엔진이다. 복잡한 상태 관리와 이벤트 시간(event time) 처리에 강점을 갖는다. 슬라이딩·세션 윈도우 같은 복잡한 윈도우 연산, 수백 MB/s ~ GB/s 처리량, 체크포인트 기반 장애 복구, Flink SQL 기반 피처 정의, PyFlink를 통한 Python ML 모델 직접 통합이 필요할 때 선택 대상이 된다.

비교 항목	Kafka Streams	Apache Flink
배포 방식	애플리케이션 내장	독립 클러스터
상태 관리	RocksDB (로컬)	분산 상태 백엔드
처리량	중간	고성능
레이턴시	수십 ms	수 ms ~ 수십 ms
운영 복잡도	낮음	높음
SQL 지원	ksqlDB (별도)	Flink SQL (내장)
ML 통합	제한적	PyFlink로 직접 통합

Flink가 만든 피처를 온라인 서빙으로 연결하는 방식

Flink와 Kafka를 묶은 온라인 피처 서빙은 2026년 현재 실시간 ML 추론 아키텍처의 표준으로 자리잡고 있다. 기준 레이턴시는 p95 기준 약 280ms, 처리량 12,000 이벤트/초가 베이스라인으로 보고된다.

[Kafka 토픽] → [Flink 스트리밍 잡] → [피처 변환/집계] → [Redis 온라인 스토어]
                                                              ↓
[AI 추론 서비스] ← [피처 룩업 (저레이턴시)] ← [피처 서빙 API]

여기서 핵심은 이중 쓰기 패턴(Dual-Write Pattern)이다. Flink 잡이 변환한 피처를 Redis 기반 온라인 스토어와 Parquet 또는 Iceberg 기반 오프라인 스토어에 함께 기록한다. 실시간 서빙은 온라인 스토어를 사용하고, 배치 학습은 오프라인 데이터를 사용한다.

Feast와 Tecton으로 피처 저장 계층 선택하기

Feast는 2026년 현재 버전 0.10 기준으로 Kafka 스트리밍 소스를 네이티브 지원한다. Feature View에 Kafka 소스를 지정하면 스트리밍 인제스트 파이프라인이 자동 구성된다.

Feast의 오프라인 스토어 선택지는 BigQuery, Redshift, Parquet이며, 온라인 스토어는 Redis, DynamoDB, Bigtable을 사용할 수 있다. Kafka와 Kinesis를 스트리밍 소스로 두고 Python SDK 또는 gRPC API로 피처를 서빙한다. 자체 인프라가 있고 오픈소스의 유연성이 필요하며, 운영 비용보다 커스터마이징을 중시하는 팀에 적합하다.

Tecton은 2025년 Databricks에 인수됐고, 2026년 현재 Databricks 플랫폼과 긴밀히 통합되고 있다. Kafka 또는 Kinesis 토픽을 데이터 소스로 지정하면 내부적으로 Flink 또는 Spark 잡을 자동 프로비저닝한다. Databricks 환경에서 관리형 스트리밍 피처 파이프라인이 필요한 엔터프라이즈에 맞는 선택이다.

비교 항목	Feast	Tecton
라이선스	오픈소스	상용 (Databricks)
스트리밍 지원	Kafka/Kinesis 네이티브	Kafka/Kinesis 자동 프로비저닝
운영 부담	직접 관리	완전 관리형
Databricks 통합	제한적	네이티브
비용	인프라 비용만	라이선스 + 인프라

이벤트가 AI 추론을 시작하는 패턴

이벤트 기반 AI 추론은 Kafka 토픽에 특정 이벤트가 들어왔을 때 ML 모델 추론을 자동으로 시작하는 구조다. 사기 탐지, 실시간 개인화 추천, 공급망 이상 감지에 활용된다.

동기 추론에서는 컨슈머가 이벤트를 받은 뒤 ML 서빙 엔드포인트(REST/gRPC)를 호출하고, 결과를 다시 Kafka에 발행한다. 구조는 단순하지만 서빙 레이턴시가 전체 파이프라인 레이턴시에 직접 반영된다.

비동기 추론은 Flink 잡 안에서 ONNX 또는 TorchScript 모델을 직접 로드해 추론한다. 외부 서빙 서비스가 없어 네트워크 홉을 줄일 수 있으며, PyFlink의 python_udf로 모델을 호출할 수 있다.

사이드카 추론은 Kafka 컨슈머 곁에 Triton 또는 BentoML 모델 서버를 사이드카로 배치한다. 공유 메모리로 통신해 직렬화 비용을 제거하는 방식이다.

피처와 서빙 계층에서 줄이는 추론 지연

피처 집계를 추론 시점이 아니라 이벤트 발생 시점에 수행해 온라인 스토어에 캐싱하면, 조회 경로를 짧게 만들 수 있다. Redis는 p99 레이턴시 1ms 이하 달성이 가능하다.

모델 서빙에서는 INT8/FP16 양자화로 추론 속도를 2~~4배 높이고, 단건 대신 10~~50건의 마이크로 배치를 사용해 GPU 활용률을 높일 수 있다. 빈번히 쓰는 모델은 메모리에 상주시켜 캐싱하고, ONNX 변환으로 프레임워크 독립적 최적화 런타임을 활용한다.

Kafka에서는 linger.ms로 배치 크기와 레이턴시를 조절한다. acks=1과 acks=all의 신뢰성·레이턴시 트레이드오프, 파티션 수와 컨슈머 병렬성의 매칭, 컨슈머 fetch.min.bytes 및 fetch.max.wait.ms 조정도 함께 검토해야 한다.

관리형 스트리밍 서비스와의 비교

Kafka 4.0 외에도 클라우드 네이티브 스트리밍 서비스는 ML 파이프라인의 구성 요소가 된다.

비교 항목	Kafka 4.0	AWS Kinesis	GCP Pub/Sub	Azure Event Hubs
운영 모델	셀프 관리 / Confluent Cloud	완전 관리형	완전 관리형	완전 관리형
메시지 보존	무제한 (설정 기반)	24시간~365일	7일 (기본)	90일 (최대)
지연시간	수 ms	수십 ms	수십 ms	수십 ms
멀티클라우드	최적 (클라이언트 호환)	AWS 종속	GCP 종속	Azure 종속
ML 프레임워크	Flink, Spark, Kafka Streams	Kinesis Analytics	Dataflow	Stream Analytics
피처 스토어 연동	Feast, Tecton 네이티브	SageMaker Feature Store	Vertex AI Feature Store	Azure ML Feature Store
비용 구조	인프라 비용	샤드 시간당 요금	메시지 건당 요금	처리량 단위 요금

멀티클라우드 환경에서 높은 처리량과 무제한 보존이 필요한 경우 Kafka 4.0이 맞는다. AWS 단일 클라우드에서 소~중규모 인제스트 → S3 파이프라인을 구성한다면 Kinesis, GCP에서 Vertex AI 통합 ML 파이프라인을 운영한다면 Pub/Sub, Azure에서 Kafka 프로토콜 호환 마이그레이션이 필요하다면 Event Hubs가 선택지가 된다.

멀티리전 액티브-액티브 스트리밍이 필요하거나 처리량이 5~10 MB/s를 초과하는 경우 Kafka가 가장 강력한 선택지로 평가된다.

Lambda와 Kappa 관점에서 보는 피처 파이프라인

빅데이터 아키텍처에서는 Lambda와 Kappa의 구분이 스트리밍 피처 설계를 이해하는 기준이 된다.

Lambda 아키텍처는 배치 레이어(Spark), 스피드 레이어(Kafka/Flink), 서빙 레이어를 함께 둔다. 복잡도는 높지만 재처리 유연성이 좋다.

Kappa 아키텍처는 스트리밍 레이어로 배치와 실시간 처리를 함께 수행한다. Kafka의 무제한 보존과 재생 기능을 이용해 Lambda의 이중 파이프라인 복잡도를 줄인다. 2026년 현재 ML 피처 파이프라인에서는 Kappa가 더 선호되는 추세다.

이 구조를 설계할 때는 KRaft의 Raft 합의 알고리즘, 온라인·오프라인 이중 스토어 패턴, 이벤트 소싱과 CQRS의 스트리밍 적용, 정확히 한 번(Exactly-Once) 시맨틱 구현 원리를 함께 봐야 한다.

스트리밍 ML 파이프라인이 향하는 곳

Flink SQL과 ksqlDB 같은 SQL 인터페이스는 피처 정의를 SQL로 옮기고, 엔진이 스트리밍과 배치 실행을 자동 선택하는 방향으로 가고 있다. 이는 오프라인·온라인 분리에 드는 비용을 낮춘다.

임베딩 벡터를 실시간 생성·저장해 RAG(Retrieval-Augmented Generation) 파이프라인과 결합하는 벡터 피처 스토어도 확산되고 있다. Kafka → Flink → 벡터 DB(Qdrant/Weaviate) 패턴이 그 예다.

IoT와 엣지 디바이스가 Kafka 클라이언트로 이벤트를 직접 발행하고, 클라우드 Flink가 ML 추론 결과를 에지로 되돌려 보내는 양방향 스트리밍 아키텍처도 넓어지고 있다. LLM 추론 결과를 Kafka 토픽으로 발행해 다운스트림 서비스가 소비하는 GenAI 통합 패턴과, Confluent Cloud·WarpStream 같은 서버리스 Kafka 서비스의 성숙 역시 이 흐름에 포함된다.

Kafka 4.0의 KRaft 전환은 스트리밍 ML 운영 복잡도를 낮추는 분기점이다. Flink와 연결하면 실시간 피처 집계와 AI 추론 트리거를 하나의 파이프라인으로 구성할 수 있고, Feast와 Tecton은 온라인·오프라인 이중 쓰기에서 발생하는 복잡도를 추상화한다. Kafka는 멀티클라우드 이식성과 무제한 보존을 바탕으로 대규모 실시간 AI 데이터 파이프라인의 핵심 인프라로 자리매김하고 있다.