인원 늘면 꼬이는 SW개발문화의 현주소

꽤 오래 전 TV에서 혼자서 무인 자동차를 개발하고 있는 한 대학 교수의 이야기를 본 적이 있다. 20년째 혼자서 연구를 하고 있었고 조금씩 개량해서 그 당시 한적한 국도를 혼자서 달릴 수 있는 수준이었지만 복잡한 도로에서는 제대로 달릴 수 없었다. 

어린 마음에 참 대단하다는 생각을 했고 운전자 없이 도로를 달리는 차들을 상상해 보기도 했다. 그러나 그 뒤에 어떻게 되었는지는 알 수가 없다. 

하지만 현재 구글은 이미 실용적인 수준의 무인 자동차를 개발했다. 시중에 운전자가 없는 자동차가 굴러다니는 것을 볼수 있기 일보직전이다.  둘의 차이는 무엇일까? 

20년전 필자가 다니던 H사는 전국적으로 뛰어나다는 소프트웨어 개발자들이 모여들었다. 필자가 참여했던 프로젝트 중 하나는 팀원이 4명이었다. 그런데 같은 종류의 제품을 만드는 미국의 경쟁회사인 C사는 프로젝트 팀원이 400명이었다. 4대400으로 경쟁하는 것이었다. 그때는 내심 부러워했지만 그때 만약 400명의 개발자가 있었다면 미국 회사 정도 제품을 만들어 낼 수 있었을까? 나는 프로젝트 팀원이었는데 스펙을 본 적도 없다. 스펙이 없기 때문이었다. 나는 팀장이 구두로 설명하면 일을 하곤 했는데 400명의 개발자가 추가 됐어도 크게 다르지 않았을 것이다.

그 당시 H사를 다니던 뛰어난 개발자들은 전국 각지의 회사들로 흩어져서 일당백의 개발자로 일하고 있고, 들으면 알만한 수많은 소프트웨어를 개발했다. 하지만 안타깝게도 글로벌 시장에서 성공한 소프트웨어를 개발한 사례는 내 기억에는 없다. 돈을 많이 번 사례로는 게임회사를 운영한 경우가 있지만 게임의 핵심 경쟁력이 소프트웨어는 아니기 때문에 예외로 해야 할 것이다. 작은 회사를 유지하면서 건실하게 유지하고 있는 회사도 있지만 큰 회사로 성장한 경우 소프트웨어 역량은 형편없어지는 사례를 자주 보았다. 

한국에서 개인 또는 소수 개발팀이 소프트웨어를 알차게 만들어서 꽤 인기를 끄는 경우를 종종 보게 된다. 규모가 꽤 큰 외국 개발팀에서 생산하는 소프트웨어보다 괜찮은 경우도 있다. 이런 굉장한 효율을 보여주는개발팀은 대부분 10명이하의 소규모팀이다. 

하지만 개발팀이 수십, 수백명이 넘어가면 효율은 점점 떨어진다. 개발자가 1000명이 넘는 회사를 가보면 거대한 개발조직이 가지고 있는 장점을 별로 찾아볼 수가 없다. 개발자는 1000명이지만 개발자 10명짜리 회사가 100개 모여있는 것처럼 느껴진다. 팀간에 지식은 공유가 잘 안되고 협조하기도 쉽지 않다. 하나의 거대한 지식 공동체라기보다는 조직적으로 잘나눠지고 관리되는 팀일 뿐이다. 

이런 현상은 현재 일하고 있는 개발자들 탓은 아니다. 한국 개발자들도 지식 공동체가 잘 구축되어있는 회사에서 처음부터 개발을 시작했다면 어떻게 서로 지식을 공유하고 협업하는지 자연스럽게 몸에 익혔을 것이다. 그런 문화속에서 대규모 프로젝트를 이끌 수 있는 아키텍트가 탄생하기 마련이다. 하지만 그런 문화가없는 조직에서는 기업의 문화를 그대로 배울 수 밖에 없다. 

비싼 툴을 쓴다고 프로세스를 강화한다고 해서 지식공동체가 만들어지는 것은 아니고 오히려 점점 멀어지게 된다. 

지식을 공유한다고 이슈관리시스템을 쓰고 위키, KMS를 도입하지만 골프채를 바꾼다고 골프를 잘치게 되는 것은 아니다. 툴은 필요하지만 먼저 문화를 익혀야 한다. 문화는 사회에 나와서 갑자기 익히기도 어렵다. 학교에서부터 공유, 토론, 협업문화를 익힐 수 있는 수업을 위주로 문화를 구축해 나가야 한다. 

한국에서 미국에 이민을간 중학생이 미술 수업시간에 그림을 그리는데 반에서 가장 잘그렸다. 하지만 B 학점을 받았다. A 학점을 받은 학생은 자신보다 그림을 못그렸지만 그림에 대해서 설명을 훨씬 잘했다고 한다. 

미국에서는 대학수업 대부분의 과목에 토론수업이 병행되고 있다. 강의를 받고 끝나는것이 아니라 그만큼의 토론수업이 또 진행된다. 토론이 항상 몸에 베이게 되는 것이다. “토론, 까짓별거야? 우리도하면되지”라고 생각하면 오산이다. 

십여년을 토론수업을 하면서 배워온 사람들과는 문화적인 차이는 명백히 드러난다. 토론을 몸으로 익혀온사람들은 소프트웨어를 개발할 때도 적절한 커뮤니케이션과 공유, 협업이 자연스럽게 이루어진다. 

대규모 프로젝트의 성공은 뛰어난 아키텍트에 달려있다. 한국에 뛰어난 프로그래머는 많지만 뛰어난 아키텍트는 절대적으로 부족한 이유가 이런 환경에 기인한 것이라고 생각한다. 개발자 10만 양병설, 초등학생 SW 교육을 외치기 전에 문화를 바꾸는데 더 노력을 해야 한다. 

SW교육, 프로그래밍이 핵심 아니다

메르세데스벤츠의 CEO 디터는“이제 자동차는 기름이 아닌 소프트웨어로 달린다”고 말했다. 앞으로의 산업에서 소프트웨어가 차지하는 중요도를 단적으로 나타내는 말이다. 과거 전세계 제조업시장에서 1등자리를내주었던 미국이 세계 최고의 소프트웨어 기술을 기반으로 제조업 부활을 위한 용트림을 시작했다. 

우리나라 전자 회사들이 그 짧은 기간에 외국의 세계 1등 기업들을 제치고 매출에서는 세계 최고가 되었지만 점점 넘지 못할 벽으로 점점 뚜렷하게 다가오는 것이 바로 소프트웨어의 역량 차이다. 개별적인 근면 성실함과 똑똑한 머리와 치열한 의지로 외국에서 100년 넘게 이룩한 산업기반을 몇 십 년 만에 앞지른 분야도 있지만 소프트웨어 분야에서는 차이를 좁히기는커녕 점점 더 뒤쳐지고 있는 듯하다. 

과거 소프트웨어라고 하면 워드프로세서나 스프레드시트, 게임 같은 것을 먼저 떠올렸다. 하지만 사실 하드웨어에 장착되는 임베디드 소프트웨어의 시장도 만만치 않게 컸고 규모는 점점 커지는 양상이다. 소프트웨어가 제조업의 기반을 뒤흔들 정도가 됐다. 옛날에는 소프트웨어는 제조업 즉, 하드웨어의 보조적인 역할에 불과했으나 지금이나 앞으로는 소프트웨어가 오히려 기반산업이 되어가고 있으며 소프트웨어 역량이 제조업 경쟁력의 핵심이 되어가고 있다. 

세상은 소프트웨어를 중심으로 바뀌어 가고 있는데 필자가 접한 대기업을 비롯한 수많은 회사들의 대응은 무신경하기 그지없다. 몇몇 기업은 소프트웨어의 중요성을 외치고는 있지만 그 대책이 소프트웨어를 전혀 모르는 탱크 같은 추진력을 가진 경영자에게 모든 것을 맡기고 기껏해야 개발자들을 끊임없는 밤샘 작업으로 내몰고 오히려 불편한 비싼 툴을 사주고 프로세스는 과도하게 복잡하게 해서 품질을 올린다고 한다. 

경영자가 소프트웨어를 모르니 잡상인에 현혹되는 것은 당연하다. 이런 식으로 소프트웨어 경쟁력을 높인다고 하니 경쟁력이 오히려 떨어지는 것이 이상할 일이 아니다. 

다행히 몇몇 기업은 소프트웨어 전문가를 경영진으로 채용해서 진정한 소프트웨어 역량 발전에 힘을 쓰고 있지만 기업의 정치 역학 구조에서 소프트웨어 전문가들이 힘을 제대로 못쓰는 경우가 많아서 안타까움을 더하고 있다. 즉, 소프트웨어 전문 경영자들이 실력은 있는데 정치에서 밀리는 것이다.

지금 당장 기업들은 소프트웨어 역량 부족으로 발등에 불이 떨어졌지만 더 중요한 것은 미래다. 전체 산업에서 차지하는 소프트웨어의 비중은 향후 10~20년 동안 폭발적으로 증가할 것이 확실시 되고 있다. 즉, 20년 후에는 엄청난 수의 소프트웨어 개발자가 필요하게 된다. 

소프트웨어 개발자가 많이 필요하다고 해서 착실한 준비없이 급하다고 학원 같은 곳에서 개발언어 약간 가르쳐서 저급 개발자를 양산해서는 소프트웨어 경쟁력을 가질 수 없다. 급하게 부족한 인력을 보충할 수는 있겠지만 지금과 같이 열악한 소프트웨어 환경을 더 악화시키는 역할을 할 것 같은 우려가 된다. 

소프트웨어가 산업이 중심이 되는 미래를 대비하기 위해서는 초, 중, 고 모든 과정에서 필수적으로 소프트웨어를 대비한 교육을 해야 한다. 소프트웨어 교육이라고 하면 개발 언어를 가르쳐야 한다고 생각하면 눈감고 코끼리의 뒷다리를 만지는 격이다. 현재 우리나라 소프트웨어 역량이 뒤쳐지는 이유가 코딩을 잘 못해서는 아니기 때문이다. 개발 문화와 환경을 바꿀 수 있는 교육을 해야 한다. 

먼저 소프트웨어에 기초가 되는 지식을 좀더 많이 가르쳐야 한다. 수학, 논리학, 과학 등 논리적인 사고를 좀더 많이 하게 하고 뛰어난 논리력을 가지고 있는 학생들에게 좀더 많은 기회와 동기를 부여해야 한다. 

다음으로는 소프트웨어 문화를 바꿀 수 있는 교육을 해야 한다. 소프트웨어 개발에서 가장 중요한 것이 협업이다. 그러기 위해서 토론, 협동, 발표를 위주로 한 교육을 해야 한다. 과거에는 한 반에 학생이 60~70명이나 되어서 토론식 교육이 불가능했지만 지금은 20~30여명의 학생이라서 토론식 교육이 충분히 가능하다. 학교에서도 토론식 교육을 점점 증가시키고 있지만 너무 더디다. 자칫 배 떠난 뒤에 손 흔드는 격이 될 수도 있다. 좀더 과감히 비중을 늘려야 한다. 

뻔하고 당연한 얘기 같지만 학부모로서 아이들의 교육과정을 지켜보면 급격한 변화에 대응하여 무신경하고 느리기 그지없다. 

암기 잘하는 학생도 공부를 잘한다고 할 수 있겠지만 토론을 잘하고 발표를 잘하는 학생에게 좀더 높은 점수를 주고 이런 학생들을 많이 키워내야 한다. 소프트웨어 개발의 핵심 역량은 토론과 협업이다. 어릴 때부터 몸에 베어 있지만 않으면 성인이 되어서 갑자기 잘 할 수는 없다. 

학생들에게 프로그래밍을 가르치는 것은 그 후순위가 될 것이다. 이런 조건 없이 프로그래밍만 가르치고 사지선다식 시험을 본다면 지금보다 나아질 것은 전혀 없다. 프로그래밍도 토론, 협업, 발표를 융합한 교육이 되어야 한다. 

필자는 지금 우연한 기회에 영재 초등학생에게 프로그래밍을 가르치고 있다. 그 결과 초등학생들이 절대 학습시간이 부족하여 프로그래밍 실력은 성인에 비해서 떨어지지만 논리력은 성인 못지 않게 뛰어나다는 것을 알게 되었다. 사실 웬만한 개발자보다 논리력이 뛰어나기도 하고 이런 초등학생들이 개발 문화를 몸에 익히고 프로그래밍 실력까지 갖춘다면 미래에 뛰어난 소프트웨어 아키텍트로 성장할 것으로 확신한다. 우리나라는 이런 미래의 소프트웨어 아키텍트가 수천명, 수만명이 필요하다. 우리나라가 2등국가로 떨어지지 않으려면 꼭 필요하다. 

이것이 당장 학생들에게 제대로 된 소프트웨어 교육이 필요한 이유다. 

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

개발 경쟁력과 실속없는 화려한 보고서

몇 년 전 A사에서 있었던 일이다. 

A사가 그동안 진행했던 프로젝트를 경영진에게 보고하기 위해서 직원들이 보고서를 만들 때였다. 그런데 직원들 보고서가 최소 1주일 전에 완성 되어야 한다는 것이다.  경영진이 보고서를 매우 까다롭게 보기 때문에 보고서의 품질이 완벽해야 하기 때문이라고 한다. 나는 그럴 수 있다고 생각했다. 

하지만 남은 1주일 동안 진행되는 일은 매우 실망스러웠다. 경영진이 까다롭게 보는 보고서의 품질은 보고의 내용이 아니었다. 문서의 외형적인 모습이었던 것이다. 물론 내용도 중요하게 보겠지만 직원들이 특히 신경을 썼던 부분은 문서의 형식이었다. 

일단 보고서가 화려해야 하고 폰트, 정렬, 이미지, 도표 등 한눈에 딱 봐도 멋지게 보이지 않으면 안된다는 것이었다. 이런 모습을 보면서 문서의 외형적인 품질을 높이기 위해서 여러 명의 고급 인력이 허비하는 1주일이 참 아깝다는 생각이 들었다. 잠깐 동안 경영진의 눈을 만족 시키기 위해서 지불하는 비용 치고는 참 비싸다고 생각했다. 어쨌든 A사는 느린 전략 결정과 시대 흐름에 뒤쳐져서 현재 어려운 길을 걷고 있다. 

이에 비해서 내가 만난 G사는 사뭇 다른 문화를 가지고 있다. 

G사는 보고서를 작성하기 위해서 시간을 허비하는 것이 용납되지 않는다. 여기서는 좋은게 좋은게 아니다. 내부 보고 문건이 너무 화려하고 깔끔하게 작성되면 여지없이 질책이 쏟아진다. 간단한 보고를 파워포인트로 만드는 것도 용납이 되지 않는다. 대부분은 이메일 본문에 보고 내용을 간단 명료하게 작성하고 이메일로 검토 및 승인도 받는다. 

전화로 승인을 받기도 한다. 파일을 만들어도 텍스트 파일이나 워드로 핵심만 적어서 간단하게 만든다. 종이나 칠판에 작성한 내용을 사진찍어서 보고를 하기도 한다. 회의시간에 칠판에 그린 그림을 다시 문서로 만드는데 드는 시간을 아까워하는 것이다. 가끔 신입사원이 이런 문화를 모르고 예쁜 문서를 만들기도 하지만 여지없이 질책을 당하기 때문에 금방 적응한다. 

물론 외부로 나가는 문서는 형식도 신경을 쓰지만 내부 문서는 내용에 충실하고 외형을 꾸미는데는 10원도 투자를 하지 않는다. G사는 빠르고 능동적인 결정이 장점이며 시장 점유율을 점점 확대해 나가고 있다. 

나는 소프트웨어 개발 시 스펙을 작성할 때 화려한 문서는 지향하지 않는다. 대부분은 MS-워드로 작성하지만 간단한 프로젝트는 노트패드로 작성한다. 요즘은 간단한 스펙은 에버노트로 바로 작성해서 동료와 공유하기도 한다. 

MS-워드로 작성할 때도 칠판에 그린 다이어그램을 사진 찍어서 첨부하기도 한다. 특별한 규칙이 있는 것은 아니고 가장 효율적으로 작성할 수 있는 방법을 찾아서 시간을 최대한 절약하려고 한다. 규칙은 단순하다. “어떻게 하면 작성된 스펙을 가지고 개발자들이 구현을 할 수 있는가”만 생각하면 된다. 

반면 S사는 스펙, 설계의 규칙이 매우 엄격하다. 템플릿(Template)도 다양하고 UML의 여러 다이어그램을 모두 작성해야 한다. 그 이유는 UML의 표준 표기법을 잘 지켜야 서로 의사 소통이 정확하게 된다는 믿음을 가지고 있기 때문이다. 이러다보니 굳이 개발하는데 불필요한 문서와 다이어그램도 작성해야 하고 비효율적인 방법인지 뻔히 아닌 문서도 형식에 맞춰서 적어야 한다. 그렇게 해도 S사에서도 소프트웨어가 잘 개발되는 것은 아니다. 지금도 문제는 매우 많고 그럴 수록 더 많은 문서와 엄격한 규칙이 추가되곤 한다. 

많은 회사들이 비단 화려한 문서만 추구하는 것이 아니다. 화려한 시스템과 툴에도 많이 현혹된다. 유독 우리나라에서 비싸고 화려한 툴이 잘 팔리는 것을 보면 화려한 문서와 보고서를 요구하는 문화와 관계가 있을 것이다. 

소프트웨어를 가장 효율적으로 잘 개발하려면 실용주의를 추구해야 한다. 겉치레는 버리고 내용에 충실해야 한다. 경영자들이 보고서 내용보다 먼저 형식을 보고 지적한다면 직원들에게 겉치레를 중요시하라는 신호를 보내는 것이다. 

우리나라에서는 담당자들이 여러 경영진을 앉혀 놓고 브리핑하듯이 보고를 하는 모습을 종종 본다. 이런 권위적인 보고 자리에서는 당연히 경영자들이 듣고 싶어하는 얘기로 채워지고 내용도 예쁘게 포장이 된다. 보고를 한 이상 보고를 받은 사람도 결과에 대해서 책임을 지는 것이 당연하지만 이런 보고 자리에서는 결과에 대해서 보고자가 책임을 져야 한다. 

이런 틀에 박힌 보고 방법은 탈피해야 한다. 이런 보고서를 만드느라고 시간 낭비를 해서는 안된다. 이런 브리핑은 보고서를 따로 작성하지 않아도 시스템을 통해서 경영자가 직접 확인할 수 있어야 한다. 게으른 경영자를 위한 브리핑을 제외하고 나면 보고의 자리는 대폭 줄어든다. 

효율적인 보고는 진짜 중요한 내용을 경영진 또는 의사결정자에게 직접 빠르게 얘기하고 결정해야 한다. 내용은 메일이나 시스템으로 먼저 공유하고 얼굴을 보고는 핵심을 빠르게 전달하고 의논하면 된다. 굳이 회의실도 필요 없다. 정보는 이미 공유를 했으므로 최종 의논은 걸어가면서 할 수도 있고 전화로도 가능하다. 시간과 장소는 구애 받지 않는다. 

직원들은 어차피 경영진이 요구하는 보고 방식을 따를 수 밖에 없다. 매 보고 시마다 의자에 앉아서 직원들의 브리핑을 듣고 싶으면 직원들은 몇 배의 시간 낭비를 하고 있다는 것을 기억하자. 직원들이 어떻게 일했고 일하고 있는지 궁금한 것은 시스템을 통해서 모니터링을 해야 하며 직원들과는 진짜 중요한 얘기를 하자.

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

한국에는 가짜 CTO가 많다

소프트웨어 회사에서 가장 중요한 한 사람을 꼽으라고 하면 단연 CTO다. 회사 전체 기술의 총 책임자이며 기술 비전과 로드맵을 이끄는 핵심이다. 회사 비즈니스 전략을 기술에 녹여내는 중추 역할을 한다. 회사 기술을 속속들이 알며 개발에 관련된 프로세스와 문화를 발전시켜나가는 사람이다. 

뛰어난 CTO가 없는 소프트웨어 회사는 기술의 바다에서 선장 없이 헤매는 배와 같다.소프트웨어 회사가 아니어도 요즘 웬만한 회사는 소프트웨어 분야가 상당히 중요하기 때문에 소프트웨어 부문 CTO가 필요하다. 자동차 회사나 전자 회사도 소프트웨어를 이끌기 위해서는 소프트웨어 CTO가 필요하다. 

그러나 한국에서 뛰어난 소프트웨어 CTO을 접하기란 하늘에 별따기와 같다. 많은 회사들은 CTO가 아예 없다. CTO의 필요성을 모르거나 CTO를 할 만한 사람이 없는 경우가 많다. CTO가 정확하게 무슨 역할을 해야 하는지 모르는 경우도 있다. 이런 회사는 개발팀장이나 연구소장이 이런 저런 기술 이슈에 관여를 하기는 하지만 CTO의 역할을 대체하지는 못한다. 

회사에 CTO가 있어도 하는 일은 CTO가 아닌 경우가 많다. 즉, 가짜 CTO인 경우다. 명함을 받아보면 CTO라고 되어 있는데 하는 일을 보면 CTO가 아니고 연구소장 등 관리자의 역할을 하는 경우다. 주로 하는 일은 전체 개발 조직을 관리하고 여러 프로젝트의 진행을 챙기는 등의 관리 일을 많이 한다. 또 경영자에게 보고를 하기 위한 보고서를 만드는데 시간을 쓰기도 한다. 이런 일을 하면서 기술을 챙기기란 시간적으로도 불가능하다. 

원래 CTO를 할 수 없는 사람이 회사의 권유로 CTO를 하는 경우도 많다. CTO가 되려면 Technical career path에서 벗어나지 않고 꾸준히 개발자로 성장을 해왔어야 한다. 또한 아키텍트 역할을 꾸준히 해서 회사의 최고 아키텍트가 되어 있어야 한다.

그러나 우리나라에서 개발자의 경력을 꾸준히 유지하기란 여간 어려운 일이 아니다. 우리나라에서 개발자 경력을 보장해주는 회사는 몇% 안된다. 설령 개발자 경력을 보장해 주는 회사도 진짜로 개발자 경력 보장의 의미를 알고 보장해 주는 회사는 또 몇% 안된다. 그러다 보니 진짜 개발자로서 경력을 보장 받으면서 꾸준히 성장하는 비율은 내 생각에 1%도 안된다. 

이런 환경에서 진짜 CTO의 자격과 실력을 갖춘 개발자가 나오기란 거의 기적과도 같은 일이다. 

B사는 CTO의 필요성을 인지하고 C사의 연구소장을 CTO로 모셔왔다. 하지만 C사에서 연구소장의 역할은 관리자였던 것이다. 그러다보니 B사에서 CTO가 제대로 CTO 역할을 하기란 어려웠다. 그 뒤에 CTO를 다시 바꿨지만 새로운 CTO도 경영자 출신으로서 진짜 CTO역할을 하기에는 적합하지 않았다. 

가짜 CTO들은 회사의 기술을 속속들이 모른다. 개발자 출신인 경우도 있지만 관리와 개발을 넘나들다 보니 이제는 기술을 속속들이 모르고 피상적인 결정밖에 못하는 경우가 많다. 이 정도의 기술 리더십으로 본인이 CTO인줄 착각하는 경우도 있다. 역할은 CTO인데 실제로는 관리를 시키는 회사도 많다. 관리란 대단히 많은 시간과 노력을 필요로 하기 때문에 관리를 하면서 기술을 제대로 챙기기란 쉽지 않다. 

한국에서 뛰어난 CTO를 만나보기 힘든 현실은 한국 소프트웨어 개발 환경이 이렇게 열악한 이유 중 중요한 하나다. 소프트웨어를 제대로 개발하기 위해서 개발 문화의 발전보다는 프로세스의 강화로 접근하는 이유도 CTO의 부재인 경우가 많다. 

소프트웨어를 잘 모르는 경영자나 관리자는 문서화를 잘하고 엄격한 프로세스를 철저히 지키면 소프트웨어가 제대로 개발 될 것으로 착각한다. 공장에서 제품 조립하는 것처럼 생각하는 것이다. 뛰어난 소프트웨어 CTO가 있다면 회사에 어떤 프로세스와 문화를 도입해야 회사의 현실에서 가장 소프트웨어를 효율적으로 개발할 수 있을지 판단하고 이끌어갈 수 있다. 

CTO가 필요하고 지금 당장 아무나 CTO로 임명을 할 수는 없다. 외부에서 뛰어난 CTO 후보를 찾는 것도 한 방법이지만 한국에서 개발자로 20~30년 꾸준히 성장한 개발자를 찾기란 매우 어렵기 때문에 이 또한 쉽지 않다. 시간이 걸리더라도 회사 내부에서 개발자들의 경력을 보장해주고 뛰어난 개발자일수록 관리로 시간을 빼앗기지 않고 개발자로서 성장을 해서 미래의 CTO가 될 수 있도록 여건을 만들어 줘야 한다. 외국에서 CTO를 데려오는 방법도 있지만 언어적인 장벽과 문화적인 괴리 때문에 적응하기 쉽지는 한다. 

벤처투자자들도 소프트웨어 회사에 투자를 할 때 가장 중요하게 보는 인력은 CTO다. 뛰어난 CTO는 회사의 성공에 중요한 열쇠다. 지금이라도 회사에서 가장 뛰어난 개발자들이 개발팀장이다 연구소장이다 해서 관리에 메어 있다면 이들이 미래와 기술 조타수가 없는 회사의 미래를 걱정해 봐야 한다. 

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

SW개발, 착한 리더보다 독한 리더가 낫다

몇년전 A사에서 이슈관리 시스템 도입에 대해서 경영자와 의논한 적이 있다. A사는 이슈관리시스템을 사용하고 있지 않았고 버그만 엑셀 파일로 관리하고 있었다. 

이슈관리시스템이 꼭 필요한 상황이었고 당장이라도 도입해야 했었다. 하지만 경영자는 결단력있게 결정을하지 못하고 일단 모든 직원들이 공감을 할 수 있도록 설득을 해야한다는 것이었다. 그렇게 직원들을 설득하는데 시간이 소요되고 결정을 해야할 시점에는 다수결로 결정해야한다고 했다.

얼핏들으면 경영자가 독선적이지 않고 직원들의 마음을 헤아린다고 생각할 수 있다. 이런 경영자는 직원들이 싫어하는 일은 안하려고 한다. 직원들이 싫어하는 것을 하게될 경우 직원들의 호응도 떨어질 것이고 결국 실패할것이라는 것이다. 그렇게 다수결에 의한 결정으로 이슈관리시스템 도입에 실패한다면 과연 회사에 잘된 결정일까? 잘못된 결정일까? 

사회가 민주화 되다 보니 민주화를 해야할 것과 그렇지 않은 것이 헷갈리는 경우가 발생한다. 개혁에 대한 중요한 결정을 다수결로 결정하는것은 어리석은 짓이다. 그 이유는 대부분의 직원은 변화를 싫어하기 때문에 회사에 필요한 결정이 다수결로 통과되기는 어렵다. 통찰력을 가지고 있는 경험이 많은 리더가 과감하게결정해야 한다. 직원들 90%가 반대한다고 해도 회사에 꼭 필요하다고 생각하면 결단을해야 한다. 

소프트웨어 회사에서 민주적인 경영자는 두 부류가 있을 수 있다. 

첫째, 소프트웨어 개발에 대해서 잘모르는 경영자다. 

소프트웨어 개발에 대해서 잘 모르기 때문에 팀장들이 하는 얘기를 그대로 들어줄 수 밖에 없는 경우가 많다. 결국 개발자들이 편한대로 회사를 이끌다가 주먹구구식 개발에서 못벗어나게 된다. 변화는 꼭 필요하나적응하기 전까지는 불편하고 거북한 것이기 때문에 누가 강요를 하지 않으면 변화하기 어렵다. 

반대로 개발도 잘 모르면서 독재적인 경영자도 있다. 이런 경영자는 개발팀에 대한 신뢰도 부족하고 본인이개발팀을 뜯어고쳐보려고 다양한 시도를 한다. 

그러면서 개발팀에 진짜로 필요한 변화가 무엇인지 잘모르고 엉뚱한것을 강요하기 시작한다. 엉뚱한 기법을 도입하기도 하고 황당하게도 비싼시스템을 구축하기도 한다. 회사역량으로는도저히 쫓아가기 어려운 복잡하고 무거운 프로세스를 도입하기도 한다. 대기업에서 흔히 이런 일들이 벌어진다. 알지도 못하면서 독선적인 개발자는 모르면서 민주적인 경영자와 똑같이나쁘다. 

둘째, 과거에 주먹구구식으로 개발 꽤나 해본 경영자다. 

이 경영자는 코딩은 좀 해봐서 개발에 관련된 얘기를 하면 대충 알아 듣기는 하나 정작 회사의 미래를 위해서 무엇이 필요한지는 잘모른다. 과거 독재형 경영자에 대한 나쁜 기억도 있고 개발자들의 얘기를 잘 들어주는 마음씨 좋은형과 같은 경영자가 된 경우다. 

개발자들이 이런저런 고충이 있다고할 때 내용을 꽤나 잘 이해한다. 그래서 개발자들의 불만은 무시하지 않고 들어주려고 한다. 그러다보니 정작 필요한 개혁은 못하고 사사건건 개발자들을 설득하려고하고 다수결로 결정을 하려고 한다. 개혁을 통해서 앞으로 나아가지 못하고 주먹구구식 개발에 머물러 있거나 기형적인개발 형태로 발전하기 쉽다. 

경영자는 독해야 한다. 독재를 말하는것은 아니고 통찰력이 있어야 하고 과감히 추진을 해야 한다. 마음씨좋은 동네형 같은 경영자가 되어서는 안 된다. 보통의 경영자는소프트웨어 개발을 잘 알기 어렵다. 그래서 CTO가 필요한 것이다. 소프트웨어 개발과 기술에 관련된 결정은 CTO가 하는 것이다. 

필자가 만나본 소프트웨어 회사는100여개가 넘는데 그중에서 진짜 CTO가 있었던 소프트웨어 회사는 한손가락을 꼽고도 손가락 몇개가 남는 정도였다. 그만큼 CTO에 대한 인식도 부족하고 CTO급 역량을 가진 개발자가 부족한 것이 우리나라의 현실이다. 

이슈관리시스템 도입에 주저하고 다수결 결정을 시도했던 A사는 수년이 지났지만 여전히 과거의 개발방식에 머물러 있고 어려움을 겪고 있다. 이제는 회사 내부구조가 과거보다 몇 배 복잡해져서 변화를 하기는 점점더 어려워지고 있다. 

회사는 성장하는 과정에서 변화를 해야하는 결정적인 순간이 온다. 그 시기를 놓치면 기회는 또 다시 오지않는다. 개발자가 30명일때 개발 방식과 프로세스를 바꾸지 못하면 개발자가 100명이 되고 고객이 몇배로많아진 시점에서는 바꾸기 더 어렵다. 

결정적인 시기를 놓치면 영원히 좋은 시기는 오지 않거나 몇배의 고통을 감내해야 한다. 

이런 다수결 결정은 개발할 때도 종종 벌어진다. 소프트웨어 개발은 수많은 결정의연속이다. 아키텍처를 결정할때도 많은 결정을 해야 한다. 예를들어서 자바로개발할까 C++로 개발을 할까 팽팽히 맞서있는 경우 개발자들이 자신들이 좋아하는 개발언어를 주장하면서 한치도 물러서지 않는다고 하자. 이때 다수결로 결정하는 경우가 있다. 

다수결은 점심메뉴 결정할 때나 쓰면 된다. ,자바로 개발해야 하는 이유와 C++로 개발해야 하는이유를 제대로 설명하고 끝장을 보더라도 토론을 해서 결정해야 한다. 이때 회사의 경영전략과 비전 등을 모두 고려해야한다. 끝까지 결론이 안나면 CTO가 결정하면 된다. 

경영자에게 민주적 행동을 기대해서는 안 된다. 그만큼 경영자는 자신의 결정에 책임이 따른다. 이런 책임을 피하려고 민주적으로 행동한다면 죽도 밥도 안 된다. 자신의 결정을 책임지지 못하고 직원들의 결정을 따라야할 만큼 무능하다면 경영자 자리에서 물러나는게 낫다. 

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

개발자에게 재택 근무가 필요한 이유

과거 서울 남부의 경기도에서 소프트웨어 개발자를 채용할 때였다. 서울에서 별로 멀리 떨어져 있지 않은 경기도에 있는 곳인데도 많은 지원자들이 거리상의 문제로 지원을 포기 했고, 특히 서울 북부에 사는 사람들은 인터뷰 시에도 출퇴근의 어려움에 대한 걱정을 토로했다. 

얼마 전 한 소프트웨어 회사는 서울에서 판교로 사옥을 이전했다. 그런데 서울 북부나 일산 등지에 사는 직원들을 주축으로 많은 개발자들이 회사 이전과 동시에 퇴사를 했다. 특히 몇몇 핵심 개발자들의 퇴사는 회사의 큰 손해가 아닐 수 없었다. 

아직도 우리나라 소프트웨어 회사의 근무형태는 농업사회에서 보여주는 전통적인 근면 성실을 강조하는 근무 시스템에서 크게 벗어나지 못하고 있다. 시간에 맞춰서 출퇴근을 하고 야근까지 하면서 상사에게 오랜 시간 열심히 땅을 파는 모습을 보여줘야 ‘열심히 일을 하고 있구나’ 하며 안심을 한다. 이런 현상을 보면 소프트웨어 개발이 지식 산업이 아닌 노동집약적 산업이라고 오해하고 있다는 생각이 든다. 

이렇게 시간 딱딱 맞춰서 사무실 자리에 앉아서 일을 해야 하는 시스템은 많은 한계를 가지고 있다. 대한민국이 아니라 미국이라면 어떨까? 거리의 제약은 수십배로 커진다. 많은 개발자들은 회사 근처로 이사를 하기도 하지만 재택 근무 형태로 일하는 개발자도 많다. 

재택 근무가 가능하면 회사에 꼭 필요한 개발자를 거리의 제약 없이 채용 할 수 있다. 같은 재택근무라도 상황에 따라서 근무 조건은 매우 다양하다. 일주일에 한번씩 출근을 하기도 하고 아예 원격으로 일하는 개발자들도 있다.

우리나라에서는 직장이 너무 멀어서 출퇴근에 2, 3시간씩 걸려도 아이들 학교 문제도 있고 직장을 옮길 때마다 이사를 하기는 쉽지가 않다. 그래서 개발자 채용에 거리 제약이 있고 회사에 꼭 필요한 개발자인데도 채용하기 어려운 경우도 많다. 

재택근무가 일반적이지 않은 이유는 옆에 앉아 같이 일하지 않으면 일이 제대로 진행되지도 않고 어떻게 일을 하고 있는지 알 수도 믿을 수도 없기 때문이다. 같이 모여서 일하지 않으면 일이 제대로 진행되지 않는다. 

필자는 여러 회사에서 강연이나 세미나를 할 때 종종 “여러분이 모두 회사에 나오지 않고 집에서 원격으로 일하면 어떻게 됩니까?”라는 질문을 한다. 100%의 회사들이 일이 전혀 제대로 진행되지 않을 것이라고 얘기를 한다. 개발자들은 허무맹랑한 질문이라는 표현을 하기도 한다. 이는 단지 재택근무가 가능한지 불가능한지 문제는 아니다. 

재택근무가 불가능한 회사는 문화적으로 프로세스적으로 개선할 점이 많은 회사다. 회사가 개발에 필요한 시스템을 잘 갖추고 있고 공유와 문서화가 잘 되어 있으면 재택근무는 그렇게 어려운 일이 아니다. 오히려 집에서 일하는 것이 더 효율적인 경우가 많다. 

재택근무가 불가능한 회사에서는 개발자들이 수시로 물어보고 의논을 하고 회의도 해야 한다고 한다. 이런 환경을 보면 회의가 너무 많고 공유와 문서화가 잘 안되어 있다는 것을 단적으로 알 수 있다. 문서나 시스템으로 대부분의 내용은 공유하고 대부분의 커뮤니케이션은 시스템을 통해서 해야 한다. 회의도 스카이프등을 이용해서 원격으로 할 수 있다. 

꼭 대면회의가 필요한 경우에 회사를 나오면 된다. 이런 환경이 갖춰지면 재택근무가 가능하다.

재택근무를 하면 개발자들이 열심히 일하는지 알 수 없어서 그렇게 할 수 없다는 회사 관계자도 만난 적이 있다. 하지만 회사에 있으면 열심히 일하는지 알 수 있는가? 시스템, 문화와 프로세스가 제대로 되어 있으면 개발 성과와 결과물이 시스템에 제대로 남고 동료 검토를 통해서 동료들이 서로 누가 어떻게 일하는지 다 알고 있다. 

옆에서 일하나 멀리서 일하나 다 알 수 있다. 하지만 그렇지 않으면 옆에서 일해도 커뮤니케이션이 어렵고 누가 열심히 일하고 누가 놀고 있는지 잘 알지 못하는 경우가 많다. 

지금 당장 이런 성숙된 문화와 효율적인 프로세스와 시스템을 갖추지 않고 재택근무를 추진한다면 어떻게 될까? 우려하고 있는 모든 문제가 드러날 것이다. 재택근무는 거리의 제약을 뛰어넘어 뛰어난 개발자를 채용할 수 있게도 할 뿐만 아니라 가정에 사정이 있는 개발자도 회사를 그만두지 않아도 된다. 

가정 사정상 아이를 돌보기 위해서 회사에 10시부터 3시까지 밖에 있지 못하는 뛰어난 개발자가 있다고 하자. 이렇게 일하는 것을 어떻게 허용할 것인가? 누구는 일주일에 이틀밖에 회사에 나올 수 없다고 하자. 이런 개발자가 회사에 꼭 필요한 사람이라면 채용해서 활용할 수 있을 것인가? 

재택근무는 그 자체로도 필요하고 회사의 문화나 프로세스의 성숙도를 가늠할 수 있는 지표로 볼 수도 있다. 필자는 회사에서는 야근을 별로 하지 않고 야간과 주말을 가리지 않고 회사의 시스템에 붙어서 이슈를 확인하고 의논을 하며 코드리뷰를 하는 등스스로 찾아서 일을 하는 것이 일상화 되어 있다. 가족이 나를 필요로 할 때 가족과 지낼 수 있으며 언제 어디서나 일할 준비가 되어 있고 일을 할 수 있다. 주말에도 굳이 회사에 나가지 않아도 원격으로 쉽게 일할 수 있다. 시간, 공간적인 제약은 별 문제가 되지 않는다. 

우리 회사는 개발자들의 재택근무가 가능하지 생각해보자. 현재는 어렵다는 생각이 든다면 그 이유가 회사에서 모여서 일할 때도 비슷한 문제를 가지고 있을 가능성이 높다. 어떻게 고쳐나가야 하는지 생각해보자. 재택근무가 가능한 시스템이 회사의 개발 문화 성숙도를 한층 높여줄 것이다.

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

SW업계에는 망치를 만드는 사람이 많다

누군가 빌딩을 만드는데 망치도 못도 다 만들어 쓴다고 하면 어떤 생각이 드는가? 빌딩을 만드는 사람은 망치와 못은 사다가 쓰는 것이 훨씬 낫다는 것을 누구나 알고 있다. 하지만 소프트웨어 업계에서는 망치와 못을 직접 만들어서 쓰는 사람들이 매우 많다. 소프트웨어 업계에도 망치와 못을 전문적으로 만드는 회사가 꽤 많지만 우리나라에서는 장사가 잘 안 되는 것이 현실이다. 

이같은 상황은 흔히 NIH(Not Invented Here) 신드롬이라고 불리기도 한다. 우리나라의 경우 더 심한 경향을 보이고 있고 이유도 매우 다양하다. 기업간에 협업이 잘되어야 망치회사도 흥하고 망치를 사다 쓰는 회사도 직접 만들어 쓰는 것보다 훨씬 효과적으로 소프트웨어를 개발할 수 있다. 망치 회사가 흥해야 망치를 만드는데 필요한 툴을 만드는 회사도 흥해서 덩달아 여러 회사가 잘되게 된다. 그런데 왜 우리나라에서는 이렇게 기업간의 협업이 잘 안 되는 것일까?

나는 여러 소프트웨어 관계자를 만나는데 엔진, 라이브러리 류의 소프트웨어를 개발하는 회사들은 국내 시장의 특수성에 대해서 하소연을 한다. 자신들의 솔루션이 국내 소프트웨어 회사들에게는 별로 인기가 없고 해외에서는 찾는 사람이 많다고 한다. 국내에서는 특히 조심을 하는 것이 기업들은 가격을 후려치려고 하고 데모를 보여주면 그대로 흉내 내서 만들기도 한다는 것이다. 물론 엉터리로 흉내는 내는 것이지만 이런 식으로 국내에서는 별로 비전이 없다고 한다. 

기업들은 자신들의 전문 분야에 집중하고 전문 분야를 개발하는데 필요한 툴이나 시스템은 다른 기업과 협력을 하는 것이 좋은데 이런 협력이 잘 안 되는 이유를 한번 살펴보자. 

첫째, NIH(Not Invented Here)신드롬이다. 

자신들이 최고라고 생각하면서 자신들이 직접 개발하지 않은 것은 배척하는 현상이다. 이런 개발자들을 인터뷰해보면 자신들이 개발하는 것은 너무 어려워서 자신들, 자신의 회사에서 밖에 개발하지 못한다는 얘기를 한다. 이와 똑같은 현상이 여러 기업에서 벌어지고 있으므로 똑똑한 사람들은 여기 저기 많이 있으며 외부의 창의력과 좋은 아이디어도 받아들일 마음가짐이 되어야 한다. 

세계적인 3D 설계 소프트웨어를 개발하는 오토데스크(Autodesk) 사는 진작부터 3D그래픽엔진은 테크소프트3D(TechSoft3D)사 엔진을 사용하고 있다. 그래픽관련 부분은 전문업체에 맡기고 자신들은 설계 애플리케이션에 집중하기 위해서다. 

둘째, 근시안적으로 비용을 절약하려는 경우다. 

요즘은 오픈소스 소프트웨어가 넘쳐나서 외부의 도움을 받을 수 있는 라이브러리, 툴, 컴포넌트 등이 많지만 여전히 상용 소프트웨어의 도움이 필요한 분야도 많다. 때로는 오픈소스와 상용 소프트웨어 사이에서 저울질을 해야할 때도 있다. 라이선스 계약에 따라서 제품을 팔 때마다 몇 % 또는 얼마의 비용이 계속 발생하기 때문에 커다란 결정이 아닐 수 없다. 

상용 소프트웨어를 활용하면 라이선스 비용 외에는 커다란 추가 비용이 없이 본연의 개발에 집중할 수 있다. 하지만 라이브러리, 툴, 엔진류를 직접 개발하면 개발 비용이 꾸준히 들어가게 된다. 오픈소스를 이용할 경우에도 이를 학습하고 유지하기 위해서 상당한 비용이 들어간다. 소프트웨어는 아기처럼 한번 탄생하고 나면 먹여주고 재워주고 비용이 계속 들어간다. 

초기 개발 비용의 수십배, 수백배가 들기도 한다. 상용 소프트웨어를 구매하는 비용은 명확하게 비용으로 보이지만 직접 개발하는데 들어가는 비용은 초기 개발비용만 고려해서 우습게 보는 경향이 있다. 하지만 대부분의 경우 직접 개발하는데 드는 비용이 상용 소프트웨어를 사다 쓰는 비용보다 훨씬 많이 들어간다. 게다가 더 큰 문제는 회사에서 본연의 제품에 집중하지 못하고 망치 만들고 못 만드는데 노력이 분산 된다는 것이다. 심지어는 망치를 잘못 만들어서 집을 제대로 만들지 못하기도 한다. 

물론 무조건 상용 소프트웨어를 써야 한다는 것은 아니다. 직접 개발을 하거나 오픈소스를 활용하는 것이 좋은 경우도 아주 많다. 여기에 들어가는 비용을 절대로 사소하게 생각하면 안된다는 것이다. 상용 소프트웨어라 하더라도 협력하기에 따라서 표준 제시 가격보다 획기적인 라이선스 조건으로 계약을 하는 것은 아주 흔한 일이다. 서로 윈윈할 수 있는 조건만 잘 맞는다면 가격은 그렇게 큰 장애물이 아니다.

셋째, 우리는 다르다고 생각하는 것이다. 

개발에 필요한 기반시스템을 구축해야 하는데 회사의 프로세스가 다른 회사들과 달라서 사다 쓰지 못하고 직접 개발을 해야 한다고 주장하는 경우를 많이 보았다. 한 예가 이슈관리시스템이다. 버그추적시스템이라고도 한다. 자신들의 회사는 개발 프로세스가 일반적인 경우와 달라서 거기에 맞추느라고 직접 개발을 해서 쓴다고 한다. 

하지만 대부분의 경우 우물 안의 개구리 같은 생각이다. 예외적인 몇 가지 경우를 제외하고는 자신들의 프로세스 자체가 잘못되거나 비효율적인 경우다. 그런데 그런 프로세스가 옳고 이에 맞는 시스템이 없다고 착각을 하고 있는 것이다. 시중에는 Mantis, Redmine, Jira 등 좋은 이슈관리, 버그추적 시스템이 많이 있고 이런 툴을 제대로만 사용한다면 좋은 개발 문화도 덤으로 얻을 수 있다. 자신들의 프로세스가 이런 툴과 맞지 않는다면 툴을 직접 개발하기 보다는 프로세스를 툴에 맞추는 것이 나을 가능성이 훨씬 높다. 

넷째, 상용 소프트웨어에는 없는 기능이라서 직접 개발해야 한다고 주장하는 경우다. 

여러 상용 소프트웨어 또는 오픈 소스를 조사해봐도 99%는 만족하는데 1% 기능이 부족해서 사용하지 못하는 경우도 많다. 그런데 예상외로 상용 소프트웨어를 만드는 회사들은 추가 기능 개발 요청에 상당히 적극적인 경우가 많다. 그런데 그런 시도를 해보지도 않고 그냥 포기를 하고 직접 만든다고 하곤 한다. 

당장 오늘 내일 필요한 것이 아니고 기획단계에서부터 검토를 할 경우 수개월의 여유기간이 있고 이 기간 동안에 추가 기능을 개발할 회사는 얼마든지 찾을 수가 있다. 하지만 이렇게 계획적으로 개발을 하지 않고 당장 필요하다고 하면 외부 업체와 협력할 시간적인 여유는 없게 된다. 급하다고 직접 만들기도 하는데 이는 새로운 문제의 시작일 가능성이 높다. 

영어 또한 상당히 큰 장벽이다. 이런 것을 조사하고 추가 개발을 요청하고 협력 방안을 조율하려면 어설픈 영어 가지고는 부족하다. 영어도 잘하고 소프트웨어 업계가 어떻게 돌아가는지도 잘 알아야 하기 때문에 그냥 영어만 잘하는 사람 가지고도 안 된다. 그래서 영어 실력이 부족하다 보니 시도도 못해보거나 시도를 해보다가도 매끄럽게 협력이 잘 안되는 경우가 많다.

소프트웨어 회사들이 다양한 소프트웨어를 개발하고 서로 협력해서 서로 키워가는 것은 전체 소프트웨어 생태계의 성장에 중요한 역할을 한다. 그런데 빌딩을 만드는데 집중할 업체에서 망치를 만드는데 신경을 쓰고 망치 업체는 망하고 이런 일이 반복되면 소프트웨어 생태계는 점점 쪼그라들고 만다. 

개발자들도 문제다. 기술을 잘 모르는 경영자들은 이런 판단을 직접 할 수는 없다. 개발자들에게 망치를 만드는 것이 좋은가, 사다 쓰는 것이 좋은가 물어볼 때 위에 제시한 이유들을 들어서 직접 개발해야 한다는 주장을 하는 경우가 압도적으로 많다. 잘못된 판단으로 빌딩을 만드는 회사는 망해도 개발자에게는 망치를 만드는 기술이 남았다고 생각할지는 몰라도 망치 전문업체의 기술에 비하면 “새발의 피”에 불과한 기술일 뿐이다. 

각 기업에서 이런 잘못된 판단이 이루어지는 이유 중 하나는 CTO의 부재 때문이다. 이런 결정은 회사의 미래에 매우 중요한 결정이기 때문에 개발자 한 명의 의견을 들어서 결정하는 것도 위험하고 회사의 기술을 책임지는 CTO가 결정을 해야 한다. 

소프트웨어 개발은 개인간의 협업도 중요하지만 기업간의 협업도 매우 중요하다. 내 것이 최고라는 생각을 버리고 서로 협력을 할 때 전체 소프트웨어 생태계가 좀더 나아질 것이다.

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