오늘은 문서 구동 개발(Document Driven Development) 에 대해 정리를 해 보겠다.

역사

  • 2007년 10월에 Vincent Massol 이 트위터에 처음으로 언급함
  • 2014년 Zack Supalla 가 본격적으로 이에 대해 github에 정리를 함.

The philosophy behind Documentation-Driven Development is a simple: from the perspective of a user, if a feature is not documented, then it doesn’t exist, and if a feature is documented incorrectly, then it’s broken.

흐름

  1. 문서를 작성
    • 개발대상을 모두 문서화 하여 정리를 하는데, 특히 기능 요구사항을 중심으로 작성하고 필요하다면 비기능 요구사항, DB테이블 정리, ER다이어그램, 화면 전이도, UI등도 같이 작성한다.
  2. 문서들에 대한 피드백 반영
    • 작성된 문서들은 PM이나 다른 동료 엔지니어들로부터 검토를 받고 그들의 피드백을 반영한다.
  3. 개발
    • Test Driven Development 를 추천하며, 이 때는 문서에 테스트 케이스까지 기록되어 있어야 한다.
  4. 개발 도중 변경이 발생하는 경우…
    • 이 부분이 중요한데, 개발 하는 모든 활동은 문서에 있는 내용을 중심으로 이뤄지는게 기본 哲學이다. 변경이 일어나는 경우는 반드시 먼저 문서를 변경하고 다시 이에 대한 피드백을 받은 후 개발 수정이 일어나야 한다.

실제 개발 현장에서 이를 도입하여 실행하기에는 어려움이 많았을 것으로 생각된다. 대부분 현장은 Code First로 운영되어 왔기 때문이다.

하지만 이제 생성형 AI의 출현으로 이 개발 방법이 다시 주목을 받기 시작했다.

문서를 작성하고 피드백을 받는 단계까지는 위 흐름과 동일하다. 혹자는 피드백도 생성형 AI에 맡길수 있지 않겠냐는 생각도 할 수 있겠지만, 프로젝트의 정황을 잘 아는 것은 생성형 AI가 아닌 PM 그리고 여러분의 동료 개발자일 것이다 .

개발 단계에서

  1. 생성형 AI에 문서를 학습 시키기
    • 문서를 텍스트 베이스로 만든 뒤 이를 생성형AI에 학습자료로 제공한다
  2. 생성형 AI에 테스트 코드 생성 시키기
    • 생성형 AI에 테스트 코드를 작성 시키고
    • 필요하면 직접 테스트 코드를 검토 후 조건을 조정해 재작성을 지시할 수 있다.
  3. 생성형 AI를 통한 기능 개발
    • 문서를 적절히 나누어 기능 개발을 시킴
  4. 테스트 코드 통과 체크
    • 테스트 코드를 실행하여 통과를 못한 코드에 대해서는 다시 생성형 AI에 재작성을 요청

만일 개발 도중 변경이 일어나더라도 개발에 대한 부담이 줄기 때문에 바로 변경된 문서를 위 개발 프로세스에 반영하여 다시 실행시키면 될 것이다.

주의할 점

이이즈미 카즈마(飯泉一馬) キリフダ VPoE / GOOD SHARE CTO 는 경험한 DocDD의 주의점에 대해 다음과 같이 정리했다.

  1. 이 방법을 통해 개발이 빨라지지 않는다.
    • 코딩을 생성형 AI에 맡기지만, 생각보다 개발 속도는 빨라지지 않는다. 피드백을 반영하는 부분, 생성형 AI에게 제대로 문서를 이해시키는 작업에 시간이 걸린다
  2. 프로토타입 중심 개발을 하고 있다면 이 방법은 맞지 않다.
    • 이 방법은 한번에 완성을 목표로 하기 때문에 조금씩 프로토타입을 만들면서 개량해 나가는 방법과는 맞지 않다.
    • 장기적으로 운용될 시스템 등 문서화가 중요한 환경에 맞는 방법이다.
  3. 개발 및 도메인 초보자들에는 맞지 않다.
    • 문서를 만들면서 개발을 진행하면 개발 및 도메인 초보자들도 쉽게 할 수 있을거라 생각하지만 그렇지 못했다.
    • 생성형 AI가 만드는 할루시네이션이나 잘못된 정보들을 걸러내는 것은 초보자들은 할 수 없는 영역이기 때문이다.
    • 문서 작성도 가급적 직접 개발할 엔지니어가 하는게 훨씬 좋다. 다른 사람이 문서를 작성하면 또다른 병목이 생긴다.

마치며

소프트웨어 서비스 개발 현장은 여러 현장이 있고 각기 성격도 다르다. 애자일 개발 방법론이 2000년대 초반에 태동되었을 때 가장 심한 반발이 일어났던 곳은 문서화를 중요하게 여기고 있는 대기업들 및 SI 업체들이었다.

문서화를 중요시하는 개발 환경에서는 이 DocDD가 잘 먹힐 수 있을 것 같지만, 애자일 개발 방법이 주는 메리트를 얻을 수 없다는 점은 감안하고 가야 한다.