💡 핵심 인사이트
스파이크(Spike)는 애자일 스크럼에서 개발팀이 새로운 기능의 스토리 포인트(점수)를 매기려는데 **"우리가 한 번도 안 써본 미지의 기술(예: 챗GPT API 연동)이라서, 이게 1일 걸릴지 10일 걸릴지 도저히 짐작(추정)조차 불가능할 때" 사용하는 예외적인 '시간제한형 집중 기술 조사/프로토타이핑 활동'**입니다.

Ⅰ. 스크럼에서의 추정 딜레마

스프린트 계획 회의 중입니다. PO가 새로운 백로그를 가져왔습니다.

• PO: "이번 스프린트에 사용자 얼굴을 인식해서 아이폰 애니모지처럼 아바타를 움직이게 하는 기능을 넣어봅시다. 포인트 몇 점 줄까요?"
• 개발팀: "(집단 멘붕) 어... 저희 팀에 3D 얼굴 인식 AI 기술 만져본 사람이 한 명도 없는데요? 라이브러리가 있는지, AWS 서버 요금이 얼마나 나올지 전혀 감이 안 옵니다. 점수를 매길 수가 없어요!"

점수 추정이 불가능한 일감을 스프린트 백로그(이번 주 할 일)로 억지로 쑤셔 넣으면, 2주 내내 헤매다가 스프린트 전체가 대실패(Fail)로 끝납니다. 이 불확실성의 장벽을 뚫는 해머가 바로 스파이크입니다.

Ⅱ. 스파이크(Spike)의 작동 원리

이름처럼 뾰족한 대못(Spike)을 미지의 벽에 쾅 박아보고(찔러보고) 속이 얼마나 단단한지 견적을 재는 것입니다. (XP 방법론에서 유래).

1. 별도의 티켓 생성: 정식 개발 티켓이 아니라, **[Spike] 얼굴 인식 라이브러리 타당성 검토**라는 특별한 조사용 티켓을 백로그에 만듭니다.
2. 타임박싱 (Timeboxing) ★절대 룰:
   • 스파이크는 완벽한 논문을 쓰는 게 아닙니다. 길어봤자 **딱 1일이나 2일(예: 최대 16시간)**로 시간을 엄격하게 끊어버립니다. (시간을 제한하지 않으면 개발자가 무한정 파고들어 삽질합니다).
3. 가장 조잡한 프로토타입 코딩:
   • 아키텍처나 에러 처리, TDD 따위는 몽땅 무시합니다. 오직 "이 AI 라이브러리가 우리 서버에서 에러 없이 켜지기나 하는가?"를 확인하기 위해 스파게티 코드로 뚝딱뚝딱 실험 코드(Throwaway code)만 짜봅니다.
4. 결과 보고 및 버려짐:
   • 2일 뒤 타임박스가 끝나면 짜던 코드를 미련 없이 휴지통에 버립니다. (운영 서버에 절대 반영 안 됨).
   • 개발자는 팀에 돌아와 발표합니다. "제가 2일간 찔러봤는데, A 라이브러리 쓰면 됩니다. 점수는 8포인트짜리 일감입니다!" ➔ 이제 불확실성이 해소되어 당당하게 스프린트 계획(추정)을 세울 수 있습니다.

Ⅲ. 스파이크의 두 가지 종류

• 기술적 스파이크 (Technical Spike): 위 예시처럼 "어떤 라이브러리를 쓸까? 성능은 나올까?"라는 기술적 리스크를 해소할 때 씁니다.
• 기능적/비즈니스 스파이크 (Functional Spike): "고객이 이 기능을 좋아할까?"를 알 수 없어, 종이에 대충 화면을 그려 고객에게 보여주며 사업적 반응(MVP)을 조사할 때 씁니다.

📢 섹션 요약 비유: 스파이크(Spike)는 전쟁터에서 숲속에 적군이 몇 명 매복해 있는지 몰라 전진(개발)을 못 할 때, 진격 부대 전체를 몰아넣지 않고 발 빠른 정찰병 한 명을 숲속에 던져 넣어(타임박싱) "딱 1시간만 수풀을 찔러보고 적군의 규모(난이도)만 파악한 뒤 무조건 복귀하라"고 시키는 극도로 효율적인 수색 및 정찰 기법입니다.