지속적인 개선
Continuous Integration
"방문은 언제나 즐거운 일이다.
도착할 때 그렇지 않으면 떠날 때라도 반드시 그렇다"
엠마뉘엘 카레르가 쓴 장편소설 <나 아닌 다른 삶>에 나왔던 문장이다. 달리기 매니아인 소설가 김연수는 그의 책 <지지 않는다는 말>에서 이 문장을 그가 좋아하는 달리기에 비유했다.
"달리기는 언제나 즐거운 일이다. 시작할 때 그렇지 않다면 끝날 때는 반드시 그렇다"
어떤 일이든 마찬가지다. 소프트웨어 개발 역시 그래야 한다는 것에 모든 개발자들이 동의할 것이다. 시작할 때 즐겁지 않더라면 끝날 때에는 반드시 즐거워야 한다. 달릴 때 느꼈던 터질것만 같던 심장의 고통과 근육의 긴장감은 결승선에서 흐르는 땀과 함께 뿌듯한 성취감으로 바뀌는 것이 마땅하다. 그런데 만약 끝이 없다면 어떨까?
소프트웨어 개발은 지난한 문제 해결 과정의 연속이다. 소프트웨어 개발이라는 것은 사실 끝이 없다. 완벽한 소프트웨어라는 것이 존재하지 않기 때문이다. 버전 1.0의 개발이 끝나도 별다른 기능추가가 필요치 않아도 유지보수라는 새로운 험로가 개발자들을 기다리고 있다. 버그를 고치면 소프트웨어를 다시 빌드해야 하고 다시 테스트해야 한다. 그리고 문제가 없다고 판단되면 사용자에게 소프트웨어를 배포한다. 이 과정은 시시포스가 굴러떨어진 바위를 다시 산 위로 밀어올리는 것처럼 끊임없이 반복된다. 이 어쩔 수 없는 반복을 인정할 수 밖에 없다면 우리는 어떻게 하면 이 반복작업을 문제없이, 그리고 효율적으로 할 방법을 찾아야만 한다.
여러 사람이 함께 코드를 작업하면 코드 정합(code merge)이 필요하다. 내가 작업해서 내 환경에서 돌렸을 때는 문제가 없었는데 소스코드 형상 관리서버에 올리고 이를 다른 사람이 받아서 돌리면 문제가 생기는 일이 비일비재하게 일어난다. 원인을 파악하고 제대로 된 코드가 나오기까지 다시 시간이 소요된다. 테스트는 어떨까? 여기서 테스트했을 때는 문제가 없었는데, 저기서 테스트하니 이상한 문제가 생긴다. 이것 역시 원인을 파악하고 조치하는데 또 만만치 않은 시간이 걸린다. 오랜 시간을 들여 확인한 결과 해프닝으로 끝나는 경우도 많다. 누군가가 잘못 남겨놓은 파일 하나 때문에 모두가 고생하는 일은 그리 드물지 않게 일어난다.
그래서 등장한 것이 지속적인 통합(CI Continuous Integration)이다. 말 그대로 지속적으로 소프트웨어 코드를 통합하자는 것이다. 방법론적으로 더 구체화해서 설명하면 소프트웨어 코드의 빌드와 테스트, 검사를 지속적으로 반복하자는 것이다. CI는 꼭 자동화를 말하지 않는다. 사람이 수동으로 하더라도 지속적으로 자주 진행하면 된다. 하지만 같은 일을 매번 사람이 반복하는 것은 비효율적이므로 자동화는 필수다. 따라서 통상 CI는 자동화된 소프트웨어 통합 프로세스라고 할 수 있다. 소프트웨어 개발에서 있어 심각한 문제 중의 하나는 '이정도 했으니 문제 없겠지'라는 어설픈 가정이다. 이런 어설픈 가정이 위에서 언급한 문제들을 만들어낸다. CI는 이런 가정 자체를 하지 않는다. 문제가 있겠지, 없겠지 와 같은 전제는 존재하지 않는다. 단지 할 수 있는 확인을 모두 하는 것이 CI시스템이 하는 일이다.
CI의 기술적인 핵심요소이자 프로세스는 다음과 같다.
지속적인 코드 체크인 continuous check-in
지속적인 소프트웨어 빌드 continuous build
지속적인 테스트 continuous test
지속적인 배포 continuous release
지속적인 피드백 continuous feedback
모든 요소가 중요하다. 어느 하나라도 빠지면 소프트웨어를 만들어서 배포하는 것에 문제가 있는 것이다. 코드 체크인과 소프트웨어 배포까지는 중요하다고 생각하는데 피드백을 소홀히 하는 경우가 많다. CI프로세스를 적용하든 그렇지 않든 각각의 활동에 대한 결과와 그 피드백이 투명하게 공유되고 다음 개선에 반영되어야 한다.
여기서 CI를 어떻게 구축하고 어떤 플랫폼을 쓰는게 좋은지와 같은 기술적인 사항은 다루지 않는다. 인터넷을 조금만 찾아봐도 좋은 플랫폼과 노하우를 찾을 수 있다. 그리고 CI는 공짜로 구축가능하다! 조금만 구글링해봐도 쉽게 도입할 수 있다. 좋은 소프트웨어를 만들고자 한다면 관심을 가질 필요가 있다.
지속적인 통합(CI, Contiunous Integraton)이 결국 지속적인 개선(CI, Contiunous Improvement)이다.
개선은 한발자국 한발자국씩 나아지는 것이다. 이는 개선에 대한 의지가 있으면 가능하다. 작은 관심으로부터 개선은 시작된다. CI 시스템 역시 점진적으로 개선하는 것이 좋다. 처음부터 모든 기능을 왕창 집어넣어서 한번에 최고의 결과를 얻고자 하는 생각은 버리자. 또한 CI는 가급적 프로젝트의 초기에 구축하는 것이 좋다. 그래야 그 효능을 100% 발휘할 수 있다. 헨리포드가 말한대로 품질이란 누가 보지 않을 때에도 제대로 돌아가는 것을 뜻한다. 누가 보고 있지 않아도 제대로 돌아가는 CI 시스템이 있다면 소프트웨어 개발에 큰 레버리지가 생기는 셈이다. 모든 소프트웨어는 본질적으로 개선의 가치를 가진다. CI 역시 그 핵심은 개선의 가치에 있다.
