Spec 세션

학습 목표

Vibe 세션과 Spec 세션의 차이점 체험
두 접근법의 장단점 이해
상황에 맞는 세션 유형 선택 능력 습득
실제 앱 개발을 통한 실습

Vibe 세션 vs Spec 세션

Vibe 세션은 Kiro의 대화형 Q&A 중심 세션입니다.

특징 :

빠른 질문, 설명, 대화형 프로젝트 구축에 최적화
유연하고 구조화되지 않은 접근법
탐색적 코딩과 학습에 적합

다음과 같은 경우에 사용 :

빠른 프로토타이핑이 필요할 때
아이디어를 빠르게 검증하고 싶을 때
개인 프로젝트나 실험적 개발
요구사항이 불명확하고 탐색이 필요할 때
학습 목적의 간단한 예제 작성

예시 시나리오 :


"새로운 UI 패턴을 빠르게 테스트해보고 싶어"
"이 API가 어떻게 동작하는지 확인해보자"
"간단한 데모를 만들어서 아이디어를 보여주고 싶어"

Spec 세션은 Kiro의 구조화된 문서 기반 개발 방식입니다. 추상적인 고수준의 아이디어에서 체계적인 실행 및 명확한 추적이 가능한 구현 계획을 만들어 낼 수 있습니다.

특징 :

문서 기반의 Requirements → Design → Tasks 3단계 프로세스
복잡한 개발 작업을 위한 체계적 접근법
품질 일관성이 높은 구조화된 프레임워크

다음과 같은 경우에 사용 :

팀 프로젝트나 협업 개발
복잡한 기능이나 시스템 구축
장기간 유지보수가 필요한 프로젝트
명확한 요구사항과 일정이 있는 개발
품질과 일관성이 중요한 프로덕션 코드

예시 시나리오 :


"새로운 팀원이 와도 쉽게 이해할 수 있는 코드를 만들어야 해"
"고객의 요구사항을 정확히 구현해야 해"
"6개월 후에도 쉽게 수정할 수 있어야 해"

실제로는 두 가지 세션을 조합해서 개발하는 것이 효과적입니다:

탐색 단계 : Vibe 세션으로 빠른 프로토타입
계획 단계 : 프로토타입을 바탕으로 Spec 작성
구현 단계 : Spec 세션 기반으로 정식 개발
개선 단계 : 필요시 Vibe 세션으로 빠른 수정

사전 준비 (기본 스티어링)

Note

AGENT STEERING에서 product, structure, tech 마크다운 파일이 이미 존재한다면 본 작업을 생략합니다.

좌측 사이드바 > Kiro 패널(유령(👻) 아이콘) 선택
AGENT STEERING에서 Generate Steering Docs 선택
세션 창 Command에서 실행이 멈출 경우, 실행(▶) 아이콘을 계속 선택
Kiro가 자동으로 기본 파일(product / structure / tech) 생성

Spec 세션으로 Spirit of Kiro 개선하기

목표


게임의 로그인 페이지를 보면, "비밀번호를 잊으셨나요?" 링크가 없음을 확인할 수 있습니다.
 
현재 이 게임은 Cognito를 이용한 인증을 사용하고 있지만, 구현은 아직 매우 기본적인 수준입니다.
 
비밀번호 재설정 이메일을 보내기 위해서는 Cognito에서 이메일 인증이 선행되어야 합니다.
 
따라서 아래 두 가지 작업 트리를 순차적으로 처리해야 합니다.
 
이메일 인증 구현
- 프론트엔드: 클라이언트 측 컴포넌트
- 백엔드: 서버 라우트 및 Cognito 통합
 
비밀번호 재설정 구현
- 프론트엔드: 클라이언트 측 화면
- 백엔드: 서버 라우트 및 Cognito 통합

Kiro의 “New Session” 창에서 Spec을 선택합니다.

다음 프롬프트를 입력합니다. Kiro는 프로젝트 정보를 수집하고, 이 복잡한 작업을 위한 명세서를 설계하기 시작할 것입니다.


사용자가 현재 비밀번호로 인증하여 비밀번호를 변경할 수 있는 옵션을 제공하고 싶습니다. 해당 설계를 위한 명세가 필요해요.

Kiro는 위 요청을 바탕으로 사용자 스토리 기반의 상세 요구사항 목록을 생성합니다. 이 스토리와 요구사항은 처음엔 모호했던 요청을 구체화해주고, 미처 생각하지 못했던 엣지 케이스들까지 드러내 줍니다.

완성된 요구사항(Requirements) 문서를 읽어본 뒤:

필요 시: 상세 피드백 반복 제공
만족 시: “Move to design phase” 클릭하여 다음 단계로 진행

이제 Kiro는 기존 코드베이스와 요구사항을 비교하여, 이를 구현하기 위한 설계를 상상하고 제안합니다. 디자인 문서에는 문제 해결을 위해 Kiro가 작성하려는 코드와 유사한 예제 코드 스니펫이 포함되어 있을 수 있습니다. 하지만 이 코드의 세부 구현에 너무 집착할 필요는 없습니다. 이 코드는 API 구조를 상상한 의사코드(pseudocode)일 뿐이며, 실제 구현은 약간 다르게 작성될 수 있습니다.

디자인(Design) 문서를 모두 읽은 후에는 다음 중 하나를 선택하세요:

수정 또는 개선이 필요하다고 판단되면, 구체적인 피드백을 프롬프트에 입력
그대로 진행해도 괜찮다면 “Move to Implementation plan” 클릭하여 다음 단계로 이동

Kiro는 요구사항 및 설계 문서를 바탕으로 실행할 작업 목록(Task List)을 작성합니다. 이 목록은 새 기능 개발의 단계별 이정표라고 보면 됩니다. 작업 목록을 수정하고 싶다면 프롬프트에 피드백을 입력하거나, 수정 없이 계속 진행하려면 “Looks good to me” 버튼을 클릭하면 됩니다.

작업을 시작하려면 해당 작업 위의 “Start Task” 버튼을 클릭하세요. Kiro는 즉시 해당 작업을 수행합니다. 여러 Task의 Start Task를 눌러서 작업 Queue에 넣을 수 있습니다.

Spec 문서의 저장 위치 및 활용

모든 명세서는 .kiro/specs 디렉토리에 저장됩니다. 이 파일들은 의도적 설계 문서이므로, 반드시 코드와 함께 커밋하는 것이 권장됩니다.

이러한 명세서는 시간이 지나면서 점점 쌓이게 되며:

후속 개발자에게 코드의 설계 배경을 설명하는 가이드 역할
Kiro가 동일 기능을 다시 다룰 때 맥락 정보 제공 역할을 하게 됩니다.