<불안은 영혼을 잠식한다(Fear Eats Soul).>라는 제목의 영화가 있다. 불안은 정말로 사람의 영혼을 잠식하고 이성을 마비시키는 것일까. 나는 최근의 경험을 통해서 과연 그렇다는 사실을 깨닫게 되었다. 사연은 이렇다.
나는 20년이 넘도록 소프트웨어 개발과 관련된 일을 해왔지만 프로젝트의 단가를 산정하거나 계약을 체결하는 종류의 일을 한 적은 없다. 큰 회사에서 개발 자체에 국한된 일만 해왔기 때문이다. 그래서 한국에 있는 친구나 후배가 전해주는 어둑어둑한 업계의 관행과 분위기가 익숙하게 들리지 않을 때가 많았다. 예를 들어서 하청에 하청이 꼬리를 물고 이어지고, 프로젝트 비용이 턱없이 낮은 단가로 산정되고, 말이 되지 않는 마감일이며, 힘없는 프로그래머들은 밤새워 몸으로 삽질을 하고.
얼마 전에 미국에서 조그만 컨설팅 회사를 다니는 후배가 나에게 기술적인 업무를 부탁했다. 한국계 클라이언트 회사에서 진행하는 프로젝트 일부를 맡아서 개발해주기로 했는데 실제적인 설계와 개발업무를 나더러 진행해 달라는 부탁이었다.
나로서는 주말시간을 투자하면 해줄 수 있는 일이었기 때문에 마다하지 않았다. 노는 시간을 활용해서 용돈을 벌자는 은밀한 동기부여도 물론 있었다.
그렇게 해서 시작된 프로젝트는 내게 말로만 들어오던 '어두운 세상'의 풍경을 생생하게 보여주는 '체험 삶의 현장'이 되어주었다. 20년 동안 개발업무를 진행해온 경험을 토대로 이야기하건대 비합리적이고 엉터리 같은 프로세스는 어디에나 존재한다. 처음부터 끝까지 한 번도 덜컹거리지 않으면서 조용한 물처럼 흘러가는 프로젝트는 존재하지 않는다는 이야기다.
그렇지만 문제는 비합리성의 수준이다. 덜컹거림에도 정도가 있다. 내가 최근에 겪은 일은 다분히 주관적인 경험이기 때문에 객관적이고 보편적인 방식으로 설명하기 쉽지 않다. 그렇지만 다른 개발자들이 현장에서 겪는 일과 맥이 통하는 부분이 없지 않으리라 생각했다.
우선 사용자의 요구사항을 담은 문서의 수준이다. 그 문서를 보았을 때 나는 너무 놀라서 눈물을 흘릴 뻔했다. 그것은 결코 요구사항 문서라고 불려서는 안 되는, '복사해서 붙여넣기'의 콜라주에 불과했다. 내가 잘 알고 있는 사실마저 흔들어서 헷갈리게 만들 정도의 위력을 가진 서사의 힘은 가브리엘 가르시아 마르케스가 와서 울고 갈 정도였다.
요구사항 문서는 프로젝트에 참여한 모든 사람들을 하나의 합의점으로 끌어당기는 커뮤니케이션 수단이다. 그 자체로는 목적이 아니다. 따라서 문서는 아름다울 필요가 없다. 다만 핵심적인 개념을 간결한 방식으로 표현하여 누가 보더라도 오해의 여지가 없어야 한다. 내가 보았던 문서는 이와 같은 문서의 조건을 완벽히 정반대되는 방식으로 구현하고 있었다.
시스템의 전체적인 그림을 크게 그려놓고 그에 수반되는 사항을 일목요연하게 정리한 아키텍처도 부재했다. 최종제품을 얼마나 많은 사용자가 사용할 것인지, 얼마나 많은 데이터가 발생하는지, 반응속도가 어느 정도로 빨라야 하는지, 보안수준은 어느 정도로 구현해야 하는지, 하드웨어 장비는 무엇을 쓸 것인지, 통신 프로토콜은 어떤 것으로 할 것인지, 플랫폼과 언어는 어떤 것으로 정할 것인지 등등. 아키텍처와 관련해서 연구하고 판단해야 하는 일들이 한두 가지가 아니지만, 그런 일들이 모두 '쓸모없는 일'로 치부되어 관심의 사각지대에 놓여 있었다.
나에게 가장 치명적인 부분은 비용과 관련된 것이었다. 후배의 부탁이었기 때문에 나는 실비만 받았다. 그것은 실제로 수행해야 하는 작업에 비하면 낮은 수준에 불과했다. ‘돈’ 때문에 하는 일이 아니었기에 개의치 않았지만 문제는 내가 하는 일의 범위가 늘어나고 있었다는 점이다.
처음에는 포함되어 있지 않았던 기능이 추가되고, 어떤 것은 복잡하게 변경되고 하더니, 정신을 차려보았을 때는 일의 범위가 처음에 생각했던 것에 비해서 거의 두 배로 확대되어 있었다. 내게 지불되는 비용은 물론 변하지 않았다.
뿐만 아니라 GUI-서버-데이터베이스의 구조에서 GUI 쪽의 일만 하기로 했던 최초의 계약이 어느덧 데이터베이스 작업까지 해야 하는 것으로 달라져 있었다.
내가 정식으로 문제제기를 하자 돌아오는 답변이 흥미로웠다. 클라이언트 회사에서 나온 사람들의 자유분방하고 파격적인 표현력은 탄복할만한 수준이었다. “어디서 실력도 없는 것이 끼어들어서 프로젝트를 망치고 있어.” “처음부터 하기로 했는데 왜 딴소리야.” 등등.
나야 하기 싫으면 언제든지 그만 둘 수 있는 프로젝트이므로 그런 말을 들어도 웃고 넘어 갈 수 있지만, 가족들을 위한 생업 속에서 이런 상황을 겪는 개발자들의 심정은 어떠할 것인가. 이러한 비합리성과 무례함을 내치지 못하고 꿀꺽 삼켜야 하는 사람들의 스트레스는 어떻게 달랠 것인가.
나는 이렇게 행동하는 사람들의 심리가 궁금했다. 그리고 그들이 사실은 매우 불안해하고 있음을 깨달았다. 그들은 분석, 아키텍처, 개발, 이런 것들이 도대체 무엇을 의미하는지 알지 못하기 때문에 손해를 볼까봐 몹시 두려워하고 있었다.
불안은 그들의 영혼을 잠식했고, 그들을 뻔뻔스럽게 만들었다. 뻔뻔해진 그들은 소프트웨어 개발 작업이 마치 누구나 할 수 있는 허접한 일인 것처럼 묘사하기 위해서 애를 썼다. 허접한 일이어야만 낮은 비용이 정당화되기 때문이다.
관련기사
- 개발자에게 야근은 미친 짓이다2014.02.26
- 액터 모델 프로그래밍 주목하라2014.02.26
- 폴리글랏 시대, 개발자를 위한 통섭의 메시지2014.02.26
- 카드정보 유출, 더 알아야할 불편한 진실2014.02.26
불안은 스스로 극복하는 것 말고 다른 방법이 없다. 불안에 휩싸여 있는 사람들에게 딱히 해줄 말도 없다. 다만 그들이 두려워해야 하는 것은, 그들의 날선 영혼이 진심으로 불안해해야 하는 것은, 자기가 볼지도 모르는 사소한 ‘손해가 아니라, (혹은 자신이 볼지도 모르는 알량한 ’이익‘이 아니라) 프로젝트의 총체적인 실패를 의미하는 ‘허접한 결과물’이라는 점을 지적하고 싶다.
그러한 실패를 이끌어내는 동력은, 프로젝트의 성공을 잠식하는 것은, 바로 그들의 불안이라는 점을 말이다.
*본 칼럼 내용은 본지 편집방향과 다를 수 있습니다.