테마
Vibe 세션
목표
Vibe 세션의 개념과 특징을 이해합니다. 대화형 즉흥 개발 방식으로, 빠른 프로토타이핑과 아이디어 검증에 최적화된 방식입니다.
Vibe 세션이란?
Vibe 세션은 Kiro의 대화형(Q&A 중심) 개발 방식입니다. 채팅 패널에서 자유롭게 요청하고, AI가 즉시 코드를 생성합니다.
명세 문서 없이 대화 흐름으로 결과물을 만들어가는 방식으로, "Vibe Coding"이라 불리는 즉흥적 AI 코딩의 핵심 모드입니다.
특징
- 🟢 빠름 — 한 줄 프롬프트로 동작하는 코드 생성
- 🟢 유연함 — 실시간 방향 변경, 즉석 개선 가능
- 🟢 탐색적 — 아이디어 검증, 실험에 적합
- 🟢 진입장벽 없음 — 별도 설정·문서 작성 불필요
- 🟡 비구조적 — 코드 스타일 불일치 가능
- 🔴 추적 어려움 — 요구사항 문서화 없음
적합한 상황
- 빠른 프로토타이핑
- 아이디어 검증 (이렇게 만들면 어떨까?)
- 개인 프로젝트·실험
- 학습용 간단 예제
- 긴급 버그 수정
- UI/UX 목업 빠르게 확인
- 일회성 스크립트·유틸리티 작성
Vibe vs Spec — 언제 무엇을 선택할까?
두 방식은 대립이 아닌 보완 관계입니다. 아래 의사결정 가이드로 상황에 맞는 모드를 선택하세요.
판단 기준 플로차트
상세 비교표
| 측면 | Vibe | Spec |
|---|---|---|
| 속도 | 🟢 매우 빠름 | 🟡 초기 느림 |
| 코드 품질 | 🟡 가변적 | 🟢 일관성 높음 |
| 문서화 | 🔴 없음 | 🟢 자동 생성 |
| 유지보수 | 🟡 어려움 | 🟢 용이 |
| 팀 협업 | 🔴 부적합 | 🟢 적합 |
| 학습 곡선 | 🟢 없음 | 🟡 EARS 형식 학습 필요 |
| 요구사항 추적 | 🔴 불가 | 🟢 코드↔요구사항 매핑 |
| 방향 전환 | 🟢 즉시 | 🟡 명세 수정 필요 |
하이브리드 패턴
실전에서는 두 방식을 결합하는 것이 가장 효과적입니다:
- Vibe → Spec 전환 — Vibe로 프로토타입을 만든 뒤, 결과가 유망하면 Spec으로 전환하여 구조화
- Spec + Vibe 병행 — 핵심 기능은 Spec으로, 부속 유틸·스타일링은 Vibe로
- Vibe 스파이크 — 기술 검증(spike)을 Vibe로 빠르게 수행한 뒤, 본 구현은 Spec으로
💡 하이브리드 활용의 전체 실습은 Scene F에서 진행합니다.
Vibe 세션 워크플로
아래는 효과적인 Vibe 세션의 진행 흐름입니다:
효과적인 Vibe 프롬프팅 팁
좋은 프롬프트의 조건
| 원칙 | 예시 |
|---|---|
| 결과물 형태 명시 | "React 컴포넌트로 만들어주세요" |
| 핵심 기능 나열 | "추가, 삭제, 완료 표시가 가능한..." |
| 기술 스택 지정 | "TypeScript + Tailwind CSS로..." |
| 시각적 참조 | "GitHub Issues 목록과 비슷한 UI로..." |
반복 개선 프롬프트 패턴
text
# 범위 좁히기
"헤더 부분만 수정해주세요. 나머지는 그대로 유지해주세요."
# 구체적 지시
"버튼 색상을 #3B82F6으로 바꾸고, hover 시 약간 어둡게 해주세요."
# 되돌리기
"방금 변경한 것을 원래대로 되돌려주세요."
# 참조 기반
"이 컴포넌트를 src/components/Header.tsx와 같은 스타일로 만들어주세요."피해야 할 패턴
- ❌ 한 프롬프트에 너무 많은 요구 — 분할하여 요청
- ❌ 모호한 지시 ("좀 더 좋게 해주세요") — 구체적 기준 제시
- ❌ 컨텍스트 없는 수정 — 어떤 파일/부분을 바꿀지 명시
- ❌ 이전 결과 무시 — 현재 상태를 기반으로 요청
한계와 Spec 전환 시점
아래 신호가 보이면 Spec으로 전환을 고려하세요:
| 전환 신호 | 설명 |
|---|---|
| 파일 수 증가 | 5개 이상의 파일이 서로 의존하기 시작 |
| 반복 수정 | 같은 부분을 3회 이상 고치고 있음 |
| 팀 합류 | 다른 개발자가 코드를 이해해야 함 |
| 배포 결정 | 프로토타입을 프로덕션에 올리기로 결정 |
| 회귀 발생 | 기능 A 수정 시 기능 B가 깨짐 |
| 요구사항 복잡화 | "이것도 되고, 저것도 되고..." 범위 확산 |
⚠️ Vibe의 기술 부채
Vibe 세션만으로 프로덕션 코드를 계속 확장하면, 요구사항 추적 부재·일관성 저하·테스트 미비로 인한 기술 부채가 급속히 누적됩니다. "빨리 만든 뒤 Spec으로 전환"이 가장 실용적인 전략입니다.
사전 준비
- Kiro IDE 로그인 완료
- 빈 폴더를 프로젝트로 열어둔 상태
해볼 것
즉흥적 요청 체험
채팅 패널에 입력:
할 일 관리 웹 앱을 만들어주세요. 할 일을 추가하고, 완료 표시하고, 삭제할 수 있으면 됩니다.즉석 개선 체험
결과를 본 뒤 바로 이어서:
좀 더 예쁘게 만들어주세요. 배경색은 무지개색이면 좋겠어요.추가 기능 요청
완료 퍼센트를 표시하는 기능도 추가해주세요.기대 결과
- 단 하나의 프롬프트로 동작하는 웹앱 생성
- 즉석 개선·추가 기능 요청의 유연함 체험
- Vibe 방식의 장점과 한계를 직접 확인
💡 실습으로 이어가기
이 페이지에서 배운 Vibe 세션을 직접 체험하려면 Scene A1 · Vibe 즉흥 요청 실습으로 이동하세요. 단 하나의 프롬프트로 동작하는 To-Do 앱을 만들어봅니다.
✅ 핵심 요약
- Vibe = 대화형 즉흥 개발. 빠르지만 비구조적
- 프로토타이핑·아이디어 검증에 최적
- 판단 기준: "폐기 가능?" → Vibe, "유지보수 필요?" → Spec
- 프로덕션 코드에는 Spec 방식과 결합 권장
- 실습 Scene A1에서 직접 체험하기
- 첫 프롬프트로 할 일 앱 생성필수
- 즉석 디자인 개선 요청 실행필수
- 완료 퍼센트 기능 추가 요청 실행필수
- Vibe 방식의 장점과 한계 확인선택