GitLab Premium 쓰면서도 Java 빌드가 느려 터지는 진짜 이유와 해결책

비싼 GitLab Premium, 뽕을 뽑고 계십니까

회사에서 인당 한 달에 수십 달러씩 주고 GitLab Premium 라이선스를 끊어줬을 때 보통 두 가지 반응이 나옵니다. "우와 기능 많다" 하고 좋아하거나, 쓰던 기능(단순 Git Push, Merge Request)만 주구장창 쓰거나. 솔직히 후자가 80% 이상입니다. 특히 Java 기반 스프링 부트 프로젝트를 운영하는 환경에서 Premium의 핵심인 고급 CI/CD 기능과 보안 스캔을 제대로 녹여내지 못하면, 그 비용은 그냥 허공에 날리는 셈입니다.

 

Java는 빌드 속도도 느리고 컨테이너 이미지 용량도 무겁습니다. 여기에 Premium 기능인 의존성 스캔(Dependency Scanning)이나 정적 분석(SAST)까지 기본 파이프라인에 대책 없이 욱여넣으면 배포 한 번에 20~30분씩 걸리는 지옥을 맛보게 됩니다. 개발자들은 답답해서 CI/CD를 건너뛰고 싶어 하겠죠. 비싼 돈 주고 산 프리미엄 툴이 오히려 개발 생산성을 갉아먹는 상황, 이걸 어떻게 해결해야 할지 실무 관점에서 다뤄보겠습니다.

Premium 기능을 살린 효율적인 3단계 파이프라인 설계

실무에서 통하는 Java 프로젝트용 파이프라인은 무작정 다 실행하는 구조가 아닙니다. 스테이지를 촘촘하게 쪼개고, 캐시와 Premium의 병렬 처리 기능을 극한으로 끌어써야 합니다. 전체적인 구조는 검증, 빌드 및 스캔, 배포의 3단계 템플릿으로 접근합니다.

stages:
 * test
 * build_and_scan
 * deploy
variables:
GRADLE_OPTS: "-Dorg.gradle.daemon=false"
CI_DEBUG_TRACE: "false"
cache:
key:
files:
- build.gradle
paths:
- .gradle/caches/
- .gradle/wrapper/

Java 환경에서 가장 중요한 게 이 cache 설정입니다. build.gradle이 바뀔 때만 캐시 키를 갱신하도록 설정해야 무의미한 라이브러리 다운로드 시간을 줄일 수 있습니다. 이거 설정 안 하면 매 빌드마다 몇백 메가씩 되는 Spring 의존성을 새로 받느라 파이프라인이 기어 다닙니다.

대형 서버 랙과 인프라 장비 - 생성형 ai 이미지

실무에서 바로 쓰는 .gitlab-ci.yml 전체 스크립트

GitLab Premium에서 제공하는 템플릿을 포함하여, Java 빌드와 컨테이너화, 그리고 보안 취약점 분석까지 한 번에 처리하는 실전 스크립트입니다.

include:
 * template: Security/SAST.gitlab-ci.yml
 * template: Security/Dependency-Scanning.gitlab-ci.yml
sast:
stage: build_and_scan
artifacts:
reports:
sast: gl-sast-report.json
dependency_scanning:
stage: build_and_scan
artifacts:
reports:
dependency_scanning: gl-dependency-scanning-report.json
unit_test:
stage: test
image: amazoncorretto:17-alphine-jdk
script:
- ./gradlew test
artifacts:
reports:
junit: build/test-results/test/TEST-*.xml
build_image:
stage: build_and_scan
image: docker:24.0.7
services:
- docker:24.0.7-dind
script:
- ./gradlew bootJar
- docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
- docker build -t $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA .
- docker push $CI_REGISTRY_IMAGE:$CI_COMMIT_SHA
rules:
- if: $CI_COMMIT_BRANCH == "main"

Premium 라이선스를 쓰면 include 구문 한 줄로 GitLab이 관리하는 최신 보안 스캔 템플릿을 가져올 수 있습니다. 별도의 소나큐브(SonarQube) 서버를 관리하는 리소스와 비용을 생각하면, 이 기본 내장 스캔 기능이 의외로 가성비가 좋습니다. 결과는 Merge Request 화면에 바로 대시보드로 꽂히기 때문에 코드 리뷰할 때 보안 취약점을 즉시 걸러낼 수 있죠.

Premium 보안 스캔 도입하면 진짜 빌드 속도가 느려지나요?

네, 확실히 느려집니다. 아무리 솔루션이 좋아도 정적 분석과 바이너리 스캔 과정에서 CPU와 메모리를 무지막지하게 잡아먹습니다. 특히 무거운 Java 프레임워크인 Spring Boot는 분석 대상 파일이 많아서 더 심합니다. 무료 플랜처럼 단일 러너(Runner)에서 순차적으로 돌리면 배포 주기가 마비됩니다.

 

이를 극복하려면 Premium의 장점인 다중 러너 할당과 스키핑(Skipping) 전략을 써야 합니다. 매 커밋마다 보안 스캔을 돌리는 짓은 지양해야 합니다. 내부 개발용 브랜치에서는 단순 유닛 테스트와 빌드만 수행하고, 마스터(main) 브랜치로 합쳐지는 Merge Request 단계나 야간 배포(Nightly Build) 시점에만 보안 스캔이 발동하도록 rules 조건을 촘촘하게 제어하는 것이 실무적인 타협점입니다.

운영 환경에서 무조건 겪는 트래픽 병목과 실패 패턴

CI/CD 파이프라인을 구축하고 나면 끝난 것 같지만, 실제 운영계에 적용하는 순간 예상치 못한 장애 포인트들이 터져 나옵니다. 자바 스프링 프로젝트 배포 시 가장 자주 넘어지는 3가지 징후를 정리했습니다.

• Docker in Docker (DinD) 메모리 고갈: 이미지를 빌드하는 러너의 메모리가 부족하면 Gradle 빌드 도중 소리 소문 없이 Exit Code 137을 뱉으며 죽습니다. 자바 빌드 프로세스(OpenJDK)가 먹는 메모리와 닥커 데몬이 먹는 메모리의 합을 계산해서 러너의 스펙을 여유 있게 잡아야 합니다.
• 의존성 다운로드 타임아웃: 넥서스(Nexus) 같은 사내 사설 저장소를 안 쓰고 메이븐 센트럴에서 매번 라이브러리를 긁어오다 보면, 네트워크 회선 문제나 일시적인 차단으로 빌드가 터집니다. 캐시 설정은 선택이 아니라 필수입니다.
• Merge Request 승인 병목: Premium 기능인 'Protected Branches'와 'Merge Request Approvals'를 걸어두면 보안상 좋긴 합니다. 하지만 승인권자가 자리를 비우면 긴급 핫픽스 배포가 불가능해지는 역효과가 납니다. 비상시 우회할 수 있는 '코드 오너(Code Owners)' 규칙을 반드시 다중화해 두어야 합니다.

결국 어떤 선택을 해야 하는가?

GitLab Premium은 분명 좋은 도구지만 명확한 트레이드오프가 존재합니다. 보안 스캔과 강력한 권한 제어를 얻는 대신, 러너 인프라 유지 비용이 늘어나고 파이프라인 최적화를 위한 공수가 끊임없이 들어갑니다.

 

팀 규모가 작고 굳이 꼼꼼한 컴플라이언스 준수가 필요 없다면 기본 기능으로도 차고 넘칩니다. 하지만 관리해야 하는 마이크로서비스(MSA)가 늘어나고, 코드 한 줄의 취약점이 서비스 전체의 치명타로 이어지는 비즈니스를 하고 있다면 Premium의 보안 파이프라인을 제대로 내재화하는 것이 장기적으로 장애 대응 난이도와 유지보수 피로도를 낮추는 확실한 길입니다. 먼저 현재 팀의 배포 빈도와 러너 인프라 스펙을 점검해 보시기 바랍니다.

 

[백엔드 아키텍처] 아침마다 빌드가 멈춘다면? Artifactory Enterprise로 트래픽 병목 끝내기