애자일(Agile)은 소프트웨어 개발 방식을 설명하는 용어로, 마지막 단계에서 모든 것을 한꺼번에 납품하는 대신 점진적 납품, 팀 협업, 지속적 계획, 지속적 학습을 강조하는 접근법입니다.
애자일은 프로세스를 간결하게 유지하고 최소 기능 제품(MVP)을 만들어 최종 완성 전까지 여러 차례 반복하는 것에 초점을 맞춥니다. 피드백은 지속적으로 수집되고 반영되며, 전체적으로 모든 구성원이 하나의 목표를 향해 함께 나아가는 훨씬 더 역동적인 프로세스입니다.
애자일 소프트웨어 개발이란?
스크럼 및 주요 애자일 방법론
애자일은 하나의 사고방식이자 가치와 원칙의 집합입니다. 애자일은 생각하고 행동하는 방식입니다. 애자일은 짧은 주기, 반복적·점진적 납품, 빠른 실패, 피드백 수집, 고객에 대한 조기 비즈니스 가치 전달, 그리고 사람·협업·소통을 중시합니다. 애자일은 투명성, 검토, 적응을 근본으로 하는 사고방식입니다. 다만 애자일 자체에는 특정 역할, 이벤트, 산출물이 포함되지 않습니다. 애자일은 사고방식 그 자체입니다. 예를 들어 Scrum은 애자일이라는 큰 틀 안에서 널리 활용되는 프레임워크 중 하나로, 더 애자일해지는 데 도움을 줄 수 있습니다. 그러나 아래 그림에서 볼 수 있듯이 Kanban, XP, Crystal 등 애자일 운동 내에는 훨씬 더 많은 프레임워크가 존재합니다.
애자일 방법론
Scrum:
Scrum은 사람들이 복잡한 적응 문제를 해결하면서 최고의 가치를 지닌 제품을 생산적이고 창의적으로 납품할 수 있는 프레임워크입니다. 소프트웨어 프로젝트 및 제품·애플리케이션 개발 관리에 활용됩니다. 크로스펑셔널 팀이 하나의 단위로 협력하여 2~4주(Sprint) 내에 공동 목표를 달성하는 적응형 제품 개발 전략에 초점을 맞춥니다. 가치, 산출물, 역할, 의식, 규칙, 모범 사례의 집합으로 구성됩니다.
Lean:
Lean은 1950~60년대 이후 물리적 제품 제조에 혁명을 일으킨 도요타 생산 방식(TPS)에서 출발했습니다. Lean은 제조업에서의 입지를 유지하면서도 지식 노동 분야에서도 새로운 적용 사례를 발굴하여, 모든 산업의 기업이 낭비를 제거하고 프로세스를 개선하며 혁신을 촉진하는 데 기여하고 있습니다. 소프트웨어 개발은 제조업처럼 정해진 프로세스를 따르고, 일정한 수용 조건이 있으며, 유형의 가치를 납품한다는 점에서 Lean 방법론의 자연스러운 적용 분야입니다. Lean 방법론의 모든 실천을 이끄는 핵심 개념인 ‘Lean의 기둥’은 다음과 같습니다.
- 지속적 개선
- 사람에 대한 존중
- 경량 리더십
Kanban:
Kanban은 Lean 팀에서 널리 사용되는 시각적 워크플로우 관리 방법론입니다. 실제로 Lean을 실천하는 팀의 83%가 Kanban을 활용하여 제품 생성 과정을 시각화하고 능동적으로 관리하며, 개발 팀에 과부하를 주지 않으면서 지속적 납품을 강조합니다. Scrum과 마찬가지로 Kanban은 팀이 더 효과적으로 협력하도록 설계된 프로세스입니다.
Kanban은 3가지 기본 원칙에 기반합니다.
- 오늘 할 일(워크플로우)을 시각화하기: 모든 항목을 서로의 맥락 안에서 파악하면 유용한 정보를 얻을 수 있습니다
- 진행 중인 작업(WIP) 양을 제한하기: 흐름 기반 접근 방식의 균형을 유지하여 팀이 한꺼번에 너무 많은 작업을 시작하지 않도록 합니다
- 흐름을 향상시키기: 작업이 완료되면 백로그에서 다음 우선순위 항목을 가져와 진행합니다
Kanban은 최적의 팀 워크플로우를 정의함으로써 지속적인 협업을 촉진하고 능동적·지속적인 학습과 개선을 장려합니다.
동적 시스템 개발 방법(DSDM):
DSDM은 8가지 원칙, 라이프사이클과 산출물, 역할과 책임, 여러 모범 사례 기법으로 구성된 프레임워크입니다. 이는 가능한 한 빠르게 전략적으로 연계된 비즈니스 가치를 납품하여 조직이 최상의 투자 수익률(ROI)을 달성하도록 지원하는 철학을 뒷받침합니다.
DSDM은 기능보다 일정과 품질을 우선시하는 방법론으로, 비용·품질·기간을 초기에 고정하고 프로젝트 요구사항을 네 가지 유형으로 분류하는 MoSCoW 우선순위 기법을 활용합니다.
- 반드시 필요(M)
- 필요함(S)
- 있으면 좋음(C)
- 이번엔 제외(W)
DSDM Atern[13]의 기반이 되는 8가지 원칙이 있습니다. 이 원칙들은 팀이 일관성 있게 납품하기 위해 취해야 할 태도와 사고방식을 안내합니다.
- 비즈니스 필요에 집중
- 제때 납품
- 협업
- 품질에 타협하지 않기
- 확고한 기반 위에서 점진적으로 구축
- 반복적으로 개발
- 지속적이고 명확하게 소통
- 통제력 입증
익스트림 프로그래밍(XP):
익스트림 프로그래밍(XP)은 Kent Beck이 처음 기술하였으며, 가장 인기 있으면서도 논쟁의 여지가 있는 애자일 방법론 중 하나로 자리잡았습니다. XP는 고품질 소프트웨어를 신속하고 지속적으로 납품하기 위한 체계적인 접근법입니다. 변화하는 고객 요구사항에 유연하게 대응하며 소프트웨어 품질과 반응성을 높이는 것을 목표로 합니다. 높은 수준의 고객 참여, 빠른 피드백 루프, 지속적 테스트, 지속적 계획, 긴밀한 팀워크를 통해 통상 1~3주 간격으로 작동하는 소프트웨어를 납품합니다.
이 방법론의 명칭은 전통적인 소프트웨어 엔지니어링 관행의 유익한 요소들을 ‘극한(extreme)’ 수준으로 끌어올린다는 아이디어에서 비롯되었습니다. 예를 들어 코드 리뷰는 유익한 관행으로 여겨집니다. 이를 극한까지 적용하면, 페어 프로그래밍을 통해 코드를 지속적으로 리뷰할 수 있습니다.
원래의 XP 방법은 단순성, 소통, 피드백, 용기라는 네 가지 핵심 가치를 기반으로 합니다.
또한 12가지 보조 실천 방법이 있습니다.
- 플래닝 게임
- 소규모 릴리스
- 고객 인수 테스트
- 단순한 설계
- 페어 프로그래밍
- 테스트 주도 개발
- 리팩토링
- 지속적 통합
- 공동 코드 소유권
- 코딩 표준
- 메타포
- 지속 가능한 속도
익스트림 프로그래밍
기능 주도 개발(FDD):
기능 주도 개발(FDD)은 1997년 Jeff De Luca가 싱가포르 대형 은행의 소프트웨어 개발 프로젝트에 참여하면서 도입한 방법론입니다. 반복적·점진적 소프트웨어 개발 프로세스로, 소프트웨어 개발을 위한 애자일 방법론입니다. FDD는 업계에서 인정받은 다양한 모범 사례를 하나의 일관된 체계로 통합합니다. 이 실천 방법들은 고객이 가치를 두는 기능(feature) 관점에서 도출됩니다. 주요 목적은 적시에 반복적으로 실질적이고 작동하는 소프트웨어를 납품하는 것입니다. FDD의 장점은 ‘초기 적정 설계(JEDI)’ 개념 덕분에 대규모 팀에서도 확장 가능하다는 점입니다. 기능 중심 프로세스로 애자일하고 점진적이며 본질적으로 복잡한 프로젝트를 효과적으로 관리할 수 있습니다. 다섯 가지 기본 활동으로 구성됩니다.
- 전체 모델 개발
- 기능 목록 작성
- 기능별 계획
- 기능별 설계
- 기능별 구축
기능 주도 개발(FDD)
모든 프로젝트는 고유한 모델을 갖게 되며, 이를 통해 기능 목록이 도출됩니다. 마지막 세 가지 활동은 짧은 반복 프로세스로, 하나의 기능을 구축하는 데 2주를 초과하지 않습니다. 2주 이상 걸릴 경우 더 작은 기능으로 분리해야 합니다.
Crystal:
Crystal 방법론은 1990년대 중반 Alistair Cockburn이 개발한 방법론 계열(Crystal 패밀리)입니다. 이 방법들은 Cockburn이 수년간 팀을 연구하고 인터뷰한 결과물입니다. 연구에 따르면, 인터뷰한 팀들은 공식적인 방법론을 따르지 않았음에도 불구하고 성공적인 프로젝트를 납품했습니다. Crystal 패밀리는 그 팀들이 프로젝트를 성공으로 이끈 요인들을 정리한 Cockburn의 방식입니다. Crystal 방법론은 다음에 초점을 맞춥니다.
- 사람
- 상호작용
- 커뮤니티
- 기술
- 재능
- 소통
애자일 선언문
“애자일”이라는 용어는 2001년 애자일 선언문(Agile Manifesto)에서 처음 만들어졌습니다. 이 선언문은 더 나은 소프트웨어 개발 방식을 안내하는 원칙을 확립하기 위해 작성되었습니다. 애자일 선언문은 4가지 중요한 가치로 구성됩니다. 애자일 선언문을 읽는 방법은, 오른쪽 항목들이 더 이상 가치 없다는 뜻이 아니라 애자일 운동이 왼쪽 항목들을 더 중시한다는 것입니다.
애자일 선언문
애자일 선언문의 첫 번째 항목을 살펴보겠습니다. 이 항목은 광범위한 프로세스와 도구보다 사람, 그들의 상호작용, 소통, 협업을 더 중시한다고 말합니다. 물론 프로세스와 도구도 가치 있지만, 사람들이 함께 일하며 훌륭한 제품을 납품하는 것을 실질적으로 지원할 때 훨씬 더 가치 있습니다. 오늘날 많은 조직에서 프로세스와 도구 자체가 목표가 되는 경우를 볼 수 있습니다. 애자일 관점에서는 이를 다르게 바라봅니다. 프로세스와 도구는 사람들이 함께 일하고 고객에게 가치를 납품하는 것을 지원해야 합니다.
애자일 선언문 원칙
애자일 선언문을 보완하여, 애자일 연합(Agile Alliance)은 선언문에 대한 지침과 상세 설명을 제공하는 12가지 기반 원칙도 정의했습니다.
애자일 선언문 원칙
애자일 선언문 원칙:
- 고객 만족을 위해 가치 있는 소프트웨어를 조기에 지속적으로 납품하는 것이 최우선 과제입니다.
- 개발 후반부에서도 요구사항 변경을 환영합니다. 애자일 프로세스는 고객의 경쟁 우위를 위해 변화를 활용합니다.
- 작동하는 소프트웨어를 몇 주에서 몇 달의 주기로 자주 납품하되, 짧은 주기를 선호합니다.
- 비즈니스 담당자와 개발자는 프로젝트 전반에 걸쳐 매일 함께 일해야 합니다.
- 동기부여된 개인들을 중심으로 프로젝트를 구성하십시오. 그들에게 필요한 환경과 지원을 제공하고, 업무 완수를 신뢰하십시오.
- 개발 팀 내외에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 대면 대화입니다.
- 작동하는 소프트웨어가 진척도의 핵심 척도입니다.
- 애자일 프로세스는 지속 가능한 개발을 촉진합니다.
- 스폰서, 개발자, 사용자는 일정한 속도를 무기한 유지할 수 있어야 합니다.
- 기술적 우수성과 좋은 설계에 대한 지속적인 관심이 민첩성을 높입니다.
- 단순성, 즉 하지 않아도 될 일의 양을 최대화하는 기술이 필수적입니다.
- 최고의 아키텍처, 요구사항, 설계는 자기조직화된 팀에서 나옵니다. 팀은 정기적으로 더 효과적인 방법을 성찰하고, 그에 맞게 행동을 조율하고 조정합니다.
요약
애자일 개발은 소프트웨어 개발 업계의 주요 화두 중 하나로, 소프트웨어 개발 프로젝트를 관리하는 새로운 방식입니다. 특정 소프트웨어 개발 방법론이 아니라, 애자일 선언문에 명시된 가치와 원칙을 기반으로 한 방법론과 실천 방법의 총칭입니다. 솔루션은 상황에 맞는 실천 방법을 활용하는 자기조직화된 크로스펑셔널 팀 간의 협업을 통해 발전합니다.
출처: https://www.visual-paradigm.com/scrum/what-is-agile-software-development/
