핵심 인사이트 (3줄 요약)

  1. 이전 장의 RPO가 '과거로 돌아가는 시간(데이터 유실)'을 의미한다면, **RTO (목표 복구 시간)**는 '장애가 난 시점부터 미래에 시스템이 정상화될 때까지의 시간'을 의미한다.
  2. RTO를 10초 이내로 잡는다면, 주 센터가 죽는 순간 백업 센터가 IP 주소를 빼앗아 스스로 살아나는 이중화(Active-Standby) 클러스터링 및 핫 스탠바이(Hot Standby) 하드웨어가 필요하다.
  3. RTO가 길어질수록 복구 비용은 싸지지만 비즈니스 중단(Downtime)으로 인한 손실이 커진다.

Ⅰ. RTO의 개념: "언제 고쳐지나요?"

오후 2시에 데이터센터에 벼락이 떨어졌습니다. 데이터는 유실 없이(RPO 0) 부산 데이터센터에 잘 저장되어 있음을 확인했습니다.

  • 현실의 복구 시간: 부산 센터의 쿨링팬을 켜고, 멈춰있던 서버(CPU)에 전원을 넣고, OS를 부팅시키고, 데이터베이스를 구동하여 웹사이트에 "결제 가능" 화면이 뜰 때까지 총 4시간이 걸렸습니다.
  • RTO의 의미: 만약 회사가 "우리 쇼핑몰은 장애가 나도 무조건 2시간 안에는 다시 열어야 해!"라고 정책을 세웠다면 이 시스템의 RTO는 2시간입니다. (위 사례는 4시간이 걸렸으므로 RTO 달성에 실패한 끔찍한 사고입니다.)

📢 섹션 요약 비유: 게임에서 죽었습니다. 방금 전 세이브 포인트에서 다시 시작하는 데(RPO), 게임 로딩 창이 얼마나 오래 걸려서 내가 다시 캐릭터를 조종할 수 있게 되느냐(RTO)의 문제입니다.

Ⅱ. RTO 수준에 따른 시스템 아키텍처

RTO를 얼마나 짧게 설정하느냐에 따라, 백업 시스템이 평소에 '어떤 상태로 대기'해야 하는지가 결정됩니다.

1. Cold Standby (콜드 대기) - RTO: 수일 ~ 1주일

  • 상태: 부산 백업 센터에 깡통 서버 하드웨어만 꺼진 상태로 먼지를 맞으며 쌓여 있습니다.
  • 복구: 불이 나면 직원이 부산으로 KTX를 타고 가서, 서버 전원을 켜고 OS를 설치한 뒤 백업 테이프를 밀어 넣고 복구합니다. 비용은 가장 싸지만 비즈니스는 일주일간 올스톱입니다.

2. Warm Standby (웜 대기) - RTO: 수 시간

  • 상태: 부산 센터의 서버에 OS와 DB가 미리 다 깔려 있고 전원도 켜져 있습니다. 하지만 앱 서비스(프로그램)는 꺼져 있습니다.
  • 복구: 직원이 원격으로 접속해 스크립트를 돌려 앱 서비스를 켜고(Start), 네트워크 IP를 돌린 후 DNS를 갱신합니다. 몇 시간 뒤 복구됩니다.

3. Hot Standby (핫 대기) - RTO: 수 초 ~ 수 분 (Active-Standby)

  • 상태: 부산 센터의 앱 서비스까지 100% 켜져 있고, 지금 당장 사용자 요청을 받을 준비를 마친 채 콧김을 뿜으며 대기 중입니다.
  • 복구: 서울 센터와 연결된 하트비트(Heartbeat) 신호가 3초간 끊기면, 소프트웨어(클러스터링 솔루션)가 이를 감지하고 사람 개입 없이 스스로 즉각 IP(가상 IP)를 탈취해 부산 센터로 트래픽을 돌려버립니다.

4. Active-Active - RTO: 0초

  • 상태: 서울과 부산이 평소에도 동시에 트래픽을 절반씩 나눠서 100% 일하고 있습니다.
  • 복구: 서울이 죽으면? 그냥 로드 밸런서가 부산으로 트래픽을 100% 몰아줍니다. 사용자는 에러 창조차 보지 못합니다. (단, 두 센터의 데이터를 실시간 동기화해야 하므로 구축 비용이 천문학적입니다.)

📢 섹션 요약 비유: 주전 선수가 다쳤습니다.

  • 콜드: 집에 있는 후보 선수를 불러와서 유니폼 입히고 뜁니다. (경기 중단)
  • 웜: 벤치에 유니폼 입고 앉아있는 선수가 스트레칭을 시작합니다.
  • 핫: 터치라인에서 이미 뛸 준비를 마친 선수가 휘슬이 울리자마자 튀어 나갑니다.
  • 액티브-액티브: 투톱 스트라이커 중 한 명이 다쳤지만, 남은 한 명이 알아서 두 몫을 뜁니다.

Ⅲ. 클라우드 시대의 RTO

과거에는 Hot Standby를 유지하려면 트래픽이 0인 서버를 위해 1년 내내 전기세와 하드웨어 감가상각비를 지불해야 하는 끔찍한 낭비(Idle Tax)가 발생했습니다.

최근의 AWS/Azure 등 클라우드 환경에서는 이를 **오토 스케일링(Auto Scaling)과 인프라 코드화(IaC, Terraform)**로 극복합니다. 평소에는 부산(다른 가용 영역, AZ)에 서버를 1대도 켜놓지 않고 돈을 아끼다가, 장애가 감지되는 순간 코드를 통해 단 30초 만에 클라우드 서버 100대를 동시에 찍어내서(Warm $\rightarrow$ Hot 전환) RTO를 분 단위로 끊어버리는 마법을 부리고 있습니다.