여기어때 이벤트 기반 통합 알림 플랫폼 구축기 Part 2. 구현은 어떻게?

NotiHub는 전사 알림을 한곳에서 관리하기 위해 만든 중앙 집중형 통합 알림 플랫폼이다. 웹훅 종속성으로 인한 운영 리스크와 알림 현황을 파악하기 어려운 문제를 해결하려고, 편의성보다 안정성과 관제 효율을 우선했다.

핵심 구조는 Receiver - Kafka - Processor의 3단 분리다. Receiver는 JSON 스키마 검증과 키 확인만 처리한 뒤 즉시 Kafka로 이벤트를 발행해 버스트 트래픽을 흡수하고, Processor가 실제 라우팅과 렌더링, 전송을 담당한다. 트래픽 급증에는 **HPA(Horizontal Pod Autoscaler)**로 Pod를 늘리고, Kafka Consumer Group과 내부 샤딩으로 논리적 분산을 맞췄다.

외부와의 접점은 내부망과 외부망으로 나눴다. 내부망은 인증 토큰 없이 URL 교체만으로 마이그레이션할 수 있게 했고, Jira와 Slack API 같은 외부망은 B2B Gateway를 통해 이중 검증했다. 전역 Static Key와 엔드포인트별 Dynamic Key를 함께 확인하며, 변경 빈도가 낮은 Static Key는 기동 시 Secret Store에서 읽어 인메모리 캐시로 유지했다.

설정과 템플릿은 3중 캐시 구조로 운영한다.

• Local Cache → Redis → API/DB 순으로 조회해 지연을 줄인다.
• Redis가 실패하면 로컬 캐시를 우선 쓰고, 최악의 경우 API 서버를 직접 호출한다.
• Redis 연결 문제에는 Exponential Backoff를 적용하고, 설정 업데이트 실패는 최대 3회까지만 재시도한다.

슬랙 전송에서는 rate limit과 메시지 무결성을 함께 다뤘다. 동일 채널은 bot_index = hash(channel_id) % bot_pool_size로 항상 같은 봇이 담당하도록 Slack Bot Sharding을 적용했고, 채널별 독립 큐를 둬서 특정 큐가 막혀도 다른 큐는 계속 처리하게 했다. 메시지 오류가 나면 Processor가 no_text, msg_too_long, blocks_too_many 같은 케이스를 감지해 분할 재전송하며 복원한다.

Processor는 이벤트를 여러 채널로 라우팅하고, 조건 엔진으로 eq, neq, contains 같은 규칙과 시간·공휴일 조건을 판단한 뒤 Handlebars로 슬랙 메시지를 렌더링한다. 같은 incident_id는 스레드로 묶고, 반응이 없으면 최대 3단계까지 에스컬레이션하며 1분 주기 배치로 처리한다. 아직은 Kafka Lag 기반 HPA나 Graceful Shutdown까지는 가지 않았지만, 인입량과 처리 지표를 보며 단계적으로 고도화할 계획이다.