개발방법론, 목적이 무엇인가?
정부/기관의 개발방법론과 민간기업 방법론
개발방법론은 다양하다.
하지만 아무 데나 동일한 방법론을 갖다 붙인다.
이건 안 하느니만 못할 때가 종종 있다.
아주 쉬운 말로 풀어서 써본다.
1. 워터폴 방법론
뭘 만들지 정해놓고 꼼꼼하게 순서대로 조립하는 방식이다.
1) 워터폴방법론 일반
이 방법론을 사용해서 개발하면....
흡사 접시가 깨지기 전의 모습을 기억한 사람이 원래 접시가 어떤 모양인지 서술해놓고 그가 추상적으로 표현하는 것들을 임의로 정의하여 그 조각들을 꼼꼼하게 연결하는 것과 비슷하다.
주로 오래된 회사들이 가장 보편적으로 사용하기도 하거니와 관공서는 대부분 이 방식을 쓴다.
관공서 감리는 보통 워터폴방법론에 대한 감리가 많다.
때때로 애자일방법론을 쓴다면 감리는 좀 더 쉬울 것 같은데 그런 경우에도 이 방법론이 쓰인다.
워터폴방법론은 개발비 견적을 내기가 용이하고 고정된 예산을 설정한 후 생기는 문제를 수주자에게 책임 지울 수 있는 장점이 있다. 그래서 탄력적인 예산 조정이 어려운 관공서에서 워터 방법론을 고집할 수밖에 없다.
이런 것들을 감리한다.2) 워터폴 방법론의 목적
개발과정에서 헛일을 안 하게 만들고 리스크나 척도를 갖고 프로젝트를 운영하는 것이 목적이므로 기가 막히게 방법론의 효과를 볼 때가 많다.
대표적인 케이스로 고객의 목적이 분명하고 그 업무에 대한 전문가인 경우다. 이럴 때는 매우 명확한 목표물이 설정되므로 형상이나 프로세스 같은 것들이 구체화되어 모든 개발자들에게 제공되므로 협업이 큰 효과를 본다.
이런 경우는 아주 이상적인 경우다.
법령, 정책과 같이 쉽게 변경되지 않는 속성을 소프트웨어화 하는 과정이므로 대체로 목적이 분명하고 결괏값이 선명한 편이다. 다만 담당자가 해당 업무에 대해 아는 게 없으면 폭망이 확정적인 방법론이다.
이 방법론은 깨진 접시 붙이기랑 닮아 있다. 깨기 전의 모습을 알아야 어떻게 붙여야 할지 알 수 있는 것처럼.
3) 워터폴 방법론의 문제점
대부분의 고객은 무엇을 하고 싶다는 지향점만으로 발주를 한다.
도대체 그 끝에 무엇이 있는지도 모르고 개발에 대해서 모르기 때문에 그것이 가능한지도 모르는 상태다.
이런 경우 추상적인 발주서를 가지고 개발사에서 목표를 설정하여 역으로 고객에게 제안하는 과정을 거친다.
한쪽은 개발을 모르고 한쪽은 업무를 100% 모른 상태에서 시작하므로 이 프로젝트가 종료된 후에 안정화 기간이라는 것이 무한정 길어지기도 한다.
흐름상 조각을 하나라도 잃어버리면 전반적으로 일이 꼬인다.
1개라도 잘못된 것은 완전한 것이 아니고 완전하지 않은 것은 실패로 간주할 수밖에 없다.
4) 워터폴 방법론을 사용하면 안 되는 프로젝트
- 새로운 부서가 신규 업무를 하려고 시스템을 구축하는 경우 : 아무도 모른다. 무엇을 만들어야 하는 지를.
- 프로젝트 규모가 매우 큰 경우 : 퍼즐이 1만 개 정도 되는 경우를 상상해봐라. 이걸 굳이 한 덩어리로 관리할 필요가 있나?
- 콘텐츠 프로젝트 : 품질의 척도가 매우 주관적인 경우 이 방법론은 적합하지 않다.
5) 그래서?
개발방법론에 대해서는 고객과 협의해서 바꾸는 게 최선이다.
추상적인 목표를 설정할 수밖에 없을 때 또는 시간에 따른 시장 변화가 매우 도드라질 때, 조직의 변화가 심각하거나 외부 협업 조직의 변화를 예측하기 어려울 때 즉시 대응성이 필요하고 변화를 감지하는 능력도 탁월해야 한다.
이런 경우 에자일방법론을 사용하거나 객체지향방법론을 사용하기도 한다.
2. 애자일법론
1) 애자일법론 일반
이를테면 휴대폰을 개발한다고 가정할 때 가장 중요한 것을 우선 개발하고 거기에 기능을 추가하는 것으로 스마트폰을 만드는 것을 상상해보면 된다.
일단 전화를 건다라는 기능이 가장 중요하다. 그러니 전화 기능을 개발한다. 그리고 문자메시지 서비스를 개발하고 시계와 달력을 넣고 달력 넣은 김에 다이어리 기능과 알람 기능을 넣는 식이다.
고객과 개발사는 뚜렷한 목표의식을 가져야 된다. 매우 유능한 전략가와 시장의 흐름을 잘 읽는 정보분석가, 그리고 전략의 정당성이나 정보분석 결과를 모두 이해할 수 있는 리더가 있어야 한다.
개발사에는 실험적인 태도에 적극적으로 임하는 태도가 요구된다.
2) 애자일방법론의 목적
선명하지 않은 목표를 가진 프로젝트를 스킬이 다른 두 그룹이 함께 프로젝트를 할 때 필요한 방법론이다.
예를 들어보자.
전 세계적으로 이제 붐업이 되고 있는 서비스가 있다. 그러나 대륙 별이나 국가 별로 서비스의 형태가 상이하고 마켓의 구조가 다르다. 이런 경우 이 서비스를 유통하기 위한 플랫폼을 구축한다면 고객도, 개발사도 무엇을 만들어야 된다고 선언하기 어려운 상황이 된다.
이런 경우 고객과 개발자는 매우 높은 빈도로 의견교환을 하면서 프로젝트의 살을 붙여나가야 된다.
기간과 투입인원을 추정하여 프로젝트를 시작하고 기간 내 달성해야 할 중대 목표만 설정한 후 프로젝트가 달려 나가는 것이다.
그래서 이 방법론은 인하우스팀 프로젝트에 적합하다.
이 방법론은 점토 공예랑 닮아있다.
뼈대를 세워놓고 계속 살을 붙여 나간다. 이따금 뼈대를 휘어서 다른 자세를 만들기도 한다. 그러므로 모든 것이 유연하고 변형의 가능성에 대응하기 좋은 구조를 갖는다.
3) 애자일방법론의 문제점
방법론의 목적을 이해하지 못한 고객과는 프로젝트 진행이 불가능하다.
하급 직원이 실무자이면서 고객사 내에서 발언권이 미비한 경우 이 방법론은 독이다.
현업 관리자가 목표가 무엇인지 인식하지 못하고 있는 경우 이 방법론은 의미가 없다.
PM이 전략이나 마케팅, 프로세스 등 경영에 관한 개념이 부족하거나 없는 경우 고객의 실험실 쥐로 전락한다.
즉... 고객사가 수준 이하면 의미 없다.
실제로 명목상 현업단에서 프로젝트 팀장과 팀원들을 설정하고 주기적인 회의와 의사소통을 약속받았다고 하더라도 이 프로젝트만 바라보고 사는 경우가 별로 없기 때문에 약속된 시간에 나타나지 않으므로 소통 과정의 정보 누락이 주는 문제들을 계속 야기한다.
결정적으로 의견이나 아이디어들에 대해서 책임을 지는 것을 두려워하는 경우 이 조직은 계속 개발사에게 책임을 전가하는 형태로 의사결정이 이뤄진다. 그게 겁나면 애초에 애자일 같은 건 넘보지 말았어야지.
버전 관리 못하면 다 의미없다~
가끔 거꾸로 거슬러올라갈 필요도 있으니까.
이 산이 아닌가벼~~
아까 그 산인가벼~~~
4) 그래서?
이 방법론은 스마트한 고객과 스마트한 개발자들에 의하여 큰 빛을 보는 방법론이다.
애자일방법론은 매우 우수한 개발 방법론이다.
적극적이고 스마트한 사람들이 이 방법론을 사용할 경우 매우 정교한 조각이 가능하다.
시장에 대응에 매우 기민한 대응이 가능하고 트렌드를 살리면서도 고유한 색깔을 갖기 쉬운 구조의 방법론이다.
어느 한쪽이라도 수준 미달인 경우 편안하게 워터폴 방법론을 쓰고 배를 산으로 끌고 가는 게 나을 수도 있다. 산 위에 뜬 배라도 어쨌거나 배는 배니까 안정화 기간 동안 끌고 내려오기만 하면 된다.(미친 짓이다. 사실은...)
다시 말하지만 고객이 준비가 안되어 있다면 애자일방법론을 사용하지 마라.
[사족]
고객이 애자일방법론을 요구할 경우 반드시 에자일 관련 TF를 구성하고 시간과 의사결정에 관한 프로세스를 담보할 수 있어야 시작할 수 있다.
개발자 입장에서 고객이 에자일 방법론을 사용해서 널을 뛸 것이 예측되고 그걸 감당할 수 없을 때 방어할만한 방법론이 있다.
객체지향방법론이다. 하지만 아무 프로젝트에서나 마구 쓸 수가 없다.
레고 블록으로 만들 수 없는 물건도 있듯이 굳이 이걸 쓰지 않아도 되는 프로젝트에서는 그저 삽질에 불과하기 때문이다.
객체지향방법론은 사실상 위에 언급한 방법론과는 다른 성격을 가지고 있다. 즉 위의 두 가지 방법론이 과정의 관리라면 객체지향방법론은 과정보다는 각 구성요소에 대한 관리라고 할 수 있다.
다음에 이야기할 기회가 있을 거다.
