Agile 애자일 방법론의 몰락 그 이유는?!

◎ Agile 애자일 방법론의 몰락 그 원인은 무엇일까 ◎

Agile 애자일 방법론에 대해서 IT 업계에 계신 분이라면 사실 누구나 한번정도는 들어보셨을 겁니다. 설사 그 이론이 어느 것인지 상세히 알지는 못한다 할지라도 말입니다. 하지만 사실 Agile 애자일 방법론에 대해서 모르더라도 이것 한가지는 잘 알고 계실 겁니다.(개발자 입장에서입니다) 그것은 바로 끊임없이 바뀌는 고객의 요구사항과 고객 본인 자체도 무엇을 원하는지 모르는 채 막연히 전산으로 가능했으면 좋겠다는 요구사항을 내미는 순간 느끼는 짜증스런 감정과 막막함말입니다. 

이럴 경우 요구사항이 가능한 것인지 그것이 진짜 필요한 것인지 기술적으로 가능한지에 대한 검토와 검증을 해야하는 것은 대부분 개발자입니다. 하지만 이렇게 검토하고 검증 한 뒤 그것이 가능할 경우에야 다행이지만 불가능할 경우 고객을 설득하고 대체할 기능을 찾아야 하는 것 또한 대부분 개발자의 몫이기에 그 난관은 이루 말할 수 없다고 설명할 수 있겠습니다.

분명 IT 업계에 발을 담그고 계신 분이라면 대부분은 공감하지 않을까 싶습니다. 이 시간에는 무엇을 요구할지 또 뭔가를 더 요구할지 모를 고객에 대비하여 나왔던 소프트웨어 공학에서는 예전부터 제기되었던 애자일(Agile) 방법론의 몰락에 대해 한번 알아볼까 합니다. 하지만 이러한 Agile 애자일 방법론의 몰락에 대해서 알기위해서는 먼저 Agile 애자일 방법론에 대해 잘 알아두어야 하지 않을까 싶습니다. 그래서 먼저 Agile 애자일 방법론에 대해 알아보고 그 후 왜 몰락의 길을 걷고 있는 것인지 한번 알아보도록 하겠습니다.

애자일(Agile) 방법론, 개발기법은 밑에 보여지는 한 싸이클과 같은 방식으로 하나의 프로젝트가 완성된다고 보고 있습니다. 보시면 아시겠지만 사실 Agile 애자일 방법론은 고객과 팀원 및 개발자의 끊임없는 교류와 협의를 통하여 모든 변화에 빠르고 유연하게 대응하는 것을 목표로 하고 있습니다. 또한 무엇보다 최대한 고객의 요구사항에 부합하는 개발 요건들을  개발에 적용하겠다는 것을 목적으로 하고 있기도 합니다. 어찌보면 고객의 입장에서 이러한 애자일(Agile) 방법론은 최상의 조건을 갖춘 개발자 방법론이 아닐까 싶기도 합니다.

하지만 기존의 방법론과 애자일(Agile) 방법론의 차이를 되짚어보면 고객의 요구사항에 대해 지속적으로 관리를 할 수 있다는 점에서 사실 애자일(Agile) 방법론은 고객과 개발자 모두에게 만족감을 줄 수 있는 방법론이 아닌가 싶습니다.

기존 방법론에서는 미리 계획한 요구사항 기간이 있고 요구사항 분석 및 완료로 잡혀있는 그 기간안에 요구사항이 들어오지 못할 경우 그러한 요구사항에 대해서는 수용하지 않고 그러한 요구사항은 추가로 요청하라며 개발을 진행하는 방식입니다. 또한 일정 및 각 프로그램에 대한 상세한 계획기반의 프로세스를 다 잡고 각각의 단계에 대해 문서화를 강조하면서 엄격한 역할분리를 통하여 철저히 자기책임하에 일하게 하고 있는 방식입니다. 

이와는 상반되는 스타일로 애자일(Agile) 방법론에서는 지속적으로 들어오는 요구사항을 받아들이고 그 요구사항을 수용하여 거기에 맞게 다시 개발하고 수정하는 일련의 과정을 프로젝트 완료라는 한 사이클 안에 주기적으로 갖고 있습니다. 주로 요구사항에 맞는 UI를 먼저 고객에게 보여주고 이에 대한 확인을 받은 뒤 개발을 진행하는 절차를 갖고 있습니다. 또한 전적인 자기자신의 책임보다는 팀워크를 중요시하여 설사 한명이 프로젝트에서 빠지더라도 남은 팀원들로 개발진행에 무리가 없도록 적절히 개발에 대한 분배와 역할을 나누어 진행한다는 것이 기존 방법론과는 다르다고 할 수 있겠습니다.

좀더 자세히 살펴보자면 위 화면과 같이 애자일(Agile) 방법론에 따른 개발기법 프로세스는 요청받은 요구사항에 대해 구현을 해보게 됩니다. 요구사항에 맞는 분석/설계/구현을 끝낸 뒤 당연히 테스트를 진행하게됩니다. 그 후 고객에게 선보인 뒤 고객의 피드백을 받고 추가된 요구사항을 다시 구현하고 있습니다. 그렇게 몇단계를 거쳐 고객의 요구를 완전히 만족시켜 줄 수 있도록 일련의 과정을 반복하면서 소프트웨어의 질을 높인다는 측면을 강조하고 있는 것이 바로 애자일(Agile) 방법론 핵심이자 사실 지향하고 있는 길이기도 합니다.

즉, 애자일(Agile) 방법론은 프로세스나 툴보다는 개인간의 교류를 소중히 하라, 포괄적인 문서작성에 힘을 쓰기보다 잘 동작하는 소프트웨어 개발에 노력하라, 계약의 교섭보다 고객과의 협업을 중시하라, 이미 계획된 것에 충실히 따르려는 노력보다 변화에 유연하게 대응하는 것을 중시하라는 애자일(Agile)  말에 충실히 이행하는 것이라 할 수 있겠습니다. 

그렇다면 이론적으로 들었을 때는 완벽해 보이는 이러한 애자일(Agile) 방법론이 왜 몰락이 거론되고 있는 걸일까요. 궁금하지 않을 수 없을 겁니다. 하지만 이미 현장에서 개발을 하거나 혹은 관리자의 입장으로 계신분이라면 애자일(Agile) 방법론 몰락, 그 이유를 이미 충분히 알고 계시리라 생각됩니다. 사실 너무 많은 정보는 없느니만 못하다는 말이 있는 것처럼 이처럼 완벽해 보이고 좋은 이론으로 여겨지는 애자일(Agile) 방법론에도 사실 단점이 분명히 존재하고 있습니다. 

자원이 매우 풍부하고 시간이 많은 프로젝트라면 상관이 없을지도 모르지만 보통의 평범한 기업/현장에서는 사실 애자일(Agile) 방법론을 적용하기에는 팀단위로 움직여야 할일이 많은만큼 계속해서 들어오는 요구사항을 적용하며 무한사이클을 돌린다는 것은 불가능하기 때문입니다. 프로젝트에는 당연히 한정되고 약속된 시간이 있습니다. 최상의 질높은 소프트웨어를 만드는 것도 중요하지만 당연히 기한을 지키고 단계를 거치는 프로세스 역시 중요합니다. 이를 어길 경우 실제 계약위반으로 진행이 되고 있기도 합니다. 

또한 고객 자신도 무엇을 요구하는지 모른채 요구사항을 내고 있거나 그것에 대한 구현 가능한지조차 알수 없으면서 무조건 고객의 니즈를 만족하면서 진행한다는 것에는 많은 한계가 있습니다. 실제 프로젝트 완료 후 그러한 요구조건들은 사용되지 않는 경우도 비일비재하고 있기도 합니다. 애자일(Agile) 방법론은 무엇보다 팀단위로 프로젝트를 진행해야하는만큼 소모되는 자원과 시간이 너무 많습니다. 하나의 만족을 위해 희생하고 거쳐야하는 의외로 많다는 것을 의미합니다.

따라서 이러한 점들을 생각해봤을 때 애자일(Agile) 방법론은 현장 실무에서 적용하기에 무리가 있고 이러한 시간들이 흘러 현재 애자일(Agile) 방법론의 몰락이 거론되고 있는 것이 아닌가 싶습니다.

실제 우리나라에서 적용하기 힘들다고 많은 현장에서 거부하고 있다는 애자일(Agile) 방법론. 애자일 기법의 가장 큰 장점이라 할 수 있는 프로젝트 리펙토링 기능은 고객의 만족이라는 부분과 계속해서 추가되는 요구사항이라는 부분에서는 추후 유지보수나 프로젝트 완성도에 있어서는 높은 점수를 줄 수 있는 이론이지만 위 이유들로 인해 사실 받아들일 수 없는 탁상공론으로 지목될 수 있는 방법론이 아닌가 싶습니다. 이 시간 Agile 애자일 방법론의 몰락과 그 원인,이유에 대해 알아보았습니다.