▲

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

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

바이너리 파일을 많이 다룬다면 git이 어울리지 않을 수 있지만 코드 중심의 레포지토리라면 git으로 충분한 것 같아요.

답변달기
▲
rtyu1120 1일전  [-]

MS 내부에서도 큰 변화였겠지만 덕분에 partial clone, sparse checkout 같은 기능들이나 Scalar 같은 도구들이 외부에도 공개되어 사용할 수 있게 된 점도 좋은 영향인 것 같습니다 ㅎㅎ

답변달기
▲
GN⁺ 1일전  [-]
Hacker News 의견
  • 언제나 이 오래된 이야기를 새롭게 풀어주는 글을 읽는 것은 즐거움이라는 생각임 TFA에서는 “오피스 저장소 전체를 가져오는 데 몇 시간이 걸렸다”는 점을 언급하면서, 사실 git에서는 VFS 같은 새로운 파일 시스템 없이는 이런 작업 자체가 거의 불가능했다는 점을 사실상 생략하고 있다는 지적임 Perforce에서는 사용자가 필요한 부분만 체크아웃할 수 있었으니, 대부분의 Source Depot 사용자도 매번 오피스 전체 앱을 가져오는 게 아니라 필요한 부분만 가져왔을 것으로 추정함 VFS는 git에서 필요한 객체만 다운로드받게 하여 이런 격차를 좁혀줌 Perforce/Source Depot은 중앙집중형 VCS로 당시에 굉장한 선택지였지만, 이제는 시대가 바뀐 느낌이라는 소감임
    • Perforce에서도 VFS처럼 필요한 순간에만 파일을 가져오는 자체 기술을 만든 회사가 있다는 설명임 이는 게임 개발에서 텍스트 파일과 함께 대용량 바이너리 소스 자산을 보관할 때 특히 중요함 윈도우에 내장된 원격 드라이브 프로그램이 사용하는 기술과 뿌리가 같다고 생각함 개인적으로는 회사 전체 소스를 저장하되, 로컬에 전체 히스토리를 복제할 필요 없이 서버 기반 VCS를 여전히 원함 하지만 git이 여러 기기 간 단발성 협업에는 충분히 쓸 만해서 중앙 서버와 CI/CD 파이프라인까지 구축할 필요성을 아직 못 느낌 git에서 stash, hunk 단위 stage, 인터랙티브 rebase 등 다양한 워크플로우를 매우 선호함
    • 우리 회사는 아직도 perforce를 쓰고 있음, 이제는 아무도 perforce를 좋아하지 않는다는 유감임 신입들에게 “우리는 git 안 써요”라고 말하는 순간 그들의 눈빛에서 빛이 사라지는 걸 직접 봄
    • VFS는 Perforce를 완전히 대체하지 못함 실제로 AAA 게임 회사 대부분이 여전히 Perforce를 사용 중이라는 점을 강조함 자산 파일에 락(lock)을 걸어 두 명이 동시에 수정해 병합 불가능한 상황을 방지해야 하고, 한 아티스트의 작업 결과를 버려야 하는 시간 낭비를 줄이는 데 필수적임
    • git이 왜 아직까지도 저장소 트리의 특정 부분만 선택적으로 체크아웃하는 기능을 제공하지 않는지 솔직히 의아함 객체 파일 등을 이해하는 중간 서비스를 붙이면 쉽게 확장할 수 있다고 생각함
  • 2016년 Microsoft 인턴십에서 Source Depot을 지원하는 자동 코드 리뷰어를 만들면서, Source Depot이 뭔지도 모르고 거의 일주일을 이 기능에 쏟은 경험이 있음 (https://austinhenley.com/blog/featurestheywanted.html) 그때도 여전히 많은 개발자들이 Source Depot을 쓰고 있었음 지금은 다 git으로 옮겨갔는지 궁금함
    • CodeFlow를 매일 그리워함 정말 멋진 툴이었다는 감정임
    • 여전히 Source Depot이 활발히 쓰이는 영역이 많다는 얘기임 Source Depot 명령어들과 환경 설정이 늘 나를 긴장하게 한다는 느낌
    • 일상적인 업무의 대부분은 이제 git에서 처리하고 있다는 근황임
  • 90년대에 직접 vss(Visual SourceSafe)를 사용한 입장에서, 이번 기사에서 그 이야기가 언급조차 안 된 점이 놀라움 Visual SourceSafe는 Microsoft가 자체적으로 만든 소스 버전 관리 프로토콜이었는데, Source Depot은 Perforce에서 라이선스 받아서 사용한 것과 차이가 있었음
    • VSS(Visual SourceSafe)는 Raleigh의 One Tree Software를 인수해서 받아들인 제품이었고, 제품명을 “SourceSafe”에서 “Visual SourceSafe”로 바꿔 Visual C, Visual Basic 등과 같이 번들로 제공했음 그 이전에는 “Microsoft Delta”라는 버전 관리 제품을 팔았는데, 가격은 비싸고 품질은 떨어졌으며 NT에서 아예 지원도 안 됨 One Tree 인수로 들어온 인물 중에 Brian Harry가 있는데, 이 분이 Team Foundation Version Control(TFS)을 이끌었음 SQL Server를 저장소로 사용하면서 VSS보다 관리성과 신뢰성이 크게 향상됨 Brian Harry는 지금 은퇴한 듯하고 블로그도 더 이상 업데이트되지 않음 당시 VSS를 쓰며 기억나는 것 중 하나는 네트워크 파일 락킹을 SMB로 처리해서 빈번한 네트워크 오류에 취약했고, 저장소가 손상되는 일이 자주 있었음 그래서 매일 새벽에 복구하는 배치 작업을 걸어 야간에 자동 복구시켜야 했음 아침에 쓸 수 있어야 했기 때문임
    • 90년대에 VSS 썼던 경험상, 팀으로 일할 때는 악몽에 가까웠으며, 알고 있기로는 Microsoft도 내부적으로는 거의 안 썼던 것으로 기억함
    • 90년대에 혼자 개발할 때 VSS를 썼었는데, 당시로선 신세계 같았음 대학원에서 다른 VCS(RCS, CVS 등)를 접했음 2004년에 마이크로소프트에 입사했을 때 누군가 VSS는 비안전적이고 손상되기 쉽다고 설명해줬던 게 기억남 그게 사실인지는 모르겠지만, 어쨌든 회사에선 VSS가 아예 선택지조차 아니었음
  • Microsoft를 XNS에서 TCP/IP로 마이그레이션할 때 팀원이었음 이 작업은 생각보다 별로 복잡하지 않았지만, 비슷한 교훈을 얻었음 MSMAIL에서 Exchange로 옮기는 건 정말 힘들었음
    • 예전에 “Exchange: The Most Feared and Loathed Team in Microsoft”라는 문구가 적힌 번호판 프레임을 봤었음, 이게 그때 경험 때문인지 궁금함 20년 전이라 정확한 표현은 기억 안 남
  • “Authenticity mattered more than production value”가 정말 와닿음 출퇴근 직전(2015년)에야 Source Depot에서 Git으로 전환하기 시작한 소규모 제품 라인에서 일했던 전 마이크로소프트 직원으로서 이런 작업에 얼마나 많은 노력이 들었는지 완전히 공감함 정말 멋진 업적임
    • 나 역시 이런 과정을 다 겪은 게 믿기지 않는다는 생각임 고마운 마음이라는 메시지임
  • 2000년대 초반 Microsoft가 고민했던 상황을 보면, Windows가 엄청나게 복잡해지고 수백만 줄 코드가 버전 관리를 필요로 했지만 git은 아예 없었고 SVN도 막 성장하던 시절이었음 Microsoft가 1998년에 개발돼 2000년 공개된 BitKeeper 같은 상업용 제품도 적극 고려했었는지 궁금함 아마도 당시에는 Perforce 같은 중앙집중 시스템이 대세였고, BitKeeper 같은 분산형은 이질감 있거나 검증된 사례가 부족했을 수도 있겠다는 추측임
    • 당시에는 VSS(Visual SourceSafe)도 있었고 이후에는 TFVC가 있었음
  • 나 같은 초보 엔지니어에게 Source Depot의 미스터리를 알려준 개발 리드들에게 고마움 전함 Source Depot 구조를 제대로 이해하자 정말 눈이 번쩍 뜨이는 경험이었음 나는 WinCE와 IE에만 의존이 있어서 복제(clone)에 20분밖에 안 걸렸지, 며칠씩 걸리지 않아서 다행이었다는 생각임 도움을 줬던 분들 이름은 잊었지만, 신입을 도와 쉽게 일 시작하게 해주려 한 자세만큼은 지금 내 팀에서도 계속 이어가며 실천함
  • 대부분 사람들이 git 도입을 기술적 승리로 기억하지만, 사실 진짜 혁신은 개발자 개개인이 스스로 워크플로우를 제어할 수 있게 된 점임 더 이상 동기화 창 기다릴 필요도, 브랜치 접근 권한을 리드에게 부탁할 필요도 없음 이제 모두가 자유롭게 속도 내며 일하면서도 서로 충돌하지 않는 환경이 됨 이 변화가 생산성 대시보드보다 분위기 개선에 훨씬 큰 영향을 줬다는 강한 인상임 git은 단지 도구뿐만 아니라 개발 루프에 대한 신뢰까지 바꿔준 계기였음
  • Microsoft가 내부적으로 Visual SourceSafe에서 언제 벗어났는지 궁금함 더 일찍 단종해 외부에서 계속 쓰이는 일만큼은 막았어야 했다고 생각함
    • 대부분 팀이 VSS를 실제로 쓰지 않았으리라 생각함 Microsoft에서 일하면서 우리 팀은 Source Depot을 사용했다는 경험임 당시 TFS도 경험했는데 별로 좋아하지 않았음, 그럼에도 Source Depot 쓰고 나니 오히려 TFS가 그리워짐
    • Microsoft 내부에서 VSS를 주요 용도로 썼는지 의문임 만약 진짜 내부에서 썼다면 그렇게 허술한 제품 상태로 내놓진 않았을 거란 생각임 TFS는 좀처럼 이해할 수 없는 경험이었고, 내부든 외부든 별로 였음
    • 2000년 즈음이었을 것으로 추정함 내가 아는 한 유일하게 쓴 프로젝트는 .NET이었는데, 그마저도 이미 Source Depot으로 넘어가 있었음
    • Microsoft SourceSafe가 있다는 사실조차 몰랐다는 반응임
  • OneNote shallow clone이 200GB라는 얘기를 잘 이해하지 못하겠음
    • 실제로는 OneNote가 아니라, office 전체 shallow clone이었다는 설명임
    • 비디오나 대용량 바이너리가 포함되어 있었던 것으로 추정함
답변달기