계획을 통째로 망쳤다. ⌘Z로는 부족했다

지난 세 편은 하나로 이어진 이야기였다. 리스크가 발목을 잡았고(9편), SPI가 지연을 숫자로 보여줬고(10편), 변경 이력이 대응을 기록했고, 종속 관계 그래프가 지연이 어디까지 영향을 주는지 계산했다(12편). 네 화면이 답한 질문은 하나다. 계획과 현실이 어긋날 때 다음 결정을 무엇에 근거할 것인가.

그 세 편이 다룬 것은 전부 바깥에서 온 지연이다. 레거시 데이터가 말썽이었고, 마이그레이션이 늦었고, 빠진 종속 관계 하나가 연쇄 지연을 일으켰다. PM이 잘못한 것이 아니라 현실이 계획을 밀어냈다. 이번 편은 반대쪽을 본다. 안에서 낸 사고, 계획을 고치다가 PM이 자기 손으로 크게 망가뜨리는 순간이다.

실행에 들어간 계획은 죽은 문서가 아니다. 매주 손이 간다. 기간을 늘리고, 종속 관계를 다시 걸고, 단계를 재편한다. 대부분은 작은 수정이다. 그러다 하루, 편집이 크게 어긋난다. 단계 하나를 통째로 잘못 지우거나 재구조화가 트리를 엉키게 한다. ⌘Z(실행 취소)는 한 수를 무른다. 하지만 편집 열 번이 뒤엉킨 상황에서는 한 수씩 되짚는 것으로 부족하다. 필요한 것은 계획 전체를 저장 시점으로 되돌리는 스냅샷이다.

광고가 아니라 실험 기록이므로 되는 것과 안 되는 것을 그대로 적는다. 하나 더 밝혀 둘 것이 있다. 이번 실연의 화면은 앞선 편들의 한국어 프로젝트가 아니라 WBS 항목까지 영어로 되어 있는 별도의 ERP 구축 복제본(MFG-ERP Next-Gen Build)에서 찍었다. 캡처의 언어가 다른 이유다. 무대의 성격은 같다.

무대: 42개 노드, 그리고 이미 잡혀 있던 BL-1

무대는 6개월짜리 제조사 ERP 구축이다. 요약 12개, Work Package 29개, 마일스톤 1개로 42개 노드, 종속성 36건, 마지막 마일스톤은 "System Go-Live"다. 착수 시점에 계획을 동결한 BL-1이 이미 하나 잡혀 있다. 3편에서 "일정이 밀린 게 아니라 기준이 사라진 것"이라고 말한 그 원본이다.

여기까지는 앞선 편들에서 본 베이스라인의 두 가지 쓰임이다. 원본의 기억(3편)과 측정 기준(10편에서 SPI의 분모)이다. 이번 편은 세 번째 쓰임을 다룬다. 되돌아갈 지점이다.

체크포인트: 위험한 편집 직전에 기준을 하나 더 만든다

이제 계획을 크게 손볼 참이다. 모듈 구성을 재편하려는데, 이런 편집은 잘못되면 크게 잘못된다. 그래서 손대기 전에 먼저 할 일이 있다. 체크포인트를 하나 만든다.

Settings ▸ Baseline에서 Re-baseline을 누르면 BL-2가 만들어진다. 라벨은 자동으로 번호가 붙고, 메모에 "Checkpoint before scope restructuring"이라고 적었다. BL-1은 비활성 이력으로 내려가고 BL-2가 활성이 된다.

이 화면에 이번 편의 두 가지가 다 들어 있다. 하나는 누적된 베이스라인이다. 프로젝트당 활성은 하나지만 이력은 여러 개가 쌓인다(한도는 10개). 재계획은 원본을 몰래 고치는 것이 아니라 새 기준을 다시 세우는 일이고, 그 이력이 남는다. 다른 하나는 각 이력 줄에 붙은 Restore to this state다. 계획을 그 스냅샷 상태로 통째로 되돌리는 버튼이다. 지금은 쓰지 않는다. 곧 필요해진다.

사고: 단계 하나가 사라지고 엉뚱한 것이 끼어든다

재편을 시작한다. 그리고 여기서 사고가 난다. "Production Module Development" 단계를 하위 Work Package 4개와 함께 통째로 지워 버렸다. 잘못 지운 것이다. 게다가 들여다보는 사이 엉뚱한 노드 하나가 계획에 끼어들었다. ERP 구축과는 상관없는 "Blockchain traceability POC" 항목이다.

트리가 조용히 어긋났다. 42개였던 노드가 38개가 됐다. 5개가 사라지고 1개가 끼어들었다. 코드는 자동으로 다시 매겨져서 없어진 자리조차 표시되지 않는다(원래 1.7이던 Purchasing이 1.6으로 당겨졌다). 눈에 걸리는 것은 맨 아래 이물질뿐이고, 정작 큰 손실인 모듈 하나가 통째로 날아간 것은 화면만 봐서는 잘 드러나지 않는다. 이것이 안에서 낸 사고의 무서운 점이다. 바깥에서 온 지연은 SPI가 붉게 경고해 주지만, 내 손이 낸 실수는 아무도 경고해 주지 않는다.

⌘Z로 한 수씩 되짚을 수도 있다. 하지만 삭제와 추가와 그 사이 다른 편집이 뒤엉켰다면 어디까지 되짚어야 정확히 그 상태로 돌아가는지 확신할 수 없다. 그래서 무르기 대신 되돌리기를 쓴다.

복원: 무엇이 바뀔지 먼저 보여주고 확인을 받는다

BL-2 옆의 Restore to this state를 누른다. 실행 전에 모달이 뜬다. 이 모달이 이번 편의 핵심이다.

모달은 되돌리기 전에 무엇이 바뀔지를 숫자 3개로 먼저 보여준다. 37 updated, 5 restored, 1 deleted다. 스냅샷과 현재 트리를 대조한 결과다. 37개는 스냅샷 값으로 갱신되고, 5개는 되살아나고(지워졌던 Production 단계와 그 자식 4개), 1개는 삭제된다. 삭제되는 노드는 이름까지 밝힌다. Blockchain traceability POC다. 되돌리면 무엇이 사라지는지 눈으로 확인하고 진행하라는 뜻이다.

안내문이 3가지를 약속한다. 첫째, 복원 직전 상태는 자동 백업 베이스라인으로 보관된다. 되돌리기 자체도 되돌릴 수 있다. 둘째, 진척률은 보존된다. 계획을 되돌려도 팀이 쌓은 실적은 지우지 않는다. 셋째, 일정은 재계산된다. 그리고 마지막 관문이 있다. "Type BL-2 to confirm." 라벨을 손으로 다시 입력해야 Restore 버튼이 열린다. 되돌릴 수 없는 동작 앞에 일부러 만들어 둔 절차다.

되돌린 뒤: 구멍이 메워지고 실적은 그대로다

BL-2를 입력하고 Restore를 누른다.

트리가 통째로 제자리로 돌아왔다. 노드는 다시 42개가 됐고, 없어졌던 Production Module Development 단계가 자식 4개와 함께 되살아났고, 끼어들었던 Blockchain 노드는 사라졌다. 중요한 것은 되살아난 Production feature build의 진척률이 여전히 20%라는 점이다. 계획은 스냅샷으로 되돌아갔지만 팀이 넣은 실적은 그대로다. 되돌리기가 지운 것은 구조의 실수였지 일한 기록이 아니다.

그리고 약속대로 안전망이 하나 남았다.

Baseline history에 "Backup before restoring BL-2"라는 줄이 새로 생겼다. 노드 수가 38개다. 조금 전 망가진 상태를 그대로 담은 백업이다. 되돌리기 직전의 상태가 사라지지 않고 이력에 남았다. 혹시 그 편집 중에 살릴 것이 있었다면 이 백업으로 다시 되돌릴 수 있다. 되돌리기가 또 하나의 되돌아갈 지점을 남긴 것이다.

아직 안 되는 것

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

• 전부 되돌리거나 아예 안 되돌리거나 둘 중 하나다. 필드 단위 부분 복원은 없다. "구조만 되돌리고 그동안 바꾼 이름은 살려 달라"는 안 된다. 되돌리면 스냅샷 이후의 좋은 편집까지 함께 되돌아간다. 그래서 큰 편집 전에 체크포인트를 자주 만드는 습관이 유일한 방어다.
• Dictionary와 코멘트는 되돌아오지 않는다. 스냅샷이 담는 것은 트리 구조·일정·종속 관계이지 WBS Dictionary 항목이나 코멘트가 아니다. 되살아난 노드의 정의서는 삭제 시점 값이 남아 있으면 그대로지만, 스냅샷이 복원해 주지는 않는다.
• schedule_mode는 스냅샷에 담기지 않는다. 베이스라인 수립 뒤 auto와 manual을 바꾼 노드는 복원해도 그 시점 모드로 정확히 돌아가지 않아 날짜가 스냅샷과 다르게 계산될 수 있다. 알려진 한계다.
• 자동 백업이 베이스라인 한 자리를 쓴다. 이력은 10개까지다. 백업이 한 칸을 차지하므로 복원을 시작하려면 그 시점에 베이스라인이 9개 이하여야 한다. 꽉 차 있으면 오래된 것을 지우고 다시 시도하라고 안내한다.
• 진척률은 복원 대상이 아니다. 위에서 장점으로 적은 바로 그것이 한계이기도 하다. 되돌리는 것은 계획이지 실적이 아니다. 그때의 진척률로 통째로 돌아가는 것은 이 기능이 하는 일이 아니다.

맺음

앞선 세 편이 다룬 지연은 전부 바깥에서 왔고, 도구가 한 일은 그것을 숫자로 드러내는 것이었다. 이번 편의 사고는 안에서 났고, 도구가 한 일은 다르다. 저장 시점으로 통째로 되돌리는 것이다. 지연은 발견의 문제였지만 실수는 복구의 문제다.

베이스라인의 세 가지 쓰임이 이제 다 나왔다. 착수 시점의 계획을 기억하고(3편), 실행의 편차를 재고(10편), 손이 미끄러졌을 때 되돌아갈 지점이 된다(이번 편). 셋은 같은 스냅샷의 다른 쓰임이다. 엑셀 계획서의 "기준 시트"가 이 셋을 다 못 하는 이유는 그 시트를 편집할 수 있기 때문이다. 기억은 덮어써지고, 기준은 늘어나고, 되돌아갈 지점은 애초에 없다.

이번 주에 자기 계획에서 큰 편집에 손대기 직전에 한 번 멈춰 보자. 되돌아갈 지점을 하나 만들어 두었는가. ⌘Z는 한 수를 물러 준다. 하지만 계획을 크게 재편하는 날에는 무르기가 아니라 되돌리기가 필요하고, 되돌리기는 되돌아갈 지점을 미리 만들어 둔 사람만 쓸 수 있다.