💡 핵심 인사이트
스프린트는 스크럼 개발론의 심장 박동으로, **1주에서 최대 4주를 넘지 않는 짧은 '타임박스(Timebox, 고정된 기간)'**를 의미합니다.
이 기간 동안 개발팀은 전력 질주(Sprint)하여, 고객에게 당장 보여줄 수 있는 '작동하는 소프트웨어(증분)' 하나를 무조건 완성해 냅니다.

Ⅰ. 스프린트(Sprint)의 본질

마라톤처럼 1년 내내 끝이 안 보이는 코딩을 하면 개발자는 지치고 시장은 변합니다. 스크럼은 거대한 프로젝트를 2주 단위의 '스프린트'라는 작은 미니 프로젝트들의 연속으로 잘게 쪼갭니다. 스프린트 1이 끝나면 잠시 숨을 고르고 피드백을 받은 뒤, 바로 그다음 날부터 똑같은 2주짜리 스프린트 2가 시작되는 컨베이어 벨트 구조입니다.

Ⅱ. 스프린트의 3대 절대 원칙

스프린트는 단순한 '기간'이 아니라, 팀을 보호하는 강력한 규율을 가집니다.

1. 기간은 절대 연장되지 않는다 (Timeboxing)

• 이번 스프린트 목표를 2주(14일)로 잡았는데 일이 덜 끝났다고 해서 마감을 16일로 미루지 않습니다.
• 무조건 14일째 되는 날 펜을 내려놓고, 완성된 것까지만 시연(리뷰)한 뒤, 못 끝낸 일은 과감히 다음 스프린트 백로그로 이월합니다. (일정의 예측 가능성 확보)

2. 목표는 절대 변경되지 않는다 (No Changes)

• 스프린트가 시작되어 개발팀이 코딩에 돌입한 순간, 영업팀이나 사장님이 찾아와 "이 기능 급한데 당장 추가해 줘!"라고 요구해도 절대 수용하지 않습니다.
• 일단 결정된 이번 스프린트의 목표(백로그)는 2주 동안 봉인(Freeze)됩니다. 새로운 기능은 무조건 제품 백로그에 쌓아두고 '다음 스프린트'가 시작될 때 반영해야 합니다. (개발자의 집중력 보호)

3. 결과물은 무조건 '작동'해야 한다 (Working Increment)

• 스프린트가 끝났을 때 나오는 결과물은 "DB 설계 문서 완료"나 "아직 화면은 없는 백엔드 API 완료"가 되어서는 안 됩니다.
• 디자인과 DB, 프론트가 모두 합쳐져서 비록 기능이 로그인 하나뿐일지라도, **고객이 당장 클릭해 보고 피드백을 줄 수 있는 '완전히 동작하는 소프트웨어 조각(Increment)'**이어야 합니다.

Ⅲ. 스프린트의 길이 결정 (1주 vs 4주)

스프린트 길이는 한 번 정하면 프로젝트 내내 일관되게 유지하는 것이 좋습니다(리듬 형성).

• 1~2주 (짧은 스프린트): 시장 변화가 극심한 모바일 앱, 스타트업에 적합합니다. 리스크를 1주 만에 파악할 수 있지만, 회의(플래닝, 회고)를 너무 자주 해야 하는 오버헤드가 있습니다.
• 3~4주 (긴 스프린트): 인프라가 무겁거나 B2B 시스템 등 며칠 만에 결과를 내기 힘든 프로젝트에 씁니다. 오버헤드는 적지만, 잘못된 방향으로 가고 있을 때 손실이 4주 치로 커집니다.

📢 섹션 요약 비유: 스프린트는 공장 컨베이어 벨트에 올라간 **'2주짜리 타이머 폭탄'**입니다. 한 번 벨트가 돌기 시작하면 외부에서 절대 손댈 수 없고(목표 불변), 2주 뒤 타이머가 울리면 무조건 하던 일을 멈추고 그때까지 조립된 자동차(작동하는 소프트웨어)를 공장 밖으로 꺼내 평가받아야 합니다.