시스템 안전(System Safety)의 관점에서 제어(Control)란, 시스템이 허용 가능한 안전 상태를 벗어나지 않도록 위험 요소와 안전 제약 조건(Safety Constraints)을 의도적으로 강제하는 모든 활동과 메커니즘을 의미한다. 이는 고장이 발생한 뒤 이를 수리하는 기술적 대응에 국한되지 않는다. 설계 단계에서의 위험 제거와 구조적 제한, 물리적 안전 장치의 구현, 그리고 운영 단계에서의 절차·감시·피드백에 이르기까지, 제어는 시스템 전 생애주기에 걸쳐 작동하는 포괄적인 개념이다.
현대 안전 공학, 특히 STAMP(System-Theoretic Accident Model and Processes)와 같은 시스템 이론 기반 모델에서 제어는 사고 예방의 중심에 놓인다. 사고는 단일 구성품의 고장보다, 제어 구조 내에서 부적절한 명령과 불충분한 피드백, 그리고 통제되지 않은 상호작용의 결과로 발생한다. 즉, 제어란 시스템을 구성하는 제어기(Controller)가 올바른 제어 명령을 내리고, 시스템 상태를 지속적으로 인식하며, 위험한 상태로의 이탈을 사전에 차단하는 능력 그 자체다.
시스템 안전에서 위험(Risk)과 유해요인(Hazard)은 제거해야 할 대상이면서 동시에 완전히 제거할 수 없는 현실이기도 하다. 많은 조직은 사고 이후 “위험을 충분히 인지하지 못했다”고 말하지만, 실제로는 위험을 알고도 그것을 어떻게 다룰지에 대한 구조적 결정이 부족했던 경우가 더 많다. 시스템이 복잡해질수록 사고는 개인의 실수나 일탈이 아니라, 설계·운영·조직 전반에 걸쳐 누적된 선택의 결과로 나타난다.
이 지점에서 Control은 단순한 안전 대책이나 규정의 목록이 아니다. Control이란 위험을 없애겠다는 선언이 아니라, 위험이 사고로 전이되는 경로를 어디에서, 어떤 방식으로 끊어낼 것인지에 대한 시스템 차원의 결정이다. 시스템 안전 엔지니어의 관점에서 제어는 “조심하자”는 메시지가 아니라, 조심하지 않더라도 위험한 상태로 진입할 수 없도록 만드는 구조적 개입이다.
우리는 위험을 인식하는 순간부터 책임을 진다. Controls는 그 책임이 문서와 분석 보고서에 머무르지 않고, 실제 시스템의 행동과 반응으로 구현되도록 만드는 유일한 수단이다. 그렇기 때문에 제어를 논한다는 것은 안전을 선언하는 것이 아니라, 위험과 함께 살아가는 방식을 설계하는 일에 가깝다.
Hazard는 시스템 안에 잠재적으로 존재하는 손상 원인이다. Risk는 그 Hazard가 특정 조건에서 현실화될 가능성과, 현실화되었을 때의 결과를 함께 고려한 개념이며, 많은 안전 분석 활동은 Hazard 식별과 Risk 평가까지는 비교적 충실하게 수행된다. 문제는 그 다음 단계다. 분석 결과가 실제 시스템 설계와 운영 방식에 어떤 변화를 만들어냈는가를 묻기 시작하면, 답이 흐려진다.
위험을 분석했다는 사실 자체는 아무것도 바꾸지 않는다.
Control은 이 간극을 메우는 역할을 한다. Hazard와 Risk는 ‘설명’의 언어지만, Control은 ‘결정’의 언어다. Control은 분석의 연장이 아니라 설계와 운영의 문제이기 때문에 많은 조직이 Hazard와 Risk, 이 둘을 분석하는 데는 능숙하지만, Control 단계에서 실패한다. 오직 Control이 설계에 반영되고, 운영에서 강제될 때만 위험은 사고로 이어지지 않는다. 따라서 Control은 분석 결과의 부속물이 아니라, 분석의 목적 그 자체에 가깝다.
Note 정리.
Hazard 식별: “무엇이 잘못될 수 있는가?”
Risk 평가: “얼마나 자주, 얼마나 크게 잘못될 수 있는가?”
Control 설계: “그 경로를 어떻게 끊을 것인가?”
Control은 위험을 설명하는 언어가 아니라, 위험을 제한하는 구조다. 따라서 좋은 Control은 항상 행동, 물리, 시스템 반응으로 이어진다.
시스템 안전 관점에서 Control은 단순히 위험을 줄이기 위한 조치가 아니다. Control은 시스템이 특정 위험 상태로 진입하지 못하도록 제한하거나, 진입하더라도 즉시 이탈하도록 만드는 제약 조건이다. 이 정의에 따르면, 좋은 Control은 몇 가지 공통된 성질을 가진다.
첫째, Control은 개인의 주의력이나 성실함에 과도하게 의존하지 않는다.
독립성: 개인의 선의나 주의력에 과도하게 의존하지 않는다.
둘째, 조건이 충족되지 않으면 다음 단계로 진행할 수 없도록 강제한다.
강제성: 조건이 충족되지 않으면 위험 상태로 진입할 수 없게 만든다.
셋째, Control이 작동했는지 여부를 외부에서 확인할 수 있어야 한다.
가시성: 작동 여부를 확인할 수 있다.
마지막으로, 실제로 위험을 줄였는지 검증할 수 있어야 한다.
검증 가능성: 실제로 위험을 줄였는지 확인할 수 있다.
이 기준을 충족하지 못하는 Control은 대부분 권고사항, 교육, 절차, 주의 문구의 형태로 남는다. 이러한 요소들은 사고 이후에만 존재감을 드려내기에 보조 수단으로는 의미가 있지만, 그것만으로 위험을 통제했다고 말할 수는 없다.
Hierarchy of Controls는 안전 조치를 분류하기 위한 편의적 목록이 아니다. 이 구조는 인간과 조직, 그리고 기술 시스템의 실패 확률을 전제로 설계된 우선순위 체계다. 상위 단계일수록 사람의 개입 이전에 위험을 제거하거나 제한하며, 하위 단계로 갈수록 인간의 판단과 행동에 의존하게 된다.
1) Elimination (제거)
위험 자체를 시스템에서 없애는 것. 가장 강력하지만 가장 어렵다. 설계 초기 단계에서만 현실적으로 가능하다.
장점: 사고 경로 자체가 사라진다.
한계: 기존 시스템에는 적용이 제한적이다.
2) Substitution (대체)
위험한 요소를 덜 위험한 요소로 바꾼다.
예: 고온 공정 → 저온 공정, 독성 물질 → 저독성 물질
한계: ‘덜 위험할 뿐’ 위험은 남아 있다.
3) Engineering Controls (공학적 제어)
시스템이 스스로 위험을 차단하거나 완화하도록 만든다.
인터락, 가드, 자동 차단, 소프트웨어 제한 로직
시스템 안전에서 가장 핵심적인 영역
이 단계부터 Control은 사람의 판단 이전에 작동해야 한다.
4) Administrative Controls (관리적 제어)
절차, 규정, 교육, 체크리스트
장점: 비교적 빠르게 도입 가능
치명적 한계: 사람이 항상 올바르게 행동할 것이라는 가정
5) PPE (개인 보호구)
사고를 막지 못하고, 결과를 완화할 뿐이다.
Hierarchy의 하단에 위치한 이유는 명확하다. 사고는 이미 발생한 이후다.
이 순서는 도덕적 판단이 아니라, 실패 가능성의 구조를 반영한 결과다.
‘무엇을 추가할까’ VS ‘어디서 막을까’
좋은 Control 설계는 새로운 장치를 추가하는 문제라기보다, 위험 전이가 시작되는 지점을 정확히 찾는 문제에 가깝다. 시스템 안전 엔지니어는 사고 시나리오를 따라가며, 어디에서 위험을 가장 효과적으로 차단할 수 있는지를 고민하며 다음 질문을 던진다.
위험 전이가 시작되는 최초 지점은 어디인가?
인간 개입 이전에 차단할 수 있는 지점은 없는가?
이 Control이 실패하면, 다음 방어선은 존재하는가?
이 과정에서 중요한 질문은 단순하다. 인간의 개입 이전에 차단할 수 있는가, 하나의 Control이 실패했을 때 다음 방어선이 존재하는가, 그리고 이 Control은 실제 운영 환경에서도 동일하게 작동하는가다. 단일 Control에 의존하는 시스템은 취약하다. 의미 있는 안전은 항상 다층적 Controls 구조에서 나온다.
문서에 존재하는 Control은 아직 Control이 아니다. Control이 시스템에 내재화되기 위해서는 설계 산출물, 테스트, 운영 과정 전반에 걸쳐 일관되게 반영되어야 한다. 요구사항에 명시되고, 인터페이스 정의에 포함되며, 시험을 통해 검증되고, 운영 데이터로 감시되어야 한다.
특히 소프트웨어 중심 시스템에서는 Control 로직이 기능 요구사항에 밀려 후순위로 취급되는 순간, 안전은 선택 사항이 된다. 우회(Bypass)가 가능한 Control이라면, 그 우회가 언제, 왜 발생했는지 기록되고 검토될 수 있어야 한다.
시스템은 시간이 지나며 변화한다. 운영 환경이 바뀌고, 사용자가 달라지며, 기술 스택과 규제 조건도 변한다. 따라서 Control은 고정된 해답이 아니라, 지속적으로 관리되어야 할 살아 있는 설계 요소다.
변경 관리 과정(Change Management)에서 Control에 미치는 영향을 평가하지 않는다면, 의도치 않게 완화 강도를 약화시킬 수 있다. 사고와 근접사고(Near Miss), 운영 데이터는 Control의 유효성을 점검하는 중요한 신호다. 또한 새로운 Hazard가 등장 시 재평가가 필요하다. Control을 유지한다는 것은 동일한 문서를 유지하는 것이 아니라, 동일한 안전 수준을 유지하는 것이다.
모든 Risk를 Control로 완전히 제거하는 것은 현실적으로 불가능하다. 기술적 한계, 비용 제약, 운영 복잡성, 인간–시스템 상호작용의 불확실성 때문에 어떤 위험은 끝내 시스템 안에 남는다. 이때 시스템 안전의 핵심은 Risk를 없애는 데 실패했는가가 아니라, 남아 있는 Risk를 어떻게 다루기로 결정했는가에 있다.
닫히지 않는 Risk는 반드시 의식적으로 관리되어야 한다. 명시적인 Risk Acceptance는 “어쩔 수 없다”는 포기가 아니라, 어떤 조건에서 어떤 위험을 감수하겠다는 조직 차원의 결정이다. 여기에 운영 범위(Operating Envelope)를 명확히 정의함으로써, 시스템이 안전하다고 판단된 조건을 벗어나지 않도록 제한할 수 있다. 또한 조기 탐지와 회복(Detection & Recovery) 전략은 위험이 사고로 확대되기 전에 이상 상태를 인지하고, 시스템을 다시 안전한 상태로 되돌리는 마지막 방어선이 된다.
Risk를 남겨두는 것과, 그 존재를 인식하지 못한 채 방치하는 것은 전혀 다른 문제다. 시스템 안전에서 진짜 위험은 남아 있는 Risk 그 자체가 아니라, 그 Risk가 통제 구조 밖에 놓여 있다는 사실이다. 관리되지 않는 Risk는 언제든지 예기치 않은 조건에서 사고로 전이될 수 있다.
Hierarchy of Controls는 여전히 강력한 프레임워크지만, 복잡한 소프트웨어 중심 시스템에서는 이것만으로 충분하지 않은 경우가 많다. 현대 시스템의 사고는 단일 위험 요소를 제거하지 못해서 발생하기보다, 통제 구조 전반에서의 상호작용 실패로 발생하기 때문이다.
STPA(System-Theoretic Process Analysis)는 이러한 관점에서 Control 실패를 개별 조치의 문제로 보지 않고, 제어 구조와 피드백 메커니즘의 문제로 해석한다. Resilience Engineering은 사고를 완전히 예방하는 것만큼이나, 실패를 얼마나 빨리 감지하고 회복할 수 있는지를 중요한 안전 능력으로 다룬다. Safety by Design 접근은 기능과 안전을 분리된 목표가 아니라, 설계 단계에서부터 함께 최적화해야 할 시스템 속성으로 본다.
이러한 접근들은 Control을 단순히 위험을 ‘차단’하는 장치로 보지 않는다. 대신 Control을 시스템의 행동을 지속적으로 제약하고, 조정하며, 안전한 경로로 유도하는 메커니즘으로 확장한다. 이는 복잡한 현대 시스템에서 안전을 유지하기 위한, Hierarchy of Controls 이후의 사고방식이다.
Controls는 사고 이후 책임의 소재를 설명하거나 분산시키기 위해 존재하지 않는다. 그것은 이 시스템 안에서 어떤 위험까지를 받아들이고, 어떤 지점에서는 반드시 멈추겠다는 결정을 사전에 구조로 고정해 둔 흔적이다. 다시 말해 Control은 안전에 대한 의도의 선언이 아니라, 위험을 다루는 방식에 대한 집단적 합의가 물리적·논리적 형태로 구현된 결과다.
Hierarchy of Controls는 이러한 결정을 도덕이나 규범이 아닌, 인간과 시스템의 한계를 전제로 구조화한 프레임워크다. 위로 갈수록 사람의 판단 이전에 위험을 제거하고, 아래로 갈수록 인간의 개입에 의존하도록 배치된 이 질서는, 우리가 얼마나 쉽게 실수하고 얼마나 자주 시스템이 기대와 다르게 행동하는지를 냉정하게 인정한 결과다.
시스템 안전 엔지니어의 역할은 이 구조를 이해하는 데서 끝나지 않는다. 그것을 현실의 시스템 속에 구현하고, 운영과 변화의 과정 속에서도 그 의미가 희석되지 않도록 유지하는 데 있다. Control이 문서로만 존재하는 순간, 안전은 이미 시스템 밖으로 밀려난다. 반대로 Control이 설계와 인터페이스, 운영 데이터와 피드백 루프 안에서 살아 움직일 때, 안전은 비로소 시스템의 속성이 된다.
안전은 선언으로 달성되지 않는다. 그것은 매 순간 작동하고, 때로는 사람의 선택을 거부하며, 위험한 경로로의 진입을 묵묵히 차단하는 Control 안에서만 존재한다. 결국 시스템의 안전 수준은 우리가 얼마나 많은 위험을 인식했는지가 아니라, 그 인식을 얼마나 단단한 Control로 고정해 두었는가에 의해 결정된다.