Kafka Streams와 Flink — 둘 다 레코드 단위인데 뭐가 다른가
직관적으로
Kafka Streams는 '내 애플리케이션 코드 안에 라이브러리로 들어와 함께 돌아가는' 방식이고, Flink는 '별도의 실행 클러스터에 내 잡을 제출하는' 방식이다. 전자는 나만의 앱을 배포하는 느낌, 후자는 회사 인프라 팀이 관리하는 별도 플랫폼에 일을 맡기는 느낌이다.
실제 사례
study_de의 Kafka Streams 학습 콘텐츠를 떠올려보면, Kafka Streams 애플리케이션은 그냥 일반 JVM 애플리케이션(jar 하나)이고, 그 프로세스 여러 개를 띄우면 그게 곧 병렬 처리가 된다 — 별도의 클러스터 매니저가 없다. 반면 Flink 잡은 반드시 Flink 클러스터(JobManager+TaskManager)에 제출돼야 실행된다 — 로컬이든 실무 클러스터든 이 실행 모델 자체는 똑같다.
정확한 원리
이 차이는 두 기술의 태생적 포지셔닝 차이에서 나온다. Kafka Streams는 "Kafka 토픽을 다루는 애플리케이션을 짜기 위한 라이브러리"로 설계돼 Kafka와 강하게 결합돼 있다(입출력이 기본적으로 Kafka 토픽). Flink는 "임의의 소스·싱크를 다루는 범용 스트림/배치 처리 엔진"으로 설계돼 Kafka는 여러 커넥터 중 하나일 뿐이다. 이 때문에 Flink는 더 무겁지만(별도 클러스터 운영 필요) 더 범용적이고, 더 정교한 상태 관리(RocksDB 기반 대용량 상태, 커스텀 윈도우 등)를 제공한다.
흔한 오해
"그럼 Flink가 Kafka Streams의 상위 호환이니 항상 Flink를 쓰면 되는 거 아닌가?"는 성급한 결론이다. Kafka 생태계 안에서만 끝나는 간단한 Java 마이크로서비스라면, 별도 클러스터 운영 부담 없이 애플리케이션에 라이브러리 하나 추가하면 되는 Kafka Streams가 오히려 운영 비용 면에서 더 합리적일 수 있다 — 이 판단 기준은 코스 마지막 날(응용)에 더 자세히 다룬다.
확인 문제
"우리 팀은 이미 Kafka 기반 마이크로서비스를 여러 개 운영 중이고, 이번에 추가할 기능도 Kafka 토픽 하나 읽어서 다른 토픽으로 쓰는 간단한 집계 로직입니다. Flink와 Kafka Streams 중 어느 쪽이 더 합리적일까?" — 왜 그렇게 생각하는가?
Answer Guide
복잡도가 낮고 Kafka 생태계 안에서 끝나는 작업이면 별도 클러스터 운영 부담이 없는 Kafka Streams 쪽이 실무적으로 더 합리적이라는 판단 근거가 들어가야 한다(정답을 강제하기보다, '별도 클러스터 운영 비용'이라는 트레이드오프를 인지하고 있는지가 핵심).