Agile과 Scrum 완벽 가이드 - 개발자를 위한 애자일 방법론
워터폴에서 애자일로의 전환, Scrum 프레임워크의 역할, 용어, 진행 방식까지. 현대 소프트웨어 개발의 핵심 방법론을 상세히 알아봅니다.
현대 소프트웨어 개발에서 빼놓을 수 없는 Agile과 Scrum 방법론에 대해 알아봅니다.
Agile이란?
Agile의 사전적 의미는 다음과 같습니다:
- 날렵한, 민첩한 (= nimble)
- (생각이) 재빠른, 기민한
소프트웨어 개발에서 Agile은 ‘유연하게 일하는 방식’을 의미합니다.
Agile의 탄생 배경
전통적인 소프트웨어 개발 방식에서는 ‘연속적인 고객의 요구사항 변경’으로 인해 프로젝트가 실패하는 경우가 빈번했습니다. 이를 해결하기 위해 소프트웨어 세계의 거장들이 모여 2001년 선언문을 작성하게 되었고, 이것이 바로 애자일 소프트웨어 개발 선언(Agile Manifesto)입니다.
애자일 선언문의 핵심 가치
1
2
3
4
5
6
7
8
9
10
11
12
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서
소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
◆ 공정과 도구보다 개인과 상호작용을
◆ 포괄적인 문서보다 작동하는 소프트웨어를
◆ 계약 협상보다 고객과의 협력을
◆ 계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
Waterfall vs Agile
Waterfall Model (폭포수 모델)
전통적인 순차적 개발 방식:
1
요구분석 → 설계 → 디자인 → 코딩 → 테스트 → 배포
특징:
- 각 단계가 완료되어야 다음 단계로 진행
- 요구사항 변경이 어려움
- 후반부에 문제 발견 시 비용이 큼
- 고객 피드백을 받기까지 오랜 시간 소요
Agile Model
짧은 주기의 반복적 개발 방식:
계획
개발
테스트
리뷰
계획
개발
테스트
리뷰
특징:
- 짧은 주기로 실제 사용 가능한 소프트웨어 제공
- 커뮤니케이션 비용 최소화
- 이슈를 즉시 발견하고 해결
- 변화하는 요구사항에 유연하게 대응
Agile 실천 방법론
Agile의 개념을 실천할 수 있도록 만들어진 도구들:
| 방법론 | 특징 |
|---|---|
| Scrum | 스프린트 기반 반복 개발, 가장 널리 사용 |
| Kanban | 시각적 작업 흐름 관리, 작업 제한(WIP) |
| XP (eXtreme Programming) | 짝 프로그래밍, TDD, 지속적 통합 |
| Lean Software Development | 낭비 제거, 빠른 전달, 팀 역량 강화 |
⚠️ 주의: 이들 방법론은 애자일이라는 용어가 나오기 전부터 존재했습니다. 애자일 선언문 발표 이후 자연스럽게 애자일 범주 안에 포함되었습니다.
Scrum이란?
Scrum은 특정 개발 언어나 방법론에 의존적이지 않으며, 제품 개발뿐만 아니라 일반적인 프로젝트 관리에도 사용 가능한 프로세스 프레임워크입니다.
Scrum의 어원
‘Scrum’은 럭비에서 경기를 재개하기 위해 팀원이 서로 밀착하여 형성하는 전술 대형을 가리킵니다. 팀워크와 협력을 강조하는 의미가 담겨 있습니다.
📚 역사: Scrum은 노나카 이쿠지로와 타케우치 히로타카에 의해 처음 등장했지만, Jeff Sutherland와 Ken Schwaber가 영감을 받아 실천 기법으로 개발하고 발전시켰습니다.
Scrum의 특성
Scrum이 추구하는 핵심 특성:
1
2
3
4
5
6
7
8
9
10
11
12
✅ 솔루션에 포함할 기능/개선점에 대한 우선순위 부여
✅ 개발 주기는 30일 정도로 조절하고,
매 주기마다 실제 동작 가능한 결과물 제공
✅ 개발 주기마다 적용할 기능/개선 목록 제공
✅ 매일 15분 정도의 스탠드업 미팅
✅ 항상 팀 단위로 생각
✅ 원활한 의사소통을 위한 열린 공간 유지
Scrum의 5가지 핵심 가치
| 가치 | 설명 |
|---|---|
| 확약 (Commitment) | 약속한 것을 실현하는 것 |
| 전념 (Focus) | 확약한 것의 실현에 전념하는 것 |
| 정직 (Openness) | 어떤 것이 자신에게 불리해도 숨기지 않는 것 |
| 존중 (Respect) | 자신과 다른 사람에게 경의를 표하는 것 |
| 용기 (Courage) | 팀원 간 갈등과 도전을 통해 올바른 일을 할 수 있는 용기 |
Scrum의 3가지 역할
1. Product Owner (PO)
역할: 비즈니스 목표를 충족시키는 제품을 만들기 위해 제품 요구사항 백로그를 작성
책임:
- 고객 및 조직 가치에 기반한 우선순위 결정
- 제품 백로그 항목들의 우선순위 관리
- 매 스프린트 결과 검토 및 우선순위 조정
- 제품 비전 제시
2. Scrum Master
역할: 프로젝트 관리자이자 코치
책임:
- 스크럼이 잘 수행될 수 있도록 지원
- 팀의 자기 조직화(Self-organization) 촉진
- 스크럼 원칙이 팀에 잘 적용되도록 가이드
- 장애물 제거 및 문제 해결
- 투명한 의사결정 지원
💡 핵심: Scrum Master는 명령하는 관리자가 아닌, 팀을 지원하는 서번트 리더(Servant Leader)입니다.
3. Scrum Team (개발팀)
구성: 프로젝트 수행에 필요한 모든 역량을 갖춘 크로스 펑셔널 팀
특징:
- 관련된 모든 부서에서 팀원 구성 (디자이너, 개발자, 테스터 등)
- 전문 영역에 고정되지 않고 다 같이 팀 과제 수행
- 작업 정의와 할당은 팀원 자율로 진행
- 끈끈한 협업 체계 유지
권장 규모: 3~9명 (너무 작으면 협업 이점이 적고, 너무 크면 조율이 어려움)
Scrum 주요 용어
제품 백로그 (Product Backlog)
개발할 제품에 대한 우선순위가 부여된 요구사항 목록
1
2
3
4
5
6
예시:
1. [P0] 사용자 로그인 기능
2. [P0] 상품 검색 기능
3. [P1] 상품 필터링 기능
4. [P2] 리뷰 작성 기능
5. [P3] 위시리스트 기능
특징:
- Product Owner가 관리
- 우선순위에 따라 지속적으로 정렬
- 제품 완성에 필요한 모든 요구사항 포함
스프린트 (Sprint)
정의: 반복적인 개발 주기
기간: 보통 1~4주 (2주가 가장 일반적)
1
2
3
4
5
Sprint 1 (2주)
├── Day 1: Sprint Planning
├── Day 2-9: Daily Scrum + 개발
├── Day 10: Sprint Review
└── Day 10: Sprint Retrospective
특징:
- 계획, 개발, 리뷰 작업 등 최소 단위의 Cycle
- 기간 중에는 스프린트 목표 변경 불가
- 매 스프린트마다 실행 가능한 제품 증분 생산
스프린트 계획 회의 (Sprint Planning Meeting)
목적: 스프린트 목표와 스프린트 백로그 계획
진행 방식:
- Part 1: 무엇을 할 것인가? (What)
- Product Owner가 우선순위 높은 백로그 제시
- 팀이 이번 스프린트에서 완료 가능한 항목 선택
- Part 2: 어떻게 할 것인가? (How)
- 선택한 백로그를 구체적인 작업으로 분해
- 스프린트 백로그 작성
소요 시간: 4주 스프린트 기준 약 8시간
스프린트 백로그 (Sprint Backlog)
정의: 스프린트 목표 달성을 위해 필요한 작업 목록
1
2
3
4
5
6
7
8
9
스프린트 목표: 사용자 인증 기능 구현
스프린트 백로그:
□ 로그인 UI 컴포넌트 개발 (4h)
□ 회원가입 API 엔드포인트 개발 (6h)
□ JWT 토큰 발급 로직 구현 (4h)
□ 비밀번호 암호화 적용 (2h)
□ 로그인 유효성 검사 (3h)
□ 단위 테스트 작성 (4h)
특징:
- 개발팀이 자율적으로 관리
- 스프린트 중 새로운 작업 추가 가능
- 완료 기준(Definition of Done) 명확히 정의
일일 스크럼 회의 (Daily Scrum Meeting)
형식: 매일 진행되는 15분 스탠드업 미팅
3가지 질문:
- 어제 무엇을 했는가?
- 오늘 무엇을 할 것인가?
- 장애물은 무엇인가?
1
2
3
4
5
6
7
8
9
10
// 예시
김개발:
- 어제: 로그인 API 엔드포인트 완료
- 오늘: JWT 토큰 발급 로직 구현
- 장애물: CORS 이슈 발생, 해결 방법 논의 필요
이디자인:
- 어제: 로그인 화면 UI 디자인 완료
- 오늘: 회원가입 화면 작업 시작
- 장애물: 없음
원칙:
- 수평적 공유 (관리자와 PO 참석은 선택사항)
- 문제 해결이 아닌 현황 공유 (자세한 논의는 별도 진행)
- 서서 진행하여 간결함 유지
실행 가능한 제품 (Shippable Product)
정의: 스프린트 결과로 나오는 실제로 작동하는 제품 증분
관련 개념:
- 잠재적 출시 가능 제품 (Potentially Shippable Product Increment)
- 실제 출시 여부와 관계없이 출시할 수 있는 수준의 완성도
- 최소 실행 가능 제품 (Minimum Viable Product, MVP)
- 최소 노력으로 고객 검증을 받을 수 있는 수준의 제품
스프린트 리뷰 (Sprint Review)
목적: 완성된 제품 증분을 검토하고 피드백 수집
참석자: 스크럼 팀, Product Owner, 이해관계자
진행 방식:
- 완료된 작업 시연 (Demo)
- 이해관계자 피드백 수집
- 제품 백로그 업데이트 논의
- 다음 스프린트 계획 논의
소요 시간: 4주 스프린트 기준 약 4시간
스프린트 회고 (Sprint Retrospective)
목적: 팀의 프로세스 개선
진행 방식 (다양한 형식 가능):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
잘한 것 (Keep):
- 매일 스탠드업 미팅을 시간 내에 마침
- 코드 리뷰가 활발했음
아쉬웠던 것 (Problem):
- 일부 작업 추정이 부정확했음
- 테스트 코드 작성이 미흡했음
개선할 것 (Try):
- 다음 스프린트부터 추정 시 과거 데이터 참고
- TDD 방식 도입 시도
새로 시작할 것 (Action):
- 주 2회 페어 프로그래밍 세션
원칙:
- 비난이 아닌 학습과 개선 지향
- 구체적이고 실행 가능한 액션 아이템 도출
- 팀원 모두의 참여
소멸 차트 (Burn-down Chart)
스프린트 진행 상황을 시각화하는 차트:
해석:
- 빨간 선 (계획): 이상적으로 작업이 완료되는 추세
- 파란 선 (실제):
- 빨간 선보다 아래 → 계획보다 빠른 진행
- 빨간 선보다 위 → 계획보다 느린 진행
⚠️ 주의: 소멸 차트는 진행 상황 파악 도구이지, 팀원을 평가하거나 비난하는 척도로 사용해서는 안 됩니다.
증분 (Increment)
정의: 매 스프린트에서 팀이 개발한 제품 기능
조건:
- 잠재적으로 출시 가능
- Product Owner의 이해관계자들에게 효용 제공
- 이전 증분과 통합되어 누적
Scrum 진행 프로세스
전체 흐름도
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
1. 제품 백로그 작성 (PO)
↓
2. 스프린트 계획 회의
↓
3. 스프린트 백로그 작성
↓
4. 스프린트 실행 (1-4주)
├── 매일 Daily Scrum
└── 개발 작업
↓
5. 스프린트 리뷰
↓
6. 스프린트 회고
↓
7. 다음 스프린트로 반복
상세 진행 순서
1단계: 제품 백로그 정의
Product Owner가 제품에서 요구하는 기능과 우선순위를 제품 백로그로 정의합니다.
1
2
3
4
5
6
7
8
예시:
[P0] 사용자 인증 (로그인/회원가입)
[P0] 상품 목록 조회
[P1] 상품 검색 및 필터링
[P1] 장바구니 기능
[P2] 결제 시스템
[P2] 주문 내역 조회
[P3] 리뷰 작성
2단계: 스프린트 범위 조율
PO가 정한 우선순위에서 어디까지 작업할지 팀과 조율합니다.
1
2
3
4
5
6
7
8
Sprint 1 목표: 사용자 인증 기능 완성
- [✓] 로그인 기능
- [✓] 회원가입 기능
- [✓] 비밀번호 재설정
Sprint 2 목표: 상품 기본 기능
- [ ] 상품 목록 조회
- [ ] 상품 상세 보기
3단계: 스프린트 백로그 작성
스프린트 목표를 구현 가능하도록 구체적인 작업으로 분해합니다.
💡 중요: 개발팀의 개발 속도(Velocity)를 예측하며 조정하는 것이 핵심입니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
개발 속도 (Velocity) 예측:
- 지난 스프린트: 40 story points 완료
- 이번 스프린트 목표: 35-45 story points
작업 분해:
□ 로그인 UI (5pt)
□ 로그인 API (8pt)
□ 회원가입 UI (5pt)
□ 회원가입 API (8pt)
□ JWT 인증 (8pt)
□ 비밀번호 암호화 (3pt)
□ 테스트 코드 (8pt)
───────────────────
합계: 45pt
4단계: 일일 스크럼
스프린트 기간 동안 매일 정해진 시간과 장소에서 모든 개발팀원이 참여하는 15분 미팅을 진행합니다.
1
2
3
시간: 매일 오전 10시
장소: 회의실 A (또는 Zoom)
형식: 스탠드업
5단계: 스프린트 리뷰
스프린트 종료 시 스프린트 리뷰 미팅을 통해 만들어진 제품을 학습하고 이해합니다.
체크리스트:
- [✓] 모든 완료된 기능 시연
- [✓] 이해관계자 피드백 수집
- [✓] 미완료 작업 파악
- [✓] 다음 스프린트 우선순위 조정
6단계: 스프린트 회고
제품 학습이 끝나면 스프린트 회고를 통해 팀의 개발 프로세스 개선 시간을 갖습니다.
목표:
- 프로세스 개선
- 팀워크 강화
- 생산성 향상
7단계: 백로그 준비 (Backlog Refinement)
다음 스프린트를 준비하기 위해 PO와 필요 인원이 모여 백로그를 정제하는 시간을 갖습니다.
활동:
- 새로운 사용자 스토리 추가
- 기존 백로그 항목 상세화
- 우선순위 재조정
- 추정(Estimation) 진행
Scrum 도입 시 주의사항
1. 형식적 도입 지양
1
2
3
4
5
❌ 잘못된 접근:
"일단 Daily Scrum 미팅만 하면 스크럼이다"
✅ 올바른 접근:
스크럼의 가치와 원칙을 이해하고 팀에 맞게 적용
2. 자기 조직화 존중
스크럼 팀은 자기 조직화(Self-organization) 능력을 가져야 합니다.
- 팀원이 스스로 작업을 선택
- 문제 해결 방법을 팀이 결정
- 외부의 명령이 아닌 내부의 합의로 진행
3. 점진적 개선
완벽한 스크럼은 없습니다. 회고를 통한 지속적 개선이 핵심입니다.
1
2
3
4
5
6
7
Sprint 1: 기본 스크럼 프로세스 적용
↓
Sprint 2: 회고를 통해 Daily Scrum 시간 조정
↓
Sprint 3: 추정 방법 개선 (Planning Poker 도입)
↓
지속적 개선...
4. 도구보다 사람
트렐로, 지라 같은 도구는 보조 수단일 뿐입니다.
1
2
3
4
중요한 순서:
1. 팀원 간의 소통과 협력
2. 스크럼 원칙의 이해와 실천
3. 도구를 활용한 효율화
실전 적용 팁
스프린트 길이 선택
| 기간 | 장점 | 단점 | 적합한 경우 |
|---|---|---|---|
| 1주 | 빠른 피드백 | 계획/회고 오버헤드 | 요구사항 변경이 매우 잦을 때 |
| 2주 | 균형 잡힌 속도 | - | 가장 일반적, 추천 |
| 3주 | 안정적 개발 | 피드백 지연 | 복잡한 기능 개발 |
| 4주 | 깊이 있는 개발 | 방향 전환 어려움 | 연구 개발 프로젝트 |
추정 기법
Planning Poker:
1
2
3
4
5
1. 각 팀원이 추정 카드를 받음 (1, 2, 3, 5, 8, 13...)
2. 작업에 대해 논의
3. 동시에 카드를 공개
4. 차이가 크면 이유를 논의하고 재추정
5. 합의에 도달할 때까지 반복
T-Shirt 사이징: XS, S, M, L, XL로 대략적 추정
완료의 정의 (Definition of Done)
명확한 완료 기준을 팀이 합의해야 합니다:
1
2
3
4
5
6
✅ 코드 작성 완료
✅ 단위 테스트 통과
✅ 코드 리뷰 완료
✅ 통합 테스트 통과
✅ 문서화 완료
✅ Product Owner 승인
마치며
Agile과 Scrum은 단순한 개발 방법론이 아닌, 일하는 방식과 문화의 변화입니다.
핵심 원칙
1
2
3
4
5
1. 고객과의 지속적인 협력
2. 변화에 대한 유연한 대응
3. 짧은 주기의 가치 전달
4. 자기 조직화된 팀
5. 지속적인 개선
성공적인 스크럼 적용을 위해
- ✅ 팀 전체의 합의와 의지
- ✅ Product Owner의 적극적 참여
- ✅ 경험 있는 Scrum Master
- ✅ 조직 차원의 지원
- ✅ 인내심과 끈기 (변화는 시간이 필요합니다)
Scrum은 완벽한 해결책이 아닙니다. 하지만 팀이 함께 배우고 성장하는 강력한 도구입니다.