180. 웜 사이트 (Warm Site)

핵심 인사이트

본질: 웜 사이트(Warm Site)는 서버·스토리지·네트워크 인프라를 사전 구축해 두되, 데이터는 주기적 백업·복제로 유지하고 재해 발생 시 수 시간~수 일 내 복구를 목표로 하는 중간 등급의 DR(Disaster Recovery) 시설이다.

가치: 핫 사이트 대비 40~70% 비용 절감을 달성하면서도 콜드 사이트보다 현저히 빠른 복구를 제공하여, 비용-연속성 균형을 추구하는 중견·대기업의 현실적 선택지가 된다.

판단 포인트: 기술사 시험에서는 데이터 동기화 주기와 RTO(Recovery Time Objective)·RPO(Recovery Point Objective) 간의 연관성, 웜 사이트를 핫 사이트로 업그레이드하는 전환 전략, 테스트 복잡도가 핵심 논점이다.

Ⅰ. 개요 및 필요성

재해 복구 전략을 수립할 때 조직은 항상 비용과 복구 속도 사이에서 균형점을 찾아야 한다. 핫 사이트는 최고의 복구 역량을 제공하지만, 주 센터와 동일한 인프라를 이중으로 운영하는 비용은 중소·중견 기업에게 부담이 크다. 반면 콜드 사이트는 최소 비용이지만 수 주에 달하는 복구 시간이 사업 연속성을 위협한다. 이 두 극단 사이에서 현실적 대안으로 등장한 것이 웜 사이트다.

웜 사이트는 물리적 공간, 네트워크 회선, 서버, 스토리지를 미리 설치해 두고 OS·미들웨어·애플리케이션까지 설정한 상태로 유지한다. 다만 핫 사이트와 달리 상시 가동은 하지 않으며, 데이터는 일별·주별 백업 또는 수 시간 주기 비동기 복제로 유지된다. 재해 선언 후 백업 데이터를 적재하고 서비스를 기동하는 과정이 필요하므로 핫 사이트보다 복구 시간이 길지만, 하드웨어 조달·설치가 필요한 콜드 사이트보다는 비교할 수 없이 빠르다.

금융기관 중 비핵심 시스템, 제조업의 ERP(Enterprise Resource Planning)·MES(Manufacturing Execution System), 대학의 학사 시스템 등이 웜 사이트의 대표적 적용 사례다. 국내 전자금융감독규정은 핵심 업무 시스템에 대한 DR 구축을 의무화하면서도, 시스템 중요도에 따라 RTO 기준을 차등 적용하므로 비핵심 시스템에는 웜 사이트가 규제 요건을 충족하는 현실적 선택이 된다.

📢 섹션 요약 비유: 웜 사이트는 부동산 모델하우스와 같다. 가구·인테리어가 다 갖춰져 있어 입주 준비가 돼 있지만, 짐(데이터)은 이사 당일 옮겨야 한다. 핫 사이트(이미 살고 있는 집)보단 느리고, 콜드 사이트(빈 땅)보단 훨씬 빠르다.

Ⅱ. 아키텍처 및 핵심 원리

웜 사이트의 기술 구성은 세 단계로 나뉜다. 인프라 사전 구축(Standby), 데이터 주기적 동기화(Synchronization), 재해 시 복구 절차(Recovery) 단계다.

┌─────────────────────────────────────────────────────────────┐
│              웜 사이트 DRS 아키텍처                           │
├─────────────────────────┬───────────────────────────────────┤
│  PRIMARY SITE (주 센터)  │   WARM SITE (DR 센터)             │
│                         │                                   │
│  ┌─────────────────┐    │   ┌─────────────────┐             │
│  │  App Server ×4  │    │   │  App Server ×4  │             │
│  │  (Active)       │    │   │  (Powered Off)  │             │
│  └────────┬────────┘    │   └─────────────────┘             │
│           │             │                                   │
│  ┌────────▼────────┐    │   ┌─────────────────┐             │
│  │  DB Server      │    │   │  DB Server      │             │
│  │  (Active)       ├────┼──►│  (Standby/Cold) │             │
│  └────────┬────────┘    │   └─────────────────┘             │
│           │  주기적 백업  │      수 시간 주기 복제             │
│  ┌────────▼────────┐    │   ┌─────────────────┐             │
│  │  Tape/NAS 백업  ├────┼──►│  Backup Storage  │             │
│  └─────────────────┘    │   └─────────────────┘             │
│                         │                                   │
│  ┌─────────────────┐    │   ┌─────────────────┐             │
│  │  Network (A)    │    │   │  Network (B)    │             │
│  │  (Active)       │    │   │  (Active)       │             │
│  └─────────────────┘    │   └─────────────────┘             │
├─────────────────────────┴───────────────────────────────────┤
│  재해 발생 → 백업 데이터 적재 → 서버 기동 → 서비스 복구       │
│  RTO: 수 시간 ~ 수 일,  RPO: 수 시간 ~ 1일                   │
└─────────────────────────────────────────────────────────────┘

복구 절차 세부 단계

단계	작업 내용	소요 시간
1. 재해 선언	DR 팀 소집, 피해 범위 확인	30분~1시간
2. DR 환경 활성화	서버 전원 투입, OS 기동	30분~2시간
3. 데이터 복원	백업 매체에서 DB·파일 복원	1~8시간
4. 무결성 검증	데이터 정합성, 애플리케이션 기능 테스트	1~4시간
5. DNS 절체	서비스 IP를 DR 센터로 변경	수 분
6. 서비스 재개	모니터링 하에 트래픽 수용	즉시

네트워크는 상시 연결된 상태를 유지하여 재해 발생 즉시 트래픽 절체가 가능하다. 이는 콜드 사이트와 웜 사이트를 구분하는 중요한 기준 중 하나다.

📢 섹션 요약 비유: 웜 사이트 복구는 오래 쉬었다 일 나온 직원 같다. 사무실(인프라)은 있고, 책상(서버)도 있지만 오늘 업무 서류(최신 데이터)를 가져다 놓고 컴퓨터를 켜야(서버 기동) 일을 시작할 수 있다.

Ⅲ. 비교 및 연결

구분	핫 사이트	웜 사이트	콜드 사이트
RTO	≤ 4시간	수 시간 ~ 수 일	수 주
RPO	0 ~ 수 분	수 시간 ~ 1일	수 일
서버 상태	상시 가동	설치됨·전원 off	없음(조달 필요)
데이터 상태	실시간 복제	주기 백업/복제	오프사이트 백업
구축 비용	주 센터의 100%	30~60%	10% 이하
연간 운영비	최고	중	최저
테스트 복잡도	중	고	매우 고

웜→핫 사이트 업그레이드 전략: 조직의 비즈니스 성장, 규제 강화, 또는 사고 학습으로 인해 웜 사이트를 핫 사이트로 격상할 수 있다. 이 경우 ①실시간 복제 솔루션 도입, ②DR 서버 상시 가동, ③Failover 자동화 구현, ④RTO 목표 재설정의 4단계를 순차적으로 적용한다. 인프라 투자는 이미 완료되어 있으므로 점진적 업그레이드가 가능하다는 것이 웜 사이트의 전략적 가치다.

📢 섹션 요약 비유: 핫·웜·콜드 사이트는 여행 준비와 같다. 핫은 캐리어 다 싸서 현관에 세워 둔 것, 웜은 옷장에서 꺼낼 옷은 골랐지만 아직 싸지 않은 것, 콜드는 여행 계획도 없는 것이다.

Ⅳ. 실무 적용 및 기술사 판단

웜 사이트 설계 시 핵심 결정 사항

데이터 동기화 주기 결정: RPO 목표(예: 4시간)에 맞게 백업 스케줄을 설정한다. 증분(Incremental) 백업과 전체(Full) 백업을 조합하여 복원 시간을 단축한다.
인프라 사이징: 주 센터 피크 부하의 70~100%를 처리할 수 있도록 설계한다. DR 시 일부 비핵심 서비스는 임시 중단하는 정책도 병행한다.
주기적 기동 테스트: 서버를 분기 1회 이상 기동하여 하드웨어 이상 여부를 확인한다. 장시간 비전원 상태에서 서버 배터리, 디스크 불량이 발생할 수 있다.
DRP 문서화: 복구 절차를 단계별로 세분화하고 담당자별 역할을 명시한다. 야간·휴일 재해 시 비상 연락망도 문서에 포함한다.
클라우드 웜 사이트: AWS Pilot Light 패턴이 대표적 클라우드 웜 사이트 구현 방법이다. 최소한의 핵심 인프라만 클라우드에서 상시 운영하고, 재해 시 스케일아웃(Scale-Out)으로 풀 규모를 구현한다.

BCP(Business Continuity Plan)와의 연계: 웜 사이트 DR 계획은 상위 개념인 BCP와 연계되어야 한다. BCP는 IT 복구뿐 아니라 인력, 업무 공간, 공급망 연속성을 포함하는 포괄적 계획이다. IT DR 계획(DRP)은 BCP의 하위 계획으로 위치한다.

📢 섹션 요약 비유: DRP와 BCP의 관계는 응급처치 매뉴얼(DRP)과 병원 전체 비상 운영 계획(BCP)의 관계와 같다. 매뉴얼이 훌륭해도 병원 전체 운영 계획 없이는 한계가 있다.

Ⅴ. 기대효과 및 결론

웜 사이트는 비용 효율성과 복구 역량의 현실적 균형점으로서, 국내 중견·대기업 DR 시장에서 가장 광범위하게 채택되는 방식이다. 핫 사이트의 높은 비용 부담 없이 규제 요건을 충족하고, 콜드 사이트의 장기 복구 위험을 회피할 수 있다.

클라우드 전환 트렌드에서 웜 사이트의 미래는 "Pilot Light" 또는 "Warm Standby" 클라우드 패턴으로 진화하고 있다. 클라우드 환경에서는 인프라를 코드로 관리하므로 기존 물리 웜 사이트 대비 ①복구 시간 단축, ②테스트 자동화, ③비용 탄력성이라는 세 가지 강점을 동시에 달성할 수 있다.

핵심은 RTO·RPO 목표를 BIA 기반으로 산출하고, 그에 맞는 DR 등급과 기술 조합을 합리적으로 선택하는 의사결정 역량이다. 웜 사이트는 그 스펙트럼에서 '현실과 이상의 교점'에 위치한 솔루션이다.

📢 섹션 요약 비유: 클라우드 웜 사이트는 마치 도미노피자의 "30분 내 배달 보장"과 같다. 재료(인프라 코드)는 항상 준비돼 있고, 주문(재해 선언)이 들어오면 빠르게 굽고(프로비저닝) 배달(서비스 복구)한다.

📌 관련 개념 맵

개념	설명	연관 키워드
RTO (Recovery Time Objective)	서비스 복구 허용 최대 시간	SLA, DR 등급
RPO (Recovery Point Objective)	허용 데이터 손실 최대 시점	백업 주기, 복제
BIA (Business Impact Analysis)	장애 시 비즈니스 영향 분석	RTO/RPO 도출
Pilot Light	클라우드 최소 인프라 상시 운영 후 재해 시 확장	AWS, 웜 사이트
Incremental Backup	변경분만 백업하여 저장 공간·시간 절약	Full Backup
Failback	DR 복구 후 주 센터로 복귀 절차	DRP
BCP (Business Continuity Plan)	IT+인력+공간 포함 전사 연속성 계획	DRP 상위 개념
DRP (Disaster Recovery Plan)	IT 시스템 복구에 특화된 세부 계획	BCP 하위 계획

👶 어린이를 위한 3줄 비유 설명

웜 사이트는 집 근처 창고에 가구(서버)는 다 넣어 두었지만 전기(데이터)는 주기적으로 충전하는 예비 집이에요.
갑자기 본집이 홍수로 못 쓰게 되면, 창고 가구를 꺼내 배치하고 전기를 연결하면 며칠 안에 살 수 있어요.
핫 사이트보다 돈이 덜 들지만 준비 시간이 조금 더 필요해서, 적당히 중요한 시스템에 딱 맞는 선택이에요.