장애 대응 매뉴얼은 ‘서버가 멈추면 담당자에게 전화한다’는 연락망만으로 충분하다는 오해가 많다. 아니다. 사내 시스템 장애 대응 매뉴얼 작성법의 핵심은 장애를 발견한 사람이 누구든 같은 기준으로 영향도를 판단하고, IT팀 대응 순서에 맞춰 조치하며, 복구 뒤에도 확인과 기록을 끝내게 만드는 데 있으며 연락처는 그중 일부다.
좋은 매뉴얼은 사고 보고서가 아니다. 새벽 당직자나 입사 초기 구성원이 봐도 10분 안에 첫 행동을 고를 수 있는 작업 지침이어야 한다. 원인 분석보다 초기 통제 절차를 앞에 두는 이유도 장애 상황에서는 시간을 놓치지 않는 일이 중요하기 때문이다.
매뉴얼 작성 전 운영 기준부터 정한다
문서를 쓰기 전 장애의 범위와 서비스 우선순위를 정해야 한다. 전사 메신저가 멈춘 상황과 결제나 고객 데이터 처리가 멈춘 상황은 같은 방식으로 다루기 어렵다. 업무 부서와 합의하지 않은 우선순위는 비상시에 쉽게 무너지므로, 먼저 판단 기준을 맞춰 둔다.
서비스 목록에는 서비스명만 적지 말고 업무 영향, 운영 시간, 담당 팀, 기술 담당자, 대체 업무 방식, 복구 목표를 함께 적는다. 복구 목표는 무리한 숫자보다 현재 백업 주기와 인력으로 지킬 수 있는 수준으로 잡아야 현실적인 대응 기준이 된다.
| 등급 | 판단 기준 예시 | 초기 대응 | 보고 기준 |
|---|---|---|---|
| 긴급 | 핵심 업무 중단, 다수 사용자 영향, 데이터 손상 의심 | 즉시 비상 채널 개설과 책임자 호출 | 경영·업무 책임자에게 즉시 알림 |
| 높음 | 주요 기능 장애, 우회 업무가 제한됨 | 담당자 배정과 원인 범위 확인 | 정해 둔 시간 안에 현황 공유 |
| 보통 | 일부 사용자 또는 부가 기능 영향 | 티켓 등록 후 우선순위 배정 | 정기 현황에 반영 |
표의 등급과 대응 시간은 예시이므로 조직의 근무 형태, 서비스 중요도, 인력과 운영 환경에 따라 조정해야 한다.
등급은 세 단계면 시작하기 좋다. 긴급과 높음의 경계는 사용자 수만으로 나누지 말고 매출 업무, 고객 약속, 개인정보나 중요 데이터 노출 의심 여부, 우회 가능성을 같이 본다. 단, 보안 사고 의심 정황이 있으면 평소 장애 절차와 별도로 조직의 보안 사고 보고 체계를 즉시 따른다.
사내 시스템 장애 대응 매뉴얼 작성법의 뼈대
문서 첫 화면에는 ‘장애 발생 시 15분 행동’을 둔다. 긴 설명을 뒤로 보내고, 알림을 확인한 사람이 무엇을 멈추고 누구에게 알리고 어디에 기록할지 한 화면에서 보게 해야 한다. 특히 급한 순간일수록 이 순서가 바로 보이도록 구성한다.
- 감지와 접수 모니터링 도구의 알림, 사용자 문의, 협력사 통보를 받은 시각과 최초 제보 내용을 기록한다. 추측으로 제목을 정하지 말고 ‘로그인 오류 증가’, ‘사내망 접속 불가’처럼 관측된 현상으로 쓴다.
- 영향 확인 영향 서비스, 사용자 범위, 시작 추정 시각, 진행 중인 배포나 설정 변경을 확인한다. 재현이 어렵더라도 오류 화면, 알림 메시지, 모니터링 대시보드 수치를 보존한다.
- 등급 선언과 역할 배정 한 명은 지휘와 의사결정을 맡고, 한 명은 기술 조치, 한 명은 공지와 기록을 맡는다. 인원이 적다면 역할을 겸하되 지휘 역할을 비워 두지 않는다.
- 피해 확산 차단 문제가 의심되는 배포를 중지하고 변경 작업을 동결하며, 필요하면 기능을 제한하거나 정상 버전으로 되돌린다. 데이터 삭제나 대량 재처리는 승인권자와 백업 상태를 확인한 뒤 진행한다.
- 복구 검증과 종료 모니터링이 정상으로 돌아온 사실만으로 끝내지 않는다. 대표 사용자 흐름을 직접 시험하고 오류율, 지연 시간, 대기 작업량을 확인한 뒤 종료를 선언한다.
IT팀 대응 순서는 ‘원인을 찾고 고친다’가 아니다. 먼저 영향을 줄이고 증거를 남긴 뒤 복구를 검증하는 흐름이다. 원인 분석은 복구와 병행할 수 있지만, 분석에 몰입하다가 차단 시점을 놓치면 업무 피해가 커지므로 이 순서를 유지해야 한다.
역할과 연락 체계는 이름 대신 역할로 쓴다
특정 직원 이름만 적은 매뉴얼은 휴가나 퇴사 때 곧바로 쓸모가 떨어진다. 서비스 오너, 장애 지휘자, 인프라 담당, 애플리케이션 담당, 보안 연락 담당, 대외 공지 담당처럼 역할을 먼저 쓰고 현재 담당자와 대체 담당자를 별도 관리한다. 당직표도 함께 연결해 둔다.
연락 단계에는 호출 기준과 응답 기한을 적는다. 예를 들어 긴급 등급은 담당자 호출 후 10분 안에 응답이 없으면 대체 담당자와 책임자에게 올리는 식이다. 이 기준은 조직의 근무 형태와 서비스 중요도에 맞춰 조정하며, 응답이 없을 때 다음 호출 단계가 멈추지 않도록 한다.
공지 문안도 미리 준비한다. 초기 공지는 원인 단정 없이 발생 시각, 영향 범위, 현재 조치, 다음 안내 예정 시각만 담으면 된다. ‘완전 복구’라는 표현은 검증 전에는 쓰지 않는 편이 안전하므로 확인된 사실만 알린다.
기록 항목과 복구 검증을 빠뜨리지 않는다
장애 기록은 나중에 책임을 가리기 위한 문서만은 아니다. 다음 장애에서 탐색 시간을 줄이는 운영 데이터다. 타임라인에는 감지, 등급 선언, 호출, 변경 중지, 우회 적용, 복구 조치, 검증, 종료 시각을 시간순으로 남겨 대응 경과를 확인할 수 있게 한다.
기술 기록에는 변경 번호나 배포 버전, 관련 로그 위치, 실행 명령의 요약, 되돌린 설정, 미해결 위험을 넣는다. 비밀번호, 접근 토큰, 고객 식별 정보, 원본 개인정보를 티켓 시스템이나 단체 대화방에 복사하지 않도록 작성 기준도 명시하고, 민감 정보는 분리한다.
복구 검증 항목은 서비스마다 다르다. 로그인 서비스라면 로그인 성공, 권한 확인, 주요 화면 이동, 오류율 확인을 넣고 배치 작업이라면 누락·중복 여부와 적체 해소 여부를 확인한다. 모니터링 수치뿐 아니라 실제 업무 흐름으로 시험한다.
매뉴얼은 훈련으로 완성한다
문서가 있어도 호출이 안 되거나 권한이 없으면 현장에서는 멈춘다. 분기마다 한 번 정도 짧은 모의훈련을 하며 알림 수신, 비상 연락, 읽기 권한, 백업 복원 절차, 공지 채널을 확인하는 방식이 실용적이며, 훈련 주기는 조직 상황에 따라 조정할 수 있다.
훈련 뒤에는 실패한 절차를 문서에 반영한다. 담당자가 혼동한 용어, 오래된 연락처, 승인 대기, 접근 권한 부족처럼 작은 막힘도 다음 실제 장애에서는 큰 지연이 되므로 변경 이력과 다음 검토일을 문서 맨 아래에 남기고 계속 보완한다.
FAQ
장애 등급은 누가 최종으로 정하나
초기에는 당직자나 최초 대응자가 임시 등급을 선언하고, 정해 둔 책임자가 영향 정보를 확인해 조정하는 구조가 운영하기 편하다. 등급 조정 시각과 이유도 타임라인에 남겨 판단이 미뤄지지 않게 한다.
원인을 모르는 상태에서 공지해도 되나
공지할 수 있다. 원인 대신 확인된 증상과 영향 범위, 조치 중이라는 사실, 다음 안내 시각을 알린다. 확인하지 않은 원인이나 복구 예정 시각을 단정하면 후속 대응이 어려워지므로 짧고 정확하게 쓴다.
장애 중 시스템을 재시작해도 되나
재시작은 유효한 조치일 때가 있지만 로그나 메모리 상태가 사라지고 영향이 넓어질 여지도 있다. 매뉴얼에는 재시작 전 확인 항목, 승인 역할, 실행 뒤 검증 항목을 적어 두고 무조건 실행하지 않는다.
작은 오류도 장애 기록을 남겨야 하나
반복될 가능성이 있거나 사용자 업무에 영향을 줬다면 짧게라도 남기는 편이 좋다. 한 줄짜리 접수 기록이 누적되면 큰 장애의 전조를 발견하는 자료가 되므로 기록 부담은 줄인다.
이 글은 일반적인 정보 제공과 참고 목적으로 작성되었으며, 법률 자문·보안 컨설팅·컴플라이언스 판단을 대체하지 않습니다. 소개하는 설정과 절차는 소프트웨어 버전이나 조직 환경에 따라 다르게 동작할 수 있으며, 어떤 보안 조치도 완전한 안전을 보장하지는 않습니다. 실제 적용 전에는 반드시 소속 조직의 정책과 담당 부서(보안·IT·법무)의 확인을 거치고, 중요한 시스템에는 백업과 사전 테스트 후 적용하시기 바랍니다. 규제 해석과 합법·불법 여부는 사안과 시점마다 달라질 수 있으므로 공식 규정과 전문가 상담으로 확인이 필요합니다. 본 사이트는 내용의 정확성과 최신성을 보장하지 않으며, 이 글의 내용을 적용하여 발생하는 어떠한 결과에 대해서도 책임을 지지 않습니다.