소스코드는 어디 있나요?

나와 우리 회사에서는 소프트웨어 관련 경영 및 공학 컨설팅을 주로 하지만 드물게 개발을 해야 할 때도 있습니다. 이런 경우 고객 회사의 개발자와 협업을 하게 되는데 "소스코드는 어디 있나요?"라는 질문을 먼저 시작합니다.

"소스코드는 어디 있나요?"라는 질문은 Subversion등과 같은 소스코드관리시스템이 어디 있냐는 질문이고 모든 소스코드는 당연히 거기에 저장되어 있고 소스코드가 저장되어 있는 Repository와 Path만 말면 Build script를 찾아서 빌드까지 한번에 끝낼 수 있을 것으로 기대하고 하는 질문입니다. 사용자 ID만 등록하고 필요한 권한만 열어주면 더이상 질문할 것도 없이 협업 준비는 끝나는 겁니다.

그런데 이렇게 해피하게 준비된 경우는 아직 본적이 없습니다.

대부분 아래와 같은 답변들이 돌아옵니다.

• 내 PC에 소스코드가 저장되어 있습니다. 
• 아직 정리가 안되서 소스코드관리시스템에 등록하지 않았습니다.
• 빌드는 IDE(Eclipse 등)에서 해야 합니다.
• 빌드하기 위해서는 이런 저런 라이브러를 알아서 직접 설치해야 합니다.
• 아참, 설정을 이렇게 바꿔야 하는데 깜빡했습니다.
• 지금 내가 소스코드를 고치고 있어서 공유가 어렵습니다.

이런 얘기가 진행되는 동안에 일은 정상적으로 진행이 되지 못하고 여러 번 만나서 대화로 소스코드 공유 문제를 해결해나가야 합니다. 

혼자서 또는 개발자들끼리 익숙해져서 나름대로 방식으로 소스코드를 관리하면서 스스로 아무 문제가 없다고 생각하고 있는 개발자들은 냄비 안에서 물이 점점 뜨거워져서 죽는 개구리처럼 소스코드관리 문제가 점점 커져서 문제가 얼마나 심각한지 인식하고 있지 못하고 있는 겁니다. 이는 기본 중에 기본으로 자꾸 소스코드 관리 문제를 가지고 얘기를 하면 민망하고 한심하기도 합니다.

소스코드를 꽉 쥐고 요청하는 사람들에게 '모이'주듯이 하나씩 던져 주는 개발자들은 이로 인해서 얼마나 많은 자신의 시간을 낭비하고 있고 정작 자신이 제대로 개발할 시간은 모자라고 회사에도 손해를 끼치며 자신의 발전도 가로막는다는 것을 알아야 합니다.

정상적인 경우는 다음과 같습니다.

개발자가 1명이든 100명이든 1000명이든 상관없이 모든 소스코드는 당연히 소스코드관리시스템에 등록이 되어 있어야 합니다.  구차하게 이거 저거 물어보지 않아도 소스코드가 저장된 경로만 알면 누가나 소스코드를 Check out해서 클릭 몇 번이면 Build Script를 찾아내서 즉시 빌드를 할 수 있어야 합니다. 당연히 컴파일러 등의 빌드 환경은 설치가 되어 있어야죠. 여러명이 동시에 소스코드를 마구 고쳐도 전혀 걱정할 필요가 없어야 합니다.

이때 구차하게 이거 저거 물어 봐야 빌드가 되고 IDE를 실행 해야 하고, 빌드 중간에 명령어를 입력해야 하는 등의 바로 알기 어려운 행위들을 해야 하면 안됩니다.

이 정도는 되어 있어야 Daily Build가 가능해지고 프로젝트 내내 소스코드 관리 비용을 최소화 할 수 있습니다.

이 정도는 되어 있어야 엄청 복잡한 소스코드 상황을 깔끔하게 관리할 수 있습니다.

이 정도는 되어 있어야 내가 휴가를 가도 아무나 빌드를 할 수 있습니다.

이 정도는 되어 있어야 개발자들이 빌드를 하지 않고 빌드 담당자에게 빌드를 맡길 수 있습니다.

이 정도는 되어 있어야 누구와도 심지어는 외부인과도 협업을 할 때 말 한마디면 소스코드 공유 준비는 끝납니다.

이 정도는 되어 있어야 개발자는 진짜 개발에 집중할 수 있습니다.

이게 뭐 큰 일이냐라고 생각할지 모르지만 이렇게 생각하는 개발자는 위에서 얘기한 기초 중의 기초가 안되어 있다고 생각하면 됩니다.

소스코드 관리는 워낙 기초이기 때문에 누구나 제대로 방법만 익히면 제대로 수행하는데 오래 걸릴 일도 아닙니다. 똑똑한 개발자라면 일주일이면 방법을 다 터득합니다. 분석, 설계 작업이 방법을 제대로 익히고도 제대로 하는데 수년이 걸리는 것과는 안전히 딴판입니다. 그럼에도 아직도 많은 개발자들이 소스코드 관리를 제대로 하고 있지 못하거나 제대로 하려고 흉내는 내는데 엉뚱한 곳에서 헤매는 경우가 많습니다. 원리는 매우 간단한데 말입니다.

소프트웨어 개발이라는 것이 협업이라는 것을 깨달으면 됩니다. 혼자서 개발하더라도 협업과 똑같습니다. 그렇게 해야 더 혼자 개발하더라도 더 빨리 개발할 수 있고 여럿이 개발할 때는 더욱 더 중요합니다.

소스코드관리시스템을 쓰기는 하는데 어중간하게 흉내만 내고 있다고 생각한다면 한번 확실하게 제대로 배워 놓을 필요가 있습니다. 그렇지 않으면 평생 기초 중에 기초에 문제거리를 안고 가는 겁니다.  

개발문서를 만들기는 했는데 업데이트가 안되는 이유

필자는 여러 소프트웨어 회사들의 컨설팅을 진행하면서 먼저 회사의 분석을 위해서 그 동안 소프트웨어를 개발하면서 만들어 놓은 문서를 요구합니다. 사실 문서만 봐도 회사의 개발현황을 대부분 알 수 있습니다.

그런데, 제대로 작성된 문서를 제시하는 회사는 거의 없다시피 합니다. 물론 Wiki나 Google Docs등의 온라인 문서를 포함해서 제대로 작성된 문서는 거의 없습니다. 가끔 문서를 제시하는 회사들이 있기는 하나 수년간 전혀 업데이트를 하지 않아서 쓸모가 없어진 것들 뿐입니다. 

정리를 해보면 다음과 같습니다. 

• 문서가 아예 없거나 없다시피 한 회사
• 몇 년동안 업데이트 안된 문서들만 있는 회사 (오늘의 주제)
• 쓸모없는 문서들을 너무 많이 만든 회사 

야심차게 문서 한번 잘 만들어보겠다고 결심하고 개발 시에 문서를 열심히 만든 후에 소프트웨어는 계속 업그레이드가 되는데 문서는 과거에 머물러 있는 경우에 대해서 얘기를 해보겠습니다.

이런 문서는 죽은 문서입니다.

내용이 맞는지 틀리는지 확인이 안되는 문서는 혼동을 일으킬 수 있습니다.

이런 일이 발생하는 이유는 여러 가지가 있지만 대표적인 이유로는 진짜 문서가 필요해서 만들었다기 보다는 문서가 필요하다고 하니까, 또는 위해서 시켜서 만들었는데, 막상 개발에 크게 도움이 안되고, 단순히 문서를 만들었다는데 의의를 두는 경우가 있습니다. 또, 문서를 너무 잘(많이) 만들어서 소프트웨어가 업그레이드 될 때마다 문서를 갱신하려고 하니 초기 개발 때에 비하여 유지보수 시는 급하게 개발하는 요청이 많아서 미처 문서까지 갱신할 시간이 없는 경우도 있습니다.

이런 경우 모두다 "문서를 위한 문서"인 경우입니다.

문서가 진짜 필요해서 만든 경우가 아니라는 얘기입니다. 역량이 충분히 성숙되기 전에 문서 작성 문화를 정착하려면 어떻게 해야 할까요?

문서를 적게 만들어야 합니다. 

적게 만들면서도 개발에 유용해야 합니다. 그래야 문서를 만드는 일이 프로젝트에 큰 부담이 되지 않고, 추후 업데이트가 가능해집니다.

오래 되어서 쓸모 없어진 문서를 책꽂이에 잔뜩 꽂아 놓고 "옛날에는 문서를 열심히 만들었는데"하고 회상 하십니까? 지금은 그렇게 하고 있지 않다면 효과적이지 않은 방법으로 문서를 만들면서 조직 내에 정착되지 못한 겁니다. 문서 작성을 문화로 정착하려면 "작고 효율적으로 문서 만드는 법"을 익혀야 합니다.

왠만한 크기의 프로젝트도 문서는 한 두 개로 충분합니다. 스펙문서(SRS)와 경우에 따라서 설계문서 정도를 만들면 됩니다. 스펙문서는 요구사항을 분석하는 방법, 꼭 필요한 내용을 적는 방법, 리뷰하는 방법 등을 익혀야 합니다. 요즘은 스펙을 적는 방법에 있어서 다양한 시도들을 하고 있지만, 방법은 조금씩 달라도 꼭 필요한 내용을 빠짐없이 효과적으로 적어야 합니다.

[이벤트 결과] 도서 증정 - "소프트웨어 개발의 모든 것"

지난 일주일간 아래와 같이 이벤트를 진행했습니다.

제목 : 저자 사인 도서 증정 이벤트(소프트웨어 개발의 모든 것, 페가수스)

기간 : 2010-03-05(금) ~ 2010-03-14(일)

대상 및 배송 방법 : 이벤트 기간안에 "소프트웨어 개발 역량 분석 서비스"를 이용한 독자 중에서 이벤트 기간 종료 후 20명을 추첨하여 착불 택배로 보내드립니다.

주의사항 : 회사 및 담당자 정보를 입력하실 때 책을 배달 받을 "주소"를 꼭 입력해주시기 바랍니다. 주소를 모르면 책을 보내드릴 수가 없습니다.^^ 

많은 분들이 응모를 해주셨습니다. 그 중에서 주소를 입력해주신 분들 중에서 20명을 무작위로 추첨하였습니다.

모든 분들에게 책을 보내드리면 좋겠지만, 저자도 자신이 쓴 책을 사야하기 때문에 모든 분께 보내드리지 못해서 죄송합니다.

책은 보내드리지 못하는 분들도 설문 내용을 분석한 보고서는 순서대로 보내드리도록 하겠습니다. 보통은 바로 보내드리는데 접수자가 많아서 시간이 조금 걸리니 양해 부탁합니다.

그런데, 택배를 보내려고 하니 수취인의 전화번호가 없으면 인터넷으로 택배 접수가 안되더군요. 

그래서 각 당첨자에게 메일을 보내서 휴대전화 번호를 접수 받았습니다. 

아직 다섯분의 메일은 받지 못했습니다. 혹시 이글을 보시면 메일을 확인해보시고 제게 휴대전화 번호를 보내주시기 바랍니다.

당첨된 20분은 다음과 같습니다.

윤아* 서울시

김명* 서울시

김수* 서울시

신현* 서울시

김종* 서울시

이준* 서울시

이상* 경기도

이종* 서울시 

남종* 수원시

윤민* 서울시

김재* 서울시

손봉* 경기도

한성* 서울시 

고형* 경기도 수

강한* 경기도

장진* 서울시

이지* 경기도 휴대전화 번화 미접수

김강* 서울시 

조석* 서울시

조명* 경기도

빨리 망해서 없어져야 할 회사들

소프트웨어 업계에는 빨리 망해야 서로 도움이 되는 회사들이 매우 많지만 악착같이 버티면서 소프트웨어 생태계를 좀먹고 있습니다. 이렇게 좀비화 된 "좀비 회사"들은 또다른 "좀비 회사"를 만들어 내는 악순환의 고리를 만듭니다.

뛰어난 기술이나 별다른 경쟁력 없이 오로지 생존력만 가지고 시장을 갉아 먹는 회사들은 빨리 빨리 사라져 줘야 합니다. 즉, 망할 회사는 빨리 망해야 우리 모두가 삽니다.

정부지원으로 버티는 회사

정부의 지원은 이를 통해서 기술을 개발하고 소프트웨어 산업의 밑거름이 되라는 것이지 이것으로 연명하라는 것이 아닙니다. 하지만 예나 지금이나 기술 개발보다 떡밥에 관심있는 회사가 많습니다. 

이런 회사들의 엉터리 기술은 시장을 교란하고 가격 체계를 무너뜨리곤 합니다.

아직 미성숙한 소프트웨어 산업을 키우기 위해서 정부 지원이 필요한 것은 사실이지만, 종종 역효과가 일어나곤 합니다. 그래서 차라리 이럴바에는 정부에서는 그냥 내버려 두는게 나을 수도 있습니다.

방해도 하지 말고 도와주지도 않는 것이 소프트웨어 업계에는 도움이 될 수 있습니다.

덤핑을 일삼는 회사

기술이 부족하다보니 모든 bidding에 덤핑으로 대응하는 회사들도 있습니다. End user market이 매우 작은 우리나라에서 이런 덤핑의 일상화는 물귀신 작전이 아닐 수 없습니다. 덤핑도 전략이라고 말할 수 있지만, 이렇게 시장이 교란되고 나면 그 피해는 고스란히 소프트웨어 업계 전체에게 돌아갑니다.

덤핑은 이런 회사 뿐만 아니라 대기업들간에도 흔히 발생하는데, 시장에서의 지위와 자본력을 내세워 경쟁자를 망해버리게 하려는 덤핑은 법으로도 금지되어 있지만, 소프트웨어 업계에서는 유명무실이더군요. 그렇게 시장을 차지해봤자 소프트웨어 업계에서는 별 재미를 못보는게 일반적입니다.

대마불사

회사의 덩치를 잔뜩 키워 놓고 마음대로 죽지 못하게 만드는 방법입니다. 회사가 망하면 대한민국 경제에 악영향을 끼치기 때문에 정부에서 망하게 가만히 두지 않을 것이라고 기대하곤 합니다. 물론 로비도 잘 해야겠죠. 또한 고객들이 워낙 많아서 담당자들이 유지보수 때문에 망하게 놔두지를 않습니다. 발목잡힌 거죠. 

투자는 없이 개발자를 혹사해서 연명하는 회사

여기에 해당하는 회사는 너무나 많은 것 같습니다. 투자는 하지 않고 특별한 기술력 없이 오로지 개발자들의 개별 전투력에 의존하여 저가수주 후에 개발자들의 끊임없는 야근으로 버텨나가는 회사입니다.

기술에 투자를 하지 않기 때문에 회사의 기술력은 발전하지 않고 개발자들이 오래 버티지 못하고 나가면 그나마 축적된 노하우도 쉽게 유출되고 맨날 이런식으로 몸으로 때우는 회사들입니다. 회사나 개발자나 미래가 없는거죠.

임금 돌려막기

위의 회사들에 해당하기도 하지만 직원들의 임금을 정상적으로 지급하지 못하면서 다음달 영업하여 체불 임금을 지급하고 이런 현상이 장기화 되는 회사입니다. 벤처기업에서 단기적으로 이런일을 겪을 수도 있고 직원들이 이런 어려움을 서로 감내해서 극복할 수도 있지만, 이런 일이 일상화되고 장기화되면 회사는 자꾸 안좋은 비즈니스라도 단기적으로 직원들의 임금을 지급하기 위해서 수주를 해야 하는 악숙환이 반복됩니다. 기가 막히게 이를 극복하면 좋겠지만, 거의 대부분 회사나 개발자들에게 상처만 남는 경우가 많죠.

이 외에도 빨리 망해서 없어져야 소프트웨어 업계에서 일하는 우리 모두가 행복해지는 회사들은 매우 많을 겁니다. 어떤 회사들이 있을까요? 여러분들의 의견을 적어주세요.

[이벤트 종료] 도서 증정 - "소프트웨어 개발의 모든 것"

안녕하세요. 블로그 독자 여러분! 

대한민국의 소프트웨어 토양에 좋은 밑거름이 되고자 하는 제 블로그에 많은 호응을 해주셔서 감사드리며 이에 보답코저 아래와 같이 이벤트를 실시합니다. 많은 참여 바랍니다.

제목 : 저자 사인 도서 증정 이벤트(소프트웨어 개발의 모든 것, 페가수스)

기간 : 2010-03-05(금) ~ 2010-03-14(일)

대상 및 배송 방법 : 이벤트 기간안에 "소프트웨어 개발 역량 분석 서비스"를 이용한 독자 중에서 이벤트 기간 종료 후 20명을 추첨하여 착불 택배로 보내드립니다.

주의사항 : 회사 및 담당자 정보를 입력하실 때 책을 배달 받을 "주소"를 꼭 입력해주시기 바랍니다. 주소를 모르면 책을 보내드릴 수가 없습니다.^^ 

        

단, 이미 "소프트웨어 개발 역량 분석 서비스"를 이용한 분들은 제가 보내드린 "분석 보고서"를 제게 답장으로 보내면서 주소도 같이 적어서 보내주시면 추첨 대상에 포함하도록 하겠습니다.

감사합니다.

세계 최초!

소프트웨어 업계만큼이나 "세계 최초"라는 수식어를 자주 듣는 곳도 드물 것입니다.

이러한 수식어가 붙는 이유는 세간의 이목을 끌기 위함이 명백합니다.

하지만 세계 최초라고 하는 것들의 99%는 아래 범주에 속합니다.

• 나는 세계 최초로 알고 있다. 하지만 진짜 세계 최초인지 알아보려는 노력은 별로 하지 않았다.
• 별거 아니라서 아무도 관심을 가지지 않는 기술이다. 따라서 시장성도 없다.
• 이미 더 좋은 기술이 있는데 나는 공부를 많이 안해서 잘 모른다.

그럼에도 불구하고 지금도 툭하면 "세계 최초"라고 주장하는 기술들이 계속 튀어나오고 있고 이제는 별로 믿음도 안 갑니다. 오히려 세계 최초라고 하면 더 색안경을 끼고 보게 되었습니다.

또, 가끔 듣는 얘기가 "획기적인 기술"이라는 겁니다. 자세한 기술 요소는 보안 때문에 밝힐 수 없다고 합니다. 이런 경우는 99% 아래 범주에 속합니다.

• 나는 획기적인 것으로 알고 있는데 그건 내가 수준이 낮아서 그런 것이고 사실 별거 아니다.
• 별거 아닌 줄 알고는 있는데 밝히면 창피하니까 자세한 기술요소는 밝힐 수 없다.

사실 소프트웨어를 개발하는데 있어서 "세계 최초", "획기적인 기술"이 필요한 경우는 그리 많지 않습니다. 

대부분의 소프트웨어 프로젝트의 성패여부는 얼마나 획기적인 기술을 적용했나로 판가름 나지 않습니다.

오히려 대부분의 프로젝트는 이미 알려진 검증된 기술들로 수행을 해야 합니다. 

현재 쏟아져 나오고 있는 기술들을 꾸준히 따라가는 것만 해도 벅찬 일입니다.

사실 세계 최초로 뭔가를 해냈다고 해서 결과가 더 좋은 것은 아닙니다. 야후가 최초의 인터넷 검색을 제공했지만 지금 1등은 구글입니다.

MS도 최초의 OS 회사는 아니죠. 물론 최초가 1등인 분야도 있지만, 최초라는 수식어가 1등을 보장해주지는 않습니다.

"세계 최초" 남발하지 말고 실속 있게 개발해야 할 것입니다.

개발자의 야근은 공짜?

소프트웨어 회사의 일들은 대부분 사람, 특히 개발자에 의존하는 일이 많습니다.

따라서 인건비는 가장 큰 비중을 차지하는 고정비입니다.

그런데 일단 뽑아 놓은 직원들의 야근은 공짜로 생각하는 경우가 많습니다.

게다가 몇몇 기업을 제외하고는 개발자들에게 "야근 수당"이나 "시간 외 근무 수당"은 딴나라 얘기입니다. 

제가 하고 싶은 얘기는 "개발자들이 야근을 하면 안된다", "시간 외 근무 수당을 받아야 한다"라는 얘기가 아닙니다.

개발자들은 동기부여만 되면 얼마든지 밤을 세가며 일하고 이는 금액으로 따지기 어렵습니다.

오늘 할 얘기는 경영자들의 절약 정신이 소프트웨어 개발팀의 효율을 떨어뜨린다는 얘기입니다. 

절대적인 잣대가 있는 것은 아니지만, 개발자들의 여분의 노동력을 공짜로 생각해서는 안됩니다. 회사마다 조금씩 다르기는 하지만, 합리적인 투자가 있어야 개발팀의 최대 능률을 이끌어 낼 수 있습니다. 

야근

개발자들이 야근을 많이 할수록 많은 시간 일을 할 수 있으니 똑같은 월급을 주고 훨씬 효율이 높다고 생각할 수 있으나 외부 요인으로 인해서 발생하는 야근의 효율성은 그리 높지 않습니다. 

특히 장기적이고 일상화된 야간 압력은 개발자의 사기 및 충성도를 떨어뜨리며 제품의 품질을 떨어뜨리고 개발자들의 발전을 저해하며 창의적인 아이디어 발생을 가로막고 개발팀의 효율을 떨어뜨립니다. 

단기적으로 야근의 압박이 있을 수는 있겠지만, 장기화 되는 것은 문제가 있습니다.

단, 자발적이고 능동적이고 자유롭고 적절한 야근은 오히려 도움이 되죠

조용한 사무실

경영자 입장에서는 작은 공간에 최대한 많은 개발자와 다른 부서 직원들을 몰아 넣고 서로 긴밀하게 커뮤니케이션을 하면서 일을 하기를 바랄 겁니다. 일단 이렇게 하면 임대료가 적게 나가고 영업의 이슈가 즉각적으로 개발팀에 전달이 잘 될 것으로 생각하곤 합니다. 하지만 이런 북적이고 시끄러운 환경에서 개발자는 최고의 능력을 발휘할 수 없습니다. 그러면 자연스럽게 몰입할 수 있는 밤시간을 선택해서 개발을 하곤 합니다. 

영업사원들의 시끄러운 전화를 옆에서 엿들어야 커뮤니케이션이 잘되는 것은 아닙니다. 커뮤니케이션은 적절한 시스템과 프로세스와 문화가 필요한 것입니다. 그리고 개발자에게는 최대한 집중해서 일할 수 있는 조용한 공간이 필요합니다.

공간이 조금 더 들어가고 임대료가 조금 더 나가더라도 개발자에게 조용한 공간을 제공할 수 있는 벽을 세우거나 사무실을 만들어 주는 것이 좋습니다.

개발자들을 따로 띄어 놓으면 딴짓 할까봐 걱정이 된다구요. 그러면 처음부터 잘못 뽑았네요. 

널찍한 모니터와 빠른 시스템

개발자들에게 끊임 없이 좋은 시스템으로 교체해주는 일이 쉬운 일은 아닙니다. 하지만 너무 인색한 회사는 좋은 시스템이 개발 효율성과 연관이 있다는 것을 잘 알아차리지 못합니다. 작은 모니터는 동시에 여러 화면을 보지 못하며 디버깅도 불편하여 조금씩 작업 시간이 더 오래 걸립니다. 특히 빌드를 밥 먹듯이 하는 개발자들은 빌드 시간을 10~20% 줄이는 것만으로도 전체적으로 꽤 많은 시간을 절약해 줍니다. 이런데 투자를 하는 것보다 개발자들이 하루에 몇십분씩 더 일하면 된다고 생각하는 경영자들도 있습니다. 개발자들의 여분의 시간은 공짜가 아닙니다.

허리를 보호해 주는 의자

안타까운 얘기지만 소프트웨어 개발자로 10년 정도 종사하면 허리 디스크에 시달리는 것은 예사가 되었습니다.

비싸지만 좋은 의자들은 개발자들이 더 오랜 시간 몸에 무리가 가지 않게 일할 수 있게 만듭니다.

직접적으로 개발 효율을 높일 수 있는 투자이지만, 대부분의 회사에서는 가장 싼 의자 구매만 승인이 납니다. 그래서 여러 개발자들은 자신의 돈을 들여서 좋은 의자를 구입하곤 합니다. 이런 투자는 회사의 몫입니다.

아침식사와 간식

최근에 컨설팅을 했던 회사는 매일 아침 직원들에게 신선한 식빵을 매일 제공하더군요. 오전시간에 속이 비어 있으면 두뇌 회전이 느려지고, 점심시간을 기다리느라고 일에 집중이 잘 안됩니다. 

비용은 얼마 안되는 투자이지만, 투자대비 효과가 높은 것 중 하나입니다. 

테스트 조직

개발자와는 별도로 테스터 조직을 만드는 것을 비용으로 생각하는 회사가 의뢰로 많습니다. 테스트의 비중을 별로 높게 생각하지 않고 개발자들이야 말로 자신들이 만든 소프트웨어를 잘 테스트할 수 있다고 생각합니다. 이런 식으로 개발을 하면 평생 구멍가게를 면치 못합니다.

테스트의 비중은 생각보다 큽니다. 테스트 팀을 활용하지 않고 개발자들에게 테스트를 맡기는 것은 상대적으로 비용이 많이 드는 개발자들을 낭비하는 것이며 실제로 개발자들은 테스트를 잘하지 못합니다. 또한 이는 테스트의 전문성도 무시하는 겁니다. 

회사마다 다르기는 하지만 적절한 인원의 테스트팀을 유지하는 것이 비용이 더 적게 들면서도 제품의 품질을 잘 유지할 수 있는 길입니다.

소프트웨어 회사에서 주변을 둘러보면 비용 효율성을 높일 수 있는 요소들이 많이 있습니다. 대부분은 사소한 비용을 절약하기 위해서 더 큰 대가를 치를 경우가 많습니다. 어디에는 투자를 해야 하고 무엇을 아껴야 하는지 적절히 판단할 수 있는 균형 잡힌 시각이 필요합니다.

삼성이 소프트웨어 분야에서도 최고가 되려면?

최근 삼성과 소프트웨어에 대한 글들을 몇 건 올리면서 정말로 다양한 의견을 접하게 되었습니다.

댓글뿐만 아니라 메일을 통해서도 의견을 들을 수 있었습니다. 

2010/01/05 - [소프트웨어이야기] - 삼성은 왜 소프트웨어를 잘 만들지 못할까?
2010/01/23 - [소프트웨어이야기] - 삼성이 바다를 출시해서는 안되는 이유
2010/02/08 - [소프트웨어이야기] - 삼성이 앞으로도 소프트웨어를 잘 만들 수 없는 이유

그 중에는 삼성 관계자 분들도 있었고, 삼성 내부 개발자, 삼성 협력사의 개발자들도 많이 있었습니다. 

현재 삼성으로 대표되는 대한민국 대기업들의 소프트웨어 개발 현황을 살펴보고 해결책을 찾아보려고 하는 블로그 글에 상당히 과민반응을 보이는 글들을 보면서 현 상황을 더욱 잘 짐작하게 해줍니다.

특히, 인상적인 글들은 삼성 내부 개발자와 삼성 협력사의 개발자의 글들이었습니다. 상당히 충격적인 증언들도 있었습니다. 댓글과 메일을 포함해서 삼성 내부 소프트웨어 조직의 심각성을 좀더 잘 알 수 있었습니다.

어쨌든 모든 댓글 및 메일을 보내주신 분들에게 감사 드립니다.

이제 결론을 내릴 때가 된 것 같습니다. 애초의 글들의 목적은 도무지 가망이 없어 보이는 대한민국의 소프트웨어 환경, 특히 삼성으로 대표되는 대기업들의 열악한 소프트웨어 개발 환경을 극복하고 소프트웨어 분야에서도 최고가 되는 방법을 찾아보려는 것이었습니다. 제 사견이긴 하지만, 그 동안의 소프트웨어 개발 및 컨설팅 경험을 근거로 나름대로 전문적이고 현실적인 방법을 찾아보려고 노력했습니다.

그럼 삼성이 소프트웨어 분야에서도 최고가 되는 방법의 시나리오를 보죠.

1. 좀더 실패가 필요합니다. 

어이 없는 결론이기는 하지만 몇번 더 실패를 통해서 소프트웨어의 중요성을 좀더 깨달아야 합니다.

현재 돌아가는 상황을 보면 소프트웨어 분야에 있어서 실패를 했고 실력은 부족하고 소프트웨어에 투자를 해야 한다는 간단한 현황을 진정으로 인식하고 있는 것으로 보이지 않습니다.

제가 삼성 및 대기업의 소프트웨어 개발 능력 부족을 지적하는 글을 작성한 이후에 놀랍게도 신문, 방송 모두 거의 똑같은 의견을 연일 쏟아 냈습니다. 이에 대응하여 삼성에서 발표한 극복 방안은 대부분 단기적이고 비전문가적인 접근들이었습니다. 소프트웨어 전문가라면 금방 문제가 있다는 것을 눈치챌 정도로 허술한 것들이었습니다. 

이는 현재상황을 진정으로 이해하고 있는 것이라고 볼 수 없습니다. 안타깝게도 몇번의 실패를 더 해야 진짜 문제가 심각하고 이대로는 안 된다는 것을 알 수 있을 것 같습니다. 삼성 내부에서도 아랫사람들이 아무리 얘기를 해봤자 시장에서 크게 실패하기 전에는 이를 깨닫기 어려울 것 같은 같습니다.

개인적인 바램은 최상위 경영층에서 가능하면 빨리 이를 인지해야 할 것 같습니다. 자칫하면 너무 늦을 수도 있습니다.

2. 소프트웨어 전문 경영자를 다시 중용해야 합니다.

기업의 경영자 인사는 다분히 정치적인 요소가 강합니다. 그러기 때문에 소프트웨어 전문 경영자가 중용되거나 오래 버티기가 힘들지만, 진짜 실패를 통해서 최고의 자리를 유지하기 위해서는 소프트웨어에 투자하는 수밖에 없다는 것을 깨닫고 나면 이를 이끌 소프트웨어 전문 경영자가 필요합니다. 

대기업의 소프트웨어 현황을 대변하는 말 중 하나가 "조삼모사"입니다.

"조三모四"아니 "조三모七"을 주장하는 소프트웨어 전문 경영자보다 "조四모一"을 얘기하는 경영자가 더 오래 살아남습니다. 여기서 저녁의 "일"은 얘기거리도 안됩니다. 소프트웨어 분야에서는 "조三모四현상이 더욱 극명하게 나타납니다.

애플은 아이폰의 플랫폼은 단 하나만을 사용하고 있고 구글도 안드로이드 하나를 사용하고 있습니다. 안드로이드는 핸드셋마다 변경될 수는 있지만 상당부분 호환성을 유지하고 있습니다.

그런데 국내의 한 굴지의 핸드폰 제조사는 지금까지 나온 6,000여개의 핸드셋에서 서로 다른 6,000개의 플랫폼을 사용하고 있습니다. 이를 공통으로 사용할 수 있는 플랫폼을 개발 할 수도 있었겠지만, 하나의 핸드셋만 놓고 보면 소스코드 복사해서 따로 만드는 것이 시간이 더 단축되기 때문에 "조三모七"이 아니고 "조四모一"을 선택한 것입니다. 

"一"이 아니고 마이너스 상황이 되고 소프트웨어가 지속적으로 발목을 잡기 전에 "소프트웨어 전문 경영자"가 이를 극복할 수 있도록 해야 할 것입니다. 또한 기존의 조직, 기존 사업부에서 결국 단기적인 실적 목표에 또 밀려 나지 않도록 새로운 조직이 필요할 것이며 정치논리에 밀리지 않도록 최상위 경영층의 지원이 필요합니다.

3. 외국의 전문 SW회사를 인수합니다.

삼성 내부의 개발조직을 가지고 어떻게 잘해보기에는 이미 늦은 듯 합니다. 물론 삼성 내부에도 뛰어난 개발자들이 많이 있지만, 조직으로 놓고 보면 얘기가 달라집니다. 이런 조직에서 오랫동안 길들여진 개발자들은 대부분 제대로 된 소프트웨어 개발 조직에서 제 역할을 하는 것을 기대하기는 힘듭니다. 

그렇다고 새로운 조직을 신입 개발자들을 뽑아서 만들어가기에는 시간이 이를 허용하지 않습니다. 

따라서 외국의 뛰어난 전문 SW회사를 인수해야 합니다. 이 또한 정치 논리가 아니고 진짜 소프트웨어 회사를 제대로 평가할 수 있는 전문가 그룹에서 삼성의 미래에 도움이 되는 소프트웨어 회사를 선택해서 제대로 평가하여 인수해야 합니다.

소프트웨어 전문 경영자는 인수한 SW회사와 삼성의 가교역할을 해야 합니다.

4. 인수한 SW회사는 삼성 내부의 개발조직과는 분리를 해야 합니다.

인수한 외국의 SW회사는 삼성 내부 개발자들과는 너무나 다른 개발문화를 가지고 있습니다. 이들을 자칫 그냥 섞어 놓다가는 둘 다 망칠 수 있습니다. 따라서 삼성 내부 개발자 중에서도 철저한 평가를 통해서만 인수한 SW회사로 이동이 가능할 것입니다. 아직 삼성의 개발문화에 많이 길들여지지 않았지만, 영어를 잘하고 똑똑한 개발자들은 인수한 SW회사와 섞어서 일하는 것이 가능할 것입니다. 

이 과정을 통해서 서서히 글로벌 소프트웨어 개발 문화를 익혀나가는 것이 필요합니다. 즉, 삼성에서 직접 활약할 선임 소프트웨어 개발자들을 양성해야 합니다.

5. 독자적인 성장을 할 수 있도록 보호를 해주고 지원해야 합니다.

인수한 소프트웨어 회사에도 "조삼모사"논리로 기존의 개발문화를 깨게 되면 평범한 소프트웨어 회사가 되어 버릴 수도 있습니다. 기존의 삼성 조직에 필요한 것들은 개발자 순환을 통해서 조금씩 익혀나가고 인수한 소프트웨어 회사에서는 독자적인 사업 영역을 계속 가져갈 수 있도록 보호를 해주고 지원해야 합니다. 이런 SW회사를 여러 개 인수하여 다양한 개발 문화를 접해야 합니다. 

6. 기존 조직의 반대와 방해로부터 보호를 받아야 합니다.

이러한 과정에서 내부 조직의 반대와 방해에 부딪힐 것은 뻔합니다. 이러한 방해는 아주 작은 소프트웨어 회사들에서도 존재하는데 삼성 같은 거대 기업은 말할 필요가 없습니다. 이를 보호해줄 수 있는 사람은 삼성내의 최상위 경영층 밖에 없을 겁니다. 이렇게 5년, 10년 투자가 이루어져야 소프트웨어 분야에서도 최고라는 소리를 조금씩 듣기 시작할 수 있을 겁니다.

고민 끝에 내린 시나리오는 이렇지만, 이 시나리오의 최대 키포인트는 바로 최고 경영층의 지원일 겁니다. 현재 상황을 얼마나 심각하게 깨닫고 기존의 경영자들은 이를 해결 할 수 없다는 것을 얼마나 빨리 깨닫느냐가 관건이라고 할 수 있습니다.

대한민국 소프트웨어 개발환경은 대기업, 중소기업 가리지 않고 열악하기 그지없습니다. 특히 삼성은 우리나라 경제의 가장 큰 버팀목이기도 하지만 수많은 중소 소프트웨어 회사의 밥줄이며 동시에 목줄을 죄고 있습니다. 삼성이 잘하면 모두 상생할 수도 있지만, 잘못하면 삼성은 약간의 타격이지만, 중소 소프트웨어 회사들은 와해되기 때문에 이것이 삼성이 소프트웨어 분야에서도 잘해야 하는 제가 생각하는 가장 큰 이유입니다. 

이는 비단 삼성만의 문제는 아닙니다. 제 바램은 이런 목소리를 통해서 소프트웨어 환경이 조금씩 나아지는 길로 가는 것입니다.