명세 우선 에이전트 개발: AI 기반 엔지니어링을 위한 새로운 워크플로우

명세 우선 개발의 핵심 원칙

명세 우선 에이전트 개발은 AI 코딩의 패러다임을 반복적인 프롬프팅에서 구조화된 게이트 체크 프로세스로 전환합니다. 에이전트가 구현 전에 YAML 기반 명세를 작성하도록 요구함으로써, 이 워크플로우는 목표, 제약 조건 및 '완료'의 정의가 기존 코드베이스와 비교하여 명시적으로 검토되도록 보장합니다. 이 접근 방식은 에이전트가 제안된 변경 사항에 대한 증거로 특정 파일과 코드 라인을 인용하도록 강제함으로써 "바이브 코딩(vibe coding)"에서 흔히 발견되는 모호함을 제거하는 것을 목표로 합니다.

4단계 수명 주기

모든 작업은 시스템 무결성을 유지하기 위해 설계된 엄격한 4단계 프로세스를 따릅니다:

create-spec: 에이전트는 애플리케이션 코드를 작성하지 않고 목표, 필수 단계 및 사실(파일/라인 인용 포함)을 정의합니다.
review-spec: 이전 대화 기록이 없는 새로운 에이전트 인스턴스가 현재 코드베이스와 비교하여 명세를 평가하고 잠재적인 충돌이나 누락된 요구 사항을 식별합니다.
apply-spec: 에이전트는 검토된 명세를 엄격히 준수하여 코드, 연결 및 테스트를 구현합니다.
deliver-spec: 변경 사항은 풀 리퀘스트가 열리기 전에 모든 테스트 및 빌드 단계가 통과되었는지 확인하는 커밋 게이트를 통해 푸시됩니다.

병렬 실행 및 상태 관리

개발을 확장하기 위해 시스템은 모든 명세에 대해 개별 브랜치와 워크트리를 사용합니다. ID는 시스템 시계에서 생성되므로 동시 실행되는 에이전트들이 충돌 없이 서로 다른 기능을 작업할 수 있습니다. 상태는 context.yaml 파일에 유지되어 에이전트가 중단 후에도 작업을 재개할 수 있습니다. 더 큰 기능의 경우 deliver-series 명령을 통해 개발자가 여러 명세를 그룹화하고, 의존성이 허용하는 경우 병렬로 빌드하여 단일 풀 리퀘스트로 병합할 수 있습니다.

부수 효과로서의 문서화

이 방법의 주요 장점 중 하나는 프로젝트 기록이 자동으로 생성된다는 것입니다. 에이전트가 빌드하는 동안 YAML 파일에 명확하지 않은 모든 결정을 기록하여 아키텍처 선택의 근거(예: 특정 라이브러리를 다른 라이브러리보다 선택한 이유)를 포착합니다. 이는 코드와 함께 존재하는 프로젝트 진화의 살아있는 기록을 생성하여 별도의 오래된 위키 문서를 유지 관리할 필요를 없애줍니다.

커뮤니티 관점 및 비판

이 접근 방식은 에이전트 워크플로우를 관리하는 구조화된 방법을 제공하지만, 커뮤니티 토론에서는 실제 환경에서 명세 기반 개발의 효율성에 대한 몇 가지 일반적인 우려 사항이 강조됩니다:

"코드가 곧 명세다"라는 주장: 일부 개발자들은 진정으로 정확한 명세는 사실상 코드와 다를 바 없으며, 별도의 문서로 복잡한 시스템을 정의하려는 시도는 불필요한 오버헤드를 초래한다고 주장합니다.
발견 및 반복: 비평가들은 많은 제품 환경에서 요구 사항을 사전에 완전히 알 수 없다는 점을 지적합니다. 한 사용자는 다음과 같이 언급했습니다: > "문제는 대부분의 제품 기반 결정에 대해 사전에 무엇을 모르는지조차 모른다는 것입니다. 문제를 해결하기 위해 명세를 계속 수정하는 것은 큰 실수입니다."
대안적 접근 방식: "바이브 코딩"의 지지자들은 빠르고 조잡한 프로토타입을 먼저 생성하는 것이 요구 사항을 발견하는 데 더 효과적이며, 이를 최종적이고 세련된 구현의 기초로 사용할 수 있다고 제안합니다.
도구 비교: 사용자들은 이 접근 방식을 Spec Kit 및 BMAD와 같은 기존 프레임워크와 비교하며, 확립된 대안보다 이 구현이 갖는 구체적인 이점에 대해 의문을 제기합니다. 유지 관리자들은 시스템의 고유한 가치가 빌드 전 검토 게이트와 커밋 단계 검사의 자동화된 강제에 있다고 강조합니다.