1. 개발의 출발점을 바꾸다
최근 CMS 개발을 진행하면서 요구사항 분석 및 설계 단계에서 사용자 메뉴얼을 함께 작성했다.
처음에는 단순히 사용자를 위한 설명서로 생각했지만, 작성할수록 이런 생각이 들었다.
“이 메뉴얼 자체를 기준으로 코딩을 시키면 어떨까?”
즉, 테스트 주도 개발(TDD)처럼 ‘문서 중심 개발(Documentation-Driven Development, 이하 DDD)’ 방식으로,
메뉴얼을 코드 작성의 기준으로 삼는 접근이었다.
놀랍게도, 이건 내가 처음 떠올린 아이디어라고 생각했는데 — 이미 AI 이전 시대부터 존재하던 방법이었다.
2. TDD와 DDD의 공통점과 차이점
| 구분 | TDD (Test-Driven Development) | DDD (Documentation-Driven Development) |
|---|---|---|
| 출발점 | 테스트 코드 | 사용자 메뉴얼 / 기술 문서 |
| 목표 | 테스트 통과를 통한 안정성 확보 | 사용자 중심의 기능 정합성 확보 |
| 검증 방식 | 코드 단위 자동화 테스트 | 문서-코드 정합성, 사용자 흐름 테스트 |
| 중심 철학 | 테스트가 곧 명세다 | 문서가 곧 명세다 |
두 방식은 모두 “코드보다 기준을 먼저 세운다”는 공통점을 갖는다.
TDD가 기능의 정확성을 보장한다면, DDD는 사용자의 관점에서 기능이 올바르게 구현되었는지를 보장한다.
3. AI 코딩 에이전트 시대의 DDD
AI가 개발 현장에 본격적으로 들어오면서, 이 DDD 방식은 새로운 가능성을 얻게 되었다.
과거에는 사람이 직접 문서를 쓰고, 개발자에게 전달하고, 구현을 확인하는 과정이 느렸지만
이제는 AI 코딩 에이전트가 그 연결고리를 자동으로 수행할 수 있다.
- 사용자 메뉴얼 작성 → 코딩 에이전트 입력
메뉴얼의 문장을 자연어 그대로 입력해도 AI는 기능을 코드로 변환할 수 있다.
“관리자가 게시물을 등록할 수 있어야 한다”는 한 문장이 곧 API 엔드포인트와 테스트 케이스로 이어진다. - 문서 변경 → 코드 자동 업데이트
문서가 수정되면, 에이전트가 변경된 부분을 감지해 코드와 테스트를 다시 조정할 수 있다.
즉, 문서가 ‘살아있는 명세’로 작동한다. - 문서-테스트 일체형 개발
AI는 문서를 기반으로 테스트 스크립트까지 자동 생성할 수 있다.
결과적으로 TDD와 DDD가 하나로 통합되는 셈이다.
4. 문서 중심 개발의 장단점 (AI 시대 관점에서)
✅ 장점
- 사용자 관점에서 출발하므로 기능 누락이나 UX 혼선이 줄어듦
- 문서와 코드가 실시간으로 연결되어 개발-기획 간 커뮤니케이션 비용 감소
- AI 코딩 에이전트를 활용하면 문서 작성과 코드 생성 모두 빠르게 진행 가능
⚠️ 단점 (그리고 현실적인 보완책)
과거에는 “문서를 먼저 작성하면 초기 개발 착수가 늦어진다”는 비판이 많았다.
문서화에 시간을 쏟다가 실제 구현이 지연되는 ‘워터폴화’ 경향이 있었기 때문이다.
하지만 AI 코딩 에이전트 시대에는 상황이 다르다.
문서 작성은 빠르게 진행할 수 있지만, 사람의 검토와 승인 과정이 조금 더 중요해졌다.
AI가 빠르게 문서를 구조화하고 코드로 변환하더라도
‘이 문서가 실제 사용자의 흐름을 제대로 반영했는가’에 대한 인간의 판단이 필요하다.
결국, 사람은 ‘품질의 관문’ 역할을 하게 된다.
5. 마무리 — DDD와 TDD의 융합
지금 CMS 개발 프로젝트에서 진행 중인 방식은 이렇게 요약할 수 있다.
사용자 메뉴얼(문서)을 기준으로 기능 정의 → 테스트 시나리오 도출 → AI 코딩 에이전트를 통한 구현
이건 더 이상 단순한 TDD도, 단순한 문서 작업도 아니다.
AI가 TDD와 DDD를 통합한 새로운 개발 패러다임의 중심에 서고 있다.
AI 에이전트는 테스트 코드, 기능 구현, 그리고 문서까지 하나의 순환 흐름으로 만들 수 있다.
결국 개발은 “문서로 생각하고, 테스트로 검증하며, AI로 구현하는” 시대가 된 것이다.
