쿠버네티스에서 Kafka 띄우기: Strimzi vs Bitnami, 그리고 KRaft

핵심 요약

쿠버네티스 위에 Kafka를 올리는 방법은 크게 두 갈래입니다. 하나는 Bitnami Helm 차트로 "설치 패키지처럼 한 번 찍어내는" 방식이고, 다른 하나는 Strimzi 오퍼레이터로 "클러스터 안에 상주하는 관리 로봇에게 운영을 맡기는" 방식입니다. 둘은 같은 Kafka를 올리지만 사상 자체가 다릅니다. 그리고 요즘 Kafka는 ZooKeeper 없이 도는 KRaft 모드가 기본이 되었는데, 이게 무엇이고 왜 바뀌었는지를 먼저 이해하면 두 방식의 차이가 훨씬 또렷해집니다.

이 글에서는 ① KRaft가 무엇인지 ② Helm과 Operator의 원리 차이 ③ Strimzi와 Bitnami를 각각 어떻게 설치하고 운영하는지 ④ 언제 무엇을 골라야 하는지를 순서대로 정리합니다.

---

1. 먼저, Kafka가 K8s에서 까다로운 이유

Kafka는 그냥 떠 있기만 하면 되는 무상태(stateless) 웹 서버가 아닙니다. 상태를 가진(stateful) 분산 시스템입니다.

비유하자면, 무상태 웹 서버는 편의점 알바와 같습니다. 누가 와도 똑같이 일하고, 한 명이 빠지면 다른 사람으로 바로 대체됩니다. 짐도, 기억도 없습니다. 반면 Kafka 브로커는 자기 전용 사물함을 가진 창고 직원입니다. 각자 맡은 짐(데이터)을 자기 사물함(디스크)에 보관하고 있어서, 잠깐 자리를 비웠다 돌아와도 반드시 자기 사물함 앞으로 돌아와야 합니다. 아무 자리에나 새로 앉으면 그 사람이 보관하던 짐을 못 찾습니다.

• 각 브로커는 자기 디스크에 메시지 로그를 쌓습니다. 그래서 파드가 죽었다 살아나도 같은 디스크(PVC)에 다시 붙어야 합니다(사물함 앞으로 복귀). 아무 데서나 새로 떠선 안 됩니다.
• 브로커마다 고유한 ID와 안정적인 네트워크 이름이 필요합니다. kafka-0, kafka-1처럼 번호가 고정돼야 서로를 찾습니다. 직원마다 사번과 자리 번호가 고정된 셈입니다.
• 업그레이드할 때 순서가 중요합니다. 한꺼번에 다 내렸다 올리면 데이터가 깨지거나 메시지가 유실될 수 있습니다. 창고 직원을 전원 동시에 퇴근시키면 그 시간 들어온 짐을 아무도 못 받는 것과 같습니다.

그래서 K8s에서는 Deployment가 아니라 StatefulSet(순서·고정 이름·고정 디스크를 보장하는 리소스)으로 띄우는 게 정석입니다. 바로 이 "상태 관리"의 무게 때문에, Kafka를 어떻게 배포·운영하느냐가 중요한 선택지가 됩니다.

참고: 단순히 apache/kafka 이미지를 Deployment 하나로 띄우는 구성도 있긴 합니다. 개발용 단일 인스턴스로는 동작하지만, 디스크 영속성·순서 보장·고가용성이 없어서 운영에는 부적합합니다. 이 글에서 다루는 Strimzi/Bitnami는 둘 다 StatefulSet 기반의 제대로 된 방식입니다.

---

2. KRaft란 무엇인가

옛날 방식: ZooKeeper

예전 Kafka는 혼자 살림을 못 했습니다. 메타데이터(브로커가 몇 대 살아있는지, 토픽이 몇 개인지, 파티션 리더가 누구인지, 권한 설정은 어떤지)를 자기가 관리하지 못하고, ZooKeeper라는 별도 시스템에 맡겼습니다.

비유하자면, Kafka는 "장사하는 가게"이고 ZooKeeper는 그 옆 건물의 별도 관리사무소였습니다. 누가 입주했는지, 누가 대표인지 같은 장부를 전부 관리사무소가 들고 있었던 셈입니다. 가게를 운영하려면 관리사무소 건물을 따로 짓고, 따로 관리하고, 따로 장애에 대비해야 했습니다.

이 구조의 문제:

• 운영해야 할 시스템이 둘이 됩니다(Kafka + ZooKeeper). 각각 클러스터를 구성하고 모니터링해야 합니다.
• ZooKeeper가 흔들리면 Kafka 전체가 흔들립니다.
• 메타데이터 변경이 ZooKeeper를 거쳐야 해서, 클러스터가 커지면 느려지고 한계가 생겼습니다.

새로운 방식: KRaft (Kafka Raft)

KRaft는 이름 그대로 "Kafka + Raft" 입니다. ZooKeeper를 없애고, Kafka가 자기 메타데이터를 직접 관리하도록 바꾼 모드입니다. 메타데이터는 Kafka 내부의 특수 토픽(__cluster_metadata)에 저장되고, Raft라는 합의 알고리즘으로 여러 노드가 일관되게 동기화합니다.

비유하자면, 별도 관리사무소 건물을 없애고 가게 건물 안에 관리실을 내장한 것입니다. 입주자 장부를 건물이 스스로 관리합니다. 관리할 건물이 둘에서 하나로 줄었습니다.

여기서 새 개념이 등장합니다. KRaft에서는 노드가 역할(role) 을 가집니다.

• controller(컨트롤러): 메타데이터를 관리하고 합의에 참여하는 역할. 과거 ZooKeeper가 하던 일을 대신합니다. 보통 홀수 대(3, 5대)로 구성해 과반 합의(quorum)를 이룹니다.
• broker(브로커): 실제 메시지를 받고 쌓고 내주는 역할. 우리가 아는 그 Kafka의 본업입니다.

비유하자면, 한 회사로 보면 됩니다. 컨트롤러는 이사회/총무팀입니다. 직접 물건을 나르진 않지만, "누가 우리 직원인지", "지금 팀장이 누구인지", "조직도가 어떻게 되는지"를 관리합니다. 브로커는 현장 직원입니다. 실제로 짐(메시지)을 받고 쌓고 내줍니다. 컨트롤러를 홀수로 두는 이유는 이사회 의결을 과반으로 하기 위해서입니다. 3명 중 2명이 동의하면 결정이 확정되니, 한 명이 자리를 비워도 회사 의사결정이 멈추지 않습니다.

한 노드가 controller와 broker를 겸할 수도 있고(소규모 — 사장이 현장도 뛰는 1인 회사), 분리할 수도 있습니다(운영 — 경영진과 현장직이 나뉜 큰 회사). 그래서 K8s에서 KRaft Kafka를 띄우면 ...-controller-0, ...-broker-0 같은 파드가 따로 보이는 경우가 많습니다.

Raft가 궁금하다면: 여러 노드가 "지금 리더가 누구다", "이 변경을 확정한다"를 과반 투표로 합의하는 알고리즘입니다. 회의에서 안건을 과반 손들기로 통과시키는 것과 같습니다. 참석자 절반 넘게 찬성해야 확정되므로, 한 명이 자리를 비우거나 의견이 엇갈려도 회의 전체가 일관된 결론을 유지합니다. 분산 시스템에서 "한 명이 죽어도 나머지가 일관된 결정을 유지"하게 해주는 표준적인 방법입니다.

요약하면, KRaft = ZooKeeper를 떼어낸 자립형 Kafka이고, 2024년 이후 Kafka(특히 4.0부터)는 KRaft가 기본이자 사실상 유일한 경로가 되었습니다. Strimzi든 Bitnami든 요즘 버전은 다 KRaft로 동작합니다.

---

3. Helm vs Operator: 두 사상의 차이

이제 본론입니다. Bitnami는 Helm 차트, Strimzi는 Operator입니다. 이 둘은 "Kafka를 까는 도구"라는 점은 같지만, 동작 원리가 근본적으로 다릅니다.

Helm = 설치 템플릿 (한 번 찍어냄)

Helm은 YAML 템플릿 엔진 + 패키지 매니저입니다. values.yaml이라는 설정값을 넣으면, 미리 만들어진 템플릿에 값을 채워 K8s 매니페스트(StatefulSet, Service, ConfigMap...)를 렌더링해서 클러스터에 적용합니다. 그걸로 끝입니다.

비유하자면, Helm은 이케아 가구 조립과 같습니다. 설명서대로 한 번 조립하면 가구가 완성됩니다. 하지만 그 뒤에 나사가 풀리거나 서랍이 빠져도 가구가 스스로 고치지 않습니다. 사람이 다시 와서 손봐야 합니다.

자바 개발자에게는 Maven archetype이 가깝습니다. 명령 한 번으로 프로젝트 뼈대를 생성해주지만, 생성된 다음부터는 관여하지 않습니다. 이후 무슨 일이 생기든, 다음에 사람이 helm upgrade를 실행하기 전까지 Helm은 잠들어 있습니다.

즉 Helm은 "설치 시점에 한 번 일하는" 도구입니다. 설치 후의 운영(업그레이드, 장애 복구, 리밸런싱)은 전부 사람 몫입니다.

Operator = 상주하는 관리 로봇 (계속 맞춰줌)

Operator는 클러스터 안에서 계속 도는 컨트롤러입니다. Kafka라는 CRD(커스텀 리소스) 에 "내가 원하는 상태"(브로커 3대, Kafka 3.9.0, TLS 켜기 등)를 선언해두면, 오퍼레이터가 현재 상태를 끊임없이 감시하면서 원하는 상태로 맞춰줍니다. 이걸 리컨실레이션(reconciliation, 조정 루프)이라고 합니다.

비유하자면, Operator는 온도조절기(thermostat) 와 같습니다. "실내 24도"라고 설정해두면, 온도조절기는 계속 온도를 재면서 더우면 냉방을, 추우면 난방을 켭니다. 사람이 매번 에어컨을 켜고 끄지 않아도 됩니다. 설정값(원하는 상태)만 정해두면 기계가 알아서 현실을 거기에 맞춥니다. Strimzi도 "브로커 3대, 버전 3.9.0"이라고 적어두면 계속 그 상태를 유지합니다.

더 익숙한 예로는 ArgoCD가 정확히 같은 원리입니다. ArgoCD는 Git에 적힌 "원하는 상태"를 보고, 클러스터의 실제 상태가 어긋나면 자동으로 맞춰줍니다(sync). Strimzi는 그 대상이 Git이 아니라 Kafka CRD일 뿐, "원하는 상태를 선언 → 컨트롤러가 계속 맞춤" 이라는 골격이 똑같습니다. 한마디로 Strimzi는 Kafka 전용 ArgoCD라고 봐도 무방합니다.

자바/스프링 개발자에게는, Operator가 클러스터에 상주하는 무한 루프형 컨트롤러입니다. @Scheduled로 끊임없이 도는 작업이 "지금 상태"와 "원하는 상태(설정)"를 비교해 차이를 메우는 것과 같습니다. CRD는 그 컨트롤러가 바라보는 커스텀 엔티티/설정이라고 보면 됩니다.

차이를 한 문장으로:

• Helm: "이렇게 설치해줘" → 설치하고 끝.
• Operator: "이 상태를 유지해줘" → 계속 지켜보며 유지.

이 차이가 모든 장단점의 뿌리입니다.

---

4. Bitnami로 Kafka 설치하기

설치 원리

Bitnami는 Kafka용 Helm 차트를 제공합니다. KRaft 모드를 기본으로, controller와 broker를 분리한 StatefulSet 구성을 만들어줍니다.

1) 차트 추가 / 확인

# Bitnami는 OCI 레지스트리로 제공됩니다
helm show values oci://registry-1.docker.io/bitnamicharts/kafka > kafka-values.yaml

2) values.yaml 작성

# kafka-values.yaml (핵심만 발췌)
controller:
  replicaCount: 3          # KRaft 컨트롤러 3대 (과반 합의)
  persistence:
    enabled: true
    size: 8Gi              # 각 컨트롤러 디스크
broker:
  replicaCount: 3          # 브로커 3대
  persistence:
    enabled: true
    size: 20Gi
listeners:
  client:
    protocol: PLAINTEXT    # 개발용. 운영은 SASL/TLS 권장
kraft:
  enabled: true            # KRaft 모드 (요즘은 기본값)

3) 설치

helm install devops-kafka \
  oci://registry-1.docker.io/bitnamicharts/kafka \
  -n devops-infra --create-namespace \
  -f kafka-values.yaml

설치하면 이런 파드가 뜹니다.

devops-kafka-controller-0   1/1   Running
devops-kafka-controller-1   1/1   Running
devops-kafka-controller-2   1/1   Running
devops-kafka-broker-0       1/1   Running
devops-kafka-broker-1       1/1   Running
devops-kafka-broker-2       1/1   Running

4) 설정 변경 / 업그레이드

값을 바꾸면 사람이 직접 helm upgrade를 실행합니다.

# broker를 3 → 5대로 늘리고 싶다면 values 수정 후
helm upgrade devops-kafka \
  oci://registry-1.docker.io/bitnamicharts/kafka \
  -n devops-infra -f kafka-values.yaml

토픽 생성 같은 일상 작업은 Kafka CLI로 직접 합니다.

kubectl exec -it devops-kafka-broker-0 -n devops-infra -- \
  kafka-topics.sh --create --topic my-topic \
  --bootstrap-server localhost:9092 \
  --partitions 3 --replication-factor 3

실제로 깔려 있는지 확인하는 법

배포 방식을 구분하는 결정적 단서는 라벨입니다.

kubectl get sts devops-kafka-broker -n devops-infra --show-labels
# app.kubernetes.io/managed-by=Helm
# helm.sh/chart=kafka-32.4.3            ← Bitnami Helm 차트
# image: docker.io/bitnamilegacy/kafka:4.0.0-debian-12-r10

managed-by=Helm + helm.sh/chart=kafka-... 가 보이면 Bitnami(Helm) 방식입니다.

---

5. Strimzi로 Kafka 설치하기

설치 원리

Strimzi는 두 단계입니다. 먼저 오퍼레이터(관리 로봇)를 설치하고, 그다음 Kafka CR(원하는 상태)을 선언합니다. 그러면 오퍼레이터가 실제 StatefulSet/파드를 만들어냅니다.

1) 오퍼레이터 설치

kubectl create namespace kafka

# 오퍼레이터 + CRD 한 번에 설치
kubectl create -f 'https://strimzi.io/install/latest?namespace=kafka' -n kafka

이 시점에 클러스터에 CRD가 등록됩니다. 이게 Strimzi의 지문입니다.

kubectl get crd | grep strimzi
# kafkas.kafka.strimzi.io
# kafkanodepools.kafka.strimzi.io
# kafkatopics.kafka.strimzi.io
# kafkausers.kafka.strimzi.io

2) KafkaNodePool + Kafka CR 선언

요즘 Strimzi는 KRaft + NodePool 방식을 씁니다. 노드 풀로 controller/broker 역할을 나눕니다.

# controller 풀
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: controller
  labels:
    strimzi.io/cluster: my-kafka
spec:
  replicas: 3
  roles:
    - controller          # 컨트롤러 역할
  storage:
    type: persistent-claim
    size: 8Gi
---
# broker 풀
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaNodePool
metadata:
  name: broker
  labels:
    strimzi.io/cluster: my-kafka
spec:
  replicas: 3
  roles:
    - broker              # 브로커 역할
  storage:
    type: persistent-claim
    size: 20Gi
---
# Kafka 본체 (원하는 상태 선언)
apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: my-kafka
  annotations:
    strimzi.io/node-pools: enabled
    strimzi.io/kraft: enabled         # KRaft 모드
spec:
  kafka:
    version: 3.9.0
    listeners:
      - name: plain
        port: 9092
        type: internal
        tls: false
    config:
      default.replication.factor: 3
      min.insync.replicas: 2
  entityOperator:
    topicOperator: {}                  # 토픽을 CRD로 관리
    userOperator: {}                   # 유저를 CRD로 관리

kubectl apply -f kafka-cluster.yaml -n kafka

적용하면 오퍼레이터가 알아서 StatefulSet과 파드를 만듭니다. 사람이 StatefulSet을 직접 작성하지 않습니다.

3) 토픽을 "선언형"으로 관리

Strimzi의 강점입니다. 토픽도 CLI가 아니라 YAML(CRD) 로 만듭니다.

apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: my-topic
  labels:
    strimzi.io/cluster: my-kafka
spec:
  partitions: 3
  replicas: 3

kubectl apply -f my-topic.yaml -n kafka

이러면 토픽 정의가 Git에 남고, ArgoCD 같은 GitOps 도구로 관리할 수 있습니다. "토픽도 코드처럼" 다루는 것입니다.

4) 설정 변경 / 업그레이드

Kafka CR의 version을 바꾸고 kubectl apply 하면 오퍼레이터가 안전한 순서로 롤링 업그레이드를 수행합니다. 컨트롤러 → 브로커 순서, 파티션 리더 안전성 확인까지 자동입니다. 사람은 "원하는 버전"만 적습니다.

비유하자면, 다리 보수공사를 차선 하나씩 막으면서 하는 것과 같습니다. 전 차선을 동시에 막으면 교통이 마비되니, 한 차선씩 막고 차가 빠진 걸 확인한 뒤 다음 차선으로 넘어갑니다. 오퍼레이터는 브로커를 한 대씩 내려 교체하고, 그 사이 데이터가 다른 브로커에 안전하게 있는지 확인한 뒤에야 다음 대로 넘어갑니다. Helm은 이 "한 차선씩, 안전 확인하며"를 보장해주지 않아서 사람이 직접 챙겨야 합니다.

spec:
  kafka:
    version: 3.9.0   # → 4.0.0 으로 바꾸고 apply 하면 오퍼레이터가 알아서 롤링

---

6. 정면 비교

항목	Bitnami (Helm)	Strimzi (Operator)
패러다임	설치 템플릿 (한 번 찍어냄)	상주 컨트롤러 (계속 맞춰줌)
설정 방식	values.yaml → 렌더링	Kafka CRD (선언형 리소스)
설정 변경 반영	사람이 helm upgrade 실행	CR 수정 → 오퍼레이터 자동 반영
롤링 업그레이드	StatefulSet 기본 동작에 의존	오퍼레이터가 안전 순서 보장
토픽/유저 관리	CLI 수동	KafkaTopic/KafkaUser CRD (GitOps 가능)
TLS 인증서	직접 발급·갱신	오퍼레이터가 자동 발급·자동 갱신 (여권 자동 갱신처럼)
파티션 리밸런싱	수동 스크립트	Cruise Control 내장 (자동, 창고 짐 재배치처럼)
학습 곡선	낮음 (Helm만 알면 됨)	높음 (CRD·오퍼레이터 이해 필요)
리소스 오버헤드	Kafka 파드만	+ 오퍼레이터 파드 상시 점유
다른 미들웨어와 통일성	높음 (PostgreSQL·Redis 등 같은 차트군)	Kafka 전용
적합 규모	소규모·개발·POC	중대형·운영·다중 클러스터

Strimzi 장단점

장점 - Day-2 운영(업그레이드·복구·리밸런싱·인증서 갱신) 자동화가 핵심 가치입니다. Kafka는 "설치"보다 "운영"이 훨씬 어렵습니다. - 토픽·유저를 선언형으로 관리 → GitOps(ArgoCD)와 궁합이 좋습니다. - CNCF 생태계의 사실상 표준 Kafka 오퍼레이터로 커뮤니티·문서가 탄탄합니다.

자동화 두 가지를 비유로 짚으면 — - 인증서 자동 갱신: 여권은 10년마다 갱신해야 하는데, 깜빡하면 출국 당일 공항에서 막힙니다. TLS 인증서도 만료되면 통신이 끊깁니다. Strimzi는 만료 전에 알아서 새 인증서를 발급해 끼워줍니다(여권 자동 재발급 서비스가 있는 셈). - 파티션 리밸런싱(Cruise Control): 창고에서 짐이 특정 선반에만 몰리면 그 선반만 무너질 위험이 있습니다. 가끔 짐을 고르게 재배치해야 하는데, Strimzi는 이 창고 정리를 자동으로 해줍니다. Bitnami는 사람이 직접 스크립트로 옮겨야 합니다.

단점 - 개념이 무겁습니다(CRD, NodePool, 오퍼레이터 동작 모델). 입문 진입장벽이 있습니다. - 오퍼레이터 파드가 상시 떠 있어 리소스를 추가로 씁니다. 작은 단일 노드에는 부담입니다. - "Kafka 하나 띄우고 끝"이면 과합니다.

Bitnami 장단점

장점 - 간단합니다. helm install 한 줄, values.yaml만 만지면 됩니다. - 가볍습니다(별도 오퍼레이터 없음). 개발·POC에 적합합니다. - PostgreSQL·Redis·Jenkins까지 같은 Bitnami 차트군으로 통일하기 좋습니다.

단점 - Day-2 운영이 전부 수동입니다(업그레이드·리밸런싱·인증서). - 설정 변경 안전성(롤링 순서 등)이 오퍼레이터만큼 보장되지 않습니다. - 이미지 동결 이슈: 2025년 8월부터 Bitnami가 무료 카탈로그를 bitnamilegacy로 옮기고 동결했습니다. 즉 bitnamilegacy/kafka 경로는 보안 패치가 더 들어오지 않습니다. 운영 이관 시 반드시 이미지 소스를 재검토해야 합니다.

---

7. 언제 무엇을 골라야 하나

• 개발·POC, 빠르게 띄우고 싶다, 운영 자동화는 아직 불필요 → Bitnami(Helm). 단순하고 가볍습니다.
• 운영, 무중단 업그레이드·자동 복구·다중 클러스터·GitOps 토픽 관리가 필요 → Strimzi(Operator). 초기 학습 비용을 내고 운영 자동화를 얻습니다.

한 가지 현실적인 기준: "Kafka를 앞으로 얼마나 자주 손볼 것인가" 입니다. 거의 안 건드리고 한 번 띄워 쓸 거면 Helm으로 충분합니다. 버전을 자주 올리고, 토픽이 계속 늘고, 인증서를 갱신하고, 장애 복구를 자동화하고 싶다면 그 반복 작업을 대신해줄 오퍼레이터(Strimzi)의 가치가 커집니다.

---

8. 현장 이야기: Strimzi로 시작했다가 Bitnami로 바꾼 이유

이건 자료만 보고 고른 결론이 아니라, 실제로 한 바퀴 돌아본 끝에 내린 선택입니다. 순서대로 적어둡니다.

처음에 Strimzi를 고른 이유

처음엔 "Kafka는 운영이 어렵다니까 제대로 하자"는 생각이 컸습니다. 검색해보면 어디서나 Strimzi가 표준으로 나옵니다. CNCF 프로젝트이고, 상용 제품의 기반이기도 하고, 무엇보다 운영 자동화가 매력적이었습니다.

• 버전을 올릴 때 알아서 안전한 순서로 롤링해준다는 점.
• 토픽을 YAML(KafkaTopic)로 선언해서 Git에 코드처럼 관리할 수 있다는 점. 마침 우리는 ArgoCD를 쓰니 궁합도 좋아 보였습니다.
• 인증서도 알아서 갱신해준다는 점.

그때 심정은 풀옵션 신축 아파트를 계약하는 기분이었습니다. 빌트인 가전에 시스템 에어컨에 홈 오토메이션까지, "이거 하나면 살림 걱정 끝"이라는 카탈로그를 보면 안 끌릴 수가 없습니다. 그래서 적용했습니다.

써보니 불편했던 점

문제는 카탈로그의 풀옵션이, 우리가 사는 집 규모에는 과했다는 데 있었습니다.

1) 작은 클러스터에 식구가 너무 많아졌습니다. 우리 개발 클러스터는 2코어 단일 노드입니다. 그런데 Strimzi를 올리니 오퍼레이터 파드, 엔티티 오퍼레이터(토픽/유저 관리) 파드, 거기에 컨트롤러 풀과 브로커 풀 파드까지 줄줄이 떠야 했습니다. 정작 메시지를 나르는 본업(브로커)보다 그걸 관리하는 사람들이 더 북적이는 모양새가 됐습니다.

비유하자면, 원룸에 집사와 경비원과 관리소장을 다 들인 격입니다. 큰 저택이라면 이 인력이 다 제값을 하지만, 원룸에서는 정작 내가 쉴 공간을 그들이 다 차지합니다. 단일 노드에서 CPU가 늘 빠듯했던 우리 환경에선 이 오버헤드가 그대로 부담이 됐습니다.

2) 간단한 일도 한 단계를 더 거쳐야 했습니다. Strimzi에서는 내가 StatefulSet을 직접 만들지 않습니다. Kafka CR에 원하는 상태를 적으면 오퍼레이터가 대신 만들어줍니다. 잘 될 때는 편한데, 안 될 때가 문제였습니다. 파드가 안 뜨면 원인이 두 겹입니다. 내 설정이 틀린 건지, 오퍼레이터가 그걸 어떻게 해석했는지를 오퍼레이터 로그까지 들어가서 추적해야 합니다.

비유하자면, 통역사를 거쳐 대화하는 것과 같습니다. 평소엔 매끄럽지만, 말이 잘못 전달되면 "내가 잘못 말했나, 통역이 잘못 옮겼나"를 양쪽 다 확인해야 합니다. 직접 말하면(직접 매니페스트를 쓰면) 오해할 일이 한 겹 줄어듭니다.

3) 오퍼레이터 자체를 또 운영해야 했습니다. Strimzi 버전을 올리면 CRD 스키마(apiVersion)가 바뀌어 기존 리소스를 마이그레이션해야 하는 일이 생깁니다. Kafka를 편하게 운영하려고 도입한 도구인데, 그 도구를 운영하는 일이 새로 생긴 셈입니다.

비유하자면, 청소를 대신해주는 로봇청소기를 샀더니, 이번엔 로봇청소기를 청소하고 펌웨어를 업데이트해야 하는 상황입니다. 자동화가 공짜가 아니라는 걸 체감했습니다.

4) 정작 자동화의 진가를 누릴 일이 별로 없었습니다. Strimzi의 핵심 가치는 무중단 업그레이드, 자동 리밸런싱, 다중 클러스터 운영 같은 "규모가 커졌을 때" 빛납니다. 그런데 우리는 단일 클러스터에 토픽도 손에 꼽을 정도였습니다. 1년에 몇 번 있을까 한 일을 위해, 매일 리소스와 복잡도를 지불하고 있었던 것입니다.

비유하자면, 1년에 한 번 갈까 말까 한 캠핑을 위해 큰 차를 사서 매일 주차난과 기름값에 시달리는 격이었습니다.

5) 다른 미들웨어와 운영 방식이 갈렸습니다. 우리 PostgreSQL, Redis, Jenkins는 전부 Bitnami Helm 차트로 깔려 있었습니다. 그런데 Kafka만 Strimzi라, 운영하는 방식과 도구가 둘로 나뉘었습니다. "Redis는 helm upgrade로, Kafka는 CR 수정으로" 식으로 머릿속에 두 개의 매뉴얼을 들고 다녀야 했습니다.

그래서 Bitnami로 바꿨습니다

결론은 단순했습니다. 우리 규모와 단계에는 가벼운 쪽이 맞다.

• helm install 한 줄이면 끝이고, 설정은 values.yaml 하나만 봅니다.
• 별도 오퍼레이터가 없으니 단일 노드에서 리소스를 덜 먹습니다.
• PostgreSQL·Redis와 같은 Bitnami 차트군으로 통일되어, 운영 매뉴얼이 하나로 합쳐졌습니다.

풀옵션 신축에서 필요한 가구만 직접 들인 깔끔한 자취방으로 옮긴 느낌이었습니다. 자동화는 줄었지만, 우리가 실제로 쓰는 만큼만 두니 오히려 손에 잡혔습니다.

그래서 Strimzi가 나쁜 도구냐 하면, 아닙니다

오해하면 안 되는 부분입니다. Strimzi는 훌륭한 도구이고, 규모가 커지면 다시 돌아갈 후보입니다. 다중 클러스터를 운영하고, 토픽이 수십 개로 늘고, 무중단 업그레이드가 일상이 되는 순간 — 그때는 오퍼레이터가 매일 일해주는 값을 합니다.

핵심 교훈은 "표준이라서"가 아니라 "지금 우리 규모에 맞아서"로 골라야 한다는 것이었습니다. 좋은 도구와 맞는 도구는 다릅니다. 풀옵션이 항상 정답은 아니고, 자취방에는 자취방에 맞는 살림이 있습니다.

그럼 매니지드 서비스는 왜 쳐다도 안 봤나

여기서 한 번쯤 나오는 질문이 있습니다. "Strimzi가 무겁고 Bitnami가 가볍고를 따지기 전에, 그냥 매니지드 Kafka(Confluent Cloud, AWS MSK 같은)를 쓰면 운영 자체를 안 해도 되지 않냐"는 것입니다. 맞는 말이고, 실제로 많은 곳이 그렇게 합니다. 그런데 우리에겐 그게 선택지에 아예 없었습니다.

이유는 단순합니다. 우리는 처음부터 온프레미스 환경입니다. 모든 서버가 사내 물리서버이고 퍼블릭 클라우드를 쓰지 않습니다. 그런데 매니지드 Kafka는 전부 클라우드를 전제로 합니다. 클라우드를 안 쓰는 순간, 그 카탈로그는 펼쳐볼 수조차 없습니다.

더 근본적인 이유도 있었습니다. 우리가 만드는 건 클라우드에 올리는 단일 앱이 아니라, 고객 환경에 통째로 설치되는 플랫폼 제품입니다. 폐쇄망에 들어가는 경우도 있습니다. 만약 Kafka를 특정 클라우드의 매니지드에 묶어버리면, 제품이 그 클라우드에서만 돌게 됩니다. 그래서 Kafka는 제품 안에 포함되는, 어디서든 자체적으로 도는 스택이어야 했습니다.

비유하자면, 이사 다닐 때마다 들고 가는 살림과 그 집에 붙박이로 딸린 시스템 에어컨의 차이입니다. 매니지드는 그 동네(클라우드)에만 있는 붙박이라, 다른 집(온프렘·폐쇄망)으로 이사하면 두고 가야 합니다. 우리 제품은 여기저기 이사 다녀야 하니, 살림은 직접 들고 다닐 수 있는 것이어야 했습니다.

물론 매니지드가 나쁜 게 아닙니다. 오히려 맞는 상황에선 가장 편한 선택입니다.

• 좋은 점: 운영 부담이 거의 0입니다. 패치·스케일·장애복구를 벤더가 다 합니다. "Kafka 운영팀"이 필요 없고, SLA로 가용성을 보장받고, 보안 패치도 자동입니다. 건물 관리를 통째로 위탁한 셈입니다.
• 아쉬운 점: 길게 보면 비용이 큽니다(처리량·저장량·전송량마다 요금). 벤더에 종속되고, 세밀한 튜닝의 자유가 줄고, 무엇보다 데이터가 사외로 나갑니다. 보안·규제·폐쇄망 요건이 있으면 이 지점에서 막힙니다.

결국 매니지드는 "클라우드를 쓰고, Kafka 운영에 사람을 안 쓰고 싶은" 조직에 최적입니다. 우리는 온프렘 플랫폼 제품이라 정반대 자리에 있었고, 그래서 자체 호스팅이 타협이 아니라 환경이 정해준 답이었습니다. 그 자체 호스팅 안에서 Strimzi와 Bitnami를 저울질한 게 이 글의 이야기입니다.

---

9. 도입 현황: 누가 어디서 더 쓰나

자주 받는 질문이 "그래서 둘 중 뭘 더 많이 쓰냐, 대기업은 뭘 쓰냐" 입니다. 먼저 솔직하게 말하면, "몇 대 몇"으로 딱 떨어지는 공개 점유율 통계는 없습니다. 그리고 둘을 1:1로 줄세우는 것 자체가 약간 어긋난 비교입니다. 용도가 다른 도구이기 때문입니다. 그래도 방향성은 분명합니다.

서로 다른 무대의 1등

• "K8s에서 Kafka를 진지하게 운영" 하는 무대 → Strimzi가 사실상 독점적 표준입니다. 오픈소스 Kafka 오퍼레이터 중 경쟁자라 할 만한 건 상용 제품 정도뿐입니다.
• "빠르게 Kafka 하나 띄우기"(개발·POC·내부도구) 무대 → Bitnami Helm 차트가 가장 흔합니다.

즉 둘은 "누가 더 많이 쓰이냐"가 아니라 다른 무대에서 각각 1등입니다. 운영 무대는 Strimzi, 간편 설치 무대는 Bitnami.

비유하자면, 트럭과 경차를 "뭐가 더 많이 팔리냐"로 비교하는 것과 비슷합니다. 시내 출퇴근용으로는 경차가 압도적으로 많이 굴러다니고, 물류 현장에서는 트럭이 표준입니다. 길에서 더 자주 보이는 건 경차지만, 그렇다고 트럭이 인기가 없는 게 아닙니다. 무대가 다를 뿐입니다.

대기업의 현실 — 반전이 하나 있습니다

여기엔 의외의 사실이 있습니다. 상당수 대기업은 Kafka를 아예 자체 호스팅하지 않습니다. 운영 부담이 커서 매니지드 서비스(Confluent Cloud, AWS MSK, Aiven 등)를 사서 씁니다. "우리가 직접 Kafka를 돌보지 않고, 돈 내고 남에게 맡긴다"는 선택입니다.

그럼에도 직접 K8s 위에 Kafka를 굴리는 대기업이라면 방향은 이렇습니다.

• 오픈소스로 간다 → 거의 Strimzi. "대기업 + 운영 + 오픈소스 Kafka on K8s" 조합에서 Strimzi는 표준에 가깝습니다.
• 상용으로 간다 → Confluent 오퍼레이터, 또는 Red Hat의 상용 Kafka(이것도 내부는 Strimzi 기반).

반대로 Bitnami로 대기업 프로덕션 Kafka를 메인으로 굴리는 경우는 상대적으로 드뭅니다. 운영 자동화가 없어서, 규모가 커지면 사람이 떠안을 일이 감당이 안 되기 때문입니다.

정리하면: 진지하게 오래 운영하면 Strimzi(또는 매니지드) 쪽, 빠르고 가볍게 쓰면 Bitnami 쪽. 작은 단일 노드인 우리가 Bitnami로 간 건 합리적이고, 대기업 규모로 커진다면 Strimzi나 매니지드로 옮겨가는 게 자연스러운 수순입니다.

생생한 장단점, 다시 한 번

표(6장)로 정리한 걸, 이번엔 체감 위주로 풀어봅니다.

Strimzi를 쓰면 좋은 순간 - 새벽에 브로커 한 대가 죽어도, 오퍼레이터가 알아서 같은 디스크에 다시 붙여 살려놓습니다. 자다 깨서 손댈 일이 줄어듭니다. - "Kafka 3.9 → 4.0 올려라"는 지시가 떨어졌을 때, version 한 줄만 바꾸면 됩니다. 한 대씩 안전하게 교체하는 건 오퍼레이터 몫입니다. 마치 베테랑 운영자 한 명을 클러스터에 상주시킨 느낌입니다. - 토픽 100개를 Git에 YAML로 박아두면, 어느 환경에 배포하든 똑같이 재현됩니다. "이 토픽 누가 언제 왜 만들었지"가 Git 히스토리에 다 남습니다.

Strimzi를 쓰면 아픈 순간 - 파드가 안 뜨는데, 내 설정 문제인지 오퍼레이터 해석 문제인지 로그를 두 군데 봐야 합니다. 통역사를 거친 대화처럼, 오해의 출처가 한 겹 더 생깁니다. - 작은 클러스터에선 오퍼레이터·엔티티오퍼레이터·컨트롤러·브로커 파드가 줄줄이 떠서 자원을 야금야금 먹습니다. 원룸에 관리 인력만 북적이는 격입니다. - Strimzi 자체를 업그레이드할 때 CRD 마이그레이션을 챙겨야 합니다. 청소 로봇을 또 청소하는 일이 생깁니다.

Bitnami를 쓰면 좋은 순간 - helm install 한 줄로 10분 만에 Kafka가 뜹니다. 오늘 당장 메시지를 흘려보고 싶을 때 막힘이 없습니다. - values.yaml 하나만 보면 모든 설정이 거기 있습니다. 조립 설명서 한 장으로 끝나는 가구 같은 명료함입니다. - Postgres·Redis와 운영 방식이 같아, 머릿속 매뉴얼이 하나로 통일됩니다.

Bitnami를 쓰면 아픈 순간 - 버전 업그레이드 시 "한 대씩 안전하게"를 사람이 직접 신경 써야 합니다. 잘못하면 메시지가 샙니다. - 인증서 만료, 파티션 쏠림 같은 걸 아무도 대신 안 봐줍니다. 알림 없는 여권 만료처럼, 터지고 나서야 압니다. - 그리고 현실적 함정 하나 — bitnamilegacy 이미지는 보안 패치가 멈춘 경로라, 오래 운영하려면 이미지 출처를 갈아끼워야 합니다.

---

10. 용어집

• Kafka: 분산 메시지 스트리밍 플랫폼. 메시지를 토픽에 쌓고 여러 소비자가 나눠 읽습니다.
• StatefulSet: 고정 이름·고정 디스크·순서를 보장하는 K8s 리소스. 상태를 가진 앱(Kafka, DB)에 씁니다.
• PVC(PersistentVolumeClaim): 파드가 죽어도 유지되는 영속 디스크 요청. 파드가 다시 떠도 같은 데이터에 붙습니다.
• ZooKeeper: 과거 Kafka의 메타데이터를 대신 관리하던 별도 시스템. KRaft로 대체되는 중입니다.
• KRaft (Kafka Raft): ZooKeeper를 없애고 Kafka가 자기 메타데이터를 직접 관리하는 모드. Raft 합의 알고리즘 사용.
• controller / broker: KRaft에서의 역할. 컨트롤러는 메타데이터·합의, 브로커는 실제 메시지 처리.
• Helm: K8s용 패키지 매니저 + 템플릿 엔진. values.yaml로 매니페스트를 찍어냅니다.
• Operator: 클러스터 안에 상주하며 CRD를 보고 원하는 상태를 유지하는 컨트롤러.
• CRD(Custom Resource Definition): K8s에 새 리소스 종류를 추가하는 확장. Strimzi의 Kafka, KafkaTopic 등.
• 리컨실레이션(reconciliation): 현재 상태와 원하는 상태를 비교해 차이를 메우는 오퍼레이터의 조정 루프.
• Cruise Control: Kafka 파티션을 자동으로 재배치(리밸런싱)해주는 도구. Strimzi에 통합돼 있습니다.

---

참고

• Apache Kafka 공식 문서 (KRaft): https://kafka.apache.org/documentation/#kraft
• Strimzi 공식 문서: https://strimzi.io/docs/operators/latest/overview
• Bitnami Kafka 차트: https://github.com/bitnami/charts/tree/main/bitnami/kafka
• Bitnami 카탈로그 변경(legacy 이전) 공지: https://github.com/bitnami/charts/issues/35164