금요일 저녁, 데이터센터 한 동에 정전과 함께 화재 진압용 살수가 터졌습니다. 주(主) 시스템이 통째로 내려갑니다. 두 회사의 운명이 갈립니다.
A사는 "매일 백업은 받고 있었다"고 합니다. 그런데 막상 복구하려니 — 최근 백업 파일이 손상돼 복원이 안 되고, 어느 서버부터 살려야 하는지 아무도 모르며, 예비 장비를 들여오는 데만 사흘이 걸립니다. 핵심 결제 서비스가 5일 멈췄고, 고객은 떠났습니다.
B사는 같은 재해를 맞았지만, 다른 지역의 DR 사이트로 트래픽을 넘깁니다. 결제·주문 같은 핵심 서비스가 우선순위대로 30분 안에 살아납니다. 분기마다 복구 훈련을 해 둔 덕에 누가 무엇을 어떤 순서로 하는지 손에 익어 있었습니다. 데이터는 마지막 복제 시점 기준 몇 분치만 잃었습니다.
둘의 차이는 "백업을 받았는가"가 아닙니다. 최악을 미리 가정하고, 무엇을 얼마나 빨리·어느 시점까지 복구할지 목표를 정하고, 그게 실제로 되는지 훈련으로 증명했는가입니다. 이 모듈은 그 설계 — 서비스 연속성과 재해복구(DR) — 를 다룹니다.
- 1IT 서비스 연속성 관리(ITSCM)와 사업연속성계획(BCP)의 관계를 설명할 수 있다
- 2RTO(복구목표시간)와 RPO(복구목표시점)를 정의하고 그 차이를 예로 들 수 있다
- 3RPO·RTO 목표가 백업 전략(주기·보관·오프사이트)과 DR 사이트 선택을 어떻게 좌우하는지 설명할 수 있다
- 4DR 사이트 콜드·웜·핫을 비용 대 복구 속도로 비교하고 상황에 맞게 고를 수 있다
- 5복구 우선순위(핵심 서비스 먼저)와 복구 훈련(리허설)이 왜 DR의 성패를 가르는지 설명할 수 있다
연속성·DR이 답하려는 질문
ITSCM과 BCP — '사업이 멈추지 않게'에서 'IT가 멈추지 않게'로
평상시 가용성 관리가 "작은 장애를 줄여 99.9%를 지키는" 일이라면, 서비스 연속성과 DR은 한 칸 더 나아가 "큰일이 나도 사업을 이어가는" 일을 다룹니다. 화재·정전·침수·랜섬웨어·지역 재해처럼 한 건으로 시스템 전체가 무너지는 상황을 미리 가정합니다.
여기서 두 개념의 층위를 구분해야 합니다.
- BCP(Business Continuity Plan, 사업연속성계획): 회사 전체가 재해에도 핵심 업무를 이어가기 위한 상위 계획. IT만이 아니라 인력·사무공간·통신·협력사·고객 응대까지 포함합니다. "콜센터 건물이 못 쓰게 되면 어디서 전화를 받을까"도 BCP의 영역입니다.
- ITSCM(IT Service Continuity Management, IT 서비스 연속성 관리): BCP가 정한 사업 목표를 IT 관점에서 떠받치는 하위 영역. "결제 서비스를 몇 시간 안에, 얼마만큼의 데이터 손실 한도로 되살릴 것인가"를 설계합니다.
- DR(Disaster Recovery, 재해복구): ITSCM 안에서 기술적 복구에 초점을 둔 실행 — 백업, DR 사이트, 복구 절차, 데이터 복제 등.
| 층위 | 범위 | 묻는 질문 | 예 |
|---|---|---|---|
| BCP | 사업 전체 | 재해에도 회사가 어떻게 굴러가는가 | 대체 사무실, 인력 비상연락망, 수기 업무 절차 |
| ITSCM | IT 서비스 | IT가 BCP 목표를 어떻게 떠받치는가 | 서비스별 RTO·RPO 목표, 우선순위 |
| DR | 기술 복구 | 시스템·데이터를 어떻게 되살리는가 | 백업·복제, DR 사이트, 복구 런북 |
핵심은 방향입니다. DR은 기술에서 출발하지 않고 사업이 요구하는 연속성(BCP)에서 거꾸로 내려옵니다. "이 서비스가 멈추면 사업에 얼마나 큰 타격인가"가 먼저고, 그 답이 복구 목표와 투자 규모를 정합니다.
그림: DR은 기술이 아니라 사업 가치에서 거꾸로 내려온다(BCP→ITSCM→DR), 그리고 복구는 순서 싸움 — 핵심 서비스부터 자원을 몰아준다.
RTO와 RPO — 복구의 두 시간 축
얼마나 빨리(RTO) vs 어느 시점까지(RPO)
DR 설계의 모든 숫자는 결국 두 개의 목표로 수렴합니다. 둘 다 '시간'을 말하지만 가리키는 방향이 다릅니다.
- RTO(Recovery Time Objective, 복구목표시간): 장애 발생 시점부터 서비스가 다시 동작하기까지 허용되는 최대 시간. "얼마나 빨리 켜야 하는가." RTO가 4시간이면 4시간 안에 복구돼야 합니다. 이것이 곧 허용 다운타임의 상한입니다.
- RPO(Recovery Point Objective, 복구목표시점): 복구했을 때 데이터가 어느 시점까지 보존되어야 하는가. "얼마만큼의 최근 데이터 손실을 감당하는가." RPO가 1시간이면 마지막 1시간치 데이터는 잃어도 된다는 뜻입니다.
시간 축에 그리면 이렇습니다. 장애 시점을 가운데 두고 — 왼쪽(과거)으로 얼마나 거슬러 올라간 데이터까지 살리느냐가 RPO, 오른쪽(미래)으로 얼마나 빨리 다시 켜느냐가 RTO입니다.
| 항목 | RTO | RPO |
|---|---|---|
| 묻는 것 | 얼마나 빨리 복구하는가 | 어느 시점 데이터까지 살리는가 |
| 축 방향 | 장애 이후(미래) — 다운타임 | 장애 이전(과거) — 데이터 손실 |
| 단위 의미 | 허용 최대 다운타임 | 허용 최대 데이터 손실 구간 |
| 직접 결정하는 것 | DR 사이트 유형, 전환 자동화 수준 | 백업·복제 주기 |
| 예(결제) | "30분 내 복구" | "데이터 손실 1분 이내" |
| 예(사내 위키) | "다음 영업일까지" | "하루치까지 손실 허용" |
둘은 독립적입니다. RTO는 빠른데 RPO는 느슨할 수도 있고(빨리 켜되 최근 데이터 일부 손실은 감수), 그 반대도 가능합니다. 그래서 서비스마다 "이 서비스는 RTO 몇, RPO 몇"을 따로 정의합니다.
그리고 둘 다 작을수록 비쌉니다. RPO를 0에 가깝게 하려면 실시간 복제가, RTO를 분 단위로 하려면 핫 사이트가 필요합니다. 그래서 목표는 '무조건 작게'가 아니라 서비스의 사업 가치에 맞춰 정합니다 — 멈췄을 때 손실이 큰 서비스에 더 투자합니다.
그림: RPO는 과거(데이터 손실), RTO는 미래(복구 속도)를 가리키며, 둘 다 작을수록 비싸다 — 서비스별 목표가 DR 사이트 유형을 정한다.
백업 전략 — RPO를 실제로 떠받치는 것
주기·보관·오프사이트, 그리고 '복원되는가'
백업은 DR의 토대지만, "백업을 받는다"는 말 한마디에 세 가지 결정이 숨어 있습니다.
- 주기(frequency): 얼마나 자주 받는가. 이게 곧 RPO의 하한입니다. 하루 1회 백업이면 최악의 경우 거의 하루치를 잃으므로 RPO는 24시간이 됩니다. RPO를 1시간으로 하려면 시간 단위 백업이나 준실시간 복제가 필요합니다.
- 보관(retention): 얼마나 오래 보관하는가. 어제 백업만 있으면, 사흘 전 침투한 랜섬웨어가 이미 백업에 포함됐을 때 깨끗한 시점으로 못 돌아갑니다. 그래서 일·주·월 단위로 세대를 두고 보관합니다(예: 일일 7개 + 주간 4개 + 월간 12개).
- 오프사이트(off-site): 어디에 두는가. 백업이 같은 데이터센터·같은 건물에만 있으면, 그 건물이 불타면 원본과 백업이 함께 사라집니다. 그래서 물리적으로 떨어진 위치(다른 지역, 클라우드)에 복제본을 둡니다. "3-2-1 원칙"이 흔히 인용됩니다 — 사본 3개, 매체 2종, 그중 1개는 오프사이트.
핵심 경고가 하나 있습니다. '백업을 받는 것'과 '백업으로 복구되는 것'은 다릅니다. 백업 파일이 손상됐거나, 복원 절차를 아무도 모르거나, 복원에 RTO를 넘기는 시간이 걸리면 — 백업은 있어도 복구는 실패합니다. 그래서 백업은 받는 것으로 끝이 아니라, 주기적으로 실제 복원 테스트를 해 무결성을 검증해야 합니다. 이 검증은 뒤에서 다룰 'DR 훈련'의 일부입니다.
DR 사이트 — 비용과 복구 속도의 트레이드오프
콜드 · 웜 · 핫
주 사이트가 통째로 죽었을 때 옮겨갈 **대체 사이트(DR site)**를 어느 수준으로 준비해 둘지가 RTO를 좌우합니다. 준비 수준이 높을수록 빨리 전환되지만, 평상시에도 그만큼 돈이 듭니다.
- 콜드 사이트(cold): 공간·전원·네트워크 회선 정도만 갖춘 '빈 껍데기'. 재해가 나면 장비를 들여오고 구성하고 데이터를 복원해야 하므로 며칠이 걸립니다. 가장 저렴하고, RTO가 길어도 되는 서비스에 적합합니다.
- 웜 사이트(warm): 핵심 서버·네트워크 장비가 미리 설치돼 있고, 최근 백업이 주기적으로 동기화됩니다. 재해 시 최신 데이터를 적용하고 켜면 되므로 보통 시간 단위로 복구합니다. 비용과 속도의 절충안.
- 핫 사이트(hot): 주 사이트와 거의 동일한 운영 환경이 항상 돌고 있고, 데이터가 실시간(또는 준실시간)으로 복제됩니다. 재해 시 트래픽만 넘기면 분 단위로 전환됩니다. 가장 빠르지만 평상시 이중 인프라 비용이 들고, 운영 복잡도도 높습니다.
| 유형 | 준비 수준 | 전형적 RTO | 데이터 신선도(RPO) | 평상시 비용 | 어울리는 서비스 |
|---|---|---|---|---|---|
| 콜드 | 공간·전원·회선만 | 며칠 | 마지막 백업 시점(느슨) | 낮음 | 멈춰도 되는 내부 시스템 |
| 웜 | 핵심 장비+최근 백업 | 수 시간 | 최근 백업 시점(중간) | 중간 | 중요하지만 분 단위는 아닌 업무 |
| 핫 | 실시간 동기 이중 운영 | 분 단위 | 거의 0(실시간 복제) | 높음 | 결제·주문 등 핵심 서비스 |
여기에 클라우드가 더한 선택지가 '파일럿 라이트'·자동 확장형 DR입니다 — 평상시엔 데이터 복제와 최소 구성만 켜 두고(저비용), 재해 시 스크립트로 빠르게 규모를 키우는 방식. 비용과 속도의 균형점을 더 유연하게 잡을 수 있습니다.
선택의 원칙은 단순합니다. 서비스별 RTO/RPO 목표가 사이트 유형을 정합니다. 모든 서비스를 핫으로 두면 파산하고, 모두 콜드로 두면 핵심 서비스가 며칠 멈춥니다. 그래서 서비스마다 등급을 매겨 차등 투자합니다.
직접 해보기 — 서비스별 복구 목표와 우선순위 설계
가상의 쇼핑몰을 운영한다고 가정합니다. 아래 5개 서비스에 대해 (1) 멈췄을 때의 사업 영향을 기준으로 RTO·RPO 목표를 정하고, (2) 어떤 DR 사이트 유형이 맞는지 고르고, (3) 재해 시 **무엇부터 복구할지 우선순위(1~5)**를 매겨 보세요. 정답 예시는 ObserveBlock에 있습니다.
1. 결제 서비스 (멈추면 매출 즉시 0, 거래 데이터 손실 치명적)
2. 주문 서비스 (결제와 직결, 핵심)
3. 상품 카탈로그 조회 (멈추면 매출 감소하나 즉각적 손실은 덜함)
4. 고객 리뷰 기능 (없어도 구매는 가능)
5. 사내 분석 대시보드 (대고객 영향 없음, 내부용)
설계 직관: **"멈추면 사업에 얼마나 큰 타격인가"**가 RTO·RPO를 정하고, 그 목표가 다시 DR 사이트와 복구 순서를 정합니다. 모든 걸 핫으로 둘 수는 없으니 핵심부터 자원을 몰아줍니다.
설계: 서비스별 RTO/RPO + DR 사이트 + 복구 우선순위- 결제 = RTO 30분 이내 / RPO ≈ 0 / 핫 사이트+실시간 복제 / 복구 우선순위 1순위 — 멈추면 매출이 즉시 0이고 거래 데이터 손실은 분쟁·신뢰 붕괴로 직결
- 주문 = RTO 1시간 / RPO 분 단위 / 핫 또는 상위 웜 / 2순위 — 결제와 한 몸이라 결제 직후 바로 살아나야 함
- 카탈로그 조회 = RTO 수 시간 / RPO 시간 단위 / 웜 사이트 / 3순위 — 중요하나 읽기 위주라 약간의 지연·손실 감내 가능
- 리뷰 기능 = RTO 1일 / RPO 1일 / 콜드~웜 / 4순위 — 없어도 핵심 구매 흐름은 동작
- 분석 대시보드 = RTO 며칠 / RPO 1일 / 콜드 사이트 / 5순위 — 대고객 영향 없는 내부용, 가장 늦게 복구
- 핵심 감각: 같은 "복구"라도 서비스마다 목표가 다르다. 우선순위 없이 "다 같이 살리자"고 덤비면 정작 핵심이 늦어진다 — 복구는 순서 싸움이다
현장에서 자주 보는 함정
증상: "우리는 백업 잘 받고 있다"고 자신했는데, 실제 장애·모의 상황에서 — 백업 파일이 손상돼 복원이 멈추거나, 복구 담당자 연락처가 바뀌어 있거나, 어느 시스템부터 살릴지 순서를 몰라 우왕좌왕하거나, 복원에 예상의 몇 배 시간이 걸려 RTO를 넘깁니다.
원인: DR 계획이 문서 속 가정에 머물렀습니다. 백업을 '받는' 것만 검증하고 '복원되는' 것은 검증한 적이 없습니다. 절차서의 연락처·권한·순서가 현실과 어긋난 채 방치됐고, 아무도 끝까지 한 번 돌려보지 않았습니다. 검증되지 않은 DR은 "복구될 것이다"라는 희망일 뿐입니다.
해결 방향:
- **정기 복구 훈련(리허설)**을 일정에 박아 둔다 — 분기 1회처럼. 실제로 DR 사이트로 전환하거나, 격리 환경에 백업을 복원해 끝까지 돌려본다.
- 훈련에서 RTO·RPO를 실측한다 — "목표 30분인데 실제 2시간 걸렸다"는 사실을 평상시에 발견해야 고친다.
- 복원 테스트로 백업 무결성을 검증한다 — 백업 성공 로그가 아니라, 그 백업으로 실제 서비스가 뜨는지를 본다.
- 훈련에서 드러난 간극(연락처·권한·순서·문서 오류)을 DR 계획에 즉시 반영하고 버전을 올린다. DR 문서는 한 번 쓰고 끝이 아니라 살아 있어야 한다.
리허설하지 않은 DR 계획은, 한 번도 시동 걸어본 적 없는 비상발전기와 같습니다 — 정전이 나서야 고장 난 걸 알게 됩니다.
국내 SI·운영(SM) 현장에서 연속성·DR은 흔히 계약과 컴플라이언스의 언어로 들어옵니다. 금융·공공 사업에서는 RTO·RPO가 사업 요구사항과 SLA에 명시되고, 전자금융감독규정·재해복구센터(DR센터) 구축 의무처럼 규제로 강제되는 경우가 많습니다. 그래서 관리자에게 "DR 사이트를 핫으로 할지 웜으로 할지"는 단순 기술 선택이 아니라 비용 산정·계약 범위·감사 대응이 걸린 의사결정입니다.
이런 자리에서 당신은 직접 복제를 구성하기보다, "이 서비스의 RTO/RPO를 사업 영향에 맞게 정의하고, 그에 맞는 DR 등급과 예산을 잡고, 협력사가 구축한 복구 체계가 실제로 동작하는지 훈련으로 검증하고, 그 결과를 발주사·감사에 보고하는" 일을 설계하고 통제합니다. 협력사 엔지니어가 "백업 잘 됩니다"라고 보고해도, 기술을 아는 관리자는 "마지막 복원 테스트는 언제, RTO 실측치는 얼마였나"를 되묻습니다. 그 질문 하나가 재해 때 회사를 살립니다.
또한 DR 훈련 보고서·복구 절차서(런북)·RTO/RPO 정의표는 그 자체가 감사와 사업 평가에서 요구되는 산출물입니다 — 잘 정리된 DR 문서는 관리 역량의 증거가 됩니다.
관련 모듈로 더 깊이:
- 가용성·용량 관리 — RTO·RPO를 떠받치는 가용성·용량 관리를 더 깊이
- 가용성·용량 관리 — 평상시 가용성과 재해 시 연속성의 연결 고리
- 정보보안 관리 — 가용성을 지키는 또 다른 축인 정보보안 관리
다음 모듈에서는 재해·장애와는 다른 결의 위협 — 외부 공격과 내부 유출로부터 서비스를 지키는 정보보안 관리(기밀성·무결성·가용성, 접근통제, 보안 인시던트 대응)를 정리합니다.