Kafka란 무엇인가 - 메시징 시스템의 진화와 Kafka의 등장

 

"Kafka는 메시지를 큐처럼 처리하는 시스템"
"Pub/Sub 기반의 고성능 스트리밍 플랫폼"
"실시간 데이터 파이프라인 구축에 꼭 필요하다"

 

Kafka를 처음 접하면 다양한 정의와 설명이 쏟아진다.
하지만 개념이 워낙 방대하고 공부하다 보면 용어도 생소할 수 있기에 처음엔 "이게 도대체 무슨 소리지?" 하는 생각이 먼저 든다.

 

요즘 백엔드 개발자 신입 수준에서 우대 사항 스펙이며, MSA라는 키워드와 함께 주목받았던 Kafka다.

전부터 관심있던 기술인 Kafka를 팀프로젝트에 도입해보며 공부했던 개념들을 글을 통해 시리즈로 정리해보려고 한다.

 

왜 Kafka가 필요하게 되었는지, 어떤 문제를 해결하려는 건지,
그 맥락을 먼저 잡아두면 이후 개념들이 훨씬 잘 정리된다.
이 글은 그 시작점에서 Kafka의 배경과 핵심 구조를 한 번에 조망해보려는 목적을 갖고 있다.

 

기존 메시징 시스템이 갖고 있던 문제들

Kafka 이전에도 RabbitMQ, ActiveMQ, IBM MQ 같은 메시지 브로커들이 많이 쓰였다.
이들은 대부분 '큐(queue)'라는 개념을 기반으로 동작한다.
생산자(Producer)가 메시지를 큐에 넣고, 소비자(Consumer)가 꺼내 처리하는 구조다.

 

이 방식은 단순한 이벤트 처리나 알림 전송에는 잘 맞았지만, 점점 데이터 처리 요구가 늘어나면서 몇 가지 한계가 드러나기 시작했다.

 

• 확장성의 한계
  메시지 양이 많아지면 하나의 큐가 병목이 된다.
  큐 하나에 여러 Consumer를 붙이긴 하지만, 메시지의 분배나 처리 속도 면에서 무거워진다.
• 재처리가 어렵다
  메시지는 한번 소비되면 큐에서 사라진다.
  장애가 발생하거나 로그를 다시 읽고 싶은 경우엔 메시지를 복구하거나 재생하는 게 쉽지 않다.
• 다른 시스템과 동시에 처리하기 어렵다
  동일한 메시지를 여러 시스템에서 동시에 처리하려면 큐를 여러 개 두거나, 브로커를 복잡하게 구성해야 했다.

 

이런 한계들은 단순히 '메시지를 전달'하는 기능 이상을 필요로 하는 환경에서는 점점 불편함으로 다가왔다.

특히 로그 수집, 실시간 데이터 파이프라인, 이벤트 기반 아키텍처처럼

데이터를 일시적인 메시지가 아니라 ‘흐름(stream)’으로 다뤄야 하는 시스템에서는 기존 메시징 방식만으로는 부족했다.

 

Kafka는 왜, 어떻게 다르게 접근했을까

Kafka는 이런 한계들을 근본적으로 해결하려는 시도에서 시작됐다.

원래는 LinkedIn에서 내부 로그 수집 시스템을 새로 설계하려다 나온 프로젝트였다고 한다.

처음 목표는 명확했다.

• 메시지를 절대 잃지 말자.
• 성능을 극한까지 끌어올리자.
• 같은 메시지를 여러 시스템이 따로 읽을 수 있게 하자.

이를 위해 Kafka는 기존 큐 방식과는 전혀 다른 구조를 택했다.

메시지를 디스크에 저장하고,
브로커는 메시지를 ‘보낸다’기보다는 ‘보관한다’는 개념으로 동작하며,
Consumer는 자신이 필요할 때 메시지를 읽고 처리하도록 설계됐다.

 

결국 Kafka는 메시징 시스템이면서, 동시에 분산 로그 저장소이고,
나아가서는 실시간 데이터 스트리밍 플랫폼 역할까지 수행하게 된다.

 

Kafka의 구조를 구성하는 기본 단위들

Kafka의 내부는 처음 보면 복잡해 보이지만, 핵심 개념 몇 가지만 잡아두면 구조가 빠르게 이해된다.

 

Topic

Kafka에서 메시지는 Topic 단위로 관리된다.
어떤 주제(topic)로 메시지를 분류해서 보내고, 해당 Topic을 구독한 Consumer들이 메시지를 가져가는 방식이다.

 

Producer / Consumer
Producer는 메시지를 특정 Topic으로 전송하는 주체고,
Consumer는 그 Topic에 저장된 메시지를 순서대로 읽어가는 역할을 한다.

 

Partition
Topic은 내부적으로 여러 개의 Partition으로 나뉘어 있다.
이 Partition이 Kafka의 병렬성과 확장성을 담당하는 단위다.
각 Partition은 하나의 파일처럼 로그를 순차적으로 저장하며, 메시지마다 번호(Offset)가 매겨진다.

 

Offset
Offset은 메시지의 고유한 번호다.
Consumer는 이 Offset을 기준으로 어디까지 메시지를 읽었는지 스스로 관리한다.
즉, 메시지를 읽고 나서 “내가 마지막으로 읽은 메시지는 Offset 103이야” 같은 식으로 기억하고 있는 것이다.

 

Retention
Kafka는 메시지를 Consumer가 읽은 뒤에도 바로 삭제하지 않는다.
기본적으로는 일정 기간 보관(retention)하고, 그 시간 동안은 여러 Consumer가 같은 메시지를 반복해서 읽을 수 있다.

 

Kafka는 메시징 시스템인가, 로그 시스템인가

Kafka를 단순히 메시징 시스템이라고 부르기엔 기능이 너무 많고,
단순히 로그 저장소라고 하기엔 Pub/Sub 기반의 실시간성이 너무 강하다.

 

Kafka는 그 중간 어디쯤 있다.
메시지라는 단위를 중심으로 스트리밍 처리, 재처리 가능성, 확장성, 내결함성까지 모두 고려한 설계를 가진다.

그래서 Kafka를 소개할 때는 다음 키워드들이 자주 등장한다.

• 분산 로그 저장소
• 고성능 메시징 브로커
• 스트리밍 데이터 플랫폼
• 데이터 허브

어떻게 부르든 Kafka는 단순한 큐의 역할을 넘어,
시스템 간 데이터를 안전하게 전달하고 보관하며,
나아가 실시간으로 분석하거나 가공할 수 있는 기반을 제공하는 플랫폼이다.

 

마무리하며

Kafka는 단순히 ‘빠른 메시지 큐’가 아니다.
처음 설계부터 기존 메시징 시스템의 한계를 극복하고,
실시간 데이터 흐름을 중심에 둔 시스템을 만들기 위해 시작됐다.

 

이번 글에서는 Kafka가 등장하게 된 배경과, 그 안에서 핵심이 되는 구조들을 개괄적으로 정리했다.
다음 글부터는 Kafka의 구성 요소 하나하나를 더 깊이 있게 살펴보면서,
실제로 이 구조가 어떻게 작동하고, 어떤 고민들이 숨어 있는지 함께 알아볼 예정이다.