혼자만 알고 있는 개발자들

많은 회사 개발자를 만나면서 느끼는 우리나라 소프트웨어 회사들의 가장 큰 문제 중 하나는 개발자간에 정보와 지식의 공유가 잘 안 되는 것이다. 회사가 크던 작던 거의 모든 회사가 동맥경화에 걸린 것처럼 정보와 지식이 공유되고 유통되지 않고 몇 사람만 알고 있다. 회사가 크면 클수록 이런 현상은 더욱 심해진다. 

 
꽤 오래 전 어떤 개발자가 개발을 하면서 특정 라이브러리의 호환성 때문에 한 일주일 고생을 한 적이 있다. 인터넷도 검색하고 여러 시도를 해 보았지만 잘 해결이 안돼 여러 개발자가 고생을 하고 있었다. 수시로 사무실 통로에 서로 모여서 이와 관련된 짧은 토론을 여러차례 하면서 회사 내의 이슈가 되고 있었다. 
 
그렇게 며칠이 지날 때쯤 한 개발자가 말하길 이것은 자신이 수개월전에 이미 시도를 해보고 다 조사를 해본 것이라고 한다. 그리고 이것은 불가능하다는 것의 증거를 가지고 있다고 했다. 진작에 이것 때문에 고생하고 있다는 것을 알았지만 개발자들이 일주일이 지나도 해결을 못하자 자랑스럽게 얘기를 해주는 것이었다. 회사가 크고 서로 사무실이 달랐다면 이 조차도 전달이 안되었을 것이다. 그나마 회사가 작으니까 나중에라도 얘기를 해줄 수 있었다. 
 
이런 얘기를 들을 경우 개발자들은 그 개발자를 어떻게 생각할까? 남들이 모르는 것을 알고 있다고 존경심을 가질까? 아니면 왜 미리 알려주지 않았나 서운해할까? 아니면 이런 정보가 공유가 잘 안 되는 회사의 문화, 프로세스와 시스템을 탓할까? 
 
이런 개발자는 회사의 중요한 사람일까? 없어야 하는 사람일까? 내 생각은 이렇게 중요한 정보를 본인만 알고 있고 고의로 공유를 안하는 개발자는 해고감이다. 개발자는 개발에 관련된 내용을 적절히 충분히 기록하고 공유를 해야 한다. 이것은 말은 쉽지만 매우 어려운 일이다. 개발 과정에서 효율적이고 자연스럽게 정보와 기록을 남기고 공유를 해야 한다. 
 
이런 현상이 비단 개발자 탓만은 아니다. 공유가 잘 안되는 문화를 가진 회사에 입사를 해서 다른 사람과 자연스럽게 동화된 것 뿐이다. 공유를 할 마땅한 방법이 없기도 하고, 혼자서 열심히 공유를 하려고 해도 대부분의 개발자들이 자신의 업무에 바빠서 공유된 정보에는 관심도 없는 경우가 많다. 국내 많은 소프트웨어 회사들이 이와 비슷하다. 공유를 위해서 애쓰지만 대부분 성공적이지 않다. 공유에 실패하는 회사는 다음과 같은 특징이 있다. 
 
첫째, 소수의 인원만 정보 공유에 애쓴다. 경영진을 비롯해서 대부분의 개발자는 공유에 별로 관심이 없다. 공유가 왜 중요한지 인식을 못하기도 한다. 개발자 혼자 공유 문화의 전도사처럼 나서지만 누구 하나 인정해주지도 않고 본인도 금방 지치게 된다. 
 
둘째, 공유를 위한 시스템이 없거나 부족하다. 공유를 한다고 문서를 만들어도 문서가 버전관리도 안되고 여기저기 굴러다니고 정보를 찾기도 어렵다. 좋고 비싼 시스템이 있어도 제대로 사용하지 않는다. 이럴 때 비싼 시스템은 오히려 적절한 공유에 방해가 되기도 한다. 
 
셋째, 개발과는 별도로 문서를 따로 만든다. 문서를 만들어도 많이 만든다. 게다가 문서를 만드는데 엄격한 규칙이 있다. 대부분의 대기업이 여기에 해당한다. 경영진이 공유의 의지를 가지고 밀어붙이는 경우도 대부분 이렇게 된다. 하지만 이렇게 별도로 문서를 많이 만든다고 공유가 잘되는 것은 아니다. 엄격한 프로세스로 비효율적으로 많은 문서를 만들기도 하고 이를 형식적으로 지키기도 하지만 이것으로 공유에 성공했다고 볼 수는 없다. 
 
정작 중요한 정보는 공유가 안된다. 이런 회사의 특징은 대부분의 문서가 서로 정보가 안맞고 계속 업데이트가 안되서 쓸모가 없다. 게다가 쓸모 없는 문서와 쓸모 있는 문서가 섞여 있어서 올바른 정보를 구분하기 어렵다. 
 
넷째, 기존의 지식을 문서로 만들려고 애쓰다가 실패한다. 기존의 지식과 정보를 모두 끄집어내서 문서화 하는 일은 거의 불가능한 일이다. 일할 당시 그때가 아니면 문서화는 어렵다. 하루가 지나면 기억 속의 정보는 50%가 사라지고 일주일이 지나면 90%가 사라진다. 지금이 아니면 나중에는 문서화 할 수 없다. 밀린 일기는 포기하고 오늘 일기부터라도 쓰는 것이 좋다. 
 
다섯째, 항상 너무 바쁘다. 특히 고참일수록 더 바쁘다. 신입사원은 제대로 일하려면 수개월이 걸린다. 그러다 보니 고참이 더 바빠서 공유에는 신경 쓸 시간이 없는 악순환이 계속된다. 
 
반대로 공유에 성공한 회사는 다음과 같은 특징이 있다. 
 
첫째, 경영진을 비롯한 모든 개발자가 공유에 힘쓴다. 공유가 얼마나 중요한지 모두 잘 알고 있고 공유에 문화적으로 시스템적으로 투자를 한다. 
 
둘째, 적절한 시스템이 구축되어 있다. 대부분 이슈관리시스템, Wiki등의 시스템이 잘 구축되어 있고 회사의 거의 모든 정보와 지식이 잘 저장되어 있다. 뿐만 아니라 휘발성 커뮤니케이션 수단인 전화, 메신저, 이메일 등은 보조수단으로 사용되며 중요 정보는 대부분 시스템을 통해서 전달되고 공유된다. 
 
셋째, 문서는 최소로 만든다. 불필요한 문서를 만들지 않고, 꼭 필요한 문서 몇 개만 만든다. 문서의 형식도 꽤 자유롭다. 개발자들이 토론하면서 노트에 그린 그림을 사진을 찍어서 올리기도 하고, 온라인 그리기 도구를 쓰기도 하고 상황에 맞게 자유로운 도구를 활용한다. 
 
넷째, 공유가 습관화 되어있다. 항상 일하는 과정에서 자연스럽게 공유를 한다. 별도로 문서를 만든다고 많은 시간을 소비하지 않는다. 자유롭게 필요한 만큼 알아서 효율적으로 공유를 한다. 항상 노트를 하고 즉각 정리해서 이슈관리시스템이나 Wiki에 등록하는 것이 일상화 되어 있다. 개발자가 수시로 하는 작은 조사, 개발도 모두 문서화되고 공식적으로 진행된다. 
 
다섯째, 리뷰가 활성화 되어 있다. 모든 정보는 문서로 공유하기는 어렵다. 토론도 많이 하고 리뷰도 자주 있다. 리뷰과정을 거쳐서 문서는 꼼꼼히 검토가 되고 여러 직원들의 전문적인 의견이 반영된다. 고참일수록 리뷰에 많이 참석하며 자신의 경험과 지식을 리뷰를 통해서 전수한다. 
 
공유는 소프트웨어에서는 가장 중요한 기업 문화이다. 소프트웨어가 창의적인 지식산업이기 때문에 더욱 그렇다. 하지만 대부분의 회사는 위에서 언급한 공유에 실패하는 증상들이 보이고 있다. 그렇다고 이제부터 공유를 열심히 하자고 마음만 먹는다고 공유가 잘되는 것은 아니다. 복잡한 프로세스를 도입하는 것보다 공유 문화 정착이 열 배는 어려운 일이다. 
 
경영진의 의지가 가장 중요하지만 의지만 가지고 밀어붙이다가는 프로세스만 복잡해지는 함정에 빠지기가 매우 쉽다. 문화란 그만큼 바뀌거나 도입하기 어려운 것이다.

이글은 ZDNet Korea에 기고한 칼럼입니다.

21C 韓 SW개발자는 16C 조선 陶工 처지

나의 취미 중 하나는 도예 즉, 도자기 만들기다. 우연한 기회에 시작해서 10년을 넘게 도자기를 만들었으며 도자기 역사나 도자기 기술에 대해서도 많은 공부를 하게 되었다. 그런데 요즘 우리나라의 소프트웨어 산업 환경이 조선 시대 임진왜란 때 일본으로 납치되어 간 도공들이 다시 조선으로 돌아오기를 거부하고 일본에서 뿌리를 내린 것과 비슷하다. 

임진왜란 당시 어떠한 일이 일어났는지 간단히 알아보자. 그리고 역사는 되풀이 된다는데 현재 우리는 무슨 문제를 가지고 있는지도 생각해보자. 

16세기까지 전세계에서 1천300도 이상에서 구워내야 하는 도자기를 만들어 낼 수 있는 나라는 중국, 한국, 베트남 정도였고 그 중에서 도자기의 최고봉인 백자는 중국과 조선만 만들어 낼 수 있었다. 지금은 도자기가 별 것 아니라고 생각할 수 있었지만  당시에는 최고로 돈이 되는 물건이었다. 유럽의 귀족들은 중국의 도자기에 열광해서 금, 은 그릇보다 비싼 가격에 도자기가 거래되고 있었고 세계 도자기 시장은 거의 중국이 석권하고 있었다. 

임진왜란이 왜 일어 났는지는 여러가지 의견이 있지만 도자기 때문에 일본이 일부러 일으켰다는 주장도 있다. 임진왜란의 근본 목적은 조선의 도자기 제작 기술을 비롯한 여러 가지 공예 기술을 훔쳐오기 위한 것이라는 주장이다. 일찌감치 네덜란드 등과 교역에 눈을 뜬 일본은 유럽에서의 도자기 인기를 알게 되었고 자신들의 도자기 제작 기술보다 월등히 높은 조선의 도자기 제조 기술을 가지고 싶어 했다. 그래서 임진왜란 전에 미리 첩자를 조선에 보내 조선의 도공들의 신상과 소재를 모두 파악한 후 임진왜란, 정유재란 중에 조선의 도공 거의 전부인 약 900명을 납치해 갔다는 것이다.물론 도공들만 납치해 간 것은 아니고 다른 수많은 분야의 장인들을 같이 납치해 갔지만 도자기 장인들이 핵심이었다. 

그렇게 납치해 간 도공들은 일본에서 도자기를 만들 수 있는 흙을 찾아냈고 20년만에 일본도 완벽한 도자기 제작 기술을 보유하게 되었다. 마침 중국의 내부 정세 혼란을 틈타 유럽의 도자기 시장을 석권하고 막대한 자금을 바탕으로 아시아 최대 강대국으로 발돋움 했다는 학설이다. 

그런데 임진왜란 후에는 조선은 도공들을 다시 돌려 받으려고 했지만 많은 도공들은 조선으로 돌아오기를 거부했다고 한다. 일본으로 끌려간 도공들은 조선에서보다 훨씬 나은 대접을 받았다고 한다. 조선에서는 기술은 천시하고 도공뿐만 아니라 대부분의 장인들은 하층민 대접을 받았지만 일본에서는 이들을 극진히 대우를 해줬다고 한다. 땅도 주고 집도 주고 결혼도 시켜주고 마음껏 도자기를 만들 수 있도록 지원을 아끼지 않았다고 한다. 옛날부터 일본은 장인을 존경하는 전통이 있었고 자신들이 가장 높게 사는 최고의 도자기 제작 기술을 가지고 있는 사람들을 존경하고 대우해주는 것은 어쩌면 당연했을지도 모른다. 

그러다보니 임진왜란 후 거의 도자기의 명맥이 끊기고 세계 예술사에서 거의 흔적을 남기지 못한 한국과는 대비되게 일본은 최고의 도자기 명문 국가가 되었고 선진국의 발판이 되었다. 역사에 만약은 없지만 도자기를 기반으로 우리나라가 18,19세기 강대국으로 발돋움 했다면 어떻게 되었을까? 

이 얘기를 하는 이유는 임진왜란 당시의 상황이 지금과 별반 다르지 않기 때문이다. 여전히 기술자는 존경과 대우를 못 받고 그나마 대우를 받으려면 관리자가 되어야 한다. 공부를 잘하는 학생들은 대부분 의사, 공무원이 되려고 한다. 소프트웨어 개발자들은 기회만 되면 외국으로 나가려고 한다. 개인 입장에서는 축하해줄 일이지만 그렇게 고급인력이 다 빠져나가면 우리나라는 어떻게 될까? 

하지만 지금 소프트웨어를 전공하는 대학생이 진로를 문의하면 나도 외국으로 나가라고 충고를 한다. 미래의 먹거리가 소프트웨어에만 있는 것은 아니지만 소프트웨어가 가장 중요한 기술 중 하나인데 개발자에 대한 인식이나 대우, 환경은 너무 열악하다. 드라마에서 잘나가는 사람들은 거의 의사, 경영자, 변호사, 검사다. 엔지니어나 소프트웨어 개발자가 주인공은 경우는 거의 없다. 사회적으로 인식이 매우 낮다는 반증이다. 

제2의 도자기 전쟁은 이미 시작되었고 핵심은 우수 두뇌 확보다. 구글이 3조원이 넘는 금액을 지불하고 네스트를 인수한 주 목적도 인재 확보다. 구글이 네스트에 지불한 금액은 1인당 100억원이 넘는다. 국가나 기업 모두 인재를 확보하기 위해서 혈안이 되어 있지만 우리나라 인재들은 외국으로 나가고 있다. 또는 기회만 되면 외국으로 가고 싶은 엔지니어도 상당 수다. 

외국의 인재도 모셔와야 하는 마당에 우리나라의 인재들이 일하기 힘든 환경을 그대로 놔두고 있는 것은 오랫동안 뿌리깊게 자리잡은 기술자 천시와 관료 우대 인식 때문이 아닐까 생각한다. 이런 기술자를 낮게 보는 인식을 없애지 않으면 구한말에 우리나라가 겪었던 고통을 또 겪어야 할지도 모른다. 나라를 좌지우지 하는 사람들은 국내 상황에 정신을 팔려서 세계의 흐름을 놓치고 있다. 나중에 애국심에 호소해서 외국에서 일하는 우리나라의 인재들에게 들어와서 나라를 다시 일으켜 달라고 해도 돌아오는 사람이 몇 명이나 될까? 

개발자들이 우리나라를 떠나고 싶어하는 가장 중요한 이유가 연봉의 차이는 아니라고 생각한다. 연봉이 높은 나라는 생활비 지출도 많고 세금도 많다. 더 중요한 것은 엔지니어에 대한 전문성의 인정과 사회적인 존경심이라고 생각한다. 창의적 지식 노동에 대한 이해와 좋은 개발환경도 필요하다. 개발자로 30년을 일해도 어린 관리자와 같이 일을 해도 전혀 어색하지 않고 어린 관리자도 늙은 개발자를 어려워하지 않는 문화가 필요하다. 생산성을 높이는 방법을 오직 야근밖에 모르는 회사가 워낙 많다. 이런 회사는 사채를 끌어 쓰는 것과 같아서 갈수록 어려워진다. 이런 환경이 계속 만연한다면 우수한 개발자 인력들은 외국으로 떠나던지 소프트웨어 업계를 떠날 것이다. 이런 환경을 수수방관하면 역사는 되풀이 될 것이다.

이 글은 ZDNet Korea에 기고한 칼럼입니다.

외국 개발자들이 보기에 군대 같은 한국 회사

“A기업은 좀비월드 같다. 직원들이 아무 생각 없이 회사를 떠돈다.”

“B기업 직원들은 불만을 말하지 않는다. 근무 내내 감옥에 있는 느낌이다.”

“C기업은 군대다. 상사가 말하면 무조건 따라야 한다. 이유를 묻거나 질문할 수도 없다.”

얼마 전 모 신문 기사에 나온 외국인들이 한국의 기업들에 대해 느낀 점을 얘기한 것이다.

국내에서 소프트웨어 개발에 한계를 느낀 대기업들은 해외에 여러 형태의 소프트웨어 조직을 설립하고 현지의 외국인 개발자를 채용하고 있다. 국내 개발자들의 소프트웨어 개발 실력이 떨어져서 소프트웨어를 제대로 개발하지 못했다고 착각하고 있는 것이 아닌가 생각된다.

그런데 우리나라 회사들의 조직 문화와 분위기는 외국에도 이미 소문이 많이 났다. 우리나라 기업문화 자체가 나쁘다고 볼 수는 없으나 소프트웨어 개발자들이 선호하는 문화는 아니다. 소프트웨어 전문가라고 하더라도 이런 조직 문화와 개발 환경에서 소프트웨어를 제대로 개발하기는 어렵다. 그래서 우리나라 회사에서 설립한 외국의 현지 소프트웨어 개발 센터에 들어가기를 꺼려하는 현상이 일어나는 것이다.

이렇게 소프트웨어 개발에 불리한 기업문화를 가지게 된 이유는 여러 가지가 있지만 중요한 이유 중 하나가 우리나라 회사의 경영진들은 소프트웨어 대한 개념이 없기 때문이다. 여기에 상명하복의 “까라면 깐다”는 조직 문화가 더해져서 소프트웨어 산업을 망치는 주범의 역할을 하고 있다.

A사의 사례다. 회사의 사활이 걸리는 매우 중요한 프로젝트가 있었다. 개발자들이 대충 예상을 해도1년반 이상 걸리는 프로젝트였다. 하지만 소프트웨어에 대한 개념이 없는 경영진들은 자신의 재임기간에 성과를 내기 위해서 6개월안에 완성하라고 했다. 기업의 분위기가 까라면 까야 하기 때문에 아키텍처가 완전히 망가지는 것을 감수하고 6개월 안에 완수를 했다. 하지만 그로 인한 피해는 심각했다. 제대로 아키텍처를 완전히 수정해서 개발을 했으면 기간과 비용이 2배 이상 들었지만, 급하게 6개월 안에 완성함으로써 미래에 드는 비용은 수십 배가 증가 했으며 이로 인해서 회사는 망하는 길로 들어섰다.

프로젝트를 완료했을 당시에는 경영진은 1년이 넘게 걸릴 프로젝트를 자신의 리더쉽과 독려로 6개월안에 완성했다는 것을 자랑하지만 이로 인해서 회사가 망하는 길로 들어섰다는 것은 전혀 몰랐다.

개발팀의 아키텍처에 대한 의견은 치기 어린 엄살로 간주하고 탱크같이 밀어붙이는 경영진을 능력 있는 경영진으로 간주하는 것이 현실이다. 이런 무모한 독선은 단기적인 효과는 거둘 수 있어도 미래에는 그로 인해 얻은 이익의 몇 배의 비용을 지불하게 되어 있다.

B사의 경영진은 개발자들이 6개월째 집에도 못 들어가고 프로젝트를 하고 있는 것을 자랑스럽게 얘기한다. 야근을 하면 야근 한 시간만큼 생산성이 비례해서 늘어난다는 착각에 빠져 있는 경영진은 정말로 많다. 야근 강요는 소프트웨어 개발을 지식 산업이 아닌 육체 노동 산업으로 내모는 결과를 가져온다. 야근은 대출과 같아서 단기적인 효과는 있어도 장기적으로는 생산성이 더 떨어진다. 자발적인 야근은 효과가 크지만 강압적인 야근은 생산성과 창의력을 점점 낮추게 된다. 지금도 암암리에 야근을 많이 해야지만 인정 받는 분위기 때문에 어쩔 수 없이 경영진의 기대에 맞추기 위해서 수많은 개발자들이 야근을 하고 있다.

야근은 생산성 저하 외에도 개인 생활과 가족과의 시간을 희생해야 하기 때문에 일을 위해 가족과의 시간을 희생을 감수하는 우리나라 개발자에 비해서 외국인 개발자들에게는 꺼려지는 문화가 아닐 수 없다.

국내의 한 회사에서는 간부들에게는 제품의 아키텍처와 디자인에 절대로 간섭하지 못하도록 최고 경영자의 지시가 있었다. 회사 초창기에는 간부들의 통찰력이 어느 정도 통했지만 회사가 커지고 제품이 복잡해지면서 더 이상 간부들의 간섭은 통하지 않고 오히려 망치는 길이라는 것을 경험적으로 깨달은 것이다.

우리나라 대기업의 경영진들은 자신들이 척박한 환경에서 그 짧은 시간에 기적적으로 회사를 성장 시켰듯이 소프트웨어 역량도 순식간에 따라 잡을 수 있다고 생각한다. 하지만 이는 대단한 착각이다.언뜻 보기에는 간단해 보이는 소프트웨어가 인류가 만들어낸 지식 산업 중에서 가장 복잡하고 어렵다는 것이다.

그 동안 기존 산업에서 익혀온 성공 방정식을 소프트웨어에도 적용하다 보니 잠깐의 반짝 성공은 있었을지 몰라도 급한 한발 내딪음으로 인해서 두발 더 뒤쳐지게 되었다.

외국인 개발자들이 꺼려하는 이러한 환경은 국내 개발자들도 똑같이 꺼려하는 환경이다. 단지 국내에 태어났기 때문에 다른 선택이 어려워 그런 환경이라도 꾹 참고 일을 하고 있는 것이다. 그래서 요즘은 처음부터 외국 기업을 찾는 개발자자도 많다.

외국인들을 위해서 외국인에게 인기가 있는 회사를 무조건 만들라는 것은 아니다. 외국인 개발자에게 인기가 없는 회사가 소프트웨어 개발에 불리한 환경이라는 것이다. 외국인 개발자들에게 인기가 있는 회사가 된다면 국내 개발자들도 일하기 좋은 환경이 될 뿐만 아니라 소프트웨어 산업 전체의 경쟁력도 증가할 것이다.

이글은 ZDNet Korea에 기고한 칼럼입니다.

쓸데없는 회의를 줄이는 방법

'회의가 많은 회사는 곧 망한다'는 속설이 있다. 다른 분야에서도 마찬가지지만 개발자도 회의에 많은 시간을 빼앗기면 개발에 집중하기 어렵고 이는 개발 생산성 저하로 이어진다. 꼭 필요한 회의는 해야 하지만 과도한 회의는 줄여야 한다. 그럼 어떻게 회의를 줄일 수 있을까? 
 
물론 개인 혼자서 회의를 줄이려고 노력한다고 해서 되는 것은 아니다. 직원들이 회의를 줄이는 것이 왜 중요하고 어떻게 줄여야겠다는 방법도 서로 공유를 하고 노력을 해야 한다. 일단 회의가 얼마나 비싼 활동인지 생각해보자. 
 
10명이 1시간동안 회의를 하면 얼마의 비용을 쓴 것일까? 회사마다 다르겠지만 적게 잡아도 100만원쯤 쓴 것으로 생각하면 된다. 개발자는 1인당 회사에서 사용하는 비용은 급여와 부대비용을 계산하면 알 수 있다. 여기에 개발자가 그 시간 동안 다른 일을 했을 때의 기회비용까지 계산하면 최소한 한 시간에 10만원은 생각해야 한다. 이보다 낮다고 주장하는 개발자가 있을 수도 있지만 평균 이 정도는 생각해야 한다. 
 
30명이 참석하는 회의에 몇 사람이 늦게 와서 10분 늦게 시작하면 50만원은 그냥 손해를 본 것이다. 이렇게 회의에 직접적으로 소모하는 비용과 회의에 참석하기 위해서 준비를 하거나 자료를 읽는 시간, 회의 참석에 이동하는 시간, 앞뒤로 어영부영 지나가는 시간을 합치면 훨씬 많은 시간을 소모하게 되고 그 비용은 상당하다. 
 
이렇게 비싼 회의는 꼭 필요한 경우에만 효율적으로 해야 한다. 그렇지 않고 회사의 생산성을 높일 수는 없다. 그럼 어떻게 회의를 줄일 수 있는지 알아보자. 회의를 줄이기 위해서는 아래 3가지 원칙을 지키면 된다. 
1. 회의를 하지 않는 것이다. 
2. 회의에 참석하지 않는 것이다. 
3. 회의 시간을 줄이는 것이다. 
 
첫째, 안해도 되는 회의는 하지 않는다. 회의를 전혀 안할 수는 없다. 특히 의사결정은 문서나 시스템으로 하기 어렵고 대부분은 회의를 통해야 한다. 하지만 회의를 하지 않거나 대규모 회의로 하지 않아도 되는데 무신경하게 또는 일상적으로 회의를 하는 경우가 많다. 
 
정보를 단순 공유하거나 브리핑을 위한 회의는 줄일 수가 있다. 일상적으로 시스템을 통해서 공유가 잘 되는 회사는 이런 단순 공유 회의는 거의 하지 않는다. 단, 시스템을 잘 쓴다는 전제하에 이런 회의는 거의 하지 않아도 되는 것이다. 이를 위한 가장 중요하고 유용한 시스템은 이슈관리시스템이다. 이슈관리시스템은 소프트웨어 회사에서는 없어서는 안될 중요한 시스템이다. Trac, Jira, Mantis, Redmine과 같은 시스템이다. 
 
하지만 필자의 블로그에서 시행하고 있는 수년간의 설문 통계를 보면 약 40%의 회사는 아직도 이슈관리시스템을 사용하고 있지 않다. 이메일과 엑셀 등으로 이슈를 주고 받거나 관리를 하는데 그렇게는 효율적인 소통이 어렵다. 게다가 이슈관리시스템을 사용하고 있는 회사도 정말 효율적으로 잘 쓰고 있는 회사는 10%가 안된다. 
 
회의를 줄일 수 있을 정도로 이슈관리시스템을 잘 쓰는 방법은 책 한권으로 설명해도 부족하겠지만 요약하면 다음과 같다.
 
모든 공식적인 요청은 이메일, 전화, 말로 하지 않고 이슈관리시스템에 등록해야 한다. 나머지는 보조수단이다. 전 임직원이 예외 없이 규칙을 따라야 한다. 이슈관리시스템에 대시보드를 자신에게 맞게 잘 만들어서 적어도 하루에 한번 이상 대시보드를 확인하고 처리를 해야 한다. 이슈관리시스템에 이슈를 등록하고 상태를 변경하며 댓글을 다는 등의 행동은 성의껏 해야 한다. 
 
내가 남긴 한 줄의 문장을 수많은 사람이 읽고 공유가 되며 대화와 회의를 대신하고 오랫동안 남아서 여러 사람에게 정보를 제공할 것이기 때문에 엉터리 문장으로 적으면 안된다. 10년 후에 후배가 봤을 때 알아 볼 수 있도록 잘 적어야 한다. 물론 이렇게 사용하려면 무신경하게 엉터리로 사용하는 것보다 약간의 노력이 더 필요하지만 충분히 그럴 가치가 있다. 
 
둘째, 내가 참석하지 않아도 되는 회의는 참석하지 않는다. 
 
회의는 참석자가 적을수록 효율적이다. 내가 참석하지 않아도 되는 회의는 참석하지 않아야 한다. 그리고 회의에 똑 필요한 인원만 초청을 해야 한다. 
 
회의 참석의 목적은 여러가지가 있지만 의사결정을 하기 위한 것이거나, 전문가로서 의견 제시하거나 정보를 습득하려는 등의 목적이 있다. 
 
가끔 회의 요청을 받으면 이런 단순 정보 공유 회의에 내가 왜 참석해야 하는지 의문이 들 때가 있다. 특히 내게 당장 필요하지는 않지만 알면 좋은 정도로 애매한 경우도 있다. 이런 때는 내가 지금 이 시간을 투자해서 참석할 필요가 있는 회의인지를 판단해야 한다. 물론 이런 회의에 무조건적으로 참석하라고 하면 안된다. 누구나 들으면 좋은 회의라고 참석자를 잔뜩 늘려서 초청을 하면 수백만원의 비용을 지불하는 것이라는 생각을 잊으면 안된다. 
 
내가 전문가로서 의견을 제시해야 하는 경우라면 회의 내용을 사전에 꼭 숙지를 하고 참석해야 한다. 이런 회의에 전문가가 아닌 사람을 여러명 불러 놓고 난상토론을 하는 것은 정말로 시간 낭비다. 회의 때마다 잘 알지도 못하지만 그냥 이슈를 마구 던지거나 자신의 취향이 전문적인 의견인양 얘기하는 사람들이 있다. 이런 회의의 참석자는 꼭 필요한 사람으로 잘 꾸려야 한다.
 
리뷰 회의가 대표적이다. 교육적인 목적으로 내용을 익히려고 참석하는 경우도 있지만 각 분야의 가장 전문가가 미리 내용을 한 글자, 한 글자 꼼꼼히 읽어보고 빠르게 의견을 제시해야 한다. 그래서 고참이 될수록 이런 리뷰 회의에 참석하는 일이 많아지게 된다. 
 
셋째, 회의 시간은 최소화 해야 한다. 
 
회의 시작 전에 회의 아젠다를 미리 공유하고 회의 자료나 문서를 미리 배포해야 한다. 회의는 시작 시간과 종료 시간을 미리 정해야 하며 무작정 길게 시간을 잡는 것은 삼가야 한다. 회의에 따라서 다르지만 대부분의 배포된 문서를 꼼꼼히 읽고 와야 한다. 경영진이라고 하더라도 미리 꼼꼼히 읽어야 한다. 회의시간에 자료를 다시 브리핑하는 것은 여간 낭비가 아니다. 
 
따라서 회의 공지는 자료를 충분히 검토할 시간이 필요하므로 충분히 미리 해야 한다. 회의 1,2시간 전에 갑자기 공지를 하면 준비할 시간이 부족하게 된다. 
 
회의시간에는 회의에 집중해서 계획한 시간 안에 꼭 내도록 노력해야 한다. 쓸데 없이 경영진이 교장선생님처럼 이런 저런 얘기를 하는 것은 좋지 않다. 회의 주제에 집중해야 한다. 
 
개발자들과 아침에 하는 5분 회의는 효율적인 회의의 대표적인 예다. 자료는 이슈관리시스템에 있고 대시보드를 확인하며 주요 이슈만 확인을 하고 꼭 공유해야 할 내용을 얘기하면 개발팀 일일회의는 5분에서 10분안에 끝나게 된다. 
 
그 외에 스카이프나 구글행아웃을 이용한 원격회의도 회의를 효율적으로 하게 해준다. 회의를 위해서 먼거리를 이동하지 않고 원격으로 회의를 할 수 있고 요즘은 스마트폰으로 회의를 하기도 한다. 코드리뷰시스템을 사용하는 것도 좋은 방법이다. 온라인으로 코드리뷰를 할 수 있도록 하여 코드리뷰 자체의 효율성도 높아지고 코드리뷰 때문에 모여야 하는 시간을 줄여주고, 코드리뷰 내용을 모든 사람과 공유할 수 있어서 좋은 정보가 된다. 
 
마지막으로 회의를 했다면 가능하면 빠른 시간에 회의록을 정리하여 회의 참석자와 참석하지는 않았지만 관련된 모든 사람에게 회의록을 배포해야 한다. 이슈관리시스템 등의 시스템을 활용해서 회의록을 배포, 관리하는 방법도 좋다. 
 
다시 한번 회의가 얼마나 비싼 활동인지 명심하자. 하루에 회의 3,4번이면 개발자는 다른 일은 거의 못한다. 개발자뿐만이 아닐 것이다. 회의는 지금의 10분의 1로 줄인다는 마음으로 회의를 줄여보자.

이글은 ZDNet Korea에 기고한 칼럼입니다.

한국의 개발자는 쓸데없이 바쁘다

한국의 개발자들은 항상 바쁘다. 소프트웨어 개발을 하느라고 바쁜 것이 아니라 쓸데없는 일에 바쁜 것이 문제다. 회사마다 차이는 있지만 많은 회사에서 개발자들은 본연의 개발 업무보다 불필요한 다른 일에 바빠서 정작 본연의 임무인 개발에 투자하는 시간이 얼마 안되는 경우가 많다. 여기서 개발이라 함은 코딩뿐만 아니라, 분석, 설계, 리뷰 등 개발에 필요한 일련의 활동을 모두 말한다.

한국 회사들의 소프트웨어 개발 생산성이 상대적으로 선진 소프트웨어 회사보다 낮은 이유 중 하나는 개발자들이 개발에 전념하지 못하는 환경 때문이다. 

개발자는 고참이 될수록 개발에 집중하지 못하고 다른 일 때문에 바빠진다. 어느 회사의 고참 개발자들은 낮 시간에는 코딩을 한 줄도 못하고 남들 퇴근 후에 개발 일을 한다. 낮에는 이 회의, 저 회의 많이 끌려 다니기 때문에 집중해서 개발 관련 일을 할 수 없어 낮시간은 아예 포기하고 밤에 개발을 한다는 것이다.

코딩, 분석, 설계 관련된 모든 일은 대단히 집중력이 필요하기 때문에 중간에 다른 일로 방해를 받으면 다시 집중하기 매우 어렵다. 하루 종일 방해 받지 않고 집중해서 일할 수 있는 환경은 매우 중요하다. 

하지만 경영자들은 개발자도 시장을 잘 알아야 한다고 말하며 고객을 직접 만나게 하고, 시장 관련 회의에 참석하게 한다. 여러 경영 회의, 전략 회의에도 개발자들을 끌고 다닌다. 그러다보니 개발자들은 보고서도 작성해야 하고 보고 회의도 참석해야 한다.

고참 개발자일수록 이런 회의에 더 많이 불려 다니게 된다. 어쩔 때는 회의에서 꿔다 놓은 보릿자루 마냥 앉아 있기만 하면서 “왜 이런 회의를 참석해야 하나” 한탄을 하지만 회사 요구 때문에 빠지기도 눈치가 보여서 그냥 참석을 하는 경우가 많다. 물론 개발자도 시장, 고객, 경영 등 여러 분야에 대해 알아야 한다. 아키텍트나 팀장인 경우 더 잘 알아야 한다. 문제는 시간의 효율적인 활용이다. 이런 회의에 다 불려 다닌다고 더 잘아는 것은 아니다. 문서로 공유해도 되는 내용을 장시간 회의에 앉아서 시간을 허비하는 경우가 많다.

개발자들은 평가, 교육 활동으로도 많은 시간을 빼앗긴다.  필요한 일들이기는 하지만 너무 많은 시간을 빼앗기는 것이 문제다. 회사 교육담당자는 개발자들에게 교육을 많이 시켜서 도움을 주고 싶어하지만 일괄교육, 집체교육, 의무교육은 개발자들의 개발업무를 방해하는 요소다. 리더 교육을 열심히 한다고 팀장이 뛰어난 리더가 되는 건 아니다. 필요 없는 교육은 아니지만 얼마나 효율적인지는 생각해봐야 한다. 기업에서는 교육보다 실무 자체로 배우는 것이 더 중요하다. 

회의를 많이 하는 회사일수록 커뮤니케이션이 잘 안되고 누가 뭘 하는지 잘 모르는 경우가 많다. 회의가 과도하게 많다는 것은 공유와 협업이 잘 안되고 있다는 반증이기도 하다. 대기업에서 개발자가 더 일하기 힘든 이유가 여기에 있다. 대기업은 회사마다 다르지만 기본적으로 회의도 많고 프로세스도 복잡하다. 정작 진짜 개발하는 시간은 몇시간 안된다. 

그럼에도 대기업이 돌아가는 이유는 우수한 인력과 여유 인력, 자본이 풍부하기 때문이다. 50% 퍼포먼스만 발휘해도 회사는 굴러간다. 이런 비효율이 회사가 잘 될 때는 문제가 안되지만, 어려울때는 큰 약점이 된다. 
그런데 중견기업 중에는 이런 대기업 형태를 따라하는 회사들이 꽤 많다. 회사가 커지다보니 관리의 필요성이 증가해 개발자들의 시간을 점점 빼앗는 것이다. 그러다보면 대기업의 장점인 관리 부문에도 만족하지 못하고 기존의 민첩하고 효율적인 개발 방식도 점점 잃게 된다. 

기본적으로 이렇게 회사에서 개발자들이 개발에 집중하지 못하게 방해를 하는 이유는 개발자를 믿지 못하기 때문이다. 심지어는 초등학생 취급하는 경우도 있다. 개발자들이 알아서 자율적으로 제대로 일할 것이라고 믿지 못하기 때문에 결과는 점점 효율성이 떨어지는 것이다. 

원칙적으로는 개발자는 거의 개발만 해야 한다. 숫자로 얘기를 하면 95% 이상의 시간은 개발에 전념할 수 있도록 해야 한다. 분석, 설계, 리뷰, 코딩 등 개발 활동에 쏟아야 한다. 중간에 방해를 하지 않도록 프로세스, 시스템이 최대한 뒷받침을 해야한다. 

대부분의 회사에서 회의는 10분의 1 정도로 줄여야 한다. 조금이라도 관련이 있는 사람은 잔뜩 불러서 하는 대규모 회의는 특히 삼가 해야 한다. 괜히 일상적으로 모여서 하는 대규모 회의도 줄여야 한다. 필요한 사람 몇명만 불러서 사안 별로 회의를 하면 된다.그렇다고 개발자가 고객, 시장, 전략을 몰라도 된다는 것은 아니다. 시간을 최대한 효율적으로 활용해서 최소 시간을 투자해서 공유를 할 수 있어야 한다. 개발자의 시간은 비싸다. 

실제로 개발자가 하루에 개발에 몇시간을 사용하는지 조사를 해보자. 80% 미만이면 심각하게 생각해야 한다. 그런 개발자는 개발을 포기하고 전문 관리자가 되는 것이 낫다. 그렇지 않다면 무엇인 문제인지 찾아서 문제를 제거하고 개발자들이 개발에 집중할 수 있도록 해줘야 한다. 이슈관리시스템을 제대로 활용하면 불필요한 회의는 많이 줄일 수 있고, 회의를 하더라도 시간을 단축할 수 있다. 회의를 줄이고 효율적으로 하는 방법은 여러가지가 있지만 다음과 같은 원칙을 지키는 것이 좋다. 

대규모 회의보다는 소규모 회의를 하고, 공유는 시스템으로 하고 의사결정이 필요할 때만 회의를 한다. 회의 전에 내용을 미리 공유해서 짧은 시간에 의사결정을 해야 한다. 회의 내용은 관련자 모두에게 즉각 공유해야 한다. 

소프트웨어 개발 경쟁력에서 핵심은 개발자다. 개발자가 많은 시간 개발에 집중할 수 있도록 하는 것은 소프트웨어 경쟁력 향상에서 가장 중요한 일이다. 이렇게 하면서도 공유, 커뮤니케이션에 문제가 없을 수 있도록 하는 것이 개발 문화, 프로세스, 기반 시스템의 역할이다.

이 글은 ZDNet Korea에 기고한 칼럼입니다.

구멍가게 될텐가? 글로벌 SW기업 될텐가?

나는 소프트웨어 스타트업 및 중소기업 관계자를 자주 만난다. 주로 소프트웨어 개발이나 마케팅 전략에 대해서 얘기를 한다. 최근에도 몇몇 기업의 대표를 만났다. 

대부분의 기업들은 국내 시장에만 머무르지 않고 해외로 진출해서 글로벌 기업으로 성장하기를 원하고 있다. 한 두명이 시작해서 세계적인 회사가 된 뉴스를 보면 우리도 그렇게 될 수 있다는 꿈을 가지게 된다. 그러기 위해서 국내에서 일단 인지도를 쌓고 고객을 확보하여 캐시카우를 만든 후에 이를 기반으로 해외 진출한다는 전략을 가지고 있는 경우가 많다. 

하지만 이런 전략은 계획대로 되지 않는 경우가 많다. 그냥 국내 시장에서 허덕대다가 그저그런 기업으로 남거나 문을 닫는다. 

물론 처음부터 해외시장은 거들떠도 보지 않고 국내 시장에서만 승부를 보는 전략도 있고 분야에 따라서 나쁜 전략도 아니다. 국내 소프트웨어 시장이 세계 시장의 2~3%에 불과하지만 지역특성이 강한 분야도 있어서 효과적인 전략이 될 수도 있다. 

하지만 국내를 발판으로 해외로 나가보자는 전략이 잘 먹혀 들어가지 않는 이유를 알아보자. 

A사는 기업용 서비스를 개발하는 회사인데 처음부터 글로벌 서비스를 목표로 시작을 한 회사다. 충분한 자본을 가지고 시작하지 않았기 때문에 먼저 돈을 벌어야 했다. 그래서 국내에서 몇몇 기업과 계약을 맺어 서비스를 제공했고, 상당 기간 고객들이 원하는 기능에 매달리느라고 글로벌 서비스에 필요한 준비를 별로 하지 못했다.

글로벌 서비스는 모든 프로세스가 완전히 자동화 되어 사람의 수동 개입이 거의 없어야 하는데 국내 고객에 대응을 하다 보니 상당 부분 사람의 노력이 들어가야 하는 반자동 서비스가 되었다. 지금은 고객이 100배로 늘어도 큰일이며 시스템의 구조를 바꾸려면 추가로 개발을 매우 많이 해야 한다. 이미 개발해 놓은 것이 많으므로 시스템 복잡도는 점점 증가하게 되었고, 이 모든 것이 미래 개발의 큰 부담이 되고 있다. 

B사는 기업용 웹 솔루션을 만드는 스타트업이다. 국내 시장에서는 어느 정도 인지도를 쌓았다. 그리고 정부 지원을 받아서 해외 진출을 하기 위해 글로벌 버전을 새로 개발하고 있다. 

국내에서 영업이 꽤 잘되어서 매출액이 급격히 늘었다. 하지만 국내 기업을 지원하느라고 개발자를 많이 채용해야 했다. 그러다 보니 많은 개발자의 월급을 주려면 상당한 매출을 계속 일으켜야 했다. 그렇게 계속 국내 고객을 발굴하고 기업들의 요구사항에 매달리다보니 처음에 계획했던 글로벌 솔루션에 투자할 시간이 점점 줄어들었다. 국내 고객이 캐시카우라서 포기할 수도 없고, 이를 위해서 많은 개발자는 계속 필요하고 이런 고리에서 빠져 나올 수가 없다. 

C사는 유럽의 작은 나라 소프트웨어 회사다. 지원수는 30명 정도지만 전세계 수많은 고객을 가진 글로벌 기업이다. 이 회사의 솔루션은 매우 단순하다. 비즈니스 전략도 단순하다. 구매도 온라인으로 이루어지고 모든 정보는 인터넷에 공개가 되어 있다. 고객지원도 온라인으로만 이루어진다. 서비스데스크 시스템을 통해서 기술문의나 사용문의를 처리하고 있다. 

고객이 전세계에 흩어져 있어서 지원을 요청한다고 방문을 할 수도 없고, 전화 지원도 언어 장벽 때문에 어렵다. 따라서 제품에 대한 문서화가 잘 되어 있고, 모든 지원은 자동화된 프로세스가 잘 구축되어 있다. 그래서 적은 개발 인원과 지원 인력으로 수많은 고객을 지원하는 것이 가능하다. 

글로벌 기업이 목표인 회사에게 국내 시장은 우선 공략 전략은 자칫 빠지기 쉬운 함정이 될 수 있다. 지역이 국내라서, 국내 고객들이 괴팍해서 그렇다는 것은 아니다. 로컬 비즈니스 전략으로 고객별 커스터마이징과 오프라인 지원에 매달리는 전략이 문제라는 것이다. 일단 이런 전략으로 시작한 기업은 '개미 지옥'에 빠진 기업과 같다. 처음에는 이렇게 돈을 번 후 멋지게 빠져나가서 성장을 하고 싶지만, 일단 발을 들여 놓으면 처음에 생각한 것과 다르게 점점 더 깊게 빠져 들어가는 '개미 지옥'이 된다. 

기술적으로도 로컬 제품을 먼저 만들었다가 글로벌 제품으로 성장하는 것은 매우 어렵다. 서비스도 마찬가지다. 패러다임을 완전히 달리 해야 하는 것이라서 처음부터 글로벌 시장을 타깃으로 한 제품을 만들지 않으면 어렵다. 

글로벌 제품의 특성은 다음과 같아야 한다. 

첫째, 소프트웨어 국제화가 잘 되어 있어야 한다. 

소프트웨어 국제화란 여러 언어와 국가를 지원할 수 있는 구조로 만든다는 것인데 국제화 전문가의 도움 없이 제대로 국제화를 하기란 거의 불가능하다. 10년 이상의 소프트웨어 국제화 경험이 있어야만 제대로 국제화를 할 수 있다. 

소프트웨어는 처음에 개발을 시작할 때부터 국제를 하는 것이 가장 좋다.국제화가 안된 소프트웨어도 처음에 영어를 기반으로 개발한 소프트웨어는 나중에 국제화가 용이하지만 그렇지 않은 경우 국제화가 힘들어진다. 또한 영어로 개발된 제품은 국제화를 하지 않아도 영어를 받아들이는 전세계 모든 회사에 판매를 할 수가 있다. 

소프트웨어 자체는 훌륭하지만 국제화에 발목 잡혀서 실패한 회사가 꽤 된다. 번역이 잘 못되거나 해당 국가의 문화나 표기 방법을 고려하지 않거나 개발 비용이 너무 과도하게 들어가서 실패를 하게 된다. 

둘째, 유지보수와 고객지원이 용이하며 거의 온라인으로 지원할 수 있도록 해야 한다. 물론 소프트웨어 품질이 높아서 장애와 지원요청이 별로 없어야 한다. 소프트웨어 장애 시 몇 번의 클릭으로 장애 리포트를 전송할 수 있도록 하고, 개발사에서는 자동으로 분석할 수 있는 시스템이 잘 구축되어 있어야 한다. 고객과는 온라인으로 소통하며 모든 이력은 데이터베이스에 기록되어서 미래의 고객 지원에 활용된다. 

요즘은 고객끼리 정보를 공유하는 서비스를 제공해서 고객지원에 들이는 노력을 더욱 절약하는 기업들이 있다. 

셋째, 기업 내부적으로는 개발에 필요한 문서가 잘 작성되어 있고, 고객에게는 충분한 정보를 문서로 제공한다. 개발 시에 꼭 필요한 문서를 충분히 잘 작성하므로 고객에게 제공되는 사용자 매뉴얼, 기술 백서 등의 문서가 자연스럽게 잘 만들어진다. 그래서 고객들은 문서를 통해서 충분히 정보를 제공 받으므로 지원 요청이 줄어든다. 물론 고객에게 정보를 제공하기 위해서 처음부터 문서화를 잘하는 것이 아니다. 개발 시에 필요한 문서를 제대로 만드는 것이 가장 빨리 개발하는 방법이기 때문에 문서를 잘 적는 것이다. 

넷째, 개별 고객의 요구사항에 흔들리지 않고 개발사가 제품의 로드맵을 주도한다. 고객의 요구사항에 귀를 기울이지만 전체를 파악하는데 노력을 하고 한 고객이 원하는 것에는 휘둘리지 않는다. 이 때문에 잃게 되는 10%의 고객보다는 나머지 90%의 고객을 유지하는데 집중한다. 따라서 소프트웨어를 급하게 개발하지도 않는다. 

다섯째, 고객이 아무리 많아도 소스코드는 한벌인 경우가 많다. 국내 소프트웨어 회사들이 가장 많이 빠지는 함정이 슈퍼 고객을 지원하기 위해서 소스코드가 갈라지거나 국제화를 위해서 별도로 개발을 하는 것이다. 눈앞의 이득만 쫓다가 수십배의 손해를 보는 경우가 허다하다. 

글로벌 회사를 계획했지만 캐시카우를 만들기 위해서 로컬 비즈니스와 커스트마이징 또는 SI를 해야 밖에 없는 상황이 있을 수도 있다. 하지만 이런 전략은 "개미 지옥"과 같다는 것을 명심하자. 절대로 빠져오지 못할 만큼 깊게 빠지지는 말아야 한다. 정신을 똑바로 차리고 있지만 않으면 영원히 못 빠져 나온다. 

가장 좋은 방법은 마약에 빠지지 말고 처음부터 글로벌 전략을 펼치는 것이다.

이글은 ZDNet Korea에 기고한 칼럼입니다.

나는 한달 동안 휴가를 갈 수 있을까?

내가 만약 한달 동안 휴가를 간다면 회사에서는 무슨 일이 벌어질까? 각자 한번 상상을 해보자.

내가 있던 없던 상관없이 회사는 잘 돌아갈까? 아니면 내가 관련된 일들이 진행되지 않아서 회사가 마비가 될까? 내가 없으면 회사가 잘 안 돌아가도 문제지만 내가 있으나 없으나 회사가 아무 일 없이 잘돌아가도 불안하다. 혹시 내가 없어도 되는 사람이 아닌가 걱정이 되기도 한다.

“유지보수가 어렵게 코딩하는 방법” 이란 책도 있다. 원제는 “How to write unmaintainable code : Ensure a job for life ;-) This essay is a joke!”이다. 이 책은 조크이지만 내가 없으면 유지보수가 몇배, 몇십배 어려워지는 온갖 다양한 방법을 소개하고 있다. 사실 본인도 유지보수가 어려워지는 방법들이다.

몇 년에 한번씩 강제로 한달 동안 휴가를 가야 하는 회사가 있다. 휴가기간 한달 동안 원격지에서 일을할 수 있다는 것이 아니다. 진짜 휴가를 가야 한다. 이런 강제 휴가제도를 만든 이유는 어느 직원이던지 그 직원이 없어도 회사가 잘 돌아가야 하기 때문이다. 업무의 특수성 때문에 한달 동안 자리를 비울수 없는 직원이 있다면 회사의 조직을 바꾸던지 프로세스를 바꿔서 다른 사람으로 대체가 가능하거나보완이 가능하도록 한다. 누구든지 한달간 휴가를 떠나도 아무런 문제가 없이 해놔야 한다.

이런 회사에서는 직원들이 언제든지 짤릴 수 있다는 불안감을 가져야 할까?

가상의 이야기가 있다. 원자력 발전소에서 일하는 홍길동은 절대로 3일 이상 휴가를 갈 수 없다. 홍길동은 오랜 노하우로 적절하게 원자로의 온도를 조절하는 특수한 능력을 가지고 있고 홍길동 외에는 그런 기술이 없다고 하자. 홍길동은 수동으로 온도 제어장치 조절이 가능한데 자동 처리 시스템을 갖추려면 엄청난 비용과 많은 추가 인력이 필요하다고 한다. 회사 입장에서는 큰 비용을 투자 하는 것보다홍길동만 잘 유지하면 적은 비용으로 발전소 운영이 가능하고 홍길동은 자신이 없으면 발전소가 돌아가지 않는 상황에 자부심을 가지고 있다. 하지만 홍길동은 격무에 시달려서 회사를 그만두거나 불의의교통사고를 당할 수도 있다. 옆 나라의 발전소에서 더 높은 연봉으로 데려갈 수도 있다.

나는 강연이나 세미나를 할 때 자주 묻는다. “지금 당장 퇴사를 해도 회사에 큰 문제가 없는 사람”. 그러면 거의 대부분 손을 드는 사람이 없다. 실제로 퇴사를 해도 문제가 없는 사람이 없을 수도 있고 다른 사람들 눈치를 보기도 한다.

반대로 “그럼 당장 퇴사하면 회사가 안 돌아가는 사람” 손을 들라고 하면 몇 사람들이 당당하게 손을번쩍 든다. 몇 사람은 떠밀려서 손을 든다. 그러면서 주변에서는 웅성웅성 말들이 많아진다. 약간의 빈소적인 말도 들려온다. 대부분의 회사에서 공통적인 현상이다.

우리 주변의 소프트웨어 회사들 중에는 개발자 한두명만 퇴사를 해도 큰 영향을 받는 회사가 많다. 회사의 경영진은 문서화도 잘되어 있고 공유도 잘 되어 있어서 문제 없다고 하는 경우도 있지만 속을 들여다 보면 유지보수에 별 쓸모도 없는 문서에 공유는 형식적으로 되어 있어서 실제로는 큰 문제지만“쉬쉬” 하는 경우가 많다. 개발자들도 자신이 없을 때 회사가 잘 안 돌아가는 상황을 그렇게 나쁘게만보지 않기 때문에 별 이슈로 생각하지 않는다.

이러한 현상 때문에 아버지가 돌아가셨는데 상중에도 회사를 나와서 일을 했다는 경우를 들기도 하고신혼여행도 제대로 못가는 경우도 발생한다.

그럼 이런 현상이 회사에는 불리하지만 개발자에게는 유리한 현상일까? 단기적으로는 그렇게 생각할수 있지만 장기적으로는 얘기가 완전히 달라진다.

나는 “당장 퇴사하면 회사가 안 돌아가는 사람”은 하루 빨리 정리를 해야 하고, “지금 당장 퇴사를 해도 회사에 큰 문제가 없는 사람”은 회사에 꼭 필요한 사람이라고 얘기한다. “당장 퇴사하면 회사가 안돌아가는 사람”이 많다면 회사가 갑자기 망해도 이상하지 않은 상황이다. 이렇게 망한 회사들은 이런이유 때문에 망한 것이라는 것을 알아채기는 쉽지 않다.

“지금 당장 퇴사를 해도 회사에 큰 문제가 없는 사람” 중에는 정말로 하는 일이 없어서 있으나 마나 한사람이 있을 수도 있지만 그건 주제에서 벗어난 얘기고 대부분 그 동안 해왔던 일들이 문서화가 잘 되어 있고, 공유가 잘되어 있으며 다른 사람이 이어 받아서 처리하는데 문제가 없는 경우다. 이런 사람은회사의 미래의 프로젝트를 위해서 꼭 필요한 사람이다.

반대의 경우는 그 동안 저질러 놓은 일이 많고 자신이 아니면 유지가 안 된다. 뭘 하나 해결하려고 해도 원 개발자에게 물어봐야 하고, 다른 사람들은 시스템에 대해서 이해하기도 어렵고 원 개발자가 한두 시간이면 뚝딱 해결할 수 있는 것을 유지보수 개발자에게 시키면 며칠이 걸려도 해결이 어렵고, 해결을 했다고 해도 또 다른 문제를 만들어 냈을까봐 두렵다. 회사입장에서는 큰 리스크가 아닐 수 없없다. 하지만 회사에서는 이런 개발자를 핵심 개발자라고 착각하고 질질 끌려 다닌다.

물론 개발자가 일부러 이런 경우는 흔치 않다. 회사의 문화, 프로세스가 엉망이니 그냥 열심히 하던대로 개발을 하다 보면 이런 현상은 십중팔구 일어난다. 특히나 개발 능력이 뛰어난 개발자들에게서이런 현상이 더 잘 일어난다. 혼자서 많은 양의 코딩을 해내지만 같이 공유하고 리뷰를 해줄 개발자가없고, 혼자서 제품 하나를 뚝딱 만들어도 유지보수에서 발을 빼기 어렵게 된다. 일부러 유지보수가 어렵게 코딩하는 사람은 없겠지만 작성해놓은 코드를 보면 “유지보수가 어렵게 코딩하는 방법” 이란 책을 공부한 사람처럼 코딩하는 경우도 있다.

이렇게 자신의 과거 업무에 발목이 잡혀있는 개발자들은 앞으로 나아가면서 성장하기 어렵다. 회사의미래 프로젝트, 좀더 어렵고 재미있는 일을 못하게 된다. 새로운 기술이나 지식을 익힐 기회는 점점 줄어들고 매일 하던 반복적인 유지보수에 매달리거나 과거에 해놓은 일의 기억을 헤집는 일을 주로 하게된다. 자신의 과거의 업무에서 자유로워지는 일은 자신의 가치를 좀더 높이는 일이다.

물론 우리나라 회사에서는 이런 것이 통하지 않는다고 주장하는 사람도 있을 것이다. 개발자를 부품으로만 생각하는 회사는 개발자가 없어도 문제없게 만들어 놓은 개발자는 언제든지 자를 수 있다. 실제이런 회사도 많이 있고 이런 회사에서 일하는 개발자라면 “유지보수가 어렵게 코딩하는 방법”을 잘 공부하기를 바란다.

개발자가 자신이 없어도 회사가 문제 없이 돌아가게 하려면 공유를 잘 해야 한다. 문화적으로 성숙되고 프로세스를 잘 갖춘 회사라면 모든 개발업무가 진행되면서 자연스럽게 공유가 되는 시스템을 갖추고 있다. 중간 중간 리뷰 과정을 다 거치고 문서화가 되며 지식과 경험이 자연스럽게 여러 사람과 공유가 된다. 이런 프로세스를 뒷받침할 기반시스템도 적절히 갖추고 있다. 공유를 위한 공유가 아니기 때문에 훨씬 자연스럽고 부담도 없다.

자신은 어떤가 생각을 해보자. 한달간 휴가를 갈 수 있을까? 회사의 모든 직원이 각자 한달간 휴가를갈 수 있을까? 그렇지 않다면 무엇을 바꿔야 할지 생각해보자.