agile scrum team

 

📷 Photo by airfocus on Unsplash

저는 처음 기획자 공부를 시작했을 때, "애자일"이라는 단어를 정말 많이 들었습니다. 스타트업 채용공고에도, 현업 기획자 인터뷰에도 항상 나오는 단어였는데, 막상 찾아보면 "빠르게 일하는 방식" 정도로만 설명이 되어 있어서 구체적인 실체가 잘 와닿지 않았습니다. 이 글은 애자일/스크럼이 처음인 분, PM이나 서비스기획자를 준비하면서 면접에서 애자일을 어떻게 설명해야 할지 고민하신 분들을 위해 씁니다.


1. 애자일이 등장한 배경 — 계획대로만 가면 무슨 일이 생길까?

애자일을 이해하려면 먼저 기존 방식인 폭포수(Waterfall)의 한계를 알아야 합니다. 폭포수 방식은 요구사항 정의부터 배포까지 각 단계가 순차적으로 진행되며, 전 단계가 완료되어야 다음 단계로 넘어갈 수 있습니다.

📉 폭포수(Waterfall) 방식 — 순차적 단방향 흐름
📋 요구사항
🖊 설계
💻 개발
🔍 테스트
🚀 배포

⚠️ 문제: 배포 직전에야 고객 피드백 가능! 수정 비용이 폭발적으로 증가!

요구사항이 매주 바뀌는 환경에서 3개월 뒤에 한 번만 결과물을 공개한다면 어떻게 될까요? 고객이 원한 것과 우리가 만든 것이 어긋났을 때, 이미 모든 비용이 소진된 후입니다. 이 문제를 해결하기 위해 2001년 17명의 개발자들이 모여 애자일 선언문(Agile Manifesto)을 발표했습니다. (참고: 공식 Agile Manifesto, Nielsen Norman Group - Agile for UX)


2. 애자일 선언문 4대 핵심 가치

저는 이 4가지 가치가 정말 단순하면서도 강력하다고 느꼈습니다. 오른쪽이 중요하지 않다는 게 아니라, 왼쪽을 더 우선한다는 뜻입니다.

✅ 더 우선하는 것 ⚖️ 덜 중요하지 않지만 차선인 것
개인과 상호작용 프로세스와 도구
작동하는 소프트웨어 포괄적인 문서
고객과의 협력 계약 협상
변화에 대응 계획 따르기

핵심: 애자일은 "계획을 무시하자"가 아닙니다. "계획보다 변화에 더 잘 대응하자"는 것입니다.


3. 스크럼(Scrum) — 애자일 실천 프레임워크

애자일은 "철학"이고, 스크럼은 그 철학을 실천하는 "프레임워크"입니다. 스크럼을 처음 배울 때 제가 가장 많이 헷갈렸던 것이 방법론과 프레임워크의 차이였습니다.

구분 방법론 (Methodology) 프레임워크 (Framework)
정의 구체적인 방법과 절차 제공 구조와 규칙만 제공
특징 단계·절차·도구 비교적 고정 팀 상황에 맞게 유연 적용
예시 워터폴(Waterfall), RUP 스크럼(Scrum), 칸반(Kanban)

🔄 스프린트(Sprint) 사이클 — 2주가 한 사이클

스프린트 한 사이클 (2주 기준)
📋
Sprint Planning
무엇을 할까?
개발 실행
+ Daily Scrum
🔎
Sprint Review
결과물 시연
🔁
Retrospective
프로세스 개선
↻ 완료 후 다음 스프린트로 반복

4. 스크럼 3대 역할(Roles)

스크럼에는 명확한 역할 구분이 있습니다. 저는 처음에 PO랑 PM이 같은 것인지 헷갈렸는데, 스크럼 맥락에서는 명확히 다릅니다.

👑
Product Owner (PO)
  • 무엇을 만들 것인가 결정
  • 제품 백로그 관리 및 우선순위 결정
  • 이해관계자 ↔ 개발팀 조율
💡 "왜 이걸 만들어야 하는가"를 항상 설명할 수 있어야 한다
🛡️
Scrum Master (SM)
  • 스크럼 프로세스 코칭
  • 장애물(Impediment) 제거
  • 서번트 리더십 실천
💡 팀의 상사가 아님 — 팀을 위해 일하는 사람
⚙️
Development Team
  • 어떻게 만들 것인가 결정
  • 자기 조직화(self-organizing)
  • 교차 기능(cross-functional)
  • 보통 3~9명
💡 외부에서 작업 지시받지 않고 스스로 계획·실행

5. 스크럼 3대 산출물(Artifacts) — 무엇을 만들고 관리하는가?

세 가지 산출물이 서로 연결되어 작동하는 구조를 이해하면 스크럼의 전체 흐름이 한눈에 보입니다.

📦 스크럼 3대 산출물 관계도
📃
Product Backlog
모든 기능 목록
(PO 소유 · 우선순위 변경)
스프린트 계획 시 선택
📋
Sprint Backlog
이번 스프린트 작업목록
(팀 소유)
스프린트 종료 시 산출
Increment
동작하는 결과물
(잠재적 출시 가능)

Definition of Done(DoD)이란 기능이 "완료"됐다고 볼 수 있는 팀 내 합의 기준입니다. 예를 들어 "코드 리뷰 완료 + QA 통과 + 스테이징 배포"가 DoD라면, 이 세 가지가 모두 충족되어야 Increment로 인정됩니다.


6. 스크럼 5대 이벤트(Events) 상세 설명

스크럼에는 스프린트 안에서 반드시 진행되는 5가지 공식 이벤트가 있습니다. 각 이벤트의 목적을 명확히 이해하는 것이 중요합니다.

📅 스프린트 이벤트 타임라인 (2주 스프린트 기준)
📋
Sprint Planning (1일차)
무엇을(PO 주도) + 어떻게(팀 주도)를 계획
☀️
Daily Scrum (매일 15분)
어제/오늘/장애물 — 보고가 아닌 팀 동기화
🔎
Sprint Review (마지막날)
결과물 시연 + 피드백 수집 → 백로그 업데이트
🔁
Sprint Retrospective (리뷰 직후)
프로세스 개선 — 잘된 것/개선할 것/액션 아이템

⚠️ Daily Scrum은 보고 시간이 아닙니다. 목적은 팀 내 동기화이고, 초점은 장애물과 우선순위 조정에 있습니다.


7. 핵심 용어 총정리 — 면접에서 바로 쓰는 용어 사전

저도 처음엔 이 용어들이 너무 많아서 헷갈렸습니다. 맥락과 함께 이해하면 훨씬 잘 기억됩니다.

용어 설명 비유/예시
Velocity 팀이 한 스프린트에서 완료한 스토리 포인트 합계 팀의 평균 작업 처리 속도 — 다음 스프린트 계획의 기준
Story Point 작업의 상대적 복잡도·노력 단위 (시간이 아님) 옷 사이즈처럼 상대적: S/M/L, 1/2/3/5/8...
User Story "나는 [사용자]로서 [목적]을 위해 [기능]을 원한다" 예: "구매자로서 주문 내역을 확인하고 싶다"
Epic 여러 User Story로 분해되는 큰 단위 기능 예: "결제 시스템" → 여러 개의 세부 User Story
Impediment 팀의 진행을 막는 장애물 (SM이 제거 지원) 예: 외부 API 응답 지연, 회의실 부족, 결정 미루기
Burndown Chart 스프린트 내 남은 작업량을 시각화한 그래프 이상적 선 vs 실제 선의 차이로 진행 현황 파악
WIP 현재 진행 중인 작업 (Work In Progress) 칸반에서는 WIP를 제한해서 집중도를 높임
MVP 핵심 가치를 검증할 수 있는 최소 기능 제품 완성품이 아닌, 가설 검증을 위한 최소 버전

8. 애자일 vs 폭포수 — 어느 상황에서 무엇을 써야 할까?

많은 분들이 "그럼 애자일이 항상 더 좋은 건가요?"라고 물어봅니다. 정답은 "상황에 따라 다릅니다"입니다. 이것이 기획자가 반드시 이해해야 할 관점입니다.

항목 폭포수(Waterfall) 애자일(Agile/Scrum)
계획 초기에 전체 계획 수립 반복적으로 계획 조정
요구사항 고정 (변경 어려움) 변화 허용 · 유연
결과물 공개 최종 완료 시 (한 번) 매 스프린트마다 (자주)
위험 관리 후반부에 발견 (비용 큼) 초기부터 지속 발견
고객 참여 초기·최종 중심 전 과정 지속 참여
팀 구조 기능별 분리 (사일로) 교차 기능 통합
적합 환경 요구사항 명확, 변화 없음 불확실성 높음, 빠른 피드백 필요

📌 요구사항이 명확하고 변화가 없는 환경(예: 건설, 법적 규제 강한 분야)에서는 폭포수가 더 효율적일 수 있습니다. 기획자는 프로젝트 맥락에 맞는 방법론을 선택할 수 있어야 합니다.


9. 기획자를 위한 마무리 정리

저는 애자일을 공부하면서 가장 크게 느낀 것이 있습니다. 애자일은 단순히 "빠르게 일하는 것"이 아니라, "올바른 것을 빠르게 검증하는 것"에 가깝다는 점입니다. 기획자는 이 철학을 팀 전체가 이해하고 실천할 수 있도록 돕는 역할을 합니다.

📌 이 글의 핵심 요약
  • 애자일 = 짧은 반복 주기로 자주 피드백을 받는 철학
  • 스크럼 = 애자일을 실천하는 가장 인기 있는 프레임워크
  • 스프린트 = 1~4주 단위 반복 사이클 (보통 2주)
  • PO = 무엇을 / SM = 프로세스 코칭 / Dev Team = 어떻게
  • Backlog → Sprint Backlog → Increment 순으로 흘러감
  • 애자일이 항상 정답은 아님 — 맥락에 맞는 방법론 선택이 중요

이 글과 함께 아래 관련 글들도 읽어보시면 기획자로서의 역량을 더 넓힐 수 있습니다.

+ Recent posts