프로젝트를 할 때 초기에 정하는 것 중 하나가 개발방법론과 관리방법론이다.
개발방법론이 있는 이유는 명확하다. 어떤 시스템을 구축할 때 개발자뿐 아니라 다양한 역할의 사람들이 참여하는데, 이때 서로 다른 언어와 속도로 진행했다가는 10년이 걸려도 100년이 걸려도 마무리를 할 수가 없다. 이는 누더기를 만들어내는 과정일 뿐이다.
서로 다른 경험, 기술력을 가진 사람들이 최소한의 communication으로 시행착오없이 프로젝트를 진행할 수 있도록 도와주는 것이 개발방법론이다. 최소한 개발방법론에서 정의한 대로 진행을 하면 중간중간 불합리해 보이는 작업이 있어 보이나 절대 실패하는 법이 없다.
불합리해 보이는 작업은 '나의 역할'에서 보면 쓸데없어 보이는 일이나, '다른 역할'을 수행하는 사람 입장에서는 필요한 인풋인 경우가 많다.
따라서 개발방법론은 단편적 이해로 그쳐서는 안 되고 전체 프로젝트 life Cycle에 맞추어 이해를 해야 한다.
그러나 현실은 정반대이다.
개발자들은 특히 산출물의 중요성을 간과하는 경우가 많다. 분석/설계/개발/테스트 단계 동안 코딩을 하는 기간은 개발단계이므로 그 전/후 단계의 산출물들은 번거롭게 여긴다. 그 입장을 이해 못 하는 바는 아니다. 내가 맡은 프로그램을 완벽하게 만들어 내면 나의 소임을 다한 것이라고 할 수 있는데 굳이 이를 문서로 분석서, 설계서, 테스트 시나리오, 테스트 결과 증적 확인 등을 하기에는 귀찮을 때가 많을 것이다.
그러나 요구사항이 어떤 방식으로 분석이 되었고, 설계가 구석구석 잘 반영되었는지, 테스트로 그 반영 결과 아무 문제없는지를 아무 근거 없이 작업했다가는 여기저기 구멍이 생긴다.
무엇보다 프로젝트 계약의 범위는 최종 아웃풋인 시스템 뿐 아니라 중간 과정 전체 산출물이 포함된다.
개발방법론이 필요한 이유는 이러한 행정적 처리보다 '과정'에 집중해야 한다. 서두에서 밝힌 대로 많은 사람들이 체계적으로 작업할 수 있게 도와주는 것이 개발방법론이므로 과정을 효과적으로 진행할 수 있게 도와준다.
개발방법론은 그냥 탄생한 것이 아니다. 분석부터 이행까지 짜임새 있게 구성되어 있다. 하나하나 산출물이 그저 구색을 맞추려고 있는 것이 아니라 하나의 단계에서 해야 할 의미있는 작업이 산출물에 담기고, 이 산출물은 다음 단계의 인풋으로 활용되어 다시 다음 단계의 의미있는 작업으로 이어진다.
이 일련의 작업을 위해 개발방법론에서 정의한 산출물의 템플릿 항목들은 정교하게 물고 물리는 구성을 하고 있다.
문제는, 프로젝트를 할 때 이를 이해하려는 사람이 점차 사라지고 있고 중요성을 인지하지도 않는다.
프로젝트에서 산출물 간소화를 내세우며 테일러링 한다는 명목 하에 기형적은 산출물 구조와 템플릿을 정의하고, 이를 가이드하며 프로젝트를 착수한다. 이 기형적인 템플릿을 받아보는 개발자는 더욱 혼란에 빠진다.
이 산출물을 왜 만드는지 알 수 없기 때문이다. 결과적으로 '제출'의 의미만 남게 되고 재활용으로써의 의미는 사라진다.
갈수록 프로젝트 형태가 복잡해지고 있다. 전면 재구축 성격보다 설루션을 대거 도입하거나, 일부 교체/수정 스타일의 프로젝트가 많다.
그렇다 보니 기존 개발방법론에서 정한 활동과 산출물 전체 세트를 다 하지 않고 프로젝트 성격에 맞게 테일러링을 하게 된다. 역시나 프로젝트에 성격에 맞게 테일러링을 하는 것이 아니라 '왠지' 있어야 할 산출물을 정하고 '반드시 필요한 항목'을 산출물 부담을 줄이겠다는 명목으로 삭제를 하는 경우가 많다.
자연에서 잘 자란 소나무를 정원에 옮겨 심으면서 새로운 환경에 어울리게 조경 차원에서 가지치기하는 것은 좋으나 눈 가리고 가위질을 해 버린 것과 다를 바 없다. 흉물스러워진 소나무를 보고, '그러니까 이 정원에서 소나무는 필요 없다고 말했잖아요.'라고 말하는 격이다.
개발방법론은 반드시 필요하다. 그리고 테일러링은 아무나 하는 것이 아니다. 유경험자가 최적의 테일러링을 해야 한다. 그리고 몇 가지 서로 다른 샘플로 직접 방법론을 따라가며 작성을 해 보고 추가 문제가 없는지 반드시 확인하고 보완해야 한다.
가이드를 받고 작성하는 개발자들은 이해에 어려움이 있거나 템플릿이 부당할 경우 이견을 제기해야 한다. 제대로 된 개발방법론과 템플릿을 받았다면 나를 위해서가 아니라 이 프로젝트 참여자를 위해 제대로 작성해야 한다.
ps. 지난주 설계서 검토를 하다가 이해가 가지 않아서 추적을 해 보니 개발방법론과 테일러링부터 문제가 있다는 것을 알게 되었다. 진단 결과를 알려주기가 난감하다. 일주일 더 분석해보고 최소한 지킬 '선'이라도 강조해야겠지.
오래전 개발방법론으로 피 터지게 갑론을박했던 시절이 그리워지는 순간이다. 그 모습을 지금은 어디에서도 보기 어려워졌으니..
