컴퓨터공학 300 주제 시리즈의 182번째 글이다. 전체 지도는 여기.

한 줄 요약

애자일(Agile)은 “계획보다 변화에 대응하고, 문서보다 동작하는 소프트웨어를 중시하자” 는 가치 선언이고, 스크럼(Scrum)은 그 가치를 팀 운영 규칙으로 구체화한 가장 널리 쓰이는 프레임워크다. 스크럼은 한 달 이하의 고정된 스프린트 안에서 계획·점검·회고를 반복한다.

왜 필요한가

앞 글에서 본 폭포수 모델은 요구사항이 처음에 다 정해진다는 전제를 깔고 있다. 하지만 대부분의 소프트웨어는 사용자가 써 보고 나서야 “이게 아니었다” 를 깨닫는다. 시장도, 경쟁 제품도, 규제도 프로젝트 도중에 바뀐다.

애자일은 이 불확실성을 없애려 하지 않는다. 대신 짧은 주기로 만들고, 보여 주고, 방향을 고치는 것을 정상 과정으로 만든다. 계획을 세우지 말자는 말이 아니다. 계획이 틀릴 것을 전제로, 틀렸다는 사실을 빨리 알아내는 구조를 만들자는 말이다.

핵심 개념

애자일 선언 (2001)

2001년 미국 유타에 모인 17명의 개발자가 애자일 소프트웨어 개발 선언을 발표했다. 네 가지 가치는 다음과 같다.

더 중시하는 것 덜 중시하는 것
개인과 상호작용 프로세스와 도구
동작하는 소프트웨어 포괄적인 문서
고객과의 협력 계약 협상
변화에 대응하기 계획을 따르기

선언문은 마지막에 “오른쪽 항목도 가치가 있지만, 왼쪽 항목을 더 가치 있게 여긴다” 고 분명히 적었다. 문서와 계획을 버리라는 뜻이 아니다. 여기에 12가지 원칙이 붙는다. “동작하는 소프트웨어를 몇 주에서 몇 달 간격으로, 더 짧은 주기를 선호하며 자주 전달하라”, “동작하는 소프트웨어가 진척의 주된 척도다” 같은 문장이 있다.

애자일은 방법론 하나의 이름이 아니라 가치의 묶음이다. 스크럼, 칸반, XP(익스트림 프로그래밍) 등이 이 가치를 각자 다른 방식으로 구현한다.

스크럼의 뼈대: 3-5-3

스크럼의 공식 정의는 Ken Schwaber 와 Jeff Sutherland 가 관리하는 스크럼 가이드다. 2020년 11월판 기준으로 정리하면 세 가지 책임, 다섯 가지 이벤트, 세 가지 산출물이다.

책임(accountabilities)

책임 하는 일
프로덕트 오너 제품 백로그를 관리하고 순서를 정한다. 제품 가치를 극대화할 책임
스크럼 마스터 팀과 조직이 스크럼을 제대로 이해·실천하도록 돕는다
개발자 스프린트마다 사용 가능한 증분(Increment)을 만든다

스크럼 팀은 보통 10명 이하다. 2020년판은 “개발 팀” 이라는 하위 팀 개념을 없애고 하나의 스크럼 팀으로 묶었다.

이벤트(events)

┌──────────────────── 스프린트 (1개월 이하, 고정 길이) ────────────────────┐
│ 스프린트 계획 → [데일리 스크럼 × 매일] → 스프린트 리뷰 → 스프린트 회고 │
└───────────────────────────────────────────────────────────────────────┘
                     끝나자마자 다음 스프린트 시작
이벤트 시간 상한(1개월 스프린트 기준) 목적
스프린트 계획 8시간 왜(스프린트 목표), 무엇을, 어떻게 할지 정한다
데일리 스크럼 15분 스프린트 목표를 향한 진행을 점검하고 계획을 조정한다
스프린트 리뷰 4시간 결과를 이해관계자에게 보여 주고 다음 방향을 논의한다
스프린트 회고 3시간 일하는 방식(사람, 도구, 프로세스)을 개선한다

스프린트가 짧으면 각 이벤트 시간도 보통 줄어든다. 리뷰는 “제품” 을, 회고는 “팀의 일하는 방식” 을 점검한다는 차이를 기억해 두자.

산출물(artifacts)과 약속(commitments)

산출물 함께 붙는 약속
제품 백로그 제품 목표(Product Goal)
스프린트 백로그 스프린트 목표(Sprint Goal)
증분(Increment) 완료의 정의(Definition of Done)

완료의 정의는 “끝났다” 를 팀이 같은 뜻으로 쓰게 만드는 장치다. 예를 들어 “코드 리뷰 통과, 단위 테스트 통과, 스테이징 배포 확인” 까지가 완료라고 정해 두면, 리뷰 안 받은 코드를 “거의 다 했다” 고 말하는 일이 사라진다.

경험주의: 투명성·점검·적응

스크럼 가이드는 스크럼이 경험주의(empiricism)에 기반한다고 쓴다. 결정은 이미 알려진 것을 바탕으로 내리고, 세 기둥으로 이를 지탱한다.

  • 투명성: 진행 상황과 산출물이 관련자 모두에게 보인다.
  • 점검: 자주 들여다보고 문제를 찾는다. 다섯 이벤트가 모두 점검 지점이다.
  • 적응: 문제가 보이면 가능한 한 빨리 고친다.

스크럼과 칸반

항목 스크럼 칸반
주기 고정 길이 스프린트 연속 흐름
작업량 제한 스프린트 단위로 담는 양을 정함 단계별 WIP(진행 중 작업) 한도
역할 세 가지 책임이 정의됨 별도 역할 정의 없음
맞는 곳 기능 개발 팀 운영·지원처럼 일이 불규칙하게 들어오는 팀

직접 해 보기

스프린트 동안 남은 작업량을 그리는 번다운(burndown)을 텍스트로 만들어 본다. 스토리 포인트는 팀이 상대적 크기를 매기는 단위로, 시간과 1:1 대응하지 않는다.

sprint_days = 10
committed = 40  # 이번 스프린트에 담은 스토리 포인트
done_per_day = [0, 3, 5, 0, 8, 2, 5, 0, 6, 5]  # 매일 완료된 포인트

remaining = committed
print("일차  이상선  실제  그래프")
for day, done in enumerate(done_per_day, start=1):
    remaining -= done
    ideal = committed - committed * day / sprint_days
    bar = "#" * remaining
    flag = " <- 뒤처짐" if remaining > ideal + 5 else ""
    print(f"{day:>3}  {ideal:5.1f}  {remaining:4d}  {bar}{flag}")

print(f"\n완료 {committed - remaining} / {committed} 포인트")
print("남은 작업은 다음 스프린트 계획에서 제품 백로그로 돌아가 다시 순서를 정한다.")

실행 결과:

일차  이상선  실제  그래프
  1   36.0    40  ########################################
  2   32.0    37  #####################################
  3   28.0    32  ################################
  4   24.0    32  ################################ <- 뒤처짐
  5   20.0    24  ########################
  6   16.0    22  ###################### <- 뒤처짐
  7   12.0    17  #################
  8    8.0    17  ################# <- 뒤처짐
  9    4.0    11  ########### <- 뒤처짐
 10    0.0     6  ###### <- 뒤처짐

완료 34 / 40 포인트
남은 작업은 다음 스프린트 계획에서 제품 백로그로 돌아가 다시 순서를 정한다.

번다운은 데일리 스크럼에서 “지금 속도로 스프린트 목표를 지킬 수 있는가” 를 묻는 도구다. 사람을 평가하는 지표로 쓰면 팀이 포인트를 부풀리기 시작하고, 그 순간 쓸모가 없어진다.

현업에서는

  • “애자일을 한다” 와 “스크럼 이벤트를 연다” 는 다르다. 회의는 다 하는데 스프린트 끝에 배포 가능한 증분이 나오지 않으면, 그것은 짧게 쪼갠 폭포수다. 완료의 정의에 “배포 가능” 을 넣는 것이 가장 효과적인 교정이다.
  • 회고가 가장 먼저 사라진다. 바쁘면 회고를 건너뛰는데, 회고가 없으면 같은 문제가 매 스프린트 반복된다. 회고에서 나온 개선 항목 한두 개를 다음 스프린트 백로그에 실제로 넣는 팀이 개선된다.
  • 운영 업무는 칸반이 맞을 때가 많다. 홈랩 클러스터처럼 장애 대응, 인증서 갱신, 노드 점검이 예고 없이 들어오는 일은 2주 단위 약속보다 WIP 한도를 둔 칸반 보드로 관리하는 편이 자연스럽다.
  • 도구가 프로세스를 대신하지 않는다. 이슈 트래커의 스프린트 기능을 켠다고 스크럼이 되지 않는다. 선언문 첫 줄이 “프로세스와 도구보다 개인과 상호작용” 이다.

확인 문제

  1. 애자일 선언의 네 가지 가치 중 “동작하는 소프트웨어” 와 짝을 이루는 덜 중시하는 항목은 무엇인가?
  2. 스크럼 가이드(2020)의 세 가지 책임을 쓰라.
  3. 스프린트 리뷰와 스프린트 회고는 각각 무엇을 점검하는가?
  4. “완료의 정의” 는 어떤 산출물에 붙는 약속인가?
  5. 위 번다운 예제에서 스프린트가 끝났을 때 남은 6포인트는 어떻게 처리되는가?

풀이

  1. 포괄적인 문서.
  2. 프로덕트 오너, 스크럼 마스터, 개발자.
  3. 리뷰는 만들어진 제품(증분)과 다음 방향을, 회고는 팀이 일하는 방식(사람·도구·프로세스)을 점검한다.
  4. 증분(Increment).
  5. 완료로 치지 않는다. 제품 백로그로 돌아가 프로덕트 오너가 다시 우선순위를 정하고, 다음 스프린트 계획에서 담을지 결정한다.

더 읽을거리 (References)