들어가며 — 2025년 9월 26일 저녁, 대한민국 행정이 멈췄다(2)
2025년 9월 26일 오후 8시 20분. 대전광역시 국가정보자원관리원 5층 전산실에서 UPS용 리튬이온 배터리에 불꽃이 튀었다. 배터리를 안전한 곳으로 옮기려다 화재가 난 것이다. 아이러니도 이런 아이러니가 없다.
결과는 참혹했다. 모바일 신분증, 국민신문고, 행정안전부 민원 시스템 등 709개 정부 업무시스템이 한꺼번에 멈췄다. 1등급 시스템 40개, 2등급 68개가 포함됐다. 민원인들은 팩스와 우편으로 민원을 넣어야 했다. 국회예산정책처는 이 사고의 직접 피해액을 100억 원에 가까운 수준으로 추산했다.
그런데 더 충격적인 사실이 있다. 화재 직전인 2024년, 행정안전부는 각 부처에 ‘1·2등급 재해복구시스템 구축 투자 금지’ 지침을 내렸다. 대전-공주 센터 간 이원화 네트워크 구축 예산 75억 6천만 원을 요구했지만 기재부가 61%를 삭감해 29억 5천만 원만 반영됐다. 결국 DR에 투자하지 않으려다 그보다 훨씬 큰 피해를 입은 것이다.
이 사건은 IT 업계에서 오래전부터 반복해온 질문 하나를 다시 수면 위로 끌어올렸다.
“재해복구 구축, 과연 얼마나 투자해야 하는가? 그리고 그 근거는 무엇인가?”
이 글은 그 질문에 실무 관점에서 답하기 위해 썼다. BIA(업무영향분석)와 RA(위험평가)를 출발점으로 삼아, DR 구축 투자의 합리적 근거를 어떻게 수립하는지, 그리고 비용 대비 효과를 어떻게 따져야 하는지 체계적으로 정리한다.
1. DR 투자 논쟁의 핵심 — “이게 보험이냐, 낭비냐”
DR(Disaster Recovery, 재해복구)은 오랫동안 경영진에게 ‘비용 블랙홀’로 여겨져 왔다. 서버를 두 배로 사고, 회선도 두 배, 라이선스도 두 배. 그런데 정작 재해는 평생 한 번 올까 말까 하다. 사용하지도 않는 인프라에 수십억을 박아두자니 CFO 눈치가 보인다.
반면 IT 담당자 입장에서는 등골이 서늘하다. 재해가 실제로 터지면 ‘그때 왜 안 만들었냐’는 질타가 쏟아진다. 이 갈등 구조가 수십 년째 반복되고 있다.
이 논쟁에서 빠진 것이 바로 BIA와 RA다. 이 두 가지가 없으면 DR 논의는 감(感)으로 하는 싸움이다. BIA와 RA가 있으면 숫자로 하는 대화가 된다. 결론부터 말하면, DR 투자의 적정 규모는 BIA와 RA가 정해준다.
2. BIA란 무엇인가 — “업무가 멈추면 얼마나 아픈가”
BIA(Business Impact Analysis)의 정의
BIA는 재해가 발생했을 때 비즈니스에 어떤 영향이 미치는지를 정량·정성적으로 분석하는 작업이다. 단순히 “시스템이 중요하다”는 감각적 판단이 아니라, 업무 중단 시간 × 시간당 손실 = 피해액이라는 계산식을 현실에 맞게 채워나가는 과정이다.
BIA가 산출하는 핵심 지표는 두 가지다.
- RTO(Recovery Time Objective): 재해 발생 후 서비스가 복구되어야 하는 최대 허용 시간. “우리는 4시간 이상 멈추면 안 된다”처럼 업무 특성에 따라 설정한다.
- RPO(Recovery Point Objective): 수용 가능한 최대 데이터 손실 시점. “최대 1시간 전 데이터까지는 잃어도 괜찮다”는 식으로 설정한다.
RTO와 RPO는 숫자가 작을수록 복구 수준이 높아지고, 그만큼 구축 비용도 올라간다. 그래서 BIA는 단순한 기술 분석이 아니라 비즈니스 의사결정의 영역이다.
BIA 수행 절차 (현장에서 실제 하는 방식)
현장에서 BIA를 수행할 때는 대략 다음 순서를 따른다.
① 핵심 업무 프로세스 식별 모든 업무를 나열한 뒤 각각의 중요도를 구분한다. “결제가 안 되면 바로 매출 손실” vs “보고서 출력이 안 되면 불편하지만 버틸 수 있음” — 이 차이를 명확히 한다.
② 업무별 의존 시스템 매핑 각 업무 프로세스가 어떤 IT 시스템에 의존하는지 매핑한다. 이 단계에서 시스템 간 상호의존성이 드러나기 시작한다.
③ 정량적 손실 추정 업무가 멈춘 시간에 따른 손실을 돈으로 환산한다. 직접 손실(매출 중단, 계약 위약금)과 간접 손실(고객 이탈, 브랜드 손상, 규제 과태료)을 모두 포함한다.
④ MTD(Maximum Tolerable Downtime) 설정 각 업무 프로세스가 버틸 수 있는 최대 중단 시간을 설정한다. MTD 내에 복구하지 못하면 해당 비즈니스 자체가 위협받는다는 의미다.
⑤ RTO/RPO 도출 MTD를 기반으로 각 시스템의 RTO와 RPO를 설정한다. MTD보다 항상 짧아야 한다.
3. RA란 무엇인가 — “재해가 얼마나 자주, 얼마나 심하게 오는가”
RA(Risk Assessment)의 역할
BIA가 “피해 규모”를 따진다면, RA는 “발생 가능성”을 따진다. 재해복구에서의 위험평가는 단순히 ‘화재 위험’, ‘지진 위험’을 나열하는 게 아니다. 각 위협이 실제로 발생했을 때 어떤 자산이 얼마나 취약한지를 체계적으로 평가하는 작업이다.
RA의 산출 공식은 간단하다.
위험 = 위협의 발생 가능성 × 취약성 × 자산 가치
여기서 자산 가치는 BIA에서 이미 산출했다. RA는 그 자산이 얼마나 쉽게 위협에 노출되는지를 평가한다.
DR 구축에서 RA가 반드시 필요한 이유
국정자원 화재 사례로 돌아가면, 사전 RA를 제대로 했다면 무엇이 달라졌을까. 아마 이런 항목이 위험 목록에 등재됐을 것이다.
- 단일 데이터센터 집중 위험: 전체 국가 정보시스템의 3분의 1 이상이 대전 본원 한 곳에 몰려 있음
- UPS 배터리 관련 화재 위험: 리튬이온 배터리 이동 작업 중 발화 가능성
- 이중화 부재 위험: 대전 장애 시 광주, 대구 센터로의 Failover 체계 미구축
RA 결과가 경영진에게 공식적으로 보고됐다면, “DR 예산 61% 삭감”이라는 결정이 그렇게 쉽게 내려지지 않았을 것이다. RA는 위험을 가시화해서 의사결정자에게 제대로 된 정보를 제공하는 역할을 한다.
4. BIA와 RA가 DR 구축 규모를 결정하는 방식
BIA와 RA를 완료하면 각 시스템은 등급으로 분류된다. 이 등급이 DR 구축 방식과 투자 규모를 직접 결정한다.
시스템 등급별 DR 구축 방식 비교
| 등급 | 기준 | DR 방식 | RTO 목표 | RPO 목표 | 구축 비용 수준 |
|---|---|---|---|---|---|
| 1등급 (Critical) | 중단 시 즉각적 비즈니스 손실, 법적 의무 | Active-Active (A-A) | 0~수분 | 0~수초 | 최고 (원장 시스템의 3~5배) |
| 2등급 (High) | 4시간 이상 중단 시 중대 손실 | Active-Standby (Hot Standby) | 수시간 이내 | 1시간 이내 | 높음 |
| 3등급 (Medium) | 1일 이상 중단 시 업무 차질 | Warm Standby | 1일 이내 | 수시간 이내 | 중간 |
| 4등급 (Low) | 수일 이상 중단 가능 | Cold Standby / 백업 복구 | 수일 이내 | 24시간 이내 | 낮음 |
이 표가 중요한 이유는, 모든 시스템에 1등급 수준의 DR을 적용하는 것이 비합리적이라는 것을 보여주기 때문이다. BIA 없이 DR 구축을 하면 어떤 일이 생기냐면 — 담당자 목소리 큰 순서대로, 또는 전산실 인맥 순서대로 이중화가 이뤄진다. 정말 돈을 버리는 것과 다를 바 없다.
국내 금융권의 사례
국내 금융기관들은 금융감독원 규정에 따라 BIA와 RA를 의무적으로 수행하고, 결과에 따라 DR 등급을 설정해야 한다. 핵심 계정계 시스템은 대부분 A-A 구조를 요구하고, 정보계나 채널 시스템은 2~3등급으로 분류한다. 이 등급 체계가 없으면 수백 개 시스템에 어떻게 투자를 배분할지 근거가 없다.
5. DR 구축 비용 — 현실적으로 얼마나 드는가
DR 구축 비용을 얘기할 때 가장 큰 오해가 있다. “원장 시스템의 복사본이니까 비슷하게 들겠지”라는 생각이다. 실제로는 그보다 훨씬 복잡하다.
DR 구축 방식별 비용 구조
① On-premise DR 센터 구축 (전통 방식)
자체 DR 전용 데이터센터를 구축하는 방식이다. 초기 투자 비용이 가장 크다.
- 부지 및 건물 임차/구축
- 서버, 스토리지, 네트워크 장비 (운영 환경의 50~100% 수준)
- 전용 회선 (운영-DR 센터 간 안정적 복제를 위한 광회선)
- 소프트웨어 라이선스 (라이선스 계약에 따라 거의 두 배)
- DR 전담 운영 인력 (또는 운영 인력 이중화)
이 방식은 완전한 통제권을 가지지만, 평상시에는 그 자산 전체가 사실상 놀고 있다는 단점이 있다.
② DRaaS(DR as a Service) — 클라우드 기반
클라우드 사업자의 DR 서비스를 이용하는 방식이다. 초기 CAPEX를 크게 줄이고 OPEX로 전환할 수 있다.
- 평상시 복제 데이터 스토리지 비용만 발생
- 재해 발생 시에만 컴퓨팅 자원 사용 과금
- Failover 테스트 비용은 별도 발생 가능
OCI, AWS, Azure 등 주요 클라우드 사업자들은 DRaaS를 제공하며, 특히 금융권에서는 오라클 DB와의 호환성을 이유로 OCI 기반 DRaaS 도입이 늘고 있다.
③ 공동구축 / 상호구축
두 기관이 서로의 DR 사이트가 되어주는 방식이다. 구축 및 유지 비용이 가장 낮지만, 동시 재해 발생 시 상호 복구가 불가능하고 보안과 신뢰성 이슈가 존재한다.
실제 투자 규모 참고 수치
정부 차원에서 보면, 이번 국정자원 화재 이후 행정안전부가 배정받은 범정부 DR 예산만 3,434억 원이다. ISP(정보화전략계획) 사전 컨설팅 단계에만 400억 원대다. NIA는 2026년 공공 재해복구시스템 구축 ISP 사업을 1차에서 5차까지 발주했으며, 총 규모는 2,523억 원에 이른다.
민간 기업 기준으로는 통상 연간 IT 예산의 10~15%를 재해복구 관련 비용(구축 + 운영 + 테스트)으로 배정하는 것이 권장된다. 물론 이 비율도 BIA 결과에 따라 달라진다.
6. DR의 비용 대비 투자효과(ROI) — 어떻게 계산하는가
DR ROI는 일반 IT 프로젝트 ROI와 접근 방식이 다르다. “이걸 하면 얼마나 이익이 생기냐”가 아니라 “이걸 안 하면 얼마나 손해가 생기냐”로 계산해야 한다.
DR ROI 계산 공식
DR 투자효과(ROI) = (재해 예상 손실 × 재해 발생 확률 - DR 연간 비용) / DR 연간 비용 × 100%
좀 더 현실적으로 분해하면:
재해로 인한 예상 손실 = 다운타임 손실 + 데이터 손실 + 브랜드 피해 + 규제 과태료 + 복구 비용
IBM 2025년 데이터 유출 비용 보고서에 따르면 전 세계 평균 데이터 침해 비용은 444만 달러(약 60억 원) 수준이다. IT 다운타임의 경우 분당 최대 17,000달러(약 2,300만 원)의 손실이 발생할 수 있다고 알려져 있다. 1시간이면 10억 원을 넘는다.
구체적 사례로 따져보기
가상의 금융사 A사 기준:
- 핵심 결제 시스템 다운타임 시 분당 손실: 2,000만 원 (거래 중단 + 민원 대응)
- 예상 연간 재해 발생 확률 (RTO 초과 장애): 5%
- 연간 기대 손실: 2,000만 원/분 × 60분 × 5% = 연 6억 원 (1시간 장애 가정)
- DR 구축 연간 비용 (DRaaS 기준): 3억 원
이 경우 DR에 3억 원을 투자해서 기대 손실 6억 원을 막으면, ROI는 단순 계산으로 **100%**다. 여기에 규제 리스크(금융감독원 제재), 고객 이탈, 브랜드 손상까지 포함하면 실제 ROI는 이보다 훨씬 높아진다.
DR ROI를 높이는 전략적 판단
ROI를 극대화하려면 무작정 DR을 구축하는 게 아니라 등급별 차등 적용이 핵심이다.
- 1·2등급 시스템: 충분한 투자로 고가용성 확보 (ROI 높음)
- 3·4등급 시스템: 백업 + Cold Standby로 비용 최소화
- 전체 시스템에 일률적 투자는 비효율의 극단
7. BIA·RA 기반 DR 구축 — 실무 프레임워크
현장에서 BIA와 RA를 실제로 DR 프로젝트에 적용하는 흐름을 정리하면 다음과 같다.
Phase 1: 사전 분석 (2~4주)
- 전사 업무 프로세스 목록화
- 각 업무의 중요도 및 의존 IT 시스템 매핑
- 이해관계자 인터뷰 (현업 담당자, IT 운영팀, 경영진)
- BIA 설문지 및 워크숍 진행
Phase 2: BIA 수행 (4~6주)
- 업무별 MTD, RTO, RPO 도출
- 정량적 손실 산정 (시나리오별)
- 핵심 업무 프로세스 우선순위 결정
- 업무별 시스템 등급 부여 (1~4등급)
Phase 3: RA 수행 (3~4주)
- 위협 목록 작성 (화재, 침수, 랜섬웨어, 인재 등)
- 자산별 취약성 평가
- 위험 수준 매트릭스 작성
- 위험 허용 기준(Risk Appetite) 경영진 승인
Phase 4: DR 전략 수립 (3~4주)
- 시스템 등급별 DR 방식 결정 (A-A, Hot/Warm/Cold Standby)
- 구축 방식 결정 (자체 구축 vs DRaaS vs 공동/상호구축)
- 비용 대비 효과 분석 (ROI 시나리오 수립)
- 투자 우선순위 및 로드맵 작성
Phase 5: DR 구축 및 검증
- 설계 및 구축
- DR 모의훈련 (Failover Test): 연 1회 이상 필수. 구축했어도 훈련 안 하면 재해 시 제대로 작동한다는 보장이 없다
- 결과 보고 및 갱신 주기 설정
8. 최신 트렌드 — DR은 어디로 가고 있는가
클라우드 기반 DRaaS의 가속화
전통적 온프레미스 DR은 비용 효율 문제로 클라우드 기반 DRaaS로 빠르게 전환되고 있다. 평상시 VM을 비가동 상태로 유지하다 재해 시에만 가동하는 방식으로, 초기 CAPEX 부담 없이 유연한 DR을 구성할 수 있다.
Active-Active(A-A) 확대
과거에는 A-A 구조가 비용 문제로 최대 미션 크리티컬 시스템에만 적용됐다. 그러나 클라우드 인프라 비용이 하락하고 기술이 성숙하면서 A-A 적용 범위가 확대되고 있다. 정부도 이번 공공 DR 개편에서 주민등록시스템, 119구급스마트시스템 등 주요 시스템에 A-A 구조를 도입하기로 결정했다.
AI 기반 예측 복구
IBM 보고서에서도 언급됐듯, AI가 과거 장애 데이터를 분석해 잠재적 장애를 사전에 예측하고 복구 절차를 자동화하는 방향으로 진화하고 있다. ML 기반 실시간 인프라 모니터링이 전통적 임계값 알람을 대체하기 시작했다.
멀티클라우드 DR/HA 전략
단일 클라우드에 의존하는 DR은 클라우드 사업자 자체의 장애에 취약하다. 2025년 디지털서비스 서밋에서도 멀티클라우드 기반 분산 DR/HA 구조가 본격적으로 논의됐다. “장애는 피할 수 없지만, 중단은 피해야 한다”는 인식이 확산되면서 멀티클라우드 전략이 DR 설계의 표준이 되고 있다.
사이버 재해에 특화된 DR
랜섬웨어 공격이 전통적 물리적 재해와 다른 점은, DR 환경까지 감염시킬 수 있다는 것이다. 이에 따라 에어갭(Air Gap) 백업, 불변 스토리지(Immutable Storage) 등 사이버 재해에 특화된 DR 기법이 별도로 요구된다.
9. PM/컨설턴트를 위한 실전 인사이트
20년 넘게 IT 프로젝트를 해오면서 DR 구축 프로젝트에서 반복적으로 보이는 패턴이 있다. 이걸 공유하는 게 이 글을 쓰는 또 다른 이유다.
① “우리는 재해 안 난다”는 믿음이 가장 위험하다
DR 예산을 깎을 때 경영진이 가장 많이 하는 말이다. 국정자원 화재가 보여주듯, 재해는 배터리 하나에서 시작된다. RA를 통해 위험을 객관적 숫자로 보여주는 것이 PM의 역할이다.
② BIA 없는 DR은 과잉투자 아니면 과소투자
BIA 없이 DR을 구축하면 담당자 경험치와 직감으로 자원이 배분된다. 1등급 시스템에 3등급 수준의 DR을 붙이거나, 4등급 시스템에 A-A를 구현하는 낭비가 생긴다. BIA는 자원 배분의 유일한 합리적 근거다.
③ 구축보다 훈련이 더 중요하다
DR 시스템을 구축해놓고 Failover 테스트를 한 번도 안 한 기관이 생각보다 많다. 구성도는 완벽한데 실제 재해 시 복구 시간이 RTO를 10배 초과하는 케이스를 직접 봤다. DR은 구축이 완성이 아니라, 정기 훈련이 완성이다.
④ ROI 보고서가 투자 승인의 열쇠다
경영진은 기술 아키텍처에 관심 없다. “이 투자로 얼마를 지킬 수 있나”에 관심 있다. BIA 기반 손실 시나리오와 ROI 수치를 담은 보고서가 없으면 DR 예산은 매년 1순위 삭감 대상이 된다.
⑤ DRaaS 전환을 검토하라
온프레미스 DR을 이미 운영 중이라면, 이 비용과 DRaaS 월정액을 비교해볼 것을 권한다. 클라우드 전환 초기에는 DRaaS가 비싸 보이지만, 장비 노후화 교체 주기와 운영 인력까지 포함하면 TCO(총소유비용) 기준으로는 DRaaS가 유리한 경우가 많다.
10. 결론 — DR은 보험료가 아니라 사업 지속성의 가격이다
재해복구(DR)에 대한 인식 전환이 필요하다. “언제 올지 모를 재해에 대비하는 보험”이라는 프레임에서, “비즈니스가 지속될 수 있는 최소한의 구조적 조건”으로 바라봐야 한다.
대전 국정자원 화재는 30억짜리 DR 예산을 61% 삭감한 결정이 어떤 결과로 이어지는지를 생생하게 보여줬다. 그 대가로 정부는 3,434억 원이 넘는 DR 대규모 투자를 강제로 집행해야 했다. 예방 투자 30억 원을 아끼려다 사후 복구에 100배가 넘는 돈을 써야 했다.
BIA와 RA는 이 계산을 사전에 가능하게 해주는 도구다. “우리 사업에서 가장 치명적인 중단은 무엇인가” (BIA), “그 중단이 얼마나 현실적인가” (RA), “막으려면 얼마가 필요한가” (DR 설계), “그게 충분히 합리적인 투자인가” (ROI 분석).
이 네 가지 질문에 답할 수 있으면, DR 투자 논쟁은 감정 싸움이 아니라 데이터 기반 결정이 된다.
지금 여러분의 조직은 그 네 가지 질문에 답할 수 있는가.
부록: BIA·RA·DR 핵심 용어 정리
| 용어 | 풀이 | 설명 |
|---|---|---|
| BIA | Business Impact Analysis | 업무영향분석. 재해 시 비즈니스 손실을 정량화 |
| RA | Risk Assessment | 위험평가. 위협 발생 가능성과 취약성 평가 |
| DR | Disaster Recovery | 재해복구. 재해 후 IT 시스템 및 업무 복구 |
| BCP | Business Continuity Planning | 업무연속성계획. DR보다 넓은 개념 |
| RTO | Recovery Time Objective | 목표 복구 시간 |
| RPO | Recovery Point Objective | 목표 복구 시점 (데이터 손실 허용 한계) |
| MTD | Maximum Tolerable Downtime | 최대 허용 중단 시간 |
| A-A | Active-Active | 운영-DR 양쪽이 동시에 실제 서비스 처리 |
| DRaaS | DR as a Service | 클라우드 기반 재해복구 서비스 |
| SPOF | Single Point of Failure | 단일 장애 지점 |
| Failover | – | 장애 시 DR 시스템으로 전환하는 것 |
| Failback | – | 복구 후 운영 시스템으로 복귀하는 것 |
이 글이 도움이 되셨다면, 재해복구 구축을 검토 중인 동료에게 공유해주세요. 실무에서 BIA, RA, DR 관련 고민이 있으시면 댓글로 남겨주세요.