백업이 있는 것과 복구되는 것은 다르다

국가정보자원관리원 대전본원 화재가 작년 9월 26일이었으니 딱 1년이 지났습니다. 709개 시스템이 멈췄고 완전 복구까지 95일이 걸렸습니다.

감사 결과와 후속 보도를 보면 기술 문제라기보다 구조와 관행의 문제였습니다. 26일차에 클라우드 장애를 다루면서 "검증하지 않은 이중화는 이중화가 아니다"라고 썼는데, 이번 사건은 그 얘기의 가장 구체적인 사례라서 정리해둘 만하다고 봤습니다.

숫자가 말해주는 것

화재 당시 국정자원이 관리하던 정보시스템 709개 중 재해복구시스템(DR)을 갖춘 건 54개, 7.6%였습니다.

그마저도 복구 목표가 서버 기반은 3~24시간, 스토리지 기반은 21일 이내였습니다. 목표 자체가 이미 "며칠"이었다는 뜻이죠.

실제 결과는 더 나빴습니다. DR로 살려낸 건 7개였고, 평균 복구에 10.8일이 걸렸습니다. 2022년 판교 데이터센터 화재 직후 국정자원은 브리핑에서 "3시간 복구"를 언급했는데, 선언과 실측의 거리가 이만큼이었습니다.

그리고 가장 눈에 띄는 대목. 2021년 이후 화재 전까지 DR을 실제로 가동해본 시스템은 둘뿐이었습니다. 기획재정부 예산회계시스템과 행정안전부 주민등록시스템.

백업과 DR은 다른 개념이다

여기서 개념 정리가 필요합니다. 두 단어가 자주 섞여 쓰이는데 목적이 다릅니다.

백업은 데이터를 복사해 보관하는 것입니다. 목표는 "잃지 않는 것"이고요. 백업이 있으면 데이터는 살릴 수 있지만, 그걸 돌릴 서버와 네트워크와 설정은 별도 문제입니다. 복원에 시간이 걸립니다.

DR은 대체 시스템을 미리 준비해두는 것입니다. 목표는 "멈추지 않는 것"이고요. 장애가 나면 대기 중인 쪽이 즉시 넘겨받습니다.

공무원 업무용 클라우드였던 G드라이브가 백업 없이 소실돼 8년치 자료가 사라진 것은 백업 부재의 문제였고, 709개 중 대부분이 며칠씩 멈춘 것은 DR 부재의 문제였습니다. 성격이 다른 두 실패가 겹친 셈입니다.

지표로는 RTO(얼마나 빨리 복구할 것인가)와 RPO(데이터를 어디까지 잃어도 되는가)로 표현됩니다. 백업 주기가 24시간이면 RPO는 최악의 경우 24시간이 됩니다.

백업이 같은 방에 있었다

가장 기본적인 원칙이 깨진 지점이 있습니다. 백업 서버가 본 시스템과 같은 전산실에 있었다는 것.

3-2-1 규칙은 백업의 오래된 기본입니다. 사본 3개, 서로 다른 매체 2종, 그중 1개는 원격지에.

원격지 조항이 있는 이유가 정확히 이 상황 때문입니다. 같은 건물에 있으면 화재나 침수 같은 물리적 사고에 함께 사라지니까요. 복사본을 여러 개 만들어도 한 방에 두면 사본 1개와 다를 게 없습니다.

여기에 요즘은 하나가 더 붙습니다. 변경 불가(immutable) 보관. 랜섬웨어가 백업부터 암호화하는 패턴이 일반화돼서, 일정 기간 덮어쓸 수 없는 사본을 두는 게 권장됩니다.

등급 산정의 함정

또 하나 짚을 만한 대목이 있습니다. 국민 생활에 영향이 큰 시스템인데도 사용자 수가 적다는 이유로 등급이 낮게 책정돼 복구가 지연된 사례가 있었습니다.

중요도를 트래픽이나 사용자 수로 대리 측정하면 이런 일이 생깁니다. 실제 중요도는 "멈추면 무엇이 불가능해지는가"인데, 측정하기 쉬운 지표를 쓰다 보니 어긋난 거죠. 2일차 토큰맥싱 글에서 다룬 굿하트의 법칙이 여기서도 나옵니다.

서비스를 운영하는 입장에서 시스템 등급을 매길 때, 호출량이 적지만 멈추면 전체가 막히는 기능이 있는지 살펴볼 만합니다. 인증 서비스가 대표적이고요.

대응으로 나온 것들

정부는 화재 이후 몇 가지를 의무화했습니다. 연 1회 이상 실전형 재해복구 훈련, 모든 정보시스템의 주기적 백업과 원격지 소산, 주요 시스템에 액티브-액티브 DR 우선 도입.

액티브-액티브는 두 개 이상 시스템을 동시에 가동해 한쪽이 죽어도 다른 쪽이 자동으로 이어받는 방식입니다. 대기만 하는 스탠바이 방식보다 비싸지만 전환이 확실합니다. 평소에 쓰지 않는 설비는 정작 필요할 때 작동하지 않는다는 걸 확인한 결과로 보입니다.

실전형 훈련 의무화가 개인적으로 가장 중요한 조항이라고 봅니다. DR 구성은 문서로 존재할 수 있지만, 실제로 트래픽을 넘겨본 적이 없으면 그건 검증되지 않은 가정일 뿐이니까요.

정리

이 사건에서 배울 점을 한 줄로 줄이면 "복구해본 적 없는 복구 계획은 계획이 아니다"가 될 것 같습니다.

실무에서 점검할 건 셋입니다. 백업이 본 시스템과 물리적으로 분리돼 있는가, 복원을 실제로 해본 적이 있는가, 선언한 RTO가 측정된 값인가. 세 번째가 특히 어려운데, 측정하지 않은 RTO는 대부분 희망 사항입니다.