개념
이 레슨은 규격 내용을 가르치지 않는다
먼저 분명히 해 둔다. 국방 소프트웨어 개발·시험 규격의 세부 요구사항을 이 레슨에서 전달하지 않는다. 이유는 두 가지다.
첫째, 공개 확인이 고르지 않다. 제도의 존재와 큰 성격은 공개 자료로 확인되지만, 구체적인 산출물 목록, 단계별 검토 항목, 시험 기준 수치, 적용 대상 판정 기준은 규정 원문과 사업 문서에서만 확인할 수 있다. 공개 논문과 업체 자료에 조각이 흩어져 있지만, 판본이 다르거나 개정 전 내용인 경우가 많다.
둘째, 개정된다. 지침과 매뉴얼은 통합·개정을 거치고, 사업마다 적용 판본이 다르다. 외운 내용을 적용하면 틀린 판본으로 일한다.
그래서 이 레슨의 산출물은 지식이 아니라 질의 목록 이다. 이 분야에 들어간 QA 가 첫 주에 해야 하는 일은 규격을 외우는 것이 아니라 "우리 사업에 적용되는 문서가 무엇이고, 그 문서의 어느 판본이며, 그것이 요구하는 산출물 목록이 어디에 적혀 있는가" 를 확인하는 것이다. 그 확인을 할 줄 아는 사람이 이 시장에서 쓰인다.
공개 자료로 확인되는 것
공개 범위에서 말할 수 있는 것은 이 정도다.
방위사업청이 무기체계 소프트웨어의 개발·관리에 관한 매뉴얼을 발간해 운용한다. 기존에 흩어져 있던 매뉴얼과 실무지침서를 사용자 중심으로 통합·개정한 문서라고 공개 자료가 설명하고 있고, 개발 단계별 활동과 검토 사항을 정의하는 성격을 갖는다. 정확한 문서명·판본·목차·요구 산출물 목록은 원문에서 확인한다.
소프트웨어 신뢰성 시험 제도가 운용된다. 공개 자료는 이 제도의 목적을 소스코드 안의 잠재적 결함을 체계적으로 제거해 품질을 높이는 것 으로 설명한다. 즉 기능이 되는지를 보는 시험과 별개로, 코드 자체를 들여다보는 활동 이 제도로 들어와 있다는 뜻이다. 시험 항목, 판정 기준, 적용 대상 선정 기준, 등급 구분, 수행 주체와 시기는 규정 원문과 사업 문서에서 확인한다.
국방기술품질원이 관련 품질 업무에 관여한다. 역할의 정확한 범위와 사업 유형별 관여 방식은 기관 공개 문서에서 확인한다.
이 세 문장이 공개 확인의 거의 전부다. 여기서 더 나아가 "산출물은 몇 종이고 단계는 몇 개다" 를 적는 자료들이 있지만, 판본 확인 없이 인용할 수 없다. QA 문서에 그런 숫자를 적었다가 틀리면, 그 문서를 믿고 일한 사람들의 일정이 함께 틀어진다.
규격 환경이 QA 에게 뜻하는 것
세부를 모르더라도 환경의 성격 은 알 수 있고, 그것이 실무에서 더 중요하다. 이 환경의 성격은 네 가지다.
1) 품질 기준이 바깥에서 주어진다. 일반 소프트웨어 QA 는 팀과 함께 "어디까지 되면 출하" 를 정한다. 이 환경에서는 그 선이 규격과 계약 문서에 이미 적혀 있다. QA 의 일은 선을 정하는 것이 아니라 그 선을 시험 가능한 문장으로 번역하고 증거를 모으는 것 이다.
2) 산출물이 결과물의 일부다. 소프트웨어가 돌아가는 것과 별개로, 문서가 납품물이다. 시험 계획서·절차서·결과서·추적표가 빠지면 소프트웨어가 완벽해도 인수되지 않는다. 그래서 일정 산정에서 문서 작업 시간이 실행 시간과 비슷하거나 더 크다.
3) 재배포로 고칠 수 없다. 장비에 실린 소프트웨어는 패치가 사업이다. 운영 중 발견된 결함 하나를 고치는 데 시험과 승인을 다시 거친다. 그래서 출하 전에 잡는 것의 가치가 일반 소프트웨어보다 자릿수로 크고, 그 가치가 두터운 검증 활동의 비용을 정당화한다.
4) 검증의 독립성이 요구된다. 만든 사람이 검증하지 않는다는 원칙이 권장이 아니라 요건으로 들어온다. 이것이 항공 쪽에서 어떻게 구체화되는지는 레슨 2 에서 DO-178C 를 통해 본다 — 그쪽은 공개 규격이라 구조를 그대로 볼 수 있다.
추적성이 산출물의 뼈대다
이 환경의 모든 문서를 꿰는 하나의 축이 추적성 이다. 요구사항 하나가 설계로, 코드로, 시험 절차로, 시험 결과로 이어지고, 거꾸로 되짚을 수 있어야 한다.
추적성이 왜 산출물의 뼈대인가. 이 환경의 질문은 "잘 되나요" 가 아니라 "요구사항 전부가 검증되었음을 어떻게 아는가" 이기 때문이다. 이 질문에 답하는 유일한 방법이 추적표다.
QA 가 처음부터 의식해야 하는 것은 추적표를 나중에 만들 수 없다 는 점이다. 시험을 다 하고 나서 요구사항과 연결하려 하면, 어느 케이스가 어느 요구를 덮는지 기억에 의존하게 되고 빈칸이 생긴다. 추적 식별자는 케이스를 쓰는 순간 붙인다. 이것은 규격을 몰라도 지금 당장 할 수 있는 실천이고, 이 분야 면접에서 바로 통하는 습관이다.
요구사항 수준이 여러 겹이다
이 환경에서는 요구사항이 한 층이 아니다. 체계 수준 요구가 있고, 그것이 소프트웨어 수준 요구로 쪼개지고, 다시 설계로 내려간다. 각 층마다 대응하는 시험이 있다.
| 층 | 대응하는 시험 성격 |
|---|---|
| 체계·상위 요구 | 체계 통합 시험, 운용 시험 |
| 소프트웨어 상위 요구 | 소프트웨어 요구 기반 시험 |
| 소프트웨어 설계·저수준 요구 | 통합 시험, 단위 시험 |
QA 가 혼동하기 쉬운 지점은 같은 이름의 시험이 층마다 다른 것을 본다 는 점이다. "통합 시험" 이 소프트웨어 모듈 간 통합인지 체계 구성품 간 통합인지에 따라 대상·환경·증거가 전부 다르다. 사업 문서의 용어 정의를 먼저 읽고, 우리 사업에서 그 단어가 무엇을 가리키는지 를 확인하는 것이 모든 혼선의 예방책이다.
이 층 구조는 항공 쪽 DO-178C 에서 명시적으로 드러나므로, 구조를 이해하는 데는 레슨 2 가 더 좋은 교재다. 국방 사업에 들어가더라도 DO-178C 의 구조를 먼저 이해해 두면 사업 문서를 읽는 속도가 달라진다.
하지 않는 일 — 분명히 해 둘 경계
이 모듈에서 다루지 않는 것이 있다.
- 실제 무기체계의 구체적 취약점·공격 기법·회피 방법 은 다루지 않는다. 이 모듈의 주제는 규격이 요구하는 검증과 증빙이지 공격이 아니다. 보안 시험 기법 일반은 모듈 50 이 맡는다
- 비공개 자료의 내용을 추정해 채우지 않는다. 대외비 문서의 내용은 접근 권한이 있는 사람이 원문으로 본다
- 사업·기관별 절차를 일반화하지 않는다. "국방 사업은 이렇게 한다" 는 문장은 대개 틀린다. 사업 유형, 체계 종류, 계약 형태에 따라 다르다
이 경계를 지키는 것이 이 분야에서 신뢰를 얻는 방식이다. 모르는 것을 모른다고 말하고 확인 경로를 제시하는 사람이, 아는 척하는 사람보다 훨씬 빠르게 일을 받는다.
실무에서 왜 필요한가
이 분야에 들어가는 QA 가 첫 달에 겪는 어려움은 기술이 아니라 문서 체계 다. 규정, 지침, 매뉴얼, 계약 문서, 사업 문서, 체계 개발 실행 계획서, 형상 관리 문서가 서로를 참조하고 있고, 어느 문장이 우리를 구속하는지가 한눈에 보이지 않는다.
이때 두 가지 실패가 흔하다.
첫째, 규격을 읽지 않고 일반 QA 방식으로 시작한다. 테스트 케이스를 잘 쓰고 결함도 잘 찾았는데, 중간 검토에서 산출물 양식이 맞지 않는다 는 지적을 받고 전부 다시 쓴다. 양식은 취향이 아니라 요건이다.
둘째, 어디선가 들은 숫자로 일한다. "신뢰성 시험은 몇 등급이고 기준이 몇 퍼센트" 같은 말을 전해 듣고 계획에 반영한다. 판본이 다르거나 사업 유형이 달라 틀린 전제로 일정을 세우게 되고, 틀어지는 시점은 항상 후반이다.
둘 다 착수 시점의 질의 목록 하나 로 막을 수 있다. 적용 문서와 판본, 요구 산출물 목록과 양식, 제출 시점, 검토 주체, 추적성 요구 수준, 독립성 요구 범위. 이 여섯 가지를 물어 답을 문서로 받아 두면 사업 전체의 뼈대가 잡힌다.
채용 관점에서 이 분야는 경력이 길게 쌓이는 쪽 이다. 진입 장벽이 문서 체계와 보안 절차에 있어서 공급이 적고, 한 번 사업을 끝까지 겪은 사람의 가치가 높다. 공고에는 "방산 사업 경험", "국방규격", "DO-178", "형상관리", "추적성", "신뢰성 시험" 같은 말이 적힌다. 면접에서 규격 조항을 외워 답하는 것보다 "적용 판본을 먼저 확인하고 산출물 목록과 양식을 받아 일정을 역산한다" 고 답하는 쪽이 실제로 일할 사람처럼 들린다.