Broken tree

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

소프트웨어를 개발하는 회사라면 Broken Tree의 발생을 엄격하게 규제해야 합니다.

소스코드관리시스템 안의 소스코드는 항상 빌드가 가능한 상태로 존재해야 합니다.

그리고 언제든지 꺼내서 빌드를 하면 빌드가 되어야 합니다.

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

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

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

빌드가 안 되는 코드를 체크인한 개발자는 모든 업무를 제쳐놓고 빌드가 가능하도록 만들어야 합니다. 

Broken Tree를 만드는 것은 개발자가 저지르는 가장 심각한 잘못 중의 하나입니다.

글이 좀 무거운데, 호랭이 블로그에서 재미 있는 카툰을 발견했네요. 재있게들 보세요.

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

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

여기서 제가 말하고 있는 "빌드"는 "공식빌드"입니다.

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

"공식빌드"가 아닌 것은 "엔지니어링 빌드"라고 합니다.

이는 개발자가 자신의 작성한 코드를 테스트하기 위해서 비공식적으로 하는 빌드입니다.

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

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

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

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

"공식빌드"는 IDE에서 이루어지면 안됩니다. 

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

빌드작업은 대단히 전문적인 작업이라서 쉽게 생각할 것이 아닙니다.

전문화되고 자동화된 빌드는 소프트웨어 개발 생산성을 대단히 높여 줍니다.

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

자동화된 빌드를 통해서 할 수 있는 일은 대단히 많습니다.

자동화가 되어야 Daily Build가 가능하며, 빌드 후에 각 소프트웨어마다 이루어지는 수많은 부가 작업들이 자동으로 연결이 가능해 집니다.

어떤 제품은 Smoke Test를 붙이기도 하고, 

Packaging을 해서 CD에 굽기 전의 상태까지 준비가 되기도 하고, 

홈페이지에 업데이트 버전이 등록되기도하고,

버그관리시스템과 연동도 됩니다.

이러한 부가 작업은 소프트웨어나 회사마다 다릅니다.

전문 빌드담당자가 정해지면 이러한 일련의 작업에 대해서 책임감을 가지고 향상을 시키게 됩니다.

이러한 것들이 눈에 잘 보이지는 않지만, 소프트웨어 개발 역량 및 생산성 향상에 많은 영향을 미치게 됩니다.

"공식빌드"와 "엔지니어링빌드"에 대해서 구분없이 소프트웨어를 개발하고 계신다면 

일단 "빌드의 중요성"에 대해서 인지를 하셔야 합니다. 

막연히 빌드의 중요성은 알기 어렵죠. 앞으로 이에 대해서 계속 포스트를 하도록 하겠습니다.

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

안다는 것과 모른 다는 것

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

1. 모르는 것을 안다고 생각하는 것

2. 아는 것을 안다고 생각하는 것

3. 모르는 것은 모른다고 생각하는 것 

여기서 모르는 것을 모른다고 생각할 수 있는 자세야 말로 엔지니어에게 꼭 필요하지만,

의외로 모른 것을 안다고 착각하거나 

아주 조금만 아는 것을 전체를 안다고 생각하거나 

자신이 아닌 범위가 전체인줄 아는 경우가 많습니다.

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

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

모르는 것을 안다고 생각하는 사람들은 사고를 많이 치고,

모르는 것을 모른다고 생각하는 사람에게는 지속적인 발전이 있다고 생각합니다.

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

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

국내의 굴지의 금융회사 중의 한 사례입니다.

회사 내에서 각 팀별로 소스코드관리시스템을 여러 개를 사용하고 있더군요.

A팀 Windows 플랫폼의 Application를 개발하니까 Microsoft Visual SourceSafe를 사용하고

B팀 Web 서비스를 개발하고 있었는데, CVS를 사용하더군요.

그리고 C팀은 Unix에서 개발을 하는데, 아무런 소스코드관리시스템을 사용하고 있지 않았고,

D팀은 별로 잘 알려져 있지 않은 외국의 상용 제품의 한글화된 버전을 사용하고 있었습니다.

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

이런 상황에서는 다음과 같은 부작용이 생깁니다.

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

이런 일들이 발생하는 이유는 다음과 같습니다.

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

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

만약 이미 여러가지 소스코드관리시스템을 사용하고 있다면 비용을 지불하고라도 통일을 하는 것이 좋습니다.

이러한 통일 작업은 기계적으로 할 수도 없는 어려운 작업이 됩니다. 

하지만 늦어질 수록 더 많은 비용을 치르게 됩니다.

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

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

기반시스템(Infrastructure system)은 소프트웨어를 개발하는데 꼭 필요한 기초 환경입니다.

여러분들도 쓰고 계시는 것이 있을 겁니다. 소스코드를 CVS에 저장하고 버그를 관리하기 위해서Bugzilla나 Mantis를 사용하고 있다면 바로 그러한것들이 기반시스템(Infrastructure System)입니다.

이러한 것들은 매우 다양한 분야에서 소프트웨어 개발을 돕고 있습니다.

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

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

그러면 수많은 기반시스템 중에서 무엇은 꼭 필요하고 어떤 것은 당장 필요하지 않을까요?

이는 회사에 따라서 상황이 달라질 수 있습니다.

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

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

개발자 폭행사건을 바라보는 심경

아래 소개된 개발자 폭행사건을 보고 나름대로 생각을 해봅니다.

우리나라 소프트웨어 업계에 만연해 있는 갑과 을의 왜곡된 구도에 대해서 생각해 보지 않을 수 없습니다.

특히 소프트웨어에 있어서는 갑이 을에게 뭐든지 시킬 수 있고, 뭐든지 바꿔달라고 할 수 있고, 어제라도 마음대로 부릴 수 있다는 인식이 깔려 있는 것 같습니다.

이러한 인식을 깨기 위해서는 법적인 보완, 소프트웨어 개발에 대한 인식 변화, 성숙한 소프트웨어 개발 문화 등이 필요할 것입니다.

우리의 소프트웨어 계약을 보면 정말로 모호하고 일방적인 경우가 정말 많습니다.

외국의 예를 보면 소프트웨어 개발 프로젝트는 분석과 설계/구현이 분리가 되어서 개발 계약시는 분석이 완료된 정확한 스펙을 가지고 개발 계약을 하게 되고, 장애해결이나 유지보수는 별도의 유지보수 계약에 의해서 하게 되어 있습니다.

그런데 우리는 귀에 걸면 귀걸이 코에 걸면 코걸이 식의 계약을 가지고 검수 때까지 발주자가 원하는대로 해줄 수 밖에 없는 구조입니다. 

소프트웨어는 절대로 소프트하지 않다는 것에 대한 인식도 같이 해야 합니다. 소프트웨어는 개발자가 간단히 뚝딱뚝딱 몇줄 코드를 바꾸면 다 해결 되는 것으로 착각하기 쉽습니다.  예, 정말로 착각입니다. 개발자가 한 줄을 바꾸면 그로 인해서 벌어져야 하는 일들은 정말로 엄청납니다. 이 모든 것을 발주자들이 알 수는 없지만, 소프트웨어 업계에 종사하는 우리들이 결국 조금씩 바꿔나가는 수밖에 없을 것 같습니다.

물론 문제를 폭력으로 해결하려고 한 개인의 문제가 가장 큰 원인이지만, 소프트웨어 개발 문화가 성숙되는 사회가 되어야 그러한 일들이 사라질 것이라고 생각합니다.

제목은 "서울특별시의회 전자회의시스템 프로젝트 프로그램 개발자 폭행사건"입니다.

이 글을 올리게 된것이 너무 힘들다...대한민국의 개발자들에게 알리고 싶댜.

원본글: http://www.devpia.com/MAEUL/Contents/Detail.aspx?BoardID=69&MAEULNo=28&no=11212

사건일시: 2008년 10월 23일 12시10분경

사건내용

2008년 서울시의회 176회 2차 본회의가 있는 날이다. 이 글의 개발자는 폭행 당한 개발자 당사자이다.

개발자는 평소대로 개발실에서 대기하고 있었다. 12시경 전화가 울렸다. 김* 주임이 의사과장이 의장용 프로그램의 버튼 인식 방식을 변경하라고 했다는 것이다. 즉 버튼을 눌렸을 경우 바로 다음 시나리오로 진행하는 것과 시간을 조금 빨리 변경해 달라는 것이다. 프로그램을 수정하기엔 본회의가 열리기 2시간 전이라 위험하고 테스트 시간이 부족하였다. PM에게 전달하니. PM이 김* 주임에게 시간이 부족하고 위험하니 혹시 발생할 위험성에 대한 책임으로 문서로 처리하여 주면 프로그램을 수정하여 주겠다고 전했다. 이에 의사팀장이 PM을 잠깐 만나자는 연락이 왔었지만 PM이 자리에 없었다. PM이 자리에 와서 의사팀장이 만나자는 내용을 전달 했다. 이때 본회의장 시나리오 담당자에게 연락이 왔다. 잠깐 내려오라는 것이다. 개발자는 혹시 다른 지원할 것이 있는 것으로 인식하고 내려갔다. 본회의장에 내려가니 의사과장은 의장 프로그램을 보고 있고 의사과 직원들15명 이상이 의원석에 앉아 있었다. 시나리오 담당자는 예전에 얘기된 의장프로그램 폰트 사이즈 크기가 왜 수정되지 않은 지 의사과장에게 다시 설명 해 달라는 것이다. 순간 의사팀장이 들어 왔다. 

“누가 하지 말랬어?” 하고 개발자에게 물었다. 개발자는 순간 아무런 얘기는 하지 못했다.

그때부터 폭행은 시작되었다.

구두발로 개발자의 무릎을 두번 차고 다음 복부를 발로 차고 옆구리를 돌려차기 하였다. 아무도 말리는 사람 없었다. 잠시 후 누군가가 와서 의사팀장을 말렸다.

개발자는 너무 황당하여 아무런 대항도 하지 않고 본회의장에서 나왔다.

의사과장은 그냥 지켜보고만 있었다. 개발자가 폭행은 당하고 있는 데로 당연하듯 쳐다보고만 있었다. 그 많은 의사과 직원들(남직원4명이상,여직원 10명이상)이 보고 있는 가운데 폭행을 당했다.

개발자는 바로 개발실로 올라가 PM에게 현재 상황을 전달하였다. PM은 어떻게 이런 경우가 있냐며 개발자를 본회의장으로 데려 갔다. 의사과장은 단상 앞에 있었다. PM이 얘기 했다. 어떻게 개발자를 폭행 할 수 있냐고, 이때 의사팀장이 나왔다. 싸우겠다는 태도처럼 PM앞으로 나오자 다른 직원 두 사람을 말렸다. 의사과장 왈 지시대로 했으면 이런 일은 없을 거냐며 얘기했다. 즉 이 모든 폭행사실을 보고 있었던 것이다.

본회의장을 나왔다. 다른 의사과 직원과 팀장들이 같이 나왔다. 참아달라고 했다. 너무 억울했다. 112에 신고 하였다. 경찰 2명이 왔다. 본회의장에 들어 가려고 하니. 의사과 * 팀장이 말렸다. 경찰이 못 들어 갈 일이 없다고 하였다. 3번 이상 경찰과 실갱이 벌였다. 경찰이 본회의장에 들어갔지만 폭행한 팀장이 없었다. 다른 팀장에게 사무실로 가자고 하였다.

폭행한 팀장은 사무실에 있었다. 다른 직원들은 점심시간이 되어 본회의가 열릴 때 시켜먹는 도시락을 먹고 있었다.

경찰이 팀장을 불러 사무실을 밖으로 나왔다. 이때 남직원들이 같이 나왔다. 경찰이 현행범으로 체포한다고 하자 옆에 팀장들이 오늘 본회의가 있으니 본회의 끝나고 진해하면 않되겠나며 얘기했다. 개발자는 어이없다. 그 많은 사람들 앞에서 맞은 것도 억울 한데.

경찰이 내 의사를 물었다. 일단 개발자는 양보했다. 본회의 끝나면 이 폭행사건을 고소하겠다고 했다. 경찰은 물러갔다.

개발실로 갔다. 너무 황당하고 당황스럽다. 

여기까지 2008년 10월23일 서울시의회 프로그램 개발자 폭행사건의 내용이다.

글을 쓰고 있지만 아직도 다리와 복부쪽이 통증이 심하다.

신체적 아픔은 참을 수 있지만 정신적 충격은…

개발경력 8년이상 지금과 같은 경우는 처음이다.

이에 이 비통한 사실을 IT강국이라는 대한민국 현실을 전 세계에 알리고 싶다.

현재 서울시의회에서 의원들이 사용하는 프로그램이 개발자의 땀과 노력이 아닌 폭행으로 흘려진 개발자의 피와 얼룩진 시퍼런 멍으로 만든 프로그램이란 것을 꼭 알리고 싶다