Kafka는 일반 메시지 큐와 무엇이 다른가요?

Kafka는 메시지를 소비한 뒤 즉시 없애는 단순 작업 분배만을 목표로 하지 않습니다. 이벤트를 토픽에 보존하고, 여러 소비자 그룹이 독립적으로 읽으며, 보존 기간 안에서는 과거 위치부터 다시 읽을 수 있다는 점이 핵심입니다. 따라서 다수 시스템의 데이터 배포와 재처리가 필요한 경우에 특히 적합합니다.

Kafka에서 이벤트 순서는 항상 보장되나요?

아닙니다. 순서는 토픽 전체가 아니라 각 파티션 안에서 보장됩니다. 같은 고객이나 주문처럼 순서가 중요한 단위의 이벤트에는 같은 키를 사용해 동일 파티션으로 보내는 방식이 일반적입니다. 전체 이벤트에 단일한 순서가 꼭 필요하면 병렬 처리 능력에 제약이 생깁니다.

Kafka를 쓰면 메시지가 중복 없이 정확히 한 번 처리되나요?

소비자 장애 등을 고려하면 기본적인 소비 설계는 중복 가능성을 전제로 해야 합니다. Kafka 내부에서 읽기·처리·쓰기를 연결하는 경우에는 트랜잭션과 read_committed 설정으로 정확히 한 번 처리 구성을 할 수 있지만, 외부 데이터베이스나 API 호출 같은 부수 효과까지 자동으로 정확히 한 번 처리되는 것은 아닙니다.

처음부터 Kafka를 도입해야 하는 팀은 어떤 팀인가요?

여러 독립 시스템이 같은 이벤트를 사용하고, 과거 이벤트의 재처리와 지속적인 대량 데이터 흐름이 중요하며, 토픽 정책·스키마·모니터링·장애 대응을 운영할 책임 주체가 있는 팀이라면 검토할 근거가 큽니다. 단일 소비자에게 단순 작업을 넘기는 정도라면 더 단순한 대안부터 비교하는 편이 합리적일 수 있습니다.

Apache Kafka는 언제 도입을 고려하면 좋을까?

작성·검토 쉬었음.com발행 2026년 9월 12일

Apache Kafka는 여러 시스템이 같은 이벤트를 독립적으로 받아 처리하고, 이벤트 이력을 일정 기간 보존해 나중에 다시 읽어야 할 때 도입을 고려할 만한 분산 이벤트 스트리밍 플랫폼입니다. 단순히 비동기 처리가 필요하다는 이유만으로 선택하기보다, 다중 구독·대량 처리·재처리·장애 허용이 함께 필요한지를 기준으로 판단하는 것이 좋습니다. kafka.apache.org

Kafka는 흔히 "메시지 큐"로 소개되지만, 그 표현만으로는 핵심을 모두 설명하기 어렵습니다. 주문 생성, 결제 완료, 고객 행동, 시스템 로그처럼 어떤 사실이 발생했다는 기록을 이벤트로 남기고, 이를 여러 애플리케이션과 데이터 시스템이 각자의 속도로 읽게 만드는 데 강점이 있기 때문입니다. 반면 작은 서비스에서 한 종류의 백그라운드 작업을 한 번 처리하는 목적이라면 Kafka의 운영 복잡성이 이점보다 클 수 있습니다.

이 글에서는 Kafka가 해결하는 문제를 먼저 정의하고, 어떤 신호가 있을 때 도입 가치가 커지는지, 설계와 운영에서 무엇을 감수해야 하는지를 차례로 살펴봅니다.

Kafka는 무엇을 하는 플랫폼인가요?

Kafka는 이벤트를 기록하는 토픽(topic)을 중심으로 동작합니다. 이벤트란 "주문이 생성되었다", "사용자가 상품을 조회했다", "센서 온도가 측정되었다"처럼 시스템에서 일어난 사실을 표현한 데이터 레코드입니다. 이벤트를 쓰는 애플리케이션은 생산자(producer), 읽어 처리하는 애플리케이션은 소비자(consumer)라고 부릅니다. kafka.apache.org

생산자는 토픽에 이벤트를 발행하고, 소비자는 필요한 토픽을 구독해 읽습니다. 이때 생산자는 누가 그 이벤트를 읽는지 직접 알 필요가 없습니다. 분석 서비스, 알림 서비스, 검색 색인 서비스가 나중에 추가되어도, 원칙적으로 주문 서비스가 각 시스템에 맞춰 별도 연동 코드를 늘리지 않고 같은 주문 이벤트를 발행할 수 있습니다. 이것이 생산자와 소비자의 느슨한 결합입니다. kafka.apache.org

또한 Kafka의 이벤트는 소비자가 읽었다고 바로 사라지는 방식이 아닙니다. 토픽별 보존 정책에 따라 저장되며, 소비자는 자신이 어디까지 읽었는지 나타내는 위치를 관리합니다. 따라서 새로운 소비자가 과거 기록부터 읽거나, 기존 소비자가 오류 수정 후 특정 시점부터 다시 처리하는 구성이 가능합니다. kafka.apache.org

이 특성 때문에 Kafka를 이해하는 데는 "메시지를 전달한다"보다 "공유 가능한 이벤트 이력을 유지한다"는 관점이 더 유용합니다. 물론 보존은 무기한 보관을 뜻하지 않습니다. 실제로 얼마나 오래 보관할지는 토픽 정책과 저장 용량 계획에 따라 정해야 합니다.

기본 구성 요소는 어떻게 함께 동작하나요?

Kafka의 주요 구성 요소를 구분하면 도입 판단과 장애 분석이 쉬워집니다.

구성 요소	역할	도입 판단에서 볼 점
토픽	같은 성격의 이벤트를 모으는 논리적 흐름	이벤트의 의미, 보존 기간, 접근 권한을 정의해야 합니다.
파티션	토픽을 나눈 순서 있는 로그 단위	처리량과 병렬성, 순서 보장의 단위가 됩니다.
생산자	이벤트를 토픽에 쓰는 애플리케이션	이벤트 키와 실패 시 재시도 방식을 정해야 합니다.
소비자	토픽의 이벤트를 읽는 애플리케이션	중복 처리, 지연, 오류 복구 방식을 설계해야 합니다.
소비자 그룹	작업을 나눠 읽는 소비자들의 집합	같은 그룹 안에서는 파티션을 나누어 처리합니다.
브로커	이벤트를 저장하고 제공하는 Kafka 서버	복제, 장애 도메인, 저장 공간의 운영 대상입니다.

토픽은 하나 이상의 파티션(partition)으로 나뉩니다. 파티션은 순서가 있는 이벤트 로그이며, Kafka는 여러 파티션을 이용해 읽기와 쓰기를 병렬화합니다. 즉, 파티션 수는 단순한 설정값이 아니라 목표 처리량, 소비자 병렬성, 순서 요구를 함께 반영하는 설계 선택입니다. kafka.apache.org

소비자 그룹은 같은 업무를 수행하는 소비자 인스턴스의 묶음입니다. 예를 들어 주문 이벤트를 데이터 웨어하우스에 적재하는 소비자 인스턴스가 여러 개라면 이들은 하나의 그룹을 이룰 수 있습니다. 그룹 안에서는 각 파티션을 한 소비자가 맡아 처리량을 나눌 수 있습니다. 반대로 알림 서비스와 분석 서비스는 서로 다른 그룹이므로 같은 주문 이벤트를 각자 독립적으로 읽습니다. kafka.apache.org

이 구조는 확장에 유리하지만, 파티션 수보다 같은 그룹의 활성 소비자 수가 많다고 해서 모두가 동시에 더 많은 파티션을 처리하는 것은 아닙니다. 따라서 인스턴스를 늘리는 것만으로 병렬성이 무한히 늘어난다고 기대하면 안 됩니다. 파티션 계획은 초기부터 실제 키 분포와 향후 확장 요구를 함께 고려해야 합니다.

어떤 문제에서 Kafka의 도입 적합성이 높아지나요?

가장 강한 도입 신호는 하나의 이벤트를 여러 시스템이 서로 다른 목적과 속도로 소비해야 하는 상황입니다. 여기서 중요한 것은 소비자 수 자체보다 소비자들이 생산자와 독립적으로 변화해야 하는가입니다.

가령 전자상거래에서 주문 생성이라는 사건이 발생했다고 가정해 보겠습니다. 처음에는 주문 데이터베이스만 갱신하면 충분할 수 있습니다. 이후 재고 예약, 결제 흐름, 고객 알림, 부정 거래 탐지, 검색·추천 데이터 갱신, 분석 적재가 추가될 수 있습니다. 각 기능이 주문 서비스에 동기 호출로 계속 붙으면, 기능 하나의 지연이나 장애가 주문 처리 경로에 영향을 주고 연동 관계도 복잡해질 수 있습니다.

이때 주문 서비스는 주문 생성 이벤트를 발행하고, 각 후속 시스템은 자신에게 필요한 이벤트를 별도 소비자 그룹으로 읽을 수 있습니다. 새 소비자가 추가될 때 기존 생산자를 직접 수정하지 않는 구조를 만들 수 있다는 점이 Kafka의 중요한 활용 방식입니다. kafka.apache.org

다음과 같은 상황은 특히 검토할 만합니다.

주문·결제·회원 상태 변경처럼 여러 업무 시스템이 참조하는 핵심 이벤트가 있습니다.
사용자 클릭, 화면 조회, 운영 로그, 측정값처럼 연속적으로 쌓이는 데이터가 있습니다.
데이터 분석, 알림, 색인, 데이터 웨어하우스 적재가 동일한 원천 이벤트를 각자 필요로 합니다.
소비자마다 처리 속도와 장애 복구 시점이 달라도 생산 흐름은 계속 유지되어야 합니다.
새 활용처가 생길 때 원천 서비스와 모든 후속 시스템을 직접 연결하는 방식이 부담스럽습니다.

이 중 하나만으로 Kafka가 반드시 필요한 것은 아닙니다. 다만 여러 항목이 동시에 해당하고, 각 데이터 흐름이 앞으로도 커질 가능성이 있다면 단순한 점대점 연동보다 이벤트 스트리밍 구조가 주는 이점이 커질 수 있습니다.

대량 처리와 급격한 변동을 어떻게 흡수하나요?

Kafka는 파티션을 통해 이벤트 읽기와 쓰기를 분산하도록 설계되어 있어, 지속적으로 많은 이벤트가 발생하는 데이터 흐름에 사용할 수 있습니다. 대표적으로 로그 집계, 사용자 활동 추적, 모니터링 지표, IoT 측정값, 거래 이벤트가 있습니다. kafka.apache.org

여기서 Kafka가 하는 역할은 생산 속도와 소비 속도가 항상 같아야 한다는 결합을 완화하는 것입니다. 예를 들어 특정 시간대에 이벤트가 급증해도 소비자가 즉시 모두 처리하지 못할 수 있습니다. 이벤트가 보존되어 있다면 소비자는 뒤처진 분량을 따라잡을 수 있습니다. 소비자가 생산자를 막지 않고 독립적으로 처리 속도를 조절할 여지가 생깁니다.

다만 이것은 지연이 없어지는 것이 아니라, 지연을 기록된 이벤트의 적체로 관리할 수 있게 된다는 뜻입니다. 소비자 지연, 즉 lag은 소비자가 최신 이벤트보다 얼마나 뒤에 있는지를 보여 주는 운영 지표입니다. 지연이 계속 증가한다면 소비자 처리 성능, 외부 의존성, 파티션 분배, 오류 재시도 등을 점검해야 합니다. Kafka는 JMX 기반 모니터링 지표를 제공하며, 운영 환경에서는 모니터링 접근 경로의 보안도 고려해야 합니다. kafka.apache.org

처리량 요구를 판단할 때는 막연히 "트래픽이 많다"고 말하기보다 다음을 분리하는 편이 낫습니다.

초당 또는 시간대별 이벤트 발생량은 어느 정도인가
이벤트 한 건의 평균·최대 크기는 어느 정도인가
피크가 얼마나 오래 지속되는가
소비자가 어느 정도 지연까지 허용되는가
장애 뒤 얼마나 빨리 적체를 처리해야 하는가
이벤트를 얼마나 오래 보존해야 하는가

이 질문에 답하면 파티션 수, 저장 공간, 복제, 소비자 확장, 재처리 시간이 서로 연결된 문제임이 드러납니다. Kafka는 높은 처리량을 위한 기반을 제공하지만, 실제 성능과 비용은 이벤트 크기, 키 쏠림, 보존 정책, 소비 로직의 병목에 따라 달라집니다.

재처리가 왜 Kafka 도입의 중요한 이유가 되나요?

실시간 처리는 이벤트가 도착한 직후 어떤 결과를 만드는 일입니다. 예를 들어 주문 직후 재고를 갱신하거나, 특정 조건의 거래를 탐지하거나, 분 단위 지표를 집계하는 작업이 여기에 해당합니다. 하지만 실시간 처리만큼 중요한 요구가 과거 데이터를 다시 처리하는 일일 수 있습니다.

재처리는 여러 이유로 필요합니다. 소비자 코드의 버그를 고친 뒤 누락되거나 잘못 계산된 결과를 다시 만들 수 있고, 새로운 분석 규칙이 생기면 기존 이벤트 이력으로 파생 데이터를 만들 수 있습니다. 장애로 소비가 중단된 경우에도 마지막 처리 위치 이후를 다시 읽어 복구할 수 있습니다. Kafka에서는 이벤트가 소비 뒤 즉시 제거되지 않으며, 보존 정책 안에서 다시 읽을 수 있습니다. kafka.apache.org

예를 들어 고객 행동 이벤트를 처음에는 일간 방문자 수 집계에만 사용했다고 해 보겠습니다. 나중에 유입 경로별 전환 분석이 필요해졌다면, 필요한 필드가 이벤트에 포함되어 있고 보존 기간이 남아 있다는 조건에서 별도의 소비자 그룹이 과거 이벤트를 읽어 새 분석 결과를 생성할 수 있습니다. 기존 집계 소비자를 멈추거나 원천 서비스의 데이터베이스를 대량 조회하지 않고도 작업을 분리할 수 있습니다.

그러나 재처리가 가능하다는 사실만으로 데이터 품질 문제가 해결되지는 않습니다. 이벤트에 필요한 식별자·발생 시각·버전 정보가 없거나, 스키마 의미가 바뀌었는데 호환성을 관리하지 않았다면 과거 데이터를 읽어도 신뢰할 결과를 만들기 어렵습니다. 또한 보존 기간보다 오래된 데이터를 다시 처리하려는 요구는 Kafka 토픽만으로 충족되지 않을 수 있습니다. 따라서 재처리를 도입 이유로 삼는다면 "무엇을 얼마 동안, 어떤 의미로 재생할 것인가"를 먼저 정해야 합니다.

데이터베이스와 외부 시스템을 연결하는 데도 쓸 수 있나요?

Kafka는 서비스 간 이벤트 전달뿐 아니라 데이터 파이프라인의 중심 흐름으로도 활용할 수 있습니다. 변경 데이터 캡처(CDC)는 데이터베이스에서 발생한 변경을 데이터 흐름으로 전달하는 방식이며, 운영 데이터의 변경을 분석·검색·다른 서비스에 반영해야 할 때 고려할 수 있습니다. Kafka Connect는 외부 시스템과의 반복적인 데이터 입출력 연동을 위한 API와 커넥터 모델을 제공합니다. kafka.apache.org

이런 구성이 유용한 예는 다음과 같습니다.

운영 데이터베이스의 변경을 분석 저장소로 지속적으로 전달합니다.
여러 애플리케이션의 로그와 지표를 공통 흐름으로 수집합니다.
한 시스템에서 생성한 데이터를 다른 저장소의 색인이나 파생 테이블에 반영합니다.
온프레미스 환경과 클라우드 환경 사이에서 지속적인 데이터 흐름을 구성합니다.

다만 커넥터를 사용한다고 해서 데이터 모델 차이, 삭제 의미, 순서 문제, 권한 관리, 대상 시스템의 쓰기 한계가 사라지는 것은 아닙니다. 특히 데이터베이스 변경을 이벤트처럼 활용할 때는 "행이 바뀌었다"는 사실과 "업무상 주문이 확정되었다"는 사건을 구별해야 합니다. 전자는 저장소 변경에 가까우며, 후자는 도메인 의미를 담은 업무 이벤트입니다. 두 데이터를 같은 것으로 취급하면 소비자가 저장 구조에 과도하게 의존할 수 있습니다.

따라서 데이터 파이프라인을 위한 Kafka 도입은 연결 개수를 줄이는 효과만이 아니라, 데이터 소유자·스키마·변경 책임을 명확히 할 수 있을 때 더 안정적입니다.

순서는 어디까지 보장되며, 왜 키 설계가 중요한가요?

Kafka에서 이벤트 순서는 토픽 전체가 아니라 파티션 내부에서 보장됩니다. 여러 파티션은 병렬 처리를 가능하게 하지만, 파티션 간에는 하나의 전역 순서가 없습니다. kafka.apache.org

예를 들어 주문 상태가 생성, 결제 완료, 배송 시작 순으로 처리되어야 한다면, 같은 주문의 이벤트가 같은 파티션에 기록되도록 주문 ID를 키로 사용할 수 있습니다. 그러면 그 주문이라는 단위 안에서는 기록 순서를 활용할 수 있습니다. 고객 상태 변경도 고객 ID를 키로 삼는 식으로 설계할 수 있습니다.

반대로 모든 주문 이벤트를 전체 시간 순서대로 하나씩 처리해야 한다고 요구하면, 사실상 단일 파티션에 가까운 선택이 필요할 수 있습니다. 이 경우 순서는 단순해질 수 있지만 병렬 처리 능력은 제한됩니다. 전역 순서와 높은 병렬성은 동시에 무제한으로 얻을 수 있는 성질이 아닙니다.

키 선택에는 또 다른 문제가 있습니다. 특정 고객이나 특정 기기에서 이벤트가 유난히 많이 발생하면 해당 키가 한 파티션에 집중될 수 있습니다. 이를 키 쏠림이라고 볼 수 있으며, 일부 소비자만 과도하게 바쁜 상태가 될 수 있습니다. 따라서 키는 순서가 필요한 업무 단위를 반영하면서도, 예상 데이터 분포에서 지나친 쏠림을 만들지 않는지 확인해야 합니다.

순서 요구를 문서화할 때는 "순서가 중요하다"는 표현만으로 끝내지 말고 다음처럼 구체화하는 것이 좋습니다.

어떤 식별자 범위에서 순서가 필요한가
생성 시각 순서와 저장 순서 중 무엇이 필요한가
늦게 도착한 이벤트를 어떻게 다룰 것인가
순서가 뒤바뀌면 어떤 업무 오류가 발생하는가
병렬성을 줄여서라도 전역 순서가 필요한가

이 답에 따라 토픽 분리, 키, 파티션 수, 소비자 로직이 달라집니다.

중복 처리와 정확히 한 번 처리는 어떻게 이해해야 하나요?

Kafka 소비자는 장애와 재시도를 고려해 기본적으로 적어도 한 번(at-least-once) 처리를 전제하는 설계가 필요합니다. 예를 들어 소비자가 어떤 이벤트의 처리를 끝냈지만 처리 위치를 기록하기 전에 중단되면, 복구 후 같은 이벤트를 다시 읽을 수 있습니다. 따라서 같은 이벤트가 중복 처리될 가능성이 있습니다. kafka.apache.org

이 문제의 실무적 해법은 소비 로직을 멱등적(idempotent)으로 만드는 것입니다. 멱등성이란 같은 작업을 여러 번 수행해도 최종 결과가 한 번 수행한 것과 같도록 만드는 성질입니다. 예를 들어 주문 123의 상태를 배송 완료로 설정하는 작업은 같은 상태 설정을 반복해도 결과가 크게 달라지지 않도록 설계할 수 있습니다. 반면 포인트 1,000점을 무조건 더한다는 연산은 같은 이벤트를 두 번 받으면 결과가 달라질 수 있으므로, 이벤트 ID 기록이나 대상 저장소의 고유 제약 같은 중복 제거 전략이 필요합니다.

Kafka는 내부 토픽에서 읽기·처리·쓰기를 연결하는 경우 트랜잭션과 read_committed 격리 수준을 사용해 정확히 한 번 처리 구성을 지원합니다. 하지만 이것을 "모든 외부 효과가 자동으로 한 번만 일어난다"는 뜻으로 이해하면 안 됩니다. 외부 데이터베이스 갱신, 이메일 발송, 결제 API 호출처럼 Kafka 바깥에서 일어나는 부수 효과는 대상 시스템과의 조정 및 별도 설계가 필요합니다. kafka.apache.org

따라서 도입 전에는 각 소비자에 다음 질문을 해야 합니다.

같은 이벤트를 두 번 처리하면 어떤 일이 생기는가
이벤트마다 중복 식별에 쓸 ID가 있는가
결과 저장소가 중복을 막거나 안전한 갱신을 지원하는가
외부 호출이 실패하거나 응답이 불명확할 때 재시도 기준은 무엇인가
재처리 시 이미 수행된 부수 효과를 어떻게 다룰 것인가

이 질문에 답하지 않은 채 Kafka를 도입하면, 전송 자체는 안정적이어도 업무 결과의 중복이나 불일치를 발견하기 어려울 수 있습니다.

장애 허용성과 내구성은 자동으로 확보되나요?

Kafka는 토픽 파티션을 복제해 브로커 장애에 대비하는 구조를 구성할 수 있습니다. 복제된 파티션, 브로커 장애 상황의 지속 운영, 다수 소비자에 대한 부하 분산이 중요한 데이터 흐름에서 이는 큰 장점이 될 수 있습니다. kafka.apache.org

하지만 "Kafka를 쓰므로 데이터는 절대 잃지 않는다"는 결론은 맞지 않습니다. 실제 내구성과 가용성은 복제 수, 생산자의 확인 응답 설정, 장애가 동시에 영향을 줄 수 있는 범위, 보존 정책, 운영 절차에 따라 달라집니다. 복제본이 있어도 동일한 장애 도메인에 함께 배치되거나, 중요한 설정이 요구 수준에 맞지 않거나, 운영자가 복구 절차를 검증하지 않았다면 기대와 다른 결과가 나올 수 있습니다. kafka.apache.org

장애 허용성을 요구사항으로 바꿔 적는 방식이 도움이 됩니다. 예를 들어 "브로커 한 대가 중단되어도 주문 이벤트의 생산과 소비가 계속되어야 한다", "소비자 장애 후 중복은 허용하되 누락은 허용하지 않는다", "특정 기간 내 이벤트는 재처리 가능해야 한다"처럼 표현합니다. 이런 요구는 복제와 확인 응답뿐 아니라 소비자 멱등성, 모니터링, 저장 용량, 복구 훈련까지 함께 결정합니다.

특히 재처리 가능한 이력은 중요한 데이터 자산이 될 수 있으므로, 토픽에 개인 정보나 민감한 업무 데이터가 포함되는지 별도로 검토해야 합니다. 접근 제어와 운영 인터페이스의 보안은 데이터 흐름의 설계와 분리된 사후 작업이 아닙니다. Kafka 운영에서 모니터링을 포함한 관리 접근의 보안 설정도 필요합니다. kafka.apache.org

단순 작업 큐나 동기 API보다 Kafka가 항상 나은가요?

아닙니다. Kafka는 모든 비동기 요구의 자동 대체재가 아닙니다. 요구가 "이미지를 한 번 변환한다", "보고서를 생성해 결과만 돌려준다", "한 소비자가 작업을 꺼내 처리한다"에 가깝고, 장기 보존·다중 구독·재처리가 핵심이 아니라면 더 단순한 작업 큐나 관리형 서비스가 비용과 운영 부담 면에서 적합할 수 있습니다. Kafka의 대표적인 강점은 대규모 이벤트 흐름, 여러 독립 소비자, 보존된 이력의 재활용이 결합될 때 드러납니다. kafka.apache.org

동기 API도 역할이 다릅니다. 사용자가 버튼을 눌러 즉시 성공·실패 결과를 받아야 하는 요청은 요청·응답 API가 자연스럽습니다. 그 요청이 완료된 뒤 후속 시스템에 사실을 알리는 흐름은 이벤트로 분리할 수 있습니다. 즉, 동기 호출과 Kafka 중 하나만 선택해야 하는 경우보다, 사용자 상호작용에는 API를 쓰고 후속 비동기 확산에는 이벤트를 쓰는 조합이 더 적절한 경우가 많습니다.

다음 비교는 판단을 단순화하는 데 도움이 됩니다.

주된 요구	우선 검토할 접근	Kafka가 특히 유리해지는 조건
한 작업을 한 번 처리	단순 작업 큐 또는 관리형 비동기 서비스	같은 작업 결과나 이벤트를 여러 독립 시스템이 읽어야 할 때
즉시 결과가 필요한 요청	동기 API	요청 완료 뒤 다양한 후속 처리를 비동기로 확산할 때
시스템 간 데이터 전달	직접 연동 또는 파일·배치 방식	지속적 흐름, 다수 목적지, 재처리 요구가 함께 있을 때
로그·행동·측정 데이터 수집	수집 도구와 저장소	대량 스트림을 여러 소비자가 독립적으로 처리할 때
상태 변경 이력 관리	업무 데이터베이스	이벤트를 재생해 상태나 파생 데이터를 재구성해야 할 때

이 표는 절대적인 제품 선택 규칙이 아닙니다. 팀의 기존 플랫폼, 관리형 서비스 이용 가능 여부, 보안 정책, 운영 인력도 판단에 영향을 줍니다. 핵심은 기능 목록보다 해결하려는 데이터 흐름의 성격입니다.

운영과 거버넌스에서 무엇을 준비해야 하나요?

Kafka 도입은 애플리케이션 라이브러리를 추가하는 일에 그치지 않습니다. 토픽, 파티션, 복제, 보존, 접근 권한, 모니터링, 용량을 지속적으로 관리하는 운영 체계를 함께 가져야 합니다. Kafka는 JMX 지표를 제공하지만, 어떤 지표를 경고로 삼고 누가 대응하며 어떻게 복구할지까지 정해야 운영 정보가 실제 가치가 됩니다. kafka.apache.org

먼저 이벤트 계약을 관리해야 합니다. 이벤트 계약은 필드 이름과 자료형뿐 아니라 각 필드의 업무 의미, 선택 여부, 버전 변경 방식, 생산 시점과 발생 시점의 구분을 포함합니다. 생산자가 필드를 삭제하거나 의미를 바꿨을 때 소비자가 조용히 잘못 동작하지 않도록 호환성 기준을 세워야 합니다.

다음으로 토픽 정책을 분명히 해야 합니다. 토픽마다 다음 사항을 결정할 필요가 있습니다.

어떤 이벤트를 담고 누가 소유하는가
보존 기간과 저장 공간 기준은 무엇인가
파티션 수와 키는 어떤 순서·처리량 요구에서 나왔는가
복제와 생산 확인 응답은 어떤 장애 수준을 목표로 하는가
누가 생산·소비할 수 있으며 민감한 데이터는 어떻게 보호하는가
소비자 지연이 어느 수준일 때 조사와 대응을 시작하는가

용량 계획도 중요합니다. 보존 기간을 길게 하거나 복제를 늘리면 저장 요구가 증가합니다. 소비자가 오래 멈춰도 재처리할 수 있게 하려면 그만큼 이력을 유지해야 할 수 있습니다. 반대로 짧은 보존은 비용을 줄일 수 있지만, 장애 복구나 새 소비자 추가 시 사용할 과거 데이터의 범위를 제한합니다. 이 선택은 비용만이 아니라 제품 기능과 복구 가능성의 범위를 정합니다.

운영 책임이 불명확한 조직에서는 공용 Kafka가 오히려 의존성 문제를 키울 수 있습니다. 토픽 소유자, 플랫폼 운영자, 보안 책임자, 소비자 개발팀이 각각 어떤 변경과 장애에 책임지는지 합의하는 일이 기술 설정만큼 중요합니다.

도입 전에는 어떤 질문으로 판단하면 좋을까요?

Kafka 도입 여부를 가장 잘 가르는 질문은 "비동기 메시지가 필요한가"가 아닙니다. 더 정확한 질문은 여러 독립 소비자가 대규모 이벤트 이력을 지속적으로 읽고, 지연이나 장애 뒤에도 다시 처리해야 하는가입니다. 이 질문에 명확히 그렇다고 답할 수 있다면 Kafka의 핵심 특성과 요구가 맞닿아 있을 가능성이 큽니다. kafka.apache.org kafka.apache.org

도입 논의를 시작할 때는 다음 점검표를 사용할 수 있습니다.

다중 소비자: 같은 이벤트를 현재 또는 가까운 미래에 여러 시스템이 독립적으로 사용합니까?
이력 가치: 이벤트를 소비 후 버리지 않고, 버그 수정·감사·새 분석을 위해 다시 읽어야 합니까?
처리 규모: 지속적인 대량 유입이나 피크 트래픽 때문에 생산과 소비를 분리할 필요가 있습니까?
순서 범위: 전역 순서가 아니라 고객·주문 같은 키 단위 순서로 문제를 풀 수 있습니까?
중복 대응: 모든 소비자가 중복 이벤트를 안전하게 처리하거나 식별할 수 있습니까?
계약 관리: 이벤트 스키마와 의미의 변경을 관리할 소유자와 절차가 있습니까?
운영 준비: 지연, 저장 공간, 브로커 장애, 권한, 재처리를 관찰하고 대응할 책임 주체가 있습니까?
대안 비교: 단일 소비자 작업 분배나 요청·응답만으로 요구를 더 단순하게 충족할 수는 없습니까?

모든 항목이 처음부터 완벽해야만 도입할 수 있는 것은 아닙니다. 다만 1~~5번의 필요가 강한데 6~~7번의 준비가 없다면, 기술적 가능성과 운영 가능한 시스템 사이에 큰 간격이 생깁니다. 작은 범위의 한 데이터 흐름에서 이벤트 계약, 중복 처리, 지연 관측, 재처리를 먼저 검증하는 접근이 판단에 도움이 될 수 있습니다.

결론: Kafka는 이벤트 이력을 공유해야 할 때 강해집니다

Apache Kafka는 단순히 메시지를 비동기로 옮기는 도구라기보다, 여러 시스템이 공유하는 이벤트 흐름을 보존하고 독립적으로 소비하게 만드는 플랫폼입니다. 동일 이벤트의 다중 구독, 대량 데이터 흐름의 병렬 처리, 지연 뒤 따라잡기, 과거 이력 재처리가 함께 필요한 환경이라면 도입 가치는 커집니다. kafka.apache.org kafka.apache.org

반대로 단일 소비자에게 일회성 작업을 넘기는 요구, 즉시 응답이 중심인 요청, 운영 부담을 최소화해야 하는 작은 흐름에서는 더 단순한 대안이 적합할 수 있습니다. Kafka를 선택할 때는 처리량만 보지 말고, 파티션 단위 순서, 중복 처리, 보존 정책, 이벤트 계약, 보안과 관측성까지 감당할 준비가 되었는지를 함께 평가해야 합니다. 이러한 조건이 갖춰질수록 Kafka는 서비스 간 결합을 줄이고 데이터 활용 범위를 넓히는 기반이 될 수 있습니다.