GitLab — 기초, 기능 및 CI/CD

GitLab이란?

GitLab — MIT 라이선스 하의 완전한 기능을 갖춘 오픈소스 DevOps 플랫폼입니다. 통합을 통해 다양한 서비스를 결합하는 GitHub와 달리, GitLab은 코드 관리와 코드 리뷰부터 CI/CD, 모니터링, 보안, 배포까지 전체 개발 라이프사이클을 위한 단일 도구를 제공합니다. 대부분의 DevOps 작업에 타사 서비스가 필요하지 않습니다.

GitLab의 역사는 2011년 우크라이나 개발자들의 내부 프로젝트로 시작되었습니다. 첫 번째 공개 버전은 2011년 9월에 출시되었고, 2015년 GitLab은 GitLab.com의 첫 번째 프로젝트가 되어 클라우드 호스팅을 시작했습니다. 2017년, GitLab은 고통스럽지만 교훈적인 마이그레이션을 수행했습니다. Azure에서 Google Cloud로의 전체 인프라 이전은 라이브로 진행되었고 일련의 블로그 게시물로 문서화되었습니다.

GitLab의 아키텍처는 세 가지 주요 구성 요소로 이루어져 있습니다: GitLab Rails(Ruby on Rails 웹 애플리케이션), GitLab Shell(SSH를 통한 Git 작업 처리), Gitaly(Git 데이터 액세스용 gRPC 서버). CI/CD는 빌드 서버에 설치되어 격리된 환경(Docker, Kubernetes, VirtualBox)에서 작업을 실행하는 별도 애플리케이션인 GitLab Runner를 통해 제공됩니다.

GitLab CI/CD: 파이프라인과 러너

GitLab CI/CD — 플랫폼의 핵심 장점인 내장형 지속적 통합 및 전달 시스템입니다. GitHub Actions와 달리 GitLab CI/CD는 처음부터 아키텍처에 내장되어 있어 별도 설정이 필요하지 않습니다. 리포지토리 루트에 .gitlab-ci.yml 파일을 추가하기만 하면 모든 프로젝트가 자동으로 CI/CD를 사용할 수 있습니다.

파이프라인은 순차적 또는 병렬로 실행되는 단계로 구성됩니다: build → test → deploy. 각 단계에는 러너에서 실행되는 하나 이상의 작업이 포함됩니다. 단계 내의 작업이 실패하면 전체 단계가 실패로 표시되고, 기본적으로 후속 단계는 실행되지 않습니다. 다음은 모바일 프로젝트의 파이프라인 예시입니다:

# .gitlab-ci.yml
stages:
  - build
  - test
  - deploy

build-android:
  stage: build
  image: openjdk:17-jdk
  script:
    - ./gradlew assembleDebug
  artifacts:
    paths:
      - app/build/outputs/

unit-tests:
  stage: test
  script:
    - ./gradlew testDebugUnitTest

deploy-firebase:
  stage: deploy
  script:
    - firebase appdistribution:distribute app.apk

GitLab Runner는 여러 실행기(Executor)를 지원합니다: Docker(권장), Kubernetes, SSH, VirtualBox, Parallels. 가장 인기 있는 옵션은 각 작업을 별도 컨테이너에서 실행하는 Docker 실행기입니다. 러너는 단일 프로젝트에 특화되거나 전체 그룹의 공유(shared) 러너로 등록할 수 있습니다. GitLab.com은 월 2000분 제한의 무료 공유 러너를 제공합니다.

CI/CD 고급 기능

GitLab CI/CD는 수동 트리거(when: manual), 지연 트리거(when: delayed), 병렬 실행(parallel: 5), 매트릭스, 동적 파이프라인(child pipelines), 다중 레벨 파이프라인(parent-child)을 지원합니다. 이를 통해 모노리포의 각 모듈에 대한 파이프라인을 동적으로 생성하거나 다양한 Android 아키텍처(arm64, x86_64)에 대한 병렬 빌드를 실행하는 등 복잡한 시나리오를 구축할 수 있습니다.

GitLab vs GitHub: 주요 차이점

GitLab과 GitHub — Git 플랫폼 시장의 두 주요 경쟁자이지만, 철학과 아키텍처가 근본적으로 다릅니다. GitHub는 개방형 커뮤니티, 통합 생태계, 소셜 기능(포크, 스타)에 중점을 둡니다. GitLab은 포괄적인 DevOps 사이클에 초점을 맞추며 계획부터 모니터링까지 모든 도구를 즉시 사용할 수 있도록 제공합니다.

주요 아키텍처 차이점: GitLab — 개발자가 전체를 설치하는 단일 모놀리식 애플리케이션입니다. 모든 기능(CI/CD, Container Registry, Security Scanning, Pages)이 내장되어 설치 후 즉시 작동합니다. GitHub는 API를 갖춘 플랫폼으로, 대부분의 기능이 타사 서비스(Travis CI, CircleCI, Jenkins, SonarQube)와의 통합을 통해 구현됩니다. 아래 표는 주요 특징을 비교합니다:

GitLab과 GitHub의 선택은 팀의 필요에 따라 달라집니다. 우선순위가 제로 구성의 빠른 배포와 개방형 커뮤니티라면 GitHub를 선택하세요. 인프라에 대한 완전한 제어, 자체 호스팅 배포, 내장 보안이 필요하다면 GitLab이 더 적합합니다. Stack Overflow 설문조사(2024)에 따르면, 90%의 개발자가 GitHub를, 33%가 GitLab을 사용합니다(종종 두 플랫폼을 동시에).

Self-Managed GitLab: 자체 서버에 설치

Self-Managed GitLab(이전 명칭 On-Premises)을 사용하면 자체 서버에 플랫폼을 설치하고 데이터, 인프라, 가동 시간을 완전히 제어할 수 있습니다. 이는 데이터를 타사 서버에 저장할 수 없는 금융, 정부 기관, 의료 기관 등 규정 준수 요구 사항이 있는 조직에 특히 중요합니다.

GitLab 설치는 Ubuntu, Debian, CentOS 및 Docker를 통해 지원됩니다. 공식 Omnibus 패키지에는 웹 서버(NGINX), 데이터베이스(PostgreSQL), 캐시(Redis), Git 핸들러(Gitaly), 백그라운드 프로세스 등 모든 구성 요소가 포함되어 있습니다. 최소 요구 사항: 최대 100명 팀 기준 4GB RAM과 2 CPU. 부하가 높은 대규모 설치의 경우 구성 요소를 별도 서버에 분할하는 것이 좋습니다.

# Omnibus로 Ubuntu에 GitLab CE 설치하기
curl -LO https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh
sudo bash script.deb.sh

# 패키지 설치
sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

# 상태 확인
sudo gitlab-ctl status
sudo gitlab-ctl tail

Self-Managed GitLab에는 CI/CD 시간 제한이 없습니다. 모든 러너는 조직이 소유하며, 그 성능은 자체 하드웨어에 의해서만 제한됩니다. 또한 리전을 위한 지역 복제(Geo-replication), 감사 로그, IP 차단, 기업 LDAP/SAML 제공업체와의 통합도 사용 가능합니다. GitLab은 매월(22일) 새로운 기능과 보안 수정 사항이 포함된 업데이트를 출시합니다.

GitLab 내장 보안 도구

GitLab의 보안은 플랫폼 수준에 내장되어 있으며 파이프라인의 각 단계에서 작동하는 여러 스캐너를 포함합니다. SAST(Static Application Security Testing)는 애플리케이션을 실행하지 않고 소스 코드의 취약점을 분석하며, Java, Kotlin, Swift, Python, JavaScript 등 15개 이상의 언어를 지원합니다. DAST(Dynamic Application Security Testing)는 실행 중인 웹 애플리케이션을 내부에서 테스트합니다.

추가 도구: Container Scanning은 기본 레이어의 취약점에 대해 Docker 이미지를 검사합니다. Dependency Scanning은 프로젝트 종속성을 분석하고 알려진 CVE에 대해 경고합니다. Secret Detection은 실수로 커밋된 API 키, 비밀번호, 토큰을 찾습니다. Fuzz Testing은 잘못된 데이터로 자동화된 테스트를 수행하여 명확하지 않은 버그를 찾습니다. 모든 스캔 결과는 통합 보안 대시보드에 표시됩니다.

GitLab은 컴플라이언스(Compliance) 도구도 제공합니다. 컴플라이언스 대시보드는 모든 프로젝트의 규정 준수 상태를 표시하고, 감사 이벤트는 관리자와 개발자의 모든 작업을 기록하며, 컴플라이언스 프레임워크는 특정 프로젝트 그룹에 구성 정책을 강제로 적용할 수 있습니다. 이는 엄격한 보안 요구 사항이 있는 엔터프라이즈 환경에서 GitLab을 인기 있는 선택으로 만듭니다.

Container Registry와 Dependency Proxy

GitLab Container Registry — CI/CD와 통합된 내장 Docker 레지스트리입니다. 파이프라인에서 Docker 이미지를 빌드한 후, 환경 변수 CI_REGISTRY와 CI_REGISTRY_USER를 사용하여 즉시 레지스트리에 게시할 수 있습니다. 레지스트리는 pull-through 캐싱, 태깅, 정리 정책, 레지스트리 내 직접 취약점 스캔을 지원합니다.

Dependency Proxy — 외부 레지스트리(Docker Hub, Quay, GCR)의 컨테이너와 이미지에 대한 캐싱 메커니즘입니다. 파이프라인이 ubuntu:latest와 같은 이미지를 요청하면 GitLab이 먼저 캐시를 확인합니다. 이미 이미지가 다운로드된 경우 다시 가져오지 않습니다. 이는 외부 레지스트리의 부하를 줄이고, 파이프라인을 가속화하며, Docker Hub의 속도 제한으로부터 보호합니다.

모바일 개발자를 위해 GitLab은 문서와 테스트 보고서를 호스팅하는 GitLab Pages를 제공합니다. 테스트 실행 후 아티팩트(HTML 보고서, 스크린샷, 로그)를 Pages로 게시하고 QA 팀과 링크를 공유할 수 있습니다. 모든 것이 동일한 GitLab 프로젝트 내에 위치하므로 클라우드 스토리지에 보고서를 업로드하는 것보다 편리합니다.

GitLab API 및 Webhook

GitLab API(REST 및 GraphQL)는 프로젝트, 사용자, 파이프라인, 병합 요청, 레지스트리 등 플랫폼의 모든 리소스에 대한 액세스를 제공합니다. API는 템플릿에서 프로젝트 생성, 리뷰어 지정, 파이프라인 상태 확인 등 자동화에 사용됩니다. Webhook은 push, merge, Issue 생성 등의 이벤트 시 외부 시스템에 HTTP 알림을 보낼 수 있습니다. Webhook은 Mattermost, Slack, Telegram 및 내부 모니터링 시스템과 통합됩니다.

모바일 문서화를 위한 GitLab Pages

GitLab Pages는 리포지토리에서 정적 웹사이트를 자동으로 게시합니다. 모바일 프로젝트의 경우 Pages는 API 문서, 테스트 커버리지 보고서, lint 분석 결과를 호스팅하는 데 유용합니다. 게시는 성공적인 파이프라인 후 자동으로 이루어집니다. .gitlab-ci.yml에 Pages 게시를 포함한 배포 단계를 추가하기만 하면 됩니다. 결과는 https://namespace.gitlab.io/project-name에서 확인할 수 있습니다.