조직에서 Git을 사용해야 하는 이유

SVN에서 각 개발자는 하나의 중앙 집중식 리포지토리를 가리키는 작업 복사본을 받습니다. 하지만 Git은 분산된 버전 제어 시스템입니다. 각 개발자는 작업 복사본 대신 전체 커밋 기록이 포함된 자체 로컬 리포지토리를 갖게 됩니다.

Git으로의 전환이 회사의 마케팅 활동에 어떤 영향을 미치는지 이해하기 위해 개발 팀이 향후 몇 주 안에 완료할 예정인 3가지 주요 변경 사항이 있다고 가정해 봅시다.

• 팀 전체는 지난 6개월 동안 작업해온 획기적인 기능을 마무리하고 있습니다.
• Mary는 기존 고객에게만 영향을 미치는 작고 관련성이 없는 기능을 구현하고 있습니다.
• Rick은 사용자 인터페이스에 절실히 필요한 업데이트를 수행하고 있습니다.

중앙 집중식 VCS에 의존하는 기존의 개발 워크플로를 사용한다면 이러한 모든 변경 사항은 하나의 릴리스로 합쳐지게 될 것입니다. 마케팅 팀은 획기적인 기능에 주로 초점을 맞춘 한 가지 발표만 할 수 있으며 나머지 두 업데이트의 마케팅 잠재력은 사실상 무시됩니다.

Git을 사용하면 개발 주기가 더 짧아져 이 모든 변경 사항을 개별 릴리스로 나누기가 훨씬 쉽습니다. 이를 통해 마케터들은 더 많은 내용을 더 자주 전달할 수 있게 됩니다. 위의 시나리오에서 마케팅 팀은 각 기능을 중심으로 하는 세 개의 캠페인을 구축하여 매우 구체적인 시장 부문을 타겟팅할 수 있습니다.

제품 관리 팀에서 누리는 Git의 이점은 마케팅 팀과 거의 동일합니다. 릴리스 빈도가 높을수록 고객 피드백을 더 자주 받을 수 있으며 그 피드백에 대해 신속하게 업데이트할 수 있습니다. 지금부터 8주 후에 있을 다음 릴리스를 기다리는 대신 개발자가 코드를 작성하는 즉시 고객에게 솔루션을 푸시할 수 있습니다.

기능 브랜치는 신속한 프로토타이핑에 적합합니다. UX/UI 디자이너가 완전히 새로운 사용자 흐름을 구현하거나 단순히 일부 아이콘을 바꾸려고 하든, 새 브랜치를 체크아웃하면 샌드박스 환경이 제공됩니다. 따라서 디자이너들은 기존 기능을 손상시킬 위험 없이 제품의 실제 작업 복사본에서 변경 사항이 어떻게 보일지 확인할 수 있습니다.

고객 지원 팀과 고객 성공 팀은 업데이트에 대한 이해가 제품 관리자와 다른 경우가 많습니다. 고객이 전화하는 경우는 보통 어떤 문제가 발생했다는 뜻입니다. 해당 문제가 회사의 소프트웨어로 인해 발생한 경우 가능한 한 빨리 버그를 수정해야 합니다.

Git의 간소화된 개발 주기는 다음 모놀리식 릴리스까지 버그 수정을 연기하지 않도록 합니다. 개발자는 문제를 패치하고 프로덕션에 직접 푸시할 수 있습니다. 수정 속도가 빨라지면 고객 만족도가 높아지고 반복적인 지원 티켓이 줄어듭니다. 고객 지원 팀은 “죄송합니다. 바로 처리하겠습니다”라는 말 대신 “이미 해결했습니다!”라고 대답할 수 있습니다.

소프트웨어 개발 워크플로에 따라 채용할 대상이 어느 정도 결정됩니다. 조직의 기술과 워크플로에 익숙한 엔지니어를 채용하는 것이 항상 도움이 되지만 Git을 사용하면 다른 이점도 얻을 수 있습니다.

직원들은 경력 성장 기회를 제공하는 회사에 마음이 끌리며, 크고 작은 규모의 조직에서 Git을 활용하는 방법을 이해하는 것은 모든 프로그래머에게 큰 도움이 됩니다. Git을 버전 제어 시스템으로 선택하는 것은 미래 지향적인 개발자들을 유치하는 결정을 내리는 것과 다름없습니다.

Git은 효율성을 무엇보다 중요시합니다. 개발자의 경우 네트워크 연결을 통해 커밋을 전달하는 데 낭비되는 시간부터 중앙 집중식 버전 제어 시스템에 변경 사항을 통합하는 데 필요한 작업 시간까지 많은 시간을 절약할 수 있습니다. 또한 후임 개발자에게 안전한 작업 환경을 제공하여 인력을 더 효율적으로 활용할 수 있습니다. 이 모든 결과는 엔지니어링 부서의 수익에 영향을 미칩니다.