SW Engineering · 한장정리
[기술사토픽] 애자일 & 스크럼 완벽 정리 - 한장정리
애자일 선언문 4대 가치·12원칙, 스크럼 3역할·3산출물·5이벤트, XP 핵심 실천법, 칸반까지 정보관리기술사·컴퓨터시스템응용기술사 빈출 주제를 완벽 정리합니다.
Ⅰ. 변화에 유연한 개발 방법론, 애자일의 개요
개념: 애자일(Agile)은 2001년 17인의 소프트웨어 개발자들이 발표한 애자일 선언문(Agile Manifesto)을 기반으로, 짧은 반복 주기로 작동하는 소프트웨어를 빠르게 제공하며 변화에 유연하게 대응하는 개발 철학입니다.
특징: (1) 반복·점진적(Iterative & Incremental) 개발 (2) 고객 협업과 빠른 피드백 중심 (3) 변화를 계획보다 우선시
가. 애자일 선언문 4대 가치 (필수 암기)
VALUE 01
개인과 상호작용
▶ 우선 ▶
프로세스와 도구
VALUE 02
작동하는 소프트웨어
▶ 우선 ▶
포괄적인 문서
VALUE 03
고객과의 협력
▶ 우선 ▶
계약 협상
VALUE 04
변화에 대응
▶ 우선 ▶
계획 준수
시험 포인트
오른쪽 항목도 가치 있지만 왼쪽을 더 우선시한다는 것이 핵심. "우선시"라는 표현 그대로 암기!
Ⅱ. 스크럼(Scrum) 구조 및 구성요소
스크럼(Scrum)은 가장 널리 사용되는 애자일 프레임워크로, 2~4주 Sprint 단위로 개발을 반복하며 제품을 점진적으로 완성합니다.
가. 스크럼 Sprint 흐름도
INPUT
Product
Backlog
Backlog
→
PLANNING
Sprint
Planning
Planning
→
SPRINT (2~4주)
Sprint Backlog
Daily Scrum(15분)
개발 작업
→
OUTPUT
Shippable
Increment
Increment
→
REVIEW
Sprint Review
Retrospective
나. 스크럼 3·3·5 구성요소
| 구분 | 항목 | 설명 |
|---|---|---|
| 3가지 역할 |
Product Owner | Product Backlog 소유·우선순위 결정, 비즈니스 가치 극대화 |
| Scrum Master | 팀 장애 제거, 스크럼 프로세스 코치, 외부 간섭 차단 | |
| Dev Team | 자기 조직화 팀, Sprint 내 개발·테스트 전담 (3~9명) | |
| 3가지 산출물 |
Product Backlog | 전체 요구사항 목록, PO가 우선순위 관리 |
| Sprint Backlog | 해당 Sprint에서 처리할 작업 목록 | |
| Increment | Sprint 완료 후 동작 가능한 제품 증분 | |
| 5가지 이벤트 |
Sprint | 2~4주 고정 반복 주기, 목표 변경 불가 |
| Sprint Planning | Sprint 목표·작업 계획 수립 (최대 8시간) | |
| Daily Scrum | 매일 15분 진행상황 공유 (어제·오늘·장애물) | |
| Sprint Review | Increment 시연, 이해관계자 피드백 수집 | |
| Retrospective | 팀 프로세스 개선 논의 (최대 3시간) |
Ⅲ. XP 핵심 실천법 및 애자일 방법론 비교
가. XP(eXtreme Programming) 핵심 실천법
Kent Beck이 제안한 기술 실천법 중심의 애자일 방법론. 코드 품질과 팀 협업에 집중합니다.
01
TDD
테스트 먼저 작성 후 코드 구현
02
페어 프로그래밍
2인 1조 코드 작성·리뷰
03
리팩토링
기능 변경 없이 코드 구조 개선
04
CI (지속적 통합)
하루 여러 번 통합·빌드·테스트
05
소규모 릴리스
짧은 주기로 빈번하게 배포
06
코딩 표준
팀 전체 공통 코드 스타일 준수
나. 애자일 방법론 비교
| 구분 | 스크럼 | XP | 칸반 |
|---|---|---|---|
| 제안자 | Sutherland·Schwaber | Kent Beck | Toyota 생산방식 |
| 중심 | 프로세스·역할 | 기술 실천법 | 흐름·시각화 |
| 반복 주기 | Sprint (2~4주) | Iteration (1~2주) | 고정 없음 (흐름) |
| 핵심 도구 | Backlog, 번다운 차트 | TDD, 페어 프로그래밍 | 칸반 보드, WIP 제한 |
| 역할 정의 | PO·SM·Dev Team | Coach·Customer | 역할 없음 |
| 적합 상황 | 일반 SW 개발 | 기술적 탁월성 필요 | 운영·유지보수 |
Ⅳ. 결론 및 전문가 의견
결론
애자일은 단순한 개발 방법론을 넘어 조직 문화와 사고방식의 전환을 요구합니다.
향후 DevOps·MLOps와의 융합, AI 기반 자동화 스프린트, 분산 팀을 위한 비동기 스크럼으로 발전하며 디지털 전환(DX)의 핵심 방법론으로 확장될 것입니다.
"애자일은 변화를 '관리'하는 것이 아니라 변화를 '환영'하는 철학이며, 스크럼은 그 철학을 현장에서 실천하는 가장 검증된 프레임워크이다."
블로그: 기술사 학습노트 · imt-log.tistory.com
'소프트웨어공학' 카테고리의 다른 글
| DevOps CI/CD 형상관리 개념 정리 (0) | 2026.03.19 |
|---|---|
| 소프트웨어 테스팅 기법과 전략 총정리 (0) | 2026.03.19 |
| SOLID 원칙 객체지향 설계 패턴 정리 (0) | 2026.03.18 |
| SDLC 소프트웨어 개발 생명주기 총정리 (0) | 2026.03.18 |
| 소프트웨어공학 완전정복 — 기술사 핵심 토픽 모음 (0) | 2026.03.18 |