개발 방법론 - 애자일

IT 개발 프로젝트의 관리 방법론은 여러 가지가 있다.

그 중 오늘은 애자일 방법론을 생각해 보기로한다.

 

 

애자일 방법론은 흔히 폭포수 방법론에 대비되어 거론된다.

 

---

애자일 선언문

 

2001년 1월, “애자일 연합(Agile Alliance)”이라는 그룹에서 ‘애자일 선언문’이라는 공동의 선언서를 작성했다.

이 문서는 지금까지도 애자일 소프트웨어 개발의 기초 원칙 과 정신으로 이야기 되고 있는 중요한 선언서이다.

 

그 서문을 살펴보면 다음과 같다.

 

우리는, 소프트웨어를 개발하면서, 그리고 또한 다른 사람의 개발을 도와주면서 소프트웨 어를 개발하는 더 나은 방법들을 찾아나가고 있다. 이 작업을 통해 다음과 같은 가치를 추 구하게 되었다. 프로세스나 도구 보다는 개인과 상호 작용을, 포괄적인 문서보다는 작동하는 소프트웨어를, 계약에 대한 협상보다는 고객과의 협력을, 계획을 고수하기 보다는 변화에 대응을 더욱 가치 있게 여긴다. 이 말은, 전자도 가치가 있긴 하지만, 우리는 후자 쪽에 더 많은 가 치를 둔다는 것이다.
...

 

원문 애자일 선언문은 첫 페이지에서 위와 같은 내용을 전면에 내세우고 있지만, 한편으로는 ‘애자일 소프트웨어의 12가지 원칙’이라는 이름으로 좀 더 구체적인 실천원칙에 대해 이야기를 하고 있다.

그 내용은 다음과 같다.

애자일 선언문의 바탕에 깔려있는 원칙들 우리는 다음과 같은 원칙들을 따른다.

• 우리의 최고 우선 순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달함으로써 고객을 만족시키는 것이다.
• 비록 개발 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
• 작동하는 소프트웨어를 자주 전달하라. 약 2주에서 2개월의 정도의 간격으로 전달하되, 간격이 짧을수록 좋다. • 비즈니스 영역 사람들과 개발자들은 프로젝트 전체에 걸쳐 매일 함께 일해야 한다.
• 동기가 갖추어져 있는 개인들로 프로젝트를 구성하라. 그들에게 그들이 필요로 하는 환경과 지원을 제공하라. 그리고 그들이 일을 끝낼 수 있도록 신뢰하라.
• 어떤 다른 개발팀을 상대로, 혹은 개발팀 내에서, (서로 간의) 정보를 전달하는 가장 효율적이고 효과적인 방법은 얼굴을 보고 하는 대화이다.
• 작동하는 소프트웨어가 진척 측정의 주된 척도이다.
• 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 그리고 사용자들은 일정한 속도를 계속 유지할 수 있어야 한다.
• 기술적 탁월함과 좋은 설계에 대한 지속적 관심이 기민함을 향상시킨다.
• 간결함-하지 않아도 되는 일의 양을 최대화하는 기술-은 필수적이다.
• 최상의 아키텍처, 요구사항, 그리고 설계는 자기조직화(self-organizing)되어 있는 팀에서 나온다.
• 정기적으로, 팀 차원에서 어떻게 하면 더 효과적일 수 있을지에 대해 되돌아보며 자신들의 행동을 이에 따르도록 조율하고 조정한다.

 

‘애자일 선언문’은 특정한 문제 상황을 가정하고 있지는 않지만, 본문에도 나와있듯이 ‘산출물’과 ‘문서’ 위주의 개발 방식으로 개발이 진행되면서도 효율적으로 진행되고 있지 못하는 수 많은 프로젝트들에 대해 새로운 접근을 제안하고 있다.

 

우리가 흔히 클라이언트, 혹은 고객이라 부르는 이들은 시작부터 끝까지 끊임없이 요구사항을 내놓는다.

언제까지고 그들의 요구를 받아들일 수 없으므로 사실 폭포수이론이 아니면 프로젝트에서 개발자들이 살아남기 어려운것도 사실이다.

 

하지만, 애자일은 단순히 고객과 개발자간의 관계만을 얘기한 것이 아니라, 사용자와 개발자 혹은 기획자가 프로젝트를 처음부터 끝까지 함께 호흡하고 운전 가능한 상태에서 개선점을 논의할 것을 제안하는 것이다.

프로젝트의 시작과 끝이라는 것이 사실 어찌보면 무의미할 수도 있는것이, 프로세스나 프로그램을 일단 모두의 만족 하에 개발이 완료되었다고 해도 막상 서비스에 나서보면 생각하지 못한 변수가 넘쳐나고 곧바로 개선점이 도출되고 말기 때문이다. 

따라서 요구상명세서 - 설계서 - 테스트시나리오 & 결과서 등의 문서는 결과적으로 별 가치가 없는 것이고, 팀 내에서 도출된 아이디어로 빨리 개발해서 런칭하고 나타나는 문제를 시정하고 새로운 아이디어를 반영하면서 살아 숨쉬는 프로그램, 프로세스를 운영하는 것이 이상적이라 할 것이다.

 

애자일 이론의 명성(?)에 비해 실제로 현장에서 프로젝트 개발론으로 채용되는 경우는 많지 않다.

(사내 프로젝트는 조금 다른 얘기지만...)

가장 큰 이유는 예산의 편성과 공과의 평가 때문이다. 지속적으로 개선해야 하는 프로그램을 어떻게 예산을 편성받아 진행할 수 있겠는가. 결국 일단 1차로 여기까지 완성하고 2차, 3차에 고도화를 생각하는 것인데, 이렇게 완료된 1차 프로젝트는 이후 어떻게 개선이 되든간에 프로젝트로서 완성된 모습을 보여야 사후 감사 등에서 지적받지 않을 수 있다.

감리도 마찬가지고...

 

애자일 소프트웨어 개발에 대한 다양한 방법론들이 처음 등장하기 시작한 것은 1990년대 중반이다.

기존의 무겁고 규범적인 방법론에서 탈피하여 가벼운 방법론을 지향하며 등장했다.

물론, 처음부터 이런 방법론들을 애자일(Agile)이라고 불렀던 것은 아니다. 초기에는 단순히 경량방법론(Lightweight methods)으로 통칭되었지만, 애자일 선언문 (Agile Manifesto) 발표 이후부터 ‘애자일’이라고 불리게 되었다.

 

폭포수 이론과 애자일 이론의 비교

 

• 계획 중심 vs 고객 중심
  폭포수 방법론은 프로젝트를 시작하기 전에 프로젝트 기간 전체에 대한 일정 계획을 수립하며, 이 계획에 따라 프로젝트를 진행한다.
  반면, 애자일 방법론은 계획을 수립하되 불확실한 프로젝트 기간 전체를 감안하여 무리하거나 현실성 없는 계획을 수립하는 것이 아니라 현재 시점에 고객에게 중요하거나 확정된 내용을 중심적으로 수립한다. 프로젝트 상황에 따라 프로젝트 계획은 변경될 수 있다는 사실을 인정하고 진행합니다. 그래서 계획보다는 고객이 중요하게 생각하는 기능을 먼저 개발하는 것을 원칙으로 한다.
• 빅뱅 릴리즈 vs 작은 릴리즈
  형태적으로 보았을 때,
  폭포수 방법론이 프로젝트가 종료되는 시점에 한꺼번에 모든 기능을 릴리즈 한다고 한다면 애자일 방법론은 이터레이션이라는 일정 기간 단위로 작은 규모 크기의 릴리즈를 반복한다.
  이렇게 하면 고객은 요구사항이 제대로 반영되고 있는지 조기에 확인할 수 있어서 개발이 모두 끝난 다음에야 비로소 요구사항에 맞지 않다고 이야기 하고, 결국 재개발하게 되는 경우를 방지할 수 있다.
• 산출물 중심 vs 동작하는 SW 중심
  폭포수 방법론에서는 계획된 단계별로 지정된 산출물이 작성되었는지 여부를 확인함으로써 프로젝트가 제대로 진행되고 있는지 확인한다.
  애자일 방법론에서는 소프트웨어가 제대로 동작하는지, 얼마나 요구사항에 맞게 개발되었는지가 중요합니다. 이러한 특징으로 인해 ‘애자일을 적용해서 개발을 진행하면 문서를 만들지 않아도 된다’는 오해를 받기도 하지만, 사실 문서를 만들지 않는것이 아니라 상황에 맞는 다양한 형태로 산출물을 만들 수 있다는 좀더 유연한 의미로 받아들일 필요가 있다.
• 왜 애자일 방법론을 도입하려 하는가
  많은 기업에서 애자일 방법론을 도입하려 하고 있고, 현재 하고 있지만, 사실 그 이유나 목적은 다양하다. VersionOne이라는 애자일 개발 전문 컨설팅 회사에서 분기별로 진행하는 설문조사 자료 를 기준으로 기업들의 애자일 도입 이유를 정리해보면 다음과 같다.
    • 팀의 생산성을 높이고 제품을 적기에 출시하기 위해
    • 개발에 들어가는 비용을 줄이기 위해
    • 소프트웨어 품질을 향상시키기 위해
    • 팀의 사기와 업무 만족도 향상을 위해

 

사실, 애자일 방법론을 도입한다고 해서 지금까지 언급된 사안을 모두 달성한다는 보장이 있는 것은 아니지만, 적어도 기존 방법론에서 해결하지 못한 부분 중 많은 부분을 애자일을 통해 해결한 사례가 많다.

 

앞으로 애자일에서 파생된 많은 방법론을 살펴보고 그 예시도 찾아보려고 한다.

 

오늘은 여기까지...