소스코드가 그렇게 중요한가요?

소스코드를 신주단지 모시듯 하는 회사나 개발자들을 자주 볼 수 있습니다.

소스코드가 자신들의 모든 기술이 함축된 집합체라고 생각들을 합니다.

 

저는 이런 회사나 개발자들 딱 접하는 순간 그 수준을 한번에 알 수 있습니다. 다른 것들은 별로 물어볼 필요도 없이 그로 인해서 회사가 어떤 식으로 개발을 하고 있다는 것을 쉽게 짐작할 수 있습니다.

 

그러한 회사들은 소스코드를 개발자를 제외한 다른 직원들은 접근하지 못하도록 하기 위해서 보안장치를 두고 개발자는 자신이 작성한 소스코드를 공유하기 꺼려하기도 합니다. 개발의 내용은 SRS나 설계서에 포함되어 있기보다는 그냥 코드에 숨어 있어서 이를 작성한 사람이 아니면 전체를 파악하기 정말 어렵습니다. 해당 개발자가 아니면 유지보수가 어렵고 신입사원이 들어와도 공유가 잘 안됩니다.

 

이런 말이 있습니다.

"경쟁회사를 어렵게 만들고 싶으면 자사의 소스코드를 실수인척하고 공개해서 경쟁회사로 흘러 들어가게 하라"

그 경쟁사는 소스코드를 얻고 횡재한 줄 알겠지만, 이를 분석하다 보면 몇 달 후 별로 얻은 것은 없이 시간만 낭비했다는 것을 알게 될 것입니다.

 

가슴에 손을 얹고 생각해보면 우리가 작성하는 소스코드 중에서 정말 획기적인 것이 있나요? 남들은 절대로 만들지 못할 엄청나게 어려운 것이 있나요? 대부분은 이미 다 공개된 알고리즘과 모듈들입니다. 물론 그런 것들이 있다면 잘 지켜야 겠지요. 하지만 그런 경우는 거의 찾아보기 힘듭니다.

정작 중요한 것은 그 아키텍처이고, 스펙입니다. 그리고 개발자들의 역량과 팀웍이죠. 그것들이 다른 회사와 우리 회사를 다르게 만들어주는 요소입니다. 소스코드는 아니죠.

 

물론 소스코드가 소프트웨어를 이루는 중요한 요소이기는 하지만 소스코드의 보안에만 신경 쓰는 순간 자신의 수준을 확 낮춘다는 것을 알아야 하겠습니다.

소프트웨어 개발자의 권리

지난번 글에서 소프트웨어 개발자윤리(의무)에 대해서 얘기를 한 적이 있습니다.

그때 많은 분들이 개발자의 권리도 좀 생각해보자고 하였습니다.

이에 개발자의 권리와 개발자에 대한 경영자와 고객의 의무를 정리해 봤습니다.

의견이 있는 분들은 댓글 남겨주세요.

개발자의 권리

○ 우리도 남들 잘 때 잘 수 있다.  ○ 우리도 희망적인 미래를 꿈꿀 수 있다.  ○ 우리도 가족과 저녁식사를 할 수 있다.  ○ 나이가 먹어도 계속 개발을 할 수 있다.  ○ 전문가로 성장할 수 있는 기회를 제공 받아야 한다. ○ 우리에게는 자기계발을 할 수 있는 시간과 기회가 제공되어야 한다.

개발자에 대한 경영자의 의무

○ 개발자를 부품이 아닌 전문가로 생각해야 한다. ○ 개발자에게 최상의 개발 환경을 제공해야 한다.  ○ 개발자에게 적절한 교육을 받을 수 있도록 해야 한다.  ○ 개발자가 원하는 캐리어로 성장할 수 있도록 보장해야 한다.  ○ 개발자는 근무시간이 아닌 실력과 성과로 평가해야 한다.   ○ 개발자의 실력과 성과에 합당한 보상을 제공해야 한다.

개발자에 대한 고객의 의무

○ 개발자를 하나의 인간으로서 존중해야 한다.  ○ 개발팀의 개발프로세스를 존중해야 한다.  ○ 요구사항을 개발자에게 정확하게 전달해야 한다. ○ 개발자의 요청에 시기적절하게 대응해야 한다.  ○ 개발 기간이나 시간을 산정한 개발자의 분석을 존중해야 한다.  ○ 요구사항 변경요청은 최대한 빨리 개발자에게 알려야 한다.  ○ 요구사항 변경은 개발팀의 프로세스를 따라야 한다.

자기 중심적인 사고에 갇힌 개발자

개발자들은 모든 생각의 중심을 본인으로 생각하는 경우가 흔합니다.

소프트웨어를 개발하면 모든 판단의 기준을 본인으로 하는 것이지요.

우주가 자신을 중심으로 돌고 있다고 생각하는 개발자들입니다.

적용하는 기술도 본인이 잘 알고 익숙한 것으로, 또 사업적인 관점으로 고려를 하기보다는 본인의 취향에 따라서 섯부른 판단을 하는 경우가 많습니다.

특히나 이렇게 자기 중심적인 사고방식에 꽉 막혀 있는 개발자들과는 대화조차 어려운 경우가 많습니다. 보통 고집도 센 것이 아니어서 같이 일하기 피곤합니다. 이런 개발자들이 실력이 뛰어난 것처럼 보여서 어쩔 수 없이 붙들어 두고 있는 경우가 많은데 일찌감치 팀에서 제외를 하던가 해고를 하는 것이 더 나을 겁니다.

소프트웨어를 개발하면서 벌어지는 수많은 판단과 결정은 이렇게 개발자 중심으로 이루어져서는 경쟁력 있는 제품이 나오기 어렵습니다. 무슨 DB를 쓸지, 어떤 개발언어를 사용할지, 아키텍처를 어떻게 구성할지? 또는 무슨 기능을 포함할지도 개발자가 마음대로 결정하고 해당 담당자에게 리뷰도 하지 않고 덜렁 소프트웨어를 개발해 놓으면 뒤늦게 문제들이 뻥뻥 터집니다.

개발자는 자신이 잘하는 일을 해야죠. 자신의 전문분야가 아닌 것은 다른 사람의 의견을 들을 수 있어야 합니다. 무슨 DB를 쓸지에 대한 이슈도 기술적인 이슈라기 보다는 비즈니스적인 측면이 더 큽니다. 개발자들은 이러한 결정의 순간에 자기 중심적인 사고를 버려야 합니다. 경험이 많은 개발자들은 이렇게 균형을 갖춘 사고를 하지만, 경험이 많은 모든 개발자가 그런 것은 아닙니다.

세상은 자신을 중심으로 돌고 있지 않다는 것을 알아야 합니다.

소스코드관리 상세 조사 결과 리포트

지난번 소스코드관리 방법 조사 후 좀더 상세하게 각 회사나 개발팀이 소스코드를 관리하면서 어떤 방법들을 사용하는지 즉 그 성숙도를 알아보기 위해서 약 2주에 걸쳐서 2차 조시를 실시했습니다.

질문항목이 26개나 되는 상당히 긴 투표였지만, 많은 분들이 응해주셔서 나름대로 의미있는 수치를 얻을 수 있었습니다. 투표에 참여해주신 모든 분께 감사드립니다.

투표위젯에 참 참여자 수를 보는 방법이 없어서 가장 많은 득표를 한 항목으로 미루어 짐작해서 35명이 투표에 참여한 것으로 생각하고 있습니다.

질문은 다음과 같았습니다.

각 항목별로 총 득표수는 다음과 같습니다. 아래 조사는 소스코드관리시스템을 사용하는 회사를 기준으로 계산을 할 것이므로 1번 항목은 100%입니다.

그럼 각 항목 별로 분석을 해보도록 하겠습니다.

1) 관리방법

2번 항목은 모든 개발자가 얼마나 소스코드관리시스템을 철저히 사용하는지에 대한 조사입니다. 소스코드의 Working copy가 개발자 PC나 개발서버에 임시로 있을 수는 있어도, 보관의 목적으로 다른 곳에 보관을 하면 안됩니다. 

3번 항목은 소스코드와 문서를 같이 보관하고 있는가에 대한 조사입니다. 즉, 소스코드 뿐만 아니라 Baseline에 포함이 되어야할 모든 문서도 같이 보관을 해야 합니다. 조사결과 문서를 같이 보관한다는 응답이 40%에 불과하는데, 실제로 Baseline에 포함될 모든 문서와 자료를 다 보관하는 경우는 40%보다 더 적을 것으로 생각이 되는 군요. Baseline을 설정할 때 항상 문서와 소스코드는 같은 버전으로 짝을 이루어야 합니다. 대부분의 소프트웨어 개발 회사가 문서 작성에 소흘하기 때문에 이 항목은 아예 신경을 안쓰는 경우가 많습니다.

2) Baseline

이 항목들은 Baseline을 얼마나 제대로 설정하고 있는가에 대한 조사입니다.

Baseline을 설정한다는 응답도 54%로 낮은 편이나 제때 빠짐없이 Baseline을 항상 설정한다는 응답은 26%에 불과하다는 것을 알 수 있습니다. 특히 프로젝트 종료후 한번만 Baseline을 설정하는 경우도 있었습니다.

똑, 특이할만 한 점은 앞의 조사에서 문서도 같이 저장하는 경우는 40%이나 문서도 같이 Baseline을 설정하는 경우는 17%에 불과합니다. 즉, Tag나 Label을 만들 때 문서는 제외하고 소스코드만을 포함하는 경우입니다. 

3) Rule

8번 항목을 보면 대부분의 회사가 메시지 작성 규칙이 없음을 알 수 있습니다.즉, 개발자들이 알아서 메시지를 남기거나 안남기기도 한다는 것이죠. 실제로 많은 회사들의 경우를 보면 소스코드관리시스템의 History가 거의 쓸모 없는 경우가 대부분입니다. 단순히 소스코드 저장소 역할만 하는 것이죠.

9번은 버그관리시스템과 연동이 되는지 보는 것인데, 8번과 같은 비율이 나온 것은 좀 이상하네요. 8번은 그야말로 기본적인 항목이고, 9번은 좀더 성숙도가 높은 항목인데요. 어쨋든, 소스코드관리시스템과 버그관리시스템은 서로 연동을 하면 개발 생산성을 높일 수 있습니다. 그리고, 버그ID가 없이 소스코드를 임의로 수정하는 일을 막을 수 있습니다. 시스템에서 버그 ID가 없으면 소스코드를 수정할 수 없도록 막을 수도 있습니다.

10번 항목은 소스코드가 항상 빌드가 가능한 상태를 유지하는지에 대한 질문입니다. 나름대로 회사들이 Broken tree를 방지하기 위해서 노력하고 있네요. 

4) Review

이번 리뷰에 대한 조사 결과는 기대보다 대단히 낮은 것을 볼 수 있습니다. 일단 리뷰를 거의 안하고, 소스코드를 등록할 때도 리뷰자를 남기는 경우가 별로 없네요. 즉, 리뷰의 대한 저변은 매우 낮은 것을 알 수 있습니다.

특이한 것은 Pair programming을 하는 회사가 11%나 되네요. 

5) Build

자동으로 Daily Build를 하고 있는 회사는 29%에 불과했습니다.

개발자 중에는 매일 빌드를 한다고해서 Daily Build를 하는 것으로 착각하는 경우가 있는데, Daily Build는 자동화 되어서 매일 지정된 시간에 자동으로 빌드를 하는 것을 말합니다.

6) 응용

이 항목은 개발자들의 공동작업을 얼마나 효율적으로 소스코드관리시스템을 이용해서 유연하게 처리하고 있는지 조사한 것입니다.

일단 Branch를 사용하고 있는 회사는 꽤 많습니다.(40%) 이에 비해서 Branch를 승인받아야 한는 경우는 17%에 불과합니다. 개발자들이 Branch를 아무 때나 만들 수 있다면 자칫 Branch가 관리가 안될 수도 있습니다.

소스코드를 Merge하는 회사는 60%정도이고 이중에서 아직도 상당히 많은 회사가 2-way merge나 눈을 이용해서 수동으로 Merge를 하고 있는 것으로 알 수 있습니다.

3-way merge툴을 아는 개발자가 40%나 되지만 그 활용도는 대단히 떨어집니다.(23%)

즉, 안다고 제대로 활용할 수 있는 것은 아니네요.

7) 백업

소스코드관리시스템은 꼭 백업을 받아야 합니다. 그런데, 약 60%만이 백업을 받고 있고 그중에서 안전한 장소에 백업을 보관하고 있는 회사는 훨씬 더 적습니다. (26%)

총평)

소스코드관리시스템 사용에 대한 성숙도를 따져보면 평균적으로 초,중급 정도의 사용도를 보이고 있습니다. 하지만, 이는 제가 실제로 접하는 여러 회사들이 평균보다도 높은 수치입니다. 그 원인이 블로그의 방문자들의 수준이 더 높던가, 얼굴을 보지 않고 이루어지는 투표라서 더 관대하게 투표를 했다고 생각합니다. 그렇다고 하더라도 아직 소스코드관리시스템의 활용도는 대단히 낮은 상태라고 볼 수 있습니다. 물론 소스코드관리시스템을 쓰지조차 않는 조직과 비교하면 상대적으로 낫겠지만, 개선할 점이 많습니다. Allofsoftware 블로그를 통해서 개선에 도움이 되는 정보를 많이 얻기를 기대합니다.

다시한번 설문에 응해주신 모든 분께 감사드립니다.

몇억짜리 툴은 쉽게 사면서 더 좋은 공짜툴은 제대로 쓸 줄 모른다.

주변의 회사들을 보면 몇 억짜리 툴을 사서 활용도 제대로 못하는 경우를 정말 많이 봤습니다.

제가 이전에 올린 글을 보면 소프트웨어를 개발하는데 있어서 그 팀의 성숙도에 따라서 무엇을 우선 도입해야 하고 무엇은 좀더 성숙도가 높아진 다음에 도입해야 하는지 설명한 적이 있습니다.

이중에서 가장 중요한 소스코드관리시스템과 버그관리시스템은 좋은 무료 툴들이 정말 많습니다. 하지만 이러한 무료 툴조차 쓰지 않거나 쓰더라도 아주 기초적인 기능만 사용을 하고 제대로 활용을 못하면서 정작 문제를 엉뚱한 곳에서 찾으려고 합니다. 그래서 비싼 툴을 팔고 있는 영업사원들에게 현혹되어서 몸에 걸맞지 않은 액세서리를 걸치듯 효용성도 떨어지는 툴을 사놓고 제대로 활용 못하는 경우가 많습니다.

쓰다 보면 그리 좋지 않다는 것을 느끼게 되도, 이를 도입한 담당자는 자신의 실수와 미숙함을 숨기기 위해서 효과를 과대포장하는 경우가 많습니다.

제가 장담 하건데 대부분의 소프트웨어 회사들은 무료 개발툴(기반시스템)로 충분히 좋은 소프트웨어를 만들 수 있습니다. 제가 이 블로그에서 소개하는 툴이나 기반시스템도 대부분은 Open Source나 무료 소프트웨어에 포커스를 하고 있습니다. 이러한 것들이 유료툴에 못지 않게 좋으니까요.

하지만 결국 무료냐 유료냐를 떠나서 얼마나 툴을 잘 사용하느냐가 중요합니다. 소프트웨어 개발에 문제가 있는 개발팀이 어느날 툴하나 도입했다고 해서 갑자기 드라마틱하게 상황이 바뀌지는 않습니다. 결국 사람들이 바뀌어야 하는데, 프로세스, 조직도 바꾸고, 각 개발자들의 마인드도 바꿔야 합니다. 스스로의 노력으로 오랜 시간에 걸쳐서 바꿀 수도 있고, 전문가의 도움을 받을 수 있죠.

앞으로도 이와 같은 툴을 유용하게 쓰는 법이나, 개발 프로세스 등 소프트웨어 개발에 우선적으로 필요한 요소들을 계속 올릴 겁니다.

감사합니다.

짝퉁 고수

이 바닥은 이상하리만치 짝퉁 고수들이 많습니다.

자신이 대한민국에서 무슨 기술이 제일 뛰어나다고 소개하는 사람을 종종 만나는데, 대한민국를 개발자 다 만나봤나 반문하고 싶습니다. 또 조금 사용해봤거나 심지어는 어디서 단어만 들어봤어도 그건 아는 거다라고 얘기하는 사람이 정말로 많습니다. 컨설팅을 하면서 개발자들의 정확한 수준을 파악하기 위해서 기술력 조사를 하는데, 자신이 전문가라고 한 항목에 대해서 beginner라도 알 수 있는 내용을 물어봐도 모르는 경우는 허다하더군요.

수많은 사람들이 자신이 고수라고 허위광고를 하고 다니는 이유는 사람들을 속이기 쉽기 때문입니다. 알맹이는 없는 표면적인 지식을 가지고 사람들을 현혹하면 더 많은 연봉을 받을 수도 있고, 더 좋은 프로젝트를 낚아챌 수도 있습니다. 하지만 이런 사람들이 진행하는 프로젝트는 자신의 실력에 비해서 무리하게 벌려 놓다가는 실패하기 일쑤이고, 또 프로젝트가 실패한 이유는 요구사항이 많이 바뀌어서라든가 다른 개발자들이 실력이 없어서라든가 PM이 무능해서 그렇다는 둥 온갖 이유를 대면서 자신의 책임을 피해가다가 약발이 떨어지면 회사를 옮겨서 또 그런 일을 반복합니다.

또, 이런 사람이 컨설팅을 한다고 하면, 자신이 알고 있는 표면적인 지식의 잣대로 수많은 종류의 회사에 적용하려고 하면 제대로 되지 않을 것은 불 보듯 뻔합니다. 그런데, 심지어는 몇 개월의 교육만을 받은 채로 컨설팅에 투입되곤 합니다. 이러한 현상들이 컨설팅 자체를 불신하는 분위기를 만들고 있다고 생각합니다.

이러한 짝퉁 고수, 짝퉁 컨설턴트를 구별하는 방법은 없을까요?

이들보다 실력이 낮은 사람이나 엔지니어가 아닌 경영자나 관리자들은 구별하기 정말 어렵습니다. 또 설령 짝퉁으로 보인다고 해도 이들에 대항해서 논리적으로 반박하기도 어렵습니다. 오히려 본인이 밀려서 낭패를 볼 수도 있습니다. 사기를 많이 당해본 사람은 사기꾼을 잘 구별하듯이 짝퉁에게 많이 당해보면 구별하는 눈이 생길 것입니다. 하지만 이 방법은 많은 비용을 지불해야 하니 별로 좋은 방법이 아닙니다. 오히려 불신만 키울 수도 있습니다. 뾰족한 답이 있어서 얘기를 꺼낸 것은 아닙니다. 그저 섯불리 판단하지 말고 신중하는 수밖에 없을 것 같습니다. 주변이 진짜 고수가 있다면 짝퉁을 가리는데 도움을 받을 수 있겠죠. 

좋은 PM은 훌륭한 리스크 관리자

프로젝트에서 가장 중요한 활동 중에 하나가 리스크 관리입니다. 프로젝트 실패의 원인의 대부분이 리스크 관리를 하지 않거나 하더라도 부실하게 하는 데 있습니다. 성공하는 프로젝트관리자는 우수한 리스크 관리자입니다.

성공하는 프로젝트는 대부분 성공 가능한 범위 및 일정을 가지고 리스크를 잘 관리한 프로젝트입니다. 반면, 성공 가능한 범위 및 일정을 가지고 시작한 프로젝트라도 리스크 관리에 거의 신경을 쓰지 않으면 예상치 못한 돌발 변수에 프로젝트는 실패하기 쉽습니다.

프로젝트 리스크 관리를 하다 보면 소프트웨어 프로젝트는 정말 가시밭길을 걷고 있다는 생각이 듭니다. 웬만한 크기의 프로젝트에서 리스크 수십 개를 찾아내기란 그리 어렵지 않기 때문입니다. 하지만 미리 발견되고 관리되는 리스크들은 그 위험을 현저히 낮출 수 있고, 다른 대처 방법들을 얼마든지 찾을 수 있습니다.

 프로젝트에서 리스크 관리는 다음과 같은 절차로 진행됩니다.

1. 리스크관리 책임자 임명 - 대부분의 중소규모의 프로젝트는 프로젝트관리자가 리스크관리자도 겸하지만 프로젝트가 대단히 크거나 특수한 경우 리스크관리자를 별도로 임명합니다.

2. 리스크 인지 - 리스크는 프로젝트에 관련된 모든 사람이 찾아내야 합니다. 추후 인지하지 못한 리스크 때문에 프로젝트가 지현되거나 실패하면, 리스크 인지가 소흘했기 때문입니다. 리스크 인지는 프로젝트 초기에 한번만 하는 것이 아니고, 프로젝트가 끝날 때까지 꾸준히 찾아야 합니다. 리스크관리자는 사소하게 흘려버리는 걱정거리들을 정리하고 계수화해서 리스크 관리 항목으로 끌어들여야 합니다.

3. 리스크 분석 - 인지된 리스크는 분석하여 분류를 해야 합니다. 그리고 발생가능성(P)과 파급효과(I)로 나누어서 분석하여 수치화를 해야 합니다. 각각은 1~5까지의 수치로 정량화를 할 수 있는데, 이때 주관적인 판단이 필요합니다. 발생가능성이 몇%가 될지를 정확하게 예측한다는 것이 거의 불가능하기 때문입니다. 그에 비하여 파급효과는 예측이 좀더 쉽습니다. 그 일이 일어났을 때 발생할 수 있는 피해를 일정이나 금액으로 환산해서 예측할 수 있습니다.

4. 리스크 우선순위화 - 프로젝트에서 관리하는 리스크는 대단히 많은 수가 됩니다. 이를 모두 동일하게 관리하기란 쉽지 않고 비효율적입니다. 따라서 우선순위가 높은 리스크를 집중적으로 관리하는 것이 좋습니다.

아래 노출도 계산 공식을 엑셀의 수식으로 변화하면 입력하면 자동으로 해당 리스크의 노출도가 계산이 됩니다.

노출도(E, Exposure) = (P/5-0.1)*0.05*(2^(I-1))

P = 발생가능성(Probability)

I = 파급효과(Impact)

낮은 노출도: 0.05 미만

중간 노출도: 0.05 이상 0.15 미만

높은 노출도: 0.15 이상

5. 리스크 대처 계획 - 리스크가 문제가 되지 않도록 미리 대처를 하거나 리스크가 발생해도 되도록 대비를 하는 것입니다. 예를 들어 개발자가 퇴사할 징후가 보일 때 다음과 같은 대응책을 마련할 수 있다.

• 개발자가 퇴사하지 않도록 노력한다.
• 개발자가 퇴사하더라도 보충할 개발자를 미리 사내에서 물색해 놓는다.
• 사내에서 보충한 개발자를 찾지 못하면, 외부 채용 활동의 준비 단계를 해 놓는다. 즉, 채용 공지를 하고, 이력서를 분석하여 채용자 후보를 미리 물색해 놓는다.
• 해당 개발자의 모듈을 다른 개발자와 많은 부분 공유하도록 계획 한다.
• 아예 해당 개발자를 프로젝트에서 제외하고 진행한다.

6. 리스크 감시 - 프로젝트가 진행되면서 리스크는 계속 변합니다. 따라서 리스크를 지속적으로 감시해야 합니다. 리스크의 모든 기록은 리스크관리대장을 만들어서 기록해야 합니다. 리스크관리대장에는 다음과 같은 것들이 적힙니다.

• 리스크 제목
• 리스크 내용
• 리스크 분류
• 리스크 발생 가능성
• 리스크 파급 효과
• 리스크 관리계획
• 리스크 발생 시 대처 계획
• 리스크 대처 기록
• 리스크 재평가 기록

리스크를 주기적으로 재평가하고 우선순위를 재정렬하고, 리스크 대처 계획을 갱신해야 합니다. 이와 더불어 새로운 리스크를 인지하기 위해서 지속적인 리스크 감시를 해야 합니다. 리스크관리대장에 내용이 꾸준히 쌓이면, 프로젝트가 끝난 후에도 다른 프로젝트에서 참조할 수 있습니다. 이 때 놓치기 쉬운 리스크를 쉽게 찾아낼 수도 있고, 리스크에 어떻게 대처해서 문제를 해결했는지도 도움을 얻을 수 있습니다.