DevOps

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

2026년 3월 18일

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

이번 글에서는 여기어때의 이벤트 기반의 통합 알림 플랫폼인 Notification Hub를 왜 구축했는지, 그 과정에서 어떤 어려움이 있었고 어떻게 풀어나갔는지를 공유해보려고 합니다.

Notification Hub를 어떻게 구축했는지, 기술적으로 어떤 고민이 있었는지가 궁금하다면 Part 2 를 읽어주시길 바랍니다!

1. 좋은 알림이란 무엇인가

서비스의 규모가 커질수록 우리가 가장 경계해야 했던 것은 알림에 무뎌지는 것이었습니다. 봐도 그만, 안 봐도 그만인 메시지들이 쌓이면서 정작 즉시 대응이 필요한 크리티컬한 신호들이 그 속에 묻히기 시작했기 때문입니다.

기존의 개별적인 알림 전송 방식은 각 서비스의 자유도를 보장해 주었지만, 조직 전체 관점 에서는 알림의 질을 일정하게 유지하거나 체계적으로 관리하기 어려운 구조적 한계가 있었습니다. 그래서 NotiHub는 단순히 ‘알림을 보내는 기능’을 넘어, 누구나 목적에 부합하고 인지하기 쉬운 알림을 설계할 수 있는 전사적 토대를 만들고자 했습니다.

목적에 맞게: 정보 전달용인지, 즉각 대응용인지에 따라 수신자와 채널이 명확히 구분될 것
인지하기 쉽게: 메시지를 읽는 즉시 상황을 파악하고 다음 행동(Action)으로 이어질 수 있을 것

2. 우리의 현실

채널을 가득 채운 알림들, 정작 중요한 건 묻혔습니다

기존에는 각 시스템(ArgoCD, GitLab 등)에서 제공하는 기본 슬랙 인테그레이션(Slack Integration)을 활용하고 있었습니다. 설정이 간편하고 슬랙이 제공하는 표준 포맷을 즉시 사용할 수 있다는 장점이 있었지만, 서비스 규모가 커지면서 자연스럽게 한계가 드러나기 시작했습니다.

첫째, 제공되는 포맷에 갇힌 낮은 자유도였습니다. 기본 인테그레이션은 정해진 포맷과 규칙 안에서만 작동합니다. 예를 들어 ArgoCD 알림 채널에는 하루 수백 건의 메시지가 쏟아졌지만, Healthy 상태의 성공 알림과 즉각 대응이 필요한 Degraded, Sync Failed 알림이 한데 뒤섞여 있었습니다. 멘션 기능조차 설정하기 어려워, 중요한 장애 신호를 찾으려면 수백 개의 메시지를 직접 스크롤해야 했습니다.

둘째, 정보의 파편화와 인지 부하입니다. GitLab도 마찬가지였습니다. MR과 Pipeline 알림이 구분 없이 섞여 올라왔고, 단순히 “실패했다”는 결과만 통보할 뿐이었습니다. 원인을 파악하려면 반드시 GitLab에 직접 접속해야만 했습니다.

결국 이러한 ‘경직된 알림 구조’는 누군가의 부주의가 아닌, 시스템이 정보를 제때 제대로 전달하지 못하는 구조적 한계로 이어졌습니다. 우리는 편리하지만 제약이 많은 기존 연동 방식에서 벗어나, 우리가 원하는 정보를, 우리가 원하는 포맷으로, 원하는 곳에 보낼 수 있는 완전한 통제권이 필요했습니다.

개인 계정 웹훅 94.48%

초기 기획 단계에서 사내 슬랙 웹훅 현황을 분석했습니다. 결과는 예상보다 좋지 않았습니다. 공용 계정 발급 프로세스가 이미 존재했음에도 불구하고, 이후 생성된 웹훅의 약 90%가 여전히 개인 계정으로 만들어졌습니다.

사실 사내에는 이미 공용 계정 발급 프로세스가 잘 갖춰져 있었습니다. 운영상의 문제를 해결하기 위해 만들어둔 소중한 장치였죠. 하지만 서비스와 조직이 급격히 성장하다 보니, 모든 정보가 온보딩 과정에서 완벽히 전달되기에 현실적인 어려움이 있었습니다.

이런 상황에서 개발자들은 당장 알림을 띄우기 위해 가장 익숙한 ‘개인 계정 생성’이라는 선택지를 택할 수밖에 없었을 거라고 생각합니다. 당시에는 그것이 최선의 해결책이었을지 모르나, 문제는 개인 웹훅이 ‘특정 개인의 계정’에 완전히 종속된다는 점이었습니다. 이로 인해 조직 전체 관점에서는 조금씩 운영 부채가 쌓여가고 있었습니다.

히스토리의 증발 (계정 종속성): 웹훅을 만든 담당자가 퇴사하여 계정이 삭제되면, 그와 연결된 웹훅도 예고 없이 함께 사라집니다.
운영의 악순환: 코드에 하드코딩된 웹훅 URL이 갑자기 에러를 내며 알림이 끊기면, 원인을 파악하고 수정하여 신규 배포까지 마쳐야 하는 비효율적인 상황이 반복되었습니다.
낮은 효율성: 단순한 알림 수신 채널 변경이나 포맷 수정조차도 매번 코드 리뷰와 배포 프로세스를 거쳐야만 했습니다.

분산된 정책, 파악할 수 없는 구조

알림 정책은 gitlab-ci.yaml, Jenkinsfile 같은 소스 코드부터 Grafana Alert, 슬랙 웹훅 설정 화면까지 사방에 흩어져 있었습니다. 어느 알림이 어디에 설정되어 있는지 찾는 것 자체가 어려웠습니다.

실제로 알림 설정을 찾지 못한 팀이 기존 채널을 그냥 나가버리고 새 채널을 파는 웃지 못할 상황도 있었습니다. 그 결과, 메시지는 발송되나 수신인은 없는 이른바 ‘유령 채널’이 무려 638개에 달했습니다.

3. 관리의 한계: 개인에서 조직으로

NotiHub는 문제의 근본 원인인 ‘개인에게 묶인 오너십’을 해결하고자 했습니다.

전 구성원이 이미 GWS(Google Workspace) 계정을 사용하고 있고 팀 소속 정보도 GWS에서 관리되고 있었기 때문에, 이를 기반으로 팀 단위 워크스페이스를 도입했습니다. 별도의 계정 체계를 새로 만들 필요 없이, GWS 소속 정보를 그대로 활용할 수 있었습니다.

권한 관리는 사내 개발자 플랫폼인 Devhub 내 NotiHub를 통해 이루어집니다. 일부 권한은 GWS 소속 정보와 자동으로 연동되며, 추가적인 접근이 필요한 경우에는 신청 후 검토를 거쳐 반영됩니다. 덕분에 특정 개인의 부재와 상관없이 알림 서비스가 안정적으로 운영될 수 있으며, 팀원 누구나 필요할 때 운영의 오너십을 함께 나눌 수 있는 구조가 되었습니다.

4. NotiHub 가 추구한 것들

문제를 정의했다면, 어떻게 풀 것인지가 중요합니다. NotiHub를 설계하면서 몇 가지 방향을 세웠습니다.

슬랙처럼 편하게: 러닝커브를 낮추되, 더 하려면 더 할 수 있게

새로운 도구를 도입할 때 가장 큰 장벽은 학습 비용입니다. 그래서 NotiHub는 기존 슬랙 웹훅과 동일한 인터페이스를 유지했습니다. 웹훅 URL만 NotiHub URL로 교체하면 즉시 동작합니다. 추가 설정 없이도 바로 사용할 수 있고, 더 세밀한 제어가 필요하다면 라우팅 규칙이나 템플릿 기능을 활용하면 됩니다.

왜 ‘직접 호출’이 아닌 ‘이벤트’여야 했는가: 관심사의 분리

NotiHub는 기존 슬랙 웹훅과 동일한 방식도 그대로 지원합니다. 알림 메시지를 직접 구성해서 보내는 기존 방식은 웹훅 URL만 교체하면 즉시 동작합니다. 이벤트 방식은 그보다 더 많은 것을 하고 싶은 팀을 위한 선택지입니다.

실제로 개발팀들과 이야기해보면 이런 니즈가 꽤 있었습니다. “배포 성공/실패 상태에 따라 다른 채널로 보내고 싶다”, “특정 이벤트가 발생했을 때 외부 API를 자동으로 호출하고 싶다”. 하지만 이런 로직을 구현하려면 결국 슬랙봇 서버가 필요했고, 서버 발급 자체가 허들이 되어 아예 포기하는 경우도 있었습니다.

NotiHub의 이벤트 방식은 바로 이 지점을 해결하고자 했습니다. 각 시스템은 “이런 이벤트가 발생했다”는 사실만 전달하고, 이벤트 상태에 따른 라우팅, 채널 분기, Actions(API 호출 등)는 모두 NotiHub가 처리합니다. 별도의 슬랙봇 서버 없이도 NotiHub가 그 중간 레이어 역할을 대신할 수 있습니다.

덕분에 단순한 알림 채널 변경을 위해 코드를 수정하고 재배포하던 과정도 사라졌습니다. 비즈니스 로직과 알림 로직이 분리되면서, 정책 변경은 UI 설정만으로 즉시 반영됩니다.

목적에 맞는 알림, 인지하기 쉬운 알림

앞서 언급했던 ArgoCD와 GitLab 알림이 NotiHub를 통해 어떻게 바뀌었는지 소개합니다.

Before

After

ArgoCD는 배포 상태에 따라 채널을 분리했습니다.

#{env}-eks-deploy-info: 정상 배포 완료 및 리비전 정보. 히스토리 추적 용도.
#{env}-eks-deploy: Degraded, Sync Failed 등 즉각 대응이 필요한 알림만.

채널을 나누고 나서 변화가 생겼습니다. 기존에는 실패 알림을 인지조차 못했던 개발팀에서 갑자기 “👀” 이모지가 붙기 시작하고, “왜 Degraded 상태로 알림이 오는 건지”를 직접 질문해오기 시작했습니다. 알림이 제 역할을 하기 시작한 것입니다.

포맷도 함께 개선했습니다. 단순히 “실패했다”는 통보에서 벗어나, 실패 원인(ComparisonError, RPC error 등)을 메시지 본문에 직접 포함시켜 ArgoCD UI에 접속하지 않아도 즉시 원인을 파악할 수 있게 했습니다. ArgoCD 애플리케이션과 Git Manifest로 바로 이동할 수 있는 딥링크도 추가했습니다.

Before

After

GitLab은 MR 알림과 Pipeline 알림을 목적에 따라 채널로 분리하고, 코드 리뷰 댓글 내용을 슬랙 메시지 본문에 바로 포함시켜 GitLab에 접속하지 않아도 내용을 확인할 수 있게 개선했습니다. 알림의 범위도 MR 위주에서 CI/CD 전체 생명주기로 확장했습니다.

초기에는 단일 프로젝트에 시범적으로 도입했으나, 해당 팀 내부에서 긍정적인 피드백을 받은 덕분에 해당 부서 내 모든 프로젝트로 확대 적용된 케이스도 있었습니다. 강제적인 지침 없이 필요에 의해 자발적으로 확산되었다는 점에서 뜻깊은 성과였다고 생각합니다.

좋은 알림을 만드는 가이드와 템플릿

“좋은 알림을 만들자”는 말은 쉽지만, 실제로 어떻게 만들어야 하는지는 막막한 경우가 많습니다. NotiHub는 모범 사례를 템플릿으로 제공합니다.

현재 제공 중인 GitLab 템플릿을 시작으로, 장애 대응용/모니터링용/상호작용형 알림 등 다양한 케이스를 순차적으로 확대할 예정입니다.

5. 마치며

지금까지 여기어때가 왜 Notification Hub(NotiHub)를 구축하게 되었는지, 그리고 우리가 정의한 ‘좋은 알림’이 조직에 어떤 변화를 가져왔는지 살펴보았습니다.

단순히 메시지를 전달하는 기능을 넘어, 개인에게 파편화되어 있던 운영 권한을 조직의 자산으로 내재화하고, 개발자가 비즈니스 로직에만 집중할 수 있는 환경을 만드는 것이 NotiHub의 목표였습니다.

다음 Part 2에서는 고가용성을 보장하기 위한 아키텍처 설계와, 쏟아지는 이벤트를 안정적으로 처리하기 위해 사용한 기술 스택(Kafka, Redis 등)에 대해 깊이 있게 다뤄보겠습니다.