잘 참고 버티는 사람에게는 역치값이 높다는 말을 흔히 한다. 그러나 그 말은 중요한 질문 하나를 의도적으로 비켜간다. 이 사람은 어디까지 버틸 수 있는 존재로 만들어졌는가, 그리고 그 고통을 끝까지 견뎌야 할 책임은 누구에게 있는가. 버틴다는 사실 자체보다, 그 한계가 어디로 설정되었는지가 훨씬 더 중요하다.
같은 이유로, 이 이야기에서 사람을 시스템으로 바꾸는 순간 가장 먼저 던져야 할 질문은 기능도, 성능도 아니다. 아마도 첫 질문은 이것일 것이다.
“이 시스템의 범주는 어디까지인가?”
다시 말해, 무엇을 시스템의 책임으로 삼고, 무엇을 세계의 조건으로 남길 것인가에 대한 질문이다.
시스템 안전 분석을 시작할 때 우리는 종종 위험 식별이나 요구사항 정의부터 떠올린다. 그러나 그 이전에 반드시 명확해져야 할 질문이 있다.
“이 시스템은 어디서 시작하고, 어디서 끝나는가?”
이 질문에 답하지 않은 채 진행되는 모든 안전 활동은, 출발지 없이 지도를 그리는 것과 다르지 않다.
현재의 시스템은 더 이상 고립된 기계가 아니다. 소프트웨어는 클라우드와 연결되고, 하드웨어는 외부 인프라와 깊이 얽히며, 운영 책임은 조직의 경계를 넘어 이동한다. 시스템은 이제 하나의 물건이 아니라, 수많은 관계 속에서 작동하는 존재가 되었다. 이런 환경에서 시스템 경계(System Boundary)를 잘못 설정하면 어떤 일이 벌어질까.
설계자가 통제할 수 없는 영역까지 책임을 떠안게 된다
안전 요구사항이 무한히 확장된다
위험 분석은 과도하게 복잡해지고 실효성을 잃는다
사고 발생 시, 책임 소재는 불명확해진다
그럼에도 불구하고 시스템 안전에서 경계 설정은 여전히 분석의 ‘준비 단계’ 정도로 취급된다. 하지만 실제로 경계를 긋는 순간 우리는 단순히 범위를 정의하는 것이 아니라, 어디까지를 설계로 통제하겠다고 약속할 것인지, 그리고 어디부터는 통제할 수 없는 세계로 인정할 것인지를 선언한다. 이 선언은 기술적 판단인 동시에 윤리적 선택이다.
문제는 이 선언이 너무 자주 무의식적으로 이루어진다는 점이다. “안전하니까”, “혹시 모르니까”, “나중에 문제 될 수 있으니까”라는 막연한 불안은 시스템의 경계를 끝없이 넓힌다. 그 결과 시스템은 점점 전능한 존재가 되어야 하고, 설계자는 세상의 모든 실패를 떠안는 위치로 밀려난다. 그렇게 만들어진 안전 분석은 현실과 단절된 추상이 된다.
시스템 안전에서 경계 설정은 단순한 범위 정의가 아니다.
“이 위험은 우리가 설계로 통제할 수 있는가?”라는 질문에 대한 조직적 합의이며, 시스템 엔지니어링 V-모델에서 환경을 이해하는 단계에서 시스템을 정의하는 단계로 넘어가는 결정적 전환점이다.
그리고 이 지점에서 시스템 안전은 기술의 문제가 아니라, 책임을 어디까지 감당할 것인가에 대한 사유의 문제로 바뀐다.
경계를 설정한다는 것은 세계를 통제 가능성과 불가능성으로 나누는 일이다. 시스템 안전 엔지니어의 첫 질문은 “무엇이 위험한가”가 아니라, “무엇을 우리가 바꿀 수 있는가”여야 한다. 우선 시스템을 둘러싼 모든 요소를 나열하고, 이를 통제 가능성 기준으로 분류하는 것으로 모든 일은 시작된다. 이때 유용한 도구가 System Boundary Chart다.
1) 내부 변수 (Internal / Endogenous)
내부 변수는 설계자의 의지가 물리적으로, 논리적으로 반영될 수 있는 영역이다. 코드 한 줄, 밸브의 위치, 센서의 임계값은 인간의 판단이 직접 개입되는 지점이다. 이 영역에서 발생한 위험은 변명의 여지가 없다. 통제 가능했음에도 통제하지 않았다면, 그것은 설계의 실패다.
엔지니어가 직접 설계·변경·검증할 수 있는 요소들은
소프트웨어 코드, 알고리즘
내부 안전 센서
연료 유입 형상, 제어 로직
인터록, 경보 조건
등이 있다.
이 경계 안으로 속한 요소는 안전 요구사항으로 귀결되어야 하며, 위험은 설계로 제거·완화하는 것이 원칙이다.
2) 외부 변수 (External / Exogenous)
반대로 외부 변수는 시스템이 살아가기 위해 받아들여야 하는 세계의 조건이다. 날씨, 사용자, 외부 인프라는 위험의 원천이 될 수 있지만, 설계자의 의지로 재구성할 수는 없다. 이 영역을 내부로 착각하는 순간, 시스템은 스스로를 신처럼 여기기 시작한다. 모든 것을 통제할 수 있다는 착각은, 시스템 안전에서 가장 위험한 오만이다.
시스템이 의존하지만 직접 통제할 수 없는 요소들이다.
사용자 행동
외부 인프라(도로, 전력망, 통신망)
기상 조건
외부 장비 호환성
여기는 위험 식별 대상이지, 설계 통제 대상이 아니다. 여기서 발생하는 문제를 내부 설계 실패로 취급하면 시스템은 과잉 설계로 붕괴된다.
3) 제외 요소 (Excluded)
마지막으로 제외된 요소들은 무책임의 결과가 아니라, 사유의 절제다. 모든 것을 고려하겠다는 태도는 성실해 보이지만, 실제로는 아무것도 책임지지 않겠다는 선언과 다르지 않다.
의도적으로 안전 분석 범위에서 제외한 요소들로는:
시스템 목적과 무관한 사회적 변수
조직 통제 밖의 정책 결정
분석 가치가 없는 극단적 시나리오
등이 있다.
제외는 무책임이 아니다. 범위 통제를 하지 않으면 안전 분석 자체가 성립하지 않는다.
우리는 여전히 경계를 물리적인 선으로만 이해하려는 경향이 있다. 그러나 현대 시스템에서 가장 치명적인 사고는 눈에 보이지 않는 경계에서 발생한다.
1) 물리적 경계 (Physical Boundary)
물리적 경계는 명확하다. 이 밸브까지가 시스템이고, 이 커넥터 너머는 외부다. 이러한 경계는 사고 이후에도 가장 먼저 확인되는 기준점이며 비교적 쉽게 합의된다. 여기서 경계가 모호하면, 설계 책임과 운영 책임이 뒤섞인다.
Note. 정리
물리적 경계는 눈에 보이고 만질 수 있는 경계다.
장비의 마지막 밸브
커넥터, 플랜지
시설과 시스템의 접점
2) 논리적 경계 (Logical Boundary)
논리적 경계는 다르게 다루어진다. 데이터는 흐르고, 권한은 전이되며, 책임은 흐릿해지기에, 논리적 경계를 명확히 설정하지 못한 시스템은, 외부의 실패를 내부의 결함으로 오해한다. 이는 설계 실패보다 더 큰 위험을 동반한다. 문제의 원인을 잘못된 곳에서 찾기 시작하면, 시스템은 끊임없이 잘못된 방향으로 진화하기 때문이다.
Note. 정리
논리적 경계는 디지털 시대에 더 위험한 경계다.
네트워크 분리 지점
소프트웨어 애플리케이션 범위
데이터 파이프라인의 시작과 끝
경계를 설정한다는 것은 단지 선을 긋는 것이 아니라, 어디까지를 ‘내가 이해하고 있는 세계’로 인정할 것인가를 결정하는 행위다.
시스템의 경계는 기능에서 시작되지 않는다. 그것은 언제나 목적에서 출발한다. 우리는 종종 시스템이 할 수 있는 일의 목록을 나열한 뒤 그 범위를 경계로 착각하지만, 시스템 안전의 관점에서 더 중요한 질문은 따로 있다.
“이 시스템은 무엇을 하기 위해서가 아니라, 어떤 손실을 막기 위해 존재하는가?”
인명 손실, 자산 손실, 환경 손실, 그리고 사회적 신뢰의 붕괴. 이러한 손실이 발생하는 지점이 바로 시스템과 세계의 경계가 흔들리는 지점이다. 시스템 안전은 기능을 얼마나 정교하게 구현했는가의 문제가 아니다. 손실이 발생하지 않도록 시스템이 세계와 어떤 거리를 유지하고 있는가에 대한 문제다. 손실을 기준으로 바라보면, 시스템이 책임져야 할 영역과 그렇지 않은 영역은 자연스럽게 구분된다.
이 목적은 곧 경계에서 요구되는 기능의 성격을 결정한다. 시스템 경계에서 정의되는 기능은 반드시 관측 가능해야 한다. 무엇이 입력되고, 무엇이 출력되며, 정상 상태와 실패 상태는 어떻게 구분되는가. 이 질문에 답할 수 없는 기능은 안전 요구사항이 될 수 없다. 관측할 수 없다면 검증할 수 없고, 검증할 수 없다면 개선도 불가능하기 때문이다. 그런 기능은 안전이 아니라 단지 기대에 불과하다.
System of Interest(SoI)와 환경을 구분하는 기준 역시 동일하다. 어디에서 손실이 발생하는가를 기준으로 인터페이스를 정의하면, 시스템 경계는 인위적으로 그어지지 않는다. 손실을 막기 위해 반드시 통제해야 하는 지점만이 경계 안으로 들어오고, 그 외의 요소는 환경으로 남는다.
결국 목적 중심의 경계 설정이란, 시스템이 무엇을 할 수 있는지를 나열하는 일이 아니라 무엇에 대해 책임지겠다고 말할 것인지를 분명히 하는 일이다. 그리고 그 책임은 언제나, 손실이 발생하는 지점에서 시작된다.
경계 설정은 한 번의 판단으로 끝나지 않는다. 그것은 반복적인 질문과 합의를 통해 점진적으로 단단해진다. 설계 초기에 그어진 경계는 가설에 불과하며, 실제 프로토타입과 테스트, 운영 시나리오를 거치며 수정되어야 한다.
중요한 것은 모든 이해관계자가 같은 경계를 바라보고 있다는 확신이다. 유지보수 조직, 운영자, 규제 기관이 각자 다른 경계를 상정한 채 시스템을 다루기 시작하면, 사고는 시간문제가 된다.
문서화는 이 합의를 고정하는 행위다. 다이어그램과 P&ID에 남겨진 경계는 단순한 그림이 아니라, 사고 이후에도 흔들리지 않는 기억 장치다.
Note. 정리
전문적인 시스템 안전 프로젝트에서 사용하는 현실적인 절차는 다음과 같다.
시스템 목적과 안전 목표 정의
모든 변수 나열
내부 / 외부 / 제외 분류
물리적·논리적 경계 정의
인터페이스 식별
경계 기반 안전 요구사항 도출
아키텍처 다이어그램, P&ID에 명시
이해관계자 합의 확보
설계 진척에 따라 반복적 재정의
경계 설정은 한 번으로 끝나지 않는다. 설계가 진화하면 경계도 함께 진화해야 한다.
경계 밖의 위험을 다루는 가장 성숙한 방법은, 그것을 억지로 안으로 끌어들이지 않는 것이다. 위험을 이전하고, 인터페이스로 제한하고, 계약과 절차로 명확히 하는 것은 회피가 아니다. 그것은 책임의 재배치다.
“이 위험을 우리는 인지했으며, 그러나 이 시스템이 통제할 수 있는 영역은 아니다.”
이 문장을 문서로 남길 수 있을 때, 시스템은 비로소 정직해진다.
경계 밖 위험을 내부 설계로 끌어들이는 것은 가장 흔한 오류다. 대신 다음 전략을 사용해야 한다.
계약 조건으로 위험 이전
인터페이스 요구사항으로 제한
운영 절차로 관리
사용자 책임 명확화
규제 기준 준수로 정당화
중요한 것은 문서화다.
“이 위험은 인지되었고, 의도적으로 시스템 경계 밖에 남겨졌다”
는 증거가 있어야 한다.
경계 안에 포함된 위험에 대해서는 침묵이 허용되지 않는다. 이 영역에 들어온 순간, 그 위험은 이미 “인지된 위험”이 아니라 “책임이 확정된 위험”이 된다. 그럼에도 불구하고 우리는 종종 교육, 주의 문구, 절차서와 같은 언어로 이 책임을 덮으려 한다. 그러나 이러한 수단은 통제가 아니라, 설계가 응답하지 못한 자리를 대신 채우는 설명에 불과하다.
경계 안 위험에 대해 시스템이 취할 수 있는 태도는 명확하다. 위험은 제거되거나, 대체되거나, 공학적으로 통제되어야 한다. 그것이 불가능할 경우에도 경보와 인터록을 통해 실패가 드러나도록 만들어야 하며, 이 모든 선택은 검증 가능한 요구사항으로 남아야 한다. 여기에는 타협의 여지가 없다.
이 지점에서 시스템 안전은 더 이상 기술의 문제가 아니다. 통제할 수 있었던 위험을 그대로 두는 것은 계산의 실패가 아니라 의도적인 선택이 된다. 그리고 그 선택은 결국, 누가 어떤 손실을 감당하도록 만들 것인가에 대한 윤리적 판단으로 귀결된다.
따라서 경계 안 위험은 말로 설명될 수 없다. 그것은 반드시 설계 변경, 물리적 차단, 논리적 인터록이라는 구체적인 설계 산출물로만 응답되어야 한다. 교육과 경고는 그 이후에야 의미를 갖는다.
아무리 정교하게 설정된 시스템 경계라도 미래를 완벽히 예측할 수는 없다. 시스템은 시간이 지나며 다른 방식으로 사용되고, 조직은 변화하며, 외부 시스템과 환경 역시 계속해서 진화한다. 오늘의 합리적인 경계는 내일의 불충분한 가정이 될 수 있다. 이 사실을 인정하지 않는 경계만이 위험하다.
그렇기 때문에 경계 설정의 목표는 처음부터 완벽한 답을 찾는 데 있지 않다. 중요한 것은 왜 이 경계를 이렇게 설정했는지, 그 판단이 어떤 가정 위에 세워졌는지, 그리고 시간이 흐른 지금 무엇이 달라졌는지를 설명할 수 있는가다. 경계가 변할 수 있다는 사실보다 더 중요한 것은, 그 변화가 추적 가능하게 관리되고 있는지 여부다.
시스템 안전에서 경계 설정은 정답을 선언하는 행위가 아니라, 합리적인 합의를 기록하는 행위다. 그리고 그 기록이 남아 있는 시스템만이, 사고 이후에도 자신이 왜 그런 선택을 했는지를 설명할 수 있고, 그 설명이 가능한 시스템만이 존중받는다.
시스템 경계는 도면 위에 그어진 선이 아니다. 그것은 설계자가 세계를 어떻게 이해하고 있는지, 그리고 어느 지점까지 책임을 감당하겠다는 태도를 드러내는 선언이다. 시스템 안전에서 경계 설정은 기술적 판단처럼 보이지만, 실제로는 통제와 손실을 어디까지 받아들이겠다는 결단에 가깝다.
잘 설정된 경계는 시스템을 보호한다. 동시에 설계자를 보호하고, 사고 이후에도 안전 논리가 무너지지 않도록 지켜낸다. 반대로 잘못된 경계는 선의에서 출발했을지라도 설계자를 과도한 책임으로 밀어 넣고, 결국 누구도 책임질 수 없는 시스템을 만든다. 이때 안전 분석은 존재했지만, 아무도 지켜주지 못하는 문서로 남는다.
시스템 안전은 모든 위험을 제거하겠다는 약속이 아니다. 그것은 어떤 위험은 우리가 책임지고 통제하겠다고 말하고, 어떤 위험은 명확한 이유를 들어 경계 밖에 둔다고 말할 수 있는 능력이다. 이 구분이 가능할 때에만 안전 요구사항은 날카로워지고, 시스템은 현실과 연결된다.
사람에게 역치값이 있듯, 시스템에도 감당할 수 있는 한계가 있다. 문제는 그 한계를 명확히 정의하지 않은 채, 끝까지 버티기를 요구하는 데 있다. 시스템 경계는 그 역치값을 설계의 언어로 드러내는 행위다. 어디까지를 견디도록 만들 것인가, 그리고 그 너머의 고통은 누구의 몫으로 남길 것인가를 분명히 하는 것.
그 용기에서 시스템 안전은 시작된다.
그리고 그 시작점이 바로, 시스템 경계다.