핀테크 실무 관점으로 보는 개념 + 적용 패턴(Java)

GarionNachal·2026년 1월 29일

kafka

목록 보기

20/23

Kafka Streams는 Kafka 토픽을 입력으로 받아 애플리케이션 내부에서 스트림 처리(변환/집계/조인)를 수행하고, 결과를 다시 Kafka 토픽으로 내보내는 JVM 라이브러리입니다. “별도 스트림 처리 클러스터 없이(예: Flink 클러스터 운영 없이) 서비스처럼 배포/스케일링”하는 접근이 핵심입니다. Source

1) 핀테크에서 Kafka Streams가 특히 잘 맞는 이유

1.1 실시간 이벤트 기반 아키텍처와 궁합

핀테크 도메인은 결제 승인/거절, 정산, 한도, 이상거래 탐지(FDS), 알림처럼 “이벤트가 계속 흐르고” “즉시 반응”이 중요한 영역이 많습니다. Kafka Streams는 이를 토픽 → 처리 → 토픽 형태로 표준화하기 좋습니다. Source

1.2 Stateful 처리(상태 저장)가 내장

핀테크의 핵심 로직(예: “10분 내 동일 사용자 5회 결제”, “가맹점별 승인율”, “사용자별 한도 소진”)은 대부분 누적 상태/윈도우가 필요합니다. Kafka Streams는 로컬 state store를 이용해 윈도우 조인/집계 같은 stateful 연산을 빠르게 지원합니다. Source

1.3 Exactly-once(정확히 한 번) 의미론: 금전 도메인 필수 옵션

Kafka Streams는 장애가 나도 “레코드가 한 번만 처리된 것과 같은 효과”를 보장하는 exactly-once processing semantics를 지원합니다. 핀테크에서 중복 승인/중복 정산은 치명적이므로 이 축이 매우 중요합니다. Source

2) 핵심 개념(개념 + 실무에서 어떻게 쓰는지)

2.1 KStream vs KTable

Kafka Streams DSL은 KStream/KTable 등의 추상화를 제공합니다. Source

KStream: “이벤트 흐름” (승인 요청 이벤트, 거래 발생 이벤트 등)
KTable: “최신 상태” (사용자 한도 상태, 사용자 위험등급, 가맹점 설정값 등)
실무 팁:
- “거래 이벤트”는 보통 KStream
- “설정/프로필/한도/위험등급”은 보통 KTable (최신 상태로 조인하기 좋음)

2.2 Topology(토폴로지) = 스트림 처리 그래프

토폴로지는 필터/변환/조인/집계를 연결한 처리 그래프입니다.

Kafka Streams Topology
Source

3) 핀테크 실무 사용 예(패턴별)

아래 예시는 “이런 요구사항이면 Kafka Streams가 깔끔해진다”를 기준으로 정리했습니다.

예시 A) 승인 이벤트 라우팅/정규화(Stateless) — “파이프라인 기본기”

상황: 결제 승인 이벤트에서 카드사별 필드가 제각각 → 내부 표준 포맷으로 정규화하고, 국가/통화/채널에 따라 토픽을 분기.

사용 연산: mapValues, filter, branch, selectKey
결과: payments.approved.normalized, payments.declined.normalized 같은 토픽으로 재발행

DSL 개념은 공식 DSL 문서 기반으로 이해할 수 있습니다. Source

예시 B) 사용자별 “단기 다건 결제” 탐지(Windowed aggregation) — FDS의 최소 단위

상황: 동일 사용자/동일 카드로 N분 내 결제 시도 횟수가 임계치를 넘으면 경보 생성

핵심: stateful + windowing
구현 포인트(실무):
- 키 설계: userId 또는 cardHash
- 윈도우: tumbling/hopping window로 “최근 5분/10분”
- 결과를 경보 토픽으로 발행: fraud.alerts

Kafka Streams는 윈도우 집계 같은 stateful 연산을 지원한다고 core concepts에서 강조합니다. Source

예시 C) 거래 이벤트 + 사용자 위험등급(KTable) 조인 — “실시간 정책 적용”

상황: 거래가 들어오는 순간, 사용자 위험등급/한도 상태(최신)를 붙여서 승인정책을 적용해야 함.

입력:
- payments.tx (KStream)
- risk.user-score (KTable; 최신 위험등급)
처리:
- KStream-KTable join으로 “거래 + 최신 위험등급” 결합
결과:
- payments.enriched → 이후 룰 엔진/머신러닝/심사로 전달

KStream/KTable은 DSL에서 공식적으로 정의된 추상화입니다. Source

예시 D) Exactly-once 기반 “중복 없는 결과 토픽 생성” — 정산/원장계 이벤트에 특히 유용

상황: 스트림 처리 결과가 “정산/원장계”에 영향을 줌. 중복 이벤트는 곧 금액 오류.

전략:
- Kafka Streams의 exactly-once processing semantics 활용
- (실무적으로는) 외부 DB 업데이트까지 완전한 의미의 end-to-end exactly-once는 별도 설계가 필요하지만, Kafka 내부 토픽 간 처리(consume→process→produce)는 EOS 옵션이 강력한 안전장치가 됩니다.

Kafka Streams가 exactly-once processing semantics를 지원한다는 점은 core concepts에 명시되어 있습니다. Source

예시 E) Interactive Queries로 “실시간 상태 조회 API” 만들기 — 한도/위험상태 조회

상황: “현재 사용자의 실시간 한도 소진액/위험 플래그”를 API로 바로 제공하고 싶음.
Kafka Streams는 state store를 직접 읽어 조회할 수 있는 Interactive Queries를 제공합니다. Source

Interactive Queries / State Store
Source

4) Java(Streams DSL)로 보는 “핀테크 미니 예제” 스케치

아래는 “결제 이벤트 → 사용자별 5분 내 시도 횟수 집계 → 경보 토픽”의 전형적인 흐름입니다(설계 감 잡기용).

StreamsBuilder builder = new StreamsBuilder();

KStream<String, PaymentEvent> payments =
    builder.stream("payments.tx", Consumed.with(Serdes.String(), paymentSerde));

// userId를 key로 설정
KStream<String, PaymentEvent> keyed =
    payments.selectKey((k, v) -> v.userId());

// 5분 윈도우 집계(개념 스케치)
KTable<Windowed<String>, Long> attempts =
    keyed.groupByKey()
         .windowedBy(TimeWindows.ofSizeWithNoGrace(Duration.ofMinutes(5)))
         .count();

// 임계치 넘으면 alerts 토픽으로
attempts.toStream()
        .filter((windowedUserId, count) -> count >= 5)
        .mapValues((windowedUserId, count) ->
            new FraudAlert(windowedUserId.key(), count, windowedUserId.window().startTime()))
        .to("fraud.alerts", Produced.with(windowedStringSerde, fraudAlertSerde));