많다고 하면 많고, 조금이라고 생각하면 조금이겠지만,

최소한 나름대로 다양한 사이트를 경험해왔다고 생각은 한다.

 

다양한 사이트를 다니면서 이런 저런 것들을 만들고 구성하면서 드는 최후의 생각은 바로 이것이였다.

 

“ 고객은 적이다!!!! “

 

하지만, 일을 하면서 돈을 주는 건 애석하게도 고객이기 때문에, 언제나 프로그래머들은 “적과의 동침"(?)을 계속 해올 수 밖에 없었다.

 

이 때, PM혹은 PL 또는 프로그래머들은 일정과 요구사항에 맞추어 고객을 무시하고 진행할 수 있다. 제시간에 프로젝트를 종료하고, 모든 프로그래머들은 행복하고, 편한 사이트라고 평할 수 있는 그런 진행말이다. 그러나, 우리나라에서 그런 짓을 하다가는 십중 팔구 프로젝트 실패나 고객의 불신 포인트 쌓기에 심하면 차기 프로젝트에 있어서 지명 제외 사태까지 벌어진다. 더욱이 고객이 네트워크 까지 넓다면 다른 사이트 들어가기는 물 건너 간셈.

그렇다면 고육지책이지만, 프로그래머를 쥐어 짜면? 무리한 요구사항들이든 뭐든 받아들이고 진행하면? 물론 프로젝트 검수 완료 될 때( 대개 프로젝트의 사이즈에 따라 다르겠지만, 1~2 주일, 혹은 한달, 심하면 1년? 지연이 되는 것은 어쩔 수 없을 듯… ) 고객의 극찬과 맛난 음식이 기다리겠지만, 그 전에 프로그래머들의 건강은 피폐해지고, 직업병에 대한 심각한 우울의 나락을 왔다 갔다 하고 자신의 신세한탄의 홍수에 오락가락 할 것은 뻔하다. 그리고 이직하고 이직하고…

 

이게 현실이다!!!! 라고 말하기에는 무언가 이상하다고 생각된다.

사실 고객이라고 해봐야, 그들도 결국 다른 이들을 고객으로 삼고있는 또 다른 형태의 서비스 제공자일 뿐이다. 그들도 이 소프트웨어 바닥의 괴로움 정도는 어느정도 알고 있다고 생각한다. (최소한 초창기 시절 보다는.. ). 이심 전심이지 않을까? 그들도 최소한 서로 Win-Win 하는 방법을 찾고 싶어하고, 그렇게 움직이고 싶어한다. 하지만, 결국 일을 시작하면, 자선사업이 아닌 이상, 결국은 비용과 일정 때문에, 결국 프로그래머들을 쪼고 또 쪼게 되는 악순환을  반복하게 된다.

 

자… 그럼 무엇이 문제일까?

이 부분에 대한 해답까지는 아니지만, 나름 대로 실타래 끝자락을 바로 이 애자일에서 찾을 수 있었다.

맨 처음 접했던 애자일은 사실 신뢰성 0 였다. 도리어 여타 다른 방법론과 같이 취급되었다. 그전에 직접 체험 보다는 간접 체험한 사람들의 결과 내용들을 보기만 했는데, 이게 과연 방법론 맞아? 라는 의구심만 들게 만들었고, 가장 위험한 방법론이구나, 라는 생각이 들었다. 그리고 몇 년이 흘러, 우연히 찾은 김창준씨의 블로그를 보면서 새롭게 바라보았고, 관련 서적을 이것 저것을 보고 난 뒤, 나의 오해는 거의 다 푼 것 같았다.

 

자,다시! 그렇다면 문제는 무엇일까?

최소한 내가 바라보는 문제는 바로 고객과 프로그래머 사이를 효율적으로 조율할 무언가의 부재였다. 이 이야기하면, “PM이나 PL이 바로 그런 역할을 하는 거야!” 라고 정중히 충고하시는 분들이 있을 것이다. 그러나 그건 다르다. PM이나 PL은 고객과 프로그래머를 조율하는 것이 아니라, 일정 관리나, 기술 관리 등을 수행하는 또 다른 조직일 뿐이다. 혹은 설계 부분을 담당하거나, 요구사항을 정리도 하겠지만, 결국 프로그래머 관리하는 관리 조직일 뿐인 것이다. 그렇다면 그 무언가는 무엇인가?

 

그건 바로 중간 결과물이다.

다시 오해를 벗기 위해 또 다시 이야기를 하겠다. 내가 말하는 중간 결과물은 단순한 문서나 제작중인 코드를 의미하는 것이 아니다. 게다가 솔직히 문서 같은 것은 중간에 고객에게 보여주기 위해서 만들기 보다는 중간에 품질 관리에서 도장을 받기 위한 숙제 같은 것일 뿐, 중간 결과물이 아니다!!!

내가 말하고 싶은 것은 바로 프로토타입 처럼 고객에게 보여줄 수 있는 그런 중간 결과물이다.

터무니 없다고 생각되는가? 그럴 수 있다. 도리어 성급하게 결과물을 보여주면 그간 모아온 요구사항과 완전 역전되는 진행을 낳을 수도 있다. 그러면 기존에 설계된 사항과 완벽히 위반되어 처음 부터 다시하는것 아닌가? 라는 것이다. 맞다. 정말 맞다.

그런데 다시 생각해보자. 왜? 요구사항과 설계가 역전되어 새로 다시 모으고 만들어야 될까?

부끄러워 숨기고 싶겠지만, 바로 그 놈의 요구사항은 고객의 의도와는 전혀 다르게 수집하고,

고객이 원하는 모습과는 전혀 다른 모습으로 설계하고 있었던 것 아닌가?

여기에 유명한 그림이 있다. (http://onestone.tistory.com/entry/user-requirements)

왜 요구사항의 환상이라고 했을까? 환상? 아니다.

고객의 의도와 개발자의 한계 상의 조율이 전혀 안된 것 뿐이라는 것이다.

 

일단, 고객에게 가장 중요한 것이 무엇인지 물어봐서, 최대 2주 내로 구현 가능한 모델을 만드는 것이다. 그리고 시연하고 보여준다. 다시 이야기한다. 다시 여기서 살을 붙이고 뼈를 잇는다. 여기서 중요한 것은 무조건 고객에게 모든 것을 다 주는 것은 아니다. 고객도 희생이 필요하다. 당신들이 원하는 것은 이정도 크기의 프로젝트다! 그러면 모든 것을 들어주는데는 10년이 걸리고 10억이 필요하다! 그렇게 하고 싶지 않으면 어떻게 할까? 이제 고객의 욕심을 줄이는 시점이 오는 것이다. 이건 있으면 좋겠지만, 꼭 필요한 것이 아니면 없앨 수 있는 계기를 만들어주는 작업을 하는 것이다. 비용과 기간을 고객의 요구사항과 저울질을 하는 것이다. 그리고 여과 없이 보여준다.

 

이게 바로 핵심이지 않을까 싶다.

이를 위해서는 라이트한 조직으로 기존과는 전혀 다른 진행, 관리 방식이 요구된다.

이 부분에서 애자일에서는 다양한 방법들을 마치 방법론 처럼 보여줄 뿐이다.

 

우리나라의 소프트웨어 개발 환경에서는(애석하게도 외국의 다양한 사이트에서는 이미 많은 성공 사례들이 발표되고 있고, 큰 개발 조직 같은 경우에서도 시도하고 있으며 이미 발전 단계에 이르렀다) 마치 환상 같아 보이기만 하지만, 이런 환경을 구성하여 진행하는 곳에 꼭 참여해보고 싶다.

 

당분간은 이런 환경 접하기는 어려워 보이고, 스스로 만들 용기나, 힘도 부족하니 당분간은 책을 통해서 생각이나 정리하면서 지식 DDR나 하면서 공상이나 해야 겠다.

728x90

+ Recent posts