HAZOP은 결국, 인간이 상상할 수 있는 마지막 방어선이다.
얼마 전, 대전 유성구에 위치한 국가정보자원관리원 화재 사고가 뉴스를 통해 전해졌다. 다행히 인명 피해는 없었지만, 책임을 짊어진 한 공무원이 안타까운 선택을 했다는 소식은 많은 이들의 마음을 무겁게 했다.
이 화재는 초진까지 무려 10시간이 걸렸다. 이유는 단순했다. 일반 화재처럼 물을 마구 쏟아부을 수 없었기 때문이며, 대량의 물은 곧바로 데이터 시설의 치명적 훼손으로 이어질 수 있었다. 결국 소방대는 물 대신 가스 소화 설비를 중심으로 진압을 진행해야 했다.
이 사건은 시스템 안전 엔지니어의 시선에서 보면, HAZOP(위험 및 운전 분석, Hazard and Operability Study)의 좋은 사례가 된다. 전산실이나 데이터센터와 같은 기술 인프라 시설은 단일한 구조가 아니라, 수많은 운전 변수(operating parameters)들이 얽혀 있는 복합적인 시스템이다.
전력 공급, 배터리 온도, 전원 차단 절차, 냉각 시스템, 접근 경로, 배선 및 장비 배치 등… 이 모든 요소가 서로 얽혀 있어 하나의 작은 이상이 전체 시스템의 기능에 영향을 줄 수 있다. 특히 UPS 및 배터리 설비는 평상시보다 비상 상황(failure mode)이나 정비 중의 비정상 상태에서 더욱 취약해진다.
게다가 이런 시설은 대부분 핵심 서비스와 밀접하게 연결되어 있다. 즉, 한 노드(node)의 실패가 여러 다른 시스템으로 연쇄적인 파급 효과(cascading effect)를 일으킬 수 있다. 그렇기 때문에 단순한 위험 요소를 넘어, 운전성(operability)과 상호의존성(interdependency)을 함께 분석해야 한다.
그래서 이번 글에서는, 대전의 이 화재 사건을 HAZOP 관점에서 살펴보며 “무엇이 위험을 키웠는가, 그리고 어떤 운전 변수들이 문제의 핵심이었는가”를 함께 분석해보려 한다.
Note.
사고 주요 내용은 다음과 같다:
장소: 대전 유성구, 국가정보자원관리원 본원 전산실(5층) 전산실 내부.
시간: 2025년 9월 26일 오후 8시 15분경
원인 추정: 무정전 전원장치(UPS)의 리튬이온 배터리 폭발(배터리 열 폭주 가능성)
피해: 정부 전산 서비스 약 70여 개 시스템 장애 발생 (1등급/2등급 시스템 포함)
인명피해는 경미: 연기흡입 등 경상자 있음 진화 소요 시간 약 10시간 (초진까지) 화재 진압 시 대량의 물 사용이 데이터 시설 훼손 우려로 자제됨; 가스 소화 설비 등 사용됨.
HAZOP 관점에서는 다양한 분석이 나올 수 있다.
전산실과 같은 기술 인프라 시설은 여러 운전 변수 (전력, 배터리 온도, 전원 차단, 냉각, 접근성, 배선/설비 배치 등)가 복합적으로 작용함.
UPS 및 배터리 시설은 “비상 상태(failure mode)” 또는 “정비 및 교체 작업” 등 비정상 운전 조건이 발생할 여지가 큼.
핵심 서비스 연계성이 높아, 하나의 노드(node)의 실패가 여러 시스템에 파급되므로, operability 및 interdependency 위험 분석이 필요함.
UPS(무정전 전원장치)는 데이터센터의 심장을 지키는 수호자다. 정전이 나도 전원을 끊기지 않게 하며, 국가의 시스템이 1초라도 멈추지 않게 한다. 하지만 그날, 한 배터리 팩의 온도가 천천히 상승하기 시작했다. 냉각팬은 돌고 있었지만, 공기의 흐름은 완벽하지 않았다.
작은 열이 모여 ‘More temperature’라는 HAZOP의 첫 번째 경고를 속삭였다.
“온도가 더 높다면, 무슨 일이 일어날까?”
그 답은 명확했다. 리튬이온 배터리는 열을 싫어한다. 열은 화학반응을 가속시키고, 그 반응은 더 큰 열을 만든다. 결국, 열 폭주(Thermal runaway) — 제어 불가능한 자기 연소가 시작된다.
노드(node): UPS 배터리팩 온도
가이드워드(Guide Word): More temperature
가능한 원인(Cause): 냉각 불량, 주변 온도 상승, 통풍 부족, 화재 이전 잔열 축적
가능한 결과(Effect): 온도 상승 → 내부 화학반응 가속 → 발화 가능성
제어 대책(Possible Safeguards / Recommendations): 냉각 시스템(에어컨/팬) 보강, 온도 센서 및 알람 설치, 통풍 구조 개선
충전 회로는 평소처럼 작동하고 있었다. 과전류 방지 회로도, 모니터링 시스템도, 경보장치도 모두 “정상”이었다. 그러나 HAZOP은 이런 질문을 던진다.
“만약 전류가 평소보다 조금 더 강했다면?”
“만약 센서가 순간적으로 오작동했다면?”
그 순간을 아무도 보지 못했다. 시스템은 숫자를 정상 범위로 표시했고, 사람은 그 숫자를 믿었다. HAZOP이 있었다면, 그 신호 하나하나를 ‘가정’으로 검토했을 것이다.
More power → 과열 → 폭발 → 화재
그 단순한 연결 고리가, 현실에서는 너무 늦게 드러났다.
노드(node): UPS 배터리 팩 전력공급
가이드워드(Guide Word): More Power/ More Current
가능한 원인(Cause): 전류 과부하, 배터리 설계 이상, 충전 회로 고장
가능한 결과(Effect): 배터리 과열 → 열 폭주 → 폭발 또는 발화
제어 대책(Possible Safeguards / Recommendations): 충전 제어 회로 강화, 과전류 보호장치, 정기 점검 및 예방적 교체
노드(node): 배터리 팩 설치/보관 조건
가이드워드(Guide Word): Wrong location / Contamination
가능한 원인(Cause): 배터리 주변 배선이나 다른 전자기기 근접, 먼지/이물 혼입, 습기 유입, 배치 불량
가능한 결과(Effect): 단락(short-circuit), 스파크, 점화원 작동 → 화재 확산
제어 대책(Possible Safeguards / Recommendations): 배터리룸 분리, 방진/방습 관리, 적절한 배치거리 확보, 절연 처리 강화
화재는 순식간이었다. 불길이 배터리 팩을 따라 번졌고, UPS 라인은 끊기지 않았다. 아이러니하게도, “무정전”을 지키기 위한 장치가 화재를 멈추지 못하게 했다.
“만약 전원을 완전히 차단할 수 없었다면?”
HAZOP의 세 번째 질문이다. UPS는 본래 전원을 유지하기 위한 시스템이지만, 정비나 비상상황에서는 전원 격리(Isolation) 기능이 필요하다. 하지만 실제로는 모듈 간 전원선이 얽혀 있고, 한 회로를 끄면 다른 회로도 영향을 받는다.
결국 “No isolation” — 즉, 차단할 수 없는 설계가 화재를 키운 셈이었다.
노드(node): 전원 차단 / 정비 작업
가이드워드(Guide Word): No power / No isolation
가능한 원인(Cause): 전원 차단 절차 미비, 정비 중 전원이 완전히 차단되지 않음, 감리 미흡
가능한 결과(Effect): 작업 중 스파크 발생, 정비 도중 누전, 화재 발생
제어 대책(Possible Safeguards / Recommendations): 정비 절차 매뉴얼화, Lock‐out / Tag‐out(LOTO) 제도 확립, 작업 전 전기 상태 확인
데이터센터의 화재는 보통의 화재처럼 물을 쓸 수 없다. 수천억 원의 서버가 물에 젖으면,
불은 꺼져도 국가는 멈춘다. 그날, 소방관들은 조심스러웠다.
불은 천천히 번지고 있었지만, 가스 소화 설비는 한계가 있었고, 연기는 층층이 쌓여갔다.
“만약 소화 시스템이 즉시 작동하지 않는다면?”
그 단 하나의 가정이 HAZOP 표에서 ‘심각도(Severity)’ 가장 높은 칸을 차지했을 것이다.
그리고 바로 그 가정이, 현실이 되었다.
노드(node): 화재진압 수단
가이드워드(Guide Word): No extinguishing / Delay
가능한 원인(Cause): 물 사용 제한, 소화장치 작동 지연, 연기/열 차단으로 접근 어려움
가능한 결과(Effect): 화재 진압 지연, 손상 범위 확대, 데이터 및 장비 손실 증가
제어 대책(Possible Safeguards / Recommendations): 가스 또는 분말 소화 시스템 설치, 자동 화재 감지 및 조기 경보, 비상 대응 훈련 정기적 실시
불길이 잡힌 뒤, 시스템은 멈췄다. 정부의 전산 서비스 70여 개가 다운되었고, 병원 예약 시스템, 주민 서비스, 국세청 포털까지 모두 정지됐다.
“만약 이 서버가 멈춘다면, 다른 곳에서 바로 복구될 수 있는가?”
HAZOP의 마지막 질문이다.
“운전 가능성(Operability)”의 핵심은 단순히 기계가 돌아가는가가 아니라, 멈췄을 때 얼마나 빨리 회복되는 가다. 그러나 이번 사고는 이중화(Redundancy)가 완전하지 않았음을 드러냈다.
재난은 시스템의 하드웨어를 태웠지만, 사람들은 절차와 설계의 취약함이 함께 불타는 것을 보았다.
노드(node): 중요 시스템 복구 / 이중화
가이드워드(Guide Word): Less redundancy / No backup
가능한 원인(Cause): 주요 서비스를 단일 전산실에 의존, 부지 이중화 미비, 백업 시스템 미비 또는 원격 백업 불완전
가능한 결과(Effect): 서비스 전체 마비, 국민 생활에 큰 피해, 복구 지연
제어 대책(Possible Safeguards / Recommendations): 원격 DR(Data Recovery) 센터 확보, 지리적 분산, 백업 데이터 정기 테스트, 중요 서비스 우선 복구 계획 수립
Note.
적용 가능한 한계점 및 추가 고려사항
배터리의 특성(열 폭주, 화학적 반응) 상, 전통 소방 방법(물·스프링클러 등)은 데이터센터 장비나 시설 손상 우려 때문에 제약이 있음. 따라서 소화 설비 선택과 화재 감지·진압 전략이 매우 중요함.
서비스 등급(1등급 vs 2등급)의 정의, 각 서비스 복구 우선순위, 어떤 서비스가 어느 노드/시스템에 종속되어 있는지 맵핑(mapping)이 필요.
작업 중인 업체, 감리 등의 역할과 책임 분담, 절차 준수 여부 등이 중요 원인 요소가 될 수 있으므로 조직·절차적 노드(node)도 포함해서 분석하는 것이 좋음.
화재는 꺼졌지만, 남은 건 잿더미가 아니었다. 국가의 전산 인프라 전반을 다시 설계해야 하는 숙제가 남았고, 그 위에는 하나의 질문이 떠오른다.
“다음엔, 같은 일이 다시 일어나지 않을까?”
대전의 화재는 단순한 시설 사고가 아니었다. 그건 우리가 얼마나 시스템을 믿고, 동시에 상상하지 않았는가를 보여준 사건이었다. 겉으로 보기엔 깨끗하고 완벽해 보이는 데이터센터도 사실은 복잡한 전기 흐름, 공기, 온도, 압력, 배터리, 그리고 인간의 판단이 얽힌 거대한 생명체와도 같다.
하나의 센서 오작동이 전원 차단을 지연시키고, 그 차단이 냉각을 멈추게 하며, 냉각 정지가 온도를 높여 결국 폭발로 이어질 수 있다. HAZOP은 그 생명체의 신경망을 하나하나 짚어가며 묻는다.
“이 노드가 멈추면, 옆 노드는 어떻게 반응하지?”
“이 흐름이 막히면, 다른 경로는 존재하나?”
그건 단순한 분석이 아니라, 시스템에 생명을 불어넣는 대화다. 모든 절차를 매뉴얼대로 수행되었을 것이다. 하지만 진짜 안전은 매뉴얼이 아니라 상상력의 영역이다.
“이건 절대 일어나지 않아.”라는 말이 가장 위험한 주문이라는 걸, 사고 이후라는 시점에서 너무 늦게 깨닫는다.
그렇기에 필요한 HAZOP은 바로 그 ‘보이지 않는 위험’을 찾아내기 위한 상상력의 도구다. “만약”이라는 단어 하나로, 시스템은 스스로를 되돌아보고, 결국 안전은 기술이 아니라 태도의 문제라는 걸 알게 된다.
위험은 언제나 상상력의 바깥에서 시작되지만, 예방은 언제나 질문하는 사람에게서 시작된다.
그래서 HAZOP은 오늘도 조용히 말한다.
“상상하라. 그리고 기록하라.”