소프트웨어 공학 100 주제 시리즈의 89번째 글이다. (카테고리: 품질·신뢰성·보안)

한 줄 요약

안전 필수 소프트웨어 표준은 “버그 없는 코드” 를 요구하지 않는다. 대신 위험의 크기에 비례해 개발 보증의 엄격도를 정하고(DO-178C 의 소프트웨어 레벨 A~E, IEC 61508 의 SIL 1~4), 그 엄격도에 맞는 목표를 추적 가능한 증거로 보이게 한다.

왜 필요한가

소프트웨어가 물리 세계를 움직이면 결함의 결과가 데이터 손실이 아니라 인명 피해가 된다.

  • Therac-25: 방사선 치료기의 소프트웨어 결함이 과다 방사선 사고로 이어졌다. Leveson 과 Turner 의 An investigation of the Therac-25 accidents (IEEE Computer 26(7):18–41, 1993)는 이 사고를 소프트웨어 안전 공학의 고전적 사례 연구로 남겼다.
  • Ariane 5 501편: ESA 발표에 따르면 1996년 6월 4일 첫 비행에서 발사 약 40초 뒤 기체가 경로를 이탈해 폭발했다. 조사위원회는 원인을 관성 기준 시스템(SRI) 소프트웨어의 명세와 설계 오류로 인한 유도·자세 정보 상실로 결론지었다. 특히 이륙 전에만 의미가 있던 정렬 기능이 이륙 후에도 동작하고 있었는데 시뮬레이션에서 고려되지 않았고, 장비·시스템 시험이 충분히 실제를 대표하지 못했다고 지적했다.

두 사례의 공통점은 “코딩 실수” 보다 요구사항·설계·검증 과정의 빈틈이다. 안전 표준은 바로 그 과정을 규율한다. 소프트웨어 실패의 사회적 영향은 CS300 소프트웨어 실패의 사회적 영향 에서 다뤘다.

핵심 개념

안전, 신뢰성, 보안

속성 질문 예
신뢰성 정해진 기능을 고장 없이 수행하는가 브레이크 제어기가 100만 시간 동안 고장 없음
안전 받아들일 수 없는 위험(인명·환경 피해)이 없는가 고장 나도 안전한 상태로 간다 (fail-safe)
보안 악의적 행위자로부터 보호되는가 원격으로 브레이크 제어기를 조작할 수 없다

신뢰성이 높다고 안전한 것은 아니다. 명세가 위험하면 명세대로 완벽하게 동작하는 소프트웨어가 사고를 낸다. Ariane 501 이 그런 예다. 반대로 자주 멈추더라도 항상 안전한 상태로 멈추는 시스템은 안전할 수 있다.

IEC 61508: 기능 안전의 모(母) 표준

IEC 61508 은 “전기·전자·프로그래머블 전자 안전 관련 시스템의 기능 안전” 표준 시리즈이고, 그중 IEC 61508-3:2010 이 소프트웨어 요구사항을 다룬다. IEC 카탈로그 설명에 따르면 Part 3 은 안전 관련 시스템의 일부가 되거나 그것을 개발하는 데 쓰이는 모든 소프트웨어에 적용되고, 개발·구성 지원 도구에 대한 요구사항을 두며, 소프트웨어 안전 기능과 체계적 능력(systematic capability) 을 명세하도록 요구하고, 안전 생명주기 단계별 활동을 규정한다.

핵심 개념은 안전 무결성 수준(SIL) 이다.

  • 위험 분석으로 각 안전 기능에 필요한 위험 감소량을 정하고, 그에 따라 SIL 1~4 를 할당한다. SIL 4 가 가장 엄격하다.
  • 하드웨어의 무작위 고장은 확률 목표(작동 요구 빈도에 따라 요구 시 평균 위험 고장 확률 또는 시간당 위험 고장 빈도)로 다룬다.
  • 소프트웨어 결함은 무작위가 아니라 체계적(systematic) 고장이므로 확률로 다루지 않고, SIL 이 높을수록 더 엄격한 기법·조치(정형 방법, 정적 분석, 독립 검증 등)를 요구하는 방식으로 다룬다.

IEC 61508 은 여러 산업 표준의 바탕이 되었다. 자동차의 ISO 26262 (Road vehicles — Functional safety, 2판 2018, ASIL A~D)가 대표적이다.

DO-178C: 항공 소프트웨어

RTCA DO-178C Software Considerations in Airborne Systems and Equipment Certification 은 2011년 12월 13일자로 발행되었고, 유럽판은 EUROCAE ED-12C (2012년 1월)다. 미국 FAA 는 AC 20-115D (2017-07-21)에서 이를 항공 소프트웨어 측면의 감항 요건 충족을 보이는 허용 가능한 수단(유일한 수단은 아님) 으로 인정한다. 같은 AC 가 함께 인정하는 보충 문서는 다음과 같다.

문서 내용
DO-330 소프트웨어 도구 자격 인정 (Tool Qualification)
DO-331 모델 기반 개발·검증 보충
DO-332 객체지향 기술 보충
DO-333 정형 기법 보충

DO-333 의 존재는 SE100 #088 의 정형 기법이 인증 체계 안에서 테스트의 일부를 대체·보완하는 공식 수단이 되었음을 뜻한다.

소프트웨어 레벨과 구조적 커버리지

소프트웨어 레벨은 시스템 안전성 평가가 할당한다(AC 20-115D 도 “시스템 안전 프로세스가 최소 개발 보증 수준을 할당한다” 고 적는다). DO-178C 에서 레벨은 해당 소프트웨어의 이상 동작이 기여할 수 있는 고장 상태의 심각도에 대응한다.

레벨 고장 상태 분류 구조적 커버리지 요구 (NASA 튜토리얼 기준)
A 파국적 (Catastrophic) 문장 + 결정 + MC/DC
B 위험 (Hazardous) 문장 + 결정
C 중대 (Major) 문장
D 경미 (Minor) 구조적 커버리지 목표 없음
E 영향 없음 (No effect) DO-178C 목표 적용 안 함

커버리지 열은 NASA 의 A Practical Tutorial on Modified Condition/Decision Coverage (NASA/TM-2001-210876)가 DO-178B 목표를 정리한 내용이다. 문장 커버리지는 레벨 A~C, 결정 커버리지는 A~B, MC/DC 는 A 에만 요구된다.

MC/DC

같은 튜토리얼의 정의에 따르면 MC/DC(Modified Condition/Decision Coverage)는 조건/결정 커버리지에 더해 각 조건이 결정 결과에 독립적으로 영향을 준다는 것을 보이도록 요구한다. n 개 입력의 결정에 대해 일반적으로 최소 n+1 개 테스트가 필요하다. 예를 들어 A or B 는 (T,F), (F,T), (F,F) 세 개로 충족된다. 모든 입력 조합을 요구하는 다중 조건 커버리지는 2ⁿ 개가 필요해 조건이 많으면 비현실적이다. MC/DC 는 그 사이의 타협이다.

 결정: (a and b) or c
 a 의 독립성 쌍:  a b c = F T F → F,  T T F → T     (a 만 바뀌고 결과가 바뀜)
 b 의 독립성 쌍:  T F F → F,  T T F → T
 c 의 독립성 쌍:  F T F → F,  F T T → T  (등)
 최소 집합: {FTF, TTF, TFF, FTT}  → 4개 = n+1

실무 적용

MC/DC 테스트 집합 계산

from itertools import product, combinations

def decision(a, b, c):           # 예: 비상 정지 = (센서A 이상 and 센서B 이상) or 수동 버튼
    return (a and b) or c

names, rows = ["a", "b", "c"], list(product([False, True], repeat=3))
pairs = {n: [] for n in names}
for i, n in enumerate(names):
    for r in rows:
        if r[i]: continue
        flipped = tuple(not v if j == i else v for j, v in enumerate(r))
        if decision(*r) != decision(*flipped):
            pairs[n].append((r, flipped))

fmt = lambda r: "".join("T" if v else "F" for v in r)
for k in range(len(names) + 1, len(rows) + 1):
    best = next((s for s in combinations(rows, k)
                 if all(any(x in s and y in s for x, y in pairs[n]) for n in names)), None)
    if best:
        print("최소 MC/DC 테스트:", len(best), [fmt(r) for r in best]); break
# 최소 MC/DC 테스트: 4 ['FTF', 'FTT', 'TFF', 'TTF']

인증과 무관한 팀이 빌려 올 만한 것

항공·원자력이 아니어도, 결제·의료 정보·산업 제어처럼 결함 비용이 큰 영역은 다음 관행을 선택적으로 차용할 수 있다.

  • 양방향 추적성: 요구사항 ID ↔ 설계 ↔ 코드 ↔ 테스트를 잇는다. “이 요구사항을 검증하는 테스트는?” 과 “이 코드는 어떤 요구사항 때문에 있는가?” 에 모두 답할 수 있어야 한다. 후자에 답이 없는 코드는 의도하지 않은 기능(Ariane 의 정렬 기능처럼)일 수 있다.
  • 핵심 결정에만 MC/DC: 전체가 아니라 안전·금전 판단 로직의 복합 조건에만 적용한다.
  • 도구도 검증 대상: 코드 생성기·정적 분석기·테스트 도구의 결과를 증거로 쓴다면 그 도구가 틀릴 가능성을 고려한다(DO-330 의 문제의식).
  • 검증의 독립성: 높은 위험 영역은 작성자가 아닌 사람이 검증한다(SE100 #082 의 인스펙션과 연결).
  • 안전 상태 정의: 고장 시 어디로 갈지(정지, 이전 값 유지, 수동 전환)를 요구사항으로 명시한다.
# trace.yaml — 추적성 매트릭스 예시 (CI 에서 누락 검사)
- req: SR-012
  text: "두 압력 센서가 모두 상한 초과이거나 수동 정지 입력이면 펌프를 정지한다"
  hazard: HZ-03 (과압 파열)
  design: docs/pump-control.md#emergency-stop
  code: [src/pump/EmergencyStop.kt]
  tests: [EmergencyStopTest.mcdc_FTF, mcdc_FTT, mcdc_TFF, mcdc_TTF]
  coverage: MC/DC

흔한 오해와 함정

  • “MC/DC 100% = 안전” — 커버리지는 요구사항 기반 테스트가 코드 구조를 충분히 실행했는지 보는 분석이지, 요구사항이 옳다는 증거가 아니다. 위험한 명세는 완벽한 커버리지로도 걸러지지 않는다.
  • “표준 준수 = 안전” — 표준은 최소한의 공학적 규율이다. 위험 분석이 빠뜨린 위험에 대해서는 아무것도 보장하지 않는다.
  • 소프트웨어 고장률을 확률로 계산 — IEC 61508 이 소프트웨어를 체계적 고장으로 다루는 이유를 기억해야 한다. “이 코드는 10⁻⁹ 확률로 실패한다” 같은 주장은 근거를 만들기 매우 어렵다.
  • 재사용 코드는 검증됐다는 가정 — 다른 환경에서 검증된 소프트웨어도 새 환경의 운용 조건에서는 다시 분석해야 한다. 조사위원회가 지적한 “실제를 대표하지 못한 시험” 이 이 문제다.
  • 안전과 보안의 분리 — 네트워크에 연결된 안전 시스템에서 보안 침해는 곧 안전 위협이다. 위협 모델링(SE100 #086)을 위험 분석과 함께 한다.

확인 문제

  1. 신뢰성은 높지만 안전하지 않은 시스템의 예를 들라.
  2. IEC 61508 이 소프트웨어 결함을 확률 목표가 아니라 기법·조치의 엄격도로 다루는 이유는?
  3. DO-178C 에서 MC/DC 가 요구되는 레벨과 그 레벨의 고장 상태 분류는?
  4. a and b and c 를 MC/DC 로 충족하는 최소 테스트 집합을 구하라.
  5. FAA AC 20-115D 가 DO-178C 를 “허용 가능한 수단이지만 유일한 수단은 아니다” 라고 표현하는 의미는?

풀이

  1. 명세대로 항상 정확히 동작하지만 명세 자체가 특정 상황에서 위험한 동작을 지시하는 제어기. 예컨대 이륙 후에는 불필요한 기능이 계속 동작하도록 명세된 경우.
  2. 소프트웨어 결함은 같은 입력·상태에서 항상 같은 방식으로 나타나는 체계적 고장이라 무작위 고장처럼 통계적 고장률로 모델링하기 어렵다. 그래서 결함을 만들지 않고 찾아내는 과정의 엄격도로 다룬다.
  3. 레벨 A, 파국적(Catastrophic) 고장 상태.
  4. TTT(결과 T)와, 각 조건 하나만 F 인 FTT, TFT, TTF(결과 F). 총 4개 = n+1.
  5. 감항 요건 충족을 보이는 방법으로 DO-178C 를 따르면 인정받을 수 있지만, 다른 방법으로 동등한 충족을 입증하는 것도 원칙적으로 가능하다는 뜻이다. 다만 AC 의 수단을 쓰기로 했다면 해당 내용을 모든 적용 측면에서 따라야 한다.

더 읽을거리 (References)