VisualPro Tech Brief
미군 표준이 요구하는 소프트웨어 안전 케이스
문제는 분석이 아니라 연결이다
MIL-STD-882E 시스템안전 | 방산 SW 안전논증 | 업계 동향 브리프
MIL-STD-882ESwHASSRSwCI 1~5Safety Case
01개요 (TL;DR) — 882E가 요구하는 것은 문서가 아니라 논증이다
미 국방 시스템안전 표준 MIL-STD-882E는 개념 탐색부터 폐기까지 전 수명주기에 걸쳐 위험을 제거하고, 제거할 수 없는 위험은 최소화하도록 규정합니다. 무기체계·차량·항공기에 광범위하게 적용되며, 소프트웨어 비중이 커진 지금 실무의 중심은 소프트웨어 안전 케이스(Software Safety Case) 구축으로 옮겨왔습니다.
안전 케이스는 보고서 묶음이 아니라 주장–논거–증거(claim–argument–evidence)의 계층 구조입니다. “모든 예견 가능한 위험원을 식별했고, 통제가 각 위험을 수용 가능한 수준으로 낮췄으며, 그 통제가 올바르게 구현되었고, 잔존 위험은 공식 승인되었다”를 논증해야 합니다. 소프트웨어가 결함이 없다고 주장하는 것이 아닙니다 — 그런 주장은 달성 불가능하고, 882E가 요구하는 바도 아닙니다.
그리고 실무에서 이 논증이 무너지는 지점은 분석의 깊이가 아닙니다. 분석과 검증 사이의 연결입니다.
소프트웨어 안전 프로그램의 가장 흔한 실패는 분석 부족이 아니라 후속 연결 부족이다.
02왜 지금인가 — 방산 SW 안전논증을 밀어 올리는 3가지 압력
1소프트웨어가 위험원의 주 경로가 되었다위험원 경로 이동
무기체계의 기능이 소프트웨어로 이동하면서 치명적 위험원의 기여 경로도 소프트웨어로 옮겨졌습니다. 882E는 소프트웨어가 하드웨어를 통제하는 정도(소프트웨어 통제 범주 5단계)와 심각도(4단계)를 교차시켜 소프트웨어 안전 치명도 행렬(SSCM)을 만들고, 여기서 산출된 SwCI(1~5)로 요구 엄격도(Level of Rigor)를 결정합니다. 치명도가 높으면 코드 커버리지 목표, 독립 검증, 정형 분석이 의무로 따라붙습니다.
2계약이 산출물을 명시한다계약 요구사항
882E의 과업은 계약 SOW에 지정되고 산출물은 CDRL로 제출됩니다. 소프트웨어 중심 체계에서는 다섯 과업이 공수를 지배합니다 — Task 205(SW 안전요구 분석), Task 206(SW 안전설계 분석), Task 301(안전성 평가), Task 302(시험·평가 안전), Task 303(시스템안전 프로그램 검토). 안전 데이터 패키지에는 SwHA 워크시트, SSR 목록과 추적성 매트릭스, 소프트웨어 FMEA, 안전 시험 케이스와 결과, 커버리지 보고서, 위험 수용 결정서(HRDR), 안전성 평가 보고서가 모두 들어갑니다.
3역량 격차가 곧 수주 격차다수주 경쟁력
잔존 위험은 위험 지수(HRI)에 따라 승인 권한이 달라집니다. 치명적·빈발(HRI 1)은 사업 결정권자(MDA) 승인까지 올라가고, 무시 가능·극희박(HRI 20)은 실무 그룹 승인으로 끝납니다. 안전 케이스는 살아있는 문서여서 소프트웨어를 수정할 때마다 재검토가 필요하고, 수용된 잔존 위험이 바뀌면 새 HRDR을 받아야 합니다. 이 사이클을 파일 기반으로 버티는 조직과 도구로 버티는 조직의 차이가 벌어집니다.
03882E 소프트웨어 안전은 3단으로 내려온다
분석의 3단 구조
| 단계 | 하는 일 | 산출물 |
|---|
PHA
예비 위험분석 | 기능 분해와 운용 개념으로 시스템 수준 위험원 식별 | 위험원 목록, 초기 HRI, 기여 기능 목록 |
SwHA
소프트웨어 위험분석 | 시스템 위험원을 소프트웨어 고장모드로 매핑 | 위험원↔고장모드 워크시트 |
SSR 도출
소프트웨어 안전요구 | 고장모드별로 요구되는 소프트웨어 거동 규정 | 긍정·부정·범위 제약 + 감시 요구 |
SSR은 네 가지 정형으로 씁니다 — 긍정 제약(반드시 해야 하는 동작), 부정 제약(금지되는 상태), 범위 제약(유효 출력 경계), 감시 요구(위험 검출을 가능하게 하는 조건).
추적성 5단 체인 — 여기가 실제로 무너지는 자리
| 연결 | 요구되는 것 |
|---|
| PHA 위험원 → SwHA | 소프트웨어 기여가 있는 모든 위험원이 SwHA 행으로 내려올 것 |
| SwHA → SSR | 모든 SwHA 행이 최소 1개 SSR로 이어질 것 |
| SSR → SRS/SDD | 모든 SSR이 특정 요구사양·설계문서 항목에 대응할 것 |
| SSR → 검증 증거 | 모든 SSR이 시험 케이스·커버리지·소프트웨어 FMEA·검토 기록으로 입증될 것 |
| 증거 → 구성 기준선 | 모든 증거가 정확한 소프트웨어 버전에 묶일 것 |
핵심 원문은 추적성을 “SwHA 품질의 운영 지표”라고 규정하며, 추적성 공백이 SwHA 재작업의 가장 흔한 원인이라고 지적합니다. 마지막 연결도 타협 대상이 아닙니다 — 어느 버전을 시험했는지 특정하지 못하는 시험 결과는 재현 가능한 증거가 아닙니다.
04SwHA의 5대 고장모드는 FMEA·STPA와 같은 뼈대다
SwHA는 시스템 위험원을 다섯 가지 정형 소프트웨어 고장모드로 분해합니다. 이 분류는 우리가 이미 수행하는 두 방법론과 구조적으로 대응합니다.
| 882E SwHA 고장모드 | FMEA 관점 | STPA 관점 |
|---|
잘못된 출력
Incorrect output | 기능 오작동 — 값·상태 오류 | 위험을 유발하는 제어 제공 (UCA) |
출력 없음
No output / 누락 | 기능 상실 | 필요한 제어 미제공 (UCA) |
늦은 출력
Late output | 타이밍 고장 | 잘못된 타이밍·순서 (UCA) |
가짜 출력
Spurious output | 의도치 않은 작동 | 불필요한 상황의 제어 제공 (UCA) |
잘못된 대상으로의 출력
Wrong destination | 인터페이스 고장 | 제어 경로 결함 — 손실 시나리오 영역 |
앞의 네 가지는 STPA의 불안전 제어 행동(UCA) 유형과 그대로 겹치고, 다섯 번째는 UCA가 아니라 STPA 손실 시나리오의 제어 경로 결함 범주에 대응합니다. 방향이 다른 두 방법론이 같은 고장 공간을 덮고 있다는 뜻입니다.
실무적 함의 882E는 새로운 분석 언어를 배우라고 요구하지 않습니다. FMEA의 고장모드 축, STPA의 제어 관점, FTA의 논리 전개를 하나의 구조 위에서 연결하고 증거까지 추적하라고 요구합니다. 실제로 소프트웨어 FMEA는 SwHA 완전성을 교차 확인하는 증거로 안전 데이터 패키지에 명시되어 있습니다.
05VisualPro는 어떻게 지원하나
하나의 구조 트리, 다섯 개의 분석구조 공유
FMEA·FTA·HARA·TARA·STPA가 동일한 시스템 구조 DB를 공유합니다. PHA에서 식별한 위험원을 구조 트리 위에 올리고, 같은 트리에서 SwHA 고장모드와 FTA 논리 전개를 이어 갑니다. 위험원을 두 번 입력하지 않습니다.
SSR ↔ 검증 증거 추적성핵심 가치
위험원 → 고장모드 → 안전요구 → 검증 항목이 단일 DB에서 양방향으로 연동됩니다. 882E가 요구하는 추적성 매트릭스를 분석 DB에서 직접 생성하므로, 설계 변경 시 끊긴 연결이 즉시 드러납니다. 원문이 지적한 “가장 흔한 실패 모드”를 도구 차원에서 막는 지점입니다.
심각도·치명도 체계 대응등급 체계
심각도 4단계와 발생 확률 5단계의 위험 지수(HRI), 소프트웨어 통제 범주 기반 SwCI 산정을 프로젝트 기준으로 설정해 운용할 수 있습니다. AIAG-VDA AP, ISO 26262 ASIL, ISO/SAE 21434 CAL과 같은 방식으로 다뤄집니다.
MCP 기반 AI 에이전트 연동AI 연동
FMEA·FTA·HARA·TARA·STPA 분석을 지원하는 MCP(Model Context Protocol) 기능으로 Claude 등 AI 에이전트가 VisualPro와 직접 통신합니다. 후보 고장모드 식별부터 SSR 초안 작성까지 대화형으로 수행하고, 분석자는 검증과 판단에 집중합니다. 전담 안전 조직이 없는 협력업체일수록 체감 효과가 큽니다.
06자주 묻는 질문 (FAQ)
Q1자동차 FMEA 역량이 방산 SW 안전논증에 전이될까요?
원리는 같습니다. 위험원 식별 → 고장모드 분해 → 요구 도출 → 검증 추적이라는 골격은 ISO 26262와 882E가 공유하고, SwHA의 고장모드 분류는 FMEA와 대응합니다. 다른 것은 등급 체계(ASIL ↔ SwCI/HRI)와 산출물 이름(안전 케이스, HRDR, SDP), 그리고 과업이 계약 SOW·CDRL로 지정된다는 점입니다. 방법론을 새로 배우는 일이 아니라 표기와 산출물을 맞추는 일입니다.
Q2안전 케이스를 반드시 GSN으로 그려야 하나요?
아닙니다. 원문도 GSN(Goal Structuring Notation)은 계층 관계를 시각화하는 수단일 뿐 필수가 아니며, 표기와 무관하게 논리 구조 자체가 본질이라고 명시합니다. 중요한 것은 주장–논거–증거가 빠짐없이 연결되어 있고 그 연결을 추적할 수 있는지입니다.
Q3이미 SwHA를 수행했는데 심사에서 재작업 지적을 받았습니다. 무엇을 봐야 하나요?
추적성 공백부터 보십시오. 원문이 SwHA 재작업의 가장 흔한 원인으로 지목한 항목입니다. 소프트웨어 기여가 있는데 SwHA 행이 없는 위험원, SSR로 이어지지 않은 SwHA 행, 시험 케이스와 연결되지 않은 SSR, 버전이 특정되지 않은 시험 결과 — 이 네 가지를 점검하면 대부분 드러납니다.
07지금 시작하십시오 (Next Step)
방산 소프트웨어 안전논증은 분석 역량과 추적 역량이 함께 요구되는 영역이고, 후자는 도구 없이는 유지되지 않습니다. 자동차·반도체·로봇 현장에서 검증된 VisualPro로, 위험원부터 검증 증거까지 하나의 구조 위에서 잇는 안전 케이스를 준비하십시오.
위험원에서 증거까지 끊기지 않게 잇는다 — VisualPro와 함께하는 방산 SW 안전논증.
참고 자료: Corvus Intelligence, “Software Safety Case Development under MIL-STD-882E” (2026-06-25) · LDRA, MIL-STD-882E / JSSSEH 자료
미 국방 시스템안전 표준 MIL-STD-882E는 개념 탐색부터 폐기까지 전 수명주기에 걸쳐 위험을 제거하고, 제거할 수 없는 위험은 최소화하도록 규정합니다. 무기체계·차량·항공기에 광범위하게 적용되며, 소프트웨어 비중이 커진 지금 실무의 중심은 소프트웨어 안전 케이스(Software Safety Case) 구축으로 옮겨왔습니다.
안전 케이스는 보고서 묶음이 아니라 주장–논거–증거(claim–argument–evidence)의 계층 구조입니다. “모든 예견 가능한 위험원을 식별했고, 통제가 각 위험을 수용 가능한 수준으로 낮췄으며, 그 통제가 올바르게 구현되었고, 잔존 위험은 공식 승인되었다”를 논증해야 합니다. 소프트웨어가 결함이 없다고 주장하는 것이 아닙니다 — 그런 주장은 달성 불가능하고, 882E가 요구하는 바도 아닙니다.
그리고 실무에서 이 논증이 무너지는 지점은 분석의 깊이가 아닙니다. 분석과 검증 사이의 연결입니다.
예비 위험분석
소프트웨어 위험분석
소프트웨어 안전요구
SSR은 네 가지 정형으로 씁니다 — 긍정 제약(반드시 해야 하는 동작), 부정 제약(금지되는 상태), 범위 제약(유효 출력 경계), 감시 요구(위험 검출을 가능하게 하는 조건).
SwHA는 시스템 위험원을 다섯 가지 정형 소프트웨어 고장모드로 분해합니다. 이 분류는 우리가 이미 수행하는 두 방법론과 구조적으로 대응합니다.
Incorrect output
No output / 누락
Late output
Spurious output
Wrong destination
실무적 함의 882E는 새로운 분석 언어를 배우라고 요구하지 않습니다. FMEA의 고장모드 축, STPA의 제어 관점, FTA의 논리 전개를 하나의 구조 위에서 연결하고 증거까지 추적하라고 요구합니다. 실제로 소프트웨어 FMEA는 SwHA 완전성을 교차 확인하는 증거로 안전 데이터 패키지에 명시되어 있습니다.
방산 소프트웨어 안전논증은 분석 역량과 추적 역량이 함께 요구되는 영역이고, 후자는 도구 없이는 유지되지 않습니다. 자동차·반도체·로봇 현장에서 검증된 VisualPro로, 위험원부터 검증 증거까지 하나의 구조 위에서 잇는 안전 케이스를 준비하십시오.