그 ERP 프로젝트에 리스크 등록부를 붙여봤다

지난 케이스 스터디에서 우리는 Claude에게 6개월짜리 제조사 ERP 프로젝트의 WBS를 통째로 맡겼다(지난 케이스 스터디). Phase 골격부터 데이터 마이그레이션·통합 테스트까지, 계획이 화면에 섰다. 그런데 계획이 서고 나면 곧바로 다른 질문이 따라온다. 이 계획을 위협하는 것들은 어디에 적나.

핵심 개발자가 나갈 수도 있다. 15년치 레거시 데이터가 생각보다 더러울 수도 있다. 요구사항 동결이 늦어질 수도 있다. 이것들은 WBS의 작업이 아니다 — 작업을 무너뜨릴 수 있는 것들이다. 전통적으로 PM은 이걸 "리스크 대장"이라는 별도 엑셀에 적는다. 그리고 대부분의 리스크 대장은 킥오프 때 한 번 만들어지고, 다시 열리지 않는다. WBS와 물리적으로 분리돼 있으니, 계획이 바뀌어도 대장은 그대로고 대장이 바뀌어도 계획은 모른다.

이번 글은 그 별도 엑셀을 없애 보는 실험이다. 같은 ERP 프로젝트(코드 MCG-26) 위에 wbsgantt의 Risk 등록부를 얹고, PMBOK 리스크 프로세스 — 식별·평가·대응·감시 — 를 화면 하나에서 돌려봤다. 미리 밝혀 둔다. 광고가 아니라 실험 리포트다. 되는 것과 안 되는 것을 그대로 적는다.

식별 — 리스크 8건

먼저 머릿속에 있던 위협을 꺼내 적었다. 8건.

New Risk 다이얼로그는 단출하다. 제목, 카테고리 4버튼(조직·기술·PM·외부), 그리고 Probability와 Impact를 각각 1~5로 고르는 세그먼트. 두 값을 고르면 아래 Score 박스가 즉시 곱을 보여준다 — P4를 누르고 I5를 누르면 그 자리에서 20 · 높음이 뜬다. "빠른 등록 — 상세 내용은 등록 후 입력합니다"라는 안내대로, 여기서는 좌표만 찍고 상세는 나중에 채운다.

8건을 이렇게 넣었다.

• 핵심 개발자 이탈 가능성 (조직) — P4×I5 = 20
• 레거시 데이터 품질 불량 (기술) — P3×I5 = 15
• 요구사항 동결 지연 (PM) — P4×I3 = 12
• 병행 운영 기간 부족 (PM) — P3×I4 = 12
• ERP 패키지 커스터마이징 범위 초과 (기술) — P3×I3 = 9
• 레거시 벤더 지원 종료 (외부) — P2×I4 = 8
• 환율 변동으로 라이선스 비용 증가 (외부) — P2×I3 = 6
• 테스트 환경 확보 지연 (조직) — P2×I2 = 4

Score는 Probability와 Impact의 곱이다. 단순한 규칙이지만, 직관을 좌표로 바꿔 준다는 게 핵심이다. "개발자 이탈이 제일 무섭다"는 느낌은 이제 20이라는 숫자가 됐고, 20은 다른 일곱 개와 한 줄로 비교된다.

평가 — 5×5 매트릭스

등록부 화면 위쪽에는 KPI 카드 넉 장이 있다 — Open 7 · High 2 · Mitigating 2 · Overdue 1. (전체 8건 중 1건은 이미 closed라 Open은 7이다.) 그 아래가 이 글의 주인공, 5×5 매트릭스다.

매트릭스는 "Open 7건 기준" pill을 달고 리스크를 Probability × Impact 좌표에 뿌린다. 그림이 말을 한다. High 2건(Score 15·20)이 우상단 빨강 셀(3-5·4-5)에 몰려 있다. 중간 밴드(주황) 셀 다섯 개에 나머지가 흩어져 있고, closed 1건은 매트릭스에 잡히지 않는다. 범례는 낮음 1–4 · 중간 5–12 · 높음 15–25.

이게 왜 중요한가. 리스크 여덟 건을 표로만 보면 "다 중요해 보인다". 매트릭스는 어디부터 손대야 하는지를 직감이 아니라 좌표로 알려준다. 우상단 빨강부터다. 셀을 클릭하면 그 P×I에 해당하는 리스크만 필터링되니, "높은 것부터 하나씩" 회의가 자연스럽게 굴러간다.

대응·연결 — 계획에 매다

우상단부터 대응 전략을 정했다. 개발자 이탈(20)은 완화 전략에 담당 김PM, 마감 8/14. 레거시 데이터 품질(15)도 완화로 김PM·마감 7/10. 나머지는 회피·수용·전가로 성격에 맞게 배분했다.

여기까지는 여느 리스크 대장과 다르지 않다. 차이는 다음 한 걸음이다.

리스크를 열면 드로어가 뜬다. 레거시 데이터 품질 리스크의 드로어에는 헤더에 mitigating과 Overdue pill이 나란히 붙어 있다(마감 7/10이 지났다). Score 박스는 15 · 높음 · P3×I5. 상태는 5종 pill(identified·assessed·mitigating·closed·realized)에서 고르고, 설명·트리거 조건·비상계획 같은 필드가 이어진다 — "2차 리허설에서 데이터 정합성 95% 미달"이라는 트리거, "정합성 미달 모듈은 수기 검증 라인 가동"이라는 비상계획을 적어 뒀다. 저장 버튼은 없다. P 세그먼트를 바꾸면 Score가 서버 재계산값으로 바로 갱신되는, 필드 단위 즉시 저장이다.

그리고 드로어 아래쪽에 "연결된 WBS 노드" 칩이 있다. 레거시 데이터 품질 리스크를 1.4 데이터 마이그레이션 노드에 연결했다. 개발자 이탈 리스크는 1.3 백엔드 코어 개발에. 이 연결이 리스크를 대장에서 꺼내 계획에 매단다.

연결의 효과는 반대편에서 드러난다. WBS 화면으로 가서 1.4 데이터 마이그레이션 행을 우클릭하면 컨텍스트 메뉴에 **"연결된 리스크 1"**이 뜬다. 클릭하면 그 노드로 필터링된 리스크 뷰(/risks?node=)로 넘어간다. 간트에서 리스크로, 리스크에서 간트로 — 왕복이 된다. 리스크 대장이 킥오프 이후 안 열리는 이유는 계획과 끊겨 있어서였다. 연결돼 있으면, 그 작업을 볼 때마다 리스크가 따라온다.

운영 사이클 — 주간 리뷰

리스크 등록부의 값은 등록이 아니라 감시에서 나온다. 주간 리뷰를 재현해 봤다.

회의의 첫 화면은 KPI 카드 넉 장이다. Open 7 · High 2 · Mitigating 2 · Overdue 1. "지금 몇 건이 살아 있고, 큰 게 몇 개고, 손 놓친 게 있나"가 한 줄로 답이 된다. Overdue 1이 바로 눈에 걸린다 — 레거시 데이터 품질의 마감 7/10이 지났다. 등록부 테이블에서 그 행의 마감일은 빨강에 경고 아이콘(⚠)으로 뜬다.

대응에 착수한 리스크는 상태를 identified에서 mitigating으로 옮겼다(개발자 이탈·레거시 데이터 둘). 대응이 끝나 더는 위협이 아닌 테스트 환경 확보 지연은 closed로 내렸다 — closed는 매트릭스에서 빠지므로, 다음 회의의 그림이 그만큼 깨끗해진다.

WBS 노드에서 넘어온 필터 뷰도 여기서 쓸모가 있다. "필터링 기준: 1.4 데이터 마이그레이션" 칩이 달린 뷰에서는 테이블이 그 노드에 걸린 1행(레거시 데이터 품질 불량)으로 줄고, 매트릭스와 KPI도 그 부분집합 기준으로 다시 계산된다. "이 작업에 걸린 리스크만" 보는 회의가 가능해진다.

정직하게 — 안 되는 것

케이스 스터디의 관례대로, 못 하는 것도 그대로 적는다.

• Realized→Issue 전환이 없다. 상태 값에 realized는 있지만, 실제로 터진 리스크를 이슈로 승격해 따로 추적하는 흐름은 아직 없다. 지금은 상태 라벨이 전부다.
• 리스크 히트맵 리포트가 없다. 매트릭스는 화면에서만 산다. Excel 내보내기(Excel 케이스 스터디의 그 기능)에도 리스크 시트는 없다 — 임원 보고에 리스크 현황을 붙이려면 아직 화면을 캡처해야 한다.
• 5×5는 정성 도구다. Score는 Probability × Impact의 곱일 뿐, EMV(기대화폐가치) 같은 정량 분석이 아니다. "20이 6보다 세 배 위험하다"는 뜻이 아니라 "20을 먼저 봐라"는 뜻이다. 그 선을 넘지 않는다.
• 카테고리는 프리셋 4종 고정이다. 조직·기술·PM·외부. 조직마다 쓰는 리스크 분류 체계가 다른데, 지금은 커스텀이 안 된다.

이건 한계라기보다 경계다. 뒤의 두 개는 특히 그렇다 — 5×5를 EMV로 착각하지 않는 것, 분류를 늘리기 전에 4종으로 버텨 보는 것은, 도구가 판단을 대신하지 않게 하는 쪽에 가깝다.

맺음

리스크 대장이 죽는 이유는 게을러서가 아니다. 계획과 끊겨 있어서다. 별도 엑셀로 살면, 열어볼 이유가 회의 알림 말고는 없다.

이번 실험에서 달라진 건 하나다. 리스크가 계획 위에 산다. 식별은 New Risk 다이얼로그에서 좌표로, 평가는 5×5 매트릭스에서 우선순위로, 대응은 전략·담당·마감으로, 감시는 KPI 카드와 상태 전이로 — PMBOK가 네 단계로 나눠 부르는 리스크 프로세스가 화면 하나로 접힌다. 그리고 무엇보다, 리스크가 WBS 노드에 매달려 있으니 그 작업을 볼 때마다 위협이 따라온다.

계획이 무엇을 할지의 지도라면(1편에서 빠뜨린 일을 이야기했다), 리스크 등록부는 그 지도가 어디서 찢어질 수 있는지의 지도다. 기준선이 사라지면 밀린 것도 모른다는 게 3편의 논지였는데, 리스크도 같다. 적어 두고 연결해 두지 않으면, 터진 뒤에야 "그거 알고 있었는데"가 된다. 이 도구가 지우는 건 리스크를 적는 수고가 아니라, 적어 두고도 잊어버리는 습관이다.