DO-178C·IEC 62279·IEC 60880 — 가장 엄격한 검증의 세계

개념

같은 기계를 가장 높은 눈금에 놓으면

앞 레슨에서 자동차(ISO 26262)와 의료기기(IEC 62304)를 보며 세운 구조는 세 칸이었다.

위험 등급을 매긴다 → 그 등급이 요구하는 테스트 강도를 정한다 → 그렇게 했음을 문서로 증명한다.

이 레슨은 새 구조를 배우는 자리가 아니다. 같은 세 칸짜리 기계를 눈금 끝까지 돌렸을 때 무슨 일이 벌어지는지 를 보는 자리다.

세 칸은 그대로인데 각 칸의 무게가 뒤집힌다. 일반 제품에서는 첫 칸(위험 판단)이 가장 어렵고 셋째 칸(증명)은 형식적인 마무리다. 이 영역은 반대다. 위험 등급도 테스트 강도도 규격이 이미 표로 정해 놓았고, 일이 정말 몰리는 곳은 셋째 칸 이다. 공수의 상당 부분이 "우리가 그렇게 했음을 제3자가 확인할 수 있게 남기는 일"로 간다.

그래서 목표는 조항 암기가 아니라 "왜 이 정도까지 하는가"를 납득하는 것 이다. 납득하고 나면 처음 보는 규격 번호를 만나도 어느 갈래인지 짚을 수 있다.

지도를 먼저 그린다 — IEC 61508이라는 뿌리

규격 번호를 하나씩 외우면 금방 뒤엉킨다. 계보를 먼저 그려 두면 새 번호가 나타나도 자리가 보인다.

출발점은 IEC 61508 이다. 전기·전자·프로그래머블 전자 시스템의 기능 안전을 다루는 범용 표준이고, 소프트웨어는 파트 3이 맡는다. 61508은 어느 산업에도 직접 쓰기엔 너무 일반적이라, 산업마다 자기 언어로 옮긴 적용판이 갈라져 나왔다.

항공은 61508의 자식이 아니다. DO-178C는 항공 인증 체계 안에서 독자적으로 발전했고 61508보다 오래된 뿌리를 갖는다. "모든 안전 규격은 61508에서 나왔다"는 흔한 오해인데 사실이 아니다. 원자력도 곧장 파생된 관계는 아니다. 자체 계보로 자라났고, 상위 규격인 IEC 61513이 61508의 안전 수명주기 틀을 참조하며 정렬되는 형태에 가깝다. 정확한 관계는 각 규격 서문의 범위 절을 직접 확인하자.

여기서 가장 자주 틀리는 지점 을 미리 못 박아 둔다. 등급의 방향이 체계마다 다르다.

DO-178C만 방향이 반대다. "ASIL A"와 "Level A"를 같은 수준으로 읽는 순간 정반대의 결론이 나온다.

DO-178C — 고장이 항공기에 무엇을 하는가로 등급이 갈린다

DO-178C는 항공기에 탑재되어 비행 중 동작하는 소프트웨어 의 인증 근거가 되는 문서다. 등급을 나누는 기준은 코드의 복잡도도 개발 규모도 아니고, 잘못됐을 때 항공기에 생기는 결과 하나뿐이다.

여기서 통찰이 하나 나온다. 같은 코드라도 어디에 실리느냐에 따라 레벨이 달라진다. 기내 엔터테인먼트의 좌석 화면은 Level E일 수 있지만, 똑같은 표시 로직이 조종석 계기에 들어가면 훨씬 높은 레벨이 된다. 등급은 코드의 속성이 아니라 시스템 안에서의 위치 다. 앞 레슨의 ASIL 결정도 같은 사고방식이었다.

레벨이 올라간다는 건 "목표가 늘어난다"는 뜻이다

DO-178C의 가장 특징적인 성격은 목표(objective) 기반 이라는 점이다. 규격은 "이렇게 개발하라"가 아니라 "다음 목표들이 달성되었음을 보여라" 로 말한다. 부속서(Annex A)의 표들이 목표를 나열하고, 각 목표에 대해 레벨별로 세 가지를 지정한다.

1. 이 레벨에서 그 목표가 적용되는가
2. 검증에 독립성(independence) 이 필요한가 — 만든 사람이 아닌 다른 사람이 확인해야 하는가
3. 산출물을 어떤 구성 관리 등급 으로 통제하는가

레벨이 A에 가까울수록 적용 목표 수가 늘고 독립성을 요구하는 비율도 늘어난다. Level E는 사실상 목표가 부과되지 않는다. 각 레벨의 정확한 목표 개수는 개정판과 보충 문서에 따라 달라지므로, 인용해야 한다면 반드시 Annex A 표 원문을 직접 확인하라. 면접에서도 개수를 외워 말하는 것보다 "레벨이 올라가면 목표 수와 독립성 요구가 함께 늘어나는 구조"를 설명하는 편이 훨씬 정확하다.

독립성이 필요한 이유는 상식으로 이해된다. 자기가 쓴 코드의 테스트를 자기가 설계하면, 자기가 놓친 곳은 테스트도 똑같이 놓친다. 오해의 방향이 같기 때문이다. 독립성은 능력 불신이 아니라 오해의 상관관계를 끊는 장치 다.

Level A에서 MC/DC가 요구된다는 사실은 모듈 3 레슨 7(구조 기반 기법)에서 이미 표로 만났다. MC/DC가 무엇인지는 그 레슨에 있으니 여기서는 되풀이하지 않는다. 이 레슨이 새로 얹는 것은 커버리지를 바라보는 방향 이다.

테스트가 요구사항에서 나왔음을 증명한다는 발상

DO-178C에서 가장 중요하고, 실무에서 가장 자주 오해되는 지점이다.

테스트는 요구사항에서 만들어져야 한다. 구조 커버리지는 그 테스트가 충분했는지를 되짚어보는 자(尺)이지, 테스트를 만들어내는 출처가 아니다.

흔한 순서를 떠올려 보자. 코드를 짜고, 커버리지를 돌리고, 빨간 줄이 남으면 그 줄을 지나가게 하는 테스트를 만든다. 숫자는 올라간다. 그런데 이렇게 만든 테스트는 코드가 하는 일을 그대로 옮겨 적은 것 이어서, 코드가 틀렸으면 테스트도 같이 틀린다. 요구사항과 코드가 어긋나 있어도 절대 빨간불이 되지 않는다.

DO-178C의 순서는 반대다.

요구사항(HLR)  →  저수준 요구사항(LLR)  →  코드
      ↓                    ↓
  요구사항 기반 테스트  ←  요구사항 기반 테스트
      ↓
  실행 → 구조 커버리지 측정 → 안 밟힌 곳이 남았다면?

마지막 화살표가 핵심이다. 요구사항에서 만든 테스트를 다 돌렸는데도 실행되지 않은 코드가 남았다면, 규격이 요구하는 것은 "그 줄을 밟는 테스트를 추가하라"가 아니라 왜 남았는지 원인을 규명하라 이다.

두 번째 행이 이 절의 값어치다. 커버리지 공백이 요구사항의 결함을 드러낸다. 모듈 3 레슨 7에서 "MC/DC를 만족시키려다 실패하는 것 자체가 결함 발견"이라고 했던 원리가, 여기서는 코드가 아니라 요구사항 쪽 을 향한다.

이 모든 것이 성립하려면 양방향 추적성 이 필요하다. 모듈 2 레슨 5에서 요구사항↔테스트 2단계로 배운 매트릭스가, 여기서는 요구사항 → 설계 → 코드 → 테스트의 네 칸으로, 그리고 반대 방향으로도 끊김 없이 이어져야 한다. 그때 "대부분의 팀은 2단계면 충분하고 4단계는 비용이 크다"고 했는데, 이 영역이 바로 그 비용을 지불할 만한 예외 다.

역방향이 특히 무겁다. 코드 한 줄, 테스트 한 건마다 "너는 어느 요구사항 때문에 존재하는가" 에 답할 수 있어야 한다. 여기에 더해 DO-178C는 상위 요구사항에서 직접 유래하지 않은 파생 요구사항(derived requirement) 을 별도로 식별해 시스템 안전성 평가로 되돌려 보내라고 한다. "필요해서 넣긴 했는데 위에서 시킨 건 아닌" 결정이야말로 위험 평가를 다시 받아야 하기 때문이다.

IEC 62279 — 철도, 오작동이 곧 충돌인 영역

IEC 62279 는 철도 제어·보호 시스템 소프트웨어를 다루는 규격이다. 유럽 CENELEC의 EN 50128 과 같은 계열로, IEC 61508의 철도 적용판에 해당한다. 그래서 등급 체계도 61508의 것을 그대로 쓴다 — SIL 이다. 철도 소프트웨어 맥락에서는 통상 SIL 0부터 SIL 4까지를 다루며 SIL 4가 가장 엄격하다.

대상을 떠올리면 왜 이렇게까지 하는지 바로 이해된다. 신호기, 연동 장치(interlocking), 열차 방호 시스템. 이 소프트웨어의 오작동은 곧 "두 열차에 같은 구간을 허가하는 일" 이고 그 결과는 충돌이다. 중간 단계가 거의 없다.

이 계열에서 QA가 실감하는 가장 뚜렷한 요구는 역할의 분리 다. 규격은 요구사항 관리자, 설계자, 구현자, 시험자, 검증자, 확인자, 평가자 같은 역할을 정의하고, SIL이 높아질수록 같은 사람이 겸할 수 없는 조합이 늘어난다. DO-178C의 독립성 요구와 발상은 같지만, 철도 쪽은 그것을 조직도와 인사 배치의 문제로 못 박는다. 프로젝트 초기에 "누가 어느 역할을 맡는가"를 문서로 확정하고, 그 표 자체가 심사 대상이 된다.

시스템 전체의 RAMS를 다루는 EN 50126, 신호 분야 안전 관련 전자 시스템을 다루는 EN 50129가 소프트웨어 규격과 짝을 이룬다. 유럽에서는 EN 50128과 차상 소프트웨어용 EN 50657을 통합하는 방향의 개정이 진행되어 왔으므로, 계약서가 지정한 규격의 판번호와 발행 연도를 반드시 확인해야 한다. 이 영역에서 "몇 년판인가"는 사소한 정보가 아니다.

IEC 60880 — 원자력, 되돌릴 수 없는 것 앞에서

IEC 60880 은 원자력발전소의 안전 관련 계측·제어 시스템 중에서도 가장 중요한 기능 — 통상 범주 A 로 분류되는 기능 — 을 수행하는 컴퓨터 기반 시스템의 소프트웨어를 다룬다. 상위 틀은 IEC 61513이 잡고 기능 범주 분류는 IEC 61226 계열이 맡는다. 즉 이 영역은 SIL도 ASIL도 아닌 기능 범주(A·B·C)와 안전 등급 이라는 자기 어휘를 쓴다.

유독 보수적인 이유는 둘이다.

첫째, 비가역성. 항공기 사고도 참혹하지만 피해 범위가 기체와 그 주변으로 한정된다. 원자력 사고는 공간적으로도 시간적으로도 경계가 훨씬 넓고 되돌릴 방법이 사실상 없다. 기대 손실의 분자가 압도적으로 커지면 아무리 큰 검증 비용도 정당화된다.

둘째, 실물 시험의 불가능성. 자동차는 충돌 시험을 하고 항공기는 시험 비행을 한다. 원전은 "사고를 한 번 내보고 안전 계통이 잘 도는지 확인"할 수 없다. 가장 중요한 동작 시나리오가 바로 실행해 볼 수 없는 시나리오다. 여기에 운영 수명이 수십 년이라는 사정이 겹친다.

이 두 조건이 검증의 무게중심을 옮긴다.

마지막 줄이 흥미롭다. 테스트하기 어려운 것을 애초에 만들지 않는 방향으로 설계를 밀어붙인다. 실행 중에 무슨 일이 벌어질지 정적으로 알 수 없는 구조를 아예 금지하는 것이다. 구체적인 조항과 요구 수준은 판본과 국가별 규제기관 지침에 따라 다르니, 여기서 가져갈 것은 조항이 아니라 "왜 무게중심이 정적 쪽으로 옮겨가는가"라는 논리 다.

도구도 검증 대상이 된다 — tool qualification

이 영역에 처음 들어온 QA가 가장 놀라는 대목이다. 테스트 도구, 컴파일러, 커버리지 측정 도구, 자동 코드 생성기 자체가 검증 대상이 된다.

논리는 간단하다. 커버리지 도구가 안 밟힌 줄을 밟았다고 보고한다면, 그 리포트를 근거로 한 모든 주장이 무너진다. 증거를 만들어 낸 기계를 신뢰할 수 없으면 증거도 신뢰할 수 없다. 항공 쪽에서는 이 주제를 별도 문서(DO-330)가 다루며, 도구를 대략 두 부류로 나눈다.

• 오류를 집어넣을 수 있는 도구 — 코드 생성기·컴파일러처럼 출력물이 최종 제품에 들어가는 도구. 잘못 동작하면 제품에 직접 결함을 심는다.
• 오류를 놓칠 수 있는 도구 — 정적 분석기·커버리지 측정기처럼 검증 활동을 대신하는 도구. 잘못 동작하면 있는 결함을 못 본 채 통과시킨다.

QA에게 실무적으로 더 자주 걸리는 것은 뒤쪽이다. "이 도구를 썼기 때문에 그 검증 활동을 생략했다"고 말하는 순간, 그 도구는 자격을 갖춰야 한다. 반대로 도구는 참고로만 쓰고 사람이 별도로 확인한다면 요구 수준이 내려간다. 그래서 이 영역의 도구 선택 회의는 기능 비교가 아니라 "이 도구에 어느 정도의 신뢰를 위임할 것인가" 를 정하는 자리가 된다.

재현되지 않는 결함 — 여기서는 닫을 수 없다

일반 서비스 팀은 재현 불가 결함을 몇 번 시도해 보고 Cannot Reproduce 로 닫는다. 이건 게으름이 아니라 합리적인 비용 판단 이다. 재현되지 않는 하나에 며칠을 쓰는 것보다 재현되는 열 개를 고치는 편이 사용자에게 이롭다. 안전 필수 영역에서는 이 계산이 성립하지 않는다.

차이의 뿌리는 하나다. "재현되지 않는다"는 "존재하지 않는다"가 아니다. 경합 조건, 타이밍, 메모리 상태, 하드웨어 편차에서 오는 결함은 원래 재현율이 낮고, 재현율이 낮다는 것과 위험하지 않다는 것은 아무 상관이 없다. 비행 중에 한 번만 나면 되는 결함에게 재현율 0.01%는 충분한 확률이다.

그래서 이 영역의 결함 보고서는 재현 절차만 적고 끝나지 않는다. 빌드 번호, 하드웨어 구성, 입력 이력, 로그, 환경 조건을 최대한 붙잡아 둔다. 다시는 같은 상태를 못 만들 수 있다는 전제로 기록 하기 때문이다. 닫는 판단도 개인이 아니라 정해진 회의체가 하고, 그 근거가 함께 보관된다.

그래서 이 영역의 QA는 하루에 무엇을 하는가

한 줄로 줄이면 이렇다. 이 영역의 QA는 테스트를 실행하는 사람이라기보다, "검증이 이루어졌다"는 사실을 제3자가 확인할 수 있는 형태로 만들어 내는 사람이다. 셋째 칸에 무게가 실린다는 말의 실제 모습이 이것이다.

실무에서 왜 필요한가

대부분의 QA는 평생 DO-178C 프로젝트에 들어가지 않는다. 그런데도 이 레슨이 필요한 이유는 셋이다.

첫째, 규격 번호를 만났을 때 당황하지 않기 위해서다. 채용공고나 입찰 규격서에 IEC 62279가 적혀 있을 때 "철도 계열의 61508 적용판이고 SIL 등급을 쓴다"까지 나오면 대화가 시작된다. 계보를 알면 처음 보는 번호도 어느 갈래의 무엇인지 추정할 수 있다.

둘째, 일반 프로젝트에 옮겨 쓸 수 있는 사고방식이 있기 때문이다. 이 영역이 모든 장치를 극단까지 밀어붙여 놓았기 때문에, 각 장치가 무엇을 위한 것인지가 오히려 선명하게 보인다.

셋째, 위험의 크기가 방법을 정한다는 원칙을 이해하기 위해서다. 모듈 4의 리스크 기반 테스트, 모듈 3의 커버리지 판단, 앞 레슨의 등급 체계가 전부 같은 말을 다른 각도에서 한다. 이 레슨은 그 원칙의 극단값이고, 극단값을 봐야 중간이 어디쯤인지 가늠할 수 있다.

반대 방향의 교훈도 분명하다. 이 방식을 일반 서비스에 그대로 가져오면 반드시 실패한다. 2주마다 요구사항이 바뀌는 제품에 4단계 추적성과 서명 절차를 강제하면 팀은 문서를 쓰다가 제품을 못 만든다. 규격의 무게는 변경 주기가 수년이고 배포에 재인증이 필요한 세계 를 전제로 계산된 것이다.

채용시장에서의 위치

이 세 규격은 경력의 방향을 바꾸는 종류의 키워드 다. 한번 들어가면 도메인 지식이 그 산업 안에서만 통용되는 대신, 대체 인력이 적어 경력이 오래 간다. 항공전자·철도 신호·원전 I&C를 다루는 회사와 협력사, 인증·심사 기관이 주요 수요처다.

공고에서 자주 보이는 표현은 규격 이름과 등급이 붙은 형태다 — "DO-178C Level B 이상 프로젝트 수행 경험", "EN 50128 SIL 4 대응 검증 경험" 같은 문구다. 경험 없이 이 문구를 뚫는 경로는 대개 둘이다. 관련 산업 협력사에서 검증 문서 작성 업무로 시작하거나, 지금 다니는 회사가 인증을 준비할 때 손을 드는 것이다.

면접에서 유리해지는 답변의 성격도 분명하다. 조항 번호나 목표 개수를 외워 말하는 것보다, "레벨이 올라가면 목표 수와 독립성 요구가 함께 늘어난다", "테스트는 요구사항에서 나와야 하고 커버리지는 그 결과를 되짚는 자다", "SIL과 DO-178C 레벨은 방향이 반대다" 처럼 구조를 설명하는 답이 훨씬 강하다. 정확히 모르는 수치를 단정했다가 되물림을 당하는 것이 이 분야 면접의 가장 흔한 실점이다. 모르는 것은 "판본을 확인해야 한다"고 말하는 편이 신뢰를 얻는다.

실습 과제

과제 1 — 계보 지도를 손으로 완성하기 (10분)

아무것도 보지 않고 다음 표를 채운다. 다 쓴 뒤에만 본문과 대조한다.

그리고 두 문장에 답한다.

1. 이 다섯 중 IEC 61508에서 갈라져 나왔다고 보기 어려운 것은 무엇이고 왜인가
2. 등급 표기의 "방향"이 다른 것은 무엇이며, 그 때문에 생기는 오해는 무엇인가

과제 2 — 이 테스트는 요구사항에서 나왔는가 (15분)

어떤 팀의 테스트 케이스 목록 일부다. 각 항목이 요구사항에서 나온 것 인지 코드에서 역산된 것 인지 판단하고, 후자라면 무엇이 위험한지 한 줄로 적는다.

과제 3 — 재현 불가 결함 보고서 다시 쓰기 (12분)

다음은 일반 서비스 팀에서 흔히 보는 결함 처리다.

제목: 가끔 계기 표시가 0으로 튐
내용: 테스트 중 한 번 발생. 다시 해봤는데 재현 안 됨.
처리: Cannot Reproduce 로 종결

이 결함이 항공기 조종석 표시 소프트웨어에서 나왔다고 가정하고 보고서를 다시 쓴다. 발생 당시 붙잡아 두어야 할 정보 항목 다섯 가지 이상, 종결하려면 무엇이 필요한지 한 문장, 종결 못 한 채 릴리즈로 가면 어떤 형태로 남는지 한 문장을 포함한다. 다시는 같은 상태를 만들 수 없다는 전제로 기록해야 한다 는 점이 반영되어야 한다.

과제 4 — 우리 제품에는 무엇이 걸리는가 (선택, 10분)

관심 있는 제품 하나를 고르고 세 문장으로 답한다. ① 이 제품의 최악의 고장이 사람에게 무엇을 하는가, ② 그 결과에 비추어 이 레슨의 어느 도메인과 가장 가까운가(혹은 어느 쪽에도 해당하지 않는가), ③ 해당하지 않는다면 그럼에도 이 레슨의 장치 중 하나만 도입한다면 무엇이고 왜인가. 세 번째 질문이 목적이다. 규격은 못 가져와도 사고방식은 가져올 수 있다.

자가 체크리스트

• IEC 61508이 무엇을 다루는 표준이고 어떤 도메인 적용판들이 갈라져 나왔는지 표로 그릴 수 있다
• SIL·ASIL·DO-178C 소프트웨어 레벨의 등급 방향 차이를 말할 수 있다
• DO-178C의 소프트웨어 레벨 A~E가 무엇을 기준으로 나뉘는지, 같은 코드라도 위치에 따라 달라진다는 점을 설명할 수 있다
• DO-178C가 "목표 기반" 규격이라는 말의 뜻과 독립성 요구가 왜 필요한지 설명할 수 있다
• 테스트가 요구사항에서 나와야 하는 이유와 코드에서 역산된 테스트의 위험을 말할 수 있다
• 커버리지 공백의 세 가지 원인을 구분하고 각각의 조치를 댈 수 있다
• IEC 62279가 어느 계열이고 어떤 등급 체계를 쓰는지, 역할 분리 요구가 무엇인지 말할 수 있다
• 도구 자격이 왜 필요한지, 어떤 경우에 요구 수준이 내려가는지 말할 수 있다
• 재현 불가 결함을 안전 필수 영역에서 닫을 수 없는 이유를 재현율 개념으로 설명할 수 있다

흔한 실수

• 모든 안전 규격이 IEC 61508에서 나왔다고 말한다. 자동차·철도·공정산업은 맞지만 항공(DO-178C)은 별도 계보 이고 원자력도 직접 파생이라기보다 정렬에 가깝다. 한 문장으로 뭉뚱그리면 아는 사람 앞에서 바로 드러난다.
• DO-178C의 Level A를 가장 낮은 등급으로 읽는다. ASIL·SIL의 감각을 그대로 옮기면 정확히 반대가 된다. Level A가 가장 엄격하다. 이 오해 하나로 프로젝트 범위 산정이 통째로 틀어진다.
• 목표(objective) 개수를 외워서 단정한다. 개정판과 보충 문서에 따라 달라지는 수치다. 구조를 설명하고 Annex A 원문 확인을 제안하는 편 이 언제나 더 정확하다.
• 커버리지를 채우려고 테스트를 만든다. 이 영역에서 가장 무거운 실수다. 역산된 테스트는 코드가 틀려도 통과하므로 숫자만 올리고 검증은 하나도 늘리지 못한다. 커버리지는 목표가 아니라 되짚는 자다.
• 추적성을 정방향만 관리한다. 요구사항에서 테스트로 내려가는 방향만 보면 근거 없는 코드와 고아 테스트를 못 잡는다. 이 영역이 요구하는 것은 양방향 이다.
• 재현 불가 결함을 일반 서비스처럼 닫는다. 재현율이 낮은 것과 위험하지 않은 것은 아무 관계가 없다. 경합 조건·타이밍 결함은 원래 재현율이 낮다.
• 이 방식을 일반 서비스 팀에 그대로 도입하려 한다. 변경 주기가 수 주인 제품에 4단계 추적성과 서명 절차를 강제하면 팀은 문서를 쓰다가 제품을 못 만든다. 전제가 다르면 결론도 달라야 한다.

참고 자료

• RTCA — DO-178C, Software Considerations in Airborne Systems and Equipment Certification — 항공 기내 소프트웨어 규격의 원문 발행처. 소프트웨어 레벨과 Annex A 목표 표는 여기서 확인한다
• IEC 61508 — Functional safety of E/E/PE safety-related systems — 이 레슨 계보도의 뿌리에 해당하는 표준의 공식 안내
• IEC 62279 — Railway applications: Software for railway control and protection systems — 철도 소프트웨어 규격. 범위 절과 판본 정보를 여기서 확인한다
• IEC 60880 — Nuclear power plants: Software aspects for computer-based systems performing category A functions — 원자력 안전 계통 소프트웨어 규격
• CENELEC 표준 검색 (EN 50128 · EN 50126 · EN 50129 계열) — 철도 계열 규격의 최신 판본과 개정 상태를 확인하는 공식 창구
• 모듈 3 레슨 7(구조 기반 기법) — MC/DC의 정의와 케이스 쌍 고르는 절차. 이 레슨은 그 위에 "커버리지를 어느 방향으로 쓰는가"만 얹었다
• 모듈 2 레슨 5(요구사항 변경과 추적성) — 양방향 추적과 고아 테스트 케이스. 이 레슨의 4단계 추적성이 그 개념의 확장판이다