본문으로 건너뛰기
중급15

표준이 필요한 이유: 공통 언어, 감사 가능성, 규제 대응

팀마다 제각각인 테스트 방식 위에, 왜 국제 표준이라는 공통 틀이 필요한지 세 가지 이유(공통 언어, 감사 가능성, 규제 대응)로 이해한다.

  • #ISO29119
  • #표준
  • #규제

개념

팀마다 다른 테스트 방식의 문제

모듈 7(레슨 6)에서 TMMi·TPI Next 같은 프로세스 개선 모델을 배웠다 — 이 모델들은 "우리 팀이 얼마나 체계적인가"를 스스로 진단하는 도구였다. 하지만 자체 진단만으로는 부족한 상황이 있다. 서로 다른 회사, 다른 팀이 같은 산출물을 주고받아야 할 때(예: 외주 개발사가 납품하는 테스트 결과를 발주사가 검토할 때), 팀마다 "테스트 계획서"의 형식과 내용이 다 다르면 소통 비용이 커진다.

표준이 해결하는 세 가지 문제

1. 공통 언어(Common Vocabulary)

"테스트 케이스"라는 단어 하나도 조직마다 다르게 쓰일 수 있다. 표준은 용어를 명확히 정의해서, 서로 다른 조직 사람들이 같은 단어를 같은 의미로 쓰게 만든다. ISTQB 용어집(이 강의 전체에서 참고 자료로 계속 인용해온 것)도 이런 표준화 노력의 일부다.

2. 감사 가능성(Auditability)

"이 소프트웨어가 충분히 테스트됐다"는 걸 제3자(고객, 규제기관, 감사자)에게 증명해야 하는 상황이 있다. 표준화된 형식의 문서는 감사자가 "이 프로세스를 제대로 따랐는지" 확인하기 쉽게 만든다 — 감사자마다 익숙한 형식이 다르면 검토 자체가 오래 걸린다.

3. 규제 대응(Regulatory Compliance)

금융, 의료기기, 항공처럼 사람의 안전이나 자산에 직결되는 산업은 법적으로 특정 수준의 테스트 문서화를 요구하는 경우가 많다. 표준을 따르면 "우리가 임의로 만든 프로세스"가 아니라 "국제적으로 합의된 프로세스를 따랐다"는 근거를 댈 수 있다.

ISO/IEC/IEEE 29119란

소프트웨어 테스트에 관한 국제 표준으로, ISO(국제표준화기구)·IEC(국제 전기기술위원회)·IEEE(전기전자기술자협회) 세 기관이 공동으로 제정했다. 이전까지 흩어져 있던 여러 테스트 표준(IEEE 829 등)을 통합해 만들어진, 현재 가장 폭넓게 참조되는 소프트웨어 테스트 표준이다.

표준을 따르는 것과 무조건 좋은 것은 다르다

표준을 도입한다고 결함이 저절로 줄어들지는 않는다. 표준은 "무엇을, 어떤 형식으로 문서화할지"에 대한 합의일 뿐이지, 테스트 자체를 더 잘하게 만드는 마법이 아니다. 오히려 규모가 작고 빠르게 움직이는 팀에게 표준의 전체 문서 체계를 그대로 강제하면 불필요한 오버헤드가 될 수 있다 — 표준은 필요한 만큼 선택적으로 적용하는 것이 현실적인 접근이다.

실무에서 왜 필요한가

규제 산업 QA 채용공고에서 "ISO 29119 이해" 또는 "테스트 문서화 표준 경험"을 요구하는 이유가 여기 있다. 표준을 몰라도 테스트 자체는 할 수 있지만, 표준화된 문서를 요구하는 고객사나 규제기관과 협업할 때는 표준의 언어를 알아야 대화가 가능하다. 특히 의료기기(스테이지 6 부록)처럼 규제가 법적으로 강제되는 영역에서는 표준 이해가 선택이 아니라 필수에 가깝다.

실습 과제

과제 1 — 표준이 필요한 상황 판단하기 (8분)

다음 두 상황 중, 표준화된 테스트 문서 체계가 더 필요한 쪽은 어디인지 판단하고 이유를 적는다.

  1. 3명이 운영하는 스타트업이 매주 새 기능을 배포하는 모바일 앱
  2. 병원에 납품되는 의료기기 제어 소프트웨어

과제 2 — 공통 언어의 가치 체감하기 (7분)

"테스트 케이스"라는 용어를 우리 팀은 어떤 의미로 쓰는지, 그리고 다른 팀·회사는 다르게 쓸 수 있는 예시를 하나 상상해서 적어본다. 이 차이가 협업에서 어떤 혼란을 만들 수 있을지도 함께 적는다.

자가 체크리스트

  • 표준이 해결하는 세 가지 문제(공통 언어·감사 가능성·규제 대응)를 설명할 수 있다
  • ISO/IEC/IEEE 29119가 어떤 기관들이 공동 제정한 표준인지 안다
  • 표준을 따르는 것이 테스트 품질을 자동으로 높여주지 않는다는 것을 설명할 수 있다
  • 작은 팀에 표준 전체를 강제하는 것이 오버헤드가 될 수 있는 이유를 설명할 수 있다

흔한 실수

  • 표준을 따르면 결함이 자동으로 줄어든다고 오해한다. 표준은 문서화 형식의 합의일 뿐, 테스트 설계 능력 자체를 대체하지 않는다.
  • 모든 조직에 표준 전체를 획일적으로 적용해야 한다고 생각한다. 규모와 리스크에 맞게 선택적으로 적용하는 것이 현실적이다.
  • 표준을 규제기관이 강제하는 귀찮은 형식으로만 본다. 실제로는 서로 다른 조직 간 협업 비용을 줄여주는 실질적 가치가 있다.

참고 자료