표준 지도 — 내 프로젝트에 어떤 규격이 걸리는가

개념

모듈 8이 끝난 자리에서 시작한다

모듈 8에서 ISO/IEC/IEEE 29119를 배웠다. 레슨 2에서 확인했듯이 29119는 Part 1(개념·정의), Part 2(테스트 프로세스), Part 3(테스트 문서화), Part 4(테스트 기법)로 나뉜다. 이 네 파트가 답하는 질문은 하나로 모인다 — "테스트를 어떤 순서로 수행하고, 그 결과를 어떤 형식으로 남기는가" 다.

그런데 실무에서 규격 번호를 마주치는 상황을 떠올려보면 이상한 점이 있다. 자동차 부품사 채용공고에는 ISO 26262가, 의료기기 회사에는 IEC 62304가, 공공 SI 제안요청서에는 GS인증과 ISO/IEC 25023이 적혀 있다. 29119는 오히려 잘 안 보인다. 왜일까.

29119는 테스트를 수행하는 방법의 표준 이기 때문이다. 반면 위 규격들은 그 바깥에서 다른 것을 정한다. "무엇을 품질이라 부를 것인가", "이 제품은 얼마나 강하게 검증해야 하는가", "우리 팀이 일하는 방식이 충분한가" 같은 질문이다. 이들은 29119를 대체하는 경쟁 표준이 아니라, 29119가 수행할 테스트의 범위와 강도를 바깥에서 결정하는 층 이다.

[도메인 안전 규격]  ISO 26262 / IEC 62304 / DO-178C
      "이 소프트웨어는 ASIL D다 → 이만큼 강하게 검증하라"
                        │  검증 강도를 결정
                        ▼
[품질 모델 규격]    ISO/IEC 25010 / 25023 / 12119
      "무엇을 품질이라 부르고, 어떤 지표로 잴 것인가"
                        │  측정 대상을 정의
                        ▼
[테스트 표준]       ISO/IEC/IEEE 29119   ← 모듈 8
      "그 검증을 어떤 프로세스와 문서로 수행할 것인가"
                        ▲
                        │  그 일하는 방식을 평가
[프로세스 평가]     Automotive SPICE / ISO/IEC 33063 / 20246

이 레슨은 이 지도 전체를 조망한다. 개별 규격의 내용은 레슨 2 이후가 맡으므로, 여기서는 분류하는 틀과 판단하는 기준 만 확실히 잡는다.

표준을 네 갈래로 나누는 틀

수십 개의 규격 번호를 개별적으로 외우는 것은 불가능하고 쓸모도 없다. 대신 네 갈래로 접어두면 처음 보는 번호도 어딘가에 넣을 수 있다.

갈래 ① — 제품 품질을 정의하고 측정하는 규격

ISO/IEC 25010 은 소프트웨어 품질을 여러 특성으로 쪼개 정의한다. 기능 적합성·성능 효율성·호환성·상호작용 능력(사용성)·신뢰성·보안성· 유지보수성·이식성이 그것이다. 이 이름들이 중요한 이유는 "품질이 좋다"는 막연한 말을 검증 가능한 항목으로 쪼개주기 때문 이다. 모듈 5에서 배운 비기능 테스트 유형들이 사실상 이 목록과 겹친다.

ISO/IEC 25023 은 그 특성들을 어떤 지표로 잴 것인지를 다룬다. 25010이 "신뢰성이라는 특성이 있다"까지라면, 25023은 "평균 무고장 시간으로 잰다" 같은 측정 방법을 준다. ISO/IEC 12119 는 패키지로 판매되는 소프트웨어 제품이 갖춰야 할 요구사항과 시험 항목을 다루는 오래된 규격으로, 국내 GS(Good Software)인증 의 시험 기준이 이 계열에 뿌리를 두고 있다.

이 갈래의 특징은 강제되지 않는다 는 점이다. 아무도 웹 서비스에 25010을 지키라고 법으로 요구하지 않는다. 대신 계약서와 인증에서 힘을 발휘한다 — "품질이 좋아야 한다"는 계약 문구는 다툼이 되지만, "응답 시간 95퍼센타일 500ms 이하"는 다툼이 되지 않는다.

갈래 ② — 도메인 안전 규격

이 갈래는 성격이 완전히 다르다. 제품이 오작동했을 때 사람이 다치거나 죽을 수 있는 영역 에 적용되고, 대개 규제·인증과 묶여 있어 사실상 강제된다.

번호와 도메인이 제각각인데도 이 규격들은 거의 같은 문법 을 쓴다.

1. 오작동했을 때의 피해 크기와 발생 가능성을 따져 위험 등급 을 매긴다
2. 등급이 높을수록 요구되는 활동과 증거가 늘어난다 (더 엄격한 커버리지, 더 독립적인 검증자, 더 많은 문서)
3. 요구사항부터 코드·테스트까지 추적성(traceability) 을 증명해야 한다

테스트 엔지니어 입장에서 이 문법의 실질적 의미는 하나다. 테스트의 강도가 내 재량이 아니라 등급표로 정해진다 는 것. ASIL D 부품에서 "이 정도면 충분히 테스트했다"는 판단은 개인의 것이 아니라 규격이 정한 것이다.

갈래 ③ — 프로세스 평가와 정적 테스트

앞의 두 갈래가 제품을 보는 반면, 이 갈래는 팀이 일하는 방식 을 본다.

Automotive SPICE 는 자동차 산업의 프로세스 평가 모델이다. 완성차 업체(OEM)가 협력사를 심사할 때 쓰며, 프로세스별로 능력 수준(Capability Level)에 점수를 매긴다. 테스트 엔지니어와 직결되는 부분은 소프트웨어 검증 계열 프로세스(SWE.5·SWE.6)이고, 레슨 6에서 다룬다.

ISO/IEC 20246 은 리뷰·인스펙션 같은 정적 테스트 를 규정한다. 코드를 실행하지 않고 문서와 코드를 사람이 검토하는 활동에도 절차와 역할이 있다는 것이 이 규격의 요지다. ISO/IEC 33063 은 테스트 프로세스를 평가하기 위한 모델로, 29119-2가 정의한 프로세스를 평가 기준으로 삼는다 — 모듈 7에서 배운 TMMi·TPI Next와 목적이 같은 자리에 있는 국제 규격이다.

갈래 ④ — 레거시 문서 표준

IEEE 829 (테스트 문서화), IEEE 1008 (단위 테스트), IEEE 730 (소프트웨어 품질보증 계획)은 29119 이전 세대의 표준이다. 공식적으로는 29119 시리즈로 대체되었지만, 현장의 문서 템플릿에는 여전히 흔적이 남아 있다 — "IEEE 829 형식의 테스트 계획서"를 요구하는 오래된 발주 문서를 지금도 만난다. 이 갈래는 모듈 8의 마지막 레슨(표준 산출물 문서 따라가기) 에서 다루므로, 이 모듈에서는 다시 설명하지 않는다.

각 갈래는 서로 다른 질문에 답한다

네 갈래를 헷갈리지 않는 가장 확실한 방법은 각 갈래가 답하는 질문을 외우는 것 이다.

같은 프로젝트에 세 갈래가 동시에 걸릴 수 있다. 자동차 부품사는 ISO 26262 (②)를 지키면서 Automotive SPICE(③) 심사를 받고, 고객사가 요구하는 품질 지표(①)를 함께 보고한다. 갈래는 배타적 분류가 아니라 서로 다른 층 이다.

내 프로젝트에 무엇이 걸리는지 판단하는 순서

지도를 그렸으면 다음 질문은 하나다 — 나에게는 무엇이 걸리는가. 순서가 중요하다. 강제력이 강한 것부터 확인 해야 시간을 아낀다.

Q1. 이 소프트웨어의 오작동이 사람의 생명·신체를 해칠 수 있는가?
    ├ 예 → 갈래 ② 확정. 도메인으로 규격이 결정된다
    │       자동차=ISO 26262 / 의료=IEC 62304 / 항공=DO-178C
    │       철도=IEC 62279 / 원자력=IEC 60880
    └ 아니오 ↓
 
Q2. 제품을 팔거나 운영하려면 규제기관·인증기관의 허가가 필요한가?
    ├ 예 → 그 기관이 인정하는 규격이 곧 요구사항이다
    │       (의료기기 인허가 심사 → IEC 62304 + 위험관리 문서)
    └ 아니오 ↓
 
Q3. 발주처·고객사가 계약서·RFP에서 특정 규격을 요구하는가?
    ├ 예 → 계약 문구에 적힌 규격과 등급을 그대로 확인
    │       (공공 SI의 GS인증 / OEM의 A-SPICE 능력 수준 2)
    └ 아니오 ↓
 
Q4. 우리가 자발적으로 채택할 이유가 있는가?
    ├ 예 → 갈래 ①·③에서 필요한 부분만 골라 쓴다
    │       (품질 목표를 부르는 공통 언어, 수출 대응, 영업 자산)
    └ 아니오 → 표준 문서 체계 대신 팀 규모에 맞는 경량 프로세스

두 가지를 주의한다. 첫째, 이 질문들은 배타적이지 않고 누적된다. Q1에서 걸렸다고 Q3을 건너뛰면 안 된다. 둘째, Q1의 답이 애매한 경우가 실무에서 가장 많다 — 그럴 때는 혼자 판단하지 말고 Q2로 넘어가 규제 기관이 이 제품을 무엇으로 분류하는지 를 확인하는 편이 훨씬 빠르고 안전하다.

네 가지 시나리오에 적용해보기

웹 서비스 스타트업 — 구독형 SaaS를 만든다. 오작동해도 사람이 다치지 않고, 판매에 인증이 필요 없으며, 고객이 규격을 요구하지도 않는다. 그렇다고 표준이 무용한 것은 아니다. ISO/IEC 25010의 특성 목록을 비기능 요구사항 체크리스트로 빌려 쓰면 "성능은 생각도 안 했다" 같은 누락을 막을 수 있다. 다만 개인정보·전자금융처럼 소프트웨어 안전과 무관한 별개 규제 는 이 흐름도 바깥에서 따로 확인해야 한다.

자동차 부품 협력사 — ECU 소프트웨어를 만든다. Q1·Q2·Q3이 모두 걸린다. ISO 26262로 ASIL 등급을 받고, 등급에 따라 요구되는 커버리지와 검증자 독립성이 정해지며, 그 위에 OEM의 Automotive SPICE 심사가 얹힌다. 테스트 엔지니어의 하루는 요구사항-테스트 케이스 추적성을 증명 가능한 형태로 유지하는 일 이 큰 비중을 차지한다.

병원 EMR — 전자의무기록 시스템 자체는 보통 의료기기로 분류되지 않지만, 진단이나 치료 판단에 직접 관여하는 기능이 붙으면 소프트웨어 의료기기로 규제 대상이 된다. 같은 제품인데 기능 하나로 갈래가 바뀌는 대표적인 사례 다. 그래서 Q1을 혼자 고민하는 대신 Q2 — 규제기관이 이 제품을 어떻게 분류하는지 — 를 먼저 확인해야 한다. 규제 대상이면 IEC 62304와 위험관리 문서가 따라오고, 아니면 병원 발주 요구사항과 갈래 ①의 문제로 좁혀진다.

공공 SI — 제안요청서에 "GS인증 1등급 제품"이 요건으로 적혀 있다. 안전 규격도 규제도 아니지만 Q3에서 걸린다. 이때 필요한 것은 갈래 ①이다 — 25010의 특성을 25023 계열의 지표로 측정해 시험 성적서로 제출하는 흐름이 된다. 계약이 품질 규격을 강제력 있는 요구사항으로 바꾸는 경로 다.

규격 번호를 만났을 때의 30초 판단법

처음 보는 번호가 문서에 등장했을 때, 검색하기 전에 번호 자체가 주는 힌트가 있다.

번호 규칙은 힌트일 뿐 근거가 아니다. 반례가 곧바로 나온다. ISO 26262는 IEC 61508에서 파생된 기능안전 규격인데 번호는 ISO 26xxx다. Automotive SPICE는 애초에 ISO 번호가 아니라 자동차 산업 단체가 관리하는 모델이다. 그래서 30초 판단 뒤에는 반드시 세 가지를 확인한다.

1. 원문의 Scope 절 — 그 규격이 스스로 밝힌 적용 범위. ISO의 온라인 열람 플랫폼(OBP)에서 Scope는 대개 무료로 볼 수 있다
2. 판(edition)과 연도 — ISO 26262:2011과 2018은 적용 대상 차량 범위부터 다르다. 계약서에 연도가 없으면 어느 판인지 되물어야 한다
3. 파트 번호 — 여러 파트로 나뉜 규격은 파트마다 대상이 다르다. ISO 26262에서 소프트웨어 개발은 Part 6이고, 계약서가 "ISO 26262 준수"라고만 적혀 있으면 어느 파트까지인지 확정되지 않은 상태다

표준 준수는 최소선이지 상한이 아니다

모듈 8 레슨 1에서 "표준을 도입한다고 결함이 저절로 줄지는 않는다" 는 점을 확인했다. 이 문장은 안전 규격에도 그대로, 오히려 더 강하게 적용된다.

표준이 요구하는 것은 제3자에게 증명 가능한 최소선 이다. 표준은 "이만큼은 했다는 것을 서류로 보일 수 있어야 한다"를 정할 뿐, "이만큼 했으면 안전하다"를 보장하지 않는다.

구조 커버리지를 100% 채워도 요구사항이 애초에 틀렸다면 그 커버리지는 틀린 것을 성실히 검증한 기록일 뿐이다. 그래서 표준을 만날 때 유지해야 할 태도는 모듈 8에서 익힌 것과 같다 — 요구 항목을 하나씩 보며 "왜 이 문서를, 왜 이 활동을 요구하는가" 를 묻는 것. 그 질문에 답할 수 있으면 규격이 바뀌어도, 처음 보는 도메인 규격을 만나도 대응할 수 있다.

실무에서 왜 필요한가

규격 지도를 갖고 있으면 실무에서 세 가지가 달라진다.

첫째, 계약서와 제안요청서를 읽을 수 있다. "본 사업의 산출물은 ISO/IEC 25023에 따른 품질 측정 결과를 포함한다"는 한 줄이 무엇을 요구하는지 즉시 알면, 견적과 일정에 그 작업을 넣을 수 있다. 모르면 프로젝트 후반에 발견하고 일정을 갈아넣게 된다.

둘째, 테스트 계획의 강도를 근거 있게 정할 수 있다. 모듈 4에서 테스트 계획을 배웠는데, 그때 "얼마나 테스트할 것인가"는 리스크 판단에 달려 있었다. 안전 규격이 걸리는 프로젝트에서는 그 답의 상당 부분이 등급표로 이미 정해져 있다. 규격을 모르면 협상의 여지가 없는 항목을 두고 논쟁하며 시간을 쓴다.

셋째, 처음 보는 도메인으로 이직해도 자세를 잡을 수 있다. 규격의 세부 조항은 그때 읽으면 되지만, "이 도메인의 규격은 위험 등급을 매기고 등급별로 검증 강도를 정하는 구조겠구나"라는 예측은 지도가 있어야 가능하다. 이 예측이 규격서를 읽는 속도를 완전히 바꾼다.

채용시장에서의 위치

이 레슨의 능력은 단독으로 채용공고에 적히지는 않는다. 공고에 적히는 것은 "ISO 26262 ASIL D 경험" 같은 구체적인 규격 이름이다. 하지만 면접에서 규격 경험을 이야기할 때 지도가 있는 사람과 없는 사람의 답이 다르다.

없는 사람은 자기가 해본 규격의 절차만 말한다. 있는 사람은 "그 규격은 위험 등급에 따라 검증 강도를 정하는 계열이고, 저는 거기서 추적성 유지와 등급별 커버리지를 담당했으며, 같은 구조라면 다른 도메인 규격도 접근할 수 있습니다"라고 말한다. 후자는 한 규격의 경험을 이전 가능한 역량으로 제시하는 답 이다.

규제 산업으로 이동하려는 사람에게는 더 직접적이다. 자동차·의료·항공은 경력 채용에서 규격 경험을 강하게 보지만, 신입·전환자에게는 "이 도메인의 규격 체계를 이해하고 있는가"를 먼저 확인한다. 지도를 그릴 수 있다는 것이 그 확인을 통과하는 최소 조건이다.

실습 과제

과제 1 — 내 프로젝트에 판단 흐름 적용하기 (10분)

지금 다니는 회사(또는 마지막으로 참여한 프로젝트)의 제품 하나를 골라 Q1~Q4를 순서대로 답한다. 각 질문마다 "예/아니오"와 그 판단의 근거 (누가 요구했는지, 어떤 문서에 적혀 있는지)를 함께 적는다. 근거를 못 적는 질문이 있다면 그것이 확인해야 할 항목이다.

과제 2 — 규격 번호를 갈래에 배정하기 (8분)

다음 여섯 개를 네 갈래 중 하나에 배정하고, 각각이 답하는 질문을 한 문장으로 적는다. 번호만 보고 먼저 추측한 뒤, 검색해서 맞았는지 확인한다.

1. ISO/IEC 25040
2. IEC 61508
3. IEEE 730
4. ISO/IEC 20246
5. DO-254
6. ISO 26262-6

과제 3 — 계약 한 줄을 요구 작업으로 번역하기 (12분)

가상의 제안요청서에 다음 문장이 있다고 하자.

"수행사는 산출물에 대해 ISO 26262 준수를 입증하고, Automotive SPICE 능력 수준 2를 만족함을 증빙한다."

이 한 줄에서 확정되지 않은 것 세 가지 를 찾아내고, 발주처에 되물어야 할 질문으로 바꿔 적는다.

과제 4 — 갈래별 질문 카드 만들기 (5분)

갈래 ①·②·③에 대해, 각각 "이 갈래가 답하는 질문"과 "안 지켰을 때 벌어지는 일" 을 한 장의 카드처럼 세 줄로 정리한다. 규격 번호를 보지 않고도 갈래를 떠올릴 수 있는지 스스로 시험하는 용도다.

자가 체크리스트

• ISO/IEC/IEEE 29119와 이 모듈의 표준들이 서로 다른 층에 있다는 것을 설명할 수 있다
• 표준을 네 갈래(품질 모델·도메인 안전·프로세스 평가·레거시 문서)로 나누고 각각의 대표 규격을 댈 수 있다
• 각 갈래가 답하는 질문("무엇이 좋은가"·"사람을 다치게 하는가"·"우리 방식이 충분한가")을 구분해 말할 수 있다
• Q1~Q4 판단 흐름을 순서대로 적용해 내 프로젝트에 걸리는 규격을 추려낼 수 있다
• 이 질문들이 배타적 분기가 아니라 누적된다는 것을 설명할 수 있다
• 도메인 안전 규격들이 공유하는 세 가지 공통 문법(위험 등급·등급별 요구 강화·추적성)을 말할 수 있다
• 규격 번호 패턴으로 갈래를 추측하되, 왜 그것을 근거로 삼으면 안 되는지 반례를 들 수 있다
• 처음 보는 규격에서 Scope·판·파트 번호 세 가지를 확인해야 하는 이유를 설명할 수 있다
• 표준 준수가 "증명 가능한 최소선"이지 좋은 테스트의 상한이 아니라는 것을 예를 들어 설명할 수 있다
• 계약서의 규격 요구 한 줄에서 확정되지 않은 항목을 찾아 질문으로 바꿀 수 있다

흔한 실수

• 규격 번호 규칙을 신뢰해 원문 Scope를 확인하지 않는다. ISO 26262는 ISO 번호를 달고 있지만 IEC 61508 계열의 기능안전 규격이고, DO-254는 DO-178C와 번호가 이웃이지만 하드웨어를 다룬다. 번호는 첫 추측을 빠르게 해줄 뿐, 근거는 언제나 원문의 적용 범위다.
• 판(edition)과 파트 번호를 빼놓고 "준수"만 이야기한다. 같은 규격도 판이 다르면 요구가 다르고, 파트가 다르면 대상이 다르다. 계약과 견적은 이 셋이 확정된 뒤에야 성립한다.
• 갈래를 배타적 분류로 오해한다. 안전 규격이 걸리면 품질 규격은 필요 없다고 생각하기 쉬운데, 실제 규제 산업 프로젝트는 세 갈래가 동시에 걸리는 경우가 흔하다.
• Q1(안전)을 혼자 판단하려 한다. EMR처럼 경계에 있는 제품은 개인의 상식이 아니라 규제기관의 분류가 답이다. 애매하면 Q2로 넘어가 분류 기준을 확인하는 것이 빠르고 안전하다.
• 표준이 요구하는 항목을 채우는 것과 잘 테스트하는 것을 같다고 본다. 커버리지 목표를 채워도 요구사항 자체가 틀렸으면 틀린 것을 성실히 검증한 기록이 남을 뿐이다.
• 아무 규격도 안 걸리는 프로젝트에서 표준이 쓸모없다고 결론짓는다. 25010의 특성 목록을 비기능 요구사항 체크리스트로 빌려 쓰는 것만으로도 누락을 크게 줄인다. 인증을 받는 것과 언어를 빌리는 것은 다른 일이다.
• 레거시 표준을 이름만 보고 무시한다. IEEE 829는 공식적으로 대체 되었지만 오래된 발주 문서와 사내 템플릿에는 여전히 살아 있다. 대체 되었다는 사실과 현장에서 마주치지 않는다는 것은 다른 이야기다.
• 규격서를 처음부터 끝까지 읽으려 한다. 모듈 8 레슨 2에서 29119를 파트별로 나눠 필요한 곳만 찾아본 것과 똑같이, 이 갈래의 규격들도 "내 질문이 어느 파트에 있는가"부터 좁히는 것이 정석이다.

참고 자료

• ISO Online Browsing Platform — 규격의 Scope와 용어 정의를 무료로 열람할 수 있다. 번호만 보고 추측한 갈래를 검증하는 첫 관문
• ISO/IEC 25010 공식 페이지 — 제품 품질 모델의 공식 범위 소개 (레슨 2에서 상세히 다룬다)
• ISO 26262 시리즈 공식 페이지 — 자동차 기능안전 규격의 파트 구성 확인
• IEC 62304 공식 페이지 — 의료기기 소프트웨어 생명주기 프로세스 규격
• Automotive SPICE 공식 사이트 — 프로세스 평가 모델 문서와 배포 자료
• RTCA 공식 사이트 — DO-178C를 포함한 항공 표준 발행 기관