애자일(Agile)이란? 철학과 원칙

애자일(Agile)이란?

우리가 익숙한 소프트웨어 개발 기법에는 폭포수 개발 방식(Waterfall model)이 있습니다.

폭포수 모델
Waterfall Model

소프트웨어 개발 생명주기(SDLC; Software Develoment Life Cycle)에 기반하고 있는 소프트웨어 개발 기법으로, 워터폴 모델, 폭포수 모형, 선형 순차 모형, 단계적 생명주기라고도 한다. 한 번 떨어지면 거슬러 올라갈 수 없는 폭포수와 같이 소프트웨어 개발도 각 단계를 확실히 매듭짓고 다음 단계로 넘어간다는 의미에서 붙여진 명칭이다. 전통적인 시스템 생명주기 모델로 소프트웨어를 개발할 때 가장 널리 사용된다.

폭포수 모델로 프로젝트를 진행하면 보통 요구 사항 분석, 설계, 개발, 테스트, 배포 순서의 프로세스를 따르게 됩니다.

고객의 요구 사항이 명확하고 그에 따른 솔루션 역시 구체적이라면 이 방식이 적합할 수 있습니다.

하지만 만약 고객의 요구 사항이 마지막 배포 단계에서 변경되었다면 어떻게 될까요?

다시 처음으로 돌아가 요구 사항을 분석하고, 그에 따른 사이드 이펙트(Side effect)들 때문에 설계 및 개발 내용 모두 변경해야 하는 돌이킬 수 없는 상황이 발생할 수 있습니다.

그 프로젝트는 결국 검수 일정을 지키지 못하게 되겠죠.

 

폭포수 모델은 개발 과정이 명확하게 단계화되어 있는 만큼 관리가 쉬우나 요구 사항 분석에 상당한 시간이 소요되며, 일단 분석이 끝나면 수정이 어렵다는 단점을 가지고 있습니다.

또 개발 단계마다 피드백이 발생하므로 순차적인 흐름을 따라가기 어려울 수 있기 때문에 규모가 크고 복잡한 시스템에는 적합하지 않습니다.

 

이러한 단점을 보완할 수 있는 것이 애자일 방법론입니다.

물론 애자일 방법론이 완벽한 것은 아니지만요.

애자일 개발방법론
Agile Software Development

신속하고 유연하며 적응적인(Adaptive) 소프트웨어 개발을 목표로 하는 다양한 경량 개발 방법론 전체를 일컫는 총칭으로, 반복(Interation)이라 불리는 단기 단위를 채용함으로 위험을 최소화하는 개발 방법이다.

애자일(Agile)의 사전적 의미는 '날렵한', '민첩한'을 뜻합니다.

 

애자일 방법론을 사용하는 프로젝트는 짧은 주기로 설계, 개발, 테스트, 배포 과정을 반복하게 된다고 생각하면 됩니다.

요구 사항(해결할 문제)을 작은 단위로 쪼개서 그에 대한 솔루션을 만들고, 빠르게 보여줌으로써 요구 사항에 대한 검증을 해 나가는 것이죠.

개발된 제품 및 서비스를 사용자 또는 이해관계자들의 목표와 일치시키는 비즈니스 접근 방식이라고도 볼 수 있습니다.

애자일 선언문

애자일 방법론은 2001년 애자일 연합에서 발표한 선언문을 시작으로 본격화되기 시작했습니다.

 

"우리는 소프트웨어를 개발하고, 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다."

• 공정과 도구보다 개인과 상호작용
• 포괄적인 문서보다 작동하는 소프트웨어
• 계약 협상보다 고객과의 협력
• 계획을 따르기보다 변화에 대응하기

애자일의 원칙

애자일 연합은 선언문과 함께 애자일 소프트웨어의 개발 원칙도 공개하였습니다.

1. 우리의 최우선 순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
2. 비록 개발의 후반부일지라도 요구 사항 변경을 환영하라. 변화를 활용해 고객의 경쟁력에 도움이 되게 하라.
3. 작동하는 소프트웨어를 자주 전달하라. 두어 주 간격으로 하되 더 짧은 시간을 선호하라.
4. 비즈니스에 관련된 사람들과 개발자들은 프로젝트 전체에 걸쳐 매일 함께 일해야 한다.
5. 동기가 부여된 개인들을 중심으로 프로젝트 팀을 구성하라. 그들이 필요로 하는 환경을 지원해 주고 그들이 일을 끝낼 수 있다고 확신하라.
6. 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대 면 대화다.
7. 작동하는 소프트웨어가 진척의 주된 척도다.
8. 고객, 개발자, 사용자는 일정한 속도를 계속 유지하며 지속 가능한 개발을 장려해야 한다.
9. 기술적 탁월성과 좋은 설계에 대한 지속적인 관심이 기민함을 높인다.
10. 단순성이 필수적이다.
11. 최고의 아키텍처, 요구 사항, 설계는 자기 조직적인 팀에서 나온다.
12. 팀은 정기적으로 어떻게 더 효과적이 될 수 있을지 숙고하고 행동을 조율한다.