GitLab 19.1 릴리즈 노트

GitLab 19.1이 2026년 6월 18일에 출시되었습니다. 이번 릴리즈에서는 GitLab Duo가 Secret Detection 취약점의 거짓 긍정(False Positive)을 자동 분석하고, 관리자가 Duo를 조직 전체에서 "Always On"으로 잠글 수 있게 되었습니다. 또한 Code Owners의 Merge request 리뷰어 자동 지정, 19종 사전 구성 컴플라이언스 프레임워크 템플릿(베타), Agentic Core 거버넌스 강화, 서드파티 SARIF 스캐너 결과 연동, Security Manager role 정식 출시 등 총 27개의 개선 사항이 포함되어 있습니다.

본 내용은 GitLab의 릴리즈 노트를 번역 및 재편집한 내용이며 원문은 GitLab 19.1 Release에서 확인할 수 있습니다.

주요 기능

1. GitLab Duo Secret False Positive Detection (GA)

GitLab Duo Agent Platform 기반의 Secret False Positive Detection이 정식 출시(GA)되었습니다. 기존에는 보안팀이 실제 시크릿으로 잘못 표시된(False Positive) 탐지 결과를 조사하는 데 상당한 시간을 들였으며, 이러한 거짓 긍정은 알림 피로(Alert Fatigue)를 유발하고 스캔 결과에 대한 신뢰를 떨어뜨리며 정작 중요한 보안 위험에 쏟아야 할 주의를 흐트러뜨렸습니다. 이제 보안 스캔이 실행되면 GitLab Duo가 치명적(Critical) 및 높음(High) 심각도의 Secret Detection 취약점을 자동으로 분석하여 거짓 긍정 여부를 판단하고, 그 결과를 취약점 보고서에 표시하여 더 빠르고 확신 있게 트리아지(Triage)할 수 있도록 돕습니다. 주요 기능은 다음과 같습니다.

• 자동 분석: 별도의 수동 트리거 없이 각 보안 스캔 이후 자동으로 실행됩니다.
• 수동 트리거: 취약점 상세 페이지에서 개별 취약점에 대해 거짓 긍정 탐지를 즉시 실행할 수 있습니다.
• 고영향 항목 집중: 치명적 및 높음 심각도 취약점만 분석하여 신호 대 잡음(Signal-to-Noise) 비율을 최대한 개선합니다.
• 맥락 기반 AI 추론: 각 평가에서 코드 맥락과 취약점 특성을 바탕으로 해당 항목이 실제 위험(True Positive)일 가능성이 높은 이유를 함께 설명합니다.
• 신뢰도 점수(Confidence Scoring): 각 탐지에는 모델의 확신도를 반영한 신뢰도 점수가 포함되어 검토 우선순위 결정을 돕습니다.
• 워크플로 통합: 결과가 기존 심각도, 상태, 해결 정보와 함께 취약점 보고서에 직접 표시됩니다.

2. GitLab Duo Always On 가용성 모드

관리자가 인스턴스 전체 또는 최상위 그룹의 모든 프로젝트에 대해 GitLab Duo를 "Always On(항상 켜짐)"으로 설정할 수 있습니다. GitLab Duo가 Always On으로 설정되면 그룹, 하위 그룹, 프로젝트 Owner가 GitLab Duo를 끌 수 없으므로, 컴플라이언스 및 규제 환경에 맞는 중앙 집중식 AI 거버넌스를 구현할 수 있습니다. 이 새로운 설정은 기존의 "Always Off(항상 꺼짐)" 설정과 대칭을 이루며, GitLab Duo를 잠가 끌 수는 있었지만 잠가 켤 수는 없었던 공백을 메웁니다. 자율적인 사업부나 자회사를 보유하여 비즈니스 전반에 걸쳐 일관된 AI 도구 사용을 보장해야 하는 조직에 특히 유용합니다. GitLab Duo를 Always On으로 설정하려면 인스턴스 또는 최상위 그룹의 GitLab Duo 설정에서 GitLab Duo availability를 Always on으로 지정하면 됩니다.

3. Code Owners 자동 리뷰어 지정

기존에는 CODEOWNERS 파일에 각 파일을 누가 리뷰해야 하는지 이미 정의되어 있더라도 Merge request마다 리뷰어를 수동으로 선택해야 했습니다. 이제 Code Owners를 리뷰어로 자동 지정하도록 프로젝트를 구성할 수 있습니다. Merge request가 준비 완료(Ready) 상태로 생성되거나 초안(Draft)이 준비 완료로 표시되면, GitLab이 변경된 파일과 일치하는 모든 Code Owners를 리뷰어로 지정합니다. 이미 리뷰어를 지정한 경우 GitLab은 자동 지정을 건너뛰고 사용자의 선택을 그대로 유지합니다. 자동 리뷰어 지정을 켜려면 Settings > Merge requests > Automatic reviewer assignment로 이동하여 Automatically assign all code owners as reviewers를 선택하면 됩니다.

4. 컴플라이언스 프레임워크 템플릿 (베타)

이제 사전 정의된 템플릿으로 컴플라이언스 프레임워크를 생성할 수 있습니다. 기존에는 컴플라이언스 프레임워크를 구축하려면 모든 요구사항과 컨트롤을 일일이 수작업으로 정의해야 했으며, 프레임워크에 수십 개의 컨트롤이 있을 경우 반복적인 작업이 되었습니다. 이제 Compliance center에서 새 프레임워크를 만들 때 다음을 수행할 수 있습니다.

• Create from template을 선택하여 요구사항과 컨트롤이 이미 구성된 프레임워크에서 시작할 수 있습니다.
• 각 템플릿을 미리 보고 이름, 설명, 색상을 커스터마이징한 다음 한 번에 그룹에 적용할 수 있습니다.

ISO 27001:2022, SOC 2, FedRAMP, NIST, CIS, TISAX 등 총 19종의 템플릿을 사용할 수 있습니다.

5. 피처 브랜치 파이프라인 Secret Detection 커버리지 개선

GitLab 19.1 이전 버전에서는 피처 브랜치 파이프라인이 브랜치 내 모든 시크릿을 빠짐없이 드러낼 것이라고 신뢰하기 어려웠습니다. 새 브랜치는 최신 커밋만 스캔했고, 기존 브랜치는 가장 최근 푸시만 스캔했기 때문에, 이전 커밋에서 유출된 자격 증명(Credentials)이 탐지되지 않은 채 공유 브랜치나 운영 환경까지 도달할 수 있었습니다. 이제 시크릿을 수정 비용이 가장 저렴한 시점에 잡아낼 수 있습니다. GitLab 19.1에서는 Secret Detection이 기본 브랜치와의 분기 지점(Divergence Point)부터 최신 커밋까지 모든 커밋을 스캔합니다. 이를 통해 후속 단계로 빠져나가는 시크릿이 줄어들고, 사후에 노출된 자격 증명을 교체하는 시간이 단축되며, 브랜치 전반에 걸쳐 일관되고 예측 가능한 커버리지를 확보할 수 있습니다.

6. GitLab Duo 에이전트 도구 승인 가드레일 (베타)

관리자가 GitLab Duo 에이전트에 대해 도구 수준의 승인 정책을 구성하여, 민감한 작업은 실행 시점에 사람의 승인을 거치도록 할 수 있습니다. 기존에는 AI 에이전트가 프로젝트에 대해 승인되면 쓰기 및 파괴적(Destructive) 작업을 포함한 모든 도구를 추가 검토 없이 호출할 수 있었습니다. 이제 그룹과 프로젝트에 대해 각 도구를 다음 세 가지 모드 중 하나에 매핑하는 규칙을 정의할 수 있습니다.

• Allow: 도구를 조용히 실행합니다.
• Ask: 사람의 승인을 요구합니다.
• Deny: 실행을 완전히 차단합니다.

AI 에이전트가 "Ask" 모드의 도구를 호출하면, 실행이 진행되기 전에 사용자에게 인라인 승인 카드(Approval Card)가 표시됩니다. 이번 베타 릴리즈는 Agentic Chat, IDE, 플로(Flows)를 지원하며 모든 승인 결정에 대해 감사 이벤트(Audit Event)를 발생시킵니다.

Agentic Core

1. 커스텀 및 외부 AI 기능 제어

이제 관리자와 최상위 그룹 Owner가 조직 내에서 어떤 AI 에이전트와 플로를 사용할 수 있는지 제어할 수 있습니다. 다음을 수행할 수 있습니다.

• 사용자가 커스텀 에이전트와 플로를 생성하거나 활성화하지 못하도록 차단해, 중앙에서 승인된 AI 자동화만 사용하도록 보장합니다.
• 그룹 계층 외부의 프로젝트가 소유한 에이전트와 플로를 사용자가 활성화하지 못하도록 제한해, 승인되지 않은 외부 콘텐츠에 노출될 위험을 줄입니다.

2. 커스텀 플로 YAML 검증

이제 AI Catalog가 커스텀 플로를 저장하거나 트리거하기 전에 구성을 검증합니다. 기존에는 커스텀 플로의 구문 오류나 잘못 구성된 파라미터(예: 누락된 입력값, 알 수 없는 도구 파라미터)가 CI 작업이 이미 시작된 후 런타임에야 드러나서, 디버깅이 느리고 어려웠습니다. 이제 AI Catalog에서 커스텀 플로를 저장하거나 업데이트하면 GitLab이 구성을 사전에 점검하여 오류를 UI에 직접 표시합니다. 유효한 플로는 영향을 받지 않으며 평소와 같이 저장 및 트리거됩니다.

3. Agentic Chat 패턴 기반 도구 승인

기존에는 Agentic Chat이 도구 호출 승인을 요청할 때, 한 번만 승인하거나 해당 인수(Arguments)로 호출되는 도구를 세션이 끝날 때까지 승인할 수 있었습니다. 인수가 다르면 추가 승인이 필요했기 때문에, 일련의 git 작업처럼 유사한 명령을 반복하는 워크플로에서는 거의 동일한 승인 프롬프트가 연달아 이어졌습니다. 이제 세 번째 승인 옵션인 Approve all uses of this tool for session을 선택할 수 있습니다. 이 옵션은 인수가 승인된 패턴과 일치하는 한, 세션이 끝날 때까지 해당 도구의 호출을 승인합니다. 패턴 기반 승인은 GitLab UI의 Agentic Chat, GitLab Duo CLI, VS Code용 GitLab, JetBrains IDE용 GitLab Duo 플러그인에서 사용할 수 있습니다.

4. 신규 GitLab 고객 대상 자동 코드 리뷰

Code Review Flow의 자동 리뷰가 GitLab.com의 신규 GitLab Duo 평가판(Trial) 고객에게 기본으로 활성화되어, 별도의 수동 설정 없이 첫날부터 Merge request에 대한 AI 기반 피드백을 받을 수 있습니다. 새로운 정액 요금제(Flat Pricing Model)와 함께, 더 똑똑하고 빠른 코드 리뷰의 가치를 즉시 누릴 수 있습니다. 필요한 경우 그룹 설정에서 옵트아웃(Opt-out)할 수 있습니다.

5. Foundational Flows 준비 상태 점검

GitLab Duo Health Check에 이제 Foundational Flows 준비 상태 점검이 포함되어 다음을 검증합니다.

• 인스턴스 수준의 Flow Execution 설정이 활성화되어 있는지 확인합니다.
• 인스턴스 수준의 Foundational Flows 설정이 활성화되어 있는지 확인합니다.
• gitlab-duo 태그가 지정된 활성 인스턴스 Runner가 하나 이상 등록 및 연결되어 있고, Docker 호환 실행기(Executor)를 사용하는지 확인합니다.

6. Code Review Flow의 GPT 모델 지원

이전 버전의 GitLab에서는 Code Review Flow가 Anthropic Claude 모델만 지원했습니다. 따라서 계약, 정책, 조달(Procurement) 제약으로 Anthropic 모델을 사용할 수 없는 팀은 Code Review Flow를 실행할 방법이 없었습니다. 이제 Code Review Flow의 모델로 GPT-5.2 또는 GPT-5.3 Codex를 선택할 수 있습니다. 최상위 그룹 Owner는 Settings > GitLab Duo > Configure features의 GitLab Duo Agent Platform 항목에서 Agentic Code Review의 모델을 전환할 수 있습니다. GPT 모델은 GitLab AI Gateway를 통해 호스팅되므로 추가 구성이 필요하지 않습니다. 두 모델 모두 GitLab Duo 코드 리뷰 데이터셋 기준 벤치마크 평가를 통과했으며, 기본 Claude Sonnet 4.6 Vertex 모델과 비슷한 수준의 리뷰 품질을 보였습니다.

7. 모델 선택 허용 목록 (Allowlist)

GitLab Duo Agentic Chat에 대해 이제 승인된 모델의 허용 목록(Allowlist)을 구성하고 조직 전체 기본값을 설정할 수 있습니다. 다음 권한이 필요합니다.

• GitLab.com에서는 최상위 그룹 Owner.
• GitLab Self-Managed에서는 인스턴스 관리자(instance administrator).

이를 통해 조직은 Agentic Chat 사용 시 사용자가 선택할 수 있는 모델을 제어할 수 있습니다.

8. 플로 및 외부 에이전트를 위한 신규 이벤트 트리거

이전 버전의 GitLab에서는 서비스 계정이 멘션되거나, 할당되거나, 리뷰어로 추가될 때만 플로와 외부 에이전트를 실행할 수 있었습니다. Merge request 라이프사이클의 나머지 단계나 작업 항목(Work Item) 생성을 중심으로 자동화를 조율하려면 외부 연동 작업이 필요했습니다. 이제 다음 네 가지 이벤트에 대해 트리거를 구성할 수 있습니다.

• Merge request ready: 사용자가 초안 Merge request를 리뷰 준비 완료로 표시합니다. 이전에는 피처 플래그 뒤에 게이트되어 있었으나 이제 정식 출시(GA)되었습니다.
• Merge request code conflict: 코드 충돌(Code Conflict)로 인해 Merge request를 더 이상 merge할 수 없게 됩니다.
• Merge request approved: Merge request가 필요한 모든 승인을 받습니다.
• Work item created: 사용자가 프로젝트에 작업 항목을 생성합니다.

트리거를 구성하려면 프로젝트의 AI > Triggers로 이동하거나, 플로를 활성화할 때 선택하면 됩니다.

통합 DevOps 및 보안

1. Scanner Enablement Wizard로 커버리지 공백 해소

이제 Scanner Enablement Wizard를 사용하여, 어떤 프로젝트에 조치가 필요한지 수동으로 식별하지 않고도 프로젝트 전반의 스캐너 커버리지 공백을 해소할 수 있습니다.

Security Configuration Profiles는 어떤 스캐너를 어떻게 실행할지 정의하고, Security Inventory는 프로젝트 전반의 스캐너 커버리지를 보여 주며 선택한 프로젝트나 하위 그룹에 프로필을 일괄 적용할 수 있게 합니다. Wizard는 그 위에 목표 기반(Goal-driven) 워크플로를 추가합니다. 사용자가 목표를 설정하면, Wizard가 커버리지가 누락된 프로젝트를 찾아 해당 공백만 해소합니다.

2. OAuth 액세스 토큰 수명 커스터마이징

기본적으로 GitLab의 OAuth 액세스 토큰은 2시간 후에 만료됩니다. GitLab 19.1에서는 GitLab Self-Managed 및 GitLab Dedicated의 인스턴스 관리자가 새 OAuth 액세스 토큰에 대해 커스텀 수명을 설정할 수 있습니다. 300초에서 7200초 사이의 값을 자유롭게 구성할 수 있습니다. 이를 통해 기존 토큰의 동작을 변경하지 않으면서도, MCP 클라이언트를 포함한 보안에 민감한 OAuth 통합에는 더 짧은 토큰 수명을 강제 적용할 수 있습니다.

3. 위키 페이지 이모지 반응

이제 프로젝트 위키와 그룹 위키 양쪽에서 위키 페이지에 직접 이모지 반응(Emoji Reaction)을 추가할 수 있습니다.

GitLab 이모지 선택기를 사용하여 페이지 콘텐츠에 반응할 수 있으며, 각 페이지에는 반응 횟수와 누가 반응했는지가 표시됩니다. 반응은 페이지 편집 및 버전 변경에도 그대로 유지됩니다.

4. Scheduled Pipeline Execution Policies (베타)

Scheduled Pipeline Execution Policies가 베타 기능으로 제공되며, 더 이상 실험(Experiment) 플래그를 활성화할 필요가 없습니다. 커밋 활동과 무관하게 프로젝트 전반에 걸쳐 일별, 주별, 월별 주기로 커스텀 CI/CD 작업을 강제로 실행할 수 있습니다. 예약 정책을 사용하면 정기적인 코드 변경이 없는 리포지터리에서도 컴플라이언스 스크립트, 보안 스캔, 의존성 점검을 실행할 수 있습니다.

예약 정책은 이제 일반 파이프라인 실행 정책과 일관되게 변수 우선순위(Variable Precedence)를 적용합니다. 각 보안 정책 프로젝트는 최대 5개의 예약 정책을 지원하며, 정책이 비활성화되거나 삭제되면 GitLab이 실행 중인 파이프라인을 자동으로 취소합니다. 일정은 YAML 또는 UI에서 구성할 수 있으며, 타임존(Time Zone) 지원, 시간 창 분산(Time Window Distribution), 브랜치 타깃팅, 스누즈(Snooze) 기능을 제공합니다.

5. Security Manager role (GA)

Security Manager role이 정식 출시(GA)되어, 취약점 관리, 보안 대시보드, 정책 구성, 컴플라이언스 도구를 포함한 보안 기능에 폭넓게 접근할 수 있는 권한을 부여합니다. 이제 보안팀은 보안 기능에 접근하기 위해 Developer나 Maintainer role을 부여받을 필요가 없으므로, 직무 분리(Separation of Duties)를 유지하면서도 과도한 권한 부여(Over-privileging) 문제를 해소할 수 있습니다. Security Manager role을 가진 사용자는 다음에 접근할 수 있습니다.

• 취약점 관리: 그룹 및 프로젝트 전반의 취약점을 조회, 트리아지, 관리합니다.
• 보안 정책: 그룹 수준에서 보안 정책을 조회 및 관리하고, 프로젝트 수준에서는 정책 YAML 작성에 참여합니다.
• Security Inventory: 그룹 내 모든 프로젝트의 스캐너 커버리지를 조회합니다.
• Security Configuration Profiles: 그룹 및 프로젝트의 Security Configuration Profiles를 조회합니다.
• 컴플라이언스 도구: 그룹 및 프로젝트 수준에서 감사 이벤트, Compliance center, 컴플라이언스 프레임워크, 컴플라이언스 상태 보고서, 의존성 목록을 조회 및 관리합니다.
• Secret Push Protection: 그룹 및 프로젝트에 대해 Secret Push Protection을 활성화합니다.
• 온디맨드 DAST: 프로젝트에 대해 온디맨드 DAST 스캔을 생성 및 실행합니다.
• Runner 가시성: 그룹 및 프로젝트의 Runner를 조회합니다.

시작하려면 그룹에서 Manage > Members로 이동하여 멤버를 초대하고 Security Manager role을 할당하면 됩니다.

6. 서드파티 스캐너 결과 GitLab 연동

이제 SARIF 2.1.0 규격을 준수하는 모든 스캐너의 보안 발견 항목을 GitLab 취약점 관리에서 사용할 수 있습니다.

스캐너를 실행하여 SARIF 아티팩트(Artifact)를 출력하는 CI/CD 작업을 정의하면, GitLab이 해당 발견 항목을 파싱하고 검증한 뒤 가져와 보안 워크플로에 통합합니다. 결과는 파이프라인 보안 탭, 취약점 보고서, 보안 대시보드, Merge request 보안 위젯, 보안 정책에서 GitLab 네이티브 스캐너 출력과 함께 표시됩니다. 이를 통해 보안팀은 어떤 도구가 생성한 결과든 관계없이 취약점을 하나의 통합된 뷰로 확인할 수 있습니다.

GitLab은 각 발견 항목의 식별자(Identifier)를 기반으로 보고서 유형을 할당하여, 결과를 SAST, dependency scanning, secret detection 등의 카테고리로 매핑합니다. 지원되는 스캐너로는 SAST의 Semgrep과 Checkmarx, 의존성 및 컨테이너 스캐닝의 Trivy와 Snyk, Secret Detection의 Gitleaks가 있습니다.

7. Recently Viewed Items에 위키 페이지 표시

이제 위키 페이지가 Recently Viewed Items에 표시되어 자주 방문하는 페이지로 다시 돌아갈 수 있습니다. GitLab 홈페이지의 Quick access 위젯은 이슈, Merge request, 에픽과 함께 최근에 조회한 프로젝트 및 그룹 위키 페이지를 나열합니다. GitLab은 삭제되었거나 더 이상 접근할 수 없게 된 페이지를 자동으로 제거합니다.

8. 취약점 상세 정보의 보안 업계 표준 레이블 개선

GitLab 19.1에서는 취약점 결과 상세 페이지가 스캔 결과에 대해 일관되고 설명적인 보안 업계 표준 용어를 사용합니다. 변경된 레이블은 다음과 같습니다.

• Scanner → Detected by
• EPSS → Exploit Probability (EPSS)
• Has Known Exploit (KEV) → Known Exploited (CISA KEV)
• Reachable → Reachability
• Image → Container Image (컨테이너 스캐닝)
• Location → Affected Location
• URL → Affected Endpoint (DAST, API 퍼징)
• Method → HTTP Method (DAST, API 퍼징)
• Solution → Remediation Guidance
• Links → References

9. 모든 액터 유형에 대한 Git 작업 감사 이벤트

GitLab 18.10에서 감사 로그가 사람 사용자가 수행한 특정 Git 작업(clone, pull, fetch, push)을 기록하기 시작했습니다.

GitLab 19.1에서는 이 기능이 배포 토큰(Deploy Token)을 사용하는 Runner와 SSH 인증서 사용자를 포함한 모든 액터(Actor) 유형으로 확장되었습니다. 이제 감사 로그는 누가 또는 무엇이 시작했는지와 관계없이 리포지터리 전반의 모든 Git 활동을 빠짐없이 반영합니다.

10. Blob 뷰어의 인라인 Blame

기존에는 blame 정보를 보려면 별도의 페이지로 이동해야 해서 코드 리뷰 흐름이 끊겼습니다.

이제 파일 뷰에서 직접 blame 정보를 토글할 수 있습니다. 각 라인에는 누가 마지막으로 수정했는지가 표시되며, 마우스를 올리면 추가 세부 정보가 담긴 커밋 팝오버(Commit Popover)를 볼 수 있습니다. View blame prior to this change를 선택하여 히스토리를 더 거슬러 추적하거나, Ignore specific revisions를 선택하여 특정 커밋을 blame 뷰에서 제외할 수 있습니다.

11. 재설계된 리포지터리 커밋 목록

기존에는 리포지터리 커밋 목록의 필터링 기능이 제한적이어서 긴 히스토리에서 특정 커밋을 찾기가 어려웠습니다. 재설계된 커밋 목록은 다음을 포함합니다.

• 작성자, 커밋 메시지, 날짜 범위로 커밋을 필터링하고 검색할 수 있습니다.
• 브랜치, 태그, 커밋 SHA 등 Git 리비전(Revision)으로 목록을 필터링할 수 있습니다.
• 커밋이 일별로 그룹화되어 더 쉽게 훑어볼 수 있습니다.
• 대규모 리포지터리에 대한 성능과 페이지네이션(Pagination)이 개선되었습니다.

12. UI의 Stacked Merge Requests

기존에는 큰 변경을 서로 의존하는 작은 Merge request로 분할할 때, UI가 이들이 관련되어 있다는 신호를 전혀 주지 않아 작성자와 리뷰어가 그 순서를 수동으로 추적해야 했습니다. 이제 GitLab이 Stacked Merge Requests를 자동으로 감지하여 Merge request 헤더에 표시합니다. 어떤 Merge request가 다른 열린 Merge request의 소스 브랜치를 타깃으로 하거나, 다른 열린 Merge request가 해당 소스 브랜치를 타깃으로 하면 스택에 합류합니다. 소스 브랜치 옆의 스택 컨트롤은 현재 위치(예: "1 of 2")를 보여 주고 스택 내 다른 Merge request로 이동할 수 있게 해 줍니다. 명령줄에서 Stacked Merge Requests를 생성하려면 GitLab CLI의 Stacked Diffs를 사용하면 됩니다.

13. AI 감사 이벤트 외부 대상 스트리밍 (베타)

이제 GitLab 감사 이벤트 스트리밍 인프라를 통해 AI 감사 이벤트를 외부 대상으로 스트리밍할 수 있어, 보안 및 컴플라이언스팀이 LLM 및 AI 상호작용에 대한 실시간 가시성을 확보할 수 있습니다.

AI 감사 이벤트 스트리밍을 활성화하면, GitLab이 이러한 이벤트를 다른 감사 이벤트와 함께 SIEM(Security Information and Event Management)을 포함한 모든 활성 인스턴스 스트리밍 대상으로 전달합니다.

---

업그레이드 안내

GitLab을 업데이트하려면 업그레이드 가이드를 참조하세요.

인포그랩은 GitLab의 공식 파트너사로서 릴리즈 노트를 번역하여 제공합니다.

원문 바로가기

GitLab 버전별 상세 기능을 확인하세요.

인포그랩의 기술지원 서비스를 받으세요!

완벽한 GitLab 구축부터 성공적인 DevOps 도입까지! 인포그랩과 DevOps 라이프사이클을 함께 하세요.