고등학생 시절, 원자 모형으로 유명한 이론물리학자 어니스트 러더퍼드가 실제로는 실험을 통해 자신의 이론을 끊임없이 의심했던 과학자였다는 이야기를 들은 적이 있다. 러더퍼드는 원자를 설명하는 모델을 제시했지만, 그 모델을 신앙처럼 받아들이지 않았다. 오히려 알파입자 산란 실험을 통해 이론과 현실이 어디에서 어긋나는지를 집요하게 확인했고, 그 간극 속에서 새로운 이해를 구축해 나갔다.
시스템 안전(System Safety) 역시 같은 질문 앞에 서 있다. 우리는 수많은 분석 기법과 모델을 통해 “안전하다”고 선언하지만, 사고는 언제나 그 선언이 끝난 이후에 발생한다. 이때 문제는 단순히 분석이 부족했는지가 아니다. 오히려 우리가 무엇을 전제로 안전을 정의해 왔는가라는 더 근본적인 질문이 남는다.
현대의 대형 사고들은 더 이상 하나의 고장이나 단일 실수로 설명되지 않는다. 모든 구성 요소가 정상적으로 작동했고, 절차 역시 준수되었으며, 누구도 명백한 규칙 위반을 하지 않았음에도 사고는 발생한다. 이 지점에서 기존 안전 분석은 설명력을 잃고, 사고를 “예외”로 밀어낸다. STPA는 바로 이 지점에서 출발한다. 사고를 예외가 아니라, 시스템이 그렇게 작동하도록 설계된 결과로 바라보기 시작하면서 말이다.
STPA(Systems-Theoretic Process Analysis)는 MIT의 낸시 레브슨(Nancy Leveson) 교수가 제안한 STAMP(System-Theoretic Accident Model and Processes) 사고 모델을 기반으로 한 시스템 안전 분석 기법이다. STAMP는 사고를 부품의 고장이나 인간의 오류가 누적된 결과로 보지 않는다. 대신 사고를 시스템 전체가 위험을 적절히 통제하지 못했을 때 나타나는 emergent property, 즉 시스템 수준에서 자연스럽게 드러나는 결과로 해석한다.
이 관점에서 안전은 개별 구성 요소의 신뢰도를 합산한 값이 아니다. 인간, 소프트웨어, 자동화 장치, 조직 규칙, 의사결정 구조, 그리고 피드백 메커니즘이 어떤 방식으로 상호작용하며 시스템 상태를 제어하는가가 안전을 결정한다. STPA는 따라서 안전을 “무언가가 고장 나지 않게 하는 문제”가 아니라, 시스템이 위험한 상태로 진입하지 않도록 어떻게 제어되어야 하는가의 문제로 재정의한다.
특히 현대 시스템에서는 이 관점이 결정적으로 중요해진다. 소프트웨어는 기계적 의미의 고장을 거의 일으키지 않으며, 잘못된 논리나 불완전한 내부 모델 위에서도 정상적으로 작동한다. 인간 역시 무작위적인 실수를 반복하는 존재가 아니라, 제한된 정보와 시간, 조직적 제약 속에서 합리적인 판단을 내린다. 그럼에도 사고가 발생하는 이유는, 이러한 정상 작동들이 시스템 수준에서 적절히 조율되고 통제되지 않았기 때문이다. STPA는 바로 이 “정상 작동 중 발생하는 사고”를 설명하기 위해 설계된 분석 체계다.
STPA에서 말하는 통제(Control)는 단순한 물리적 차단이나 보호 장치를 의미하지 않는다. 인간과 자동화, 소프트웨어, 조직 구조, 의사결정 규칙, 그리고 피드백 흐름까지 포함하는 전체 제어 구조(control structure)를 뜻한다. 따라서 STPA는 안전을 부품 신뢰성이나 절차 준수의 문제로 보지 않고, 제어 구조의 설계와 유지 문제로 바라본다. 이 제어 중심 사고가 STPA를 기존 안전 분석 기법과 근본적으로 구분 짓는 핵심이다.
STPA는 전통적인 기계 중심 시스템보다는, 복잡하고 소프트웨어 의존도가 높은 시스템에서 특히 강점을 가진다. 항공우주 시스템, 철도 신호 및 관제 시스템, 원자력 발전소, 의료기기, 자율주행 차량 등이 대표적이다. 이들 시스템의 공통점은 인간과 자동화가 긴밀하게 얽혀 있으며, 시스템 상태를 완전히 가시화하기 어렵다는 데 있다.
이러한 환경에서는 “어떤 부품이 고장 날 것인가”라는 질문이 점점 의미를 잃는다. 대신 더 중요한 질문은
“누가 어떤 정보를 기반으로 어떤 결정을 내렸는가”,
“그 결정이 시스템 전체에 어떤 영향을 미쳤는가”,
“피드백은 적시에, 올바른 형태로 전달되었는가”
이다.
STPA는 바로 이러한 질문을 구조적으로 던질 수 있게 해준다.
2025년 이후 특히 주목받는 영역은 생성형 AI 및 프런티어 AI 시스템이다. AI 시스템은 명시적 고장 없이도 예기치 않은 행동을 보이며, 그 의사결정 과정을 사후적으로 완전히 설명하기 어렵다. 이때 STPA는 AI를 하나의 ‘제어자(controller)’로 모델링하고, 그 내부 모델과 외부 피드백의 불일치를 통해 위험 시나리오를 식별하는 데 활용되고 있다. 이는 기존 고장 중심 분석으로는 접근이 불가능한 영역이다.
전통적인 안전 분석 기법인 FMEA와 FTA는 여전히 산업 현장에서 널리 사용되고 있으며, 특정 목적에서는 매우 유효하다. FMEA는 개별 구성 요소의 고장 모드와 그 영향을 분석하고, FTA는 특정 사고를 최상위 이벤트로 두고 그 원인이 되는 고장 조합을 논리적으로 추적한다. 이 기법들의 공통된 전제는 사고가 고장의 결과라는 점이다.
그러나 현대 시스템에서는 이 전제가 자주 무너진다. 예를 들어 센서는 정확한 값을 전달했고, 소프트웨어는 요구사항대로 동작했으며, 운영자는 절차를 준수했음에도 불구하고 사고가 발생하는 경우가 많다. 이때 FTA는 더 이상 분해할 고장을 찾지 못하고, 분석은 “인적 오류” 혹은 “미확인 원인”이라는 결론으로 끝나기 쉽다.
STPA는 이 지점에서 다른 질문을 던진다. 센서가 고장 나지 않았더라도, 그 정보가 통제자에게 어떤 의미로 해석되었는가? 제어 명령은 왜 그 시점에, 그 강도로 내려졌는가? 시스템 내부 모델은 실제 시스템 상태를 충분히 반영하고 있었는가? 즉, STPA는 사고를 상호작용과 제어 논리의 실패로 재구성한다. 이 차이는 단순한 기법의 차이가 아니라, 사고를 바라보는 인식론적 전환에 가깝다.
Note. 정리
1) 기존 분석의 시선
FMEA: 이 부품이 고장 나면 무엇이 문제인가?
FTA: 이 사고를 만들기 위한 고장 조합은 무엇인가?
이 방법들은 여전히 유효하다. 하지만 전제는 같다.
사고 = 고장의 조합
2) STPA의 시선
STPA는 이 전제를 버린다.
소프트웨어는 고장 나지 않는다. 논리가 틀릴 뿐이다
인간은 오류를 낸다기보다, 불완전한 정보 속에서 합리적으로 행동한다
사고는 구성요소 간 상호작용의 실패에서 발생한다
FTA 질문:
“센서 고장 → 제어 실패 → 사고?”
STPA 질문:
“센서는 정상인데, 왜 이 제어 명령이 이 시점에 나갔는가?”
“이 피드백은 왜 통제자에게 의미 있게 전달되지 않았는가?”
STPA는 사고 이후 책임을 찾기보다,
사고 이전에 실패가 구조적으로 내재되어 있었는지를 묻는다.
STPA는 네 단계의 구조화된 절차를 통해 수행된다. 첫 단계는 시스템이 결코 입혀서는 안 되는 손실을 정의하고, 이를 유발할 수 있는 시스템 수준의 위험(Hazard)을 도출하는 것이다. 이는 분석의 범위를 명확히 하고, 이후 단계에서 불필요한 세부 분석으로 빠지는 것을 방지한다.
1) 목적 정의 (Define Purpose)
시스템이 입혀서는 안 되는 손실 정의
시스템 수준의 Hazard 도출
두 번째 단계에서는 시스템을 제어 구조 관점에서 모델링한다. 여기서 중요한 점은 물리적 구성도가 아니라 기능적 제어 관계를 그린다는 것이다. 인간, 소프트웨어, 자동화 장치는 모두 제어자로 간주되며, 제어 명령과 피드백의 흐름이 명확히 표현된다. 이 단계는 STPA의 핵심으로, 사고 가능성이 숨어 있는 구조적 취약점을 시각화한다.
2) 제어 구조 모델링 (Control Structure)
인간, 소프트웨어, 자동화 장치를 제어자로 정의
제어 명령과 피드백 흐름을 기능적으로 모델링
세 번째 단계에서는 불안전 제어 동작(Unsafe Control Actions, UCA)을 식별한다. 제어 명령이 아예 내려지지 않았을 때, 잘못된 명령이 내려졌을 때, 타이밍이나 순서가 부적절했을 때, 혹은 명령이 너무 오래 또는 짧게 유지되었을 때 발생할 수 있는 위험을 체계적으로 분석한다. 마지막 단계에서는 이러한 UCA가 왜 발생했는지를 추적하며, 센서 오류, 통신 지연, 인간의 인지 한계, 소프트웨어 모델 불일치 등 구체적인 손실 시나리오를 도출한다. 이 과정에서 중요한 것은 정답을 찾는 것이 아니라, 위험이 발생할 수 있는 경로를 최대한 드러내는 것이다.
3) 불안전 제어 동작(UCA) 식별
다음 4가지 관점에서 분석한다.
제어 명령을 주지 않은 경우
잘못된 명령을 준 경우
너무 빠르거나 늦은 경우
너무 짧거나 길게 지속된 경우
4) 손실 시나리오 도출
왜 그런 UCA가 발생했는가?
센서 오류, 모델 불일치, 통신 지연, 인간의 인지 한계 등 근본 원인을 추적
STPA는 만능 도구가 아니다. 정량적 위험 평가에는 적합하지 않으며, 분석자의 시스템 이해도와 사고 수준에 따라 결과 품질 편차가 크다. 또한 조직이 사고를 개인의 실수나 규정 위반으로만 해석하는 문화에 머물러 있다면, STPA는 형식적인 문서로 전락할 위험도 있다.
무엇보다 STPA는 시간과 사고력을 요구한다. 체크리스트를 채우듯 수행할 수 있는 기법이 아니며, 시스템에 대한 깊은 이해와 끊임없는 질문이 전제되어야 한다. 이 점에서 STPA는 도구라기보다 사고 훈련 방법론에 가깝다. 그래서 더더욱 도입은 쉽지만, 정착은 어렵다.
현재, 시스템 안전은 분명히 새로운 국면으로 접어들고 있다. 사고 분석의 초점은 고장에서 상호작용으로, 규정 준수에서 제어 구조의 적절성으로 이동하고 있다. 인간 오류는 더 이상 원인이 아니라, 시스템 설계가 인간에게 요구한 역할의 결과로 해석된다.
고장 분석 → 상호작용 분석
절차 중심 → 제어 구조 중심
책임 추적 → 설계 의도 검증
인간 오류 → 인간-시스템 공진 실패
특히 AI와 고도의 자동화 시스템이 확산되면서, “왜 그렇게 판단했는가”를 설명할 수 없는 시스템은 사회적으로 받아들여지기 어려워지고 있다. STPA는 이러한 변화 속에서 사고를 설명하는 언어이자, 안전을 설계하는 사고 체계로 점점 더 중요한 위치를 차지하고 있다.
러더퍼드는 이론을 부정하지 않았지만, 현실 앞에서 언제든 수정될 수 있어야 한다고 믿었다. 그는 모델을 신뢰했지만, 그 모델이 실제 세계를 설명하지 못한다면 주저 없이 다시 실험으로 돌아갔다. 시스템 안전 역시 다르지 않다. 문서 속에서 완벽해 보이는 안전 논리가 실제 운영 환경, 인간의 판단, 소프트웨어의 결정 과정 속에서 그대로 작동하지 않는다면, 그것은 안전이 아니라 단지 스스로를 안심시키기 위한 설명에 불과하다.
STPA는 사고를 예측하는 마법의 도구가 아니다. 대신 우리가 무엇을 통제하고 있다고 믿어왔는지, 그리고 실제로는 무엇을 통제하지 못하고 있었는지를 드러낸다. 사고는 종종 규칙이 부족해서 발생하는 것이 아니라, 이미 존재하던 통제 구조가 현실의 복잡성을 감당하지 못했기 때문에 발생한다. 이 점에서 안전은 더 많은 절차나 규정으로 완성되지 않는다. 오직 더 나은 통제 구조에 대한 이해와 설계를 통해서만 완성될 수 있다.
STPA의 진짜 가치는 분석 결과 그 자체에 있지 않다. 그것은 우리가 당연하게 여겨왔던 안전 가정들을 다시 의심하게 만들고, 통제가 실제로 어떻게 작동하고 있는지를 끝까지 질문하도록 만든다는 데 있다. 불편하지만 정직한 이 질문들 위에서만, 이론과 현실이 분리되지 않는 안전이 비로소 시작된다.