한방에 빌드

Visual Studio나 Eclipse를 실행해야만 빌드를 할 수 있습니까?

"Yes"라고 대답하는 개발자들은 대부분은 이것이 무슨 문제인지 모르고 있는 상황입니다. 

Joel Test 12개 항목 중 하나를 차지할 정도 한방에 빌드를 만들어 내는 것은 중요합니다. Visual Studio나 Eclipse에서 버튼 하나만 누르면 빌드가 된다고 이것을 한방에 빌드를 만들어 내는 것이라고 착각하면 곤란합니다. 일단 Command line이 아니고 빌드를 위해서 사람의 손을 통해서 무슨 프로그램을 실행해야 한다면 한방의 빌드와는 거리가 먼 겁니다.

그럼 왜 한방에 빌드를 만들어 낼 수 있을까요? 

빌드는 반복적인 작업이며 대단히 귀찮은 작업이면서 전문적인 작업이기도 하고 실수하기 쉽기도 하며 개발에서 많은 시간을 소모하는 작업입니다. 한번의 빌드는 큰 시간 소모가 아니라고 생각할지 몰라도 개발 프로젝트 전체를 놓고 보면 아주 큰 시간과 비용입니다.

그래서 빌드는 자동화되어야 하고, 전문화 되어야 하고, 통제가 되어야 하며, 별도의 담당자가 할당되게 됩니다. 빌드의 효율성을 높이기 위해서 전과정을 자동화 하기 위해서는 Build Technology에 대한 연구가 이루어져야 합니다. 빌드는 일반 개발자가 개발도 하면서 매우 잘 해내기 힘든 전문 분야입니다. 

한방에 빌드란 개발자들이 해당 빌드에 추가될 모든 기능을 구현해서 소스코드 관리시스템에 등록을 한 상태에서 단 한번의 명령어 실행으로 빌드 전과정을 자동으로 실행해서 최종 마스터가 마스터 보관소에 저장이 되는 것을 말합니다. 이 빌드 전과정은 회사마다 제품마다 상당히 다르며 어떤 제품은 5분이면 끝나고 어떤 제품은 24시간이 넘게 걸리는 것도 있습니다. 또 어떤 제품은 수십개가 넘는 OS에서 빌드를 해야 하고, 어떤 제품은 빌드를 위해서 수십개의 빌드시스템을 동시에 실행하기도 합니다. 

5분짜리 빌드만 해본 개발자들이라면 한방에 빌드와 IDE를 통한 수동 빌드가 별로 차이가 없어 보이지만, 규모가 커지고 빌드가 복잡해지기 시작하면 그 차이는 확연히 드러납니다. 사실 5분짜리 빌드도 자동화의 잇점이 상당으로 작기는 하지만 자동화를 하는 것이 더 유리하죠. 그래야 자동화의 필요성도 깨닫게 되구요.

개발자가 분석, 설계, 구현하는 작업 외에 다른 작업에 많은 시간을 소모하고 있다면 그런 작업은 최대한 자동화하고 개발자들은 개발에 집중할 수 있도록 해야 합니다. 한번의 자동화가 귀찮다고 조금씩 갉아 먹는 시간은 대단히 큰 비용입니다.

아직 빌드 자동화에 대한 경험이 부족하다면 막상 시작하려면 막막한 경우들이 있습니다. 궁금하신 내용들이 있아면 제게 메일을 보내주세요. 제가 아는 한 최대한 성심껏 답변드리겠습니다.

베이스라인

"Baseline"이라는 용어가 생소한 개발자들이 있을 수 있습니다.

우리말로 번역을 하면 "기준선"이라고도 하는데, 헷갈리므로 그냥 Baseline이라고 사용해도 무관할 것입니다.

소스코드는 살아 있습니다. 매 순간 변화하고 있다고 봐도 됩니다. 실제로 몇 천명의 개발자가 참여하는 프로젝트에서는 소스코드 관리시스템의 로그를 보면 거의 매 순간 소스코드가 바뀌는 것을 알 수 있습니다. 또 작은 프로젝트라고 하더라도 어느 순간에 소스코드가 바뀔지는 알 수 없습니다. 그래서 Baseline을 관리하지 않으면 소스코드의 어느 의미 있는 순간을 잡아내는 것이 쉽지 않습니다. 그래서 Baseline을 관리합니다.

Baseline을 설정하는 방법은 여러 가지가 있습니다. 소스코드를 통째로 특정 디렉터리에 복사를 해 놓는 것도 Baseline설정의 한 방법입니다. 그 순간의 소스코드를 언제든지 꺼내 올 수 있죠. 하지만, 더 편리하고 일반적인 방법은 소스코드관리시스템의 Baseline설정 기능을 이용하면 됩니다. Visual SouceSafe에서는 Label이라고 하며 CVS, SVN에서는 Tag라고 합니다. 이중에서 SVN이 Baseline을 설정하는데 탁월한 성능적인 우위를 가지고 있습니다.

Baseline 설정이 왜 필요할지 해보지 않고 선뜻 이해를 한다는 것은 불가능합니다. 여태 Baseline 설정 한번 하지 않고도 소프트웨어를 잘 개발해 왔으니까요. 그럼 Baseline을 설정하지 않으면 어떠한 부작용들이 있는지 알아보죠.

가장 먼저 버그가 발생했을 경우 정확하게 버그가 발생한 그 버전에 대한 소스코드를 찾기가 어려워서 정확한 버그 재현이 곤란해질 수 있습니다. 그리고 릴리즈가 통제가 되지 않을 수도 있습니다. 즉, 1.5버전을 빌드해서 만들어 놓고, 은근 슬쩍 소스코드 몇 개 바꾸고 그냥 1.5버전을 다시 빌드해서 그냥 내보내는 겁니다. 사소한 것으로 생각해서 이렇게 하는 경우도 있지만, Baseline이 관리되지 않은 조직에서는 흔히 볼 수 있는 일입니다. 

Baseline은 주민등록과 같이 개발팀에서 낳은 모든 아이(소프트웨어)의 기록입니다. 개발팀에서는 아무리 많이 소스코드를 바꾸어도 출생기록이 남는 것은 아닙니다. 하지만, 일단 소프트웨어가 빌드 되어서 개발팀 바깥으로 나가서 테스트팀으로 넘기던, 고객이 소프트웨어를 사용하던, Baseline라인이 관리되어야 합니다. 소스코드 한 줄을 바꿔서 다시 릴리즈를 했어도 Baseline은 바뀐 것이고, 다른 소프트웨어로 관리가 되어야 합니다. 그렇지 않으면 아이는 수십명 낳아놓고 각 아이들의 출생 기록도 없고, 이름도 없는 아이들이 많아지는 겁니다. 많은 아이 중에서 한 아이가 아픈데, 누가 아픈 것인지 정확하게 지칭도 못하는 일이 발생하기도 합니다.

소스코드관리시스템을 이용하면 아주 쉽게 Baseline을 설정할 수 있습니다. 기존에 Baseline을 설정하지 않고도 소프트웨어 개발에 문제가 없다고 하더라도, 기존의 방법에 익숙해진 것 뿐이지 문제가 없는 것도 아니고 효율적이지도 못합니다. 소프트웨어를 빌드하고 릴리즈하는 기준을 현재변화하고 있는 소스코드가 아닌 Baseline을 이용하는 방법으로 전환을 해야 합니다. 각론에 들어가면 회사마다 Baseline설정 규칙이 달라질 수는 있겠지만, 소프트웨어를 공식 빌드하고 릴리즈하기 위해서는 Baseline을 설정한다는 규칙은 바뀌지 않습니다.

누가 소스코드를 몰래 바꿔놨다.

누군가 몰래 여러분 회사의 소스코드를 바꿔놓는 일이 가능한가요? 진짜 이런 일이 일어 날 수 있는 환경이라면 당장 고쳐야 합니다.

실제로 이러한 걱정을 하는 회사도 많이 있습니다. 

영화 슈퍼맨3를 보면 한 프로그래머가 은행 이자의 우수리 돈을 자신의 계좌로 몰아서 스포츠카를 사는 장면이 나옵니다. 또, 퇴사하는 직원이 악의를 품고 소스코드를 몰래 바꿔놓지 않을까 걱정을 하기도 합니다.

정상적인 시스템과 프로세스를 갖춘 회사라면 이러한 걱정을 할 필요가 없으나 그렇지 못한 대부분의 소프트웨어 회사들에서는 언제든지 일어날 수 있는 일입니다.

정상적인 경우라면 소스코드의 모든 변경은 기록에 남게 됩니다. 또 소스코드를 변경하기 위해서는 버그ID(또는 이슈ID)가 있어야 합니다. 이것이 소스코드 변경 승인의 역할을 대신하기 때문에 소스코드를 변경 시 버그 ID가 없다면 소스코드 변경이 차단되도록 되어 있는 경우도 있습니다.

또, 버그ID도 가짜로 만들어서 등록을 했다고 하더라도, Peer review에서 이상한 코드는 발견이 되게 됩니다. Peer review를 통과 했다고 하더라도, Build팀에서 빌드를 하면서 바뀐 소스코드와 버그ID를 체크하는 과정에서 가짜 버그 ID가 발각 될 수 있습니다. 여기까지 통과를 하였다고 하더라도, 테스트에서 걸리게 되어 있습니다. 이것도 통과를 하였다고 하더라도, 모든 변경의 이력은 기록이 남아 있고, Log가 존재하므로 추후 추적이 가능해집니다.

제대로 시스템과 프로세스가 갖추어져 있다면 누가 소스코드를 마음대로 바꾸지 않을까 걱정할 필요가 없습니다. 이를 걱정하고 온갖 프로텍트 장치를 해 놓는 것은 오히려 개발 효율성을 떨어뜨리게 됩니다.

모든 것이 다 Open되어 있고 허술한 것 같아 보이지만, 이렇게 하는 것이 오히려 더 안전하고 투명하게 개발이 진행되며 생산성을 훨씬 더 높이는 방법입니다.

Daily Build를 하십니까?

Daily Build는 많은 혜택을 줍니다.

소프트웨어가 항상 빌드 가능한 상태를 유지할 수 있도록 해주며

모든 소스코드가 매일 통합되므로 통합의 혼란을 줄여주며 개발자들의 개발진척도를 피부로 느끼게 해줍니다. 또 유닛테스트를 자동으로 매번 시행하여 기본적인 테스트를 해줍니다.

요즘은 Daily가 아니고 CI툴을 이용하여 빌드 주기를 조절하고 추가적인 작업들도 하지만 개념은 Daily Build와 크게 다르지 않습니다. CI툴은 이를 좀더 편하게 UI와 몇몇 기능을 제공하고 있습니다.

여기까지는 대부분의 개발자들이 알고 있는 내용이기도 합니다.

하지만 Daily Build를 언제부터 시작하느냐에 대해서는 의견이 명확하지 않더군요.

저는 Daily Build는 설계가 끝나고 구현 첫날부터 Daily Build를 할 수 있어야 한다고 생각합니다.

기본적인 개발 Stage를 사용하던, Iteration을 쓰던 간에 설계의 결과물은 빌드가 되어야 한다는 것입니다. TDD를 사용할 경우 Test 코드를 먼저 작성을 하기 때문에 빌드가 가능합니다. 테스트는 통과를 하지 못하더라도 말입니다. 즉 껍데기, Class, Public function의 Prototype을 정해 놓고 빌드가 가능한 상태로 만들어 놓고 구현을 시작합니다.

이때 SCM에 Baseline을 한번 설정을 하고 소스코드의 내용을 채워 나가기 시작합니다. Daily Build의 혜택을 누리기 위해서는 소스코드를 빌드 가능한 상태로 만들어 놓고 시작을 해야 합니다.

빌드가 먼저일까? 베이스라인 설정이 먼저일까?

빌드와 베이스라인 순서에 대해서 이슈가 있다는 글을 보고 아래 글을 작성합니다.

몇몇 빌드관련 솔루션들이 빌드를 해서 성공을 하면 베이스라인(Tag, Label)을 설정하는 것이 있더군요.

이는 원칙에 어긋나는 겁니다.

원칙은 베이스라인을 설정한 후에 해당 베이스라인을 가지고 빌드를 하는 것입니다. 작은 소프트웨어는 사실 이러한 것이 거의 문제가 되지 않습니다. 하지만 대규모 프로젝트는 빌드에 24시간이 넘게 걸리는 것도 있습니다.

Windows NT 개발팀은 Daily Build가 48시간이 걸려서 몇대의 장비가 교대로 Daily Build를 수행했다고 할 정도 입니다.

이 경우 빌드가 끝나고 나서 베이스라인을 설정하려고 하면 이미 소스코드는 엄청나게 바뀌어 있게 됩니다.

베이스라인 설정, 태깅 한 후에 태그를 가져와서 빌드를 하도록 빌드 스크립트를 만들면 됩니다.

Broken tree

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

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

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

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

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

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

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

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

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

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