[카프카 챌린지] 1부: 카프카란 무엇인가? 카프카는 왜 태어났는가?

Kafka는 무엇인가?

Kafka는 분산 이벤트 스트리밍 플랫폼이다.

 

여기서 이벤트 스트리밍이란, 애플리케이션이나 데이터베이스 등 다양한 이벤트 소스로부터 데이터를 실시간으로 수집하고, 이를 내구성 있게 저장한 뒤, 실시간 또는 과거 데이터를 기준으로 처리하고 필요한 목적지로 전달하는 방식을 말한다.

 

이벤트는 "무언가가 발생했다"는 사실을 기록한 데이터다. 예를 들어 사용자가 회원가입을 했다, 주문이 생성되었다, 결제가 완료되었다, 프로필 정보가 변경되었다 같은 사실들이 이벤트가 될 수 있다.

 

---

Kafka는 왜 만들어졌을까?

Kafka는 LinkedIn에서 만들어졌다.

 

LinkedIn은 서비스가 빠르게 성장하면서 여러 시스템 간에 데이터를 주고받아야 하는 일이 많아졌다. 초기에는 필요한 상황마다 임시방편으로 파이프라인을 만들었지만, 시스템이 늘어날수록 연결 구조가 점점 복잡해졌다.

 

예를 들어 하나의 사용자 이벤트가 검색 인덱스 갱신, 추천 시스템 갱신, 통계 시스템 갱신 등 여러 곳에 영향을 준다고 해보자. 각 시스템을 직접 연결하는 방식으로 처리하면, 시스템 수가 늘어날수록 연결 수도 함께 폭발적으로 증가한다.

 

 

Kafka는 이 문제를 각 시스템끼리 직접 연결하는 방식이 아니라, 중앙에 데이터 스트림 허브를 두는 방식으로 해결했다.

 

---

Kafka의 기본 흐름

Kafka에서는 이벤트를 만드는 쪽을 Producer, 이벤트를 읽어서 처리하는 쪽을 Consumer라고 한다.

 

Producer는 이벤트를 Kafka에 기록한다. 그리고 그 이벤트가 필요한 Consumer들은 Kafka로부터 각자 독립적으로 이벤트를 읽어간다.

즉, Producer와 Consumer가 서로를 직접 알 필요가 없다.

Producer → Kafka → Consumer A
                 → Consumer B
                 → Consumer C

 

이 구조 덕분에 새로운 시스템이 추가되어도 기존 Producer를 크게 변경하지 않고 확장할 수 있다. 예를 들어 기존에는 주문 생성 이벤트를 알림 시스템만 사용하고 있었는데, 나중에 통계 시스템이나 추천 시스템이 추가되더라도 Kafka에 쌓인 주문 이벤트를 새 Consumer가 읽어가면 된다.

 

이것이 Kafka가 단순한 메시지 전달 도구를 넘어, 여러 시스템 사이의 데이터 흐름을 정리하는 중앙 허브로 사용되는 이유다.

 

---

Kafka의 장점

Kafka의 대표적인 장점은 다음과 같다.

1. 높은 처리량
   대량의 이벤트를 빠르게 처리할 수 있다.
2. 낮은 지연시간
   적절히 설계하면 이벤트가 생성된 뒤 Consumer에게 전달되기까지의 지연시간을 낮게 유지할 수 있다.
3. 높은 확장성
   트래픽이 증가해도 broker, topic, partition 등을 통해 수평 확장이 가능하다.
4. 내구성 있는 저장
   Kafka는 이벤트를 소비했다고 바로 삭제하지 않는다. 설정된 보관 정책에 따라 일정 기간 동안 이벤트를 저장할 수 있다.
5. 높은 가용성
   일부 broker에 장애가 발생하더라도 복제 구조를 통해 전체 시스템이 계속 동작할 수 있도록 설계할 수 있다.

다만 "Kafka는 무조건 빠르다" 또는 "Kafka는 영구 저장소다" 라고 이해하면 안 된다. 실제 지연시간과 안정성은 Producer 설정, Broker 구성, Consumer 처리 속도, replication 설정, retention 설정 등에 따라 달라진다.

 

---

Kafka는 언제 쓰면 좋을까?

Kafka는 다음과 같은 상황에서 특히 잘 맞는다.

1. 하나의 이벤트를 여러 시스템이 독립적으로 활용해야 할 때

예를 들어 OrderCreated 이벤트가 발생했을 때, 알림 시스템, 통계 시스템, 추천 시스템, 포인트 시스템이 각각 이 이벤트를 사용할 수 있다.

이때 각 시스템을 직접 연결하면 구조가 복잡해지지만, Kafka를 사용하면 하나의 이벤트 스트림을 여러 Consumer가 독립적으로 읽어갈 수 있다.

2. 서비스가 커지면서 시스템 간 데이터 파이프라인이 계속 늘어날 때

서비스가 작을 때는 API 호출이나 DB 직접 연동으로도 충분할 수 있다. 하지만 시스템이 늘어나고 데이터 흐름이 복잡해지면, 각 시스템을 직접 연결하는 방식은 운영하기 어려워진다.

Kafka는 이런 복잡한 데이터 흐름을 중앙 스트림 방식으로 정리하는 데 유용하다.

3. 최근 상태뿐만 아니라 상태 변화의 흐름이 필요할 때

DB는 보통 현재 상태를 저장하는 데 적합하다. 반면 Kafka는 어떤 일이 언제 발생했는지, 이벤트가 어떤 순서로 흘러갔는지를 다루는 데 적합하다.

예를 들어 "현재 사용자의 회사 정보가 무엇인가"만 필요하다면 DB 조회로 충분할 수 있다. 하지만 "사용자가 언제 어떤 회사로 이직했고, 그 이벤트를 어떤 시스템들이 처리했는가" 같은 흐름이 중요하다면 Kafka가 잘 맞을 수 있다.

 

---

Kafka를 신중하게 써야 하는 경우

Kafka가 모든 문제를 해결해주는 것은 아니다.

1. 즉시 정합성이 중요한 트랜잭션 (Consistency)

포인트 차감, 결제 승인, 재고 차감처럼 정합성이 중요한 로직에 Kafka를 먼저 두는 것은 위험할 수 있다.

이런 로직은 보통 DB 트랜잭션으로 먼저 확정하고, 그 결과를 이벤트로 발행하는 방식이 더 안전하다.

예를 들어 결제 승인 자체를 Kafka Consumer가 나중에 처리하게 만들면, 사용자는 이미 결제가 된 것처럼 보이는데 실제 처리는 실패하는 문제가 생길 수 있다. 따라서 Kafka는 핵심 트랜잭션의 source of truth라기보다는, 확정된 사실을 다른 시스템에 전파하는 용도로 보는 것이 좋다.

2. 데이터베이스처럼 사용하려는 경우

Kafka는 이벤트를 저장할 수 있지만, RDBMS처럼 자유롭게 조회하고 join하고 검색하기 위한 저장소는 아니다.

복잡한 조건 검색, 최신 상태 조회, 관계형 데이터 join이 필요하다면 Kafka가 아니라 DB나 검색 엔진을 사용해야 한다.

3. 소규모 서비스나 MVP 단계

소규모 서비스나 MVP 단계에서는 Kafka가 오버엔지니어링이 될 수 있다.

Kafka를 도입하면 broker 운영, topic 관리, partition 설계, consumer group 관리, 장애 대응, 모니터링, retry, dead letter 처리 등 고려할 것이 많아진다. 단순한 비동기 작업이라면 Redis Queue, RabbitMQ, BullMQ, Celery 같은 작업 큐가 더 현실적인 선택일 수 있다.

 

 

---

정리

Kafka는 단순한 메시지 큐가 아니라, 서비스에서 발생하는 이벤트 흐름을 중앙에서 관리하는 분산 이벤트 스트리밍 플랫폼이다.

 

Producer는 이벤트를 Kafka에 기록하고, Consumer는 필요한 이벤트를 독립적으로 읽어간다. 이 구조 덕분에 시스템 간 결합도를 낮추고, 서비스가 커져도 데이터 흐름을 비교적 일관된 방식으로 관리할 수 있다.

 

Kafka는 여러 시스템이 같은 이벤트를 활용해야 하거나, 서비스 규모가 커지면서 데이터 파이프라인이 복잡해지는 상황에서 강력한 선택지가 된다.

 

하지만 즉시 정합성이 중요한 트랜잭션, 복잡한 검색과 조회, 소규모 서비스나 MVP 단계에서는 신중하게 도입해야 한다. Kafka는 강력한 도구지만, 모든 상황에 필요한 도구는 아니다.

 

---

 

본 글은 쉬운코드 유튜브 채널의 회원 전용 Kafka 챌린지 라이브 강의를 기반으로 개인 학습 및 복습 목적으로 정리한 내용입니다.

원본 영상은 아래 링크에서 확인할 수 있습니다.

https://www.youtube.com/live/_TxvpUTcz-E