프로젝트 사전 부검 워크숍: 실패 원인과 대응을 미리 찾는 법

“예상되는 위험이 있나요?”라고 물으면 짧은 대화 끝에 별문제 없다는 답을 듣기 쉽습니다. 프로젝트 사전 부검, 또는 프리모템(Pre-mortem)은 질문을 바꿉니다. “프로젝트가 이미 실패했다고 상상해 봅시다. 무슨 일이 있었을까요?” 아직 계획을 바꿀 시간이 있을 때 구체적인 상황을 떠올려 살펴보는 것입니다.

워크숍을 마치면 검증할 가정, 추가할 안전장치, 지켜볼 경고 신호, 다시 협의할 약속처럼 프로젝트에서 실제로 바꿀 몇 가지가 남아야 합니다.

프로젝트 사전 부검은 언제 진행하나요?

계획의 윤곽이 잡힌 뒤, 비용이 크거나 되돌리기 어려운 결정을 내리기 전에 진행합니다. 새로운 서비스 도입, 시스템 이전, 행사, 여러 팀이 참여하는 출시에 활용할 수 있습니다. 프로젝트가 크게 바뀌었다면 워크숍 전체를 기계적으로 반복하기보다 관련된 위험을 다시 살펴보세요.

사전 부검은 가상의 실패를 통해 앞으로 일어날 수 있는 일을 살펴봅니다. 회고는 실제로 진행한 일을 돌아보며, 위험 등록부는 위험을 기록하고 지속적으로 추적합니다. 워크숍 결과를 위험 등록부에 반영할 수는 있지만, 기술 테스트, 계약 검토, 전문적인 안전 분석을 대신할 수는 없습니다.

Atlassian의 사전 부검 진행법은 개인별 아이디어 작성, 토론, 담당자가 정해진 행동을 통해 프로젝트 위험을 탐색합니다. 아래에서는 이 기본 방식을 출시 상황에 적용하되, 조기 경고 신호에 특히 주목합니다.

상상이 가능한 실패 시나리오를 쓰세요

“프로젝트가 잘 안됐다”처럼 막연하게 쓰지 마세요. 시점과 중요한 결과를 명시합니다. 고객 지원 시스템을 이전하는 프로젝트라면 이렇게 쓸 수 있습니다. “도입한 지 한 달이 지났습니다. 고객은 여전히 예전 메일함으로 연락하고, 상담원은 이전 대화를 찾지 못하며, 팀은 기존 시스템을 복구했습니다.”

이것은 워크숍을 위한 가상 시나리오이지 예측이 아닙니다. 어떤 원인을 제시해야 할지 미리 정해 주지 않으면서도 모두가 같은 상황에서 출발하게 합니다. “일정을 놓쳤다”는 시나리오만 사용하면, 제때 출시했지만 사용자에게 도움이 되지 않는 실패를 놓칠 수 있습니다.

현재 프로젝트 계획, 달성하려는 결과, 이미 알고 있는 제약을 미리 공유합니다. 변화를 구현하는 사람뿐 아니라 바뀐 환경에서 일해야 하는 사람도 초대하세요. 지원 시스템 이전에서는 상담원과 관리자가 프로젝트 후원자는 보지 못한 실패 경로를 발견할 수 있습니다.

논쟁으로 흐르지 않게 워크숍을 진행하세요

먼저 비판의 대상은 계획이지 작성자의 능력이 아니라고 밝힙니다. 각자 가능한 원인을 적게 하고, 원인 하나당 메모 하나를 사용합니다. 리더는 다른 사람들의 의견이 나온 뒤에 자신의 설명을 제시하는 편이 좋습니다. 그렇지 않으면 보드가 상급자의 첫 의견을 뒷받침하는 이유들로만 채워질 수 있습니다.

분류하기 전에 메모를 읽어 보세요. “교육이 끝나지 않았다”와 “상담원이 예외적인 질문에 답하지 못한다”는 관련이 있을 수 있지만 같은 문제는 아닙니다. 하나는 교육 이수 여부이고 다른 하나는 대응 역량입니다. 너무 일찍 묶으면 행동으로 옮기는 데 필요한 세부 정보가 사라질 수 있습니다.

각 묶음에서 실패가 어떤 과정으로 일어나는지 물어봅니다. “소통 부족” 대신 “새 연락처를 뉴스레터로만 알렸다 → 고객은 예전 이메일 대화에 답장했다 → 전환 후에는 아무도 기존 메일함을 확인하지 않았다”처럼 흐름을 적으세요. 팀이 개입할 수 있는 지점이 여러 곳 드러납니다.

원인이 특정 사람의 실수에만 쏠린다면 고객, 기술, 데이터, 사람, 프로세스, 외부 조건을 나누어 살펴보세요. 확인된 사실과 아직 검증하지 않은 가정은 색이나 표기로 구분하면 이후 논의에서 섞이지 않습니다.

예시: 고객 지원 시스템 이전

다음 가상의 보드는 실패 시나리오를 구체적인 결정으로 바꾸는 방법을 보여 줍니다. 실제 담당자 이름과 날짜는 프로젝트팀이 추가해야 합니다. 표의 역할은 누가 맡을 수 있는지 보여 주는 예시입니다.

“시스템 이전에 실패한다”는 원인이 아니라 결과입니다. 마찬가지로 “프로젝트를 모니터링한다”는 말도 무엇을 관찰하고 그에 따라 어떤 결정을 내릴지 정하기 전에는 대응책이 되지 않습니다.

정확한 확률을 아는 척하지 말고 우선순위를 정하세요

발생했을 때의 영향, 실제로 일어날 수 있다고 보는 근거, 언제까지 대응할 수 있는지를 논의합니다. 다음 주에 쉽게 되돌릴 수 있는 위험과 되돌릴 수 없는 전환 뒤에야 드러나는 위험은 다릅니다. 확률을 추정할 근거가 없다면 정밀해 보이는 백분율을 만들어 내지 말고 “알 수 없음”으로 표시하세요.

투표로 논의할 만한 우려를 찾을 수는 있지만, 투표만으로 최종 대응을 정해서는 안 됩니다. 전문가가 발견한 심각한 실패 가능성을 다른 사람들이 이해하지 못해 표가 적게 나올 수도 있습니다. 판단의 근거를 듣고 적절한 전문가에게 검토를 요청하세요.

결정에 맞는 행동을 선택합니다. 대규모 도입을 승인하기 전에 샘플 이전을 테스트하는 것은 유용할 수 있습니다. 반면 짧은 연습만으로 주요 문제가 접근 권한임을 알 수 있다면, 모든 교육 자료를 다시 쓰는 것은 낭비가 될 수 있습니다.

예방 행동과 비상 대응을 구분하세요

예방 행동은 실패가 발생하기 전에 발생 가능성이나 영향을 줄입니다. 비상 대응은 정해 둔 조건에 도달했을 때 팀이 무엇을 할지 정하는 것입니다. 지원팀은 예방을 위해 출시 전에 이전된 기록을 대조할 수 있습니다. 동시에 도입을 미루거나 서비스를 복구할 조건을 비상 대응으로 정할 수 있습니다.

대응을 시작할 조건은 관찰 가능해야 합니다. “상황이 나빠 보이면”이라는 기준은 압박 속에서 다시 협의하게 만듭니다. “리허설에서 반드시 처리해야 하는 유형의 문의를 처리하지 못하면”이라는 기준은 출시 책임자가 구체적으로 판단할 수 있게 합니다. 기준값은 예시에서 임의의 숫자를 가져오는 대신 프로젝트의 서비스 요구 사항을 반영해야 합니다.

예방 행동과 비상 대응에는 각각 담당자, 기한, 필요한 자원을 적어 실제로 실행할 수 있는지 확인하세요.

중요한 선택은 의사결정 기록부에 남기고, 남아 있는 위험을 누가 수용할 수 있는지도 적습니다. 워크숍 진행자가 모르는 사이에 그 권한까지 떠맡게 해서는 안 됩니다.

말하기 어려운 우려도 회의 후까지 남겨 두세요

여럿이 있는 자리에서 프로젝트 후원자가 정한 일정을 비판하기 어려워하는 사람도 있습니다. 회의 전에 우려를 전달할 방법을 제공하고, 합의하지 못한 쟁점은 후속 논의로 이어 가세요. 실제 수집 방식이 익명성을 보장하지 않는다면 익명이라고 약속하지 마세요.

행동의 책임이 여전히 불분명하다면 RACI 매트릭스를 사용합니다. 사전 부검 보드에는 위험, 신호, 대응, 담당자, 다음 결정 날짜만 간결하게 남겨 두세요. 실제 실행 작업과 연결해 서로 다른 두 곳에서 진행 상황을 중복 관리하지 않도록 합니다.

Boardmix를 열고 캔버스 상단에 지원 시스템 이전 실패 시나리오를 적습니다. 그 아래에는 예시처럼 가능한 원인, 조기 경고 신호, 대응 제안, 확인할 담당 역할의 네 열을 만드세요. 각 원인과 대응은 같은 행에 둡니다. 대화 기록이 누락되는 문제라면 샘플 문의 점검에서 발견한 문제를 이전 작업 책임자의 대조·보완 작업과 연결합니다. 시스템 전환을 승인하기 전에 그 작업과 아직 해결하지 못한 다른 신호를 확인하세요. 필요한 첨부 파일이 여전히 없다면 출시 책임자는 일정을 미룰 구체적인 근거를 갖게 됩니다.