네, ASPICE 관점에서는 일반적으로 베이스라인 이후에 산출물이 변경되었다면, 그 변경은 반드시 형상변경관리(Change Control) 절차를 거쳐야 합니다.
즉 질문하신 상황이라면:
- 시스템 요구사항 명세서(SyRS) v1.2를 기준으로 Baseline 설정 완료
- 이후 문서가 v1.3으로 변경됨
→ 이 경우에는 원칙적으로:
- 변경 요청(CR/ECR 등) 등록
- 영향도 분석(Impact Analysis) 수행
- CCB(Change Control Board) 승인
- 승인 후 문서 수정
- 새 버전(v1.3) 발행 및 필요 시 재베이스라인
이 흐름이 있어야 ASPICE의 형상관리/변경관리 기대사항을 만족한다고 보는 게 일반적입니다.
다만 중요한 건 ASPICE가 “반드시 CCB 회의를 해야 한다”라고 고정적으로 요구하는 건 아니라는 점입니다.
ASPICE에서 핵심은:
- Baseline 이후 변경이 통제되었는가
- 변경 이력이 추적 가능한가
- 승인 권한이 정의되어 있는가
- 영향 분석이 있었는가
- 누가 승인했는가가 남아 있는가
입니다.
즉 CCB는 그걸 구현하는 대표적인 방법이지, “회의 자체”가 필수 요구는 아닙니다.
예를 들면 조직 프로세스에 따라:
- Jira Workflow 승인
- 전자결재
- Change Tool 승인
- 메일 승인
- 간소화된 Change Authority 승인
등으로도 가능합니다.
ASPICE 관점에서 연결되는 주요 프로세스는 보통:
- SUP.8 Configuration Management
- 베이스라인 관리
- 형상항목 변경 통제
- SUP.10 Change Request Management
- 변경 요청 등록/분석/승인/추적
입니다.
특히 SUP.8 BP5/BP6 계열에서:
baseline 이후 변경은 통제되어야 한다
라는 취지의 기대사항이 핵심입니다.
실무적으로 심사에서 많이 보는 포인트는 아래입니다.
반대로 예외도 있습니다.
예를 들어 조직 프로세스에서:
- “Draft 상태는 baseline 아님”
- “Baseline 이전 버전 변경은 자유 수정 가능”
- “오탈자 수준은 Minor Change로 간소 승인 가능”
같은 규칙이 정의되어 있다면 괜찮습니다.
하지만 이미 공식 Baseline으로 선언된 시점 이후라면,
ASPICE에서는 일반적으로 “통제된 변경” 증적을 기대합니다.
한 줄로 정리하면:
Baseline 이후 v1.3으로 변경되었다면, ASPICE 만족을 위해서는 최소한 변경요청 + 승인(형상변경통제) 증적은 있어야 하고, CCB 회의는 대표적인 방법이지만 반드시 회의 형태일 필요는 없습니다.
아, 그 상황이면 얘기가 조금 달라집니다.
그 경우는 ASPICE 심사에서도 꽤 자주 나오는 현실적인 케이스예요.
즉 상황을 정리하면:
- SyRS v1.2를 Baseline 설정
- 하지만 당시 상태는 Accepted 아님
- Draft / In Review 상태
- 프로젝트 일정이나 인터페이스 동결 등의 이유로
“완전 승인 전이지만 일단 기준점(Baseline)” 필요 - 이후 리뷰 반영해서 v1.3으로 변경
이런 흐름이죠.
이 경우 핵심은:
“그 Baseline이 어떤 성격의 Baseline이었는가?”
입니다.
ASPICE에서는 사실 “Baseline = 반드시 최종 승인본”이라고까지 강제하지는 않습니다.
실무에서는 아래처럼 많이 운영합니다.
즉 “완전히 Accepted는 아니지만 현 시점 frozen 기준”으로 baseline 잡는 건 가능합니다.
다만 중요한 건 프로세스/증적입니다.
예를 들어 심사에서 아래처럼 설명 가능해야 합니다.
“v1.2는 Draft 상태였으나 프로젝트 마일스톤상 임시 Baseline으로 설정하였다. 이후 Review 결과 반영을 위해 v1.3으로 업데이트하였다.”
이 흐름 자체는 크게 이상하지 않습니다.
그럼 v1.2 → v1.3 변경 시 CR/CCB가 반드시 필요하냐?
여기서 포인트는 조직 프로세스 정의입니다.
케이스 1) “Baseline 이후 모든 변경은 Change Control 대상”
이렇게 프로세스 정의되어 있으면:
- Draft baseline이라도
- 변경 요청
- 영향분석
- 승인
필요합니다.
이 경우 CCB 간소화는 가능해도,
“통제된 변경” 증적은 있어야 합니다.
케이스 2) “Draft Baseline은 경량 변경 허용”
실무에서 꽤 많습니다.
예를 들면 프로세스에:
- Draft Baseline 상태에서는 리뷰 반영 변경 가능
- Formal Acceptance 이후부터 strict change control 적용
- Minor review comment는 CR 생략 가능
같은 예외 규칙이 정의되어 있으면,
v1.2 → v1.3에서 별도 정식 CR 없이 운영 가능할 수도 있습니다.
ASPICE는 이런 “조직 규칙이 명확히 정의되어 있고 일관되게 운영되는가”를 더 중요하게 봅니다.
심사원이 실제로 보는 건 보통 이겁니다.
좋은 케이스
- “v1.2는 Interim Baseline”
- “Review pending 상태 명시”
- “Review comment 기반 수정”
- “변경이력 존재”
- “승인 흐름 존재”
→ 충분히 설명 가능
위험한 케이스
- Baseline인데 아무 통제 없음
- 누가 왜 바꿨는지 없음
- 변경 이력 없음
- 리뷰 결과 추적 안 됨
- 승인 책임 불명확
→ SUP.8/SUP.10 약점 지적 가능
실무적으로는 이런 식으로 많이 방어합니다.
- Baseline Type 구분
- Preliminary Baseline
- Interim Baseline
- Formal Baseline
- 문서 상태 명시
- Draft Baseline
- Review Baseline
- Review Comment 기반 변경 관리
- CR 대신 Review Log 활용
한 줄로 정리하면:
Draft/In Review 상태에서 불가피하게 Baseline을 잡은 것은 ASPICE상 충분히 가능한 시나리오입니다. 다만 이후 변경(v1.3)이 “통제된 변경”이었다는 증적은 필요하며, 반드시 정식 CCB/CR만이 답은 아니고 조직 프로세스에 정의된 경량 변경관리 방식으로도 충분히 설명 가능합니다.
근데 이런 규칙이, 형상관리 계획서나 절차 같은데 아직 명시가 안되어 있다면 어떡해?
그럼 ASPICE 심사에서는 솔직히 조금 위험한 상태입니다.
왜냐하면 ASPICE는 결국:
“우리가 이렇게 운영했습니다”
보다
“그 운영 방식이 프로세스로 정의되어 있었습니까?”
를 더 중요하게 보기 때문입니다.
즉 지금 상황은:
- 실무적으로는 충분히 이해 가능한 상황
- 하지만 규정/절차에 명시가 없음
- 그러면 심사 시 “임의 운영(ad-hoc)”처럼 보일 가능성 있음
이라는 게 핵심입니다.
다만 이게 곧바로 Major NC급 문제라는 뜻은 아닙니다.
심사에서는 보통 아래처럼 판단합니다.
지금 상황에서는 현실적으로 3가지 방어 포인트가 있습니다.
1. “Interim Baseline” 개념을 사후라도 정의
가장 현실적입니다.
예를 들면 형상관리계획서(CMP)나 절차서에:
- 프로젝트 일정상 필요 시 Draft 상태에서도 Interim Baseline 가능
그럼 냉정하게 말하면 ASPICE 관점에서는 “프로세스 미정의 상태에서 운영한 것”이 됩니다.
즉 심사원이 보면:
“왜 baseline 이후 변경을 CR 없이 했습니까?”
라고 물었을 때,
“실무적으로는 draft baseline이라서요”
라고 설명은 가능하지만,
심사원 입장에서는 바로 이어서:
“그 규칙이 어디 정의되어 있습니까?”
를 보게 됩니다.
그리고 현재 문서에 없다면,
엄밀히는 “정의되지 않은 예외 운영”으로 해석될 가능성이 있습니다.
다만 여기서 중요한 건:
이미 발생한 상황을 어떻게 ‘합리적으로 방어’하느냐
입니다.
실무 심사에서는 완벽무결보다도:
- 합리적 운영인가
- 통제 의도가 있었는가
- 추적 가능한가
- 개선 활동을 하는가
를 많이 봅니다.
지금 상황에서 가장 현실적인 대응은 보통 아래 순서입니다.
1. 절차/계획서에 규칙 추가 (가장 중요)
가능하면 ASAP로 아래 같은 내용을 넣는 게 좋습니다.
예시:
- Draft/In Review 상태의 형상항목은 Interim Baseline으로 관리 가능
- Interim Baseline 이후 리뷰 결과 반영 변경은 경량 변경관리 적용 가능
- Formal Accepted Baseline 이후에는 정식 CR/CCB 적용
이렇게 정의를 추가하면:
“당시 명확한 정의는 부족했지만, 현재 프로세스를 보완하였다”
라는 개선 흐름이 만들어집니다.
ASPICE에서는 이런 CAPA/Process Improvement를 긍정적으로 보는 편입니다.
2. v1.2 baseline 성격을 명확히 남기기
이게 중요합니다.
예를 들면:
- Baseline Log
- Release Note
- Configuration Record
- Review Record
등에:
“v1.2는 프로젝트 일정상 Interim Baseline으로 설정되었으며 Review pending 상태임”
같은 흔적이 있으면 꽤 방어가 됩니다.
3. v1.3 변경이 “무통제 수정”은 아니었다는 증적 확보
CR이 없더라도 아래가 있으면 꽤 도움이 됩니다.
- Review Comment
- Peer Review 결과
- Jira ticket
- 변경 이력
- Git history
- 승인 메일
- 회의록
즉:
“완전 자유 수정이 아니라 리뷰 기반 controlled update였다”
를 보여주는 게 핵심입니다.
그리고 현실적으로 심사 결과는 보통 이렇게 갈 가능성이 큽니다.
중요한 건 ASPICE는 ISO처럼:
“문서에 한 줄 없었으니 실패”
이렇게만 보지는 않는다는 겁니다.
특히 숙련 심사원들은:
- 프로젝트 현실성
- 긴급 baseline 상황
- 고객 milestone 압박
이런 것도 이해합니다.
대신 싫어하는 건:
- 설명이 매번 바뀜
- 프로젝트마다 다름
- 누가 승인했는지 모름
- 변경 이유 없음
같은 “비체계성”입니다.
그래서 지금 상황에서 가장 좋은 전략은:
“당시 Interim 성격으로 운영했고, 이를 명확히 하기 위해 현재 CM 절차를 보완 중이며, 변경은 리뷰 기반으로 통제되었다”
라는 스토리로 정리하는 겁니다.
이 방향이면 ASPICE 심사에서 충분히 방어 가능한 편에 속합니다.
'ASPICE 기본 이론' 카테고리의 다른 글
| 고객 요구사양서, 승인도 파헤치기1 (0) | 2026.05.20 |
|---|---|
| 실무적으로 변경요청은 어떻게 이루어지는가? (0) | 2026.05.19 |
| SW, SYS 검증영역 병렬 진행 (0) | 2026.05.08 |
| MAN.3에 마일스톤별 소프트웨어 배포는 어떻게 정의? (0) | 2026.04.24 |
| MAN.3에 고객 마일스톤 별 목표는 어떻게 정의 (0) | 2026.04.23 |