74. 깃랩 CI (GitLab CI/CD) - .gitlab-ci.yml 활용

⚠️ 이 문서는 코드 저장소(Git)와 CI/CD 배포 엔진(Jenkins)을 억지로 이어 붙여 써야 했던 과거의 분절된 인프라 환경을 혁파하고, **소스코드 저장소 그 자체인 깃랩(GitLab)이 뱃속에 강력한 CI/CD 로봇(Runner)을 내장하여, 폴더에 .gitlab-ci.yml 스크립트 하나만 넣어두면 코드를 올리는 즉시 빌드부터 배포까지 원스톱으로 끝내버리는 통합형 데브옵스 플랫폼인 'GitLab CI/CD'**를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 젠킨스를 버리게 만든 주범 중 하나다. 깃랩(GitLab)은 단순한 소스코드 저장소(GitHub의 대체재)로 출발했지만, CI/CD 엔진을 자체적으로 완벽히 내재화(Built-in)하여 "저장소 + 파이프라인 + 이슈 트래커"를 하나로 묶은 괴물 플랫폼이 되었다.
  2. 가치: 개발자가 외부 젠킨스 화면에 로그인할 필요 없이, 평소 작업하던 깃랩 소스코드 화면 안에서 배포가 10% 진행 중인지 100% 완료되었는지, 어디서 에러가 났는지 파이프라인 그래프를 한눈에 모니터링할 수 있어 극강의 개발자 경험(DX)을 선사한다.
  3. 기술 체계: 프로젝트 최상단 루트에 .gitlab-ci.yml 이라는 YAML 포맷의 파일을 텍스트로 작성하여 Stages(단계)와 Jobs(작업)를 선언하는 완벽한 Pipeline as Code (PaC) 철학을 따른다.

Ⅰ. 파편화된 데브옵스 도구들의 한계와 깃랩의 융합

도구가 3개면, 장애를 추적해야 할 포인트도 3배가 된다.

  1. 프랑켄슈타인 툴체인 (Toolchain)의 피로감:
    • 전통적인 팀은 코드는 GitHub이나 Bitbucket에 올리고, 빌드는 Jenkins 서버를 따로 사서 돌리고, 배포는 AWS CodeDeploy로 하고, 에러 알림은 Slack으로 받았다.
    • 코드를 푸시했는데 젠킨스 웹훅(Webhook)이 끊겨서 빌드가 안 돌면, 개발자는 깃허브, 젠킨스, AWS를 번갈아 가며 로그인해서 어디서 선이 끊어졌는지 디버깅하느라 하루를 날렸다.
  2. GitLab CI/CD의 파괴력 (Single Application):
    • 깃랩은 "이거저거 깔지 말고 그냥 내 안에서 다 해라!"라고 선언했다.
    • 내가 짠 소스코드(Commit) 탭을 클릭하면 바로 옆 화면에 그 코드가 지금 컴파일 중인지 파이프라인 막대기(Pipeline Graph)가 초록색으로 스르륵 차오르는 것이 실시간으로 보인다.
    • 보안 검사(SAST) 결과부터 배포 성공 여부까지 단 하나의 플랫폼, 단 하나의 화면(UI)에서 통제되는 완벽한 원스톱(One-stop) 데브옵스의 표준이 되었다.

📢 섹션 요약 비유: 옛날엔 자동차(앱)를 만들려면 1공장에서 엔진을 깎고 트럭에 실어 2공장에 보내 조립하고 다시 3공장에 보내 도색을 해야 했습니다(파편화된 CI/CD 툴체인). 깃랩 CI는 자재를 쏟아 넣으면(Push), 한 지붕 아래에 있는 컨베이어 벨트를 쭉 타고 흘러가(Pipeline) 완제품 자동차가 바로 튀어나오는 완벽한 수직 계열화(일체형) 메가 팩토리입니다.

Ⅱ. .gitlab-ci.yml 파일의 해부학

어떻게 배포할지는 이 텍스트 파일 한 장에 모든 것이 담겨있다.

  1. YAML 기반의 파이프라인 애즈 코드 (PaC):
    • 젠킨스에 Jenkinsfile이 있다면, 깃랩에는 .gitlab-ci.yml이 있다.
    • 이 파일을 깃랩 저장소 최상단에 올려두는 순간, 깃랩 로봇(Runner)이 이 파일을 냄새 맡고 깨어나 배포를 시작한다.
  2. Stages와 Jobs의 논리적 계층:
    • Stages: 전체 파이프라인의 '순서(단계)'다. (예: build, test, deploy)
    • Jobs: 그 단계 안에서 실제로 돌아갈 톱니바퀴들이다.
    stages:
  - build
  - test

job_build_app:     # 첫 번째 Job (사용자 정의 이름)
  stage: build     # 이 Job은 build 단계에서 뛴다
  script:
    - echo "컴파일을 시작합니다."
    - npm run build
  3. Artifacts (전리품 전달):
    • 빌드(Build) 단계에서 컴파일된 .jar 실행 파일이나 빌드된 dist 폴더를 다음 단계인 테스트(Test)나 배포(Deploy) 단계로 넘겨줘야 한다.
    • 이때 artifacts 키워드를 써서 "이 파일은 안 버리고 다음 방(Job)으로 무사히 토스해 줘!"라고 명시하는 기법이 핵심이다.

📢 섹션 요약 비유: .gitlab-ci.yml 파일은 공장 반장님께 드리는 엑셀 작업 지시서입니다. 윗줄(Stages)에는 "1. 재단, 2. 조립, 3. 포장" 순서를 적고, 아랫줄(Jobs)에는 "재단 단계에서는 가위를 써라(script), 조립 단계에서는 드라이버를 써라"라고 구체적 행동을 적습니다. 재단이 끝나고 남은 천 쪼가리를 다음 방으로 넘겨주는 서류 봉투가 바로 Artifacts입니다.

Ⅲ. 깃랩 런너 (GitLab Runner)와 캐싱 (Caching) 최적화

지시서(YAML)가 있다면, 그 지시를 행동으로 옮길 '몸통(컴퓨터)'이 필요하다.

  1. GitLab Runner (명령 실행기):
    • 깃랩 중앙 서버가 직접 수천 명의 코드를 빌드하다간 CPU가 터져 죽는다.
    • 그래서 깃랩은 지시서(.yml)만 분석하고, 실제 망치질(빌드 스크립트 실행)은 외부 클라우드나 사내 서버에 몰래 띄워둔 수많은 **'깃랩 런너(GitLab Runner)'**라는 꼬봉 프로그램들에게 외주를 던진다.
    • 이 런너들은 보통 도커(Docker) 컨테이너로 띄워져 있어서, 배포가 끝나면 흔적도 없이 사라지는 깔끔한 격리 환경을 제공한다.
  2. Shared Runner vs Specific Runner:
    • 깃랩 클라우드(SaaS)에서 무료로 빌려주는 공용 컴퓨터(Shared)를 쓸 수도 있고, "우리 회사 코드는 유출되면 안 되니 우리 회사 전산실 서버(Specific Runner)에서만 빌드 쉘을 돌려라!"라고 지정할 수도 있어 폐쇄망 보안에도 완벽히 대응한다.
  3. 캐싱(Cache)을 통한 속도 극대화:
    • 매번 빌드할 때마다 1GB짜리 node_modules (의존성 패키지)를 인터넷에서 처음부터 다운받으면 배포에 10분이 걸린다.
    • .gitlab-ci.yml 파일에 cache: 옵션을 세팅하면, 어제 다운받은 패키지 폴더를 쓰레기통에 안 버리고 창고에 몰래 숨겨뒀다가(Caching) 오늘 빌드할 때 1초 만에 다시 꺼내 써서 파이프라인 속도를 로켓처럼 끌어올려 준다.

📢 섹션 요약 비유: 깃랩(중앙 플랫폼)은 파이프라인을 기획하는 똑똑한 머리(CEO)일 뿐이고, 실제로 무거운 삽질(명령어 실행)을 하는 땀 흘리는 일꾼들의 정체는 서버 어딘가에 깔려있는 '깃랩 런너(GitLab Runner)'들입니다. 이 런너들이 매일 아침 공구통(의존성 라이브러리)을 새로 사 오지 않고 사물함(Cache)에 넣어뒀다가 내일 또 꺼내 쓰는 꼼수를 부려야만 야근 없이 배포 속도를 맞출 수 있습니다.