대규모 오픈소스 DevOps: GitLab을 직접 운영하기

laptop screen showing code in a busy room

소스 코드는 거의 모든 기술 회사가 핵심 자산이라는 데 동의하는 유일한 자산이면서, 동시에 대부분의 회사가 자기 소유가 아닌 인프라 위에, 자기가 고르지 않은 관할권 아래, 꼼꼼히 읽지 않은 계약에 따라 보관하고 있는 자산이기도 합니다. 보통은 그 상태로도 괜찮습니다. 그래도 다른 길이 얼마나 드는지 알아 둘 가치는 있습니다. GitLab은 십 년 넘게 개발 수명주기 전체를 직접 호스팅하는 일을 진짜로 실행 가능한 선택지로 만들어 왔기 때문입니다.

이 제품은 또한 무료 등급이 사람들 예상보다 후하고, 운영 부담은 예상보다 무겁습니다. 둘 다 결정하기 전에 이해해 두는 편이 좋으니, 이 글은 자체 운영 GitLab이 실제로 무엇인지, 무료 등급이 진짜로 무엇을 주는지, 그리고 고통의 대부분을 차지하는 세 가지 운영 문제를 다룹니다.

GitLab이란 무엇인가

부가 기능을 덧붙인 Git 호스팅이 아닙니다. Rails 애플리케이션, PostgreSQL, Redis, 저장소 보관을 담당하는 Gitaly, 백그라운드 작업을 처리하는 Sidekiq, 그리고 컨테이너 레지스트리가 하나의 시스템으로 묶여 버전 관리, 코드 리뷰, 이슈 추적, CI/CD, 패키지 및 컨테이너 레지스트리, 보안 스캔, 배포까지 아우릅니다.

이 폭이 곧 전체 논지입니다. GitHub 더하기 Actions 더하기 Dependabot 더하기 패키지 레지스트리 더하기 프로젝트 추적기는 비슷한 기능 묶음을 만들어 내지만, 그것은 부품을 조립한 결과입니다. GitLab은 하나의 애플리케이션이고 권한 모델도 하나, 데이터베이스도 하나입니다. 그것은 정확히 원하는 바이거나, 필요 이상이거나 둘 중 하나이고, 어느 쪽인지는 수명주기의 얼마만큼을 실제로 한곳에서 돌릴 생각인지에 달려 있습니다.

아키텍처 측면에서 중요한 사실은 Matomo로 분석을 직접 운영하는 것, Mautic으로 마케팅 자동화를 직접 운영하는 것, Mattermost로 팀 메신저를 직접 운영하는 것과 같습니다. 여러분이 둔 곳에서 돌아갑니다. 여러분의 저장소, 여러분의 CI 로그, 여러분의 산출물, 여러분의 데이터베이스입니다.

라이선스 상황, 있는 그대로

이 대목은 정말로 헷갈리고 정확할 가치가 있습니다. 혼란이 사람들이 예상하는 것과 반대 방향으로 흐르기 때문입니다.

소스 배포판은 둘입니다. Community Edition은 MIT 라이선스입니다. Enterprise Edition은 저장소의 ee/ 디렉터리에 적용되는 더 제한적인 자체 라이선스를 갖습니다. 여기까지는 흔한 오픈 코어 구도로 들립니다.

놀라운 부분은 이겁니다. 거의 모두가 설치하는 리눅스 패키지는 Enterprise Edition 빌드이고, 라이선스 키를 넣지 않으면 Free 등급으로 동작하며 Community Edition처럼 행동합니다. 즉 의도적으로 CE 패키지를 고르지 않았다면 MIT 라이선스 배포판을 돌리고 있는 것이 아닙니다. 실무에서는 이것이 문제가 되는 일이 드물지만, 자체 호스팅의 이유가 데이터 통제가 아니라 엄격한 오픈소스 정책이라면 대단히 중요해집니다. 그런데 확인하는 사람이 거의 없습니다.

상용 등급은 Free, 연간 청구 기준 사용자당 월 29달러의 Premium, 그리고 개별 견적인 Ultimate입니다. Premium은 고급 CI/CD, 더 나은 프로젝트 관리, 우선 지원을 더합니다. Ultimate은 보안과 컴플라이언스 묶음을 더합니다. 애플리케이션 보안 테스트, 공급망 보안, 의존성 스캔입니다. 두 유료 등급 모두 이제 AI 기능용 GitLab Credits를 포함하며, Premium은 사용자당 월 12달러, Ultimate은 24달러입니다.

그리고 대부분의 팀에게 계산을 바꾸는 사실이자 Mattermost 상황의 정확한 반대가 여기 있습니다. 자체 운영의 Free 등급에는 사용자 수 제한이 없습니다. 사람들이 들어 본 다섯 사용자 상한은 GitLab.com의 비공개 그룹에만 적용됩니다. 자체 호스팅에서 Free는 무제한 사용자, 버전 관리, CI/CD, 레지스트리를 주고, 스토리지와 러너는 여러분이 가져옵니다. 엔지니어 백 명 규모 조직도 전부 그 위에서 돌아갈 수 있습니다.

포기하는 것은 보안 스캔, 컴플라이언스 보고, 고급 승인 규칙, 그리고 지원입니다. 사이버 복원력 법의 적용을 받고 의존성 스캔과 SBOM 생성을 별도 도구로 조립하는 대신 파이프라인에 내장하고 싶다면 그건 Ultimate 이야기입니다. 다른 대부분의 팀에게 Free는 체험판이 아닙니다. 지속 가능한 영구적 답입니다.

설치하기

소규모 구성

GitLab은 보이는 것보다 무겁습니다. 단일 노드에 대해 문서화된 기준은 8 vCPU와 16GB 메모리이고, 대다수 벤더 최소 사양과 달리 이 숫자는 낙관적이지 않고 정직합니다. 8GB에 밀어 넣을 수도 있지만 체감이 되고, 스왑은 꺼 두는 편이 낫습니다. 이 애플리케이션을 스왑시키는 것은 메모리가 아예 없는 것보다 나쁘기 때문입니다.

PostgreSQL이 유일하게 지원되는 데이터베이스입니다. 어느 버전인지는 GitLab 버전에 달려 있습니다. 17.x는 PostgreSQL 14.14부터 16.x까지, 18.x는 16.5부터 17.x까지, 19.x는 17.x를 요구합니다. Redis는 7.2 권장에 7.0이 최소이며, Valkey 7.2도 대체로 쓸 수 있습니다. 독립 인스턴스만 지원되며, Redis의 클러스터 구성과 서버리스 변형은 지원되지 않습니다.

리눅스 패키지로 설치하십시오. Helm 차트, Operator, Docker 이미지, 소스 빌드 경로도 있지만 리눅스 패키지가 가장 성숙한 선택지이고 GitLab.com 자신이 돌아가는 것도 이것입니다. PostgreSQL, Redis, Sidekiq을 함께 담고 있어서 머신 한 대와 설정 파일 하나면 동작하는 인스턴스가 나옵니다.

# /etc/gitlab/gitlab.rb
external_url 'https://git.example.com'

# Let's Encrypt, on by default when external_url is https
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['ops@example.com']

# Keep Puma and Sidekiq honest on a small box
puma['worker_processes'] = 2
sidekiq['max_concurrency'] = 9

# Move artefacts and uploads off local disk early
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-central-1',
  'aws_access_key_id' => 'REPLACE_ME',
  'aws_secret_access_key' => 'REPLACE_ME'
}

gitlab-ctl reconfigure 한 번이면 인스턴스가 생깁니다. external_url은 처음부터 제대로 설정하십시오. 이 값은 클론 URL, 웹훅, 레지스트리 주소에 그대로 박힙니다.

운영 구성

GitLab은 1,000명부터 50,000명까지의 참조 아키텍처를 공개하는데, 하나도 구현하지 않더라도 읽어 볼 가치가 있습니다. 어떤 구성 요소가 가장 먼저 병목이 되는지 보여 주기 때문입니다.

돈을 가장 많이 아껴 주는 조언은 GitLab 자신에게서 나오고, 복잡성에 반대합니다. 3,000명 미만이면 고가용성보다 탄탄한 백업 전략을 권합니다. 문서는 이 점에서 유난히 솔직해서, 백업 방식이 복구 시간은 더 느리지만 훨씬 작은 아키텍처와 더 낮은 유지 비용을 뜻한다고 적어 두었습니다. 3,000명을 넘거나 장애가 실제로 회사를 멈춰 세우는 곳이라면 고가용성이 권고가 됩니다.

이 말은 진지하게 받아들일 만합니다. 백업이 잘 되어 있고 복구를 시험해 본 단일 노드가, 절반만 이해한 고가용성 클러스터보다 실무에서 더 믿을 만하고 훨씬 저렴합니다.

산출물, 업로드, LFS 객체, 레지스트리 이미지는 처음부터 오브젝트 스토리지로 옮기십시오. 다른 데서와 같은 논리입니다. 노드를 무상태로, 백업을 감당 가능하게, 이전을 가능하게 유지해 줍니다.

어긋나는 세 가지

여기까지는 모두 문서에 있습니다. 아래가 사고를 만들어 내는 부분입니다.

백업 안에 그것을 복호화할 것이 없다

이 글에서 가장 중요한 문단입니다.

gitlab-backup create는 꽤 많은 것을 담습니다. 데이터베이스, 저장소, LFS 객체, CI 산출물과 작업 로그, 레지스트리 이미지, 위키, 업로드, Pages 콘텐츠, Terraform 상태, 스니펫. 담지 않는 것은 설정 디렉터리이고, 구체적으로는 /etc/gitlab/gitlab-secrets.json입니다.

이 파일이 데이터베이스 암호화 키를 갖고 있습니다. 문서는 그 결과에 대해 단호합니다. 이 파일을 잃으면 GitLab 애플리케이션은 데이터베이스의 어떤 암호화된 값도 복호화할 수 없게 됩니다. CI/CD 변수, 토큰, 이중 인증 비밀, 연동 자격 증명이 여기 해당합니다. 복원은 되지만 자기 비밀을 읽지 못하는 인스턴스가 만들어지는 셈입니다.

역시 빠지는 것들: /etc/gitlab/gitlab.rb, TLS 키와 인증서, SSH 호스트 키, 그리고 오브젝트 스토리지를 설정했을 때 그 안의 내용물. 마지막 항목은 아키텍처적으로 옳은 선택을 해 놓고 백업이 그것까지 덮는다고 넘겨짚은 사람들을 정확히 붙잡습니다.

그러니 /etc/gitlab은 따로 백업하고, 아카이브 옆이 아닌 다른 곳에 보관하십시오. 그것이 그 아카이브의 열쇠이기 때문입니다. 그런 다음 전체를 일회용 머신에 복원해서 로그인이 되는지, CI 변수를 읽을 수 있는지 확인하십시오. 시험해 보지 않은 백업은 백업이 아니고, GitLab에서는 시험해 보지 않은 복원은 대개 망가진 복원입니다.

한 번에 건너뛰어 업그레이드할 수 없다

GitLab에는 필수 업그레이드 경유 지점이 있고, 이는 권고가 아닙니다. 건너뛸 수 없습니다. 17.5부터 경유 지점은 예측 가능하게 x.2, x.5, x.8, x.11에 놓입니다. 따라서 18.0에서 19.2로 가려면 도중에 18.2, 18.5, 18.8, 18.11, 19.0을 지나야 합니다.

각 경유 지점에는 백그라운드 마이그레이션이 딸려 있고, 다음으로 넘어가기 전에 완전히 끝나야 합니다. 마이그레이션이 아직 돌고 있는데 다음 업그레이드를 시작하는 것이야말로 인스턴스가 지원팀만 풀 수 있는 상태에 빠지는 경로입니다. 큰 인스턴스에서는 이 마이그레이션이 몇 시간씩 걸릴 수 있습니다.

실무적 결론은 둘입니다. 정기적으로 올리십시오. 일 년 미룬 업그레이드는 연달아 올리는 주말이 됩니다. 그리고 목표 마이너 버전의 첫 패치가 아니라 최신 패치 릴리스를 받으십시오. 문서가 명시적으로 그렇게 말합니다. GitLab은 업그레이드 경로를 계산해 주는 도구를 유지하고 있고, 직접 따져 보는 것보다 그것을 쓰는 편이 낫습니다.

진짜 비용은 러너에 있다

GitLab 서버는 여러분의 CI를 실행하지 않습니다. GitLab Runner는 여러분이 설치하고 설정하고 비용을 대는 별도 구성 요소이며, 인프라도 여러분이 제공합니다. 자체 운영 Free에는 컴퓨팅 분이 전혀 포함되지 않습니다. 줄 수 있는 포함 연산 자원이 아예 없기 때문입니다. 머신은 여러분이 가져옵니다.

보통은 좋은 거래입니다. 물량이 진지해지면 전용 러너가 어떤 호스팅 CI보다 분당 비용이 싸고, 빌드마다 필요한 하드웨어를 붙여 줄 수 있습니다. 하지만 이건 진짜 인프라 작업입니다. 실행기를 shell로 할지 Docker로 할지 Kubernetes로 할지, 새벽 세 시에 러너가 놀고 있지 않도록 오토스케일링을 어떻게 할지, 그리고 4분짜리 파이프라인과 14분짜리 파이프라인을 가르는 캐싱을 어떻게 할지 결정하게 됩니다.

러너 무리는 별도 예산 항목으로 잡으십시오. 자체 호스팅 비용을 GitLab 노드만 보고 계산하는 팀은 크게 과소평가하고, 그 차이를 대기 중인 작업 줄로 발견하게 됩니다.

GitHub에서 옮겨 가기

GitHub 임포터는 좋고, 대부분의 벤더 이전 도구보다 훨씬 낫습니다. 저장소 데이터, 브랜치, LFS 객체, 이슈와 풀 리퀘스트를 댓글과 리뷰, 토론 답글까지, 위키 페이지, 릴리스와 첨부, 라벨, 마일스톤, 브랜치 보호 규칙, 역할 매핑을 포함한 협업자를 가져옵니다.

문서화된 빈틈은 미리 계획해 두는 게 좋습니다. 조직과 그룹은 넘어오지 않으므로 그룹 구조는 물려받는 대신 직접 설계하게 되는데, 대개는 개선입니다. GitHub Actions 워크플로는 GitLab CI로 변환되지 않습니다. 2017년 이전 풀 리퀘스트 댓글은 GitHub API 제약 때문에 별도 스레드로 들어오고, 댓글이 대략 3만 개를 넘는 저장소는 대체 댓글 가져오기 방식을 켜야 합니다.

GitHub은 이슈와 풀 리퀘스트에 모두 #을 쓰는데 GitLab은 둘을 구분하므로, 일부 상호 참조는 해석되지 않습니다. 잃는 것은 없지만 오래된 토론의 링크가 엉뚱한 곳을 가리킬 수 있습니다.

CI 재작성을 진짜 프로젝트로 잡고 계획하십시오. 실제로 그렇습니다. 나머지는 돌려 보고 확인하면 되는 가져오기 작업입니다.

유럽 관점

유럽에서 사업하는 기업에게는 비용 위에 컴플라이언스 차원이 얹힙니다. 소스 코드, 빌드 파이프라인, 산출물은 기술 회사가 보유한 것 중 가장 민감한 축에 들고, 그것들이 어디에 사는지는 점점 여러분이 답하기로 선택하는 질문이 아니라 받게 되는 질문이 되고 있습니다.

자체 호스팅은 그것들을 여러분이 통제하는 경계 안에 둡니다. 이는 GDPR의 이전 분석과 NIS2의 공급망 질문을 한 번에 단순하게 만들고, 클라우드 및 AI 개발법이 그 둘레에 세워진 것과 같은 주권 논리이기도 합니다.

더 날카로운 연결은 사이버 복원력 법입니다. EU 시장에 소프트웨어를 내놓는다면 의존성 목록, 취약점 처리, 조율된 공개 절차가 필요합니다. 이 의무들은 문서가 아니라 빌드 파이프라인 안에서 충족되며, 파이프라인과 레지스트리와 스캔이 여러분이 운영하는 하나의 시스템에 있으면 증거를 만들어 내는 일이 네 개 벤더에서 그러모으는 것보다 훨씬 덜 고통스럽습니다.

굳이 하지 않아도 될 때

엔지니어가 스무 명 미만이고 규제 압력도 없고 코드가 어디 사는지에 대해 아무도 강한 의견이 없다면 SaaS를 쓰십시오. GitLab.com과 GitHub 모두 훌륭하고, 운영 작업이 구독료보다 비쌉니다.

조직이 GitHub 생태계에 깊이 들어가 있다면 무엇을 잃을지 정직하게 세어 보십시오. Actions, 마켓플레이스, 그리고 채용하는 모든 후보자에게 익숙하다는 사실 자체가 실제 자산이고, 답이 자동으로 GitLab의 승리가 되지는 않습니다.

그리고 아무도 그 인스턴스를 떠맡지 않을 거라면 시작하지 마십시오. GitLab은 패치를 적용하고 러너 무리를 지켜보고 복원을 시험하는 사람에게 보답합니다. 그 사람이 없으면 가장 값진 자산을 담은 채 패치되지 않은 상자로 퇴락하고, 그것은 떠나려 했던 SaaS보다 나쁩니다.

도움이 필요하시면

우리는 유럽에서 사업하는 기업을 위해 자체 호스팅 개발 인프라를 구축하고 운영합니다. 필수 경유 지점을 지나는 업그레이드 순서, 제대로 오토스케일되는 러너 무리, 오브젝트 스토리지로의 이전, 실제로 복원해 본 백업 설계처럼 아무도 즐기지 않는 부분까지 포함해서입니다.

정직하게 크기를 잡은 GitLab 인스턴스, CI 재작성을 해 본 사람이 계획하는 GitHub 이전, 혹은 현재 백업이 진짜 장애를 견딜지에 대한 점검이 필요하시면 office@c9group.dev로 연락 주십시오. 인프라 작업에 관해서는 AWS 비용 최적화 페이지를 참고하십시오.

자체 호스팅 스택을 통째로 꾸리신다면 같은 논리가 분석, 마케팅 자동화, 팀 메신저에도 적용됩니다.

게시일: 2026년 8월 8일 카테고리: DevOps, 오픈소스, 개인정보 보호