글로벌 소프트웨어를 꿈꾸다

글로벌 소프트웨어를 꿈꾸다

김익환 지음

한빛미디어 / 2010년 9월 / 248쪽 / 15,000원



1 소프트웨어 회사가 성공하기 위한 다섯 가지 조건



혁신하든가, 사라지든가

70년까지 살 수 있는 솔개의 대부분은 40년에 수명을 다 한다. 40년이 되면 부리는 너무 길어져 먹이를 쪼기 힘들어지고, 발톱이 무뎌지고, 날개는 기름에 절고 무성해져서 사냥을 할 수 없다. 이때 엄청난 자기 갱생의 노력을 한 솔개는 살아남고 그렇지 않은 솔개는 죽는다. 부리를 일부러 돌에 부딪혀 깨뜨려서 새 부리가 나오게 만들고, 새로 나온 부리로 발톱을 쪼아 없애서 새 발톱을, 날개를 뽑아서 새 날개가 나오게 만든다. 이 노력을 6개월 동안 해서 30년을 더 살아남는다. 이 죽음과도 같은 고통을 참지 못하는 솔개는 40년에 죽는다. 70년을 사는 솔개는 이렇게 혁신에 성공하여 재탄생한다. 피터 드러커는 『위대한 혁신』에서 "혁신하든가, 사라지든가"라고 했다. 기업혁신을 다루는 많은 책에서는 혁신의 중요성과 혁신을 이루었을 때의 희망적인 메시지를 전한다. 하지만 책은 책일 뿐이다. 책을 보는 것으로 혁신에 성공했다는 사례를 본 적이 없다. 실행이 문제인 것이다.

많은 소프트웨어 회사가 혁신에 실패하고 사라졌거나 희망없는 생존을 이어간다. 대기업이라고 이런 혁신의 진리를 피해갈 수는 없다. 혁신의 중요성을 알면서도 혁신을 이루지 못하는 이유는 간단하다. 혁신에 죽음과도 같은 고통이 따르기 때문이다. 고통을 회피하고자 하는 본능에 따라 더 큰 고통이 와서 할 수 없이 혁신을 해야 할 때까지 최대한 미룬다. 솔개가 40년이 아닌 30년 때 갱생의 노력을 하지 않는 것과 같다. 솔개나 회사나 위기에 처하지 않으면 개선에 대한 필요성을 느끼지 못한다. 결국 위기에 닥쳤을 때 마지막으로 혁신할 수 있는 기회가 온다. 어쩌면 그 한 번이 마지막이다. 한 번의 기회에서 혁신을 못하면 회사는 솔개와 같이 수명을 다한다. 그러나 고통을 이겨내고 혁신에 성공하면 새로운 전기를 맞는다.

소프트웨어 회사가 성공하기 위한 다섯 가지 조건

소프트웨어 회사가 성공하기 위해 갖추어야 할 기본 조건은 무엇일까? 벤처투자가의 관점에서 투자를 할 때는 기술도 중요하고 비즈니스도 중요하니까 CEO가 누구고 CTO가 누구인지를 본다. 그리고 일단 기술이 있으면 투자를 한다. 하지만 필자가 소프트웨어 회사를 컨설팅하는 입장에서 볼 때는 다음 다섯 가지를 본다. 물론 이 다섯 가지 외에도 성공하기 위해서는 자본, 비즈니스 전략, 영업능력 그리고 마지막으로 행운이 필요하다.

기반시스템: 회사의 기반시스템에는 이슈관리시스템, 소스관리시스템, 테스트관리시스템, 빌드/릴리즈관리시스템, 프로젝트관리시스템, 작업관리시스템, 고객관리시스템, ERP등 수많은 시스템이 있는데 소프트웨어 회사에 가장 필수적인 두 개의 기반시스템을 꼽으라고 하면 소스관리시스템과 이슈관리시스템이다. 아무리 작은 규모의 개발이라고 해도 이 두 시스템을 갖추지 않고 개발한다는 것은 기적에 가깝다. 이슈, 문서, 소스코드 관리를 하면서 프로세스를 구동하는 데 필요한 기본 시스템이다. 물론 설치해 놨다고 다 똑같은 것은 아니다. 입문, 초급, 중급, 고급, 전문가 수준에 따라 효율성에 엄청난 차이가 있다. 수준의 차가 크다는 얘기다. 하지만 한 번에 전문가가 될 수는 없다. 경험이 필요한 것이므로 차근차근 수준을 높여 가면 된다.조직: 국내에는 슈퍼개발자가 많다. 개발자가 분석, 설계, 코딩, 빌드, 테스트, 기반시스템 관리 등 모든 업무를 다 한다. 그 말은 전문성이 없다는 말과 100% 일치한다. 동네 축구에서는 운동 잘하는 사람이 모든 포지션을 다 잘한다. 1970년도에는 고등학교 야구가 무척 인기였는데 그때는 4번 타자가 투수도 하는 것이 보통이었다. 프로야구에서 투수가 4번 타자인 것을 상상할 수 있을까? 그만큼 수준이 낮았던 시절이다. 전문성 있는 조직이 있어야 각 기능이 제대로 돌아갈 수 있다. 처음에는 개발자가 다 맡아서 하다가 회사가 성장함에 따라 하나씩 전문직에 일을 넘겨주는 것이 통상적이다.

프로세스: 프로세스라고 하면 '정해진 순서에 의해 정해진 산출물을 만들어 내면서 개발을 진행하는 것'이라고 간단히 설명할 수 있다. 국내에 프로세스가 광풍처럼 유행했던 때가 있었다. 마치 한국의 소프트웨어가 잘 안되는 이유가 프로세스인 것처럼 모든 누명을 뒤집어 쓴 것이 프로세스였다. 프로세스 입장에서는 억울한 일이 아닐 수 없다. 잘못하면 해를 입을 수 있는데도 인삼이 건강에 좋다고 하니까 모든 사람이 인삼만 많이 먹으면 건강해지는 걸로 착각한 것과 같았다. 글로벌 수준의 소프트웨어 회사가 되기 위해서 꼭 필요한 것이 프로세스인 것은 사실이다. 하지만 넘쳐도 안 되고 모자라도 안 되는 것이 프로세스이기에 현실에서 사용하는 방법이 매우 중요한, 진정한 소프트웨어 공학의 영역이다.

기술: 기술이야 말로 개발자의 고유 영역에 속한다. 아무리 지나쳐도 나쁘지 않다. 하지만 기술은 시대에 따라 변한다. 수많은 기술이 생겨났다 없어진다. 어떤 기술은 오래 가지만 소프트웨어 역사를 돌아볼 때 기술의 평균 수명은 3년이다. 그러므로 이런 저런 기술에 관심을 가지고 시도해 보는 것은 흥미로운 일이지만 많은 시간이 들어간다. 시간이 들어간 만큼 나중에 쓰인다는 보장도 없다. 기술은 단기적으로 필요한 만큼만 배우면서 사는 것이 효율적이다. 배고플 때 슈퍼에 가지 말라는 말이 있다. 슈퍼에 가서 먹거리를 왕창 사서 오면 결국은 안 먹고 썩어서 버리게 되는 데서 비롯된 말이다. 기술에 관한 한 당장 먹을 만큼만 사오는 것이 효율적이다.

문화: 웹 2.0의 3대 키워드인 참여, 공유, 개방은 새로운 것이 아니다. 60년 전 소프트웨어 탄생 때부터 중요시해온 소프트웨어 업계의 문화다. 다른 일에 참여도 하고 자기 것을 공유도 하고 개방도 하면 된다. 예를 들어 소스코드를 적고, 동료검토를 하고, 항상 누구나 볼 수 있게 해주는 것이 바로 소프트웨어 업계의 문화다. 소스코드뿐만이 아니라 스펙이나 설계문서 등 다른 것들도 마찬가지다. 공유나 개방을 하기 위해서는 기반시스템의 도움도 필요하고 약속된 프로세스의 도움도 필요하다. 구글에서는 입사 첫날 누구든지 모든 소스코드를 다운로드받아 컴파일해서 사용할 수 있다고 한다. 필자가 일했던 모든 글로벌 회사에서도 소스코드에 접근하는 데 제한이 없었다. 지금 소스코드를 공유하고 있지 않다면 보안과 공유 사이에서의 장 · 단점을 생각해 보기 바란다.

2 이슈관리시스템을 보면 회사를 안다



이슈관리시스템을 보면 회사를 안다

많은 기반시스템 중에서 제품의 생명주기에 관련하여 가장 중요한 이슈관리시스템과 소스관리시스템을 소개하려고 한다. 소스관리시스템은 개발자의 관점에서 보았을 때 없으면 안 되는 시스템이다. 하지만 전사적으로 보았을 때 가장 중요한 기반시스템은 이슈관리시스템이다. 때로는 버그관리시스템이라고도 불린다. 이 이슈관리시스템을 제대로 사용하고 있었다면 회사의 축소판이 여기 들어 있다고 해도 과언이 아니다. 그만큼 포괄적인 시스템이다. 필자가 회사의 역량을 파악하기 위해 가장 처음에 보는 것이 이슈관리시스템이다. 이슈의 정의를 알고 나면 놀라는 사람이 많다. 오류 혹은 버그는 당연하고 '새로운 기능'도 이슈에 포함된다. 또한 작업요청, 사소한 질문이나 의견 같은 것도 이슈에 속한다. 즉 제품에 관해 회사에서 대화의 대상이 되는 거의 모든 것을 의미한다고 보면 된다. 그러므로 이슈로 등록된 것 중에서 개발자의 구현으로 이루어지지 않는 것도 상당수라는 것을 알 수 있다. 각 회사 상황에 따라 다르지만 아마 전체 이슈 중에서 구현이 필요한 것은 반도 안 된다고 생각하면 무리가 없을 것이다. 이제 이슈관리시스템이 어떻게 사용되는지 살펴봄으로써 이슈관리시스템의 중요성을 알아보자.

- 이슈관리시스템은 대시보드 형식으로 모든 직원이 항상 모니터에 띄워 놓고 모니터링한다. 개발자의업무지시가 대부분 여기에서 온다. 물론 각자의 업무에 따라 대시보드에서 보고 싶은 정보를 화면에 적절히 설정한다.- 출근 후 가장 먼저 본다. 아침에 몇 분 정도 이슈관리시스템을 관찰함으로써 현재의 상태를 파악할 수 있다. 이것으로 오늘 하루의 일과를 예상할 수 있다. 경영진도 담당자를 불러서 보고 받는 것을 대체할 수 있다. 모두의 귀중한 시간을 절약할 수 있다.- 모든 직원이 사용한다. email이나 전화를 이용한 이슈 전달을 최소화해야 한다. 각자 자발적으로 참여하는 것이 핵심이다. 특히 전화는 개발자의 생산성을 저하시키는 주범이다.- 이슈를 등록한다. email, 전화 등 다른 모든 커뮤니케이션은 이슈관리시스템의 보조 수단으로 사용한다. 공식적인 요청은 모두 이슈 등록에서 시작된다.- 이슈는 발견한 사람이 등록한다. 즉 대리 등록은 되도록 피한다. 전체 시간이 더 걸리기도 하고 지속적으로 계속 대리인에게 의존하게 되어 모두의 생산성을 떨어뜨린다. 특히, 윗사람이 아랫사람에게 시키지 않도록 해야 한다.- 이슈 등록은 되도록 개념 단계와 같이 초기 단계에 한다. 그럼으로써 이슈 초기의 진행 과정과 내용도 기록에 남긴다.

앞서 필자가 회사의 역량을 파악하기 위해 이슈관리시스템을 본다고 했는데 어떤 점을 보려고 하는지, 무엇을 알 수 있는지 알아보자. 물론 이슈관리시스템을 제대로 사용하고 있다는 가정에서다.

- 전사적으로 제품이 몇 개나 있는지 한 눈에 알 수 있다. 또 각 제품의 버전과 컴포넌트가 몇 개나 있는지도 알 수 있다.- 어떤 제품이 회사의 핵심 제품인지를 알 수 있다. 고객이 누구인지도 알 수 있고 얼마나 많이 팔리는 제품인지도 추측할 수 있다.- 현재 각 제품의 안정성, 즉 버그나 기능 요청이 얼마나 있는지, 혹은 어제 새로 발생한 심각한 문제가 있는지를 알 수 있다.-각 제품의 개발 혹은 유지보수의 진행 상태를 알 수 있다. 즉 다음 버전이 언제 나오는지 몇 퍼센트나 이슈가 해결되었는지를 알 수 있다.- 데이터베이스로 관리되므로 필터를 이용하여 보고 싶은 정보를 항상 여러 각도로 볼 수 있다.

이렇게 수많은 혜택이 있음에도 불구하고 체계를 잡는 것은 매우 어렵다. 이슈관리시스템을 위한 프로세스도 정립하고, 시스템도 설정하고, 사용법도 익히는 데 적지 않은 시간이 걸린다. 하지만 그에 비해 얻는 혜택은 회사의 성장에 큰 역할을 한다. 일단 이슈관리시스템이 정립되면 혜택을 극대화하는 것은 의외로 쉽다. 경영진이 이슈관리시스템을 가끔 들여다보고 댓글을 달아주면 그만이다. 아무것도 아닌 것처럼 보이는 댓글로 직원의 참여도는 놀랄 만큼 올라가고 회사의 효율은 상상할 수 없을 정도로 커진다. 해보면 안다. 아마 경영진이 가장 적은 시간을 들여서 가장 큰 효과를 볼 수 있는, 시간대비 효과가 가장 큰 행위가 바로 하루에 잠깐씩 이슈관리시스템을 사용하는 것이다.

3 CTO의 역할은 아무나 대신하지 못한다



CTO의 역할은 아무나 대신하지 못한다

실리콘밸리는 벤처회사의 천국이다. 많은 벤처투자자가 대박을 꿈꾸며 벤처회사에 투자한다. 물론 대부분의 벤처회사가 실패하지만 극히 소수는 한 시대를 풍미하는 회사로 성장한다. 벤처투자자가 벤처회사에 투자할 때 보는 첫 번째 조건이 CTO가 있는가이다. CTO가 없으면 일단 탈락이다. CEO가 없으면 벤처투자가가 구해줄 수 있지만 CTO는 구해줄 수 없기 때문이다. 다른 좋은 투자 대상 회사가 많은데 CTO 없는 회사에 투자해서 고생할 필요가 없어 아예 고려도 안 한다. 아이디어만 있으면 아무나 개발할 수 있다고 주장하는 사람도 있겠지만 생각이 다른 것은 자유니 반대하지 않겠다. CEO는 회사의 비전과 돈을 책임지고 CTO는 기술에 관한 모든 것을 책임지는 것이라고 보면 된다. 장기기술전략, 실행전략, 아키텍처, 구현, 인프라구조 정립, 프로세스 등 개발에 관한 기술적인 것이라면 모두 책임진다. 그러니 CEO와 CTO를 한 사람이 수행한다는 것은 슈퍼맨과 같은 역량과 두 배의 시간을 요구한다. 한 사람이 둘 다 한다는 것은 그만큼 두 가지 역할에 모두 충실하지 못한다는 것을 의미한다.

간혹 연구소장, 개발실장, R&D부사장 등의 직함이 CTO와 혼란을 일으킨다. 이들과 CTO를 구별 짓는 가장 중요한 기준은 CTO는 인사관리를 안 한다는 것이다. 연구소장처럼 '장'자가 붙는 사람은 부서원을 관리해야 한다. '장'의 권리를 즐기는 대신에 사람관리를 위한 시간이 엄청나게 들어간다. 역시 CTO가 되기에는 시간상으로 모자란다. 외국의 CTO와 미팅을 한다고 하자. 그쪽 CTO가 "아이폰에는 멀티태스크가 안 되고 안드로이드에는 서비스가 되니까 우리는 플랫폼을 이렇게 디자인했습니다. 그래서 API가 이렇게 됐는데 당신들이 사용하기에 문제가 있는지 말해주세요"라고 물었을 때 "나중에 개발자한테 물어봐서 답해 드릴게요"라고 대답한다면 그건 CTO가 아니다. 회의를 해야 할 상대방은 기술의 대가인데 자신은 무늬만 CTO일 뿐 실제 역할이 관리자라면 대화가 표면에서 머물다가 더 이상 얘기가 진행되지 못하고 금방 종료될 것이다. 연구소장, 개발실장, R&D부사장 등의 직함을 가진 사람이 외국 회사의 CTO와 만날 때 주의해야 할 점이다.

회사에서 누가 기술적인 면에서 가장 권위가 있을까? 정상적이라면 당연히 CTO이어야 한다. 나이 때문이 아니라 실력으로 최고가 되어야 한다. 그런데 아쉽게도 국내 회사에서는 그렇지 못하다. 기술만으로 얘기하면 아마 과장 정도가 아닐까 생각한다. 위로 올라가서 관리를 하면 할수록 비즈니스 전략, 인사관리, 사업계획, 예산 등 경영에 관해서는 폭넓게 알게 되지만 깊이있는 기술지식은 점점 뒤떨어지게 된다. 왕년에 개발자였다는 것은 아무런 의미가 없다. 아름다운 추억일 뿐이다. 예를 들어 CTO라면 요새같이 스마트폰이 대세인 상황에서는 이미 아이폰이나 안드로이드 플랫폼의 특성은 직접 경험해 봐서 알고 있어야 하고 그런 것을 손으로 느낄 수 있도록 프로그래밍도 해봤어야 한다. 아래 직원이 정리해온 정보를 가지고 결정하는 것은 CTO가 아니라 관리직에 있는 연구소장 같은 사람이 하는 일이다. 연구소장이 잘못 결정하는 것을 바로 잡아주는 것이 CTO의 역할이다. 그러니 CTO가 없는 회사에서는 아래 직원 중에서 가장 설득력 있는 자료를 만들어 가지고 온 제안을 선택하게 된다. 결국 그런 결정은 과장, 차장 정도에서 이루어진다. 필자도 R&D 부사장과 CTO의 역할을 겸임했다가 결국 CTO의 일을 소홀히 하게 된 경험을 갖고 있다. 관리는 매일매일 벌어지는 전투와 같은 일이기 때문에 항상 전략적인 CTO의 일보다는 급히 처리해야 한다. 그래서 CTO의 일은 뒷전으로 밀리 수밖에 없다. CTO의 부재로 인해 미성숙한 개발자가 잘못된 결정을 하고 프로젝트를 진행하는 경우가 많다. 비즈니스 적으로도 옳은 결정을 해야 하지만 그 비즈니스를 기술적으로 실행하는 전략도 제대로 되어 있어야 회사가 성공한다. 둘 다 성공의 핵심인데 하나는 CEO가 책임져야 하는 것이고 하나는 CTO가 책임져야 하는 것이다. CEO와 CTO가 서로 얘기를 주고받으면서 조언을 받는다.

CEO는 CEO와 만나야 깊이 있는 대화가 되는 것이고, CTO는 CTO끼리 만나야 깊이 있는 대화가 된다. 연구소장이나 개발팀 부사장은 외국회사의 VP of Engineering과 만나야 대화가 될 것으로 추측하지만 현실적으로 다른 회사의 관리자와 만날 기회도 없고 만나서도 별로 할 얘기가 없다. 직원 관리기법이 서로 배울 일은 아니다. 그들은 근본적으로 만날 필요가 없는 사람들이다. 대외적인 회의는 CEO 아니면 CTO가 주로 담당한다. 물론 영업과 마케팅 쪽은 완전히 다른 세계이니 여기서 언급하지 않겠다. 그래서 CEO가 컨퍼런스에서 발표를 할 때면 기술적인 질문에 대답할 수 있는 CTO를 대동하고 다닌다. 그 둘이면 어떤 질문이 나와도 답할 수 있다.

구글의 차세대 운영체제인 크롬 OS 발표회를 보면 구글의 창업자인 세르게이도 기술적인 질문이 나올 경우를 대비해서 같이 참석해 있다가 필요할 때 그가 나서서 대답했다. 중요한 것은 어떤 기술적인 질문이 나와도 다 답할 수 있어야 CTO다. 그것이 바로 CTO의 역할이다. 직원이 만들어 준 자료나 일방적으로 발표한다면 그건 CTO가 아니다. 빌 게이츠도 은퇴하기 전까지 Chief Software Architect라는 직함을 갖고 있었다. 마이크로소프트는 최고 기술 전략책임자를 Chief Software Architect라고 부른다. 현재는 레이 오지가 맡고 있다. 그 아래 많은 CTO가 있다. 빌 게이츠는 CEO와 CTO 사이를 넘나들었는데 어떤 제품의 설계 문서를 검토하다 날짜 Format이 잘못될 수 있다는 것을 발견해 내고 질문했다는 일화도 있다. 다행히 그 팀원은 그런 버그가 있다는 것을 이미 아는 상태에서 고치지 않기로 결정을 한 것이기 때문에 큰 질책 없이 넘어갔다고 한다.