GitLab CI에서 anchors와 artifacts 제대로 이해하기

DevSecOps 실무에서 .gitlab-ci.yml 파일을 다루다 보면 반복적인 설정을 줄이고, 빌드 결과물을 효율적으로 관리하기 위해 anchors와 artifacts 키워드를 자주 활용하게 됩니다. 이 글에서는 이 두 키워드의 개념부터 실무 적용 사례, 그리고 주의해야 할 점까지 구체적으로 설명드리겠습니다.

---

1. anchors란 무엇인가

개념

GitLab CI의 .gitlab-ci.yml은 YAML 문법을 따릅니다. YAML은 anchors(&)와 aliases(*) 기능을 제공하여, 설정 내용을 재사용할 수 있습니다. 마치 코드에서 공통 함수를 정의하고 불러오는 것처럼, CI 설정의 중복을 줄이고 관리 효율성을 높이는 데 유용합니다.

문법 예시

 

.default_script: &default_script
  script:
    - echo "공통 스크립트 실행"

job1:
  <<: *default_script

job2:
  <<: *default_script
  script:
    - echo "job2만의 스크립트 실행"

 

실무 활용 시나리오

• 보안 스캔 파이프라인에서 공통 사전 작업 정의: 예를 들어 모든 Job에 공통적인 SAST 사전 설치 작업이 있다면 anchor로 정의해 놓고 각 Job에서 재사용합니다.
• 환경 분리 설정에 따른 중복 제거: dev, staging, prod 환경에 따라 Job 설정만 조금씩 다른 경우, 공통 부분은 anchor로 관리하고 차이만 override 합니다.

주의사항

• Anchor는 YAML 레벨에서만 작동하므로, GitLab CI 문법이 아닌 YAML 문법 오류로 인한 문제 발생 가능성이 있습니다.
• 복잡한 중첩 anchor는 가독성을 오히려 해칠 수 있으므로, 2단계 이상 중첩은 지양하는 것이 좋습니다.
• Anchor로 가져온 뒤 일부 키만 수정할 경우, 오히려 처음부터 작성하는 것보다 비효율적일 수 있습니다.

---

2. artifacts란 무엇인가

개념

artifacts는 Job 실행 결과물(파일, 디렉터리 등)을 GitLab Runner가 저장하고, 다음 Job으로 전달하거나 다운로드할 수 있도록 하는 기능입니다. 보통 빌드 산출물, 보안 리포트, 로그 등을 전달할 때 사용합니다.

문법 예시

build-job:
  script:
    - make build
  artifacts:
    paths:
      - build/
    expire_in: 1 hour

test-job:
  dependencies:
    - build-job
  script:
    - ./test build/

실무 활용 시나리오

• 보안 리포트 전달: SAST, DAST, Dependency Scan 등의 결과물을 artifacts로 지정하여 이후 Job이나 UI에서 검토 가능하게 합니다.
• 빌드 캐싱: 빌드된 바이너리 또는 패키지를 다음 테스트 Job에서 재활용할 수 있습니다.
• 인프라 배포 전 중간 결과 보존: 예를 들어 Terraform Plan 결과 파일을 artifacts로 저장하고 승인 후 배포 Job에서 그대로 사용할 수 있습니다.

 

주요 키워드 정리

• paths: 보존할 파일이나 디렉터리 경로 목록
• expire_in: 저장된 아티팩트의 만료 시간. 기본은 30일이며, SAST 등 보안 스캔 관련 Job은 명시적으로 짧게 설정하는 것이 좋습니다.
• when: 항상 저장(always), Job 성공 시(on_success), 실패 시(on_failure) 중 선택 가능
• reports: GitLab UI에서 표시할 수 있는 보안/테스트 리포트 지정 (예: sast, dependency_scanning, dast, junit 등)

주의사항

• 모든 Job에서 artifacts를 남기면 GitLab 스토리지가 빠르게 소모될 수 있습니다. 특히 대용량 로그나 빌드 결과물이 자주 생성될 경우 주의해야 합니다.
• CI/CD Job이 병렬적으로 실행되는 경우 dependencies를 명시하지 않으면 artifacts가 제대로 전달되지 않을 수 있습니다.
• Runner 유형에 따라 artifacts의 upload/download 속도에 큰 차이가 발생할 수 있으며, 자체 GitLab 설치 환경에서는 네트워크 병목도 고려해야 합니다.

---

3. anchors + artifacts 조합 활용 예시

보안 스캔 Job에 공통된 artifacts 설정을 anchor로 관리하는 예시)

 

.common_artifacts: &common_artifacts
  artifacts:
    paths:
      - reports/
    expire_in: 1 hour
    when: always

sast-scan:
  script:
    - run-sast-scan > reports/sast.json
  <<: *common_artifacts
  artifacts:
    reports:
      sast: reports/sast.json

dependency-scan:
  script:
    - run-dep-scan > reports/dependency.json
  <<: *common_artifacts
  artifacts:
    reports:
      dependency_scanning: reports/dependency.json

 

 

이렇게 구성하면 paths, expire_in, when 같은 반복적인 설정을 anchor로 관리하면서도, 각 스캔 종류에 맞는 리포트를 개별적으로 지정할 수 있습니다.

---

결론

DevSecOps 환경에서 .gitlab-ci.yml을 구조적으로 작성하는 것은 코드 품질 못지않게 중요합니다.
anchors를 통해 중복을 제거하고 유지보수성을 높이며, artifacts를 통해 Job 간 의존성과 결과물을 체계적으로 관리할 수 있습니다.
단, YAML 문법에 대한 이해 부족, 무분별한 아티팩트 저장, 가독성 저하 등은 오히려 CI/CD 파이프라인의 복잡도와 비용을 높일 수 있으므로 신중한 설계가 필요합니다.