Spec Kitty 3.2.7, 요구사항을 작업 묶음과 검토 상태로 남기는 로컬 데모
한 덩어리 요구사항을 AI 코딩 에이전트에게 바로 넘기면 코드는 생겨도 “무엇을 검토했고 어디까지 승인했는지”가 흐려지기 쉽습니다. Spec Kitty 3.2.7은 요구사항을 spec → plan → tasks로 나누고, 작업 묶음의 상태를 planned, in_progress, for_review, approved, done처럼 저장소 안에 남기는 CLI입니다.
이번 글은 실제 실행 후기가 아니라 공식 README와 v3.2.7 릴리스 노트를 바탕으로 따라갈 수 있게 만든 문서 기반 하루 데모입니다.
핵심은 AI에게 더 긴 프롬프트를 주는 것이 아니라, 검토 가능한 작업 경계를 먼저 만드는 데 있습니다.
한눈에 보는 결론
- 요구사항은 먼저 제품 의도와 수용 기준으로 쪼갭니다.
- 작업 묶음마다 담당 범위와 상태를 따로 둡니다.
for_review와approved를 나누면 검토 전후가 섞이지 않습니다.- Spec Kitty 3.2.7은 로컬 저장소 중심이며 호스팅 기능은 선택 사항입니다.
- 작은 일회성 스크립트에는 구조가 오히려 무거울 수 있습니다.
Spec Kitty 3.2.7은 무엇을 남기나
Spec Kitty는 AI 코딩 에이전트용 오픈 소스 CLI입니다. 제품 의도를 저장소 안의 명세, 계획, 작업 묶음, 수용 기준, 검토 상태, 병합 결정으로 이어 붙이는 방식이라 작업 기록이 대화창에만 남지 않습니다.
생활 비유로 보면 장보기 메모와 비슷합니다. “저녁 준비”라고만 적는 대신 재료를 사고, 손질하고, 조리하고, 맛을 확인하는 단계로 나누면 누락된 일이 보입니다.
Spec Kitty는 이 단계를 Git 저장소와 작업 묶음에 대응시키는 쪽에 가깝습니다.
공식 저장소는 MIT 라이선스를 표시하고 Python 3.11+ 환경을 전제로 안내합니다. v3.2.7 릴리스는 2026년 9월 9일 공개됐으며, 프로젝트 레이어 에이전트 프로필과 첫 실행·Windows 안정성, finalize-tasks 관련 수정이 포함된 유지보수 릴리스입니다.
- 공식 저장소: https://github.com/spec-kitty/spec-kitty
- v3.2.7 릴리스: https://github.com/spec-kitty/spec-kitty/releases/tag/v3.2.7
요구사항 한 줄이 작업 묶음으로 바뀌는 순서
예시 입력을 “로그인한 사용자가 오늘 할 일을 추가하고 완료 처리할 수 있는 작은 목록 앱”이라고 해보겠습니다. 공식 흐름을 따라가면 먼저 specify에서 제품 의도와 수용 기준을 적고, plan에서 구현 방향을 잡은 다음, tasks에서 실행 가능한 작업 묶음으로 나눕니다.
specify: 로그인 사용자의 할 일 추가·완료 기능
plan: 데이터 구조, 화면 흐름, 검증 방법 결정
tasks:
WP-1 사용자 입력과 저장
WP-2 목록 화면과 완료 상태
WP-3 테스트와 검토 자료
이제 작업 상태를 붙입니다. WP-1은 in_progress, WP-2는 planned, 테스트 묶음은 구현이 끝나면 for_review로 이동합니다.
리뷰어가 수용 기준을 확인한 뒤에야 approved, 병합까지 끝나면 done으로 보는 식입니다.
for_review는 구현 완료와 승인 완료 사이의 빈칸을 보이게 합니다.
로컬 하루 데모를 따라가는 법
공식 README의 설치 예시는 다음과 같습니다. pipx를 권장하고 uv tool 또는 가상환경 안의 pip도 대안으로 제시합니다.
아래 명령은 이 글에서 실행한 기록이 아니라 v3.2.7 README 기반 예제입니다.
pipx install 'spec-kitty-cli==3.2.7'
spec-kitty init my-project --ai codex
cd my-project
spec-kitty verify-setup
프로젝트를 만든 뒤 AI 코딩 에이전트에서 다음 순서로 입력합니다.
/spec-kitty.charter
/spec-kitty.specify 오늘 할 일 목록을 추가·완료 처리하는 작은 앱
/spec-kitty.plan
/spec-kitty.tasks
그 다음 미션의 다음 작업을 확인하고, 검토·수용·병합 단계로 이어갑니다.
spec-kitty next --agent codex --mission <mission-slug>
/spec-kitty.review
/spec-kitty.accept
/spec-kitty.merge --push
README는 작업 상태를 spec-kitty agent tasks status로 확인하고, 도구 연동에는 --json을 사용할 수 있다고 안내합니다. 실제 출력 형식이나 이 환경에서의 성공 여부는 직접 실행해 확인해야 하므로 여기서는 결과를 만들어 쓰지 않습니다.
기존 방식과 무엇이 다른가
일반적인 AI 코딩 세션에서는 요구사항, 구현 지시, 리뷰 요청이 채팅 기록과 여러 브랜치에 흩어질 수 있습니다. Spec Kitty는 명세와 작업 묶음을 kitty-specs/ 아래에 두고, 병렬 작업을 위한 격리된 Git worktree를 .worktrees/에 둔다는 점이 다릅니다.
| 확인할 것 | 대화 중심 작업 | Spec Kitty 흐름 |
|---|---|---|
| 요구사항 | 프롬프트와 기억 | 저장소의 spec |
| 구현 단위 | 사람이 임의로 나눔 | work package |
| 검토 전 상태 | 문장으로 전달 | for_review |
| 승인 기록 | 리뷰 댓글·대화 | approved와 병합 흐름 |
다만 상태명이 있다고 품질이 자동으로 보장되는 것은 아닙니다. 수용 기준을 모호하게 적으면 approved도 모호한 기준 위의 승인일 뿐입니다.
언제 쓰고, 언제 생략할까
여러 AI 에이전트가 같은 저장소에서 일하거나 요구사항·검토·병합의 흔적을 Git에 남겨야 한다면 잘 맞습니다. 반복되는 기능 개발에서 작업 묶음의 경계를 정하고 싶을 때도 선택지가 됩니다.
반대로 한 파일을 고치는 일회성 수정, 아주 작은 스크립트, Git을 쓰지 않는 폴더라면 초기 구조가 작업보다 커질 수 있습니다. 공식 README도 이런 경우에는 과할 수 있다고 설명합니다.
작업이 작다는 이유보다, 검토 이력을 남겨야 하는지로 도입 여부를 판단하는 편이 정확합니다.
확장 프롬프트와 한계
최소 데모가 익숙해지면 에이전트에게 다음처럼 요청할 수 있습니다.
현재 mission의 요구사항을 사용자 흐름·데이터·검증 작업으로 다시 나누고,
각 작업에 수용 기준과 의존성을 적은 뒤 for_review 상태로 보낼 조건을 제안해줘.
이 프롬프트는 작업 분해를 돕지만, 기준을 대신 결정하지는 않습니다. 공식 릴리스 노트에 기록된 수정 범위와 실제 프로젝트의 설정·에이전트 조합은 다를 수 있으므로, 버전 고정 뒤 verify-setup과 상태 출력을 직접 확인해야 합니다.
Spec Kitty 3.2.7의 강점은 자동 코딩 자체보다 명세와 검토 상태를 저장소의 작업 기록으로 만드는 것입니다. 다음 단계는 작은 테스트 저장소에서 spec, plan, tasks, review 산출물이 실제로 어떻게 생기는지 확인하고, 팀이 쓸 수용 기준부터 정하는 일입니다.
작업 환경을 함께 정리한다면
긴 CLI 입력과 노트북 연결이라는 작업 장면에 맞는 제품만 두 가지 역할로 골랐습니다. 모델 세부 정보·가격·후기는 카드에 표시된 범위를 넘겨 단정하지 않습니다.
긴 명령어를 입력하는 작업 환경을 정리할 때 참고할 수 있는 카드입니다. 직접 사용 경험이나 타건감은 확인하지 않았습니다.
로컬 데모를 외부 화면이나 저장장치와 함께 구성하려는 독자에게 연결할 수 있는 카드입니다. 실제 포트 호환성은 구매 화면에서 확인해야 합니다.
이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.
출처
- Spec Kitty v3.2.7 공식 릴리스: https://github.com/spec-kitty/spec-kitty/releases/tag/v3.2.7
- Spec Kitty v3.2.7 README: https://raw.githubusercontent.com/spec-kitty/spec-kitty/v3.2.7/README.md
- Spec Kitty 공식 저장소: https://github.com/spec-kitty/spec-kitty
핵심 정리: 다섯 가지 질문과 답
Q. Spec Kitty 3.2.7은 무엇인가요?
AI 코딩 에이전트 작업을 spec, plan, tasks, review, accept, merge 흐름으로 관리하는 로컬 우선 오픈 소스 CLI입니다.
Q. 작업 묶음은 왜 나누나요?
요구사항을 구현 가능한 범위로 나누고, 각 범위의 진행·검토·승인 상태를 따로 보기 위해서입니다.
Q. for_review와 approved는 어떻게 다른가요?
for_review는 검토를 기다리는 상태이고, approved는 수용 기준을 확인한 뒤 승인된 상태로 구분하는 흐름입니다.
Q. 3.2.7을 실제로 실행했나요?
아닙니다. 설치와 명령 예시는 공식 v3.2.7 README를 바탕으로 정리했으며, 실제 출력과 성능은 직접 실행 검증이 필요합니다.
Q. 누구에게는 필요 없나요?
일회성 파일 수정이나 아주 작은 스크립트처럼 검토 이력을 남길 필요가 거의 없는 작업에는 구조가 무거울 수 있습니다.
글을 읽어 주셔서 감사합니다.
이 글이 도움이 되었고 새로운 정보를 계속 받아보고 싶으시다면 구독해 주세요.
'AI > 오픈 소스 소개' 카테고리의 다른 글
| Token Monitor 사용법, Codex·Claude Code 한도와 Hermes 사용량을 한 화면에 놓는 법 (0) | 2026.09.29 |
|---|---|
| oMLX 0.7.0rc1, 메뉴 막대 서버의 모델·캐시는 어디서 볼까 (0) | 2026.09.28 |
| Kiro Crew 0.7.1, 재시작 뒤에도 이어지는 작업은 어디까지일까 (0) | 2026.09.27 |
| ConnectOnion 함수 도구 연결, 에이전트가 무엇을 했는지 기록까지 남기는 법 (0) | 2026.09.26 |
| Orca Git worktree 데모, 에이전트 답이 섞일 때 비교부터 분리하는 법 (0) | 2026.09.25 |
댓글