애자일 소프트웨어 개발

애자일 소프트웨어 개발이란?

애자일 방법론은 소프트웨어 개발 방법에 있어서 아무런 계획이 없는 개발 방법과 계획이 지나치게 많은 개발 방법들 사이에서 타협점을 찾고자 하는 방법론입니다. 계획이 없는 방법론의 경우, 앞으로의 일을 예측하기 힘들고 효율적이지 못하다는 점에서 취약점을 가지고 있으며, 계획에 너무 의존하는 경우는 그 형식적인 절차를 따르는데 필요한 시간과 비용을 무시할 수 없으며, 전체적인 개발의 흐름 자체를 느리게 하는 단점을 가지고 있습니다.

그렇기 때문에 애자일 방법론에서 택한, 그리고 다른 고전적인 방법론, 예를 들면 폭포수 모델 또는 나선 모형과 구별되는 가장 큰 차이점은 less document-oriented, 즉 문서를 통한 개발 방법이 아니라, code-oriented, 실질적인 코딩을 통한 방법론이라는 점입니다. 그러므로 애자일 개발 방법론은 계획을 통해서 주도해 나갔던 과거의 방법론과는 다르게 앞을 예측하며 개발을 하지 않고, 일정한 주기를 가지고 끊임없이 프로토 타입을 만들어내며 그때 그때 필요한 요구를 더하고 수정하여 하나의 커다란 소프트웨어를 개발해 나가는 adaptive style이라고 할 수 있습니다.

애자일 개발 프로세스란 어느 특정 개발 방법론을 가리키는 말은 아니고 "애자일(Agile=기민한, 좋은것을 빠르고 낭비없게 만드는 것) 개발을 가능하게 해 주는 다양한 방법론 전체를 일컫는 말입니다. 예전에는 애자일 개발 프로세스는 "경량(Lightweight)" 프로세스로 불렸습니다. 익스트림 프로그래밍(XP:eXtreme Programming)이 애자일 개발 프로세스의 대표적인 방법이라 볼 수 있습니다.

폭포수 모델이란?

폭포수 모델(waterfall model)은 순차적인 소프트웨어 개발 프로세스(소프트웨어를 만들기 위한 프로세스)로, 개발의 흐름이 마치 폭포수처럼 지속적으로 아래로 향하는 것처럼 보이는 데서 이름이 붙여졌습니다. 이 폭포수 모델의 흐름은 소프트웨어 요구사항 분석 단계에서 시작하여, 소프트웨어 설계, 소프트웨어 구현, 소프트웨어 시험, 소프트웨어 통합 단계 등을 거쳐, 소프트웨어 유지보수 단계에까지 이릅니다.

한계점 

주로 실제 실행에 있어 불가능한 모델이라는 점이 그 주요 논지인데, 의미있는 규모의 프로젝트에서는 다음 단계에 대한 이해나 경험 없이, 각 단계를 완벽히 마무리한 후 다음 단계를 진행하는 것이 불가능하다는 것입니다. 예를 들어 고객들은 동작하는 프로토타입을 보지 않고는 정확히 자신들이 무엇을 원하는지를 요구사항으로 정하지 못할 수 있습니다. 또 고객들은 정해진 요구사항을 빈번하게 수정해달라고 요구하는 경우도 많으며, 그럴 경우 설계자나 구현자가 이를 통제할 수 있는 방법은 많지 않습니다. 만약 고객이 설계가 완료된 이후에 요구사항 변경을 요구했다면, 설계는 새로운 요구사항을 위해 변경되어야 하고 그때까지 투입된 많은 노력은 무위로 돌아가게 됩니다. 또한 설계자들은 설계 시에 향후 구현 작업의 난이도를 예측하기 어렵습니다. 즉, 구현 단계에 이르러서야 특정 부분의 설계를 구현하는 것이 불가능하거나 매우 어려움이 명백해지는 경우가 있을 수 있습니다. 그럴 경우, 기존 설계를 유지하여 어려운 구현을 진행하는 것보다 재설계를 택하는 것이 향후 발생할 수 있는 더 큰 문제 상황을 방지하는 데 나은 선택입니다.

기존 개발 프로세스와 차이점

전통적인 개발 프로세스들은 폭포수 모델과 계획 기반 개발을 따르는 반면, 애자일 개발 프로세스는 그에 반한다는 점에서 가장 큰 차이를 가집니다. 폭포수 모델과 계획 기반 개발 기법들은, 일련의 차례와 탄탄한 계획을 기반으로 하여 개발을 진행시킵니다. 이것은, 이해하기도 쉽고 사용하기도 쉬운 바람직한 기법이기도 하지만, 이로 인해서 많은 부작용이 생길 수 있습니다. 가장 큰 부작용이 발생할 때는, 계획대로 진행되지 않을 경우입니다. 이럴 경우에는 다음과 같은 부작용이 발생하게 됩니다.

• 납기일 전 철야
• 철야에도 불구하고 납기일 지연
• 지연에 따른 비난과 스트레스로 개발자 에너지 소진
• 결국 납품된 솔루션은 고객의 요구를 충족하지 못함

이런 부작용은 근본적인 개발 프로세스 접근법의 차이에서 나타납니다. 전통적인 개발 프로세스들은 공업에서 사용하는 정형적 프로세스 제어 모델을 따르고 있습니다. 정형적 프로세스 제어모델은, 동일한 입력에 대해서 동일한 결과가 기대 될 경우에 적합합니다. 하지만, 소프트웨어를 포함한 IT의 개발은 경험적 프로세스 제어 모델로 접근할 필요가 있습니다. 경험적 프로세스 제어 모델은 항상 불확실성을 수반하고 포용하고 있습니다. 애자일 개발 프로세스는 경험적 프로세스 제어모델로 개발을 관리합니다.

종류

애자일 개발 프로세스로 불리는 개발 방법론에는 다음과 같은 것들이 있습니다.

• 익스트림 프로그래밍(Extreme Programming, XP) - 애자일 개발 프로세스의 대표자로 애자일 개발 프로세스의 보급에 큰 역할을 함. 이 방법은 고객과 함께 2주 정도의 반복개발을 하고, 테스트우선 개발(TDD)을 특징으로 하는 명시적인 기술과 방법을 가지고 있음.

• 스크럼 - 30일마다 동작 가능한 제품을 제공하는 스프린트(Sprint)를 중심으로 하고 있음. 매일 정해진 시간에 정해진 장소에서 짧은시간의 개발을 하는 팀을 위한, 프로젝트 관리 중심의 방법론.

• 크리스털 패밀리 - 이 방식은 프로젝트의 규모와 영향의 크기에 따라서 여러종류의 방법론을 제공. 그중에서 가장 소규모 팀에 적용하는 크리스털 클리어는 익스트림 프로그래밍만큼 엄격하지도 않고 효율도 높지 않지만, 프로젝트에 적용하기 쉬운 방법론.

• Feature-Driven Development - feature마다 2주정도의 반복 개발을 실시. Peter Coad가 제창하는 방법론으로써, UML을 이용한 설계 기법과도 밀접한 관련을 가짐.

• Adaptive Software Development, ASD - 소프트웨어 개발을 혼란 자체로 규정하고, 혼란을 대전제로 그에 적응할 수 있는 소프트웨어 방법을 제시하기 위해 만들어진 방법론. 내용적으로는 다른 방법론들과 유사하지만, 합동 애플리케이션 개발(Joint Application Development, 사용자나 고객이 설계에 참가하는 개발 방법론)을 사용하고 있는 것이 조금 다름.

• 익스트림 모델링 - 익스트림 모델링은 UML을 이용한 모델링 중심 방법론. 다만, 여타 모델링 방법들과는 달리, 언제나 실행할 수 있고 검증할 수 있는 모델을 작성하는 공정을 반복해서, 최종적으로는 모델로부터 자동적으로 제품을 생성하게 함.

상기 소개된 애자일 개발 프로세스들은 각자 다른 특징과 적용 범위가 있으며, 서로 조합도 가능합니다. 애자일 개발 프로세스를 채용하고 있는 프로젝트에서는 특정 방법론만을 채택해서 매뉴얼대로 흉내만 내는 것이 아니라, 여러 방법 중에서 자신의 프로젝트에 맞는 부분을 취사 선택하여 조합하고, 또 독자적인 방법을 만들어 냄으로써 큰 효과를 올리고 있습니다. 이러한 애자일 개발 프로세스의 제창자들은 애자일 연합이라는 자유로운 조직을 만들고, 애자일 개발 프로세스의 보급에 힘쓰고 있습니다.

적용대상

애자일 개발 프로세스를 필요로 하는 조직은 크게 두 가지로 나뉩니다.

1. 하나는 목표 달성을 위한 프로세스를 가지지 않고, 임기응변적인 소프트웨어 개발로 인해 혼란에 빠져있는 조직. 이러한 프로젝트 팀에게 있어 애자일 개발 프로세스는, 개선을 위한 좋은 힌트가 될 것입니다. 애자일 개발 프로세스는 작고 쉽게 도입할 수 있으며, 그것에 들어가는 비용과 위험도 낮습니다.
2. 두 번째는 이미 전통적인 소프트웨어 프로세스를 도입하고 있지만, 제대로 동작하지 않는(또는 프로세스 실시를 위한 오버헤드가 너무 커서 오히려 업무에 부담을 주고 있는) 조직. 프로세스의 도입은 조직의 문화를 바꿉니다. 효과가 크면 클수록 조직문화에 대한 영향은 커지고, 도가 지나치게 되면 고유의 문화를 파괴해 버리기도 합니다. 그러나 조직에 있어서 애자일 개발 프로세스는 좋은 결과를 가져다 줄 것입니다. 또한 CMMI나 SPICE등의 인증을 얻으려고 하는 조직에서는 그들의 요구를 충족시킬 아이디어를 제공해 줄 수 있을 것입니다.