장애 대응 문서가 없는 팀의 공통점: 다들 기도부터 합니다

장애 대응 문서가 없는 팀의 공통점: 다들 기도부터 합니다

no-incident-runbook-prayer-first

소개

서비스 장애가 발생하면 팀의 진짜 운영 실력이 드러납니다. 평소에는 모두가 침착하고, 대시보드는 멋지고, 배포도 자동화되어 있으며, 회의에서는 “우리도 이제 안정적으로 운영하고 있습니다”라는 말이 자연스럽게 나옵니다. 그런데 어느 날 알림이 울리고, 사용자가 접속이 안 된다고 말하고, 매출 화면이 조용해지고, 고객 문의가 들어오기 시작합니다. 그 순간 팀 채팅방에는 익숙한 문장이 올라옵니다. “혹시 이거 아시는 분 계신가요?”

장애 대응 문서가 없는 팀은 대개 비슷한 순서로 움직입니다. 먼저 모두가 대시보드를 봅니다. 그다음 누가 담당자인지 찾습니다. 그다음 최근 배포를 의심합니다. 그다음 로그 위치를 묻습니다. 그리고 누군가는 조용히 마음속으로 기도합니다. 물론 간절함은 인간적인 반응입니다. 다만 운영 절차가 기도에만 기대면 서비스는 꽤 불안한 신앙 생활을 하게 됩니다.

장애 대응 문서는 거창한 문서가 아닙니다. 문제가 생겼을 때 누가 무엇을 어떤 순서로 확인하고, 어떤 기준으로 결정을 내리며, 누구에게 어떻게 알릴지 정리한 실전 안내서입니다. 이 글에서는 장애 대응 문서가 없는 팀에서 반복되는 문제와, 작은 팀도 바로 시작할 수 있는 대응 문서 구성 방법을 정리하겠습니다.

장애 대응 문서가 없으면 사람이 절차가 됩니다

문서가 없으면 경험 많은 사람이 절차가 됩니다. 어떤 장애가 생기면 모두가 특정 사람을 찾습니다. 그 사람이 온라인이면 다행입니다. 휴가 중이거나 회의 중이거나 잠들어 있으면 대응 속도는 갑자기 느려집니다. 시스템은 여러 명이 운영하지만, 실제 대응 지식은 한 사람의 머릿속에 있는 상태가 됩니다.

이 구조는 위험합니다. 경험 많은 사람이 나쁘다는 뜻이 아닙니다. 오히려 그 사람이 너무 많은 것을 알고 있기 때문에 문제가 됩니다. 중요한 정보가 개인에게만 있으면 팀은 그 사람의 기억력과 컨디션에 의존하게 됩니다. 장애는 보통 가장 친절한 시간에 오지 않습니다. 중요한 지식이 머릿속에만 있으면, 새벽 알림 앞에서 팀 전체가 기억력 테스트를 보게 됩니다.

장애 대응 문서는 사람을 대체하지 않습니다. 사람의 판단을 돕습니다. 장애 상황에서는 평소보다 사고 폭이 좁아집니다. 알림은 울리고, 고객은 기다리고, 팀 채팅방은 빨라집니다. 이때 문서는 “먼저 이것부터 보세요”라고 알려 주는 작은 난간이 됩니다. 난간이 있으면 뛰어난 사람이 아니어도 넘어지지 않을 가능성이 커집니다.

기도부터 하는 팀의 흔한 증상

장애 대응 문서가 부족한 팀에는 몇 가지 공통 증상이 있습니다. 이 증상이 익숙하다면 팀이 게으른 것이 아니라, 운영 지식이 아직 문서화되지 않았다는 신호일 수 있습니다.

증상	현장에서 보이는 모습	필요한 문서
담당자를 찾느라 시간이 갑니다.	“이거 누가 봐야 하죠?”라는 질문이 반복됩니다.	서비스별 담당자와 연락 경로
로그 위치를 모릅니다.	로그 도구는 있는데 검색어를 모릅니다.	로그 위치와 검색 예시
심각도를 판단하지 못합니다.	큰 장애인지 작은 오류인지 논쟁합니다.	장애 등급 기준
고객 안내가 늦습니다.	기술 확인에 몰두하다 공지가 늦어집니다.	상황 공유 템플릿
복구 후 배움이 남지 않습니다.	장애는 끝났지만 같은 문제가 다시 옵니다.	회고와 후속 조치 양식

이 표의 핵심은 단순합니다. 장애 대응은 기술만의 문제가 아닙니다. 정보 찾기, 역할 나누기, 의사결정, 커뮤니케이션, 회고가 함께 움직여야 합니다. 이 중 하나라도 비어 있으면 팀은 어느 순간 “일단 재시작해 볼까요?”라는 마법 주문에 기대게 됩니다. 재시작은 가끔 효과가 있지만, 항상 설명을 남겨 주지는 않습니다.

장애 대응 문서에 꼭 들어가야 할 내용

좋은 장애 대응 문서는 길다고 좋은 것이 아닙니다. 장애 중에 읽을 수 있어야 합니다. 평소에는 자세한 설계 문서를 읽을 수 있지만, 장애 중에는 시간이 없습니다. 그래서 대응 문서는 짧고 명확해야 합니다. 첫 화면에서 무엇을 봐야 하는지, 누구에게 연락해야 하는지, 무엇을 하면 안 되는지 알 수 있어야 합니다.

최소한 아래 항목은 포함하는 것이 좋습니다.

1. 서비스 이름과 담당 팀
2. 주요 담당자와 대체 담당자
3. 장애 등급 기준
4. 첫 5분 확인 절차
5. 주요 대시보드와 로그 검색 방법
6. 최근 배포 확인 방법
7. 롤백 또는 임시 차단 기준
8. 고객 또는 내부 공유 문구
9. 복구 확인 기준
10. 장애 후 회고와 후속 조치 양식

이 목록을 처음부터 완벽하게 만들 필요는 없습니다. 오히려 너무 완벽하게 만들려다 문서가 영원히 작성되지 않는 경우가 많습니다. 처음에는 “장애가 났을 때 모두가 같은 첫 페이지를 본다”는 목표면 충분합니다. 문서는 운영하면서 자라야 합니다. 처음부터 백과사전을 만들려 하면, 장애보다 문서 작성이 먼저 장애가 됩니다.

첫 5분 절차가 가장 중요합니다

장애 대응 문서에서 가장 중요한 부분은 첫 5분 절차입니다. 장애 초반에는 정보가 부족하고 감정은 많습니다. 누군가는 원인을 추측하고, 누군가는 최근 배포를 의심하고, 누군가는 서버를 다시 시작하고 싶어 합니다. 이때 첫 절차가 없으면 팀은 각자 다른 방향으로 뛰기 쉽습니다.

첫 5분 절차는 원인을 완벽히 찾는 시간이 아닙니다. 상황을 안정적으로 파악하는 시간입니다. 사용자 영향이 있는지, 어느 서비스가 영향을 받는지, 최근 변경이 있었는지, 알림이 반복되는지, 담당자가 누구인지 확인해야 합니다. 무작정 조치하기보다 먼저 상태를 고정해야 합니다.

• 알림 내용을 확인하고 장애 후보 서비스를 정합니다.
• 사용자 영향이 있는지 대시보드에서 확인합니다.
• 최근 배포나 설정 변경 여부를 확인합니다.
• 장애 등급을 임시로 정합니다.
• 대응 담당자와 커뮤니케이션 담당자를 나눕니다.
• 필요하면 내부 상황 공유 채널을 엽니다.
• 추측성 조치보다 증거 수집을 먼저 합니다.

첫 5분 절차가 있으면 팀의 멘탈이 조금 안정됩니다. 장애가 없어지는 것은 아니지만, 적어도 모두가 같은 방향을 봅니다. 같은 방향을 보는 것만으로도 많은 혼란이 줄어듭니다. 장애 중에는 기술적 안정성만큼 심리적 안정성도 중요합니다. 사람 손이 떨리면 명령어도 조금 더 위험해집니다.

장애 등급 기준이 없으면 모든 일이 큰일이 됩니다

장애 대응에서 등급 기준은 매우 중요합니다. 어떤 상황이 긴급한지, 어떤 상황은 업무 시간에 처리해도 되는지, 어떤 경우에 고객 공지가 필요한지 정해 두어야 합니다. 기준이 없으면 목소리 큰 사람이 장애 등급을 정하게 됩니다. 이것은 운영 체계라기보다 즉석 토론회에 가깝습니다.

장애 등급은 팀마다 다를 수 있지만, 사용자 영향과 비즈니스 영향을 중심으로 나누는 것이 좋습니다. 단순히 오류 로그가 많다고 가장 높은 등급은 아닐 수 있습니다. 반대로 오류 로그가 적어도 결제나 로그인처럼 핵심 기능이 멈췄다면 높은 등급일 수 있습니다.

등급	상황 예시	대응 방식
긴급	전체 서비스 접속 불가, 결제 중단, 데이터 손상 위험	즉시 담당자 호출, 상황 공유, 복구 우선
높음	핵심 기능 일부 실패, 특정 고객군 영향	우선 대응, 원인 분석, 필요 시 공지
보통	우회 가능한 기능 오류, 일부 지연	담당자 배정 후 업무 시간 내 처리
낮음	사용자 영향이 적은 경고, 내부 도구 오류	기록 후 정기 개선 작업으로 처리

장애 등급은 사람을 긴장시키기 위한 장치가 아닙니다. 대응 자원을 적절히 쓰기 위한 기준입니다. 모든 것을 긴급으로 다루면 팀은 금방 지칩니다. 반대로 진짜 긴급 상황을 낮게 보면 피해가 커집니다. 기준은 팀을 차분하게 만드는 도구입니다.

커뮤니케이션 담당자를 따로 두어야 합니다

장애 중에는 기술 담당자와 커뮤니케이션 담당자를 나누는 것이 좋습니다. 원인을 찾는 사람은 로그와 대시보드에 집중해야 합니다. 동시에 고객 문의, 내부 공유, 경영진 보고, 상태 페이지 공지를 모두 처리하면 집중력이 빠르게 사라집니다. 장애 대응 중 멀티태스킹은 멋있어 보이지만, 실제로는 실수의 확률을 올립니다.

커뮤니케이션 담당자는 현재 상태를 정리하고, 확인된 사실과 추정 중인 내용을 구분하며, 다음 업데이트 시간을 공유합니다. 이 역할이 있으면 팀 밖의 사람들이 같은 질문을 반복하지 않아도 됩니다. “지금 어떻게 되고 있나요?”라는 질문이 줄어들면 기술 담당자는 조금 더 문제 해결에 집중할 수 있습니다.

상황 공유 문구는 미리 템플릿으로 준비해 두면 좋습니다. 장애 중에 문장을 처음부터 쓰면 말이 길어지거나 애매해질 수 있습니다. 특히 고객에게 알릴 때는 추측보다 사실을 중심으로 말해야 합니다. 아직 모르는 것은 모른다고 말하되, 다음 업데이트 시점을 함께 알려야 합니다.

상황 공유 예시:
현재 일부 사용자에게 로그인 지연이 발생하고 있습니다.
담당 팀이 원인을 확인 중이며, 최근 배포와 인증 서비스 지표를 함께 점검하고 있습니다.
다음 업데이트는 15분 후 공유하겠습니다.

이런 문구 하나가 장애 대응의 분위기를 바꿉니다. 아무 말이 없으면 사람들은 최악을 상상합니다. 짧고 정확한 공유는 불안을 줄입니다. 장애 대응에서 침묵은 종종 문제보다 크게 느껴집니다.

롤백 기준이 없으면 모두가 망설입니다

장애 중 가장 어려운 결정 중 하나는 롤백입니다. 최근 배포가 의심되지만 확실하지 않을 때, 롤백을 할지 더 조사할지 고민하게 됩니다. 이때 기준이 없으면 시간이 갑니다. 어떤 사람은 “일단 롤백하자”고 하고, 어떤 사람은 “조금만 더 보자”고 합니다. 둘 다 틀린 말은 아닐 수 있습니다. 문제는 판단 기준이 없다는 점입니다.

롤백 기준은 미리 정해 두는 것이 좋습니다. 예를 들어 배포 후 특정 시간 안에 오류율이 급증하고, 핵심 기능에 사용자 영향이 있으며, 원인을 빠르게 분리하기 어렵다면 롤백을 우선할 수 있습니다. 반대로 데이터 마이그레이션이 포함되어 롤백이 더 위험한 경우에는 별도 절차가 필요합니다.

• 최근 배포 이후 오류율이 명확히 증가했나요?
• 사용자 영향이 핵심 기능에 발생했나요?
• 롤백이 데이터 정합성을 해치지 않나요?
• 롤백 절차와 담당자가 명확한가요?
• 롤백 후 복구 확인 지표가 정해져 있나요?

롤백은 실패 인정이 아닙니다. 사용자 영향을 줄이기 위한 운영 판단입니다. 개발자의 자존심보다 서비스 안정성이 먼저입니다. 물론 마음은 조금 아플 수 있습니다. 하지만 장애 중에는 자존심도 잠시 대기열에 넣어 두는 편이 좋습니다.

복구 기준이 없으면 장애가 끝났는지 모릅니다

장애 대응 문서에는 복구 기준도 있어야 합니다. 알림이 멈췄다고 끝난 것이 아닐 수 있습니다. 오류율이 정상으로 돌아왔는지, 응답 시간이 회복됐는지, 큐가 밀린 작업을 처리했는지, 고객 영향이 남아 있는지 확인해야 합니다. 특히 비동기 작업이나 결제, 알림, 데이터 동기화처럼 뒤늦게 영향이 나타나는 기능은 더 조심해야 합니다.

복구 기준이 없으면 누군가는 끝났다고 생각하고, 누군가는 아직 불안해합니다. 그러면 장애는 기술적으로 끝났지만 분위기상 끝나지 않습니다. 복구 기준은 팀이 같은 시점에 “이제 정상입니다”라고 말할 수 있게 해 줍니다.

1. 핵심 지표가 정상 범위로 돌아왔는지 확인합니다.
2. 오류율과 응답 시간이 안정적인지 봅니다.
3. 밀린 작업이나 재처리 대상이 없는지 확인합니다.
4. 고객 문의나 내부 보고가 필요한지 정리합니다.
5. 임시 조치가 있다면 후속 작업으로 등록합니다.
6. 장애 종료 시간을 기록합니다.

장애 종료는 “이제 괜찮은 것 같습니다”가 아니라 “이 기준을 만족했으므로 종료합니다”에 가까워야 합니다. 운영에서는 느낌보다 기준이 오래갑니다. 느낌은 피곤하면 흔들립니다.

장애 후 회고가 없으면 같은 일이 다시 옵니다

장애가 끝난 뒤 바로 일상으로 돌아가고 싶습니다. 모두가 지쳤고, 이미 충분히 힘들었고, 밀린 업무도 기다리고 있습니다. 하지만 회고 없이 넘어가면 같은 장애가 다시 올 수 있습니다. 장애는 친절하게 복습 기회를 제공하는 경우가 많습니다. 물론 우리가 원한 복습 방식은 아닙니다.

장애 후 회고에서는 사람을 탓하기보다 시스템을 봐야 합니다. 알림은 빨랐는지, 대응 문서는 충분했는지, 로그와 대시보드는 도움이 됐는지, 권한 문제는 없었는지, 커뮤니케이션은 적절했는지 확인해야 합니다. 그리고 후속 조치를 담당자와 마감일이 있는 작업으로 남겨야 합니다. “다음에 조심하자”는 회고 결과로는 부족합니다. 다음에는 모두가 또 바쁩니다.

회고 질문	목적	후속 조치 예시
어떻게 발견했나요?	알림 품질을 확인합니다.	핵심 오류율 알림 추가
무엇을 찾는 데 오래 걸렸나요?	문서와 대시보드 부족을 찾습니다.	로그 검색 예시 추가
어떤 결정이 어려웠나요?	판단 기준을 보완합니다.	롤백 기준 문서화
누가 계속 질문을 받았나요?	역할 분리를 개선합니다.	커뮤니케이션 담당자 지정
다시 발생하면 더 빨리 대응할 수 있나요?	재발 대응 능력을 확인합니다.	첫 5분 절차 업데이트

좋은 회고는 장애를 팀의 자산으로 바꿉니다. 나쁜 회고는 피곤한 회의로 끝납니다. 차이는 후속 조치에 있습니다. 문서가 업데이트되고, 알림이 개선되고, 절차가 짧아졌다면 그 장애는 적어도 팀을 조금 더 강하게 만들었습니다.

작은 팀을 위한 장애 대응 문서 시작법

작은 팀은 문서에 많은 시간을 쓰기 어렵습니다. 그래서 더 단순하게 시작해야 합니다. 처음부터 완벽한 운영 매뉴얼을 만들려고 하지 말고, 자주 장애가 나는 서비스 하나를 골라 한 페이지짜리 문서를 만드세요. 담당자, 대시보드, 로그 위치, 첫 확인 절차, 롤백 방법, 공유 문구만 있어도 큰 차이가 납니다.

처음 만든 문서는 부족할 수 있습니다. 괜찮습니다. 장애 대응 문서는 실제 장애와 연습을 통해 좋아집니다. 배포 후 작은 문제가 생겼을 때 문서를 열어 보고, 빠진 항목을 추가하세요. 문서는 책상 위 장식이 아니라 자주 손때가 묻어야 하는 도구입니다.

• 가장 중요한 서비스 하나를 선택합니다.
• 담당자와 대체 담당자를 적습니다.
• 첫 5분 확인 절차를 씁니다.
• 대시보드와 로그 검색 위치를 붙입니다.
• 롤백 또는 임시 차단 방법을 적습니다.
• 상황 공유 문구를 하나 준비합니다.
• 장애 후 회고 항목을 아래에 붙입니다.

이 정도면 시작할 수 있습니다. 완벽하지 않아도 없는 것보다 훨씬 낫습니다. 장애 중에는 완벽한 문서보다 찾을 수 있는 문서가 더 중요합니다. 어딘가에 대단한 문서가 있는데 아무도 위치를 모르면, 그것은 거의 전설 속 문서입니다.

자주 묻는 질문

장애 대응 문서는 누가 작성해야 하나요?

서비스를 가장 잘 아는 개발자와 실제로 장애를 대응하는 운영 담당자가 함께 작성하는 것이 좋습니다. 개발자는 시스템 구조를 알고, 운영 담당자는 장애 중 필요한 정보를 압니다. 둘 중 한쪽만 작성하면 실제 대응 흐름이 빠질 수 있습니다.

문서가 오래되면 오히려 위험하지 않나요?

맞습니다. 오래된 문서는 잘못된 자신감을 줄 수 있습니다. 그래서 배포 구조, 담당자, 대시보드, 롤백 절차가 바뀔 때마다 문서를 업데이트해야 합니다. 정기적으로 문서 검토 시간을 갖는 것도 좋습니다.

작은 서비스에도 장애 대응 문서가 필요할까요?

작은 서비스일수록 간단한 문서가 더 효과적일 수 있습니다. 담당자가 적고 시간이 부족하기 때문에, 장애 중에 기억에 의존하면 더 쉽게 흔들립니다. 한 페이지짜리 문서라도 있으면 대응 속도가 달라집니다.

장애 대응 훈련도 해야 하나요?

가능하다면 하는 것이 좋습니다. 실제 장애가 아니어도 가상의 상황을 두고 문서를 따라가 보면 빠진 부분이 보입니다. 문서는 읽는 것보다 사용해 볼 때 품질이 드러납니다.

마무리

장애 대응 문서가 없는 팀은 대개 장애가 날 때마다 비슷한 혼란을 반복합니다. 담당자를 찾고, 로그 위치를 묻고, 최근 배포를 의심하고, 고객 안내를 고민하고, 복구 기준을 감으로 판단합니다. 그러다 보면 어느 순간 모두가 마음속으로 기도부터 하게 됩니다. 인간적으로는 이해되지만, 운영 방식으로는 조금 아슬아슬합니다.

좋은 장애 대응 문서는 팀을 차분하게 만듭니다. 첫 5분에 무엇을 볼지, 누가 어떤 역할을 맡을지, 언제 롤백할지, 어떻게 공유할지, 언제 복구됐다고 판단할지 알려 줍니다. 문서는 사람의 판단을 없애는 것이 아니라, 판단을 더 잘할 수 있게 도와줍니다.

오늘 당장 모든 서비스를 문서화할 필요는 없습니다. 가장 중요한 서비스 하나부터 시작하세요. 한 페이지면 충분합니다. 담당자, 대시보드, 로그 위치, 첫 절차, 롤백 기준, 공유 문구만 적어도 다음 장애는 조금 덜 무섭습니다. 그리고 언젠가 알림이 울렸을 때, 팀이 기도보다 문서를 먼저 열게 된다면 이미 큰 발전입니다.