문제해결관리, 변경요청 관리에서 긴급절차는 어떻게 정의

ASPICE 심사(특히 SUP.9 문제 해결 관리)에서 "긴급 시 조치(Urgency/Emergency Action)" 절차는 심사원이 협력사의 **'위기 대응 성숙도'**를 판단하는 아주 중요한 척도입니다.

단순히 "빨리 고친다"라고 쓰면 100% 지적을 받습니다. 심사원들이 합격점을 주는 기준과 지적을 하는 기준을 명확히 나누어 정리해 드릴게요.

---

1. 지적을 받는 수준 (Bad Case)

"문제가 발생하면 즉시 담당자에게 보고하고, 긴급 회의를 거쳐 최우선으로 수정하여 배포한다."

• 왜 지적받나? * 객관적 기준 부재: 무엇이 '긴급'인지 기준이 없습니다. (누구에겐 긴급인데 누구에겐 아닐 수 있음)
  • 프로세스 무시: 긴급하다고 해서 ASPICE의 기본인 검증(V-Model)을 건너뛰어도 되는지 명시되지 않았습니다.
  • 추적성 유실: 긴급 수정 후 나중에 정식 프로세스로 어떻게 되돌릴(Normalizing) 것인지에 대한 계획이 없습니다.

---

2. 지적을 안 받는 수준 (Good Case)

심사원은 **'긴급 상황에서도 통제력을 유지하는가'**를 봅니다. 다음 4가지 요소가 포함되어야 합니다.

① 긴급 상황의 명확한 정의 (Criteria)

• 작성 내용: "OEM 라인 중단 위험(Line-off), 실차 주행 중 안전 문제 발생, 양산 릴리즈 24시간 전 발견된 치명적 결함" 등 수치와 상황을 명시합니다.

② 'Fast-Track' 절차의 구체화

• 작성 내용: 긴급 시에는 일부 단계를 생략하거나 사후 승인할 수 있다는 점을 명시하되, 최소한의 필수 단계는 남겨둬야 합니다.
  • 예: "긴급 시에는 동료 검토(Peer Review)를 생략할 수 있으나, 최소한의 단독 단위 테스트(Unit Test) 결과 없이는 배포할 수 없다."

③ 임시 조치 vs 영구 조치 구분

• 작성 내용: "현장 대응을 위한 임시 패치(Workaround)를 먼저 제공한 후, 5일 이내에 정식 변경 관리 프로세스(SUP.10)를 통해 영구 수정본을 배포한다."

④ 사후 보고 및 분석 (Root Cause Analysis)

• 작성 내용: "긴급 조치 완료 후 72시간 이내에 문제 해결 위원회(CCB 등)를 소집하여 근본 원인을 분석하고 산출물을 업데이트한다."

---

3. 심사 대응을 위한 체크리스트 (Table)

심사원이 "이 절차가 실효성이 있나요?"라고 물었을 때, 아래 표의 내용이 문서에 있다면 지적을 피할 수 있습니다.

 

💡 심사원을 방어하는 '결정적 한 마디'

심사 때 이렇게 말씀하시면 아주 좋습니다.

"저희는 리소스 효율을 위해 평소에는 정석 프로세스를 따르지만, **리스크 기반 접근(Risk-based Approach)**에 따라 긴급 상황 시에만 가동되는 별도의 Fast-Track 절차를 운영하고 있습니다. 이는 단순히 단계를 건너뛰는 것이 아니라, 사후에 반드시 정식 프로세스로 소급 적용(Back-filling)하여 데이터의 일관성을 맞추도록 설계되었습니다."

결론적으로, "어떻게 빨리 하느냐"보다 **"빨리 하느라 놓친 것들을 나중에 어떻게 메꾸느냐"**가 계획서에 들어가 있으면 지적을 받지 않습니다.