일일 빌드와 동작 테스트

출처 : http://blog.naver.com/dejavu_blog?Redirect=Log&logNo=30020145905

 

18장 일일 빌드와 동작 테스트

 

일일 빌드와 동작 테스트는 소프트웨어 제품을 매일 전체적으로 다시 컴파일하고, 기본 동작을 검증하기 위해 필요한 일련의 테스트를 거치는 공정이다. 이 공정은 제작 단계 공정이며 프로젝트가 어느 정도 궤도에 올라섰을 때 시작할 수 있다. 이 공정은 통합 실패, 낮은 품질, 낮은 프로젝트 가시성과 같은 공통적이고 소모적인 시간 위험이 발생할 가능성을 줄여 시간을 절약한다. 이 공정은 회복 상태의 프로젝트에게 결정적인 제어기능을 제공한다. 이 공정을 성공하려면 개발자는 이 공정을 준수하고, 동작 테스트를 세심하게 설계해야 한다. 일일 빌드와 동작 테스트는 어떤 크기와 복잡성을 가진 프로젝트에도 효과적으로 활용할 수 있다.

 

효능
명목 일정에서 잠재적인 절감 요인 : 우수
작업 가시화 향상 : 우수
일정 위험에 미치는 영향 : 위험 감소
도입 초기 성공 가능성 : 매우 우수
장기적인 성공 가능성 : 최고

 

주요 위험요소
- 중간 단계의 프로그램을 자주 배포하라는 압력

 

주요 상호작용과 상충요인
- 통합에 따르는 위험을 상당히 줄이며 공정 가시성을 증가시키기 위해 부가 비용을 감수한다.
- 상세 중간목표와 함께 활용할 때 훨씬 효과적이다.
- 점진적인 개발 생명주기 모델에 필요한 사항을 지원한다.

 

단지 파일 하나로 이뤄진 단순한 컴퓨터 프로그램이 있다고 가정하자. 이 프로그램을 빌드하기 위해서는 단순히 컴파일해서 파일만 링크하면 실행파일이 생긴다. 전형적인 팀 프로젝트는 수십, 수백, 수천 개 파일과 연관이 있기에, 실행 파일을 생성하는 절차는 더욱 복잡하고 시간이 많이 소모된다. 제품을 제대로 돌리려면 반드시 '빌드'를 해야 한다.

일일 빌드와 동작 테스트 공정에서 제품 전체를 매일 새로 빌드한다. 이는 모든 파일을 컴파일하고 링크시키고 결합해서 실행 가능한 프로그램을 매일 빌드한다는 말이다. 이렇게 빌드한 제품은 전원을 올렸을 때 연기가 나는지 지켜보는 비교적 손쉬운 테스트와 유사한 '동작 테스트'를 거친다.

 

이렇게 단순한 공정은 여러 방면에서 시간을 상당히 절약해주는 효과가 있다.

 

통합에 따르는 위험을 최소화한다. 프로젝트가 직면하는 가장 큰 위험 중 하나는 팀원이 독자적으로 작업하던 코드를 결합하거나 '통합'할 때, 코드가 서로 결합한 상태에서 갑자기 동작하지 않는 문제다. 프로젝트에서 얼마만큼 늦게 이러한 비호환성을 찾아내느냐에 따라 디버깅은 통합 과정을 일찍 진행하는 경우에 비해 훨씬 오래 걸릴지도 모른다. 이러한 이유는 프로그램 인터페이스가 바뀔지도 모르며, 시스템 주요 부분을 새로 설계해서 새로 구현해야 할지도 모르기 때문이다. 극단적인 경우에, 통합 오류는 프로젝트를 취소해버린다. 일일 빌드와 동작 테스트는 통합 오류를 작고 관리할 수 있는 수준으로 유지하기에, 통제 불가능한 통합 오류를 방지한다.

 

낮은 품질과 같은 위험을 줄인다. 성공적이지 못하거나 문제가 있는 통합과 같은 위험은 낮은 품질 위험과 관련이 있다. 매일 제품에 있는 모든 코드에 대해 최소한으로 동작 테스트를 진행함으로써, 품질 문제를 프로젝트 제어권 내에 둘 수 있도록 만든다. 시스템을 낯익고 안정적인 상태로 가져다 놓고, 이를 계속 유지하자. 이는 단순히 시간 소모적인 품질 문제가 발생할 수도 있는 지점이 돌출하도록 허용하지 않는다.

 

초기에 결함 분석을 지원한다. 매일 제품을 빌드하고 테스트할 때, 특정 일에 제품이 왜 망가졌는지 집어내기가 훨씬 수월하다. 제품이 17일에 동작하고, 18일에 망가졌다면 17일과 18일 사이에 어떤 사건이 발생해서 제품을 망가뜨려 버렸다. 만일 제품은 단지 주일 단위나 달 단위로 빌드하고 테스트한다면, 문제는 17일과 24일 사이나, 17일과 47일 사이의 어느 한 지점에서 발생했을 수 있다.

 

진척 상황 감시를 지원한다. 시스템을 매일 새로 빌드하면, 현존하거나 현존하지 않는 기능이 명확해진다. 기술 관리자나 비 기술 관리자나 단순히 제품을 돌려보고 얼마만큼 완성에 가까워졌는지 쉽게 파악할 수 있다.

 

사기 증진을 촉진한다. 프레드 브룩스가 지적한 바와 같이, 놀랍도록 강력한 사기는 동작하는 제품을 보면서 싹 터 오른다. 제품이 뭐가 되었든지 상관없다. 개발자들은 단지 사각형을 그리는 모습을 보기만 해도 이미 들떠서 야단이다. 매일 새로 빌드하면, 매일 제품이 조금씩 더 동작하기에, 사기를 최고로 유지한다.

 

고객 관계를 계선한다. 매일 새로 빌드하는 노력이 개발자 사기에 긍정적인 영향을 미친다면, 또한 고객 사기에도 긍정적인 영향을 미친다. 고객은 진척 상황이 나아지는 단서를 좋아하며, 매일 새로 빌드하는 작업은 주기적으로 친척 상황을 보여주는 단서를 제공한다.

 

 

18.1 일일 빌드와 동작 테스트 활용

 

일일 빌드와 동작 테스트 공정 이면에 숨겨진 사상은 단순하다. 매일 제품을 빌드하고 테스트하는 원칙뿐이다. 다음에 나오는 절에서 이러한 단순한 사상이 중요한 이유를 설명한다.

 

매일 빌드하기. 매일 빌드하는 작업에 있어 가장 기본이 되는 밑바탕은 매일 제품을 빌드해내야 한다는 사실이다. 짐 맥카시가 말했듯이, 매일 빌드하는 작업은 프로젝트의 심장 박동으로 취급해야 한다. 만일 심장 박동이 멈추면 그 프로젝트는 죽는다.

 

다른 사람은 매일 빌드하는 작업을 프로젝트의 동기화 맥박으로 설명한다. 상이한 개발자 코드는 동기화 맥박 사이에 다소간 비동기 상태로 남아있다가. 매 동기화 맥박이 뛰고 나면, 모든 코드는 정렬 상태로 들어간다. 맥박을 밀접하게 함께 뛰도록 유지할 때, 몇몇 개발자가 동기화 상태에서 벗어나는 현상을 막을 수 있다.

 

'make'와 같은 자동화된 빌드 도구는 매일 빌드하는 작업과 연관있는 반복적인 작업량을 줄여 준다.

 

잘못된 빌드 점검하기. 매일 빌드하는 공정을 효과적으로 하기 위해, 빌드한 소프트웨어는 반드시 동작해야 한다. 소프트웨어를 사용할 수 없다면 빌드가 잘못 되었다고 판단해 빌드 문제를 수정하는 작업을 가장 먼저 진행한다.

 

각 프로젝트는 빌드 실패의 원인을 표준화해야 한다. 표준은 매일 빌드 과정을 망가뜨리는 심각한 결함을 제거할 만큼 강력하지만, 사소한 결함은 무시할 수 있도록 설정해서(사소한 결함에 불필요하게 집중하면 프로젝트 진행을 마비시킬 수 있다.) 품질 단계를 설정할 필요가 있다.

 

최소한 빌드는 다음과 같아야 한다.
 - 모든 파일, 라이브러리와 필요한 컴포넌트를 성공적으로 컴파일 한다.
 - 모든 파일, 라이브러리와 필요한 컴포넌트를 성공적으로 링크한다.
 - 프로그램 수행을 막거나 운영에 나쁜 영향을 미치는 치명적인 버그를 포함하지 않는다.
 - 동작 테스트를 통과한다.

 

몇몇 프로젝트는 좀더 엄격한 표준을 정해서 컴파일러와 링크 오류, 경고까지 성공적인 빌드 정의에 포함시킨다. 어떤 경우에서든 리트머스 테스트는 빌드가 테스트를 위한 배포에 충분할 만큼 안정적인지를 파악한다. 테스트하기에 충분하다면 망가지지 않는다.

 

매일 동작 테스트를 수행한다. 동작 테스트는 반드시 전체 시스템을 처음부터 끝까지 살펴볼 수 있어야 한다. 완벽한 테스트까지 할 필요는 없지만, 주요 문제점을 감지하기에 충분해야 한다. 정의에 따르면 빌드가 동작 테스트를 통과할 경우, 이는 테스트를 진행하기에 충분한 성공적인 빌드를 의미한다.

 

동작 테스트가 없다면 일일 빌드는 의미가 없다. 동작 테스트는 빌드가 동작하는지 그렇지 않은지를 알려준다. 빌드를 프로젝트의 심장 박동이라고 취급하면, 동작 테스트는 심장이 뛰는지를 판단하는 데 도움을 주는 청진기라고 볼 수 있다. 동작 테스트는 테스트 중에서도 프로그램 훼손에 대항하는 최전방 수비수다. 동작 테스트 없는 일일 빌드는 단지 컴파일 성공 사실만을 점검하는 수단으로 전락하고 만다.

 

동작 테스트는 시스템이 발전해 나감에 따라 함께 발전해 나가야만 한다. 처음 동작 테스트는 시스템이 "Hello World"와 같이 간단한 출력을 할 수 있는지 테스트하는 비교적 단순한 과정을 거칠 것이다. 시스템이 발전함에 따라 동작 테스트도 점차 복잡해진다. 처음 테스트는 실행하는 데 몇 초면 끝나 버릴 지도 모른다. 하지만 시스템이 커감에 따라 30분, 1시간, 아니 훨씬 더 오래 걸릴 수도 있다.

 

빌드 그룹은 동작 테스트를 우선 순위 중에서 최상위에 놓아야만 한다. 동작 테스트와 관련한 작업 품질은 성능 평가에 중요한 척도가 된다. 빌드 그룹이 동작 테스트를 너무 까다롭게 하지 않도록 개발자가 압력을 넣을 수 있기에, 구성원은 반드시 개발자 직함보다 품질보증 직함을 확보해야 한다. 어떤 좋은 의도가 있는지는 몰라도, 개발자에게 동작 테스트를 맡기면 마치 고양이에게 생선을 맡기는 상황이 되어 버린다. 그룹 구성원은 반드시 개발 책임자가 아닌 품질보증 책임자에게 결과를 보고해야 한다.

 

테스트를 위한 시스템 설계가 도움을 주는 분야가 존재한다. 동작 테스트는 반드시 자동화시켜야 하며, 테스트를 위한 코드를 작성하여 쉽게 자동화시킬 수 있다.

 

빌드 그룹을 결성한다. 대부분 프로젝트에서 매일 빌드를 진행하는 작업이 너무 큰 과업이기에 명시적으로 작업을 할당할 필요가 있다. 대규모 프로젝트에서는 두 명 이상 정규직을 고용한다. 예를 들어, 윈도우즈 NT 3.0을 개발할 때는 빌드 그룹에 정식직원 4명이 달라붙어 있었다. 또한 제품이 커지고 발전함에 따라 동작 테스트를 유지할 수 있도록 노력을 기울여야 한다. 작은 프로젝트에서는 매일 빌드를 진행하기 위해 정규 직원을 고용할 필요가 없을지도 모른다. 이런 경우에 품질보증팀에서 인력을 지원받아 임무를 맡기면 된다.

 

단지 의미가 있을 경우에만 빌드를 위해 코드를 추가한다. 매일 진행하는 빌드는 시스템을 매일 다시 빌드해야 하지만. 매일 개발자가 시스템을 위해 작성한 새로운 코드를 반드시 추가하도록 요구하지는 않는다. 개별 개발자는 매일 시스템에 의미있는 추가 사항을 만들어 낼 만큼 빨리 코드를 작성하지 못한다. 개발자는 코드 단위로 작업을 하며, 조화로운 상태에서 코드 묶음을 확보해야 이를 통합한다. 개발자는 작업시 원시 코드 파일을 바로 수정하는 대신 반드시 개인적인 사본을 유지해야만 한다. 일단 완벽한 변경 집합을 만들어내면 변경 사항을 활용하기 위해 개인적인 사본을 빌드해서 테스트해야 한다.

 

하지만, 너무 오랫동안 코드 추가를 방지하지 않는다. 극소수 개발자만이 매일 코드를 점검하는 경향이 있고, 우리는 부정기적으로 코드를 점검하는 개발자를 경계해야 한다. 개발자가 변경 집합을 너무 복잡하게 만들어서 시스템의 모든 파일이 연관되도록 만들면, 매일 빌드를 진행하는 가치를 상실하게 만든다. 나머지 팀원은 점진적인 통합의 장점을 깨닫기 시작할 무렵에, 특정 개발자는 여전히 암흑 속에 빠져있다. 어떤 개발자가 며칠 이상 변경 집합을 점검하지 않고서 작업을 계속한다면, 개발자 작업에 위기가 닥쳤다고 판단할 수 있다.

 

개발자가 시스템에 코드를 추가하기 전에 동작 테스트를 요구한다. 개발자는 자신이 만든 코드를 빌드하기 전에 테스트할 필요가 있다. 개발자는 테스트 작업을 개인 시스템에서 개인적인 빌드를 만드는 방법으로 진행할 수 있다. 이렇게 한 다음에 개발자는 개인적인 테스트를 진행한다. 또는 개발자는 개인적인 빌드를 해당 개발자 코드에만 초점을 맞추는 테스트 동료에게 넘길 수 있다. 두 경우 모두 새로운 코드가 시스템의 다른 부분에 영향을 미치기 전에 동작 테스트를 통과하도록 점검한다.

 

빌드를 위해 추가하려는 코드를 위한 대기 영역을 만든다. 매일 빌드 공정을 성공하기 위한 일부 요건은 어떤 빌드가 성공적이고 어떤 빌드가 그렇지 못한지를 알아 내는 데 있다. 자신이 만든 코드를 테스트하면서 개발자는 미리 알고 있는 성공한 시스템을 참고할 필요가 있다.

 

그룹 대부분은 개발자가 빌드를 위해 추가하기로 생각한 코드를 위한 대기 영역을 생성하는 방법으로 이러한 문제를 해결한다. 새로운 코드는 이 대기 영역으로 들어가서 새롭게 빌드를 진행한다. 빌드를 받아들일 수 있을 수준이면 새로운 코드는 주저장소로 이주한다.

 

작거나 중간 정도의 프로젝트에서는 버전 관리 시스템이 이러한 기능을 담당할 수 있다. 개발자는 새로운 코드를 버전 관리 시스템으로 집어 넣는다. 이미 알고 있는 성공한 빌드를 사용하기 위해 개발자는 단순히 버전 관리 옵션에서 시각 플래그를 설정하여 가장 최신의 성공한 빌드 버전을 날짜에 기반해서 파일을 꺼내 달라고 시스템에게 요청한다.

 

대규모 프로젝트나 복잡하지 않은 버전 관리 시스템 소프트웨어를 사용하는 프로젝트에서는 대기 영역 기능을 수동으로 처리해야 한다. 새로운 코드 집합을 만든 저자는 빌드 그룹에 편지를 보내서 점검을 원하는 새 파일을 어디서 찾을 수 있는지 알려 준다. 또는 그룹은 파일 서버에 '점검' 영역을 만들어서 개발자가 여기에 새로운 원시 코드 버전을 넣을 수 있도록 한다. 빌드 그룹은 새로운 코드가 빌드를 망가뜨리지 않음을 확인한 이후부터 새로운 코드를 버전 관리 시스템에 추가하는 책임이 있다.

 

빌드를 잘못할 경우 벌칙을 준다. 매일 빌드를 수행하는 그룹 대부분은 빌드를 망가뜨릴 경우 벌칙을 준다. 빌드가 너무 자주 망가지면, 개발자가 빌드를 성공하도록 신중히 작업하는 상황을 방해한다. 빌드를 망가뜨리는 상황은 예외이지, 규칙은 아니다. 시작부터 빌드를 튼튼하게 유지하는 작업을 프로젝트 최고 우선순위로 유지하도록 명쾌하게 밝힌다. 망가진 빌드를 이따금 허용하는 관례에 저항하라. 빌드를 망가뜨린 개발자는 빌드를 정상적으로 돌릴 때까지 다른 일을 못하도록 강력하게 밀어붙여라.

 

흥미로운 벌칙은 빌드를 튼튼하게 유지하는 우선순위에 도움을 준다. 몇몇 그룹은 빌드를 망가뜨린 개발자에게 막대 사탕을 준다. 빌드를 망가뜨린 실패자는 망가진 빌드를 복구할 때까지 사무실 문에 테이프로 *막대 사탕을 붙여 놓는다. (*막대 사탕 : 역자주 : 원문에서 sucker는 막대 사탕과 실패자라는 중의적인 표현으로 쓰였다.) 다른 프로젝트에서 빌드를 망가뜨린 개발자는 다른 누군가가 빌드를 망가뜨리기 전까지 빌드 임무를 맏도록 한다. 또 다른 프로젝트에서는 빌드를 망가뜨린 개발자는 망가뜨린 빌드를 복구할 때까지 우산으로 만든 모자를 쓰고 다니도록 한다. 또 다른 그룹에서는 죄인에게 염소 뿔을 달고 다니게 하거나, 5불을 윤리 기금에 기부하도록 한다.

 

몇몇 프로젝트는 좀더 강력한 벌칙을 만들었다. NT, 윈도우즈 95, 엑셀과 같은 대형 프로젝트를 수행하는 마이크로소프트 개발자는 프로젝트 후반부에 무선 호출기를 차고 다녔다. 빌드를 망가뜨렸다면, 밤낮에 상관없이 망가진 빌드를 복구하기 위해 호출당한다. 이러한 관례는 빌드 그룹이 정확하게 누가 빌드를 망가뜨렸는지 파악하고 있었기에 성공할 수 있었다. 빌드 그룹이 주의하지 않으면, 빌드를 수정하도록 새벽 3시에 호출된 개발자는 일일 빌드 공정을 망가뜨린 억울한 역적이 될 수도 있다.

 

아침에 빌드를 배포한다. 몇몇 그룹은 늦은 밤에 빌드하고 이른 아침에 통합 테스트를, 오후가 아닌 오전에 새로운 빌드 배포를 선호한다는 사실을 발견했다. 동작 테스트와 빌드 배포를 오전에 수행하는 관례는 몇 가지 장점이 있다.

 

먼저, 오전에 빌드를 배포하면 테스터는 매일 새로운 빌드로 테스트를 진행할 수 있다. 일반적으로 오후에 빌드를 배포하면 테스터는 하루 일과를 마치기 전에 자동화된 테스트를 진행하도록 압력을 받는다. 빌드가 늦어지면 종종 그렇듯이, 테스터는 테스트를 걸기 위해 늦게까지 남아야 한다. 하지만 늦게까지 남아야만 하는 원인이 테스트에 있지 않으므로, 빌드 공정이 테스터의 사기를 꺽게된다.

 

오전에 빌드를 마치면, 빌드 과정에서 문제가 나타날 경우에 좀더 안정적으로 개발자에게 다가설 수 있다. 일과 중에는 개발자는 건물 안에 있기 마련이다. 일과가 끝나면 개발자는 다른 곳에 있을 수 있다. 심지어 개발자가 무선 호출기를 차고 다닐지라도, 늘 빨리 올수 있는 가까운 거리에 있지 않다.

 

하루 일과 끝 무렵에 동작 테스트를 진행해서 문제를 발견했을 때, 한밤 중에 개발자를 호출하는 관례를 당연하다고 생각할 수도 있다. 하지만 팀원이 힘들어하고 시간을 낭비하여 얻는 이득보다 잃는 손해다 더 많을 뿐이다.

 

거센 압력에서도 빌드와 동작 테스트 진행하기. 스케줄 압력이 거세지면, 일일 빌드를 유지하기 위해 들어가는 노력이 크게 부담이 될 수 있다. 하지만 그 반대가 정답이다. 일정 압력으로 개발자는 다소간 규율을 상실하기 마련이다. 설계와 구현같은 스트레스를 덜 받는 상황에서 선택하지 안았던 지름길을 찾아야 한다는 부담을 느낀다. 또한 평상시보다 부주의하게 자신이 만든 코드를 검토하고 단위 테스트를 진행한다. 코드는 스트레스를 조금 덜 받는 때와 비교해 불안정한 상태가 보다 증가하는 방향으로 기울어지기 쉽다.

 

이러한 문제점을 극복하기 위해, 일일 빌드와 동작 테스트 공정은 규율을 준수하고 진행 중인 프로젝트에 자연적인 압력 작용을 한다. 코드는 여전히 불안정성이 증가하는 방향으로 진행되지만, 매일 이런 경향을 치유할 수 있다. 매일 전체를 컴파일하고, 빌드가 망가지면 개발자 책임을 인식한 다음, 즉각적인 코드 수정을 관리 가능한 과업으로 확보하도록 주장할 수 있다. 불안정한 상태에서 코드를 원래로 돌리는 작업은 비교적 작은 의무이다.

 

만일 코드에 두 배로 많은 결함이 들어갈 때까지 이틀을 기다렸다면, 두 배로 많아진 결함과 이러한 결함으로 인해 복합적으로 나타날 각종 영향 모두를 처리해야 한다. 이렇나 작업은 분석하고 수정하는데 들어가는 노력과 비교해서 두 배 이상 노력을 필요로 한다. 빌드 사이에 오래 기간을 둘수록 빌드를 원상복구 시키는 작업은 훨씬 더 어렵다.

 

도대체 어떤 프로젝트에서 일일 빌드와 동작 테스트 공정을 활용하는가

 

사실 모든 프로젝트에서 일일 빌드를 활용할 수 있다. 즉, 큰 프로젝트, 작은 프로젝트, 운영체제, 기성품 소프트웨어, 비즈니스 시스템 모두가 이에 해당한다.

 

프레드 브룩스는 어떤 조직에 속한 소프트웨어 빌드 당당자는 일일 빌드 공정에 놀라거나 심지어 충격을 받는다고 보고했다. 담당자는 매일이 아닌 매주 빌드를 진행한다고 보고한다. 이러한 주 단위 빌드와 관련한 문제점은 바로 매주 빌드를 하지 않으려는 유혹에 빠린다는 점이다. 빌드가 한 주 동안 실패한다면, 다음 성공적인 빌드를 이뤄낼 때까지 여러 주를 기다려야 한다. 이러한 일이 생기면 사실상 일일 빌드에서 얻는 장점을 모두 잃어버린다.

 

어떤 개발자는 프로젝트가 너무 크기 때문에 매일 빌드를 진행하는 작업이 실용적이지 못하다고 주장한다. 하지만 최근 역사에서 가장 복잡한 소프트웨어 개발 노력을 기울인 프로젝트에서 일일 빌드 방법을 성공적으로 활용해왔다. 처음 배포할 무렵 윈도우즈 NT는 코드가 원시 파일 4만개에 560만 행이 흩어져 있었다. 완벽한 빌드는 여러 기계에서 19시간 정도 잡아먹었지만, NT 개발 팀은 여전히 매일 빌드를 진행하도록 관리하였다. 성가신 존재라기 보다 NT 팀은 이렇게 거대한 프로젝트에서 성공을 이룰 수 있었던 공로를 매일 빌드를 진행하는 관례에 기인한다고 생각했다. 이런 큰 프로젝트와 비교해 훨씬 적은 프로젝트에 몸담고 있는 우리 개발자 대부분은 왜 그렇게 매일 빌드를 진행할 수 없는지 설명하기가 정말 난감할 것이다.

 

기술 관리자 입장에서 매일 빌드를 진행하는 관례는 특히 유용하다. 그 이유는 순수하게 기술적인 단계에서 이를 구현할 수 있기 때문이다. 팀이 매일 성공적으로 빌드를 마쳐야 한다고 주장하기 위해서 어떠한 관리 권한도 필요없기 때문이다.

매일 빌드를 진행하는 관례는 프로젝트 복구 상황에서 특히 빛을 발한다. 성공적인 빌드를 마친 상태까지 도달할 수 없다면, 심지어 제품을 출시할 희망조차 없으므로 첫째 프로젝트 복구 목표 중 하나로 튼튼한 빌드를 위한 작업을 함께 고려하는 편이 바람직 하다. 일단 알려진 튼튼한 상태에 도달하면, 점진적인 추가를 통해 지속적으로 알려진 튼튼한 상태에 머문다. 항상 동작하는 제품을 보유하고 있다는 사실은 프로젝트 복구 단계에서 급격한 사기 증진으로 작용하며, 명확한 진행 표시를 가능하게 만든다.

 

18.2 일일 빌드와 동작 테스트 관련 위험 관리

 

일일 빌드에도 결정이 있다. 다음은 주요 결점이다.

 

낮은 완성도 제품 출시의 영향. 개발 그룹 외부의 사람이 매일 제품에 대한 빌드를 진행하는 광경을 보면, 외부 그룹을 위해 배포판을 만들어 달라고 자주 요청한다. 외부 배포판을 만드는 작업은 제품 관리자에게는 쉬워 보이며, 일일 빌드를 하지 않는 개발자가 아니라면 훨씬 쉬워 보인다. 하지만 이는 미묘한 방법으로 개발자 시간을 좀먹어 들어간다.

 

 - 개발자는 배포판을 지원하기 위해 필요한 자료지만, 최종 제품에 필요하지 않은 자료를 준비하느라 시간을 낭비한다. 이러한 자료는 문서, 여전히 개발 중인 특징을 정리한 중간 버전, 제품의 위험한 영역에 대해 불끄기. 디버깅 소스 감추기 등을 포함한다.

 

 - 개발자는 신중하게 변경을 진행할 수 있는 시점까지 기다리는 대신, 급하게 고쳐서 해당 특정 기능이 배포판에서 동작하도록 만든다. 이러한 급히 뜯어 고친 부분은 결국 문제를 가져오고, 개발자는 신중하게 변화를 추구했어야 하는 부분을 결국 다시 수정해야 한다. 전체적으로 개발자가 동일한 코드를 두 번 수정하는 시간 낭비로 귀결될 수 있다.

 

 - 개발자는 개발 생명주기 초기에 주먹구구에 근거하여 사소한 문제에 대응하느라 좀더 많은 시간을 소비한다. 하지만 이런 문제점은 개발자의 평소 작업 주기 일부분으로 좀더 효율적으로 처리할 수 있었을 것이다.

 

중간 배포판을 완전히 없애 버리길 바라지는 않을 것이다. 여기서 할 수 있는 일로 중간 배포판 숫자를 제한하는 계획을 세운 다음에는 이 숫자를 늘이려는 낌새조차 보이지 마라.

 

 

18.3 일일 빌드와 동작 테스트 관련 유발 효과

 

일일 빌드를 활용해온 어떤 개발자는 전반적인 제품 품질을 향상시킨다고 주장한다. 일반적인 주장 이외에 일일 빌드가 미치는 영향은 통합에 따른 위험, 품질에 따른 위험, 진척 상황에 따른 가시성 향상에만 국한된다.

 

18.4 일일 빌드, 동작 테스트와 다른 개발법 사이의 연관성

 

일일 빌드는 상세 중간목표 활용과 특히 잘 어울린다. 크리스 피터스는 "계획을 잡을 때 고려할 제1규칙은 지속적인 주의다" 라고 말했다. 완벽한 상세 중간 목표 집합을 정의했으며 일일 빌드가 망가지지 않았다는 사실을 알고 있다면, 작업 진행에 있어 예외적인 가시성을 확보한 셈이다. 프로젝트가 상세 중간목표를 충족시키는지 그렇지 못한지를 판단하기 위해 일일 빌드를 점검할 수 있다. 상세 중간 목표를 충족시킨다면 제때 끝날 것이다. 뒤처지기 시작한다면, 즉시 이를 감지할 수 있기에 여기에 맞춰 계획을 조정할 수 있다. 발생할 수 있는 유일한 스케줄 관련 오류는 스케줄에서 벗어난 상태를 계속 유지하는 무모함 뿐이다.

 

일일 빌드는 또한 점진적인 개발법을 위한 지원을 제공한다. 이러한 개발법은 소프트웨어 중간 버전을 외부적으로 배포할 수 있는 능력에 의존한다. 배포를 위해 빌드를 준비하는 데 들어가는 노력은 평균적이면서 부정기적으로 빌드를 진행한 프로그램을 출시를 위한 빌드로 바꾸는 데 필요한 노력과 비교하면 상태적으로 적기 마련이다.

 

18.5 일일 빌드와 동작 테스트에 대한 최종 결론

 

일일 빌드와 동작 테스트 공정은 사실상 위험 관리 개발법이다. 매일 진행하는 빌드와 동작 테스트 공정이 밝혀내는 위험은 스케줄과 관련한 위험이므로, 스케줄을 보다 예측 가능하게 만들고, 과도한 지원을 초래하는 통합 문제. 낮은 품질, 작업 진척 가시회 문제와 같은 몇몇 위험을 제거하는 강력한 능력이다.

 

일일 빌드 공정과 관련한 스케줄 효능에 대해 어떤 정량적인 자료가 있는지 모르겠지만, 일화는 일일 빌드 공정 값어치가 얼마만큼 매력적인지 알려준다. 맥카시는 마이크로소프트사가 개발 공정에서 얻은 단 한가지 사상을 전도해야 한다면, 이는 바로 일일 빌드와 동작 테스트 공정이라고 말한 바 있다.

 

18.6 일일 빌드와 동작 테스트를 성공하는 방법

 

여기에 일일 빌드와 동작 테스트를 활용하는 방법을 제시한다.

 - 매일 빌드를 진행한다.

 - 매일 동작 테스트를 진행한다.

 - 제품과 더불어 동작 테스트도 변화해야 한다. 제품이 발전함에 따라 테스트도 위미있게 진행해야 함을 명심하자.

 - 튼튼한 빌드를 프로젝트의 최고 우선순위로 두자.

 - 망가진 빌드는 규칙보다는 예외로 못박는 조치를 취하자.

 - 일일 빌드와 동작 테스트 공정을 압력이 크다고 포기하지 마라.