실리콘밸리에서 20년 글로벌 소프트웨어 회사에서의 경험과 한국에서의 20년 정부,학계,산업계를 컨설팅한 경험을 바탕으로 소프트웨어 업계가 필요로 하는 "소프트웨어 지혜"를 얘기합니다. 기사는 제한없이 퍼가셔도 됩니다.
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원인인 분석능력인 것이다.
인재가 중요한가, 시스템이 중요한가?
저서 "글로벌 소프트웨어를 말하다"의 18장
부처님의 가르침의 방법에서 천재들에게는 규율을 강조하지 않았다. 많은 고승들의 경우에 술도 마시고 고기도 먹고 규율에 전혀 구애받지 않았다. 하지만 일반 대중들에게는 오계, 십계와 같은 규율을 지키게 했다. 소프트웨어도 천재들의 경우에는 시스템이 없어도 일할 수 있다. 하지만 보통 사람들은 시스템의 도움 없이 일한다는 것은 불가능하다. 이렇게 인재와 시스템은 독립적인 실체가 아니고 둘 사이에는 상관관계가 존재한다.
인재도 당연히 한 종류가 아니고 다양한 종류의 인재가 있다. 기업교육 전문기업 휴넷이 발표한 7가지 인재형을 보자.
1. 위기와 변화에 강한 인재
2. 가시적이고 단기적 성과를 내는 인재
3. 글로벌 이슈에 밝은 인재
4. 조직적인 리더십을 갖춘 인재
5. 인문학적 소양을 갖춘 인재
6. 스마트워킹 등 유연한 실무능력을 갖춘 인재
7. 끊임없이 학습하는 인재이다
인재의 종류에 따라 교육해야 하는 것이 다르고 또 성장경로가 다를 수 밖에 없다.
그럼 시스템의 종류는 무엇이 있는가? 아래 그림에서 보자. 많은 시스템들이 있다. 모든 회사에 공통된 시스템도 있고 소프트웨어 회사에 특화된 시스템도 있다. 모든 회사가 모든 시스템이 필요한 것은 아니다. 벤처 회사는 한 두개의 시스템으로 시작해서 글로벌 대기업이 되면서는 많은 시스템이 필요하게 된다. 중간 규모의 회사는 자기에 맞게 적절히 시용해야 한다. 여기에 표준되는 답은 없다. 소프트웨어 회사도 모두 다르기 때문에 일률적으로 정할 수는 없다. 마치 살림살이를 마련해 가는 것과 같다. 혼자 살 때와 신혼 때가 다르고 가족이 생기면서 또 다르다. 사는 장소에 따라 다르고 모든 사람의 살림살이가 다르다.
경험의 법칙(Rule of Thumb)은 ‘시스템은 비타민처럼 사용하라’ 라고 말한다. 필요할 때 필요한 양만큼만 사용해야 한다. 미리 앞서서 사용해도 안되고, 모자라도 안되고, 과도하게 사용해도 안된다. 사람에 따라 섭취해야 하는 비타민 종류도 달라지고 먹는 양도 달라져야 한다. 즉 회사에서는 인재의 역량에 따라 사용해야 하는 시스템 종류가 달라지는 것이다. 모짜르트 같은 천재들에게 형식을 맞추라고 하는 것은 비효율적이다. 그렇다고 아무한테나 자유를 주는 것은 더 큰 문제다. 통상적인 소프트웨어 회사의 성장 경로에서 보면 순서적으로 소스관리시스템, 이슈관리시스템, 빌드시스템, 테스트 관리시스템, 프로젝트 관리시스템 같은 정도로 중요하다. 하지만 하나의 정답은 없다. 필자가 가장 많이 본 오답은 지식관리시스템(KMS)이다. 필요의 원인을 잘못 생각하기도 하고 방법을 모르기도 해서 필요 없는 KMS를 설치하는 경우를 많이 보았다. 물론 컨설팅업체나 판매업체들은 항상 미사여구를 동원한다. 속지 않는 것이 역량이다. 잘못 설치된 시스템은 두고두고 괴롭힌다. 설치해 놓았으니 강제로 사용하게 규칙을 만든다. 그리고 합리화를 한다. 그러다 보면 악순환이 계속되어 비효율성만 커진다. 그래서 시스템은 잘 모르면 빨리 설치하는 것보다 천천히 심사숙고 하는 것이 안전하다. 독약인지 약인지 모를 때는 먹지 말라.
위에서 말한 7가지 인재 중에 ‘가시적이고 단기적 성과를 내는 인재’가 많은 회사와 ‘조직적인 리더십을 갖춘 인재’가 많은 회사와는 사용해야 하는 시스템이 다르다. 체계적인 관리시스템을 도입할 지 안할 지의 결정이 달라질 수 있다. 시스템은 사람이 할 수 없는 부분을 보충해서 시너지 효과를 낼 수 있게 사용하는 것이기 때문에 회사마다 다르게 사용해야 한다. 한의학에서도 사람마다 사상체질이 다르기 때문에 먹어야 하는 음식도 다르고 약도 다르다.
모든 시스템은 돈도 들지만 항상 비효율성이라는 간접비용을 유발한다. 회사의 직원 역량 수준이 낮으면 시스템이 해야 할 일이 더 많아 진다. 비효율성이 더 발생할 수 밖에 없지만 회사로서는 최선이다. 반대로 천재들에게 시스템의 제약 아래서 움직이게 만든다면 재능의 낭비이다. 구글이나 삼성이 시용한다고 우리도 똑같이 했다가는 100% 망한다. 회사의 규모도 다르고 인재의 역량도 다르고 만드는 제품이 다르다. 순수 소프트웨어를 만드는 회사와 임베디드 시스템을 만드는 회사는 시용하는 시스템이 다르다. 회사의 역량을 최대로 높이기 위해서는 인력의 역량을 잘 파악하고 조화롭게 사용하기 위한 다양한 시스템 사용 전략이 필요하다.
개발과정의 여기저기에서 체크리스트를 사용하는 회사들을 많이 본다. 얼마나 답답했으면 지식 산업이라는 소프트웨어에서 체크리스트를 사용할까 이해는 가지만 다시 생각해 볼 일이다. 체크리스트는 시스템을 안전하게 움직이기 위해 사용하는 극단적인 방법이다. 예를 들어 아침에 출근해서 시스템이 작동하고 있나를 항목 하나씩 체크하면서 확인한다. 마치 능력 없는 의사가 생각 없이 많은 검사에 의존하는 것과 같다. 그런 방식은 최소 한도의 확인은 할 수 있지만 예외가 생긴 경우에 대응을 할 수 없다. 원리를 이해하고 응용 능력이 뛰어난 사람은 어떤 경우에도 대응할 수 있기 때문에 체크리스트 같은 것이 필요 없다. 체크리스트는 초급 인력들이 방향을 잡지 못하는 경우에 한 걸음씩 나갈 수 있도록 길을 정해 버린 것이다. 체크리스트가 많은 회사는 스스로 역량이 낮다는 것을 인정하는 것이다. 같은 맥락으로 세세한 내용의 템플릿이나 프로세스를 많이 가지고 있는 회사도 마찬가지이다.
사지선다형에 익숙한 사람과 주관식 문제에 익숙한 사람과는 가져야 하는 시스템이 다르다. 또 할 수 있는 일의 종류도 다르다. 다 나름대로 쓸 데가 있다. 위의 그림 중에 소프트웨어 공학도구라는 부분이 있는데 설계가 잘 되어 있는지 체크리스트를 이용해서 평가하는 방법도 있고 스펙을 적기 위해 항목을 하나씩 채워 가는 도구도 있다. 이런 체크리스트 기반의 시스템들은 다 최하 수준의 인력들을 기준으로 만든 시스템들이다. 자신이 존경 받기를 원한다면 개나 소나 할 수 있는 체크리스트 시스템이나 템플릿 위주의 개발은 지양해야 한다. 지식 산업이라는 것을 다시 한번 명심하기 바란다.
사회에는 여러 종류의 사람이 필요하듯이 회사에도 여러 종류의 사람들이 필요하다. 유일하게 회사에 필요 없는 인력은 자신이 옳다고 시스템을 무시하고 회사의 규칙을 따르지 않는 사람이다. 설령 경영진의 착오에 의해 잘못된 시스템이 설치되더라도 악법도 법이니 고치기 전까지는 일단은 따라야 한다. 준법정신은 미래에 개선을 하기 위해 매우 중요한 문화이다. 정말 싫다면 불량아로 남아 있지 말고 회사를 떠나면 된다. 시스템을 무시하고 각자 자기 생각대로 한다면 미래에 개선도 할 수 없는 최악의 무정부상태가 된다.
인력과 시스템은 서로 보충적인 관계이다. 훌륭한 인재는 시스템이 덜 중요하지 않지만 초급 인력은 시스템의 도움을 많이 받아야 한다. 작은 회사에서는 인력이 시스템보다 더 중요하다. 큰 회사에서는 인력과 시스템이 다 같이 중요하다. 아무리 인재들이 모여 있다고 해도 시스템이 없이 천재 몇 명이 비행기나 항공모함을 만들 수는 없다. 반대로 작은 회사에서 시스템을 많이 사용하는 것은 부작용이 더 크다. 보트 만드는데 항공모함 만드는 시스템은 비효율적이다. 어설프게 대기업을 따라 하는 것은 실패의 지름길이다. 그러나 글로벌 회사로 성장하기 위해서는 시스템도 필수이므로 빠르지도 않고 늦지도 않은 적절한 시점에 하나씩 적용해 가야 한다.
하드웨어와 소프트웨어는 같고나서 다르다
저서 "글로벌 소프트웨어를 말하다"의 4장
‘하드웨어와 소프트웨어는 다르다’는 말을 많이 듣는다. 필자의 경험으로 보면 이 말이 나오는 거의 모든 경우가 소프트웨어가 하드웨어와 다르니 내 맘대로 하고 싶을 때 대는 핑계이다. 필자는 강연시에 이 질문에 대해 실리콘밸리에서와 국내에서 답이 달라진다고 말한다.
먼저 ‘사람과 동물이 같은가?’ 하는 질문을 생각해 보자. 사람과 동물은 둘 다 생물이고 언젠가는 죽는다는 점에서 같다. 하지만 사람과 동물도 역시 다르다. 일단 염색체가 다르다. 그럼 염색체가 같은 모든 사람은 같은가? 역시 각 사람마다 다르다. 즉 ‘같다 다르다’에 대한 답을 하기 위해서는 어느 수준에서 판단하는가를 얘기해야 한다. 필자가 생각하는 ‘같다, 다르다’의 수준을 얘기하면 하드웨어와 소프트웨어는 ‘같은 인간이면서 사용하는 언어가 다른 나라의 사람’이다. 그 만큼 가깝다는 것이다.
우리나라에서는 하드웨어와 소프트웨어가 마치 사람과 식물정도의 차이처럼 아예 상관 없는 식으로 얘기한다. 또 그러다가 가끔 사용하는 정책을 보면 소프트웨어에 적용해서는 안되는 하드웨어 특성의 정책을 사용하기도 한다. 아직 하드웨어와 소프트웨어의 본질을 이해하지 못하기 때문에 따라해서는 안 될 일을 하기도 하고, 꼭 따라해야 할 일을 안하기도 한다.. 그럼 과연 어떤 것이 공통된 속성이고 어떤 점이 다른 속성인지를 살펴보자. 하드웨어의 다양한 종류인 건축공학, 기계공학, 전자공학, 심지어는 양복점과도 비교를 해보자. 소프트웨어 공학에서 사용하는 용어는 대부분 건축공학에서 왔다. 하지만 개념은 기계공학이나 전기공학 심지어는 옷을 만드는 양복점에서도 같다. 가장 일반적인 개발방식인 분석, 설계, 구현, 테스팅, 유지보수의 생명주기에서 봤을 때 똑같다. 물론 구현 단계에서 사용하는 방법이 다르다. 설계에서도 다른 도구를 사용한다. 즉 인간이 생각하는 방식은 같지만 나라에 따라 언어가 다른 것과 같다.
근본적으로 소프트웨어 개발방식은 건축에서 유래되었는데 다른 산업도 마찬가지이지만 많은 시간을 분석과 설계에 시간을 보내고 또 가치를 둔다. 고급 인력들은 다 분석과 설계에 집중된다. 그리고 구현 단계는 건축에서는 시공이라는 단계로 전혀 다른 인력들이 투입된다. 이런 개념이 건축공학이며 기계공학이며 전자공학이다. 심지어는 양복점도 분석과 설계를 하고 마지막 재단 작업은 아무나 할 수 있는 일이기에 외주를 준다. 그러니까 대량생산은 아예 북한이나 중국 등 인건비가 저렴한 나라에서 하면 된다. 즉, 앞 단계의 핵심 지식 작업과 뒤로 가면서 노동집약적인 일을 분명히 나누고 가장 효율적인 방법으로 구현한다.
모든 산업이 그렇게 돌아가는 데 유일하게 그렇지 않은 경우가 바로 국내의 소프트웨어 산업이다. 국내 소프트웨어 업계는 내가 아니면 못한다는 엄청난 착각아래 한 사람이 시작에서 끝까지 다 만들어 낸다. 그러면서 하는 말이 소프트웨어는 하드웨어와 달라서 그렇게 하는 거라고 합리화를 한다.
여기에서 생각해야 할 점이 두 가지가 있다. 의지와 역량의 문제이다. 일인 만능주의 개념에 대한 잘못된 착각으로 인한 변화 의지의 부족이 첫 번째이고, 착각에서 깨어났다고 하더라도 수행할 수 있는 역량이 있는가가 두 번째이다. 깨닫기는 했는데 역량이 없다면 공허한 깨달음이다. ‘닭이 먼저인가 달걀이 먼저인가’ 하는 문제인데 결국은 동시에 해결해야 하는 문제이다.
여기까지가 소프트웨어와 하드웨어가 같은 부분이다. 즉, 하드웨어 산업과 같은 개념을 가지고 수행하기까지가 소프트웨어 개발 역량의 90% 정도 차지한다. 나머지 다른 10%는 벽돌공 대신에 개발자를 사용하는 것이다. 물론 벽돌공도 아무나 못하듯이 개발자도 나름대로 배운 것이 있어야 한다. 그런 인력들도 필요하기 때문에 정부에서 양성한다고 해도 나쁠 것이 없다. 그런데 개발자(벽돌공)를 사용하기 위해서는 그 앞 단계에서 분석과 설계를 잘 해야 하는 것이 필수이다. 다른 모든 산업과 비교해서 생각해 보면 이해가 갈 것이다. 누가 필자에게 ‘소프트웨어나 하드웨어나 똑같다’고 얘기한다면 나는 일단 존경하는 느낌으로 쳐다 볼 것이다. 다르다고 얘기한다면 의심의 눈초리를 보낼 것이다. 달인 아니면 초보인데 3분만 얘기해 보면 정체를 판단할 수 있다. 거의 예외 없이 초보자로 판명난다.
건축공학에서 배울 것은 안 배우고(앞 단계의 핵심 지식 작업과 뒤로 가면서 노동집약적인 일울 분명히 나누고 가장 효율적인 방법으로 구현하는 일) 소위 공사판 십장질만 배워서 소프트웨어에서 사용하려고 한다. 노동집약 산업의 핵심인 인부들을 관리하는 법만 배워서 그걸 지식 산업의 핵심 부분인 분석과 설계 단계부터 시작해 소프트웨어 개발의 전 공정에서 써먹으려고 한다. 아무리 세계적인 프로젝트 관리시스템을 사용해도 잘 될리가 없다. 돈만 낭비한다. 사실 건설산업의 시공단계에서 사용하는 가장 정교한 프로젝트 관리 시스템을 사용할 필요도 없는 곳이 소프트웨어이다. 이 주제는 또 다른 큰 주제이므로 여기서는 넘어간다.
소프트웨어와 하드웨어는 같기도 하고 다르기도 하다. 소프트웨어의 역사가 계속되고 성숙해지면서 다른 모든 산업들과 마찬가지로 수렴과 발산의 역사를 되풀이하게 될 것이다. 지금 국내는 최초의 수렴을 위해 나아가고 있다. 최초 수렴이 끝나면 '하드웨어와 소프트웨어는 같다'는 말을 의미심장하게 할 수 있다. 그 다음은 발산을 할 것이다. 그러면 '다르다'는 말을 할 수 있다. 조금 더 깨달으면 다시 '같다'라고 말할 것이다. 실리콘밸리의 회사들이 국내 회사들보다는 분명히 앞서 있고 최초의 수렴은 하드웨어의 좋은 점을 받아들여 소프트웨어 공학이 정립되면서 이미 오래 전에 끝났다. 이제는 발산단계로서 소프트웨어 고유 특성들을 찾아서 많은 기술이 나오고 있지만 언젠가는 모든 산업의 공통점을 찾아 서로 응용하면서 다음 단계의 수렴을 하게 될 것이다. 모든 진리는 하나로 통한다는 말을 이해하지 못하더라도 지금은 최초의 수렴을 위해 열심히 하드웨어의 좋은 점을 배워 체득한다면 글로벌 회사가 되기 위한 기초 체력을 마련한 것이다.
2014년 5월 6일 화요일
컴파일러가 안 가르쳐 주지?
프로그램을 제대로 개발하려면 너무 세세히 신경쓸 일이 많다. 그러니까 대충 가정하며 하게 된다. 이거야 당연히 이렇게 될 테지 하는 거 말이다. 그 중에 모든 사람이 저지르는 잘못이 변수를 당연히 null이 아니라고 가정하고 사용하는 것이다. 누구의 코드를 봐도 이런 잘못을 쉽게 발견할 수 있다.
예를 들어 보자.
int[] priceArray = getPriceList(); int sum = 0; for (int i=0; i< priceArray.length. i++) { sum = sum + priceArray[i]; }
이 얼마나 간단한 코드인가. 보통 경우 문제없이 구동 될 것이다. 아마 운이 좋으면 평생 뭐가 잘못된 지를 발견 못할지도 모른다. 문제는 priceArray가 null 포인터가 될지도 모른다는 것이다. Null 포인터가 되면 priceArray.length 에서 NullPointException이 발생하고 프로그램이 작동 중지될 것이다. 왜 이것이 컴파일은 문제없이 되고 구동시에만 문제가 되는지 모르는 사람도 많다. 보통은 Exception이 발생하는 경우에 처리하는 코드가 없으면 컴파일러가 친절하게 가르쳐 주지 않던가? 처리하는 코드를 추가하라고.
이것은 소위 RuntimeException 이라고 컴파일할 당시에는 오류를 발견할 수 없는 경우다. 실제 구동 할때만 발생할 수 있는 경우다. 아직도 Exception을 사용해 본적이 없거나 RuntimeException이 무엇인지 몰랐다면 지금 당장 책을 보고 배우라. 당신은 지금까지 엉터리 프로그램을 하고 있었던 것이다. NullPointException 이외에도 ArrayIndexOutOfBoundsException 같은 것도 흔히 보는 RuntimeException이다.
여러분이 프로그램을 구동하다가 NullPointException 이나 ArrayIndexOutOfBoundsException 이 한번이라도 발생했다면 믿을 수 없는 코드이다. 당장 가서 코드를 고쳐야 한다. 발생한 곳만 고치는 것이 아니라 전체 소스코드를 처음부터 끝까지 한줄 한줄 코드를 보면서 비슷한 오류를 범했는지 확인해야 한다.
그러면 어떻게 해야 옳은 프로그램인가? 여러가지 방법이 있는데 두 가지만 보여주겠다.
(첫째 방법)
int[] priceArray = getPriceList(); int sum = 0; if (priceArray != null) { for (int i=0; i< priceArray.length. i++) { sum = sum + priceArray[i]; } }
(둘째 방법)
int[] priceArray = getPriceList(); int sum = 0; try { for (int i=0; i< priceArray.length. i++) { sum = sum + priceArray[i]; } } catch (NullPointException e) { e.printStackTrace(); // 어떻게 처리할지 코드를 여기에 삽입한다. }
여기서도 역시 되는 기능보다는 항상 잘못될 경우를 처리하는데 더 신경을 곤두세우고 있다는 것을 명심하기 바란다. 되게 만드는 것보다는 안되는 경우를 처리하는데 몇배의 시간이 들어간다.
한줄 코딩 잘못이 1000배 느려진다.
한 줄 코딩 잘못이 1000배 느려진다. 무어의 법칙이라는 게 있다. 1965년 미국의 과학자 고든 무어는 '반도체 칩의 정보 기억량은 18~24개월 단위로 2배씩 증가하지만 가격은 변하지 않는다'라는 이론을 내 놓았다. 인텔 CPU의 경우 대충 맞아 떨어졌다. 우리는 PC가 구매후 2-3년 지나면 느리다고 새 PC로 교체한다. 약 두배 정도의 성능차이일 것이다. 내가 1980년 초에 IBM PC가 처음에 나왔을 때 64K 메모리에 하드디스크도 없고 360K 용량 플로피디스크로 사용하곤 했었다. 지금 보면 장난감이다. 지금까지 보면 무어의 법칙이 대충 맞아 떨어진다. 하드웨어에서는 성능상 큰 변화를 찾아보기 힘들다. 일년 사이에 열배가 변하겠는가? 백배가 변하겠는가 ?
DB에 관한 프로젝트를 하고 있었다. 큰 데이터를 로드시키는 프로그램을 팀원이 개발 했는데 너무 느린 것이었다. 조그만 데이터는 별 차이가 없는데 데이터가 커지면서 기하급수적으로 느려지는 것이었다. 한번 로드하고 테스트하는데 거의 하루가 걸리게 생겼다. 중간에 한번 잘못하면 그냥 하루를 손해본다. 한사람의 하루가 아니라 프로젝트종료가 하루가 지연되는 것이다. 컴퓨터가 성능이 안 좋으니 CPU빠르고 메모리 큰 것을 사용해야 하지 않겠느냐고 한다. 그러면 두세배는 향상될 것이다. 그러나 해결책은 아니었다. 그래서 내가 일단 소스코드를 분석해 보기로 했다. 자바코드였는데 다음과 같은 부분이 있었다. 자바를 모르더라도 프로그래밍을 해본 사람들은 금방 이해할 수 있을 것이다.
String str = “”; while (…) { ... String message = getMessage(); str = str + message; ... } return str;
이 보다는 훨씬 긴 프로그램이지만 관계 없는 부분은 생략했다. “while” 은 수만번정도 구동된다. 무엇이 문제이었을까? 운영체제나 컴파일러 같은 이론적인 배경이 없는 사람이면 찾기 힘든 문제일 수도 있다. 문제는 str + message 를 실행하기 위해서 str을 memory에 복사하게 되는데 수만번 도는 while 루프에서 str이 점점 길어지면서 memory에 복사하는데 많은 시간이 걸리는 것이었다. 이 문제를 해결하기 위해 다음과 같이 바꾸었다.
StringBuffer str = “”; while (…) { ... String message = getMessage(); str = str.append(message); ... } return str.toString;
여기서는 str.append(message)는 것을 사용하는데 이것은 memory에 복사를 하는 것이 아니라 기존의 String 뒤에 message를 붙이게 된다. 복사하는 과정이 없는 것이다. 이 한 줄을 이해 못함으로써 기하급수적으로 성능이 저하되는 것이다.
지금 경우처럼 심각하게 현상이 나타나면 문제점을 발견하고 해결책을 찾겠지만 만약 10배정도만 성능저하가 되었더라도 그런가 보다 하고 무시하고 넘어갔을 것이다. 컴퓨터 좋은 것 사달라고 할 것이다. 바보는 항상 남의 탓만 한다는 말도 있다. 잘못은 자기한테 있는데 엉뚱한데서 잘못을 찾는다. 이러한 무시되어서는 안 되는 문제가 수도 없이 존재하는 것이 현실이다. 내가 다른 사람이 쓴 소스코드를 보면 수많은 문제점을 즉시 찾아 낼 수 있다.
프로그램과 도박과 골프
도박을 해보면 그 사람의 진짜 인간성을 알 수 있다고 한다. 골프도 마찬가지다. 그런데 프로그램도 또 그렇다. 세가지 다 모두 인간이 받는 유혹을 뿌리치기 힘들다는데 있다. 도박은 인간의 물질에 대한 욕심을 적나라하게 보여준다. 액수가 크고 작고를 막론하고 도박에 들어가면 자기 성격을 감추기가 힘들다. 치사한 사람, 속이는 사람, 무모한 사람, 허풍치는 사람, 너무 솔직한 사람등 성격이 그대로 나타난다. 나는 한국에서 대학생활의 많은 시간을 포카 같은 카드게임 하는데 보냈다. 오락시설도 많지 않았던 시절 카드게임이 어떻게 보면 지금의 PC게임 같은 것이었다. 한번 시작하면 끝내기도 힘들다. 돈 잃은 사람이 끝내려고 하지 않으니까.
반면에 골프는 어떻게 보면 혼자의 게임이다. 다른 사람이 바로 옆에서 지켜 볼 때도 있지만 대부분이 혼자서 치게 된다. 골프는 신사 운동이라고도 한다. 서로가 자발적으로 신사답게 룰을 지켜가면서 해야 한다는 것이다. 그런데 룰이라는 것이 아무도 안보는 곳에서 나 혼자 룰을 꼭 지키기는 웬 만큼 소신 있고 정직한 사람이 아니면 쉽지 않다. 나는 나 스스로 룰을 잘 따르는 사람이라고 생각한다. 하지만 나도 편의상 룰을 안 지킨다. 밤 늦게 집에 갈 때 건너야 하는 길이 있다. 밤에는 교통량도 없고 한적하다. 신호등 있는 횡단보도로 가려면 200미터이상 우회하게 된다. 그래서 그냥 무단횡단 한다. 속으로 생각은 아무한테도 피해를 안 주는데 어떠냐는 생각이다. 물론 이게 잘못된 생각인 것이다. 내 마음대로 해석하는 것이다. 죄를 지었을 때 합리화하는 것은 인간의 본능이다. 아주 어려운 자기 양심과의 싸움이다. 한편에서는 잘못된 행동에 대한 합리화추구를 끊임없이 하고 다른 한편에서는 남들이 보면 창피한데 하는 양심에 거리낌을 동시에 느끼면서.
다시 골프로 돌아와서 골프를 하다 보면 많은 경우에 아무도 모르게 이익을 볼 수 있는 경우가 많다. 슬쩍 공을 몇 센티만 옮겨 놓으면 타구가 훨씬 쉬워질 수 있다. 특히 내기라도 할 경우에는 이 얼마나 큰 유혹인가. 그런데 완전범죄가 없듯이 이상하게도 다른 사람이 그런 행동을 하는 것을 언젠가는 알게 된다. 당사자들은 지금도 완전범죄를 저질렀다고 생각할 것이다. 아무도 그런 것을 일부러 지적해서 말을 해주지 않으니까. 모른 척 그냥 넘어가고 다시 같이 안치면 그만이지 그걸 뭘 민망하게 지적해서 인간관계 나빠지게 해. 다 이렇게 그냥 넘어간다. 그런데 고의가 아니고 룰의 해석을 다르게 해서 오해를 살 수가 있다. 실제 그런 경우가 많다. 옛 속담에 선비는 배나무 밑에서는 갓 끈을 고쳐매지 않는다고 했다. 룰에 의해 공을 유리한 자리로 옮길 수 있어도 혹시 다른 사람이 오해할까 해서 그냥 손해보고 말지 하는 정직하다 못해 고지식한 사람도 있다. 골프룰은 하도 많아서 다 아는 사람은 거의 없다. 워낙 많은 룰이 있으니까 모르고 실수하는 사람도 많다. 잘 모를 때 자기에게 유리하게 해석하는 사람도 있고 불리하게 해석하는 사람도 있다.
프로그래밍은 어떤가. 가끔 모여서 회의를 하기도 하지만 많은 시간을 혼자서 프로그램하는 데 보낸다. 혼자서 자유롭게 자기의 능력을 펼칠 수 있는 많은 자유시간이 주어진다. 물론 마감시간도 주어지고. 학교에서 아무리 작은 프로그래밍 숙제를 주어도 결과가 다 다르다. 모두가 정답이라도 다를 수 있다. 그래서 프로그래밍은 예술에 가깝다. 많은 부분이 창조적이어야 한다. 그런데 문제가 이 창조적이고 자율적인 시간에 하는 일에 각자의 인간성이 노출된다는 것이다. 하드웨어를 만드는 산업에서는 규칙적이고 반복적인 일을 동일하게 하는 경우가 많기 때문에 소프트웨어와는 경우가 다르다. 조립공장에서 일하는 데는 인간성이 별로 중요하지 않다. 인간성이 끼어 들 여지가 별로 없기 때문이다. 프로그래밍에도 골프와 마찬가지로 지켜야 할 많은 규칙이 있다. 그것을 다 기억하는 사람은 없다. 이게 문제의 시작이다. 자기 나름대로 자기 규칙대로 일을 한다. 그러다가 시간에 쫓기기라도 하면 편법이 등장하기 시작한다. 제대로 규칙에 맞게 하려면 시간이 많이 걸릴 수 밖에 없다. 쉽게 쉽게 근시안적인 처방들이 등장할 수 밖에 없다. 이 책의 후반부에서 지적하지만 무수한 편법들이 있다. 편법과 정통파와의 갈등이 시작되고 당연히 당사자의 인간성에 따라 이 결정을 하게 된다. 이에 따른 결과는 불행하게도 금방 나타나지 않는다. 대부분 미래에 나타난다. 이 모든 것이 소스코드에 증거로 남는다. 그래서 범인은 나중에 잡히기는 한다.
도박에서의 물질에 따르는 유혹, 골프와 프로그램에서의 편법사용시의 이득과 자기자신과의 싸움. 이 모두 인간의 본능과 자제력을 시험하는 것이다. 내가 무척이나 즐겼던 이 세가지 모두에서 같이 상종하지 말아야 하겠다는 사람들을 꽤 많이 접했다. 미국과 한국의 회사를 비교해 보면 한국 소프트웨어회사에서 훨씬 더 많은 편법적인 코드를 발견할 수 있다. 내가 지금 당장 한국의 어떤 소프트웨어 회사든지 소스코드만 보여주면 이런 문제점을 수도 없이 지적해 낼 수 있다.
조용히 열심히 일하는 사람은 해고 대상자
어느 회사에 가나 조용한 사람도 있고 수다스러운 사람도 있다. 다 장점이 있고 단점이 있다. 조립공장에서는 조용히 자기 맡은 일만 열심히 하는 사람이 회사가 원하는 사람일 것이다. 딴 사람 말 시켜서 업무방해하면 안되니까. 소프트웨어는 어떨까? 지위 고하를 막론하고 소프트웨어처럼 커뮤니케이션이 중요한 것은 없다. 소프트웨어의 성공여부는 일하는 사람들 사이의 거리에 기하급수적으로 반비례한다고 한다. 팀 동료가 바로 옆 자리에 있을 때하고 한 자리 건너 있을 때하고 다르다. 옆방에 있으면 또 차이가 난다. 다른 층에 있을 때, 다른 빌딩에 있을 때 완전히 다르다. 다른 나라에 있을 수도 있다. 동료가 바로 옆에 있는 것과 다른 나라에 있는 것을 상상해 보면 그 차이를 느낄 수 있다.
내가 한국에서 프로젝트를 할 때 인도 프로그래머들을 5명 고용해서 일한 적이 있다. 그 중에 “라비 팔” 이라는 엔지니어는 나이가 가장 어리면서도 내가 지금까지 같이 일해 본 사람들 중에 가장 커뮤니케이션을 적절히 하는 프로그래머이었다. 모두에게 비슷한 수준의 업무를 맡겼는데 일하는 스타일이 여러 종류였다. 혼자서 모든 것을 해결하려는 사람, 무조건 물어보는 사람등. 그 중에 라비는 마치 내 마음을 그대로 읽는 것 같았다. 지금쯤 어떻게 되어가고 있나 하는 생각이 들려고 하면 어김없이 와서 상의하곤 하였다. 내가 먼저 궁금해서 물어보게 만든 적이 한번도 없었다.
라비가 와서 상의하는 문제는 여러가지 종류였다. 기술적인 문제도 있고, 개발계획을 변경해야겠다, 사양이 변경되어야겠다 이번 주 토요일은 일이 있어서 쉬어야겠다 등등 주제도 다양하다. 하지만 목적은 모두 한가지로 귀착될 수 있다. 일이 어떻게 진행되고 있는지를 사전에 정확하게 알려주고 문제가 있을 때 대안을 찾는 것이다. 문제를 혼자서 무리하게 해결하려고 하면 꼭 부작용이 따른다. 서로 협조해서 해결해야 할 문제도 열등감에 사로잡혀 혼자서 모든 시간을 다 보내고 해결한다면 회사는 회사대로 개인은 개인대로 손해를 보기 마련이다. 간단한 것을 자존심 혹은 열등감때문에 물어보기 싫어서 고생하는 경우가 얼마나 많던가. 인간이 감정의 동물인 이상 어느 정도 이해는 간다. 다행히 아무도 모르게 넘어가면 좋은데 소프트웨어는 이상하게도 꼭 나중에 들통나기 마련이다. 일한 결과가 소스코드로 남는데 그것을 보면 그때 취한 행동거지를 짐작할 수가 있기 때문이다.
이 인도인력들의 대화수준이나 상의하고자 하는 주제로 볼 때 라비만 엔지니어라고 말할 수 있고 나머지는 시키는 대로 코딩만 하려고 하는 프로그래머에 가까웠다. 요령피우는 것도 그렇고. 한국직원들을 포함해서 피우는 요령의 하나가 이미 어느 날을 쉬려고 작정했으면서도 미리 얘기를 안하는 것이다. 쉰다는 얘기는 하기가 쉽지 않다. 미루다가 그 전날와서 얘기하는 경우가 대부분인데 라비는 항상 미리 얘기를 해 주었다. 윗사람이 어떤 사람을 신뢰할 수 있는지를 알고 있었다. 결국은 나이도 가장 어린 라비에게 가장 중요한 일과 전체 관리하는 일을 맡기게 되었다. 내 사무실은 항상 오픈되어 있다. 그냥 지나가다가 한두마디 잡담하는 것도 업무에 도움이 된다. 라비는 이런 행동이 몸에 배어있었다.
다양한 스타일 중에 가장 문제가 되는 것이 조용히 일하는 사람이다. 이런 사람은 나중에 꼭 문제가 생기기 마련이다. 소프트웨어 개발방법론에서 보면 현 단계에서 문제점을 발견하는 것과 다음 단계에서 발견해서 고치는 것과의 차이가 열 배의 노력이 더 드는 것으로 되어 있다. 조용히 일하는 스타일의 사람에게 어떻게 되어가냐고 물으면 잘 되어가고 있다는 대답이 대부분이다. 많은 경우에 문제가 있을 때 혼자서 자기편법을 사용해서 슬쩍 넘어가려고 하는 것이 다반사이다. 이것이 바로 실패하는 소프트웨어의 시초이다. 이런 사람은 당장은 조금이라도 이익이 되는 것처럼 보이나 미래에 생기는 문제는 다 조용한 사람이 만들어 낸다. 이사람 저사람 붙어서 보수작업 할 걱정이 먼저 든다. 이런 사람이 감시대상이며 감원대상 일순위인 것이다. 사사건건 확인하며 물어보는 사람은 업무진행속도는 느릴지언정 일을 믿고 맡길 수가 있다. 사실은 이런 스타일의 사람이 너무 많으면 안되지만 꼭 필요하다. 전체팀원과의 커뮤니케이션을 활발히 해주는 기폭제가 되기 때문이다.
컨설팅에는 돈을 안 낸다.
한국의 비즈니스에서는 대체로 하나의 공통점이 있다. 무형의 가치를 잘 인정하지 않으려고 한다. 자동차나 냉장고 같은 하드웨어는 제 값을 받고 파는데 문제 없지만 소프트웨어는 그 가치를 잘 인정하려고 하지 않는다. 한번 만들어 놓으면 원가 없이 복사만 하면 사용할 수 있기 때문에 돈 내고 소프트웨어제품을 사는 것을 아까워 한다. 하물며 그냥 대화나 하면서 자문을 해주는 것에는 돈을 지불할 생각을 하지 않는다. 구체적인 형체가 있는 것에는 돈은 아깝지 않게 내는데 컨설팅식의 자문이나 방향 설정이라든지 하는 것은 으레 공짜로 하려고 한다. 저녁이나 한번 사면 된다고 생각한다. 여기에는 두 가지 문제가 있다. 첫째가 돈을 내려고 하지 않는다는 점이고 둘째는 지속적인 컨설팅 없이는 효과가 나지 않는다는 것이다. 정당한 대가를 지불하지 않으면 누가 시간 낭비하면서 지속적인 컨설팅을 해주겠는가? 한두번 만나고는 더 이상 안 만날 것이다.
소프트웨어개발을 하려고 하면 컴퓨터도 필요하고 운영체계도 필요하고 소스코드를 적기위한 도구등 필요한 것이 많다. 개발시작 전에 이런 것을 다 결정해야 한다. 전산고문이 “이런 개발도구를 사용해야 합니다” 하는 결정을 내린다고 하자. 이러한 결정이 잘못 선정된 개발도구로 수 많은 엔지니어가 밤새워서 열심히 일하는 것보다 중요한 것이다. 이렇게 중요한 정보를 공짜로 주워 들으려고 한다. 이를 결정하기까지는 수 많은 시행착오를 거치면서 정립된 경험과 동물적인 감각이 필요하다. 그리고 결정을 내리기 위한 자료수집도 필요할 지 모른다. 하지만 마지막으로 나온 결론은 간단하다. 그러니 그런 말 한마디에 왜 돈을 내느냐고 생각한다. 이미 다 알았는데 더 이상 필요 없다고 생각하기도 한다.
프로그래머들이 만들어 내는 소스코드는 물론 시간도 걸리고 양도 방대하다. 하지만 올바른 길을 갈 때 그 가치가 있는 것이다. 전산고문의 한마디 말을 가치를 기준으로 해서 보면 모든 엔지니어의 임금을 더한 것보다 중요할 수 있다. 정량적으로 측정하기는 힘들다. 가끔 소프트웨어의 가치를 억지로 정량적으로 측정하기 위해 소스코드의 줄 수를 세는 경우가 있는데 이 역시 말도 안 되는 것이다. 뾰족한 수가 없으니까 궁여지책으로 나온 방법이다. IT ROI(투자회수대비)를 측정하는 방법이 있다고 주장하는 사람들도 있다. 이것 역시 궁여지책끝에 나온 부정확한 방법이다. 기술쪽에서 자라온 사람들이 보면 사기라고 볼 수도 있다. 마치 그림을 한 장 사서 회사에다 걸어놓았는데 이 그림에 대한 투자가 얼마나 생산성에 기여했는지를 계산할 수 있다고 주장하는 것과 다를 바 없다. 이러한 것은 오랫동안의 기업경영에서 오는 직감적인 판단의 영역이다. 정량화하기는 어렵지만 주관적인 판단을 내려야 하는 경우는 수도 없이 많다.
언젠가 한국에서 게임을 개발하는 업체인 E사를 방문한 적이 있다. 친구가 부탁을 했었다. 자기 동생이 관련되어 있는 회사인데 제품에 문제가 있는데 고치면 또 다른 문제가 생기고 해서 고객들의 불평이 끊이지 않는다는 것이었다. 방문을 해서 개발팀장들을 모아놓고 회의를 했다. 그 즉시 문제를 알 수 있었다. 개발 프로세스가 전혀 정립되어 있지 않은 것이었다. 학교숙제하는 식의 주먹구구식의 개발이었다. 너무 고칠 데가 많은 중에도 가장 필요가 있을 듯한 개발관리도구를 사용하라고 충고해 주었다. 모두들 진지하게 자세히 질문도 하고 어떻게 적용하는지를 가르쳐 주었다. 그리고 자세한 내용이나 실제 상황에서 벌어질 일은 모든 경우가 다르므로 각 경우에 맞게 진행하면서 조정을 필요로 한다고 말해 주었다. 그리고 그것은 일주일에 한 번 정도 개발과정을 계속 지켜보면서 자문을 해야 가능하다고 하였다. 물론 자문료는 비싸다고 했다. 사실 프로그램하며 일하는 사람들의 관점에서 보면 비싸기는 하다. 하루 와서 말 몇 마디 하고 가는 것처럼 보이는데 자기들 한달 월급을 지불하려면 아깝기 그지 없다. 그래서 그런지 더 이상 자문을 요청하지 않았다. 물론 처음 자문도 공짜였다. 나 역시 바쁜 와중에 자문을 계속 할 수 있는 처지도 아니어서 더 이상 확인하지는 않았다. 나중에라도 부탁하면 친구를 생각해서 억지로 시간내야 하는 처지였으니 말이다. 그 회사가 경영에 어려움을 겪고 있던 것을 고려하면 비싼 돈을 지불하면서 자문을 받을 처지는 아니었다. 또 새로운 방법으로 변화하는 것에 대한 두려움도 있었다. 새로운 방법론이 정립되기까지 변경 후 초기에는 개발속도가 느려질 수 밖에 없다고 얘기했기 때문에 어려운 결정이었을 것이다. 아마도 그 때 사용하던 방법 그대로 개발하고 있을 것이다. 계속 똑 같은 문제를 가지고 있을 것이고. “나는 내 방식대로 살겠다”는 의지의 한국인이다.
몰라서도 못하고 알아도 제대로 하기 힘드는 것이 올바른 소프트웨어 개발이다. 모든 운동이 마찬가지이지만 혼자서 골프교본 없이 골프를 배우기도 힘들지만 마치 골프교본 한 권 주었다고 골프를 잘 칠 수 없는 것과 마찬가지다. 누가 말 한마디로 잘못된 점 교정해 준다고 고쳐지던가? 천만의 말씀이다. 진정 골프를 잘 치려면 계속해서 실전과 함께 전문가한테서 레슨을 받아야 한다. 필드에 나가 실전만 하는 것도 문제가 있고 연습장에서 레슨만 받는 것도 문제가 있다. 실전과 교육이 적절히 균형을 이루어야 한다. 교육은 특히 좋은 선생한테서 받아야 한다. 경험이 많아서 그 사람의 특성에 맞는 방법을 가르칠 수 있어야 한다. 획일적으로는 안 된다. 골프뿐 아니라 모든 운동이 그렇고 소프트웨어개발도 비슷하다. 나도 가끔 골프 레슨을 받는데 돈이 아깝다는 생각이 들기도 한다. 하지만 나 혼자서는 골프실력이 늘기는 어려우니까 아깝지만 할 수 없다. 그러니 소프트웨어개발의 컨설팅도 그렇게 생각할 것이다. 안타까운 일이다. 그 회사는 다행히도 게임업체이니까 그래도 성공할 수 있는 여지는 남아 있다. 다른 소프트웨어와 달리 조금 결함이 있어도 사용할 수 있기 때문이다. 하지만 회계프로그램이나 영업프로그램같이 결함을 용납하지 않는 응용프로그램의 경우에는 시장에서 실패할 것이 뻔하다.
소프트웨어로 성공하기 위해서는 근본적으로 배움에 투자할 줄 알아야 한다. 전문가에게서 제대로 된 방법을 꾸준히 배워야 한다. 불행히도 한국에는 소프트웨어의 역사가 너무 짧아 좋은 전문가를 찾기 어렵다. 올바른 지도 없이 자수성가 하기는 오랜 시간이 지나도 제대로 되기 어렵다. 잘못된 문화가 뿌리깊게 자리 잡기 전에 조금이라도 빨리 제대로 된 소프트웨어 문화를 정립해야 할 때다.
잭 웰치와 나의 첫 직장
General Electric(GE)라고 하면 세계에서 가장 큰 회사이다. 미국에서 1984년도의 일이다. 실리콘밸리의 대학교에서 전산학를 공부하고 있을 때 룸메이트로 친구 3명이 같이 기거하고 있었다. 그 중의 한명이 지금 미국에서 천재골프소녀로 이름을 떨치고 있는 위성미 (미셸위) 의 아버지이다. 그 친구는 덩치가 크더니 그 딸도 13살인데 벌써 183센티란다. 또 다른 룸메이트가 GE에 먼저 입사했는데 그 친구의 소개로 인턴으로 1년간 엔지니어일을 하게 되었다. 에디슨 프로그램이라고 하는데 공대졸업생중 장차 GE를 이끌어 나갈 엘리트를 고용해서 2년간 회사업무와 함께 교육도 시키는 프로그램이었다. 그 친구가 어떻게 말을 잘 했는지 모르지만 고맙게도 졸업도 안 한 나를 1년계약 인턴이긴 하지만 고용해 주었다. 미국에서의 첫 직장이었으니 모든 게 생소했다. 그 친구의 도움을 많이 받았는데 그때 이런 얘기를 해주었다. 젊은 사장이 왔는데 대대적으로 감원을 한다는 것이었다. 한 마디로 어수선한 분위기였다. 내가 근무하게 된 부서도 감원에서 살아 남은 사람들이 일하고 있었다. 감원에서 살아 남았지만 또 추가감원이 있을 수도 있었고 해서 분위기는 싱숭생숭했다. 그 사장이 바로 지금 전 세계에서 가장 성공적인 CEO라고 평가 받는 잭 웰치였다. 잭 웰치의 경영철학은 회사에서 가장 우수한 20%는 충분한 보답을 해주고 가장 열등한 10%는 항상 감원시킨다는 것이었다. 살벌하지 않은가. 낙제점수를 받는 것도 아닌데 상대적으로 열등하다고 10%를 감원하다니. 하지만 나도 회사경영을 해보니까 동감이 간다.
내가 근무한 부서는 원자력 발전소를 관리하는 소프트웨어를 개발하는 부서였다. 이때 사용한 컴퓨터가 중앙컴퓨터는 하니웰이라는 대형컴퓨터였고 PC로는 IBM에서 만든 최초의 IBM-PC였다. 64K RAM에 360K 플로피 디스크가 달린 PC였다. 이 당시는 지금과 같이 MS Office같은 워드 프로세서는 없었다. PC를 거의 터미날 용으로 쓰고 프로그래밍언어는 지금은 거의 사용하지 않는 베이직 프로그램이나 파스칼, 포트란을 많이 사용했다. 그래도 그때는 불편한 줄 모르고 잘 사용했다.
나에게 할당된 업무에 대한 설명을 듣고 샘플 서류를 받았다. 그 때 어떻게 나에게 그런 중요한 일을 맡겼는지는 모르겠는데 GE가 미국에 설치한 원자력 발전소가 과열되지 않도록 할 때 사용되는 흑연막대봉을 조절하는 프로그램이었다. 중성자가 충돌하면서 핵분열이 일어나는 것인데 그 중성자를 흡수해서 핵분열을 감소시키는 것이 흑연막대봉이다. 흑연막대봉을 많이 집어 넣으면 화력이 감소하고 적게 집어 넣으면 과열되는 것이다. 1979년에 미 동부 뉴욕근처의 “Three Mile Island”라는 원자력 발전소에서 대형사고가 발생했었다. 그 사건 때문에 미국에서는 원자력 발전소를 더 이상 세우지 않게 됐다. 바로 이 컨트롤프로그램이 불완전한 상태에서 인간이 함께 잘못을 했기 때문에 발생한 비극적인 사건이었다. 내가 맡은 프로그램은 한치라도 실수를 용납할 수 없는 매우 중요한 프로그램이었다.
팀장으로부터 업무는 주어졌고 샘플서류에 있는 것과 같은 형식으로 진행했다. 그게 후에 알고 보니 바로 디자인단계였다. 팀에서 검토과정이 있었고 당연히 검토를 받고 지적된 사항 수정하고 재검토 받았다.그리고 나서 다음 단계로 넘어가니 상세 디자인 단계였다. 또 같은 과정의 검토를 받았다. 그리고 나서 코딩을 했다. 또 검토를 받았다. 그러니까 일이 무척 쉬웠다. 내가 하는 일이 잘못될 수 있는 길이 없으니 마음도 편하다. 매 단계마다 배우는 것도 많았다. 그런 식으로 진행되어 내 프로젝트는 별 무리 없이 끝냈다. 이러한 시스템이 있으니까 초보인 나에게도 이렇게 중요한 일을 맡길 수 있었던 것 같다. 마찬가지로 나도 다른 사람들의 검토회의에 들어가서 다른 사람들의 업무내용과 방법을 많이 배웠다. 일을 잘 했는지 미국에서의 취업사정이 최악이었던 그 시절에 다음해 여름방학 때 또 인턴으로 뽑아주었다. 이게 내가 소프트웨어의 체계화된 개발시스템을 처음으로 접촉했던 것이다. 거의 20년 전의 일이었다. 세살 버릇 여든까지 간다고 이 때 배운 방법이 그 후 내 평생에 버릇으로 남아 있다. 그 후에 지금까지 다른 회사들에서 접한 개발방법론도 근본적으로 유사하다.
피드 구독하기:
글 (Atom)