설치본을 가장 먼저 만드는 프로젝트.

요즘에야 프로젝트의 시작부분에 설치본을 만드는 것이 당연하다 생각되나, 나 자신도 몇년전에는 그러하다 생각지 못하였는데, 그 이유는 "설치할 것이 있어야 설치본을 만들지!"라는 생각에서였다.

하지만, 제일 쉬우면서도 가장 오래, 배포되는 프로그램의 끝까지 애를 먹이는 것이 바로 배포를 위한 설치본, 또는 부분패치 설치본이며, 이것은 릴리즈 엔지니어링의 마지막 결과물에 해당한다.

강조를 백번해도 모자랄 정도로 프로젝트의 시작부분에서의 설치본인데, 이것은 개발조직이 분화되기 위한 첫걸음이된다. 개발초기부터 테스팅 및 릴리즈를 위한 얘기를 할 수 있고, 중간 단계쯤에서 그간 진행된 기능에 대한 다양한 피드백을 받을 수도 있고, 나중에 고생할만한 일을 초기에 잡을 수 있는 아주 필수적인 것이 개발팀이 설치본을 만들어 배포하는 것이다. 그것이 비록 불완전하게 동작한다할 지라도, 설치본이 대화의 중심에 있어야한다.

다양한 계층의 테스터, 성능이나 UI에 대한 피드백을 프로그래머들이 오너십을 가지고 진행한다는 것은 얼마나 피곤한 일인가? 그것은 전문성도 떨어지려니와 프로그래머에게 설계/구현/디버깅이라는 행위에서 의견 수집/분석/조율이라는 행위간의 문맥전환을 수시로 일으키기란 참으로 어려운 일이다.

설치본을 어떻게 만들것이냐는 것은, 초기에는 대~~충 설치본을 만드는 한이 있더라도 초안을 생각해두고 진행해야한다. 설치 및 삭제 그리고 부분 업그레이드에 대한 것이 나중에 버그를 잡는데도 도움이 된다. 그 이유는 한 번 개발팀을 떠난 것은 어떤 식으로든, 부메랑을 타고 돌아오게 되어 있다. 그런데, 문제는 개발팀의 손을 한두번 떠난것이 아닌 상황이 오게되면, 부메랑에 맞아 쓰러지는 상황이 발생하게 된다.

몇가지 정리하자면, 설치본을 만들때는 다음과 같은 상황을 고려해야한다.

1. 매일매일 최신소스로 설치본이 자동으로 만들어지는가?
2. 임의의 바이너리가 어느 빌드에서 생성되었는지 알 수 있는가?
3. 바이너리들이 의존하고 있는 라이브러리들은 모두 알고 있는가?
4. 바이너리안에 들어 있는 global symbol(nm 명령을 통해)들은 관리가 되고 있는가?
5. 이전 설치본과 지금 설치본에서 변경사항은 자동으로 뽑혀 릴리즈 노트를 구성할 수 있는가?
6. 부분 테스트를 위한 정보들은 버그트래킹시스템과 연결되어 꼭 필요한 인수 테스트를 할 수 있는가?

매일매일 최신소스로 설치본이 자동으로 만들어지는가?
아마 이 부분이 다른 다섯가지보다 가장 재미있고, 쉽고, 뿌듯한 부분이 아닐까 한다. 왜냐하면, 자동으로 만드는 스크립트에는 나머지 것들에 대한 모든 것이 포함되기 때문이다. 그 끝은 관련자들에게 따끈따끈한 설치본의 URL과 빌드로그 및 릴리즈 노트를 메일로 전송하는 것이 될 것이다. 이렇게 기쁜 일은 프로젝트가 시작할 때 얼른 담당하고 남주지 말자. 만약 당신이 닥치는대로 공부하는 열정이 있는 사람이라면 이 일은 정말 남주면 안될 것이다.

적절히 crontab 을 운영할 것이고, 빌드 로그중에서 warning만을 추려내어 따로 보고해야할 지도 모르며, 하나의 소스로 여러 OS에서 동시에 빌드할 수 있어야하고, apache의 fancy indexing도 사용해야할 수도 있고, 가장 빨리 빌드하는 방법을 위한 여러 안건을 만들 수도 있고, cvs나 subversion 등의 tag, diff, merge 등에 대해 일가견이 생기게 되고 하여간 도무지 말로 할 수 없는 수 많은 것들을 빌드 시스템을 구축하면서 찾고 공부하게 된다.

임의의 바이너리가 어느 빌드에서 생성되었는지 알 수 있는가?
바이너리 안에는 대개 "static char []"형으로 된 $Id$가 들어가게 된다. 이것은 소스 정보만을 나타내게 되지만, ident라는 좋은 툴은 $String ...$ 형태로 되어 있는 모두 뽑아주므로 거기에 팀의 독특한 스트링을 버전 및 빌드 번호를 표시하는데 사용할 수 있다. 예를 들면
$Version: doorscan 2.2.1.1224 $
와 같이 Version 이라는 것을 사용할 수 있겠다. 만약 2.2.1.1224 와 같은 이름으로 소스 트리를 태깅을 해놓는 다면, 바이너리를 만드는데 들어간 소스들의 버전을 쉽게 뽑아낼 수 있게된다.

또는 반대로, 바이너리를 출시한 뒤 MD5 해시 값을 구해놓고 빌드시점에 모든 파일의 MD5 해시를 저장해 놓은 뒤 비교하여 구할 수도 있다.

바이너리들이 의존하고 있는 라이브러리들은 모두 알고 있는가?
ldd 를 이용한 검사인데, 개발도중 어느새 모르게 개발팀이 모르는 라이브러리가 들어갈 수 있다. 이것은 설치가 개발 장비에서만 제대로 될 수 있고, 정작 다른 곳에는 해당 바이너리가 없는 것으로 인해 설치후에 수행이 되지 않을 수 있다. 어딘가에 그 프로젝트 전체적으로 외부 라이브러리를 사용한다면 모든 배포되는 바이너리가 어떤 의존관계를 가지고 있고, 그 의존 관계에 대한 것은 선행작업이 필요함을 설치본 배포시에 적절히 명시해야한다.

바이너리안에 들어 있는 global symbol(nm 명령을 통해)들은 관리가 되고 있는가?
바이너리가 특히나 shared object(so) 파일이라면, 흔히 저지르기 쉬운 것이 단지 어떤 실행파일이 사용한다정도의 정보만을 가지기 쉽다. 즉, ldd에 의한 의존성만 확인하는 경우가 발생할 수 있는데, nm 을 통해서 정확히 외부에 노출시킬 것이 노출되고 있는지, 이전과 다르게 추가되거나 삭제된 것이 없는지 확인해야한다. shared object 의 생명은 global symbol(defined, undefined)l과 의존성이다. 이것이 적절히 빌드시점에 생성되거나 관리되지 않는다면, 나중에 업그레드시에 모든 바이너리가 배포되어야하는 상황이 발생할 수 있다. 그러면 왜 so로 분리했느냐!라는 소릴 듣게 될 수도 있다. 무작적 so로 쪼게는 것은 정말 삼갈일이며, 그것은 신발에 껌을 잔뜩 붙이고 줄넘기하는 것과 똑같다.

이전 설치본과 지금 설치본에서 변경사항은 자동으로 뽑혀 릴리즈 노트를 구성할 수 있는가?
릴리즈 노트라는 것은 새로운 버전을 출시할 때, 개발자들이 그간의 기억을 미루어 적어 내거나, 그동안 처리했던 버그 리스트를 정리하는 것이 아니다. 그것은 버그를 처리할 때마다 적어 놓은 간단한 노트들이 있어야하고, 그 노트들을 각 버전별로 뽑을 수 있는 상태로 관리되어야하는 것이다.

간단히는 cvs나 subversion을 쓸 때, 커밋로그를 이용해서 릴리즈 노트용을 적절한 규칙에 의해 적게되면, 태깅한 기간별로 구별하여 뽑아 낼 수 있다. 로그는 한 번 올리면 다시 수정못하는 것으로 아는데, cvs의 경우 cvs admin 명령으로 subversion의 경우 svn ps svn:log 조합으로 다시 고칠 수 있다. 로그는 커밋하는 시점외에는 다시 자세히 적을일이 없게된다. 대략 간단한 어플리케이션을 개발하는데, 5000 번 정도의 커밋이 되면 알파 릴리즈가 만들어지는데, 5000번에 대한 것을 누가 이후에 관리할 것인가.

부분 테스트를 위한 정보들은 버그트래킹시스템과 연결되어 꼭 필요한 인수 테스트를 할 수 있는가?
SCM(Software Configuration Management)이라는 영역이 있다. 검색을 하게 되면 개발 관련된 각종 도우미 툴들이 소개되는데, 가장 중요한 것은 소스를 소스만으로 두는 것이 아니라, 제기된 이슈나 버그, 그리고 고친 내역등을 유기적으로 결합하는 방법을 어떻게 구성할 것인가에 있다.
학교에서 갓 나온 수준으로 기업형 프로그램을 만들어야할 경우, 프로그램이란 몇달하고 마는 것이 아니라 계속 살아서 발목을 잡아 당기는 실로 무시무시한 존재와 같은 것을 느끼게 된다. 이런 문제를 해결하기 위해 버전 컨트롤 시스템을 도입하게되는데, 그 이후에도 문제는 또 발생한다. 버전 컨트롤 시스템이 단지 코드의 변화에 대한 것은 알려주지만, 코드가 변하는데는 이유가 있어야 하며, 그 이유의 근원에 대한 것은 동시에 수십 수백개가 관리되어야하고, 릴리즈 이후 코드에 변형을 가하는 모든 커밋에 대한 것이 테스트 대상으로 연결되어 문제를 재발하지 않고, 원하는 방향으로 적절한 계획을 가지고 나갈 수 있어야한다.

이상으로 간단히 빌드와 관련된 것을 살펴보았는데, 소스가 공개되어 개발되는 프로그램들을 잘 살펴보면, 빌드 및 그 관리와 관련된 상당히 많은 노하우들이 그 프로젝트안에 녹아 있고, 그 과정들이 단지 프로그래밍 실력으로만 시작하여 진행되는 것이 아니라는 것을 알 수 있다. 그들은 끊임없이 고객의 요구를 수용하고 있고, 버그를 찾고 있으며, 새로운 기능을 추가하고 있다. 이것이 모두 릴리즈를 어떻게 관리할지에 대한 것에 대한 것이 모두 오픈되어 진행된다.

어디서 개발을 하던지, 이상과 같은 빌드관리가 선행되지 않는다면, 조만간 누구도 손댈 수 없는 코드로 변신하고 말것이다.