IEEE 829·1008·730 — 29119에 흡수된 구 표준 통역하기

개념

폐지된 표준을 왜 지금 배우는가

레슨 1에서 29119를 소개하며 한 줄이 지나갔다 — "이전까지 흩어져 있던 여러 테스트 표준(IEEE 829 등)을 통합해 만들어진" 표준이라고. 이 레슨은 그 한 줄을 펼쳐낸 것이다.

다만 목적이 표준의 역사 감상은 아니다. 훨씬 실용적인 이유가 있다.

현장에서 이 번호들을 아직도 만나기 때문이다.

• 회사 위키에 10년 전 누군가가 올려둔 테스트 계획서 템플릿 의 머리말에 "IEEE 829 기준"이라고 적혀 있다
• 공공기관·SI 프로젝트의 제안요청서(RFP) 와 계약 산출물 목록에 "IEEE 829에 준하는 테스트 문서 일체"라는 문구가 그대로 박혀 있다
• 품질 매뉴얼의 문서 번호 체계가 TP / TDS / TCS / TPS / TIR 처럼 옛 서식의 약어를 그대로 쓰고 있다
• 사수가 "이건 SQA 계획서(730)에 들어갈 내용이지, 테스트 계획서가 아니야"라고 말한다

이때 필요한 능력은 옛 표준을 암기하는 것이 아니라 통역 이다. 눈앞의 옛 번호를 보고 "지금 기준으로는 29119의 어디에 해당하는가", "이 요구는 우리가 이미 만들고 있는 문서로 충족되는가"를 판단할 수 있으면 된다. 실제로 대부분의 경우, 이름만 바꿔 이미 만들고 있는 문서다.

29119 이전의 풍경 — 표준이 흩어져 있던 시절

29119가 나오기 전에도 테스트 관련 표준은 있었다. 문제는 한 기관이 여러 표준을 따로따로 냈다는 점 이었다. 문서 서식은 이 표준, 단위 테스트는 저 표준, 품질보증 계획은 또 다른 표준 식이었다.

표를 보면 알 수 있듯이, 이 표준들은 서로 경쟁하는 관계가 아니라 관심사가 달라서 따로 존재했다. 문제는 조직이 이 중 여러 개를 동시에 참조해야 했다는 점이다. 문서 서식은 829를 보고, 단위 테스트 절차는 1008을 보고, 그 둘을 아우르는 계획은 730을 보는 식이면, 같은 개념을 부르는 이름이 문서마다 달라지는 일이 생긴다. "테스트 항목", "테스트 대상", "시험 단위"가 사실 같은 것을 가리키는데 출처가 달라 용어가 갈리는 상황을 떠올리면 된다. 레슨 1에서 표준의 첫 번째 가치로 공통 언어 를 꼽았는데, 정작 표준들 사이에서 그 공통 언어가 흔들렸던 셈이다.

각각은 잘 만들어졌지만, 서로 용어가 미묘하게 다르고 프로세스와 문서의 연결이 느슨했다. 레슨 6에서 본 "계획서 → 설계 명세 → 케이스 명세 → 실행 → 완료 보고서" 처럼 하나의 이야기로 이어지는 그림이 없었던 것이다. 29119가 프로세스(Part 2)와 문서(Part 3)를 같은 시리즈 안에 나란히 놓은 것이 가장 큰 변화라고 이해하면 된다.

IEEE 829 — 테스트 문서화 표준

이 레슨에서 가장 자주 마주칠 번호다. 정식 명칭은 소프트웨어·시스템 테스트 문서화(Test Documentation) 에 관한 표준으로, "테스트를 하면 어떤 문서를 남기고 그 문서에는 어떤 항목이 들어가야 하는가"를 정의했다.

가장 널리 인용되는 것은 다음 문서 세트다. 사내 템플릿에서 이 이름들을 보면 거의 확실히 IEEE 829 계열이다.

이후 개정판에서는 계획과 보고서를 마스터 수준(프로젝트 전체)과 레벨 수준(단위·통합·시스템 등 각 테스트 레벨)으로 나누는 등 구성이 달라졌다. 어느 판을 기준으로 쓰인 템플릿인지에 따라 문서 목록이 조금씩 다르므로, 정확한 목록과 조항은 반드시 원문(또는 IEEE 공식 페이지)에서 확인 하고 단정하지 않는 습관이 필요하다.

29119-3과의 대응 — 이름이 바뀌었을 뿐이다

레슨 6에서 하나의 쿠폰 기능을 계획서부터 완료 보고서까지 따라가 봤다. 그때 만든 문서들이 IEEE 829의 어느 서식에 해당하는지 보면, 이 표준이 왜 "흡수됐다"고 표현되는지 한눈에 들어온다.

핵심은 이것이다. 서식의 이름과 묶음 단위는 바뀌었지만, "무엇을 남겨야 하는가"라는 질문의 답은 거의 그대로다. 계획을 남기고, 무엇을 왜 테스트할지 남기고, 실제 실행 기록을 남기고, 이상 현상을 남기고, 마지막에 판단 근거를 남긴다. 표준이 바뀌어도 이 다섯 가지는 사라지지 않는다.

한 가지 차이는 짚어둘 만하다. IEEE 829는 이름 그대로 문서 서식 에 집중했고, 그 문서를 만들어내는 프로세스는 다른 표준에 있었다. 29119는 프로세스(Part 2)와 문서(Part 3)를 한 시리즈 안에 두고 서로를 참조하게 만들었다. 레슨 4·5에서 배운 프로세스 단계와 레슨 6의 문서가 자연스럽게 이어졌던 이유가 이것이다.

IEEE 1008 — 단위 테스팅 표준

IEEE 1008은 단위 테스팅(Software Unit Testing) 을 다룬 표준이다. 단위 테스트를 계획하고, 대상 단위를 정하고, 테스트를 설계·실행하고, 완료 여부를 판정하는 단계를 정의했다.

지금 시점에서 이 표준이 흥미로운 이유는, 스테이지 3의 모듈 10(단위·통합 테스트)에서 배우게 될 내용이 표준 문서로는 이렇게 정리돼 있었다 는 사실 때문이다. "단위를 어디까지로 볼 것인가", "무엇을 완료로 볼 것인가" 같은 질문은 새로 생긴 고민이 아니라 오래전부터 표준이 붙잡고 있던 문제였다.

29119 체계에서는 이 내용이 특정 레벨 전용 표준으로 따로 있지 않다.

• 29119-2(프로세스) 가 테스트 레벨을 가리지 않는 공통 프로세스를 정의하고, 단위 테스트는 그 프로세스를 특정 레벨에 적용한 사례가 된다
• 29119-4(기법) 가 단위 테스트에서 자주 쓰는 설계 기법(모듈 3에서 배운 동등분할·경계값 분석, 그리고 구문·분기 커버리지 같은 구조 기반 기법)을 담는다

실무에서 IEEE 1008이라는 번호를 만나는 빈도는 829보다 훨씬 낮다. 단위 테스트는 대개 개발팀이 코드와 함께 관리하고, 별도 표준 문서로 규정하는 조직이 많지 않기 때문이다. 그래도 알아둘 값어치는 있다. 오래된 품질 매뉴얼이 "단위 테스트 완료 기준"을 따로 규정해 두었다면 그 뿌리가 여기일 가능성이 높고, 그럴 때 "지금은 29119-2의 테스트 프로세스를 단위 레벨에 적용한 것으로 본다"고 설명하면 대화가 정리된다.

다만 "1008의 어느 조항이 29119의 어느 조항으로 옮겨졌다"는 식의 1:1 이관표는 존재하지 않는다고 보는 편이 안전하다. 표준의 대체 관계는 범위 차원의 대체 이지 문장 단위 이식이 아니다. 대응 관계를 문서로 남겨야 하는 상황이라면 "개념적으로 29119-2/4가 해당 범위를 포괄한다"고 쓰고, 정확한 상태는 공식 페이지 확인을 권하는 것이 정직한 서술이다.

IEEE 730 — 소프트웨어 품질보증 계획(SQA Plan)

IEEE 730은 앞의 두 표준과 결이 다르다. 테스트 문서도, 특정 테스트 레벨도 아니고 소프트웨어 품질보증(SQA) 활동 전반의 계획 을 다룬다.

모듈 1에서 QA·QC·테스터의 역할을 구분했던 것을 떠올려 보자. 테스트는 품질 활동의 일부일 뿐이고, 그 위에는 프로세스 준수 확인·리뷰·감사·형상관리· 공급자 관리 같은 더 넓은 활동이 있다. 그 전체를 어떻게 계획할 것인지를 문서로 만든 것이 SQA 계획서 다.

관계를 그림으로 잡아두면 헷갈리지 않는다.

SQA 계획 (IEEE 730 계열)  ← 품질보증 활동 전체의 우산
├── 프로세스 준수 확인·감사
├── 리뷰·정적 테스트 (모듈 5)
├── 형상·변경 관리
└── 테스트 계획 (29119 / IEEE 829 계열)  ← 이 안의 한 갈래
    ├── 테스트 설계 명세
    ├── 테스트 케이스 명세
    └── 테스트 완료 보고서

여기서 자주 나오는 오해를 하나 정리해두자. IEEE 730은 29119가 대체한 표준이 아니다. 다루는 범위 자체가 다르기 때문이다 — 29119는 테스트 프로세스와 문서를 다루고, 730은 그보다 넓은 품질보증 활동의 계획을 다룬다. 그래서 옛 번호 대조표를 만들 때 730 칸에 "29119-x"를 적으면 오히려 틀린 통역이 된다. 이 표준의 현재 판과 상태는 IEEE 공식 페이지에서 직접 확인하는 것이 맞다.

실무 감각으로는 이렇게 기억하면 충분하다. 문서에 "SQA 계획"이라고 적혀 있으면, 그건 테스트 계획서보다 한 층 위의 문서이고 테스트 계획은 그 안의 한 절(節)로 들어간다.

폐지(Withdrawn)와 대체가 실제로 뜻하는 것

표준 문서에서 "withdrawn(폐지)", "superseded(대체됨)"라는 단어를 보면 "이제 쓰면 안 되는 것"으로 읽기 쉽다. 하지만 실무에서의 의미는 조금 다르다.

폐지는 "표준화 기구가 더 이상 이 문서를 유지·개정하지 않는다"는 뜻이다. 그 표준을 참조해 만들어진 기존 문서가 무효가 된다는 뜻이 아니고, 그 문서에 적힌 내용이 갑자기 틀린 내용이 된다는 뜻도 아니다. 실제로 IEEE 829가 정의한 문서 항목 대부분은 지금 봐도 타당하다.

그래서 다음 세 가지 상황을 구분해서 판단해야 한다.

첫 번째 칸이 특히 중요하다. QA가 "그 표준은 폐지됐는데요"라고 말해서 계약 산출물 목록이 바뀌지는 않는다. 그럴 때 할 수 있는 실용적인 대응은 대응표를 만들어 붙이는 것 이다. 계약이 요구하는 옛 문서 이름을 표지에 쓰고, 실제 내용은 팀이 이미 쓰는 29119 형식으로 채운 뒤, 어느 항목이 어느 요구를 충족하는지 매핑 표를 앞에 넣는다. 감사자와 발주처가 확인해야 하는 것은 "이름"이 아니라 "요구한 정보가 다 들어 있는가"이기 때문이다.

이건 모듈 7(레슨 1)에서 배운 트레이서빌리티 를 문서 서식 차원에 적용한 것이기도 하다. 요구 ↔ 산출물의 연결을 보여주면 이름이 달라도 검증이 가능해진다.

옛 번호를 현행으로 통역하는 대조표

마지막으로 한눈에 볼 수 있게 정리한다. 실무에서 옛 번호를 만났을 때 이 표만 떠올리면 대화를 시작할 수 있다.

표에서 얻어야 할 결론은 두 가지다. 첫째, IEEE 829와 IEEE 1008은 29119 쪽으로 읽으면 된다. 둘째, 모든 옛 IEEE 번호가 29119로 흡수된 것은 아니다 — 730·1012처럼 애초에 다른 것을 다루는 표준을 억지로 29119에 매핑하면 오히려 틀린 통역이 된다.

사례 — 두 벌 쓰기를 막은 매핑 표 한 장

공공 사업 RFP의 산출물 목록에 옛 이름이 그대로 적혀 있었다.

요구 산출물 (RFP 발췌)
  1. 시험 계획서 (IEEE 829 기준)
  2. 시험 설계 명세서
  3. 시험 사례 명세서
  4. 시험 절차 명세서
  5. 시험 로그
  6. 시험 인시던트 리포트
  7. 시험 요약 보고서

팀의 첫 반응은 "우리 양식을 버리고 일곱 개를 새로 만들어야 하나" 였다. 실제로는 이미 있는 것이 대부분이었고, QA가 한 일은 매핑 표 한 장이었다.

발주처가 요구한 일곱 개 중 새로 만든 문서는 하나도 없었다. 중단·재개 기준 두 줄을 더하고, 도구에서 네 개를 내보내고, 매핑 표를 표지 다음에 붙인 것이 전부였다.

여기서 효과가 두 가지 있었다. 첫째, 산출물 협의가 한 번에 끝났다. 발주처가 확인하고 싶은 것은 요구한 정보가 들어 있는지였고, 매핑 표가 그것을 보여 줬다. 둘째, 2번 항목이 쟁점이 되지 않았다. 설계 명세를 계획서에 합쳐 둔 상태였는데, 합쳤다는 사실을 명시했기 때문에 "누락" 으로 읽히지 않았다(레슨 6의 문서 줄이기 + 레슨 1의 재단 표시).

반대 경우도 기록해 둘 만하다. 같은 사업의 다른 수행사는 일곱 개를 새로 작성했다. 내용은 우리와 비슷했지만 기존 도구의 기록과 두 벌이 되어, 프로젝트 중간에 숫자가 어긋나는 문제가 생겼다. 레슨 6에서 본 문서 간 불일치가 문서를 두 벌 만든 데서 발생한 것이다.

실무에서 왜 필요한가

이 지식이 실제로 쓰이는 순간은 대체로 셋 중 하나다.

첫째, 오래된 사내 문서를 물려받았을 때. 입사 후 "기존 테스트 계획서 참고해서 이번 프로젝트 것 써주세요"라는 요청을 받으면, 물려받은 문서가 옛 서식인 경우가 많다. 이때 "이건 낡았으니 다 갈아엎자"는 대응은 대개 환영받지 못한다. 문서에 담긴 항목이 지금 우리가 쓰는 형식의 어디에 해당하는지 통역해 보이고, 빠진 항목만 보완하는 쪽이 현실적이다.

둘째, 공공·SI 제안과 계약 단계. RFP의 산출물 목록에 옛 표준 이름이 그대로 들어 있는 경우가 흔하다. 이때 QA가 "요구된 산출물 8종을 우리 29119 기반 문서로 이렇게 충족한다"는 매핑을 만들어 제출하면, 산출물 협의가 훨씬 빨리 끝난다. 반대로 이 통역을 못 하면, 같은 내용을 이름만 바꿔 두 벌 쓰는 낭비가 생긴다.

셋째, 감사·심사 대응. 감사자가 옛 번호로 질문할 수 있다. "테스트 인시던트 리포트는 어디 있습니까?" 같은 질문에 "저희는 결함 관리 도구의 이 필드로 관리하고, 완료 보고서 3장에 요약돼 있습니다"라고 즉시 안내할 수 있으면 심사가 매끄럽게 진행된다.

세 상황 모두 공통점이 있다. 문서를 새로 만드는 일이 아니라, 이미 있는 것을 상대의 언어로 설명하는 일이다. 이 레슨의 가치는 정확히 거기에 있다.

채용시장에서의 위치

옛 표준 번호 자체가 채용공고에 요구 사항으로 적히는 일은 드물다. 대신 이 지식은 면접에서 "레거시 환경을 다룰 줄 아는 사람" 이라는 인상을 만드는 데 쓰인다.

금융·공공·국방·SI 도메인의 QA 포지션은 대부분 오래된 문서 자산 위에서 일한다. "기존 산출물 체계가 IEEE 829 기반인데 29119로 어떻게 옮기시겠어요" 같은 질문은, 표준 암기가 아니라 이관 전략과 이해관계자 설득 능력 을 보는 질문이다. 좋은 답은 대체로 이런 모양이다 — 항목 단위 대응표를 먼저 만들고, 계약·규정이 강제하는 부분은 유지하고, 새로 시작하는 프로젝트부터 새 체계를 적용하며 점진적으로 옮긴다.

반대로 위험한 답도 분명하다. "폐지된 표준이니 전부 29119로 바꿔야 합니다"는 계약 리스크를 모르는 답으로 들린다. 표준 지식보다 판단의 결 을 보여주는 것이 이 주제의 채용 가치다.

실습 과제

과제 1 — 옛 서식 목록을 29119로 통역하기 (10분)

가상의 RFP 산출물 목록을 받았다고 가정한다.

[요구 산출물 — IEEE 829에 준함]
1. Test Plan
2. Test Design Specification
3. Test Case Specification
4. Test Log
5. Test Incident Report
6. Test Summary Report

각 항목이 레슨 6에서 만든 문서 체계의 무엇에 해당하는지 옆에 적고, 하나라도 "우리 형식에는 대응하는 문서가 없다"고 판단되는 항목이 있는지 확인한다.

과제 2 — SQA 계획서와 테스트 계획서 가르기 (8분)

다음 다섯 항목을 SQA 계획서(IEEE 730 결) 에 들어갈 것과 테스트 계획서(29119 결) 에 들어갈 것으로 나눈다.

1. 코드 리뷰를 어떤 기준으로 언제 수행할 것인가
2. 쿠폰 할인 기능의 테스트 종료 기준
3. 형상관리 도구와 브랜치 정책
4. 시스템 테스트에 투입할 인원과 일정
5. 공급업체가 납품한 컴포넌트의 품질 확인 절차

과제 3 — 계약이 옛 표준을 지정했을 때의 대응 문안 쓰기 (7분)

계약서에 "테스트 산출물은 IEEE 829를 따른다"고 적혀 있는데, 우리 팀은 이미 29119 기반 템플릿으로 일하고 있는 상황이다. 발주처에 보낼 한 문단짜리 설명을 직접 써본다. 다음 세 요소를 반드시 포함한다.

• 계약이 요구한 문서 목록을 어떤 문서로 충족할 것인지
• 이름이 다른 이유를 어떻게 설명할 것인지
• 무엇을 첨부해 확인 가능하게 만들 것인지

자가 체크리스트

• 폐지된 옛 표준을 알아야 하는 실용적 이유를 세 가지 상황으로 설명할 수 있다
• IEEE 829가 정의한 주요 문서들의 이름과 역할을 말할 수 있다
• IEEE 829의 각 문서가 29119-3의 어느 산출물에 대응하는지 표로 설명할 수 있다
• IEEE 1008이 다룬 범위가 29119에서 어디로 흡수됐는지 설명할 수 있다
• IEEE 730이 테스트 표준이 아니라 품질보증 계획 표준이라는 점을 설명할 수 있다
• SQA 계획과 테스트 계획의 포함 관계를 그림으로 그릴 수 있다
• "폐지됨"이 기존 문서를 무효로 만들지 않는다는 것을 설명할 수 있다
• 계약이 옛 표준 판을 지정한 경우의 현실적 대응을 말할 수 있다
• 모든 옛 IEEE 번호가 29119로 대체된 것은 아니라는 점을 예를 들어 설명할 수 있다
• 옛 번호 → 현행 대조표를 보지 않고 대략 재구성할 수 있다

흔한 실수

• "폐지된 표준이니 무시해도 된다"고 단정한다. 계약서·RFP·품질 매뉴얼이 그 번호를 지정하고 있으면 여전히 구속력이 있다. 표준화 기구의 유지 여부와 계약의 효력은 별개다.
• 모든 옛 IEEE 번호를 29119에 억지로 매핑한다. IEEE 730(SQA 계획)이나 1012(V&V)처럼 애초에 다른 범위를 다루는 표준을 29119 파트에 대응시키면 틀린 통역이 된다.
• 문서 서식 이름을 바꾸는 것을 개선이라고 착각한다. 레슨 6의 마지막 경고와 같은 맥락이다 — 형식은 그릇이고, 실제 가치는 그 안의 테스트 설계와 기록의 품질에서 나온다.
• 옛 서식과 새 서식으로 같은 내용을 두 벌 만든다. 대응표 한 장이면 해결되는 일을 문서 중복으로 푸는 것은 순수한 낭비이고, 두 문서가 어긋나기 시작하면 오히려 신뢰를 떨어뜨린다.
• 개정 이력이나 조항 번호를 기억에 의존해 단정한다. 표준은 판마다 문서 구성이 달라진다. 계약·감사처럼 정확성이 중요한 자리에서는 반드시 공식 페이지나 원문에서 해당 판을 확인하고 인용한다.
• IEEE 829를 "옛날 방식"으로만 보고 배울 것이 없다고 여긴다. 그 문서 목록은 "테스트에서 무엇을 남겨야 하는가"에 대한 오래 검증된 체크리스트다. 이름이 바뀌었을 뿐 질문은 그대로다.

참고 자료

• ISO/IEC/IEEE 29119-1 공식 페이지 — 시리즈 전체의 범위와 다른 표준과의 관계
• ISO/IEC/IEEE 29119-3 공식 페이지 — 옛 IEEE 829 문서 서식이 대응되는 현행 문서화 표준
• IEEE Standards Association — IEEE 829·1008·730·1012의 현재 상태(활성·폐지·대체)를 번호로 직접 검색해 확인할 수 있는 공식 창구
• ISO/IEC/IEEE 29119 워킹그룹 공식 사이트 — 시리즈 구성과 배경 설명
• ISTQB Glossary — 테스트 계획·인시던트 리포트 등 옛 서식 용어의 현행 정의 대조

이 커리큘럼 안에서

• 모듈 8 레슨 1 — 표준이 필요한 이유. 계약·심사가 형식을 요구하는 배경
• 모듈 8 레슨 2 — 29119 구조. 옛 번호를 통역해 보낼 목적지
• 모듈 8 레슨 3~5 — 조직·관리·동적 프로세스. IEEE 1008이 흡수된 자리
• 모듈 8 레슨 6 — Part 3 산출물. 옛 서식과 대응시킬 현행 문서
• 모듈 7 레슨 1 — 추적성과 도구 내보내기. 매핑 표의 실제 수단
• 모듈 7 레슨 7 — 문서 수명. 옛 템플릿을 [보관]으로 분리하는 방법
• 모듈 6 레슨 5 — 지표. 두 벌 쓰기가 숫자를 어긋나게 만드는 지점

한 줄 정리 — 옛 표준 번호를 만났을 때 할 일은 새로 만드는 것이 아니라 통역하는 것이다. IEEE 829와 1008은 29119 쪽으로 읽으면 되고, 730·1012처럼 애초에 다른 것을 다루는 표준은 억지로 매핑하지 않는다. 계약이 옛 이름을 지정했으면 그 이름을 표지에 쓰고 매핑 표를 붙인다 — 확인하려는 것은 이름이 아니라 요구한 정보가 들어 있는가다.

모듈 8 마무리 — 이 모듈은 표준을 "더 잘하는 법이 아니라 서로 통하는 법" 으로 다뤘다. 왜 필요한지(레슨 1), 어디에 무엇이 있는지(레슨 2), 세 계층의 프로세스(레슨 3~5), 산출물의 실물(레슨 6), 그리고 옛 번호의 통역(레슨 7). 전체를 꿰는 결론은 하나다 — 모듈 4·6·7을 익힌 팀은 이미 내용을 갖고 있고, 표준이 요구하는 것은 대부분 형식과 기록이다. 그래서 착수 시점에 형식을 먼저 확인하는 질문 하나가 이 모듈에서 가장 값진 실무 습관이다.