¶ 21권 — GitLab 자체 구축 기반 CI/CD 구성하기
← 시리즈 로드맵 목차 · ↔ 7권과 짝을 이루는 심화 트랙
자체 구축한 GitLab 위에서 GitLab CI로 SaaS형 GitHub Actions가 해 주던 역할을 어떻게 재현·확장할지를 다룬다. SaaS를 쓸 때는 신경 쓸 필요 없던 Runner 인프라 설계·확장·튜닝까지 팀이 직접 감당해야 한다는 것이 자체 구축 CI/CD의 핵심 차이다.
¶ GitLab CI/CD의 기본 구조: 파이프라인, 스테이지, 잡
.gitlab-ci.yml로 정의되는 파이프라인은 stages로 실행 순서를 정하고, 같은 스테이지의 잡은 병렬로 실행된다.
needs 키워드는 잡이 스테이지 순서를 따르지 않고 특정 상위 잡에만 의존하는 DAG 실행을 가능하게 한다. 이를 통해 독립적인 빌드 흐름을 동시에 진행시켜 전체 파이프라인 시간을 줄일 수 있다.
¶ Runner 설치·등록과 Executor 선택
Runner는 GitLab CI/CD와 함께 동작하며 실제 잡을 실행하는 애플리케이션이다. 가장 중요한 결정은 Executor 선택이다.
| Executor | 특징 | 적합한 상황 |
|---|---|---|
| Kubernetes | 잡마다 Pod를 생성하는 클라우드 네이티브 방식 | 쿠버네티스 운영 역량이 있는 팀 |
| Docker | 컨테이너 기반의 깨끗한 빌드 환경 | 컨테이너 재현성이 중요하고 부하가 예측 가능한 경우 |
| Shell | — | 간단한 소규모 팀의 시작점(중장기적으로는 Docker 계열 전환 권장) |
¶ 파이프라인 설계와 배포 자동화
실전 파이프라인은 build→test→deploy 스테이지에 조건을 걸고, 프로덕션 배포처럼 되돌리기 어려운 잡에는 수동 승인 단계를 두는 것이 자체 구축 환경에서 특히 중요한 관행이다.
프로젝트/팀이 늘어나면 include 키워드로 외부 YAML을 조합해 언어별 공통 잡을 공유 저장소에서 관리한다.
¶ 쿠버네티스 배포 연동: Registry에서 ArgoCD까지
커밋 하나가 클러스터에 반영되는 전체 경로는 다섯 단계다.
- 이미지 빌드: 데몬리스 도구(Buildah·Podman)가 현재 권장 대안이다.
- 이미지 태그:
latest대신 커밋 SHA 기반 불변 태그를 써야 롤백·추적이 가능하다. - Container Registry: GitLab이 프로젝트별로 내장 제공한다.
- Helm Chart 패키징: 애플리케이션을 Helm Chart로 패키징한다.
- ArgoCD 연동: ArgoCD가 Git 저장소의 차트를 참조하도록 설정한다.
¶ 빌드 캐시로 파이프라인 속도 개선하기
캐시와 아티팩트는 서로 다른 문제를 푼다.
| 구분 | 역할 |
|---|---|
| 캐시 | 의존성을 Runner에 저장해 파이프라인 간 재사용 |
| 아티팩트 | 스테이지 간 산출물 저장 |
Runner가 고정 한두 대뿐이면 로컬 캐시로 충분하다. 오토스케일링을 쓰거나 쓸 계획이라면 캐시 도입과 동시에 분산 캐시를 설계해야 한다.
¶ 안정성 튜닝 체크리스트와 핵심 원칙
.gitlab-ci.yml은 애플리케이션 코드만큼 파급 범위가 넓은 로직이므로, 별도 브랜치·MR 리뷰·CI Lint 검증을 거쳐 병합해야 한다. 공유 템플릿은 버전 태그로 각 프로젝트가 원하는 시점에만 업그레이드하게 해야 한다.
¶ 참고할 만한 사례
국내에서는 다나와가 Kubernetes 기반 Shared Runner 하나로 여러 프로젝트의 빌드·배포를 통합 운영했고, 해외에서는 Goldman Sachs가 GitLab CI/CD 도입 후 릴리스 주기를 1~2주에서 몇 분 단위로 단축했다.
¶ 💬 질문이 있으신가요?
아래 댓글로 남겨주세요. 로그인 없이도 바로 남길 수 있습니다.