온콜 인수인계에서 SLO 알림 튜닝까지: 새벽 장애를 줄인 운영 플레이북

서비스가 커질수록 장애 자체보다 인수인계 실패가 더 비싸게 돌아옵니다. 우리 팀도 분기 초에 같은 패턴을 세 번 겪었습니다. 자정 이후 결제 API 지연이 올라오면 대시보드에는 빨간 선이 쏟아지는데, 당번 엔지니어가 어떤 경고부터 믿어야 하는지 기준이 달라 대응 순서가 계속 바뀌었습니다. 특히 금요일 새벽에는 이전 담당자가 “DB 연결 수 확인 필요”라는 한 줄만 남긴 채 퇴근했고, 다음 담당자는 커넥션 풀 문제인지 외부 PG 지연인지 분리하지 못해 40분을 로그 탐색에 썼습니다. 그날 회고에서 확인한 핵심은 기술 난도가 아니라 실행 문서의 구조였습니다. 그래서 인수인계 문서를 사건 요약형에서 실행 지시형으로 바꿨고, 첫 화면에 현재 위험 경로, 즉시 차단 스위치, 롤백 가능 버전 세 칸만 남겼습니다. 문서가 짧아지니 오히려 판단 속도가 빨라졌고, 다음 주부터는 같은 유형의 경고가 와도 초기 10분 안에 원인 후보를 둘로 줄일 수 있었습니다.

문서를 고친 뒤에는 SLO 자체를 다시 정의했습니다. 이전에는 전체 요청 에러율 1개만 보고 알림을 만들었는데, 이 방식은 실제 사용자 체감과 자주 어긋났습니다. 예를 들어 검색 API가 순간적으로 흔들려도 결제 흐름이 정상이라면 비즈니스 충격은 제한적인데, 단일 에러율은 동일한 심각도로 페이지를 울렸습니다. 그래서 사용자 경로를 로그인, 탐색, 결제 세 구간으로 나누고 각 경로마다 에러 버짓을 별도로 부여했습니다. 임계치도 “5분 평균 2% 초과” 같은 고정 숫자 대신 “최근 7일 동일 시간대 대비 편차 + 절대 임계치 동시 만족” 조건으로 바꿨습니다. 이중 조건을 넣으니 트래픽 피크 시간의 정상 흔들림은 걸러지고, 실제 장애로 번지는 급격한 이상만 남았습니다. 중요한 점은 지표를 많이 만드는 게 아니라, 경보가 울렸을 때 담당자가 바로 실행할 수 있는 액션과 1:1로 연결되게 만드는 것입니다. 경보 설명 텍스트에도 원인 추정 문구를 금지하고, 확인 순서를 번호로 강제했습니다.

실행 절차는 주간 루틴으로 고정했습니다. 월요일에는 지난주 경보를 무시 가능, 추적 필요, 즉시 수정 세 그룹으로 분류하고, 수요일에는 라우팅 규칙을 점검해 야간 알림이 사람을 제대로 찾는지 확인했습니다. 여기서 가장 효과가 컸던 변화는 “알림 소유권”을 코드 소유권과 분리한 것입니다. 특정 마이크로서비스의 코드 오너가 아닌, 해당 경로의 복구 경험이 많은 사람이 1차 알림을 받게 하니 응답 시간이 안정됐습니다. 금요일에는 20분 복구 드릴을 넣어 실제로 스위치를 누르고 롤백 커맨드까지 실행해 봤습니다. 처음 두 번은 체크리스트가 길어 중간에 누락이 났지만, 세 번째부터는 단계 수를 9개에서 5개로 줄이면서 평균 복구 시간이 눈에 띄게 감소했습니다. 드릴 기록은 길게 쓰지 않고 “막힌 단계, 원인, 다음 수정”만 남겼고, 다음 주 첫 회의에서 바로 플레이북에 반영했습니다. 이 루프를 한 달 돌리자 새벽 고우선 알림 건수가 절반 가까이 줄었습니다.

운영 체크리스트는 화려할 필요가 없습니다. 대신 실패를 빨리 드러내야 합니다. 첫째, 알림 메시지에 반드시 서비스 버전과 최근 배포 SHA를 포함해 원인 추정 시간을 줄입니다. 둘째, 온콜 시작 30분 안에 차단 스위치 동작 여부를 수동 확인해, 실제 장애 순간에 토글이 먹지 않는 사태를 예방합니다. 셋째, 에러 버짓 소진률을 주간 보고서 첫 줄에 배치해 기능 개발 압박 속에서도 신뢰도 비용을 가시화합니다. 넷째, 임계치 변경은 즉시 반영하지 말고 24시간 관찰 플래그를 두어 과민 반응을 방지합니다. 다섯째, 장애 종료 후 24시간 이내에 대시보드 캡처와 타임라인을 함께 보관해 “왜 늦었는지”를 개인 기억이 아니라 증거 기반으로 검토합니다. 마지막으로 회고 문서에는 “무엇을 배웠나”보다 “다음 담당자가 5분 안에 무엇을 할 수 있나”만 남기면 됩니다. 실제 현장에서는 완벽한 탐지보다 빠른 의사결정이 팀을 살립니다. 인수인계 문서, SLO, 알림 라우팅, 복구 드릴을 따로 운영하지 말고 한 세트로 묶어야 새벽 장애가 줄어듭니다.