Microsoft Office가 Source Depot에서 Git으로 마이그레이션한 과정

• Microsoft Office는 오랜 기간 내부 소스 관리 시스템인 Source Depot를 사용하다가, 개발자 경험과 기술 혁신을 위해 Git으로 대규모 마이그레이션을 진행했음
• Source Depot는 중앙집중식, 느린 브랜칭, 불편한 워크플로우로 생산성에 한계가 있었으며, Git으로의 이전은 수백 명의 엔지니어와 수년에 걸친 작업이 필요함
• 마이그레이션 과정에서는 VFS for Git과 같은 새로운 기술 개발, 기존 빌드/테스트 인프라 이식, 병행 시스템 운영 등 대규모 기술적·조직적 도전과제를 극복했음
• 성공적인 이전을 위해 "챔피언" 중심의 소통 체계, 과감한 투명성, 실용적인 교육, 즉각적 롤백 전략 등 협업적이고 인간 중심의 접근법을 강조함
• 마이그레이션 이후 온보딩 시간 감소, Git 선호도 증가(89%) , 생산성 향상 등 긍정적인 결과와 함께, 대규모 기술 변화의 핵심 교훈을 남김

Source Depot에서 Git으로: Microsoft Office 대규모 마이그레이션 경험

개발자 생산성 극대화라는 새로운 도전

• 개발자 생산성을 높이는 작업은 'Multiplier work' 로, 대규모 조직일수록 그 가치가 큼
• Microsoft Office의 Source Depot에서 Git으로의 마이그레이션 프로젝트가 대표적 경험이었음
• 이 작업은 단순한 도구 변경이 아니라 수백 명 엔지니어, 복잡한 시스템, 오랜 기간에 걸친 대형 프로젝트였음

Source Depot: 그 시절 소스 관리 이야기

• 2000년대 초 Microsoft는 Perforce 기술 기반의 자체 버전 관리 시스템인 Source Depot를 운영함
• Source Depot는 느린 브랜칭, 중앙집중화, 긴 코드 체크아웃 시간, 불편한 병합 방식(Reverse/Forward Integrate) 등으로 작업 효율에 한계가 있었음
• 전체 개발 인프라(빌드, 릴리스, 워크플로우)와 강하게 결합되어 있어 단순 교체가 불가능한 구조였음
• Microsoft Office의 Git 전환에는 수년과 수백 명 엔지니어의 노력이 필요했음

OneNote를 시작으로: 마이그레이션의 시작

• Office 엔지니어링 조직에서 Source Depot 유지·패치 비용과 “경쟁력 있는 기술” 요구로 대대적 Git 이전이 결정됨
• Office 제품군은 출시 주기(수개월, 반기, 월별, 인사이더)별로 개발 스케줄이 달라, 장기간 Source Depot-Git 병행 운용이 필요했음
• Office 버전 관리 일관성, 빌드 검증, 레거시 테스트 인프라 이식 등이 필수 과제로 등장했음

Office 규모와 소통 전략

• Office는 당시 4,000명 규모의 엔지니어가 협업하는 초대형 조직이었음
• 팀별로 'Developer Satisfaction Champion'을 지정, 각 팀을 연결하는 hub-spoke 모델을 통해 원활한 피드백과 소통 구조를 마련했음
• 필자는 OneNote의 챔피언으로, 대규모 마이그레이션 현장의 핵심 역할을 담당했음

VFS for Git: 초대형 코드베이스의 한계 돌파

• 한 번의 git clone이 200GB 이상 필요할 정도로 코드 규모가 커, GitHub와 공동 개발한 Virtual File System for Git (VFS for Git) 로 문제를 해결함
• VFS for Git은 실제로 쓰는 파일만 받아오는 방식으로 기본 Git의 한계를 극복함
• Microsoft Windows와 협력하며 업계 최대급의 버전 관리 시스템 한계를 뛰어넘는 경험이었음

마이그레이션 단계별 접근

1단계: 병렬 우주(Parallel Universe)

• Source Depot와 Git을 실시간 동기화하는 브리지 서비스를 구축, 양 시스템의 불일치 및 모델 차이(브랜치 구조, changelist 등) 문제를 반복 개선함
• Office 메인/Private 브랜치-동기화-빌드 과정을 24/7 자동화 시스템으로 운영함
• 세 번에 걸친 재시도 끝에 안정적으로 동작하는 병렬 시스템을 구현함

2단계: 동등성 검증

• 모든 테스트 스위트를 두 시스템에서 반복 실행하여, 빌드 결과가 완벽히 같음을 입증함
• 줄바꿈 방식, 대소문자, 테스트 결과 포맷 등 미묘한 차이를 수개월 동안 디버깅하며 해결함
• 'Green across the board' (양쪽 시스템 모두 테스트 통과) 성과로, 실제 전환 단계 진입 준비 완료함

인간 중심의 접근법

다중 채널, 반복 소통

• 4,000명+ 엔지니어와 수십 팀의 스케줄을 맞추기 위해, 각 팀별 챔피언과 집중적인 커뮤니케이션 체계를 구축함
• 중요 공지는 최소 3회(이메일, Teams, 위키, 미팅 등) 반복 전달해 혼선 최소화함
• 문제 발생 시, 즉각적이고 투명한 정보 공개로 신뢰 확보

Git 도입 교육 및 적응

• 10년간 Source Depot에 익숙한 엔지니어를 위해 실습형 교육 환경과 전환 명령어 안내 등 단계적 학습 체계를 마련함
• 실전 중심의 비디오 라이브러리 등을 통해 실제 시나리오 기반 학습 제공
• 불안 해소와 역량 강화를 넘어서 기존 워크플로우 적응 지원

롤백 전략과 안전 장치

• 실제 전환 시 Director에게 '레드 버튼'을 제공, 심각한 문제시 언제든 즉시 롤백 가능
• 과거 Source Depot의 일부 기록은 오랜 기간 보존, 기존 개발 히스토리 안전하게 유지

결과와 주요 성과

• 이전 후 온보딩 시간 50% 단축, Git 선호도 89% 확인, 빌드 성능 개선, 코드 리뷰 효율성 및 협업 증가 등의 생산성 향상 효과가 나타남
• 엔지니어들은 산업 내 변환 가능한 기술 습득을 긍정적으로 평가함
• 신규 인력의 바로 투입 가능성도 높아짐

대규모 마이그레이션 핵심 교훈

• 기술 요소뿐 아니라 사람 중심의 소통에 예상을 뛰어넘는 투자를 해야 성공 가능
• 병행 시스템 구축과 완벽 동등성 입증, 초기부터 확실한 롤백 설계, 핵심 인력(챔피언) 강조
• 만족도 등 정성적 지표 병행 측정이 반드시 필요하며, 변화 과정에서 조직적 안정과 심리적 안전 감각이 중요
• 대규모 변화의 본질은 조직 전체의 유연하고 체계적인 변화 관리임

결론 및 향후 적용

• Office의 Git 마이그레이션은 수년간의 준비, 수개월의 실행으로 이뤄진 역사적 프로젝트였음
• 궁극적으로 수천 명의 업무 연계성을 보장하며 조직적 변화를 성공적으로 추진한 사례로 남음
• 클라우드 전환, 모놀리식 아키텍처 분해, 프레임워크 업그레이드 등 다른 대규모 변화에서도 병행 검증, 반복적 소통, 신속 롤백 설계가 동일하게 적용될 수 있음
• 기술적 상세(빌드 인프라, 오프라인/계약 이슈 등)는 추가적으로 다루지 않았으나, 대규모 기술 변화의 전략적·조직적 접근이 가장 중요한 교훈임