Kiro Spec 워크플로우의 한계와 Vibe로 우회하기
Kiro 워크플로 총정리에서 Spec 모드를 “제일 많이 쓴다”고 적었는데, 그만큼 1.0으로 오면서 실무에서 걸리는 지점도 눈에 들어왔습니다. 이 글은 그 한계를 정리하고, 무거운 문서 생성을 Vibe로 통제해 우회하는 방법을 담았습니다. 출처: Kiro IDE Changelog
목차
- 들어가며 — Spec의 구조와 걸리는 지점
- 실무에서 걸리는 네 가지 지점
- Vibe로 일부 해결하기
- 마치며
- TL;DR
1. 들어가며 — Spec의 구조와 걸리는 지점
Kiro의 Spec 모드는 하나의 기능을 requirements → design → tasks 세 단계로 문서화하며 진행합니다. 각 단계에 승인 게이트가 있고, “Run all Tasks”를 누르면 태스크 의존성 그래프를 만들어 독립 태스크를 wave 단위로 병렬 실행합니다. 여기까지는 공식 문서로 확인되는 구조이고, 그 자체는 깔끔합니다.
다만 1.0으로 오면서 이 구조 위에서 실무자가 체감상 걸리는 지점이 몇 가지 생겼습니다. 아래는 제가 실사용하며 관찰한 동작 위주라, 단정보다는 경험을 공유하는 톤으로 적었습니다.
2. 실무에서 걸리는 네 가지 지점
2-1. 오케스트레이터가 직접 작업을 못 한다
1.0부터 spec 실행이 “오케스트레이터 + 병렬 태스크 실행” 구조로 나뉘었습니다. 오케스트레이터는 조율/위임 역할이라, 경험상 위임된 실행이 실패해도 예전처럼 직접 이어받아 처리하지 못합니다. 1.0 이전에는 “위임이 실패하면 직접 실행하라”는 조건을 걸어 복구가 됐는데, 체감상 그 fallback 경로가 구조적으로 막힌 셈입니다.
2-2. requirements 자동 생성이 첫 draft에서 뻗는다
가장 아픈 지점입니다. spec 모드가 requirements를 처음 자동 생성할 때, 경험상 모델이 내용을 길게 쓰다가 출력 한계에서 잘리거나 멈춥니다. 요구사항을 아무리 잘게 나눠도 모델은 그 한 조각을 또 길게 쓰려 하기 때문에, 범위 축소만으로는 잘 해결되지 않았습니다.
2-3. “나눠 써라”는 규칙이 spec 경로엔 안 걸린다
“뼈대 먼저 만들고 이어쓰기” 같은 스티어링은 일반 파일 쓰기 흐름을 통제하는 규칙입니다. 그런데 체감상 spec 자동 생성은 이 흐름이 아니라 워크플로우 내부 문서 생성 경로로 한 번에 렌더링돼서, 규칙이 걸릴 지점 자체가 없어 보였습니다.
2-4. 병렬 태스크 실행의 충돌
“Run all Tasks”의 wave 병렬 실행은 여러 태스크가 같은 파일이나 상태를 동시에 건드리기 쉽습니다. 경험상 그 과정에서 충돌하거나, 컨텍스트가 흩어져 에러를 내는 경우가 있었습니다.
3. Vibe로 일부 해결하기
핵심은 “출력 길이를 내가 통제할 수 있는 경로(Vibe)에서 먼저 완성하고, spec에는 구조와 추적만 맡긴다”는 분업입니다. 아래는 제가 실제로 써본 우회법입니다.
3-1. requirements를 Vibe에서 미리 작성 후 파일로 주입 (가장 안정적)
일반 채팅(Vibe)에서 requirements를 청크 단위로 잘리지 않게 완성해 .kiro/specs/<기능명>/requirements.md에 저장한 뒤 spec 모드로 진입하면, 경험상 새로 생성하지 않고 기존 파일 기반으로 design/tasks를 이어갑니다. 첫 자동 생성이라는 폭발 지점을 건너뛰는 방식입니다.
3-2. 태스크는 하나씩 실행
“Run all Tasks” 대신 개별 실행하면, 체감상 병렬 위임 경로를 타지 않고 메인 에이전트가 직접 수행합니다. 실패해도 같은 컨텍스트에서 바로 재시도되는 편이라 복구가 쉬웠습니다.
3-3. 첫 생성을 강제로 짧게
부득이 자동 생성을 쓸 땐, 시작 프롬프트에 “우선 스토리 제목과 상위 항목만, 수용 기준은 빼고 개요 수준으로만 생성하라”고 명시해 첫 draft 분량을 눌러두고, 이후 Refine으로 확장합니다.
3-4. 이 흐름을 스티어링으로 고정하기
위 우회법을 매번 손으로 챙기는 대신, default(Vibe) 세션이 Spec처럼 “작업 전 문답 → 작업 → 산출물 문서화”를 따르도록 만드는 스티어링 규칙을 만들어 올려뒀습니다.
핵심은 세션 타입을 바꾸는 게 아니라(그건 IDE 레벨이라 불가능합니다) default 세션이 Spec처럼 행동하도록 강제하는 데 있습니다. 코드 변경 작업이면 먼저 요구사항을 문답으로 확정하고, 작업 후 .kiro/specs/{spec명}/에 requirements.md(요구사항 + 문답 결과)와 changes.md(변경 파일 + 상세 + 검증)를 남깁니다. 단순 질의나 오타 수정 같은 사소한 편집엔 적용하지 않아 문서 오염도 줄였습니다. 무거운 글쓰기는 Vibe에서 통제하고 구조와 추적만 남긴다는 이 글의 분업을, 매번 반복하지 않도록 규칙으로 굳힌 셈입니다.
4. 마치며
정리하면, 1.0의 spec 워크플로우는 위임/병렬 구조로 바뀌면서 예전의 fallback이 사라지고 긴 문서 자동 생성이 취약해진 것으로 보입니다. 완전한 설정 토글은 아직 없지만, 무거운 글쓰기는 Vibe에서 통제해 완성하고 spec에는 구조와 추적 역할만 맡기면 상당 부분 우회할 수 있었습니다. Spec을 버리자는 이야기가 아니라, 무게가 실리는 지점만 Vibe로 덜어내는 분업에 가깝습니다.
5. TL;DR
- Kiro 1.0 Spec은 오케스트레이터/병렬 구조로 바뀌며 위임 실패 시 직접 복구가 어렵고, requirements 첫 자동 생성이 출력 한계에서 자주 뻗습니다(경험상).
- “나눠 써라”는 스티어링은 일반 쓰기 경로만 통제해, spec 내부 문서 생성에는 잘 걸리지 않습니다.
- 우회법: requirements를 Vibe에서 완성해 파일로 주입, 태스크는 하나씩 실행, 부득이하면 첫 draft를 개요 수준으로 짧게 생성 후 Refine.
- 핵심은 “무거운 글쓰기는 Vibe, 구조와 추적은 Spec”이라는 분업입니다.
- 이 분업을 매번 손으로 챙기지 않도록 default-as-spec-workflow.md 스티어링으로 고정해 두면, default 세션이 문답 → 작업 → 문서화를 자동으로 따릅니다.