서비스되는 소프트웨어가 조직 혹은 팀단위의 결과물이고 팀웍을 통해 작성되어 유지된다는 것을 의심하는 이가 없습니다. 팀은 일감을 분리해 병렬 방식으로 업무하고 각자의 결과물을 통합합니다.
이러한 통합을 위해 XP(Extreme programming)의 관행 속 하나의 용어이며, 익히 알려진 ‘연속 통합 (CI)’ 전략은 팀을 하나의 동기화된 덩어리로 묶는데에 매우 효과적입니다. 해당 소프트웨어를 개인이 프로그래밍하고 있는 것이 아니라 팀이 프로그래밍하고 있는 것이죠.
이를 적용하기 위한 팀은 자동화를 필수적으로 도입합니다.
그런데 자동화를 위한 빌드 서버만 갖추면 ‘연속 통합’ 을 도입한 것 일까요?
실망했겠지만 ‘연속 통합’에서 자동화는 필수가 아닙니다.
연속 통합에 대한 논리적인 이해
‘연속 통합’에 대해 서술하자면…
이는 팀원의 작업을 연속적으로 자주 통합시키는것을 일컫습니다.
그럼 어느 정도로 자주, 그리고 연속적으로 통합해야할까요?
제임스 쇼어는 ‘연속 통합’에 대해 2~4시간마다 통합하는것을 설명의 사례로 사용했습니다. 마틴 파울러는 모든 팀원이 최소한 하루에 한번 통합해야하고 하루에 여러번 통합될 수 있다고 이야기합니다.
저는 이것을 팀원들이 서로와 자주 동기화해 소프트웨어 작성에서 팀의 응집력을 극도로 상향시키자는 것으로 해석하고 있습니다. 또한 마틴파울러는 통합을 ‘팀원들간 커뮤니케이션에 관한 것’이라고 설명합니다.
팀 단위 작업에서 서로 자주 커뮤니케이션 한다는건 어떤것을 의미할까요?
‘보물찾기’를 하는데 보물이 없던 곳을 서로에게 자주 공유하는것과 같습니다.
통합의 주기가 클수록 큰덩어리를 통합해야합니다. 이것은 확인되지 않은 ‘문제’를 계속해서 축적하게 합니다. 여기에서 ‘문제’는 ‘통합으로 인한 문제’입니다.
물리적 연속 통합 도입
연속 통합을 이행하기 위한 물리적인 환경을 구성하고 유지하고 발전시키는 건 앵간한 기술 조직 아니면 쉬운 일이 아닙니다.
연속 통합을 위해 사용하던 ‘Task 쪼개기’ 방식이 영향을 받을 수 있습니다. 특정 인원이 해당 Task를 하루 만에 해결하지 못할 수도 있습니다. 기능단위로 분기(Branch)를 관리했다면 이는 변경되어야할 것 입니다. 팀 구조도 영향을 받습니다. 또한 중간에 발생하는 학습비용도 무시할 수 없습니다.
통합될 주체 저장소는 (git은 Main branch) 항상 건강해야 합니다. 문제가 발생하면 이는 최대한 빨리 해결해야 한다는 과제를 포함합니다. 수많은 팀원들이 하루에도 몇 번씩 복사하는 원본이기에 문제가 있다면 그리 유쾌한 일은 아닐 겁니다.
자동화된 머신의 빌드 속도 또한 무시 못 합니다. 빌드 자동화 단계를 몇 개로 세분화해 가벼운 1차 방어선을 획득하는 것도 좋은 전략 중 하나입니다.
무엇보다 모든 팀원이 연속 통합을 이해해야 합니다.
연속 통합(CI) 도입에 대한 자세한 이야기는 웹에 많은 사례와 자료가 있으므로 중략하겠습니다.
마치며
연속 통합은 아직까지도 발전을 이루고 있는 현역입니다.
중요한건 빌드 자동화를 도입했다고 CI를 도입한건 아니라는 것입니다.
자동화는 논리적인 면을 실현하는 물리적인 도구일 뿐입니다.
연속 통합은 모든 비지니스에서 정답이 아닙니다.
이것을 유지하는데 더 큰 비용이 든다고 판단되면 필요가 없습니다.
