개발자의 커뮤니케이션이란 무엇인가?

저서 "글로벌 소프트웨어를 말하다"의 31장



회사를 컨설팅하다 보면 가장 많이 듣는 소리가 “개발자들은 커뮤니케이션을 못한다” 라고 한다. 그러고는 소위 훌륭한 경영자는 개발자들의 커뮤니케이션을 향상시키기 위해 커뮤니케이션 전문 컨설팅을 받는다. 불행이도 그런 커뮤니케이션 스킬은 개발자들을 목표로 한 것이 아니다. 실리콘밸리의 회사에서 아침에 와서 묵묵히 하루 종일 자기 사무실에 앉아서 한 번도 나오지 않고 일하고 있는 개발자는 커뮤니케이션이 전혀 없는가? 재택근무 하면서 일주일에 한 번만 회사에 나와서 잠깐 회의하고 가는 개발자는 커뮤니케이션을 충분히 하지 않고 있는 것인가?  모두 틀렸다. 그들은 아주 커뮤니케이션을 잘 하고 있다. 영업사원이 하는 종류의 커뮤니케이션을 하지 않고 있을 뿐이다.



개발자들의 커뮤니케이션의 목적은 무엇인가?  개방, 협업, 공유이다. 그럼 아무도 안 만나고 어떻게 개방, 협업, 공유를 한단 말인가? 만나서 하는 것은 개방, 협업, 공유가 아니라 개방, 협업, 공유를 하기 위한 준비작업을 하는 것이다.



개방, 협업, 공유가 효율적으로 일하는 가장 좋은 방법이며 자신의 스킬을 향상시키는 가장 좋은 방법이다. 선배한테만 배우는 것이 아니라 동료한테서도 배우고 후배한테서도 배우는 것이 있다. 이 세상에 혼자서 배워서 프로가 될 수 있는 것은 없다. 있다면 얘기해 주기 바란다. 천재 골퍼인 타이거 우즈도 스승이 없었던 적이 한 번도 없었고 천재 김연아도 항상 코치가 필요하다. 그런데 무슨 베짱으로 소프트웨어를 혼자 할 수 있다고 하는 지 모르겠다. 개방, 협업, 공유를 하지 않으므로써 얻는 장점은 오직 한가지이다. 자기만 아는 비밀로 얻는 직업의 안정성(Job Safety)이다. 소위 영업 사원들이 “Red Book” 이라고 자기의 비밀고객명부를 혼자만 가지고 있는 것이다. 개발자도 그런 안전 장치인 비밀정보를 가질 수 있다면 일단 단기적인 안전성은 확보한 것이다. 실제로 국내 소프트웨어 회사에서는 많은 개발자가 자신만의 비밀정보를 만들어 다른 사람이 쉽게 파악하지 못하는 안정권에 들어가는데 성공했다. 실리콘밸리에서는 비밀정보가 되기 위한 경계를 넘기기가 불가능하다. 그러기 전에 아마 해고 당할 것이다. 비밀임계치를 넘기지 못하도록 만드는 것이 회사의 책임이다.



그런 공유와 개방를 강제화 하는 것이 것이 바로 기반 시스템과 프로세스이다. 하지만 공유와 개방은 했지만 아직도 협업은 완성되지 않은 상태로 남아 있다. 개방과 공유를 해도 협업이 없으면 지식이 미완성된 상태로 남는다. 협업은 개인들의 자발적인 노력이 받쳐주어야 한다. 회의에서 아무런 말도 하지 않고 다른 사람을 도와주려고 하는 마음이 없으면 협업은 되지 않는다. 그래서 아무리 강제로 개방과 공유를 해도 남과 협업해서 일을 하려고 하지 않으면 개방과 공유의 효과가 반감된다.



여기서는 개발자의 핵심 역량인 개방과 공유를 하기 위한 커뮤니케이션이 무엇인지 알아보기 쉽도록 통상적으로 생각하는 커뮤니케이션 방법과 개발자들의 커뮤니케이션 방법을 비교해서 보자.



 말을 잘 한다  <-> 문서를 잘 만든다.



개발자는 말을 잘할 필요가 없다. 말을 잘하는 것 대신에 조용히 문서를 잘 만들면 된다. 말은 오래 기억되지 않는다. 그리고 오해의 소지가 많다. 회의가 끝난 다음에 회의록을 적어보내면 틀렸다고 하는 경우가 많다. 개발하려는 제품의 사양을 말로 할 필요가 없다. 문서로 적고 다 검토하게 요청하면 된다. 개발자가 말을 하는 경우는 분석이나 설계의 검토회의나 코드리뷰를 할 때이다. 그 외에는 업무상 말로 할 이슈가 거의 없다.

협상을 잘 한다  <-> 정확하게 명시한다



개발자는 일단 무엇을 왜, 언제, 어떻게 하는지를 정확하게 명시하는 것이 핵심이고 그건 개발자들이 가장 잘 할 수 있는 것이다. 영업이나 고객등 다른 부서와의 협상은 관리자나 소수의 분석가의 담당이다. 정확한 정보를 관리자와 분석가에게 입력하는 것이 개발자들의 책임이다. 개발자들이 직접 협상하러 나가면 대부분 싸우고 망친다. 개발자로서 협상의 기술까지 가지고 있으면 좋지만 기본이 자신만의 로직으로 작동하는 개발자의 특성상 모순에 가깝다.



사수가 가르친다 <-> 멘토가 가이드 한다.



둘 다 선배한테서 뭔가 배운다는 입장은 똑 같은데 무엇이 차이인가? 국내회사에서 사수한테 배운다고 하지만 사실은 모순투성이이다. 사수라고 하면 일단 고급 개발자인데 사수가 바쁘지 않다면 회사가 인력관리를 잘 못하는 것이고 바쁘다면 가르쳐 줄 시간이 없는 것이다. 대부분의 회사는 사수가 가르쳐 줄 시간이 없어 말만 사수지 결국은 혼자서 고생하면서 겨우 배워 간다. 사실 사수도 조수한테 잘 가르쳐줘서 금방 자기를 따라잡으면 불안하기도 할 테고 시간도 없으니 많은 시간 내서 가르쳐 줄 수도 없다. 결국 사수는 인간의 본능으로 보나 회사에서의 우선순위로 보나 조수를 제대로 가르쳐 준다는 것은 기대하기 어렵다. 그럼 실리콘밸리에서 새로운 회사를 들어가면 아무것도 모르는 상태에서 멘토가 정해지는 데 무엇을 배울까? 멘토가 하는 일은 거의 없다. 어디에 어떤 정보가 있나를 가르쳐 주는 것이 멘토의 일이다. 그런 것을 가르쳐 주는데는 하루에 5분이면 된다. 즉 이슈관리시스템의 IP 주소가 이거다. 설계문서의 위치는 소스관리시스템의 어느 디렉토리에 있다. 이런 것들이다. 그 다음부터는 다 알아서 공부하고 일을 할 수가 있다. 이게 바로 멘토와 멘티의 커뮤니케이션인 것이다. 가내 수공업처럼 사수가 가르쳐 줄 때까지 노예처럼 살 필요가 없다. 이런 커뮤니케이션이 가능하게 된 것은 기반시스템과 문서가 이미 다 준비되어 있기 때문에 가능한 것이다. 이 두가지가 준비되어 있지 않다면 국내처럼 사수만을 바라보며 기다리는 수 밖에 없다. 사실은 항상 사수가 더 실력이 좋다고 할 수는 없다. 가지고 있는 정보의 폐쇄성에 의해 단기간 가짜 실력의 우위를 누리기도 하지만 장기적으로는 별 것도 아닌 것으로 들통나기도 한다.



회의를 자주 한다  <-> 재택근무 한다



국내 소프트웨어 회사와 실리콘밸리 회사의 개발자와의 하루 일과 중에 가장 다른 것이 이것이다. 국내 회사에서는 과장 정도 되는 지위만 오르면 회의하느라 하루 종일 뛰어 다닌다. 과장이면 이제 조금 개발을 알 정도의 경험인데 개발은 물 건너가고 회의만 한다. 반면에 실리콘밸리에서는 회의는 일주일에 한 번이나 와서 잠깐 하는 것이고 집에서 일할 수도 있다. 집에서 일한다고 정보가 단절 된 것이 아니고 회의를 많이하는 국내 회사보다도 더 많은 정보를 기반시스템을 통해 공유한다. 그러니까 회의를 할 필요도 없이 모든 사람이 공유할 수 있는 지식인 것이다. 정보의 공유가 아니라 어떤 심각한 결정을 해야 하는 경우가 되어야 일주일에 한번 회의하면 된다. 자잘한 결정들은 이미 기반시스템을 통해 서로 다 대화하고 이미 다 결정했다. 만나서 하는 비 효율적인 회의를 할 필요가 별로 없는 것이다. 그래서 국내 회사에는 회의실이 항상 모자란다. 그것도 낭비다. 회의실을 늘리면 늘리는 대로 그래도 모자란다. 아무리 늘려도 사용하고자 하는 사람은 끝이 없다. 처음부터 근본적으로 잘못된 것이다.



보고를 자주 한다  <-> 보고는 기반시스템을 본다



필자가 컨설팅을 하면서 가장 듣기 싫어하는 말이 바로 “보고하러 간다” 이다. 사람을 앞에 놓고 말을 들어보는 것이 중요한 경우가 가끔 있겠지만 시시때때로 보고하러 간다. 실리콘밸리에서는 어떤 때는 주간 회의를 빼 놓고는 거의 보고하러 갈 필요가 없다. 그 이유는 보고해야 될 자료가 다 기반시스템이나 저장소에 있기 때문이다. 그것도 훨씬 더 보기 좋은 형태로 되어 있기 때문에 누구를 오라고 할 필요가 없다. 그러는 것이 시간이 더 걸리고 보고하는 사람이 만들어 온 자료는 그 사람의 관점 밖에 보지 못한다. 다른 관점에서 보고 싶을 때 다른 자료를 또 만들어서 다시 보고해야 한다. 예를 들어 새 버전을 출시하기 위해서 버그를 고쳐야 하는데 지금 몇 개나 남아 있고, 누가 몇 개를 고쳤고, 지금 일이 밀려있는 개발자가 누구고, 어느 컴포넌트가 할 일이 제일 많은지 등등 물어볼 수 있는 관점이 수십개 혹은 수백개는 된다. 이슈관리시스템에서 그냥 누구나 보면 다 있는 정보인데 와서 보고하라고 하면 보고자가 자기의 관점에서 자료를 만들어 와서 보고한다. 그래서 필자는 컨설팅 하면서 상관이 보고하라고 하면 상관 컴퓨터에 가서 이슈관리시스템을 놓고 같이 보면서 질문에 따라 다 보여주라고 한다. 보고서 만드느라 시간 들이고 종이 낭비한다. 실리콘밸리의 경우는 자신이 직접 훨씬 더 잘 볼 수 있는데 아예 그런 보고를 요구할 리가 없다. 회사 컨설팅을 할 때 사장님들에게 이슈관리시스템을 사용하는 것이 훨씬 더 많은 정보를 정확하게 볼 수 있으니까 버튼 몇 번만 누르시면 됩니다 라고 얘기해도 듣지 않는다. 그래서 회의와 보고에 끌려다니다 보니 고급개발자는 영원히 개발 실무에서 멀어지게 된다. 인재의 손실이다.



개발자의 커뮤니케이션을 일반 커뮤니케이션과 혼동하면 안된다. 인간 관계를 소홀히 하는 개발자도 있다. 하지만 기본적으로 정보의 공유가 개발자의 커뮤니케이션의 핵심이기 때문에 기반시스템을 얼마나 잘 사용하고 문서를 얼마나 정확히 적느냐가 중요하다. 인간관계로 영업을 할 때나 연봉협상을 유리하게 하려면 협상의 스킬이기 때문에 말을 잘해야 한다. 그래서 일반 커뮤니케이션도 잘하면 나쁘지는 않다. 단 기본적인 개발자 커뮤니케이션을 소홀히 하면 안된다.