안녕하세요. 오늘은 우리 개발자들의 귀를 솔깃하게 할 이야기를 들고 왔습니다. 바로 Microsoft Office가 내부 소스 관리 시스템(SCM)인 Source Depot에서 Git으로의 대규모 마이그레이션 여정을 다룬 것입니다. 이 흥미진진한 프로젝트의 배경과 과정, 그리고 배우게 된 교훈까지 함께 탐구해보겠습니다.
Source Depot에서 Git으로 – 그 도전의 시작
마이크로소프트에서는 2000년대 초부터 Perforce 기반의 Source Depot 시스템을 사용해왔습니다. Source Depot는 느린 브랜칭과 중앙집중식 구조로 당시에는 최선의 선택이었지만, 시간이 지남에 따라 생산성을 제한하는 걸림돌이 되었습니다. 그 결과, Microsoft Office 팀은 더 나은 개발자 경험을 위해 그들의 소스 관리 시스템을 Git으로 전환하기로 결단했습니다.
도구의 변화가 아닌 조직의 변화
이 프로젝트는 단순한 도구 전환이 아니라, 수백 명의 엔지니어와 수년에 걸친 대형 프로젝트였습니다. Office 엔지니어링 팀은 제품의 출시 주기가 다양하고, 이미 강력하게 묶인 기존 인프라를 그대로 유지할 수밖에 없는 상황에서, Git과 Source Depot을 병행 운영해야 했습니다. OneNote를 시작으로 Git으로의 전환이 천천히 시작됩니다.
VFS for Git – 초대형 코드베이스의 해결책
마이크로소프트 개발자들이 줄곧 겪어온 문제 중 하나는 Git의 대용량 소스 코드 처리 한계입니다. 이 문제를 해결하기 위해 GitHub와 함께 Virtual File System for Git(VFS for Git)을 개발했는데, 이는 실제로 필요한 파일만 받아오는 방식으로 Git의 한계를 혁신적으로 극복했습니다.
소통과 협력을 중심으로
마이그레이션 성공의 핵심은 'Developer Satisfaction Champion'을 지정해 모든 팀이 원활히 소통할 수 있는 구조를 마련한 것이었습니다. 저마다 프로젝트를 이끄는 챔피언들이 각 팀의 연결고리가 되어, 신속한 피드백과 협력 체계가 가능하게 했죠.
교육과 롤백 전략의 중요성
오랜 기간 Source Depot에 익숙해진 엔지니어들을 위해 실습형 교육과 체계적인 전환 지원은 필수였습니다. 또한, 전환 과정에서 문제가 발생할 경우를 대비하여 즉시 롤백 가능한 시스템을 준비해 놓았습니다. 이러한 안전 장치는 프로젝트 진행에 있어 매우 중요한 역할을 했습니다.
성공의 결실과 교훈
이 모든 노력을 통해 Microsoft Office 팀은 온보딩 시간을 반으로 줄이고, Git 도입 후 생산성을 상당히 향상시켰습니다. 특히 Git 도입으로 엔지니어들은 스스로 워크플로우를 제어할 수 있게 되면서, 더 이상 동기화 창을 기다리거나 권한을 요청할 필요가 없었습니다. 이는 생산성 향상뿐 아니라, 개발자들의 만족도와 협업의 질을 크게 높였습니다.
결론적으로, 이 대규모 마이그레이션 프로젝트는 기술적 성공뿐만 아니라 사람 중심의 변화 관리가 얼마나 중요한지를 보여주는 훌륭한 사례가 되었습니다. 다른 기업에서도 이러한 경험이 새로운 도전의 밑거름이 되기를 기대합니다. 여러분도 큰 변화를 계획 중이라면, 이 사례를 참고해 보세요!