Kafka 파이프라인 플레이메모

updated at 17 April 2025

카프카 운영을 하면서 겪은 문제점들과 이를 해결하기 위해 여러 도구를 도입하고 고도화한 과정을 공유해보려고 합니다.

이 과정에서 겪은 시행착오와 제 생각의 흐름은, 플레이북이라는 단어에서 조금 정리가 덜 된 느낌이라 플레이메모라고 작성해 보았습니다.


결과를 우선 말씀드리면,

  • Strimzi와 ksqlDB를 도입하여 카프카 파이프라인의 유지보수성과 확장성을 높여서
  • 데이터 엔지니어의 역할을 더 쉽고 넓게 가져갈 수 있게

만들었습니다.


이 과정에서 카프카와 맞닿아 있는 기술적인 고민 뿐만아니라, 조직의 역할과 인터페이스에 대한 고민들이 있었기도 했고요.

지금은 이직하신 동료분이 고민하던 일감인데, 근 한 달간 진행하면서 무척 재미있었기에 블로그로 작성하게 되었습니다.


이 글은 우선 기존 운영 환경의 모습을 설명하고, 문제를 제기하고, 해결하기 위한 방법과 기대 효과를 설명합니다.

디테일한 내용은 하위 링크의 별도 포스트로 작성할 예정입니다.

아직은 카프카 내에서 잘 모르는 디테일들이 많기 때문에 너그러이 봐주시면 감사드리겠습니다.

기존 운영 환경의 모습

일단, 기존에 카프카를 사용하던 방식을 먼저 설명드리겠습니다.

제가 속한 조직에서는 MSK Private or Broken Links
The page you're looking for is either not available or private!
를 기반으로 여러 개의 카프카 클러스터가 백엔드 개발 조직별로 나뉘어져 운영되고 있습니다.

타 개발 조직에서는 직접 프로듀서/컨슈머 코드를 작성하여 어플리케이션을 배포하는 경우가 많습니다.


flowchart TD subgraph MSK["Kafka (MSK 기반)"] A1["타 개발 조직
Producer/Consumer"] A2["데이터 조직
Kafka Connect 기반"] end subgraph SourceRepositories["소스 레포지토리"] SR1["소스 레포지토리"] SR2["소스 레포지토리"] SR3["소스 레포지토리"] end subgraph S3["S3 아티팩트 저장소"] AR["커넥터 및 SMT"] end SR1 & SR2 & SR3 --> AR A1 -->|메시지 송수신| K1["Kafka 클러스터"] A2 -->|커넥터 기반 운영| K2["데이터 Kafka 클러스터"] K2 --> SC subgraph KafkaConnect["Connect 클러스터"] PP["Plugin Path"] SC["Source Connector
(DB, Kafka 토픽 등)"] SMT["SMT 변환"] SK["Sink Connector
(BigQuery)"] end AR -->|배포 시 다운로드| PP SC --> SMT --> SK --> BQ["BigQuery"] subgraph Downstream["Downstream 처리"] BQ --> DBT["dbt 모델"] end


제가 속한 데이터 조직은 cp-kafka-connect 기반의 커넥트 클러스터를 구성해서 사용했습니다.

프로듀서/컨슈머 어플리케이션 제작 없이 커넥터 기반으로만 데이터를 처리해왔습니다.

커넥터를 사용함으로써 반복되는 파이프라인의 구성을 재사용할 수 있을거라 기대했습니다.


커넥터나 SMT 등 커넥터 실행에 필요한 빌드 아티팩트는 각 소스 레포지토리를 통해서 S3에 배포되어 있습니다.

커넥트 클러스터가 배포될 때 이 아티팩트들을 다운로드하는 구조입니다.


이전까지의 카프카 파이프라인의 용도는 단순 추출 - 적재 였습니다.

주요 사용사례로

  • 다른 카프카 토픽이나 데이터베이스 변경 사항을 수집
  • 뭐든 그대로 빅쿼리로 적재

하는 파이프라인으로 구성되어 있었습니다.

배치 파이프라인에서는 빅쿼리와 dbt를 사용하고 있고, 필요한 경우 람다 아키텍쳐를 구성할 수 있었기 때문에 그간 실시간 처리의 중요성을 느끼지 못했습니다.

겪은 문제들과 원인

1. 커넥트 클러스터 형상 관리의 어려움

flowchart TD subgraph SourceRepositories["소스 레포지토리"] SR1["소스 레포지토리"] SR2["소스 레포지토리"] SR3["소스 레포지토리"] end subgraph KafkaClusters["카프카 클러스터"] K1["Kafka Cluster 1"] K2["Kafka Cluster 2"] K3["Kafka Cluster 3"] end subgraph S3["S3 아티팩트 저장소"] AR["커넥터 및 SMT"] end subgraph ConnectClusters["커넥트 클러스터"] C1["Connect Cluster 1"] C2["Connect Cluster 2"] C3["Connect Cluster 3"] end SR1 --> AR SR2 --> AR SR3 --> AR K1 --> C1 K2 --> C2 K3 --> C3 AR --> C1 AR --> C2 AR --> C3

여러 Github 레포지토리에 분산된 S3에 아티팩트를 배포하는 파이프라인이 있습니다. 이 과정에서 여러 문제들이 발생했습니다:

  • 각 카프카 클러스터별로 중복된 구성의 커넥터 클러스터를 유지해야 함
  • 현재 각 커넥트 클러스터가 어떤 아티팩트들을 중심으로 배포되었는지 파악이 어려움
  • 이로 인한 각 모듈 유지보수 및 업그레이드의 어려움

2. 커넥터 수동 배포의 한계

kafbat-ui 를 통해 수동 API 호출 방식으로 커넥터 배포를 진행하고 있었습니다. 이 방식도 여러 문제를 야기합니다:

  • 휴먼 에러가 발생할 가능성이 높음
  • 기록된 소스 코드 형상의 부재로 문제가 발생했을 때 원인 파악이 어려움
  • 현재 배포된 커넥터의 형상 파악이 어려움
  • 설정의 반복 복사/붙여넣기로 인해 실패 지점 파악이나 일괄 변경이 어려움

3. 언급된 문제들로 인해 발생하는 하위 문제들

  • 스트리밍 파이프라인의 관리 / 배포 어려움으로 "데이터 조직 = 집계 배치 처리 조직" 이라는 인식
  • 배치 처리 기반으로 어떻게든 수행되는 데이터 엔지니어링 일감
  • 인식으로 인해 제한되는 데이터 엔지니어의 역할

4. 전체 개발 조직 내 실시간 집계 파이프라인의 부재

  • 데이터 조직은, 앞서 말했듯이 집계 배치 처리 조직으로 인식되어 실시간 파이프라인의 개발 요청이 거의 없었습니다.
  • 개발 조직은, 데이터 처리 방식에 대한 고민이 거의 없어서
    • 복제 MySQL 데이터베이스에서 마이크로 배치 쿼리를 실행하거나
    • 장기간 걸리는 쿼리를 구성하는 경우가 많았습니다
  • 이로 인해 복제 데이터베이스의 요구 스펙이 올라가고, 많은 비용이 발생하기도 했습니다.
  • 현재에도 이런식의 기술 부채가 남아 있습니다.

개선 포인트와 기대 효과

드디어, 조금 기술적인 내용이 들어가기 시작합니다.


Strimzi를 통한 커넥트 클러스터 및 커넥터 관리Strimzi를 통한 커넥트 클러스터 및 커넥터 관리

배경 설명은 앞선 포스트 Kafka 파이프라인 플레이메모를 참고해주세요.


사용한 기술


Strimzi 0.45.0
ArgoCD v2.9.5
Helm 3


목적

커넥트 클러스터와 커넥터를 쉽고 빠르게 배포할 수 있는 구성 마련
커넥터 문제 발생 시 빠르게 대응할 수 있는 구성 마련


Strimzi 개요





...

우선 Strimzi를 사용해서 커넥트 클러스터를 구성하고 커넥터를 코드로 관리하는 방식으로 개선하고자 했습니다.

이를 진행하면서 커넥터나 SMT 같은 플러그인 빌드 아티팩트의 버전도 잘 관리할 수 있게 개선했습니다.


ksqlDB를 통한 스트리밍 파이프라인 기능 추가 Private or Broken Links
The page you're looking for is either not available or private!

단순히 소스 / 싱크 커넥터를 운영하는 것만으로는 제한적인 운영을 할 수 밖에 없다고 판단했고, 실시간 집계 도구가 필요했습니다.


사실 요즘은 실시간 집계 도구들로 ksqlDB가 아닌 Spark Streaming, RisingWave, Flink 같은 도구들이 자주 언급되는 것 같습니다.

심지어, ksqlDB를 소유하고 있는 Confluent는 2023년 Flink 회사인 Immerok를 인수하고 활발히 활동을 이어가고 있습니다.


반면, ksqlDB는 기술적으로 미니멀하고 제한적인 부분들이 있었습니다.

게다가 카프카의 창시자중 한명이자 Confluent의 창업자인 제이 크랩스(Jay Kreps)도 ksqlDB는 실패했고, Flink로 전환했다고 말하기도 했습니다.


하지만, ksqlDB의 즉각적인 생산성과 직관성을 바탕으로 조직 내에서 "이건 된다"라는 생각을 만들기에 빠르고 효과적일거라 기대했습니다.

우선 조직의 전반적인 인식을 바꿔야, 앞서 지적한 복제 데이터베이스 사용사례 같은 고차원적인 문제들이 해결될 수 있을 것입니다.


끝내며

flywheel


조직에 새로운 기술을 도입할 때 가장 큰 장벽은 기술 자체가 아니라 "이게 우리 조직에서 진짜 될까?"라는 불신입니다.

그 불신을 넘는 가장 효과적인 방법은, 작지만 의미 있는 시범 프로젝트를 통해 실제로 돌아가는 결과를 보여주는 것입니다.


딥러닝 계의 대가인 앤드류 응(Andrew Ng)의 AI Transform Playbook에서 읽어, 자주 인용하는 생각이 있습니다.

가장 가치 있는 AI 프로젝트가 되는 것보다, 처음 몇 개의 AI 프로젝트가 성공하는 것이 더 중요합니다.

이러한 프로젝트들은 초기 성공이 회사가 AI에 익숙해지는 데 도움이 되고, 회사 내 다른 사람들이 더 투자하게 설득할 만큼 충분히 의미 있어야 합니다.

다른 사람들이 하찮게 여길 정도로 너무 규모가 작아서는 안 됩니다.

중요한 것은 AI 팀이 추진력(Momentum)을 얻을 수 있도록 플라이휠(flywheel)을 돌리는 것 입니다.

이것은, AI 프로젝트에만 적용되는 이야기가 아닙니다.


핵심은 "가장 중요한 프로젝트가 아니라, 가장 성공 가능성이 높고 적당한 시범 프로젝트부터 시작하라"는 것입니다.

시범 프로젝트의 조건은 아래와 같습니다:

  • 단기간내에 가시적인 성과를 낼 수 있어야 하고
  • 기술적으로 현실 가능해야 하며
  • 너무 하찮어서도 안되며
  • 내부 도메인 전문가와 개발팀이 협업할 수 있는 구조여야 합니다.

말하자면, 완벽하고 멋진 기술이 아니라 Use Case에 적용 가능하고 작동하는 기술이 더 중요합니다.

ksqlDB와 같은 시범 프로젝트를 통해 조직의 인식을 바꾸고, 데이터 엔지니어의 역할을 더 쉽고 넓게 가져갈 수 있기를 바랬습니다.


또, 모멘텀을 굴리기에 앞서 빠른 반복을 돌리기 위한 환경 또한 필수적입니다.

새로운 유사한 일감이 들어왔을 때, 이미 준비된 환경을 통해 빠른 대응이 가능해야 조직에 더 설득력을 가질 수 있습니다.

그러기 위해서 반복을 방해하는 병목을 찾아 해결하기도 했습니다.

Strimzi와 Helm Chart를 통해서 카프카 커넥터들을 템플릿화하고, 빠른 배포가 가능하게 구성했습니다.


이에 그치지 않고, 설득력을 가지기 위해서 자주 소통하기도 했습니다.

이해관계자나 조직장, 많은 동료에게 작동하는 기술로 만들어진 신기한 결과물들을 자주 보여주고 소통했습니다.

이렇게 조금씩, 조직에 새로운 기술에 대한 설득력을 만들어나가야 더 많은 일감을 받고 기여할 수 있습니다.


수행하는 업무나 요청들이 그 짧은 한 달 사이에 많이 바뀐 같습니다.

여기저기 실시간으로 데이터를 꽂아달라는 요청이 들어오고, 지금까지 이걸 왜 못했지 싶은 생각도 듭니다.


돌이켜보면

  • 처음 웨어하우스라는 개념을 도입했을 때
  • 처음 ArgoCD를 도입했을 때
  • 처음 BigQuery ML을 도입했을 때

모두 같았던 그런 기억들이 납니다.


몇 년뒤에 다시 돌이켜봤을 때, 이 글이 당시와 같이 제 커리어에 있어 자랑스러운 순간이었으면 좋겠습니다.