(A-SPICE 9회차) SUP.9: 이슈 폭탄 해체반!

💣 9회차: 이슈 폭탄 해체반!

SUP.9 문제 해결 관리 vs MAN.5 리스크 관리, 뭐가 다를까?

“이거… 누가 고쳤지?”
“그 버그는 왜 또 나타났어!?”
→ 팀에 이런 말이 자주 들린다면?
🧨 이슈 관리 체계부터 다시 세워야 할 때입니다!

---

🎯 오늘의 주제: SUP.9 – Problem Resolution Management (문제 해결 관리)

A-SPICE에서 말하는 SUP.9는
프로젝트 중 생겨나는 ‘문제’를
정리 → 추적 → 해결 → 기록까지 관리하는 프로세스입니다.

즉, 이슈를 "덮지 말고, 제대로 마무리하자!" 라는 거죠.

---

🤔 잠깐! MAN.5(리스크 관리)랑 뭐가 달라요?

좋은 질문이에요! 이 둘은 많이 헷갈리지만 완전히 다른 개념입니다.

항목	SUP.9 문제 해결	MAN.5 리스크 관리
시점	문제가 발생한 후	문제가 생기기 전에
성격	현재 벌어진 ‘이슈’를 다룸	미래에 생길 가능성 있는 ‘위험’을 다룸
예시	빌드 실패, 고객 불만, 테스트 실패	일정 지연 가능성, 인력 부족 위험, 요구 변경 가능성
목표	문제를 정확하게 해결하고 기록	리스크를 미리 예측하고 방지

⚠️ 요약하면:
SUP.9는 "이미 터진 문제"에 대한 소방관 역할
MAN.5는 "터지기 전에 막는" 예방 의사 역할

---

🛠️ SUP.9의 문제 해결 프로세스 (아주 현실적으로!)

1. 🔍 문제 인식
   → “테스트 케이스 TC-042가 실패했습니다!”
2. 🧾 등록 및 식별
   → 이슈 트래커에 등록: ID 042-BUG, 발생일, 담당자
3. 🔄 분석 및 대응방안 수립
   → 원인 분석: 인터페이스 시그널 값 오류
   → 조치 계획: 소스 수정 및 재검토
4. ✅ 해결 및 확인
   → 수정 완료 → 재테스트 통과 확인
5. 📜 종결 및 기록 보관
   → 상태 “Closed”로 변경, 근거 문서 첨부

---

🧰 실무에서 많이 쓰는 이슈 추적 도구

도구	특징
JIRA	이슈-에픽-릴리즈까지 유기적으로 연결 가능
Redmine	오픈소스 기반, 커스터마이징 유리
Bugzilla	단순하고 강력한 버그 추적기
GitHub Issues	깃 기반 개발 프로젝트에 적합

💡 어떤 도구든 중요한 건 "과정이 남고, 이력이 관리되느냐"입니다!

---

💼 예를 들어 볼까요?

🧑‍💻 개발자 A: 테스트 시 HMI 버튼 작동 안 됨 발견
→ SUP.9 등록: Issue#HMI-103
→ 원인: CAN ID 매칭 오류
→ 해결: 소스 수정 → 코드 리뷰 → 통합 테스트 통과
→ 문서화: 해결 경과, 영향 없음 확인 후 Closed

이제 이슈#HMI-103은 과거의 역사가 됩니다.
필요할 땐 누구든 찾아볼 수 있죠!

---

🔥 왜 SUP.9가 중요한가요?

• 고객이 “문제 있다!” 했을 때 “우리는 이렇게 조치했습니다!” 문서화 가능
• 반복 문제 방지! 똑같은 실수, 다시 안 하려면 이력 관리 필수
• 팀 내부 지식 공유! 문제 해결 과정은 곧 팀의 자산
• A-SPICE 평가 시 필수 항목! 문제는 있었냐보다 어떻게 해결했냐가 더 중요!

---

✅ 실천 미션: 우리 팀의 문제 관리 성숙도 점검하기

• 문제가 발생하면 항상 이슈 등록하고 있나요?
• 해결 내역이 명확히 기록되나요?
• 유사 문제 발생 시 과거 이슈에서 힌트를 얻을 수 있나요?
• 담당자가 바뀌어도 이슈 이력이 남아있나요?

---

🧠 한 줄 요약!

SUP.9는 개발자들의 문제 해결 내역을 ‘전설처럼 남기는 프로세스’입니다.
리스크(MAN.5)는 미래 걱정, 문제(SUP.9)는 현실 대응!
둘 다 필요하지만, 절대 혼동하지 마세요!

---

📌 다음 회차 예고

10회차에서는
"SUP.10 – 변경 요청 관리 (Change Request Management)"
“이거 조금만 바꿔주세요…”라는 말 한마디가
어떤 파장을 일으킬 수 있는지 알려드립니다!

변경은 자유지만, 무계획 변경은 팀을 무너뜨립니다!
A-SPICE의 SUP.10으로 안정적인 변화 관리, 함께 배워요 😊