이 마감일, 원래 언제였죠?

프로젝트 회의에서 가장 조용해지는 순간이 있다. 누군가 화면 속 날짜 하나를 가리키며 묻는다. "이 마감일 원래 언제였죠?" 아무도 확신 있게 답하지 못한다. 엑셀 계획서에는 현재 값만 남아 있고 이전 값은 누군가 덮어쓴 순간 사라졌다. 메신저를 뒤지고 지난주 회의록을 뒤지다가 결국 "제 기억에는"으로 문장이 시작된다.

이 질문이 사소해 보인다면 운이 좋았던 것이다. 발주처가 낀 프로젝트에서 일정 변경의 근거를 소명하라는 요구는 정기 행사이고, 감리가 들어오면 언제·누가·왜가 문서로 나와야 한다. 그때 PM이 가진 것이 덮어쓰기된 엑셀뿐이라면 소명은 발굴 작업이 된다. 메일함과 회의록을 파헤쳐 날짜를 맞춰야 한다.

지난 편에서 SPI 0.84를 보고 그날 바로 일정을 고쳤다. 기간을 늘렸고, 이름을 다듬었고, 담당을 지정했고, 잘못 넣은 진척률을 정정했다. 이번 편은 그 조정 세션 직후의 복기다. 방금 무엇을 바꿨는지를 기억이 아니라 기록으로 되짚을 수 있는가. 광고가 아니라 실험 기록이므로 기록되는 것과 기록되지 않는 것을 그대로 적는다.

실험 설계: 방금 일어난 일을 되짚는다

무대는 지난 편 그대로다. 실행 7주차의 44노드 ERP 프로젝트이고, 캡처 시점에 맞춰 날짜를 다시 맞춘 복제 프로젝트(화면 코드 MCG-26B)라는 점도 같다. 조정 세션에서 직접 바꾼 것은 5가지다.

이 5가지가 화면에 어떻게 남았는지가 이번 실험의 전부다.

"엑셀에도 변경 내용 추적이 있잖아요"라는 반론이 있을 수 있다. 있다. 켜져 있다면, 그리고 아무도 '변경 내용 모두 적용'을 누르지 않았다면, 그리고 파일이 최종_수정_진짜최종_v3.xlsx로 갈라지지 않았다면 그렇다. 공유 문서의 이력은 켜야 하는 기능이고, 켜는 일은 잊힌다. 여기서 확인하려는 것은 반대 방향이다. 끌 수 없는 이력, 기본값이 기록인 상태다.

노드의 이력: 이전 값, 새 값, 누가, 언제

상세 패널에는 탭이 2개 있다. 상세와 변경 이력이다. 기간을 늘렸던 마이그레이션 실행·검증 노드의 변경 이력 탭을 연다.

행 하나가 문장 하나다. 기간 7d → 10d 외 1건, 김PM, 22:32. 이전 값에 취소선이 그어지고 새 값이 굵게 표시된다. 마감일이 왜 이 날짜인지 궁금한 사람은 이제 회의록이 아니라 이 탭을 연다. 원래 7일이었고 조정 세션에서 10일로 늘었다는 사실이 바로 나온다.

시각이 "3일 전" 같은 어림이 아니라 절대시각으로 남는 것도 복기에는 중요하다. "어제쯤 바꿨어요"와 "22시 32분에 바꿨다"의 차이는 그 변경이 회의 전이었는지 후였는지를 가른다. 순서가 책임을 가르는 날이 온다.

"외 1건"이라는 표시도 눈여겨볼 만하다. 기간을 늘린 뒤 이름을 연달아 두 번 고쳤는데, 편집 3번이 3행이 되면 이력은 금세 지저분해진다. 같은 노드를 연속으로 만진 편집은 한 행으로 병합되고, 사이에 다른 편집이 끼면 새 행으로 갈라진다. 이력이 타자 기록이 아니라 요약본으로 남는 이유다.

이번 실연은 김PM 혼자 진행했지만, 아바타가 붙는 이유는 여럿이 함께 작업할 때 드러난다. 계획을 여러 사람이 같이 만지는 순간부터 "누가"는 장식이 아니라 본문이다. 발주처 담당이 고친 날짜인지 팀 리드가 고친 날짜인지에 따라 다음 행동이 달라진다. 이력의 각 행이 사람 얼굴로 시작하는 것은 그 질문에 미리 답해 두는 장치다.

정정의 기록, 담당자 지정의 기록

레거시 데이터 정제 노드에서는 다른 모양이 보인다.

진척률 0% → 9%가 22:20에, 9% → 12%가 22:32에 기록됐다. 처음 넣은 9%가 실측과 달라 12%로 고친 과정이 두 행으로 남았다. 엑셀이라면 12%라는 최종값만 남고 원래 9%로 보고했었다는 사실은 사라진다. 진척률처럼 보고와 직결되는 숫자는 최종값 못지않게 고쳐진 적이 있다는 사실이 중요한 정보다.

기록이 남는다는 것은 정정의 부담이 줄어든다는 뜻이기도 하다. 고친 흔적이 사라지는 도구에서는 정정이 은폐처럼 보일까 봐 잘못된 숫자를 그대로 끌고 가는 팀이 생긴다. 흔적이 남으면 반대가 된다. 9를 12로 고친 기록은 감추기가 아니라 성실하게 관리했다는 증거가 된다. 4편에서 말한 정직한 진척 관리의 절반은 문화 문제인데, 문화는 이런 작은 구조에서 자란다.

담당자를 지정한 회계 기능 개발 노드에도 행이 남았다. 담당자 변경, 22:32이다. 패널 헤더에는 김PM 아바타가 들어섰다.

프로젝트 전체의 활동 피드

노드 단위 복기는 패널이면 충분하다. 그런데 조정 세션처럼 여러 노드를 한꺼번에 만진 날은 오늘 이 프로젝트에 무슨 일이 있었는지를 한 화면에서 봐야 한다. Overview의 최근 활동 카드가 그 역할을 한다.

조정 세션 4건이 맨 위에 나란히 있다. 진척률 정정, 담당자 변경, 기간 연장, 그리고 선행 1.9.2 (FS) 추가까지, 종속 관계를 새로 그은 것도 피드에 잡힌다. 필드 편집만 기록하는 이력이라면 절반짜리다. 일정을 실제로 움직이는 것은 날짜 입력보다 종속 관계를 긋고 지우는 일인 경우가 많은데, 그것도 여기 남는다.

피드 아래쪽에는 13분 전의 기록이 보인다. 진척률 일괄 입력의 흔적이다. 진척률 0% → 100%, 0% → 31% 하는 식으로 노드마다 한 줄씩 있다. 기록은 편집의 경중을 가리지 않는다. 정례 입력도 한밤의 급한 수정도 같은 무게로 남는다. 피드에서는 "1분 전" 같은 상대시각으로 흐름을 훑고, 특정 건이 궁금하면 그 노드의 패널 탭에서 절대시각으로 확인한다. 두 화면의 역할이 나뉘어 있다.

기준과 기록, 그리고 기록되지 않는 것

지난 편의 베이스라인과 이번 편의 이력은 자주 헷갈린다. 역할이 다르다. 베이스라인은 계획이 원래 어땠는지를 알려주는 기준점이고, 동결된 스냅샷 하나다. 변경 이력은 누가 언제 무엇을 만졌는지를 알려주는 기록이다. 앞의 것이 없으면 얼마나 밀렸는지 못 재고, 뒤의 것이 없으면 왜 바뀌었는지 못 찾는다.

세 가지를 구분하면 그림이 완성된다. 3편에서 다룬 변경통제(CR·CCB)는 변경을 승인하는 절차고, 이력은 변경을 관찰하는 기록이다. 이력은 아무것도 막지 않는다. 잘못된 수정도 그대로 기록한다. 막는 일은 권한과 변경통제가 맡고, 이력이 할 일은 무슨 일이 있었는지에 대해 거짓말하지 않는 것이다. 관찰이 정확해야 통제도 설 수 있다.

이 이력에는 의도된 공백이 하나 있다. 기간을 3일 늘렸을 때 CPM은 후행 작업들의 날짜를 줄줄이 다시 계산했다. 그런데 그 파생 이동은 어느 노드의 이력에도 없다. 기록되는 것은 사람의 직접 편집뿐이다. 처음에는 누락처럼 보였는데 생각할수록 맞는 설계다. 파생까지 기록하면 편집 한 번에 이력 수십 행이 쏟아져 정작 사람의 결정이 묻힌다. 다만 그 결과 "이 날짜 왜 바뀌었죠?"의 답이 이력 탭에 없는 경우가 생긴다. 그 답은 종속 관계와 간트에 있다. 어느 화면이 어느 질문에 답하는지 아는 것도 도구 사용법의 일부다.

아직 안 되는 것

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

• 병합된 행은 펼칠 수 없다. "외 1건"에 접힌 개별 변경, 이 경우 이름 수정 두 번의 상세를 다시 볼 방법이 없다. 병합은 소음을 줄이지만 가끔은 그 소음이 증거가 된다.
• 담당자 변경은 값이 안 보인다. "담당자 변경"이라는 사실만 남고 누구에서 누구로 바뀌었는지는 표시되지 않는다. 인수인계 추적에는 아직 부족하다.
• 파생 변경은 기록되지 않는다. 위에서 설계 의도라고 설명했지만 트레이드오프인 것은 분명하다. CPM이 옮긴 날짜의 이유는 이력이 아니라 종속 관계에서 찾아야 한다.
• 이력에서 되돌릴 수 없다. 조회 전용이다. 실행 취소(⌘Z)는 편집 세션 안에서만 동작하고, 이력 행을 눌러 그 시점으로 복원하는 기능은 없다.

맺음

감사(audit)라는 말은 거창하지만 실무에서 이력이 하는 일은 소박하다. "제 기억에는"으로 시작하는 문장을 회의에서 없애는 것이다. 원래 값이 있고 바꾼 사람이 있고 바꾼 시각이 있으면 기억력 대결은 끝난다. 남는 논쟁은 그래서 다음에 어떻게 할 것인가뿐인데, 그것이 원래 회의가 해야 할 일이다.

이번 실험에서 확인한 것은 그 소박한 일이 실제로 되는가였다. 조정 세션의 5가지 변경 중 5가지가 모두 어딘가에 남았다. 4가지는 값과 함께, 담당자 변경 하나는 사실만 남았다. 완벽하지는 않지만 "이 마감일 원래 언제였죠?"라는 이 글의 첫 질문에는 이제 화면이 답한다. 원래 7일이었고 지난 조정에서 10일로 늘렸다고, 그 자리에서 그 시각과 함께 답한다.

이력은 무엇이 바뀌었는지까지 답했다. 그런데 조정 세션에는 아직 풀지 않은 문제가 있다. 기간을 3일 늘렸을 뿐인데 왜 오픈 날짜가 통째로 밀렸는가. 그리고 그 전에는 왜 3일을 늘렸는데도 아무것도 밀리지 않았는가. 답은 작업 사이의 종속 관계에 있다. 다음 편에서 그 관계를 따라간다.