“이벤트 주도 모든 것”의 숨겨진 비용: 대부분의 시스템이 아직 카프카를 필요로 하지 않는 이유
Source: Dev.to
지난 10년 동안 이벤트‑드리븐 아키텍처(EDA)는 특수한 설계 선택에서 기본 권장 사항으로 조용히 전환되었습니다. 팀은 도메인 경계를 정의하기도 전에 Kafka를 도입하고, 설계자는 처리량 요구 사항을 검증하기도 전에 비동기 워크플로를 제안합니다.
“이벤트‑드리븐”은 이제 “현대적”이라는 의미와 동의어가 되었습니다. 이 변화는 면밀히 검토할 가치가 있습니다.
이벤트‑드리븐 시스템은 강력합니다. 결합도를 낮추고, 확장성을 제공하며, 재생 가능성을 보장하고, 도메인 간 통합을 가능하게 합니다. 그러나 이러한 이점은 특정 조건 하에서만 나타납니다. 그 조건이 충족되지 않을 경우, 도입되는 복잡성이 제공되는 가치보다 더 크게 작용합니다.
문제는 EDA가 작동하는가가 아니라—분명히 작동합니다—당신의 시스템이 진정으로 필요로 하는가 하는 것입니다.
1. 문제와 해결책 사이의 불일치
많은 조직에서 비동기 메시징은 미래 대비 차원에서 도입됩니다. 확장성 문제가 필연적으로 발생할 것이며, 처음부터 Kafka로 구축하면 나중에 비용이 많이 드는 재작성을 방지할 수 있다는 가정입니다.
이 논리는 매력적이지만 잘못되었습니다.
아키텍처는 현재의 제약을 최적화하면서도 진화할 수 있는 능력을 유지해야 합니다. 낮거나 중간 수준의 처리량 시스템에 분산 스트리밍 인프라를 도입하면 비례하는 이점 없이 운영 오버헤드만 증가합니다. 대부분의 초기 단계 플랫폼, 내부 시스템, 그리고 CRUD 중심의 SaaS 제품은 스트리밍 백본을 정당화할 만큼의 이벤트 양이나 도메인 분산이 없습니다.
필요성보다 앞서 인프라를 추가하는 것은 선견지명이 아니라 추측적 복잡성입니다.
2. 인지적 오버헤드와 디버깅 현실
Synchronous systems fail in visible ways. A request times out. An exception propagates. Observability is straightforward.
Event‑driven systems fail in temporal fragments:
- A producer succeeds while a consumer fails.
- Retries mask systemic issues until they explode.
- Dead‑letter queues (DLQ) accumulate unnoticed.
- State divergence surfaces minutes (or hours) later.
Debugging becomes temporal reconstruction. You are no longer tracing a call stack; you are reconstructing distributed causality across logs and timestamps. This demands:
- Disciplined correlation IDs
- Idempotent handlers
- Schema governance
- Distributed tracing
Without high operational maturity, these aren’t “nice‑to‑haves”—they are survival mechanisms.
3. 최종 일관성 vs. 비즈니스 의미론
이벤트‑주도 아키텍처는 종종 최종 일관성에 의존합니다. 실제 운영에서는 이는 일시적인 데이터 차이로 나타납니다:
- 재고 수량이 구매를 즉시 반영하지 않을 수 있습니다.
- 재무 집계가 거래보다 뒤처질 수 있습니다.
- 사용자 대시보드가 오래된 상태를 표시합니다.
비즈니스 도메인이 일시적인 불일치를 허용할 수 없다면, 아키텍처는 추가적인 조정 메커니즘으로 보완해야 합니다. 이러한 조정은 보통 EDA가 약속한 “단순성” 자체를 파괴합니다.
4. 운영 복잡성은 선형이 아니다
분산 스트리밍 플랫폼을 운영하는 것은 REST 엔드포인트를 노출하는 것과 실질적으로 다릅니다. 여러 가지 비용이 드는 개념들을 고려해야 합니다:
- Partitioning – 순서 보장 및 처리량에 영향을 줍니다.
- Rebalancing – 지연 시간 급증 및 “stop‑the‑world” 소비자 일시 중지를 초래할 수 있습니다.
- Exactly‑once – 종종 at‑least‑once 로 낮아져, 모든 곳에서 멱등 로직이 필요합니다.
- Storage – 브로커 안정성은 디스크와 보존 관리에 직접 연결됩니다.
EDA가 정당화되는 경우는 언제인가?
- 고용량 트랜잭션 시스템.
- 실시간 분석 파이프라인.
- IoT 수집 레이어.
- 금융 트랜잭션 처리.
이러한 경우 Kafka는 단순한 아키텍처 트렌드가 아니라 인프라스트럭처 필요성입니다.
실용적인 진화 경로
가장 탄력적인 아키텍처는 예측 가능한 진행 단계를 따릅니다:
- 모듈형 모놀리식: 먼저 명확한 도메인 경계를 구축합니다.
- 동기 서비스: 확장 압력이 발생하는 경우에만 서비스를 추출합니다.
- 목표 지향 비동기: 특정 고부가가치 사용 사례(예: 이메일 전송, 보고서 생성)를 위해 메시징을 도입합니다.
- 전체 이벤트‑드리븐 생태계: 도메인 간 워크플로우가 비용을 정당화할 때만 적용합니다.
최종 생각: 아키텍처는 트레이드‑오프 관리
산업계가 복잡성을 정교함과 동일시하는 경향은 의사결정을 왜곡한다. 이해 가능하고, 관찰 가능하며, 운영 가능한 잘 구조화된 동기식 시스템은 대부분의 환경에서 과도하게 설계된 비동기식 시스템보다 뛰어나다.
명확성은 추상화보다 더 멀리 확장된다.
성숙한 아키텍처 질문은 *“이벤트‑드리븐으로 어떻게 만들까?”*가 아니라 “우리가 해결하려는 구체적인 제약은 무엇이며, 그 대가로 어떤 비용을 감수하는가?”