핵심 인사이트 (3줄 요약)
- 본질: Spike는 Agile에서 기술적 불확실성·위험을 해소하기 위한 시간 제한(Timebox) 조사·실험 활동이며, 스토리 추정이 불가능할 때 "먼저 조사해보자"로 수행된다.
- 가치: 기술적 불확실성(새 라이브러리·성능 한계·아키텍처 선택)이 있으면 스토리 포인트 추정이 불가능하고 스프린트가 예측 불가능해지므로, Spike로 사전 검증하여 리스크를 제거한다.
- 판단 포인트: Spike는 **산출물이 코드가 아니라 "지식(결정·판단)"**이며, 타임박스(보통 1~2일)를 반드시 설정하여 무한 탐구를 방지한다.
Ⅰ. 개요 및 필요성
┌───────────────────────────────────────────────────────┐
│ Spike 프로세스 │
├───────────────────────────────────────────────────────┤
│ 1. 불확실성 식별: "이 라이브러리가 요건을 충족할까?"│
│ 2. Spike 생성: 타임박스 2일, 목표 명확히 │
│ 3. 조사·PoC: 프로토타입·성능 테스트 │
│ 4. 결과 공유: "A 라이브러리 사용 결정, 이유는..." │
│ 5. 원래 스토리: 이제 추정 가능 → 스프린트 투입 │
└───────────────────────────────────────────────────────┘
- 📢 섹션 요약 비유: Spike는 정찰대이다. 본대(개발팀)가 진격하기 전에 정찰대가 먼저 가서 "이 길이 안전한지" 확인한다.
Ⅱ. 아키텍처 및 핵심 원리
Spike 유형
| 유형 | 목적 | 예 |
|---|
| 기술 Spike | 기술 가능성 검증 | PoC, 성능 테스트 |
| 기능 Spike | 요구사항 명확화 | 사용자 인터뷰, 프로토타입 |
- 📢 섹션 요약 비유: 기술 Spike는 "다리가 무게를 견딜까?" 테스트, 기능 Spike는 "이 다리가 필요한가?" 확인이다.
Ⅲ. 비교 및 연결
| 비교 | 일반 스토리 | Spike |
|---|
| 산출물 | 작동하는 코드 | 지식·결정 |
| 추정 | 스토리 포인트 | 타임박스 |
| 목적 | 가치 전달 | 불확실성 제거 |
Ⅳ. 실무 적용 및 기술사 판단
Spike 규칙
- 타임박스 필수 (1~2일, 최대 1스프린트).
- 목표·질문을 명확히 정의.
- 결과를 팀에 공유 (문서·데모).
- Spike 후 원래 스토리를 추정·계획.
Ⅴ. 기대효과 및 결론
Spike는 Agile에서 기술 리스크를 사전 제거하는 유일한 공식 메커니즘이며, "모르는 것을 인정하고 조사한다"는 Agile 투명성 원칙의 실천이다.
📌 관련 개념 맵
| 개념 | 연결 포인트 |
|---|
| Spike | 기술 불확실성 조사 |
| 타임박스 | Spike의 시간 제한 |
| PoC | 기술 Spike의 산출물 |
| 스토리 포인트 | Spike 후 추정 가능 |
| Technical Debt | Spike 없이 진행 시 발생 |
📈 관련 키워드 및 발전 흐름도
[XP (Extreme Programming, 1999) — Spike 개념 도입]
│
▼
[Scrum + Spike (2005~)]
│
▼
[SAFe Spike (2015~) — 대규모 Agile에서의 Spike]
│
▼
[PoC as Code (2020~) — Spike 산출물 재사용]
│
▼
[현재: AI Spike — LLM으로 기술 조사 자동화]
👶 어린이를 위한 3줄 비유 설명
- Spike는 정찰대예요. 본대(개발팀)가 가기 전에 먼저 가서 확인해요.
- "이 길이 안전한가?" "이 도구가 쓸만한가?" 조사하고 보고해요.
- 정찰 결과를 보고 본대가 안전하게 진격할 수 있답니다!