Kafka란 무엇이며 현대 시스템에서는 어떻게 사용되나요?

Kafka를 쉽게 풀어 설명하면

Apache Kafka는 분산 이벤트 스트리밍 플랫폼입니다. 간단히 말해, 여러 시스템이 무슨 일이 일어났는지를 게시(publish)하고 다른 시스템이 그 사실을 빠르게, 대규모로, 순서대로 읽을 수 있게 해 주는 공유되고 내구성 있는 "파이프"입니다.

시스템 간에 느슨한 결합으로 안정적으로 데이터가 이동해야 할 때 팀들은 Kafka를 사용합니다. 한 애플리케이션이 다른 애플리케이션을 직접 호출하면 상대가 다운되거나 느릴 때 실패할 수 있지만, 프로듀서는 이벤트를 Kafka에 기록합니다. 컨슈머는 준비되었을 때 읽습니다. Kafka는 이벤트를 설정한 기간 동안 저장하므로 시스템이 장애에서 복구하고 이력을 재처리할 수 있습니다.

자주 보는 용어 몇 가지

• 이벤트 / 메시지: 무슨 일이 발생했는지를 기록한 레코드(예: “OrderPlaced”, “PaymentFailed”). '메시지'라고도 하지만 '이벤트'는 실제 세계의 변화임을 강조합니다.
• 스트림: 시간에 따라 지속적으로 흐르는 이벤트의 연속입니다.
• 로그: Kafka는 이벤트를 추가 전용(append-only) 로그로 조직합니다—새 이벤트는 끝에 추가되고 리더는 자신의 속도로 앞으로 이동합니다.

이 가이드는 누구를 위한 것인가(그리고 무엇을 배우나)

이 가이드는 제품 관점을 가진 엔지니어, 데이터 담당자, 기술 리더를 위한 것으로, Kafka에 대한 실무적 멘탈 모델을 제공합니다.

핵심 구성 요소(프로듀서, 컨슈머, 토픽, 브로커), 파티션으로 확장하는 방법, 이벤트를 저장하고 재생성하는 방식, 이벤트 기반 아키텍처에서의 위치를 배우게 됩니다. 또한 일반적인 사용 사례, 전달 보장, 보안 기초, 운영 계획, Kafka가 적절하거나 적절하지 않은 경우도 다룹니다.

핵심 개념: 프로듀서, 컨슈머, 토픽, 브로커

Kafka는 공유 이벤트 로그로 이해하면 쉽습니다: 애플리케이션이 이벤트를 쓰고 다른 애플리케이션이 나중에(대개 실시간으로) 그 이벤트를 읽습니다—때로는 몇 시간, 며칠 뒤일 수도 있습니다.

프로듀서와 컨슈머

프로듀서는 쓰는 쪽입니다. 예를 들어 "주문 생성(order placed)", "결제 완료(payment confirmed)", "온도 측정" 같은 이벤트를 발행할 수 있습니다. 프로듀서는 특정 앱에 직접 이벤트를 보내지 않고 Kafka에 보냅니다.

컨슈머는 읽는 쪽입니다. 대시보드를 갱신하거나, 배송 워크플로를 트리거하거나, 분석용으로 데이터를 적재할 수 있습니다. 컨슈머는 이벤트를 어떻게 처리할지 결정하며 자신의 속도로 읽을 수 있습니다.

토픽: 이벤트를 조직화하기

Kafka의 이벤트는 토픽이라는 이름 붙여진 카테고리로 그룹화됩니다. 예:

• orders — 주문 관련 이벤트
• payments — 결제 이벤트
• inventory — 재고 변경

토픽은 해당 이벤트 유형의 “진실의 출처(source of truth)” 스트림이 되어 여러 팀이 일회성 통합을 만들지 않고도 같은 데이터를 재사용하기 쉽게 합니다.

브로커와 클러스터

브로커는 이벤트를 저장하고 컨슈머에 제공하는 Kafka 서버입니다. 실제 운영에서는 여러 브로커가 함께 동작하는 클러스터로 실행되어 더 많은 트래픽을 처리하고 머신 장애 시에도 서비스를 유지합니다.

컨슈머 그룹: 작업을 중복 없이 확장하기

컨슈머는 보통 컨슈머 그룹으로 실행됩니다. Kafka는 그룹 내에서 읽기 작업을 분산시키므로 컨슈머 인스턴스를 늘려 처리량을 확장할 수 있습니다—모든 인스턴스가 동일 작업을 반복하지 않습니다.

토픽과 파티션이 Kafka를 확장하는 방법

Kafka는 관련 이벤트 스트림인 토픽을 만들고, 각 토픽을 더 작은 독립 단위인 파티션으로 나누어 확장합니다.

파티션 = 병렬성 및 처리량

파티션이 하나뿐인 토픽은 컨슈머 그룹 내에서 한 번에 하나의 컨슈머만 읽을 수 있습니다. 파티션을 늘리면 이벤트를 병렬로 처리할 수 있는 컨슈머도 늘릴 수 있습니다. 이것이 Kafka가 높은 볼륨의 이벤트 스트리밍과 실시간 데이터 파이프라인을 지원하는 방식입니다.

파티션은 또한 부하를 브로커들에 분산시키는 데 도움이 됩니다. 하나의 기계가 토픽의 모든 쓰기와 읽기를 처리하는 대신 여러 브로커가 서로 다른 파티션을 호스팅해 트래픽을 나눕니다.

순서 보장: Kafka가 보장하는 것(그리고 보장하지 않는 것)

Kafka는 단일 파티션 내의 순서를 보장합니다. 이벤트 A, B, C가 같은 파티션에 그 순서로 쓰였다면 컨슈머는 A → B → C 순서로 읽습니다.

파티션 간 순서는 보장되지 않습니다. 특정 엔터티(고객, 주문 등)에 대해 엄격한 순서가 필요하면 해당 엔터티의 모든 이벤트가 같은 파티션으로 가도록 설계합니다.

키가 이벤트의 위치를 결정한다

프로듀서가 이벤트를 보낼 때 키(예: order_id)를 포함할 수 있습니다. Kafka는 키를 사용해 관련 이벤트를 동일 파티션으로 일관되게 라우팅합니다. 이렇게 하면 그 키에 대해 예측 가능한 순서를 유지하면서도 전체 토픽은 여러 파티션에 걸쳐 확장할 수 있습니다.

복제(replica)로 데이터 가용성 확보

각 파티션은 다른 브로커에 복제될 수 있습니다. 한 브로커가 실패하면 복제본을 가진 다른 브로커가 대신 역할을 맡을 수 있습니다. 복제는 Kafka가 미션 크리티컬한 pub-sub 메시징과 이벤트 기반 시스템에서 신뢰받는 주요 이유 중 하나로, 애플리케이션이 별도의 페일오버 로직을 만들 필요 없이 가용성과 내결함성을 제공합니다.

저장, 보관, 이벤트 재생

Apache Kafka의 핵심 아이디어는 이벤트가 단순히 전달되는 것이 아니라 디스크에 순서대로 기록된다는 점입니다. 소비자는 지금 읽을 수도 있고, 나중에 읽을 수도 있습니다. 이 때문에 Kafka는 데이터 이동뿐 아니라 무슨 일이 일어났는지에 대한 내구성 있는 이력을 보관하는 데 유용합니다.

이벤트는 "전송 중" 상태만이 아니다 — 영속화된다

프로듀서가 이벤트를 토픽에 보내면 Kafka는 이를 브로커의 스토리지에 추가합니다. 컨슈머는 저장된 로그에서 자신의 속도로 읽습니다. 컨슈머가 한 시간 동안 다운되어도 이벤트는 남아있어 복구 후 따라잡을 수 있습니다.

보관(retention): Kafka가 데이터를 얼마나 오래 보관하나

Kafka는 다음과 같은 보관 정책에 따라 이벤트를 보관합니다:

• 시간 기반 보관: 예를 들어 7일간 보관
• 크기 기반 보관: 로그가 설정한 크기에 도달할 때까지 보관하고, 이후 가장 오래된 데이터부터 삭제

보관은 토픽별로 설정하므로 감사 트레일 토픽과 고빈도 텔레메트리 토픽을 다르게 취급할 수 있습니다.

컴팩션(compaction): 키별 최신 값만 유지하기

어떤 토픽은 완전한 이력보다 변경 로그 성격이 강합니다(예: "현재 고객 설정"). 로그 컴팩션은 각 키에 대해 최신 이벤트를 최소한으로 유지하고 오래된 대체된 레코드는 제거합니다. 이렇게 하면 최신 상태의 내구성 있는 진실의 출처를 유지하면서 무한한 데이터 증가를 막을 수 있습니다.

이벤트 재생: 상태 재구성과 버그 복구

이벤트가 저장되어 있기 때문에 다음과 같은 재생이 가능합니다:

• 검색 인덱스나 물리화된 뷰를 처음부터 재구성
• 잘못된 배포 후 서비스를 복구하기 위해 이전 지점부터 재처리
• 신규 컨슈머를 온보딩하고 히스토리 데이터를 읽도록 허용

실무에서는 컨슈머가 어디서부터 읽기 시작할지(오프셋)로 재생을 제어하므로 시스템이 진화할 때 강력한 안전망을 제공합니다.

신뢰성 및 내결함성 기초

Kafka는 시스템 일부가 실패하더라도 데이터 흐름을 유지하도록 설계되었습니다. 이는 복제, 각 파티션의 "책임자"에 대한 명확한 규칙, 그리고 구성 가능한 **쓰기 인정(acknowledgments)**으로 달성됩니다.

복제: 리더와 팔로워(개념 수준)

각 토픽 파티션에는 하나의 리더 브로커와 하나 이상의 팔로워 복제본이 있습니다. 프로듀서와 컨슈머는 해당 파티션의 리더와 통신합니다.

팔로워는 리더의 데이터를 지속해서 복사합니다. 리더가 다운되면 Kafka는 최신 상태인 팔로워를 승격시켜 새로운 리더로 만들어 파티션의 가용성을 유지할 수 있습니다.

브로커 장애 시 무슨 일이 일어나나(간단히)

브로커가 실패하면 그 브로커가 리더로 호스팅하던 파티션들은 잠시 이용 불가가 됩니다. Kafka의 컨트롤러가 실패를 감지하고 해당 파티션들에 대해 리더 선출(leader election) 을 트리거합니다.

충분히 따라잡은 팔로워가 있다면 그 팔로워가 리더가 되어 클라이언트는 생산/소비를 재개합니다. 만약 동기화된 복제본(in-sync replica)이 없다면 Kafka는 설정에 따라 쓰기를 중단해 인정된 데이터를 잃지 않도록 할 수 있습니다.

내구성: acks와 복제 인자

내구성은 주로 두 가지 설정으로 결정됩니다:

• 복제 인자(replication factor): 각 파티션의 복제본 수(예: 3)
• 인정(acks): 프로듀서가 쓰기를 성공으로 간주할 때까지 기다리는 정도

개념적으로:

• acks=0: 프로듀서는 기다리지 않음—빠르지만 메시지를 잃을 수 있음
• acks=1: 리더가 쓰기를 확인—더 낫지만 리더가 팔로워로 복사하기 전에 실패하면 최근 메시지를 잃을 수 있음
• acks=all(또는 -1): 리더가 동기화된 복제본의 확인을 기다림—안전하지만 약간 느림

재시도 중 중복을 줄이려면 보통 더 안전한 acks 설정과 멱등 프로듀서, 견고한 컨슈머 처리를 결합합니다.

지연 시간과 안전성의 트레이드오프

안전성을 높이면 더 많은 확인을 기다리고 더 많은 복제본을 동기화해야 하므로 지연 시간과 최종 처리량이 늘어날 수 있습니다.

지연 시간을 낮추는 설정은 텔레메트리나 클릭스트림처럼 일시적 손실이 허용되는 데이터에 적합할 수 있지만 결제, 재고, 감사 로그 같은 경우는 추가 안전을 우선시하는 것이 일반적입니다.

이벤트 기반 아키텍처에서의 Kafka 역할

이벤트 기반 아키텍처(EDA)는 비즈니스에서 발생하는 사건(주문 생성, 결제 승인, 발송 등)을 다른 시스템이 반응할 수 있는 이벤트로 표현하는 방식입니다.

이벤트 발행, 컨슈머로 반응

Kafka는 종종 공유 "이벤트 스트림"의 중심에 위치합니다. 서비스 A가 서비스 B를 직접 호출하는 대신, 서비스 A는 Kafka 토픽에 OrderCreated 같은 이벤트를 발행합니다. 여러 서비스가 그 이벤트를 구독해 이메일 발송, 재고 예약, 사기 검사 등을 수행할 수 있으며, 서비스 A는 이들 존재를 알 필요가 없습니다.

느슨한 결합(직접 의존성 감소)

서비스들이 이벤트를 통해 통신하므로 모든 상호작용에 대해 요청/응답 API를 조율할 필요가 없습니다. 이는 팀 간의 강한 의존성을 줄이고 새로운 기능 추가를 쉽게 만듭니다: 기존 프로듀서를 변경하지 않고도 새로운 컨슈머를 추가할 수 있습니다.

비동기 워크플로와 트래픽 스파이크 견디기

EDA는 본질적으로 비동기적입니다: 프로듀서는 빠르게 이벤트를 쓰고 컨슈머는 자신의 속도로 처리합니다. 트래픽 스파이크 시 Kafka는 다운스트림 시스템이 즉시 과부하되지 않도록 버퍼 역할을 합니다. 컨슈머는 스케일 아웃해 따라잡을 수 있고, 하나의 컨슈머가 일시적으로 다운돼도 오프셋부터 다시 이어서 처리할 수 있습니다.

실무적 멘탈 모델

Kafka를 시스템의 "활동 피드(activity feed)"로 생각하세요. 프로듀서는 사실을 발행하고 컨슈머는 자신이 관심 있는 사실을 구독합니다. 이 패턴은 실시간 데이터 파이프라인과 이벤트 기반 워크플로를 가능하게 하면서 서비스들을 단순하고 독립적으로 유지합니다.

현대 시스템에서의 일반적인 Kafka 활용 사례

Kafka는 많은 작고 독립적인 “발생한 사실(이벤트)”을 여러 시스템 사이에서 빠르고 신뢰성 있게, 여러 소비자가 재사용할 수 있게 전달해야 할 때 자주 사용됩니다.

활동 추적 및 감사 로그

애플리케이션은 종종 사용자 로그인, 권한 변경, 레코드 업데이트, 관리자 작업 같은 추가 전용 히스토리가 필요합니다. Kafka는 이러한 이벤트의 중앙 스트림으로 잘 작동하여 보안 도구, 리포팅, 컴플라이언스 추출이 동일한 소스를 읽도록 합니다. 이벤트가 일정 기간 보관되므로 버그나 스키마 변경 후에도 감사 뷰를 재구성하기 위해 재생할 수 있습니다.

이벤트 기반 마이크로서비스 통신

서비스들이 서로 직접 호출하는 대신 "주문 생성", "결제 수신" 같은 이벤트를 발행할 수 있습니다. 다른 서비스들은 구독해서 각자 처리합니다. 이는 강한 결합을 줄이고 부분 장애 동안 시스템이 계속 동작하도록 돕고, 기존 이벤트 스트림을 소비함으로써 사기 검사 같은 새로운 기능을 쉽게 추가할 수 있게 합니다.

분석 및 웨어하우스로의 데이터 파이프라인

Kafka는 운영 시스템에서 애널리틱스 플랫폼으로 데이터를 옮기는 공통 백본입니다. 팀은 애플리케이션 데이터베이스의 변경을 스트리밍해 웨어하우스나 데이터 레이크로 낮은 지연으로 전달하면서 프로덕션 앱을 무거운 조회로부터 분리할 수 있습니다.

IoT 및 버스트 트래픽을 가지는 텔레메트리

센서, 디바이스, 앱 텔레메트리는 종종 버스트로 도착합니다. Kafka는 버스트를 흡수해 안전하게 버퍼링하고 다운스트림 처리기가 따라잡을 수 있게 해줍니다—모니터링, 알림, 장기 분석에 유용합니다.

Kafka 생태계: Connect, Streams, 도구들

Kafka는 브로커와 토픽만 있는 것이 아닙니다. 대부분의 팀은 일상적 데이터 이동, 스트림 처리, 운영을 실용적으로 만들어 주는 도구들을 함께 사용합니다.

Kafka Connect: 코드 없이 데이터 이동

Kafka Connect는 데이터를 Kafka로 들여오거나 Kafka에서 내보낼 수 있는 통합 프레임워크입니다(소스와 싱크). 일회성 파이프라인을 직접 만들고 유지하는 대신 Connect를 실행하고 커넥터를 설정합니다.

일반 예로는 DB에서 변경을 끌어오기, SaaS 이벤트 수집, Kafka 데이터를 데이터 웨어하우스나 오브젝트 스토리지로 전달하기 등이 있습니다. Connect는 재시도, 오프셋, 병렬성 같은 운영 이슈도 표준화합니다.

Kafka Streams: 앱 내부의 실시간 처리

Connect가 통합용이라면 Kafka Streams는 계산용입니다. 애플리케이션에 추가하는 라이브러리로 스트림을 실시간으로 변환(필터, 보강, 조인, 집계)합니다.

Streams 앱은 토픽을 읽고 결과를 다시 토픽에 쓰기 때문에 이벤트 기반 시스템에 자연스럽게 맞고 인스턴스를 늘려 스케일할 수 있습니다.

스키마 관리: 이벤트 일관성 유지

여러 팀이 이벤트를 발행하면 일관성이 중요합니다. 스키마 레지스트리 같은 스키마 관리는 이벤트의 필드와 진화 방식을 정의해 생산자가 필드를 변경해 소비자가 깨지는 상황을 막습니다.

도구들: 중요한 것을 모니터링하기

Kafka는 운영에 민감하므로 기본 모니터링은 필수입니다:

• 컨슈머 라그(consumer lag): 컨슈머가 뒤처지고 있는가?
• 처리량(throughput): 초당 몇 건의 이벤트가 흐르는가?
• 에러: fetch 실패, produce 에러, 커넥터 작업 실패

대부분의 팀은 운영 UI와 자동화로 배포, 토픽 구성, 접근 제어 정책을 관리합니다(참고: /blog/kafka-security-governance).

전달 보장과 처리 패턴

Kafka는 보통 "내구성 있는 로그 + 컨슈머"로 설명되지만, 실제로 팀이 가장 신경 쓰는 건: 이벤트를 각 한 번만 처리할 수 있나? 실패 시 어떻게 되나? 입니다. Kafka는 빌딩 블록을 제공하고 여러분이 트레이드오프를 선택합니다.

전달 보장(개념적 수준)

최대 한 번(at-most-once): 이벤트를 잃을 수 있지만 중복은 없음. 컨슈머가 위치를 먼저 커밋하고 작업을 마치기 전에 다운되면 발생합니다.

최소 한 번(at-least-once): 이벤트를 잃지 않지만 중복이 발생할 수 있음—가장 흔한 기본 패턴입니다.

정확히 한 번(exactly-once): 손실과 중복을 모두 피하려는 것. Kafka에서는 보통 트랜잭셔널 프로듀서와 호환되는 처리(종종 Kafka Streams)를 통해 달성합니다. 강력하지만 제약이 있고 신중한 설정이 필요합니다.

멱등성과 중복 제거

실무에서는 많은 시스템이 at-least-once를 수용하고 다음과 같은 안전장치를 추가합니다:

• 멱등성 쓰기: 동일 이벤트를 여러 번 적용해도 안전하도록 설계(예: 업서트, 조건부 업데이트, 유니크 키)
• 중복 제거: 이벤트 ID나 비즈니스 키를 저장하고 일정 기간 내 반복을 무시

컨슈머 오프셋: 당신의 "북마크"

컨슈머 오프셋은 파티션에서 마지막으로 처리한 레코드의 위치입니다. 오프셋을 커밋하면 "여기까지 끝냈다"고 표시하는 것입니다. 일찍 커밋하면 손실 위험이 있고, 늦게 커밋하면 크래시 후 중복 처리가 늘어납니다.

재시도와 포이즌 메시지

재시도는 한정적이고 가시적이어야 합니다. 일반적 패턴:

1. 일시적 오류에 대해 백오프와 함께 재시도,
2. 그 후 실패 레코드를 데드레터 토픽으로 전송해 검사와 재처리를 가능하게 함

이렇게 하면 하나의 문제 레코드가 전체 컨슈머 그룹을 막지 않으면서 데이터도 보존합니다.

보안 및 거버넌스 고려사항

Kafka는 종종 주문, 결제, 사용자 활동 같은 비즈니스에 중요한 이벤트를 실어나릅니다. 따라서 보안과 거버넌스는 설계의 일부여야 합니다.

인증과 권한 부여

인증은 "당신은 누구인가?"를 확인하고 권한은 "무엇을 할 수 있는가?"를 정합니다. Kafka에서는 일반적으로 SASL(SCRAM, Kerberos 등)로 인증하고 ACL(액세스 제어 목록)으로 토픽·컨슈머 그룹·클러스터 수준의 권한을 관리합니다.

실무 패턴은 최소 권한 원칙: 프로듀서는 자신이 소유한 토픽에만 쓸 수 있고, 컨슈머는 필요한 토픽만 읽을 수 있게 해 자격 증명 유출 시 영향 범위를 줄입니다.

전송 중 암호화(TLS)

TLS는 애플리케이션, 브로커, 도구 간에 이동하는 데이터를 암호화합니다. 내부 네트워크에서도 이벤트가 가로채질 수 있으므로 TLS가 필요하며, 브로커 식별을 검증해 중간자 공격을 막는 데도 도움됩니다.

멀티테넌트 Kafka와 네이밍 규칙

여러 팀이 클러스터를 공유할 때는 가드레일이 필요합니다. 명확한 토픽 네이밍 규칙(예: <팀>.<도메인>.<이벤트>.<버전>)은 소유권을 분명히 하고 정책 적용을 쉽게 합니다.

네이밍과 함께 쿼터 및 ACL 템플릿을 도입해 한 워크로드가 다른 워크로드를 고갈시키지 않도록 하고, 새 서비스가 안전한 기본값으로 시작하도록 합니다.

데이터 거버넌스: PII, 보관, 정책 정렬

Kafka를 이벤트 이력의 시스템 오브 레코드로 취급하려면 의도적으로 하세요. 이벤트에 PII가 포함된다면 데이터 최소화(전체 프로필 대신 ID 전송), 필드 수준 암호화 고려, 민감 토픽 문서화 등을 하세요.

보관 설정은 법적·비즈니스 요구에 맞춰야 합니다. 정책이 "30일 후 삭제"라면 6개월치를 그냥 보관하지 마세요. 정기적 검토와 감사를 통해 설정을 정렬하세요.

Kafka 운영: 팀이 계획해야 할 것들

Apache Kafka 운영은 "설치하고 잊어버리기"가 아닙니다. 공유 유틸리티처럼 행동하며 많은 팀이 의존하므로 작은 실수도 하류 앱에 영향을 줍니다.

용량 계획 기초

Kafka 용량 계획은 주기적으로 재검토해야 하는 수학 문제입니다. 주요 요소는 파티션 수(병렬성), 처리량(MB/s in/out), 스토리지 증가(보관 기간)입니다.

트래픽이 두 배가 되면 부하 분산을 위해 더 많은 파티션, 보관을 담을 더 많은 디스크, 복제를 위한 네트워크 여유가 필요할 수 있습니다. 실무 습관은 피크 쓰기율을 예측하고 보관 기간을 곱해 디스크 증가량을 추정한 뒤 복제와 예기치 못한 성공을 위한 버퍼를 더하는 것입니다.

일상 운영 작업

서버를 유지하는 것 외에도 다음과 같은 작업이 필요합니다:

• 업그레이드: 롤링 업그레이드 계획, 클라이언트 호환성 테스트, 트래픽이 낮은 시간에 스케줄
• 리밸런싱: 컨슈머 그룹 리밸런스는 짧은 일시 중단을 유발할 수 있으므로 안전한 배포 패턴과 명확한 소유권 필요
• 사건 대응: 브로커 장애, 디스크 가득참, 잘못 구성된 프로듀서가 토픽을 폭주시키는 상황에 대한 플레이북

비용 요인과 배포 선택

비용은 디스크, 네트워크 아웃(egress), 브로커 수/크기로 결정됩니다. 매니지드 Kafka는 운영 부담을 줄이고 업그레이드를 단순화하지만, 자체 호스팅은 경험 있는 운영팀이 있다면 규모에 따라 더 저렴할 수 있습니다. 트레이드오프는 복구 시간과 온콜 부담입니다.

측정해야 할 지표(추측하지 않으려면)

팀은 보통 다음을 모니터링합니다:

• 엔드투엔드 지연(latency) (프로듀스부터 컨슘까지)
• 컨슈머 라그 (컨슈머가 얼마나 뒤처졌나)
• 브로커 상태 (디스크 사용량, 언더리플리케이티드 파티션, 요청 에러율)

좋은 대시보드와 알림은 Kafka를 "미스테리 박스"에서 이해 가능한 서비스로 바꿉니다.

Kafka를 선택할 때(그리고 선택하지 말아야 할 때)

Kafka는 많은 이벤트를 신뢰성 있게 이동시키고, 일정 기간 보관하며, 여러 시스템이 같은 데이터를 각자 처리해야 하고, 이벤트를 재생할 수 있어야 할 때 강력한 선택입니다. 특히 재생 기능이 중요하거나 향후 생산자/컨슈머가 늘어날 것으로 예상될 때 유용합니다.

Kafka가 빛을 발하는 경우

다음과 같은 상황에서 Kafka는 탁월합니다:

• 고처리량 이벤트 스트림(클릭, 주문, 센서 데이터)
• 동일 이벤트를 필요로 하는 다수의 컨슈머(애널리틱스, 모니터링, 사기 탐지, 알림)
• 재생과 장기 이력이 기능으로 필요한 경우
• 팀과 서비스의 결합을 줄이는 통합 작업이 필요한 경우

Kafka가 너무 무거운 경우

필요가 단순하면 Kafka는 과잉일 수 있습니다:

• 두 서비스 간의 저빈도 단일 큐
• 재생 가치가 없는 단기 작업(백그라운드 잡)
• 분산 시스템을 운영하고 모니터링할 시간이나 인력이 없는 팀

이 경우 클러스터 용량 계획, 업그레이드, 모니터링, 온콜 등의 운영 비용이 이점을 넘을 수 있습니다.

대안 및 보완 기술

• RabbitMQ: 전통적인 워크 큐와 라우팅 패턴에 적합
• NATS: 낮은 지연의 경량 메시징
• 클라우드 퍼브/서브(pub/sub): 관리형 인프라와 단순한 운영을 원할 때 유리

Kafka는 데이터베이스(시스템 오브 레코드), 캐시(빠른 읽기), 배치 ETL(대규모 주기적 변환)을 대체하는 것이 아니라 보완합니다.

빠른 결정 체크리스트

자문해 보세요:

1. 여러 컨슈머와 재생이 필요한가?
2. 처리량이 크게 성장할 것인가?
3. 이벤트 이력/보관이 기능적으로 필요한가?
4. 운영 소유권을 감당할 수 있나(또는 매니지드 Kafka를 사용할 것인가)?
5. 우리는 명령/작업을 보내는 것이 아니라 이벤트를 스트리밍하려는가?

대부분에 '예'라면 Kafka는 보통 합리적인 선택입니다.

시작하기: 간단한 도입 경로

Kafka는 다수의 시스템이 사실(주문 생성, 결제 승인, 재고 변경)을 생산하고 다수의 시스템이 그 사실을 소비해 파이프라인, 분석, 반응형 기능을 구동할 때 가장 잘 맞습니다.

1단계: 하나의 구체적 사용 사례 선택

초기에는 좁고 가치 있는 흐름 하나로 시작하세요—예: 다운스트림 서비스(이메일, 사기 검사, 이행)를 위한 OrderPlaced 이벤트 발행. 첫날부터 Kafka를 모든 용도의 큐로 만들지 마세요.

2단계: 이벤트와 토픽 정의

다음 사항을 문서화하세요:

• 이벤트: 비즈니스 관점에서 무슨 일이 일어났는지
• 토픽: 이벤트가 어디에 위치할지(보통 이벤트 타입 또는 도메인별 토픽)
• 컨슈머: 어떤 팀/서비스가 왜 이벤트를 필요로 하는지

초기 스키마는 단순하고 일관되게 유지하세요(타임스탬프, ID, 명확한 이벤트 이름). 스키마를 초기부터 강제할지, 점진적으로 진화시킬지 결정하세요.

3단계: 소유권과 운영 기초 확립

Kafka가 성공하려면 누군가가 책임져야 합니다:

• 토픽 생성과 네이밍 규칙
• 보관과 접근 정책
• 온콜 책임과 런북

즉시 모니터링(컨슈머 라그, 브로커 헬스, 처리량, 에러율)을 추가하세요. 플랫폼 팀이 없다면 매니지드 제공을 사용하고 명확한 한계를 정하세요.

4단계: "얇은(thin)" 첫 파이프라인 구축

한 시스템에서 이벤트를 생성하고 한 곳에서 이를 소비해 엔드투엔드 루프를 증명하세요. 그 다음 더 많은 컨슈머, 파티션, 통합으로 확장하세요.

아이디어에서 작동하는 이벤트 기반 서비스로 빠르게 이동하고 싶다면 Koder.ai 같은 도구가 주변 애플리케이션(React UI, Go 백엔드, PostgreSQL)을 프로토타입하는 데 도움을 줄 수 있습니다. 채팅 기반 워크플로로 프로듀서/컨슈머를 빠르게 추가하고 내부 대시보드나 경량 서비스에 유용한 기능(플래닝 모드, 소스 코드 내보내기, 배포/호스팅, 스냅샷 및 롤백)을 제공합니다.

이벤트 기반 접근법 매핑은 /blog/event-driven-architecture를 참고하세요. 비용과 환경 계획은 /pricing을 확인하세요.