일일 빌드라던가 지속적인 통합에 대해 들어본 적이 있는지 모르겠다. 대부분의 현업 종사자라면 최소한 한번쯤 들어보기라도 했으리라 생각하지만, 나의 경험에 비추어봤을 때 학생의 경우라면 들어보지 못한 사람도 많을 것이다. 통합개발서버를 두었다고 가정하고 간단하게 설명해보자. 당신은 C# 기반의 RSS Reader를 개발하고 있다. 모 포탈의 블로그 서비스의 RSS 포맷이 변경되었다. 불행하게도 RSS 2.0 포맷을 제대로 이해 못한 개발자의 작품인지, 파싱이 되지 않는다. 예외처리 코드를 추가하고 커밋한다. 소스버전관리시스템에 새로운 코드가 추가되자, 통합개발서버가 할 일이 생겼다며 기뻐한다. 부지런히 빌드하고 코드 컨벤션이 지켜졌는지 확인한 다음, 단위 테스트를 시행한다. 어이쿠, 단위 테스트 중 하나가 실패했다. 당신은 슬프지만 코드를 다시 검토한다.
자, 여기서 살펴보려는 것이 무엇일까? 앞서 소스 코드를 커밋하자마자 모든 작업이 이뤄지는 것처럼 묘사했다. 그러나 일반적으로 통합개발서버는 자신만의 주기를 갖는다. 다시 말해 10분 또는 30분 주기로 새로운 소스코드가 들어왔는지, 소스버전관리 시스템에 묻는 작업을 반복한다. 그렇다 보니 빌드 및 테스트 실패를 사용자에게 알리는 것이 중요한 문제가 된다. 이메일로 결과를 통보하면, 사용자가 문제를 파악하는데 어느 정도의 시간이 걸릴지 알 수가 없다. 운이 나쁘면 한 시간을 넘기고서야 눈치챌 수도 있다. ‘지속적인 통합’이 성공하려면 지속적으로 제품의 스냅샷을 올바르게 유지해야 한다는 점을 감안하면, 큰 문제가 아닐 수 없다.
지난 8월에 좋은 사람이란 아이디를 쓰시는 분께서 XP 팀의 작업실을 번역하셨다. 한동안 인구에 회자되었던 글인지라, 이미 일독한 이도 있으리라 생각한다. 이 글 중 ‘개발 통합 서버’라는 항목엔 다음과 같은 설명이 달려 있다. 모두 성공하면 기쁜음악이 연주되지만, 문제가 발생하면 슬픈음악이 연주됩니다.
슬픈 음악은 슬프지 않고 오히려 우스꽝스럽다. 한번 상상해보자. LCD를 눈이 떨어져라 지켜보고 있다. 10분이면 해결될 줄 알았던 문제가 꽤 오래간다. 머리가 아파올 것 같다. 순간, 통합 실패를 알리는 효과음이 들린다. 피식 웃으며 고개를 돌려 누구야?
라고 묻는다. 오늘의 간식 당번이 누구인지 자못 궁금하다.
개발자 5명 정도가 한 방에 모여 있다면, 우스꽝스러운 음악으로 충분하다. 하지만 대규모 개발팀이라면 어떨까? Microsoft SQL Server의 개발팀이라면 엄청나게 큰 출력의 스피커가 필요할 것이다. 코오롱 그룹의 경우에는 본관 현관에 매순간의 실적 달성률을 보여주는 전광판이 있다고 한다. 이와 유사한 아이디어가 소프트웨어 업계에서도 사용되고 있다. extreme Feedback devices라고 불리는 램프를 누구나 볼 수 있는 곳에 세워놓는다. 왜 이런 쓸데없는 짓을 하는가?
라고 생각할지도 모르겠다. 분명한 것은 브룩스가 The Mythical Man-Month를 내 놓은 이후로 소프트웨어 프로젝트의 가장 큰 이슈는 의사소통이었다. 대규모 개발일수록 참가자 모두가 프로젝트의 진행 상황에 대한 명확한 감각을 공유할 필요가 있다. 일주일에 평균 한번 꼴로 빨간불이 들어왔었다. 그런데 최근 들어 불길한 기운과 자주 마주치는 것 같다. 무엇인가 잘못되고 있다는 불안감을 느낀다. 굳이 누군가 총대를 매고 수십 또는 수백명이 모이는 회의를 주선하지 않아도, 팀 스스로 위기의식을 느끼고 문제를 해결할 기회가 주어진다. 결코 재미로 램프를 제작하는 것이 아니다.
이외에도 여러 시도가 있었는데 참고 문헌에 적어놨다.
참고 문헌
-
eXtreme Feedback for Software Development by Alberto Savoia
-
On Java Lava Lamps and Other eXtreme Feedback Devices by Alberto Savoia
-
Hacking together an Extreme Feedback Device
