(A-SPICE 10회차) SUP.10: "이거 살짝만 바꿔주세요"의 무서움?!

🔄 10회차: "이거 살짝만 바꿔주세요"의 무서움?!

SUP.10 – 변경 요청 관리, EO를 무시하면 벌어지는 일들

“고객이 버튼 위치를 바꿔달래요~”
“요구사항 3줄만 바꿨는데요?”
🤯 그런데 왜 프로젝트가 터질 것 같은 느낌이 들죠?

---

🎯 오늘의 주제: SUP.10 – Change Request Management

A-SPICE의 SUP.10은 변경 요청을 공식적으로 접수하고, 평가하고, 반영하고, 추적하는 프로세스입니다.

즉, "뭐든 쉽게 바꾸지 말고, 체계적으로 바꿔라!"는 말이죠.

변경은 개발의 일부입니다.
그런데 관리 안 하면 좀비처럼 프로젝트를 물어뜯습니다 🧟‍♂️

---

📦 EO(Engineering Order)란?

자동차 개발에서 고객사(=OEM)는
변경 요청을 EO(Engineering Order)라는 형식으로 전달합니다.

📌 EO란?

"이 시스템의 어떤 부분을 어떻게 바꿔달라"는 공식 문서
설계 변경, 기능 수정, 사양 변경 등 모두 EO로 처리됨

🧷 EO와 SUP.10의 연결

EO 항목	SUP.10 단계
변경 요청 접수	변경 요청 등록 (Change Request 생성)
영향 평가	영향도 분석 (비용, 일정, 품질 등)
승인 / 거절	변경 승인 여부 결정
변경 수행	실제 설계/코드 변경 및 검증
상태 추적	변경 내역 기록 및 종료 처리

---

🧨 개발업체들이 SUP.10에서 흔히 취약한 부분

1. ✋ EO를 메일로 받고 말로 처리한다?!

“그거 그냥 메일로 왔던 건데요…”
→ 변경 이력 추적 불가!
→ 누가, 언제, 왜 바꿨는지 모름!

2. 📊 영향 분석 없이 무조건 “네!”

“변경이요? 네~ 해드릴게요~”
→ 일정 지연, 품질 저하, 리스크 폭탄!
 고객 만족 → 단기적, 조직 피해 → 장기적

3. 📁 변경 후 문서, 테스트 반영 안 됨

→ 설계서/테스트 케이스/릴리즈 노트는 여전히 옛날 기준
→ “테스트는 왜 실패했죠?” → 바뀐 걸 테스트 안 했어요…

4. 📉 변경 후 피드백 없이 ‘일단 끝냄’

→ Closed 처리만 하고 Lesson Learned 없음
→ 똑같은 실수, 3개월 뒤에 다시 등장!

---

🛠️ 실무에서는 이렇게 대응하자!

✅ 변경 요청 프로세스 예시

1. 📨 EO 접수
   → Change Request 문서로 등록
2. 📚 영향도 분석
   → “이 변경이 S/W, 테스트, H/W, 비용에 어떤 영향을 주지?”
3. 📋 승인 프로세스
   → 고객 승인 + 내부 검토 후 작업 시작
4. 🔄 변경 수행
   → 설계/코드 수정 + 관련 문서/TC 업데이트
5. 📎 변경 내역 기록
   → 형상관리 도구에 반영 + 추적 ID 남김

---

🎯 A-SPICE 평가 포인트는?

• 변경 요청이 체계적으로 등록 → 평가 → 추적 → 종료됐는가?
• EO가 변경관리 체계에 잘 반영됐는가?
• 변경의 영향도가 분석되고, 적절히 관리됐는가?

즉, "그냥 바꿨어요!"는 절대 A-SPICE에서 통하지 않습니다!

---

✅ 실천 미션: 우리 팀의 변경 관리 자가 진단

• EO 요청이 수기로 처리되지 않고 Change Request로 관리되는가?
• 영향도 분석 문서가 존재하고, 승인자가 명확한가?
• 변경 요청 이력이 형상관리 도구나 시스템에서 추적 가능한가?
• 변경으로 인해 수정된 산출물(설계, 테스트 등)이 최신 상태인가?

---

🧠 한 줄 요약!

변경 요청은 언제나 온다.
그러나 SUP.10 없이는 ‘관리된 개발’이 아닌 ‘즉흥적인 대응’일 뿐!

---

📌 다음 회차 예고

11회차에서는
" SYS.2 요구사항 분석"을를 주제로
고객 요구를 해석하는 과정에서의 문제, 시스템 요구사항과 소프트웨어 요구사항의 경계  
를 함께 고민해봅니다.

요구사항 분석이 잘되어야 개발이 잘된다 ! 🧠🦺