문서 주도 개발(Document Driven Development)이란?

문서 주도 개발(Document Driven Development)이란?

새로운 DDD에 대해서 알게 되어 흥미를 느꼈고 이 글을 쓰는 계기가 되었다. 기존에 DDD라고 하면 도메인 주도 개발, 혹은 도메인 주도 설계를 의미하는 Domain Driven Development를 의미했는데 요즘엔 아주 간간히 이 단어를 볼 수 있다. 새로이 뜨는...? 뜬다기보단 그냥 수면 밑바닥 언저리에서 은근히 쓰이는 말이라고 볼 수 있다.

 

TDD, D(Domain)DD가 각자의 성격을 갖고 있듯이 D(Document)DD도 고유의 성격을 갖고 있다. 이름에서 유추할 수 있듯이 이 방법론은 문서화를 중요시하는 것이며 다음과 같은 특징을 갖고 있다.

 

문서주도개발 방법은 상당히 심플한 컨셉이다.

문서화되지 않은 기능은 없는 기능이며, 문서화가 잘못돼있다면 기능이 손상된 것이다.

이것이 문서 주도 개발의 근간이 되는 개념이며 정수이다. 이 말에서 알 수 있다시피 문서 주도 개발이라는 것도 결국엔 어플리케이션을 만들 때 쓰는 방법론의 일종이라고 할 수 있겠지만 그 주체가 어플리케이션이 아닌 문서가 된다. 물론 새로운 기능을 개발할 때도 먼저 문서에 작성해놓고 시작한다. 조금 어폐가 있는 말이긴 하다. 어플리케이션을 만드는데 어플리케이션이 아닌 문서가 주가 된다는 것 자체가 말이다.

 

그래서 이 DDD개념은 주로 웹페이지보단 API를 만들 때 쓰인다. 외국 포럼에서 이 DDD에 대해 정리한 글에 Documentation is the best way to define a feature in a user's eyes.라는 말이 있는 걸로 봐선 말이다. 문서를 보는 사용자는 곧 개발자를 의미하며, 문서가 필수로 요구되는 어플리케이션은 API이니 말이다.

 그리고 이와 더불어 기능의 변경에 있어서도 문서 변경의 선행, TDD의 도입을 통한 변경부분의 유닛 테스트 등을 요구하기도 한다. 이에 대해 흥미가 있다면 이에 대한 토픽을 다루고 있는 깃허브 기스트를 읽어보는 걸 추천한다. API를 개발하는 회사, 혹은 개인이라면 이 DDD의 도입이 어플리케이션 품질을 올리는 데에 꽤나 큰 역할을 할 수 있을 것 같다.