카파 아키텍처: 배치 계층 없이 스트림 하나로 처리하기
람다 아키텍처의 배치 계층을 없애고 단일 스트림 파이프라인으로 실시간 처리와 재처리를 모두 감당하는 카파 아키텍처의 구조와 트레이드오프를 정리한다.
2026-08-13 · 최초 발행 2025-05-23
배치 계층 없이 스트림 하나로 처리한다는 발상
카파 아키텍처(Kappa Architecture)는 람다 아키텍처(Lambda Architecture)의 대안으로 제안된 빅데이터 처리 패턴이다. 2014년 LinkedIn의 Jay Kreps가 "Questioning the Lambda Architecture"라는 블로그 포스트에서 처음 제시했다. 단일 스트림 처리 파이프라인만으로 실시간 데이터 처리와 배치 처리를 모두 처리해, 데이터 처리 복잡성을 줄이고 유지보수성을 높이는 것이 목표다. 카파(κ)는 그리스 알파벳에서 람다(λ) 다음에 오는 문자로, 람다 아키텍처의 다음 진화 단계를 상징한다.
람다 아키텍처가 부딪힌 문제
람다 아키텍처는 배치 계층과 스피드 계층으로 구성된 이중 파이프라인 구조다. 두 계층에서 동일한 로직을 중복 구현해야 해서 유지보수 복잡성이 늘고, 두 처리 결과의 일관성을 유지하기도 어렵다. 배치 처리 시스템과 실시간 처리 시스템을 모두 관리해야 하는 운영 부담도 뒤따른다.
카파가 택한 방식
모든 데이터를 이벤트로 모델링해 단일 스트림 처리 시스템에서 처리한다. 이벤트 로그를 영구적으로 저장하고 재생 가능한 로그 시스템(예: Apache Kafka)을 활용해, 데이터 처리 로직을 한 번만 구현하고 필요할 때 전체 데이터를 재처리한다. 스트림 처리 엔진이 실시간 데이터와 과거 데이터를 모두 처리하고, 처리 결과는 상태 저장소(State Store)에 저장돼 쿼리를 지원한다.
이벤트 로그·스트림 엔진·상태 저장소가 나누는 역할
**이벤트 로그(Event Log)**는 모든 원시 데이터를 시간 순서대로 저장하는 변경 불가능한(immutable) 로그다. 분산 메시징 시스템 겸 로그 저장소로 Apache Kafka가 주로 쓰이며, 내구성 있고 확장 가능한 장기 데이터 저장소 역할을 한다. 과거 특정 시점부터 데이터를 재생할 수 있고, 데이터 복제와 파티셔닝으로 고가용성을 보장한다.
**스트림 처리 엔진(Stream Processing Engine)**은 이벤트 로그에서 데이터를 소비해 실시간으로 처리한다. Apache Flink, Apache Spark Streaming, Kafka Streams 등을 활용해 필터링·집계·변환·조인 같은 연산을 수행하고, 상태 기반 처리(stateful processing)로 시간 윈도우 집계를 지원한다. 내결함성 처리와 정확히 한 번(exactly-once) 처리를 보장한다.
**상태 저장소(State Store)**는 처리된 결과를 저장하는 데이터베이스 또는 저장소다. NoSQL, 관계형 DB, 인메모리 저장소 등 다양한 시스템을 쓸 수 있고, 실시간 대시보드·API·애플리케이션에 데이터를 서빙한다. 필요하면 전체 데이터를 재처리해 상태를 다시 구성할 수 있다.
추천 시스템과 이상 탐지에 적용한 예
실시간 추천 시스템에서는 사용자 행동 이벤트(클릭, 구매, 검색 등)를 Kafka에 실시간으로 수집하고, Flink로 사용자 프로필·행동 패턴·선호도를 분석한다. 처리된 데이터는 Redis나 Cassandra 같은 빠른 조회 저장소에 저장돼 추천 API로 실시간 개인화 추천을 제공하고, 새로운 추천 알고리즘을 도입할 때는 전체 이벤트 로그를 재처리해 새 모델을 구축한다.
실시간 모니터링·이상 탐지에서는 IoT 장치·서버·애플리케이션의 모니터링 데이터를 Kafka에 원시 텔레메트리로 저장하고, Kafka Streams로 실시간 집계와 이상 탐지 알고리즘을 적용한다. 이상 징후가 발견되면 알림이 트리거되고, 과거 데이터를 재처리해 새로운 이상 탐지 모델을 학습시킨다.
람다와 나란히 놓고 보면
| 특성 | 람다 아키텍처 | 카파 아키텍처 |
|---|---|---|
| 처리 파이프라인 | 배치 계층 + 스피드 계층 (이중) | 단일 스트림 처리 파이프라인 |
| 코드 중복 | 두 계층에 동일 로직 구현 필요 | 한 번만 구현 |
| 복잡성 | 높음 (두 시스템 운영) | 낮음 (단일 시스템) |
| 데이터 일관성 | 두 계층 결과 통합에 어려움 | 단일 파이프라인으로 일관성 보장 |
| 배포 및 유지보수 | 복잡함 | 단순함 |
| 처리 지연 | 배치(고지연), 실시간(저지연) | 스트림 처리 엔진 성능에 의존 |
| 재처리 방식 | 배치 계층에서 재처리 | 전체 로그 재생 |
얻는 것과 잃는 것
단일 처리 로직만 구현하면 되니 유지보수가 간소화되고, 단일 기술 스택으로 운영 복잡성이 줄어든다. 동일한 처리 엔진을 쓰므로 데이터 처리 일관성이 높아지고, 분산 로그와 스트림 처리 시스템의 수평적 확장도 쉽다. 데이터가 손실돼도 원본 이벤트 로그에서 상태를 재구성할 수 있는 복원력이 있고, 개발자가 단일 시스템에만 집중할 수 있어 생산성이 오른다. 모든 데이터를 실시간으로 처리해 빠른 인사이트를 얻을 수 있다는 것도 장점이다.
반대로 전체 데이터를 재처리할 때는 상당한 컴퓨팅 자원이 필요하고, 처리 로직이 복잡해질수록 스트림 프로세싱 난이도가 올라간다. 장기간 대용량 로그를 저장하다 보면 스토리지 비용이 늘고, 특정 분석 작업에서는 배치 처리보다 스트림 처리의 효율이 낮을 수 있다. Kafka 같은 이벤트 로그 시스템에 강하게 의존하게 되고, 스트림 처리 시스템의 상태 관리도 복잡하다. 스트림 처리 패러다임에 팀이 적응하는 학습 곡선도 감안해야 한다.
재처리를 안정적으로 돌리려면
이벤트 로그는 재처리에 필요한 시간을 고려해 충분한 보존 기간을 설정하고, 데이터 스키마 설계와 진화 전략을 마련해야 한다. 파티셔닝 전략을 적절히 짜서 병렬 처리를 최적화하는 것도 중요하다. 스트림 처리 쪽에서는 정확히 한 번(exactly-once) 처리를 보장하고, 로컬 상태와 원격 상태 중 상태 관리 전략을 정한 뒤 체크포인트·복구 메커니즘을 구현해야 한다. 재처리는 점진적 재처리 메커니즘을 두고, 처리 로직 변경을 버전으로 추적하며, 재처리에 드는 리소스를 미리 계획해야 한다. 처리 지연·처리량·오류율 같은 핵심 지표를 모니터링하고 파이프라인 상태를 시각화해, 문제가 생기면 빠르게 알림이 가도록 해야 한다.
이커머스 데이터로 그려보는 전체 흐름
이커머스 플랫폼에서 사용자 클릭, 주문, 재고 이벤트가 발생하면 모든 이벤트는 Apache Kafka에 영구 저장된다. Apache Flink가 스트림 데이터를 실시간으로 처리해 사용자 세션을 분석하고 고객 행동 패턴을 식별하며, 주문 상태를 추적해 매출을 집계하고, 재고 수준을 모니터링·예측한다. 처리된 데이터는 목적에 맞는 저장소로 나뉘어 저장된다 — Redis는 실시간 대시보드와 KPI 모니터링에, Elasticsearch는 복잡한 분석 쿼리와 검색에, Cassandra는 고객 프로필과 개인화 데이터에 쓰인다. 비즈니스 요구사항이 바뀌면 Kafka의 원본 이벤트 로그에서 데이터를 다시 처리하면 된다.
앞으로의 방향
클라우드 기반 서버리스 스트림 처리가 확산되면서 운영 복잡성이 줄어들 것으로 보이고, 스트림 처리와 머신러닝 모델이 통합돼 실시간 예측·의사결정을 지원하는 방향으로 갈 가능성이 있다. IoT 장치와 엣지 환경으로 스트림 처리가 확장되고, 다양한 클라우드 환경에서 카파 아키텍처를 구현하는 사례도 늘어날 전망이다. 기업 전체 데이터 메시 아키텍처의 핵심 컴포넌트로 발전할 가능성도 거론된다.