무서운 개발자

최근 몇 년 사이에 읽은 개발자와 관련한 여러 책에서 개발자에 대한 이미지를 읽을 수 있었다. 오래 전에 나온 책에서 언급하는 개발자와 달리 최근의 책은 개발자 자신의 숨겨진 이면을 솔직하게 말하고 있는 경우가 많다. 개발자의 과거 이미지에는 어떤 코드를 스스로 창조하는 열정적인 모습으로 자주 묘사되곤 했지만 최근 발간된 책에서는 대개의 개발자가 그렇지 않음을 말하기도 한다. 애자일이나 XP 프로그래밍과 관련한 책에서 흔히 "뛰어난 개발자 한 명이 18명의 평범한 개발자보다 낫다"고 말하곤 하는데 이것은 프로그래밍이 창조적인 작업임을 말하고 있다. 그러나 관점을 조금 바꿔서 생각해보면 현재 우리 회사에서 18 명의 그저 그런 별로 창조적이지 않은 개발자가 일하고 있다고 볼 수도 있다. 그리고 또 다른 개발자들의 숨겨진 이야기가 "무서운 개발자"에 대한 것이다. 어떤 개발자들은 이렇게 말하거나 혹은 자신도 그럴 수 있다고 믿는다,

고객이나 상사들은 대체로 좀 멍청해. 그들에게 설명을 해 봐야 못 알아 들어. 고객이 내 코드를 읽을 수 없지. 내가 고객이나 상사를 처단할 수는 없지만 그들을 굉장히 힘들게 만들 수는 있어. 물론 내가 일부러 그랬다고 그들이 알 가능성이 없도록 말이야.

이 글을 읽는 사람이 개발자라면 여러분을 향해 이야기하는 것은 아니고 여러분 곁에 있는 또 다른 개발자를 향해 하는 이야기라고 생각하기 바란다. 이 이야기에 자신을 투영할 필요는 없다. 나는 모든 개발자가 예비 범죄자라고 말할 생각은 없다. 여기 내가 경험한 한 가지 사례를 이야기하겠다. 



요새를 구축한 개발자

7년 전 쯤 한 회사에 외부 컨설턴트로 신규 웹 서비스 기획에 관여하게 되었다. 일주일에 두 세번 정도 회사를 방문해서 기획에 대해 검토하고 새로운 아이디어를 토론하는 역할이었다. 나는 새로운 웹 서비스의 초기부터 기획자와 개발자가 함께 참여하는 것을 좋아하는 편이라 고객사 사장에게 회의에 늘 개발자를 참석 시키도록 요청했다. 그러나 다음 번 회의에도 개발자는 회의에 오지 않았고 그 다음에도 오지 않았다. 의아해서 사장에게 왜 개발자나 개발팀장이 참석하지 않느냐고 물었다. 그는 개발팀에서 기획이 완료되지 않은 상태에서 할 이야기가 없다고 대답했다고 전했다. 나는 사장에게 왜 서비스 초기 기획부터 개발자가 참석하는 게 좋은 지 설명하고 다시 참석을 요청했다.

그러나 그 다음 회의에도 개발자나 팀장은 참석하지 않았다. 나는 좀 화가 나서 사장에게 "회사의 신규 웹 서비스에 개발자가 참석하지 않는다면 개발을 외부 업체에게 맡길 생각이냐?"고 말했다. 그러자 사장이 기다렸다는 듯 "혹시 추천할 업체가 있느냐?"고 대답했다. 내부에 자체적으로 웹 서비스를 개발할 수 있는 인력이 있는 걸로 알았는데 오히려 사장이 외부 개발 업체를 요청하니 무슨 일이 있는 듯 했다. 나는 굳은 얼굴로 물었다, "혹시 개발팀과 무슨 문제가 있는가?" 역시 그랬다.

이 회사의 사장은 사업 개발과 마케팅을 주로 했던 사람이었다. 사업 개발과 고객사 영업 능력은 뛰어났지만 개발과 관련한 지식은 일반인보다 조금 나은 수준이었고, 스스로 개발을 해 본 경험은 전혀 없었다. 그에게 프로그래밍 코드는 고대 히랍어보다 더 이해하기 힘든 그저 문자열일 뿐이었다. 그리고 개발팀은 그와 우연한 인연으로 만난 팀장이 채용한 사람으로 꾸려져 있었고 지난 2년 간 조직 구성과 시스템 운영 또한 순전히 개발팀장의 요구에 의해 이뤄진 상태였다. 사장이 새로운 물량를 수주해 와서 개발팀장과 회의를 하는 광경을 본 적이 있다. 회의는 참 희안하게 이뤄지고 있었다. 사장은 일에 대해 설명하고 있었고 개발팀장은 골치아프다는 표정으로 왜 그 일이 지금 바로 처리하기 힘든 지 이야기했다. 회의는 설득과 거부로 이어지고 있었고 결국 다음 주말은 되야 새로운 일에 대한 일정을 알려 줄 수 있다는 개발팀장의 선포로 끝났다.

이런 상황이니 새로운 웹 서비스를 자체적으로 개발하려고 하는 사장의 의도와 지금 하는 일도 많은데 '돈도 안되는' 새로운 웹 서비스를 맡아야 하는 개발팀장이 충돌할 수 밖에 없다. 그런 이유로 결국 사장의 회의 참석 요청에도 불구하고 고의적으로 이런 저런 이유를 대며 개발팀장 혹은 개발자가 회의에 참석하지 않는 상황이 반복된 것이었다. 나는 이런 상황이라면 새로운 웹 서비스를 개발하는 게 불가능하다고 판단했다. 게다가 새로운 웹 서비스는 회사의 신규 사업이기 때문에 외부 업체에게 개발을 맡기는 것은 의미가 없었다. 나는 사장에게 뭔가 제안하기 전에 개발팀의 현황을 일주일 정도 조사했다. 그들이 하는 일을 조심스럽게 관찰했고, 출퇴근 시간과 업무 시간 중 하는 일을 살펴 보았다. 개발팀장을 비롯한 개발팀 전원을 비공식적으로 인터뷰하고 그들이 가진 불만을 들었다. 그리고 또 며칠 동안 다른 부서가 개발팀에 대해 생각하는 바도 들었다.
 
2주일 정도가 지난 후 나는 사장과 30분 정도 진지한 이야기를 나눴다. 사장은 내 제안을 이해하는 듯 했다. 그러나 나는 분명히 문제가 발생할 것이고 그 문제는 어쩌면 치명적일 수도 있다고 말했다. 그런 위험을 받아 들일 수 있다면 최선을 다해 돕겠다고 말했다. 그 날 저녁 나는 사장으로부터 짧은 메시지를 하나 받았다, "그렇게 하자". 그 다음 주 개발팀장은 해고 되었고, 개발팀은 해체되었다. 이후 3개월 간 개발팀은 인사관리팀 소속에 있었고 개발팀 인원 중 절반 정도가 다시 해고되었고 새로운 인력이 보충되었다. 나는 그 일이 끝난 후 2개월만에 새로운 웹 서비스를 완성할 수 있었다. 


고객을 두렵게 하는 개발자

지금도 당시의 기억을 이야기하는데 불편하다. 어떤 이유든 간에 나는 어떤 사람들의 직장을 잃게 만들었다. 그게 회사에게는 이익이었더라도 또한 내가 해야 할 일이었더라도 결코 즐거운 기억은 아니다. 그럼에도 불구하고 당시의 선택이나 판단이 틀렸다고 생각하지 않는다. 왜냐면 당시 그 개발자들은 가장 나쁜 개발자들이었기 때문이다. 가장 나쁜 개발자는 개발 능력이 떨어지는 개발자도 아니고, 오류 코드를 잔뜩 생산하는 개발자도 아니고, 말 안듣는 개발자도 아니다. 가장 나쁜 개발자는 고객을 두렵게 하는 개발자다. 고객은 다른 회사나 상사를 말한다. 

대개의 고객은 개발자가 무엇을 하고 있는 지 잘 모른다. 몇 시간을 컴퓨터 앞에 붙어 있는 지 관찰할 수는 있지만 정작 개발을 하고 있는 건지 일이 얼마나 진행되고 있는 건지, 또한 개발되어 나온 산출물이 얼마나 정확하게 작동하는 지 잘 모른다. 개발자가 상세하고 친절하게 설명하지 않으면 대개의 고객은 그저 무지의 상태에 있을 뿐이다. 무지 상태의 고객은 두려움을 느끼게 된다. 앞으로 일이 어떻게 돌아갈 지 알 수 없는데 그걸 팔아야 하고 그걸로 무엇을 해야 하기 때문이다. 그런데 개발자는 퉁명스럽게 대답할 뿐이고 그나마 대답도 상세하지 않다. 고객의 두려움은 더욱 커진다. 

개발자들 사이에서 이런 이야기가 있다, "가장 힘쎈 개발자는 가장 바닥에 있는 개발자다. 누구도 그들에게 뭔가를 요구하지 않고 그래서 내 마음대로 할 수 있지." 그래서 어떤 회사의 어떤 개발자들은 그런 상황을 충분히 이해하며 적절히 응용한다. 마치 자신만의 요새를 구축하는 것처럼. 물론 그리 나쁘지 않은 의도로 요새를 구축하는 경우도 있다. 개념없는 상사나 고객으로부터 자신의 공간을 지키기 위해 요새를 구축할 수도 있다. 어떤 의미에서 그런 요새는 개발자 특유의 독립적 환경을 보존시키는 역할을 하기도 한다. 그러나 그건 오래된 구습이다. 더 이상 토론하지 않고 개방하지 않는 개발자를 반기는 조직은 없다. 특별히 뛰어난 능력의 개발자조차 이제는 고객에게 자신이 하는 일을 설명할 수 있어야 하고 설명해야 할 의무가 있다. 입 다물고 멋진 코드만 생산하고 자신이 내킬 때만 말하는 개발자는 고객을 두렵게 하는 개발자이며 그런 개발자는 결국 스스로 나쁜 길을 걷고 있는 셈이다. 게다가 말하지 않는 개발자가 멋진 코드를 생산할 가능성은 점점 적어지고 있다. 더 이상 세상은 혹은 이 업계에서 개발자 혼자 생산할 수 있는 코드를 요구하지 않고 있기 때문이다.