[SW Eng] 애자일과 스크럼 — 스프린트·백로그·세리머니의 리듬

워터폴은 요구→설계→개발→테스트→배포를 한 번에 길게 갑니다. 요구가 초기에 확정되고 안 바뀐다면 잘 동작합니다. 그러나 웹·앱 서비스는 출시 전에 시장·사용자가 바뀌고, "다 만들고 보니 원하던 게 아닌" 일이 잦습니다.

애자일은 이 문제를 작게 만들고 빨리 피드백받아 방향을 자주 교정하는 것으로 해결합니다. 애자일 선언의 4가지 가치:

프로세스·도구       < 개인과 상호작용
포괄적 문서         < 동작하는 소프트웨어
계약 협상           < 고객 협업
계획 준수           < 변화 대응

오른쪽도 가치 있지만 왼쪽을 더 중시한다는 상대적 선언입니다. SDLC의 단계를 없애는 게 아니라, 작은 단위로 반복하는 것이 핵심입니다. 스크럼은 이를 구현하는 가장 흔한 프레임워크입니다.

확대 위 그림처럼 폭포수는 6개월 후에야 고객 피드백을 받지만, 애자일은 2주 스프린트마다 결과를 검증해 방향을 교정합니다.

스크럼은 몇 가지 요소로 리듬을 만듭니다.

• 제품 백로그(Product Backlog): 만들 것들의 우선순위 목록(PO 소유). 요구사항 정의의 유저스토리가 여기 쌓입니다.
• 스프린트(Sprint): 고정 길이(보통 2주) 반복 주기. 시작 때 백로그에서 이번에 할 것을 골라 스프린트 백로그로.
• 증분(Increment): 스프린트 끝에 나오는 '잠재적 출시 가능' 결과물.
• 세리머니 4종(아래).

확대

세리머니를 캘린더에 올리는 것과 애자일하게 일하는 것은 다른 문제입니다. 형식은 완비됐는데 정작 '검사와 적응'은 멈춘 상태를 흔히 좀비 스크럼이라 부릅니다 — 겉보기엔 스크럼인데 아무것도 교정되지 않는 팀. 다음 신호가 보이면 프로세스가 형식화되고 있는 것입니다.

• 스프린트 안의 미니 워터폴: 8일차까지 개발만 하고 마지막 이틀에 QA를 몰아서 하면, 스프린트라는 포장 안에서 워터폴이 그대로 돌아갑니다. 신호는 스프린트 초반에 테스트 담당이 놀고 마지막 날 밤을 새우는 패턴입니다. 처방은 스토리를 세로로 얇게 쪼개 스프린트 내내 '완료'가 꾸준히 흘러나오게 하고, 완료 정의(DoD)에 테스트를 포함시키는 것입니다.
• velocity의 KPI화: 경영진이 팀 간 velocity를 비교하거나 평가에 쓰는 순간 포인트는 부풀기 시작하고 숫자는 계획 도구로서의 의미를 잃습니다. velocity는 '그 팀의 과거 추정 대비 소화량'이라는 상대값이라 팀 밖으로 나가면 안 되는 지표입니다(추정과 우선순위).
• 회고가 하소연으로 끝남: 매번 같은 불만이 나오는데 액션이 실행되지 않으면 팀은 "회고해봤자"를 학습하고, 다음 수순은 회고 생략입니다. 처방은 액션에 반드시 담당자를 붙이고, 다음 회고 첫 5분을 '지난 액션 점검'으로 고정하는 것입니다.
• 권한 없는 PO(프록시 PO): 우선순위를 실제로는 조직 상부가 정하고 PO는 전달만 한다면, 스프린트 범위는 중간에 계속 뒤집힙니다. 스크럼은 '그 자리에서 결정할 수 있는 PO'를 전제하는 프레임워크라, 조직 성숙도가 그에 못 미치면 세리머니 도입보다 권한 정리가 먼저입니다.
• 팀 규모에 따른 조절: 스크럼의 세리머니는 39인 교차기능 팀을 전제로 설계됐습니다. 23인 팀에 풀 세리머니는 과합니다(플래닝·회고를 합쳐 경량화). 반대로 10인이 넘으면 데일리가 보고회로 변질되므로 팀을 나누라는 신호입니다.

공통 처방은 하나입니다 — 각 세리머니에 대해 "이 자리는 무엇을 위한 것인가"를 팀이 답할 수 있는지 주기적으로 확인하고, 답이 안 나오는 세리머니는 고치거나 없애는 것. 형식을 지키는 것보다 그쪽이 애자일 선언에 가깝습니다.