배포 실패 로그 30분 트리아지 플레이북

배포 실패 상황에서 가장 많이 보는 실수는 로그를 처음 줄부터 끝까지 읽으면서 "정답 로그"를 찾으려는 습관입니다. 운영에서는 이 방식이 거의 항상 늦습니다. 실제로 사용자 영향은 이미 진행 중이고, 20분이 지나면 원인보다 신뢰 하락 비용이 더 커집니다. 그래서 첫 단계는 분석이 아니라 문제 정의입니다. 현재 장애가 모든 요청에서 발생하는지, 특정 API와 특정 리전에만 보이는지, 로그인 이후 흐름에서만 터지는지부터 분리해야 합니다. 저는 온콜 문서에 이걸 영향 범위 3분 컷으로 고정해 둡니다. CDN 5xx 비율, 애플리케이션 에러율, 결제/로그인 같은 핵심 전환 지표를 동시에 보고 "전면 장애/부분 장애/기능 장애" 중 하나로 라벨링합니다. 이 라벨이 정해져야 팀이 같은 화면을 보고 말하게 됩니다. 원인 추정은 그다음입니다. 라벨 없이 로그를 파면, 각자 다른 가설을 들고 회의실에 들어와 시간을 버리게 됩니다.

판단 기준은 단순해야 현장에서 작동합니다. 저는 배포 직후 장애 트리아지에서 로그를 기술 스택이 아니라 서비스 경계로 나눕니다. 첫 묶음은 인증/세션, 두 번째는 데이터 저장소, 세 번째는 외부 연동입니다. 인증 실패가 급증하면 배포된 환경 변수나 쿠키 도메인 설정을 우선 의심하고, DB 타임아웃이 올라가면 마이그레이션 락이나 커넥션 풀 고갈을 먼저 확인합니다. 외부 API 오류는 우리 코드 버그처럼 보일 때가 많아서, 반드시 공급자 상태 페이지와 우리 재시도 로그를 함께 봐야 합니다. 여기서 중요한 것은 "무엇을 증명할지"를 미리 정해 두는 것입니다. 예를 들어 로그인 401 증가 + 세션 서명 키 변경 이력이 함께 보이면 롤백 후보 1순위, DB wait event 급증 + 스키마 변경 직후면 읽기 트래픽 우회나 마이그레이션 중단을 즉시 검토합니다. 체크 기준이 숫자와 조건으로 적혀 있으면, 주니어 온콜도 감으로 결정하지 않고 같은 결론에 도달할 수 있습니다.

실행 절차는 30분 타임박스로 끊어야 합니다. 0~10분에는 피해 확산 차단, 10~20분에는 가설 축소, 20~30분에는 복구 방식 확정으로 분리합니다. 지난 분기 실제 사고에서 제가 맡았던 케이스는 배포 후 7분 만에 결제 API 성공률이 92%에서 61%로 떨어졌고, 팀은 처음에 PG사 장애를 의심했습니다. 하지만 에러 로그를 묶어 보니 외부 호출 실패보다 내부 요청 서명 검증 실패가 먼저였고, 새 릴리스에서 시크릿 로딩 경로가 바뀐 게 핵심이었습니다. 이때 회의에서 오래 토론하면 끝이 없어서 "성공률 80% 미만 5분 지속 시 즉시 롤백" 규칙을 발동했고, 롤백 후 6분 내 89%까지 회복시킨 뒤 핫픽스를 분리 배포했습니다. 이 장면에서 배운 점은 하나입니다. 원인 100% 확정 전에도 롤백 기준을 만족하면 되돌려야 한다는 것. 운영은 정답 찾기 게임이 아니라 손실 최소화 게임입니다.

운영 체크리스트는 배포가 끝난 뒤가 아니라 장애가 끝난 직후 24시간 내에 작성해야 효과가 있습니다. 최소 항목은 다섯 가지면 충분합니다. 첫째, 탐지 지연 시간(장애 발생부터 알림 수신까지). 둘째, 판단 지연 시간(알림부터 복구 액션 결정까지). 셋째, 복구 지연 시간(결정부터 정상 지표 회복까지). 넷째, 커뮤니케이션 품질(고객 공지와 내부 공유가 일치했는지). 다섯째, 재발 방지 작업의 소유자와 마감일입니다. 특히 주의할 점은 "로그가 부족했다" 같은 모호한 결론으로 끝내지 않는 것입니다. 어떤 필드가 없어서 어떤 판단이 늦었는지, 대시보드 임계치가 실제 트래픽 패턴과 어떻게 어긋났는지까지 문장으로 남겨야 다음 온콜이 그대로 재사용할 수 있습니다. 문서가 기술 회고에서 끝나지 않고 실행 작업으로 연결될 때, 배포 실패는 단순한 사고 기록이 아니라 팀 운영 체계를 강하게 만드는 데이터가 됩니다.