주말 슬랙 알림 공포증: 무음 설정의 비극

가을이 들어서니 퇴근길이 조금 더 편해졌다. 해가 일찍 지니까 야근을 하지 않는 이상 어두운 건물을 빠져나올 수 있다는 뜻이니까. 어제도 그랬다. 금요일 6시 딱 맞춰 자리에서 일어났고, 모니터를 끄고 슬랙을 열었다. 상태 메시지를 “자리 비움”에서 “주말 모드”로 바꾸고, 손가락이 거기서 멈췄다.

슬랙 알림 설정 화면. 그 초라한 체크박스들이 나를 바라보고 있었다.

금요일 저녁, 결정의 순간

보통 금요일 밤이 되면 이 문제가 터진다. 혼자만의 싸움이 아니라, 개발자라면 누구나 겪는 그 오래되고도 끝나지 않는 문제. “슬랙 무음으로 할 거야, 아니면 소리 켜둘 거야?”

회사 지친다고 늘 투덜대던 선배 개발자 김상현이는 올해 초 이렇게 말했었다. “나? 그냥 핸드폰 내려놔. 금토일 슬랙 안 본다. 죽고싶지 않으면.” 그의 얼굴에선 반은 농담이고 반은 진지함이 묻어났다. 나는 한참을 생각했다. 그게 가능할까? 정말?

나는 그정도까진 못하겠다고 생각했다. 온전히 손을 놓는 건 너무 무섭다. 배포 이슈라도 터지면? QA 팀에서 급한 버그를 발견하면? 아니면 시스템이 다운되면? 일단 한 번 “음소거” 버튼을 눌렀다. 휴대폰의 슬랙 앱을 열어서 알림을 모두 끐다. “세상이 아무리 떠들어도 나는 모를 일”이라는 생각으로.

그런데 마음이 놓이지 않는다.

30분을 버티더니 다시 설정 화면으로 돌아갔다. 조용할 땐 너무 조용하고, 그 조용함 속에서 내 상상만 자꾸 살아난다. 우리 서비스 메인 데이터베이스가 지금 이 순간 죽어가고 있는 건 아닐까? Redis 캐시가 터졌을지도 모르지? 아니면 저 신입 개발자 이준호가 실수로 프로덕션에 직접 핫픽스를 푸시했거나. 음… “도움말”이 라는 설정으로 바꿔봤다. 긴급 메시지만 울리게. 하지만 슬랙에서 “긴급”의 정의가 뭔지는 아무도 명확히 알지 못한다.

결국 일요일 자정을 넘길 무렵, 나는 이 설정들을 전부 다시 기본값으로 되돌렸다. 음성 알림, 배지, 데스크톱 알림 전부. “차라리 좀 울리는 게 낫지.” 이렇게 중얼거리며.

월요일 아침의 악몽

실제로 그런 일이 터진 건 3주 전이었다. 정확히는 지난 8월 셋째 주 토요일이었다.

금요일 오후 4시쯤에 우리 팀에 신규 배포가 들어갔다. 여름 행사 특수 기간을 대비하는 배포였고, 내가 리뷰한 PR 3개, 다른 팀원들이 리뷰한 PR 4개가 포함되어 있었다. 보통 배포는 금요일 오전에 하는 게 회사의 암묵적인 룰인데, 이번엔 기획팀 요청으로 오후에 했다. “마지막 데이터 정합성만 한 번 더 체크하려고요.”라는 명목 아래. 배포 후 한 시간 정도 모니터링을 하고 나서 나는 좀 이상한 느낌이 들긴 했지만, 에러 로그도 없고 응답 속도도 괜찮아 보였다.

금요일 6시. 회사를 나왔다. 토요일은 아내가 일찍 집에 올 예정이라서 카페를 한 바퀴 돌고 회사 근처 마트에 들렀다가 집으로 돌아갔다. 첫 번째 무음 설정을 했다. 휴대폰에서.

“주말이야, 조용해지자.”

토요일은 정말 조용했다. 슬랙이 울리지 않았다는 게 아니라, 나는 그걸 들을 수 없도록 설정했으니까. 아내랑 영화도 봤고, 점심에 밖에서 밥도 먹었다. 일요일도 비슷했다. 치킨을 시켜먹고, 개인 노트북으로 쓸데없는 깃허브 레포지토리도 만들어 봤다가 포기했다. 휴대폰은 책상 한구석에 놔뒀다.

월요일 아침 7시 40분.

회사로 출근하는 지하철 안에서 휴대폰의 알림을 다시 켰다. 아이폰 화면에 한 번에 터져나온 슬랙 알림. 빨간 배지에 “47”이라고 떠있었다. 47개. 토요일 오후 2시부터 일요일 밤 11시까지, 거의 36시간 동안 온 메시지들. 내 얼굴이 확 굳었다.

슬랙을 열었다.

[12:47] 팀장: 배포 후 데이터 정합 이슈 감지. 회원 경험치 산정에 문제 있는 것 같음. 확인 부탁

[12:59] 이준호: 김개발님 계신가요?

[13:15] 팀장: 김개발님 일하시나요? 응답 부탁

[13:47] QA담당자: 심각해보이는데 배포 롤백할까요?

[14:02] 팀장: 긴급 회의실 1번방 입장 부탁

[14:15] 팀장: 김개발님 연락 안 되네요. 우선 롤백 결정

[14:33] CTO: 앞으로 변경사항 발생했을 때 담당 개발자 연락 안 되면 팀장이 직접 롤백하기로. 공지 예정

[14:47] 이준호: 형… 왜 연락이…

[15:22] QA담당자: 롤백 완료. 원인 파악 필요. 코드 리뷰 다시 해야 할 것 같음

후속 메시지는 토요일 밤부터 일요일 내내 이어졌다. 동료들이 원인을 찾아내려고 한 흔적들, 몇 가지 추측들, 그리고 점점 우울해지는 톤.

내 손이 떨렸다.

원인은 결국 월요일 아침 회의에서 밝혀졌다. 내가 승인한 PR 중 하나였다. 신규 기능을 추가할 때 캐시 무효화 로직을 제대로 넣지 않아서, 기존 데이터와 새 데이터가 섞여서 나왔던 거였다. 코드만 봐도 한 30초면 문제를 찾을 수 있는 수준이었다. 나는 그날 오후 3시경 PR을 승인했고, 리뷰하면서 커피를 마셨고, 그때 화면에 다른 창을 띄웠었다. 그래서 그 부분을 놓쳤다.

팀장은 차분하게 말했다. “배포 전에 충분한 모니터링 시간이 없었고, 금요일 오후 배포가 그래서 위험한 거다. 근데 역시 배포 담당자가 주말에라도 연락은 돼야 할 것 같아. 그게 프로페셔널이니까.”

내가 “죄송합니다”라고 말하는 동안, 마음속으로는 다른 생각이 맴돌고 있었다.

“아, 그래. 내가 무음으로 설정하지 말았어야 했나?”

트루 스토리: 다른 동료들은?

그 이후로 나는 다른 팀원들과 아주 솔직한 대화를 나눴다. “너희 금토일 슬랙은 어떻게 해?”

결과는 놀랍게도 다양했다.

먼저 박세진 선배. 15년차 벡엔드 개발자다. 그이는 “핸드폰 자체를 집에 안 가져가”라고 했다. 회사 휴대폰 따로, 개인 휴대폰 따로. 퇴근하고 회사 핸드폰을 락커에 둔다는 뜻이었다. “그렇게라도 해야 미쳐 안 된다고.”

그 다음은 신입 이준호. 그이는 “뭐 어차피 내가 롤백할 권한도 없으니 음소거 해도 되겠지?”라고 했다. 면접 때는 “회사를 위해 개인 시간도 아끼겠습니다”라고 했지만, 현실은 다르다고. 밀실에서 혼잣말로 한숨을 쉬는 모습이 보였다.

그리고 QA팀의 이수영 팀장. 그이는 “그냥 개인 휴대폰엔 안 깔아. 회사 노트북이랑 회사 핸드폰은 회사 건물 밖으로 안 가져간다”고 했다. “배포 담당자랑 팀장만 음성 알림을 켜. 나머지는 배지만 켜서 나중에 확인하고, 정말 긴급하면 전화를 해.”

가장 현실적인 건 아키텍처를 담당하는 김수진이었다. “배포 관리 정책을 바꿨어. 금요일 오후 배포는 원칙적으로 금지. 긴급이면 수동으로 팀장 승인 받고, 그때는 배포 담당자가 일요일 저녁까지는 깨어 있기로 계약서처럼 합의.”

나는 이 대화들을 들으면서 깨달았다. 결국 “정답은 없다”는 것을.

모두가 놓친 포인트: 시스템의 문제

월요일 회의가 끝나고 나서 한 가지 더 진행된 게 있다. 신규 정책 수립이었다.

CTO가 주도해서 만든 규칙:

1. 금요일 오후 3시 이후 프로덕션 배포 금지 (긴급 제외)
2. 배포 담당자는 배포 후 최소 2시간 모니터링 필수
3. 긴급 배포는 팀장이 반드시 동반하고, 배포 담당자 연락처 3곳 모두에 연락
4. 배포 롤백 프로세스 자동화 (수동 롤백 시간 단축)
5. 모니터링 대시보드 표준화 (동일한 항목을 모두가 체크)

여기서 재미있는 건, 이 규칙들이 사실 “개발자의 주말을 보호하기 위한” 규칙이 아니라, “배포 이슈를 줄이기 위한” 규칙이라는 점이었다. 결과적으로 개발자 복지가 향상됐지만, 그건 부수효과였다.

내가 느낀 건 이거였다: 개발자 개인이 슬랙 음소거를 고민하는 게 아니라, 회사가 시스템을 고민해야 한다는 거.

문제는 금요일 오후 배포가 터졌을 때 개발자가 주말에 대응할 수 있는 여건이 아니었다. 문제는 배포 담당자만 원인을 알고 있어서, 다른 팀원들이 복구를 하지 못했다. 문제는 롤백 프로세스가 느려서 36시간이나 서비스가 깨진 상태로 남았다.

그 모든 게 개발자 개인의 휴대폰 음소거 설정이 해결할 수 있는 문제가 아니었다.

다음 주 월요일, 나는 슬랙 설정을 다시 만졌다.

이번엔 자신감 있게 “모든 알림 켜기”를 눌렀다. 하지만 이상하게도 마음이 불안했다. 왜냐하면 이제 토요일 오전에 알림이 울려도, 그건 시스템의 문제이지 내가 음소거를 하지 않은 문제는 아니라는 걸 알았으니까.

결국 우리는 뭘 배워야 하나

지금 시점에서 돌아보면, 이 사건은 여러 층의 실수가 겹쳐진 결과였다.

첫째, 내 리뷰가 정확하지 않았다. 그건 인정한다. 오후 3시쯤 피로도가 높아진 상태에서 캐시 로직까지 한눈에 보기는 어려웠고, 나는 충분히 신경을 쓰지 않았다.

둘째, 금요일 오후 배포라는 시스템의 문제가 있었다. 팀장도, CTO도, 아무도 지적하지 않았다. “그런가보네?”라고 넘어갔다.

셋째, 배포 후 모니터링이 불충분했다. 1시간 정도만 한 후 “괜찮겠지”라고 생각했는데, 실제로는 특정한 기간대의 특정한 행동을 했을 때만 버그가 터지는 거였다.

넷째, 그리고 내가 무음 설정을 했다. 이건 앞의 세 문제를 안고도, 마지막 방어선을 없앤 셈이다.

근데 생각해보니 넷째가 가장 비난하기 쉬운 부분이어서, 결국 나만 욕먹은 거다. “휴대폰 확인 좀 해. 어른답게.”라는 눈길들.

분명히 내 잘못도 있다. 50%는 내 책임이다. 근데 나머지 50%는? 그건 개발팀의 프로세스, 배포 정책, 모니터링 시스템, 회사 문화였다.

그리고 문제는, 이 50%를 개발자 개인이 해결해야 한다고 생각하는 경향이 업계 전체에 있다는 거다.

“너는 열정이 있으니까, 주말도 슬랙을 체크해.” “너는 시니어니까, 배포 관련 알림은 꺼도 안 된다.” “너는 팀 리드니까, 팀원 문제는 언제든 해결할 수 있도록.”

이런 문화들. 다들 어느 정도는 옳은 말이지만, 어느 정도는 우리를 갈아서 커피를 만드는 과정이기도 하다.

우리가 만든 새로운 규칙

회의가 계속되면서, 재미있는 일들이 생겼다.

팀원들이 하나둘 자기 생각을 말하기 시작했다. 보통 개발자들은 회의에서 조용한데, 이번엔 달랐다.

이준호: “그 금요일 오후 3시 금지 정책, 혹시 긴급 배포가 생기면 누가 판단하는 거죠?”

수진: “좋은 질문. 팀장이 하나 다 결정하기엔 너무 많으니까, 기획팀, QA팀, 개발팀 합의로.”

이준호: “그럼 합의하는 과정에 제한 시간이 있어야 하지 않을까요? 왔다갔다 하다가 배포 시간이 늦어지면, 또 금요일 저녁이 될 텐데.”

세진: “맞다. 결정 30분 이내. 결정이 못 나면 일단 롤백하고 월요일에 다시 배포.”

김수진: “좋아. 그럼 롤백 프로세스도 표준화 해야지. 지금은 수동으로 하니까 시간이 오래 걸려.”

팀장: “롤백 스크립트 만들 사람?”

”…”

결국 그건 내가 하기로 했다. 하지만 이번엔 다르게 생각했다. 이 스크립트를 나만 알고 있으면 또 다음에도 나한테 물어볼 거다. 그래서 나는 문서화하기로 했고, 팀원들이 전부 롤백할 수 있도록 교육하기로 했다.

“난 모르겠어”라고 말할 수 있는 환경을 만들자는 뜻이었다.

정답은 여기에 있지 않다, 하지만

8월의 일이 있은 지 지금 거의 2개월가 지났다.

금요일 오후 배포는 이제 거의 없다. 긴급으로 생기면 팀장과 CTO가 직접 와서 상황을 본다. 내 휴대폰 알림이 울려도, 그건 정말 급할 때만이다.

근데 솔직히 말해서, 나는 여전히 금요일 퇴근 후 슬랙 앱을 음소거한다.

완전히 차단하는 건 아니고, “중요” 태그가 달린 메시지들만 알람이 오도록 설정했다. 그리고 화요일부터 금요일까지는 그 설정도 안 본다. 그냥 슬랙 앱을 삭제했다. 회사 노트북은 회사에 두고, 퇴근하면서 PC를 종료한다.

아내가 최근에 물었다. “일 생각 안 하니?”

나는 “일 생각이 나면 월요일까지 기다리지 뭐.”라고 대답했다.

그 대답에 아내는 웃었고, 나도 웃었다. 하지만 속으로는 이렇게 생각했다.

일이 정말 나가리면, 그건 내 책임만이 아니다. 그걸 수습할 시스템과 팀, 회사의 문제도 있다. 내가 토요일 오전 11시에 알림 하나를 못 봤다고 해서, 전체 배포 프로세스가 무너져서는 안 된다.

만약 그게 무너지는 거라면, 그건 내 휴대폰 설정이 아니라 회사의 시스템이 약한 거다.

그래서 나는 이제 다르게 생각한다.

슬랙을 음소거하는 게 죄책감이 아니라, 권리라고. 정시 퇴근이 “게으름”이 아니라 당연한 일과라고. 배포 담당자가 주말 연락이 안 돼도 롤백할 수 있는 시스템이 갖춰지는 게 “프로페셔널”이라고.

다음 달 예산 회의에서, 내가 모니터링 자동화 도구 도입을 건의하기로 했다. 그리고 배포 후 자동 테스트 강화도 건의하기로 했다. 롤백 자동화 시스템도.

왜냐하면 결국, 문제의 답은 개발자의 주말 시간에 있지 않으니까.

---

좋은 시스템도 결국은 휴일에 음소거를 믿고 일어난다.