STPASTPA 손실 시나리오 도출의 다음 단계: Class 조합 가이드워드 + MCP AI
요약
STPA(시스템 이론 기반 위험 분석)의 손실 시나리오는 보통 가이드워드 원형 하나를 골라 한 문장으로 씁니다. 그런데 사고 보고서에서 자주 보는 이야기는 "센서가 죽었는데 시스템은 마지막 값을 믿고 달렸다"처럼 두 원형에 걸쳐 있습니다. 이 글은 제어기·피드백·제어 경로·프로세스 네 Class의 원형 66개에서 교차 조합 원형 77개를 추려 가이드워드에 더하고, 고속도로 주행 보조 기능 교육용 예제에서 AI가 그 가이드워드로 손실 시나리오를 만들게 한 결과를 보여 줍니다. 조합 원형 11건 중 6건은 기준선에 없던 것, 2건은 부분, 2건은 설계 확인 전까지 질문, 1건은 중복이었습니다. 다만 6건 중 3건은 단일 원형을 더 골랐으면 닿을 수 있던 것이고, 대책이 달라진 것은 3건입니다. 내일 분석 중인 UCA 하나에 네 가지 질문을 던져 보시기 바랍니다.
장면: UCA 하나에 시나리오 두 개
고속도로에서 차선을 바꾸고 속도를 조절하는 주행 보조 기능을 STPA로 분석한다고 해 보겠습니다. 이 글의 예제는 교육용 가상 시스템이며 특정 제조사의 설계가 아닙니다(이하 NOA 예제). 제어기는 NOA 시스템, 제어행동은 속도 제어기에 보내는 "속도 요청", 피드백은 카메라·레이더·지도에서 들어옵니다. 비안전 제어행동(UCA) 하나는 "NOA가 제한속도를 넘는 속도를 요청한다"입니다.
이 UCA에 시나리오를 쓰는 가장 빠른 방법은 가이드워드 원형을 고르는 것입니다. 제어기 원형 "제어기가 실제와 다른 상태를 믿는다"를 고르면 "NOA가 오래된 지도 데이터로 제한속도를 110 km/h로 믿는데 실제 도로는 공사 구간 60 km/h다"가 됩니다. 피드백 원형 "센서 데이터 손상으로 피드백이 틀린다"를 고르면 "표지판 인식 오류로 60 km/h 표지판이 80으로 읽힌다"가 됩니다. 둘 다 맞는 시나리오입니다.
그런데 이 두 문장은 사고 보고서에서 자주 보는 이야기를 비껴갑니다. "안개로 카메라가 표지판을 못 읽었고, 시스템은 직전 제한속도를 그대로 쓰며 공사 구간에 들어갔다"는 이야기입니다. 앞부분은 피드백 원형이고 뒷부분은 제어기 원형입니다. 원형을 하나만 골라 문장을 끝내면 이 이야기는 반쪽만 남습니다. 센서 고장은 적지만 그 순간의 기본값은 적지 않고, 기본값 가정은 적지만 왜 그 순간 피드백이 없었는지는 적지 않습니다.
핸드북도, 표준도 이미 묻는다. 빠진 자리는 습관에 있다
MIT STPA Handbook(Leveson & Thomas, 2018)은 손실 시나리오를 두 부류로 나눕니다. 비안전 제어행동이 나오는 이유(제어기의 결함, 부적절한 피드백)와 제어행동이 제대로 실행되지 않는 이유(제어 경로, 피제어 프로세스)입니다. 핸드북은 첫 부류에서 프로세스 모델 결함의 원인을 피드백으로 거슬러 올라가라고 예시로 보여 주고, 둘째 부류에서는 명령이 실행되지 않았음을 제어기가 알 수 있는지 묻습니다. 이 글에서 쓴 원형 목록(VisualPro STPA 가이드워드 셋)은 핸드북의 두 부류를 제어기·피드백·제어 경로·프로세스 네 Class로 나누고, Class마다 "제어기가 오래된 상태를 믿는다", "피드백이 지연된다", "작동기가 명령을 무시한다", "프로세스가 입력 없이 자동 반응한다" 같은 원형 문장을 둡니다. 모두 66개입니다. 이 틀은 잘 되어 있고 바꿀 이유가 없습니다.
자동차 독자가 실제로 쓰는 표준도 이 글이 다루는 것을 상당 부분 이미 묻습니다.
| 기존 체계 | 묻는 것 | 묻지 않는 것 |
|---|---|---|
| STPA Handbook의 시나리오 두 부류 | 프로세스 모델 결함의 원인으로 피드백을 거슬러 가라고 예시로 보여 준다 | 그 연결을 원형 목록으로 강제하지는 않는다 |
| 가이드워드 원형(Class 1~4, 66개) | 각 Class 안에서 무엇이 잘못될 수 있는가 | 두 Class의 결함이 한 제어 루프 안에서 하나의 고리를 이루는 경우 |
| ISO 26262-9 종속 고장 분석(DFA) | 전원·버스·커넥터 같은 공유 자원으로 인한 종속 고장 | 그 공유가 어느 UCA의 어느 시나리오에 들어가는가 |
| ISO 21448(SOTIF) | 센서 성능 한계와 유발 조건(안개, 정지 물체 필터링) | 그때 제어기가 무엇을 기본값으로 두는가 |
| AUTOSAR E2E·신호 유효성 | 타임아웃·CRC·유효성 표시 | 제어기가 그 표시를 안전 모드 전환 조건에 쓰는가 |
빠진 자리는 핸드북이나 표준이 아니라, 원형을 하나 골라 문장을 끝내는 실무 습관에 있습니다. 표준이 요구하는 유효성 표시와 공유 자원 분석의 결과가 어느 UCA의 어느 시나리오에 들어가는지는 누군가 끌어와야 합니다.
조합 원형: Class를 나누지 않고, 그 사이를 묻는 층을 더한다
네 Class의 원형 66개를 서로 짝지어 보면 의미가 통하는 조합이 생각보다 많지 않고, 생기는 방식은 다섯 가지로 정리됩니다.
| 기제 | 뜻 | 예 (NOA 예제) |
|---|---|---|
| 인과 연쇄 | 앞 Class의 결함이 뒤 Class의 결함을 일으킨다 (방향이 있다) | 카메라 피드백 상실 → NOA가 지도만으로 속도를 요청하는 저하 모드로 들어감 |
| 은폐 | 한 Class의 결함이 다른 Class의 결함을 제어기 눈에서 가린다 | 제동 작동기가 감속을 못 내는데, 피드백은 "명령한 감속도"를 돌려줘 실패가 안 보임 |
| 공통 원인 | 링크·버스·전원·커넥터 하나가 두 Class를 동시에 친다 | 차량 버스 과부하가 속도 요청과 속도 피드백을 함께 지연시킴 |
| 보상 무력화 | 한 Class의 대체 전략이 다른 Class의 결함과 만나 역작용한다 | NOA가 대체 목표로 명령을 보류하자, 차량 쪽이 일정 시간 무입력 뒤 스스로 반응함 |
| 다중 제어기 | 두 제어기가 같은 모호한 입력을 다르게 해소해 명령이 충돌한다 | 모호한 표지 값을 NOA와 하위 속도 제어기가 달리 읽어 명령이 충돌함 |
이 기준으로 추린 조합 원형은 77개입니다. 원형 문장은 단일 원형과 같은 규칙으로 썼습니다. %Controller%, %Feedback% 같은 placeholder를 그대로 두고 실제 요소만 채우게 하고 조합마다 어느 단일 원형 둘(셋)에서 왔는지를 적어 추적할 수 있게 했습니다.
이 77개를 VisualPro STPA의 가이드워드 셋에 "Class 5"로 추가했습니다. 툴에서는 편의상 다섯 번째 Class 노드로 두었지만, 원인 범주가 아니라 범주 사이의 관계 층입니다. Class 1~4는 손대지 않았습니다. 분석자는 평소처럼 원형을 고르다가 아래 네 질문 중 하나가 "예"이면 조합 원형으로 바꾸면 됩니다.
실험: 같은 UCA, 단일 원형 6건과 조합 원형 11건
NOA 예제에서 UCA 두 개와 제어행동 하나를 골랐습니다. "NOA가 제한속도를 넘는 속도를 요청한다", "앞에 장애물이 있는데 NOA가 속도 요청을 하지 않는다", 그리고 UCA와 무관하게 "속도 요청"이 제대로 실행되지 않는 경우입니다. 세 곳 모두 시나리오가 0건인 상태에서 시작했습니다.
AI(Claude)가 툴의 가이드워드와 제어 루프 요소(제어기, 프로세스 모델, 하위 제어기)를 읽고, 먼저 단일 원형으로 6건을, 다음에 조합 원형으로 11건을 만들어 저장했습니다. 원형 선택과 placeholder 채우기는 AI가 했고 대상 UCA 지정과 판정은 필자가 했습니다. 판정 기준은 세 가지였습니다. 단일 원형 6건에 없는 내용인가, NOA의 제어 구조에서 성립하는가, 대책이 달라지는가. 판정은 조합 원형을 만든 필자가 했고 독립 검토는 아직 받지 않았으므로, 아래 수치는 상한으로 읽어 주시기 바랍니다. 기준선도 대상당 2건이라 얇습니다. 아래 원형 번호는 필자의 원형 목록 기준이며 툴의 Class 1~4 항목 번호와 다릅니다.
| 조합 원형 | 시나리오 요지 | 판정 |
|---|---|---|
| C2-11 + C1-19 (인과) | 본선 100 km/h와 진출로 60 km/h 표지가 나란히 보여 두 해석이 충돌하고, NOA가 본선 쪽을 택해 진출로에서 100을 요청 | 대책이 달라짐 — "충돌하면 낮은 값"이라는 해소 정책. 단일 원형 둘을 이어도 안 나옴 |
| C3-3 + C2-2 (공통 원인) | 버스 과부하가 감속 요청과 속도 피드백을 함께 지연시켜, NOA는 속도가 안 변한 줄 알고 요청을 거듭 보냄 | 대책이 달라짐 — 이미 쓰는 E2E 타임아웃이 속도 피드백 신호에 걸려 있는지, 재발행 전에 그것을 보는지 |
| C3-1 + C2-6 (은폐, UCA 무관) | 제동 작동기가 요청 감속을 못 내는데 피드백은 "명령한 감속도"를 돌려줘 실패가 NOA에 보이지 않음 | 대책이 달라짐 — 실측 감속도 피드백 |
| C2-1 + C1-20 (인과) | 안개로 카메라가 표지판을 못 읽자 NOA가 직전 제한속도 110 km/h를 그대로 써서 공사 구간 60 km/h에서 110을 요청 | 기준선에 없었으나 단일 원형(기본값·직전값 가정)을 더 골랐으면 닿는 것. 조합은 두 문장을 한 고리로 묶어 줌 |
| C2-1 + C1-20 (인과, 장애물 UCA) | 폭우로 레이더가 죽자 NOA가 "장애물 없음"을 기본값으로 가정해 감속 요청을 안 함 | 중복 — 기준선 두 건(레이더 고장, 기본값 가정)을 한 문장으로 이은 것 |
| C4-2 + C2-1 (공통 원인) | 12 V 전원 저하가 제동 권한을 줄이는 동시에 레이더를 끈다 | 설계 확인 필요 — 레이더와 제동이 같은 전원 계통인지 확인 전에는 가설 |
표에 없는 5건은 저하 모드 입력 검증(인과), 안전 모드 조건이 유효성 표시를 참조하지 않음(인과), 지도의 임시 구간 맥락 부재(인과), 정지 물체 필터링(인과), 명령·피드백 링크 공유(공통 원인)입니다. 앞의 둘은 단일 원형으로도 닿을 수 있었고, 다음 둘은 기존 단일 시나리오와 부분적으로 겹치며, 마지막은 설계 확인 전까지 가설입니다.
집계하면 조합 원형 11건 가운데 기준선에 없던 것 6건, 부분 2건, 설계 확인 전 질문 2건, 중복 1건입니다. 6건을 다시 쪼개면 대책이 달라지는 것 3건, 단일 원형을 더 골랐으면 닿는 것 3건입니다. 세 가지가 보였습니다.
첫째, 조합 원형이 제값을 하는 자리는 좁고 분명합니다. 두 원형을 이어도 나오지 않는 대책(해소 정책, 타임아웃 참조, 실측 피드백)이 있는 곳입니다. 나머지는 단일 원형을 꼼꼼히 골라도 닿습니다. 조합 원형은 단일 원형을 대신하는 것이 아니라, 단일 원형이 각각 서 있을 때 그 사이가 비어 있는지 묻는 층입니다.
둘째, 같은 조합 원형이라도 UCA에 따라 결과가 다릅니다. "센서 고장 → 기본값 가정" 원형은 제한속도 UCA에서는 기준선에 없던 것이었지만 장애물 UCA에서는 중복이었습니다. 기준선에 단일 시나리오 두 건이 이미 있으면 조합은 둘을 잇는 것 이상이 못 됩니다.
셋째, 공통 원인형은 AI가 내는 순간에는 가설입니다. 전원이나 링크를 정말 공유하는지는 ISO 26262-9 DFA 결과와 아키텍처 문서가 답합니다. 다른 예제(공개된 설계 문서를 바탕으로 재구성한 가상 소형 원자로 플랜트)에서는 시뮬레이션으로 얻은 결합 시나리오 후보 여섯 개를 원문의 다중화·투표 논리와 대조하자 세 개가 기각됐습니다. 이 글의 조합 원형 일부는 거기서 추상화한 것입니다. 조합 원형은 후보이지 발견이 아닙니다.
이 실험에서 AI가 한 일은 원형을 고르고 placeholder를 실제 요소로 채워 저장한 것이고, 사람이 한 일은 가이드워드 셋을 설계하고 결과를 판정한 것입니다. 두 번째 일은 줄어들지 않습니다. 후보가 많아질수록 "이것이 우리 설계에서 성립하는가"를 묻는 시간이 늘어나고, 그 시간이 분석의 본체입니다.
내일 확인할 것
- 진행 중인 분석에서 UCA 하나를 골라 네 질문(피드백 없을 때 기본값, 실행 실패 인지, 경로 공유, 보류 뒤 자동 반응)을 던져 본다. 하나라도 "예"면 그 UCA의 시나리오는 두 Class에 걸쳐 있다.
- 이미 쓴 시나리오 중 "센서 고장"으로 끝나는 문장을 찾아 그 순간의 기본값을 뒤에 붙여 본다.
- 가이드워드 셋에 조합 원형을 넣을 때 Class 1~4는 그대로 두고 별도 층으로 더한다. 기존 시나리오의 추적성이 깨지지 않는다.
- 공통 원인형 시나리오는 "설계 확인 필요" 상태를 따로 두고, DFA 결과(공유 여부, 다중화)를 적어야 닫히게 한다.
- 제어기로 가는 피드백이 "명령한 상태"인지 "도달한 상태"인지 신호별로 적는다. 명령한 상태만 돌려주는 피드백은 은폐형 시나리오의 재료다.
- E2E 유효성 표시와 타임아웃이 어느 신호에 걸려 있고, 제어기의 안전 모드 조건이 그것을 참조하는지 적는다.
마무리
자주 묻는 질문
Q1단일 원형을 두 개 고르면 되지 않습니까?
됩니다. 실험에서도 6건 중 3건은 그렇게 닿을 수 있었습니다. 다만 두 문장을 따로 쓰면 "센서 고장"과 "기본값 가정"이 서로 다른 시나리오로 남고, 그 사이의 고리(어느 센서가 죽었을 때 어느 기본값이 쓰이는가)는 아무도 적지 않습니다. 조합 원형은 그 고리를 한 문장으로 적게 합니다. 대책이 달라지는 3건은 두 문장을 이어도 나오지 않았습니다.
Q2DFA·SOTIF·E2E가 이미 묻는데 무엇이 새롭습니까?
새로운 대책은 없습니다. 공유 자원은 DFA가, 센서 한계는 SOTIF가, 유효성 표시는 E2E가 요구합니다. 빠진 것은 그 결과가 어느 UCA의 어느 시나리오에 들어가는지입니다. 조합 원형의 네 질문은 그 연결을 UCA마다 묻게 하는 장치입니다. 설계 확인이 필요한 2건은 DFA 결과를 가져와야 닫힙니다.
Q3AI가 만든 시나리오를 그대로 써도 됩니까?
그대로 쓰지 않습니다. 11건 중 2건은 전원·링크 공유라는 가설 위에 서 있었고, 확인 전에는 시나리오가 아니라 질문입니다. 다른 예제에서는 결합 시나리오 후보 여섯 개 중 세 개가 원문 대조에서 기각됐습니다. AI는 후보를 빠짐없이 내고 사람은 설계 문서로 성립 여부를 판정하는 분업이 맞습니다.
Q4핸드북의 두 부류 분류와 충돌하지 않습니까?
충돌하지 않습니다. 핸드북은 프로세스 모델 결함의 원인으로 피드백을 거슬러 가라고 이미 예시로 보여 줍니다. 조합 원형은 그 연결을 원형 목록으로 만들어, 분석자가 원형 하나를 고를 때 그 연결을 빠뜨리지 않게 할 뿐입니다.
Q5우리 툴에는 가이드워드 셋 기능이 없습니다. 적용할 수 있습니까?
네 질문은 툴과 무관합니다. 스프레드시트의 시나리오 열 옆에 "피드백 없을 때 기본값", "실행 실패 인지", "경로 공유", "보류 뒤 자동 반응" 네 칸을 두고 UCA마다 예·아니오를 적는 것으로 시작할 수 있습니다. 가이드워드 셋으로 쓰면 추적성이 자동으로 남는 것이 차이입니다.
- ISO 26262-9:2018, 7절 종속 고장 분석(Dependent failure analysis); ISO 21448:2022(SOTIF); AUTOSAR E2E Protocol Specification
- 필자 정리, Class 1~4 손실 시나리오 원형(66개)과 교차 조합 원형(77개) 목록, 2026 — 요청 시 제공
- Nancy G. Leveson, John P. Thomas, STPA Handbook, MIT, 2018 — psas.scripts.mit.edu
- MIT PSASS, STAMP Tools — psas.scripts.mit.edu/home/stamp-tools
이 글의 NOA 예제는 교육용 가상 시스템이며 특정 차량이나 제조사의 설계가 아닙니다. 제한속도 수치(110·60·100 km/h)는 설명을 위한 예시입니다. 기준선은 대상당 단일 원형 2건으로 얇게 잡았고, 판정은 조합 원형을 만든 필자가 했으며 독립 재판정은 받지 않았습니다. 원형 선택과 placeholder 채우기는 AI가, 대상 UCA 지정은 필자가 했습니다. 공통 원인형 2건(전원 공유, 링크 공유)은 아키텍처 확인 전의 가설입니다. 가상 소형 원자로 플랜트의 기각 사례는 공개된 설계 문서를 바탕으로 재구성한 자체 예제에서 나온 것입니다. 시나리오 생성과 저장은 VisualPro STPA의 MCP 연결로 Claude가 수행했습니다.