Experiments never fail

조금전까지 모 용역과제의 문서화작업을 하다가 문득 개발과정에서 문서화는 어떻게 하는 것이 제일 좋은 것일까를 생각해 봤다.

문서는 반드시 필요하다. 아무리 애자일한 방법과 알기 쉬운 코드가 쓰여졌다 하더라도, 이를 설명하는 무언가는 반드시 있어야 한다. 가장 쉽게 떠올릴 수 있는 문서는 사용자 매뉴얼. 매뉴얼이 필요없을 정도로 사용자 인터페이스가 훌륭하다 할지라도, 전반적인 설명을 담는 무언가가 필요하다. (도움말도 일종의 문서이다.) 그밖에도 운영자 메뉴얼, 요구사항 분석서, ERD 등등 프로젝트 결과물 자체를 설명하는 문서를 통해 모르는 사람은 처음 프로젝트를 접했을 때 문서를 읽는 것 만으로 가이드를 받을 수 있다.

폭포수 개발방식은 "분석 -> 설계 -> 구현 -> 시험"으로 이루어져 있고 각 단계별 나와야 하는 문서들이 있다. (그래서 이를 산출물이라고도 한다.) 저 일방향으로만 결과가 만들어진다면 구현 단계에서는 설계의 변화는 없겠으나 아쉽게도 리얼월드에서는 설계의 변화가 자꾸 나오기 마련.

모 데이터베이스 관련 강의에서 들었던 얘기. 강사분이 모 업체의 DB 컨설팅 차원에서 DB 스키마 및 테이블 현황표를 달라고 하면, 이따시만한 두꺼운 문서를 준다고. 그러면서 하는 말. "지금 돌고 있는 버전이랑은 조금 달라요~"

변경내역이 발생할 때마다 문서도 수정하기. 말은 쉬운데 잘 반영하기 힘든 부분이다.

XP에서는 가능한 불필요한(나중에 의미가 없어질) 문서들의 생성을 최소화한다. ERD같은 것도 실시간 자동생성하는 방향으로 프로젝트를 운영한다. 그럼에도 불구하고, 최소한의 문서화는 어느정도 필요하다. 그렇다면 그것의 관리는 어떻게 하는 것이 좋은 것일까?

일단 다음 두가지 방식이 떠오른다.
 1. Documentation --> Test --> Code
 2. Test --> Code --> Documentation

두 방법 모두 장점과 단점이 보인다.

위키피디아에서 V-모델이란 문서를 보았다. 폭포수 모델의 확장된 형태로, 내려갔던 것을 다시 올라가면서 테스트하며 점검한다고. XP와는 살짝 다르지만 노리는 효과는 유사하다. 처음의 유저스토리가 나중의 사용자승인 테스트로 연결되는 것을 본다면, 매우 유사하다고 할 수 있을 듯. V를 다 거친 이후 발생한 변경요구에 대해서는 다시 V를 반복한다.  

이 방법에 문서화를 결합할 수 있을 듯. 혹자가 얘기하는 BDD(Behavior Driven Development)의 장점을 떠올리며 구현 이전에 먼저 문서의 초안을 만드는 것이다. 이는 구현시 실질적인 문제해결에 도움을 줄 것이다. 구현이전의 불확실성으로 인해 나중에 고쳐야 할 점이 생길 것이고, 이것은 저 V-모델처럼 구현 이후에 문서를 점검함으로 해결한다. 이 역시 구현 이후의 변경요청에 대해서는 V를 반복.

위 방법을 습관화하기가 좀 번거로운 면이 없잖다. 그래서 XP에서 얘기하는 것처럼 문서화는 필요한 부분만 간단하게.