소프트웨어 프로젝트에 대한 또다른 메타포

우리는 소프트웨어 프로젝트와 프로젝트 수행방식에 대한 아주 오랜 메타포인 폭포(Waterfall)를 만났으며, 만나고 있으며, 불행하게도 계속 만날 것 같다. 누군가 새로운 메타포로 끝없이 저항하고 철저히 무력화시켜주지 않는다면 계속 만날 것 같다. 

폭포(Waterfall) 메타포가 선언되고 오랜 세월이 흐른 지금 우리는 잘못된 메타포가 우리를 얼마나 힘들게 하는지 온몸으로 느끼고 있다. 소프트웨어 프로젝트의 본질에 대한 오해 정도는 아무것도 아니다. 그러한 메타포를 기반으로 개발 프로세스가 정의되었다는 사실은 우리의 희망을 빼앗아 간다. 폭포 메타포는 선언한 직후에, 메타포가 잘못되었다고 스스로 선언했다. 그럼에도 폭포 메타포 추종세력은 절대로 죽지 않고 끝없이 살아나는 강시처럼 IT 업계 여기저기서 활개치며 돌아다니고 있다. 
  

[참고자료-인터넷을 검색하면 다음과 같은 자료는 얼마든지 만날 수 있다.]
Waterfall Model Advantages and Disadvantages 
(http://www.buzzle.com/articles/waterfall-model-advantages-and-disadvantages.html)

개발프로세스는 개발자들의 작업 공간을 넘어 그들의 삶에 커다란 영향을 미친다. 따라서 잘못된 메타포를 기반으로 하는 개발프로세스는 프로세스 자체의 정당성을 떠나 개발자 입장에서는 저항할 여지가 없는 독재자같은 존재다. 개발자의 일상은 매우 현실적이다. 하지만, 프로세스 담당자의 일상은 산출물이 생산되는 현장에서 한 발 떨어져 있다. 따라서 독재가 휘두르는 포악한 칼날이 개발자의 하루하루를 얼마나 피폐하게 하는지 개발자 이외에 아는 사람은 없다. 프로젝트 관리자, QA, 테스트 담당자, 프로세스 관리자와 같은 역할 담당자는 그저 결과만을 요구할 뿐이다. 그 절차가 옳든 그르든 시간의 흐름에 따라 산출물이 쏟아져 나와야 된다는 단순명료한 원칙만을 고집하고 있다. 

개발자가 뭔가를 만들어내는 현장이 바로 현실이다. 개발자는 폭포 메타포의 문제를 너무나 잘 알고 있다. 하지만, 아무리 아니라고 외쳐도 들려오는 것은 "언제까지 산출물 끝낼래?"라는 무표정한 얼굴에서 내뱉어지는 차가운 질문 뿐이다. 이 시점에서 이 산출물을 왜 만들어야 되는가라는 질문을 해도 같은 질문을 들어야 한다. 어느 순간부터 개발자는 저항을 포기하고 의미가 있든 없든 그저 산출물을 만들어 낸다. 템플릿에서 부여한 목차 속의 작은 제목들이 가지는 의미를 생각하기 보다는 그 속에 무엇이든 구겨넣을 자료를 찾거나 만들 뿐이다. 그 산출물은 작성한 개발자 본인이나 그것을 무슨 보물인양 인계받은 유지보수 개발자에게도 아무런 도움이 되지 못한다.  

개발 방법론(Development Methodology은 개발 프로젝트의 전체 범위를 가진다. 프로젝트 예산 집행, 협력업체 관리 등과 같은 프로젝트 관리에 필요한 모든 것을 포함한다. 반면, 개발 프로세스(Development Process)는 개발행위와 관련된 범위를 가진다. 즉, 요구사항 파악, 시스템 분석, 그리고 개발 환경 구축 등과 관련된 역할, 활동, 산출물 그리고 각종 가이드와 템플릿 등에 대한 정의를 포함한다.  

오늘 나는 새로운 메타포를 이야기하고 싶다. 사실 이 메타포는 내겐 새로운 것이 아니다. 각종 자료나 컨퍼런스의 발표에서 사용한 지는 6개월이 넘은 것 같다. 온라인에 공개하는 글로는 처음일 뿐이다. 소프트웨어 프로젝트에 대한 여러 메타포 대열에 그냥 줄서서 주목을 받기를 기다리는 그런 메타포 신세가 되지 않았으면 하는 바램 간절하다. 잘못된 메타포의 해악을 20년이 넘도록 온몸으로 느껴온 터라 그 간절함은 더하다. 

며칠 동안 고민의 꼬리를 자르지 못해 고민하던 어느 날 밤, 
그날도 나의 의문은 단 하나뿐이었고, 날이 갈수록 집요함만이 늘어갈 뿐이었다. 

도대체 프로젝트의 본질이 무엇이건대 프로젝트 팀원들은 이토록 고통스런 시간을 보내야 할까?

같은 오류를 반복하고, 또 계획하고, 다시 그 오류를 반복하고, 
과연 이것이 합리적인 이성을 가지고 있는 인간들이 할 일(차라리 "짓"이라고 표현하고 싶다)인가?

확정되지 않을 요구사항을 확정지으려는 미련한 시도는 계속되고,
내용도 모르고 사용처도 모르면서 산출물 챙기기는 계속되고,  
결론도 나지 않을 회의는 끝없이 계속되고,
관리자들은 모여앉아 허위보고로 나온 98%의 진척율에 기뻐하고, 
모델링을 모르는데 이렇게 저렇게 설계는 끝이나고,  
초급개발자는 내용도 모른 채 채워넣기나 복사와 붙이기만을 계속하고, 
중급개발자는 개발시간이 없어 아우성치다가, 프로젝트 말미에서 겨우 시간을 조금 얻는다. 
 
그러면서 염치없게도 프로젝트 수행 품질과, 시스템 품질을 이야기 한다. 
여전히 감리는 이상없이 통과한다.
당연히 시스템은 여기저기 탈이 나 있다. 

폭포 근처에 서있는, 
개발자는 괴롭다, 
그들을 괴롭히는 관리자도 괴롭다.

[안개고지전투(Foggy Hills Battle)  

 

소프트웨어 개발은 안개고지전투(Foggy Hills Battle)다. 
    - 고지는 요구사항 그룹이다. 어떤 산이든 작은 산으로 이루어지듯 요구사항도 마찬가지이다.  

    - 안개 자욱하여 앞이 보이지 않듯이 우리의 요구사항은 언제나 안개 속이다.  
    - 하나의 고지를 점령하면 다음 고지가 더 잘 보일 뿐만 아니라, 경험을 활용할 수 있다. 
    - 고지는 언제나 서로  다르며, 지도는 단순한 참조일 뿐이다.
    - 고지로 이르는 길은 고지를 점령하고 의미가 없다. 고지만이 의미가 있다.   

>> 안개고지 전투에서 반드시 패배하는 방법
    - 잘 보이지 않는 모든 고지를 동시에 공략한다. 
    - 각 팀이 고지를 오를 때, 끝없이 좌로 우로 통제를 한다. 
    - 고지 보다는 고지에 이르는 길을 중요시 한다. 

>> 안개고지 전투에서 반드시 승리하는 방법 
    - 맨 앞의 낮은 고지부터 점령한다. 
    - 팀이 일단 고지를 오르기 시작하면 팀에게 맡긴다. 지휘관이 할 수 있는 것은 지원사격 밖에 없다. 
    - 팀은 최선을 다해서 반드시 고지를 점령해야 한다. 

새로운 메타포를 바탕으로 새로운 프로세스를 만들고 싶다. 하지만, 내가 그런 수고를 할 필요가 없다. 이미 세상에는 안개고지전투 메타포를 반영한 정말 훌륭하면서도 매력적인 프로세스가 나와있다. 세상의 뛰어난 개발팀들이 그 프로세스를 따라 행복한 개발자의 꿈을 이루고 있다. 

우리는 그것을 애자일(Agile) 프로세스라고 부른다. 

[마흔살 엔지니어]