기술에 있어서도 얼리 어답터가 있다. 나 역시 그런 부류에 속한다. CI를 다루는 내용이 몇 년에 걸쳐 최고의 서적으로 꼽히고 있고, 기타 등등으로 대세인 듯 하여 CI 환경이 욕심이 났다. 빌드나 배포 절차에 대해서 잘 모르면 CI 구축 자체도 간단한 일은 아니다. 빌드 스크립트에 대한 이야기는 기본 요건이니 다루지 않겠다. 국내 환경에서 CI가 잘 쓰여지는 것은 쉬운 일이 아닐 것이다. (그런 면에서 KSUG 7th는 무척 의미있는 자리다.)

CI가 잘 쓰이기가 왜 그렇게 힘든가? 잘 쓰이려면 어떻게 해야 하는가에 대하여 여기에서 짧막하게 써보려고 한다.¹ 먼저, CI는 차곡차곡 쌓인 테스트가 있을 때 의미가 있다. 본인 이름을 거명하는 것을 좋아하지 않는 T씨가 이렇게 말했다. 'CI 구축하면 뭐하냐? 테스트가 없으면 헛 일인데'. 사실이 그렇다. CI를 구축하는 일은 (단위) 테스트 없이 개발하는데 수년을 보낸 개발자들에게 테스트를 하게 하는 것에 비하면 만분의 일의 노력도 들지 않는다. 많은 사람이 돈을 받고 만들어내는 프로그램의 경우 테스트는 그리 녹록치 않다.

두 번째, SCM에 커밋 혹은 CI(Check in)하는 단위, 그리고 자동 빌드를 수행하는 주기는 팀의 진척과 연관이 있어야 한다. 아래 그림을 보자. 563회의 수정이 가해졌다. 그러나, 주석을 가만히 보면 의미있는 작업이 쌓인 것이라고 보기 힘들다.


의미있는 단위로 개인의 작업(task)을 분할하고, 그 결과를 Commit한다면 SCM의 갱신이력은 의미있는 작업 이력으로 보일 것이다. 그 작업 이력이 모여서 마일린(Mylyn)의 작업목록, 이슈트래커의 작업이력에 대응하면 연계가 깔끔(seamless)하다. 그 작업들이 모여서 Milestone을 이루고, Release Note에 기술하는 항목을 이룬다면.... 그것이 Spring 등의 오픈소스 프로젝트가 보여주는 간결하고 기민한 공정이다.

꿈이 있다면 3,4개월 혹은 5,6개월 이후에 그런 공정을 만들어나가는 과정에 대해서 공유하고 싶다. 가능할까?

오늘 낚은 블로그에 좋은 그림이 있다.

출처: Enterprise Engineering, based on Architecture and Ontology