(기능안전 21강) 검토(Review) vs 확인(Verification) vs 검증(Validation)의 차이점 완전정복!

✅ 21강: 검토(Review) vs 확인(Verification) vs 검증(Validation)의 차이점 완전정복!

안녕하세요, 여러분!
이번 강의 주제는 기능안전 실무자라면 절대 헷갈려선 안 되는 세 가지 개념!
바로 검토(Review), 확인(Verification), 검증(Validation)입니다.

 

그리고 ISO 26262에서만 등장하는 그 녀석!
Confirmation Review도 빼놓을 수 없겠죠?
그럼 오늘도 기능안전 한 입 배워볼까요? 😎

---

🧠 기본 개념 다시 잡기! (정의부터 딱 잡자)

구분	정의	질문으로 기억하기
Review (검토)	개발 산출물이 적절하고, 기준을 충족했는지 전문가가 정성적으로 검토	“우리가 제대로 만들고 있나?”
Verification (확인)	요구사항에 맞게 제품이나 소프트웨어가 정확히 구현되었는지 검토	“우리가 만든 게 설계대로 맞나?”
Validation (검증)	사용자의 니즈를 제품이 정량적으로 충족하는지 확인	“이거 진짜 사용자가 원하는 거 맞아?”
Confirmation Review (확증 검토)	ISO 26262에서 요구하는 독립성 있는 전문가의 독립적인 검토	“기능안전 절차가 제대로 수행됐는지 독립적으로 봤어?”

---

🧩 실무에서 헷갈리는 이유?

• 같은 문서를 보고도 어떤 활동인지는 보는 시점과 목적에 따라 달라요!
• 예를 들어, 소프트웨어 요구사항 명세서:
  • 작성할 때 → Review
  • 작성 후 요구사항 매핑 확인 → Verification
  • 테스트 결과와 사용자 니즈 비교 → Validation
  • 기능안전 팀이 독립적으로 체크 → Confirmation Review

---

🔧 Confirmation Review란?

ISO 26262만의 기능안전 보증 장치!

항목	설명
목적	기능안전 표준과 절차가 적절히 적용되었는지를 독립적으로 검토
수행 시기	각 주요 개발 단계 이후 (예: Item 정의, TSR 작성, SW 설계 등)
요구되는 독립성 수준	ASIL에 따라 다르며, ASIL D는 반드시 독립적인 부서/사람 필요
수행 주체	기능안전 관리자 or 독립된 기능안전 책임자
결과	기능안전 심사서(FSC)로 남김 – ISO 26262 감사 때 주요 문서!

🎯 예시 상황

HW 설계 완료 후 Review 진행
→ Verification 완료
→ 기능안전 팀에서 설계 절차 준수 여부를 Confirmation Review
→ 문제가 없다는 문서화까지 완료!

---

🎭 직무별 R&R 요약 정리

역할	Review	Verification	Validation	Confirmation Review
개발자/평가자	✅	✅	✳️	❌
품질 관리자(QA)	✅	✅	✅	❌
기능안전 책임자	✳️	✳️	✳️	✅
독립 검토자	❌	❌	❌	✅

※ ✳️는 참여할 수 있으나 주체는 아님

---

📝 실무 꿀팁: 이럴 때 구분 포인트

1. 작성 직후 내부 검토? → Review
2. 요구사항과 일치 확인? → Verification
3. 사용자 시나리오 테스트? → Validation
4. 기능안전 책임자가 독립 검토? → Confirmation Review

---

📌 정리하면?

• Review: 내부에서 잘 하고 있는지 점검
• Verification: 설계대로 만들었는지 확인
• Validation: 사용자가 원하는 제품인지 확인
• Confirmation Review: 기능안전 절차 준수했는지 독립적으로 재검토

모두 다르지만 서로 연계돼 있고, 각각의 목적이 분명합니다!

---

🧭 다음 강의 예고

22강에서는?
🔥 "ASIL별 테스트 전략 – 품질과 안전을 함께 잡는 법"을 다룹니다!

• 테스트도 ASIL 따라 다르다구요?
• 시험 전략 수립은 어떻게?
• 실무에서 자주 빠뜨리는 테스트 포인트는?

다음 시간도 놓치지 마세요!
그럼 오늘도 안전한 하루 되세요! 🧡

---