제8부 안전·보안·시스템공학
8.2 항공기 개발 프로세스와 시스템공학(ARP4754B)
8.2.1 이 장에서 배우는 것 / 선수 지식 / 특히 중요한 독자
8.1이 "요구를 작성하고 추적하고 검증한다"는 범용 규율을 세웠다면, 이 장은 그 규율을 민간 항공의 안전과 인증에 연결하는 방식을 본다. 핵심 문서는 SAE ARP4754 계열(최신 판 ARP4754B)이다. 이 문서는 새 기법을 가르치지 않는다. 개발의 엄격함을 안전의 중대성에 비례하게 정하는 약속을 정한다.
배우는 것:
- 개발 보증이란 무엇인가 — 우연 고장과 체계적 오류의 차이, 그리고 왜 후자를 확률이 아닌 "프로세스의 엄격함"으로 다루는가.
- 문서군과 개발 흐름 — ARP4754B, ARP4761A, DO-178C·DO-254가 서로 무엇을 주고받는가.
- 개발 프로세스의 활동 — 계획·요구 포착·요구 확인·구현·검증·형상 관리·프로세스 보증·인증 조정.
- 개발 보증 수준 — 고장 조건 등급에서 기능 수준(FDAL)과 품목 수준(IDAL)이 나오는 길, 그리고 독립성이 하는 일.
- 공통 원인 고장 — 다중화(같은 채널을 늘림)가 줄이는 것과 줄이지 못하는 것을 숫자로 본다.
- 어디까지 적용할 것인가 — 대형 항공기, eVTOL, 소형 UAS에서의 현실적 선택지.
선수 지식: 8.1(요구·검증·추적성)을 읽었다고 가정한다. 안전성 평가의 기법(FHA·FTA·FMEA)은 8.4가, 소프트웨어·하드웨어 보증은 8.8이 자세히 다루므로 이 장은 둘을 잇는 틀만 보인다.
특히 중요한 독자: 인증 담당자는 8.2.3~8.2.5와 8.2.12를, 엔지니어는 8.2.6의 계산을 건너뛰지 않는다. 정책·사업 담당자는 8.2.9와 8.2.10만 읽어도 "왜 안전 중요 기능은 비용이 이렇게 드는가"를 이해할 수 있다. 법무는 개발 보증 문서가 증거로 제출되는 구조(8.2.12)를 본다.
기준 시점과 정직성. 2026년 10월 기준이고 지식은 2026년 중반까지다. ARP4754B와 ARP4761A는 2023년에 발행된 것으로 알고 있으나 발행 연월과 인정 여부는
(확인 필요)다. 이 장은 규격 본문(유료)을 옮기지 않고 구조와 요지만 적었다. 규격 속 표의 구체 조합·판별 규칙은 본문에서 확인해야 한다. 워크스루의 값은 모두 원리를 보이기 위한 가정이다.
8.2.2 개념 — 개발 보증은 "사람의 실수"를 다루는 틀이다
항공 안전에서 위험의 원천은 둘로 나뉜다.
| 우연 고장(random failure) | 체계적 오류(systematic error) | |
|---|---|---|
| 원인 | 부품의 마모·피로·열화처럼 확률적으로 일어남 | 요구·설계·구현의 사람 실수 |
| 거동 | 개체마다 다른 때에 난다 | 같은 조건에서는 모든 개체에서 같게 난다 |
| 다루는 법 | 고장률·확률로 계산, 다중화로 줄임 | 확률로 계산하기 어렵다. 개발 과정의 엄격함으로 억제 |
| 예 | 모터 권선의 단락 | 소프트웨어가 특정 입력에서 0으로 나눔, 틀린 요구 |
개발 보증(development assurance)은 둘째를 위한 것이다. 오류가 없다는 증명은 어렵기 때문에, "이 정도로 엄격하게 만들고 검증했으면 오류가 남았을 가능성이 충분히 낮다"는 신뢰의 수준을 정하고 그 수준에 맞는 활동을 요구한다. 이 수준이 A(가장 엄격)부터 E까지의 개발 보증 수준(DAL) 이다.
시스템공학과의 관계는 이렇다. ISO/IEC/IEEE 15288은 어떤 시스템에도 사용하는 수명주기 프로세스를 정한다. ARP4754 계열은 그 틀을 민간 항공기·시스템에 맞추어 안전성 평가와 인증을 개발 흐름에 직접 연결한다. 이 연결이 항공 특화의 본질이다.
세 축에서 위치가 다르다. 대형 민간 항공기에서는 인증 프로그램에서 사실상 표준 입증 수단이다. eVTOL은 형식증명 프로그램에서 이 계열을 입증 수단으로 사용하는 것이 일반적이다(20.5·20.12, 구체 인용은 (확인 필요)). 소형 UAS는 의무가 아닌 경우가 많고 운용 위험 평가의 견고성 수준(20.14)에 연결된다. 군용 드론은 군 감항 기준과 계약이 틀을 정한다(12.3).
8.2.3 문서군과 개발 흐름
ARP4754B는 단독으로 사용되지 않는다. 관련 문서를 함께 읽어야 한다.
| 문서 | 대상 | 이 장과의 관계 | 상세 장 |
|---|---|---|---|
| SAE ARP4754B | 항공기·시스템 개발 보증 | 이 장의 주제. 요구·아키텍처·검증·형상·프로세스 보증 | — |
| SAE ARP4761A | 안전성 평가 방법(FHA·PSSA·SSA·FTA·FMEA·CMA) | 개발이 만든 구조안을 평가하고 안전 요구를 되돌려 줌 | 8.4 |
| RTCA DO-178C | 항공기 탑재 소프트웨어 | 품목 수준 구현 지침(IDAL 따라 목표 수가 달라짐) | 8.8 |
| RTCA DO-254 | 복잡 전자 하드웨어 | 품목 수준 구현 지침 | 8.8 |
| RTCA DO-330·DO-331 | 도구 인정·모델 기반 개발 보충 | 자동 도구·모델을 증거로 사용하는 조건 | 8.8 |
| RTCA DO-326A | 항공 보안 프로세스 | 보안 위협을 개발·안전 흐름에 포함시킴 | 8.11 |
흐름의 요지는 세 가지다. 첫째, 기능 위험 평가(FHA) 가 개발에 안전 요구를 준다. 둘째, 개발이 구조안을 만들면 예비 시스템 안전성 평가(PSSA) 가 그 구조안이 안전 목표를 만족하는지 보고 요구를 더 내린다. 셋째, 구현과 통합·검증 뒤에 시스템 안전성 평가(SSA) 가 결과를 모아 "목표를 달성했다"는 증거를 닫는다. 양쪽이 서로를 기다리므로 순차 폭포가 아니라 되먹임이 있는 동시 진행이다.
8.2.4 개발 프로세스의 활동
ARP4754 계열이 다루는 활동은 다음과 같다(요지).
| 활동 | 하는 일 | 대표 산출물 |
|---|---|---|
| 계획 | 무엇을 어떻게 할지 먼저 문서로 정한다 | 개발·안전·요구 관리·확인·검증·형상 관리·프로세스 보증·인증 계획 |
| 요구 포착 | 항공기 기능, 안전, 인증기준에서 오는 요구를 모은다 | 항공기·시스템 요구, 가정 목록 |
| 요구 확인(validation) | 요구가 옳고 완전한가를 확인한다 | 확인 기록, 가정의 검토 |
| 구현 | 품목(소프트웨어·하드웨어)을 개발한다 | DO-178C·DO-254 산출물 |
| 검증(verification) | 구현이 요구를 만족함을 보인다 | 시험·해석·검사 보고서 |
| 형상 관리 | 기준선을 정하고 변경을 통제한다(8.22) | 형상 식별·변경 기록 |
| 프로세스 보증 | 계획대로 했는지 독립적으로 확인한다 | 프로세스 보증 보고 |
| 인증 조정 | 당국과 기준·증거를 미리 합의한다(20.5·20.6) | 인증계획, 적합성 입증 |
두 활동에 주의한다. 요구 확인은 시험이 아니라 요구 자체를 겨냥한다. ARP4754A가 열거한 확인 방법은 추적성·해석·모델링·시험·유사성·공학 검토다(요지, B판 세부는 (확인 필요)). 가정도 요구처럼 다룬다. 어떤 요구가 "배터리 열폭주는 셀 단위에서만 일어난다"는 가정에 기댄다면 그 가정은 적고, 확인하고, 틀렸을 때의 영향을 추적해야 한다. 파생 요구는 반드시 안전 평가로 되돌려 보내 안전 영향을 평가한다(8.1.3.1).
8.2.4.1 안전 요구의 종류
안전 평가가 개발에 돌려주는 요구는 모양이 몇 가지로 정해져 있다. 모양마다 검증하는 방법이 다르다는 점이 요구를 작성할 때 중요하다.
| 종류 | 모양 | 예(가정) | 검증 방법 |
|---|---|---|---|
| 정량 확률 요구 | 고장 조건의 확률 상한 | 비행 제어 상실 확률은 $10^{-9}$/FH 이하 | 해석(고장 수목, 8.4) |
| 단일 고장 허용 | 어느 한 고장도 치명적 결과를 만들지 않는다 | 로터 하나가 고장 나도 자세 제어를 유지한다 | 해석 + 고장 주입 시험(2.5) |
| 독립성 요구 | 두 기능·채널이 공통 원인을 나누지 않는다 | 두 비행 제어 컴퓨터는 별도 전원·별도 소프트웨어 | 공통 원인 분석, 검사 |
| 검출·점검 요구 | 잠재 고장을 일정 시간 안에 찾는다 | 대기 채널의 고장을 비행마다 점검한다 | 시험, 해석 |
| 안전 상태 요구 | 고장 뒤 도달할 상태 | 추진 전량 상실 시 낙하산을 전개한다(1.30) | 시험, 시연 |
| 개발 보증 요구 | 개발 엄격함의 수준 | 이 기능은 FDAL B로 개발한다 | 프로세스 보증 |
8.2.4.2 개발 단계와 심사 게이트
개발은 단계로 나뉘고 단계마다 검토 게이트가 있다. 게이트 이름(SRR·PDR·CDR·TRR)은 시스템공학 일반의 관용이고, 당국과의 접점은 eVTOL 형식증명을 가정한 예다. 실제 일정과 심사 항목은 인증계획에서 합의한다.
| 단계 | 하는 일 | 대표 게이트 | 당국과의 접점(예) |
|---|---|---|---|
| 개념·요구 | 운용 개념, 요구 포착, 첫 FHA | 요구 검토(SRR) | 인증기준 제안, 인증계획 초안 합의 |
| 예비 설계 | 구조안, PSSA, 독립성 주장 | 예비 설계 검토(PDR) | 입증 방법 합의, 이슈페이퍼(20.5) |
| 상세 설계 | 품목 설계, DAL 확정 | 상세 설계 검토(CDR) | 소프트웨어·하드웨어 단계 심사(20.9) |
| 구현·통합 | 제작, 하위체계 통합 | 시험 준비 검토(TRR) | 시험 계획 승인, 적합성 시험 입회 |
| 검증·인증 | 적합성 입증, SSA 마감 | 인증 검토 | 적합성 확인, 증명 발급(20.6·20.8) |
게이트는 일정표가 아니라 증거를 확정하는 시점이다. 한 게이트에서 넘어가려면 앞 단계의 요구·안전 평가·검증 계획이 기준선(8.22)으로 고정되어 있어야 한다.
8.2.5 고장 조건 등급과 개발 보증 수준
개발 보증의 엄격함은 그 기능이 잘못되었을 때의 결과로 정한다. 결과는 FHA에서 고장 조건 등급으로 매긴다.
| 고장 조건 등급 | 뜻(요지) | 대형기에서 흔히 사용하는 확률 목표(시간당) | 기능 개발 보증 수준(FDAL) |
|---|---|---|---|
| 치명적(catastrophic) | 항공기 상실, 다수 사망 | $10^{-9}$ 이하(극히 일어나기 어려움) | A |
| 위험(hazardous) | 안전 여유·기능 능력의 큰 감소, 중상 | $10^{-7}$ 이하 | B |
| 중대(major) | 안전 여유의 상당한 감소 | $10^{-5}$ 이하 | C |
| 경미(minor) | 안전 여유의 약간의 감소 | $10^{-3}$ 이하 | D |
| 안전 영향 없음 | 안전에 영향 없음 | 목표 없음 | E |
표의 확률 목표는 대형 운송기 관행의 값이고, 소형기·eVTOL·UAS는 별도 값을 사용한다(8.4·8.6). 규정마다 다르므로 (확인 필요)다.
기능 수준(FDAL) 은 시스템이 수행하는 기능의 개발에, 품목 수준(IDAL) 은 그 기능을 구현하는 하드웨어·소프트웨어 품목의 개발에 매긴다. 기본은 IDAL = FDAL이다. 다만 독립성이 입증된 다중 구조에서는 기능을 맡은 품목들에 한 단계 낮은 수준을 허용하는 규칙이 있다(허용되는 조합은 규격 본문의 표에서 확인해야 한다 (확인 필요)).
두 가지를 분명히 한다. 첫째, DAL은 확률이 아니다. A라고 해서 고장률이 $10^{-9}$이라는 뜻이 아니다. "체계적 오류가 남았을 가능성을 낮추는 활동의 엄격함"이다. 소프트웨어에는 확률을 할당하지 않고 DAL을 사용한다. 둘째, DAL이 높을수록 활동과 증거의 양이 크게 늘어난다. DO-178C에서 요구되는 목표 수는 수준별로 A가 71, B가 69, C가 62, D가 26 정도라고 알려져 있으나 이 장에서 확인하지 못했다 (확인 필요, 8.8). 비용은 대체로 DAL이 높은 기능을 줄이는 아키텍처 선택에 크게 좌우된다.
8.2.5.1 예시 — 같은 기능도 운용에 따라 등급이 달라진다
고장 조건 등급은 기능만이 아니라 기체와 운용에서 정해진다. 다음 표는 개념을 보이기 위한 가정 예다. 실제 등급은 FHA에서 비행 단계·운용 환경을 따져 매긴다(8.4).
| 기능(예) | 고장 조건(예) | 등급(가정) | FDAL |
|---|---|---|---|
| 승객 탑승 eVTOL: 비행 제어(자세·경로) | 비행 중 제어 상실 | 치명적 | A |
| 승객 탑승 eVTOL: 추진 | 모든 로터의 동시 상실 | 치명적 | A |
| 승객 탑승 eVTOL: 비행 정보 표시 | 틀린 고도·속도를 정상으로 표시(오도) | 위험~치명적(비행 단계에 따라) | B~A |
| 승객 탑승 eVTOL: 정비 정보 | 정비 알림 누락 | 중대 | C |
| 승객 탑승 eVTOL: 객실 오락 | 오락 정지 | 안전 영향 없음 | E |
| 2 kg 쿼드콥터: 자세 제어, 사람 없는 지역 상공 | 제어 상실로 추락 | 경미~중대(지상 위험 평가에 따름) | 의무 없음(20.14) |
| 2 kg 쿼드콥터: 자세 제어, 군중 위 비행 | 제어 상실로 추락 | 위험~치명적에 해당할 수 있음(8.6) | 운용 승인 조건에 따름 |
마지막 두 줄이 핵심이다. 기능과 기체가 같아도 운용이 바뀌면 등급이 바뀐다. 소형 UAS의 개발 보증이 "하느냐 마느냐"가 아니라 "어떤 운용을 허가받느냐"로 정해지는 이유다.
8.2.6 워크스루 — 같은 채널을 늘려도 확률의 하한은 남는다
다중화는 우연 고장에 강하다. 그런데 "채널을 늘리면 확률이 계속 내려가는가"를 계산해 보면 개발 보증이 왜 필요한지가 드러난다. 모형은 널리 사용되는 β 인자 모형이다(IEC 61508-6 부속서 D에 있는 방법 (판 확인 필요)). 같은 채널 $N$개가 있는 기능의 한 비행시간 동안의 상실 확률은 다음과 같다.
$$P_{\mathrm{loss}}(N)=\beta\,\lambda T+\bigl[(1-\beta)\lambda T\bigr]^{N}\quad(N\ge 2),\qquad P_{\mathrm{loss}}(1)=\lambda T$$
기호는 아래 표와 같다. 첫째 항이 공통 원인 고장(한 원인이 모든 채널을 동시에 고장 나게 함), 둘째 항이 독립 고장이 동시에 일어나는 경우다.
| 기호 | 뜻 | 값(가정) |
|---|---|---|
| $\lambda$ | 채널 하나의 고장률 | $10^{-5}$ /FH |
| $T$ | 노출 시간 | 1 비행시간 |
| $\beta$ | 고장 중 공통 원인의 비율 | 0, 0.1 %, 1 %, 10 % |
| 목표 | 치명적 고장 조건의 일반적 목표 | $10^{-9}$ /FH |
공통 원인을 고장 수목으로 그리면 구조가 보인다. 공통 원인은 OR로 최상위 사건에 곧장 이어진다.
계산 결과다(fig-src/8.2-calc.py, 표준 라이브러리만 사용).
| 같은 채널 수 $N$ | $\beta=0$ | $\beta=0.1\,\%$ | $\beta=1\,\%$ | $\beta=10\,\%$ |
|---|---|---|---|---|
| 1 | $1.0\times10^{-5}$ | $1.0\times10^{-5}$ | $1.0\times10^{-5}$ | $1.0\times10^{-5}$ |
| 2 | $1.0\times10^{-10}$ | $1.0\times10^{-8}$ | $1.0\times10^{-7}$ | $1.0\times10^{-6}$ |
| 3 | $1.0\times10^{-15}$ | $1.0\times10^{-8}$ | $1.0\times10^{-7}$ | $1.0\times10^{-6}$ |
| 5 | $1.0\times10^{-25}$ | $1.0\times10^{-8}$ | $1.0\times10^{-7}$ | $1.0\times10^{-6}$ |
결론부터: 채널을 둘 이상 두면 확률은 독립 고장이 아니라 $\beta\lambda T$가 정한다. 이 값이 목표를 충족하려면 $\beta\le P_{\mathrm{target}}/(\lambda T)$이어야 하고, 위 가정에서는 $\beta\le 10^{-4}$, 곧 0.01 % 다. 고장률을 $10^{-6}$으로 낮추면 상한이 0.1 %로 느슨해지지만 여전히 작다. 현장에서 사용하는 β는 보통 몇 퍼센트 수준이라는 문헌이 많아 대상마다 큰 차이가 있다 (확인 필요).
이것이 개발 보증과 이어지는 이유는 세 가지다.
- 같은 소프트웨어를 복제한 채널은 오류까지 복제한다. 소프트웨어의 체계적 오류에서는 β가 1에 가깝다. 다중화가 이를 줄이지 못한다. 그래서 소프트웨어는 확률이 아니라 DAL로 다룬다.
- 이질성(dissimilarity)이 β를 낮춘다. 다른 팀·다른 언어·다른 하드웨어로 채널을 만들면 같은 실수를 공유할 확률이 준다. 그러나 비용이 늘고 독립성은 입증해야 한다(공통 원인 분석, 8.4).
- 그래서 독립성 주장에는 증거가 요구된다. 그림 1의 "독립성 주장" 화살표가 이를 나타낸다.
고장 허용 구조(2.5)와 환경·전기 공통 원인(1.19의 배선 분리 등)은 β를 낮추는 설계 수단이다. 이 계산은 모형이 단순하다. 노출 시간·검출 가능성·점검 간격을 넣지 않았고, 채널이 모두 필요한 구조(예: 로터 여섯 개 중 넷이 필요)는 다른 식을 사용한다. 숫자는 경향을 보이기 위한 것이다. 바로 그 "채널이 모두 필요한 구조"를 다음 절에서 계산한다.
8.2.6.1 분산 추진 — 로터 여섯 개 중 넷이 필요할 때
로터 유닛(모터·ESC·프로펠러) $n$개 중 $k$개가 있어야 기능이 유지된다면, $n-k+1$개 이상이 고장 나는 경우에 기능을 잃는다. β 인자 모형에 이항 분포를 사용하면 다음과 같다.
$$P_{\mathrm{loss}}=\beta\lambda T+\sum_{j=n-k+1}^{n}\binom{n}{j}\,q^{\,j}(1-q)^{\,n-j},\qquad q=(1-\beta)\lambda T$$
유닛 하나의 고장률을 $\lambda=10^{-4}$/FH(가정, 앞 절의 채널보다 크게 잡았다), 노출 1 비행시간으로 계산했다(같은 스크립트).
| 구조 | $\beta=0$ | $\beta=1\,\%$ |
|---|---|---|
| 쿼드콥터: 4개 중 4개 필요 | $4.0\times10^{-4}$ | $4.0\times10^{-4}$ |
| 헥사콥터: 6개 중 4개 필요 | $2.0\times10^{-11}$ | $1.0\times10^{-6}$ |
| 옥토콥터: 8개 중 6개 필요 | $5.6\times10^{-11}$ | $1.0\times10^{-6}$ |
세 가지를 읽는다. 첫째, 쿼드콥터는 하나만 고장 나도 기능을 잃으므로 단위 고장률의 네 배 근처가 그대로 나온다. 둘째, 헥사·옥토는 독립 고장만 보면 치명적 목표 $10^{-9}$를 이미 크게 넘어선다. 셋째, 그런데 β가 1 %이면 $10^{-6}$으로 다섯 자릿수 가까이 나빠진다. 헥사에서 β가 0.1 %여도 $1.0\times10^{-7}$이다. 목표를 충족하려면 $\beta\le10^{-9}/(10^{-4})=10^{-5}$, 곧 0.001 % 여야 한다.
또 하나. 독립 항은 $\lambda$의 세제곱에 비례하고(헥사: $\lambda=10^{-3}$에서 $2.0\times10^{-8}$, $10^{-5}$에서 $2.0\times10^{-14}$), 공통 원인 항은 $\lambda$의 일차에 비례한다. 부품을 더 좋게 만들면 독립 항은 크게 내려가지만 하한은 비례해서만 내려간다. 분산 추진의 안전 이점은 β를 얼마나 낮게 입증하느냐에 달려 있다. 같은 전원 버스, 같은 ESC 제조 로트, 같은 펌웨어, 같은 센서가 β를 올리는 원천이다(2.5·1.19).
8.2.7 모델 기반 개발과 도구
MBSE(8.1.7)와 모델 기반 개발은 인증 증거에서 한 가지 질문을 만든다. 모델이 요구인가, 설계인가? DO-331은 명세 모델(요구를 표현)과 설계 모델(설계를 표현)을 구분하고, 각각에 필요한 검증 활동을 달리한다(요지). 같은 모델이 둘을 겸하면 증거가 섞여 심사에서 문제가 된다.
도구도 증거에 들어온다. 코드 생성기가 만든 코드는 시험으로 다시 검증하지 않는다면 그 도구를 믿을 근거가 필요하다. DO-330은 도구가 오류를 만들 수 있는 정도와 그 오류를 다른 활동이 잡을 가능성으로 도구 인정 수준을 정한다(8.8). 모델과 도구에 기댈수록 인정 부담이 커진다는 점이 실무의 반대급부다.
8.2.8 변경과 계속감항
설계가 바뀌면 개발 보증 활동의 일부를 다시 해야 한다. 변경 하나가 요구를 바꾸고, 그것이 안전 평가를 바꾸고, 영향받는 검증을 다시 하게 만든다. 요구와 증거의 추적(8.1.4)이 되어 있지 않으면 어디까지 다시 해야 하는지 알 수 없다. 변경 통제는 형상 관리(8.22), 인증된 설계의 변경은 설계 변경 승인(20.7), 운용 중 발견된 고장은 계속감항(20.23)의 틀에서 처리한다. 고친 것이 개발 보증 수준을 낮추지 않는지가 변경 심사의 핵심이다.
8.2.9 설계 트레이드오프 — 개발 보증을 어디까지 적용할 것인가
소형 UAS와 초기 eVTOL 프로젝트에서 실제 선택은 이렇게 나뉜다.
- ① 완전 준용. ARP4754B·ARP4761A·DO-178C·DO-254를 인증 프로그램의 입증 수단으로 사용한다. 증거가 가장 완전하고 당국과 합의하기 쉽지만 비용과 일정이 크다. 형식증명을 목표로 하는 eVTOL과 대형 UAS에 맞다.
- ② 규모에 맞춘 준용. 요구 확인·추적성·형상 관리·안전성 평가(FHA)와 DAL 개념은 쓰되, 문서 양과 독립성 입증은 기체 규모에 맞춘다. 중형 UAS, 인증을 준비하는 초기 단계에 맞다.
- ③ 운용 위험 중심. 특정 운용 위험 평가의 견고성 수준(20.14)을 만족하는 데 집중하고 개발 보증 형식은 따로 두지 않는다. 소형·저위험 UAS에 맞다.
견해: ③에서 시작하더라도 FHA·요구 추적·형상 관리, 이 세 가지만은 처음부터 갖춘다. 근거: 나중에 운용 범위를 넓히거나 형식증명으로 올릴 때 가장 비싼 일은 증거를 소급해 만드는 것이고, 시험 기록·설계 근거·변경 이력은 사후에 되살릴 수 없는 경우가 많기 때문이다. 이 판단은 정성 논거이며 비용 효과를 공개 데이터로 확인한 것은 아니다.
8.2.10 세 축 비교
| 항목 | 군용 드론 | 민간 UAS | AAM(eVTOL) |
|---|---|---|---|
| 개발 보증의 근거 | 군 감항 기준·계약 조건(12.3) | 운용 위험 평가의 견고성 수준(20.14), 의무 없는 경우가 많음 | 형식증명 인증기준·특별조건과 입증 수단(20.5·20.6) |
| 안전 목표의 출처 | 체계안전 기준과 감항 기준 | 운용 범주별 목표 | 인증기준의 고장 조건 확률 목표(8.4) |
| 요구 확인 | 소요·시험평가 단계에서 | 제조사 자율 | 인증계획과 확인 계획에서 당국과 합의 |
| 독립성 입증 | 기준에 따라 | 드묾 | 안전 중요 기능에서 필수에 가까움 |
| 증거의 상대 | 군 감항 당국·획득 기관 | 규제 당국의 운용 승인 | 형식증명 당국(설계 조직 승인, 20.3) |
| 도구·모델 증거 | 계약에 따라 | 거의 없음 | DO-330·DO-331 적용이 늘어남 |
8.2.11 관련 규격·프로토콜
| 문서 | 발행 | 무엇을 정하나 | 상세 장 |
|---|---|---|---|
| SAE ARP4754B(ARP4754A는 2010) | SAE | 민간 항공기·시스템 개발 보증 | — |
| SAE ARP4761A | SAE | 안전성 평가 방법 | 8.4 |
| RTCA DO-178C | RTCA | 소프트웨어 개발 보증 | 8.8 |
| RTCA DO-254 | RTCA | 복잡 전자 하드웨어 보증 | 8.8 |
| RTCA DO-330·DO-331 | RTCA | 도구 인정·모델 기반 개발 | 8.8 |
| RTCA DO-326A | RTCA | 항공 보안 | 8.11 |
| ISO/IEC/IEEE 15288:2023 | ISO·IEC·IEEE | 범용 시스템 수명주기 프로세스 | 9.1 |
| 14 CFR §25.1309·CS 25.1309·SC-VTOL의 해당 요건 | FAA·EASA | 장비·시스템의 안전 요건 | 8.4 |
| FAA AC 20-174 | FAA | ARP4754A의 인정(EASA도 별도 문서로 인용, 번호 (확인 필요)) | 20.5 |
| IEC 61508-6 부속서 D | IEC | β 인자 모형(공통 원인 정량화) | 8.4 |
유료 규격의 본문은 옮기지 않았고, 표의 판·인정 여부는 시점마다 달라질 수 있다. 전체 지도는 A.6에 있다.
8.2.12 관련 규제·인증 요구와의 연결
- 인증기준 → 안전 목표 → FDAL. 형식증명 인증기준(20.5)이 고장 조건과 확률 목표를 정하고, 개발 보증 수준은 그 목표를 만족하는 증거의 엄격함이다. 입증 방법과 적합성 매트릭스는 20.6에 있다.
- 설계 조직 승인(20.3). 승인된 설계 조직은 개발 보증 절차를 갖추고 위임받아 심사에 참여한다.
- 소프트웨어·하드웨어 심사(20.9). 개발 단계별 심사(SOI)에서 IDAL에 맞는 증거를 본다.
- 운용 위험 평가(20.14). 소형 UAS에서는 견고성 수준이 개발 보증의 부담을 대신한다.
- 계속감항(20.23). 운용 중 고장은 안전 평가와 개발 증거를 다시 검토하게 한다.
- 군용. 군 감항인증(12.3)의 요구 기준선과 증거도 같은 개념의 짝이다.
8.2.13 함정과 한계
| 오해 | 실제 | 더 볼 곳 |
|---|---|---|
| DAL이 높으면 고장 확률이 낮다 | DAL은 확률이 아니라 체계적 오류를 억제하는 활동의 엄격함이다 | 8.2.5 |
| 다중화하면 DAL을 낮춰도 된다 | 독립성이 입증될 때만 낮출 수 있고, 공통 원인이 확률의 하한을 정한다 | 8.2.6 |
| ARP4754B를 따르면 인증된다 | 이 문서는 입증 수단의 하나다. 적합 여부는 당국이 인증기준에 비추어 판단한다 | 20.5 |
| 요구 확인은 초기에 한 번이다 | 가정과 요구는 개발 내내 바뀐다. 변경마다 다시 연다 | 8.2.8 |
| 도구가 만든 것은 믿어도 된다 | 도구가 오류를 만들 수 있으면 도구 인정이 필요하다 | 8.8 |
| 소형 UAS에는 무관하다 | 의무는 아니어도 상향 시 증거 소급이 가장 큰 비용이다 | 8.2.9 |
| 위 β 계산이 실제 안전 해석이다 | 노출·검출·점검 간격이 없는 경향 계산이다 | 8.4 |
미해결 문제. 학습 기반 기능(인공지능)은 "요구에서 코드까지의 추적"이라는 틀에 맞지 않아 새 보증 틀이 논의 중이다(20.10). 모델·시뮬레이션을 형식증명 증거로 인정받는 범위, 그리고 eVTOL 분산 추진 구조에서의 독립성 입증 방법도 열려 있다 (확인 필요).
8.2.14 체크포인트·연구 질문
체크포인트:
- 우연 고장과 체계적 오류의 차이를 한 문장씩 말해 보라. 각각을 어떻게 다루는가.
- 고장 조건 등급에서 FDAL이 정해지는 길을 설명하고, DAL이 확률이 아닌 까닭을 말해 보라.
- β가 0.1 %인 3채널 구조가 치명적 목표 $10^{-9}$를 만족하는가. 계산으로 답하라.
- 요구 확인과 검증의 차이를 개발 흐름 그림에서 찾아보라.
- 자신의 프로젝트에 ①②③ 중 무엇이 맞고, 최소한으로 갖출 세 가지는 무엇인가.
연구 질문(25.7에 모은다):
- 분산 전기 추진(여섯 개 이상의 로터)에서 β를 어떻게 추정하고 입증할 수 있는가.
- 소형 UAS·eVTOL에서 개발 보증을 규모에 맞춘 준용의 효과를 공개 사고·인증 자료로 정량화할 수 있는가.
- 학습 기반 기능의 DAL 할당과 독립성 입증을 어떻게 정의할 것인가.
- 모델 기반 증거의 인정 범위를 어떤 검증 사례로 넓혀 갈 것인가.
1차 출처(이 장):
- SAE ARP4754B, Guidelines for Development of Civil Aircraft and Systems (2023, 발행 연월
(확인 필요)). ARP4754A는 2010. - SAE ARP4761A, Guidelines for Conducting the Safety Assessment Process on Civil Aircraft, Systems, and Equipment (판·연도
(확인 필요)). - RTCA DO-178C(2011), DO-254, DO-330, DO-331, DO-326A.
- FAA AC 20-174, Development of Civil Aircraft and Systems.
- 14 CFR §25.1309와 EASA CS-25(CS 25.1309).
- EASA SC-VTOL-01(2019년 최초 공표, 이후 개정은
(확인 필요)). - IEC 61508-6, 부속서 D(β 인자 모형).
- ISO/IEC/IEEE 15288:2023.
- 계산:
mil-uam/fig-src/8.2-calc.py(표준 라이브러리만 사용).
다음 장: 8.3 — 체계 통합: 하위체계·탑재체 통합과 인터페이스 관리. 개발 흐름의 "구현·통합" 칸을 열어, 서로 다른 팀이 만든 하위체계가 인터페이스 문서(ICD)와 전력·데이터·시야 요구를 통해 어떻게 한 기체로 합쳐지는지 본다.