들어가며

스트림 처리를 한다고 하면 자연스럽게 떠오르는 개념들이 있다.

“이벤트가 들어오면 바로 반영된다”, “배치가 아니라 실시간이다”, “상태를 저장하면서 처리한다” 같은 흐릿한 이미지들.

Kafka Streams는 이런 이미지를 아주 구체적인 기술로 바꿔주는 라이브러리다.

프로듀서·컨슈머를 직접 구성하지 않아도 되고, 스트림을 자연스럽게 함수처럼 다루게 해준다.

이 편에서는 Kafka Streams가 어떤 내부 구조로 동작하는지, 특히 Topology – Processor – State Store가 어떻게 연결되어 있는지를 명확하게 정리해본다.

전체 구조 한 번에 보기

Kafka Streams의 핵심은 크게 세 가지다.

• 토폴로지(Topology): 스트림 처리 로직의 설계도
• 프로세서(Processor): 토폴로지 위의 실제 연산 단위
• 상태 저장소(State Store): join, aggregation 등을 위한 로컬 상태 DB
• 리파티셔닝(Repartition): 처리 단계에서 파티션 키 정렬이 필요한 경우 발생
• 체인지로그(Changelog): 상태 저장소의 durability를 위한 Kafka 백업 토픽

전체 관계를 먼저 시각적으로 보면 흐름이 확 열린다.

flowchart TD
    subgraph K[Kafka Cluster]
        A[Input Topic] -->|partitioned| B[Repartition Topic]
    end

    subgraph S[Kafka Streams App]
        subgraph T[Topology]
            P1[Source Processor]
            P2[Map/Filter Processor]
            P3[Aggregate/Join Processor]
            P4[Sink Processor]
        end

        subgraph ST[State Store - RocksDB]
            ST1[(Local RocksDB)]
        end

        P3 --> ST1
        ST1 -->|changelog| C[Changelog Topic]
    end

    A --> P1
    P1 --> P2
    P2 --> P3
    P3 --> P4
    B --> P3

Topology: 스트림 처리의 설계도

Kafka Streams 애플리케이션은 결국 하나의 “Topology”를 만든다고 볼 수 있다.