인수인계를 위한 복원 문서 구성법

1. 인수인계 없는 백업, 위험하다

백업은 한 사람의 역량에 의존해서는 안 된다.
하지만 실무에서는 종종 ‘백업 담당자’만 알고 있는 구조가 된다.
그가 퇴사하거나 부서 이동을 하면, 복구는 단절된다.

복원은 기술이 아니라 ‘과정’이다.
그리고 그 과정이 문서로 인수인계되지 않는다면,
백업은 결국 ‘복구할 수 없는 구조’가 된다.

 

2. 문서화되지 않은 백업의 위험 사례

• 복구 스크립트 위치를 아무도 모름
• NAS 접속 계정만 전 담당자가 알고 있었음
• 특정 경로가 마운트되지 않으면 백업 실행이 안 되는 구조
• ‘장비를 잘 아는 사람’이 없으면 절차 진행 불가

이런 상황에서 장애가 발생하면 백업은 의미를 잃는다.
정보가 공유되지 않는 백업은, 결국 실패한 백업이다.

 

3. 인수인계 문서에 포함해야 할 핵심 요소

항목	설명
시스템/서비스 목록	복원 대상 시스템 이름, 목적
백업 위치	NAS, 클라우드 경로, 접근 계정
복원 절차	명령어, 순서, 주의사항 정리
의존 정보	DB, 외부 API, 설정파일 등
예상 소요 시간	RTO 기준 복구 시간 예상치
담당자 변경 로그	이전/현 담당자, 최근 테스트 일시

이 정보를 표와 체크리스트로 정리하면
누가 보더라도 바로 실행 가능한 문서가 된다.

 

4. 실무 인수인계 예시 문장

[서비스명] ERP-Web  
복원 경로: /mnt/backup/erp-web/2024  
복구 절차: Docker 컨테이너 정지 → DB 덤프 복원 → conf.json 적용  
RTO 목표: 1시간 이내  
필요 자격: SSH 접근 가능 계정, DB 루트 권한

이처럼 짧고 명확하게 쓰인 인수인계 문서는
예상치 못한 상황에서 조직을 구할 수 있다.

 

5. 보안과 책임 분산도 함께 고려해야 한다

백업 문서는 보안 대상이기도 하다.
그래서 접근 권한, 열람 이력 관리, PDF 암호화 등의 방식도 필요하다.
또한, 한 사람만 복원 책임을 지는 구조는 반드시 피해야 한다.

• 최소 2인 이상 공동 점검 체계
• 연 1회 이상 문서 검토 및 업데이트
• 인수인계 시 서명 기록 또는 관리자 승인 포함
  
  

결론

복원 전략이 ‘한 사람의 기억’에 머문다면
그 백업은 실패를 향해 가고 있는 중이다.

백업은 기술이 아니라 체계이고,
체계는 문서로 전파되어야 비로소 조직의 자산이 된다.

오늘 당신의 복원 절차는,
다른 사람도 실행할 수 있도록 정리되어 있는가?