실패의 자산화: 반복 실수율 72%를 8%로 잠재운 '5Why 복기 시스템' 180일의 기록

프로젝트 성공률 89% 도달 전략을 팀원들과 논의하고 있는 모습

지난 2년간 실패한 프로젝트 8건을 그냥 넘어갔고("바빠서 어쩔 수 없었어" 변명만 반복), 같은 실수를 계속 반복했으며(일정 지연이 8건 중 6건), 실패 원인을 팀원이나 외부 환경 탓으로 돌렸고, 결과적으로 프로젝트 성공률이 58%에 머물렀으며 팀 내 신뢰도도 낮아져 있었습니다. 6개월간 체계적인 실패 복기 시스템을 구축한 결과, 실패한 프로젝트 12건을 5Why 기법과 KPT 회고법으로 분석했고, 반복 실수율이 72%에서 8%로 급감했으며, 실패를 학습으로 전환하는 비율이 23%에서 84%로 상승했고, 프로젝트 성공률이 89%까지 올랐으며, 실패 체크리스트 47개 항목을 만들어 다음 프로젝트에 적용하게 되었습니다. 이 글에서는 실패를 회피하던 패턴부터 Post-mortem 회의 운영법, 5Why 심층 분석, KPT 회고 프레임워크, 실패 유형 분류, 그리고 6개월간의 측정 데이터까지 알려드리려 합니다.

프로젝트 실패하면 그냥 덮고 넘어가던 나

1년 전, 신규 서비스 런칭 프로젝트가 망했습니다. 3개월 준비했는데, 출시 일주일 만에 사용자 이탈률 87%. 완전히 실패했어요. 팀 회의에서 팀장님이 물었습니다. "왜 이렇게 됐을까요? 원인을 분석해 봅시다." 저는 대답했어요. "시장 상황이 안 좋았고요, 경쟁사가 먼저 비슷한 기능을 출시해서요. 타이밍이 나빴습니다."

팀장님이 다시 물었습니다. "우리 내부에서 잘못한 건 없었나요?" 저는 잠깐 생각하다가 말했어요. "개발 일정이 좀 빡빡했던 것 같긴 해요. 근데 다들 최선을 다했으니까..." 팀장님은 "알겠습니다"라고만 하고 회의를 끝냈어요. 그게 전부였습니다. 실패 원인 분석 끝. 다음 프로젝트로 넘어갔습니다.

3개월 후, 또 다른 프로젝트가 실패했어요. 이번에는 고객사 제안서 탈락. 2주 동안 밤샘하며 준비했는데, 경쟁 PT에서 졌습니다. 이번에도 똑같았어요. "경쟁사 가격이 너무 낮았어요. 우리가 이길 수 없었어요." 변명하고, 넘어갔습니다. 복기 없이.

2년 동안 이런 식이었습니다. 실패한 프로젝트 8건. 매번 실패하면 "외부 요인" 탓하고, "어쩔 수 없었다" 정리하고, 빨리 잊으려 했어요. 실패를 되돌아보는 게 고통스러웠거든요. "내가 잘못했구나" 인정하기 싫었습니다. 그냥 덮고, 다음으로 넘어가는 게 편했어요.

문제는 같은 실수가 반복됐다는 겁니다. 8건 중 6건이 "일정 지연" 때문에 실패했어요. 매번 "이번엔 일정 관리 잘해야지" 다짐했지만, 또 지연됐습니다. 왜일까요? 원인을 제대로 분석 안 했으니까요. "일정이 빡빡해서"라는 피상적 분석으로 끝냈거든요. 진짜 원인은 파고들지 않았습니다.

프로젝트 성공률을 계산해봤어요. 2년간 총 14개 프로젝트. 성공 8개, 실패 6개. 성공률 58%. 절반 정도만 성공한 거예요. 팀 내에서 제 평판도 안 좋았습니다. "또 프로젝트 망치는 거 아니야?" 동료들이 제 프로젝트 참여를 꺼렸어요. 신뢰가 떨어졌습니다.

전환점은 책 한 권이었습니다. 아툴 가완디의 "체크! 체크리스트". 의사인 저자가 수술 실패율을 줄이기 위해 체크리스트를 만드는 과정을 다룬 책이에요. 핵심 메시지: "실수는 반복된다. 체크리스트가 없으면." 머리를 망치로 맞은 느낌이었습니다. 제가 바로 이거였어요. 실패를 분석 안 하니까, 체크리스트가 없으니까, 같은 실수를 반복한 거예요.

그날부터 바꾸기로 결심했습니다. 모든 실패 프로젝트를 체계적으로 복기하기로요. 더 이상 덮고 넘어가지 않겠다고. 6개월 실험을 시작했습니다.

측정 지표 (6개월)	복기 시스템 구축 전	복기 시스템 구축 후	개선율
반복 실수율	72% (8건 중 6건 동일 원인)	8% (12건 중 1건)	-89%
실패 학습 전환율	23%	84%	+265%
프로젝트 성공률	58% (14건 중 8건)	89% (18건 중 16건)	+53%
실패 체크리스트 항목	0개	47개	신규

5Why 기법: 실패의 진짜 뿌리 찾기

첫 번째로 배운 건 "5Why 기법"이었습니다. 도요타 생산방식에서 나온 방법론이에요. 문제가 생기면 "왜?"를 5번 물어서 근본 원인을 찾는 거죠. 피상적 원인에서 멈추지 않고, 계속 파고드는 겁니다.

예전에 실패했던 프로젝트를 다시 꺼냈어요. 신규 서비스 론칭 실패 건. 5Why를 적용해 봤습니다.

문제: 사용자 이탈률 87%로 서비스 실패. Why 1: 왜 이탈률이 높았나? → 사용자가 기능을 이해 못 했음. Why 2: 왜 이해 못 했나? → 온보딩 튜토리얼이 없었음. Why 3: 왜 튜토리얼이 없었나? → 개발 일정에 포함 안 했음. Why 4: 왜 일정에 포함 안 했나? → 기획 단계에서 사용자 테스트를 안 했음. Why 5: 왜 사용자 테스트를 안 했나? → "빨리 출시해야 한다"는 압박에 기획 과정을 생략했음.

진짜 원인이 나왔습니다. "시장 상황이 안 좋아서"가 아니었어요. "기획 단계에서 사용자 테스트를 생략했기 때문"이었습니다. 이건 제어 가능한 원인이에요. 다음 프로젝트에서 바꿀 수 있는 거예요. 외부 환경 탓하면 아무것도 못 바꾸지만, 내부 프로세스 문제면 바꿀 수 있습니다.

다른 실패 프로젝트도 똑같이 분석했어요. 고객사 제안서 탈락 건.

문제: PT 경쟁에서 탈락. Why 1: 왜 탈락했나? → 경쟁사보다 가격이 높았음. Why 2: 왜 가격이 높았나? → 개발 공수를 많이 잡았음. Why 3: 왜 공수를 많이 잡았나? → 고객 요구사항을 정확히 파악 안 했음. Why 4: 왜 파악 안 했나? → 사전 미팅을 1회만 했음. Why 5: 왜 1회만 했나? → "시간 없다"라며 추가 미팅 요청을 안 했음.

또 진짜 원인이 나왔어요. "경쟁사 가격이 낮아서"가 아니라, "고객 요구사항을 제대로 파악 안 해서" 불필요한 공수를 잡은 거였습니다. 다음 제안서부터는 사전 미팅을 3회 이상 하기로 했어요.

5Why의 핵심은 "제어 가능한 원인"을 찾는 겁니다. "시장 환경", "경쟁사", "운" 같은 건 제어 불가능해요. 바꿀 수 없으니까, 학습도 없습니다. 근데 "사용자 테스트 생략", "사전 미팅 부족" 같은 건 제어 가능합니다. 다음에 바꿀 수 있어요. 이게 진짜 복기의 가치입니다.

6개월간 실패 프로젝트 12건을 모두 5Why로 분석했어요. 매번 5번째 Why까지 파고들었습니다. 처음엔 힘들었어요. "왜?"를 계속 물으면 결국 "내 잘못"이 나오거든요. 인정하기 싫었습니다. 근데 3개월쯤 지나니까 익숙해졌어요. "내 잘못 찾기"가 아니라 "배울 점 찾기"로 마인드가 바뀌었습니다.

KPT 회고: Keep, Problem, Try 프레임워크

5Why로 원인을 찾았으면, 다음은 "어떻게 바꿀까?"입니다. 여기서 쓴 게 "KPT 회고법"이에요. 애자일 방법론에서 나온 회고 프레임워크입니다. Keep(계속할 것), Problem(문제점), Try(시도할 것). 세 가지로 나눠서 정리하는 거죠.

신규 서비스 론칭 실패 건을 KPT로 정리해 봤습니다.

Keep(잘한 점, 계속할 것): 개발 품질은 좋았음(버그 거의 없었음). 팀 커뮤니케이션 원활했음(매일 스탠드업 미팅). 디자인 퀄리티 높았음(사용자 반응 좋았음). 이 세 가지는 다음 프로젝트에서도 유지하기로 했어요.

Problem(문제점): 사용자 테스트 없이 출시함. 온보딩 튜토리얼 없었음. 출시 후 피드백 수집 체계 없었음. 이 세 가지가 실패 원인이었습니다.

Try(다음에 시도할 것): 출시 2주 전 베타 테스트 진행(최소 20명). 온보딩 튜토리얼 필수 포함(기획 단계부터). 출시 후 주간 사용자 설문 실시. 이 세 가지를 다음 프로젝트에 적용하기로 했어요.

KPT의 장점은 "긍정"과 "개선"을 동시에 본다는 겁니다. 실패 프로젝트에도 잘한 점은 있어요. Keep 항목을 찾으면, "완전히 망한 건 아니구나" 위안이 됩니다. 자존감이 덜 떨어져요. 동시에 Problem과 Try로 구체적 개선책을 만드니까, 다음 프로젝트가 기대됩니다. "이번엔 다르게 해 볼 수 있겠다."

고객사 제안서 탈락 건도 KPT로 정리했어요.

Keep: 제안서 디자인 좋았음. 발표 자료 깔끔했음. 팀원들 PT 연습 열심히 함. Problem: 고객 요구사항 파악 부족. 사전 미팅 1회로 부족. 경쟁사 분석 안 함. Try: 다음 제안서는 사전 미팅 최소 3회. 고객 담당자와 비공식 커피 미팅 추가. 경쟁사 제안서 사례 조사.

매 프로젝트마다 KPT를 작성하니까, 패턴이 보였어요. Keep 항목은 비슷했습니다. "팀 커뮤니케이션", "개발 품질", "디자인". 이건 우리 팀 강점이더라고요. 계속 유지하면 되는 거예요. Problem 항목도 반복됐어요. "일정 관리", "사전 조사 부족", "테스트 생략". 이게 우리 팀 약점이었습니다. 집중적으로 개선할 부분.

6개월 동안 12개 프로젝트의 KPT를 모았어요. 노션에 표로 정리했습니다. Keep 총 38개 항목, Problem 총 47개 항목, Try 총 52개 항목. 이게 우리 팀의 "실패 데이터베이스"가 됐습니다. 새 프로젝트 시작할 때 이 표를 꺼내봐요. "이전 프로젝트에서 어떤 문제가 있었지? Try 항목 중 뭘 적용해 볼까?" 체크리스트처럼 쓰는 겁니다.

실패 유형	발생 빈도 (12건 중)	근본 원인 (5Why 분석)	해결책 (Try)
일정 지연	7건 (58%)	초기 공수 추정 과소	버퍼 30% 추가, 주간 진행률 체크
요구사항 오해	4건 (33%)	고객과 소통 부족	사전 미팅 3회 이상, 요구사항 문서화
품질 이슈	2건 (17%)	테스트 시간 부족	출시 2주 전 베타 테스트 필수
팀 갈등	1건 (8%)	역할 분담 불명확	킥오프 때 RACI 매트릭스 작성

Post-mortem 회의: 팀과 함께 복기하기

혼자 복기하는 것도 좋지만, 팀과 함께 하면 더 좋습니다. "Post-mortem 회의"를 도입했어요. 프로젝트 끝나고 일주일 이내에 팀 전체가 모여서 복기하는 거예요. 구글에서도 쓰는 방법이더라고요.

첫 Post-mortem 회의를 열었습니다. 신규 기능 개발 프로젝트가 막 끝났을 때예요. 성공은 했지만(기능 잘 작동), 일정이 2주 늦었습니다. 팀원 5명 모았어요. 회의실에 화이트보드 준비하고, 포스트잇 나눠줬습니다.

규칙을 정했어요. 첫째, 비난 금지. "누구 때문에 망했다" 이런 말 하면 안 됩니다. 둘째, 사실만 말하기. "내 느낌엔..." 아니고 "데이터상..." 셋째, 개선 중심. "왜 망했나"보다 "다음엔 어떻게 할까". 이 세 가지 규칙이 중요했어요. 안 그러면 서로 공격하는 자리가 되거든요.

KPT 프레임워크로 진행했습니다. 먼저 각자 포스트잇에 Keep, Problem, Try를 적어요. 5분 시간 줬습니다. 조용히 각자 생각하며 적는 거예요. 그다음 한 명씩 발표하며 화이트보드에 붙였습니다. 비슷한 항목끼리 묶었어요.

Keep 항목: "매일 스탠드업 미팅 좋았음", "개발 품질 높았음", "팀 분위기 좋았음". 7개 나왔어요. Problem 항목: "초기 일정 추정 잘못됨", "중간에 요구사항 변경 많았음", "테스트 시간 부족했음". 9개. Try 항목: "다음엔 일정에 버퍼 30% 추가", "요구사항 동결 기간 정하기", "매주 금요일 테스트 데이". 11개.

회의 시간은 1시간 반이었어요. 처음엔 어색했습니다. "이거 뭐 하는 거지?" 의아해하는 팀원도 있었어요. 근데 점점 활발해졌습니다. "아 그때 그거 진짜 문제였어요", "저도 그렇게 생각했어요" 공감대가 형성됐어요. 평소엔 못했던 솔직한 이야기가 나왔습니다.

가장 중요한 건 회의 후예요. Try 항목 11개를 "액션 아이템"으로 만들었습니다. 누가, 언제까지, 뭘 할지 정했어요. "다음 프로젝트 시작 전까지 테스트 체크리스트 만들기 → 담당: 김 팀원, 기한: 2주 후". 이렇게 구체적으로 정하니까, 실제로 실행됐습니다.

두 번째 Post-mortem은 더 좋았어요. 팀원들이 익숙해졌거든요. "이번엔 뭐가 문제였을까?" 스스로 생각하며 왔어요. 포스트잇도 더 많이 적어왔고요. 회의 시간은 1시간으로 줄었습니다. 효율적으로 진행됐어요.

6개월간 총 6번의 Post-mortem 회의를 했습니다. 매 프로젝트 마다요. 회의록을 노션에 다 기록했어요. Keep 항목 누적 52개, Problem 누적 68개, Try 누적 74개. 이게 팀의 집단 지성이 됐습니다. 새로운 팀원이 들어오면, 이 회의록을 먼저 읽게 했어요. "우리 팀이 과거에 어떤 실수를 했고, 어떻게 개선했는지" 알 수 있으니까요.

실패 체크리스트: 다시는 같은 실수 안 하기

5Why로 원인 찾고, KPT로 개선책 정하고, Post-mortem으로 팀과 공유했습니다. 마지막 단계는 "체크리스트"예요. 아툴 가완디가 말했듯이, 실수는 반복됩니다. 체크리스트가 없으면요.

6개월간 쌓인 Problem과 Try 항목을 정리했어요. 총 120개쯤 됐습니다. 이 중 반복되는 것들만 골랐어요. 한 번만 나온 문제는 제외. 2번 이상 나온 문제만 남겼습니다. 47개가 나왔어요. 이게 우리 팀의 "실패 체크리스트"가 됐습니다.

체크리스트를 4단계로 나눴습니다. 기획 단계, 개발 단계, 테스트 단계, 론칭 단계. 각 단계별로 확인할 항목들이에요.

기획 단계 체크리스트(12개 항목): 고객 요구사항 문서화했는가? 사전 미팅 3회 이상 했는가? 경쟁사 분석 완료했는가? 프로젝트 목표 SMART 하게 정의했는가? 팀원 역할 RACI로 명확히 했는가? 일정에 버퍼 30% 포함했는가? 등등.

개발 단계 체크리스트(15개 항목): 매일 스탠드업 미팅 하는가? 주간 진행률 측정하는가? 요구사항 변경 시 일정 재조정했는가? 코드 리뷰 진행하는가? 기술 부채 문서화하는가? 등등.

테스트 단계 체크리스트(11개 항목): 베타 테스트 진행했는가? 사용자 피드백 수집했는가? 버그 리스트 정리했는가? 성능 테스트 완료했는가? 등등.

론칭 단계 체크리스트(9개 항목): 출시 후 모니터링 체계 있는가? 피드백 수집 채널 준비했는가? 롤백 플랜 있는가? 등등.

새 프로젝트 시작할 때 이 체크리스트를 꺼냅니다. 각 단계마다 체크해 가며 진행해요. "기획 단계 12개 항목 중 11개 완료. 1개 누락: 경쟁사 분석." 이렇게 확인하면, 놓치는 게 없습니다. 예전엔 "이번엔 빠르게 가자"며 건너뛰던 것들이, 이제는 "체크리스트에 있으니 해야지"로 바뀌었어요.

체크리스트 효과는 즉각적이었습니다. 첫 번째 적용 프로젝트부터 달랐어요. 일정 지연 없이 완료. 고객 만족도 높음. 버그 거의 없음. 성공률이 확 올랐습니다. 팀원들도 "체크리스트 있으니 안심된다"라고 말했어요. "뭘 놓쳤나" 불안해하지 않아도 되니까요.

체크리스트는 계속 업데이트됩니다. 새로운 실패가 생기면, 새로운 항목을 추가해요. "이번 프로젝트에서 X가 문제였네? 체크리스트에 추가하자." 살아있는 문서예요. 6개월 전엔 47개였는데, 지금은 62개입니다. 팀이 성장하는 기록이죠.

6개월 후: 실패가 두렵지 않은 팀

6개월간 실패 복기 시스템을 운영한 결과를 측정했습니다. 가장 극적인 변화는 반복 실수율이었어요. 72%에서 8%로 급감. 12개 프로젝트 중 1개만 이전과 같은 실수를 했습니다. 나머지 11개는 새로운 실수 거나, 실수 없이 성공했어요. 체크리스트 덕분이었습니다.

프로젝트 성공률도 올랐어요. 58%에서 89%로 상승. 18개 프로젝트 중 16개 성공. 실패는 단 2개. 예전엔 절반만 성공했는데, 지금은 거의 다 성공합니다. 실패해도 "새로운 실패"예요. 같은 실수 반복은 거의 없어요.

실패 학습 전환율이 84%까지 올랐습니다. 실패하면 그냥 넘어가는 게 아니라, 반드시 복기하고, 배우고, 다음에 적용해요. 12개 실패 중 10개에서 명확한 학습을 얻었습니다. 실패가 "낭비"가 아니라 "투자"가 됐어요.

팀 문화도 바뀌었습니다. 예전엔 실패하면 숨기려 했어요. "내 탓 아니야" 변명부터. 지금은 실패해도 솔직하게 말합니다. "이번 프로젝트 실패했어요. Post-mortem 회의 언제 할까요?" 실패를 부끄러워하지 않아요. 학습 기회로 보니까요.

심리적 안전이 생겼습니다. 에이미 에드먼슨이 말한 "psychological safety". 실수해도 비난받지 않는다는 믿음. Post-mortem 회의에서 "비난 금지" 규칙을 지키니까, 다들 솔직하게 말해요. "제가 이 부분 놓쳤어요", "저도 여기서 실수했어요". 숨기지 않습니다. 덕분에 진짜 원인을 빨리 찾아요.

팀 내 제 평판도 좋아졌어요. "프로젝트 망치는 사람"에서 "실패를 학습으로 바꾸는 사람"으로. 동료들이 제 프로젝트 참여를 원합니다. "저 사람이랑 하면 실패해도 배울 게 있어" 신뢰가 생겼어요.

상사 평가도 올랐습니다. 팀장님이 "요즘 프로젝트 관리 정말 잘한다. 실패율이 확 줄었어"라고 말씀하셨어요. 인사평가 점수도 상승. 실패 복기 시스템이 제 커리어에도 도움이 됐습니다.

가장 큰 변화는 마인드셋이었어요. 예전엔 실패가 두려웠습니다. "또 망하면 어쩌지?" 불안했어요. 지금은 실패가 덜 무섭습니다. "실패해도 괜찮아. 복기하면 배우니까." 실패를 회피하지 않게 됐어요. 오히려 도전적인 프로젝트를 선택합니다. "실패할 수도 있지만, 배울 게 많겠네."

6개월 전 저는 프로젝트 실패하면 그냥 덮고 넘어갔습니다. "빨리 잊자." 지금은 실패하면 노트북 꺼내서 5Why 적습니다. "왜 실패했지? 진짜 원인은 뭐지?" 6개월 전 저는 같은 실수를 반복했습니다. 지금은 체크리스트 보며 확인합니다. "이번엔 다 챙겼나?" 6개월 전 저는 혼자 고민했습니다. 지금은 팀과 함께 Post-mortem 합니다. "우리 다음엔 어떻게 할까?"

실패는 끝이 아닙니다. 복기하지 않는 실패가 끝이에요. 복기하는 실패는 성장의 시작입니다. 여러분도 시작해 보세요. 이번 주에 하나만 해보세요. 최근 실패한 일 하나 꺼내서, 5Why 적어보세요. "왜?"를 5번 물어보세요. 진짜 원인이 보일 겁니다. 그 원인을 다음엔 바꿔보세요. 한 달 후엔 다른 사람이 돼있을 겁니다. 실패를 회피하는 사람에서, 실패를 학습으로 바꾸는 사람으로.