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

안녕하세요. DevOps팀 아리입니다.

지난 1편에서는 시스템의 탄생 배경을 다뤘다면, 이번 글에서는 NotiHub의 기술적 설계와 그 과정에서 내린 주요 의사결정들을 깊이 있게 공유하고자 합니다.

1. 왜 만들었는가

인터널 툴에는 두 가지 측면이 있습니다. 조직적 측면과 개인적 측면입니다. NotiHub는 조직적 효율성에 무게를 둔 프로젝트라고 생각합니다.

슬랙은 보편적으로 어느 회사에서나 사용하고 있지만, NotiHub는 우리 조직만의 커스텀 도구입니다. 사용자에게는 새로운 학습 비용이 발생하게 됩니다. 그럼에도 ‘중앙 집중형 구조’를 선택한 이유는 명확한 관리의 한계 때문이었습니다.

• 웹훅의 종속성 문제: 특정 개인이 생성한 웹훅은 퇴사 시 계정 삭제와 함께 사라집니다. 이는 애플리케이션 에러와 긴급 배포로 이어지는 악순환을 만들었습니다.
• 모니터링의 부재: 어떤 팀이 어떤 채널로 알림을 보내는지 파악이 불가능해 전사적인 알림 정책을 수립하기 어려웠습니다.

또한 대부분의 SaaS 서비스는 자체적인 슬랙 연동 기능을 제공합니다. 하지만 실제 운영 환경에서 이를 그대로 사용하기에는 몇 가지 한계가 있었습니다.

• 제한된 포맷: SaaS가 제공하는 알림은 포맷이 고정되어 있어, 우리 팀에게 필요한 핵심 정보를 강조하거나 불필요한 노이즈를 제거하기 어려웠습니다.
• 라우팅의 경직성: 특정 이벤트가 발생했을 때 내용에 따라 수신 채널을 동적으로 분리하고 싶어도, SaaS 설정만으로는 세밀한 조건별 분기가 불가능한 경우가 많았습니다.

이 외에도 자세한 탄생 배경이 궁금하다면 1편을 참고해주시길 바랍니다.

트레이드오프: 편의성 vs 안정성

중앙화의 가장 큰 숙제는 단일 장애점(SPOF) 문제입니다. NotiHub가 멈추면 전사의 알림이 멈춥니다. 저희는 이를 해결하기 위해 HPA(Horizontal Pod Autoscaler) 기반의 Scale-out과 무중단 배포, 그리고 다중 레이어 캐싱을 통해 가용성을 확보했습니다. 완벽한 정답은 없겠지만 관제 효율화로 얻는 이득이 운영 리스크보다 크다고 판단하여, 아키텍처 차원의 방어 기제를 두터이 설계했습니다.

2. 전체 아키텍처 개요

NotiHub는 확장성과 독립성을 위해 세 개의 레이어로 분리되어 있습니다. 아래 시퀀스 다이어그램을 통해 이벤트가 수신되어 슬랙으로 전달되기까지의 흐름을 확인할 수 있습니다.

이 구조의 핵심은 이중화된 확장 전략에 있습니다. 급격한 트래픽 증가 시 물리적인 Pod 확장은 HPA(Horizontal Pod Autoscaler)가 담당하여 컴퓨팅 자원을 확보하고, 논리적인 작업 분배는 Kafka의 Consumer Group과 내부 샤딩 로직이 담당하여 데이터 처리의 일관성과 분산 처리를 동시에 보장합니다. 각 컴포넌트는 Kafka와 Redis를 매개체로 연결되어 있어, 특정 구간에 부하가 걸려도 전체 시스템으로 전이되지 않는 구조를 가집니다.

3. 외부와의 접점: 보안과 확장성

내부망과 외부망의 분리 설계

기존 슬랙 웹훅의 사용자 경험을 유지하는 것이 핵심이었습니다.

• 내부망: 인증 토큰 없이 URL 교체만으로 즉시 마이그레이션이 가능합니다.
• 외부망 (Jira, Slack API 등): 보안을 위해 B2B Gateway를 통한 이중 검증 구조를 도입했습니다. 엔드포인트를 분리하여 ‘가벼운 Receiver’라는 원칙을 지키면서도 보안 요구사항을 충족했습니다.

단일 키 노출 시의 위험을 방지하기 위해, 시스템 전역에서 사용하는 Static Key 와 각 엔드포인트 별로 발급된 Dynamic Key를 동시에 검증하는 구조를 택했습니다.

모든 검증을 외부 저장소(Redis)에 의존하면 네트워크 레이턴시가 발생합니다. 따라서, 변경 빈도가 낮은 Static Key 는 애플리케이션 기동 시 Secret Store에서 조회하여 인메모리에 캐싱함으로써 1차 검증 속도를 극대화했습니다.

4. 유실 없는 수신을 위한 전략

Receiver는 의도적으로 최소한의 역할만 수행합니다. JSON 스키마 검증과 키 확인만 마치면 즉시 이벤트를 Kafka로 발행하여, 급격한 트래픽 증가(Burst) 상황에서 안정적인 버퍼 역할을 수행하고 Receiver와 Processor 간의 결합도를 낮춥니다.

이벤트 브로커로 Kafka를 선택한 배경에는 사내에서 이미 운영 중인 공용 Kafka 클러스터가 있었다는 점도 크게 작용했습니다. 덕분에 인프라 구축이나 운영 리소스 부담 없이 즉시 메시징 구조를 도입할 수 있었습니다. 구체적으로는 Kafka의 Consumer Group 메커니즘을 통해 다수의 Processor Pod가 이벤트를 균등하게 나누어 처리하며, 특정 Pod에 장애가 발생하더라도 리밸런싱을 통해 유실 없이 작업을 이어받도록 설계했습니다. 동시에 CPU 점유율(80%) 기준의 HPA를 설정하여 트래픽 폭증 시 물리적 자원을 확장하도록 구성했습니다.

물론 설계 단계에서 Kafka Lag 기반 HPA나 Graceful Shutdown 같은 고도화된 장치들도 검토했으나, 현재는 Receiver 인입량과 Processor 처리 지표를 실시간 모니터링하며 가용성을 확인하는 방식만으로도 충분하다고 판단했습니다. 인프라 복잡도를 낮게 유지하되, 지표상 유의미한 지연이 감지되는 시점에 맞춰 해당 기능들을 단계적으로 도입할 계획입니다.

5. 실시간 설정 반영: 3중 캐시 구조

사용자가 관리 페이지에서 알림 규칙(Rule)이나 템플릿을 수정하면 즉시 반영되어야 합니다. 성능과 최신 데이터 사이의 균형을 위해 계층형 캐시 전략을 사용합니다.

• 캐시 계층: Local Cache (In-memory) → Redis → API/DB
• 전략: 현재는 로컬 캐시의 TTL을 짧게 유지하여 별도의 무효화(Invalidation) 로직 없이도 데이터 정합성을 확보하고 있습니다.

특히 Redis 장애가 서비스 전체의 중단으로 이어지지 않도록 다음과 같은 방어 기제(Failsafe)를 구축했습니다.

• Fallback 구조: Redis 조회가 실패할 경우 각 인스턴스의 로컬 캐시를 우선 활용하며, 최악의 상황에는 API 서버를 직접 호출하도록 설계했습니다. API 서버 또한 HPA 설정이 되어 있어 일시적인 직접 호출 부하 증가에 유연하게 대응합니다.
• 재연결 및 업데이트 제어: Redis 연결 이슈 발생 시 Exponential Backoff 전략을 적용해 재시도 간격을 점진적으로 늘림으로써 시스템 부하를 방지합니다. 설정 업데이트 실패 시에도 최대 3회까지만 재시도하여 프로세스 점유를 차단합니다.

결과적으로 각 인스턴스가 독립적인 로컬 캐시를 보유하고 있어, 단기간의 Redis 장애 상황에서도 알림 서비스의 연속성을 보장할 수 있습니다. 향후 이벤트 수가 늘어나고 API 서버의 부하가 가중될 경우, Redis의 Pub/Sub 기능을 도입하여 설정 변경 시점에만 로컬 캐시를 갱신하는 ‘이벤트 기반 무효화’ 방식으로 전환할 예정입니다.

6. 슬랙 API의 한계 극복 (Rate Limit 핸들링)

베타 테스트 중 수천 건의 알림이 쏟아질 때 슬랙의 429 Too Many Requests 오류가 빈번했습니다. 이를 해결하기 위해 두 가지 전략을 도입했습니다.

슬랙봇 샤딩 (Slack Bot Sharding)

동일한 봇이 너무 많은 메시지를 보내지 않도록 봇 풀(Pool)을 구성했습니다.

• 일관성 유지 : bot_index = hash(channel_id) % bot_pool_size. 동일 채널의 메시지는 항상 동일한 봇이 담당합니다. 그래야만 메시지 업데이트(Update)나 스레드(Thread) 연결 시 권한 문제가 발생하지 않습니다.
• Main Bot vs Shard Bots: Private 채널이나 인터랙션(Button 클릭 등)이 필요한 경우, 모든 샤딩 봇을 채널에 초대하는 번거로움을 피하기 위해 권한을 가진 ‘Main Bot’이 예외적으로 처리하도록 이원화했습니다.

샤딩 도입 후 초당 수천 건의 메시지 전송도 안정적으로 처리됨을 확인했습니다.

채널별 큐 격리

특정 채널에서 Rate Limit이 발생해도 다른 채널에 영향이 가지 않도록 채널별 독립 큐를 운영합니다. 큐는 슬랙봇 샤딩과 동일한 모듈러 연산으로 관리되며, release 환경 기준으로 10개의 큐를 운영합니다. 지연이 발생하는 큐는 잠시 멈추지만, 다른 큐들은 정상적으로 메시지를 처리합니다.

이 과정에서 앞서 언급한 물리적 확장(HPA)과 논리적 분배(Sharding)가 시너지를 냅니다. Pod가 아무리 늘어나도(HPA), 특정 채널의 메시지는 일관된 해시 결과에 따라 지정된 큐와 봇을 통해 처리되므로 메시지 업데이트나 스레드 연산의 무결성이 깨지지 않습니다.

Slack API 오류 대응 및 복원 전략

단순 실패 처리 대신 Processor 레벨에서 자동 복원을 시도합니다. no_text, msg_too_long, blocks_too_many 등의 오류가 감지되면 메시지를 분할하거나 blocks/attachments를 나눠 재전송하도록 처리됩니다.

7. Processor의 핵심 로직

Kafka를 통해 전달된 이벤트는 다음과 같은 핵심 과정을 거쳐 슬랙으로 전송됩니다.

(1) 일대다 채널 라우팅 (Multi-channel Routing)

하나의 이벤트는 설정에 따라 여러 채널로 동시에 전송될 수 있습니다. 각 채널마다 별도의 템플릿과 전송 규칙(Rule)을 가질 수 있으며, 특정 조건에 따라 메시지를 분기하여 전달합니다.

(2) 조건 엔진 및 템플릿 렌더링 (Handlebars)

• Condition Engine : 페이로드의 특정 필드 값이 error, critical 인지 등 조건(eq, neq, contains)을 판단하여 전송 여부를 결정합니다. 공휴일이나 시간 조건도 함께 설정할 수 있어 업무 시간 외 알림 등을 유연하게 제어할 수 있습니다.
• Handlebars : JSON 형태의 raw payload를 사용자 친화적인 슬랙 메시지로 변환합니다. {{#each errors}}...{{/each}}와 같이 복잡한 리스트 구조도 유연하게 표현할 수 있습니다. 렌더링 실패 시 raw payload를 텍스트로 전송하여 메시지 유실을 방지하고 있습니다.

(3) 스레드 관리와 에스컬레이션

동일한 컨텍스트(예: incident_id)를 가진 이벤트는 하나의 스레드로 묶어 채널의 가독성을 높입니다. 스레드 키의 만료 시간은 기본 24시간이며 최대 7일까지 설정할 수 있습니다.

특정 시간 내에 확인 이모지 반응이 없는 경우 담당자를 멘션하거나 상위 채널로 재전송하는 에스컬레이션 정책을 최대 3단계까지 설정할 수 있습니다. 에스컬레이션은 1분 주기의 배치로 처리됩니다.

8. 마치며

개인 프로젝트나 단일 서비스에서 알림 시스템을 구축하는 것이 기술적 구현의 영역이라면, 전사 구성원이 함께 사용하는 플랫폼을 만드는 과정은 그와는 전혀 다른 고민을 안겨주었습니다.

특히 ‘단일 장애점(SPOF)’에 대한 우려와 시스템 안정성에 대한 동료들의 날카로운 피드백은 NotiHub가 더 견고한 아키텍처를 갖추는 데 가장 큰 동력이 되었습니다.

전사 플랫폼을 구축한다는 것은 결국 기술을 통해 조직의 신뢰를 쌓아가는 여정이라고 생각합니다. 앞으로도 사용자의 목소리에 귀 기울이며, NotiHub가 우리 조직에서 누구나 믿고 사용할 수 있는 플랫폼이 될 수 있도록 다듬어 가겠습니다.

감사합니다.