Flink vs Spark Structured Streaming vs Kafka Streams — 실무 선택 기준
직관적으로
세 기술 중 하나를 고르는 건 '어떤 자동차가 가장 좋은가'가 아니라 '내 상황에 어떤 차가 맞는가'를 묻는 문제다. 스포츠카(Flink)가 항상 정답은 아니고, 이미 있는 SUV(기존 Spark 인프라)를 계속 타는 게 나을 때도 있다.
실제 사례
이미 Spark 배치 인프라(스케줄러, 모니터링, 팀 숙련도)를 갖춘 조직이 초 단위 지연이면 충분한 대시보드 집계를 추가한다면, 새 클러스터 운영 부담을 감수하고 Flink를 도입하기보다 Spark Structured Streaming으로 확장하는 게 합리적일 수 있다. 반대로 결제 이상거래 탐지처럼 수십~수백 ms 지연이 실제로 비즈니스에 영향을 준다면, 그 정확도-지연시간 요구 자체가 Flink를 선택할 근거가 된다. Kafka 생태계 안에서 끝나는 간단한 Java 마이크로서비스라면(Day 1-3에서 다룬 것처럼) Kafka Streams가 운영 부담 면에서 유리하다.
정확한 원리
일반적으로 관찰되는 경향은(정확한 수치는 워크로드·튜닝에 따라 크게 달라지므로 참고용) Spark Structured Streaming이 초 단위, Kafka Streams가 수백 ms대, Flink가 그보다 낮은 지연시간대를 목표로 한다는 것이다. Exactly-once 지원 수준도 다르다 — Flink는 체크포인트+2단계 커밋으로 end-to-end exactly-once를 비교적 폭넓게 지원하고, Spark Structured Streaming은 일부 싱크(특히 Kafka로 쓰기)에서 exactly-once를 기본적으로 보장하지 않는다. 선택 기준을 정리하면: (1) 이미 Spark 인프라가 있고 초 단위 지연이면 충분하다 → Spark Structured Streaming, (2) Kafka 생태계 안에서 끝나는 간단한 서비스 → Kafka Streams, (3) 초저지연·복잡한 상태 관리·대용량 상태가 필요하다 → Flink.
흔한 오해
"제일 빠르고 기능 많은 걸 무조건 쓰는 게 낫다"는 생각으로 항상 Flink를 고르면, 별도 클러스터 운영이라는 실질적 비용을 과소평가하는 것이다. 반대로 "이미 Spark 쓰고 있으니 무조건 Spark로 밀어붙인다"도, 지연시간 요구사항이 실제로 초저지연이라면 근본적으로 안 맞는 선택일 수 있다 — 기술의 우열이 아니라 **요구사항과 기존 인프라의 궁합**이 기준이다.
확인 문제
코스를 시작하기 전 진단 질문에서 "Kafka를 이미 쓰고 있다"고 답하셨다면(또는 study_de의 Kafka 학습 콘텐츠를 이미 아신다면), 지금 배운 세 기준(기존 인프라/생태계 결합도/지연시간 요구)으로 볼 때 다음 상황엔 어떤 걸 고르겠는가: "Kafka 토픽 3개를 조인해서 복잡한 세션 기반 사용자 행동 분석을 하고 싶고, 결과는 1분 정도 늦어도 괜찮다"
Answer Guide
1분 지연은 세 기술 모두 커버 가능한 범위지만, '복잡한 세션 기반 조인+상태 로직'이라는 조건이 핵심 — Kafka Streams로도 가능은 하지만 복잡한 다중 스트림 조인·세션 윈도우는 Flink의 DataStream API/CEP 쪽이 표현력과 대용량 상태 관리 면에서 더 유리하다는 방향으로 답하면 좋다. 정답을 강제하기보다 '지연시간만으로 결정하지 않고 로직 복잡도까지 함께 고려했는지'가 핵심 채점 기준.