Korean only
This page is available in Korean only. An English version will be added later.
애자일 · 스크럼 (Agile · Scrum)
I. 개요
- 정의: 애자일은 변화에 유연하게 대응하며 짧은 주기로 반복(iteration) 하여 동작하는 소프트웨어를 점진적으로 전달하는 개발 철학. 스크럼은 이를 구현하는 대표 프레임워크다.
- 배경 / 필요성: 요구사항이 자주 바뀌는 환경에서, 계획 중심의 폭포수는 변화 대응이 느리다. 2001년 애자일 선언(Agile Manifesto) 으로 체계화됐다.
II. 애자일 4대 가치
| 중시 | 보다 덜 |
|---|---|
| 개인과 상호작용 | 프로세스·도구 |
| 작동하는 소프트웨어 | 포괄적 문서 |
| 고객과의 협력 | 계약 협상 |
| 변화 대응 | 계획 준수 |
오른쪽도 가치 있으나 왼쪽을 더 중시한다.
III. 스크럼 — 구성
Product Backlog → (Sprint Planning) → Sprint Backlog
→ [Sprint 2~4주: Daily Scrum] → 증분(Increment)
→ Sprint Review(결과) → Sprint Retrospective(개선) → 반복
| 구분 | 요소 |
|---|---|
| 역할 | Product Owner(우선순위), Scrum Master(프로세스 촉진), Development Team |
| 이벤트 | Sprint, Sprint Planning, Daily Scrum, Review, Retrospective |
| 산출물 | Product Backlog, Sprint Backlog, Increment |
IV. 특징 · 장단점
| 구분 | 내용 |
|---|---|
| 장점 | 빠른 피드백, 변화 대응, 리스크 조기 발견, 투명성 |
| 단점 | 문서 부족 위험, 숙련된 팀·문화 필요, 범위 관리 어려움 |
| 고려사항 | 조직 문화·경영진 지원, 과도한 회의 경계, 명확한 DoD(완료 정의) |
V. 비교 — 폭포수 vs 애자일
| 구분 | 폭포수 | 애자일 |
|---|---|---|
| 진행 | 순차(분석→설계→구현→테스트) | 반복·점진 |
| 요구변경 | 어려움(후반 비용 큼) | 유연 |
| 전달 | 끝에 한 번 | 주기마다 조금씩 |
| 문서 | 많음 | 동작 SW 우선 |
VI. 적용 · 실무 관점
- 요구가 유동적인 신규 서비스·제품 개발에 적합. 규제·안전이 중요한 영역은 하이브리드(계획+반복).
- 확장형: 대규모엔 SAFe, LeSS 같은 스케일드 애자일. 운영까지 묶으면 DevOps로 연결.
VII. 결론
- 애자일은 "방법"이 아니라 변화에 대응하는 문화다. 스크럼은 그 실천 틀.
- 도구·의식만 도입하고 문화가 없으면 실패한다("가짜 애자일" 경계).