소프트웨어 프로젝트 실패를 예방하는 사전 부검(Pre-mortem) 엔지니어링: 코딩 착수 전 숨은 병목을 도출하는 설계 회의법

1. 왜 일반적인 착수 회의(Kick-off)에서는 치명적인 리스크가 침묵하는가?

사내 업무 시스템 구축이나 신규 웹 서비스 프로젝트를 시작할 때, 기획서와 화면 설계서를 띄워놓고 **“이대로 개발 들어가면 문제없겠죠?”**라고 물으면 참석자 대부분은 고개를 끄덕입니다.

현장 실무자는 *‘특정 부서의 예외 정산 규칙이 빠진 것 같은데’*라는 의구심이 들어도 개발 용어를 몰라 말을 아끼고, 의사결정권자는 *‘일단 만들어서 배포하면 직원들이 알아서 잘 쓰겠지’*라고 낙관합니다. 그렇게 침묵 속에 통과된 가정(Assumption)들은 개발 공정률 80%를 넘어 건물의 골조가 다 올라간 시점에야 **“사실 현장에서는 이렇게 안 쓰는데요”**라는 치명적인 설계 변경 요청으로 폭발합니다.

이 구조적 침묵을 깨기 위해 제이앤코어가 요구사항 분석 단계에서 활용하는 도구가 의사결정 연구자 게리 클라인(Gary Klein)이 제시한 사전 부검, 즉 프리모텀(Pre-mortem) 엔지니어링입니다.

프리모텀(Pre-mortem) 핵심 질문:
“지금으로부터 3개월 뒤, 우리가 구축한 시스템이 현장에서 철저히 외면받고 프로젝트는 실패로 끝났습니다. 대체 무슨 일이 벌어졌던 것일까요?”

계획의 성공 가능성을 묻는 대신 **‘이미 실패가 확정된 미래’**를 가정하고 그 원인을 역추적하면, 누군가의 기획을 공격하는 부담 없이 현장의 숨은 제약 조건과 예외 시나리오가 수면 위로 쏟아져 나옵니다.

2. 소프트웨어 설계에 적용하는 4단계 프리모텀 프로토콜

단순히 불안한 말을 나열하는 회의는 아무런 기술적 가치를 만들지 못합니다. 제이앤코어는 도출된 우려를 실제 데이터베이스 스키마와 UI 워크플로우 수정으로 직결시키는 4단계 구조로 프리모텀을 수행합니다.

[제이앤코어 프리모텀(Pre-mortem) 엔지니어링 4단계 파이프라인]
[Step 1. 독립 기록 (Silent Generation)]
  └─ 기획자·현장 실무자·아키텍트가 각자 5분간 독립적으로 '시스템 실패 시나리오' 작성 (집단 사고 차단)
[Step 2. 구조적 군집화 (Failure Clustering)]
  └─ 도출된 실패 원인을 [데이터 유입 병목 / 도메인 예외 누락 / 운영 권한·책임 공백]으로 분류
[Step 3. 조기 경보 지표 매핑 (Early Warning Signal)]
  └─ 각 실패 원인이 현실화될 때 가장 먼저 관측될 구체적 현상(신호) 정의
[Step 4. 아키텍처 방어 설계 반영 (Preventive Spec Modification)]
  └─ 코딩 착수 전 데이터 모델·화면 흐름·운영 규칙에 선제 반영 및 담당·기한 확정

3. 실전 적용 예시: B2B 상담 신청 및 사내 업무 시스템 기획

가상의 신규 B2B 상담 및 주문 접수 웹 시스템을 구축한다고 가정해 보겠습니다. 일반적인 회의에서는 *“소개 문구와 신청 폼을 다 만들었으니 이제 코딩만 하면 된다”*고 결론짓기 쉽습니다.

여기에 프리모텀 질문을 던져 도출된 막연한 걱정들을 엔지니어링 수정 명세로 변환하는 과정은 다음과 같습니다.

① 추상적인 우려를 ‘사용자가 멈추는 구체적 장면’으로 변환

흔히 나오는 추상적 걱정	프리모텀을 통해 구체화된 실패 장면 (Failure Scene)	선제적 설계 변경 조치 (Engineering Action)
“홍보나 안내가 부족할 것 같다”	고객이 첫 화면에 들어왔으나 본인 업종이 대상인지, 신청 후 어떤 결과물을 받는지 알 수 없어 10초 만에 이탈했다.	메인 히어로 섹션에 대상 고객군과 상담 직후 제공되는 산출물(진단표·견적 기준)을 명시하도록 UI 구조 변경
“신청 폼이 너무 복잡하다”	담당자가 모바일로 문의를 남기려다가 필수 입력 칸이 12개나 되고 당장 모르는 항목이 있어 작성을 포기했다.	초기 입력 필드를 핵심 3~4개(연락처·현재 겪는 불편 한 줄)로 축소하고, 세부 자료는 후속 단계에서 받는 2-Step 폼으로 재설계
“실무자들이 새 시스템을 안 쓰고 다시 엑셀로 돌아갈 것 같다”	기존 엑셀에서 쓰던 부분입금·당직 예외 처리가 새 화면에서 막혀 있어, 결국 엑셀을 따로 켜서 계산한 뒤 결과만 타이핑했다.	정상 케이스 자동화 외에 실무자가 수동으로 예외 사유를 입력·조정할 수 있는 예외 오버라이드(Override) 슬롯을 DB 스키마에 추가
“접수 후 응대가 늦어질 수 있다”	주말이나 외근 중 문의가 들어왔는데 누가 언제까지 1차 답변을 해야 하는지 정해지지 않아 고객이 방치되었다.	접수 즉시 슬랙/이메일 실시간 웹훅(Webhook) 알림을 발송하고, 미확인 상태로 기준 시간 경과 시 상단 경고 배지 노출

4. 조기 경보 신호(Early Warning Signals)의 정의

프리모텀에서 도출한 리스크가 실제 운영 초기 단계에서 발생하고 있는지 판단하려면, 감(Feeling)이 아니라 **관찰 가능한 첫 신호(First Signal)**를 정의해 두어야 합니다.

가설 1 (대상 및 가치 전달 모호성): 오픈 초기 유입된 문의에서 “저희 같은 소규모 업체도 의뢰가 가능한가요?” 같은 기본 자격 질문이 반복된다면, 첫 화면의 서비스 범위 정의가 실패하고 있다는 신호입니다.
가설 2 (입력 병목): 페이지 방문 대비 폼 제출 완료율이 급감하거나 첨부파일 항목에서 오류가 빈번하다면, 입력 유효성 검증(Validation) 조건이 현장의 실제 파일 형식과 맞지 않는다는 신호입니다.
가설 3 (운영 공백): 접수 시각(created_at)과 담당자 최초 확인 시각(acknowledged_at)의 편차가 요일이나 시간대별로 크게 흔들린다면, 알림 라우팅이나 담당자 배정 규칙에 구멍이 있다는 신호입니다.

이러한 신호들은 거창한 빅데이터 분석 도구가 없어도, 출시 전 **실제 업무 담당자 2~3명에게 프로토타입 화면과 실제 엑셀 파일 하나를 주고 직접 처리해 보게 하는 것(Hallway Usability Test)**만으로도 대부분 사전에 포착할 수 있습니다.

5. 엔지니어링 결론: 코드로 고치는 것보다 설계도 위에서 한 번 실패해 보는 것이 압도적으로 저렴합니다

소프트웨어 개발에서 요구사항 오류를 수정하는 비용은 단계가 뒤로 갈수록 기하급수적으로 증가합니다.

기획·설계 단계(Pre-mortem): 테이블 컬럼 하나를 추가하고 화면 스케치의 흐름을 바꾸는 데 단 30분이 걸립니다.
개발 80% 완료 후(Post-hoc): 이미 구축된 DB 외래키 구조, 백엔드 API, 프론트엔드 정산 화면을 전부 뜯어고치는 데 수주일의 일정 지연과 막대한 추가 비용이 발생합니다.

제이앤코어가 2주(300만 원) / 4주(500만 원) 정찰제 스프린트라는 압축된 일정 안에서도 높은 현장 안착률을 유지할 수 있는 비결은 코딩 속도가 빨라서만이 아닙니다. 코드를 단 한 줄도 작성하기 전에, 고객사 실무자와 함께 **“이 시스템이 현장에서 버려진다면 어떤 예외 상황 때문일까?”**를 끝까지 파고들어 아키텍처의 뼈대에 미리 반영하기 때문입니다.

💡 실패 없는 사내 업무 전산화 및 웹 시스템 기획 상담

외주 개발을 맡겼다가 현장의 예외 규칙이 반영되지 않아 무용지물이 된 경험이 있으십니까?
새로운 서비스나 사내 프로그램을 기획 중인데, 개발 착수 전 어디에 숨은 지뢰가 있는지 전문가의 시각으로 점검받고 싶으십니까?

현재 구상 중인 업무 흐름이나 가장 우려되는 현장 시나리오를 공유해 주십시오. 기능 목록을 늘리는 대신 사용자와 실무자가 멈추는 병목 지점부터 정확히 짚어드립니다.