2009년 3월 30일 월요일

외주를 주면 된다고요?

"우리가 못하면 외주를 주면 된다."

이렇게 생각하십니까? 아니면 인력이 모자라거나 시간이 부족하여 외주를 주십니까?
대부분의 개발자라면 외주에 대한 쓰라린 기억이 있을 겁니다.

한 포탈업체가 인도에 포탈 시스템 외주를 줬다가 통째로 버리고 국내 업체에 다시 외주를 줘서 개발한 적이 있습니다. 그리고도 국내 업체에 질질 끌려 다녔었지요.

인도에 외주를 줄 때는 스펙을 제대로 전달 하지 못했고, 개발 기간에도 전혀 관리와 리뷰를 하지 않고 최종 결과물만 받아 본 사례입니다. 이런 케이스 많죠?

그리고 국내 업체에 외주를 줄 때도 자체적으로 기술을 보유하지 못하고 외주에 의존하다 보니 지속적으로 문제가 됩니다.

결국 스스로 만들 능력이 없는데, 외주를 주는 것은 성공할 확률도 낮고, 경험있는 외주 업체를 만나면 개발은 제대로 되더라도 질질 끌려다니기 일쑤입니다. 또한 외주를 주기 위해서는 분석능력과 관리 능력이 필수 입니다. 특히 해외 업체에 외주를 줄 때는 대단히 정교한 스펙문서(SRS 등)가 필요합니다. 따라서 대다수의 업체는 외주를 줄 능력이 없다고 볼 수 있습니다. 그래서 외주가 아니고 사람만 빌려오는 거죠. 옆에 앉혀놓고 같이 의논해가면서 개발하는 방법이 유일한 방법입니다. 소프트웨어 개발 생산성이 아직도 매우 낮은 수준에 머물러 있는 원인이기도 합니다. 

"스스로 잘 할 수 없다면 외주는 더 어렵다."

2009년 3월 28일 토요일

RSS Feed 업데이트 문제 해결

저는 RSS Feed를 위해서 Feedburner를 사용하고 있었습니다. 
오랫만에 Feedburner 사이트에 들어가서 이거 저거 보고 있는데, 3월초부터 제 블로그의 RSS Feed가 전혀 업데이트가 되고 있지 않았었습니다. 
그래서 TroubleShootize 메뉴에서 원인을 찾아봤습니다.


이걸 보니 3/11에 에러가 난 것이 발견이 되더군요. 
"Feed의 크기가 너무 크다."
"Maximum size는 512K다."

다들 알고 계신 내용인지 모르지만 저는 모르고 있었습니다.
기억을 더듬어보니 제가 그당시 Feed의 크기를 키우는 행동을 몇가지 한 것 같더군요.

첫째, RSS Feed를 부분 공개에서 전체 공개로 바꿨습니다. 여러분들이 글을 읽어 주는 것이 목적이므로 굳이 블로그에 들어오지 않아도 된다고 생각해서 전체 공개로 바꿨었습니다.

둘째, RSS Feed 갱신 개수를 10개에서 30개로 늘렸습니다.

셋째, 저는 OneNote를 이용해서 글을 작성을 하고 나중에 Copy&Paste해서 글을 올렸었습니다. 그렇게 하니 원래 글보다도 크기가 5배 이상 커지더군요. OneNote의 CSS가 너무 복잡해서 괜히 크기가 커지고 있었습니다.

이러한 3가지가 겹쳐서 3/11에 드디어 512K를 넘기는 일이 발생했습니다.

지금은 2,3번째를 수정해서 10개로 줄이고 복잡한 스타일의 글도 간단하게 수정해서 크기를 대폭 줄였습니다. 그러고 나니 RSS가 다시 업데이트가 되는 군요.

그동안 2주 넘게 RSS를 기다리신 분들께 죄송합니다. 

RSS Feed가 잘되는지 수시로 점검도 해봐야 겠어요. 앞으로는 Text Editor로 일단 글을 옮긴 후에 Plain Text를 블로그에 붙여 넣는 식으로 글을 작성해야 할 것 같습니다.

혹시 저와 같은 장애를 겪으신 분은 안계시나요?

마지막으로 옛날 Feed(http://feeds2.feedburner.com/softwaredev)를 사용하고 계신 분들은 
새로운 Feed인 http://feeds2.feedburner.com/allofsoftware 로 바꿔주시면 좋겠습니다. 블로그 이름을 바꾸면서 Feed이름도 바꿨는데, 지금은 괜히 바꿨다는 생각을 하고 있습니다. 옛날 Feed 구독자가 줄어들지 않아서 완전히 두개가 되어 버렸습니다. 

감사합니다.

2009년 3월 27일 금요일

Peer Review를 성공하기 위한 요소들

얼마 전에 "코드리뷰 정착이 어려운 이유"라는 글을 올린 적이 있습니다.

그에 대해서 codeart 님께서 코드리뷰에 대한 일반적인 방법론에 대해서 궁금해 하시더군요. 하지만 이런 방법론은 알면 도움이 되지만, 이것을 안다고 코드리뷰를 성공하는데는 별로 도움이 안됩니다. 하지만 몇가지 성공 요소는 생각해 볼 수 있습니다. 

이제부터는 코드리뷰보다는 Peer Review라고 하겠습니다. 사실 코드만 리뷰를 하는 것이 아니고 스펙문서부터 소스코드등 개발 관련된 산출물들을 다 리뷰를 합니다. 그리고 동료들간에 검토를 해 준다는 것이 중요한 요소입니다.

그럼 Peer Review를 성공하기 위해서는 어떻게 해야 하는지 한번 보죠.

첫째, 개발자들끼리 으쌰으쌰 해서는 성공하기 힘듭니다. 회사에서 정책적으로 Peer Review를 추진해야 합니다. 개발잘들끼리 한번 해보려고 하는 것은 Peer Review를 너무 우습게 본 겁니다. 그냥 시간 좀 내서 서로 리뷰해주면 되지 뭐 그렇게 어려울게 있어? 라고 생각하면 오산이죠. 일단 많은 시간을 빼앗기는 것이 가장 큰 장애물입니다. 처음에는 의욕적으로 시작했다가, 금방 시들해지게 됩니다. 아직 Peer Review가 정착되지 않은 회사에서 개발자들끼리 한번 시도해보는 것은 거의 대부분 실패합니다. 따라서 회사에서는 Peer Review 담당자도 지정을 해주고, 제도와 자원을 지원해야 합니다.

둘째, 개발일정에 Peer Review를 포함해야 합니다. 그러면 더 시간이 오래 걸린다구요? Peer Review가 조금만 정착이되어도 결국은 이것이 훨씬 시간을 더 절약해준다는 것을 알아야 합니다. 테스트 시간이 절약되고, 유지보수 비용이 절약되고, 후배들이 빨리 성장하고 여기저기서 중복된 코드를 만드느라고 헛되이 보낸 시간이 절약됩니다. 이는 너무 뻔한 것이기 때문에 Peer Review가 개발 시간과 비용을 얼마나 절약하는지 증명하라고 하면 허탈하죠.

셋째, Peer Review는 동료와 하는 겁니다. 강사가 학생들을 가르치는 것도 아니고, 고객에게 설명을 하기 위한 것도 아니고, 서로 리뷰를 하면서 결함을 찾는 겁니다. 여기에 집중해야 합니다.

넷째, 자주해야 합니다. 프로세스에 따라서 빡빡하게 진행하기보다는 수시로 동료들과 리뷰를 하는 것이 좋습니다. 언제든지 "이것 좀 봐줘"하면서 부탁을 할 수 있고, 짧은 시간을 내서 흔쾌히 봐주면서 차츰 적응해 가야 합니다. 많은 양을 몰아서 리뷰를 하게 되면, 쉽게 질려서 포기하게 되고, 모든 코드와 문서를 모든 개발자가 다 리뷰를 해야 하는 것은 아니니 수시로 적당한 동료와 리뷰를 하면 좋습니다.

적어도 이 네가지만 지켜도 Peer Review를 지속하는데 약간의 도움은 될 겁니다.

그런데, 왜 Tool에 대한 설명은 없냐구요? Tool이 리뷰를 대신해주지는 않기 때문에 Tool을 그렇게 심각한 요소는 아닙니다. Tool이 도움이 될 수는 있지만, Tool이 없다고 리뷰를 못하지는 않습니다.

위 조건을 보면 일단 첫번째에서 막힐 수 있습니다. 설령 회사차원에서 Peer Review를 시행하더라도, 촉박한 일정에 쫓겨서 쉽게 포기해버리기 일쑤입니다. 이런 상황이라면 Peer Review가 정착하기는 어렵습니다. 회사도 단단한 의지가 없다면 Peer Review를 정착시키는 대단히 어렵습니다.

이렇게 만만한 일이 아니기 때문에 회사의 개발 성숙도에 따라서 적절한 계획이 필요합니다. 처음부터 욕심부리면 금방 포기하게 됩니다.

2009년 3월 26일 목요일

밥그릇을 지키려는 처절한 몸부림(기생충 개발자)

자신이 작성한 소스코드를 숨김으로써 자신의 밥그릇을 지키려고 애쓰는 개발자들이 상당히 많습니다.

이런 개발자들의 특징은 자신이 작성할 소스코드는 정말 어렵고 복잡하다고 광고를 하고, 소스코드관리시스템에 등록하는 것을 거부하거나 코드리뷰를 기피합니다. 그리고 철저히 문서와 주석 없이 코딩을 하며 심지어는 소스코드를 비비 꼬아서 분석하기 어렵게 만들어 놓기도 합니다.

개발자들의 이러한 행동은 단기적으로는 자리보존에 도움이 될지 모르지만, 스스로의 발전을 저해하고 결코 오래가지 못할 것입니다.

또한, 이러한 개발자들이 한두 명만 있어도 회사는 큰 시한폭탄을 안고 있는 것과 마찬가지입니다.

저는 직업상 수많은 개발자들을 만나기 때문에 이런 개발자가 정말로 많고 웬만한 소프트웨어 회사에는 꼭 몇 명씩 있다는 것을 잘 알고 있습니다. 실제로 수년 전 알고 있던 한 회사에서는 개발자가 암호 같은 소스코드를 잔뜩 남겨놓고 인수인계도 하지 않고 퇴사를 했는데, 소스코드관리시스템을 사용하지 않았기 때문에 개발 History도 하나도 없고, 스펙서도 설계서도 없고, 소스코드는 주석도 하나 없이 깨끗했으면, 혼자 다루던 소스코드라서 이를 알고 있던 개발자는 하나도 없었습니다. 물론 코드리뷰도 안 했었지요. 그래도 회사에서 가장 뛰어난 개발자라고 추켜줬었는데, 달랑 소스코드만 남은 상태에서 회사는 위기를 맞게 되었습니다. 이런 스토리는 너무흔합니다. 대부분 비슷한 얘기는 한 두개씩 알고 계실 걸요?

대부분의 별것도 아닌 소스코드라 하더라도 이렇게 망쳐 놓은 상황이라면 유지보수하기가 정말 어려운 상황이 됩니다. 이렇게 회사의 피를 빨아먹고 다른 곳으로 옮겨 다니는 "빈대형 개발자"가 있는 반면에 회사가 망할 때까지 회사를 숙주 삼아 오랫동안 고혈을 빨아먹는 "기생충형 개발자"도 있습니다.

이러한 개발자는 회사도 어렵게 하고, 본인 스스로도 미래를 지워버리는 것과 같습니다. 개발자는 이렇게 자신만 아는 소스코드를 생산함으로써 자신의 밥그릇을 지키기보다는 소프트웨어 전문가로서의 실력을 키우는데 집중해야 할 것입니다. 그래야 회사도 살고 본인의 미래도 키워집니다.

그럼 이런 개발자가 있는 회사는 어떻게 해야 할까요?

당장 짤라 버리십시오.

그럼, 회사가 망한다구요? 그런 상황이라면 이미 시기를 놓치셨네요. 안타깝습니다. 암조직을 떼어내는 순간 본인도 죽을 수 있는 상황이 된 겁니다. 당분간은 암조직과 같이 살아야 합니다. 그리고 암조직을 떼어내어도 살 수 있도록 체력을 키우셔야죠.

회사의 개발 체계를 정립하고, 소스코드를 관리하고, 개발 문서를 제대로 만들고, Peer Review도 시행을 해야 합니다. 3년이 걸릴지 5년이 걸릴지 모르는 일이지만, 이 수밖에 없습니다. 전문가의 도움을 받으면 시간이 조금 앞당겨지겠지요. 이 동안 이런 "기생충, 빈대형 개발자"들의 엄청난 반대와 비평에 시달릴 겁니다. 당장 프로젝트가 급하다고 하기도 하고, 개발자의 창의성을 방해한다고 하기도 하고, 온갖 그럴싸한 이유를 댈 겁니다. 그럼 같이 망하는 거죠. 듣기에는 정말 그럴싸하지만 이는 자신의 밥그릇을 지키기 위한 본능적인 몸부림이라는 것을 잊으면 안됩니다. 그렇다고 대놓고 이런 개발자를 비난하면 안됩니다. 살살 잘 유도해서 새로운 체계로 끌어들여야죠. 그렇지 않아서 중간에 나가버리면 곤란합니다. 그리고 이런 개발자들에게 기회를 줘야죠.

사실 대부분의 소프트웨어 회사의 경영자들은 이러한 고비를 넘지 못합니다. 심지어는 자신의 회사가 이러한 개발자에게 피를 빨리고 있다는 것을 인식조차 못하는 경우도 많습니다. 이러한 개발자가 회사를 먹여 살리고 있다고 생각하고 성실히 일하는 보통의 개발자들은 이런 개발자보다 못하다고 생각하기도 합니다.  이런 회사야 어차피 싹수가 없지만, 이를 알고 있는데도 이미 암덩어리가 커져서 어떻게 못하는 상황이라면 각고의 노력을 해야 합니다. 혼자 어려우면 전문가의 도움도 받으세요.

개발자들을 비난하기 위해서 이 글을 쓰는 것은 아닙니다. 대부분의 개발자들은 성실히 일하니까요. 대부분의 성실한 개발자들이 이러한 개발자들에게 피해를 당하지 안았으면 하는 바램이고, 소프트웨어 업계 저변에 소프트웨어 공학이 잘 접목된 개발 방법이 퍼져서 개발자도 살고 성공하는 회사도 마구 쏟아져 나오는 미래를 기대하는 마음에 글을 씁니다. 그동안 제 글들을 읽으신 분이라면 제가 소프트웨어 개발을 사랑하고 있다는 것을 아실 겁니다.

2009년 3월 24일 화요일

코드리뷰 정착이 어려운 이유

코드리뷰는 소프트웨어를 개발하는데 있어서 가장 좋은 문화중의 하나이지만 또한 가장 정착시키기 어려운 것 중의 하나입니다.
 
코드리뷰를 도입하거나 정착하기 어려운 이유는 다음과 같습니다. 
  • 공개적으로 망신을 당하거나 자신을 비판하는 것에 대한 두려움
  • 과거의 부정적인 코드리뷰에 대한 경험
  • 자신이 실력이나 약점이 드러나서 평가가 나빠질 것에 대한 두려움
  • 자신의 코드는 완벽하다는 밑도 끝도 없는 확신 및 자신에 대한 너그러움
  • 코드리뷰가 개발 일정을 지연시킨다는 생각
  • 코드리뷰보다는 테스트가 더 효율적이라는 믿음
  • 남을 비평하거나 비평 받는 것을 싫어하는 문화
 
실제로 준비 없이 코드 리뷰를 시행하면 위와 같은 모든 일이 일어나서 개발자들의 거부감을 불러 일으키게 됩니다.
 
주기적으로 시간을 정해놓고 끝장 코드리뷰를 하고 있는데, 시간이 지날수록 지루하고 졸리게 되고, 코드에 대한 사전 검토 없이 바로 코드리뷰에 들어와서 코드를 보니 코드가 눈에도 잘 안 들어 오고, 서로 코딩 스타일이나 모양에 대해서 지적을 하느라고 진도가 안 나갑니다.
코드리뷰에 들어온 개발자를 한번 왕창 깨놨더니 다들 코드리뷰를 하기 두려워 하고, 처음에는 의욕을 가지고 시작했으나 점점 "이거 왜 하나"라는 생각이 들어서 슬슬 피하게 됩니다.
개발하기도 바쁜데 리뷰할 시간이 어디 있나 생각이 들고, 바쁘게 코드를 작성하다 보니 남을 보여주기가 창피하기도 합니다. 또, 내 코드 다 오픈하면 내 힘이 줄어드는 것이 아닌가 하는 생각이 듭니다.
회사에서는 코드리뷰를 자꾸 하라고 하는데, 안해도 그만이고 내 시간만 갉아먹는 코드리뷰는 적당히 피하고 싶은 것이 일반적입니다.
 
코드리뷰를 정착하기 위해서 툴을 사용하기도 하고, 제도를 만들기도 하지만, 하나의 정답이 있는 것은 아닙니다. 회사의 개발 역량 수준에 맞게 단계별 계획을 세워서 서서히 정착 시켜 나가야 합니다. 회사의 개발 문화 성숙도가 어느 정도 수준인지 어느 정도의 제도를 소화해 낼지 판단하고 적절한 계획을 세우는 것 또한 많은 경험이 필요한 일입니다. 일단 쉽게 시작할 수는 있지만 가장 효과적인 계획을 세우는 것은 경험자의 도움을 받는 것도 좋은 방법입니다.

모든 개발자들이 코드리뷰를 당연 시 하기 전까지는 언제든지 실패할 가능성이 있습니다.

2009년 3월 23일 월요일

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

소스코드를 신주단지 모시듯 하는 회사나 개발자들을 자주 볼 수 있습니다.
소스코드가 자신들의 모든 기술이 함축된 집합체라고 생각들을 합니다.
 
저는 이런 회사나 개발자들 딱 접하는 순간 그 수준을 한번에 알 수 있습니다. 다른 것들은 별로 물어볼 필요도 없이 그로 인해서 회사가 어떤 식으로 개발을 하고 있다는 것을 쉽게 짐작할 수 있습니다.
 
그러한 회사들은 소스코드를 개발자를 제외한 다른 직원들은 접근하지 못하도록 하기 위해서 보안장치를 두고 개발자는 자신이 작성한 소스코드를 공유하기 꺼려하기도 합니다. 개발의 내용은 SRS나 설계서에 포함되어 있기보다는 그냥 코드에 숨어 있어서 이를 작성한 사람이 아니면 전체를 파악하기 정말 어렵습니다. 해당 개발자가 아니면 유지보수가 어렵고 신입사원이 들어와도 공유가 잘 안됩니다.
 
이런 말이 있습니다.
"경쟁회사를 어렵게 만들고 싶으면 자사의 소스코드를 실수인척하고 공개해서 경쟁회사로 흘러 들어가게 하라"
그 경쟁사는 소스코드를 얻고 횡재한 줄 알겠지만, 이를 분석하다 보면 몇 달 후 별로 얻은 것은 없이 시간만 낭비했다는 것을 알게 될 것입니다.
 
가슴에 손을 얹고 생각해보면 우리가 작성하는 소스코드 중에서 정말 획기적인 것이 있나요? 남들은 절대로 만들지 못할 엄청나게 어려운 것이 있나요? 대부분은 이미 다 공개된 알고리즘과 모듈들입니다. 물론 그런 것들이 있다면 잘 지켜야 겠지요. 하지만 그런 경우는 거의 찾아보기 힘듭니다.

정작 중요한 것은 그 아키텍처이고, 스펙입니다. 그리고 개발자들의 역량과 팀웍이죠. 그것들이 다른 회사와 우리 회사를 다르게 만들어주는 요소입니다. 소스코드는 아니죠.
 
물론 소스코드가 소프트웨어를 이루는 중요한 요소이기는 하지만 소스코드의 보안에만 신경 쓰는 순간 자신의 수준을 확 낮춘다는 것을 알아야 하겠습니다.

2009년 3월 15일 일요일

소프트웨어 개발자의 권리

지난번 글에서 소프트웨어 개발자윤리(의무)에 대해서 얘기를 한 적이 있습니다.
그때 많은 분들이 개발자의 권리도 좀 생각해보자고 하였습니다.
이에 개발자의 권리와 개발자에 대한 경영자와 고객의 의무를 정리해 봤습니다.

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

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

 개발자에 대한 경영자의 의무
○ 개발자를 부품이 아닌 전문가로 생각해야 한다.
○ 개발자에게 최상의 개발 환경을 제공해야 한다. 
○ 개발자에게 적절한 교육을 받을 수 있도록 해야 한다. 
○ 개발자가 원하는 캐리어로 성장할 수 있도록 보장해야 한다. 
○ 개발자는 근무시간이 아닌 실력과 성과로 평가해야 한다.  
○ 개발자의 실력과 성과에 합당한 보상을 제공해야 한다.
 개발자에 대한 고객의 의무
○ 개발자를 하나의 인간으로서 존중해야 한다. 
○ 개발팀의 개발프로세스를 존중해야 한다. 
○ 요구사항을 개발자에게 정확하게 전달해야 한다.
○ 개발자의 요청에 시기적절하게 대응해야 한다. 
○ 개발 기간이나 시간을 산정한 개발자의 분석을 존중해야 한다. 
○ 요구사항 변경요청은 최대한 빨리 개발자에게 알려야 한다. 
○ 요구사항 변경은 개발팀의 프로세스를 따라야 한다.

2009년 3월 11일 수요일

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

개발자들은 모든 생각의 중심을 본인으로 생각하는 경우가 흔합니다.
소프트웨어를 개발하면 모든 판단의 기준을 본인으로 하는 것이지요.

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

적용하는 기술도 본인이 잘 알고 익숙한 것으로, 또 사업적인 관점으로 고려를 하기보다는 본인의 취향에 따라서 섯부른 판단을 하는 경우가 많습니다.
특히나 이렇게 자기 중심적인 사고방식에 꽉 막혀 있는 개발자들과는 대화조차 어려운 경우가 많습니다. 보통 고집도 센 것이 아니어서 같이 일하기 피곤합니다. 이런 개발자들이 실력이 뛰어난 것처럼 보여서 어쩔 수 없이 붙들어 두고 있는 경우가 많은데 일찌감치 팀에서 제외를 하던가 해고를 하는 것이 더 나을 겁니다.

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

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

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

2009년 3월 8일 일요일

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

지난번 소스코드관리 방법 조사 후 좀더 상세하게 각 회사나 개발팀이 소스코드를 관리하면서 어떤 방법들을 사용하는지 즉 그 성숙도를 알아보기 위해서 약 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 블로그를 통해서 개선에 도움이 되는 정보를 많이 얻기를 기대합니다.

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

2009년 3월 5일 목요일

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


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

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

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

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

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

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

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

감사합니다.