개념
번호 셋의 관계부터
모듈 32 레슨 7의 인정범위 목록에는 IEC 62279:2015 와 KS C IEC 62279:2015 가 나란히
있었다. 그리고 그 레슨의 판 추적표에서 유럽의 대응 규격 EN 50128이 EN 50716:2023 으로
대체됐다는 것도 봤다. 철도 소프트웨어 규격을 시작하기 전에 이 셋의 관계를 고정해 둔다.
EN 50128:2011 (유럽, CENELEC) 철도 제어·보호 시스템 소프트웨어
│ 기반
▼
IEC 62279:2015 (국제) 같은 계열의 국제 규격
│ 부합화
▼
KS C IEC 62279:2015 (국가) 국내 KS
EN 50128:2011 + EN 50657:2017(차량 탑재 소프트웨어)
│ 통합·대체
▼
EN 50716:2023 (유럽) 철도 소프트웨어 전 영역실무 결론은 하나다. 국내 사업은 KS C IEC 62279나 IEC 62279를, 유럽 사업은 점점 EN 50716을 요구한다. 두 규격은 뼈대가 같지만 역할·도구·기법표에서 달라진 곳이 있고, 이 레슨 마지막 절이 그 차이다. 병행 적용 기간에 대한 안내는 자료마다 다르게 적혀 있으므로 계약서가 지정한 규격과 판을 원문으로 확정한다.
소프트웨어 SIL과 기본 무결성
철도 소프트웨어 규격은 모듈 25 레슨 5에서 본 대로 SIL 을 쓴다. IEC 62279와 EN 50128은 SIL 0~4 를 두고, SIL 4가 가장 엄격하다. SIL 0은 안전 관련이 아닌 소프트웨어에 대응하는 자리다.
EN 50716은 이 가장 낮은 칸의 이름을 "기본 무결성(Basic Integrity)" 으로 바꿨다. 철도 시스템 RAMS 규격 EN 50126과 용어를 맞춘 것이다. 번호 표기가 달라져도 의미는 "안전 무결성 요구가 할당되지 않은 소프트웨어"라는 점은 같다. 두 규격을 오가는 문서에서 SIL 0과 기본 무결성을 같은 칸으로 대응 해 두면 혼동이 줄어든다.
기법표 — 61508과 같은 틀, 그러나 "M"이 있다
62279 계열도 부속서 A에 기법표를 두고 SIL별 권고를 표기한다. 레슨 1의 61508-3과 거의 같은 틀인데, 표기가 하나 더 있다.
| 표기 | 뜻 |
|---|---|
| M | 필수(Mandatory) |
| HR | 강력 권고 |
| R | 권고 |
| - | 권고도 반대도 없음 |
| NR | 권고하지 않음 |
M이 있다는 것 이 철도 규격의 성격을 보여준다. 61508-3에서는 HR을 쓰지 않을 때 근거를 적으면 되지만, 62279 계열의 M은 근거로 넘을 수 없는 칸 이다. 시험 계획서의 기법 선택표를 만들 때 M 칸은 "채택/미채택" 열이 아니라 "수행 증거" 열만 있는 것처럼 다뤄야 한다.
시험 담당자가 가장 자주 여는 표는 세 개다.
| 표 | 내용 | 레슨 1과의 대응 |
|---|---|---|
| A.5 | 검증과 시험 | 61508-3 A.9 · A.5 |
| A.13 | 동적 분석과 시험 | 61508-3 B.2 |
| A.21 | 코드 시험 커버리지 — 문장·분기·복합 조건·데이터 흐름·경로 | 61508-3 B.2 구조 커버리지 줄 |
A.21에 데이터 흐름 커버리지와 경로 커버리지 가 들어 있다는 점이 눈에 띈다. 61508-3과 26262의 구조 커버리지가 제어 흐름(문장·분기·조건) 중심이었다면, 철도 규격 표는 선택지를 더 넓게 준다. 어떤 조합을 택하든 왜 그 조합이 해당 SIL에 충분한지 를 소프트웨어 검증 계획에 적어야 한다.
역할과 독립성 — 조직도가 증거가 되는 규격
모듈 25 레슨 5에서 철도 규격은 역할의 분리를 조직도와 인사 배치의 문제로 못 박는다 고 했다. 규격이 정의하는 역할은 대체로 이렇다.
요구사항 관리자 · 설계자 · 구현자 · 시험자 · 검증자 · 통합자 ·
확인자(Validator) · 평가자(Assessor) · 프로젝트 관리자 · 형상 관리자독립성 요구의 핵심은 만든 사람과 확인하는 사람의 거리 다.
| 역할 | 확인하는 대상 |
|---|---|
| 검증자(Verifier) | 각 단계 산출물이 그 단계 입력과 내부적으로 일관적인가 |
| 확인자(Validator) | 완성된 소프트웨어가 명세된 요구를 충족하는가 |
| 평가자(Assessor) | 수명주기 전체가 규격을 따랐는가 — 독립 안전 평가 |
SIL이 오를수록 거리가 멀어진다. 해설 자료들이 요약하는 경향은 이렇다. 낮은 SIL에서는 같은 팀 안의 다른 사람으로 분리해도 되지만, SIL 3~4에서는 부서나 조직 단위의 분리가 요구될 수 있다. 그리고 독립성은 선언이 아니라 조직도, 보고 라인, 평가자와 작성자 사이 재정적 연결 부재 로 확인된다.
그래서 이 규격에서 시험소나 평가자가 제일 먼저 요구하는 문서는 시험 결과가 아니라 역할 배치표 다.
| 역할 | 이름 | 소속 부서 | 보고 대상 | 겸임 역할 | 목표 SIL 에서 허용되는 겸임인가 | 근거 조항 |"겸임 역할" 칸이 판정의 대상이다. 작은 조직에서 시험자와 통합자를 한 사람이 겸하는 것은 흔하지만, 검증자가 설계자를 겸하는 조합 은 SIL과 무관하게 독립성 원칙을 정면으로 어긴다. 시험 결과가 모두 합격이어도, 이 표에서 허용되지 않는 겸임이 발견되면 그 결과를 만든 검증 활동의 신뢰가 무너진다.
도구 등급 T1~T3
레슨 1에서 61508-3 7.4.4가 오프라인 지원 도구를 요구한다고 했다. 철도 규격도 같은 세 등급을 쓴다.
| 등급 | 정의 | 예 | 요구 수준 |
|---|---|---|---|
| T1 | 실행 코드(데이터 포함)에 직접·간접으로 기여하는 출력을 만들지 않는다 | 텍스트 편집기, 코드 생성 없는 요구사항·설계 지원 도구, 형상 관리 도구 | 식별 |
| T2 | 설계나 실행 코드의 시험·검증을 지원한다. 도구 오류가 결함을 못 보게 할 수는 있지만 실행 코드에 오류를 직접 만들지는 않는다 | 시험 하니스 생성기, 커버리지 측정 도구, 정적 분석 도구 | 식별 + 선택 근거 + 도구 명세·매뉴얼 + 버전 관리 |
| T3 | 안전 관련 시스템의 실행 코드에 직접·간접으로 기여하는 출력을 만든다 | 컴파일러, 코드 생성기 | T2 요구 + 명세에 대한 적합성 증거 |
모듈 25 레슨 5가 항공 쪽 도구를 "오류를 집어넣을 수 있는 도구 / 오류를 놓칠 수 있는 도구"로 나눴는데, T3와 T2가 정확히 그 둘이다. QA가 일상적으로 쓰는 커버리지 도구·정적 분석기·시험 자동화 도구는 거의 모두 T2 다.
T2 요구가 실무에서 의미하는 것은 도구 버전이 형상 기준선의 일부 라는 점이다. 61508-3도 T2·T3 도구가 형상 기준선에 들어가는 항목을 만들면 도구 정보를 기준선에 기록하고, 새 버전마다 적격성을 확인하도록 한다. 커버리지 도구를 4.0에서 4.1로 올리면 그 자체가 형상 변경이고 적격성 확인 대상 이 된다.
[도구 등록부]
| 도구 | 버전 | 등급 | 사용 목적 | 선택 근거 | 적격성 확인 방법 | 확인 기록 | 기준선 ID |
|---|---|---|---|---|---|---|---|
| 커버리지 측정기 Y | 4.0.2 | T2 | 단위 분기 커버리지 | … | 알려진 커버리지 샘플 코드로 결과 대조 | TQ-Y-402 | BL-2026-07 |
| 크로스 컴파일러 Z | 11.3 | T3 | 타깃 빌드 | … | 벤더 적합성 증거 + 컴파일러 검증 스위트 | TQ-Z-113 | BL-2026-07 |"적격성 확인 방법" 칸에 흔히 쓰는 기법이 알려진 답을 가진 샘플 이다. 문장·분기 수를 손으로 계산해 둔 샘플 코드에 커버리지 도구를 돌려 결과가 일치하는지 본다. 모듈 18c에서 AI 출력을 교차검증할 때 정답이 알려진 기준 세트를 쓴 것과 같은 발상이다.
시험소가 이 규격으로 확인하는 증거
레슨 1의 세 갈래(증거 적합성 검토·독립 재수행·표본 시험)는 여기서도 같다. 철도 규격에서 두드러지는 확인 항목만 추리면 이렇다.
| 확인 항목 | 증거 | 자주 나오는 부적합 |
|---|---|---|
| 역할 배치와 독립성 | 역할 배치표, 조직도, 보고 라인 | 검증자가 설계에 참여한 흔적(리뷰 기록 작성자 불일치) |
| 기법표 충족 | 기법 선택표(M 칸의 수행 증거, HR 미채택 근거) | M 칸의 증거 누락, 표 판 번호 불일치 |
| 코드 커버리지 | A.21에서 택한 조합과 측정 결과, 미도달 분석 | 조합 선택 근거 부재 |
| 도구 등급 | 도구 등록부, 적격성 확인 기록, 기준선 | T2 도구 버전 변경이 기준선에 반영되지 않음 |
| 문서 체계 | 수명주기 단계별 계획·명세·보고서 | 단계 보고서가 다음 단계 입력과 연결되지 않음 |
첫 줄의 "리뷰 기록 작성자 불일치"는 흔한 발견 경로다. 역할 배치표에는 검증자가 A로 되어 있는데, 설계 리뷰 회의록의 설계 변경 제안자가 A라면 검증자가 설계에 참여한 것 이다. 문서 간 이름을 대조하는 것만으로 독립성 문제가 드러난다.
EN 50716 전환이 시험 계획에 주는 변화
EN 50716으로 넘어가면서 달라진 점 중 시험 계획에 직접 영향을 주는 것만 모으면 이렇다.
| 변화 | 시험 계획에 주는 영향 |
|---|---|
| SIL 0 → 기본 무결성 으로 명칭 변경 | 문서 템플릿과 대응표 갱신 |
| 통합자 역할 삭제 — 책임이 구현자와 시험자에게 재배분 | 역할 배치표에서 통합 시험 책임 주체 재지정 |
| 검증자·확인자 간 역할 이동 허용(권장하지는 않음) | 이동 시 이력과 독립성 영향 분석을 기록 |
| 안전 당국 승인 요구 일부 삭제 | 승인 절차 서식 정리 |
| 선형 수명주기뿐 아니라 반복·애자일 수명주기 를 명시적으로 수용 | 반복마다 검증·확인 활동과 증거가 어떻게 쌓이는지 계획서에 명시 |
| 정형 기법 의 권고 강도 상향 | 낮은 SIL에서도 정형 기법 채택 검토와 미채택 근거 필요 |
| 도구 다양성 — T3 도구의 출력을 독립적인 T2 도구로 검증하는 방식 인정 | 코드 생성기 적격성 대신 독립 검증 도구 경로 설계 가능 |
| 기본 무결성에서 T2 도구 문서 요구 완화 | 등급별 도구 등록부 요구 차등 |
"도구 다양성"은 시험 담당자에게 기회다. 코드 생성기(T3)의 적격성을 벤더 증거로만 입증하기 어렵다면, 생성된 코드를 독립적인 정적 분석기·시험 도구(T2)로 검증 하는 경로로 논거를 세울 수 있다. 이때 T2 도구의 독립성(같은 벤더·같은 파서를 공유하지 않는가)이 새로운 확인 항목이 된다.
애자일 수용은 모듈 7 레슨 8에서 다룬 스프린트 단위 QA와 안전 규격이 만나는 지점이다. 반복이 허용된다고 해서 증거가 줄지는 않는다. 반복마다 어떤 산출물이 갱신되고 어떤 검증이 다시 수행되는지 를 계획서에 규칙으로 적어야 한다.
실무에서 왜 필요한가
국내 철도 시스템 사업과 해외 수주 사업에서 소프트웨어 안전 증거는 계약의 인수 조건이다. 이 영역의 QA가 가장 먼저 부딪히는 일은 시험이 아니라 조직 설계 다. 작은 협력사가 SIL 4 신호 소프트웨어를 맡으면, 검증자와 확인자를 어느 조직에서 데려올지부터 정해야 하고 그 결정이 견적과 일정을 바꾼다. 역할 배치표를 사업 초기에 쓰지 않으면 시험을 다 하고도 독립성 문제로 결과를 다시 만드는 일이 생긴다.
도구 등록부는 일상적인 사고를 막는다. 개발자가 로컬에서 커버리지 도구를 업데이트하고, CI의 도구 버전은 그대로이고, 기준선 문서에는 또 다른 버전이 적혀 있는 상태가 흔하다. T2 도구 버전을 CI 설정과 기준선 문서에서 한 곳으로 관리 하는 것만으로 심사 지적의 상당수가 사라진다.
유럽 사업에서는 EN 50716 전환이 문서 전반의 개정을 요구한다. 전환 대응표(구 규격 조항 → 신 규격 조항 → 우리 문서 위치)를 먼저 만드는 QA가 전환 비용을 통제한다. 모듈 32 레슨 7에서 판 전환이 문서의 연도를 고치는 일이 아니라 서식을 고치는 일이라고 했던 것이 여기서 그대로 반복된다.