Kafka 도입 배경과 아키텍처 전환

초기 서비스는 API 간 직접 연동(point-to-point)으로도 충분히 동작한다. 문제는 서비스가 늘어날수록 데이터 흐름이 복잡해지고, 변경 비용이 선형이 아니라 기하급수적으로 커진다는 점이다.

Point-to-point 구조의 한계

초기에는 데이터 생산자와 소비자를 직접 연결해도 문제를 느끼기 어렵다. 하지만 지표, 로그, 사용자 행동 이벤트처럼 재사용되는 데이터가 늘어나면 같은 데이터를 여러 서비스에 중복 전달하게 된다.

이때 나타나는 공통 문제는 다음과 같다.

• 데이터 연결이 늘어날수록 의존 관계가 복잡해진다.
• 특정 API 장애가 연쇄 장애로 이어진다.
• 소비 시스템 추가 시 생산 시스템까지 수정해야 한다.

즉, 데이터 흐름을 서비스 간 호출로 직접 엮어두면 확장 단계에서 구조적 한계가 드러난다.

발행-구독 전환이 필요한 이유

해결 방향은 생산과 소비를 분리하는 것이다. 생산자는 이벤트를 발행하고, 소비자는 자신이 필요한 속도로 구독한다.

Kafka를 중심에 두면 데이터 전달 책임이 애플리케이션 간 직접 호출에서 이벤트 로그로 이동한다.

• 생산자는 “누가 읽는지”를 몰라도 된다.
• 소비자는 “언제 읽을지”를 스스로 결정할 수 있다.
• 신규 소비 시스템은 기존 생산 경로를 깨지 않고 추가할 수 있다.

핵심은 기능 확장이 아니라 데이터 흐름 자체를 독립 계층으로 분리하는 데 있다.

Kafka가 확장에 유리한 이유

Kafka의 메시지는 토픽/파티션 로그에 순차 저장된다. 이 구조는 단순한 큐와 다르게 동일 이벤트를 여러 소비자가 각자 오프셋으로 독립 소비할 수 있게 만든다.

• 다중 프로듀서: 여러 시스템이 같은 토픽으로 이벤트를 발행할 수 있다.
• 다중 컨슈머: 서로 다른 컨슈머 그룹이 같은 이벤트를 각자 목적에 맞게 처리할 수 있다.
• 디스크 기반 보존: 컨슈머가 느려도 데이터가 즉시 사라지지 않아 재처리 경로를 확보할 수 있다.

결과적으로 Kafka는 “전송”보다 “저장 가능한 이벤트 스트림”에 더 가깝다.

메시지와 스트림 관점에서 보는 설계 포인트

Kafka의 기본 단위는 메시지다. 메시지의 key/value는 Kafka 입장에서 바이트 배열이며, key는 파티션 배치와 순서 보장 범위에 영향을 준다.

실무 설계에서는 다음 기준이 중요하다.

• 순서 보장이 필요한 단위를 key로 정한다.
• 토픽은 업무 도메인 기준으로 분리한다.
• 컨슈머 그룹은 처리 목적(적재, 알림, 통계)을 기준으로 분리한다.

같은 스트림을 여러 서비스가 재사용할수록 데이터 아키텍처의 결합도가 내려간다.

적용 시 체크리스트

• 이벤트 스키마와 소유 팀을 먼저 정한다.
• 장애 시 재처리 범위(오프셋 기준)를 운영 절차에 포함한다.
• 파티션 수는 현재 처리량뿐 아니라 예상 소비자 확장까지 고려해 설계한다.
• API 호출과 이벤트 발행이 혼재된 구간은 단계적으로 분리한다.

Kafka 도입의 본질은 기술 교체가 아니라 아키텍처 책임 분리다. 이 관점이 선행되어야 운영 복잡도와 변경 비용을 실제로 줄일 수 있다.