Perforce에서 Git으로: 마이그레이션하는 이유

작업흐름

SCM 도구는 근본적으로 공동 작업을 중요시하므로 개발자 팀은 공유된 소프트웨어 파일에 대해 작업할 수 있습니다. Git은 간단하고 계산적으로 비용이 저렴한 브랜칭을 제공하기 때문에 여러 유용한 워크플로를 활용할 수 있습니다. 작업 브랜칭, Git Flow, 포크된 리포지토리와 강력한 코드 검토 및 공동 작업 도구를 통해 오픈 소스에서 전문 개발까지 모든 유형의 팀이 빠르고 쉬운 워크플로를 사용할 수 있습니다.

또한 Git을 사용하면 교차 기능 개발의 공통적인 요구 사항인 회사 경계를 넘는 공동 작업이 손쉽게 이루어집니다. Git 공유 리포지토리에 대한 물리적 네트워크 액세스가 불가능하더라도 Git 패치와 번들 도구를 사용하면 데이터를 간단하게 공유할 수 있습니다.

반면에 Perforce는 Git의 커밋당 기록과 달리 파일별로 브랜칭 레코드를 유지합니다. 이것은 무엇을 의미할까요? 우선 브랜치를 만들 때마다 Perforce 데이터베이스에 엄청난 양의 메타 데이터가 만들어집니다. 이는 많은 Perforce 관리자가 브랜치 만들기를 제한해야 할 정도로 대규모 배포에서 성능 문제를 일으킵니다.

새 기능을 시험하기 위해 작업 브랜치를 만들 때마다 권한을 요청해야 한다고 생각해 보세요. 작업 브랜치를 만들 수 없다면 main 브랜치에서 불안정한 코드를 체크인하거나 그냥 “완료”될 때까지 기다렸다가 커밋할 수도 있습니다. 작업 브랜치에 대한 CI/CD와 진행 중인 작업을 세부적으로 추적할 수 있다는 이점은 포기하게 됩니다. 개발자가 덜 생산적인 워크플로를 사용하거나 Git을 부수적인 도구로 사용하여 작업을 Perforce에 다시 수동으로 병합하는 방법을 알아내려고 한다면 결과적으로 생산성이 떨어집니다.

Perforce 브랜치는 비용이 많이 들 뿐만 아니라 대부분의 개발자가 선호하는 워크플로 유형에 적합하지 않습니다. Perforce 브랜치는 공유되므로 주기적으로 rebase하는 비공개 작업 브랜치란 없습니다. 또한 Perforce의 병합 알고리즘은 매우 복잡합니다. 이름이 변경되거나 특성이 수정된 파일을 병합하는 방법에 대해 어마어마하게 긴 글이 작성될 정도입니다.

그리고 Perforce 서버 간 코드 공유의 경우 공통의 기록이 없는 tar 파일 공유로 돌아오게 됩니다. Perforce의 데이터 모델은 소프트웨어 기록을 단일 서버에 고유한 것으로 간주하며 기록을 어디에나 쉽게 복제하고 공유할 수 있는 Git의 기능과는 비교됩니다.

마음 점유율 및 커뮤니티

상용 경쟁업체를 제외하고 Git이 Mercurial 및 기타 주요 경쟁업체를 제칠 수 있었던 이유는 무엇일까요? Git에는 추진력에 대한 가치가 있습니다. Git은 Linus Torvalds가 Linux 커널 프로젝트의 분산된 개발 과제를 해결하기 위해 만들었으며 현재 Linux, Android, OpenStack을 비롯한 대부분의 주요 오픈 소스 프로젝트를 위한 표준 SCM 도구로 사용됩니다. 그만큼 인기 있는 도구이므로 채용 관리자라면 신입 엔지니어가 광범위한 교육 없이도 Git을 사용할 수 있고 (또 원할 것이라고) 생각할 수 있습니다.

그리고 물론 Git의 활발한 오픈 소스 커뮤니티의 모든 힘을 활용할 수 있습니다. Git LFS와 같은 새로운 주요 기능이 등장하면서 Git은 실질적인 문제를 해결하기 위해 빠르게 발전하고 있습니다. 수정하고 싶은 버그가 있으면 Git 프로젝트에 자신의 코드를 기여할 수 있으며 하나의 회사에서 설정한 로드맵과 속도에 따라 상용 제품에 얽매이지 않을 것입니다. 강력한 데스크톱 GUI, Windows Explore 통합, 모든 IDE용 플러그인 및 개발자 도구와 같이 사용 가능한 여러 Git 클라이언트 프로그램을 살펴보세요.

GUI 및 개발자 도구

Git 초창기에는 GUI와 도구 지원이 다소 부족했습니다. Git 리포지토리와 상호 작용하기 위해 시각적 인터페이스를 선호하는 사용자에게 걸림돌이었습니다. 게임 아티스트와 같이 기술 분야 이외의 공동 작업자인 경우 특히 더 쉽지 않았습니다. Perforce의 Windows Explorer 플러그인이 이러한 사용자들 사이에서 인기를 끌었습니다.

다행히 그 시절은 지났습니다. Sourcetree와 같은 GUI는 포인트 앤 클릭 경험을 제공하고 Git에는 여러 셸 통합이 있습니다. Bitbucket은 코드 검토, 병합 및 풀리퀘스트, 포킹, 온라인 코드 검색을 비롯해 기타 다양한 공동 작업 도구를 제공합니다. 실제로 데이터 사이언티스트부터 크리에이티브 에이전시까지 모두 Git과 Bitbucket이 가능하게 만든 열린 공동 작업을 활용하는 커뮤니티를 구성하고 있습니다.

특별한 게임 개발자

그렇다면 게임 개발자 및 연구원과 같이 거대한 데이터 집합을 다루는 일부 커뮤니티가 시류에 뛰어드는 것을 막은 요인은 무엇일까요? 모든 것의 핵심은 데이터 유형과 프로젝트 조직의 복잡성입니다.

바이너리 파일

게임 개발자, 특히 아티스트는 텍스처 및 오디오 자산과 같은 대규모 바이너리 개체로 작업해야 합니다. 데이터 사이언티스트는 수십억 개의 이벤트 샘플로 구성된 거대한 데이터 집합을 가지고 있을 수 있습니다.

이는 Git에 두 가지 문제를 제기합니다.

• 이러한 파일은 병합할 수 없습니다. 중앙 집중식 잠금 메커니즘이 편리하며 Perforce에서 이 메커니즘을 제공합니다. (하지만 중앙 집중식 서버라도 한 브랜치에서만 잠금 메커니즘을 제공하므로 이 기능에 의존한다는 것은 워크플로가 매우 제한적임을 의미합니다.)
• 이러한 파일로 인해 리포지토리 크기가 커질수록 Git의 속도가 느려집니다.

리포지토리 크기 문제는 대부분 Git이 대용량 파일을 처리하고 실제 파일 스토리지는 다른 곳에 위임할 수 있도록 해주는 확장 기능인 Git LFS를 통해 해결됩니다.

파일 잠금 문제는 두 가지 측면에서 살펴봐야 합니다. 소프트웨어 구성 관리 관점에서 볼 때 Git LFS는 로드맵에서 파일 잠금 기능이 훨씬 뛰어납니다. Git LFS는 어떤 브랜치에 있든 최신 버전에서 작업할 수 있게 해주는 알고리즘으로 여러 브랜치에 걸친 바이너리 파일 잠금을 조정하는 데 도움이 됩니다. 그러면 Perforce의 단일 브랜치 잠금 모델에 비해 대용량 바이너리 파일로 작업하는 사용자가 브랜칭 워크플로를 사용할 수 있도록 합니다.

파일 잠금을 조정 문제로 생각하는 것도 좋은 방법입니다. 병합할 수 없는 공유 자산에 대한 작업을 시작하려는 경우 그 지식을 모든 이해 관계자에게 어떻게 전달할 수 있을까요? 다시 강조하자면 풀리퀘스트와 실시간 팀 공동 작업을 사용하는 최신 워크플로의 등장은 바로 이 부분에서 정말 효과적입니다. HipChat으로 신속하게 의도를 전달하고 특정 파일에 대해 진행 중인 작업이 있는지 확인할 수 있습니다.

빅데이터 시대에 대용량 파일 처리의 문제가 어떻게 발전할지 생각해 보는 것도 흥미롭습니다. 빅데이터 분석 작업을 테스트하려면 몇 테라바이트 크기의 데이터 집합이 필요할 수 있습니다. 이 프로젝트는 빅데이터 호환 파일 시스템에서 테스트 및 실행되므로 SCM 시스템은 잊어버리세요. 여기서 필요한 것은 HDFS나 S3에 있는 아티팩트로 더 복잡한 파이프라인을 오케스트레이션할 수 있는 CI/CD 시스템입니다. 이 부분이 다음 주제로 이어집니다.

대규모 프로젝트

게임 개발은 게임 엔진, UI, 정적 아트, 비디오 렌더링 등 여러 모듈이나 구성 요소가 있는 소프트웨어 프로젝트의 전형적인 예입니다. 모놀리식 중앙 집중식 리포지토리인 Perforce는 단일 서버에서 이 모든 모듈을 호스팅하고 사용자가 자신의 작업 영역에서 원하는 부분을 선택할 수 있도록 합니다.

그러나 이러한 이점은 이제 거의 무의미합니다. Bitbucket과 같은 최신 Git 시스템에서는 하위 모듈 및 하위 트리와 같은 Git 다중 모듈 도구를 더 쉽게 관리할 수 있습니다. 그리고 더 중요한 것은 Android와 같은 대규모 프로젝트에서는 더 높은 수준의 구성 도구를 사용하여 복잡한 프로젝트를 관리하는 방법이 나타났습니다. 여기서 배운 점은 대부분 복잡한 지속적 통합 워크플로를 오케스트레이션하고 프로젝트 간 종속성을 모델링하며 아티팩트를 관리할 수 있는 Bamboo 및 Bitbucket Pipelines와 같은 최신 CI/CD 도구에 적용되었습니다.

이러한 추세는 주로 하나의 작업을 매우 잘 수행하는 도구를 만든다는 Git(및 *nix) 철학을 따릅니다. 지속적 통합과 지속적 제공(CI/CD)은 빌드 및 릴리스 워크플로를 이해하기 위한 도구를 통한 자체적인 관행입니다. 모놀리식 프로젝트가 아닌 자립적인 소규모 마이크로서비스를 사용하는 것을 목표로 하는 최신 소프트웨어 개발 모범 사례와도 정렬됩니다.

다음 단계

“Perforce에서 Git으로”의 변화에는 어느 정도 추진력이 있으며 이제 Git 및 최신 CI/CD 도구는 가장 크고 복잡한 개발 작업을 처리할 준비가 되어 있습니다. 실제로 Perforce는 중앙 집중식 Perforce 리포지토리의 일부를 Git 리포지토리로 추출할 수 있는 Git Fusion이라는 도구도 만들었습니다.

안타깝게도 Git Fusion은 훌륭한 노력의 결과물이었지만 중앙 집중식 SCM 시스템에 Git을 계층화하는 것은 쉬운 일이 아닙니다. 사용 모델을 혼합하려고 하면 한 시스템의 데이터 보기가 쉽게 손상될 수 있습니다. 사용 모델을 혼합하지 않으면 상용 중앙 집중식 백엔드를 Git에 두는 것의 가치를 얻기가 어렵습니다. Atlassian에서 본 추세는 사실 반대 방향입니다. 유용했던 중앙 집중식 SCM의 남은 몇 가지 부분을 Git에 어떻게 적용할까요?

소프트웨어나 게임 개발에 Perforce를 사용하고 있다면 Git으로 마이그레이션하는 방법이 궁금하면서도 마이그레이션이 걱정될 수 있습니다. 어떻게 해야 할까요? 전환 비용을 감수할 만한 가치가 있을까요? 바로 이러한 질문을 다음 글에서 다루게 됩니다.