Spec-Driven Development를 위한 EPIC 프레임워크

우리가 인터뷰한 한 실무자는 코딩 에이전트에게 지시할 때 'should' 대신 'must'를 사용한다고 말했습니다. 왜냐하면 에이전트는 'should'를 선택 사항으로 간주할 수 있기 때문입니다. 사소한 단어 선택이 중요한데, 이는 에이전트가 종종 지침의 빈틈을 자체 가정으로 채우기 때문입니다. Spec-driven development (SDD)는 개발자에게 코드를 작성하기 전에 명세(specification), 계획(plan), 작업(tasks)을 작성하도록 요구합니다. SDD 프레임워크는 이러한 아티팩트들을 위한 템플릿을 제공하지만, 이 템플릿들은 개발자가 충분하거나 충분히 명확하게 작성했는지 판단하는 데 도움을 주지 못합니다. 우리는 좋은 SDD 명세가 무엇을 포함해야 하는지 연구했습니다. 우리는 114개의 오픈 소스 SDD 저장소의 아티팩트들을 ISO/IEC/IEEE 29148에 따라 점수화하고, 최고점을 받은 것들로부터 관행(practices)을 도출했습니다. 그 결과로 나온 프레임워크인 EPIC은 코딩 에이전트를 위한 명세, 계획 및 작업에서 기대치와 결정을 명시적으로 만드는 데 개발자들을 안내하는 10가지 품질 차원과 40가지 관행으로 구성되어 있습니다. 대부분의 SDD 실무자(N=15)는 모든 관행에 동의했습니다. 명세 품질 상위 3분의 1에 속한 저장소들은 버그 수정에 커밋 시간의 11.8%를 사용한 반면, 하위 3분의 1은 20.4%를 사용했으며, 기여자(contributors)는 중앙값이 4배 더 많았습니다. 개발자들은 에이전트가 하기 전에 EPIC을 사용하여 명세의 빈틈을 찾고 채울 수 있습니다.