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

1. 서버에 불이 났을 때 "얼마나 많은 데이터가 날아갔는가?"를 나타내는 한계선이 **RPO (목표 복구 시점)**이다.
2. RPO가 **"0"**이라는 것은 단 1건의 결제 내역도 유실되지 않아야 한다는 뜻이며, 이를 위해서는 무조건 거리 제한과 성능 하락을 감수하고서라도 동기식(Synchronous) 스토리지 미러링을 써야 한다.
3. RPO가 **"24시간"**이라면 하루에 한 번만 자기 테이프(Tape)에 백업해 두면 되므로 인프라 구축 비용이 기하급수적으로 저렴해진다.

Ⅰ. RPO의 개념: "과거"로의 시간 여행

오후 2시에 데이터센터에 벼락이 떨어져 스토리지 서버가 몽땅 타버렸습니다. 관리자가 부산에 있는 백업 센터(DR)의 스토리지를 열어보았더니, 가장 마지막으로 데이터가 복사된 시간이 오후 1시였습니다.

• 현실의 데이터 유실량: 오후 1시부터 오후 2시까지(1시간 동안) 고객들이 결제하고 게시판에 쓴 데이터는 영영 복구할 수 없이 날아갔습니다.
• RPO의 의미: 만약 회사가 "우리는 최악의 경우라도 최근 1시간 치의 데이터 유실까지만 감당할 수 있어!"라고 정책을 정해두었다면, 이 시스템의 RPO는 1시간이 됩니다.

📢 섹션 요약 비유: 게임을 할 때 "내가 언제 세이브를 했지?"입니다. RPO가 1시간이라면 게임에서 죽었을 때 1시간 전 세이브 파일로 돌아가는 고통(유실)을 감당하겠다는 뜻입니다.

Ⅱ. RPO에 따른 하드웨어 아키텍처의 변화

RPO를 얼마나 타이트하게 잡느냐에 따라 회사가 써야 하는 하드웨어 스토리지의 구조가 완전히 달라집니다. (비용과 직결)

1. RPO = 24시간 (수백만 원 소요)

• 방식: 매일 새벽 3시에 서버 관리자가 일괄적으로 데이터를 '자기 테이프(LTO Tape)'나 값싼 HDD 백업 스토리지(NAS)로 압축해서 넘깁니다. (Batch Backup)
• 적용: 하루 치 데이터가 날아가도 엑셀 보고서 다시 쓰면 되는 사내 인트라넷, 단순 웹진.

2. RPO = 5분 ~ 1시간 (수천만 원 소요)

• 방식: 주 스토리지에서 5분 단위로 스냅샷(Snapshot)을 찍어 비동기식(Asynchronous)으로 DR 센터에 전송합니다.
• 적용: 대형 쇼핑몰. 5분 치 결제가 날아가면 큰일 나지만, 고객들에게 사과 공지 띄우고 DB 로그를 뒤져 수동으로 보상해 주면 기업이 망하진 않습니다.

3. RPO = 0 (수십~수백억 원 소요)

• 방식: 동기식 스토리지 미러링(Synchronous Mirroring). 데이터를 서울에 씀과 동시에 부산(또는 판교) 디스크에도 완벽히 100% 쓰였는지 확인한 뒤에야 완료를 띄웁니다.
• 적용: 은행의 계좌 이체, 주식 거래소. 0.001초의 송금 데이터라도 날아가면 소송이 걸리고 금융감독원에 불려 갑니다.

📢 섹션 요약 비유: 세이브 파일을 매일 밤 자기 전에 한 번씩 수첩에 베껴 적을지(RPO 24h), 5분마다 복사기로 찍어둘지(RPO 5m), 아니면 아예 양손에 펜을 쥐고 두 개의 노트에 동시에 꾹꾹 눌러서 똑같이 적을지(RPO 0) 결정하는 것입니다.

Ⅲ. 현대의 꼼수: 액티브-액티브 (Active-Active) 분산 DB

RPO 0을 달성하려면 동기식 미러링의 속도 저하(Latency)를 견뎌야 했습니다. 하지만 최근 넷플릭스나 구글은 아예 하드웨어 미러링(SAN)에 의존하는 대신, **카산드라(Cassandra)**나 구글 스패너(Spanner) 같은 분산 데이터베이스를 도입했습니다.

데이터를 저장할 때 3개의 데이터센터(서울, 도쿄, 싱가포르)에 동시에 쏘고, "최소 2곳(Quorum)에서 저장 성공하면 결제 완료해!"라는 식의 소프트웨어적 타협(Paxos 알고리즘)을 통해 하드웨어의 지연을 우회하면서도 RPO 0을 달성하는 방향으로 진화하고 있습니다.