개념
왜 DO-178C 를 먼저 보는가
국방·항공우주 QA 를 배우는 데 공개 규격인 DO-178C 부터 보는 것이 가장 효율적이다. 이유는 두 가지다.
첫째, 구조가 그대로 드러난다. 위험의 심각도 → 소프트웨어 수준 → 충족할 목표 → 목표마다 요구되는 증거와 독립성이라는 사슬이 명시적으로 짜여 있다. 이 사슬을 한 번 이해하면 다른 규격 환경(레슨 1 의 국방 사업 문서를 포함해) 의 문서를 읽는 속도가 달라진다.
둘째, 공개 자료로 확인할 수 있다. 규격 본문은 유료로 배포되지만, 구조와 수준 구분은 널리 공개되어 있어 인용 가능한 범위가 넓다. 이 레슨에서 숫자를 쓰는 부분은 공개 확인된 범위이고, 목표별 세부 요구와 각 조항의 정확한 문장은 규격 원문에서 확인한다.
다만 선을 그어 둔다. DO-178C 는 "항공기 탑재 소프트웨어" 의 규격이다. 지상 장비, 위성 데이터 처리, 일반 국방 정보체계에 그대로 적용되지 않는다. 사업에 적용되는 규격이 무엇인지는 레슨 1 에서 다룬 대로 사업 문서에서 확인한다.
사슬의 시작 — 심각도가 수준을 정한다
이 체계의 출발점은 소프트웨어가 아니라 고장이 났을 때 항공기와 탑승자에게 무슨 일이 일어나는가 다. 소프트웨어 수준(software level, 흔히 DAL — Design Assurance Level 로 불린다) 은 그 결과의 심각도에서 따라온다.
| 수준 | 고장 상태(failure condition) |
|---|---|
| A | Catastrophic |
| B | Hazardous |
| C | Major |
| D | Minor |
| E | No Safety Effect |
중요한 함의 — 코드의 복잡도나 규모가 수준을 정하지 않는다. 아주 단순한 코드도 그 고장이 파국적이면 A 이고, 아주 복잡한 코드도 안전 영향이 없으면 E 다. QA 가 받아 드는 수준은 체계 안전 분석의 결과물 이며, QA 가 정하지 않는다. 각 심각도 용어의 정확한 정의와 판정 절차는 체계 안전 쪽 규격·지침에서 확인한다 (정의 문장과 판정 절차 — 원문 확인).
수준이 정하는 것 — 목표 수와 독립성
수준이 정해지면 충족해야 하는 목표(objective) 의 수 와 그중 독립성을 갖고 충족해야 하는 수 가 따라온다. 공개 자료가 널리 인용하는 값은 이렇다.
| 수준 | 목표 수 | 그중 독립성 요구 |
|---|---|---|
| A | 71 | 30 |
| B | 69 | 18 |
| C | 62 | 5 |
| D | 26 | 2 |
| E | 0 | 0 |
이 표에서 읽어야 할 것은 숫자 자체가 아니라 모양 이다.
- A 와 B 의 목표 수 차이는 작다(71 대 69). 반면 독립성 요구는 30 대 18 로 크게 벌어진다. A 와 B 를 가르는 것은 "무엇을 더 하는가" 보다 "누가 하는가" 라는 뜻이다
- C 에서 독립성이 5 로 떨어지고, D 는 목표 수 자체가 26 으로 줄어든다
- E 는 목표가 0 이다. 안전 영향이 없다고 분류되면 이 규격의 활동이 요구되지 않는다. 그래서 수준 분류 자체가 사업 비용을 결정하는 지점 이고, 분류를 낮추려는 압력이 생기는 지점이기도 하다
목표 수는 규격의 부속 표(Annex A) 에 수준별로 정리되어 있다. 각 목표의 내용, 요구되는 산출물, 그리고 "with independence" 가 붙는 목표가 구체적으로 무엇인지는 규격 원문의 해당 표에서 확인한다.
독립성은 사람 분리이고, 기록으로 증명된다
"with independence" 는 검증하는 사람이 그 대상을 만든 사람이 아님 을 뜻한다. 요구사항을 쓴 사람이 그 요구사항을 검토하지 않고, 코드를 쓴 사람이 그 코드를 검증하지 않는다. 그리고 그 분리가 문서로 명확히 드러나야 한다.
QA 실무로 옮기면 이렇다.
- 검토·시험 기록에 작성자와 검증자가 별개 이름으로 남는다
- 조직적으로 분리가 어려운 소규모 팀에서는 누가 무엇을 만들었고 누가 검증했는지 를 항목 단위로 기록해 분리를 보인다
- 자동화 도구가 검증을 수행하는 경우, 도구와 그 사용 자체에 조건이 붙는다 (도구 자격 — 뒤에서 다룬다)
독립성에서 가장 흔한 실패는 조직이 아니라 기록 이다. 실제로는 다른 사람이 검증했는데 기록에 그 사실이 보이지 않아 증거가 되지 못한다. QA 가 양식을 설계할 때 작성자·검증자 칸을 분리 해 두는 단순한 조치가 사업 후반의 재작업을 막는다.
생애주기 데이터 — 계획서부터 시작한다
이 체계에서 QA 가 만지는 문서는 시험 절차서 하나가 아니다. 계획 문서가 먼저 나오고, 그 계획대로 했음을 나중에 증거로 보인다.
계획 계열에는 인증 연계 계획, 개발 계획, 검증 계획, 형상관리 계획, 품질보증 계획이 있고, 표준 계열에는 요구사항·설계·코딩 표준이 있다. 그 뒤에 요구사항·설계·소스 코드·실행 코드, 검증 케이스와 절차, 검증 결과, 추적 데이터, 형상 색인, 문제 보고, 그리고 완료를 선언하는 요약 문서가 따른다. 각 문서의 정확한 명칭·약어·요구 내용·제출 시점은 규격 원문과 사업의 인증 계획에서 확인한다(원문 확인).
QA 입장에서 실질적으로 중요한 세 가지는 이렇다.
1) 검증 계획이 시험 설계를 구속한다. "어떤 방법으로 어느 목표를 충족할지" 를 계획에 써서 승인받은 뒤에 시험을 만든다. 계획에 없는 방법으로 얻은 결과는 쓰기 어렵다. 그래서 계획 단계에서 QA 가 참여하지 않으면 나중에 손발이 묶인다.
2) 완료는 선언이 아니라 대조다. 모든 목표에 대해 "이 목표는 이 증거로 충족됐다" 를 표로 맞추는 작업이 마지막에 온다. 그 표를 염두에 두고 처음부터 증거에 목표 식별자 를 달아 두면 마지막이 수월하다.
3) 문제 보고가 생애주기 데이터다. 결함 관리 도구가 아니라 납품 산출물 로 다뤄진다. 결함의 상태 전이와 종결 근거가 추적 가능해야 한다.
검증은 시험만이 아니다
이 체계에서 "검증(verification)" 은 시험보다 넓다. 검토(review), 분석(analysis), 시험(test) 세 수단이 모두 검증 방법으로 쓰인다. 어떤 목표는 시험으로 충족할 수 없고 분석으로만 충족된다.
QA 가 여기서 얻을 실무적 함의는 "시험으로 덮을 수 없는 요구를 알아보는 능력" 이다. 예컨대 특정 조건이 절대 발생하지 않음을 보이는 것은 시험으로 보이기 어렵고 분석의 영역이다. 시험으로 안 되는 것을 억지로 시험으로 덮으려 하면 의미 없는 케이스가 늘어난다. 모듈 58 레슨 2 의 문서 검토 기법과 모듈 58 레슨 1 의 오라클 논의가 여기서 그대로 쓰인다.
요구 층과 양방향 추적
레슨 1 에서 본 층 구조가 이 규격에서는 명시적이다. 상위 요구(high-level requirements) 와 저수준 요구(low-level requirements), 그리고 설계와 코드가 구분되고, 각 층 사이에 추적이 요구된다.
추적은 양방향이다.
- 위에서 아래로 — 모든 요구가 설계·코드·시험으로 구현·검증되었는가
- 아래에서 위로 — 구현된 모든 것이 어느 요구에 근거하는가
아래에서 위로의 추적이 중요한 이유는 근거 없는 코드 를 찾아내기 위해서다. 어느 요구에도 대응하지 않는 코드는 요구 누락이거나 불필요한 기능이다. 안전이 걸린 소프트웨어에서 "왜 있는지 설명되지 않는 코드" 는 그 자체로 문제다. 이 관점은 레슨 3 의 구조 커버리지 결과를 해석할 때 다시 쓰인다.
보충 규격 네 종 — 도구와 방법에 붙는 조건
DO-178C 에는 네 개의 보충 문서가 함께 나왔다. 각각 이런 역할이다.
| 문서 | 다루는 것 |
|---|---|
| DO-330 | 소프트웨어 도구 자격(tool qualification) 고려사항 |
| DO-331 | 모델 기반 개발·검증 보충 |
| DO-332 | 객체지향 기술 및 관련 기법 보충 |
| DO-333 | 정형 기법(formal methods) 보충 |
QA 가 당장 체감하는 것은 DO-330(도구 자격) 이다. 검증 활동을 도구에 맡기려면 그 도구에 요구되는 조건이 따로 있다. 커버리지 측정 도구, 자동 시험 생성 도구, 정적 분석 도구를 쓰는 것이 자유롭지 않고, 도구를 바꾸는 것도 사업 변경 이다. 실무 함의는 단순하다 — 도구 선택을 QA 가 임의로 하지 않고, 계획 단계에서 합의해 문서에 적는다. 자격 요구의 범위와 구분은 DO-330 원문과 사업의 인증 계획에서 확인한다(원문 확인).
DO-333(정형 기법) 은 공개 자료가 정형 검증을 시험을 보완하되 대체하지는 않는 수단으로 설명한다. "정형 기법을 썼으니 시험을 생략한다" 는 결론으로 가지 않는다는 점이 QA 에게 중요하다. 정확한 적용 조건은 원문에서 확인한다.
실무에서 왜 필요한가
항공·방산 소프트웨어 사업에서 QA 가 후반에 무너지는 가장 흔한 경로는 "시험은 다 했는데 증거가 목표에 매핑되지 않는 것" 이다. 기능은 검증됐고 결함도 잡았는데, 목표 71개에 대해 "이 목표는 이 문서의 이 부분으로 충족됐다" 를 채울 수 없다. 그 시점에 남은 선택은 산출물을 다시 쓰는 것뿐이고, 일정에 그 시간은 없다.
반대로 목표 매핑을 처음부터 걸어 두면 사업이 전혀 다르게 흘러간다. 시험 케이스마다 요구 식별자와 목표 식별자가 붙어 있고, 결과에 작성자·검증자가 분리돼 기록되어 있으면, 마지막 대조는 표 한 장을 생성하는 일이 된다.
그리고 이 구조를 이해하는 것은 일정과 비용을 말할 수 있게 되는 것 이다. "이 기능은 수준 B 입니다" 라는 말에 담긴 작업량 — 목표 69개, 그중 18개는 독립성 요구, 구조 커버리지 요구(레슨 3), 추적 데이터, 계획 문서 — 을 설명할 수 있는 QA 는 착수 협의에서 발언권을 갖는다. 수준 하나가 올라가면 비용이 얼마나 늘어나는지를 근거와 함께 말할 수 있기 때문이다.
채용 관점에서 DO-178 경험은 국내에서 희소하고 해외 이동성이 있는 이력 이다. 항공 전자, 무인기, 위성 탑재 소프트웨어, 그리고 완성차의 기능안전 쪽으로도 문법이 통한다. 공고에는 "DO-178B/C", "DAL", "MC/DC", "인증 대응", "추적성 관리" 같은 말이 적히고, 면접에서는 구조를 설명할 수 있는지 를 본다.