**스펙 주도 개발(SPEC DRIVEN DEVELOPMENT)**은 구현 코드보다 명세(Specification)를 먼저 정의하고, 그 명세를 기준으로 설계, 구현, 테스트를 진행하는 개발방식이다. 이렇게 작성된 “명세는 시스템이 만족해야하는 계약과 규칙의 SSOT"이다.
AI 시대에 인간의 역할은 코드를 직접 작성하는 것이 아닌, 모호한 문제를 잘 정의하고, 목표와 맥락을 AI에게 전달하여 AI가 구현한 결과물을 검증하는 역할이 되었다고 생각한다. 인간이 이러한 역할을 잘 수행해내기 위한 방법론이 SPEC DRIVEN DEVELOPMENT라고 생각한다.
나는 다음과 같은 Workflow를 사용한다.
- Context Document (Human)
- Write Spec (AI)
- Spec Validation (Human)
- Task Document (Human)
- Task Planning (AI)
- Task Planning Review (Human)
- Implementation by TDD (AI)
- Implementation Review (Human)
- (Before Push) Code Review (AI)
- Apply Code Review Feedback (Human)
- Verification (Human)
- SSOT Update (AI)
- Commit Message Generation (AI)
- Commit & Push (Human)
새로운 기능 구현을 해야하는 경우를 생각해보자. 기획자가 작성한 기획 문서를 통해서 개발자는 문제, 제약조건, 스펙에 대해서 작성을 해야한다. 이것을 Context라고 한다. Context Document를 작성하고 나서 AI에게 이를 잘 구조화하여 Spec으로 만들도록 시킨다. 스펙 문서의 산출물은 다음과 같다.
- Testcase
- Sequence Diagram
- Functional Requirements
- Non-Functional Requirements
- API contracts
- Edge Cases
- Domain Rules
개발자는 작성된 Spec 문서를 검토하고 개선하는 루프를 진행하게 된다. 완성도 있는 Spec 문서를 작성하기 위해서는 Context Document가 최대한 디테일해야 한다. 요구사항에 대한 디테일, 모호한 경계 정의, AI가 하지 말아야할 것을 결정, 제약 조건 등을 디테일하게 정의해야한다.
만약, 인간이 검토가 끝나면 위 스펙 문서들을 프로젝트 루트 하위에 docs(SSOT) 폴더를 만들어서
이동 시키고, AGENTS.md가 docs를 항상 참고하도록 한다. 이렇게 하면 실제 Agents가 구현을
시작할때 SSOT를 항상 참고하게 된다.
이렇게 STEP3(Spec Validation)까지 끝나면 인간은 기능을 완성 시키기 위해서 작업을 Ticket 단위로 쪼개야 한다. 그리고 Ticket을 처리하기 위해 다시 작업에 대한 문제 정의, 목표, 제약조건 등을 AI에게 제시하기 위한 문서를 작성해야 하며 이 단계가 STEP4인 Task Document 단계이다. AI에게 Task Document를 주고 Task Planning을 시키며, AI가 작성한 Planning Document를 인간이 검토한다. 검토가 완료되면 구현을 AI에게 시킨다. 이때 중요한 점은 TEST DRIVEN DEVELOPMENT를 사용하는 것이다.
내 생각에 테스트 코드는 이제 더 이상 인간을 위한 코드가 아니다. 테스트 코드는 AI가 프로젝트를 빠르게 이해하기 위한 정책 문서라고 생각한다. 그리고 TDD는 AI가 구현시 회귀 문제를 일으키지 않도록 하기 위함이며, 프로덕션 코드가 테스트 없이 작성되지 않도록(즉, 검증되지 않은 코드가 작성되지 않도록) 방지하기 위한 도구라고 생각한다. 이렇게 쌓인 테스트 코드들은 추후에 대규모 리팩토링을 진행함에 있어서 회귀 문제를 단 한번도 일으키지 않도록 막아주는데 도움이 된다.
AI의 구현이 완료되면 인간은 구현 리뷰를 진행한다. 이때 AI가 구현이 완료되면 자신이 진행하면서 얻은 인사이트와 여정을 별도 문서로 남기도록 하면 좋다. STEP9, 10은 생략할 수 있고(원격 저장소에 AI 기반 자동 리뷰 시스템이 구축되어있다면 생략해도 된다), 구현 리뷰 단계에서 Verification을 같이 진행할 수 있다.
