많은 조직은 사고가 발생한 뒤에야 비로소 “요구사항이 부족했다”는 결론에 도달한다. 그러나 시스템 안전 엔지니어의 시선으로 사고를 되짚어 보면, 그 원인은 사고 직전의 운용이나 단일 설계 오류에 있지 않은 경우가 대부분이다. 사고의 씨앗은 훨씬 이전, 개념 설계 단계에서 이미 뿌려진다. 그 단계에서 명확히 정의되지 않았던 안전 요구, 여러 방식으로 해석될 수 있도록 남겨진 기준, 그리고 애초에 검증이 불가능했던 문장 하나가 프로젝트의 다음 단계를 거치며 그대로 굳어지고, 수년의 시간 차를 두고 현실의 사고로 되돌아온다.
Safety Requirements / Criteria Analysis(SRCA)는 바로 이 취약한 지점을 겨냥한 분석이다. SRCA는 새로운 위험을 찾아내는 활동이 아니다. 그것은 위험이 시스템 안으로 유입되는 순간을 요구사항 단계에서 차단하기 위한 방어 작업이며, 안전 요구사항이 실제로 위험을 통제할 수 있는 수준과 형태로 정의되었는지를 끝까지 확인하는 과정이다. 이 단계에서 요구사항이 모호하거나 느슨하게 남겨진다면, 이후 아무리 정교한 시험과 검증을 수행하더라도 시스템에 내재된 근본적인 안전 결함은 제거되지 않는다.
시스템 안전 엔지니어로 일하다 보면 이러한 구조를 반복해서 확인하게 된다. 사고나 중대한 결함이 발생한 뒤 원인을 추적해 올라가다 보면, 최종적으로 도달하는 지점은 종종 설계 오류나 구현 실수가 아니라 요구사항 단계에서 내려진 판단이다. 위험은 이미 인지하고 있었지만 요구사항으로 명확히 제한하지 않았거나, 안전을 확보하기에는 턱없이 부족한 기준을 ‘현실적인 선택’이라는 이름으로 수용했던 결정들이 시간이 지나면서 실제 사고의 형태로 모습을 드러낸다. 이러한 경험은 안전이 분석 기법의 수나 시험의 강도에 의해 보장되는 것이 아니라, 위험을 어떻게 요구사항이라는 언어로 고정했는지에 의해 결정된다는 사실을 분명히 보여준다. SRCA는 바로 이 지점에서 시스템 안전 엔지니어가 수행하는 가장 근본적이고도 결정적인 방어 활동이다.
SRCA(Safety Requirements / Criteria Analysis)는 시스템에 부여된 안전 요구사항과 그 수용 기준이 실제로 위험을 통제할 수 있는 수준으로 정의되어 있는지를 검증하는 체계적인 분석 활동이다. 많은 사람들이 SRCA를 단순한 요구사항 리뷰나 문서 검토 정도로 오해하지만, 시스템 안전 관점에서 SRCA는 위험 분석 결과가 설계와 구현 단계로 전달되기 직전에 거치는 논리적 검증 관문이다. FHA, PHA, HAZOP, FTA 등에서 도출된 위험은 그 자체로는 아무것도 바꾸지 않는다. 그것이 요구사항이라는 구속력 있는 형태로 변환되어야만 시스템의 구조와 동작을 제한할 수 있다. SRCA는 이 변환 과정에서 의미가 왜곡되거나, 강도가 약화되거나, 아예 누락되는 순간을 찾아내는 역할을 한다. 다시 말해 SRCA는 “이 요구사항이 정말 위험을 막고 있는가?”라는 질문을 끝까지 밀어붙이는 분석이다.
Note 정리.
SRCA(Safety Requirements / Criteria Analysis)는 시스템에 부여되는 모든 안전 요구사항과 수용 기준이
위험을 충분히 통제하는지,
모호하지 않은지,
검증 가능한지,
상위 위험 분석 결과와 논리적으로 연결되는지를 체계적으로 검토하는 활동이다.
중요한 점은 SRCA가 “새로운 위험을 식별하는 분석”이 아니라는 것이다.
그렇다면, 프로젝트에서 SRCA가 사용되는 시점과 위치를 알아보자. SRCA는 특정 단계에만 수행되는 독립적인 일회성 활동이 아니라, 시스템 생명주기 전반에 걸쳐 반복적으로 적용되는 안전 관리 활동이다. 개념 설계 단계에서는 시스템 안전 목표와 상위 위험 통제 전략이 요구사항으로 충분히 분해되었는지를 검토하며, 이 단계의 SRCA는 이후 모든 설계 판단의 기준선을 형성한다. 상위 설계 단계에서는 시스템 레벨 안전 요구사항이 하위 서브시스템과 소프트웨어 요구사항으로 누락 없이 할당되었는지를 확인하며, 이때 요구사항 간 책임 분리가 핵심 이슈가 된다. 상세 설계와 구현 단계에서는 설계 선택이나 인터페이스 정의가 기존 안전 요구사항을 암묵적으로 약화시키지 않았는지를 검증한다. 마지막으로 검증 및 인증 단계에서의 SRCA는 요구사항이 실제 시험과 분석으로 입증 가능한 상태인지, 즉 형식적 안전이 아닌 실질적 안전으로 이어질 수 있는지를 재확인하는 역할을 한다. 이처럼 SRCA는 프로젝트의 한 단계를 통과하기 위한 산출물이 아니라, 각 단계에서 안전 논리가 유지되고 있는지를 확인하는 연속적 점검 장치다.
Note.
단계별 정리
개념/요구사항 정의 단계 시스템 안전 목표(Safety Objectives)가 요구사항으로 적절히 분해되었는지 검토
상위 설계 단계 시스템 레벨 안전 요구가 서브시스템 요구로 누락 없이 할당되었는지 확인
상세 설계 및 구현 단계 설계 선택이 안전 요구를 훼손하지 않는지 점검
검증/인증 단계 요구사항이 실제로 검증 가능한 형태인지 재확인
특히 항공, 철도, 방산, 원자력과 같은 고위험 산업에서는 SRCA 결과가 인증 기관과의 기술적 신뢰를 형성하는 핵심 근거가 된다.
SRCA는 정해진 체크리스트를 기계적으로 적용하는 활동이 아니라, 위험과 요구사항 사이의 논리를 따라가는 사고 과정이다. 먼저 시스템 안전 계획과 위험 분석 산출물, 규제 요구사항, 그리고 시스템 요구사항 명세서를 입력 자료로 삼아 안전과 직접적으로 연관된 요구사항을 식별한다. 이때 중요한 것은 ‘안전 관련’이라는 표현이 아니라, 해당 요구사항이 제거되거나 완화될 경우 위험이 다시 허용되는지를 기준으로 판단하는 것이다. 이후 각 안전 요구사항에 대해 문장의 명확성, 단일성, 조건 정의, 그리고 검증 가능성을 집중적으로 분석한다. 요구사항이 모호한 표현에 의존하거나, 여러 조건을 한 문장에 섞어 놓았다면 그것은 이미 안전 통제 수단으로서 실패한 것이다. 다음 단계에서는 각 요구사항이 어떤 위험 시나리오를 통제하기 위해 존재하는지 명확히 연결하며, 위험과 요구사항 간의 추적성을 통해 논리적 공백이나 과잉 통제를 식별한다. 마지막으로 수용 기준을 검토하여 “요구사항을 만족했다”는 판단이 주관적 해석이 아니라 객관적 검증 결과로 귀결될 수 있는지를 확인한다. 이 전 과정은 문서 검토가 아니라, 시스템이 위험한 상태로 진입하지 않도록 논리적 울타리를 세우는 작업이다.
1) 입력 자료 식별
SRCA는 단독으로 존재할 수 없다. 다음 자료가 입력으로 필요하다.
시스템 안전 계획(SSP)
FHA / PHA / HAZOP 결과
상위 안전 목표 및 규제 요구사항
시스템/서브시스템 요구사항 명세서
2) 안전 요구사항 추출
전체 요구사항 중 안전 관련 요구사항(Safety-Critical Requirements)을 식별한다.
이 단계에서 자주 발생하는 오류는 “기능 요구사항 = 안전 요구사항”으로 착각하는 것이다.
3) 요구사항 품질 분석
각 요구사항을 다음 기준으로 검토한다.
모호성 여부 (“적절히”, “가능한 한” 같은 표현)
단일성(하나의 요구사항에 여러 의미가 섞여 있지 않은가)
검증 가능성(Testable / Verifiable)
조건 및 한계의 명확성
4) 위험-요구사항 추적성 확인
각 안전 요구사항이 어떤 위험을 통제하기 위해 존재하는지를 명확히 연결한다.
위험은 있는데 요구사항이 없거나, 요구사항은 있는데 연결된 위험이 없다면 둘 다 문제다.
5) 수용 기준(Criteria) 검토
“만족한다”는 것이 무엇을 의미하는지 수치, 조건, 상태로 정의되어 있는지 확인한다.
수용 기준이 없다면 해당 요구사항은 사실상 검증 불가능하다.
6) 불일치 및 공백 식별
중복 요구사항, 상충 요구사항, 누락된 요구사항을 도출하고 개선 권고안을 작성한다.
SRCA는 강력하지만 만능은 아니다. SRCA는 강력한 분석 도구이지만, 그 효과는 입력과 조직 환경에 크게 의존한다. 위험 분석이 피상적으로 수행되었거나, 조직 차원에서 이미 일정과 비용을 이유로 위험 수용이 결정된 상태라면 SRCA는 형식적인 승인 절차로 전락하기 쉽다. 또한 복잡한 소프트웨어 중심 시스템에서는 요구사항 문장만으로 동적 상호작용과 시간 의존적 위험을 충분히 포착하기 어렵다는 구조적 한계도 존재한다. 무엇보다도 SRCA는 “불편한 질문”을 던지는 활동이기 때문에, 조직 문화가 이를 환영하지 않을 경우 실질적인 개선으로 이어지기 힘들다. 이 한계들은 SRCA가 기술적 기법이면서 동시에 조직의 안전 성숙도를 드러내는 거울이라는 사실을 보여준다.
위험 분석 자체가 부실하면 SRCA도 한계를 가진다
조직 문화가 “요구사항은 형식”이라고 인식하면 실효성이 떨어진다
일정 압박 속에서는 문장 검토 수준으로 축소되기 쉽다
소프트웨어 중심 시스템에서는 동적 행위까지 포착하기 어렵다
SRCA는 분석 도구이기 이전에 사고방식의 문제이기도 하다.
실효성을 높이기 위해서는 요구사항을 설계 산출물이 아니라 위험 통제 장치로 인식하는 관점 전환이 필요하다. 안전 요구사항은 기능 요구사항과 동일한 형식으로 작성되지만, 그 목적은 기능 구현이 아니라 위험 차단에 있다. 따라서 위험 시나리오, 요구사항, 검증 방법을 하나의 연속된 논리로 묶어 관리해야 하며, 특히 소프트웨어 요구사항에서는 상태 전이, 경계 조건, 타이밍 제약을 명시적으로 포함해야 한다. 또한 독립적인 시각에서 요구사항을 재검토하는 절차를 도입하면, 프로젝트 내부에서 당연하게 받아들여진 위험 수용 판단을 다시 문제 삼을 수 있다. SRCA가 문서 리뷰가 아닌 사고 예방 활동으로 기능하려면, 이러한 구조적 개선이 필수적이다.
Note.
요구사항을 설계 산출물이 아닌 안전 통제 수단으로 인식하기
Hazard → Requirement → Verification의 논리를 항상 명시적으로 연결
소프트웨어 요구사항에는 상태, 타이밍, 경계조건을 반드시 포함
SRCA를 문서 리뷰가 아닌 시스템 사고 실험 과정으로 운영
독립적인 시각(Independent Safety Review) 도입
아마 SRCA는 시스템 안전 엔지니어가 수행하는 활동 중 가장 귀찮고, 가장 환영받지 못하는 작업일 것이다. 일정은 항상 촉박하고, 요구사항은 이미 “합의된 것”으로 취급되며, SRCA는 그 흐름을 다시 멈춰 세운다. 문장 하나하나를 붙잡고 왜 이렇게 써야 하는지, 이 기준으로 정말 위험이 통제되는지 묻는 과정은 팀 전체의 진도를 늦추는 일처럼 보인다. 나 역시 여러 프로젝트에서 SRCA를 수행하며 “이미 다 합의된 요구사항인데 왜 다시 보느냐”는 질문을 수없이 들어왔다. 그러나 시간이 지나 사고 조사나 중대한 결함 분석에 참여할 때마다, 그때 그 질문을 던지지 않았던 장면들이 선명하게 떠올랐다.
대부분의 사고는 절차를 따르지 않아서가 아니라, 위험을 허용한 절차와 요구사항을 너무나도 성실하게 따랐기 때문에 발생한다. 사고 조사 보고서에서 “요구사항은 충족되었다”는 문장이 반복해서 등장하는 이유도 여기에 있다. 문제는 사람들이 요구사항을 어겼느냐가 아니라, 그 요구사항 자체가 위험을 충분히 막을 수 있었느냐는 점이다. SRCA는 바로 이 모순을 정면으로 다룬다. 요구사항을 만족했다는 사실이 곧 안전을 의미하는 것인지, 아니면 조직이 암묵적으로 선택한 위험 수준을 그대로 재현했을 뿐인지를 구분해 내는 작업이 SRCA다.
현장에서 SRCA를 수행하다 보면 불편한 순간이 많다. 위험 분석에서는 분명 심각한 시나리오가 제시되었는데, 그것을 받아낸 요구사항은 “가능한 한”, “적절히”, “필요 시” 같은 표현으로 흐릿하게 작성된 경우를 자주 본다. 형식적으로는 요구사항이 존재하고, 검증 역시 통과할 수 있지만, 정작 그 요구사항을 충족했을 때 위험이 정말 차단되는지는 아무도 명확히 설명하지 못한다. 나는 이런 요구사항들을 그대로 두고 다음 단계로 넘어갔던 프로젝트가, 결국 운용 단계에서 반복적인 인적 판단과 임시 조치에 의존하게 되는 모습을 여러 번 목격했다. 그때마다 깨닫게 된다. SRCA에서 던지지 않은 질문은, 언젠가 현장에서 더 큰 대가로 되돌아온다는 사실을.
사고는 대부분 “요구사항을 지키지 않아서”가 아니라, 위험을 허용한 요구사항을 그대로 지켰기 때문에 발생한다. SRCA는 “이 요구사항을 충족하면 정말 안전한가?”라는 질문을 문서 한 줄, 기준 하나하나에 대해 집요하게 던지는 과정이다. 이 질문을 건너뛴 시스템은 결국 운용 단계에서 안전을 설계나 요구사항이 아니라 사람의 판단과 경험, 그리고 운에 맡기게 된다. 시스템 안전 엔지니어에게 SRCA는 규정을 만족시키기 위한 형식적 활동이 아니다. 그것은 위험을 어디까지 허용할 것인지에 대한 윤리적이고 기술적인 판단을 요구사항이라는 언어로 고정해 두는 작업이며, 사고가 발생하기 훨씬 이전에 수행해야 하는 가장 중요한 책임이다.
시스템 안전은 시험 단계에서 갑자기 확보되는 성질의 것이 아니다. 그것은 훨씬 이전, 우리가 어떤 위험을 정의했고 그 위험을 어떤 수준과 형태의 요구사항으로 제한했는지에서 이미 방향이 결정된다. 위험을 인지했다는 사실만으로 안전이 확보되지는 않는다. 그 위험이 요구사항이라는 구속력 있는 언어로 정확히 고정되고, 설계와 구현 전반에 걸쳐 일관되게 유지될 때 비로소 시스템은 위험한 상태로 진입하지 않도록 구조화된다. SRCA는 이러한 결정이 관성이나 일정 압박 속에서 무심코 이루어지지 않도록 붙잡아 두는 분석이며, 요구사항이 안전을 담보할 수 있는 수준으로 작성되었는지를 끝까지 확인하는 과정이다.
요구사항 하나하나는 단순한 문장이 아니다. 그것은 미래의 사고를 허용할 것인지, 아니면 그 가능성을 사전에 차단할 것인지에 대한 선택이다. 시스템 안전 엔지니어의 역할은 이 선택이 충분히 신중했는지를, 그리고 위험을 실제로 통제할 수 있는 강도를 갖추었는지를 끝까지 검증하는 데 있다. 아무리 정교한 위험 분석이 수행되었더라도, 그 결과가 요구사항으로 정확히 구현되지 않는다면 안전은 분석 보고서 안에만 머무를 뿐 현실에서는 작동하지 않는다.
SRCA는 행정 절차나 형식적인 검토 단계가 아니다. 그것은 위험이 시스템 안으로 들어오기 직전, 마지막 문 앞에 서서 요구사항을 하나씩 확인하는 안전 엔지니어의 질문이다.
“이 요구사항을 충족하면 우리는 정말 안전한가?”
라는 질문을 회피하지 않고 끝까지 붙잡는 것이 SRCA의 본질이며, 시스템 안전 엔지니어에게 부여된 가장 무거운 책임이다. SRCA는 안전을 문서로 설명하는 도구가 아니라, 안전이 실제 시스템과 현장에서 구현되도록 만드는 마지막 논리적 방어선이다.