[ISSUE] 소프트웨어 개발 방법론 / 애자일(Agile) 방법론

1. 소프트웨어 개발 방법론이란?

소프트웨어 개발 방법론이란, 소프트웨어를 개발하는데 있어 필요한 프로그래밍 개발 과정들을 정리하고 표준화하여 프로그래머들이 프로그래밍 개발과정에서 각 개인이 개발과정에서 일관성을 유지하여 프로젝트의 분야별 프로그래머들간의 효과적인 협업이 이루어 질 수 있도록 돕는 방법론을 말한다.

소프트웨어 개발 방법론에서 가장 중요한 내용은 프로그래머들간의 효과적인 협업이라고 볼 수 있으며 WaterFall 방법론, Agile 방법론, Scrum 방법론, DevOps 방법론 등이 있다.

이 포스팅은 현재 많은 관심을 받고 급부상중인 사용되는 Agile 방법론을 말할 예정이다.

2. 애자일(Agile) 방법론이란?

소프트웨어는 유동적이고 개방적인 특징을 가지고 있다. 또한 사용자의 요구사항의 변경에 따라 작업량을 예측하기 힘들다. 그렇기 때문에 전통적인 방법론들을 통하여 소프트웨어 개발에서의 문제들을 즉각적으로 대처하는게 어려웠다.

이런 문제를 대처하기위해서 [C++ Basic]에서 언급했었던 OPP(객체지향 프로그래밍)이 등장하게 되었고 이러한 객체지향 기술은 소프트웨어 개발에서 발생한 문제들을 적절하게 대처해 주기도 했다. 하지만 이러한 객체지향 개발을 위해서는 그에 적합한 소프트웨어를 필요했고 이때 지금 소개할 애자일(Agile) 개발 방법론 등이 등장하게 되었다.(그러므로 애자일 개발 프로세스들은 과반수 이상이 객체지향 기술을 기반으로 한다.)

애자일 방법론은 제한된 시간과 비용 안에서 정보는 불완전하고 예측은 불가능하다는 전제를 가지고 있다. 그리고 이러한 전제안에서 적절한 결과를 내기위하여 사용하는 것이 애자일 방법론이다.

<애자일 선언문[출처 : https://agilemanifesto.org/iso/ko/manifesto.html]>

위에 보이는 애자일 선언문은 2001년 17인의 쟁쟁한 소프트웨어 개발자들이 모여서 리조트에 모여 소프트웨어에 대한 방법론에 대해 토론하게 되었고 그 결과로 애자일 선언문이 탄생하게 되었고 이것은 우리들에게 애자일 방법론으로 정착하게 되었다. 

위의 내용에서 강조되어지는 8가지는 소프트웨어 개발자라면 모두 이해할만한 이야기들이고 또한 앞에서 이야기한 [WaterFall 방법론]과는 정반대인 점이 존재한다.

---

첫번째, 공정과 도구보다 개인과 상호작용 

공정과 도구 < 개인과 상호작용에서 다들 공감할 이야기지만 어디에서나 제일 중요하고 기본이 되는 내용이 제일 앞줄에 오는 것은 다들 아실 것이다. 애자일 선언문에서도 가장 중요한 내용이자 애자일이면 이게 제일 중요하다. 라고 할 이야기이다. 여기서 공정과 도구는 '어떤 도구(Tool)을 사용해서 어떠한 설계(Design)과정을 거쳐 어떠한 결과를 낼 것인가?'라는 말이다. 또한 개인과 상호작용은 팀원들과의 상호작용(Interation)을 중요시하라는 말로 해석할 수 있다. 

---

두번째, 포괄적인 문서보다 작동하는 소프트웨어

포괄적인 문서 < 작동하는 소프트웨어는 당연히 이야기이지 않을까 생각하겠지만 앞에서 말한 [WaterFall 방법론]과 같이 체계적인 기획(문서)을 세우고 그 계획을 하나씩 없애가며 문제가 발생하면 기존 전 단계로 돌아가 작업을 하는 것이 아닌 즉각적인 대처를 할 수 있는 프로토 타입을 계속 찍어낸다. WaterFall과 애자일의 가장 큰 차이점인 문서화에서 애자일은 잘 작동하는 소프트웨어가 더 중요하다는 말이다.

---

세번째, 계약협상보다 고객과의 협력

계약협상 < 고객과의 협력은 소프트웨어의 특징을 가장 잘 보여주는 관계이다. 일단 위의 말에 관련있는 소프트웨어의 특징은 소프트웨어는 매우 유동적이다. 쉽게 말해서 어떠한 요청에 의해서 빠른 변경이 가능하다는 점, 우리가 매일 손에 쥐고 다니는 스마트폰일 경우 버젼의 변경이 기본 1년이상이다. 또한 고객의 요청에 의해서 '스마트폰 이부분이 안 좋으니 변경되었으면 좋겠다'라고 하면 이러한 부분이 즉각적인 변경이 불가능하다. 하지만 소프트웨어라면 고객의 요청에 의해서 빠른 시일내에 수정과 변경이 가능하다. 그러므로 계약협상보다 고객과의 협력이 더 가치있다는 말이다. 그렇기 때문에 계약협상을 따내서 실적을 높이고 수익을 창출하는 것도 물론 중요하지만 기존의 만들어진 소프트웨어를 고객과의 의사소통을 통하여 최적화시키는게 더 가치있게 되는 것이다.

---

네번째, 계획을 따르기보다 변화에 대응하기

계획을 따르기 < 변화에 대응하기는 계획 수립이 중요하지 않다는 말이 아니라 계획을 세우는 것도 중요하지만 사용자(고객)의 요청사항에 대한 대응이나 기술의 발전으로 인한 코드의 대체 등과 같이 변화가 필요할 때 즉각적을 소프트웨어를 대체하여 변화에 대응하는 것이 더 중요하다는 이야기이다. 앞에서 언급한 것과 같이 소프트웨어의 특징인 유동성 등과 큰 관계가 있다고 볼 수 있다.

사실 위와같은 애자일 선언문을 통해 살펴보건데 방법론이라기보단 무슨 철학과 같이 보인다. 이를 좀 더 뒷받침하기 위해서 <애자일 12계명>, <애자일 12가지 원칙>, <애자일 선언 이면의 원칙> 으로 불리는 12가지의 문구가 있다.

1. 우리의 최우선 순위는 가치있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.

2. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.

3. 작동하는 소프트웨어를 자주 전달하라. 2주 ~ 2개월 정도의 간격으로 하되 더 짧은 기간을 선호하라.

4. 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야한다.

5. 동기가 부여된 사람들을 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.

6. 개발팀으로 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.

7. 작동하는 소프트웨어가 진척의 주된 척도이다.

8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.

9. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.

10. 단순성이 (안하는 일의 양을 최대화하는 기술이) 필수적이다.

11. 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.

12. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.

3. 애자일(Agile) 방법론의 실천

사실 위와같이 애자일과 같은 방법론들은 알아두면 좋은 TIP과 같은게 아니라 매번 실천을 할려고 노력해 나가야하는 것들이다. 만약 자신을 포함한 프로젝트 팀이 존재한다면 위의 12원칙을 하나하나씩 대입해보고 자신의 팀에 부족한 내용을 변경하여 애자일 방법론에 적응해 나가는 것이 중요하다.

또한 방법론이란 어떤 방법이 제일 좋다. 라고 단정 지을 수는 없다. 개발할때의 환경, 프로젝트의 크기, 프로젝트 팀의 인원 수 등을 고려하여 적절한 방법론을 선택하여야 한다.