Kafka 입문

Kafka 입문. 서비스가 커지면 "주문이 생기면 알림 보내고, 재고 줄이고, 통계 쌓고..."가 거미줄처럼 얽힌다. Kafka는 이 흐름을 이벤트로 풀어낸다. Producer·Consumer·Topic·Partition 같은 핵심 개념부터 Spring 코드까지 정리한다.

---

들어가며

배치와 스트림 처리 글에서 Kafka를 스트림 처리의 대표 도구로 잠깐 다뤘다. 이번엔 그 Kafka를 제대로 들여다본다.

서비스가 작을 땐 모든 걸 직접 호출하면 된다. "주문이 들어오면 결제하고, 재고 줄이고, 이메일 보내고, 통계 쌓는다." 그런데 이 후속 작업이 늘어날수록 주문 코드가 모든 걸 알아야 하는 거미줄이 된다. 하나가 느려지면 전체가 느려지고, 하나가 죽으면 주문까지 실패한다.

Kafka는 이 문제를 이벤트(event) 라는 발상으로 푼다. "주문이 생겼다"는 사실 하나만 던지면, 그걸 필요로 하는 시스템들이 각자 알아서 가져가 처리한다. 보내는 쪽과 받는 쪽이 서로를 몰라도 된다.

Kafka의 핵심은 "데이터를 직접 전달하지 않고, 흐르는 통로에 흘려보낸다"는 것이다. 보내는 쪽과 받는 쪽이 분리되면 시스템이 유연해진다.

이 글에서는 Kafka의 핵심 개념과 동작 원리를 잡고, Spring으로 실제 코드를 작성해본다.

---

Kafka란

Apache Kafka는 분산 이벤트 스트리밍 플랫폼이다. 2011년 링크드인에서 만들어졌고, 지금은 대용량 실시간 데이터 처리의 사실상 표준이다.

쉽게 말하면 거대하고 빠른 메시지 통로다. 한쪽에서 데이터(이벤트)를 흘려보내면, 다른 쪽에서 그걸 받아 처리한다. 핵심 특징은 셋이다.

• 고성능: 초당 수백만 건의 메시지를 처리한다.
• 확장성: 서버를 여러 대로 늘려 부하를 분산한다.
• 영속성: 메시지를 디스크에 저장해, 소비자가 나중에 읽어도 된다. (메시지가 사라지지 않음)

마지막 특징이 전통적인 메시지 큐와의 큰 차이다. Kafka는 읽었다고 메시지를 지우지 않는다. 정해진 기간 동안 보관해서, 여러 소비자가 각자 다른 속도로 읽을 수 있다.

---

핵심 개념

Kafka를 이해하려면 네 개념을 잡아야 한다.

개념	역할
Producer	이벤트를 발행하는(보내는) 쪽
Consumer	이벤트를 구독하는(받는) 쪽
Topic	이벤트가 쌓이는 카테고리별 통로
Partition	Topic을 나눈 단위 (병렬 처리·확장의 핵심)

 

Kafka 이벤트 구조

흐름은 단순하다. Producer가 Topic에 이벤트를 발행하면, 그 Topic을 구독하는 Consumer들이 이벤트를 가져가 처리한다. 중간의 Kafka가 이벤트를 안전하게 보관하고 전달한다.

Topic과 Partition

Topic은 이벤트의 카테고리다. "orders", "payments", "user-signups"처럼 종류별로 통로를 나눈다.

Partition은 하나의 Topic을 여러 조각으로 나눈 것이다. 이게 Kafka 성능의 핵심이다. Topic을 파티션 3개로 나누면, 3개의 Consumer가 동시에 병렬로 처리할 수 있다. 파티션을 늘리면 처리량이 늘어난다.

Topic: orders
 ├ Partition 0 → Consumer A
 ├ Partition 1 → Consumer B
 └ Partition 2 → Consumer C   (3배 병렬 처리)

같은 키(예: user_id)를 가진 이벤트는 항상 같은 파티션으로 가서, 순서가 보장된다. 한 사용자의 주문 순서가 뒤바뀌지 않는다.

Consumer Group

여러 Consumer를 묶은 게 Consumer Group이다. 같은 그룹 안에서는 파티션을 나눠 가져서 부하를 분산하고, 다른 그룹끼리는 같은 데이터를 각자 독립적으로 받는다.

Topic: orders
 ├ Group "재고관리"  → 재고 차감 (orders를 받아 처리)
 └ Group "통계"      → 통계 집계 (같은 orders를 또 받아 처리)

orders 토픽 하나를 재고팀과 통계팀이 서로 영향 없이 각자 소비한다. 이게 이벤트 기반 아키텍처의 힘이다.

---

Spring으로 Producer 만들기

이제 코드로 보자. 주문이 생길 때마다 이벤트를 발행하는 Producer다. 먼저 설정.

# application.yml
spring:
  kafka:
    bootstrap-servers: localhost:9092
    producer:
      key-serializer: org.apache.kafka.common.serialization.StringSerializer
      value-serializer: org.springframework.kafka.support.serializer.JsonSerializer
    consumer:
      group-id: order-service
      auto-offset-reset: earliest
      value-deserializer: org.springframework.kafka.support.serializer.JsonDeserializer
      properties:
        spring.json.trusted.packages: "*"

이벤트 객체와 Producer 코드.

// 발행할 이벤트 (record로 간단히)
public record OrderEvent(Long orderId, Long userId, int amount) {}

@Service
public class OrderEventProducer {

    private final KafkaTemplate<String, OrderEvent> kafkaTemplate;

    public OrderEventProducer(KafkaTemplate<String, OrderEvent> kafkaTemplate) {
        this.kafkaTemplate = kafkaTemplate;
    }

    public void publish(OrderEvent event) {
        // key를 userId로 → 같은 사용자 이벤트는 같은 파티션(순서 보장)
        kafkaTemplate.send("orders", String.valueOf(event.userId()), event);
    }
}

주문 서비스는 이제 후속 작업을 직접 호출하지 않는다. 이벤트만 발행하고 끝이다.

@Service
public class OrderService {

    private final OrderEventProducer producer;

    public void createOrder(OrderRequest req) {
        Order order = orderRepository.save(req.toEntity());

        // 후속 작업(재고·알림·통계)을 직접 부르지 않고 이벤트만 발행
        producer.publish(new OrderEvent(
                order.getId(), order.getUserId(), order.getAmount()));
        // 이후 누가 무엇을 하는지 OrderService는 모른다
    }
}

---

Spring으로 Consumer 만들기

발행된 이벤트를 받아 처리하는 Consumer들이다. @KafkaListener 하나면 된다.

@Service
public class InventoryConsumer {

    // "재고관리" 그룹으로 orders를 구독
    @KafkaListener(topics = "orders", groupId = "inventory")
    public void handle(OrderEvent event) {
        // 재고 차감
        inventoryService.decrease(event.orderId());
        log.info("재고 차감 완료: order={}", event.orderId());
    }
}

@Service
public class NotificationConsumer {

    // "알림" 그룹으로 같은 orders를 독립적으로 구독
    @KafkaListener(topics = "orders", groupId = "notification")
    public void handle(OrderEvent event) {
        // 주문 확인 알림 발송
        notificationService.send(event.userId(), "주문이 완료되었습니다");
    }
}

두 Consumer는 서로 다른 그룹이라, 같은 주문 이벤트를 각자 독립적으로 받는다. 재고 차감과 알림 발송이 서로 영향을 주지 않는다. 알림 서버가 잠시 죽어도 재고 차감은 멀쩡히 돌아가고, 알림 서버가 살아나면 Kafka에 보관된 이벤트를 이어서 처리한다.

새 후속 작업을 추가하고 싶으면? 새 그룹의 Consumer를 하나 더 만들면 끝이다. 기존 코드는 한 줄도 안 바꾼다.

@Service
public class StatsConsumer {
    @KafkaListener(topics = "orders", groupId = "stats")
    public void handle(OrderEvent event) {
        statsService.record(event);   // 통계 집계 추가 — 기존 코드 변경 없음
    }
}

---

직접 호출 vs Kafka

Kafka를 쓰면 무엇이 달라지는지 비교하면 분명하다.

	직접 호출	Kafka (이벤트)
결합도	주문이 모든 후속을 앎	서로 모름 (느슨함)
후속 추가	주문 코드 수정	Consumer만 추가
장애 전파	하나 죽으면 주문 실패	격리됨 (독립)
부하	동기 처리로 느려짐	비동기로 흘려보냄
재처리	어려움	보관된 이벤트 재소비

디자인 패턴 글에서 다룬 옵저버 패턴을, 시스템 레벨로 확장한 것이라고 볼 수 있다. 발행자와 구독자를 분리하는 그 발상이 Kafka에서는 서비스 간 통신으로 커진다.

---

언제 쓰고, 언제 안 쓰나

Kafka가 만능은 아니다. 도입하면 운영할 인프라가 하나 더 생긴다.

Kafka가 어울리는 경우

• 하나의 이벤트에 여러 시스템이 반응해야 할 때
• 서비스 간 결합도를 낮추고 싶을 때 (MSA)
• 대용량 데이터를 실시간으로 흘려보내야 할 때
• 로그 수집, 이벤트 소싱, 실시간 파이프라인

굳이 필요 없는 경우

• 서비스가 작고 후속 작업이 단순할 때 → 직접 호출이 더 간단
• 즉각적인 응답이 꼭 필요할 때 (Kafka는 비동기)
• 트래픽이 적어 메시지 큐가 과한 경우

작은 서비스에 Kafka를 깔면 운영 복잡도만 늘어난다. "이벤트에 여러 시스템이 반응해야 하는" 상황이 됐을 때가 도입 타이밍이다.

---

마치며

Kafka는 "데이터를 직접 전달하는" 방식을 "이벤트를 흘려보내는" 방식으로 바꾼다. 그 결과 보내는 쪽과 받는 쪽이 분리되고, 시스템이 유연해진다. 주문 서비스는 그저 "주문이 생겼다"고 외치고, 재고·알림·통계는 각자 알아서 반응한다.

핵심만 다시 짚으면, Producer가 Topic에 이벤트를 발행하고, Partition으로 병렬 처리되며, Consumer Group이 각자 독립적으로 소비한다. 이 구조 위에서 느슨한 결합, 장애 격리, 손쉬운 확장이 가능해진다.

물론 모든 곳에 필요한 건 아니다. 하지만 서비스가 커지고 이벤트에 반응할 시스템이 늘어날 때, Kafka는 거미줄 같은 직접 호출을 깔끔한 이벤트 흐름으로 바꿔준다. 그게 많은 회사가 Kafka를 쓰는 이유다.

---

참고 출처

• Apache Kafka 공식 문서 — https://kafka.apache.org/documentation/
• Spring for Apache Kafka — https://docs.spring.io/spring-kafka/reference/
• Confluent: What is Kafka? — https://www.confluent.io/what-is-apache-kafka/