국방·항공우주 소프트웨어 검증 — 국방규격·DO-178C·위성 데이터

학습 목표

이 모듈 한 줄 요약 — "다시 배포할 수 없는 소프트웨어". 웹은 잘못 나가면 다시 올리면 된다. 장비에 실린 코드는 패치하는 것 자체가 사업이고, 위성에 올라간 코드는 손이 닿지 않는다. 되돌릴 수 없다는 전제가 시험의 깊이와 증거 요구를 완전히 바꿔 놓는다.

모듈 35 에서 기능안전 규격이 요구하는 활동을, 모듈 46 에서 임베디드 검증의 기법을 다뤘다. 이 모듈은 그 둘을 재배포로 고칠 수 없는 소프트웨어 라는 환경에 적용한다. 장비에 실린 코드는 패치가 사업이고, 위성에 올라간 코드는 손이 닿지 않는다. 그래서 이 분야의 질문은 "잘 되나요" 가 아니다. "요구사항 전부가 검증되었음을 어떻게 아는가" 다. 그 질문에 답하는 유일한 수단이 증거이고, emphasis 가 말하는 바 그대로다 — 재배포로 고칠 수 없는 소프트웨어는 증거로 신뢰를 만든다.

이 모듈은 출처 규율을 다른 모듈보다 엄하게 적용해서 썼다. DO-178C·MC/DC·CC·위성 처리 레벨은 공개 규격이거나 공개 정의가 있어 구조를 그대로 다룰 수 있다. 반면 국방 소프트웨어 규격의 세부 산출물, 무기체계 시험 절차, 비닉 환경의 상세 절차는 공개 확인이 제한적이거나 대외비다. 그 영역은 추정으로 채우지 않고 범위를 줄였다 — 확인되는 것만 쓰고, 나머지는 "원문 확인" 과 질의 목록으로 남겼다. 레슨 1 과 레슨 4 가 특히 그렇게 쓰여 있고, 그 이유를 본문에서 밝혔다. 그리고 실제 무기체계의 취약점·공격 기법·회피 방법은 어느 레슨에도 없다. 이 모듈의 주제는 규격이 요구하는 검증과 증빙이지 공격이 아니다. 보안 시험 기법은 모듈 50 이 맡는다.

여섯 갈래로 간다. 첫째, 규격 환경 읽기 다. 세부를 외우는 것이 아니라 적용 문서와 판본을 확인하고 산출물 목록과 양식을 받아 일정을 역산하는 일 — 이 분야 첫 주의 실제 작업이다. 둘째, DO-178C 와 설계보증수준 이다. 고장 심각도가 수준을 정하고 수준이 목표 수와 독립성을 정하는 사슬을 따라가면, 비공개 영역의 문서도 같은 눈으로 읽을 수 있다. 셋째, MC/DC 구조 커버리지 다. 독립 쌍을 손으로 찾고, 유일원인과 마스킹을 구분하고, 커버리지를 시험 설계의 기준으로 쓰지 않는 순서를 지킨다. 넷째, 시험 환경 이다. 호스트에서 통과한 결과가 왜 증거가 되지 못하는지, 계측이 대상을 바꾼다는 역설을 어떻게 처리하는지, 환경 자체를 어떻게 문서로 적격화하는지다. 다섯째, 위성 데이터 파이프라인 이다. 정답이 없는 산출물의 정확도를 판정하는 네 방법과, 값이 바뀌는 것이 의도인 재처리를 검증 가능하게 만드는 절차다. 여섯째, 보안 인증과 증거 관리 다. CC 가 증명하는 것의 좁은 범위를 정확히 알고, 반출이 통제되는 환경에서 증거를 설계한다.

이 모듈의 실습 과제는 전부 설계·문서 과제 다. 실물 장비·구동부·전원 계통 조작, 안전 장치 우회, 통제 절차 우회는 어떤 과제에도 들어 있지 않고, 실제 현장에서도 하지 않는다. 수치가 필요한 자리는 상상해 넣지 않고 "명세에서 확인한 값(원문 확인)" 으로 쓰게 했다. 이 습관이 이 분야에서 신뢰를 만드는 방식이다.

완료 후 할 수 있는 것

• 국방 소프트웨어 규격 환경에서 세부 내용을 외우는 것보다 적용 문서와 판본 확인이 먼저인 이유를 설명할 수 있다
• 공개 자료로 확인되는 범위와 원문에서만 확인되는 범위를 가르고, 모르는 자리를 빈칸과 확인 요청으로 남길 수 있다
• 착수 질의 목록 6축(적용 문서·산출물과 양식·제출과 검토·추적성·독립성·시험 환경) 을 만들어 답을 문서로 받을 수 있다
• 사업 문서의 용어 정의를 먼저 확인해 "통합 시험" 같은 단어의 범위 혼선을 예방할 수 있다
• 추적 식별자 체계를 설계하고, 추적표를 나중이 아니라 케이스 작성 시점부터 쌓을 수 있다
• 요구 → 시험, 시험 → 요구 양방향 추적으로 시험 누락과 근거 없는 코드를 각각 찾아낼 수 있다
• 고장 상태 심각도 → 소프트웨어 수준(DAL A~E) → 목표 수·독립성이라는 사슬을 설명할 수 있다
• 코드 복잡도가 수준을 정하지 않는다는 점과, 수준 분류가 QA 의 협상 대상이 아니라는 점을 설명할 수 있다
• 수준별 목표 수와 독립성 요구의 모양을 읽어 작업량과 비용 영향을 근거와 함께 말할 수 있다
• 독립성이 사람 분리이며 기록으로 증명된다는 것을 알고, 작성자·검증자가 분리된 양식을 설계할 수 있다
• 계획 문서가 시험 설계를 구속한다는 순서를 알고, 계획 단계에 QA 가 참여해야 하는 이유를 설명할 수 있다
• 목표-증거 매핑표를 설계하고, 증거를 만드는 순간 목표 식별자를 붙이는 운영을 할 수 있다
• 검증이 검토·분석·시험 세 수단임을 알고, 시험으로 덮을 수 없는 요구를 골라낼 수 있다
• 보충 규격 네 종(DO-330·331·332·333) 의 역할을 구분하고, 도구 자격 요구가 도구 선택과 교체를 제약함을 안다
• MC/DC 를 독립 효과로 정의하고, 독립 쌍을 손으로 찾아 조건 n 개에 최소 n+1 개의 시험을 보일 수 있다
• 유일원인과 마스킹 형태의 차이를 설명하고, 도구 설정이 커버리지 수치를 바꾼다는 점을 보고서에 명시할 수 있다
• 커버리지가 시험 설계의 기준이 아니라 사후 측정이라는 순서를 지키고, 그 순서를 뒤집으면 요구 확인이 되지 않는 이유를 설명할 수 있다
• 커버리지 빈 곳을 네 가지(시험 부족·요구 누락·실행 불가 코드·의도적 비활성) 로 분류해 처리하고 근거를 문서화할 수 있다
• 커버리지 숫자를 재현 가능하게 만드는 여섯 조건을 보고서 머리글로 설계할 수 있다
• 조건식 복잡도를 일정·증거 관점의 설계 지적으로 바꿀 수 있다
• 호스트와 대상 하드웨어가 같은 코드를 다르게 실행하는 여섯 축을 들고 활동을 환경에 배분할 수 있다
• 계측이 코드를 바꾸는 역설을 계측·비계측 두 빌드와 형상 동일성 확인으로 처리할 수 있다
• 계측 유무로 결과가 갈리는 것을 결함 신호로 다룰 수 있다
• 실시간 요구를 최악 경로 설계·반복 실행·여유 기준으로 시험 가능하게 만들 수 있다
• 환경 적격성 문서(구성·소프트웨어 식별·대상 동등성·자극·관측·설정 보존·변경 통제) 를 작성할 수 있다
• 환경 변경을 전면·부분·불필요 재실행으로 분류하는 기준을 미리 합의해 둘 수 있다
• 위성 데이터 처리 레벨 0~4 의 구분을 읽고 레벨별 검증 질문을 설계할 수 있다
• 정답이 없는 산출물의 정확도를 네 방법(독립 기준·물리적 타당성·내부 일관성·알려진 사례) 으로 판정할 수 있다
• 품질 플래그의 조건·모순·분포를 검사로 만들고, 플래그 결함의 영향을 두 방향으로 설명할 수 있다
• 재처리를 "달라진 것이 의도한 것뿐인가" 로 검증하고, 변경 명세 없이는 검증할 수 없다고 말할 수 있다
• 산출물 버전 메타데이터와 구·신버전 혼용 방지 장치를 요구할 수 있다
• 대용량 산출물을 메타데이터 → 요약 통계 → 차분 분포 → 설계된 표본 → 시각화 5단계로 비교할 수 있다
• 파이프라인 운영 결함 여섯 유형을 대조 지점 표로 덮을 수 있다
• CC 인증이 "주장한 기능이 선언한 깊이로 검증되었다" 는 좁은 증명임을 설명하고, 보안 시험 생략 주장을 반박할 수 있다
• TOE 경계·ST·PP 의 역할을 구분하고, 운용 환경 가정이 깨지는 조건을 시험으로 만들 수 있다
• 보증수준(EAL) 의 성격과 상호인정 범위가 사업 조건이 되는 이유를 설명할 수 있다
• 보안 기능 주장을 판정 가능한 시험 문장으로 번역하고 양방향 추적표를 만들 수 있다
• 통제 환경에서 증거 형태를 시험 전에 합의하고, 민감 정보를 분리해 두 층(구역 안 상세·구역 밖 보고서) 으로 설계할 수 있다
• 기록할 수 없는 활동에서 참관·서명 확인서를 증거로 쓸 수 있다
• 증거를 제품·환경·시험·증거 네 축의 형상과 묶고, 설정값을 파일로 관리해 첨부할 수 있다
• 변경 영향 분석 양식을 미리 만들어 보안 패치 판단을 빠르게 할 수 있다

채용시장에서의 위치

이 모듈이 겨냥하는 시장은 방산 체계업체와 구성품 공급사, 항공 전자·무인기 개발사, 위성 지상국·관측 데이터 처리 기업, 보안 제품 개발사와 공공 납품 솔루션 기업 이다. 국내 공고는 "방산 사업 경험", "국방규격", "DO-178B/C", "DAL", "MC/DC", "형상관리", "추적성", "신뢰성 시험", "CC 인증 대응", "지상국 시스템", "검보정" 같은 말로 나타난다.

이 시장의 특징은 진입 장벽이 기술이 아니라 문서 체계와 보안 절차에 있다 는 점이다. 그래서 공급이 적고, 한 사업을 끝까지 겪은 사람의 가치가 길게 유지된다. 경력이 쌓이는 방향도 분명하다 — 사업 하나를 착수부터 인수까지 통과한 경험이 그다음 사업의 자격이 된다. 반대로 진입할 때는 "무엇을 읽어야 하는지 모르는 상태" 가 가장 큰 벽이다.

경쟁력이 되는 것은 넷이다. 첫째, 규격을 외우지 않고 확인하는 태도 다. 면접에서 조항을 외워 답하는 것보다 "적용 판본을 먼저 확인하고 산출물 목록과 양식을 받아 일정을 역산한다" 고 답하는 쪽이 실제로 일할 사람처럼 들린다. 둘째, MC/DC 를 실제로 해 본 흔적 이다. 독립 쌍을 손으로 그리고 n+1 을 말하고 도구 설정으로 숫자가 달라진다는 것을 아는 사람과, "조건 조합을 다 보는 것" 이라고 답하는 사람은 즉시 갈린다. 셋째, 환경을 증거로 다루는 습관 이다. "시험을 돌렸습니다" 와 "대상 동등 구성에서 비계측 빌드로 반복 실행해 여유를 확인하고 환경 구성서를 첨부했습니다" 의 차이가 경력의 구분선이 된다. 넷째, 모르는 것을 모른다고 말하고 확인 경로를 제시하는 태도 다. 이 분야에서는 추정으로 채운 문서 한 장이 다음 사람의 몇 달을 틀어뜨린다. 경계를 지키는 사람이 더 빨리 일을 받는다.

자격증 축에서는 ISTQB CTFL·CTAL-TA 가 설계 기법의 공통 언어로, CTAL-TTA 가 구조 기반·기술 영역에서 쓰인다. 정보처리기사는 공공·방산 사업의 인력 등급 산정에서 의미를 갖고, DO-178 관련 교육 이수나 CC 평가 대응 경험은 그 자체로 이력이 된다. 보안 구역 근무 요건이 걸리는 자리가 많아 신원·보안 절차를 통과할 수 있는지 가 실질적 조건이 되기도 한다. 다만 최종적으로 평가되는 것은 "증거를 만들어 사업을 통과시켜 봤는가" 다. 이 모듈의 실습 과제는 그 경험이 없는 상태에서 경험에 해당하는 산출물 — 질의 목록, 추적 체계, 목표 매핑표, 미달 처리 절차서, 환경 구성서, 재처리 검증 계획서, 통제 환경 증거 설계 — 을 미리 만들어 두는 방향으로 설계했다.