R&D 실패 분석과 근본 원인 체크리스트: 프로토타입 결함을 의심 원인에서 검증 원인으로 좁히는 법

빠른 결론

R&D 실패 분석은 “왜 고장 났는가”를 빨리 단정하는 문서가 아니라, 프로토타입 결함을 더 퍼지지 않게 막고, 증거를 보존한 뒤, 의심 원인을 재현 시험과 물증으로 검증 원인까지 좁히는 절차입니다. NASA는 root cause를 단순히 무엇이 일어났는지와 구분해 “왜”를 추적하는 구조화된 과정으로 설명하고[S1], ASQ도 RCA를 문제 원인을 드러내는 도구와 기법의 묶음으로 봅니다[S2]. 따라서 좋은 체크리스트는 결함 설명, 임시 봉쇄, 5 Why와 fishbone, 증거 보존, 재현 조건, suspected cause와 verified cause의 구분, corrective action, fix verification, lessons learned를 한 흐름으로 묶어야 합니다.

프로토타입 결함이 발견되면 회의실의 첫 반응은 보통 빠릅니다. “센서가 문제다”, “조립 공차가 벌어졌다”, “펌웨어 예외 처리 같다”처럼 그럴듯한 원인이 바로 나옵니다. 그러나 빠른 설명은 좋은 출발점일 뿐, 아직 원인이 아닙니다. 원인으로 인정하려면 같은 조건에서 다시 결함을 만들 수 있거나, 결함을 만든 물리적·전기적·소프트웨어적 경로가 증거로 연결되어야 하며, 조치를 넣은 뒤 같은 결함이 사라지는지도 확인해야 합니다.

이 글은 위험 등록부, QMS 부적합 처리, design freeze와 change control, 사용자 테스트, 필드 테스트 데이터 수집, 최종보고서 증거 패키지를 다시 설명하지 않습니다. 여기서 다루는 범위는 더 좁습니다. 연구실이나 파일럿 제작 단계에서 프로토타입 결함이 보였을 때, 결함을 어떻게 설명하고, 무엇을 격리하고, 어떤 증거를 손대지 않고 남기며, 5 Why와 fishbone을 어디까지 쓰고, suspected cause를 verified cause로 바꾸기 위해 어떤 재현 시험과 검증 조치를 해야 하는지에 집중합니다.

R&D 실패 분석은 결함 설명을 좁게 쓰는 데서 시작합니다

실패 분석의 첫 줄은 “프로토타입이 불안정하다”가 아니라 “무엇이, 언제, 어떤 조건에서, 기대와 어떻게 달랐는가”여야 합니다. 예를 들어 “v0.6 센서 모듈이 45도 고온 챔버에서 8시간 구동 후 3회 중 2회 통신 패킷을 잃었고, 상온 bench test에서는 재현되지 않았다”처럼 씁니다. 이 문장은 이미 결함 대상, 버전, 환경, 시간, 반복 횟수, 기대와의 차이를 담고 있습니다. DOE RCA 문서는 조사 과정에서 발생한 일을 단계별로 outline하고 원치 않은 조건·상황·행동을 식별하라고 설명합니다[S3].

나쁜 실패 설명은 원인을 미리 섞습니다. “고온 때문에 통신 오류가 났다”는 아직 증거가 부족하면 실패 설명이 아니라 가설입니다. “고온 조건에서 통신 오류가 관찰되었다”가 더 안전합니다. 같은 이유로 “작업자 실수”, “부품 불량”, “알고리즘 한계” 같은 단어도 초반에는 조심해야 합니다. 원인 후보가 문장 안에 들어가면 팀은 그 후보를 증명하려고 움직이고, 반대 증거를 놓치기 쉽습니다.

결함 설명에는 정상 조건과 비정상 조건을 함께 둡니다. 결함이 난 샘플과 나지 않은 샘플, 통과한 온도와 실패한 온도, 이전 버전과 현재 버전, 다른 fixture와 같은 fixture, 같은 펌웨어와 다른 하드웨어처럼 비교 기준이 있어야 합니다. NIST의 DOE 소개는 실험 설계가 통계적 실험의 개념과 절차를 다루며, 원인 확인에는 조건을 의도적으로 나누어 보는 사고가 필요하다는 점을 뒷받침합니다[S8]. 실패 설명을 잘 쓰면 뒤의 재현 시험 설계가 절반은 끝납니다.

containment는 원인 해결이 아니라 결함 확산 방지입니다

결함이 보이면 가장 먼저 할 일은 고치는 것이 아니라 더 망가뜨리지 않는 것입니다. containment는 문제 샘플, 같은 lot, 같은 assembly, 같은 firmware build, 같은 시험 fixture, 같은 raw data 묶음을 임시로 묶어 두는 조치입니다. ISO 9001 Auditing Practices Group 자료는 부적합을 닫기 전 containment, correction, cause analysis, corrective action results를 검토하고 효과성의 객관적 증거를 확인해야 한다고 설명합니다[S5]. 이 관점은 초기 R&D 실패 분석에도 유용합니다.

containment 기록에는 세 가지가 필요합니다. 첫째, 무엇을 hold했는지입니다. 샘플 3개인지, 같은 lot 전체인지, 특정 firmware build인지, 특정 시험 결과만 보류했는지를 적습니다. 둘째, 무엇을 계속해도 되는지입니다. 모든 개발을 멈추면 일정만 잃고 원인 증거도 사라질 수 있습니다. 셋째, 누가 해제할 수 있는지입니다. 임시 봉쇄는 원인 검증 전까지의 안전장치이므로, 해제 기준 없이 “일단 보류”로만 남기면 다음 시험자가 같은 결함 조건을 다시 밟습니다.

containment에서 피해야 할 문장

“문제 샘플 제외 후 시험 계속”: 제외 기준과 같은 위험군 범위가 없습니다.

“펌웨어 수정 후 재시험”: 수정 전 증거 보존 여부와 수정 범위가 없습니다.

“작업자 재교육”: 결함 발생 경로가 작업 절차 때문인지 검증되지 않았습니다.

“해당 현상 재발 없음”: 어떤 조건을 얼마나 반복했는지 없습니다.

containment는 QMS의 공식 부적합 절차와 닮았지만, 이 글의 목적은 시스템 처분이 아닙니다. R&D 팀이 당장 다음 실험을 안전하게 진행하기 위해 문제 범위를 잠그는 것이 목적입니다. 공식 부적합 번호, 고객 통보, 릴리즈 보류 판단은 QMS 문서에서 다룰 일이고, 여기서는 원인 분석을 망치지 않는 최소 봉쇄만 다룹니다.

5 Why와 fishbone은 답을 내는 도구가 아니라 가설을 정리하는 도구입니다

5 Why는 단순해서 강력하지만, 단순해서 위험합니다. “왜?”를 다섯 번 묻는다고 반드시 root cause가 나오지는 않습니다. NASA RCA 자료도 보통 why 질문을 반복해 causal factor와 root cause chain을 찾는다고 설명하지만[S1], 그 과정은 증거와 연결되어야 합니다. ITRC 자료는 5 Whys가 문제를 구체적으로 적고 왜 그런지 반복해 묻는 방식이며, 여러 원인이 있을 때는 fishbone이 특히 도움이 된다고 설명합니다[S6].

프로토타입 결함에서는 5 Why를 한 줄로 밀고 가기보다 fishbone으로 원인 후보를 나누는 편이 안전합니다. 범주는 제품 구조, 부품·소재, 조립·공정, 시험 fixture, 측정 장비, 펌웨어·알고리즘, 환경 조건, 작업 절차, 데이터 처리처럼 잡을 수 있습니다. 예를 들어 통신 패킷 손실이라면 부품 온도 특성, 케이블 strain, connector 접촉, firmware timeout, 전원 noise, chamber 내부 위치, logging script 누락이 모두 후보가 될 수 있습니다.

원인 상태	의미	다음 행동
suspected cause	관찰과 경험상 그럴듯하지만 아직 증거가 부족한 후보	반대 조건, 재현 시험, 물증 수집 계획을 붙입니다
probable cause	일부 증거와 재현 단서가 있지만 다른 후보를 완전히 배제하지 못한 상태	경쟁 가설을 줄이고 추가 샘플 또는 조건으로 확인합니다
verified cause	결함을 만들고 제거하는 경로가 시험·물증·기록으로 확인된 원인	corrective action과 fix verification으로 넘어갑니다
contributing factor	단독 원인은 아니지만 결함 확률이나 영향을 키운 조건	재발 방지 조치 또는 검사 조건에 반영합니다

이 표가 중요한 이유는 회의에서 “원인”이라는 말을 너무 빨리 쓰지 않게 하기 위해서입니다. ASQ는 RCA가 여러 접근과 도구를 포함한다고 설명하며, 좋은 결과는 관련자가 함께 문제 원인을 찾을 때 더 좋아진다고 봅니다[S2]. 즉, 5 Why와 fishbone은 한 명의 직감이 아니라 여러 역할의 증거를 같은 판 위에 올리는 도구여야 합니다.

증거 보존은 사진보다 원본 조건을 남기는 일입니다

프로토타입 실패 분석에서 가장 흔한 실수는 고치면서 증거를 지우는 것입니다. connector를 다시 꽂고, firmware를 덮어 쓰고, fixture를 조정하고, raw log를 정리한 뒤에는 결함이 왜 생겼는지 더 이상 추적하기 어렵습니다. EASA의 root cause failure analysis 자료는 시각 검사와 사진 문서화, 관련 문서 검토, checklists, hypothesis testing의 중요성을 강조합니다[S7]. 사진은 시작일 뿐이고, 실제로는 원본 조건을 보존해야 합니다.

증거 보존 묶음은 최소 다섯 갈래로 나눕니다. 첫째, 물리 증거입니다. 실패 샘플, 파손 부위, connector, 케이블, fixture 접촉면, chamber 위치, 조립 사진을 남깁니다. 둘째, 전기·소프트웨어 증거입니다. firmware commit, build artifact, configuration, sensor calibration, power log, exception log, raw binary log를 보존합니다. 셋째, 시험 조건입니다. 온도, 습도, 전압, load, cycle, 반복 횟수, operator, fixture ID, measurement equipment를 적습니다. 넷째, 비교 샘플입니다. 실패 샘플만 남기지 말고 같은 조건에서 통과한 샘플도 같이 남깁니다. 다섯째, 조치 전후 기록입니다. 손대기 전 사진과 log가 없으면 fix 효과를 설명하기 어렵습니다.

결함 증거 보존 리스트

sample_state: 샘플 ID, lot, assembly revision, 사용 이력, 보관 상태

failure_context: 발생 시간, 시험 step, 환경 조건, 직전 조작, 반복 횟수

raw_evidence: 원본 log, 사진, 영상, 계측기 출력, chamber 기록, crash dump

comparison_set: 같은 조건의 pass 샘플, 이전 revision, 다른 fixture 결과

touch_log: 결함 발견 뒤 누가 무엇을 분해·수정·재시험했는지

증거 보존은 최종보고서 증거 패키지와 다릅니다. 최종보고서는 과제 종료 시점의 제출물 일치와 성과 연결을 봅니다. 여기서는 결함 원인을 지우지 않기 위한 원본 상태 보존이 핵심입니다. 따라서 보기 좋은 요약보다 수정 전 원본, 실패 조건, 비교 샘플의 보전성이 더 중요합니다.

재현 시험은 같은 실패를 만드는 조건과 만들지 않는 조건을 같이 찾습니다

failure reproduction은 “다시 실패했다”만 확인하는 일이 아닙니다. 같은 결함을 만드는 조건과 만들지 않는 조건을 동시에 찾는 일입니다. DoD reliability growth handbook은 reliability growth가 failure mode discovery, problem feedback, failure mode root cause analysis and proposed corrective action, approval and implementation의 feedback loop로 이루어진다고 설명합니다[S4]. 이 흐름에서 재현 시험은 원인 분석과 조치 검증 사이를 연결합니다.

재현 시험에는 baseline, trigger, contrast, stop rule이 있어야 합니다. baseline은 결함이 없던 조건입니다. trigger는 결함이 난 조건입니다. contrast는 원인 후보를 하나씩 바꾸는 조건입니다. stop rule은 샘플을 계속 손상시키지 않기 위한 중단 기준입니다. 예를 들어 “고온에서 통신 손실”이라면 상온·고온, fixture A·B, firmware v0.5·v0.6, cable 고정 전·후, 전원 noise injection 유무를 무작정 모두 섞지 말고 원인 후보별로 순서를 잡습니다.

재현 시험의 핵심은 한 번에 하나씩 바꾸는 것입니다. 여러 조건을 동시에 바꾸면 실패가 사라져도 무엇이 원인이었는지 모릅니다. 물론 실제 R&D 일정에서는 모든 조건을 완벽히 분리하기 어렵습니다. 그럴 때는 “이번 시험은 원인 확정이 아니라 후보 축소”라고 기록합니다. 결론의 강도를 시험 설계의 강도에 맞추는 것이 중요합니다.

suspected cause와 verified cause를 분리해야 시정조치가 맞아집니다

의심 원인을 검증 원인처럼 다루면 corrective action이 표면 처방으로 흐릅니다. “케이블 접촉 불량 같으니 케이블을 교체한다”는 repair일 수 있지만, root cause corrective action은 아닐 수 있습니다. 케이블이 왜 접촉 불량이 되었는지, 특정 fixture가 cable strain을 만들었는지, assembly instruction이 빠졌는지, connector 선택이 vibration 조건에 맞지 않았는지까지 봐야 합니다. NASA는 root cause를 what happened와 구분하고 recurrence를 막을 수 있는 why를 추적하는 취지로 설명합니다[S1].

검증 원인으로 승격하려면 세 가지 질문을 통과해야 합니다. 첫째, 그 원인을 넣으면 결함이 재현되는가. 둘째, 그 원인을 제거하면 결함이 사라지는가. 셋째, 다른 주요 후보가 같은 증거를 더 잘 설명하지는 않는가. 이 세 질문 중 하나라도 비어 있으면 probable cause 또는 contributing factor로 남기는 편이 안전합니다.

원인 승격 문장 예시

“고온 자체가 원인”이 아니라 “45도 조건에서 cable routing B가 connector latch에 지속 strain을 만들었고, 동일 샘플에서 routing B를 적용하면 3회 중 2회 packet loss가 재현되며, routing C로 변경하면 같은 firmware와 fixture에서 10회 반복 중 packet loss가 관찰되지 않았다. 따라서 verified cause는 고온 단독이 아니라 고온 조건에서 routing B가 만든 connector 접촉 안정성 저하로 본다”처럼 씁니다.

이 문장은 길지만 의사결정에는 더 안전합니다. 원인을 좁게 쓰면 조치도 좁게 설계됩니다. 고온 test 전체를 중단할 필요가 없고, firmware 전체를 다시 쓰지 않아도 되며, routing과 connector retention을 조치 대상으로 삼을 수 있습니다. 반대로 “고온 문제”라고만 쓰면 시험 조건을 줄이는 임시 처방으로 끝날 가능성이 큽니다.

corrective action은 repair, correction, recurrence prevention을 구분합니다

결함 샘플을 정상 상태로 되돌리는 것은 repair입니다. 이미 만든 샘플의 문제를 바로잡는 것은 correction입니다. 같은 실패가 다시 생기지 않도록 설계, 공정, fixture, firmware, 검사 기준을 바꾸는 것이 corrective action입니다. ISO APG 자료는 corrective action이 원인을 제거해 recurrence를 막아야 하고, 객관적 증거로 구현과 효과성을 보여야 한다고 설명합니다[S5]. 이 구분을 하지 않으면 “샘플 교체 완료”가 재발 방지처럼 기록됩니다.

R&D 단계의 corrective action은 지나치게 무거울 필요는 없습니다. 프로토타입 단계에서는 “다음 revision부터 connector latch clearance를 0.3mm 확보하고, assembly instruction에 cable routing 그림을 추가하며, 고온 8시간 후 packet loss 재현 시험을 release gate로 둔다” 정도가 충분할 수 있습니다. 중요한 것은 조치가 verified cause를 직접 겨냥해야 한다는 점입니다. 원인이 fixture alignment라면 firmware 예외 처리를 고치는 것은 우회 조치일 뿐입니다.

시정조치에는 owner, due date, affected scope, verification method가 붙어야 합니다. owner가 없으면 조치가 회의록에 남고, due date가 없으면 다음 build에 반영되지 않으며, affected scope가 없으면 이미 만든 샘플과 다음 revision의 경계가 흐려집니다. verification method가 없으면 조치가 들어간 뒤에도 효과를 말할 수 없습니다.

fix verification은 “좋아 보인다”가 아니라 실패 조건 재시험입니다

fix verification은 개선된 샘플이 일반 조건에서 잘 작동한다는 확인이 아닙니다. 결함을 만들었던 조건에서 다시 실패하지 않는지 보는 시험입니다. MIL-HDBK-189C는 redesign 뒤 failure sources의 detection이 redesign effort의 verification이 된다고 설명합니다[S4]. 즉, 고친 뒤에는 원래 실패가 났던 조건을 다시 통과해야 합니다.

fix verification 계획에는 네 가지를 적습니다. 첫째, 원래 failure trigger입니다. 둘째, 조치 후 변경점입니다. 셋째, 동일하게 유지한 조건입니다. 넷째, pass 기준과 관찰 기간입니다. 예를 들어 고온 8시간 조건에서 문제가 났다면, 조치 후에도 같은 chamber, 같은 fixture 또는 통제된 fixture 차이, 같은 firmware base, 같은 log capture 방식으로 시험해야 합니다. 다른 조건이 너무 많으면 pass가 조치 때문인지 조건 변경 때문인지 설명할 수 없습니다.

검증 결과가 애매하면 “완료”로 닫지 말고 제한 조건을 남깁니다. “routing C 적용 후 45도 8시간 조건에서는 재현되지 않았으나, vibration 동시 인가 조건은 아직 미시험”처럼 씁니다. 이것은 실패가 아니라 정직한 경계입니다. R&D 실패 분석의 목적은 모든 위험을 없애는 것이 아니라 현재 원인 검증의 범위를 정확히 말하는 것입니다.

lessons learned는 다음 설계와 시험 조건을 바꾸는 문장이어야 합니다

lessons learned는 “초기 검토를 강화한다”로 끝나면 쓸모가 없습니다. 다음 프로토타입 설계, 조립 지침, 시험 fixture, data logging, pass/fail 기준 중 무엇이 바뀌는지까지 가야 합니다. DOE RCA guidance는 원인 조사와 보고의 기본 이유를 recurrence를 막을 corrective action 식별로 설명합니다[S3]. 교훈도 같은 방향이어야 합니다.

좋은 lessons learned는 짧고 구체적입니다. “고온 시험 전 cable routing 사진과 latch clearance 확인을 test readiness check에 추가한다.” “packet loss 시험은 평균 손실률만 보지 않고 연속 손실 burst와 recovery time을 함께 기록한다.” “fixture 교체가 있을 때는 이전 failure reproduction 결과를 새 fixture에서 1회 confirm한다.” 이런 문장은 다음 작업자의 행동을 바꿉니다.

반대로 “협업 강화”, “검토 철저”, “품질 의식 제고”는 행동을 만들지 못합니다. 교육이 필요할 수도 있지만 교육만으로 verified cause가 제거되는지 확인해야 합니다. root cause가 설계 여유 부족인데 작업자 교육으로 닫으면 같은 결함은 다른 조건에서 다시 나옵니다.

프로토타입 결함 분석 60분 체크리스트

0분부터 10분까지는 실패 설명을 씁니다. 샘플 ID, revision, 시험 조건, 기대값, 실제값, 반복 횟수, 처음 발견 시각을 적고 원인 단어를 빼둡니다. 10분부터 20분까지는 containment를 겁니다. 같은 lot, 같은 firmware, 같은 fixture, 같은 raw data 묶음 중 무엇을 hold할지 정하고 계속해도 되는 시험을 분리합니다.

20분부터 30분까지는 증거를 보존합니다. 손대기 전 사진, raw log, fixture 상태, chamber 기록, operator note, pass sample을 묶습니다. 30분부터 40분까지는 fishbone으로 원인 후보를 펼칩니다. 제품 구조, 부품, 조립, fixture, 측정, firmware, 환경, 데이터 처리 범주를 나누고 각 후보를 suspected cause로 둡니다.

40분부터 50분까지는 재현 시험을 설계합니다. baseline, trigger, contrast, stop rule을 정하고 한 번에 여러 조건을 바꾸지 않도록 순서를 잡습니다. 50분부터 60분까지는 결론의 강도를 정합니다. verified cause가 없으면 없다고 쓰고, probable cause와 next evidence를 남깁니다. 이 마지막 구분이 다음 corrective action의 품질을 좌우합니다.

rndatlas 안에서 이어 볼 문서 경로

프로토타입의 기술 성숙도 주장까지 이어져야 한다면 R&D 프로토타입 TRL 검증 체크리스트가 다음 경로입니다. 시험 fixture와 측정 조건이 원인 후보에 있다면 R&D 테스트 픽스처와 지그 교정 증거 체크리스트를 먼저 봅니다. 원인 분석 결과가 요구사항과 검증 증거 연결로 확장되면 R&D evidence traceability matrix checklist로 분리합니다. 공식 부적합, 릴리즈 보류, 공급자 품질까지 넘어가면 R&D 품질관리 QMS 증거 체크리스트에서 별도 판단하는 편이 안전합니다.

오늘 만들 실패 분석 문서는 복잡할 필요가 없습니다. 실패 설명, containment, 증거 보존, 가설 목록, 재현 시험, verified cause, corrective action, fix verification, lessons learned만 빈칸 없이 있으면 됩니다. 중요한 것은 빨리 닫는 것이 아니라 잘못 닫지 않는 것입니다. 프로토타입 결함은 개발 속도를 늦출 수 있지만, 원인 검증 없이 넘어간 결함은 다음 revision에서 더 비싸게 돌아옵니다. 실패 분석의 좋은 결론은 “원인을 찾았다”가 아니라 “어떤 증거로 원인을 검증했고, 어떤 조건에서 다시 확인할 것인가”입니다.