한국의 엔지니어들을 위한 입문서? 자기계발서? 나는 엔지니어가 아니다. 하지만 회사를 다니는 동안 겪은 개발 관련 프로젝트는 네 번 정도. 물론 엔지니어가 아니니 현업에서 맡은 역할은 테스터와 장기적으로 보면 프로젝트의 결과물인 프로그램 사용자라고 할 수 있겠다. 그럼에도 구분하자면 엔지니어들을 위한 이 책을 읽을 수밖에 없었던 나름대로 절박했던 이유는 그들을 이해하고 싶어서였다. 그러니까 이 책의 아주 일부만 취득했다고 볼 수 있다. 무엇을? 개발자들의 심리를. 이 책은 크게 4가지 개발 프로젝트 사례를 통해 '소프트웨어의 이해, 개발팀, 개발 조직, 그리고 개발자 개인의 특성'에 대해서 이야기하고 있다. 따라서 용도와는 다른 접근이 되었지만, 엔지니어와 함께 살아가야 하는 이들에게도 이 책은 꽤 유용한 선택이다.

지금이야 새삼스럽지도 않지만, 개발자들과 소통하려고 꽤나 노력하던 시기에 한 개발자로부터 충격적인 '고백'을 들었던 적이 있다. "개발이 불가능한 것은 없다. 단지 시간, 비용, 그리고 엔지니어의 실력 차이만 존재할 뿐이다." 심한 배신감이 느껴졌다. 순진하게도 불가능하다는 답변이 돌아온 요청에 대해서 열심히 다른 기획과 방안을 모색했었으니까. 하지만 덕분에 커뮤니케이션의 한계와 그 속에 숨은 함정을 깨달았다. 때로 귀찮아서, 힘들어서, 어려워서 '불가능합니다' 라는 답변을 던질 수 있다는 것을. 물론 모든 개발자와 프로젝트를 단순하게 매도할 생각은 없다. 하지만 그 뒤로 개발 회의를 할 때 결정적인 한 방이 필요하거나 협의의 난관에 부딪히면 무기로 사용하게 됐다. "절대절대 불가능하다는 말씀입니까?" 라고 던지면 즉답으로 그렇다고 고개를 끄덕이는 (나쁜)개발자는 다행히 아직 만나보지 못했다. 그리고 그 뒤로 협의의 접점을 찾기가 한결 수월해졌다. 좀 이상한 경험이었지만, 이를 통해 커뮤니케이션의 한 방법을 찾았다고 볼 수 있다. (무턱대고 다 통하지는 않는다. 이 또한 함정.)

개발팀에 수많은 요구와 요청, 부탁을 하면서 쌓인 노하우는 요구사항에 대한 개발자의 답변의 측정할 수 있는 눈치 정도랄까. 참 지질하고 슬픈 현실이지만 어쩔 수 없다. 그들과 산뜻한 공존이 가능했더라면 이 책을 읽지도 않았을 일이다. 그러니까 불행하게도 미리 짐작해서 가능할 것 같은 요청만 하게 된 것이다. 아니면 전쟁을 치를 각오를 하던가. 하지만 이는 개발자들에게 더욱 심각하고 슬픈 현실이다. 부록으로 실린 '또 다른 SW 엔지니어의 변' 인터뷰를 읽으면 개발자들에게는 크게 놀라운 일도 아니겠지만, 고객 그러니까 사용자들은 '이 정도였어?'라는 충격을 받을 수도 있겠다.

(본문) “프리랜서나 외부업체에서 온 개발자들이 개발 완료되었음을 보고하고 프로젝트에서 빠졌는데 나중에 보니 프로그램에 버튼을 누르면 마치 데이터베이스에 들어가 값을 가져오는 것처럼 보이게만 프로그램을 작성한 것이다. 이렇게 심하게 속이지 않더라도 오류를 잡지 않거나 로직을 일부 빼고 프로그램을 제출하는 경우는 부지기수로 많다. 이런 개발자가 프로젝트 중간에 나가게 되면 남은 개발자들이 그 프로그램을 재작성해야 하는 이중 부담을 지게 된다. 개발자가 무엇을 하고 있는지 알 수 없다는 것이 프로젝트 관리의 큰 구멍이다.” --- p.67

이 책은 깜짝 놀랄 정도로 이 세계의 폐단과 자성의 고백들을 꽤나 솔직하게 밝히고 있다. 본문의 대부분은 개발자들을 위해 다양한 프로젝트를 통해 성공한 사례와 실패의 원인 등을 짚어가면서 혹독한 현장의 생생한 기록들이 이어진다. 추리소설의 범인이 밝혀진 것도 아닌데 읽으면서 '어머'를 연발하며 무릎을 쳐댔다. 드라마틱한 사례도 있고, 실제 사례인가 싶을 정도로 황당한 실패(그것도 초대형 프로젝트)는 스릴러처럼 조마조마하게 읽힌다. 개발자도 아닌데 내가 왜 이러지 하는 그 순간, 이해의 벽을 넘을 수 있다. 특히 Chapter 2와 3을 통해 들여다본 현장은 이들에게도 팀워크, 그리고 조직의 불합리한 구조에 대한 고민은 똑같구나 하는 동조가 일어난다. 엔지니어의 글이기에 관련 용어로 풀어 썼지만, 크게 어렵지도 않다.

불행하게도 새로운 문제가 생겼다. 이해의 벽은 넘었지만 '이해'만 하게 됐다는 것이다. 직업을 엔지니어로 전환할 것도 아니고, 앞으로도 사용자로서 나는 그들의 말을 더욱 검증하려 들 것이고, 확인하려 할 것이다. 더욱 매의 눈으로 지켜봐야 하는 내 처지가. '인간, 조직, 권력 그리고 어느 SW 사용자의 변' - 으로 이름 붙여서 고백하자면, 사용자로서 한 발 양보할 수 있었던 기능에 대해서 고집을 피운 적이 있다는 것 정도. 앞으로 개발자는 사용자의 이런 패턴을 알아가는 것이 관리의 한 방법이라고 할 수 있겠다. 싸우자는 것은 아니고.