도제식으로 배운 기획, 그리고 자가증식하는 스토리보드

나는 도제식으로 기획을 배웠다. 첫 업무가 엑셀 다운로드 버튼 추가였듯, 두 번째는 그 버튼이 뱉어낼 데이터의 컬럼 순서 정하기였다. 세 번째는 컬럼명을 클릭하면 정렬이 되어야 하는지, 여부였다. 팀장은 말했다. "어드민 화면 그리드 그대로 엑셀에 옮기면 된다. 간단하지?" 그렇게 간단한 문제들이 쌓여 '업무 경력'이 되었다.

하지간 단순함의 댓가는 파편화였다. 각 기능마다 1페이지짜리 스토리보드가 생성되었다. '엑셀 다운로드 버튼 추가_기획서_v1', '다운로드 데이터 항목 수정_v2', '정렬 기능 추가_v3'. 동일한 메뉴에 대한 수정이었지만, 파일은 각각 존재했다. 개발자는 매번 새 파일을 열어야 했고, 나는 매번 "이전 파일과 비교해서 봐주세요"라고 요청해야 했다.

이게 바로 기술 부채(Technical Debt)의 기획 버전이었다. 나중에 돌이켜보니, 그것은 '기획 부채(Planning Debt)'였다. 하나의 기능이 자가증식하듯 파일을 양산했고, 결국엔 아무도 전체 맥락을 파악할 수 없는 상황이 되었다. 팀장이 "그거 언제 한 거요?"라고 물으면 나는 파일을 열어야만 기억이 났다. 내 기억력이 아니라, 브라우저 히스토리가 나의 경력이었다.

왜 그랬을까? 변명하자면, 밑도 끝도 없을 것 같아서였다. 서비스의 어드민을 수정한다면, 사용자 등록부터 시작해야 하는 게 맞는지, 권한 관리는 어떻게 연결되는지, 배치 작업은 어떻게 되는지 알아보기 시작하면 끝이 없었다. 그래서 당장 눈에 보이는 것만 보고 처리했다. 이것이 린(Lean)이 아닌, 나태(Lazy)였다.

개발자는 나를 어떻게 봤을까?  "기획자가 요구사항을 깊게 파지 않으면, 개발자가 그걸 메우려다 결국엔 우리가 욕먹어요." 그는 나의 겸손한 '요청서'를 높은 수준의 기획으로 봐준 게 아니었다. 그냥 고객사(Internal Client)가 엉성해서 알아서 했을 뿐이었다. 그리고 그 댓가는 내게로 돌아왔다.

스토리보드가 자가증식하는 동안, 나의 평판은 자가감소하고 있었다. 팀장은 "기획서가 왜 이렇게 많아요?"라고 물었다. 나는 "버전 관리 차원에서요"라고 대답했다. 하지만 그는 알고 있었다. 버전이 많다는 건, 처음부터 완성도가 낮았다는 증거라는 걸.