Linear·GitHub·Slack 알림 폭주 – 하루 200개를 5개로 줄이는 법
Linear, GitHub, Slack 알림이 엔지니어링 팀을 압도하고 있나요? 아키텍처의 결함과 실제로 필요한 5가지 시그널을 알아보세요.
By Ellis Keane · 2026-03-13
문제는 알림이 너무 많다는 게 아닙니다. 문제는 같은 이벤트에 대해 세 가지 도구에서 동시에, 딱 알맞은 수만큼 도착한다는 것입니다.
모든 웹훅은 올바르게 실행됩니다. 모든 통합은 약속한 대로 정확히 작동합니다. GitHub은 PR에 대해 알립니다. Linear는 해당 PR이 닫는 이슈에 대해 알립니다. Slack은 누군가가(아마도 당신이, 3개월 전에 "가시성"에 대한 근거 없는 낙관주의에 빠져) 봇을 프로젝트 채널에 연결했기 때문에 알립니다. 세 개의 도구, 세 개의 알림, 하나의 이벤트, 모두 설계대로 완벽하게 작동합니다. 엔지니어링은 흠잡을 데 없습니다. 경험은 끔찍합니다.
Linear, GitHub, Slack 알림이 너무 많은 이유는 무언가가 고장났기 때문이 아닙니다. 아무것도 고장나지 않았기 때문입니다. 각 도구는 다른 도구의 존재를 전혀 인식하지 못한 채 알림 역할을 충실히 수행합니다. 공유 이벤트 버스도 없습니다. 중복 제거 레이어도 없습니다. 스택 어디에도 "이 사람은 이미 이것을 알고 있다"는 개념이 없습니다. 당신이 겪는 건 잘못된 설정의 고통이 아닙니다. 여섯 개의 도구를 같은 워크플로에 연결하고 각각이 독립적으로 소리치도록 내버려 둔 논리적인 결과입니다.
"알림 시스템은 실패하고 있지 않습니다. 너무 성공적으로 작동해서 당신을 묻어버리고 있을 뿐입니다." – Chris Calo
발전이란 이런 것입니다.
하나의 머지 해부학 – 중복의 부검
하나의 이벤트, 즉 단일 PR 머지를 예로 들어 알림 레이어에서 무슨 일이 일어나는지 추적해 보겠습니다. 드문 일이어서가 아니라 지겹도록 평범한 일이기 때문입니다.
팀원이 GitHub에서 PR을 머지했습니다. 다음이 그 연쇄 반응입니다:
- GitHub이 당신의 알림 수신함에 웹훅을 보냅니다. 당신은 이 PR에서 리뷰를 작성했으므로 구독자입니다. 이것이 첫 번째 알림.
- Linear의 GitHub 통합이 연결된 이슈를 감지하고 상태를 "진행 중"에서 "완료"로 자동 전환합니다. Linear는 이슈를 보고 있는 모든 사람에게 알림을 생성합니다. 같은 팀에 있는 당신도 포함됩니다. 이것이 두 번째 알림.
- Slack 봇(낙관주의에 빠져 연결한 그 봇)이 #frontend에 머지 요약을 게시합니다. 누군가 그 메시지에 이모지나 댓글로 반응하면 Slack이 스레드 알림을 생성합니다. 이것이 세 번째, 경우에 따라 네 번째 알림.
- CI가 머지 커밋에서 실행됩니다. GitHub이 또 다른 웹훅을 보냅니다. CI가 통과해도 신경 쓰지 않을 수 있지만 GitHub의 구독 모델은 이진입니다. 보고 있거나 보지 않거나 둘 중 하나입니다. 이것이 다섯 번째 알림.
다섯 개의 알림. 하나의 이벤트. 그리고 당신은 머지가 논의된 통화에 있었으므로 이 알림들이 도착하기 전에 이미 알고 있었습니다.
이것을 6명 팀의 모든 PR, 모든 이슈 전환, 모든 CI 실행에 곱하면, 진정으로 새로운 시그널을 세기 전에 1인당 하루 30〜40개의 중복 이벤트를 처리하고 있는 것입니다. 알림 시스템은 실패하고 있지 않습니다. 너무 성공적으로 작동해서 당신을 묻어버리고 있습니다.
음소거는 출혈에 붙이는 반창고
표준적인 조언은 적극적인 음소거입니다. GitHub 이메일 알림을 끕니다. Slack을 다이렉트 멘션만 알리도록 설정합니다. Linear에서 자신에게 할당된 이슈 외에는 모두 팔로우 해제합니다. 이것은 손목이 골절됐는데 시계를 푸는 것과 같습니다. 기술적으로 손목 관련 복잡성을 줄였지만 시간을 확인하는 능력도 잃었습니다.
저도 음소거 방식을 시도했습니다(물론입니다. 누구나 하는 일입니다. 모든 사람이 처음 시도하는 것이고, 그다음에 시도하는 것은 왠지 더 악화되는 Zapier 체인입니다). 적극적으로 했습니다: GitHub 이메일을 완전히 끊고, 팀 작업 채널 외 모든 Slack 채널을 음소거하고, Linear에서 내 이슈 외에는 모두 팔로우 해제했습니다. 약 3일 동안은 천국이었습니다.
그런 다음 음소거한 채널에서 토론이 이루어졌기 때문에 두 개의 블로킹 PR 리뷰를 놓쳤습니다. 내 리뷰가 필요했던 엔지니어들은 결국 DM을 보냈습니다. 그건 그냥 여분의 단계와 수동적 공격적인 "메시지 봤어요?" 에너지가 붙은 알림일 뿐입니다. 일주일 후, 내가 만들고 있던 컴포넌트를 완전히 바꾸는 디자인 결정이 Figma 댓글 스레드에 올라왔고, PR이 거부될 때까지 몰랐습니다. 재미있었습니다.
음소거의 근본적인 문제는 동적인 컨텍스트에 정적인 규칙을 적용한다는 것입니다. 지난 화요일의 알림 설정은 오늘 아침 도착한 긴급 버그에 대해 모릅니다. 그리고 적극적으로 음소거할수록 인식의 공백이 넓어집니다. 팀원들은 그 공백을 "봤어요?" DM으로 채웁니다. 즉, 적극적인 음소거는 알림을 줄이지 않습니다. 봇(판단하지 않는)에서 사람(분명히 판단하는)으로 이동할 뿐입니다.
실제로 방해를 정당화하는 5가지 시그널
몇 주 동안 알림을 기록한 후(일반 텍스트 파일로. 알림 아키텍처에 관한 기사를 쓸 것 같은 사람다운 방법입니다), 패턴이 나타났습니다. 하루 약 200개의 알림 중 실제로 한 시간 내에 조치가 필요했던 것은 다섯 가지 카테고리에 속했습니다:
- 누군가가 당신으로 인해 블로킹되어 있습니다. 당신이 소유한 코드의 PR 리뷰 요청, 당신만이 답할 수 있는 질문, 당신의 의견을 기다리는 결정. 이것이 지연에 복리 비용이 발생하는 유일한 카테고리입니다. 응답하지 않는 매 시간이 다른 사람이 일할 수 없는 시간입니다.
- 당신이 배포한 것이 고장났습니다. 당신 브랜치의 CI 실패, 머지 후 오류 급증, 되돌리기 요청. "당신의 코드가 불타고 있다" 카테고리.
- 현재 작업에 영향을 미치는 결정이 내려졌습니다. 디자인 변경, API 계약 업데이트, 제품 측의 우선순위 변경. 드물지만 놓치면 큰 비용이 드는 것들(위의 거부된 PR 참조).
- 마감일이 이동했습니다. 스프린트 범위 변경, 데모가 앞당겨짐, 의존성이 밀림. 캘린더를 바꾸는 이벤트.
- 누군가가 도움이 필요하고 당신이 적합한 사람입니다. 모든 @channel이 아닙니다. 모든 @here도 아닙니다. 당신의 전문성이 진정으로 관련된 특정한 것들만, 그것도 다른 누군가가 답할 수 없는 경우에만.
그 외 모든 것, 상태 전환, 자동화된 봇 메시지, "좋아요" 이모지 반응, 보고 있지 않은 브랜치의 CI 통과, 이것들은 언젠가 유용할 수 있는 정보지만 작성 중인 함수를 방해할 필요는 없습니다. 알림 산업 복합체는 이 모든 것이 동등한 긴급성을 가진다고 우리를 설득해왔습니다. 그렇지 않습니다.
하루 200개의 알림 중 실제로 하던 일을 방해할 가치가 있는 것은 약 5가지 카테고리뿐입니다. 나머지는 언젠가 유용할 수 있는 정보입니다. 하지만 도구들은 모든 것을 동등하게 긴급하게 취급하므로, 결과적으로 아무것도 긴급하지 않게 됩니다.
아키텍처에 배신당한 자를 위한 트리아지 프레임워크
오늘부터 사용할 수 있는 프레임워크를 소개합니다. 도구는 필요 없고 규율과 약 20분의 설정만 있으면 됩니다. 아키텍처 문제는 해결하지 못합니다(중복 제거 레이어 외에는 해결할 수 없습니다). 하지만 장기적인 해결책을 평가하는 동안 출혈을 멈출 것입니다.
하루 2회 스윕: 지속적으로 알림을 확인하는 대신 두 번의 스윕으로 묶습니다. 오전에 한 번, 오후에 한 번입니다. 각 스윕 동안 GitHub 알림, Linear 수신함, Slack 읽지 않은 것을 확인하고 각각을 세 가지 버킷으로 분류합니다:
| 버킷 | 규칙 | 조치 | |--------|------|--------| | 지금 처리 | 누군가 블로킹됨, 무언가 고장남, 또는 결정이 필요 | 즉시 처리 | | 배치 | 중요하지만 시간적으로 여유 있음 | "나중에 답장" 목록에 추가, 하루 끝에 처리 | | 보관 | 봇 잡담, 상태 업데이트, 해결된 스레드, 중복 | 읽음 표시 후 계속 진행 |
Slack에서 채널 수준 기본값 설정: 각 채널에 대해 결정합니다: 이것이 "지금 처리" 채널(팀 작업 채널, 인시던트 채널)인가, "배치" 채널(일반 공지, 크로스팀 업데이트)인가? 배치 채널을 음소거하고 스윕 중에만 확인합니다. 네, 이것은 기술적으로 음소거이고, 방금 두 단락에 걸쳐 비판한 것입니다. 차이점은 존재하지 않는 척하는 대신 일정에 따라 확인한다는 것입니다.
GitHub 알림 필터 사용: github.com/notifications?query=reason:review-requested를 북마크하세요. 이 URL은 당신에게 명시적으로 할당된 PR 리뷰만 표시하여 구독/CI 노이즈를 완전히 차단합니다. 이메일의 경우 GitHub에는 필터링할 수 있는 reason 헤더(review_requested, mention, subscribed, ci_activity)가 포함되어 있습니다. "subscribed"와 "ci_activity"를 자동 보관하면 실제로 필요한 것을 잃지 않습니다. GitHub이 이 유용한 메타데이터를 알림 UI가 아닌 이메일 헤더에 묻어 놓는다는 사실은 이러한 시스템의 소비 측면에 얼마나 많은 생각이 들어갔는지를 모두 말해줍니다.
이 접근 방식은 컨텍스트적 시그널을 잡지 못합니다(내 PR을 망친 Figma 댓글을 기억하나요? 하루 2회 스윕도 그것을 잡지 못했을 것입니다). 하지만 노이즈를 60〜70퍼센트 줄여줄 것입니다. 이것은 진짜 해결책이 필요한지 평가하면서 강박적인 alt-tab을 멈추기에 충분합니다.
중복 제거 레이어가 실제로 해야 하는 것
여기서 아키텍처적으로 흥미로워집니다. 그리고 제가 이것을 알림 설정 문제에서 분류 문제로 생각하기 시작한 전환점입니다.
단순한 접근 방식은 키워드 매칭과 멘션 감지입니다. 당신의 이름이 나타나면 표시합니다. 당신에게 할당된 리뷰 요청이면 표시합니다. 이것은 명백한 경우를 잡지만 컨텍스트적인 경우는 완전히 놓칩니다. 아무도 당신이 영향을 받는 컴포넌트를 만들고 있다는 걸 몰라서 @멘션하지 않은 스레드의 디자인 결정(그건 한동안 저를 괴롭힐 것입니다).
실제로 필요한 것은 관계의 그래프입니다: 어떤 작업이 당신 것인지, 어떤 PR이 어떤 이슈와 관련되는지, 어떤 Slack 스레드가 어떤 기능에 대한 것인지, 어떤 사람들이 어떤 주제에 대해 당신의 의견을 필요로 하는 경향이 있는지. 새로운 시그널이 도착하면 – Slack 메시지, GitHub 이벤트, Linear 전환 – 그 지식 그래프에 대해 분류합니다. "이것이 Chris를 언급하나요?"가 아니라 "이것이 Chris가 적극적으로 작업하고 있거나, 기다리고 있거나, 책임지고 있는 무언가에 영향을 미치나요?"
분류는 다음과 같은 것으로 분해되어야 합니다:
| 분류 | 의미 | 조치 | |---------------|---------------|--------| | 긴급 | 누군가를 블로킹하거나 무언가 고장남 | 즉시 표시 | | 중요 | 현재 작업에 영향을 미치지만 시간적으로 중요하지 않음 | 일별 다이제스트로 배치 | | 정보 | 알면 좋지만 조치 불필요 | 찾아볼 때 이용 가능 | | 노이즈 | 중복, 봇 잡담, 해결된 스레드 | 완전히 필터링 |
어려운 점은 분류 신뢰도가 이진이 아니라는 것입니다. 절대 방문하지 않는 채널의 Slack 메시지도 당신에게 할당된 이슈를 참조한다면 긴급할 수 있습니다. 몇 달 동안 건드리지 않은 리포지토리의 GitHub 알림도 누군가가 방금 수정됐다고 생각한 버그를 다시 열었다면 중요할 수 있습니다. 두 레이어가 함께 작동해야 합니다: 들어오는 웹훅을 복합 키(리포지토리, 이슈 ID, 액터, 이벤트 유형)에 대해 해싱하고 TTL 중복 제거 창(기본적으로 최근 이벤트 핑거프린트의 슬라이딩 창)에 대해 확인하는 이벤트 정규화 레이어, 그 뒤에 작업 소유권, PR 연결, 스레드 참가자, 최근 활동 패턴을 매핑하는 라이브 관계 지식 그래프. 팀의 작업 상태 전체의 읽기 모델을 거의 실시간으로 업데이트하고 들어오는 모든 시그널에 대해 쿼리하는 것을 구축하는 셈입니다. 중복 제거 레이어는 명백한 중복을 잡습니다. 지식 그래프는 더 어려운 질문에 답합니다: "이것이 지금, 당신에게 구체적으로 관련 있나요?"
핵심 분류 루프는 명확한 경우를 잘 처리하고 그것만으로도 노이즈를 크게 줄입니다. 하지만 진정으로 모호한 시그널(억제할 만큼 자신 있지 않지만 표시할 만큼 자신 있지도 않은)은 아직 해결되지 않은 문제입니다. 그것들을 "maybe" 다이제스트로 배치하는 실험을 하고 있지만, 해결했다고 주장하지 않겠습니다.
호스가 멈췄을 때 무엇이 바뀌는가
예상하지 못한 것이 있었습니다. 단순히 "알림이 적다"만의 이점일 거라고 진심으로 생각했는데 그 이상이었습니다. 도구들이 소리치는 것을 멈추면 도구와의 관계가 근본적으로 바뀝니다.
모든 알림이 중요할 수 있을 때, 읽지 않은 수에 대한 낮은 수준의 불안이 생깁니다. 굵은 채널 이름이 즐비한 Slack 사이드바. GitHub 벨. Linear 수신함. 긴급한 것을 기대해서가 아니라 무언가를 놓치는 비용이 노이즈로 드러나는 50개를 확인하는 비용보다 높게 느껴지기 때문에 강박적으로 확인합니다. 함수 시그니처와 본문을 쓰는 사이에 Slack으로 alt-tab 했습니다. 의식적인 결정이 아니라 빨간 신호에서 미러를 확인하는 것 같은 반사였습니다.
예방적 자기 방해는 알림 자체보다 더 나쁘다고 할 수 있습니다. 왜냐하면 핑이 도착하기 전에 스스로 집중을 깨뜨리기 때문입니다. 지속적인 부분적 주의 상태에서 살고 있고, 작성하는 코드에서 그것을 느낄 수 있습니다. 얕은 리뷰, 더 안전한 아키텍처 선택, 45분의 방해받지 않는 생각 시간을 갖지 못할 것 같아서 실제로 올바른 접근 방식 대신 최소 저항의 길.
호스가 멈추면, 중요한 시그널이 찾아오고 노이즈는 찾아오지 않는다고 신뢰하면, 그 반사가 사라집니다. 즉시는 아닙니다. 오래된 습관은 고집스럽기 때문입니다. 하지만 몇 주 안에 강박적인 alt-tab 없이 에디터에서 더 오래 머무르는 것을 알아차립니다. 생각을 마무리하기 시작합니다. 더 나은 코드를 작성합니다. 갑자기 더 똑똑해진 게 아니라 요청하지도 않은 알림 시스템을 위해 시간당 30번의 컨텍스트 스위칭을 자원하는 것을 멈췄기 때문입니다.
알림의 홍수에서 벗어나세요. Sugarbug은 Linear, GitHub, Slack의 모든 시그널을 관련성에 따라 분류하고 실제로 필요한 것만 표시합니다.
Q: Sugarbug은 Linear, GitHub, Slack의 알림 폭주를 줄여줄 수 있나요? A: 네. Sugarbug은 API를 통해 Linear, GitHub, Slack에 연결하고 모든 시그널을 긴급도와 관련성으로 분류합니다. 모든 알림을 전달하는 대신 주의가 필요한 것만 표시합니다. 수백 개의 일일 알림이 진정으로 당신이 필요한 소수로 줄어드는 것이 일반적입니다.
Q: Sugarbug은 현재 작업 내용을 바탕으로 GitHub PR 알림을 우선순위화할 수 있나요? A: Sugarbug은 작업, PR, 대화의 지식 그래프를 구축합니다. 어떤 PR이 현재 작업과 관련 있는지 파악해 리뷰 요청, 머지 충돌, CI 실패를 먼저 표시하고 나머지는 조용히 보관합니다.
Q: Sugarbug은 Slack의 내장 알림 설정과 어떻게 다른가요? A: Slack의 설정으로는 채널을 음소거하거나 키워드를 설정할 수 있지만, 여러 도구에 걸친 컨텍스트를 이해하지 못합니다. Sugarbug은 Linear, GitHub, Slack을 함께 읽어 음소거한 채널에 있는 PR 관련 Slack 스레드도 긴급하다고 인식합니다.
Q: 엔지니어링 팀에서 알림 과부하의 실제 비용은 무엇인가요? A: UC 어바인의 글로리아 마크 연구에 따르면 방해를 받은 후 깊은 집중을 되찾는 데 약 23분이 걸린다고 합니다. 알림 자체뿐 아니라 그것이 만들어내는 강박적인 확인 행동이 복잡한 엔지니어링 작업에 필요한 지속적인 집중을 분산시킵니다.
엔지니어링 팀의 알림이 "정보 유지"에서 "불안 유지"라는 선을 넘었다면, 그것은 아마도 알림 설정이 아니라 아키텍처를 수정해야 한다는 신호일 것입니다.