공급망의 채찍효과, 그리고 기획 부채의 복리

취업 전에 공부했던 공급망 관리(SCM) 개념이 떠올랐다. Bullwhip Effect. 예전에 벌려둔 일이 적시뿐만 아니라 나중에 영향을 미친다는 이론. 유통에서만 발생하는 줄 알았는데, 기획서에도 똑같이 적용되더라. 내가 초반에 형편없이 작성한 기획서는 리뷰 단계에서, 테스트 단계에서, 심지어 배포 후에도 채찍처럼 돌아와 내 발목을 잡았다.
처음 작성한 '엑셀 다운로드 버튼 추가_v1'이 그랬다. 권한 검증 로직을 빼먹었고, 데이터 로깅을 안 했다. 리뷰에서 지적당했다. "보안 취약점 있어요." 테스트에서 발견했다. "관리자가 다운로드 이력을 모르겠는데요?" 배포 후에 사고가 났다. "권한 없는 사용자가 고객 데이터 다운로드했어요." 그래서 수정했다. '엑셀 다운로드 버튼 수정_v2'를 만들었다. 하지만 v2는 v1의 결함을 메우기에 급급했고, v3는 v2의 레거시를 끌고 갔다. 이게 바로 기획 부채(Planning Debt)의 복리였다. 1%의 결함이 7년 차엔 107%의 부채가 되어 있었다.
잘해보자고 다짐해도, 예전에 벌려둔 일이 발목을 잡았다. 새로운 프로젝트를 맡으면, 먼저 기존 시스템부터 파악해야 했다. 하지만 그 시스템의 기획서는 파편화되어 있었고, 테스트 케이스는 부실했다. "이번엔 다르게 해보겠다"고 시작해도, 어느 순간 "아, 이건 예전에 내가 놓친 부분이네"라고 깨달았다. Regression Testing의 대상이 내 자신이었다. 과거의 나를 수정해야 현재의 나가 진행될 수 있었다.
업무 진척도 안 되고, 뭘 잘해야 할지도 모르겠다. 이건 단순한 정치력 부족이 아니었다. 요구사항 추적성(Requirement Traceability)이 완전히 무너진 상태였다. 내가 3년 차에 작성한 기획서가 5년 차의 프로젝트를 망쳤고, 그게 다시 7년 차의 평가를 망쳤다. Bullwhip Effect는 공급망에서 재고를 왜곡시키지만, 조직에서는 개인의 신뢰를 왜곡시켰다. 초반의 몇 번의 실수가, 시간이 지나면서 '이 사람은 실수를 반복하는 사람'이라는 레이블이 되었고, 그 레이블이 더 많은 실수를 만들었다.
코드는 리팩토링(Refactoring)할 수 있지만, 기획서는 리팩토링할 수 없었다. 왜냐하면 코드는 Git에 히스토리가 남지만, 기획서는 파일 서버에 final_v3_really_final_v2.docx로 쌓이기 때문이다. Legacy Code는 주석으로 설명할 수 있지만, Legacy Spec은 아무도 설명해주지 않는다.
결국 이것이 2연속 진급 누락의 가장 큰 원인이었다. 정치력이 없어서가 아니라, 7년 동안 쌓인 기술 부채가 너무 커서, 그 부채를 상환하기도 전에 새로운 대출(새 프로젝트)을 받아야 했기 때문이다. 평가자는 "이 사람은 과거 실수를 반복하지 않고 성장했다"고 보지 못했다. 왜냐하면 그 실수의 흔적이 아직 운영 서버에 살아 있었으니까.