프로젝트에 이미 요구사항을 관리하는 명세 체계가 있는데, 새 작업 도구가 자기 템플릿부터 만들면 문서가 하나 늘어난다. 정돈된 시작처럼 보이지만 곧 같은 결정을 적는 장소가 두 군데가 된다.
기존 명세의 형식과 저장 위치는 그대로 두는 편이 낫다. 새 작업 흐름이 가져온 질문 정리, 필수 내용 확인, 승인 절차는 그 체계 안에서 적용하면 된다. 검증 규칙을 들여오는 일과 파일 형식을 갈아엎는 일은 묶일 필요가 없다.
명세가 둘이면 이름과 상태가 조금씩 어긋난다. 한쪽에는 결정이 반영됐는데 다른 쪽에는 예전 선택이 남고, 재시작한 작업자는 어느 문서를 기준으로 삼아야 할지 다시 판단해야 한다. 문서가 많아져서 생기는 문제가 아니라 권위 있는 원본이 갈라져서 생기는 문제다.
그렇다고 기존 문서를 무조건 통과시키는 것은 아니다. 필요한 질문이 빠졌는지, 구현 조건과 승인 경계가 적혔는지는 새 절차의 기준으로 확인해야 한다. 부족한 내용은 기존 명세에 보완하고, 담을 수 없는 정보가 분명할 때만 새 형식을 검토한다.
좋은 작업 절차는 자기 문서를 남기는 양으로 증명되지 않는다. 이미 작동하는 명세 체계가 있다면 그 안에서 더 엄격하게 질문하고 검증하는 쪽이 충돌을 줄인다. 새 틀을 추가하는 일은 기존 틀이 실제로 필요한 정보를 담지 못한다는 증거가 나온 뒤에도 늦지 않다.