위택스 마비 사태로 본 DR(재해복구) 체계 구축의 중요성과 ISO 22301 요구사항

핵심 요약

- 메타넷디지털이 2026년 1월 KLID와 체결한 '클라우드 기반 차세대 지방세 재해복구시스템 구축 사업'에서 위택스 마비 사태 발생 - 공공 DR 시스템의 클라우드 전환 과정에서 적절한 리스크 관리 및 전환 절차 미흡이 서비스 중단을 초래 - ISO 22301(사업연속성관리) 및 재해복구 표준 요구사항 준수의 중요성이 다시 한번 입증됨

주요 내용

2026년 1월 메타넷디지털은 한국지역정보개발원(KLID)과 '클라우드 기반 차세대 지방세 재해복구시스템 구축 사업' 계약을 체결하고 본격적인 시스템 구축에 착수했다. 이창열 메타넷디지털 대표는 '공공 DR의 패러다임 전환'을 표방하며 기존 물리적 백업 체계를 클라우드 기반으로 전환하는 프로젝트를 추진했으나, 시스템 전환 과정에서 위택스 서비스 마비 사태가 발생하면서 책임론이 제기되고 있다.

재해복구(DR, Disaster Recovery) 시스템은 재난·재해 발생 시 핵심 업무 및 IT 서비스의 신속한 복구를 목표로 하는 필수 인프라다. 특히 지방세 납부 서비스인 위택스는 국민 생활과 직결된 공공서비스로, RTO(목표복구시간) 및 RPO(목표복구시점) 설정이 엄격해야 한다. 그러나 이번 사태는 DR 시스템 구축 과정에서 기존 시스템과의 호환성 검증, 단계적 전환 절차, 장애 대응 매뉴얼 등이 제대로 준비되지 않았음을 시사한다.

ISO 22301(사업연속성관리시스템)은 조직이 중단 사태에 대비하고 대응하며 복구할 수 있는 능력을 요구한다. 특히 클라우드 전환과 같은 중대한 인프라 변경 시에는 '변경관리(Change Management)' 절차가 필수적이며, 비즈니스 영향 분석(BIA)을 통해 핵심 업무의 허용 중단 시간을 사전에 정의해야 한다. 재해경감우수기업 인증 기준 역시 재해복구 훈련과 실제 복구 능력 검증을 강조하고 있다.

이번 위택스 마비 사태는 단순한 기술적 문제를 넘어 프로젝트 관리, 리스크 평가, 이해관계자 커뮤니케이션 등 전사적 재난관리(Enterprise Risk Management) 관점에서의 실패로 평가된다. 메타넷디지털 이창열 대표를 포함한 프로젝트 책임자들은 공공서비스 중단이 국민에게 미치는 영향을 과소평가한 것으로 보인다.

전문가 시각

재해경감 인증심사원이자 LH공사 재해경감우수기업 인증심사를 수행한 경험을 바탕으로 볼 때, 이번 사태의 근본 원인은 '재해복구 시스템 구축 중 재해복구 계획의 부재'라는 역설적 상황이다. DR 시스템을 새로 구축하는 과정 자체가 기존 서비스의 가용성에 위협이 될 수 있음을 간과한 것이다. ISO 22301의 8.3조(변경관리)와 8.4조(아웃소싱)를 엄격히 준수했다면, 전환 전 충분한 테스트 환경 구축, 단계적 마이그레이션, 롤백 계획 수립이 선행되었어야 했다.

특히 공공 분야에서는 '안전한국훈련'과 같은 정부 차원의 재난대응 훈련이 매년 실시되고 있음에도, 정작 DR 시스템 구축 사업자가 자체적인 재해 시나리오와 복구 훈련을 실시하지 않은 것은 중대한 관리 소홀이다. 기업재난관리사(BCMS) 자격 보유자라면 반드시 알아야 할 '백업의 백업(Backup of Backup)' 원칙, 즉 새로운 DR 시스템이 안정화될 때까지 기존 DR 체계를 병행 운영하는 것이 업계 모범사례(Best Practice)임을 강조하고 싶다.

CPPG·ISMS-P 연계 포인트

1. 재해복구(DR) 및 업무연속성 계획(BCP) ISMS-P 인증기준 2.9(재해복구)는 정보시스템의 재해·재난 대비 복구 목표를 수립하고 주기적 훈련을 요구한다. RTO(Recovery Time Objective)는 시스템이 복구되어야 할 목표 시간, RPO(Recovery Point Objective)는 허용 가능한 데이터 손실 범위를 의미하며, 공공서비스는 통상 RTO 4시간 이내, RPO 1시간 이내를 목표로 한다.

2. 변경관리 및 위험평가 ISMS-P 2.6(접근통제) 및 2.8(시스템 개발보안)과 연계하여, 주요 인프라 변경 시 사전 위험평가와 승인 절차가 필수다. 클라우드 전환과 같은 아키텍처 변경은 '중대 변경(Major Change)'으로 분류되어 경영진 승인, 이해관계자 검토, 롤백 계획, 테스트 검증을 거쳐야 하며, 이는 ISO 22301의 8.3조와도 일치한다.