여기어때 이벤트 기반 통합 알림 플랫폼 구축기 Part 1. 왜 만들었나?

좋은 알림은 단순히 메시지를 많이 보내는 기능이 아니라, 목적에 맞는 수신자와 채널로 정확히 전달되고 읽는 즉시 다음 행동으로 이어지게 만드는 일입니다. 서비스가 커질수록 “봐도 그만, 안 봐도 그만”인 알림이 쌓이고, 정작 중요한 신호가 묻히는 문제가 커졌습니다.

기존의 Slack Integration은 설정이 쉽고 표준 포맷을 바로 쓸 수 있었지만, 조직 전체 관점에서는 자유도가 낮았습니다. ArgoCD 알림 채널에는 Healthy 성공 알림과 Degraded, Sync Failed 같은 긴급 알림이 섞여 들어왔고, GitLab도 MR과 Pipeline 알림이 뒤섞인 채로 원인 정보 없이 결과만 전달했습니다.

초기 분석에서는 사내 Slack webhook의 약 **94.48%**가 개인 계정으로 만들어진 것으로 나타났습니다. 공용 계정 발급 프로세스가 있었지만 온보딩 과정에서 충분히 전달되지 못했고, 개인 webhook은 계정 삭제나 담당자 변경에 따라 함께 사라질 수 있는 구조적 위험을 안고 있었습니다.

알림 정책도 gitlab-ci.yaml, Jenkinsfile, Grafana Alert, Slack webhook 설정 화면 등 여러 곳에 흩어져 있었습니다. 설정 위치를 찾지 못해 기존 채널을 버리고 새 채널을 파는 일이 반복되면서, 수신자 없는 유령 채널 638개가 생겼습니다.

이 문제를 풀기 위해 Notification Hub(NotiHub) 는 개인이 아니라 조직 단위로 운영되는 구조를 택했습니다. 전 구성원이 사용하는 GWS(Google Workspace) 소속 정보를 기반으로 팀 단위 워크스페이스를 만들고, 권한은 사내 개발자 플랫폼 Devhub 에서 관리해 운영 오너십을 조직 자산으로 전환했습니다.

설계 방향은 세 가지였습니다.

• 슬랙처럼 쉽게: 기존 Slack webhook과 같은 인터페이스를 유지해 URL만 바꾸면 바로 동작하게 함
• 이벤트 기반으로 분리: 각 시스템은 이벤트 발생 사실만 알리고, 라우팅과 채널 분기는 NotiHub가 담당
• 목적에 맞게 전달: 정보성 알림과 즉시 대응 알림을 구분하고, 템플릿과 라우팅 규칙으로 메시지 품질을 높임

이 방식으로 단순한 채널 변경이나 포맷 수정 때문에 매번 코드 수정과 배포를 반복하던 흐름이 사라졌습니다. ArgoCD는 배포 완료용 채널과 장애 대응용 채널을 분리했고, 실패 원인까지 본문에 넣고 딥링크를 추가해 UI에 들어가지 않아도 상황을 파악할 수 있게 했습니다.

GitLab 역시 MR 알림과 Pipeline 알림을 분리하고, 리뷰 댓글 내용을 메시지에 직접 포함해 접근 비용을 줄였습니다. 일부 팀에서 시작된 적용이 부서 전체로 자연스럽게 확산되면서, 강제가 아니라 필요에 의해 쓰이는 알림 플랫폼이라는 점도 확인됐습니다.

현재는 GitLab 템플릿 을 시작으로 장애 대응용, 모니터링용, 상호작용형 알림 템플릿을 넓혀가고 있습니다. 다음 Part 2에서는 고가용성 아키텍처와 Kafka, Redis 를 활용한 이벤트 처리 방식을 다룰 예정입니다.