폐쇄망 DR 설계 — 무엇을 다중화하고 무엇을 *그냥 백업* 만 하나
클라우드 DR 가이드는 *모든 것을 다중 region* 가정. 폐쇄망에서는 *region 이 없음*. 4 가지 자원 분류와 각각의 다중화 전략.
클라우드 DR 가이드는 멀티 region 가정. 폐쇄망에는 region 이 없음. 같은 데이터센터의 별도 rack, 또는 멀리 떨어진 두 번째 데이터센터, 또는 그냥 백업 테이프. 이 셋 중 어느 것을 어디에 적용하나.
이 글은 우리 폐쇄망 고객 5곳의 DR 설계 정리. 4 자원 분류 + 각각의 다중화 전략.
4 자원 분류
자원 종류 | 다중화 비용 | 손실 비용
──────────────────────────┼───────────┼───────────
유저 데이터 (PII, 결제) | 매우 높음 | 매우 높음
운영 데이터 (메트릭, 로그) | 높음 | 중
설정 / 코드 | 낮음 | 낮음
임시 데이터 (캐시) | 0 | 0이 4 분류 각각에 다른 DR 전략. 모든 것을 같은 수준 으로 다중화하면 비용 폭발.
전략별 매핑
유저 데이터 — 동기 복제 + 별도 사이트
비용 매우 높음. 그러나 손실도 매우 높음 (법적 + 평판). 무조건 별도 데이터센터 에 동기 복제.
운영 사이트 | DR 사이트 (별도 데이터센터)
───────── ─────────────────────────
Postgres primary ← 동기 → Postgres replica
RPO: 0
RTO: 5~15분 (수동 failover)
RTO: 30초 (자동 failover, 복잡)폐쇄망 특성 — 두 사이트 사이의 전용선 필요. 암호화 강제. 지연시간 < 5ms 권장 (멀어지면 동기 복제 성능 저하).
운영 데이터 — 비동기 복제 + 같은 사이트 백업
비용 높음, 손실 중. 같은 데이터센터의 별도 rack 에 비동기 복제. 분기 1회 별도 사이트로 cold backup.
RPO 5분, RTO 1시간. 인시던트 분석에 손실이 생길 수 있지만 서비스 자체는 정상.
설정 / 코드 — git + 빌드 캐시
비용 낮음. git 저장소를 두 곳 mirror. 빌드 artifact 는 내부 registry 에 자동 백업.
이건 사실상 DR 의 기본. 거의 모든 조직이 자동으로 만족.
임시 데이터 — 그냥 잃음
캐시, 임시 세션, in-flight 요청 — DR 시점에 잃음. 사용자가 재시도 하면 됨.
이걸 다중화하려고 하면 비용이 유저 데이터급 으로 올라감. 받아들임 이 정답.
DR 시뮬레이션 — 분기 1회 강제
설계만 있는 DR 은 작동 안 함. 분기 1회 DR 시뮬레이션 강제.
Q1 시뮬레이션: primary DB 의도적 down → replica 로 failover → 검증 → 복구
Q2 시뮬레이션: 운영 사이트 전체 통신 차단 → DR 사이트 활성 → 검증 → 복구
Q3 시뮬레이션: 콜드 백업에서 *전체 복구* (일부 시스템) → 검증
Q4 시뮬레이션: 통합 — Q1+Q2+Q3 한 번에각 시뮬레이션은 반나절~하루 의 작업. 그러나 시뮬레이션 안 했던 조직은 진짜 사고 시 RTO 가 5배 늘어남.
4 자원 분류의 비용 표
자원 분류 | 다중화 인프라 비용 (월)
─────────────────┼─────────────────────────
유저 데이터 | $4,000~12,000 (별도 사이트)
운영 데이터 | $1,000~3,000
설정 / 코드 | $200 (git mirror)
임시 데이터 | 0
─────────────────┼─────────────────────────
총 | $5,200~15,200 / 월 = $62k~182k / 연이게 폐쇄망 DR 의 실제 비용. 클라우드 DR 보다 2~3배 — 전용선 + 별도 사이트 + 자체 운영 때문.
유저 데이터만 진짜 다중화
폐쇄망 시스템의 DR 을 설계 중인 SRE / 인프라 리드가 모든 것을 다중화 하는 가정으로 시작하면 비용 심사를 통과하지 못한다. 위 4 분류 중 유저 데이터만 진짜 다중화 하고 나머지는 적정 수준 으로 내리는 것 — 이게 현실적 답이다.
비슷한 글
기획자가 코드를 배포하면, 장애는 누가 책임질까
AI로 제품 담당자가 직접 코드를 만들고 여러 에이전트가 동시에 작업하는 조직에서, 운영에 나가는 변경을 누가 무엇으로 확인해야 하는지. NIST SSDF, SLSA provenance, Google SRE 포스트모템 문화를 근거로 작성자와 분리된 검증·승인·복구의 역할 설계를 정리했다.
백재민
에이전트 시대의 Eclipse 플러그인 — 작업 컨텍스트는 20년 전에도 문제였다
Mylyn 이 2000년대에 풀려던 문제와 지금 에이전트 컨텍스트 문제는 같습니다. 달라진 건 그 컨텍스트를 읽는 쪽에 사람만 있는 게 아니라는 점입니다.
김영상
에이전트 시대의 VS Code 확장 — 개발자는 에디터에서 무엇을 보는가
코드 작성 비용이 무너진 뒤 개발자의 시간은 판단과 승인으로 옮겨갔습니다. 그 일들이 왜 에디터 밖에 있으면 안 되는지, VS Code 확장을 만들며 내린 선택들.
이승백