애자일과 스프린트

애자일이란

폭포수(Waterfall)는 요구사항 → 분석 → 설계 → 구현 → 테스트를 한 번에 순서대로 밟는다. 각 공정이 아무리 효율적이어도 결과가 고객이 원한 것이 아니면 전부 물거품이고, 구현 단계에서 허점을 발견해도 앞 공정으로 돌아가기 어렵다. 애자일은 같은 공정을 작게 여러 번 돌려 작동하는 결과물을 자주 확인하는 방식이다.

애자일은 정해진 규정이 아니라 가치 체계라서 정의가 하나로 정해져 있지 않다. 실무 감각으로 한 문장에 담으면 다음과 같다.

우선 만들고, 보여 주고, 평가받고, 고쳐 나가기를 반복하되, 모두가 함께 참여하고 누구나 볼 수 있게 시각화하면서 피드백 주기를 점점 짧게 만드는 것.

반복적과 점진적

반복적(iterative) 개발은 같은 것을 피드백에 따라 여러 번 다듬는다. 점진적(incremental) 개발은 동작하는 뼈대 위에 기능을 한 조각씩 더한다. 애자일은 둘을 함께 쓴다. 매 주기 기능을 하나 더하고(점진), 이미 만든 것도 피드백에 맞춰 고친다(반복).

폭포수가 맞을 때, 애자일이 맞을 때

애자일이 늘 정답은 아니다. 변경 비용과 불확실성이 기준이다.

애자일 안에서도 실천 방법이 갈린다. 고정 길이 스프린트와 정해진 책임·이벤트로 리듬을 만드는 스크럼, 스프린트 없이 WIP 제한으로 흐름을 만드는 칸반, 둘을 섞은 스크럼반이 대표적이다. 스크럼은 애자일을 하는 한 방법일 뿐이라, 스크럼 마스터나 스프린트 없이도 작은 팀·짧은 주기·정기 검토만 지키면 애자일하게 일할 수 있다.

왜 피드백 간격이 핵심인가

느린 피드백은 애착을 만든다

결과물을 보여 주기까지 오래 걸리면 그 사이 생각과 구현물에 애착이 생긴다. 매몰 비용이 쌓이면 정당한 반박도 나에 대한 공격처럼 느껴져 방어적이 된다. 의견이 몇 번 묵살되면 "이 회사는…" 식의 학습된 무력감으로 번진다.

• 구체화되기 전에 공유한다. 덜 다듬어진 아이디어일수록 내 것이 아니라 우리 것이 되어 피드백을 주고받기 쉽다.
• 만들지 않고 논의를 길게 끌지 않는다. 결과물 없는 논의는 각자의 상상끼리 부딪히는 싸움이 된다. 만들 재료가 모이면 논의를 멈추고 눈으로 볼 것을 만든다.

빠른 피드백은 일을 게임으로 만든다

게임에 몰입하는 이유는 분명한 목표, 행동에 대한 즉각적인 피드백, 눈에 보이는 진척이다. 내가 어디까지 했고 남은 것이 얼마이며 동료는 어디쯤인지 보이면 주도성이 생긴다. 칸반 같은 업무 시각화가 중요한 이유도 그것이 피드백 시스템이기 때문이다. "언제까지 돼요?"라는 질문은 통제권을 잃은 사람의 불안에서 나온다.

스프린트의 목적

스프린트는 주기마다 목표를 쳐내는 달리기가 아니라, 주기마다 한 것을 점검하는 장치다.

변질된 스프린트:

flowchart LR
  A1["#quot;이번 2주 동안 Task 10개를 끝낸다#quot;"] --> A2["달성 / 실패"]
  A2 --> A3["회고가 청문회가 되고, 남은 일은 다음 스프린트로 밀린다"]

본래의 스프린트:

flowchart LR
  B1["#quot;2주 해 보니 이만큼 하는구나. 고객은 만족하나? 방향은 맞나?#quot;"] --> B2["속도와 방향을 확인하고 다시 달린다"]

변질의 신호는 마감과 열정 페이를 요구하는 관리 도구로 쓰이기 시작할 때다. 매주 마감이 있으면 사람은 지칠 뿐이다.

일정은 예측하지 말고 측정한다

• 기획은 대부분 해 본 적 없는 일이라, 요구사항만 듣고 낸 일정은 근거 없는 추정이다.
• 입 밖에 낸 일정은 목줄이 된다. 2일·3일로 쪼개 약속하면 쉬운 쪽은 남고 어려운 쪽은 야근이 된다. 이런 경험이 쌓이면 일정을 보수적으로 부르는 문화가 생긴다.
• 그러니 작게 다 같이 먼저 만들어 보고 속도를 잰다. 질문도 "언제까지 돼요?"가 아니라 "언제쯤이면 일정이 예측될까요?"로 바꾼다.

데드라인을 없애자는 것이 아니라, 날짜를 역산해 개수를 강요하지 말고 언제든 배포 가능한 상태로 조금씩 키워 가자는 것이다.

완성의 기준은 "테스트할 수 있다"

80%를 만들었어도 아무도 써 볼 수 없으면 안 만든 것과 같다. 3일차에 테스트 가능한 80%를 내면 기획·디자인이 남은 2일의 방향을 바꿀 수 있다. 5일차에 처음 보여 주면 고치기 비싸서 아쉬운 채로 타협하게 된다. 태스크 우선순위도 "가장 먼저 테스트 가능한 형태가 되는 순서"로 세운다.

스크럼 운영 장치

스크럼의 공식 구성(책임·이벤트·산출물)은 스크럼: 책임·이벤트·산출물에, 스토리 쪼개기와 추정·속도는 백로그와 추정에 있다. 여기서는 실무에서 쓰는 운영 요령만 둔다.

• 스프린트를 "못 지키면" 피드백한다는 발상부터 목표치를 정하는 실수다. 회고에서 스스로 돌아보면 충분하고, 따로 지적하면 방어만 남는다.
• 플래닝 포커는 성급한 일정 예측으로 빠지기 쉽다. 개발자끼리 집단지성으로 해 보는 정도가 낫다.
• 일정 예측과 목표 달성이 더 중요해지면 스프린트는 목적을 잃는다. 변질된 스프린트는 안 하느니만 못하다.

구글 스프린트 5일 구성

구글 벤처스의 제이크 냅이 만든 5일짜리 아이디어 검증 절차다. 원래 MVP·프로토타입 검증용이지만 실무 신규 기능의 첫 주나 온라인 팀 프로젝트에도 맞게 바꿔 쓸 수 있다. 원격으로 진행할 때는 포스트잇 대신 FigJam·Figma 같은 온라인 화이트보드를, 회의실 대신 화상 회의·가상 오피스를 쓴다.

실무에서는 기획이 월화수, 디자인이 화수목, 개발이 수목금에 집중하는 식으로 겹쳐 흘러간다.

장치와 그 의도

투표 전에 선택과 이유를 먼저 적는 방법과 결정권자 역할 분리는 의사결정 체크리스트에, "나 사용설명서"는 협업을 잘하는 개발자에 있다.

첫 데모는 그럴싸함이 먼저다

첫 스프린트의 결과물은 가능성을 보여 주는 데모이므로 개발하다 만 느낌을 주지 않는 것이 중요하다. 빈 버튼에도 "준비 중인 기능입니다"를 띄우고, 탭 제목·파비콘·OG 카드를 서비스에 맞추고, README에는 실행 방법보다 서비스 소개를 쓴다.

정리

• 애자일은 피드백 주기를 짧게 만드는 일이다. 애착이 생기기 전에 공유하고, 논의보다 결과물을 먼저 낸다.
• 스프린트는 목표 달성 도구가 아니라 속도와 방향을 점검하는 주기다.
• 일정은 예측하지 말고 만들어 보며 측정한다. PM은 한 것을 중심으로 말한다.
• 완성의 기준은 테스트 가능 여부다. 언제든 배포할 수 있는 작은 완성을 유지한다.
• 장치의 형식보다 의도를 이해해야 회사마다 다른 환경에 응용할 수 있다.

관련 노트: 스크럼: 책임·이벤트·산출물, 백로그와 추정, 칸반과 린: 흐름과 낭비, 회의 잘하는 법, BDD·SDD로 태스크 나누기, 협업을 잘하는 개발자, Jira: 이슈 구성, JQL, 워크플로, 새 서비스 개발 프로젝트 진행 순서, 제품 중심 개발자, 페어 프로그래밍, EoA: 불확실성을 다루는 애자일 메커니즘