Spec Kitty mission lifecycle: a domain modeling pass through Giiken

개요

Spec Kitty는 단순한 계획 생성에 그치는 기존 에이전트 프레임워크와 달리, 스테이트 머신을 통해 실제 미션을 디스크상의 아티팩트와 단계별 게이트를 거쳐 실행하는 방식으로 작동합니다.

주요 내용

* Spec Kitty 미션의 구조: 각 미션은 kitty-specs/ 디렉토리 아래에 슬러그와 ULID로 명명된 고유한 디렉토리로 구성됩니다. 이 디렉토리에는 spec.md, plan.md, research.md, data-model.md, status.json, checklists/ 등 각 파일이 스테이트 머신의 특정 역할을 수행합니다.
* 미션 실행 단계: 미션은 Specify, Plan, Tasks, Implement, Review, Merge의 여러 단계를 거칩니다. 각 단계는 특정 아티팩트를 생성하고 상태 이벤트를 발생시키며, 이전 단계의 결과물과 명확한 게이트를 통과해야 다음 단계로 진행됩니다.
* 단계별 게이트: 각 WP(Work Package)는 승인되기 전에 반드시 리뷰를 통과해야 하며, 모든 WP가 승인되지 않으면 최종 머지가 불가능합니다. 이는 에이전트가 스테이트 머신의 구조에 의해 제약되도록 합니다.
* 최종 산출물: Giiken 프로젝트의 경우, 도메인 모델 아키텍처 문서 2개가 생성되었고, WP01 및 WP02의 구현 작업으로 데이터 모델 마이그레이션이 정렬되었으며 PHPUnit 및 Vitest 테스트가 모두 통과되었습니다.
* "트레일"의 중요성: Spec Kitty 미션의 핵심은 결과물 자체보다 "트레일" 즉, 무엇이 요청되었고, 어떤 접근 방식이 선택되었으며, 어떤 증거가 기반이 되었고, 무엇이 구축되었으며, 어떤 검사를 통과했는지 추적 가능한 기록을 남기는 것입니다. 이 기록은 다음 에이전트나 사람에게 전달될 수 있는 작업 기억의 역할을 합니다.
* 지속적인 컨텍스트: AI 세션 종료 시 컨텍스트가 증발하는 기존 에이전트 워크플로우와 달리, Spec Kitty는 미션 디렉토리를 지속적인 컨텍스트로 활용하여 다음 에이전트가 채팅 로그가 아닌 명확한 명세와 체크리스트를 기반으로 작업을 이어갈 수 있게 합니다.

시사점

Spec Kitty는 단순히 코드를 배포하는 것을 넘어, 감사, 재개, 확장이 가능한 구조화된 워크플로우를 통해 에이전트가 진행한 수명 주기 자체를 증명하는 프레임워크로, 결과물뿐만 아니라 그 과정의 투명성과 재현성을 확보하는 데 기여합니다.

원문 읽기 →
원문을 불러오는 중...

댓글

GitHub Discussions