MAN.3에 마일스톤별 소프트웨어 배포는 어떻게 정의?

심사원이 보고 싶은 것은 **"각 마일스톤에서 배포되는 SW가 정확히 어떤 사양(Spec)이고, 어떤 품질 기준을 통과한 물건인지"**에 대한 명확한 정의입니다. 이를 만족시키기 위해 프로젝트 계획서(또는 부속 릴리즈 계획서)에 포함되어야 할 핵심 수준은 다음과 같습니다.

---

1. 배포 대상의 구체적 정의 (Content Definition)

각 마일스톤(PROTO, M/CAR, P1 등)에서 배포될 SW의 **'실체'**를 정의해야 합니다.

• 기능 범위: 해당 배포본에 포함되는 요구사항 ID 리스트 또는 핵심 기능(Feature) 목록.
• HW 버전: 이 SW가 구동되는 타겟 보드의 버전(예: HW v1.0용인지 v2.1용인지).
• 변경 사항: 이전 배포 대비 추가된 기능이나 수정된 버그 리스트.

2. 마일스톤별 '종료 조건(Exit Criteria)'의 수치화

가장 중요한 부분입니다. 단순히 "테스트 완료"가 아니라, **"어느 정도 수준의 품질이어야 배포를 승인할 것인가"**에 대한 정량적 기준이 있어야 합니다.

• 테스트 커버리지: "단위 테스트 커버리지 100%, 통합 테스트 커버리지 80% 달성."
• 결함 상태: "치명적(Critical) 결함 0건, Major 결함은 우회 방법(Workaround)이 있는 경우에만 허용."
• Pass Rate: "시스템 테스트 통과율 95% 이상."

---

3. 배포 방식 및 절차 (Release Mechanism)

SW가 어떤 형상 관리(Configuration Management) 체계 하에서 만들어지고 전달되는지 기술해야 합니다.

• Baseline 정보: 해당 배포본을 구성하는 소스 코드, 설계서, 요구사항 명세서의 베이스라인 버전.
• 전달물(Deliverables): 실행 파일(.hex, .bin), 릴리즈 노트, 검증 보고서, 매뉴얼 등.
• 승인 절차: 누가 검토하고 누가 최종 릴리즈 사인을 하는지(예: QA 팀장의 최종 승인 필수).

4. 심사 대응용 '소프트웨어 배포 계획' 예시 테이블

계획서 내에 아래와 같은 수준의 요약표가 들어가면 심사원의 지적을 완벽히 방어할 수 있습니다.

심사원을 만족시키는 핵심 팁

1. "정의"와 "기록"의 일치: 계획서에 "치명적 결함 0건이 배포 조건"이라고 정의했다면, 실제 배포 시점에 발행된 **릴리즈 노트(Release Note)**에도 "결함 0건 확인됨"이라는 기록이 있어야 합니다.
2. QA의 역할 명시: 배포 정의가 되어 있어도 QA가 이를 점검(Auditing)하고 승인한다는 프로세스가 빠져 있으면 다시 지적받을 수 있습니다.
3. 예외 상황 처리: 만약 품질 기준을 달성하지 못했는데도 고객 일정 때문에 긴급히 배포해야 한다면, 어떤 '예외 승인(Deviation)' 절차를 거치는지도 계획서에 한 줄 언급해 두는 것이 좋습니다.

결론적으로, 심사원은 **"당신들이 이번 달에 배포하는 SW가 '충분히 좋은 상태'라는 것을 무엇을 근거로 판단하는가?"**에 대한 공식적인 기준(Plan)을 보고 싶어 하는 것입니다

 

근데 심사원의 지적을 완벽히 방어할 수 있는 테이블을 작성해줬는데, 거기 내용을 보니까 소프트웨어 배포 버전까지 나왔는데, 프로젝트 초기에 미리 배포할 소프트웨어의 버전을 정할 수가 있는가?

 

날카로운 질문입니다! 프로젝트 초기에 마지막 소수점 자리까지 완벽한 버전을 확정하는 것은 당연히 불가능합니다. 개발 과정에서 버그 수정이나 사양 변경으로 인해 버전은 계속 바뀌니까요.

심사원도 "무조건 이 버전 번호로 배포해!"라고 강요하는 게 아닙니다. 심사원이 보고 싶은 것은 **'버전 번호 그 자체'가 아니라 '버전을 부여하는 규칙(Naming Convention)과 마일스톤과의 매핑'**입니다.

따라서 계획서에는 다음과 같은 방식으로 **'예상 버전'**과 **'명명 규칙'**을 작성해야 지적을 피할 수 있습니다.

---

1. '확정 버전'이 아닌 '예상 버전(Target Version)'으로 작성

계획서에는 구체적인 빌드 번호 대신, 큰 흐름을 보여주는 메이저 버전을 기입합니다.

• 작성 예시:
  • PROTO: v0.1.x (Initial Functional Release)
  • M/CAR: v0.5.x (Integration Release)
  • SOP: v1.0.0 (Production Release)
• 심사원 대응: "이 버전은 프로젝트 계획 수립 시점의 Target Version이며, 실제 배포 시에는 형상 관리 절차에 따라 최종 버전이 부여됩니다."라고 명시하면 됩니다.

2. 버전 명명 규칙(Versioning Convention)의 정의

버전을 어떻게 매길 것인지에 대한 **'정의'**가 계획서(또는 형상 관리 계획서)에 포함되어 있어야 합니다. 심사원은 이걸 더 중요하게 봅니다.

[예시: Semantic Versioning] v(Major).(Minor).(Patch)

• Major: 하드웨어 변경 또는 대규모 사양 변경 시 업데이트
• Minor: 마일스톤 내 기능 추가 시 업데이트
• Patch: 단순 버그 수정 및 형상 유지보수 시 업데이트

3. 마일스톤과 배포 정의의 '연결' (핵심)

심사원이 지적한 "배포에 대한 정의"를 만족시키려면 버전 숫자보다 **"이번 배포의 성격"**을 규정하는 것이 핵심입니다.

• PROTO 배포 정의: "고객 요구사항 v1.0 중 필수 A기능이 포함된 '기능 검증용' 배포"
• M/CAR 배포 정의: "실차 통신 및 진단 기능이 포함된 '통합 검증용' 배포"

이렇게 정의를 내리면, 나중에 실제 배포된 버전이 v0.1.2이든 v0.1.5이든 심사원은 **"계획서에 정의된 PROTO 목표(기능 검증)를 달성했는가?"**를 확인하며 만족하게 됩니다.

---

💡 정리하자면: 계획서에 써야 할 수준

1. 버전 번호: v0.x (Draft), v1.x (Final) 수준의 가이드라인만 제시.
2. 명명 규칙: 버전을 어떤 논리로 부여할 것인지에 대한 Rule 제시.
3. 배포 성격: 각 마일스톤에서 배포될 소프트웨어가 **어떤 사양(Baseline)**을 담고 있는지에 대한 범위(Scope) 제시.

한 줄 조언: 계획서에 "PROTO 배포 버전은 v0.1.x 계열로 한다"라고 쓰고, 그 밑에 **"상세 버전은 형상 관리 시스템의 릴리즈 노트를 따른다"**는 문구를 한 줄 넣어주세요. 그러면 "정의가 확인되지 않는다"는 지적에서 완벽히 해방될 수 있습니다.

 

지금 회사 내부적으로 사용하는 **SW 버전 명명 규칙(예: v1.0.0 등)**이 이미 정해져 있는가? 있다면 그 규칙을 계획서에 인용(Reference)하기만 해도 충분합니다.