멈추지 않는 기업을 위한 보험, DR 시스템
2022년 판교 데이터 센터 화재 사건은 우리에게 큰 교훈을 남겼습니다. "데이터가 사라지면 기업도 사라진다"는 사실입니다. 천재지변, 해킹, 랜섬웨어, 혹은 단순한 작업자 실수로 시스템이 멈췄을 때, 기업이 얼마나 빨리, 그리고 얼마나 온전하게 다시 일어설 수 있는지를 결정하는 것이 바로 재해 복구(Disaster Recovery, DR) 시스템입니다.
하지만 무작정 "가장 빨리, 데이터 손실 없이"를 외치면 천문학적인 비용이 듭니다. 합리적인 DR 전략을 세우기 위해 경영진과 실무자가 반드시 합의해야 할 두 가지 기준, RTO와 RPO에 대해 알아봅니다.
1. RTO (Recovery Time Objective): "언제 다시 켜지는가?"
RTO는 우리말로는 '목표 복구 시간'입니다. 쉽게 말해, 재해가 발생한 시점부터 서비스가 재개될 때까지 걸리는 허용 시간을 의미합니다. 이는 비즈니스 중단 시간(Downtime)과 직결됩니다.
- 핵심 질문: "서버가 죽으면 몇 시간 안에 다시 켜져야 고객들이 떠나지 않을까?"
- 예시: RTO가 4시간이라면, 오후 1시에 장애가 발생했을 때 늦어도 오후 5시까지는 시스템이 정상 가동되어야 합니다.
- 비즈니스 영향: RTO가 짧을수록 서비스 중단 시간이 줄어들어 매출 손실과 브랜드 이미지 타격을 최소화할 수 있습니다. 하지만 이를 위해서는 Active-Standby나 고가용성(HA) 장비 등 즉각적인 복구 인프라가 필요하므로 비용이 급격히 상승합니다.
2. RPO (Recovery Point Objective): "데이터를 얼마나 잃어도 되는가?"
RPO는 '목표 복구 시점'입니다. 재해 발생 시 데이터를 어느 시점까지 되살릴 것인가에 대한 기준입니다. 이는 데이터 손실 허용 범위(Data Loss Tolerance)를 결정합니다.
- 핵심 질문: "사고가 났을 때, 최근 몇 시간 동안의 데이터가 날아가도 회사가 망하지 않을까?"
- 예시: RPO가 1시간이라면, 오후 1시에 장애가 발생했을 때 데이터를 복구하면 오후 12시(정오) 시점의 데이터로 돌아갑니다. 즉, 12시부터 1시 사이의 1시간 분량 데이터는 유실됨을 각오해야 합니다.
- 기술적 의미: RPO는 백업 주기와 직결됩니다. RPO를 0에 가깝게 하려면 실시간 동기화(Synchronous Replication)가 필요하고, RPO가 24시간이라면 하루 한 번 테이프 백업만 해도 충분합니다.
3. RTO와 RPO의 결정적 차이 비교
두 개념을 혼동하기 쉽지만, 명확히 구분해야 올바른 투자를 할 수 있습니다.
- RTO는 '시간(Time)'의 싸움: 얼마나 빨리 복구하느냐 (Speed focus)
- RPO는 '데이터(Data)'의 싸움: 얼마나 많이 살려내느냐 (Volume focus)
가령, 금융권의 계좌 이체 시스템은 단 1원의 오차도 허용할 수 없으므로 RPO는 '0(Zero)'이어야 합니다. 하지만 사내 게시판 시스템이라면 하루치 데이터가 날아가도 치명적이지 않으므로 RPO를 '24시간'으로 설정해 비용을 아낄 수 있습니다.
4. 비용과 리스크의 줄다리기: 최적의 지점 찾기
이상적인 목표는 당연히 RTO = 0, RPO = 0입니다. 재해가 나자마자 즉시 복구되고, 데이터 손실도 전혀 없는 상태죠. 하지만 이를 구현하려면 미러링(Mirroring) 서버를 구축하고 전용 회선을 까는 등 막대한 예산이 듭니다.
반대로 비용을 아끼려고 RTO와 RPO를 너무 길게 잡으면, 실제 재해 발생 시 복구가 너무 늦어져 고객 신뢰를 잃거나 핵심 데이터를 영구히 잃어버릴 위험이 커집니다. 따라서 다음과 같은 단계별 접근이 필요합니다.
- 업무 중요도 분류 (Tiering): 모든 시스템이 똑같이 중요하지 않습니다. 핵심 업무(Tier 1), 중요 업무(Tier 2), 일반 업무(Tier 3)로 나눕니다.
- 차등 적용:
- Tier 1 (결제, DB): RTO 수 분, RPO 0 (실시간 동기화)
- Tier 3 (이메일 아카이브): RTO 24시간, RPO 24시간 (일일 백업)
5. 클라우드 시대의 DR 전략
과거에는 DR 센터를 구축하려면 물리적인 건물을 짓고 서버를 사야 했지만, 클라우드(AWS, Azure 등)의 등장으로 패러다임이 바뀌었습니다.
- 파일럿 라이트(Pilot Light): 평소에는 DB 데이터만 실시간으로 복제하고, 웹 서버는 꺼둡니다. 재해 시에만 서버를 켜서 비용을 획기적으로 줄이는 전략입니다.
- 웜 스탠바이(Warm Standby): 최소한의 사양으로 축소된 버전의 시스템을 항상 켜두고, 재해 시 빠르게 확장(Scale-up)하는 방식입니다.
기술이 아니라 경영의 문제입니다
RTO와 RPO 설정은 단순한 IT 팀의 숙제가 아닙니다. "우리 회사가 멈췄을 때 시간당 얼마의 손해를 감수할 수 있는가?"에 대한 경영진의 의사결정입니다.
지금 여러분 조직의 BCP(업무 연속성 계획) 문서를 열어보세요. 혹시 "최대한 빨리"라는 모호한 말만 적혀 있지는 않나요? 명확한 수치로 된 RTO와 RPO를 정의하는 것, 그것이 위기 상황에서 기업을 구하는 첫 번째 안전장치입니다.