테스트를 담당하는 팀원이 물었다.

'지금 메일 Sender 테스트 열심히 돌리고 계시죠?'

다른 일을 하고 있던 나는 아니라고 대답했다. 메일 Sender에서 수신처를 본인의 실제 메일 주소로 설정한 모양이다. 메일 박스를 확인했는데, 테스트로 보낸 메일이 쌓여 있어서 내가 테스트를 많이 해서 그런 것이라고 추측한 듯하다. 원인은 CI툴이었다. 정확히 말하면 CI툴에 설정해놓은 자동화 테스트였다. 테스트 계정을 만들어두거나 Mock을 활용한 것이 아니라 마치 자가스팸 발송 스케줄러를 돌릴 꼴이었다. 물론, CI 설정을 본인이 하지 않았으니 이런 일을 미리 예상하지는 못했으리라. 아직 개발초기라 모니터링 차원에서 Commit 시점마다 테스트를 수행하도록 설정해두었기에 꽤나 메일이 많이 보내졌으리라. 어쨌든 덕분에 웃을 수 있었다.

팀 협업의 중요성를 작성한지 일주일만에 슬슬 '이슈 트래커 + 마일린 조합'의 실전 적용을 시도하고 있다. 실제 진척관리는 엑셀을 이용해서 하고 있는데, 그게 마일린의 작업(Task) 단위로 쓰기에는 너무 길어서 이를 커밋하는 단위로 쓰면 팀 작업이 통합이 안되는 긴 기간이 발생한다. 결국 진척관리와 이슈 트래커 + 마이린 연계를 일원화 하기 위해서는 작업을 미세하게 나눌 필요가 있다. 감으로는 대략 작업 시간의 최대치를 반나절 이하로 나누야 할 듯 하다.

Ticket으로 구분하는(Trac 기준) 작업이 SCM 커밋에 주석으로 사용한 첫 번째 사례를 만들었다.

3주 후를 본격 적용 시점으로 잡고 있는데, 우리 팀이 과연 해낼 수 있을까?

팀 협업의 중요성은 말하고 말 것도 없다. 그러나, 조금 다른 시각으로 다시 한 번 실감했다. 약 한달 전인 4월 7일 올렸던 포스트에 첨부했던 그림이다.


SCM 이력이다. 주석(Comment)에는 여러 가지 내용을 넣을 수 있다. 위에 보이는 것처럼 아무것도 넣지 않을 수도 있다. 그러나, 최소한 무엇을 변경했는지 알려줘야 내 동료가 자칫 허비할 수 있는 노력을 줄일 수 있다.

최근 3일 정도 SCM 개정 이력이다. 무슨 작업을 하고 올린 것인지 상당히 명확하게 바뀌었다. 얼마전 박재성씨가 했던 세미나에서 다룬 주제가 이른바 CI(Continuous Integration) 환경이다. 박재성씨는 아마도 Andrew Hunt와 David Thomas가 만든 조류를 칭하여 실용주의개발환경이라고 이름 지은 듯 하다.

뭐라 칭하든 팀 개발 속도(Velocity)를 높이고, 불필요한 버려지는 시간을 줄이려는 목적을 갖고 있다. 불필요한 버려지는 시간은 상당 부분은 개별 개발자들이 팀의 지향점과 동떨어져서 혼자 개발한 부분을 모아서 하나로 통합하려고 할 때 실감할 수 있다. 간혹 스스로도 Jira와 Clover 같은 도구에 집착하긴 하지만, 정작 중요한 것은 협업하는 주체 즉 팀원이다. 그들이 단결(Integration)해서 협업(Collaboration)하지 못한다면, CI 도구¹ 는 한낱 것치레에 불과하다. 그러나, CMMI 인증을 얻는 과정에서 개발팀의 성숙도가 높아지는 혹은 높아지기도 하는 것을 보면, CI 도구 역시 개발팀의 협업 성숙도² 를 높이는 촉매제 역할은 할 수 있을지도 모른다.

기술에 있어서도 얼리 어답터가 있다. 나 역시 그런 부류에 속한다. 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

(관련 글을 이어가면서 팁으로써 쌓아두고, 시간이 지나고 나면 가지치기를 통해 더 나은 열매를 거둘 수 있을까 하는 심정으로...)


CI 관련 글:
헛슨(Hudson)이 만들어준 상쾌한 프로젝트 환경
공동작업시 묵비권 행사를 자제해주세요
중복의 제거
사람을 위한 자동화 한글 번역 시리즈 (IBM DW)
진정한 의미의 리비전?
개발환경 자동화 환경에 대한 추천 조합 (조대협님 블로그)
Hudson을 이용한 빌드 배포 테스트 자동화 (조대협님 블로그)
Atlassian JIRA를 이용한 프로젝트 관리 (기초편) (조대협님 블로그)

TDD 관련 글:
실전 테스트 코드 리팩토링(수정)
Test Driven Development 전도 일지 1
Test Driven Development 전도 일지 2
EasyMock(old)을 활용한 협업 테스트

문서화 관련 글:
jAutodoc으로 깔끔한 javadoc 만들기

오픈소스 Continuous integration 툴인 헛슨(Hudson)을 이용하면 변경 내용에 대한 요약 정보를 보다 쉽게 알 수 있다. 그리고, PMD 플러그인을 추가하면 일반적인 규칙이나 팀 표준을 위반한 사항을 쉽게 확인할 수 있다. 또한 ANT Target 설정을 해두면 테스트 결과 추이를 도표로 확인할 수 있다.




테스트 커버리지를 위한 플러그인(Cobertura)을 추가하면 코드 커버리지도 확인이 가능하다. 조금만 노력하면 무료인 오픈소스 솔루션 만으로도 프로젝트 진척 상황을 보기 위한 상쾌한 환경을 구성할 수 있다. (커버리지가 0%인 좋지 못한 예제 화면이지만... ^^)

하지만, 프로젝트에 조금의 여력이 있다면 아틀라시안 툴 사용을 권장하고 싶다. (나도 아틀라시안 툴 쓰고 싶다. ㅡㅡ;)

흥미로운 뉴스는 자바지기 박재성님께서 관련 노하우를 공유하고 싶어해서, KSUG와 공동으로 세미나를 열기로 했다. 자세한 사항은 아직 일정과 장소가 미정인지라 추후 공지할 예정이다. 대략의 내용은 자바지기님 블로그에서 확인할 수 있다.


* 허드슨 설정에 대한 자세한 한글 가이드가 있네요.
- Hudson을 이용한 빌드 배포 테스트 자동화 (4/22 추가)

지속적 통합으로 조기에 결함 발견하기

워낙에 흥미로운 주제를 다루고 있다. 많은 개발자들에게 아직은 생소할 Continuous Integration을 다룬 글이다. 이전에 번역을 기다리는 리뷰를 쓴 일이 있는데, 약 두달만에 한글 문서가 올라왔다. 2쪽에서 '넛셸에서의 CI'라는 생소한 표현이 나오는 부분은 조금 아쉽다. 구글에서 "in a nutshell 이란"으로 검색해보면, 첫번째 결과만으로도 좋은 지침을 주었을 텐데... 하지만, 본문을 이해하는데 무리를 주는 표현은 아니다.