2014년 5월 27일 화요일

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





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



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



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



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



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



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



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



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

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



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



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



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



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



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



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



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



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

글로벌 소프트웨어 회사의 필요조건과 특징



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



글로벌 소프트웨어 회사가 가져야 하는 조건은 무엇일까? 많은 필요조건을 늘어놓을 수 있다. 하지만 충분조건은 아니다. 성공할 모든 필요조건을 명시할 수 있다면 좋겠지만 회사의 성공여부를 가장 잘 예측하는 벤처투자가들도 확률이 10% 밖에 안된다. 하지만 그들은 안될 것 같은 회사들은 금방 가려낼 수 있다. 필요조건 중의 하나만 모자라면 투자하지 않는다. 투자를 할 이유를 찾는 것은 어렵지만 투자를 하지 않아야 할 이유를 찾는 것은 쉽다. 필자가 보는 관점은 영업, 재무, 기획역량이나 CEO의 비전 같은 것이 아니고 소프트웨어 회사의 심장인 개발역량의 관점에서만 본다. 개발 역량이 없으면 나머지가 다 있더라도 성공할 수 없다. 마찬가지 논리로 여기있는 개발역량 조건을 다 만족시킨다고 해서 충분조건은 아니기 떄문에 글로벌 개발역량을 보장하는 것은 아니다. 하지만 필자가 생각할 때 여기 있는 것 정도면 역량이 매우 높은 회사인 것은 분명하고 충분조건에 매우 가깝다고 볼 수 있다.



이 중의 일부분은 국내 회사중 단기간에 팔고 버리는 생명주기가 짧은 제품과 항상 최신 버전 하나만 유지해도 되는 포털서비스 같은 회사에서는 해당되지 않을 수도 있으나 특수한 경우일 뿐이고 제품 생명주기가 길고 여러 버전을 유지해야 하는 경우가 일반적인 경우라고 할 수 있다. 여기서는 글로벌 회사가 될 수 없는 조건들을 늘어 놓는 방식으로 적는다. 이 중에 하나라도 해당되면 글로벌 회사의 역량은 없다고 보면 된다.



  • 개발자가 재택 근무를 할 수 없다.

재택근무를 할 수 있다는 것은 많은 것이 준비되어 있다는 것을 의미한다. 개발자들이 재택근무를 한다고 시뮬레이션을 해보면 안되는 많은 이유를 발견할 수 있을 것이다. 그 안되는 것을 다 해결해야만 한다. 재택근무가 가능한 상태에서 회사가 어떤 근무정책을 선택하는 가는 아예 재택근무를 할 수 없는 상황과는 다르다.



  • * 개발자들을 계속 회의 한다고 불러 댄다

개발중인 개발자 들과 많은 얘기를 해야 한다는 것은 계획이 없다는 것을 뜻한다. 계획이 없으니 개발자들에게 심심하면 물어보아야 한다. 간식과 같이 궁금하면 불러댄다. 관리자나 기획팀이 주요 원인이다. 위의 재택근무를 할 수 없는 이유 중의 하나이기도 하다. 열정적인 회의가 열심히 일하는 모습으로 관리자가 착각할 지 모르나 이는 분석단계와 같이 많은 협업이 필요한 개발의 초기에만 나타나야 하는 모습이다.



  •  * 멘토가 시간을 많이 소비해서 가르쳐주지 않고는 신입사원이 일을 시작할 수 없다

사수가 가르쳐 주어야 일을 시작할 수 있다면 진퇴양난이다. 바쁜 사수가 시간을 낼 수도 없고 그렇다고 신입사원들을 놀게 내버려둘 수도 없다. 이 역시 모든 문제를 한 눈에 보여주는 확실한 증거이다. 글로벌 회사에서 이런 소리 하는 경우는 본 적이 없다.



  • * 제품 릴리스를 일 년에 세 번 이상 한다.

제품 릴리스를 자주 한다는 것을 고객서비스를 잘 한다고 착각하지 말아라. 일 년에 세 번의 릴리스면 필자의 경험으로 유지보수하느라 허덕대는 수준이다. 이 정도면 독약을 먹고 있는 것이다. 잦은 제품 릴리스는 상상도 할 수 없는 많은 문제를 가져온다. 초기에 조금이라도 많이 팔아야 생존해야 하는 회사가 빠져드는 달콤한 유혹이다. 장기적으로 살아남기 위해서는 고객에게 욕을 먹더라도 자주 릴리스를 하지 말아라. 그래서 회사가 망한다면 일찍 망하고 다른 일을 찾는 것이 현명하다.

  • * 백발이 성성한 개발자가 한 명도 없다.

SW 관련 외국 컨퍼런스를 가보면, 나이 지긋한 백발의 엔지니어를 만나는 것이 어렵지 않다. 지식은 경험을 통해 시간이 흐르면서 지혜와 통찰력으로 변화되어 간다. 이런 전문가가 없이 젊은 개발자들만을 데리고 일을 하겠다는 것은 젊은 군졸들이 전쟁을 하는 것과 같다. 전투는 하겠지만 전쟁에서 승리하기는 힘들다.



  •  * 지금 없어지면 제품 유지보수에 큰일 나는 개발자가 있다.

회사를 판단하는 방법 중의 하나가 '누가 중요한 개발자인가' 이다. 담당자가 퇴사해서 문제가 생겼습니다 라고 말하는 회사는 미래가 불안한 회사이다. 그런 개발자가 한두 명이 아닐 테니 지뢰 속에서 살고 있는 것이다. 우리 회사는 개발자가 나가도 유지보수에는 아무 문제 없습니다 라고 안심할 수 있어야 제대로 된 회사이다. 단 직원이 나가면 미래의 역량은 감소한다.



  •  * 시장에 나온 새로운 개발 도구는 다 가지고 있다.

돈 많은 대기업에서 주로 벌어지는 현상인데 도구 공부는 재미는 있지만 실력향상과는 관계가 없다. 골프채 많이 가지고 있는 사람이 골프 잘 치지 못한다. 소위 장비병은 아마추어들에게만 나타나는 병이다. 설령 도구의 차이가 있더라도 편하고 싼 평범한 도구를 잘 사용하는 것이 좋다. 회사 출퇴근 하는데 벤츠가 필요한 것이 아니고 그냥 조그만 자동차 하나 있으면 된다. 나머지는 실용성과는 관계없는 개발에 방해가 되는 과시용이다.



  • * 코드를 많이 복사해서 사용한다.

스포츠로 말하면 가장 기본인 달리기 체력이 없는 것이다. 필자가 10년 전에 출간한 책에서도 복사하지 말라고 샘플코드를 적어 놓은 적이 있는데 국내 개발자들은 아직도 변한 것이 없다. 10년 동안 변화가 없는 것을 보면 앞으로도 희망이 보이지 않는다. 코드 복사하는 이유는 빨리 개발해야 한다는 이유에서이다. 복사하고 난 다음 뒤치다꺼리는 생각하지도 못하는 근시안이다. 이 문제가 얼마나 심각한 것인지는 회사가 커지면 안다. 그 때까지는 뭐 큰일이라고 그러냐고 무시하다가 막상 당하게 되면 지금 치루는 비용의 10배, 100배의 비용을 치루게 될 것이다.



  • * 코딩하면서 예외 처리를 하지 않는다.

위의 코드 복사 문제와 비슷하지만 복사보다는 미래의 예상 피해도는 작다. 하지만 꼭 지켜야 하는 기초 체력중의 하나이다.



  • * 코딩을 각자 다 자기 스타일로 한다.

코딩 스타일의 표준화는 로마에 가면 로마법을 따라야 하는 현지법이다. 내 법이 옳다고 현지 법을 지키지 않는 다는 것은 관리가 안되는 오합지졸이며 불량배이다. 가독성이 생길 수가 없다. 빈 칸도 나중에는 못 고치는 게 잘 되는 회사에서 미래에 벌어지는 현상임을 깨닫는다면 표준화된 코딩의 중요성을 추측할 수 있다.



  •  * 어떤 개발자가 마지막 1 주일에 소스코드를 왜 몇 줄을 고쳤는지 모른다

소스코드관리시스템과 이슈관리시스템을 사용해야 하는 기본적인 목적이다. 열심히 일한다고 생각하는 개발자들이 의외로 엉터리인 경우가 많다. 누가 무엇을 왜 하는 지를 서로 아는 것이 투명성이다. 이 투명성이 없는 회사는 일정관리나 리스크관리를 할 수 없다. 그냥 서로 믿고 가다가 봉변 당하기 쉽다.



  • * 착한 개발자가 피해를 입는다

깨끗한 물과 더러운 물이 섞이면 깨끗한 물이 피해를 입는다. 한 편이 약속한 대로 하지 않을 경우에 지저분한 쪽보다는 깨끗한 쪽에서 수정하는 게 더 쉽기 때문에 제대로 개발한 사람에게 일이 더 많아진다. 일이 훨씬 많더라도 지저분한 쪽을 고치게 해야 한다. 아니면 그나마 남아있던 깨끗한 쪽도 다 사라질 것이다.



  •  * 보고하느라 시간을 많이 보낸다.

'이게 뭐예요?' 라고 물어 보면 '이슈관리시스템에 가서 보세요' 라고 말할 수 있다면 회사가 잘 돌아간다는 증거이다. 보고는 보고자의 주관적인 관점을 접하게 된다. 또 보고의 문제는 보고자료를 예쁘게 만드느라 시간을 낭비한다. 아마도 개발자가 파워포인트를 가장 많이 사용하는 나라가 한국일 것이다. 개발자들이 파워포인트를 만들 일이 없어야 한다. 보고라는 것은 정보가 공유가 되지 않았기 때문에 요구하는 것이다. 유비가 제갈량에게 보고하라고 하지 않는다. 항상 무슨 일을 하는지 알고 있기 때문이다. 보고해서 알게 된다면 사후 약방문이다. 국내회사에서 이슈관리시스템만 잘 사용해도 보고의 90%는 없어진다. 그리고 객관적인 정보를 여러 관점에서 항상 볼 수 있다.



  •  * 개발자가 휴가를 2주 갔다 올 시간이 없다.

'놀 수 없는 사람은 해고시킨다' 라는 말이 있다. 어떤 사람이 중요한 것과 대체 가능한 것과는 다르다. 대체가능하면서 중요한 개발자가 가장 중요한 개발자이다. 대체가능하지 않고 중요한 사람은 회사에 엄청난 위험성을 주는 사람이다. 유비나 제갈량 같이 CEO나 CTO 수준에서는 대체가 불가능하지만 개발자 수준에서는 그렇게 되면 안된다.



  • * 모든 결정에 ROI(투자대비효과)를 달라고 한다.

화사에서 결정을 하는 두가지 요소는 통찰력과 근거이다. 통찰력이 없이 근거만으로 움직이는 회사는 모든 일에 ROI를 가져오라고 한다. 통찰력 없는 CEO나 임원이 무지한 상태에서 책임을 피하려는 목적이 크다. 이런 회사는 개발자들이 일하기 피곤하고 얼마든지 조작된 ROI를 만드는 부작용이 생긴다.



  • * 다음에 개발할 제품이 무엇인지 모른다.

다음에 개발할 제품에 대한 정보가 없이 지금 제품을 개발하고 있다면 안개 속을 걷는 것과 같다. 아키텍처는 미래를 내다볼 수 있어야지 가치가 있다. 많은 재작업이 항상 벌어지는 원인이 되고 이랬다 저랬다 개발자들에게는 짜증나는 상황이 벌어진다.



  •  * 문서를 만들기는 하나 보지는 않는다.

보지 않는 문서가 만들어 지는 데는 여러가지 원인이 있으나 어떤 원인이든지 회사가 엄청난 비용을 낭비하고 있고 개발체계가 전혀 잡혀있지 않다는 것을 말해준다. 보지 않으려면 절대 만들지 않는 것이 좋다. 연습을 한다고 생각하면 큰 착각이다. 잘못된 연습은 잘못된 선입관과 잘못된 습관을 만들어 내니 아예 하지 않는 것이 잘못하는 것보다는 낫다.



  • * 물려줄 자산이 없다.

물려줄 자산이 있다는 것은 부자란 얘기이다. 부자의 #1 걱정은 상속이라고 한다. 상속을 걱정해보지 않은 사람은 금전적으로 부자가 아니라고 한다. 소프트웨어 회사의 자산은 튼튼한 소스코드이다. 대부분은 개발자 자신도 유지보수를 못하는 상태라 회사를 떠나고 나면 남은 사람들은 새로 개발하는 상황이 부지기수다. 다른 사람들에게 물려줄 자산이 없는 것이다. 부모의 상속 없이 자식이 새로 만들어서 자수성가한다는 것은 고생이다.



이런 많은 특징들이 글로벌 회사에서는 벌어지지 않는다. 사실 모두가 독립적인 것은 아니고 인과관계와 상관관계가 있기도 하지만 회사의 종류에 따라 우선순위는 다를 수 있다. 필자는 회사에 들어가서 보기 전에도 강연을 함으로써 그 회사의 역량을 알 수 있다. 강연의 주선부터 시작해서 강연을 마치고 강연비 지급이 완료되는 것까지가 강연의 생명주기이다. 잘 되어 있는 회사는 필자가 아무런 의문을 가질 필요도 없이 오직 강연준비만 잘하면 되게 만든다. 내가 이동해야 하는 모든 동선을 포함해서 강연장의 준비 등 전혀 걱정할 필요 없이 미리 얘기해 준다. 머리 속으로 시뮬레이션을 완벽하게 한다. 반대로 혼란스러운 회사는 내가 물어 보면서 내 살 길을 찾아야 한다. 가르쳐 주는 정보도 부실해 회사 안에서도 길을 헤매기도 한다. 강연의 내용에 집중할 시간에 다른 곳에 낭비하고 있으니 둘 다 피해이다.



좋은 식당과 나쁜 식당의 차이가 고객이 어떻게 행동할 지 모르는 식당이라고 한다. 새우튀김에서 머리를 먹는지 안 먹는지 애매모호한 경우가 있다. 새우 크기에 따라 다르고 튀긴 정도에 따라 다르다. '손님이 알아서 먹으세요' 라는 식당은 고급식당이 아니다. 생각할 필요가 없이 즐길 수 있게 만들어야 한다. 개발자도 개발에만 집중하고 나머지는 신경 쓸 필요 없게 만들어 주는 회사가 좋은 회사이다.



위에서 언급한 많은 실패의 특징 중에 대부분이 해당된다면 난감하다. 탈무드에서 두 개의 거짓말은 해도 된다고 했다. 물건을 이미 산 사람에게 잘 샀다고 얘기하는 것과 결혼한 남자에게 부인이 아름다워서 행복하게 살 것이라는 거짓말이다. 소프트웨어 회사에 컨설팅가서 이미 가능성이 없는 회사에는 얘기한다고 해도 도움이 안되니 그냥 잘한다고 말해준다. 발전 가능성이 있는 회사에서는 이런저런 점을 개선해야 한다고 말한다. 즉 축구 동호회에 가서는 축구 잘한다고 칭찬하지만, 국가대표팀에 가서는 그 따위로 축구해서 무슨 월드컵에 나가냐고 얘기하는 것이다. 그러니 나중에라도 필자의 말을 믿지 말고 스스로 판단하기 바란다. 어떻게 고치는지에 대한 방법은 책 여러 권이 필요할 정도의 방대한 내용이니 먼저 의지가 생긴 다음에 생각해야 할 일이다.

구글이 원하는 개발자 - 문제 해결 역량




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



2년전 쯤에 구글에 취직한 한국 개발자가 자기가 경험한 면접과정을 기사화 한 적이 있다. 한국하고는 다르니까 신기한 경험이었을지 모르지만 미국 소프트웨어 회사들의 공통된 얘기였다. 만약에 개발자로서 실리콘밸리에 취직하려고 한다면 국내 회사에 취직하는 것과는 다른 준비를 해야 한다. 어쩌면 준비할 것이 없을 지도 모른다. 마지막 순간에 쪽집게 공부로는 준비할 수 없는 것이다. 자신의 모든 진실한 역량이 드러나기 때문이다.



필자가 미국 대학교에서 과목을 들을 때도 마땅히 시험 준비를 위해 특별히 공부할 필요가 없는 경우가 많았다. 마지막에 잠깐 공부하고 운이 좋으면 점수가 좋게 나온다는 것은 진정한 실력도 아니고 그런 식의 시험문제가 나오지도 않는다. 그래서 어떤 시험은 일주일 시간주고 집에서 해오는 경우도 많다. 학생 입장에서는 진이 빠지는 경우이다. 답이 하나가 아니고 생각하는 방법에 따라 문제 자체가 달라지고 학생마다 답도 물론 다르다. 그래서 베낄 수도 없고 비슷하게 흉내 낼 수도 없다.



회사 인터뷰를 보자. 개발자의 경우 하루정도 인터뷰 한다. 한국에서는 여러 명의 면접관이 한 명의 지원자를 앉혀 놓고 여러가지 질문을 하며 동시에 관찰을 한다. 필자는 이런 식으로는 평가를 제대로 할 수 없기 때문에 이런 방식을 좋아하지 않는다. 미국은 일대일로 면접을 진행한다. 지원자로서는 한국에서는 한 시간 정도의 인터뷰만 잘 넘기면 된다. 아주 편하다. 미국은 그게 안된다. 면접관 한 사람 당 40-50분 정도 하루종일 인터뷰를 한다. 그래도 잘 판단이 안되면 다시 부른다. 면접관은 위 아래 개발자들이 골고루 섞여 있다. 대부분 점심도 같이 한다. 점심도 지원자를 판단하기 위한 중요한 부분이다. 성격의 많은 부분을 볼 수 있다. 하지만 개발자를 뽑는 것이기 때문에 역시 핵심은 개발 역량이다. 어차피 미국은 다양한 인종이 살기 때문에 성격이 다 독특할 수 밖에 없기 때문에 진짜 이상한 경우만 아니면 문제가 되지 않는다.



인터뷰의 핵심은 문제 해결 능력이다. 문제를 전개하고 정의하고 협의하고 풀어나가는 능력이다. 필자가 한국에서 개인적으로 인터뷰할 기회가 생기면 "숫자 3개를 정렬" 하는 문제를 낸다. 아무 질문없이 문제를 그대로 풀어오면 빵점이다. 문제 자체를 정의하지도 않은 상태에서 자기 멋대로 풀어온 것이다. 이런 스타일의 개발자는 회사에서 가장 큰 문제아다. 언제 어디서 무슨 짓을 저지를지 모르는 동키호테이다. 지원자가 문제를 미리 알고 있다고 해도 아무 상관 없다. 어차피 일 년 동안 풀어도 못푸는 문제이기 때문이다. 지금까지 이 문제에서 필자의 기준에 합격한 국내 개발자는 거의 없었다. 어차피 국내에서는 실리콘밸리 수준의 문제 해결 능력을 가지고 있기가 어렵기 때문에 기대하지도 않는다. 기준에 모자라더라도 그 중에서 상대적으로 나은 개발자를 뽑을 수 밖에 없다. 이 문제를 풀 때 프로그래밍 언어는 상관하지 않는다. 시험에서 연필로 쓰나 볼펜으로 쓰나 상관하지 않는 것이나 같다. 언어 프로그래밍 능력은 금방 배울 수 있는 것이기 때문이다. 객체지향을 이해하는 것이 중요한 것이지 C++이나 Java 같은 언어를 잘 알아야 하는 것은 아니다.



먼저 국내 개발자들의 예를 보자. 그냥 3개 숫자 정렬하는 소스코드를 막 쓰기 시작한다. 물론 자기가 가장 자신있는 프로그래밍 언어를 사용한다. 나를 어떻게 생각하는 지 모르겠는데 내가 그걸 몰라서 풀어보라고 할 리는 없다. 즉 물어보는 사람의 의도를 파악해 보려는 생각은 하지도 않고 늘 정해진 문제를 풀 듯이 그냥 알고리듬 생각해 내기에 바쁘다. 숫자 3개 정렬하는 알고리듬이 복잡해야 얼마나 복잡하겠는가? 삼척동자도 다 아는 것이다. 바로 국내 교육의 병폐가 여기서 확연히 드러나는 것이다. 필자는 국내 회사에 가서 개발자들과 일을 할 때도 이런 문제가 보통 심각한 문제가 아니라는 것을 느낀다.

문제를 해결하기 위해 필요한 전제조건이 문제를 찾아내고 정확히 정의하는 능력이다. 이 능력은 학원가서 배울 수 있는 것도 아니고 주입식 위주의 교육 환경에서 쌓여온 무의식의 축적이기 때문에 장기적인 교육환경의 변화를 필요로 한다. 하여튼 국내 교육의 결과로 그런 능력은 없다 치고 알고리듬이라도 제대로 쓰면 가장 기본적인 논리력은 인정해 준다. 그런데 이것도 헤매지 않고 적어내는 사람도 많지 않다.

필자가 풀라고 한 "3개 숫자의 정렬"이란 문장으로서 문제가 확실히 정의되었다고 보는가? 아직도 그렇게 생각한다면 국내 소프트웨어 업계가 성숙하지 않았다는 구체적인 증거이다. 그럼 실리콘밸리의 회사의 인터뷰에서 벌어지는 대화를 시뮬레이션 해보자.

면접관: 숫자 3개 정렬하는 문제를 풀어보세요
지원자: 숫자 3개만 정렬할 것인가요? 4개, 5개, 혹은 많은 숫자를 정렬할 필요가 있나요?
면접관: 나중에는 숫자가 늘어날 겁니다.
지원자: 오름차 순, 내림차 순을 선택할 필요가 있나요?
면접관: 예
지원자: 숫자가 정수인가요, 실수인가요?
면점관: 두 가지를 다 사용합니다.
지원자: 정수일 경우 최대와 최소범위가 무엇인지요?
면접관: 최대가 큽니다. 30자리 숫자 입니다. 최고는 마이너스로 10자리 정도 됩니다.
지원자: 실수일 경우는 어떤가요?
면접관: 소수점 이하 20자리 까지 정확해야 합니다.
지원자: 이 프로그램이 독립적인 프로그램인가요? Function으로 제공해야 합니까?
면접자: 둘 다 필요합니다.
지원자: 어떤 응용프로그램이 사용하려고 하는 건가요?
면접관: 우주 관제 센터에서 사용할 것입니다.
지원자: 이 프로그램을 사용할 운영환경이 무엇입니까?
면접자: IBM 메인프레임 입니다.
지원자: 이 프로그램을 얼마나 자주 호출합니까?
면접자: 1초에 1억번 정도 호출됩니다.
지원자: 속도 때문에 소숫점 20자리를 계산하기는 불가능 할 것 같습니다.
면접자: 메모리는 충분히 늘릴 수 있으니까 어떤 알고리듬을 써야 속도가 가장 빠를까요?
지원자: 일단은 O(N log N) 인 알고리듬이 빠르겠지만 정렬해야 하는 숫자가 천 개, 만 개가 될 것이 아니라면 별 차이는 없으니까 중요한 것은 Function을 부를 때 숫자가 30자리나 되니까 parameter로 넘기지 말고 pointer로 넘기거나 Global 변수로 접근 하는 것이 어떨까요?
면접관: 그렇게 하면 객체지형적인 측면에서 어떤 문제가 있을까요?
.............



지금까지 보았지만 이 문제 정의는 아직 끝나려면 멀었다. 이런 대화가 1시간을 진행된다고 생각해 보자. 지원자가 가지고 있는 모든 지식이 나타난다. 국내 개발자들에게 풀라고 하면 그냥 답 적어내겠다고 하는 것과는 워낙 접근 방법이 다르니 비교할 수 조차 없다. 이런 인터뷰를 여러 명하고 하루 종일 하면 실력이 다 드러난다. 다른 면접관하고 얘기를 하면 또 완전히 다른 방향으로 간다. 그래서 문제를 안다고 해도 미리 공부해 갈 수도 없다. 사실은 대화 중에 면접관도 많은 것을 배운다. 지원자에게 많이 배울수록 감동받고 "저 사람은 꼭 고용해야 합니다" 라는 평가서를 적을 것이다. 이런 상호존중이 바로 회사에서 가장 중요한 것이다. 그룹으로 협업하면서 문제를 해결하는 능력인 것이다. 실리콘밸리의 개발자들은 이런 식의 사고방식이 익숙해져 있기 때문에 추상적인 문제가 주어져도 협업하면서 구체적으로 정의하며 문제를 해결해 나간다. 어차피 벼락치기 한다고 인터뷰 준비가 될 것도 아니기 때문에 평소 실력으로 편안하게 인터뷰에 임하면 된다.



이런 인터뷰 과정을 거쳐 입사를 하게 되면 한국 회사에서는 상상도 하지 못할 일이 다음날 벌어진다. 실제 업무를 하는 것이다. 교육은 없다. 필자가 대학 졸업 때부터 많은 미국 회사를 다녔지만 교육을 시킨 회사는 하나도 없었다. 그 다음날 부터 일을 시키는 것이다. 문제 해결 능력이 있는 사람들을 뽑았다면 당연히 자기가 해결해야 할 문제를 발견하고 정의하고 해결할 수가 있어야 한다. 물론 그러기 위한 기본적인 기반시스템은 갖추고 있어야 하는 것은 회사의 책임이다. 국내회사는 이런 기본 시스템도 갖추고 있지 않은 것이 산 넘어 산이다. 또 다른 방대한 주제이므로 여기서는 넘어간다. 그래서 국내 소프트웨어 개발자들의 화려한 이력서가 아무런 의미가 없다. 사상누각인 것이다. 대부분의 이력서에는 많은 프로그래밍 언어, 플랫폼, 방법론, UML같은 도구를 자랑스럽게 적어 놓는다. 미국 회사 인터뷰때는 그런 것은 별로 보지도 않는다. 다 보조적인 도구에 불과한 것 뿐이지 소프트웨어 개발자로서의 역량과는 거의 상관관계가 없다.



참고로 한국의 개발자가 구글에서 경험했다는 인터뷰 질문은 다음과 같으니 자신이 얼마나 깊이 많은 관점에서 대화를 할 수 있을까를 한 번 시물레이션 해보기 바란다. 그냥 정답을 내려고 하는 접근 방법으로는 아마 100% 불합격할 것이다.

* integer operation으로 log를 구현하려면 어떻게 하는가? 이 경우 총 연산의 수는?

*두 개의 sort된 행렬을 merge하려면 어떻게 하는가? 이 경우 complexity는 어떻게 되는가?

* C++ class의 static variable은 어떤 의미가 있고 어떻게 쓰이는가?



인터뷰 질문에서 보듯이 문제의 깊이와 다양한 관점을 가지기에는 경험도 필요하다. 그런 이유로 미국 회사에서는 젊은 개발자도 많지만 젊은 개발자가 쫓아 갈 수 없는 백발이 성성한 개발자의 역량이 존재한다. 그래서 실리콘밸리에는 60세된 개발자가 흔하고 회사의 핵심 역량이기도 하다. 실제 회사를 대표하는 기술 회의에 나가면 백발의 개발자가 나오는 경우가 많다.



문제 해결 역량은 교육부터 시작해서 기초를 배우고 제대로 된 회사에서 협업하며 경험을 함으로써 쌓여가는 것이다. 혼자서 열심히 프로그램 한다고 길러지는 역량이 아니다. 국내 교육기관도 변해야 하고 국내 기업문화도 빨리 답을 재촉하는 것보다 여러 관점에서 다양하게 생각할 기회를 주는 것이 결국은 좋은 품질의 제품을 가장 빨리 만드는 지름길이다. 이것이 바로 제1원인인 분석능력인 것이다.