계획을 통째로 망쳤다. ⌘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 네 개와 함께 통째로 지워 버렸다. 잘못 지운 것이다. 게다가 들여다보는 사이 엉뚱한 노드 하나가 계획에 끼어들었다 — "Blockchain traceability POC", ERP 구축과는 아무 상관 없는 항목이.

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

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

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

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

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

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

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

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

트리가 통째로 제자리로 돌아왔다. 노드는 다시 42개, 없어졌던 Production Module Development 단계가 자식 넷과 함께 되살아났고, 끼어들었던 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는 한 수를 물러 준다. 하지만 계획을 크게 재편하는 날엔, 무르기가 아니라 되돌리기가 필요하다 — 그리고 되돌리기는, 되돌아갈 지점을 미리 만들어 둔 사람에게만 있다.