제8부 안전·보안·시스템공학
8.1 요구공학·MBSE·디지털 엔지니어링
8.1.1 이 장에서 배우는 것 / 선수 지식 / 특히 중요한 독자
이 장은 제8부(안전·보안·시스템공학)의 첫 장이다. 제8부의 나머지 장은 모두 한 가지 질문에 기댄다. 무엇을 만들어야 하는지 어떻게 합의하고, 만들어진 것이 그 합의를 지켰음을 어떻게 보이는가. 군용 드론도, 민간 UAS도, eVTOL도 이 질문에서 벗어나지 못한다. 다만 합의의 상대(군 소요 기획 부서, 고객, 인증 당국)와 증거의 형식이 다를 뿐이다.
배우는 것:
- 요구의 종류와 좋은 요구의 조건 — 기능·성능·인터페이스·제약, 한 문장에 한 요구, 검증할 수 있는 문장, 문장 틀(EARS).
- 흐름 내리기와 추적성 — 이해관계자 요구가 시스템·하위체계·부품 요구로 내려가고, 검증이 아래에서 위로 이어지는 짝 구조.
- 검증과 확인 — 둘의 차이, 시험·해석·검사·시연 네 방법.
- 기술성능지표(TPM)와 여유 — 질량·전력·체공이 개발 중에 자라고 여유가 줄어드는 방식.
- MBSE와 디지털 엔지니어링 — 문서 중심과 모델 중심의 차이, SysML과 Capella, 디지털 스레드와 디지털 트윈, 그리고 도입 비용.
- 숫자로 해 보기 — 2 kg급 쿼드콥터에 "탑재 0.5 kg, 호버 30분"을 요구하면 해석만으로 요구 충돌이 드러난다.
선수 지식: 시스템공학 사전 지식은 필요 없다. 워크스루의 호버 동력식은 1.7.7, 양력·추력의 기초는 1.1에 있다. 개발 프로세스 전체(ARP4754B)는 8.2가, 안전성 평가는 8.4가 이어 받는다.
특히 중요한 독자: 엔지니어는 8.1.3~8.1.6과 8.1.9를 읽는다. 인증 담당자는 요구와 증거의 연결(8.1.4·8.1.13)을, 법무는 요구 명세가 계약 문서가 되는 지점(8.1.3·8.1.14)을 본다. 사업·정책 담당자는 8.1.9와 8.1.11만 읽어도 "왜 요구 한 줄이 일정과 비용에 영향을 주는가"를 이해할 수 있다.
기준 시점과 정직성. 2026년 10월 기준이고 지식은 2026년 중반까지다. 인용한 표준의 판(版)은 개정될 수 있고, 유료 표준은 본문을 옮기지 않고 구조와 요지만 적었다. 워크스루의 기체와 모든 입력값은 원리를 보이기 위한 가정이며 특정 제품의 제원이 아니다. 확인하지 못한 판·날짜는
(확인 필요)로 표시했다.
8.1.2 개념 — 요구는 설계의 입력이자 검증의 기준이자 인증의 증거다
시스템공학은 "무엇을 만들 것인가"를 합의하고, 그 합의가 준수되었음을 증거로 보이는 일이다. 요구(requirement)는 그 합의를 문장으로 적은 것이다. 요구는 세 가지 일을 한다.
- 설계의 입력. 설계자는 요구에서 출발해 형상과 부품을 고른다.
- 검증의 기준. 시험과 해석은 요구를 판정 기준으로 삼는다. 요구가 흐리면 합격과 불합격을 가를 수 없다.
- 계약·인증의 증거. 구매 계약의 성능 조항, 인증기준의 적합성 입증, 운용 승인의 완화 수단은 모두 결국 요구와 증거의 짝이다.
세 축은 요구의 출처가 다르다. 군용 드론은 군 소요 기획(12.4)에서 작전운용성능(ROC)이 내려오고 획득 절차(12.5)를 따라 체계 요구로 바뀐다. 민간 UAS는 고객의 용도와 운용 환경이 요구를 만들고, 운용 승인(20.14)이 제약을 더한다. AAM은 인증기준과 특별조건(20.5)이 안전 요구를 대량으로 일으키고, 그 요구가 설계에 가장 큰 영향을 준다. 출처는 달라도 이후의 절차는 같다. 요구를 작성하고, 나누고, 추적하고, 검증한다.
이 장이 다루는 도구는 두 층이다. 요구공학은 요구를 작성하고 관리하는 체계적 방법이다. MBSE(모델 기반 시스템공학)와 디지털 엔지니어링은 그 요구와 설계 정보를 문서가 아니라 연결된 모델과 데이터로 다루는 방식이다. 요구공학이 없으면 MBSE는 그림을 그리는 일에 그친다.
8.1.3 요구의 종류와 좋은 요구의 조건
8.1.3.1 요구의 종류
| 종류 | 무엇을 정하나 | 예(기준 기체, 가정) | 흔한 실수 |
|---|---|---|---|
| 기능 요구 | 시스템이 무엇을 해야 하는가 | 기체는 C2 링크가 끊기면 귀환 모드로 전환해야 한다 | 어떻게 할지(해법)까지 적는다 |
| 성능 요구 | 얼마나, 어떤 조건에서 | 해면 표준대기에서 탑재 0.5 kg으로 20분 이상 호버 | 조건·허용오차가 빠진다 |
| 인터페이스 요구 | 외부·내부 접점의 형식 | 탑재 전원은 12 V ±5 %, 최대 25 W(→ 8.3) | 기계·전기·데이터를 한 줄에 섞는다 |
| 제약 요구 | 해(解)의 범위를 한정 | 최대이륙중량(MTOW) 3.50 kg 이하 | 이유가 적혀 있지 않다 |
| 품질·비기능 요구 | 안전·신뢰성·정비성·보안 | 치명적 고장 조건 확률 목표(→ 8.4) | 수치 없이 "높은 신뢰성"만 적는다 |
요구는 층위로도 나눈다. 이해관계자 요구는 사용자·고객의 언어로 적은 필요이고("30분쯤 떠 있었으면"), 시스템 요구는 시스템이 만족해야 할 검증 가능한 문장이다. 파생 요구는 상위 요구에서 직접 나오지 않고 설계 선택에서 생긴 요구다. 예컨대 큰 모터를 고르면 ESC 전류와 배선 굵기, 냉각에 대한 요구가 새로 생긴다. 파생 요구는 상위에서 추적되지 않기 때문에 빠뜨리기 쉽고, 안전과 직결되는 것은 안전성 평가(8.4)가 모은다.
8.1.3.2 좋은 요구의 조건
ISO/IEC/IEEE 29148은 개별 요구가 갖출 특성을 나열한다(필요·적절·명확·완전·단일·실현 가능·검증 가능·정확·적합. 우리말 옮김은 이 책의 것이고 규격 본문은 옮기지 않았다). 실무에서 가장 자주 깨지는 다섯 가지만 표로 본다.
| 특성 | 뜻 | 위반 문장 → 고친 문장(예시 값, 가정) |
|---|---|---|
| 명확 | 읽는 사람마다 같은 뜻 | "충분히 오래 비행해야 한다" → "해면 표준대기에서 탑재 0.5 kg으로 20분 이상 호버해야 한다(사용 가능 에너지 80 % 기준)" |
| 단일 | 한 문장에 한 요구 | "화면은 빠르고 사용하기 쉬워야 한다" → "화면은 입력 후 0.2초 이내에 응답해야 한다(95번째 백분위)". 사용성은 따로 작성한다 |
| 검증 가능 | 시험·해석·검사·시연으로 판정 | "링크가 끊기면 안전하게 대응한다" → "링크 두절이 3초 지속되면 설정 고도로 상승해 귀환점으로 자동 비행한다(→ 2.6)" |
| 구현 중립 | 해법이 아니라 필요를 적는다 | "4S 배터리를 사용한다" → 필요한 에너지·전압·질량을 적고, 해법을 고정해야 한다면 제약으로 이유와 함께 적는다 |
| 실현 가능 | 물리·일정·비용 안에서 가능 | "탑재 0.5 kg으로 호버 30분"(→ 해석하면 이 기체 구조로는 불가, 8.1.9.2) |
모호한 낱말은 경고 신호다. 충분한·적절한·빠른·가능한 한·등·최소한·일반적으로·필요 시·사용자 친화적 같은 말이 보이면 수치와 조건으로 바꾸거나 요구가 아니라 설명으로 내린다.
8.1.3.3 문장 틀 — EARS
EARS(Easy Approach to Requirements Syntax)는 요구 문장을 몇 가지 틀로 제한해 모호함을 줄이는 방법이다(Mavin 등, 2009). 틀은 "언제"를 앞에 두는 것이 핵심이다.
| 패턴 | 형식 | 예(가정) |
|---|---|---|
| 상시 | 시스템은 …해야 한다 | 기체는 호버 시 자세 오차를 2° 이내로 유지해야 한다 |
| 사건 구동 | …가 일어나면, 시스템은 …해야 한다 | C2 링크 두절이 3초 지속되면, 비행제어 컴퓨터는 귀환 모드로 전환해야 한다 |
| 상태 구동 | …인 동안, 시스템은 …해야 한다 | 배터리 잔량이 25 % 미만인 동안, 기체는 새 임무 시작 명령을 거부해야 한다 |
| 원치 않는 동작 | …이면, 시스템은 …해야 한다 | GNSS 품질 지표가 임계 이하이면, 기체는 대체 항법으로 전환해야 한다(→ 제4부) |
| 선택 기능 | …가 장착된 경우, 시스템은 …해야 한다 | 카메라 짐벌이 장착된 경우, 기체는 짐벌 전원을 별도 퓨즈로 공급해야 한다 |
틀을 사용한다고 요구가 옳아지지는 않는다. 틀은 문장의 빈칸(조건·응답)을 눈에 보이게 만들 뿐이다.
8.1.4 요구의 흐름 내리기와 추적성
요구는 위에서 아래로 분해되고 할당된다. 시스템 요구 "호버 20분"은 배터리 에너지, 호버 효율(성능지수·전동기 효율), 질량 요구로 나뉘어 각각 하위체계에 배분된다. 검증은 반대 방향(아래에서 위)으로 이어진다. 부품 시험이 하위체계 통합 시험으로, 다시 시스템 검증으로 올라간다. 같은 층의 요구와 검증은 짝이다.
추적성(traceability) 은 이 연결을 기록으로 남기는 일이다. 한 요구에 대해 세 방향의 연결이 있어야 한다.
| 방향 | 묻는 것 | 끊겼을 때의 증상 |
|---|---|---|
| 위로(출처) | 이 요구는 왜 있나 | 고아 요구 — 불필요한 기능이거나 빠진 상위 요구 |
| 아래로(구현) | 어떤 설계 요소가 이 요구를 만족하나 | 매달린 요구 — 아무도 구현하지 않는다 |
| 옆으로(검증) | 어떤 시험·해석이 이 요구를 판정하나 | 검증 없는 요구 — 만족했는지 알 수 없다 |
검증 연결의 완성도는 비율로 본다.
$$C_{\mathrm{ver}}=\frac{N_{\mathrm{verified}}}{N_{\mathrm{req}}}$$
여기서 $N_{\mathrm{req}}$는 요구의 수, $N_{\mathrm{verified}}$는 검증 방법·단계·합격 기준이 모두 정해진 요구의 수다. 이 값이 1이어도 안심할 수는 없다. 연결이 있다는 것과 연결이 타당하다는 것은 다르다. 엉뚱한 시험에 요구를 걸어도 비율은 올라간다(8.1.14).
기준선(baseline)을 정하고 그 뒤의 변경을 통제하는 일은 형상 관리(8.22)가 맡는다. 이 장은 변경 통제의 대상, 곧 요구와 연결 관계를 다룬다.
8.1.5 검증과 확인
두 낱말은 자주 섞인다.
- 검증(verification) — 만든 것이 요구를 만족하는가. "제품을 올바르게 만들었는가."
- 확인(validation) — 요구 자체가 맞는가, 그 요구를 만족하면 운용 목적을 이루는가. "올바른 제품을 만들었는가." (Boehm, 1981에서 널리 퍼진 구분이다.)
확인은 개발 초기에 요구를 대상으로 하는 것과 마지막에 완성된 시스템을 대상으로 하는 것이 있다. 민간 항공기 개발 지침(ARP4754B)은 요구 확인을 별도의 활동으로 두고(8.2), 워크스루에서 보듯 "30분"이라는 요구는 확인 단계에서 "왜 30분인가"로 되물어야 한다.
검증은 보통 네 방법으로 한다(NASA 핸드북의 분류).
| 방법 | 무엇을 하나 | 증거 | 기준 기체 예 | 특징 |
|---|---|---|---|---|
| 시험(Test) | 실물을 실제 조건에서 구동해 측정 | 시험 데이터·보고서 | 추력 시험대에서 로터당 최대 추력 측정 | 가장 신뢰, 가장 비쌈 |
| 해석(Analysis) | 검증된 모형으로 계산·시뮬레이션 | 해석 보고서 | 호버 체공을 운동량 이론으로 계산 | 모형 자체의 검증이 필요 |
| 검사(Inspection) | 육안·측정·문서 대조 | 검사 기록 | 칭량으로 MTOW 확인 | 물리량이 단순할 때 |
| 시연(Demonstration) | 기능이 동작함을 보임 | 시연 기록 | 링크 두절 시 귀환 시연 | 정량 판정이 어려울 때 |
인증 실무에서는 여기에 설계 검토와 유사성(이미 인증된 설계와의 비교) 인용이 더해진다(20.6). 요구를 작성할 때 검증 방법을 같이 정한다. 방법을 정할 수 없는 문장은 아직 요구가 아니다.
8.1.6 기술성능지표(TPM)와 여유 관리
개발이 진행되면 설계는 요구에 얼마나 다가갔는지 숫자로 추적해야 한다. 그 숫자가 기술성능지표(TPM, technical performance measure) 다. 무인기에서 자주 추적하는 것은 질량, 전력, 체공·항속, 소음(1.31), 링크 마진(3.8), 소프트웨어 크기와 처리 부하다.
TPM 관리의 핵심은 여유(margin) 다. 용어는 기관마다 조금씩 달라서 이 책은 다음처럼 사용한다.
| 용어 | 이 책의 뜻 | 누가 쓰나 |
|---|---|---|
| 성장 허용 | 설계가 아직 충분히 성숙하지 않아서 예측값이 커질 것으로 미리 더해 두는 몫 | 설계자(예측값에 포함) |
| 여유 | 예측값과 요구 한계 사이에 일부러 남긴 간격 | 프로그램 관리자 |
| 예비 | 위 둘 이후에도 남겨 두는 마지막 몫 | 관리자 보관 |
개발 단계가 지나면 불확실성이 줄어들고, 그만큼 여유를 소진해도 되는 속도를 정책으로 정한다. 질량 성장 허용의 크기는 기관·프로젝트마다 다르다. 이 장의 워크스루는 비율을 단정하지 않고, 여유가 얼마나 있어야 요구를 충족할 수 있는지를 계산으로 거꾸로 구한다(8.1.9.3). 우주 쪽에는 질량 성장 허용을 정하는 규격(AIAA S-120)이 알려져 있으나 항공기 적용은 확인하지 못했다 (확인 필요).
8.1.7 모델 기반 시스템공학(MBSE)
문서 중심 방식에서는 요구 명세서, 인터페이스 문서, 시험 계획서가 각각 워드·스프레드시트 파일이고, 사람이 문서 사이의 일치를 맞춘다. 모델 중심 방식에서는 요구·기능·구조·시험이 한 모델 안의 객체이고 서로 연결되어 있다. 문서와 표는 모델에서 뽑아 낸 뷰다.
MBSE의 대표 언어는 SysML(OMG)이다. SysML v1.x는 다이어그램 아홉 종을 가진다.
| 분류 | 다이어그램 | 무엇을 그리나 |
|---|---|---|
| 요구 | 요구 | 요구 사이의 파생·정제와 설계 요소의 충족·검증 관계 |
| 구조 | 블록 정의, 내부 블록, 패키지 | 구성 요소와 그 연결, 모델 정리 단위 |
| 구조 | 파라메트릭 | 요구·성능을 제약식으로 연결해 계산 |
| 행위 | 활동, 시퀀스, 상태 기계, 유스케이스 | 기능 흐름, 메시지 순서, 모드 전이, 사용 시나리오 |
SysML v2는 정확한 의미를 가진 새 언어 핵심(KerML)과 텍스트 표기, 표준 API를 도입했고 OMG가 2025년에 채택한 것으로 알려져 있다 (확인 필요). 도구와 교육 자료의 성숙도는 도입 전에 별도로 확인해야 한다. 다른 접근으로는 ARCADIA 방법론과 Eclipse Capella가 있다. 운용 분석·시스템 분석·논리 구조·물리 구조의 단계로 모델을 쌓는다.
MBSE가 주는 것은 세 가지다. 요구 변경의 영향 분석(어떤 블록과 시험이 연결되어 있는가), 일관성 검사, 뷰의 자동 생성이다. 대가도 있다. 모델을 다룰 줄 아는 사람, 도구의 수명, 모델 품질 관리(틀린 모델은 틀린 문서만큼 해롭다), 공급사 사이의 모델 교환(ReqIF·XMI)이다. 가장 흔한 실패는 목적 없는 모델링이다. "무엇을 알아내려고 이 모델을 만드는가"를 먼저 정하고, 그 질문에 답하는 만큼만 모델링한다.
8.1.8 디지털 엔지니어링 — 디지털 스레드와 디지털 트윈
디지털 엔지니어링은 MBSE를 수명주기 전체로 넓힌 개념이다. 미 국방부의 Digital Engineering Strategy(2018)는 모델을 공식화하고, 권위 있는 진실원(ASoT, authoritative source of truth) 을 두고, 기술 혁신과 기반 환경, 문화와 인력의 전환을 다섯 목표로 제시했다(요지). 이후 국방 정책 문서로 이어졌으나(DoDI 5000.97, 2023) (확인 필요) 이 장은 정책의 세부를 다루지 않는다.
| 개념 | 뜻 | 흔한 오해 |
|---|---|---|
| 권위 있는 진실원 | 한 데이터에는 한 원천만 인정 | 복사본이 여러 곳에 흩어져 서로 다르다 |
| 디지털 스레드 | 요구→설계→제작→시험→운용을 잇는 데이터 연결 | 폴더를 같은 서버에 모으는 것으로 착각 |
| 디지털 트윈 | 실제 기체 개체 와 데이터로 동기화되는 모형 | 3차원 CAD 모형이면 트윈이라고 부른다 |
시뮬레이션 모형이 디지털 트윈이 되려면 운용 중인 기체의 비행 로그·정비 이력과 이어져 갱신되어야 한다. 시험평가와 모형·시뮬레이션의 체계는 8.19, 시뮬레이션 상호운용 표준은 9.21, 비행 기록은 8.23에서 다룬다.
한계 셋을 기억해 둔다. 첫째, 모델은 가정의 요약이다. 해석이 검증 증거가 되려면 그 모형이 검증되어 있어야 한다(8.19·20.6). 둘째, 디지털 스레드 자체가 보호할 자산이다. 설계 데이터와 모형은 사이버 공격의 표적이므로 보안 장(8.11~8.13)의 대상이다. 셋째, 공급망 데이터 공유와 지식재산이 도입 속도를 정한다.
8.1.9 워크스루 — 2 kg급 쿼드콥터에 탑재 0.5 kg과 호버 30분을 요구한다
8.1.9.1 요구와 가정
이해관계자가 말한다. "0.5 kg짜리 카메라 짐벌을 싣고 30분쯤 떠 있었으면 좋겠다." 기준 기체(1.7.7: 지름 0.254 m 로터 4개)로 이 요구가 풀리는지 계산한다. 모형은 1.7.7과 같다.
| 항목 | 값 | 비고 |
|---|---|---|
| 비배터리 질량 $M_0$ | 1.40 kg | 기준 기체 2.0 kg − 배터리 0.6 kg. 탑재는 별도로 더한다 |
| 총 디스크 면적 $A$ | 0.2027 m² | 로터 4개 |
| 성능지수 FM·전동기 효율 $\eta_d$ | 0.62 · 0.78 | 1.7.7 가정 |
| 보조 전력 $P_{\mathrm{aux}}$ | 15 W | |
| 팩 비에너지 $e$ | 170 Wh/kg (비교: 250) | 팩 수준 가정(1.21) |
| 사용 가능 비율 $u$ | 0.8 | 예비 20 % |
| 공기 밀도 | 1.225 kg/m³ | 해면 표준대기 |
이륙 질량 $m=M_0+m_p+m_b$($m_p$는 탑재, $m_b$는 배터리)이고 호버 전기 동력과 체공은 다음과 같다.
$$P_{\mathrm{el}}=\frac{W^{3/2}}{\sqrt{2\rho A}\,\mathrm{FM}\,\eta_d}+P_{\mathrm{aux}},\qquad t=\frac{60\,u\,e\,m_b}{P_{\mathrm{el}}}\ \text{[분]}$$
$W=mg$는 무게다. 결론부터: 이 모형은 배터리를 늘릴수록 체공이 늘다가 포화한다. 배터리 자신이 무게여서 호버 동력을 키우기 때문이다(1.7.7.2).
8.1.9.2 해석으로 요구 충돌을 찾는다
네 조합을 풀면 다음과 같다(계산: fig-src/8.1-calc.py, 표준 라이브러리 math).
| 요구(탑재 0.5 kg) | 팩 비에너지 | 필요 배터리 | 이륙 질량 | 판정 |
|---|---|---|---|---|
| 호버 30분 | 170 Wh/kg | 해 없음 | — | 배터리를 아무리 늘려도 최대 약 25.0분 |
| 호버 30분 | 250 Wh/kg | 1.371 kg | 3.271 kg | 가능(팩 가정이 낙관적일 수 있음) |
| 호버 20분 | 170 Wh/kg | 1.304 kg | 3.204 kg | 가능 |
| 호버 20분 | 250 Wh/kg | 0.630 kg | 2.530 kg | 가능 |
이 모형은 비배터리 질량 1.40 kg을 고정했다. 실제로는 이륙 질량이 커지면 프레임·모터도 무거워지므로 실제 한계는 이보다 낮다. 곧 "해 없음"은 결론으로 안전하고 "가능"은 낙관적이다.
요구 충돌을 찾았으니 선택지가 생긴다. 저자의 판단은 "견해"로 구분해 적는다.
- 요구를 낮춘다(20분). 형상을 그대로 두고 비용·일정을 준수한다. 이해관계자의 필요가 실제 30분 호버인지 먼저 확인해야 한다.
- 에너지를 높인다(팩 250 Wh/kg). 전지 기술이 그 값을 팩 수준에서 제공할 수 있는가가 관건이고, 비용과 안전 문제(1.21·15.5)가 따라온다.
- 형상을 바꾼다. 호버 중심이 아니라 순항 효율이 좋은 결합형 VTOL(1.11)로 가면 같은 에너지로 더 오래 날 수 있으나 기체가 복잡해진다.
견해: 첫 조치는 셋 중 하나를 고르는 것이 아니라 요구 확인이다. "30분"이 제자리 호버 시간인지, 이동까지 포함한 임무 시간인지 먼저 묻는다. 호버가 임무의 일부일 뿐이라면 요구를 "호버 합계 몇 분, 그 밖은 이동"으로 쪼개는 편이 형상을 바꾸는 3번보다 훨씬 싸다. 근거: 이 기체는 호버 전기 동력이 270 W에서 532 W로 거의 두 배가 되는 영역에 있고(8.1.9.3), 호버 시간을 줄이면 그만큼 배터리와 이륙 질량이 함께 줄기 때문이다.
8.1.9.3 질량 증대 계수와 질량 여유
협상한 요구(20분, 170 Wh/kg)의 해를 파생 요구로 풀어 본다.
| 양 | 값 | 기준 기체(2.0 kg)와 비교 |
|---|---|---|
| 이륙 질량 | 3.204 kg | 1.60배 |
| 호버 전기 동력 | 532 W | 270 W의 1.97배 |
| 디스크 하중 | 155 N/m² | 96.8 N/m²의 1.60배 |
| 로터당 호버 추력 | 7.86 N | 4.905 N의 1.60배 |
| 추력 대 무게비 2를 요구하면 로터당 최대 추력 | 15.7 N | 기준 로터·ESC의 용량 재검토가 필요(파생 요구) |
| 팩 에너지 / 사용 가능 | 221.7 Wh / 177.4 Wh | 배터리 1.304 kg |
시스템 요구 하나가 로터와 ESC에 대한 파생 요구를 만들었다는 점에 주목한다. 추력 대 무게비 2는 이 장의 가정이다.
더 중요한 양은 질량 증대 계수(growth factor)다. 20분 요구를 유지하면서 비배터리 질량 $M_0$를 늘리면 이륙 질량이 얼마나 늘어나는가를 수치 미분으로 구했다.
$$\frac{\partial m}{\partial M_0}\approx 2.46$$
비배터리 질량이 1 g 늘면 이륙 질량이 약 2.46 g 늘어난다. 늘어난 무게가 호버 동력을 키우고, 그 동력을 채우려 배터리가 커지고, 커진 배터리가 다시 무게가 되기 때문이다.
이륙 질량 상한(MTOW 3.50 kg, 가정)을 준수해야 하면 같은 현상이 체공 손실로 나타난다. 탑재 0.5 kg, 170 Wh/kg 고정이다.
| 비배터리 질량 성장 | $M_0$ [kg] | 남는 배터리 [kg] | 호버 체공 [분] |
|---|---|---|---|
| 0 % | 1.400 | 1.600 | 21.6 |
| +5 % | 1.470 | 1.530 | 20.6 |
| +10 % | 1.540 | 1.460 | 19.7 |
| +15 % | 1.610 | 1.390 | 18.7 |
| +20 % | 1.680 | 1.320 | 17.8 |
임계는 +8.3 %($M_0$ = 1.516 kg)다. 이를 넘으면 20분 요구가 깨진다. 곧 이 설계에서는 비배터리 질량이 설계 초기 예측보다 8 % 넘게 자라지 않도록 TPM으로 매 단계 확인해야 하고, 초기 성장 허용이 8 %보다 작게 잡혀 있었다면 요구를 충족하지 못할 가능성이 크다.
8.1.9.4 추적 행렬
요구를 EARS 틀로 작성하고 출처·검증을 연결한 예다(값은 모두 가정).
| ID | 요구 | 출처 | 할당 | 검증(방법·단계) |
|---|---|---|---|---|
| N-01 | 탑재 0.5 kg을 싣고 20분 이상 떠 있을 것 | 이해관계자 | 시스템 | 확인(운용 시연) |
| SR-01 | 기체는 0.5 kg 탑재를 장착·분리할 수 있어야 한다 | N-01 | 기체 구조 | 검사 + 시험(하중), 하위체계 |
| SR-02 | 기체는 해면 표준대기에서 탑재 0.5 kg으로 20분 이상 호버해야 한다 | N-01 | 추진·에너지 | 해석(8.1.9.2) + 시험(비행), 시스템 |
| SR-03 | 이륙 질량은 3.50 kg 이하여야 한다 | 제약 | 전체 | 검사(칭량), 시스템 |
| SR-04 | 최대 추력은 이륙 무게의 2배 이상이어야 한다 | 파생(조종성) | 추진 | 시험(추력 시험대), 하위체계 |
| SR-05 | 비배터리 질량은 1.50 kg 이하여야 한다 | SR-02·SR-03에서 파생 | 구조·추진·항전 | 검사(칭량), 하위체계 |
$C_{\mathrm{ver}}$는 위 다섯 시스템 요구에서 5/5다. 이 표의 SR-05가 질량 증대 계수 계산에서 나온 파생 요구라는 점이 중요하다. 상위 요구 어디에도 "1.50 kg"은 적혀 있지 않다.
8.1.10 설계 트레이드오프 — 문서 중심·모델 중심·하이브리드
방식은 셋으로 나눌 수 있고, 어느 하나가 정답은 아니다.
| ① 문서 중심 | ② 모델 중심(SysML·Capella) | ③ 하이브리드 | |
|---|---|---|---|
| 구성 | 요구 관리 도구·표 계산·문서 | 모든 요구·구조·행위를 한 모델에 | 요구는 데이터베이스, 구조·인터페이스만 모델 |
| 장점 | 학습 부담 적음, 누구나 읽음 | 영향 분석·일관성 검사·뷰 자동 생성 | 도입 비용 대비 효과가 균형 |
| 단점 | 문서 사이 불일치, 변경 추적이 수작업 | 도구·인력 비용, 모델 품질 관리 부담 | 두 체계의 연결을 사람이 유지함 |
| 맞는 곳 | 소규모·단일 형상·짧은 개발 | 대형·다형상·공급사 다수·인증 증거가 큰 개발 | 중형 UAS·eVTOL 초기 단계 |
견해: 요구가 수백 개 이하이고 형상이 하나인 무인기 개발에서는 ③을 권한다. 근거는 위험이 모델링 도구가 아니라 요구의 추적과 파생 요구의 누락에 있고, 이는 요구 데이터베이스와 인터페이스 모델만으로도 상당 부분 막히기 때문이다. 반대로 공급사가 많고 인증 증거(20.6)를 대량으로 연결해야 하는 eVTOL 형식증명 프로그램은 ②의 이점이 커진다. MBSE 도입 효과를 정량으로 보인 공개 근거는 제한적이라(8.1.14) 이 판단은 정량이 아닌 정성 논거다.
8.1.11 세 축 비교
| 항목 | 군용 드론 | 민간 UAS | AAM |
|---|---|---|---|
| 요구의 원천 | 군 소요 기획(작전운용성능, 12.4)과 획득 절차(12.5) | 고객 용도·운용 환경·시장, 운용 승인의 제약 | 인증기준·특별조건(20.5)과 사업자의 운용 개념(15.1) |
| 요구 문서의 형식 | 규정된 소요·체계 요구 문서와 계약 | 제조사 내부 명세, 제품 사양서 | 인증계획·인증기준 합의와 적합성 매트릭스 |
| 안전 요구의 비중 | 체계안전·감항 요구(12.3) | 운용 위험 평가의 완화 수단(20.14) | 가장 큼(고장 조건 확률 목표, 8.4) |
| 변경 속도 | 소요 변경이 느리고 계약 통제 | 시장 대응으로 빠름 | 형식증명 이후 설계 변경이 무겁다(20.7) |
| 추적성 의무 | 획득 계약·감항 기준에 따라 | 법적 의무 없음, 제조사 선택 | 소프트웨어·시스템 개발 보증에서 사실상 필수(8.2·8.8) |
| MBSE·디지털 엔지니어링 | 국방 정책 차원의 도입 압력(8.1.8) | 선택. 규모 큰 제조사가 도입 | 다수 공급사와 인증 증거 때문에 도입 유인이 큼 |
8.1.12 관련 규격·프로토콜
| 문서 | 발행 | 무엇을 정하나 | 상세 장 |
|---|---|---|---|
| ISO/IEC/IEEE 29148:2018 | ISO·IEC·IEEE | 요구공학 프로세스, 요구의 특성, 명세 내용 | 9.1 |
| ISO/IEC/IEEE 15288:2023 | ISO·IEC·IEEE | 시스템 수명주기 프로세스 | 8.2 |
| ISO/IEC/IEEE 42010:2022 | ISO·IEC·IEEE | 아키텍처 기술(관점·뷰) | 9.1 |
| SAE ARP4754B | SAE | 민간 항공기·시스템 개발 보증(요구 확인 포함) | 8.2 |
| RTCA DO-178C | RTCA | 소프트웨어 요구와 추적성 | 8.8 |
| OMG SysML v1.x·v2 | OMG | 시스템 모델링 언어(v2 채택 시점 (확인 필요)) | 9.1 |
| OMG ReqIF | OMG | 요구 교환 형식 | 9.1 |
| STEP(ISO 10303)·FMI | ISO·Modelica Association | 설계 데이터·시뮬레이션 모형 교환 | 8.19·9.21 |
| INCOSE Systems Engineering Handbook(5판, 2023), NASA/SP-2016-6105 Rev2 | INCOSE·NASA | 지침서(표준이 아님) | — |
EARS와 TAID(시험·해석·검사·시연)는 규격이 아니라 널리 사용되는 작성·분류 관행이다. 규격 전체의 지도는 A.6에 있다.
8.1.13 관련 규제·인증 요구와의 연결
- 인증기준 → 요구. 형식증명의 인증기준과 특별조건(20.5)이 상위 요구가 되고, 적합성 입증 방법과 적합성 매트릭스(20.6)는 "요구-증거 추적표"의 규제판이다. 이 장의 추적성이 곧 매트릭스의 기본 구조다.
- 안전성 평가가 낳는 요구. 고장 조건 분석의 결과로 안전 파생 요구가 생기고(8.4), 안전 사례(8.7)는 요구와 증거를 논증으로 연결한다.
- 소프트웨어·하드웨어 보증. 시스템 요구에서 소프트웨어 요구, 소스 코드, 시험까지의 양방향 추적성 자료가 요구된다(8.8·20.9).
- 형상·변경 통제. 기준선과 변경 심사(8.22), 설계 변경의 인증 영향(20.7).
- 운용 승인. 운용 위험 평가의 완화 수단은 곧 운용 요구다(20.14).
- 군 감항. 군용 무인기의 감항인증(12.3)도 요구 기준선과 증거의 짝을 전제한다.
8.1.14 함정과 한계
| 오해 | 실제 | 더 볼 곳 |
|---|---|---|
| 요구는 한 번 정하면 끝이다 | 학습하며 바뀐다. 문제는 변경 자체가 아니라 통제되지 않은 변경이다 | 8.22 |
| MBSE는 SysML 그림을 그리는 일이다 | 그림은 뷰다. 핵심은 연결된 모델 데이터와 모델링 목적이다 | 8.1.7 |
| 추적 행렬이 100 %면 충분하다 | 연결의 존재와 타당성은 다르다. 엉뚱한 시험에 걸어도 100 %가 나온다 | 8.1.4 |
| 후반 변경 비용은 100배 | 널리 인용되는 배수는 근거가 약하다(비판: Bossavit, 2013). 일찍 발견할수록 대체로 싸다는 방향만 안전하다 | — |
| 디지털 트윈은 3차원 모형이다 | 실제 개체와 데이터로 동기화되어 용도에 쓰일 때 트윈이다 | 8.19 |
| 해석으로 검증하면 시험은 필요 없다 | 해석은 모형이 검증되어 있을 때만 증거가 된다 | 8.19·20.6 |
| 요구가 많을수록 안전하다 | 요구마다 검증·변경 비용이 든다. 필요 없는 요구는 설계를 제한하는 제약이다 | 8.1.3 |
| 이 장의 워크스루가 실제 설계다 | 비배터리 질량 고정, 호버 모형은 낙관적인 가정이다 | 1.7.7 |
미해결 문제. ① 인증 당국이 모델 기반 증거를 어디까지 받아들이는가, ② MBSE 효과의 공개된 정량 근거, ③ 요구의 자동 점검(언어 모델 활용 포함)의 신뢰성과 인증 수용은 열려 있다 (확인 필요).
8.1.15 체크포인트·연구 질문
체크포인트:
- 한 요구에서 위·아래·옆 세 방향의 연결을 대 보라. 끊긴 방향의 증상은 무엇인가.
- "충분히 오래 비행해야 한다"를 EARS 틀과 검증 방법까지 갖춘 요구로 고쳐 작성해 보라.
- 검증과 확인의 차이를 워크스루의 "30분" 요구로 설명해 보라.
- 질량 증대 계수 2.46은 무엇에서 나오고, 왜 이 값이 질량 여유 정책을 바꾸는가.
- 문서 중심·모델 중심·하이브리드 중 자신의 프로젝트에 맞는 것과 그 근거는 무엇인가.
연구 질문(25.7에 모은다):
- 요구 변경의 비용 곡선을 무인기·eVTOL 개발에서 실증한 연구가 있는가. 없다면 어떤 데이터로 만들 수 있는가.
- 모델 기반 증거(해석·시뮬레이션)를 형식증명에서 인정받기 위한 모형 검증의 최소 요건은 무엇인가.
- 질량·전력 TPM의 개발 단계별 성장 허용을 소형 무인기에서 공개 데이터로 추정할 수 있는가.
- 요구 점검에 언어 모델을 사용할 때 위음성(놓친 모호함)을 어떻게 측정하고 통제할 것인가.
1차 출처(이 장):
- ISO/IEC/IEEE 29148:2018, Systems and software engineering — Life cycle processes — Requirements engineering.
- ISO/IEC/IEEE 15288:2023, Systems and software engineering — System life cycle processes.
- INCOSE, Systems Engineering Handbook, 5th ed., Wiley, 2023.
- NASA/SP-2016-6105 Rev2, NASA Systems Engineering Handbook.
- SAE ARP4754B, Guidelines for Development of Civil Aircraft and Systems (2023, 발행 연월
(확인 필요)). - Mavin, A., Wilkinson, P., Harwood, A., Novak, M., "Easy Approach to Requirements Syntax (EARS)", 17th IEEE International Requirements Engineering Conference, 2009.
- Boehm, B. W., Software Engineering Economics, Prentice-Hall, 1981.
- Office of the Deputy Assistant Secretary of Defense for Systems Engineering, Digital Engineering Strategy, 2018.
- Bossavit, L., The Leprechauns of Software Engineering, 2013.
- 계산:
mil-uam/fig-src/8.1-calc.py(표준 라이브러리math만 사용).
다음 장: 8.2 — 항공기 개발 프로세스와 시스템공학(ARP4754B). 이 장의 요구·검증·추적이 개발 보증 수준(기능·품목 개발 보증 수준)과 어떻게 연결되는지, 민간 항공기 개발의 표준 흐름 속에서 본다.