개념
먼저 표준이 무엇이 아닌지부터 정하자. 표준은 더 잘하는 방법이 아니라 서로 통하는 방법이다.
나사 규격을 떠올리면 정확하다. M6 나사 규격이 나사를 더 튼튼하게 만들지 않는다. 다만 어느 공장에서 만든 나사든 같은 구멍에 들어간다. 그 호환성 하나가 산업 전체의 비용을 바꾼다.
테스트 표준도 같다. 29119를 따른다고 결함이 줄지 않는다. 다만 다른 조직이 만든 테스트 산출물을 서로 읽을 수 있게 된다. 이 레슨은 그 호환성이 언제 돈이 되는지를 다룬다.
팀마다 다른 테스트 방식의 문제
모듈 7(레슨 6)에서 TMMi·TPI Next 같은 프로세스 개선 모델을 배웠다 — 이 모델들은 "우리 팀이 얼마나 체계적인가"를 스스로 진단하는 도구였다. 하지만 자체 진단만으로는 부족한 상황이 있다. 서로 다른 회사, 다른 팀이 같은 산출물을 주고받아야 할 때(예: 외주 개발사가 납품하는 테스트 결과를 발주사가 검토할 때), 팀마다 "테스트 계획서"의 형식과 내용이 다 다르면 소통 비용이 커진다.
이 비용이 실제로 청구되는 순간이 정해져 있다. 평소에는 안 보이고, 아래 상황에서 한꺼번에 온다.
| 상황 | 표준이 없을 때 치르는 비용 |
|---|---|
| 외주 납품·검수 | 산출물 형식을 처음부터 협의해야 한다 |
| 인증·심사 | 심사자가 요구하는 형식으로 다시 작성한다 |
| 규제기관 제출 | 반려되고 보완 요구가 반복된다 |
| 내부·외부 감사 | "했다" 는 증명이 안 되어 자료를 다시 모은다 |
| 회사 간 통합·인수 | 양쪽 산출물을 대조할 수 없다 |
| 담당자 이직·교체 | 인수인계가 구두로만 가능해진다 |
첫 줄과 세 번째 줄이 국내에서 가장 자주 온다. 공공·대기업 수탁 개발에서는 산출물 목록이 계약에 포함되고, 그 목록이 표준을 참조하는 경우가 많다. 그때 "우리는 이렇게 해 왔습니다" 는 통하지 않는다.
마지막 줄은 조용하지만 누적된다. 모듈 7 레슨 9의 버스 팩터가 문서 형식 쪽에서 나타나는 모습이다 — 형식이 제각각이면 읽는 법 자체를 배워야 한다.
표준이 해결하는 세 가지 문제
1. 공통 언어(Common Vocabulary)
"테스트 케이스"라는 단어 하나도 조직마다 다르게 쓰일 수 있다. 표준은 용어를 명확히 정의해서, 서로 다른 조직 사람들이 같은 단어를 같은 의미로 쓰게 만든다. ISTQB 용어집(이 강의 전체에서 참고 자료로 계속 인용해온 것)도 이런 표준화 노력의 일부다.
실제로 뜻이 갈리는 말들이 있다. 아래는 조직 간 회의에서 매번 되묻게 되는 것들이다.
| 용어 | 어떤 조직에서는 | 다른 조직에서는 |
|---|---|---|
| 테스트 케이스 | 절차 한 단위(한 줄) | 시나리오 전체(여러 단계) |
| 회귀 테스트 | 전체 재실행 | 영향 범위만 재실행 |
| 스모크 테스트 | 배포 직후 핵심 흐름 | 빌드가 켜지는지만 확인 |
| 통합 테스트 | 모듈 간 연결 확인 | 외부 시스템 연동 확인 |
| 인수 테스트 | 고객이 하는 최종 확인 | QA가 하는 요구 충족 확인 |
| 테스트 완료 | 케이스 전부 실행 | 결함 0건 |
마지막 줄이 가장 위험하다. "테스트 완료" 를 서로 다르게 이해한 채 계약하면, 검수 단계에서 분쟁이 된다. 한쪽은 실행을 끝냈다고 보고 다른 쪽은 결함이 남았으니 미완이라고 본다.
그래서 표준의 가장 실용적인 쓸모가 여기 있다 — 분쟁이 날 만한 말에 출처를 붙일 수 있다. "저희 기준" 이 아니라 "29119 정의" 라고 하면 논쟁이 짧아진다.
2. 감사 가능성(Auditability)
"이 소프트웨어가 충분히 테스트됐다"는 걸 제3자(고객, 규제기관, 감사자)에게 증명해야 하는 상황이 있다. 표준화된 형식의 문서는 감사자가 "이 프로세스를 제대로 따랐는지" 확인하기 쉽게 만든다 — 감사자마다 익숙한 형식이 다르면 검토 자체가 오래 걸린다.
감사에서 실제로 묻는 것은 생각보다 단순하다. 네 가지다.
| 묻는 것 | 무엇을 본다 |
|---|---|
| 존재 | 계획서·설계서·결과 보고서가 있나 |
| 추적성 | 요구 → 케이스 → 결과 → 결함이 이어지나(모듈 7 레슨 1) |
| 승인 | 누가 언제 검토·승인했나 |
| 일관성 | 계획에 쓴 범위를 실제로 실행했나 |
네 번째가 가장 많이 걸린다. 계획서에 "성능 테스트 포함" 이라고 써 두고 실제로는 안 했으면, 그것이 문서와 실행의 불일치로 지적된다. 안 할 것은 계획서에서 빼거나 미실시 사유를 적는 것이 정답이다 (모듈 6 레슨 5의 "못 한 것을 적는다" 와 같은 원칙).
여기서 QA가 알아야 할 중요한 차이가 있다. "테스트를 했다" 와 "테스트를 했다는 것을 증명할 수 있다" 는 다르다. 규제 영역에서는 후자가 요구 사항이고, 증명은 기록의 형태로만 가능하다.
3. 규제 대응(Regulatory Compliance)
금융, 의료기기, 항공처럼 사람의 안전이나 자산에 직결되는 산업은 법적으로 특정 수준의 테스트 문서화를 요구하는 경우가 많다. 표준을 따르면 "우리가 임의로 만든 프로세스"가 아니라 "국제적으로 합의된 프로세스를 따랐다"는 근거를 댈 수 있다.
국내에서 실제로 마주치는 규제·표준을 영역별로 정리하면 이렇다. 이름을 알아 두면 공고와 계약 문서를 읽을 수 있다.
| 영역 | 관련 규제·표준 |
|---|---|
| 의료기기 | 의료기기법·GMP, IEC 62304(의료기기 소프트웨어 생명주기) |
| 금융 | 전자금융감독규정, 망분리·접근통제 요구 |
| 자동차 | ISO 26262(기능안전), ASPICE |
| 철도 | EN 50128 |
| 항공 | DO-178C |
| 공공·행정 | 정보시스템 감리, 산출물 목록이 계약에 포함 |
| 개인정보 | 개인정보보호법, ISMS-P |
29119는 이 목록의 대체가 아니라 바탕이다. 위 규제들은 "테스트를 체계적으로 하고 기록하라" 고 요구하는데, 그 체계의 구체적인 모양을 29119 같은 표준에서 가져다 쓴다. 스테이지 5·6의 해당 모듈에서 각각 자세히 다룬다.
ISO/IEC/IEEE 29119란
소프트웨어 테스트에 관한 국제 표준으로, ISO(국제표준화기구)·IEC(국제 전기기술위원회)·IEEE(전기전자기술자협회) 세 기관이 공동으로 제정했다. 이전까지 흩어져 있던 여러 테스트 표준(IEEE 829 등)을 통합해 만들어진, 현재 가장 폭넓게 참조되는 소프트웨어 테스트 표준이다.
이름이 긴 이유도 그래서다. 세 기관의 이름이 모두 붙어 있다 —
ISO/IEC/IEEE 29119. 실무에서는 29119 로만 부른다.
구성은 여러 부(Part)로 나뉘고, 각 부가 다른 것을 다룬다. 레슨 2에서 구조를 자세히 보지만, 지금은 네 부가 서로 다른 질문에 답한다는 것만 알아 두면 된다.
| 부 | 다루는 것 |
|---|---|
| Part 1 | 개념과 용어 |
| Part 2 | 프로세스 — 무엇을 어떤 순서로 |
| Part 3 | 문서 — 무엇을 어떤 형식으로 |
| Part 4 | 테스트 설계 기법 |
QA가 실무에서 가장 많이 펼치는 것은 Part 3이다. 산출물 형식을 요구받을 때 참조할 템플릿이 거기 있다.
표준을 둘러싼 논쟁도 알아 둘 만하다
29119는 무조건적인 합의 사항이 아니다. 2014년 제정 당시, 맥락 중심 테스팅(Context-Driven Testing) 진영에서 공개적인 반대가 있었다. 주요 비판은 셋이었다.
| 비판 | 요지 |
|---|---|
| 문서 중심 | 테스트의 본질은 탐색과 학습인데 문서 산출을 중심에 둔다 |
| 획일성 | 다양한 맥락의 팀에 한 가지 틀을 강요할 수 있다 |
| 표준의 권위 | "표준" 이라는 이름이 대안을 억누른다 |
이 비판을 아는 것이 QA에게 실질적으로 도움이 된다. 표준을 맹신하지 않으면서도 쓸 수 있게 되기 때문이다. 모듈 5에서 배운 탐색적 테스팅은 29119의 문서 체계와 충돌하지 않는다 — 다만 탐색의 가치를 문서로 증명하기 어렵다는 긴장이 있고, 그 긴장을 다루는 것이 실무다.
실용적인 결론은 이렇다. 규제·계약이 요구하면 표준을 따르고, 그렇지 않으면 필요한 부분만 가져온다. 표준 자체가 그것을 허용한다.
테일러링 — 표준이 스스로 허용하는 재단
표준을 따르는 것과 무조건 좋은 것은 다르다
표준을 도입한다고 결함이 저절로 줄어들지는 않는다. 표준은 "무엇을, 어떤 형식으로 문서화할지"에 대한 합의일 뿐이지, 테스트 자체를 더 잘하게 만드는 마법이 아니다. 오히려 규모가 작고 빠르게 움직이는 팀에게 표준의 전체 문서 체계를 그대로 강제하면 불필요한 오버헤드가 될 수 있다 — 표준은 필요한 만큼 선택적으로 적용하는 것이 현실적인 접근이다.
그리고 이것은 편법이 아니다. 29119 자체가 테일러링(tailoring), 즉 조직 맥락에 맞게 재단해서 쓰는 것을 명시적으로 허용한다. 중요한 것은 재단했다는 사실과 그 근거를 적어 두는 것이다.
| 재단 방식 | 예 |
|---|---|
| 문서를 합친다 | 테스트 계획서 + 설계서를 한 문서로 |
| 항목을 생략한다 | 해당 없는 절은 "해당 없음" 과 사유를 적는다 |
| 형식을 바꾼다 | 문서 대신 도구의 화면·링크로 대체 |
| 깊이를 조절한다 | 고위험 영역만 상세, 저위험은 요약 |
두 번째가 핵심 기술이다. 항목을 그냥 비우는 것과 "해당 없음, 사유: 외부 연동이 없음" 을 적는 것은 감사에서 완전히 다르게 읽힌다. 전자는 누락이고 후자는 판단이다.
세 번째도 현실적이다. 레슨 1의 테스트 관리 도구나 이슈 추적 도구에 이미 있는 정보를 문서로 다시 옮기지 않고 링크로 가리키는 것이 모듈 7 레슨 7의 원칙과도 맞는다. 다만 감사 대상이면 그 링크가 감사 시점에 접근 가능한지를 확인해 둔다.
표준을 처음 만났을 때 할 일
문서가 수백 쪽이라 막막하다. 순서가 있다.
- 요구받은 것이 정확히 무엇인지 확인한다 — 계약서·심사 기준에 적힌 문서 이름을 먼저 본다. 표준 전체가 아니다
- Part 3의 해당 템플릿만 펼친다 — 요구된 문서의 목차를 본다
- 우리가 이미 만들고 있는 것과 대조한다 — 대개 내용은 있고 형식만 다르다
- 빈 항목을 찾는다 — 그것이 실제 공백이다
- 재단 근거를 적는다 — 생략한 항목과 사유
3번에서 안심하게 되는 경우가 많다. 모듈 7을 익힌 팀이라면 계획· 케이스·실행 기록·결함 추적이 이미 있고, 표준이 요구하는 것의 상당 부분이 이름만 다른 상태다.
표준을 아는 것이 QA 개인에게 주는 것
조직 차원의 이유 외에, 개인에게 돌아오는 것도 분명하다.
| 얻는 것 | 어떻게 |
|---|---|
| 대화 자격 | 심사·검수 자리에 들어갈 수 있다 |
| 이직 폭 | 규제 산업은 이 요건이 필수에 가깝다 |
| 산출물 설계 | 처음부터 형식을 맞춰 쓰면 재작업이 없다 |
| 판단 근거 | "저희 기준" 이 아니라 출처 있는 기준으로 말한다 |
두 번째가 커리어 관점에서 크다. 금융·의료·자동차·공공은 인력 수요가 꾸준하고 경력 단절에 덜 민감한 영역인데, 공고에 거의 항상 표준·문서화 요건이 적힌다. 반대로 그 요건이 없으면 지원 자체가 걸러진다.
사례 — 납품 검수에서 반려된 산출물
공공 사업에 테스트 산출물을 납품했다가 반려된 기록이다. 테스트는 충실히 했고 결함도 잘 잡았는데, 검수에서 세 가지가 지적됐다.
| 지적 | 실제 상황 |
|---|---|
| 테스트 계획서에 종료 조건이 없다 | 종료 판단은 했지만 문서에 안 적었다 |
| 요구사항과 케이스의 추적표가 없다 | 추적은 도구 안에 있었지만 제출 산출물에 없었다 |
| 미실시 항목의 사유가 없다 | 성능 테스트를 안 했는데 계획서에는 포함돼 있었다 |
세 지적 모두 "일을 안 했다" 가 아니라 "기록이 없다" 였다. 보완에 2주가 걸렸고, 그 2주는 새로 테스트한 시간이 아니라 이미 한 일을 적는 시간이었다.
두 번째 지적이 특히 아까운 경우다. 추적 정보가 도구 안에 이미 있었는데 제출 형식으로 뽑아내지 않은 것이다. 처음부터 형식을 알았다면 버튼 몇 번으로 끝났을 일이었다.
그 뒤 팀이 바꾼 것은 둘이다.
- 계획서 템플릿에 종료 조건·추적표·미실시 사유 칸을 고정으로 넣었다
- 착수 시점에 검수 기준을 받아 형식을 먼저 맞췄다
두 번째가 더 큰 변화였다. 끝에 형식을 맞추는 것과 처음부터 맞춰 쓰는 것의 비용 차이가 몇 배다. 그리고 이 교훈은 규제 산업이 아니어도 적용 된다 — 레슨 6에서 산출물 템플릿을 볼 때 이 관점으로 보면 된다.
실무에서 왜 필요한가
규제 산업 QA 채용공고에서 "ISO 29119 이해" 또는 "테스트 문서화 표준 경험"을 요구하는 이유가 여기 있다. 표준을 몰라도 테스트 자체는 할 수 있지만, 표준화된 문서를 요구하는 고객사나 규제기관과 협업할 때는 표준의 언어를 알아야 대화가 가능하다. 특히 의료기기(스테이지 6 부록)처럼 규제가 법적으로 강제되는 영역에서는 표준 이해가 선택이 아니라 필수에 가깝다.
산출물을 나중에 맞추면 비용이 몇 배다
이 레슨의 가장 실용적인 함의다. 테스트는 잘했는데 형식이 안 맞아서 다시 쓰는 일이 실제로 흔하다. 그리고 그 작업은 새로 알아낸 것이 하나도 없는 순수한 손실이다.
| 언제 형식을 맞추나 | 비용 |
|---|---|
| 착수 시점 | 템플릿을 쓰기만 하면 된다 |
| 진행 중 | 일부 재작성 |
| 검수·심사 직전 | 전면 재작성 + 일정 지연 |
그래서 표준을 아는 QA가 하는 가장 값진 일은 착수 때 "제출 산출물 목록과 형식" 을 먼저 받아 오는 것이다. 질문 하나로 2주를 아낄 수 있다.
표준은 QA의 발언에 출처를 준다
모듈 6 레슨 3에서 "사실로 말한다" 를 다뤘다. 표준은 그 사실에 출처를 붙여 준다.
"테스트 완료의 기준을 정해야 합니다. 29119에서도 종료 조건을 계획 단계 산출물로 규정하고 있고, 지금은 그 기준이 없어서 완료 판정이 매번 달라집니다."
"제 생각에는" 과 비교하면 무게가 다르다. 특히 의사결정자가 QA의 영역을 잘 모를 때 출처가 있는 주장이 통한다.
반대 방향의 주의 — 표준을 방패로 쓰지 않는다
같은 힘이 반대로 쓰일 위험도 있다. "표준에 있으니까 해야 한다" 로 불필요한 문서를 늘리는 것이다. 그러면 모듈 7 레슨 6에서 본 "문서화를 위한 문서화" 가 되고, 팀은 표준 자체를 적대하게 된다.
판단 기준은 하나다 — 이 문서가 누군가의 결정이나 증명에 쓰이나. 쓰이지 않는 문서는 표준에 있어도 재단 대상이다.
채용시장에서의 위치
표준 지식은 일반 공고에서는 가점, 규제 산업 공고에서는 필수다. 그래서 지원 가능한 범위를 넓히는 효과가 분명하다.
| 질문 | 약한 답 | 강한 답 |
|---|---|---|
| "ISO 29119 아세요?" | "테스트 표준입니다" | "Part 2가 프로세스, Part 3가 문서 템플릿입니다. 실무에서는 Part 3을 가장 많이 씁니다" |
| "표준을 전부 따라야 하나요?" | "따르는 게 좋습니다" | "테일러링이 허용됩니다. 생략한 항목과 사유를 적는 것이 핵심입니다" |
| "감사·검수를 겪어 보셨어요?" | "자료를 제출했습니다" | "착수 때 제출 산출물 목록과 형식을 먼저 받아 재작업을 없앴습니다" |
| "표준의 한계는요?" | "번거롭습니다" | "문서 중심이라는 비판이 있습니다. 탐색적 테스팅의 가치를 문서로 증명하기 어렵다는 긴장이 실재합니다" |
| "작은 팀에도 필요할까요?" | "필요합니다" | "용어 정의와 종료 조건만 가져와도 효과가 있습니다. 전체 문서 체계는 과합니다" |
세 번째가 가장 변별력이 크다. 검수를 당해 본 사람과 대비해 본 사람의 차이가 거기서 드러난다. 착수 시점에 형식을 받아 오는 습관은 실제로 겪어 본 사람만 말한다.
네 번째도 좋은 답이다. 표준의 한계를 말할 수 있으면 맹신하지 않고 쓰는 사람으로 읽힌다. 모듈 5의 탐색적 테스팅과 함께 이해하고 있다는 신호이기도 하다.
공고 표현으로는 "ISO 29119", "테스트 문서화 표준", "품질 시스템 대응", "감리·심사 대응", "IEC 62304", "ISO 26262" 가 이 레슨 및 이어지는 레슨들에 걸린다.