스프린트 플래닝을 하다 보면 가끔 아무도 포인트를 못 매기는 스토리가 나옵니다. 추정치는 2에서 13까지 제각각이고, 누군가 “그게, 상황에 따라 다른데요"라고 말하면 논의는 빙빙 돌기 시작하죠. GraphQL로 갈까 REST로 갈까? 시스템이 동시 사용자 1만 명을 버틸 수 있나? 이 서드파티 라이브러리, 프로덕션에서 써도 되나? 이런 질문은 추정으로 풀 수 없습니다. 직접 알아보는 수밖에 없어요. 그게 스파이크가 존재하는 이유입니다.
스파이크라는 말의 유래#
이 용어는 익스트림 프로그래밍(XP)에서 왔습니다. 원래는 “해결책 후보를 탐색하기 위한 아주 단순한 프로그램"을 뜻했죠. 문제에 스파이크(못)를 박아 넣는 이미지입니다. 요즘 식으로 말하면 타임박스를 정해 놓은 짧은 조사 작업이고, 산출물은 동작하는 소프트웨어가 아니라 지식입니다. 스파이크는 사용자 스토리가 아니고, 그 자체로는 고객 가치를 만들지 않습니다. 그래도 괜찮습니다. 스파이크의 역할은 딱 하나의 질문에 답을 내서, 진짜 작업을 제대로 추정하고 계획할 수 있게 하는 것이니까요.
실무에서는 두 갈래로 나뉩니다. 기술 스파이크는 “어떻게 만들 것인가"를 탐색합니다. 프레임워크나 라이브러리 평가, 아키텍처 패턴 프로토타이핑, 현실적인 조건에서의 성능 테스트, 외부 시스템 연동이 얼마나 골치 아플지 확인하는 일 같은 것들이죠. 기능 스파이크는 “무엇을 만들 것인가"를 탐색합니다. 모호한 스토리를 명확히 하고, 버릴 프로토타입으로 UI 아이디어를 검증하고, 도메인의 복잡함이 이해될 때까지 파보는 일입니다.
시간을 들일 가치가 있는 이유#
큰 미지수를 안은 채 추정하면 결과는 둘 중 하나입니다. 잔뜩 부풀린 추정치이거나, 깨지는 마감이거나. 스파이크는 “모르겠다"를 실제 데이터로 바꿔 주기 때문에 팀이 떳떳하게 커밋할 수 있게 됩니다. 의견 싸움도 증거 기반으로 바뀝니다. 어느 데이터베이스가 나은지 말로 싸우는 대신 이틀 동안 측정하는 거죠. 그 결과는 그대로 의사 결정 문서에 흘러 들어갑니다.
무엇보다 싼 보험입니다. 라이브러리의 한계를 드러내는 이틀짜리 스파이크가, 개발이 세 스프린트나 진행된 뒤에 같은 한계를 발견하는 것보다 훨씬 쌉니다.
스파이크를 써야 할 때, 쓰면 안 될 때#
스파이크가 필요한 순간은 이렇습니다. 기술적 미지수 때문에 팀이 자신 있게 추정을 못 할 때, 쓸 만한 선택지가 여럿이라 고르려면 데이터가 필요할 때, 새 기술이나 연동을 검토 중일 때, 성능이 불확실한데 중요할 때, 이해관계자와 아무리 회의해도 요구사항이 계속 모호할 때.
반대로 팀이 이미 할 줄 아는 작업이나, 지금 가진 정보로 내릴 수 있는 결정을 미루는 용도로는 쓰지 마세요. 그리고 스파이크는 제대로 된 요구사항 수집이나 사용자 수용 테스트의 대체재가 아닙니다. 질문에 답하는 도구지, 제품을 검증하는 도구가 아니거든요.
제가 진행하는 방식#
먼저 질문을 적습니다. “캐싱 조사"가 아니라 “Redis 클러스터가 50ms 지연 요구사항을 맞출 수 있는가?“처럼요. 범위 안팎을 명시하고, 타임박스는 1~3일로 잡습니다(그보다 더 필요하면 질문이 너무 넓은 겁니다). 끝났는지 판단할 성공 기준도 미리 정해 둡니다.
그다음은 조사입니다. 문서와 사례를 읽고, 최소한의 개념 증명을 만들고, 해본 사람에게 물어보고, 실제 코드로 측정합니다. 스파이크 코드는 처음부터 버릴 각오로 씁니다.
타임박스가 끝나면 조사 결과, 근거가 담긴 권장안, 발견한 리스크를 정리하고, 프로토타입 링크에는 “스파이크 산출물이며 프로덕션 코드가 아님"을 분명히 적어 둡니다. 팀에 공유하고 질문을 받고, 배운 것에 따라 백로그를 조정합니다. 스토리를 새로 만들거나, 다듬거나, 없애거나. 스파이크 진행 방식 자체를 다음 회고에서 돌아보는 것도 추천합니다. 스파이크는 해볼수록 눈에 띄게 늘거든요.
제가 쓰는 템플릿#
## 스파이크: [제목]
**타임박스**: [X일]
**담당자**: [이름]
**스프린트**: [스프린트 번호/이름]
### 답해야 할 질문
[이 스파이크가 답할 단일 집중 질문]
### 배경
[이 스파이크가 필요한 이유; 불확실성의 촉발 요인]
### 가정
- [가정 1]
- [가정 2]
### 범위
**범위 내**:
- [항목 1]
- [항목 2]
**범위 외**:
- [항목 1]
### 성공 기준
- [ ] [기준 1]
- [ ] [기준 2]
### 결과
[스파이크 중 완료 예정]
### 권장사항
[스파이크 후 완료 예정]
### 후속 스토리
- [ ] [스토리 1]
- [ ] [스토리 2]“가정” 칸은 제값을 합니다. 시작하기 전에 “우리 데이터 모델은 기본적으로 관계형이다”, “읽기가 쓰기보다 10배 많다"라고 적어 두면 두 가지 효과가 있습니다. 타임박스를 다 쓰기 전에 전제 자체에 대한 반박을 받을 수 있고, 조사 도중 가정이 틀렸다는 게 드러나면 그건 이틀 낭비가 아니라 훌륭한 발견이 됩니다.
스파이크가 산으로 가는 패턴#
고전적인 실패는 범위 확대입니다. 어느새 스파이크가 끝없는 연구 프로젝트가 되어 있는 거죠. 새 질문이 생기면(반드시 생깁니다) 지금 스파이크를 늘리지 말고 다음 스파이크 후보로 적어 두세요. 두 번째 실패는 과잉 제작입니다. 스파이크 코드에 에러 처리나 테스트를 붙이기 시작한 순간, 탐색에서 구현으로 선을 넘은 겁니다. 세 번째는 기록 생략. 6개월 뒤 누군가 같은 질문에 부딪혔을 때, 당신의 이틀치 배움이 사라져 있을 테니까요. 마지막은 스파이크를 정해진 답의 추인으로 취급하는 것입니다. “이 접근은 안 된다"를 밝혀낸 스파이크는 자기 일을 완벽하게 해낸 겁니다.
스프린트 계획에 끼워 넣기#
스프린트를 계획할 때 효과를 봤던 습관 몇 가지입니다. 진짜 미지수가 있는 스토리는 이번 스프린트에 스파이크를 돌리고, 실제 작업은 다음 스프린트로 미룹니다. 스파이크는 스프린트당 한두 개까지만. 그 이상이면 집중력이 흩어집니다. 스파이크에는 스토리 포인트를 매기지 않습니다. 소프트웨어가 아니라 지식을 만드는 작업이니 타임박스로 관리하면 됩니다. 그리고 스파이크 결과는 관련 스토리를 추정한 뒤가 아니라 그 전, 리파인먼트 자리에서 공유합니다.
다음에 답보다 질문이 더 많이 생기는 스토리를 만나면, 이번 스프린트에서 가장 가치 있는 작업이 스파이크일지도 모른다고 생각해 보세요. 멈춰서 배우는 게 결국 가장 빠른 길일 때가 있습니다.
추가 읽기#
이 사이트의 관련 기사:
- 회고: 스파이크 결과 반영 - 스파이크에서 배운 것을 지속적 개선으로 잇기
- 사용자 수용 테스트 - 스파이크 기반 결정이 사용자 요구를 충족하는지 검증
- 의사 결정 문서 - 스파이크 결과로 내린 결정을 구조화하기
- API 계획 - 스파이크가 API 설계 판단에 어떻게 도움이 되는지
외부 리소스:
- 스파이크 - Scaled Agile Framework (SAFe) - 대규모 조직에서의 스파이크 운영 가이드
- 스파이크 솔루션 - 익스트림 프로그래밍 - 스파이크가 탄생한 XP 원전
- 스크럼 가이드 - 스프린트 계획에서 스파이크의 위치
- Martin Fowler의 기술 부채에 대하여 - 스파이크가 기술 부채 예방에 기여하는 방식