[Beyond DAG] Day 4: Event-driven Pipelines - 센서(Sensor)와 웹훅을 활용한 실시간 연동

서론: 스케줄링에서 반응형 처리로

매시 정각 배치만으로는 제품 요구를 따라가기 어렵다. 이벤트 발생 즉시 파이프라인이 반응해야 하는 경우가 늘고 있다.

대표 사례:

• 결제 완료 후 리스크 스코어 즉시 갱신
• 문서 업로드 후 임베딩/인덱싱 즉시 실행
• 외부 시스템 상태 변경 후 다운스트림 재계산

1. 이벤트 기반 오케스트레이션 기본 구조

Event Source -> Queue/Broker -> Orchestrator Trigger -> Processing Pipeline -> Status Callback

핵심은 트리거와 처리 로직을 분리하는 것이다.

• 트리거: 센서, 웹훅, 메시지 소비
• 처리: 자산 갱신, 워크플로우 실행, 검증/알림

2. Sensor 패턴

Sensor는 특정 조건 충족 여부를 관찰해 파이프라인을 실행한다.

예시 조건:

• 특정 버킷에 새 파일 도착
• 업스트림 자산 버전 변경
• 외부 API 상태 플래그 변경

운영 포인트:

1. 폴링 주기와 비용 균형
2. 중복 트리거 방지(마지막 처리 오프셋 저장)
3. 실패 시 백오프/재시도 정책

3. Webhook 패턴

웹훅은 이벤트를 push 방식으로 받아 지연을 줄인다.

필수 고려사항:

• 서명 검증(HMAC 등)
• 재전송 중복 처리(idempotency key)
• 순서 역전(out-of-order) 대응

웹훅은 빠르지만 신뢰성은 수신 측 설계가 좌우한다.

4. 배치와 실시간의 하이브리드 운영

현실적으로는 완전 실시간보다 하이브리드가 많다.

• 실시간: 사용자 영향 큰 핵심 이벤트 처리
• 배치: 비용 최적화 가능한 대량 후처리

이때 중요한 지표:

• 이벤트 지연(latency)
• 처리 성공률
• 재처리 큐 백로그
• 이벤트당 처리 비용

5. 장애 대응 설계

이벤트 기반 파이프라인은 “한 번 실패하면 끝” 구조를 피해야 한다.

1. Dead Letter Queue(DLQ) 운영
2. 재처리 워크플로우 분리
3. 중복 수신 안전성 보장
4. 알림과 자동 완화(runbook) 연결

6. Day 4 체크리스트

1. 트리거 채널(센서/웹훅/큐)을 용도별로 분리했다.
2. 이벤트 멱등성 키 설계를 표준화했다.
3. DLQ와 재처리 절차를 문서화했다.
4. 실시간 파이프라인 SLO(지연/성공률)를 수립했다.

다음 글 예고

Day 5에서는 시리즈를 정리하며 단순 배치 vs 복잡한 상태 머신 관점에서 아키텍처 선택 가이드를 제시한다.