여기어때, 알림 관리 문제 해결을 위한 NotiHub 구축기
개별 알림 전송 방식의 한계로 인해 중요한 알림이 묻히고, 알림 관리의 어려움 발생
개인 계정 기반 웹훅(Webhook) 사용으로 인한 운영 부채 증가 및 알림 정책 관리의 어려움
NotiHub 도입을 통해 개인에게 종속된 알림 운영 권한을 조직 자산으로 전환
슬랙(Slack) 웹훅과 유사한 인터페이스 제공 및 이벤트 기반 아키텍처(Event-driven Architecture)를 통해 개발 편의성 향상
알림 관리의 구조적 한계
본문에서는 기존 알림 시스템의 문제점으로 낮은 자유도(Low Flexibility), 정보 파편화(Information Fragmentation), 인지 부하(Cognitive Load)를 지적한다. 기존 슬랙(Slack) 인테그레이션(Integration)은 설정이 간편하지만, 정해진 포맷과 규칙에 갇혀 있어 알림의 목적에 맞는 세부 설정이 어려웠다. 특히, 중요한 장애 알림이 수많은 메시지에 묻히는 문제가 발생했다. 또한, GitLab 알림의 경우 MR과 Pipeline 알림이 구분 없이 섞여 올라와 정보의 파악을 어렵게 했다. 이러한 문제들은 결국 시스템이 정보를 적시에 제대로 전달하지 못하는 구조적 한계로 이어졌다.
개인 계정 웹훅(Webhook)의 위험성
글에 따르면, 개인 계정 웹훅(Webhook) 사용은 계정 종속성(Account Dependency), 운영의 악순환(Operational Vicious Cycle), 낮은 효율성(Low Efficiency)을 야기한다. 개인 계정에 종속된 웹훅은 담당자 퇴사 시 알림이 중단되는 문제를 발생시키고, 하드코딩된 URL 변경 시 코드 수정 및 배포가 필요하다. 또한, 알림 채널 변경이나 포맷 수정조차 코드 리뷰와 배포를 거쳐야 하는 비효율성을 초래한다. 이러한 문제들은 결국 조직 전체의 알림 관리 효율성을 저해하는 요인으로 작용한다.
NotiHub의 아키텍처(Architecture) 설계
NotiHub는 기존 슬랙(Slack) 웹훅과 동일한 인터페이스를 제공하여 러닝 커브(Learning Curve)를 낮추고, 이벤트 기반 아키텍처(Event-driven Architecture)를 통해 유연성을 확보했다. 기존 웹훅 URL을 NotiHub URL로 교체하는 것만으로 알림 전송이 가능하며, 라우팅 규칙 및 템플릿 기능을 통해 세밀한 제어가 가능하다. 특히, 이벤트 방식은 각 시스템이 이벤트 발생 사실만 전달하고, 라우팅, 채널 분기, 액션(Action) 처리를 NotiHub가 담당하도록 하여 관심사 분리(Separation of Concerns)를 실현했다. 이를 통해 비즈니스 로직과 알림 로직을 분리하고, 정책 변경을 UI 설정만으로 즉시 반영할 수 있도록 했다.
NotiHub를 통한 알림 개선 사례
본문에서는 ArgoCD와 GitLab 알림 개선 사례를 통해 NotiHub의 효과를 설명한다. ArgoCD는 배포 상태에 따라 채널을 분리하고, 실패 원인을 메시지 본문에 포함하여 문제 해결 시간 단축(Faster Troubleshooting)을 이끌었다. GitLab은 MR 알림과 Pipeline 알림을 분리하고, 코드 리뷰 댓글 내용을 슬랙(Slack) 메시지에 포함하여 정보 접근성(Information Accessibility)을 향상시켰다. 또한, 알림 범위를 CI/CD 전체 생명주기로 확장하여 개발 생산성을 높였다. 이러한 개선 사례는 NotiHub의 확장성(Scalability)과 유연성(Flexibility)을 보여주는 중요한 지표이다.