국가정보자원관리원 화재, 개발자의 눈으로 본 '이중화' 실패의 교훈

 

https://www.youtube.com/watch?v=mmplgzgBD68

또다시 울린 데이터센터 화재 경보

지난 저녁, 동료 개발자들과의 단톡방이 갑자기 뜨거워졌다. '국가정보자원관리원 화재로 정부24, 모바일 신분증 서비스 장애.' 뉴스를 보자마자 2022년 가을, 대한민국을 멈춰 세웠던 판교 데이터센터 화재의 악몽이 떠올랐다.

그리고 개발자라면 누구나 반사적으로 같은 질문을 던졌을 것이다.

"어? 이중화(Redundancy) 구성 안 되어 있었나? 왜 서비스가 멈추지?"

이번 사태는 단순한 화재 사건을 넘어, 대한민국의 디지털 인프라가 얼마나 견고한지, 그리고 우리가 과거의 실패로부터 얼마나 배웠는지를 보여주는 뼈아픈 바로미터다. 개발자의 입장에서 이번 사건을 기술적인 관점으로 파헤쳐 보고 싶어졌다.

국가정보자원관리원(NIRS), 무엇을 하는 곳인가?

먼저, 이곳이 얼마나 중요한 곳인지 알아야 한다. 국가정보자원관리원(NIRS)은 대전과 광주, 대구에 센터를 둔, 대한민국 정부의 모든 정보 시스템을 통합 관리하는 '디지털 정부의 심장부'다. 우리가 일상적으로 사용하는 거의 모든 대국민 서비스가 이곳에서 운영된다.

• 정부24: 주민등록등본 등 각종 민원서류 발급
• 홈택스: 연말정산, 세금 신고
• 모바일 신분증: 실물 신분증을 대체하는 디지털 신분증
• 나라장터: 국가 공공 입찰 시스템

이 외에도 1,600여 개의 중앙부처 정보 시스템이 이곳에 있다. 이런 곳에 불이 났다는 것은, 국가의 디지털 행정이 사실상 마비될 수 있다는 의미다.

개발자의 근본적인 의문: "이중화는 어디에?"

이번 사태의 핵심은 '이중화의 실패'다. 개발자에게 '이중화'는 시스템 설계의 기본 중의 기본이다. 서버 한 대가 죽어도 서비스는 계속되어야 하니까. 이중화는 크게 두 가지 레벨로 나눌 수 있다.

• 고가용성 (HA, High Availability): 하나의 데이터센터 내에서 여러 대의 서버가 액티브-스탠바이 또는 액티브-액티브 형태로 구성되어, 일부 서버에 장애가 발생해도 서비스 중단 없이 운영되는 것을 말한다. 로드밸런서 뒤에 여러 웹 서버를 두는 것이 가장 기본적인 예다.
• 재해 복구 (DR, Disaster Recovery): 이번 사태의 핵심이다. 지진, 화재 등으로 데이터센터 하나가 통째로 마비되는 상황에 대비하는 것이다. 물리적으로 멀리 떨어진 곳에 백업 데이터센터를 두고, 메인 센터에 문제가 생겼을 때 백업 센터로 시스템 전체를 전환(Failover)하는 것을 의미한다.

왜 백업 센터는 작동하지 않았나?

보도에 따르면, 국정자원관리원은 대전 본원 외에 광주에도 백업 센터를 운영하고 있었다. 그런데 왜 정부24와 같은 핵심 서비스들은 몇 시간 동안이나 멈춰 섰을까? 여기서 우리는 '무늬만 DR'이었을 가능성을 엿볼 수 있다.

1. Active-Standby의 한계: 가장 가능성이 높은 시나리오다. 대전(Active)과 광주(Standby) 센터가 실시간으로 똑같이 운영되는 'Active-Active' 방식이 아니었을 확률이 높다. Active-Standby 구성에서는 평소 Standby 센터는 대기만 하다가, 재난 시 수동 또는 반자동으로 서비스를 전환한다. 이 전환 과정은 짧게는 수십 분에서 길게는 몇 시간이 걸리며, 그동안 서비스 중단은 불가피하다. 실시간 동기화 방식인 Active-Active는 구축 및 운영 비용이 기하급수적으로 비싸기 때문에, 예산 문제로 타협했을 가능성이 크다.
2. 미흡한 재해 복구 훈련: DR 시스템은 '만들어두면 끝'이 아니다. 실제 재난 상황을 가정해 주기적으로 백업 센터로 전환하는 훈련을 하지 않으면, 막상 진짜 재난이 닥쳤을 때 시스템은 제대로 작동하지 않는다. "전환 과정에서 장애가 날까 봐", "서비스를 중단할 수 없어서" 등의 이유로 훈련을 소홀히 했다면, DR 시스템은 그저 비싼 저장 장치에 불과했을 것이다.
3. 드러나지 않은 단일 장애점(SPOF): 서버와 스토리지를 이중화했더라도, 두 센터가 공유하는 특정 네트워크 회선이나 인증 시스템, DNS 설정 등에 단일 장애점(Single Point of Failure)이 존재했다면 무용지물이다. 이번 화재가 UPS(무정전 전원 장치)실에서 시작된 것처럼, 전원 시스템의 이중화 설계 미흡도 원인일 수 있다.

2년 전 카카오 사태에서 배우지 못한 교훈

2022년 카카오 데이터센터 화재 이후, 정부는 민간 기업들에게 강력한 데이터센터 이중화를 요구했다. 하지만 정작 국가의 심장부인 자신들의 시스템은 그때와 똑같은 문제를 되풀이했다. 이는 기술의 문제가 아니라, 안정성에 대한 투자와 의지의 문제다.

개발자로서 우리는 종종 새로운 기능 개발에만 매몰되곤 한다. 하지만 이번 사태는 우리가 만든 서비스가 사용자의 일상에 얼마나 깊숙이 관여하는지, 그리고 그 서비스의 안정성과 복원력(Resilience)을 확보하는 것이 얼마나 중요한지를 다시 한번 일깨워준다.

단순히 불을 끄고 서버를 복구하는 것에서 끝나선 안 된다. 이번 화재가 우리 국가 디지털 인프라의 취약점을 투명하게 드러내고, '소 잃고 외양간이라도 제대로 고치는' 계기가 되기를 간절히 바랄 뿐이다. 이번만큼은 보여주기식 대책이 아닌, 실제 작동하는 견고한 시스템을 위한 근본적인 투자와 변화가 이루어지길 기대한다.

 

 

#국가정보자원관리원 #데이터센터 #화재 #서버장애 #이중화 #재해복구 #DR #개발자 #SRE