스펙문서의 존재 이유는 구현 시작 전에 팀이 제품에 대한 이해를 같이 하기 위함이다. 잘 만든 스펙은 그 자체가 사용자 스토리 단위로 쪼개질 수 있고, 그것은 다시 할 일 목록으로 쪼개져, 결국에는 버그라는 작은 단위로 환원된다.

개발이 끝난 다음에 스펙을 유지보수해야 되는가? 이미 구현 완료된 스펙이라면, 그럴 필요가 없다고 생각된다. 스펙에 언급한 내용들이 모두 코드가 되어 working software 로 만들어 졌다면, 스펙문서는 자신의 할 일을 다한 셈이다.

스펙 문서의 life cycle 이 시한부임을 이해한다면, 스펙문서에 피드백을 줘야하는 시기도 분명히 한정되어 있음을 알 수 있을 것이다. 스펙은 코딩 시작 전 또는 개발 초기에 최대한 피드백을 받아야 한다. 스펙을 리뷰해야 하는 것은 개발자들의 의무이기도 하다.

지난 스프린트의 작업 목록에 해당하는 스펙을 제대로 리뷰하지 않고 지나갔다. 담당 개발자들에게 리뷰를 부탁했으나 그리 철저한 리뷰는 이뤄지지 않았다. 팀 이외의 사람들과도 리뷰를 했었어야 됐으나 하지 못했다. 그 당시에는 구현해야하는 목표점이 분명하고 이미 정해져 있었기 때문에, 굳이 그럴 필요가 없었다고 느꼈기 때문이다. 지금와서 생각해보면 모두가 당연하다고 여기는 부분을 명시적으로 확인받기 위해서라도 임원등에 의한 리뷰를 했었으면 좋았을 것 같다.

스펙 문서를 계약으로 여기려고 하는 듯한 기류도 감지되는데, 이 부분은 조금 더 관찰해보고 그래선 안된다고 정확히 이야기해야 될 것 같다. 스펙을 stabilize 하고 개발을 시작하는 이유는 목표와 부합되지 않는 개발을 하지 않기 위해서이지, 스펙 문서를 누군가의 족쇄로 만들기 위함이 아니다.