2025년 국정자원 화재가 남긴 교훈: 공공기관이 지금부터 해야 할 것은

모든 사고를 예방할 수 없지만, 영향은 최소화할 수 있다

2025년 9월, 국가정보자원관리원에서 발생한 화재로 647개 정부 시스템이 동시에 중단되었습니다.(647대에서 더 증가되었다고 함) 그러나 이 사건에서 우리가 주목해야 할 것은 ‘화재 발생’ 자체가 아닙니다. 화재, 정전, 설비 장애 등 예기치 못한 사고는 언제든 발생할 수 있습니다. 정보시스템은 이 외에도 장애에 대한 정말 많은 위협요소가 있어서 모든 사고를 예방하는 것은 현실적으로 불가능에 가깝습니다.

그러니 가장 중요한 것은 알려진 위협요인을 철저히 진단하여 정보시스템의 취약점을 사전에 제거하고 예방하는 것이며, 그럼에도 사고가 발생할 경우에는 서비스의 복구 속도와 정상화 능력을 얼마나 빠르고 안정적으로 확보하느냐가 핵심입니다.

현재 정보시스템 장애는 재난으로 등록됨에 따라 정보시스템 운영에도 예방·대비·대응·복구의 재난관리 프레임워크 적용이 필수이며 정부도 이를 요구하고 있습니다.

이번 글에서는 2022년부터 2024년까지 수립된 법령과 지침을 바탕으로, 공공기관이 정보시스템의 서비스의 연속성(Business Continuity)관점에서 지금 당장 무엇을 해야 하는지 실무적으로 정리해보겠습니다. 특히 행안부에서 각 공공기관에 배포한 범정부 정보시스템 예방점검체계를 기반으로 설명하겠습니다.

1. 법령이 요구하는 것 : 사후 대응이 아닌 사전 관리 체계

1). 법적 지위의 변화: 기술적 문제에서 국가 재난으로

2022년 10월 SK C&C 판교 데이터센터 화재로 카카오톡이 나흘간 먹통이 된 사건을 기억하시나요? 이 사건 이후 정부는 정보시스템 장애에 대한 근본적인 관점 전환을 시도했습니다.

가장 큰 변화는 2024년 7월 17일부터 시행된 「재난 및 안전관리 기본법 시행령」 개정입니다. 이 개정으로 “행정·공공 정보시스템 장애로 인해 발생하는 대규모 피해”가 태풍, 지진과 같은 사회재난의 범주에 포함되었습니다. 다시 말해, 정보시스템 장애는 더 이상 단순한 ‘IT 장애’가 아니라 국가가 관리해야 할 재난이 된 것입니다.

이에 따라 재난관리책임기관의 장은 재난 및 안전관리 기본법 제20조에 따라 재난상황을 즉시 행정안전부장관에게 보고해야 하며, 제25조의4에 따라 재난 예방조치를 의무적으로 수행해야 합니다.

<정보시스템 장애관리 관련 주요 법령 및 지침 체계>

구분	법령/지침	핵심 내용
법적 근거	재난 및 안전관리 기본법 (2024.7.17 시행령 개정)	– 정보시스템 장애로 인한 대규모 피해를 사회재난으로 분류- 재난관리책임기관의 장에게 재난상황 보고 및 예방조치 의무 부여
법적 근거	전자정부법 제56조의2	– 정보시스템 장애 예방·대응을 위한 방안 마련 의무- 장애관리계획 수립 및 제출 의무
실행 지침	디지털행정서비스 국민신뢰 제고 대책(2024.1.31)	– 1·2등급 시스템 상시 모니터링 자동화- 장비 이중화 및 재해복구시스템 구축- 주기적 실전형 전환훈련 실시
	행정기관 및 공공기관 정보자원 통합기준(2023.12.27 개정)	– 1·2등급 시스템: 운영시설 안정성 기준 “상” 필수- 통신선 이중화 필수- 업무연속성계획(BCP) 수립 및 주기적 모의훈련 필수
	범정부 정보시스템 예방점검체계	– 3개 분야(일상·특별·구조진단) 8개 점검항목- 1등급: 8개 항목 의무, 2등급: 7개 항목 의무

2). 정부 대책의 핵심: 사후 대응이 아닌 사전 관리

2024년 1월 31일, 정부는 국무총리 주재 국정현안관계장관회의에서「디지털행정서비스 국민신뢰 제고 대책」을 발표했습니다. 이 대책은 판교 데이터센터 화재의 교훈을 바탕으로, 정보시스템 장애를 예방-대비-대응-복구의 전주기 관점에서 관리하겠다는 정부의 의지를 담고 있습니다.

예방 단계

1·2등급 정보시스템에 대한 상시 모니터링 자동화 체계 구축
장애징후 알림기준 하향 조정으로 골든타임 확보

대비 단계

네트워크, 방화벽 등 모든 장비에 대한 이중화 진행
재해복구시스템(DR) 구축기준 마련

대응 단계

디지털안전상황실 신설 및 운영
실시간 장애 전파 체계 구축

복구 단계

재해복구시스템을 활용한 주기적 실전형 전환훈련 실시
업무연속성계획(BCP) 수립 의무화

특히 행정안전부가 2023년 12월 27일 개정(시행일)한 「행정기관 및 공공기관 정보자원 통합기준」에서는 1·2등급 정보시스템에 대해 운영시설 안정성 기준 “상” 등급을 필수로 규정했습니다. 이는 통신선의 이중화, 업무연속성계획(BCP) 수립 및 주기적 모의훈련을 반드시 수행해야 함을 의미합니다.

3). 재난관리 프레임워크로 본 정보시스템 관리

전통적인 재난관리는 예방-대비-대응-복구의 4단계로 구성되어있는데, 행정안전부가 제시하고 있는 「범정부 정보시스템 예방점검체계」는 이 프레임워크를 정보시스템에 그대로 적용했다고 할 수 있습니다.

<재난관리 프레임워크로 본 정보시스템 관리>

출처: 행안부 「범정부 정보시스템 예방점검체계」기반 작성자 해석/정리

2. 등급별 의무사항: 행정안전부가 제시한 점검 체계

1). 범정부 정보시스템 예방점검체계란?

행정안전부가 제시한 「범정부 정보시스템 예방점검체계」는 정보시스템의 재난관리를 체계화한 지침이며, 이 체계는 1·2등급 정보시스템을 운영하는 모든 공공기관이 반드시 따라야 하는 점검 기준을 담고 있습니다.

행정안전부가 제시한 예방점검체계는 일상점검, 특별점검, 구조진단의 3개 분야로 구성되어 있습니다.

<1등급 시스템 필수 이행사항>

분야	주기	항목	서비스 연속성 관점의 의미
일상점검	일	① 상태점검	CPU/메모리/디스크 이상 징후 조기 감지 → 장애 예방
	일	② 서비스점검	실제 사용자 관점 서비스 가용성 확인
	월	③ 유효성점검	인증서/도메인 만료로 인한 서비스 중단 예방
특별점검	년	④ 오프라인점검	시스템 재기동 절차 검증 → 복구 시간 단축
	년	⑤ 이중화점검	Fail-Over 실제 동작 검증 → 무중단 서비스 보장
	년	⑥ 성능점검	부하 상황 대응력 검증 → 서비스 안정성 확보
	특정기간	⑦ 업무집중기간점검	피크 타임 서비스 지연/중단 예방
구조진단	3년	⑧ 구조진단 및 개선	시스템 전반의 서비스 연속성 취약점 도출 및 개선

2등급 시스템은 구조진단(⑧)을 제외한 7개 항목 의무 이행

각 영역에 대해 적용 대상 및 의무화 수준을 정의하고 있는데,

1등급 시스템: 8개 항목 의무 이행
2등급 시스템: 7개 항목 의무 이행 (구조진단 제외)
3·4등급 시스템: 권고 사항

그렇다면 1·2등급 시스템은 어떻게 구분될까요? 전자정부법 시행령과 행정기관 및 공공기관 정보시스템 구축·운영 지침에 따르면, 정보시스템의 중요도를 평가하여 등급을 부여합니다. 1등급은 국가 핵심 업무를 수행하거나 대규모 국민 대상 서비스를 제공하는 시스템으로, 장애 발생 시 국가 및 사회에 미치는 영향이 매우 큰 시스템입니다.

2). 3개 분야 8개 점검 항목 상세 분석

3개 분야 8개 점검 항목에 대해 좀더 상세히 살펴보겠습니다. 먼저 ‘ 일상점검’은 매일/매월 수행해야 하는 기본 점검을 의미하며, 이중 상태점검과 서비스 점검은 매일 점검하도록 되어있습니다.

일상점검: 매일/매월 수행하는 기본 점검

주기	항목	내용	재난관리 관점
일	① 상태점검	CPU/메모리/디스크 상태 등 이상 유무 점검	예방: 자원 고갈로 인한 서비스 중단 사전 차단
일	② 서비스점검	메인 화면 접속여부 및 접속시간 점검	예방: 사용자 관점 서비스 가용성 실시간 확인
월	③ 유효성점검	인증서 유효기간, 도메인 종료일 등 점검	예방: 만료로 인한 예기치 않은 서비스 중단 방지

상태점검의 세부 영역

이 중 상태점검은 9개 영역 115개 세부 항목으로 구성되어있는데, 점검 대상별로 서비스 연속성 관점에서 세부적인 항목들을 디테일하게 정의하고 있습니다.

서버 영역: CPU 사용률, 메모리 사용률, 파일시스템 사용량, Disk I/O, 클러스터 상태, NW 링크 상태, 시스템 로그 등
WEB 영역 : 프로세스 상태, 파일시스템 점검, 서비스 포트 상태, 로그 점검 등
WAS 영역: Thread Pool 상태, Heap Memory 사용률, DB Connection Pool, Dump 파일 점검 등
DBMS 영역 : 테이블스페이스 사용률, 프로세스 상태, 백업 상태, 트랜잭션 로그 등
네트워크 영역: 자원사용률, HW 상태, 서비스 상태, 로그 점검 등
보안장비 영역: 자원사용률, 파일시스템, 트래픽, 세션 상태, 이중화 등
클라우드 영역: 가상화SW 상태, 컨테이너 Pod 상태, 이벤트 로그 등
스토리지 영역: 로그, Path 이중화 등
백업 영역: 수행 결과, 물리적 상태, 용량, SW 상태 등

특별점검: 연 1회 이상 수행하는 심화 점검

특별점검은 연 1회 이상 수행하는 심화 점검으로 오프라인 점검, 이중화 점검, 성능점검을 포함하고 있는데 장애시나리오에 기반해서 장애상황에 시스템이 실제로 대응이 가능한가를 테스트하도록 되어있습니다. 특별점검은 별도의 서비스 다운시간을 계획하고 실시하며, 철저한 백업복구 시나리오에 따라서 시행하게 됩니다. (가능하다면, 시스템 관리자, 서비스 담당자, AP담당자, 벤더 엔지니어들이 모두 참여해서 시나리오에 따라 실제 동작하는지, 문제가 있다면 문제원인을 파악하는데까지 진행합니다. 아마도 대규모 작업이 되겠지요.)

주기	항목	내용	재난관리 관점
년	④ 오프라인점검	의도적 시스템 정지·재가동으로 이상유무 점검	대비: 실제 복구 절차 검증 및 복구시간 측정
년	⑤ 이중화점검	이중화된 장비·부품의 정상 동작 여부 점검	대비: Fail-Over 시나리오별 실제 동작 검증
년	⑥ 성능점검	부하 테스트 등으로 설정값 최적화 등 성능저하 요인 점검	예방: 부하 상황 대응력 검증 및 임계치 조정
특정기간	⑦ 업무집중기간점검	서비스 집중 기간 중 사용량 증가에 따른 서비스 지연·중지 대비 사전 점검 및 집중 모니터링	예방: 피크 타임 서비스 안정성 보장

실제 이중화점검이 중요한 이유는

이번 국정자원 화재 사례에서 확인된 것처럼, 이중화가 구축되어 있어도 물리적으로 같은 공간에 있다면 의미가 없습니다. 행정안전부 예방점검체계의 이중화점검은 단순히 이중화 구성 여부만 확인하는 것이 아니라, 모든 장애가능성에 대한 Single Point Of Failure를 검증합니다.

시스템을 구축할 때 예산의 문제로 모든 SPOF를 제거한 완벽한 이중화를 구현할 수는 없습니다. 그러나 적어도 우리가 구현한 이중화 영역에 대해서는 이중화가 제대로 동작하는가는 점검을 해야겠죠.

이중화 점검은 “시스템에 구현된 이중화가 제대로 동작하는가” 라는 관점으로 진행됩니다.

Active-Standby 서버가 물리적으로 다른 존(Zone)에 위치하는가?
전원이 서로 다른 UPS에서 공급되는가? (데이터센터 관점에서는 분전반 이중화까지도 점검)
네트워크 경로가 완전히 분리되어 있는가?
Fail-Over가 실제로 자동으로 작동하는가?
Fail-Over 시 서비스 중단 시간이 목표(RTO) 내인가?
백업 데이터가 물리적으로 분리된 장소에 있는가?

구조진단: 3년마다 수행하는 전체 시스템 진단

시스템 구조진단은 가이드라인에 따르면 3년만다 수행하도록 되어있고, 구축된 정보시스템의 구조(아키텍처) 관점의 진단과 개선점을 도출하는 것을 목적으로 하고있습니다. 시스템 전반의 서비스 연속성의 취약점 측면의 종합적인 진단(Risk Findings)에 해당하며, 여기에서 식별된 위험요소를 기반으로 단기/중기/장기 개선계획을 수립해서 단계적으로 Risk를 Hedge해나가는 것을 목적으로 합니다.

주기	항목	내용	재난관리 관점
3년	⑧ 구조진단 및 개선	하드웨어, 시스템SW, 응용프로그램, 데이터베이스, 네트워크 등 전체 정보시스템 구조에 대한 진단 및 개선점 도출	예방: 시스템 전반의 서비스 연속성 취약점 종합 진단 및 장기 개선 계획 수립

행정안전부 예방점검체계에서 제시한 구조진단은 다음과 같이 구성되어있습니다.

서버 공통 진단
- OS 환경구성 정보 (커널 파라미터, 네트워크 설정, 디스크 마운트, 보안 설정)
- 자원 사용률 및 추이 분석 (CPU, 메모리, 파일시스템, I/O)
- 장애 발생 시 서비스 영향도 분석
- 다중화 진단 (전원, 회선, NIC, 부하분산)
- 시스템 로그 진단
- 인프라 구성 환경 (노후화, 시스템 구성 적정성, 서버 이중화 여부)
WEB/WAS 공통 진단
- 자원 사용률 (세션, Heap 메모리, Thread Pool, DB Connection Pool)
- 다중화 진단 (WEB/WAS, WAS/DB 간 다중화)
- 부하분산 및 장애 발생 시 Fail-Over 설계
- 시스템 로그 진단 (access, error 로그, output, GC로그)
- WEB/WAS 파라미터 진단
- 덤프 분석 (thread, Heap 덤프)
DBMS 공통 진단
- 자원사용률 (세션, 메모리, DB 파일시스템)
- 다중화 진단 (주요 파일, 아카이브 로그)
- 인스턴스 진단 (메모리 할당, SQL Parse 효율, PGA 할당, Load Profile, Literal SQL)
- 데이터베이스 진단 (Log Switch, 주요 파일 구성, 백업정책)
- 구성 환경 및 효율성 진단 (Data Block I/O, 대기 이벤트, 세그먼트 아키텍처)
- 파라미터 진단 (프로세스, 세션수, 공유 메모리, 캐시)
- SQL문 성능 진단 (응답시간, CPU/메모리 이용률, Full Scan, 비효율 SQL)
- 테이블/인덱스 아키텍처 진단 및 튜닝
네트워크/보안 공통 진단
- 다중화 진단 (전원, 회선, NIC, 부하분산)
- 부하분산, Fail-Over
- 장애 발생 시 서비스 영향도
- 네트워크 구간의 최대 트래픽 적정 여부
- 망분리 정책 준수 여부
- 보안정책 및 망구성 정합성
스토리지/백업 공통 진단
- 스토리지 용량 진단 (향후 3년 동안의 데이터 증가 시 볼륨 적정성)
- OS, 파일시스템, DB 백업 효율성 및 누락 여부
AP(애플리케이션) 진단
- AP 성능정보 (동시사용자, TPS, 응답시간, 성공률)
- 점검 범위별 성능점검 (통합, 임계, 일시 접속, 단위, 가용성)
- 과부하 대비 시스템 최대 처리 성능 및 적정 용량
- 과부하 시 서비스 영향도
- 사용자 접속 방식, 화면 및 외부 연계시스템 연동 방식
- 컨텐츠 구성 및 용량에 따른 트래픽 사용량
외부연계 진단
- 연계 솔루션 처리량 및 처리 속도
- 연계 서버 및 솔루션의 다중화 및 부하분산
- 연계 방식 진단 (프로토콜, 연계 규약, 데이터 처리 횟수)

지금까지는정부에서 가이드하는 관리요소를 설명드렸는데, 어떤 생각이 드시나요?

‘다른 기관은 다 이렇게 하고있나? 우리기관만 못하고있는건가?’ 아니면, 기술을 조금이라도 아시는 분들이라면 ‘아니 이걸 어떻게 다하라고? ‘ 아마도 이런 생각들이 드실겁니다.

물론 이론적으로 당연히 이렇게 해야하는것이 맞습니다만, 현실적으로는 그렇게 쉬운문제는 아닙니다. 이론과 실제는 다를 수밖에 없습니다.

3. 현실의 문제: 왜 실행이 어려운가

1). 점검 항목의 복잡성과 작업량

행정안전부가 제시한 예방점검체계를 실제로 수행한다고 하면 얼마나많은 에포트가 들어갈까요? 중규모 공공기관을 대상으로 예상되는 시간을 산출해보면, 서버 20대를 기준으로 하루 8시간 작업해도 꼬박 2일이 소요됩니다. 매일 수행해야하는 일일점검만 말이죠…(말이 안되겠죠?)

사실 현장에서는 일일이 command를 쳐가면서 점검하지는 않고 미리 shell script를 만들어놓고 매일 리포트를 받아보는식으로 진행할겁니다. 그래도 그 로그를 해석하고 분석하는 것은 작업자의 일이니 20개 로그를 보고 해석하는것 만으로도 하루는 소요될것으로 예상됩니다.

2). 이중화 구성의 맹점: ‘있다’와 ‘작동한다’는 다르다

두번째는 이중화 구성에 대한 내용입니다. 앞서도 설명했지만, 행정안전부 예방점검체계의 특별점검에 포함된 “이중화점검”은 매우 중요한 항목임에도 불구하고 기관에서는 안일하게 생각하는 경향이 있습니다. “우리는 이중화가 되어 있으니까 안전하다”라고 넘어가죠. 시스템 구축당시에 감리도 받았으니까 잘 해놨을 거다…라고 ‘추정’하고 넘어가는 것이죠.

이번 국정자원 화재에서 드러난 문제가 바로 이것입니다. 시스템은 이중화되어 있었지만 물리적으로 같은 건물, 같은 층, 같은 전산실에 있었습니다. 그 결과 한 곳에서 발생한 화재가 이중화된 모든 시스템에 동시에 영향을 미쳤습니다.

<이중화 점검 시 반드시 확인해야 할 체크리스트>

구분	체크리스트
□ 물리적 분리	□ 서버가 다른 건물 또는 다른 층에 위치하는가?
	□ 최소 이격 거리가 확보되어 있는가?
	□ 화재/침수 시 동시 피해 가능성은?
□ 전원 분리	□ 서로 다른 UPS에서 전원을 공급받는가?
	□ UPS도 물리적으로 분리되어 있는가?
	□ 한쪽 UPS 장애 시 다른 쪽은 정상 작동하는가?
□ 네트워크 분리	□ 서로 다른 스위치에 연결되어 있는가?
	□ 네트워크 경로가 완전히 분리되어 있는가?
	□ 한쪽 스위치 장애 시 다른 경로로 우회 가능한가?
□ Fail-Over 검증	□ 실제로 Fail-Over 테스트를 수행했는가?
	□ 자동 전환이 작동하는가? (수동 개입 없이)
	□ 전환 시간이 목표(RTO) 내인가?
	□ 전환 후 서비스 품질은 정상인가?
	□ 모든 시나리오별로 테스트했는가?(서버,, 전원, 네트워크, 스토리지 장애)
□ 백업 데이터 분리	□ 백업 데이터가 물리적으로 다른 장소에 있는가?
	□ 본원 전체 장애 시에도 백업에 접근 가능한가?
	□ 정기적으로 복구 테스트를 수행하는가?

대부분의 기관이 시스템 구축 당시의 구성도만 보고 ‘이중화 구성이 되어있다’라고만 믿고, 실제 테스트까지 해보지 않거나, 또는 초기에는 잘 구축되어있었으나 중간에 여러 변경과정에서 변경된 사항들을 테스트해보지 않아서 “이중화는 되어 있지만 작동하지 않는” 상황이 발생합니다.

이중화 구성 검증은 단순히 구축 당시에 ‘이중화 구성을 했느냐’만을 체크하는것이 아닌, 연 1회 이상 정기 유지보수 점검(PM, Preventive Maintenance, 행안부 용어(정기 안전점검)) 시 실제 Fail-Over 테스트를 수행하여 동작 여부를 검증하는것을 의미합니다.

또한, 이중화 점검은 체계적인 IT서비스관리(ITSM) 프로세스의 일부로 철저한 검증과 통제 하에 수행되어야 하는데, 그렇지 않을 경우 오히려 더 큰 장애를 유발할 수 있습니다.
대부분의 기관들은 ITSM 체계를 갖추고 있지 않거나, 형식적으로만 하는 경우가 많아서 내제화가 되어있는 경우가 드물다보니 저희가 시스템 구조진단 후 개선계획 보고서를 쓰면서도 엄청 우려하는 부분입니다. 다시 한번 강조드립니다. 이중화 테스트는 ‘무조건 하시면 안됩니다. 철저하게 계획하고 하셔야 합니다’

정기 유지보수 점검(PM) 시:

사전 점검 계획 수립 및 승인
변경관리 절차에 따른 작업 수행(백업 및 BackOff Plan을 철저히 계획)
테스트 결과 문서화 및 이력 관리
발견된 문제점에 대한 후속 조치

3). 구조진단의 전문성 문제

행정안전부 예방점검체계에서 규정한 ‘구조진단’은 1등급 시스템에 대해 3년마다 의무적으로 수행하도록 하고있는데 3개 점검 중 가장 높은 수준의 전문성을 요구합니다. 구조진단은 단순한 점검이 아닌 최상의 전문가들이 투입되어 ‘시스템 Risk’관점에서 전반적인 부분을 종합적으로 진단하는 컨설팅에 해당합니다.

왜 구조진단이 어려운가?

①. 다영역 전문 지식 필요

구조진단은 7개 영역을 모두 진단해야 합니다:

서버 진단

└─ OS별 전문 지식 (AIX, Linux, Windows)

└─ 벤더별 명령어와 도구 (IBM, HP, Dell 등)

└─ 커널 파라미터, 네트워크 스택, 파일시스템

WEB/WAS 진단

└─ 제품별 아키텍처 이해 (Apache, Tomcat, Jeus, WebLogic)

└─ JVM 튜닝, Thread Dump 분석, GC Log 해석

└─ Heap 메모리 최적화, Connection Pool 설정

DBMS 진단

└─ DBMS별 내부 구조 (Oracle, MySQL, PostgreSQL)

└─ AWR 리포트 분석, 실행계획 해석

└─ SQL 튜닝, 인덱스 설계, 파티셔닝

네트워크 진단

└─ L2/L3/L4 스위치, 방화벽, 로드밸런서

└─ VLAN, Routing, STP, VRRP

└─ 패킷 분석, 트래픽 엔지니어링

스토리지 진단

└─ SAN, NAS, 파일시스템

└─ RAID 구성, Multipath, LUN 관리

└─ I/O 성능 분석, 용량 계획

한 사람이 모든 영역의 전문가가 되기는 거의 불가능하기때문에 최소 3~5명의 분야별 실무경력 10년 이상의 다양한 문제진단 경험과 관련 전문지식을 보유한 전문가가 필요하며, 시스템의 서비스 연속성 관점에서 문제점을 들여다볼 수 있는 인사이트도 있어야 합니다.

② 전문 도구 활용 능력

구조진단 시에는 다양한 진단 도구들을 사용하게 되는데, 행정안전부 예방점검체계에서 제시한 진단 도구들만 해도 진단의 범위와 Depth에 따라 다양한 툴이 사용됩니다.

서버: OS 명령어, 벤더 자체 툴
WEB/WAS: APM 툴, Java 명령어 (jstat, jmap, jstack), GC 로그 분석기
DBMS: AWR, ADDM, SQL Trace, 실행계획 분석기, 진단 스크립트
네트워크: SNMP, 패킷 캡처 도구, 트래픽 분석 툴

진단 전문가들은 각 도구의 출력 결과를 해석하고, 문제점을 진단하고, 개선안을 제시해야 하는데, 그러기 위해서는 상당한 전문성이 요구됩니다.

③ 법령 근거 기반 판정과 보고서 작성 능력(컨설팅 능력)

구조진단은 단순히 기술적으로 문제를 발견하는 것만으로는 부족하고, 행정안전부 예방점검체계와 디지털행정서비스 신뢰 제고 대책에 명시된 기준에 따라 판정하고, 법령 근거를 명시해야 하며, 컨설팅 보고서 형태로 작성되어야 합니다.

1. 진단 개요 – 진단 대상, 범위, 방법

2. 진단 결과 요약

– 영역별 위험/주의/확인/정상 현황

– 핵심 발견 사항 (Executive Summary)

3. 영역별 상세 진단 결과

– 각 진단항목별

∙ 진단 내용 ∙ 현황 (로그, 스크린샷, 수치)

∙ 판정 (위험/주의/확인/정상)

∙ 개선 방안

4. 개선 권고사항 (우선순위별)

– 높음 (3개월 내)

– 중간 (6개월 내)

– 낮음 (12개월 내)

5. 서비스 연속성 개선 로드맵

– 단기/중기/장기 계획

제 경험상 이러한 구조진단 보고서를 작성하려면 시스템 진단부터 결과보고서 작성까지 수작업으로 최소 2~3개월이 소요되며, 진단 대상 서버 대수가 많거나 시스템 구성이 복잡할 경우, 이 기간은 6개월 이상으로 늘어날 수밖에 없습니다.

4. 전문성과 자동화, 두 가지가 모두 필요

1). 전문성과 경험 모두 필요

지금까지 설명드린것처럼 행정안전부가 제시한 범정부 정보시스템 예방점검체계와 구조진단은 단순한 체크리스트가 아닙니다. 시스템의 서비스 연속성을 보장하기 위한 체계적인 프레임워크이며, 이를 제대로 수행하기 위해서는 깊이 있는 기술적 전문성과 현장 경험이 필수적입니다.

제가 몸담고 있는 씨에스리는 아키텍처 전문회사로서 2016년부터 과학기술정보통신부와 TTA(한국정보통신기술협회)가 우리나라 중요 정보시스템을 대상으로 대대적으로 실시했던 시스템 구조안전진단 사업에 전문 진단기관으로 참여해왔는데요. 이러한 전문성과 경험을 바탕으로 TTA의 시스템 안전진단 가이드라인 개발 작업에도 참여하여, 진단 기준과 방법론 수립에도 직접 기여한 바 있습니다. 시스템 장애는 고객의 Top Secret이라 모든 사례를 말씀드리기는 어려우나 그동안 우리나라 굵직굵직한 대형사고에는 거의 참여해왔기에 시스템 장애 상황을 들어보면 해당고객사는 어디까지 되어있을 것이다가 감으로 옵니다. 이번 국정자원 사고도 데이터 유실이 꽤 있을 것이다 예상했는데 역시나입니다. 더 큰 피해가 없기만을 바래봅니다.

2). 진단 생산성을 위한 솔루션 필요

앞서 살펴본 것처럼, 행정안전부가 제시한 예방점검체계를 수작업으로 수행하는 것은 현실적으로 매우 어렵습니다. 저희 전문가들이 해도 전문성과 ‘생산성’은 또 다른 문제라 ‘진단 생산성’을 높이기 위해서는 ‘자동화’가 필수적입니다. 단순한 자동화가 아니라, 행정안전부가 제시한 예방점검체계와 법령 기준을 완벽하게 준수하면서도, 실무에서 실제로 활용 가능한 수준의 자동화가 필요한 것이죠. 기관의 정보시스템이 수천대 이상일텐데, 아무리 전문가라 하더라도 물리적인 양은 감당이 안되는 수준입니다.

그래서 저희 씨에스리는 진단시에 자체 개발한 ‘CS진단’ 솔루션을 사용합니다. 진단 솔루션이 갖춰야 하는것은 먼저 진단 체계에 대한 진단 커버리지와 수작업 요소의 최소화라 할 수 있습니다.

그동안의 현장 경험과 전문성을 바탕으로 개발한 씨에스리의 ‘CS 진단’ 솔루션은:

행정안전부의 범정부 정보시스템 예방점검체계 115개 항목을 완벽하게 준수
법령 근거 기반의 자동 판정 및 보고서 생성
7개 영역 24개 구조진단 항목 자동 진단

단순한 모니터링 도구가 아니라, 재난 및 안전관리 기본법과 디지털행정서비스 신뢰 제고 대책에서 요구하는 예방-대비-대응-복구 관점의 시스템을 진단하고 관리를 지원하는 통합 플랫폼입니다.

지금이 가장 적기입니다.

2025년 국정자원 화재는 우리에게 명확한 메시지를 남겼습니다:

“사고는 언제든 발생할 수 있다. 중요한 것은 우리가 얼마나 준비되어 있느냐다.”

행정안전부가 제시한 범정부 정보시스템 예방점검체계는 선택이 아닌 의무입니다. 더 중요하게는, 이는 국민에게 안정적인 행정서비스를 제공하기 위한 최소한의 안전장치입니다.

참고문헌

1. 법령

행정안전부. (2024). 재난 및 안전관리 기본법 시행령 개정안. 대통령령 제34660호.
행정안전부. (2023). 전자정부법. 법률 제19030호.
전자정부법 시행령 제70조의2(정보시스템 장애 예방 및 대응 등)
행정안전부. (2022). 행정기관 및 공공기관 정보자원 통합기준. 행정안전부고시 제2022-27호.
행정안전부. (2025). 행정기관 및 공공기관 정보시스템 구축·운영 지침. 행정안전부고시 제2025-1호.
행정자치부. (2017). 자치단체 정보시스템 장애 예방 및 대응 지침. 행정자치부 예규 제90호.

2. 정부 정책 문서

행정안전부. (2022). 행정·공공기관 정보시스템 표준 운영 절차서.