실용주의이야기(Pragmatic Story)

지속적인 통합의 이점

전반적으로 내가 생각하는 지속적인 통합의 가장 크고 넓은 범위의 장점은 위험을 줄여준다는 것이다. 내가 첫번째 단락에서 언급했던것 처럼 소프트웨어 프로젝트 초기로 돌아가 보자. 장기 프로젝트에는 끝이 정해져 있지만 실제로 끝나기 전에는 얼마나 오래걸릴지 사실은 알수가 없다.

통합이 지연되는 문제는 이 작업이 얼마나 오래 걸릴지 예측하기가 아주 힘들다는 것이고 더욱 안좋은건 이 과정이 얼마나 진행되었는지 아는것이 어렵다는 것이다. 이런 알수없는 부분은 프로젝트에서 가장 긴장되는 부분이다. 이런 경우가 아주 드물긴 하지만 이미 늦은건 아니다.

지속적인 통합은 이런 문제에 대해 완벽한 해결책이다. 통합은 오래 걸리지 않으며 알수 없는 부분을 완전히 제거할 수 있다. 시스템에서 어느 위치에 있는지, 뭐가 동작하는지, 뭐가 동작하지 않는지, 시스템에 버그가 무엇인지 항상 알수 있다.

버그는 자신감을 없애는 심술맞은 것이고 일정과 명성을 망친다. 소프트웨어를 배포할때의 버그는 사용자를 화나게 만든다. 작업중에 발생하는 버그는 소프트웨어의 남은 부분을 제대로 동작하도록 만드는걸 더 어렵게 만든다.

지속적인 통합이 버그를 없애주는건 아니지만 이를 발견하고 제거하는걸 쉽게 만들어 준다. 이렇게 해주는건 셀프 테스트 코드 덕분이다. 버그를 빨리 발견하게되면 이를 없애는것도 더 쉬어진다. 시스템에서 수정한 부분이 작기 때문에 살펴볼 필요가 없다. 시스템에서 작업한지 얼마 안됐기 때문에 작업한것을 생생이 기억하고 있다. 다시 만들게 되면 버그를 발견하는걸 더 쉽게 해준다. 시스템의 현재 버전과 버그가 없는 초기 버전과 비교하는 diff debugingg에 대해 살펴보라.

버그 역시 축척된다. 버그가 많아지면 이를 하나씩 없애는것은 더 어려워진다. 이는 버그와 상호작용 때문에 부분적으로 나타나는것이며 여러 결함은 실패로 나타나는데 각 결함을 발견하는건 더 어려워진다. 심리적인 부분도 있는데 버그가 많아지면 사람들은 버그를 발견하고 제거하는데 더 적은 에너지를 사용하게 된다. 실용주의 프로그래머에서는 이 현상을 Broken Windows syndrome 이라고 부른다.

지속적인 통합은 프로젝트에서 제품과 프로세스에서 극적으로 버그를 줄여준다. 그러나 이런 장점은 얼마나 테스트를 잘 하느냐에 직접적으로 관련이 있다는걸 강조하고 싶다. 차이를 알수 있도록 테스트를 빌드하는게 어렵지 않다는 사실을 알게 될 것이다. 그러나 보통은 팀이 정말로 낮은 수준의 잠재 버그를 발견하는데는 약간의 시간이 걸린다. 이 말은 계속해서 테스트를 만들고 향상시켜 나가야 한다는 의미이다.

만일 지속적인 통합을 사용한다면 잦은 배포를 위한 가장 큰 벽을 하나 제거한 셈이다. 잦은 배포는 사용자게 새로운 기능을 빨리 제공할수 있게 해주며 개발 주기를 더욱 공동의 작업으로 만들어주기 때문에 중요하다. 고객과 개발사이의 벽을 허무는데 도움이 되는데, 이 벽은 성공적인 개발에 있어 가장 큰 벽이라고 나는 생각한다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.