신기술 밀림 속 생존전략 Part 3: 프로젝트 현장의 이야기 |
 |
많은 프로젝트의 초반에는 요구사항을 협상 테이블에 올려놓고 실랑이가 벌어진다. 어떤 고객(개발을 의뢰한 업체의 담당자)은 특정 기능이 반드시 필요하다고 목청을 높인다. 이에 대응하여 한 개발자가 그것은 기술적으로 불가능하다고 말한다. 그 후엔 첨예한 신경전 혹은 난타전(?)이 벌어진다. 만약에 논쟁의 당사자들을 경계심을 품지 않는 사석에서 만난다면 어떻게 될까?
술자리에서 그들을 만나다
실화는 아니다. 또한, ‘술자리’라는 것은 앞서 언급한 경계심을 품지 않는 사석을 의미하고 식사하는 자리로 바꾸어도 무방하다. 고객이 정말로 원하는 것이 무엇인가를 알기 위해 다각도로 질문을 해봐야 한다. 질문을 하면 할수록 양파 껍질을 벗기는 것처럼 쉽게 끝이 드러나지 않는 것을 경험할 수 있다.
대개 고객은 자신의 문제를 정확하게 설명하지 못한다. 자신들의 문제를 정리하고 설명할 방법을 연구해온 학자가 아니기 때문이다. 더군다나 그들은 돈을 지불하고 서비스를 받고자 하는 손님 위치에 선 사람들이다.
개발자 1의 입장에서는 고객의 문제가 쉽게 이해될까? 개발자들은 고객이 하고 있는 일을 오래도록 하고 있는 것이 아니기 때문에 정확하게 무엇을 원하는지 알 수가 없다. 단박에 설명만 듣고 알겠다고 고개를 끄덕이는 사람이라면 더욱 위험하다. 자신이 믿는 기법과 기술을 가지고 고객이 바라지도 않는 것을 만들어내는 사람일 가능성이 많기 때문이다.
여하튼 산 넘고 물 건너 고객의 어려움을 이해했다고 가정해보자. 그 과정에서 고객이 일하는 현장에서 문제점을 맛보려고 노력했을 가능성이 크다. 심지어는 고객집단 내에서 통용되는 특수한 표현까지 이해할 정도로 어울리게 되었을 것이다. 그렇게 되었을 때에도 과연 ‘그러한 요구는 기술적으로 불가능하다’라고 뻣뻣하게 대답할까?
필자는 프로젝트 현장에서 고객의 요구사항을 다양한 기법으로 정리할 수 있게 돕는 역할을 한다. 경험이 늘어갈수록 어떤 요인들이 중요한지 눈을 뜨기는 한다. 하지만 안타깝게도 어떠한 기법도 고객 한 사람 한 사람을 이해하는 방법을 제공하지는 못한다.
그러나 고객 혹은 프로젝트에 관계된 모든 사람을 이해하기 위해 진심으로 노력한다면 다양한 기술과 기법이 강력한 도구가 되어준다. 종종 프로젝트 전체의 문제에는 관심이 없고, 자신이 알고 있는 기술에 대해서만 열을 올리는 사람들을 만나게 된다. 사소한 기술적 문제나 기계적인 형식에만 관심을 갖는 사람들을 보면 화가 치밀지만 그들도 프로젝트의 구성원이다.
그림 1. Philippe Kruchten의 4+1뷰
프로젝트에 참여한 사람들의 다양한 뷰에 대한 이해가 높아질수록 많은 사람을 이해할 수 있고, 그들과 제대로 대화하는 일이 가능하다.
이해의 충돌과 인정
앞서의 술자리(?)를 통해 고객의 진정한 요구를 이해하게 되었다고 가정해보자. 그런데 우리 회사가 가진 기술력이 최적의 안이 아니란 것을 알게 되었다. 경쟁업체의 기술을 활용하면 더 효과적으로 문제를 해결할 수 있을 것으로 보인다. 이런 상황에 봉착했다면 어찌 해야 할까?
먼저 다른 대안은 일체 언급하지 않고, 우리 회사가 가진 기술력의 범위 내에서 해결책을 이야기해볼 수 있을 것이다. 가장 일반적인 답안이 아닐까 생각되지만 양심에 약간의 가책이 있을지도 모른다. 둘째로 해당 업체와 제휴해 문제를 해결할 수 있을지도 모른다. 요즘은 경쟁사 사이에서도 일시적인 협력을 하는 일이 흔히 발생한다. 어떠한 결정을 하더라도 고객의 진정한 문제를 충분히 공감한 상태라면, 아마도 고객은 개발자가 내놓은 대답이 어떤 것이라도 실망하지 않을 것이다. 서로에 대한 인정을 통해 이미 충분히 신뢰를 쌓은 상태이기 때문이다.
일반적으로 고객은 저렴한 가격과 짧은 기간에 좋은 소프트웨어가 만들어지기를 원한다. 개발자는 풍족한 비용으로 넉넉한 기간 안에 프로젝트를 완수하고 싶어한다. 시작부터 이해는 충돌하기 마련이다. 개발자 사이에서도 서로의 책임 범위와 일하는 방식 등으로 인해 많은 충돌이 내재되어 있다. 고객들 사이에서도 서로 다른 요구를 갖고 있어 이해가 상충되는 것은 어쩌면 당연한 일이다.
특정한 사람이 이기적이기 때문이 아니라 기본 구도가 그렇다. 이해의 충돌은 피할 수 없는 프로젝트의 특성이다. 사람들은 동일한 현상에 대해서도 전혀 다르게 인지한다. 또한, 개인적 기호나 사회적 위치에 따라 같은 사건의 결과에 대해 조금씩 다른 반응을 보이기 마련이다. 그래서 문제를 다양한 관점에서 포착해내는 것은 어떤 분야에서나 매우 중요하게 다루어진다. 시사 문제에 대해 취급할 때도 사회의 각기 다른 진영의 목소리를 한 자리에서 다루기 위해 노력하는 모습을 쉽게 볼 수 있다.
그림 2. 시사토론 현장
토론 현장에서 짜증스런 답변을 하는 패널의 경우는 대개 상대를 인정하지 않는다. 필자는 종종 프로젝트에서 마음에 들지 않는 사람을 만난다. 그 사람의 행동은 사사건건 문제를 일으키는 것으로 보인다. 그런 경우는 의심할 여지없이 필자가 그를 인정하지 않고 있는 경우다. 스스로 짜증나는 토론 패널 역할을 하고 있던 것이다.
마음에 들지 않던 사람을 프로젝트를 함께 하는 같은 팀의 일원으로 인정하는 순간 똑같은 사람이 달라 보이고 그가 하는 말과 행동을 조금씩 이해하기 시작한다.
최소한의 공동체 의식
함께 프로젝트를 하는 사람들과 식사를 하는 도중에 ‘IT 사람들은 사기꾼’이라는 취지의 이야기가 나왔다. 이야기를 꺼내놓은 사람들도 모두 IT 사람들이기에 강한 비난조의 이야기는 아니었다. 이 바닥 경력이 까마득한 분들이었기에 현장에서 지친 사람들의 자조 섞인 넋두리라고 할 수 있다. 그렇지만 인정하고 싶지 않은 이야기다.
고객의 기술적 무지를 활용하여 지갑을 열게 한다는 것이다. 고객과 개발자 사이의 공동체를 완전히 부정하는 것을 전제로 한 이야기다. 공포감이나 무지를 활용한 마케팅 기법이 있기도 하다. 실제로 그렇게 행동하는 사람들이 있기는 하다. 지난 시간에 그런 사람들의 이야기도 언급했다. 하지만 스스로를 포함하여 IT 사람들 전체를 매도할 필요는 없다.
언젠가 읽었던 ‘있음과 없음(윤구병 지음)’이라는 책에서 학문하는 사람들의 말버릇(http://younghoe.info/87)이라는 표현이 매우 인상 깊게 와 닿았다. 가치관이 없는 상태로 오랫동안 지식만 습득하다 보면 은연중에 자신의 지식을 가지고 다른 이들을 따돌리는 태도를 몸에 익힐 수도 있겠구나 싶어 섬뜩한 마음도 들었다.
프로젝트를 하면서 스스로에게 공동체 의식이 매우 부족한 것을 느끼게 된다. 이미 XP 진영에서는 오래 전부터 공동체 의식을 설파하고 있다. 이는 기술로 해결되는 것이 아니라 일상의 매 순간 스스로를 닦아내야만 가능한 일이다.
그림 3. XP 실천사항
필자는 학창 시절에 ‘수신제가치국평천하’의 진정한 의미에 대해 조금도 배운 바가 없고, ‘공동체 의식’이란 것마저도 고작 윤리 시험을 위한 답안으로만 배웠다. 중고생을 자녀로 두고 있으면 한 달에 사교육비로 수백만 원을 준비해야 하는 시대라고 한다. 그럼에도 불구하고 그들이 공동체 의식을 배우기 위해서는 더 오랜 세월이 걸릴 것만 같다.
맺음말
소프트웨어 개발 프로젝트 현장에서의 이야기를 담았지만, 공동체를 이루는 곳이라면 어디서나 통용될 수 있는 이야기다. 짧은 글이나마 정리하면서 스스로 돌아보는 계기가 되었다. 공동체 의식에 대해 필자가 조언을 할만한 입장은 아니다. 단지 함께 살아가는 동시대의 사람으로서 그저 느끼는 바를 공유하고자 함이다.
주
1 시스템 분석가, 설계자, 프로그래머를 통칭하는 의미로 사용함.
참고 자료
- 있음과 없음, 윤구병, 도서출판 보리, 2003년 출간
- Vincent Xu: Agile 101: Pair Programming & Simple Design
 [지난 Special Issue 보기]
|
안영회 
