✅ XP vs Scrum vs Kanban 비교
| 항목 | XP (Extreme Programming) | Scrum | Kanban |
|---|---|---|---|
| 정의 | 품질 중심의 애자일 개발 기법 | 시간 기반 반복 개발 프레임워크 | 작업 흐름 기반의 시각적 관리 기법 |
| 목적 | 코드 품질 및 빠른 피드백 확보 | 팀 협업과 반복적 개선 | 흐름 최적화와 병목 제거 |
| 주요 특징 | - 테스트 주도 개발 - 페어 프로그래밍 - 지속적 통합 - 고객 상시 참여 | - 고정된 스프린트 - 역할(PO, SM, 팀) - 회고, 리뷰 | - WIP 제한 - 칸반 보드 - 지속적 전달 - 유연한 우선순위 |
| 프로세스 | 짧은 반복(iteration), 매일 배포 가능 | 정해진 스프린트 (보통 2주), 계획 회의 포함 | 스프린트 없음, 지속적인 흐름 |
| 역할 구조 | 개발자 + 고객 (비공식) | PO, SM, 팀 (명확히 분리) | 역할 분리 없음 (팀 자율적 운영) |
| 작업 단위 | 스토리 카드 (User Story) | 백로그 항목 | 칸반 카드 (작업 단위) |
| 일정 단위 | iteration (1~2주) | Sprint (2~4주) | 없음 (작업 흐름 중심) |
| 문서화 | 최소화, 코드 중심 | 백로그 및 산출물 정리 | 보드 중심 시각화 (정형 문서 없음) |
| 계측 지표 | 코드 품질, 테스트 커버리지 | 스프린트 벨로시티, 번다운 차트 | 리드 타임, 처리 속도, Cumulative Flow |
| 장점 | - 높은 코드 품질 - 빠른 피드백 - 개발자 주도 | - 명확한 역할 분담 - 반복적 개선 - 관리가 쉬움 | - 유연성 극대화 - 병목 관리 우수 - 비개발 업무도 적용 쉬움 |
| 단점 | - 고객 상시 참여 필수 - 기술 중심이라 팀 역량 요구 높음 | - 스프린트 강제성에 의한 부담 - 변화 대응 느릴 수 있음 | - 구조적 가이드 부족 - 초보팀은 오히려 혼란 가능 |
| 적합 상황 | 소규모 팀, 기술 품질 중시 | 중간 규모 팀, 복잡한 프로젝트 | 유지보수, 운영, 가변성 높은 업무 (DevOps 등) |
🔍 핵심 요약
- XP: *"개발자 중심 품질 확보"* – 코드 품질과 피드백 중시
- Scrum: *"조직적 반복 관리"* – 일정 주도형 반복 개발
- Kanban: *"유연한 흐름 관리"* – 지속적 전달, WIP 제한
📌 활용 예시
| 상황 | 추천 방법론 |
|---|---|
| 스타트업, 빠른 변화 대응 | XP, Kanban |
| 중장기 프로젝트 관리 | Scrum |
| 장애 대응, 운영팀 | Kanban |
| 코드 품질 개선 과제 | XP |
| 신제품 개발 | Scrum + XP 조합 |
✅ 스파이크 (Spike)
| 항목 | 설명 |
|---|---|
| 정의 | 특정 기술적 문제나 불확실한 요구사항을 빠르게 실험·탐색하여 해결 방안을 찾기 위한 짧은 시간의 연구 개발 작업 |
| 목적 | 미지의 기술, 툴, API, 아키텍처 선택지 등에 대한 기술 리스크 제거 |
| 형태 | 코드 프로토타입, 기술 리서치, 짧은 실험 프로젝트 등 |
| 적용 예 | - 외부 API를 처음 사용할 때 - 라이브러리 비교 - 성능 측정 기법 탐색 |
| 산출물 | 실험 결과 요약, 결정 사항 정리, 종종 폐기 가능한 코드 |
| 특징 | - 실제 기능 개발이 아님 - 실패를 전제로 빠른 실험 - Sprint/Iteration 안에서 관리됨 |
✅ 구조적 스파이크 (Architectural Spike)
| 항목 | 설명 |
|---|---|
| 정의 | 전체 시스템 구조나 핵심 아키텍처 결정과 관련된 보다 복잡한 수준의 스파이크 활동 |
| 목적 | 시스템 전반에 영향을 미치는 아키텍처 결정을 실험하고 리스크를 사전 제거 |
| 적용 예 | - 마이크로서비스 도입 여부 실험 - 비동기 메시징 큐 구조의 성능 검증 - DB 샤딩 전략의 구조 실험 |
| 산출물 | 아키텍처 결정안, 프로토타입 코드, 구조 도식 |
| 특징 | - 일반 스파이크보다 더 넓은 범위, 더 장기적 영향 - 주요 아키텍처 의사결정과 직결됨 |
🔍 핵심 차이 요약
| 구분 | 스파이크 (Spike) | 구조적 스파이크 (Architectural Spike) |
|---|---|---|
| 초점 | 기술/기능/도구의 단기 불확실성 해결 | 아키텍처 구조 수준의 의사결정 실험 |
| 범위 | 국소적인 기능, 도구, 기술 | 시스템 전체 또는 핵심 모듈 |
| 예시 | 외부 API 연동 실험, OAuth 인증 방식 확인 | CQRS vs CRUD 아키텍처 실험 |
| 영향도 | 비교적 제한적 | 전체 설계 방향에 영향 |
🧩 참고
XP에서는 **"모르는 것은 실험하라"**는 철학을 기반으로, 스파이크를 통해 **"지연된 의사결정(Defer Decision)"**을 최소화하고 빠르게 학습합니다.
스파이크?
XP에서의 **"스파이크(Spike)"**는 일반 영어 의미와는 다르게 비유적 의미로 사용된 용어입니다.
✅ 1. 일반 영어에서의 "Spike"
| 형태 | 의미 |
|---|---|
| 명사 (Spike) | - 못, 뾰족한 것 - 급격한 증가(예: a spike in traffic) |
| 동사 (to spike) | - 못을 박다, 찌르다 - 급등하다 |
✅ 2. XP에서의 "Spike" 의미
✔ 비유적 의미
- XP에서의 Spike는 **"불확실한 부분을 해결하기 위한 날카로운 침투(찌르기)"**를 뜻합니다.
- 즉, 복잡하거나 모호한 기술적 문제를 짧고 집중적으로 파고드는 실험 또는 탐색 작업을 의미합니다.
✔ 개념적 유추
| 일반 의미 | XP 의미 |
|---|---|
| 뾰족한 것으로 뚫는다 | 기술적 미지영역을 뚫고 들어가본다 |
| 짧고 강하게 박힘 | 짧은 시간 동안 집중적 탐색을 수행 |
| 변화의 급등 | 리스크와 불확실성의 급격한 제거 효과 |
✅ 3. 비유적 해석 예
"This part of the system is unclear. Let’s do a spike."
- → 이건 명확하지 않으니 짧게 실험해보자.
✅ 요약
| 항목 | 설명 |
|---|---|
| 원어 의미 | 뾰족한 것, 급등 |
| XP에서 의미 | 불확실한 기술적 문제나 선택지를 빠르게 실험해서 리스크를 제거하는 짧고 집중적인 탐색 활동 |
| 비유 방식 | 미지의 기술 문제에 뾰족하게 파고들어 해결한다는 뜻에서 유래 |