왜 백업, 복구 테스트, DR이 늦게까지 무시되는가

이 글에서 말하는 백업, 테스트, 그리고 DR의 차이

팀들은 종종 “백업이 있다”고 말하지만, 실제로는 서로 다른 세 가지 관행을 섞어 말합니다. 이 글은 의도적으로 이를 분리합니다. 각각이 다른 방식으로 실패하기 때문입니다.

백업(사본)

백업은 데이터(때로는 전체 시스템)의 여분 사본을 다른 곳에 보관하는 것입니다—클라우드 스토리지, 다른 서버, 또는 오프라인 장치 등. 백업 전략은 기본 질문에 답합니다: 무엇을 백업하나, 얼마나 자주하나, 어디에 저장하나, 얼마나 오래 보관하나.

복구 테스트(증거)

복구 테스트는 일정에 따라 실제로 백업에서 데이터를 복구하거나 시스템을 복구하는 습관입니다. 이는 “우리가 복구할 수 있을 것 같다”와 “우리는 지난주에 복구했고 작동했다”를 구분합니다. 테스트는 또한 RTO 및 RPO 목표를 충족할 수 있음을 확인합니다:

• RTO (복구 시간 목표, Recovery Time Objective): 얼마나 빨리 시스템을 다시 가동해야 하는지
• RPO (복구 시점 목표, Recovery Point Objective): 얼마나 최근 데이터까지 잃어도 되는지

재해 복구(DR)(업무 재개 계획)

재해 복구 계획은 중대한 사고 후 비즈니스를 다시 가동하기 위한 조정된 플레이북입니다. 역할, 우선순위, 의존관계, 접근 권한, 커뮤니케이션을 다룹니다—단순히 백업 위치만 적는 것이 아닙니다.

“너무 늦다”는 어떤 상황인가

“너무 늦다”는 최초의 실전 시험이 장애, 랜섬노트, 혹은 실수로 파일을 삭제했을 때 이루어지는 상황입니다—스트레스가 높고 시간이 아주 비싼 상황이죠.

이 글의 초점은 작은 규모 또는 중간 규모 팀이 유지할 수 있는 실용적인 단계입니다. 목표는 단순합니다: 놀람을 줄이고, 더 빠르게 복구하며, 문제가 생겼을 때 책임을 분명히 하는 것.

흔한 패턴: “백업은 있다”지만 복구는 안 되는 경우

대부분 회사는 백업을 전혀 안 하는 것이 아닙니다. 백업 도구를 도입하고 대시보드에서 “성공”으로 표시되는 작업을 보고 보호되고 있다고 가정합니다. 놀람은 나중에 옵니다: 첫 번째 실제 복구가 장애, 랜섬웨어, 또는 "지난달 파일이 필요하다"는 긴급 요청 때 발생하고, 그때 간극이 드러납니다.

겉보기엔 괜찮은 백업—사용하려 할 때 문제가 생긴다

백업 작업이 완료되어도 복구 불가 상태일 수 있습니다. 흔한 원인은 단순하지만 치명적입니다: 애플리케이션 데이터 누락, 손상된 아카이브, 암호화 키가 잘못된 곳에 저장됨, 또는 필요한 버전을 삭제한 보존 규칙 등.

데이터가 있어도 복구 절차를 연습한 사람이 없거나 자격증명이 바뀌었거나 복구에 예상보다 훨씬 오래 걸려서 실패할 수 있습니다. “백업이 있다”는 말이 조용히 “어딘가에 백업 파일이 있다”로 변합니다.

문서로만 존재하는 DR 계획

많은 팀이 감사나 보험 문서 때문에 재해 복구 계획을 갖고 있습니다. 그러나 압박이 있을 때 문서는 계획이 아닙니다—실행이 계획입니다. 런북이 몇 사람의 기억, 특정 노트북, 또는 다운된 시스템 접근에 의존한다면 상황이 복잡해지면 버티지 못합니다.

알려지지 않은(혹은 상상 속의) RTO/RPO와 불명확한 소유권

세 명의 이해관계자에게 복구 목표를 물어보면 보통 세 가지 다른 답을 듣거나 아무 답도 못 듣는 경우가 많습니다. RTO와 RPO가 정의되어 합의되지 않으면 기본값은 “가능한 빨리(ASAP)”가 되고, 이것은 목표가 아닙니다.

소유권도 조용한 실패 포인트입니다. 복구가 IT, 보안, 또는 운영 중 누가 주도하나요? 그게 명확하지 않으면 사건의 첫 시간은 복구 노력 대신 책임 떠넘기 논쟁으로 낭비됩니다.

사람들이 가시성이 낮은 위험을 무시하는 이유

백업, 복구 테스트, DR은 전형적인 “조용한 위험”입니다: 작동하면 아무 일도 일어나지 않습니다. 사용자에게 보이는 개선도 없고 즉각적인 수익 영향도 없습니다. 그래서 미루기 쉽습니다—신뢰성에 진심인 조직에서도 마찬가지입니다.

“나중에 처리하자”는 심리

몇 가지 예측 가능한 인지적 편향이 팀을 방치로 밀어넣습니다:

• 낙관 편향: 장애와 데이터 손실은 남의 일처럼 느껴집니다. 우리 팀은 똑똑하고 클라우드 제공자는 신뢰할 수 있으며 “우리는 큰 사고가 없었다”.
• 가용성 편향: 마지막 소방훈련이 오래 전이면 긴박감을 느끼기 어렵습니다. 최근 사건은 긴박감을 만들고, 긴 평온기는 안일함을 만듭니다.
• 현재 편향: 이번 스프린트 기능 출시는 즉각 보상받습니다. 내년의 가상 위기를 막는 일은 칭찬받기 어렵고, 시간이 부족할 때 잘려나가기 쉽습니다.
• 책임 분산: 백업은 ‘IT’, 테스트는 ‘엔지니어링’, DR은 ‘보안’처럼 들립니다. 소유권이 흐릿하면 모두가 다른 누군가가 맡고 있다고 생각합니다.

가시성이 낮은 업무가 우선순위에서 밀리는 이유

DR 준비는 문서화, 접근성 확인, 런북, 테스트 복원 같은 준비 작업이 대부분입니다. 성과가 명확한 작업(성능 개선이나 고객 요청)과 경쟁합니다. 백업 비용을 승인하는 리더도 테스트와 훈련을 ‘프로세스’로 무의식적으로 취급해 프로덕션 수준의 작업으로 보지 않는 경우가 많습니다.

결과적으로 위험은 가정 기반의 자신감으로 대체됩니다. 실패는 보통 실제 장애 때만 드러나므로 조직이 진실을 배우는 시점은 최악의 순간입니다.

준비 태세를 잠식하는 운영 마찰

대부분의 백업 및 DR 실패는 “신경 쓰지 않음” 때문이 아닙니다. 사소한 운영 디테일들이 쌓여 결국 아무도 자신 있게 “예, 복구할 수 있습니다”라고 말하지 못하게 됩니다. 작업은 미뤄지고, 표준화되고, 잊혀지며—정작 필요할 때까지 이어집니다.

무엇이 포함되는지가 애매하면 소유권이 사라진다

백업 범위는 명확함에서 암시에 따라 움직이기 쉽습니다. 노트북도 포함인가요, 아니면 서버만 포함인가요? SaaS 데이터, 데이터베이스, 공유 드라이브, 모두가 여전히 쓰는 파일 공유는요? 답이 “상황에 따라 다르다”라면 중요한 데이터가 보호되지 않았음을 너무 늦게 알게 됩니다.

간단한 규칙: 내일 비즈니스가 그 항목을 못 쓰면, 명시적 백업 결정(보호됨/부분적 보호/의도적 제외)을 내려야 합니다.

도구 난립이 실패를 숨긴다

많은 조직이 VM용 백업, 엔드포인트용, SaaS용, 데이터베이스용 등 여러 백업 시스템을 갖게 됩니다. 각 시스템은 자체 대시보드, 알림, “성공”의 정의를 가집니다. 결과는 복구 가능성에 대한 단일 뷰가 없다는 것.

더 나쁜 점은 “백업 성공”이 지표가 되고 “복구 검증”이 지표가 아니게 된다는 것입니다. 알림이 시끄러우면 사람들은 무시하는 법을 배우고, 작은 실패들이 조용히 쌓입니다.

복구가 실패하는 지루한 이유들: 접근과 비밀

복구에는 더 이상 작동하지 않는 계정, 변경된 권한, 사건 중에 테스트하지 않은 MFA 워크플로우가 필요할 수 있습니다. 여기에 누락된 암호화 키, 오래된 비밀번호, 오래된 위키에 있는 런북이 더해지면 복구는 보물찾기가 됩니다.

해결책은 영웅적 조치가 아니라 운영적인 것

범위를 문서화하고, 리포팅을 통합하며, 자격증명/키와 런북을 최신 상태로 유지하세요. 복구가 일상적일 때 준비태세가 향상됩니다—특별한 이벤트가 아닙니다.

왜 복구 테스트가 건너뛰어지는가

대부분의 팀이 복구 테스트를 건너뛰는 이유는 관심이 없어서가 아닙니다. 대시보드에 보이지 않는 불편함 때문에 그렇습니다—그 불편함은 필요할 때까지 드러나지 않습니다.

시간이 많이 들고, ‘안전한’ 방법도 위험해 보일 수 있다

실제 복구 테스트는 계획이 필요합니다: 적절한 데이터셋 선택, 컴퓨트 예약, 앱 소유자 조정, 결과가 단순한 파일 복사가 아니라 사용 가능함을 증명해야 합니다.

부실하게 테스트하면 프로덕션 중단(추가 부하, 파일 잠금, 예기치 못한 설정 변경)이 발생할 수 있습니다. 격리된 환경에서 테스트하는 것이 가장 안전하지만, 이를 설정·유지하는 데 시간이 듭니다. 그래서 기능 작업, 업그레이드, 일상 소방 작업 뒤로 밀립니다.

실패한 복구는 아무도 발견하고 싶지 않은 긴급한 일을 만든다

복구 테스트는 불편한 진단을 제공할 수 있습니다.

실패한 복구는 즉각적인 후속 작업을 의미합니다—권한 수정, 누락된 암호화 키, 깨진 백업 체인, 문서화되지 않은 의존성, “데이터는 백업했지만 그 데이터를 유의미하게 만드는 시스템은 백업하지 않았다” 같은 문제들. 많은 팀이 이미 용량이 꽉 차 있어 새로운 고우선 작업을 열고 싶어하지 않습니다.

KPI 문제: 백업은 측정하지만 복구는 측정하지 않는다

조직은 종종 측정하고 보고하기 쉬운 “백업 작업 성공”을 추적합니다. 그러나 “복구가 작동했다”는 것은 사람에게 보이는 결과가 필요합니다: 애플리케이션이 시작되는가, 사용자가 로그인할 수 있는가, 데이터가 합의된 RTO와 RPO에 충분히 최신인가?

리더가 녹색 백업 리포트를 보게 되면 복구 테스트는 선택처럼 보입니다—사건이 닥치기 전까지는.

습관이 아니라 프로젝트로 다뤄진다

한 번의 복구 테스트는 빠르게 오래된 것이 됩니다. 시스템이 바뀌고, 팀이 바뀌고, 자격증명이 회전하고, 새로운 의존성이 생깁니다.

복구 테스트가 패치나 청구처럼 정기적으로 스케줄되지 않으면 큰 이벤트가 됩니다. 큰 이벤트는 미루기 쉽고, 그래서 첫 번째 “실제” 복구 테스트가 종종 장애 중에 이루어집니다.

예산과 인센티브: 잘못 해석되는 숫자들

백업 전략과 재해 복구 계획 작업은 보통 순수한 ‘비용 센터’처럼 예산 싸움에서 밀립니다. 문제는 리더가 관심이 없는 것이 아니라—제시되는 숫자가 실제 복구에 필요한 것을 반영하지 않는다는 점입니다.

눈에 보이는 비용(그리고 잘려나가는 이유)

직접 비용은 청구서와 근무시간표에 보입니다: 스토리지, 백업 도구, 보조 환경, 복구 테스트와 백업 검증을 위한 인건비. 예산이 타이트해지면 이런 항목은 선택 사항처럼 보입니다—특히 “최근에 사건이 없었다면.”

나중에 도래하는 비싼 비용들

간접 비용은 실재하지만 시차가 있고 무너지기 전까지는 귀속하기 어렵습니다. 실패한 복구나 느린 랜섬웨어 복구는 다운타임, 주문 손실, 고객 지원 폭증, SLA 벌금, 규제 리스크, 사건 이후 오랫동안 남는 평판 피해로 이어질 수 있습니다.

흔한 예산 실수는 복구를 이분법적으로 보는 것입니다(“복구할 수 있다” vs “할 수 없다”). 실제론 RTO와 RPO가 비즈니스 영향을 정의합니다. 비즈니스가 8시간 내 복구가 필요한데 복구가 48시간 걸리면 그 시스템은 "커버된다"가 아니라 계획된 다운타임입니다.

조직 내 잘못 정렬된 인센티브

보상 체계가 준비태세를 낮게 유지합니다. 팀은 가동시간과 기능 제공으로 보상받지, 복구 가능성으로 보상받지 않습니다. 복구 테스트는 계획된 중단을 만들고, 불편한 간극을 드러내며, 일시적으로 용량을 줄일 수 있어 단기 우선순위에 밀립니다.

실용적 해결책은 복구 가능성을 측정 가능하고 소유 가능한 목표로 만드는 것입니다: 중요한 시스템에 대해 백업 작업 “성공”이 아니라 성공적인 복구 테스트 결과에 적어도 하나의 목표를 연결하세요.

조달과 승인 지연이 DR을 늦춘다

조달 지연도 또 다른 조용한 방해요인입니다. DR 개선은 보통 보안, IT, 재무, 앱 소유자 간 합의와 때로는 새로운 벤더나 계약을 필요로 합니다. 그 주기가 몇 달 걸리면 팀은 개선안을 제안하지 않고 위험한 기본값을 수용하게 됩니다.

요점: DR 지출을 단순한 “스토리지 추가”로 제시하지 말고, 특정 RTO/RPO 목표와 이를 만족시키기 위한 검증된 경로를 제시하세요.

현대의 위협들이 방치 비용을 키운다

백업과 복구를 무시한 비용은 예전엔 "불운한 장애"로 나타났다면, 지금은 의도적인 공격이나 장기간 영향을 주는 의존성 실패로 나타납니다. 이는 수익, 평판, 규정 준수에 해를 끼칩니다.

랜섬웨어는 단순히 프로덕션을 암호화하지 않는다

현대 랜섬웨어 그룹은 복구 경로 자체를 찾습니다. 백업을 삭제, 손상, 혹은 암호화하려 시도하고 종종 백업 콘솔을 먼저 노립니다. 백업이 항상 온라인에 있고 항상 쓰기 가능하며 동일한 관리자 계정으로 보호되어 있으면 백업도 피해 범위에 들어갑니다.

격리가 중요합니다: 자격증명 분리, 불변 스토리지, 오프라인/에어갭 복사본, 동일하게 타격받은 시스템에 의존하지 않는 명확한 복구 절차.

“제공자가 백업을 한다”는 것은 복구 계획이 아니다

클라우드/서비스 제공자는 플랫폼을 보호할 수 있지만 그것은 당신의 비즈니스를 복구하는 것과 다릅니다. 다음을 답해야 합니다:

• 삭제되거나 손상된 데이터를 적절한 세분성으로 빠르게 복구할 수 있는가?
• 계정이 잠기거나 벤더 장애 시 중요한 데이터를 내보낼 수 있는가?
• 누가 복구를 시작할 수 있고 얼마나 걸리는가?

제공자가 커버한다고 가정하면 사건이 발생했을 때 간극을 발견하게 됩니다—시간이 가장 비쌀 때요.

원격 근무는 중요한 데이터를 엣지로 밀어낸다

노트북, 가정 네트워크, BYOD로 중요한 데이터가 데이터센터 밖에, 기존 백업 작업 범위 밖에 존재하는 경우가 많습니다. 도난당한 장치, 동기화된 폴더가 삭제를 전파하는 경우, 또는 손상된 엔드포인트는 서버와 상호작용하지 않고도 데이터 손실 사건이 될 수 있습니다.

제3자 장애는 해킹 없이도 서비스를 마비시킬 수 있다

결제 처리사, ID 공급자, DNS, 핵심 통합이 다운되면 당신도 함께 다운될 수 있습니다. 복구 계획이 “우리 시스템만 문제”라고 가정하면 파트너 장애 시 실질적 해결책이 없을 수 있습니다.

이 위협들은 단순히 사고 가능성을 높이는 것이 아니라 복구가 느려지거나 부분적이거나 불가능해질 가능성을 높입니다.

간단한 복구 맵부터 시작하세요(시스템, 소유자, RTO/RPO)

대부분의 백업/DR 노력이 도구(“백업 소프트웨어를 샀다”)로 시작해서 결정(“무엇을 먼저 복구해야 하고 누가 결정을 내리나?”)으로 멈춥니다. 복구 맵은 그 결정을 가시화하는 가벼운 방법입니다.

인벤토리 항목(실용적으로 유지)

공유 문서나 스프레드시트를 만들어 다음을 나열하세요:

• 시스템: SaaS 앱, 서버, 데이터베이스, 파일 공유, 엔드포인트, 아이덴티티(SSO), 이메일, CI/CD 등
• 데이터 유형: 고객 데이터, 재무, 소스 코드, 계약서, 지원 티켓, 직원 기록
• 소유자: 복구 결정을 책임지는 명시된 개인 이름(팀명만 쓰지 않음)
• 의존성: “시스템 A는 시스템 B가 필요” (예: 애플리케이션은 DB + 아이덴티티 공급자 + DNS 필요)

추가 열: 어떻게 복구하는가(벤더 복구, VM 이미지, DB 덤프, 파일 레벨 복원). 한 문장으로 설명할 수 없으면 빨간불입니다.

평이한 언어로 RTO와 RPO

• RTO (복구 시간 목표) = 얼마나 빨리 복구해야 하는가. 결제 시스템을 4시간 내에 올려야 하면 RTO는 4시간.
• RPO (복구 시점 목표) = 얼마나 최근의 데이터를 잃어도 되는가. 주문의 마지막 30분을 잃어도 된다면 RPO는 30분.

이는 기술적 목표가 아니라 비즈니스 허용치입니다. 주문, 티켓, 급여 같은 실제 예로 합의하세요.

서비스 분류

시스템을 그룹화하세요:

• 치명적(Critical): 수익, 안전, 법적 의무(예: 결제, 아이덴티티, 핵심 DB)
• 중요(Important): 고통스럽지만 버텨질 수 있음(예: 분석, 내부 위키)
• 있으면 좋은 것(Nice-to-have): 수일 기다릴 수 있음(예: 실험, 오래된 아카이브)

“Day 1” 최소 운영 정의

장애 당일에 운영을 유지하기 위해 필요한 최소 서비스와 데이터를 적은 짧은 체크리스트를 작성하세요. 이것이 기본 복구 순서이자 테스트와 예산의 기준이 됩니다.

내부 도구를 빠르게 개발한다면(예: Koder.ai 같은 빠른 개발 플랫폼으로), 생성된 서비스도 동일한 맵에 추가하세요: 앱, DB, 시크릿, 커스텀 도메인/DNS, 정확한 복구 경로. 빠른 개발도 명시적 복구 소유권이 필요합니다.

실제로 유지할 수 있는 복구 테스트 루틴

복구 테스트는 정상 운영에 맞아야만 작동합니다. 목표는 연례 큰 행사보다 작고 예측 가능한 루틴을 만들어 신뢰를 쌓는 것입니다(그리고 문제를 저렴할 때 드러나게 함).

지키기 쉬운 주기 설정

두 계층으로 시작하세요:

• 월간 스팟 복구(30–60분): 무작위 항목을 골라 안전한 위치로 복구
• 분기별 전체 드릴(반나절~하루): 보다 현실적인 장애를 시뮬레이션하고 엔드투엔드 복구 절차를 검증

둘 다 재무 마감이나 패치처럼 캘린더에 고정하세요. 선택사항이면 밀립니다.

현실적 복구 시나리오 순환

매번 동일한 ‘정상 경로’만 테스트하지 마세요. 실제 사건을 반영한 시나리오를 순환하세요:

• 단일 파일 복구(실수로 삭제된 파일, 버전 롤백)
• 전체 서버/VM 복구(업데이트 실패, 하드웨어 고장)
• DB 시점복구(point-in-time)(잘못된 배포, 데이터 손상)

SaaS 데이터(예: Microsoft 365, Google Workspace)가 있으면 메일박스/파일 복구 시나리오도 포함하세요.

실험 로그처럼 결과 기록하기

각 테스트에 대해 기록하세요:

• 시도한 내용과 어떤 백업 세트를 사용했는지
• 무엇이 작동했고 무엇이 실패했는지, 그리고 왜(권한, 키 누락, 느린 스토리지, 잘못된 보존 등)
• 복구 시간(시작부터 사용 가능까지)과 수동 단계

시간이 지나면 이것이 가장 정직한 “DR 문서”가 됩니다.

실패를 자동으로 가시화하기

문제가 조용할 때 루틴은 죽습니다. 백업 도구를 구성해 실패한 작업, 누락된 스케줄, 검증 오류에 대해 알림을 보내고, 이해관계자에게 월간 요약(성공/실패 비율, 복구 시간, 미해결 수정사항)을 전송하세요. 가시성은 행동을 만들고 준비태세가 사건 사이에 희미해지지 않게 합니다.

최악의 놀람을 막는 백업 설계 기초

백업은 보통 평범한 이유로 실패합니다: 프로덕션과 동일한 계정으로 접근 가능, 원하는 시간 범위를 커버 못함, 사고 시 아무도 복호화할 수 없음. 좋은 설계란 화려한 도구가 아니라 실용적 가드레일 몇 가지입니다.

3-2-1 원칙으로 시작하되 상황에 맞게 조정

간단한 기본은 3-2-1 아이디어입니다:

• 데이터의 3개 복사본(프로덕션 + 백업 2개)
• 서로 다른 2종류의 스토리지에 보관(예: 클라우드 오브젝트 스토리지와 로컬 어플라이언스)
• 그중 1개는 오프사이트에 보관(한 사건으로 모두 사라지지 않도록)

이렇게 하면 “한 곳에 하나의 백업” 같은 위험에서 벗어날 수 있습니다.

백업을 프로덕션 자격증명과 분리하세요

백업 시스템이 서버, 이메일, 클라우드 콘솔과 동일한 관리자 계정으로 접근 가능하면 단일 탈취된 자격증명으로 프로덕션과 백업이 둘 다 파괴될 수 있습니다.

분리를 목표로:

• 전용 백업 계정(필요 최소 권한)
• 서로 다른 관리자 역할(다른 사람 또는 적어도 다른 자격증명)
• 가능하면 불변성(immutable) 또는 쓰기-한번 보호

보존 정책 설계: 빠른 복구 vs 장기 아카이브

보존 정책은 “얼마나 과거로 갈 수 있나?”와 “얼마나 빨리 복구할 수 있나?” 두 질문을 답합니다.

두 계층으로 생각하세요:

• 단기 보존(일/주): 빠른 복구에 최적화된 빈번한 백업(가장 흔한 필요)
• 장기 보존(월/년): 감사, 법적 보존, 늦게 발견된 문제 용으로 저비용 아카이브

키 관리 계획(암호화된 백업이 사용 가능하게 유지되도록)

암호화는 유용하지만, 사고 시 키가 없으면 무용지물입니다.

사전에 결정하세요:

• 암호화 키와 시크릿이 어디에 저장되는가(KMS, HSM, 비밀번호 금고)
• 사고 시 누가 접근 가능한가(브레이크-글래스 절차)
• 키를 교체할 때 오래된 백업이 읽을 수 없게 되지 않도록 백업하는 방법

복구 시 접근·복호화·발견 불가능한 백업은 백업이 아니라 단지 스토리지일 뿐입니다.

DR을 문서에서 실행 가능한 플레이북으로 바꾸기

PDF로만 존재하는 DR 계획은 없는 것보다 낫지만—사건 시 사람들은 그 문서를 읽지 않습니다. 이 때문에 DR을 참조 문서가 아니라 팀이 실제 실행할 수 있는 순서로 바꿔야 합니다.

첫 한 시간을 수월하게 만들기

압박 아래 사람들이 묻는 질문에 답하는 한 페이지짜리 런북으로 시작하세요:

• 누가 무엇을 언제 하는가(사건 리드, IT 리드, 보안, 앱 소유자, 커뮤니케이션)
• 어떤 시스템을 먼저 다루는가(아이덴티티, 핵심 DB, 결제, 고객-facing 앱)
• 각 단계의 완료 정의(서비스 접근 가능, 데이터 검증, 모니터링 정상)

상세 절차는 부록에 두세요. 현장에선 한 페이지가 실사용됩니다.

커뮤니케이션 규칙을 미리 정하세요

업데이트가 임의적이면 혼란이 커집니다. 미리 정하세요:

• 내부 업데이트 주기(예: 30분마다)와 단일 진실의 원천(한 채널, 한 문서)
• 고객 공지 트리거(어떤 조건에서 상태 페이지 업데이트가 필요한지)
• 벤더 연락 경로(백업 제공자, 클라우드 지원, MSP)와 계정 ID 및 에스컬레이션 루트

상태 페이지가 있다면 런북에 링크하세요(예: /status).

어려운 결정을 미리 정하세요

의사결정 포인트와 소유자를 적어두세요:

• 페일오버할지 현장 복원할지
• 복원할지 깨끗하게 재구축할지
• “악성코드 격리됨”을 선언하기 위해 필요한 증거

장애 시에도 접근 가능한 위치에 보관하세요

플레이북을 시스템이 다운되었을 때도 사라지지 않는 곳에 두세요: 오프라인 사본과 브레이크-글래스 접근 가능한 안전한 공유 위치.

지속시키기: 지표, 소유권, 검토 주기

백업과 DR이 문서에만 있으면 흐트러집니다. 복구를 다른 운영 기능처럼 다루세요: 측정하고, 소유하고, 예측 가능한 주기로 검토하세요.

행동을 바꾸는 소수 지표

차트로 가득한 대시보드가 필요 없습니다. “우리는 복구할 수 있는가?”에 답하는 소수 지표를 추적하세요:

• 복구 성공률(시스템 등급별): 테스트 복구가 수동 개입 없이 완료되는 빈도
• 복구 시간: “복구 시작”부터 “서비스 사용 가능”까지 걸린 시간(사용자가 체감하는 값)
• 커버리지: 지난 90일 내 테스트된 중요한 시스템 목록

이들을 RTO/RPO와 결부해 허상 숫자가 되지 않게 하세요. 복구 시간이 꾸준히 RTO를 넘으면 이는 단순한 '나중에' 문제가 아닙니다.

소유권: 한 사람의 이름이 중요하다

모두가 관여되지만 아무도 책임지지 않으면 준비태세가 죽습니다. 지정하세요:

• 복구 프로그램의 명시된 책임자(개인 또는 팀)
• 각 주요 시스템(앱+데이터)에 대한 백업 전략 소유자
• 반복되는 캘린더 약속(예: 월간 복구 테스트 창, 분기별 검토)

소유권에는 테스트를 스케줄하고 간극을 에스컬레이트할 권한이 포함되어야 합니다. 그렇지 않으면 작업은 무기한 연기됩니다.

연례 가정 검토(조용한 놀람의 근원)

연 1회 “가정 검토” 회의를 열어 다음을 바탕으로 DR 계획을 업데이트하세요:

• 작년 이후 추가된 앱이나 DB
• 벤더 변화(SaaS 마이그레이션, 새로운 MSP, 새로운 클라우드 계정)
• 새로운 위협과 제약(특히 랜섬웨어 복구 시나리오)
• 실제 사건에서 느리거나 실패했던 항목

이때 복구 맵이 현재 소유자와 의존성을 반영하는지 확인하세요.

가벼운 체크리스트(그리고 참고 링크 몇 개)

내부 런북 최상단에 간단한 체크리스트를 두어 사람들이 압박 속에서도 행동할 수 있게 하세요. 접근 방식 구축이나 개선 중이라면 /pricing 또는 /blog 같은 리소스를 참조해 옵션, 루틴, 그리고 당신이 의존하는 도구들에 대해 “프로덕션 준비된” 복구가 어떤 모습인지 비교할 수 있습니다. 또한 스냅샷/롤백 및 소스 내보내기를 지원하는 플랫폼(예: Koder.ai)을 고려하세요.