GitLab 18.0으로의 원활한 전환을 위해 지금 준비를 시작하세요. 곧 제거될 기능들의 영향을 평가하고 문서에서 제공하는 대응 방안을 검토하시기 바랍니다. GitLab 18.0에는 DevSecOps 혁신을 한층 발전시키는 새로운 기능이 도입되며, 동시에 일부 레거시 기능이 제거될 예정입니다. 이러한 중요한 변화가 미치는 영향과 이에 대한 대비 방법을 안내해드립니다.

배포 범위 및 기간​

GitLab.com​

GitLab.com의 주요 변경 사항은 다음 세 가지 기간으로 제한됩니다.

  • 2025년 4월 21~23일
  • 2025년 4월 28~30일
  • 2025년 5월 5~7일

그 외에도 많은 변경 사항이 한 달 내내 계속 적용될 예정입니다. 이 주요 변경 사항 문서에서 각 기간에 적용되는 영향력 있는 변경 사항에 대해 자세히 알아볼 수 있습니다.

참고: 예외적인 상황에서는 이 기간을 약간 벗어나는 변경 사항이 적용될 수도 있습니다.

GitLab 자체 관리​

GitLab 18.0은 5월 15일부터 사용할 수 있습니다. 릴리스 일정에 대한 자세한 내용은 여기에서 확인할 수 있습니다.

GitLab 전용​

2025년 6월 24일부터 29일까지 유지 관리 기간 동안 GitLab 18.0으로의 업그레이드가 진행됩니다. 여기에서 자세한 내용을 알아보고 배정된 유지 관리 기간을 확인할 수 있습니다.

또한 18.0 업그레이드에 앞서 이러한 변경 사항이 환경에 미치는 영향을 평가하고 필요한 조치를 계획하는 데 도움이 되는 사용자 지정 도구와 리소스도 개발했습니다. 아래에서 GitLab Detective를 비롯한 이러한 완화 도구 및 리소스에 대한 정보를 확인할 수 있습니다.

18.0에서 제거될 예정인 전체 항목 목록을 보려면 사용 중단 페이지를 방문하세요. 특정 배포에 따라 올해 릴리스에 어떤 기능이 추가되고 어떻게 준비해야 하는지 알아보세요.

주요 변경 사항​

높은 영향도​

1. CI/CD 작업 토큰 - "프로젝트에서 액세스 제한" 설정 제거​

GitLab.com | Self-managed | Dedicated 해당

GitLab 14.4에서는 보안 강화를 위해 프로젝트의 CI/CD 작업 토큰(CI_JOB_TOKEN)에서 접근을 제한하는 설정이 도입되었습니다. 이 설정은 CI_JOB_TOKEN 액세스 제한이라고 불렸습니다. GitLab 16.3에서는 명확성을 위해 이 설정의 이름을 이 프로젝트에서 액세스 제한으로 변경했습니다.

GitLab 15.9에서는 권한 있는 그룹 및 프로젝트라는 대체 설정을 도입했습니다. 이 설정은 허용 목록을 사용하여 프로젝트에 대한 작업 토큰 액세스를 제어합니다. 이 새로운 설정은 기존 설정에 비해 크게 개선되었습니다. 첫 번째 반복은 GitLab 16.0에서 더 이상 사용되지 않으며 GitLab 18.0에서 제거될 예정입니다.

이 프로젝트에서 액세스 제한 설정은 모든 새 프로젝트에 대해 기본적으로 비활성화되어 있습니다. GitLab 16.0 이상에서는 어떤 프로젝트에서든 이 설정을 비활성화한 후에는 다시 활성화할 수 없습니다. 대신 권한 있는 그룹 및 프로젝트 설정을 사용하여 프로젝트에 대한 작업 토큰 액세스를 제어하세요.

2. CI/CD 작업 토큰 - 권한 부여된 그룹 및 프로젝트 허용 목록 적용​

GitLab.com | Self-managed | Dedicated 해당

GitLab 15.9에 도입된 권한 있는 그룹 및 프로젝트 설정 (GitLab 16.3에서는 이 프로젝트에 대한 접근 제한에서 이름 변경)으로 프로젝트에 대한 CI/CD 작업 토큰 접근을 관리할 수 있습니다. 이 프로젝트와 허용 목록에 있는 모든 그룹 및 프로젝트만으로 설정하면 허용 목록에 추가된 그룹 또는 프로젝트만 작업 토큰을 사용하여 프로젝트에 액세스할 수 있습니다.

  • GitLab 15.9 이전에는 허용 목록이 기본적으로 비활성화되어 있어(모든 그룹 및 프로젝트 액세스 설정 선택) 모든 프로젝트에서 작업 토큰 액세스가 가능했습니다.
  • GitLab 17.6부터는 모든 프로젝트에 대해 프로젝트 관리자가 모든 그룹 및 프로젝트를 선택하지 못하도록 하는 보다 안전한 설정을 적용할 수 있는 옵션이 GitLab 셀프 관리 및 전용 인스턴스 관리자에게 제공됩니다. 이 변경으로 프로젝트 간에 더 높은 수준의 보안이 보장됩니다.
  • GitLab 18.0에서는 이 설정이 기본적으로 활성화됩니다. GitLab.com에서는 프로젝트 인증 로그를 기반으로 프로젝트의 허용 목록을 자동으로 채웁니다.
  • 프로젝트 간 인증에 작업 토큰을 사용하는 프로젝트 관리자는 GitLab.com에서 이 변경에 대비하여 프로젝트의 권한 그룹 및 프로젝트 허용 목록을 채워야 합니다. 그런 다음 설정을 이 프로젝트와 허용 목록에 있는 모든 그룹 및 프로젝트만으로 변경해야 합니다. GitLab 18.0 이전 프로젝트의 인증 로그를 기반으로 허용 목록 생성을 자동화하기 위해 사용 가능한 마이그레이션 도구를 사용하는 것이 좋습니다.
  • 셀프 관리 사용자는 18.0 업그레이드를 완료하기 전에 허용 목록을 채워야 합니다.
  • 전담 사용자는 GitLab 계정 팀과 협력하여 특정 인스턴스에 적합한 전략을 개발해야 합니다.
  • 사용 중단 공지
  • 문서
  • GitLab Detective 확인 가능

3. 종속성 프록시 토큰 범위 적용​

GitLab.com | Self-managed | Dedicated 해당

컨테이너용 디펜던시 프록시는 범위를 검증하지 않고 개인, 프로젝트 또는 그룹 액세스 토큰을 사용하여 도커 로그인 및 도커 풀 리퀘스트를 수락합니다.

GitLab 18.0에서는 종속성 프록시에서 인증을 위해 read_registry 및 write_registry 범위가 모두 필요합니다. 이 변경 후에는 이러한 범위가 없는 토큰을 사용한 인증 시도는 거부됩니다.

업그레이드하기 전에 필요한 범위로 새 액세스 토큰을 만들고 워크플로 변수와 스크립트를 이 새 토큰으로 업데이트하세요.

또한 토큰을 보고 자동으로 회전할 수 있는 커뮤니티 개발 스크립트인 종속성 토큰 검사기를 사용할 수도 있습니다.

중간 영향도​

1. GitLab.com의 취약점에 대한 새로운 데이터 보존 한도 설정​

GitLab.com - Ultimate 티어 고객 전용

6개월 동안 단계적으로 출시되는 GitLab 18.1부터 시스템 성능과 안정성을 개선하기 위해 GitLab.com Ultimate 고객에게 새로운 데이터 보존 제한을 도입할 예정입니다. 데이터 보존 제한은 취약점 데이터가 저장되는 기간에 영향을 미칩니다.

업데이트되지 않은 12개월이 지난 취약점은 자동으로 콜드 스토리지 아카이브로 이동됩니다. 이러한 아카이브:

  • GitLab UI를 통해 계속 액세스하고 다운로드할 수 있습니다.
  • 3년 동안 보관됨
  • 3년 후 영구적으로 삭제됨
  • 사용 중단 공지
  • 문서

2. allowed_pull_policies 없는 컨테이너 이미지 풀 정책 거부하기​

GitLab.com | Self-managed | Dedicated 해당

구성된 모든 풀 정책은 러너의 config.toml 파일에 지정된 allowed_pull_policies 구성에 있어야 합니다. 그렇지 않은 경우 호환되지 않는 풀 정책 오류와 함께 작업이 실패해야 합니다.

현재 구현에서는 여러 풀 정책이 정의된 경우, 다른 정책이 포함되어 있지 않더라도 하나 이상의 풀 정책이 허용된 풀 정책의 정책과 일치하면 작업이 통과됩니다.

GitLab 18.0에서는 풀 정책 중 허용된 풀 정책과 일치하는 풀 정책이 하나도 없는 경우에만 작업이 실패합니다. 그러나 이전 동작과 달리, 작업은 허용된 풀 정책에 나열된 풀 정책만 사용합니다. 이 차이로 인해 현재 통과한 작업이 GitLab 18.0에서는 실패할 수 있습니다.

3. PostgreSQL 14 / 15 지원 중단​

Self-managed 해당

GitLab은 PostgreSQL의 연간 업그레이드 주기를 따릅니다. PostgreSQL 14 및 15에 대한 지원은 GitLab 18.0에서 제거될 예정입니다. GitLab 18.0에서는 PostgreSQL 16이 최소 요구 버전이 됩니다. PostgreSQL 14 및 15는 전체 GitLab 17 릴리스 주기 동안 지원됩니다. GitLab 18.0 이전에 업그레이드하려는 인스턴스에 대해서도 PostgreSQL 16이 지원됩니다.

PostgreSQL 클러스터를 사용하지 않는 인스턴스에서 이 변경에 대비하기 위해(예: Omnibus Linux 패키지와 함께 설치한 단일 PostgreSQL 인스턴스를 실행하는 경우), GitLab 17.11로 업그레이드하면 PostgreSQL을 버전 16으로 자동 업그레이드하려고 시도합니다. PostgreSQL 클러스터를 사용하거나 이 자동 업그레이드를 선택 해제하는 경우, 수동으로 PostgreSQL 16으로 업그레이드 해야 GitLab 18.0으로 업그레이드할 수 있습니다. 업그레이드를 수용할 수 있는 충분한 디스크 공간이 있는지 확인하세요.

4. Terraform CI/CD 템플릿 사용 중단​

Self-managed 해당

Terraform CI/CD 템플릿은 더 이상 사용되지 않으며 GitLab 18.0에서 제거될 예정입니다.

이는 다음 템플릿에 영향을 줍니다:

  • Terraform.gitlab-ci.yml
  • Terraform.latest.gitlab-ci.yml
  • Terraform/Base.gitlab-ci.yml
  • Terraform/Base.latest.gitlab-ci.yml

GitLab은 작업 이미지의 terraform 바이너리를 BSL에 따라 라이선스가 부여된 버전으로 업데이트할 수 없습니다.

Terraform을 계속 사용하려면 템플릿과 Terraform 이미지를 복제하고 필요에 따라 유지 관리하세요. 맞춤형 이미지로 마이그레이션하기 위한 자세한 지침은 GitLab에서 제공합니다. 대안으로, GitLab.com의 새로운 OpenTofu CI/CD 구성 요소 또는 GitLab 셀프 관리의 새로운 OpenTofu CI/CD 템플릿을 사용하는 것이 좋습니다. CI/CD 구성 요소는 아직 GitLab Self-Managed에서 사용할 수 없지만 이슈 #415638에서 이 기능을 추가할 것을 제안하고 있습니다. CI/CD 구성 요소를 GitLab Self-Managed에서 사용할 수 있게 되면 OpenTofu CI/CD 템플릿은 제거됩니다.

새로운 OpenTofu CI/CD 구성 요소에 대해 자세히 알아보세요.

5. Prometheus 하위 차트 주요 업데이트​

Self-managed 해당

GitLab 18.0 및 GitLab 차트 9.0에서는 Prometheus 서브차트가 15.3에서 27.3으로 업데이트됩니다. 이 업데이트와 함께 Prometheus 3가 기본으로 제공됩니다. 업그레이드를 수행하려면 수동 단계가 필요합니다. 알림 관리자, 노드 익스포터 또는 푸시 게이트웨이를 활성화한 경우 헬름 값도 업데이트해야 합니다.

자세한 내용은 마이그레이션 가이드를 참조하세요.

낮은 영향도​

1. SUSE Linux Enterprise Server 15 SP2 패키지 지원 중단​

Self-managed 해당

SUSE Linux Enterprise Server(SLES) 15 SP2에 대한 장기 서비스 및 지원(LTSS)은 2024년 12월에 종료됩니다.

따라서 더 이상 Linux 패키지 설치용 SLES SP2 배포를 지원하지 않습니다. 지속적인 지원을 받으려면 SLES 15 SP6으로 업그레이드해야 합니다.

2. Gitaly 비율 제한기 제거​

Self-managed 해당

Gitaly는 RPC 기반 속도 제한을 지원했습니다. 이 기능은 원하는 결과를 얻지 못하므로 더 이상 사용되지 않습니다. 자세한 내용은 사용 중단 이슈를 참조하세요. 고객이 비율 제한기를 구성한 경우(더 이상 사용되지 않음) 오류가 반환되지 않으며 해당 구성은 무시됩니다. 고객은 대신 동시성 제한기를 사용해야 합니다.

3. NGINX 컨트롤러 이미지 1.3.1 지원 중단​

Self-managed 해당

기본 NGINX 컨트롤러 이미지를 1.11.2로 업그레이드합니다. 이 새 버전에는 새로운 RBAC 규칙이 필요하며 일부 사용자는 자체 RBAC 규칙을 관리하기 위해 nginx-ingress.rbac.create: false를 설정합니다.

이러한 사용자는 1.11.2 이상으로 마이그레이션하기 전에 RBAC 규칙을 추가해야 합니다. 이 헬름 값이 위와 같이 설정된 경우에만 1.3.1을 배포하는 폴백 메커니즘을 추가했습니다. 또한 기본값이 false로 설정되는 nginx-ingress.controller.image.disableFallback을 추가했습니다. 자체 RBAC를 관리하는 사용자는 새 RBAC 규칙이 적용되었는지 확인한 후 배포에서도 1.11.2를 사용하도록 이 값을 true로 설정할 수 있습니다.

17.5에서는 1.3.1 이미지 지원과 폴백 메커니즘을 더 이상 지원하지 않을 계획이므로, 이 지원을 완전히 제거하고 다양한 보안 이점을 제공하는 1.11.2만 사용할 수 있도록 할 예정입니다.

지원 중단 공지

4. 애플리케이션 보안 테스트 분석기 주요 버전 업데이트​

GitLab.com | Self-managed | Dedicated 해당

애플리케이션 보안 테스트 단계에서는 GitLab 18.0 릴리스와 함께 분석기의 주요 버전을 업데이트할 예정입니다.

기본 포함된 템플릿을 사용하지 않거나 분석기 버전을 고정해 놓은 경우, 고정된 버전을 제거하거나 최신 주 버전을 업데이트하기 위해 CI/CD 작업 정의를 업데이트해야 합니다.

GitLab 17.0-17.11 사용자는 GitLab 18.0이 출시될 때까지 분석기 업데이트를 정상적으로 계속 사용할 수 있습니다. GitLab 18.0 이후에는 새로 수정된 모든 버그와 기능은 분석기의 새로운 메이저 버전에서만 릴리스됩니다.

유지 관리 정책에 따라 버그와 기능을 더 이상 사용되지 않는 버전으로 백포트하지 않습니다. 필요에 따라 보안 패치는 최신 마이너 릴리스 3종으로 백포트됩니다.

5. API Discovery는 기본적으로 브랜치 파이프라인을 사용합니다.​

GitLab.com | Self-managed | Dedicated 해당

GitLab 18.0에서는 API 디스커버리용 CI/CD 템플릿(API-Discovery.gitlab-ci.yml)의 기본 동작이 업데이트됩니다.

GitLab 18.0 이전에는 이 템플릿이 MR이 열려 있을 때 기본적으로 병합 요청 파이프라인에서 실행되도록 작업을 구성합니다.

GitLab 18.0부터는 이 템플릿의 동작을 다른 AST 스캐너용 Stable 템플릿 에디션의 동작에 맞게 조정할 예정입니다:

  • 기본적으로 템플릿은 브랜치 파이프라인에서 스캔 작업을 실행합니다.
  • MR이 열려 있을 때 대신 MR 파이프라인을 사용하도록 CI/CD 변수 AST_ENABLE_MR_PIPELINES: true를 설정할 수 있습니다. 이 새로운 변수의 구현은 이슈 #410880에서 추적됩니다.
  • 사용 중단 공지

6. DAST DAST_DEVTOOLS_API_TIMEOUT의 기본값이 낮아집니다.​

GitLab.com | 자체 관리 | 전용

DAST_DEVTOOLS_API_TIMEOUT 환경 변수는 DAST 스캔이 브라우저의 응답을 기다리는 시간을 결정합니다. GitLab 18.0 이전에는 이 변수의 고정값이 45초였습니다. GitLab 18.0 이후에는 다른 시간 제한 설정에 따라 계산되는 동적 값을 갖는 DAST_DEVTOOLS_API_TIMEOUT 환경 변수가 있습니다.

대부분의 경우 45초 값은 많은 스캐너 기능의 시간 초과 값보다 높았습니다. 동적으로 계산된 값은 적용되는 케이스 수를 증가시켜 DAST_DEVTOOLS_API_TIMEOUT 변수를 더욱 유용하게 만듭니다.

영향력 관리를 위한 도구 및 리소스​

저희는 고객이 계획된 변경 사항이 GitLab 인스턴스에 어떤 영향을 미치는지 이해하는 데 도움이 되는 구체적인 도구를 개발했습니다. 영향을 평가한 후에는 문서에 제공된 완화 단계를 검토하여 GitLab 18.0으로 원활하게 전환할 수 있도록 하는 것이 좋습니다.

  • 고급 검색 사용 중단: 이 도구는 GitLab의 고급 검색 API를 사용하여 GitLab 그룹 및 프로젝트 전반에서 사용 중단과 관련된 문자열을 찾습니다. 또한 수동으로 확인해야 하는 파일도 보고합니다. 참고: 일부 오탐이 있을 수 있습니다.
  • 종속성 스캔 빌드 지원 감지 도우미: 이 도구는 세 가지 종속성 검사 사용 중단(1, 2, 3, 모두 19.0으로 연기됨)의 영향을 받는 프로젝트를 식별합니다. API를 사용하여 관련 파일 및 CI 작업 이름을 검색합니다.
  • GitLab Detective(자체 관리 전용): 이 실험적 도구는 GitLab 설치에서 알려진 문제를 자동으로 검사합니다. 구성 파일이나 데이터베이스 값을 살펴봄으로써 복잡한 검사를 완료합니다. 참고: GitLab 노드에서 직접 실행해야 합니다.

본 내용은 GitLab 블로그 글을 번역한 게시물 입니다.

더 많은 GitLab에 대한 정보와 데모가 궁금하신가요? 혹은 GitLab 업그레이드가 필요하신가요? 그렇다면 인포그랩에 연락하세요! DevOps 전문가가 도와드립니다. 지금 문의하기