[Agile] 애자일 방법론에 대한 단상(短想)

<출처 : https://agilemanifesto.org/iso/ko/manifesto.html>

애자일(Agile) 은 여타 많은 소프트웨어 개발 방법론 중의 하나 입니다. 전통적이지만 아직까지도 많은 기업에서 실무에 적용되고 있는 폭포수(Waterfall) 방식과의 비교를 통해, 폭포수방식 보다 훨씬 더 좋은 방법론이라고 이야기하는 사람들이 꽤 많은 것 같습니다.
필자가 이 글을 포스팅하게 된 것도, 어떤 IT회사 대표님과의 저녁식사 자리에서의 대화 때문입니다. 애자일이 만능이라고 나에게 침 튀도록 야그하던데, 이상하게 사이비 종교를 포교하는 듯한 느낌이 들었고, 내가 이해하기 힘든 장점만 얘기 하더라는...... (사실 IT쪽을 잘 모르거나 하면, 혹 하고 넘어가긴 할 것 같이 말은 정말 잘 하던데, 구지 오랜시간 같이 하고 싶지 않아서, 대충 맞장구 쳐주고 영양가 없는 대화의 시간을 마무리 했습니다. ㅋㅋ)

지금부터 하는 얘기는 순전히 필자의 개인적인 생각임을 미리 명확히 하겠습니다.
그냥 이렇게 생각하는 사람도 있구나~~~ 하고 이해해 주시면 됩니다.

폭포수니 애자일이니 서두에서와 말한 바와 같이 소프트웨어 개발 방법론 중의 하나입니다. 구체적인 내용은 웬만하면 다들 아실 듯 하니, 필자는 실무 관점에서 평소 생각해 왔던 몇가지를 짚어 보고자 합니다. 

애자일 경험이 많은 구성원으로 팀빌딩 하는 것 부터 애자일방식으로 플젝을 진행하다고 하는 회사들 요즘 너무 많지요.
과연 그런 기업 들 가운데 애자일 방법론을 제대로 이해하고 실천에 옮기는 기업이 몇이나 될까요?
애자일 방법론의 여러 장점들 가운데 중요하게 얘기하는 몇가지가, 워터폴 방식의 단점을 보완하여 변화에 유연하게 대처 하면서 빠른 결과를 보여줄 수 있다고 하지만, 정말 그러할 지 솔직히 저는 잘 모르겠습니다.
적어도 우리나라의 일반적인 기업문화에서는 말입니다.

예를 들어 보겠습니다.
한 기업이 6개월 기간동안 애자일 방식으로 수행할 플젝을 5억에 수주했다고 가정하겠습니다.
빠르고 유연하게 상황 변화에 대처해 가며 지속적인 요구사항의 변화도 수용할 수 있다는 애자일 방법론을 적용했으니, 과연 고객의 요구사항 변화에 부응하면서 프로젝트를 성공적으로 끝낼 수 있을까요?

일단, 필자는 다음과 같은 여건을 신중히 고민해 봐야 할 것이라고 생각합니다.

우리나라 기업문화의 차이점을 간과해서는 안된다는 것 입니다.

프로젝트 진행기간 혹은 프로젝트 전체 수행금액의 증가에 크게 영향을 주는 환경이나 요구사항의 변화가 있을 경우 발주사와 수행사 중 어느 한쪽, 또는 양사 협의로 기간이나 비용 증가를 해결해 줄 수 있는지를 구체적으로 고민해야 합니다.
애자일 도입으로 정해진 기간과 비용내에서 요구사항의 변화에 대응할 수 있다고 이해하시면 안되고, 요구사항의 변화에 맞게 기간이나 비용의 변화도 적용받게 될 수 있음을 이해해야 한다는 것 입니다.
아쉽게도 우리나라의 기업문화에서는 기대하기 어려운 것이 사실이며, 물론 그렇지 않은 기업도 있겠지만 대다수의 기업은 기간과 비용이 정해지고 프로젝트가 시작되면, 정해진 기간과 비용 내에서 더 많은 양질의 결과물을 얻기 위해 크고 작은 요구사항들의 변경을 끊임없이 요청하게 되고, 그러한 것들이 반영된 결과물을 제출할 때 까지 엄청 쪼아댑니다.
애자일이 변화에 기민하고 발빠르게 대처 가능하다는 것이 장점이라고는 하나, 모든 것에 만능일 수는 없겠지요.
요구사항의 변화도 어떤 내용이냐에 따라, 그리고 프로젝트 진행 단계 중 어떤 단계에서 요구사항 변경을 요청 하는가에 따라 기간과 비용의 증가 문제가 엄청나게 커질 수 있을 것입니다.
요구사항의 변경 요청이 주는 변화 자체가 클 수도 있겠지만, 요청 시기에 따라 파급되는 효과는 기하급수적으로 커질 수 있다는 뜻 입니다. 당연한 얘기지만, 프로젝트 시작 초에 발생하는 요구사항의 변경이라면 워터폴이나 애자일이나 정도의 차이가 있을 뿐 충분히 반영 가능하겠지만, 프로젝트 진행 후반에서 발행하는 요구사항의 변경은 내용에 따라 설계 자체를 변경해야 할 경우의 요청이라면 방법론에 상관없이 타격이 클 수 밖에 없기 때문에 변경요청 시기도 중요하다는 겁니다.

결국 이러한 현상들은 한정된 기간과 자원내에서 타이트하게 정해진 개발을 수행해야 하기 때문에 발주사는 계약서의 내용 안에서 양질의 결과물을 얻기 위해 요구사항의 변경이나 추가사항을 요청하게 되고, 수행사는 정해진 기간내에 프로젝트를 완료하는데 영향을 줄수 있는 내용은 최대한 방어적인 자세로 수용해야만 기간내에 프로젝트를 끝낼 수 있는 우리나라의 기업문화 때문이 아닐까 생각합니다. 공증된 계약서의 기간이나 수행범위가 변경될 일은 거의 없습니다.
대개의 경우, 파급효과가 클 것으로 예상되는 내용이나 요구사항 변경 요청은 프로젝트가 끝난 후 2차 개발 또는 고도화작업 이라는 이름으로 모아서, 다음 프로젝트를 따내기 위한 영업전략으로 활용되기도 합니다

해외에서 애자일 방법론의 성공적인 적용 사례들을 자세히 살펴보면, 애자일 방법론이 성공적인 결과를 낼 수 있도록 인식하고 적극적으로 움직이는 기업문화가 밑바탕에 있습니다. 애자일 방식으로 프로젝트를 진행하면서 발주처의 요구사항 변경 또는 환경의 변화에 의해 기간이나 비용이 증가 될 수 있음을 양사가 공동 인식하고, 그러한 상황이 발생 했을 시 기간이나 비용증가 부분을 양사가 합리적 협의를 통해 기간을 늘리거나 추가 비용발생을 수용하는 기업문화가 밑바탕이 되어 준다면 그만큼 성공 확률이 증가되겠지요.
하지만, 해외 사례의 경우도 필자가 보기에는 애자일 방법론과 함께 마케팅이나 관련한 다른 요인에 의해 프로젝트가 잘 마무리 되었음에도 불구하고, 애자일 방법론으로 인해 성공했다고 과대평가 되어 있는 경우도 많은 듯 합니다.

기업문화 외에 한가지 더 생각해 봐야 할 것이 있습니다.
바로, 구성원들의 경험과 소통능력, 그리고 참여도 입니다.

애자일 방법론을 실제 경험해본 구성원이 있고 없고의 차이는 명백하게 드러날 수 밖에 없습니다. 왜냐하면 애자일 방법론은 짧고 주기적인 소통과 피드백을 통해 개발과 테스트를 하는 사이클이 반복되므로, 팀 내에서의 의견 충돌이나 기술적인 문제점들을 해결해야 할 경력자가 필요하고, 발주처의 프로젝트 참여 또한 끝날때 까지 계속 함께 하며 양질의 결과를 위한 테스트 및 피드백을 제공 해 주어야 합니다. 이는 비단 애자일 만의 고려사항은 결코 아니며 모든 방법론에서 동일하게 고민해야 할 사항이지만 가장 쉽지 않은 문제이기도 하지요.
이러한 사항들에 대한 충분한 고려가 없는 상태의 기업들이 애자일 방법론 적용한다고 하면, 십중팔구 겉으로는 애자일이라고 하고 내부적으로는 워터폴 형태로 플젝을 하면서 두 방법론의 장점을 취하지 못하고 오히려 단점을 안고 가는 기업일 확률이 높습니다.
차라리, 워터폴 방법론을 메인으로 하되 내부적으로는 애자일 방법론을 일부 적용해서 진행하겠다고 얘기하는 기업이면 조금 더 믿음이 갈지도 모르겠습니다. 애자일은 워터폴의 단점을 보완하기 위해 만들어진 또 다른 방법론이기 때문입니다.

그렇다면 우리나라에서는 앞서 얘기한 이유들로 애자일 방법론을 적용하는 것이 어렵기만 할까요?
ㅎㅎ 그럴리가요. 저 또한 환경이나 규모 등을 고려 했을때 애자일 도입이 적절한 기업의 경우 최고의 시너지를 창출할 수 있는 훌륭한 방법론 임을 격하게 인정하고 있습니다.
다만, 30년 가까이 워터폴 방법론에 익숙해져 있는 오래된 프로그래머로서 몇가지 고려해야 할 사항만 전달하고자 합니다.

첫번째. 어느 한쪽에 너무 치우치지 마시기 바랍니다.

워터폴과 애자일 방법론의 장단점 잘 비교해 보면 상대적으로 대치되는 부분들이 많습니다.
지금까지 워터폴 방식에 익숙해진 필자의 경우, 문서작성에 대해 가장 불필요한 노동력 소모가 많았다는 생각입니다.
결국, 프로젝트 종료 승인은 통합 테스트결과와 각각의 단계별 산출물의 작성 여부였습니다.
(내용의 Quality 보다는 내용의 존재 여부와 제목이 더 중요했던 것 같습니다. ㅠㅠ)
최초 분석 및 설계단계에 만든 요구사항정의서와 스크린 레이아웃, 테이블 설계서, 기능 명세서 등 중요한 문서들은 반복 작성하는 경우가 많았습니다. 프로젝트가 진행되면서 매번 관련 문서들을 업데이트 해가면 개발하면 되는거 아니냐고 반문 하시분들도 많이 있습니다. 물론 그렇긴 한데 제가 부족해서인지 기능이나 화면 하나씩 개발 끝나면 정리할 여유 보다는 다음 개발 분량 때문에 개발 중 문서작성을 같이 한다는게 말처럼 쉽지는 않았습니다. 하여 프로젝트 시작할때 다른 프로젝트에서 작성했던 문서들을 싸그리 복사해 놓고, 초기에 작성해야 할 요구사항정의서 같은 몇몇 문서들만 만들어 놓은 후 개발이 끝날 즈음 날잡아서 문서작업만 하곤 했습니다. (예전에 3☆에서 공공개발쪽 할때가 최고의 절정이었던 듯 합니다)
암튼,,, 할많하않~~~

애자일 개발 선언문에도 "포괄적인 문서보다 작동하는 소프트웨어를" 이라고 언급 했듯이 산출물 보다는 실제하는 소프트웨어 결과물에 더 가치를 둔다고 했습니다.
중요한 포인트는 더 가치를 둔다고 하는 부분인데, 결코 포괄적인 문서는 안해도 된다라는 의미가 아닙니다.
하지만 몇몇 대표님들이 과장했겠지만 이렇게 얘기하기도 합니다. "우리는 애자일 방법론을 적용하기 때문에 문서작성은 크게 신경쓰지 않습니다" 라고......
하지만, 과연 필요한 핵심문서 작성도 없이 프로그램 개발이 잘 진행될지 한번 고민해 보셔야 합니다.
오류없이 제기능을 발휘하는 개발코드 제일 중요하지만, 그 프로그램을 어떻게 어떤 과정으로 개발했고, 다른 개발자가 인수인계를 받더라도 소스분석을 위해 전체적인 요구사항들이 어떻게 적용되어 만들어 졌는지를 알기 위한 최소한의 문서들은 당연히 존재해야 합니다.
형상관리 툴을 사용하여 클라우드에 소스코드와 문서들을 관리 한다고 하더라도, 출력만 안할 뿐 당연히 필요한 최소한의 문서들은 반드시 존재해야 합니다. 소스코드는 물론이고, 소스코드 내에 주석문으로 개발문서를 대신한다는 건 최소한의 문서들 중 극히 일부분일 뿐이거든요.
절대로, 작동하는 소프트웨어에만 신경쓰겠다는 뉘앙스는 표현하지 마시기 바랍니다.

두번째. 프로젝트 환경에 적합한 방법론의 선택과 병행

프로젝트의 환경과 규모, 구성원, 향후 발전 및 변경 가능성 등을 종합하여 포괄적 변동성을 감안한 선택이 우선입니다.
그리고, 복합적으로 적용 가능한 부분을 찾아 보시기 바랍니다. 기업의 상황에 맞게, 또는 팀의 여건에 부합하는 방식을 적용해야 합니다. 프로젝트 전체는 워터폴 방법론을 기준으로 하되 각각의 서브 프로젝트들은 상황에 맞게 애자일 프로젝트를 적용하는 것도 하나의 방법이 될 수 있겠지요. 이런 경우에는 워터폴 방법론도 일정 부분 애자일을 위한 양보가 필요하기도 합니다.

세번째. 많은 방법론 중의 하나일뿐, 만능이 아닙니다.

우리나라의 플젝 대부분은 시작할 때 이미 틀에 짜여져 있는 어느 정도의 계획과 문서들이 있는 상태에서 시작하게 됩니다.
과거의 경험과 자료들이 있고 정해져 있는 방식들이 있다면, 구지 애자일을 적용 할 필요까지는 없다고 생각됩니다.
애자일 적용이 적당한 환경과 규모인지, 프로젝트 성격과 부합하는지 등등 많이 고민해 본 후, 수많은 환경의 변화가 예상되고 결과를 예측할 만한 데이터가 충분하지 않다면 고려 할 만 합니다. 애자일은 관용도가 상당히 높은 방법론이긴 하지만 지속적이고 충분한 결과를 만들기 위해 워터폴과는 또 다른 관점의 리소스가 필요 할 수도 있습니다.

현실은, 애자일 방법론에서 얘기하는 대로 움직여 주지 않습니다.
그럼에도 불구하고 필자는 워터폴과 애자일의 조화로운 병행(애자일 스러운 워터폴, 또는 그 반대)을 추구합니다.