애자일 방법론
IT위키
더 많은 작업
- Agile
- 절차나 문서보다 사람과 업무 자체를 중요시하여 유연하고 신속한 개발을 추구하는 방법론
- 애자일 그 자체로는 방법론이라기 보단 철학에 가깝다.
- 애자일 정신을 기반으로 구체화된 실천기법들이 '애자일 방법론' 또는 '애자일 기법', '애자일 프로세스'라고 불린다.
- 절차와 도구보다 개인과 소통을 중요하게 생각한다.
- 문서화보다는 소프트웨어가 잘 실행되는데 가치를 둔다.
- 계획보다는 효과적인 변경 대응에 중점을 둔다.
- 고객과의 피드백을 중요하게 생각한다.
- 그래서 철저한 사전 계획과 포괄적인 문서화는 애자일의 특징이 아니라, 폭포수 모델 같은 계획 주도 방법론의 특징이다.
- 애자일 선언(2001)의 네 가치: 프로세스와 도구보다 개인과 상호작용, 포괄적인 문서보다 작동하는 소프트웨어, 계약 협상보다 고객과의 협력, 계획을 따르기보다 변화에 대응하기
- 요구사항이 자주 바뀌는 중소규모 프로젝트에 잘 맞는다. 요구사항의 변화가 적은 대규모 시스템은 계획과 문서를 앞세우는 폭포수 모델 같은 계획 주도 방법론이 맞는 경우이며, 애자일의 적용 대상으로 드는 것은 틀린 설명이다
- 대표 방법론: 익스트림 프로그래밍(XP), 스크럼, DSDM(동적 시스템 개발 방법론), 크리스탈, FDD, 린
계획 주도 개발의 품질 관리는 품질 계획·표준·절차를 문서로 정하고, ISO 9001 같은 표준 기반 체계를 따르며, 공식 인스펙션과 리뷰로 산출물을 확인한다. 애자일은 이런 문서 중심 절차 대신 팀의 품질 문화에 기댄다. 모든 팀원이 제품 품질에 책임을 느끼고 스스로 품질을 지키는 비공식적 방식이다. 서머빌은 애자일 품질 관리의 실천으로 다음을 든다.[1]
- 체크인 전에 점검한다 - 코드를 공용 저장소에 넣기 전에 동료에게 코드 리뷰를 받는다
- 빌드를 깨뜨리지 않는다 - 체크인한 코드가 전체 시스템의 빌드와 자동 테스트를 깨면 안 되며, 깨지면 바로 고친다
- 문제를 보면 고친다 - 다른 사람이 만든 코드에서 문제나 모호한 점을 발견하면 원래 개발자에게 돌려보내지 않고 직접 고친다
마지막 실천은 익스트림 프로그래밍의 공동 코드 소유(Collective Ownership)와 같은 생각이다. 누구든 어느 코드든 기능 추가, 버그 수정, 설계 개선, 리팩토링을 위해 고칠 수 있고, 모든 코드에 단위 테스트가 붙어 있어 변경이 기존 기능을 깨지 않는지 바로 확인한다.[2] 짝 프로그래밍은 공식 인스펙션 대신 코드를 쓰는 동안 계속 리뷰가 일어나게 하는 방법이다.
| 구분 | 계획 주도 품질 관리 | 애자일 품질 관리 |
|---|---|---|
| 근거 | 품질 계획서·표준·절차 문서 | 팀의 품질 문화와 실천 |
| 표준 | ISO 9001 등 외부 표준 준수를 중시 | 팀이 합의한 관례, 자동화된 테스트 |
| 검토 | 정기적인 공식 인스펙션·리뷰 | 짝 프로그래밍, 체크인 전 동료 리뷰 |
| 결함 수정 | 원작성자에게 돌려보내 고치게 함 | 발견한 사람이 직접 고침(공동 소유) |
| 종류 | 특징 | 비고 |
|---|---|---|
| XP |
|
최근 가장 주목 |
| SCRUM |
|
스프린트와 트래킹 중점 |
| DSDM |
|
주로 영국에서 사용 |
| FDD |
|
설계와 구축을 반복 |
| Crystal |
|
인적자원 중심 |
| ASD (Adaptive Software Development) |
|
짐 하이스미스, RAD 에서 발전 |
- ↑ Ian Sommerville, 『Software Engineering』 10th ed., Pearson, 2016, 24.4 Quality management and agile development, ISBN 978-0-13-394303-0.
- ↑ Don Wells, 「Collective Ownership」, ExtremeProgramming.org, http://www.extremeprogramming.org/rules/collective.html, 확인일: 2026-11-05.