2008년 11월 12일 수요일

소프트웨어 프로젝트는 누가 진행하는가?



안녕하세요. 조성경님. Ray라고 합니다.
블로그에 쓰신 글을 보고 동감을 하면서 제 의견을 몇자 덧붙여 봅니다.

소프트웨어 프로젝트를 진행하기 위해서는 여러 전문가가 필요하죠.
프로젝트관리자도 전문가여야 하고, 개발자들도 소프트웨어 전문가여야 하고, 분석/설계/테스트/빌드/UI/Techpub 등 많은 전문가가 있어야 하죠.
물론 프로젝트 규모에 따라서 혼자서 이 모든 일을 다하는 경우도 있고, 수백명이 각각의 업무를 나눠서 하는 경우도 있습니다.
확실한 것은 혼자서 뚝딱뚝딱 만드는 것과는 다르다는 것이죠.
그런데, 우리는 전문적이지 못한 사람들이 모여서 프로젝트를 진행하는 경우를 허다하게 봅니다.

그런 이유는 간단합니다. 
그렇게 일을 해왔기 때문에 전문적인 지식을 배울 기회를 별로 보기 어렵고 그러다 보니 후배들에게 별로 가르칠 것이 없는 악순환이 계속 됩니다.
그래서 코딩 기술과 몇가지 Domain 지식만을 가지고 욹어 먹게 되는 경우가 많죠.

이런 기반이 잘되어 있는 회사에 들어가서 몇년 일하는 것만으로도 충분히 배울 수 있으나 그런 회사가 그렇게 많지 않는 것은 안타까운 일입니다.

조성경님이 경험했던 "소스보세요", "서버만들어" 이런 현상은 아주 흔합니다.
회사의 지식이 문서화 되어 있지 않고 소수의 머리속에 있고, 
소프트웨어 프로젝트를 진행하는데 가장 중요한 스펙의 중요성을 잘 모른 것이지요.

이 글에서 말하려고 하는 요지는 소프트웨어 엔지니어라면 단순히 코딩, 요소기술, Domain 지식에 매달리지말고, 소프트웨어 엔지니어로서 갖춰야 할 다양한 지식의 전문가가 되어야 한다는 것입니다.

제 책(소프트웨어 개발의 모든 것)에서도 이에 대한 내용을 상당히 다루고 있습니다.
앞으로 전문가로서 갖춰야 할 지식에 대해서 블로그에 계속 포스팅을 해나갈 겁니다.

감사합니다.


 난 자율따위는 믿지 않는다.

10개월이 걸리는 프로젝트A가 있다고 하자. 프로젝트A를 10개월에 끝낼 수 있는 능력을 실제로 가진 10명을 모아 따로 프로젝트를 진행하게 한다. 조건은 다음과 같다.

>> 어떠한 간섭도 없고 10개월 후 결과물을 보여준다.

10개월 후 제대로 프로젝트를 완료한 사람은 몇명이나 될까? 나는 많아야 한두명이 기대에 충족하는 결과를 내놓을 것이라고 본다. 실력이 모자란 사람은 없지만 자신을 관리할 수 있는 사람은 드물기 때문이다. 개인적인 경험에 의존한 결론이기는 하지만 당분간 이 생각을 바꿀것 같지는 않다.

내 경험과 다른 이들의 증언을 종합해보면 2~3개월 이상의 긴 일정을 툭 던져놓고 신경 끄는 관리자들이 있다. 이런 경우는 십중팔구 실패나 일정지연을 유발한다. 이때 실패는 작업자와 관리자중 누구의 잘못이 더 클까? 내 기준으로는 100% 관리자의 잘못이다. 만약에 이런 실패가 없다면 관리자는 존재 가치가 없다. 모든 조직에 관리자가 있다는 사실 자체가 스스로 뭔가를 알아서 하는게 쉽지 않다는 증거인데도, 이를 무시한다.

첫 회사에서 내가 받은 첫 주문은 "소스 보세요", 두번째 회사에서는 "서버 만들어"였다. 그래서 소스를 보고 고치고, 서버를 만들었다. 이 과정으로인해 나는 몇번의 큰 실수를 한다. 내가 그렇게 해왔으니까 남들도 그렇게 하면 되는 줄 알았고, 그렇게 못하는 남들을 제대로 이해하지도 못했다. 그리고 그렇게 하지 못하는 사람들을 낮게 평가했다. 지금 생각해보면 그냥 부끄러운 과거일뿐이고, 그 사람들에게 진실로 미안한 마음이 든다. 그때는 내가 미숙했다.

다시 프로젝트A를 진행하는 10명으로 돌아가보자. 프로젝트를 성공적으로 끝낼 한두명이 나머지보다 낫다는 점은 두말할 가치가 없다. 그러나 나머지 사람들이 쓸모없는 사람이냐라고 묻는다는 그건 절대 아니다. 단지 그들이 잘 못하는 부분이 들어났을 뿐이다. 좋은 관리자라면 그들을 이끌고 목표를 향해 나갈 줄 알아야하고, 경우에 따라서는 그들이 더 좋은 결과를 만들기도 한다.

왜 이런 구질구질한 얘기를 했냐면 오전에 있었던 엔진쪽 인원에 대한 평판 조회(reference check) 대답때문이다. 평가를 간단히 요약하면 엔진 연구하라고 했는데 1년이 넘도록 제대로된 결과를 만들지 못해서 해고했었다고 한다. 따져 묻고 싶은게 많았는데 그리 친한 사이도 아니라서 더 물고늘어질수는 없었고 잡다한 생각들이 들었다.

1년이 넘도록 결과물을 얻지 못했을 때 관리자는 뭘 했으며, 1년이 넘게 기다려야 했을까?
그 사람이 1년 넘는 기간동안에 진짜로 한 일은 뭘까?

이러한 생각에 대한 내 대답이 바로 이글이다. 계속 해고하면서 자기 스스로 관리가 가능한 스타 플레이어를 채용할 운을 시험해보는 것은 관리자 스스로가 무능하다는 자백과 다를게 없다. 그러니 이거 보세요, 분석하세요, 공부하세요 이런 말은 고만하자.

Broken tree



소프트웨어의 빌드가 안 되는 상황을 Broken Tree라고 합니다.

소프트웨어를 개발하는 회사라면 Broken Tree 발생을 엄격하게 규제해야 합니다.
소스코드관리시스템 안의 소스코드는 항상 빌드가 가능한 상태로 존재해야 합니다.
그리고 언제든지 꺼내서 빌드를 하면 빌드가 되어야 합니다.

개발자들은 버그를 고치거나 새로운 기능을 추가할  소스코드관리시스템에서 최신 소스코드를 가져와서 소스코드를 고치고 개발자 테스트를 마친 후 소스코드를 체크인 하는 것만으로 임무가 끝나지 않습니다.  내가 소스코드를 수정하는 사이에 누군가가 다른 소스코드를 수정했을 수도 있으니  다시한번 최신 소스코드가 빌드가 되는지 확인 해야 합니다.

믈론 한두명이 개발한다면 이런 일은 거의 없겠지만  규모의 회사나 프로젝트에서는 종종 발생하는 문제 입니다.

항상 빌드가 가능한 소스코드를 유지하기 위해서 CI (Continuous Integration)솔루션을 사용하기도 합니다.

빌드가  되는 코드를 체크인한 개발자는 모든 업무를 제쳐놓고 빌드가 가능하도록 만들어야 합니다
Broken Tree 만드는 것은 개발자가 저지르는 가장 심각한 잘못 중의 하나입니다.




2008년 11월 10일 월요일

소프트웨어 프로젝트에서 빌드를 어떻게 하시나요?

소프트웨어를 개발하고 계신다면 빌드를 어떻게 하고 계시나요?

여기서 제가 말하고 있는 "빌드"는 "공식빌드"입니다.
"공식빌드"란 소프트웨어를 개발하는 프로젝트나 절차에서 공식 Output을 만들어 내는 것입니다.

"공식빌드"가 아닌 것은 "엔지니어링 빌드"라고 합니다.
이는 개발자가 자신의 작성한 코드를 테스트하기 위해서 비공식적으로 하는 빌드입니다.

그럼 원래 질문으로 돌아가서 "공식빌드"를 어떻게 하고 계십니까?

혹시 IDE(통합개발환경)에서 빌드를 하고 계시나요?

Visual Studio나 Eclipse의 IDE를 이용해서 빌드한 결과물이 공식적으로 릴리즈가 되고 있습니까?

그러면 잘못되고 있는 겁니다.

"공식빌드"는 IDE에서 이루어지면 안됩니다. 
"공식빌드"는 빌드 전용 장비에서 커맨드라인 통해 한, 두개의 스크립트로 자동으로 전과정의 빌드가 이루어져야 합니다.

빌드작업은 대단히 전문적인 작업이라서 쉽게 생각할 것이 아닙니다.
전문화되고 자동화된 빌드는 소프트웨어 개발 생산성을 대단히 높여 줍니다.

실제로 자동화되지 않은 빌드로 인해서 많은 소프트웨어 프로젝트에서 쓸데 없는 비용을 낭비하고 있습니다.

자동화된 빌드를 통해서 할 수 있는 일은 대단히 많습니다.
자동화가 되어야 Daily Build가 가능하며, 빌드 후에 각 소프트웨어마다 이루어지는 수많은 부가 작업들이 자동으로 연결이 가능해 집니다.
어떤 제품은 Smoke Test를 붙이기도 하고, 
Packaging을 해서 CD에 굽기 전의 상태까지 준비가 되기도 하고, 
홈페이지에 업데이트 버전이 등록되기도하고,
버그관리시스템과 연동도 됩니다.
이러한 부가 작업은 소프트웨어나 회사마다 다릅니다.

전문 빌드담당자가 정해지면 이러한 일련의 작업에 대해서 책임감을 가지고 향상을 시키게 됩니다.
이러한 것들이 눈에 잘 보이지는 않지만, 소프트웨어 개발 역량 및 생산성 향상에 많은 영향을 미치게 됩니다.

"공식빌드"와 "엔지니어링빌드"에 대해서 구분없이 소프트웨어를 개발하고 계신다면 
일단 "빌드의 중요성"에 대해서 인지를 하셔야 합니다. 
막연히 빌드의 중요성은 알기 어렵죠. 앞으로 이에 대해서 계속 포스트를 하도록 하겠습니다.

빌드에 대한 의견 환영합니다.

안다는 것과 모른 다는 것

사람들은 어떤 지식에 대해서 아래 3가지의 모습을 보이는 것 같습니다.

1. 모르는 것을 안다고 생각하는 것
2. 아는 것을 안다고 생각하는 것
3. 모르는 것은 모른다고 생각하는 것 

여기서 모르는 것을 모른다고 생각할 수 있는 자세야 말로 엔지니어에게 꼭 필요하지만,
의외로 모른 것을 안다고 착각하거나 
아주 조금만 아는 것을 전체를 안다고 생각하거나 
자신이 아닌 범위가 전체인줄 아는 경우가 많습니다.

자신이 모르는 것이 무엇인지 아는 사람이 가장 많이 아는 사람이라고 생각합니다.

하지만 자신이 모르는 것을 정확하게 알고 인정하는 것은 대단히 어려운 일인것 같습니다.

모르는 것을 안다고 생각하는 사람들은 사고를 많이 치고,
모르는 것을 모른다고 생각하는 사람에게는 지속적인 발전이 있다고 생각합니다.

2008년 11월 7일 금요일

소스코드관리시스템을 몇개 사용하고 있나요?

소프트웨어 개발 컨설팅을 하다보면 여러가지 경우를 보지만 그중의 한 예를 소개할까 합니다.

국내의 굴지의 금융회사 중의 한 사례입니다.
회사 내에서 각 팀별로 소스코드관리시스템을 여러 개를 사용하고 있더군요.
A팀 Windows 플랫폼의 Application를 개발하니까 Microsoft Visual SourceSafe를 사용하고
B팀 Web 서비스를 개발하고 있었는데, CVS를 사용하더군요.
그리고 C팀은 Unix에서 개발을 하는데, 아무런 소스코드관리시스템을 사용하고 있지 않았고,
D팀은 별로 잘 알려져 있지 않은 외국의 상용 제품의 한글화된 버전을 사용하고 있었습니다.

한 회사에 총 4가지 유 형의 소스코드 관리가 존재하는 겁니다.



이런 상황에서는 다음과 같은 부작용이 생깁니다.
  • 개발자들이 다른 부서로 이동할 때 쓸데 없는 학습 비용이 들어 갑니다.
  • 중복된 시스템 및 관리 비용이 들어갑니다. 소스코드관리시스템은 비용이 많이 들어가는 시스템입니다. 
  • 각 부서간의 정보의 공유가 어렵게 됩니다.

이런 일들이 발생하는 이유는 다음과 같습니다.
  • 회사에서 기술적인 결정을 컨트롤하는 상위 조직이 없어 개발자들의 입맛에 따라 각각 다른 시스템을 쓰게 된 경우
  • 회사를 인수하면서 기존의 시스템을 그대로 사용하고 통합을 시도하지 않은 경우

소스코드관리시스템은 한 회사에 딱 하나만 설치하는 것이 좋습니다. 세계 각지에 떨어져서 개발을 하더라도 하나의 소스코드관리시스템을 사용해야 합니다.

만약 이미 여러가지 소스코드관리시스템을 사용하고 있다면 비용을 지불하고라도 통일을 하는 것이 좋습니다.
이러한 통일 작업은 기계적으로 할 수도 없는 어려운 작업이 됩니다. 
하지만 늦어질 수록 더 많은 비용을 치르게 됩니다.

2008년 11월 5일 수요일

기반시스템(Infrastructure System)을 사용하고 계신가요?

기반시스템(Infrastructure System) 용어를 들어보신 적이 있나요?

기반시스템(Infrastructure system) 소프트웨어를 개발하는데 꼭 필요한 기초 환경입니다.
여러분들도 쓰고 계시는 것이 있을 겁니다소스코드를 CVS 저장하고 버그를 관리하기 위해서Bugzilla Mantis 사용하고 있다면 바로 그러한것들이 기반시스템(Infrastructure System)입니다.
이러한 것들은 매우 다양한 분야에서 소프트웨어 개발을 돕고 있습니다.

기반시스템 없이는 생산적으로 소프트웨어 개발할 없습니다기반시스템은 소스코드를 안전하게 보관해주고프로젝트 구성원 간의 의사소통을 원활하게 해주는 등 프로젝트의 모든 활동이 잘 진행되도록 돕습니다개발자들을 편하게 해주고불필요하게 노력을 낭비하지 않게 해주며개발에 집중할 있게 해줍니다성공적인 프로젝트는 거의  적절한 기반시스템 하에서 개발 된 것이라고 보면 됩니다.

기반시스템에는 좋은 오픈 소스(Open Source) 솔루션이 아주 많습니다세계적인 소프트웨어 회사들도 기반시스템으로 오픈 소스 솔루션을 애용하고 있습니다특별한 이유가 있는 경우가 아니라면 비싼유료 제품을 사서  필요가 없습니다.

그러면 수많은 기반시스템 중에서 무엇은  필요하고 어떤 것은 당장 필요하지 않을까요?
이는 회사에 따라서 상황이 달라질  있습니다.

아래 그림은 각 기반시스템의 난이도와 효과를 설명한 것이다오른쪽으로 갈수록 도입이 쉽고도입 쉽게 적응할  있는 시스템이다또 위로 갈수록 도입 시 효과가 크고 프로젝트에 많은 영향을 미치는 것들이다아직 아무런 시스템을 도입하고 있지 않는 회사라면 오른 쪽 윗부분의 영역에 있는 시스템부터 차례대로 도입하는 것이 좋을 것이다.

아직 소스코드관리시스템과 버그관리시스템을 사용하고 있지 않다면 가능하면 빨리 도입해야 합니다  기반시스템은 어떤 소프트웨어 회사이건 필수적으로 필요하기 때문입니다