¶ 20권 — 형상관리 자체 구축하기: GitLab 셀프호스팅과 브랜치 전략
← 시리즈 로드맵 목차 · ↔ 3권과 짝을 이루는 심화 트랙
GitHub 같은 SaaS 형상관리로 개발을 시작한 조직이 "우리가 직접 서버를 두고 운영해야 하는가"라는 질문과 마주칠 때 참고할 수 있도록, GitLab 셀프호스팅의 설치·브랜치 전략·권한 구조·운영 원칙을 판단 기준 중심으로 정리한다.
¶ 왜 SaaS에서 자체 구축으로 전환을 고려하는가
전환을 검토하는 이유는 대체로 세 축으로 정리된다.
- 비용: 인원이 늘수록 사용자당 과금이 선형적으로 증가하는 SaaS와 달리, 자체 구축은 라이선스 비용을 서버·운영 인건비로 대체하는 것에 가깝다.
- 보안·데이터 주권: 규제 산업이거나 계약상 소스코드 반출 금지 조항이 있으면 SaaS는 원천적으로 제외되며, 이는 성장 단계와 무관하게 초기부터 적용된다.
- 유지보수 부담: 자체 구축은 서버 패치·업그레이드·백업·재해복구를 모두 사내에서 책임져야 한다.
¶ 설치 방법과 서버 규모 가늠하기
설치 방식은 리눅스 패키지(Omnibus) 방식이 가장 성숙하고 확장 가능하다.
설치 전에는 "몇 명이 어느 부하로 쓸 것인가"를 가늠해야 한다.
- 팀 규모가 수십~백여 명이면 단일 노드 설치로 충분하다.
- 실제 부하가 늘어날 때는 참조 아키텍처 문서를 보고 단계적으로 확장하는 것이 현실적이다.
¶ 브랜치 전략: GitLab Flow와 병합 규칙
GitLab 진영의 대표 워크플로는 GitLab Flow다. main은 항상 배포 가능한 상태를 유지하고, 기능 개발은 기능 브랜치에서 MR을 통해 합류시킨다.
필요에 따라 브랜치 종류를 추가한다.
- 온프레미스 납품이나 다중 환경 순차 배포가 필요하면 환경 브랜치를 추가한다.
- 다중 버전을 동시 지원해야 하면 릴리스 브랜치를 추가한다.
브랜치 전략은 반드시 규칙으로 강제해야 한다. 보호된 브랜치로 병합/푸시 권한을 세분화하고, 병합 요청 승인 규칙과 코드 오너(Code Owners) 승인을 결합해 강제할 수 있다.
¶ 그룹·서브그룹으로 권한 구조 설계하기
자체 구축의 장점 하나는 조직 구조를 세밀하게 반영할 수 있다는 점이다. 이를 가능케 하는 것이 그룹/서브그룹의 상속 기반 권한 모델이다.
조직 개편이 잦은 스타트업이라면 조직도가 아니라 "제품/서비스 단위"로 서브그룹을 나누는 편이 유지보수가 쉽다. 처음엔 2~3단계로 단순하게 시작하고, 구체적 필요가 생겼을 때만 추가하는 점진적 접근이 권장된다.
¶ 운영의 핵심: 백업과 업그레이드
자체 구축을 결정한 순간부터 백업은 선택이 아니라 필수 운영 업무가 된다. 백업 정책은 다음을 포함해야 한다.
- 배포 빈도에 맞춘 주기 설정
- 별도 스토리지·오프사이트 복제
- 정기적인 복원 리허설
업그레이드는 "필수 업그레이드 정류장" 개념이 있다. 오래된 버전을 방치하다 몰아서 업그레이드하면 리스크가 커지므로, 분기 1회 정도 최신 안정 버전을 따라가는 것이 안전하다.
¶ 라이선스·요금제: Free, Premium, Ultimate
GitLab은 "오픈소스니까 무료"라는 단순화가 통하지 않는다.
| Free 요금제 제약 | 내용 |
|---|---|
| 병합 승인 | 선택 사항일 뿐 강제 불가 |
| Code Owners 강제 | 미지원 |
| 그룹 SAML SSO | 미지원 |
| 에픽/로드맵 | 미지원 |
이 조건들이 깨지기 시작하면 Premium 이상을 검토할 시점이다.
¶ 참고할 만한 사례
하이비젼시스템은 폐쇄망 제조업 환경에서 인포그랩 지원으로 GitLab 자체 구축 및 마이그레이션을 수행했다. GitLab Inc. 자신도 사내 운영용으로 ops.gitlab.net이라는 별도 자체 구축 인스턴스를 운영한다.
¶ 💬 질문이 있으신가요?
아래 댓글로 남겨주세요. 로그인 없이도 바로 남길 수 있습니다.