gitlab·2026년 7월 16일·5분 읽기큐레이션 요약

GitLab 19.2 릴리스 노트 | GitLab Docs

GitLab 19.2는 GitLab Duo와 AI 에이전트 기능을 중심으로 개발·보안·운영 자동화를 강화한 릴리스입니다. Duo CLI와 커스텀 플로우가 정식 출시되었고, 정책 기반 예약 파이프라인과 Agentic Chat 연동이 추가되었습니다. 또한 의존성 취약점 자동 수정, 비기본 브랜치 취약점 추적, 하위 그룹 단위의 Duo 접근 제어가 베타 또는 정식 기능으로 제공됩니다. ## GitLab Duo CLI 정식 출시 - 터미널에서 GitLab Duo Agent Platform을 사용할 수 있습니다. - 코드베이스에 대한 복잡한 질문을 하거나 변경 작업을 자율적으로 수행하도록 요청할 수 있습니다. - 외부 AI 도구와 달리 GitLab 프로젝트, 파이프라인, 에이전트 설정을 문맥으로 활용합니다. - 주요 기능: - 대화형 모드와 CI/CD용 헤드리스 모드 - 모델 선택 및 세션 공유 - 도구 실행 승인 - MCP(Model Context Protocol) 연결 - 슬래시 명령어와 컨텍스트 사용량·압축 관리 - `AGENTS.md`와 스킬을 활용한 사용자 정의 - `glab`을 통해 설치하거나 독립 실행형 도구로 설치할 수 있습니다. - GitLab Self-Managed와 Dedicated에서는 관리자가 기능을 켜거나 끌 수 있습니다. ## GitLab Duo 커스텀 플로우 정식 출시 - 여러 단계로 구성된 AI 기반 작업 흐름을 YAML로 정의하고 재사용할 수 있습니다. - GitLab 이벤트에 따라 반복적인 개발·운영 작업을 자동 실행합니다. - 주요 기능: - 팀별 YAML 워크플로 - 복잡한 작업을 위한 멀티 에이전트 오케스트레이션 - 승인이나 피드백을 받는 HITL(Human-in-the-loop) 체크포인트 - 멘션, 담당자 지정, 파이프라인, 머지 리퀘스트 이벤트 트리거 - 프로젝트 또는 AI Catalog에서 플로우 생성·관리 - 공개·비공개 가시성 설정 - 서비스 계정과 복합 ID를 이용한 보안 실행 - 실행 전 YAML 검증 - GitLab CI/CD 안에서 실행되므로 별도 외부 자동화 플랫폼 없이 운영할 수 있습니다. ## 예약 파이프라인 실행 정책 정식 출시 - 보안 정책 프로젝트에서 일정을 한 번 정의하면 범위 내 여러 프로젝트에 강제 적용할 수 있습니다. - 각 프로젝트의 `.gitlab-ci.yml`을 직접 수정하지 않아도 됩니다. - 커밋 활동과 무관하게 일·주·월 단위로 다음 작업을 실행할 수 있습니다. - 컴플라이언스 검사 - 보안 스캔 - 의존성 취약점 점검 - 각 정책은 별도 파이프라인으로 실행됩니다. - 시간대, 실행 시간 분산 범위, 대상 브랜치를 설정할 수 있습니다. - 코드 변경이 드문 저장소에서도 새롭게 발견된 취약점을 주기적으로 탐지하는 데 유용합니다. ## Agentic Chat에서 기본 플로우 시작 - 기존에는 특정 UI 동작, 멘션, 담당자 지정 등을 통해 시작하던 기본 플로우를 Agentic Chat 대화 중에도 실행할 수 있습니다. - 요청 내용에 맞춰 전문 플로우로 넘길 수 있습니다. - Developer Flow: 코드 변경 또는 머지 리퀘스트 생성 - Code Review Flow: 머지 리퀘스트 검토 - Fix CI/CD Pipeline Flow: 실패한 파이프라인 진단 및 수정 - 사용자가 채팅에서 전환을 승인한 뒤, 대화창이나 **AI > Sessions**에서 진행 상황을 확인합니다. ## 의존성 스캔 자동 수정 베타 - 취약한 의존성을 자동으로 수정하는 두 가지 기능이 추가되었습니다. - 자동 의존성 버전 업데이트: - 취약한 의존성을 안전한 버전으로 올리는 머지 리퀘스트를 자동 생성합니다. - 기본적으로 패치 및 마이너 버전 업데이트를 대상으로 합니다. - Agentic Breaking Change Resolution: - 의존성 업데이트 후 파이프라인이 주요 변경 사항으로 실패하면 GitLab Duo가 원인을 분석합니다. - 파이프라인 오류, 의존성 변경 로그, 프로젝트의 실제 사용 방식을 함께 검토합니다. - 같은 머지 리퀘스트에 수정 사항을 커밋하고 파이프라인을 통과할 때까지 재실행합니다. - 활성화하면 메이저 버전 업데이트도 대상에 포함됩니다. - GitLab Credits를 사용합니다. - 결과적으로 GitLab이 수정 머지 리퀘스트를 생성하고, Duo가 복잡한 호환성 문제까지 해결하는 자동화된 보안 수정 흐름을 제공합니다. ## 비기본 브랜치 취약점 추적 베타 - 기본 브랜치 외에도 장기 유지되는 릴리스·배포 브랜치의 취약점을 추적할 수 있습니다. - 예시는 다음과 같습니다. - `project-qa` - `project-prod` - `project-iOS` - `project-android` - 보안 설정에서 추적 브랜치를 추가할 수 있으며, 네임스페이스 프로젝트 수의 최대 두 배까지 등록할 수 있습니다. - 취약점 보고서와 프로젝트 보안 대시보드에서 브랜치별 필터링을 지원합니다. - CVE를 포함한 모든 취약점 유형을 추적합니다. - 브랜치가 기본 브랜치에 병합될 때 취약점 상태 메타데이터를 일관되게 유지합니다. - 추적 브랜치의 취약점 상태도 갱신할 수 있습니다. - 사용 브랜치는 너무 많이 지정하기보다 환경별·플랫폼별 장기 브랜치로 제한하는 것이 권장됩니다. ## 하위 그룹별 GitLab Duo 접근 제어 - GitLab Dedicated 및 Dedicated for Government 관리자는 특정 하위 그룹에서 Duo와 Duo Agent Platform을 제한할 수 있습니다. - 기존에는 전체 인스턴스에서 비활성화하거나 모든 그룹에서 사용 가능하게 하는 방식만 제공되었습니다. - 이제 하위 그룹별 기본 거부(default-deny) 및 허용 목록(allowlist) 정책을 적용할 수 있습니다. - 특정 그룹을 **Always off**로 잠그면 하위 그룹과 프로젝트에서도 기능을 활성화할 수 없습니다. - 다른 그룹은 Owner 권한 사용자의 선택에 맡길 수 있습니다. - 잠금 설정과 해제는 관리자만 수행할 수 있으며, 영향을 받는 Owner에게는 상위 그룹 정책으로 기능이 잠겼다는 안내가 표시됩니다. - 조직의 규정 준수와 AI 기능 사용 범위에 대한 플랫폼 거버넌스를 세밀하게 관리할 수 있습니다. ## 실용적인 적용 방향 - 개발팀은 Duo CLI와 Agentic Chat을 코드 작성, 코드 리뷰, 실패한 파이프라인 수정에 활용할 수 있습니다. - 보안팀은 예약 파이프라인 정책과 의존성 자동 수정으로 지속적인 취약점 대응 체계를 구성할 수 있습니다. - 릴리스 브랜치를 운영하는 조직은 비기본 브랜치 추적을 제한적으로 적용하는 것이 좋습니다. - 규제 환경에서는 하위 그룹별 Duo 허용 정책을 사용해 AI 기능을 조직 단위로 통제하는 것이 적합합니다.

원문 읽기(새 탭에서 열림)

gitlab모델 컨텍스트 프로토콜vulnerability-managementyaml+4

gitlab·2026년 7월 16일·3분 읽기큐레이션 요약

GitLab Duo Agent Platform을 터미널로 가져오세요

GitLab 19.2에서 GitLab Duo CLI가 정식 출시되어, 코드 작성뿐 아니라 파이프라인 실패·테스트·보안 취약점·CI/CD 작업까지 터미널에서 처리할 수 있게 됐다. GitLab 프로젝트와 파이프라인, 에이전트 설정 및 권한 정보를 이미 알고 있어 별도 도구보다 더 일관된 컨텍스트를 제공한다. 대화형 모드와 CI·스크립트용 헤드리스 모드를 모두 지원하며, 터미널·GitLab UI·에디터 간 세션도 공유된다. ## 터미널 중심 개발의 필요성 - 기존 에이전트형 AI는 파일 편집과 코드 생성에 집중되어 있었다. - 실제 소프트웨어 전달 과정에서는 다음과 같은 문제가 자주 발생한다. - 파이프라인 실패 - 테스트 오류 - 의존성 문제 - CI 설정 오류 - 보안 취약점 - 이러한 문제의 핵심 컨텍스트는 로컬 코드보다 GitLab 프로젝트와 파이프라인에 있기 때문에, 일반적인 코딩 전용 CLI 도구로는 충분히 대응하기 어렵다. - 외부 CLI 도구를 사용하면 조직 단위 관리자 제어, MCP 설정 진단, GitLab 전체 에이전트 생명주기와의 통합이 부족할 수 있다. ## GitLab Duo CLI의 주요 기능 - 터미널에서 코드 탐색, 리팩터링, CI/CD 정리, 파이프라인 장애 분석, 다단계 작업을 수행할 수 있다. - GitLab UI, Duo CLI, 에디터 확장 기능 사이에서 세션과 대화가 공유된다. - 브라우저에서 시작한 작업을 터미널에서 이어갈 수 있다. - 동일한 프로젝트 맥락과 대화 내용을 유지할 수 있다. - GitLab.com, GitLab Self-Managed, GitLab Dedicated에서 사용할 수 있다. - Self-Managed와 Dedicated 환경에서는 관리자가 인스턴스 단위로 접근을 활성화하거나 비활성화할 수 있다. - `/doctor` 명령으로 설치·환경 설정을 점검하고, `/mcp` 명령으로 MCP 구성을 확인할 수 있다. ## 계획 모드와 빌드 모드 - **Plan 모드** - 코드베이스와 관련 상황을 조사한다. - 파일을 변경하지 않고 해결 방법을 먼저 계획한다. - **Build 모드** - 사용자가 승인한 뒤 실제 코드나 설정을 변경한다. - 대화형 세션에서는 도구 실행 전에 승인을 요청하므로, 변경 사항을 검토하면서 작업할 수 있다. ## 헤드리스 모드와 자동화 - 헤드리스 모드는 사용자의 입력이나 승인 없이 실행되는 비대화형 방식이다. - CI 러너, 셸 스크립트, 자동화 작업에 적합하다. - 다음 명령으로 목표를 전달해 실행할 수 있다. ```bash glab duo cli run --goal duo run --goal ``` - 예를 들어 현재 셸에서 다음과 같이 특정 머지 리퀘스트의 파이프라인 실패 원인 분석과 수정안을 요청할 수 있다. ```bash glab duo cli > The pipelines in MR 23 are failing. Please help me fix them. ``` - Duo CLI는 관련 상황을 분석하고 수정안을 제안한 뒤, 적용 전에 검토할 수 있도록 한다. ## 설치와 실행 방식 - GitLab CLI를 사용하는 가장 간단한 방법은 다음 명령이다. ```bash glab duo cli ``` - `glab`이 인증을 처리하므로 별도의 인증 절차를 줄일 수 있다. - Duo CLI를 독립 도구로 설치하고 개인 액세스 토큰으로 실행하는 방식도 제공된다. ```bash duo ``` - 두 방식 모두 대화형 모드와 헤드리스 모드 등 동일한 기능을 지원한다. ## 프로젝트 지침과 확장성 - Duo CLI는 프로젝트 또는 조직의 사용자 지정 지침을 따를 수 있다. - 지원되는 지침 파일의 예시는 다음과 같다. - `chat-rules.md` - `AGENTS.md` - `SKILL.md` - 대화형 세션에는 사용자 정의 슬래시 명령을 추가할 수 있어 팀의 반복적인 작업 흐름을 확장할 수 있다. ## 실용적인 활용 방법 GitLab CLI를 이미 사용 중인 팀은 `glab duo cli`부터 도입하는 것이 좋다. 먼저 Plan 모드로 파이프라인이나 CI 설정 문제를 분석한 뒤 Build 모드에서 변경을 승인하고, 반복 작업은 `run --goal`을 이용해 CI나 스크립트에 연결하면 된다. 관리자는 Self-Managed·Dedicated 환경에서 접근 권한과 MCP 구성을 점검한 후 단계적으로 배포할 수 있다.

원문 읽기(새 탭에서 열림)

AI 에이전트CI/CD모델 컨텍스트 프로토콜DevSecOps+2

gitlab·2026년 7월 16일·3분 읽기큐레이션 요약

GitLab Duo Security Review, 스캐너가 놓치는 논리 결함 발견

정적 보안 스캐너는 SQL 인젝션이나 하드코딩된 비밀처럼 알려진 패턴에는 강하지만, 애플리케이션의 권한 모델과 업무 흐름을 이해해야 발견할 수 있는 논리적 취약점에는 한계가 있습니다. GitLab Duo Security Review의 Security Review Flow는 MR의 변경 내용을 주변 코드와 함께 분석해 권한 누락, 정보 노출, 비즈니스 로직 오류, 경쟁 조건 등을 찾아냅니다. 퍼블릭 베타 단계이며, 기존 스캐너와 수동 보안 검토를 보완하는 용도로 설계되었습니다. ## 패턴 기반 스캐너가 놓치는 취약점 - 코드 한 줄만 보면 정상적으로 보이지만, 애플리케이션의 도메인 규칙을 위반하는 문제가 주요 대상입니다. - **접근 제어 및 권한 문제** - 객체 ID만 바꿔 다른 사용자의 데이터를 조회하는 BOLA(Broken Object Level Authorization) - 관리자 전용 기능이나 상태 변경 작업에 대한 권한 검사 누락 - **데이터 노출** - 객체를 직렬화해 반환하는 코드는 문법상 문제가 없어도, 민감한 필드가 포함되면 정보 노출이 발생할 수 있습니다. - 어떤 필드가 민감한지, 어떤 사용자가 받아도 되는지는 도메인 지식이 필요합니다. - **제어 흐름과 업무 로직** - 결제 없이 주문 완료 단계에 접근 - 가격을 결정하는 파라미터를 조작 - 특정 상태에 반복 진입 - 동시 요청으로 상태 검증을 우회하는 경쟁 조건(race condition) ## MR마다 보안 판단을 적용하는 Security Review Flow - GitLab Duo Agent Platform의 기능으로, 코드 변경 시점에 보안 검토를 수행합니다. - 다음 유형의 문제를 탐지하도록 설계되었습니다. - 객체 수준 및 함수 수준 권한 우회 - 상태 변경 작업의 권한 검사 누락 - 정보 노출 및 대량 할당(mass assignment) - 비즈니스 로직 오류 - 상태 기반 워크플로의 경쟁 조건 - 수동 보안 리뷰나 침투 테스트를 대체하지 않고 보완합니다. - 수정 비용이 낮은 MR 단계에서 문제를 발견하는 것이 목적이며, GitLab 애플리케이션 보안팀도 내부 MR에 사용해 왔습니다. ## 변경 내용과 주변 맥락을 함께 분석 - MR의 diff뿐 아니라 다음 정보를 함께 검토합니다. - 원본 파일 - 변경된 코드 - MR 토론 내용 - 관련 코드 - 보안 엔지니어처럼 코드의 의도와 실행 흐름을 추론합니다. - 별도의 검증 단계가 각 발견 사항을 다시 점검해 오탐 가능성을 줄입니다. - 발견 결과는 관련 코드 라인의 diff 스레드와 내부 노트에 표시됩니다. - 퍼블릭 프로젝트에서는 보안 세부 정보가 외부에 노출되지 않도록 내부 노트에만 결과가 기록됩니다. ## 발견 사항과 MR 처리 방식 각 결과에는 다음 정보가 포함됩니다. - 취약점 유형과 CWE(Common Weakness Enumeration) 참조 - 심각도: Critical, High, Medium, Low - 분류 등급 - Tier 1: 악용 가능성이 높은 취약점 - Tier 2: 논리적 결함 - Tier 3: 설계 문제 - 문제에 대한 평이한 설명 - 가능한 경우 제공되는 수정 제안 심각도에 따라 MR 상태도 달라집니다. - Critical 또는 High: `Request changes` - Medium 또는 Low: `Comment` - 취약점이 발견되지 않아도 자동 승인하지 않으며, 최종 승인은 항상 사람이 담당합니다. 발견된 문제는 수정 제안 적용, 오탐으로 기각, 위험 수용 중 하나로 처리할 수 있습니다. 수정 후에는 새 검토를 요청해 변경 사항이 해결되었는지 다시 확인합니다. ## 도입 대상과 비용 - Security Review Flow는 GitLab Ultimate 고객을 위한 퍼블릭 베타 기능입니다. - GitLab.com, Self-Managed, Dedicated 환경에서 사용할 수 있습니다. - GitLab Duo Agent Platform 무료 체험 또는 Ultimate 구독에 포함된 GitLab Credits로 이용할 수 있습니다. - 비용은 diff의 복잡도와 선택한 모델에 따라 달라지므로, 전체 적용 전에 일부 MR에서 시험하는 것이 권장됩니다. - 베타 이후 가격은 변경될 수 있습니다. 실무에서는 기존 SAST·시크릿 스캐너를 계속 사용하면서, 인증·인가와 상태 전이가 복잡한 MR에 Security Review Flow를 추가하는 방식이 적절합니다. 특히 결제, 계정 권한, 개인정보, 멀티테넌트 데이터처럼 업무 규칙 위반의 영향이 큰 변경부터 적용하는 것이 효과적입니다.

원문 읽기(새 탭에서 열림)

DevSecOpsai-securitygitlab-duostatic-analysis+4

gitlab·2026년 7월 16일·3분 읽기큐레이션 요약

버전 업으로 빌드가 깨졌을 때 GitLab이 해결해 줍니다

GitLab의 Dependency Scanning Auto-Remediation은 취약한 의존성을 자동으로 업그레이드하고, 버전 변경으로 빌드가 깨지면 AI가 코드까지 수정하는 기능이다. 수정 사항은 동일한 머지 리퀘스트에서 검토되며, 기존 승인 절차와 감사 기록을 그대로 따른다. 이를 통해 개발자가 보안 취약점 수정에 직접 많은 시간을 쓰지 않고도 컴플라이언스 기한 내에 대응할 수 있다는 것이 글의 결론이다. ## 의존성 보안 백로그가 증가하는 이유 - 취약하거나 오래된 외부 컴포넌트는 OWASP Top 10에 포함되는 대표적인 위험 요소다. - Maven 생태계 조사에 따르면 최신 릴리스에 유입되는 취약점의 약 63%가 직접 의존성이 아닌 전이적 의존성에서 발생했다. - 취약점 수정은 기능 개발과 경쟁하는 수작업이어서, 특히 PCI-DSS와 FedRAMP의 30일 기한을 넘기는 고위험 취약점이 생기기 쉽다. - 의존성 업데이트 8건 중 약 1건은 호환성이 깨지는 변경을 포함하며, “하위 호환”으로 표시된 업데이트도 실제 프로젝트의 빌드를 깨뜨릴 수 있다. - AI를 활용한 익스플로잇 개발과 무기화가 빨라지면서 취약점을 장기간 방치할 위험도 커지고 있다. ## 취약점 발견부터 수정까지 자동화 - SBOM 기반 의존성 스캐닝이 수정 가능한 취약점을 발견하면, GitLab이 가장 가까운 안전 버전으로 올리는 머지 리퀘스트를 자동 생성한다. - 적절한 수정 버전이 없으면 무리하게 변경하지 않고 취약점을 보고서에 유지한다. - 자동 생성된 머지 리퀘스트는 전용 서비스 계정으로 작성되어 변경 주체를 추적할 수 있다. - 취약점의 심각도, 허용할 업데이트 범위(패치·마이너·메이저)를 설정할 수 있다. - 특정 취약점에 대해서는 취약점 보고서에서 사용자가 직접 자동 수정을 실행할 수도 있다. ## AI 기반 breaking change 해결 - 버전 업그레이드 후 파이프라인이 실패하면 GitLab Duo Agent Platform이 자동으로 원인을 분석한다. - 분석 대상에는 다음이 포함된다. - 파이프라인 오류 메시지 - 의존성의 변경 로그 - 프로젝트 코드에서 해당 의존성을 사용하는 방식 - AI는 같은 머지 리퀘스트 안에서 필요한 애플리케이션 코드 수정 커밋을 추가한다. - 수정 후에도 파이프라인이 통과하지 않으면 자동으로 중단하고, 분석 결과를 머지 리퀘스트에 남겨 개발자가 이어서 처리할 수 있게 한다. - 지원 생태계는 Bundler, Maven, Gradle, 주요 Python 및 JavaScript/TypeScript 패키지 관리자이며, Rust와 Go 지원도 예정되어 있다. ## 검토와 감사 절차를 유지하는 자동화 - 자동 수정은 절대로 자체적으로 병합되지 않는다. - 모든 변경은 기존 리뷰어 승인과 브랜치 보호 규칙을 거친다. - 머지 리퀘스트에는 다음 정보가 명시된다. - 어떤 취약점을 해결하는지 - 어떤 버전으로 업데이트하는지 - 빌드를 통과시키기 위해 AI가 제안한 코드 변경 - 변경 내용, 승인자, 승인 과정이 감사 기록으로 남아 보안 및 규제 대응에 활용할 수 있다. - 자동화는 조직 자체의 파이프라인에서 실행되므로 기존 접근 제어와 승인 게이트를 상속한다. ## 자동화 폭주를 막는 안전장치 - 쿨다운 기간을 설정해 모든 파이프라인마다 새로운 수정 작업이 생성되는 것을 방지한다. - 닫힌 머지 리퀘스트는 더 최신 수정 버전이 등장하지 않는 한 다시 만들지 않는다. - 프로젝트 또는 그룹 단위 구성 프로필로 조직의 위험 허용 수준에 맞게 정책을 관리할 수 있다. - 기능은 현재 퍼블릭 베타이며 GitLab.com에서 제공되고, GitLab Self-Managed와 Dedicated에도 순차적으로 적용된다. - 자동 버전 업데이트는 GitLab Ultimate에 추가 비용 없이 포함된다. AI 기반 breaking change 해결은 GitLab Duo Agent Platform의 무료 체험 또는 Ultimate에 포함된 GitLab Credits로 이용할 수 있다. ## 실용적인 적용 권장 사항 - 먼저 패치·마이너 업데이트만 허용해 자동화 범위를 제한하고, 안정화 후 메이저 업데이트로 확대하는 것이 안전하다. - AI가 작성한 코드도 반드시 일반 코드 리뷰와 테스트를 거쳐야 한다. - PCI-DSS나 FedRAMP처럼 기한이 명확한 환경에서는 고위험 취약점과 전이적 의존성을 우선 대상으로 삼는 것이 효과적이다.

원문 읽기(새 탭에서 열림)

AICI/CDgitlabPython+4

gitlab·2026년 7월 16일·3분 읽기큐레이션 요약

다단계 소프트웨어 딜리버리를 신뢰할 수 있는 에이전틱 플로우로 전환하세요

GitLab 19.2에서 Custom Flows가 정식 출시되며, 반복적인 소프트웨어 개발 절차를 AI 기반 워크플로로 정의하고 자동 실행할 수 있게 되었습니다. 팀은 이슈 구현, 파이프라인 오류 수정, 머지 리퀘스트 검토 같은 다단계 작업을 GitLab 이벤트나 Agentic Chat에서 시작하고, 사람은 승인과 중요한 판단에 집중할 수 있습니다. 이를 통해 개인의 기억과 수작업에 의존하던 런북을 일관된 자동화로 전환합니다. ## 다단계 개발 작업이 수작업으로 남는 이유 - 실제 소프트웨어 개발은 단일 명령으로 끝나지 않습니다. - 작업 맥락 수집 - 코드 수정 - 머지 리퀘스트 생성 - CI 결과 대기 - 리뷰 의견 반영 - 기존의 AI 채팅은 답변만 제공하므로 각 단계의 실행과 인계는 사용자가 직접 처리해야 합니다. - 사내 스크립트는 접근 권한, 트리거, 리뷰 정책이 변경되어도 자동으로 따라가지 못합니다. - 그 결과 팀이 반복적으로 수행하는 절차가 자동화되지 못하고 개인의 경험이나 팀 내 구두 지식에 머물렀습니다. ## Custom Flows를 통한 워크플로 자동화 - Custom Flows는 한 번 정의한 다단계 작업을 GitLab 플랫폼에서 실행합니다. - 다음과 같은 GitLab 이벤트를 트리거로 사용할 수 있습니다. - 멘션 - 작업 할당 - 파이프라인 상태 변화 - 머지 리퀘스트 생명주기 - 워크 아이템 변경 - 워크 아이템 상태 변경 - 예를 들어 다음과 같은 자가 복구 파이프라인을 자동화할 수 있습니다. - 실패한 테스트 분석 - 수정 코드 생성 - 변경 사항 커밋 - 팀에 결과 알림 - 복합 ID(composite identity)로 실행되므로 권한 범위를 제한하고 각 작업의 실행 주체를 추적할 수 있습니다. - 민감한 단계에는 사람의 승인을 요구하는 human-in-the-loop 체크포인트를 추가할 수 있습니다. ## Agentic Chat에서 전문 플로우 실행 - 사용자가 Agentic Chat에 작업을 설명하면 요청 내용에 맞는 Foundational Flow를 추천합니다. - 사용자는 실행을 승인한 뒤 대화 화면에서 진행 상황을 확인할 수 있습니다. - 대표적인 전문 플로우는 다음과 같습니다. - **Developer Flow**: 이슈나 변경 요청 구현 - **Code Review Flow**: 머지 리퀘스트 검토 - **Fix CI/CD Pipeline Flow**: 실패한 파이프라인 진단 및 수정 - 기존 채팅형 AI와 달리, 사용자가 각 중간 단계를 직접 클릭하거나 복사할 필요 없이 전체 작업이 GitLab 안에서 이어집니다. ## 코드 리뷰 자동화 제어 - 자동 코드 리뷰를 모든 머지 리퀘스트에 적용하지 않도록 제외 규칙을 설정할 수 있습니다. - 봇이 작성한 머지 리퀘스트나 특정 브랜치 패턴을 검토 대상에서 제외해 불필요한 크레딧 소비를 막습니다. - 사용자 정의 리뷰 지침을 통해 팀의 기준에 맞는 검토가 가능합니다. - 따라서 어떤 머지 리퀘스트를 리뷰할지뿐 아니라 무엇을 중점적으로 검사할지도 지정할 수 있습니다. ## 설정과 확장 기능 - Custom Flow는 프로젝트 또는 AI Catalog에서 생성할 수 있습니다. - 공개 범위를 정하고 필요한 프로젝트에서 활성화한 뒤, 적절한 GitLab 이벤트를 연결합니다. - GitLab 19.2에서는 공개 플로우를 최대 100개 프로젝트에 일괄 활성화할 수 있습니다. - 향후에는 Flow Creation Agent가 제공될 예정입니다. - 사용자가 자연어로 원하는 작업 절차를 설명하면 - 전체 스키마를 직접 작성하지 않아도 실행 가능한 플로우 정의를 생성하는 방식입니다. ## 도입 시 고려할 점 - 이벤트 기반 플로우는 수행한 작업량에 따라 크레딧을 소비합니다. - 처음부터 대규모 그룹 전체에 적용하기보다는 몇 개 프로젝트에서 먼저 테스트하는 것이 권장됩니다. - 자동화 범위가 넓어질수록 권한 설정, 승인 단계, 제외 규칙을 함께 설계해야 합니다. - GitLab Duo Agent Platform 무료 체험이나 Premium·Ultimate 구독에 포함된 GitLab Credits로 사용할 수 있습니다. 작업 절차가 반복적이고 팀마다 동일하게 수행된다면 Custom Flows로 먼저 인코딩하는 것이 좋습니다. 특히 이슈 구현, CI 오류 복구, 코드 리뷰처럼 단계가 명확한 업무부터 도입하고, 크레딧 사용량과 승인 지점을 확인한 뒤 적용 범위를 넓히는 방식이 실용적입니다.

원문 읽기(새 탭에서 열림)

AI 에이전트CI/CDgitlab-duo-agent-platformagentic-workflows+3

gitlab·2026년 7월 9일·4분 읽기큐레이션 요약

그린 DevOps: 탄소 측정이 CI/CD 파이프라인에 포함되어야 하는 이유

CI/CD 파이프라인은 매일 상당한 컴퓨팅 에너지와 탄소를 소비하지만, 일반적인 파이프라인 지표에는 그 영향이 드러나지 않는다. 글은 GitLab에 Eco CI와 Carmen을 연동해 파이프라인·인프라·애플리케이션 수준의 탄소 배출량을 측정해야 한다고 주장한다. 측정만으로도 불필요한 테스트 실행, 의존성 재설치, 유휴 서비스 같은 낭비를 찾아 비용과 탄소 배출을 함께 줄일 수 있다. ## CI/CD 파이프라인에 탄소 측정이 필요한 이유 - 현대적인 개발 파이프라인은 하루에도 수백 개의 작업을 실행한다. - AI 기반 테스트, 코드 리뷰, 자동화 작업이 늘면서 과거보다 실행 작업과 에너지 소비가 증가했다. - 파이프라인 로그나 아키텍처 다이어그램에는 컴퓨팅에 따른 탄소 배출량이 표시되지 않는 경우가 많다. - 배출량을 줄이려면 먼저 파이프라인 실행별, 서비스별, 팟(pod)별 배출량을 측정해야 한다. - Green DevOps는 탄소 데이터를 엔지니어링 의사결정에 활용하는 실천 방식이다. ## 파이프라인 수준의 측정: Eco CI - Eco CI는 CI/CD 작업별 에너지 소비량과 탄소 배출량을 측정한다. - 별도 서버나 데이터베이스 없이 가벼운 Bash 스크립트로 실행할 수 있다. - 각 작업의 배출량을 확인하고, 자원 사용량이 큰 작업과 시간에 따른 추세를 파악할 수 있다. - README에 탄소 배출량을 보여주는 배지를 추가할 수도 있다. - 기존 GitLab 파이프라인에 몇 줄을 추가하는 방식이므로 도입 난도가 낮다. - 파이프라인 자체가 이미 관측 대상이므로, 초기 Green DevOps 도구로 적합하다. ## 인프라와 애플리케이션 수준의 측정: Carmen - Carmen(Carbon Measurement Engine)은 Green Software Foundation의 Impact Framework를 기반으로 한다. - Kubernetes에서 실행되는 가상 머신, 팟, 개별 애플리케이션 워크로드까지 측정한다. - 컴포넌트별 CSV 보고서를 생성하며 다음 탄소를 구분한다. - 운영 탄소: 전력 사용으로 발생하는 배출량 - 내재 탄소: 하드웨어 제조와 폐기 과정에서 발생하는 배출량 - 주요 출력 필드는 다음과 같다. - `EnergykWh`: 에너지 소비량 - `TotalCarbonGramsCO2eq`: CO₂ 환산 총 배출량 - 생성된 데이터는 Grafana, FinOps 대시보드, 사내 분석 도구에 직접 연결할 수 있다. - “어떤 서비스가 가장 많은 CO₂를 배출하는가?”, “API 게이트웨이와 데이터 처리 계층 중 어디가 더 큰가?” 같은 질문에 답할 수 있다. ## GitLab 파이프라인에 연동하는 방법 - Eco CI와 Carmen 모두 `.gitlab-ci.yml`에 직접 추가할 수 있다. - Carmen 예시는 다음 작업을 수행한다. - `python:3.12` 이미지 사용 - Node.js, npm, Git, `lsb-release` 설치 - Carmen 저장소를 Git으로 복제 - Impact Framework 관련 npm 패키지 설치 - Carmen을 Python 패키지로 설치 - `carbon-daemon` 실행 - 생성된 결과를 GitLab artifact로 보관 - 결과 artifact는 예를 들어 1주일 동안 보관한 뒤 다운로드해 첫 탄소 보고서로 활용할 수 있다. - Carmen 작업을 별도의 비차단(non-blocking) 작업으로 구성하면 기존 배포 경로를 지연시키지 않는다. ## 측정으로 발견할 수 있는 낭비 - 한 팀은 Eco CI 도입 후 통합 테스트가 전체 파이프라인 배출량에서 예상보다 큰 비중을 차지한다는 사실을 발견했다. - 원인은 테스트 코드가 아니라 매 실행마다 모든 의존성을 처음부터 다시 설치하는 설정이었다. - 의존성 캐시를 추가하면 다음 효과를 동시에 얻을 수 있다. - 테스트 실행 시간 단축 - CI 탄소 배출량 감소 - 개발자 대기 시간 감소 - CI 비용 절감 - Carmen을 스테이징 클러스터에 적용한 결과, 폐기된 기능의 데이터 처리 서비스가 유휴 상태로 계속 실행되고 있었다. - 해당 서비스를 제거함으로써 불필요한 운영 탄소와 내재 탄소 소비를 줄일 수 있었다. - 두 사례 모두 대규모 지속가능성 프로젝트가 아니라, 데이터 가시성에서 출발한 개선이었다. ## 낮은 도입 비용과 실질적인 효과 - Eco CI는 몇 줄의 설정과 Bash 스크립트만으로 추가할 수 있다. - 별도 인프라를 구축하지 않으며 파이프라인에 의미 있는 지연을 추가하지 않는다. - Carmen 역시 독립적인 작업으로 실행할 수 있어 기존 핵심 경로에 영향을 주지 않는다. - 측정 데이터는 향후 탄소 보고와 규제 대응을 위한 조직의 기준선(baseline)이 된다. - 탄소 배출이 적은 코드는 대체로 더 빠르고 저렴하다. - 의존성 캐시, 러너 규모 조정(right-sizing), 불필요한 서비스 제거는 환경 개선이면서 동시에 FinOps 최적화이기도 하다. ## 규제와 기업 요구사항 변화 - 탄소 인식형 엔지니어링은 선택적 활동에서 전문적인 개발 관행으로 자리 잡고 있다. - EU의 기업 지속가능성 보고 지침(CSRD)은 대기업에 클라우드 사용량을 포함한 가치사슬 전반의 배출량 공개를 요구한다. - 기업 고객도 공급업체 선정 과정에서 지속가능성 정책과 배출량 관리 여부를 확인하는 경우가 늘고 있다. - 법적 의무가 생긴 뒤 시작하기보다, 지금부터 작은 범위에서 측정 기준과 내부 운영 습관을 마련하는 편이 유리하다. Eco CI를 단일 GitLab 파이프라인에 먼저 적용해 작업별 탄소 배출량을 확인하고, 이후 Carmen으로 Kubernetes와 서비스 수준까지 범위를 확장하는 접근이 현실적이다. 특히 의존성 캐시, 유휴 리소스 제거, 러너 크기 조정처럼 비용과 성능도 함께 개선하는 항목부터 실행하는 것이 효과적이다.

원문 읽기(새 탭에서 열림)

쿠버네티스CI/CDgitlabDevOps+4

gitlab·2026년 7월 8일·4분 읽기큐레이션 요약

GitLab 패치 릴리스: 19.1.2, 19.0.4, 18.11.7 | GitLab 문서

2026년 7월 8일 GitLab은 CE/EE용 패치 버전 19.1.2, 19.0.4, 18.11.7을 출시했다. 이번 릴리스는 XSS·HTML 인젝션·권한 우회·자격 증명 노출 등 여러 보안 취약점과 버그를 수정했으며, 자체 호스팅 사용자는 즉시 업그레이드하는 것이 권장된다. GitLab.com은 이미 패치가 적용됐고, GitLab Dedicated 고객은 별도 조치가 필요 없다. ## 패치 릴리스와 업그레이드 권고 - 패치 릴리스는 정기 릴리스와 고위험 취약점에 대응하는 비정기 긴급 패치로 나뉜다. - 정기 패치는 매월 둘째·넷째 수요일에 배포된다. - 영향을 받는 모든 자체 관리형 설치 환경은 Omnibus, 소스 코드, Helm Chart 등 배포 방식과 관계없이 최신 패치 버전으로 업그레이드해야 한다. - 보안 취약점 상세 이슈는 수정 버전 출시 후 90일이 지나면 공개된다. ## 취약점: XSS와 HTML 인젝션 - **CVE-2026-6896** - GitLab EE의 취약점 증거 테이블 렌더러에서 사용자 입력 sanitization이 충분하지 않았던 문제다. - Developer 권한의 인증 사용자가 다른 사용자의 브라우저 세션에서 임의 스크립트를 실행할 수 있었다. - CVSS 8.7로 이번 릴리스에서 가장 심각한 취약점 중 하나다. - EE 13.11 이후 버전 중 18.11.7, 19.0.4, 19.1.2 이전 버전에 영향을 준다. - **CVE-2026-13320** - CE/EE의 Wiki 마크업 렌더링 과정에서 HTML 인젝션이 가능했던 문제다. - 인증 사용자가 다른 사용자의 브라우저 세션에서 스크립트를 실행할 수 있었다. - CVSS 7.3이며, 높은 권한과 특정 조건이 필요하다. - CE/EE 15.7 이후 버전 중 각 패치 버전 이전 릴리스가 영향을 받는다. ## 자격 증명 및 저장소 보안 문제 - **CVE-2026-11827** - EE 저장소 미러링 기능의 권한 검사가 부족했다. - Maintainer 권한 사용자가 다른 사용자의 저장된 자격 증명을 획득할 수 있었다. - CVSS 4.9이며, EE 9.5 이후 버전에 영향을 준다. - **CVE-2025-12506** - Git 태그·브랜치 이름 해석이 모호하게 처리되는 문제다. - 공격자가 웹 인터페이스에 표시되는 저장소 내용과 다운로드 가능한 실제 내용이 다르게 보이는 저장소를 만들 수 있었다. - CE/EE 16.5 이후 버전에 영향을 주며 CVSS는 3.5다. ## 권한 검증 및 정보 노출 문제 - **CVE-2026-8472** - EE Work Items 기능에서 비공개 프로젝트의 메타데이터 접근 권한 검사가 누락됐다. - 최소 권한을 가진 인증 사용자가 비공개 프로젝트의 Work Item 정보를 읽을 수 있었다. - CVSS 4.3이다. - **CVE-2026-7492** - 커밋 토론 표시와 프로젝트 간 참조 페이지에서 권한 검사가 제대로 이뤄지지 않았다. - 비인증 사용자가 비공개 프로젝트의 존재 여부를 추론할 수 있었다. - CE/EE에 영향을 주며 CVSS는 4.3이다. - **CVE-2026-13151** - EE 그룹 수준 설정에 대한 권한 검사가 부정확했다. - 인증 사용자가 자신의 권한 범위를 넘어 그룹 설정을 수정할 수 있었다. - CVSS 2.7이며 GitLab 내부에서 발견됐다. - **CVE-2026-6352** - EE의 컴플라이언스 위반 관리 GraphQL 작업에서 권한 검사가 부족했다. - Auditor 수준 사용자가 컴플라이언스 위반 기록을 수정할 수 있었다. - CVSS 2.7이다. ## 버그 수정 및 기술 변경 ### 19.1.2 - OAuth 애플리케이션 등록 및 생성 시 `organization_id`를 설정하도록 수정했다. - 제약 조건 검증 전에 `oauth_applications`의 `NULL organization_id` 값을 보완하는 백필을 추가했다. - Go 버전을 1.25.11로 업데이트했다. - 멀티 아키텍처 태그를 레거시 레지스트리 경로에서 처리할 때 발생하던 HTTP 500 오류를 수정했다. - 외부 에이전트 흐름에서 커밋 작성자와 커미터의 신원을 사용하도록 개선했다. - ClickHouse 23.x에서 `ci_finished_builds` 엔진 교체가 동작하도록 수정했다. - Duo Workflow 이벤트 조회를 최신 체크포인트로 제한하고 커서 페이지네이션을 적용했다. - Developer가 작성한 Merge Request의 승인 규칙 재정의 회귀 문제를 수정했다. - 커밋 설명을 지나치게 미리 가져오면서 발생하던 커밋 페이지 메모리 누수를 해결했다. - 더 이상 필요하지 않은 `ActiveUserCountThresholdWorker` cron 스케줄을 제거했다. - 레지스트리 인증, OAuth 처리, 빌더 이미지 리비전 등 관련 구성도 백포트 및 조정했다. ### 19.0.4 및 18.11.7 - 19.0.4에도 OAuth 애플리케이션 등록 시 `organization_id`를 설정하는 수정이 백포트됐다. - CI_JOB_TOKEN을 이용한 레지스트리 인증 방식과 같은 일부 수정 사항이 19.0 안정화 브랜치에 반영됐다. - 18.11.7은 위 보안 취약점들이 수정된 18.11 계열의 권장 패치 버전이다. ## 실용적인 권장 사항 자체 호스팅 GitLab 운영자는 현재 지원 중인 계열에 맞춰 **19.1.2, 19.0.4, 18.11.7 중 하나로 즉시 업그레이드**하는 것이 좋다. 특히 EE에서 저장소 미러링, Work Items, 컴플라이언스 관리, 취약점 증거 렌더링을 사용하는 환경은 패치 적용 전까지 권한과 외부 입력 처리 기능을 우선 점검해야 한다.

원문 읽기(새 탭에서 열림)

gitlabGraphQLoauthcross-site-scripting+4

gitlab·2026년 7월 8일·5분 읽기큐레이션 요약

AI 에이전트를 활용해 GitLab의 레이트 리미팅을 마이그레이션한 방법

GitLab은 3명의 엔지니어와 AI 에이전트를 활용해 레거시 애플리케이션·Rack 기반 레이트 리미팅을 `labkit-ruby` 단일 구현으로 통합했다. 에이전트는 코드 탐색, 사양 작성, 반복적인 구현과 테스트에는 효과적이었지만, 아키텍처 결정·점진적 롤아웃·관측성 설계·최종 판단은 여전히 사람의 책임이었다. 프로젝트의 성공을 결정한 것은 에이전트 자체보다 명확한 작업 루프, 작은 변경 단위, 점진적 배포, 그리고 실패를 되돌릴 수 있는 운영 체계였다. ## 레거시 레이트 리미팅 통합의 목표 - GitLab에는 다음 두 가지 레이트 리미팅 경로가 수년간 공존했다. - 애플리케이션 수준의 `Gitlab::ApplicationRateLimiter` - Rack 수준의 별도 레이트 리미터 - 목표는 두 시스템을 `labkit-ruby`의 단일 구현으로 통합하는 것이었다. - 새로운 구현은 다음 조건을 만족해야 했다. - 모든 요청에 적용될 만큼 안정적일 것 - 동작을 관측하고 테스트할 수 있을 것 - 장애 발생 시 되돌릴 수 있을 것 - 모놀리스와 다른 환경에서 동일하게 운영할 수 있을 것 - 기존 시스템에는 121개의 레이트 리미팅 키가 존재했다. ## 3명으로 구성된 포드와 AI 에이전트의 역할 - 포드는 세 명의 GitLab 엔지니어를 중심으로 구성됐다. - 모놀리스 측 구현과 롤아웃 담당 - `labkit-ruby`와 아키텍처 담당 - 범위 관리와 초기 gem 코드 작성 담당 - AI 에이전트는 다음 작업을 수행했다. - 코드와 기존 맥락 분석 - 기술 사양 초안 작성 - 범위가 제한된 변경 구현 - 테스트 작성 - 머지 리퀘스트 사전 검토 - GitLab Duo Code Review도 머지 리퀘스트의 품질 검토에 활용됐다. - 사람은 다음을 직접 맡았다. - 작업 범위 결정 - 아키텍처 설계 - 배포 및 롤아웃 판단 - 최종 리뷰와 승인 ## 사양-구현-검증 반복 루프 - 팀은 다음과 같은 엄격한 순서를 적용했다. 1. 에픽과 기존 코드 읽기 2. 사양 작성 3. 적대적 리뷰로 사양의 문제점 검토 4. 차단 이슈가 해결된 뒤 구현 5. 명시적인 증거를 바탕으로 검증 6. 머지 리퀘스트에 대한 적대적 리뷰 7. 필요 시 사람에게 에스컬레이션 8. 머지 - 적대적 리뷰는 최대 두 번의 해결 라운드까지만 허용하고, 이후에는 사람의 판단을 받도록 했다. - 프로젝트에서는 14개의 번호가 매겨진 사양과 30개가 넘는 `labkit-ruby` 머지 리퀘스트가 만들어졌다. - 레거시 코드처럼 맥락 파악과 반복 검증이 중요한 작업에서는 이처럼 제한된 루프가 에이전트 활용에 적합했다. ## 단계적 롤아웃과 에이전트가 잘한 작업 - 첫 번째 코호트에서는 트래픽이 많은 5개 키를 다뤘다. - `pipelines_create` - `notes_create` - `user_sign_in` - 그 외 주요 키 - 트래픽 비율을 `1% → 10% → 50% → 100%`로 단계적으로 높였고, 2026년 5월 5일 100% 배포를 완료했다. - 기존 `ApplicationRateLimiter`와 새 구현의 결과가 일치하는지 확인했지만, 단순히 불일치가 없다는 사실만으로 성공을 판단하지 않았다. - 실제로 제한에 걸릴 정도의 트래픽이 발생하지 않았을 가능성도 있기 때문이다. - 두 번째 코호트에서는 모놀리스 83개와 EE 12개를 포함한 95개 호출 지점을 두 개의 기능 플래그로 통합했다. - 이 작업을 수작업으로 했다면 약 95개의 플래그 변경과 190개의 YAML 수정이 필요했을 수 있지만, 에이전트는 이런 반복적인 코드베이스 전반의 변경에 특히 강했다. ## 관측성은 있었지만 실패 유형을 구분하지 못함 - 두 번째 코호트는 며칠간 섀도 모드에서 기존 구현과 비교되었고, 대체로 일치했다. - 그러나 강제 적용 모드로 전환한 뒤 인증되지 않은 일부 경로에서 식별자가 조용히 유실되는 문제가 발생했다. - 원인은 세 개의 `String` 값이 두 개의 원시 슬롯에 압축되면서 잘못된 값이 식별자를 덮어쓴 구조적 충돌이었다. - 일부 사용자는 짧은 시간 동안 일반적인 오류 메시지를 받았다. - 비교 시스템은 해당 키의 불일치를 이미 감지했지만, 대시보드가 다음을 구분하지 못했다. - 정상적인 동작 차이 - 데이터 구조 충돌 - 사용자에게 영향을 줄 수 있는 치명적 불일치 - 팀은 즉시 강제 적용 플래그를 끄고, 이틀 뒤 긴급 수정 사항을 배포했다. - 문제는 사양, 적대적 리뷰, 구현, 코드 리뷰, 점진적 롤아웃을 모두 통과했으므로, 단순히 “에이전트가 위험하다”기보다는 관측성이 충분히 세분화되지 않았던 것이 핵심 교훈이었다. ## 전체 키 인벤토리 관리의 실패 - 처음에는 다섯 개 코호트로 마이그레이션을 끝낼 계획이었다. - 마스터 브랜치 감사 과정에서 누락된 항목이 발견되어 여섯 번째 코호트를 추가했다. - Claude가 놓친 항목에는 다음이 포함됐다. - EE 전용 `notification_emails` - 일부 EE 레지스트리 항목 - 웹훅 관련 키 3개 - 1초 미만 주기의 `partner_*` 키 3개 - 고립된 어댑터 행 - 총 121개 키 중 17개가 초기 코호트에서 빠져 있었다. - 각 항목이 특정 코호트에 쉽게 들어가지 않는 이유는 있었지만, 목록에서 보이지 않아도 될 이유는 없었다. - 근본적인 실수는 에이전트와 사람이 전체 키 인벤토리 대비 진행 상황을 지속적으로 집계하도록 요구하지 않았다는 점이다. ## Redis 인프라 병목과 운영 판단 - `redis-cluster-ratelimiting`은 4개 샤드 클러스터로 운영됐다. - 마이그레이션으로 사용량이 증가하면서 기존에 알려져 있던 인프라 병목이 다시 나타났다. - 팀은 `maxclients`를 단계적으로 높였지만, 연결 수를 100,000까지 밀어붙이지 않고 75,000에서 중단했다. - 더 많은 연결을 허용하면 각 프라이머리의 CPU가 포화될 수 있었기 때문이다. - 각 샤드는 명령 실행에 하나의 코어를 사용했고, 수직 확장으로 해결할 여지도 제한적이었다. - 따라서 에이전트가 코드를 생성하더라도, 실제 배포 속도와 범위는 인프라 용량과 운영자의 판단에 의해 결정됐다. ## AI 에이전트가 바꾼 병목 - 에이전트 덕분에 코드 작성 자체는 더 이상 가장 느린 단계가 아니었다. - 대신 병목이 다음 영역으로 이동했다. - 사람의 리뷰 처리 용량 - 롤아웃 시점과 범위에 대한 판단 - 운영 중인 시스템을 주의 깊게 관찰하는 능력 - 에이전트는 요청하면 95개의 기능 플래그 같은 반복 작업도 만들어내지만, 그런 설계가 실제로 필요한지는 판단하지 못한다. - 예를 들어 코호트 1 이후 팀은 레이트 리미트마다 별도 기능 플래그를 두는 방식이 과도하다고 판단해 이후 마이그레이션에서는 적용하지 않기로 했다. - 에이전트와 협업하는 방법 자체도 학습이 필요했으며, 때로는 에이전트와 반복적으로 막혀 직접 처리하는 편이 빠르다고 느끼는 순간도 있었다. ## 최종 상태와 실용적인 교훈 - 2026년 6월 중순 기준으로 여섯 개 코호트가 모두 100% 롤아웃됐다. - `ApplicationRateLimiter`의 121개 키가 새 프레임워크를 통해 동작하게 되었고, 감사로 결과를 확인했다. - 이 사례에서 권장할 만한 방식은 다음과 같다. - 에이전트에는 반복적이고 범위가 명확한 변경을 맡긴다. - 아키텍처, 위험 허용 수준, 배포 중단 기준은 사람이 결정한다. - 전체 마이그레이션 대상을 인벤토리로 관리하고 누락 여부를 자동 검증한다. - 단순한 불일치 감지를 넘어 실패 원인과 심각도를 구분하는 관측성을 구축한다. - 기능 플래그와 점진적 롤아웃으로 즉시 되돌릴 수 있게 한다. - 코드 생성 속도가 빨라져도 리뷰와 운영 관찰에 필요한 사람의 시간을 충분히 확보한다.

원문 읽기(새 탭에서 열림)

AI 에이전트옵저버빌리티gitlab-duo-agent-platformredis+4

gitlab·2026년 7월 6일·4분 읽기큐레이션 요약

제한된 액세스로 GitLab 좌석을 관리하세요

GitLab의 **Restricted access**는 구매한 라이선스 좌석이 모두 사용된 뒤 새로운 과금 대상 사용자가 추가되는 것을 막아 좌석 초과와 예기치 않은 비용을 줄이는 기능입니다. SAML·SCIM·LDAP 기반 프로비저닝, OIDC/SSO 재로그인, 휴면 사용자 재활성화까지 처리 방식이 개선되어 자동화된 사용자 관리 환경에서도 더 안정적으로 사용할 수 있습니다. 다만 기존 초과 사용자를 자동으로 정리하지는 않으므로, 이미 발생한 초과분은 관리자가 별도로 해결해야 합니다. ## Restricted access의 역할 - GitLab.com과 Self-Managed에서 사용할 수 있는 좌석 제어 기능입니다. - 라이선스 좌석이 모두 소진되면 새로운 **과금 대상 사용자(billable user)** 추가를 차단합니다. - 좌석 초과를 사후에 되돌리는 기능이 아니라, 앞으로 발생할 추가 초과를 예방하는 기능입니다. - 프로젝트나 그룹 접근 없이 인증만 필요한 사용자는 **Minimal Access** 역할로 지정할 수 있습니다. - Minimal Access 사용자는 인증은 가능하지만 유료 좌석을 소비하지 않습니다. ## 기존 과금 사용자는 소급 적용되지 않음 - Restricted access를 이미 좌석 한도 초과 상태에서 활성화해도 기존 사용자는 영향을 받지 않습니다. - 기존 멤버가 자동으로 강등되거나 제거되거나 접근 차단되지 않습니다. - 관리자는 초과된 과금 사용자를 제거하거나 추가 좌석을 구매해 사용량을 한도 이내로 되돌려야 합니다. - 사용량이 한도 이내로 내려간 뒤부터 Restricted access가 추가적인 좌석 초과를 방지합니다. ## ID 프로바이더 기반 프로비저닝 개선 - 좌석이 없을 때 SAML, SCIM, LDAP로 프로비저닝된 사용자는 과금 역할로 바로 추가되지 않습니다. - 대신 자동으로 비과금 역할인 Minimal Access가 할당됩니다. - 중앙 집중식 계정 동기화를 유지하면서도 즉시 라이선스 초과가 발생하는 것을 막을 수 있습니다. - GitLab을 OIDC 프로바이더로 사용하는 경우, 인증만 필요한 사용자를 최상위 그룹에서 Minimal Access로 지정하는 방식이 유용합니다. - Minimal Access 사용자와 해당 역할만 가진 사용자는 좌석이 없어도 재활성화할 수 있습니다. ## 휴면 사용자 재활성화 문제 해결 - GitLab은 일정 기간 활동이 없는 사용자를 자동 비활성화해 좌석을 회수할 수 있습니다. - 이전에는 해당 사용자가 OIDC나 SSO로 다시 로그인하면 과금 사용자로 조용히 재활성화되어 좌석 초과가 발생할 수 있었습니다. - 이제 좌석이 부족하고 Restricted access가 활성화된 경우, 휴면 사용자는 **관리자 승인 대기 상태**로 전환됩니다. - 기존 그룹·프로젝트 멤버십은 유지됩니다. - 좌석이 확보되면 관리자가 사용자를 승인해 재활성화할 수 있습니다. ## 경고와 운영 가시성 강화 - LDAP 동기화, SAML 그룹 연결, SCIM 프로비저닝 설정 시 Restricted access의 동작을 안내하는 경고가 표시됩니다. - 좌석 한도에 접근 중인 상태와 한도에 도달한 상태가 제품 내에서 구분됩니다. - 좌석 부족으로 사용자가 Minimal Access로 배정되면 그룹 소유자나 인스턴스 관리자에게 이메일 알림이 전송됩니다. - Minimal Access로 전환된 이벤트는 감사 로그에서 확인할 수 있습니다. - 단순히 사용자 추가를 차단하는 것을 넘어, 왜 그런 처리가 발생했는지 추적하고 관리할 수 있게 개선되었습니다. ## Self-Managed의 설정 캐시 - GitLab Self-Managed는 성능을 위해 애플리케이션 설정을 기본적으로 60초간 캐시합니다. - Restricted access와 user cap 사이를 전환한 직후에는 UI나 좌석 제어 동작이 즉시 반영되지 않을 수 있습니다. - 캐시는 자동으로 갱신되며, 갱신 후에는 설정이 일관되게 적용됩니다. - 필요하다면 관리자가 캐시 간격을 조정할 수 있습니다. ## Restricted access와 user cap의 차이 - **User cap** - 좌석 여유 여부와 관계없이 새 사용자를 승인 대기 상태로 보냅니다. - 관리자나 그룹 소유자가 모든 신규 사용자 추가를 검토하는 승인 제어 기능입니다. - **Restricted access** - 라이선스 좌석이 모두 사용된 경우에만 신규 과금 사용자 추가를 제한합니다. - 구매한 좌석 수를 기준으로 동작하는 좌석 한도 제어 기능입니다. - 두 기능은 동시에 활성화할 수 없습니다. - Restricted access를 활성화하면 user cap은 자동으로 비활성화됩니다. - GitLab.com에서 user cap에서 Restricted access로 전환할 때 기존 대기 멤버의 상태가 영향을 받을 수 있으므로 전환 전에 관련 동작을 확인해야 합니다. ## 활성화 방법 - **GitLab.com** - `Settings > General > Permissions and group features > Seat control > Restricted access` - 그룹 Owner가 설정할 수 있습니다. - **Self-Managed** - `Admin > Settings > General > New user account restrictions > Seat control > Restricted access` - 관리자만 설정할 수 있습니다. - GitLab.com에서는 최상위 그룹이 외부 그룹과 공유된 경우 Restricted access를 사용할 수 없습니다. 자동 프로비저닝과 SSO를 사용하는 조직이라면 Restricted access를 활성화해 좌석 초과를 예방하는 것이 좋습니다. 다만 활성화 전 이미 발생한 초과 사용자는 별도로 정리하고, user cap과의 차이 및 기존 대기 사용자 처리 방식을 검토해야 합니다.

원문 읽기(새 탭에서 열림)

gitlabidentity-providersamlsingle-sign-on+4

gitlab·2026년 7월 1일·2분 읽기큐레이션 요약

GitLab 패치 릴리스: 18.8.11 | GitLab 문서

2026년 7월 1일 공개된 GitLab 18.8.11은 Rails 7.2 업그레이드로 발생한 데이터베이스 연결 누수 문제를 해결하는 패치 릴리스입니다. 데이터베이스 로드 밸런싱을 사용하는 환경의 안정성을 높이기 위한 긴급 패치이며, 보안 수정이나 신규 마이그레이션은 포함하지 않습니다. 다중 노드 배포에서는 일반적으로 다운타임 없이 업그레이드할 수 있습니다. ### 데이터베이스 연결 누수 수정 - 데이터베이스 로드 밸런서를 사용할 때 연결이 커넥션 풀로 정상 반환되지 않는 회귀 버그를 수정했습니다. - 해당 문제는 Rails 7.2 업그레이드 이후 발생했습니다. - 연결 누수가 지속되면 사용 가능한 데이터베이스 연결이 고갈되어 GitLab 성능 저하나 장애로 이어질 수 있습니다. - GitLab 18.8 필수 업그레이드 구간의 안정성을 확보하기 위해 정식 일정 외 패치로 제공되었습니다. ### 업그레이드 영향 - 신규 데이터베이스 마이그레이션은 포함되지 않습니다. - 다중 노드 배포 환경에서는 일반적으로 서비스 중단이 필요하지 않습니다. - Omnibus 패키지는 업그레이드 규모와 관계없이 기본적으로 다음 작업을 수행합니다. - GitLab 중지 - 마이그레이션 실행 - GitLab 재시작 - 업그레이드 시 자동 재구성을 건너뛰려면 다음 파일을 생성할 수 있습니다. ```text /etc/gitlab/skip-auto-reconfigure ``` - 이 설정은 업그레이드 작업에만 적용됩니다. ### 버전 및 구독 안내 - 대상 버전: - GitLab Community Edition 18.8.11 - GitLab Enterprise Edition 18.8.11 - 이번 릴리스에는 보안 수정 사항이 없습니다. - 업데이트 절차는 GitLab 공식 업데이트 페이지를 따라야 합니다. - Premium 및 Ultimate 기능은 유료 구독이 필요하며, 별도로 GitLab.com을 이용할 수도 있습니다. 데이터베이스 로드 밸런싱을 사용하는 GitLab 18.8 환경이라면 연결 고갈 위험을 줄이기 위해 18.8.11로 업데이트하는 것이 권장됩니다. અપ그레이드 전에는 자동 재구성 및 재시작 정책을 확인하고, 운영 환경에서는 공식 업데이트 절차에 따라 진행하는 것이 안전합니다.

원문 읽기(새 탭에서 열림)

gitlabdatabase-migrationsruby-on-railsdatabase-load-balancing+2

gitlab·2026년 6월 30일·3분 읽기큐레이션 요약

GitLab의 Claude Sonnet 5: 더욱 안정적이고 효율적으로

Claude Sonnet 5가 GitLab Duo Agent Platform에 모든 요금제와 배포 모델로 제공된다. GitLab 평가 제품군의 모든 벤치마크 작업을 완료한 첫 모델로, 이전 모델인 Sonnet 4.6의 93.8%보다 높은 안정성과 8.8% 더 많은 이슈 해결 성과를 보였다. GitLab은 이를 다단계 코딩 작업의 완주율과 결과 품질을 높이면서도 대규모 운영 비용을 낮출 수 있는 모델로 소개한다. ## GitLab Duo Agent Platform에 Claude Sonnet 5 출시 - Anthropic의 Claude Sonnet 5가 GitLab AI Gateway를 통해 GitLab Duo Agent Platform에 통합됐다. - 모든 GitLab 요금제와 배포 모델에서 사용할 수 있다. - 주요 대상은 다음과 같은 소프트웨어 개발 업무다. - 다단계 에이전트 작업 - 코드 생성 및 리뷰 대응 - 테스트 생성 - 보안 조사 - 저장소 이력 분석 - 파이프라인 장애 조사 ## 모든 에이전트 실행을 완료하는 안정성 - Sonnet 5는 GitLab 평가 제품군의 모든 벤치마크 작업을 완료한 첫 모델이다. - 이전 모델인 Sonnet 4.6은 벤치마크의 93.8%를 완료했다. - 에이전트가 작업 중간에 멈추면 재실행, 재프롬프트, 부분 결과 검증에 추가 비용이 발생한다. - Sonnet 5는 다음과 같은 작업에서 중단 가능성을 줄이는 것을 목표로 한다. - 여러 파일을 수정하는 리팩터링 - 실제로 활용 가능한 테스트 커버리지 생성 - 저장소 이력을 추적하는 보안 조사 - 장시간 실행되는 파이프라인 장애 분석 - 단순히 결과를 반환하는 데 그치지 않고, 8.8% 더 많은 이슈를 해결해 검토 가능한 결과를 제공하는 데 초점을 둔다. ## 효율성과 운영 비용 - 에이전트가 더 많은 작업을 완료하고 작업 과정에서 자원을 적게 사용할수록 실제 완료 작업당 비용이 낮아진다. - GitLab Duo Agent Platform의 모델마다 GitLab Credits 소비율이 다르다. - 팀은 작업 난이도와 모델의 비용 특성을 고려해 일상적인 개발 작업에 적절한 모델을 선택해야 한다. - GitLab은 모델별 크레딧 소비량을 GitLab Credits 문서에서 제공한다. ## 작업에 맞는 모델 선택 - Sonnet 5가 모든 작업에 적합하다는 의미는 아니다. - 일반적인 개발 업무에서는 품질, 속도, 비용의 균형을 제공하는 안정적인 기본 모델로 활용할 수 있다. - 더 복잡하고 긴 추론이 필요한 장기 에이전트 작업에는 Claude Opus 4.8을 선택할 수 있다. - GitLab 인스턴스의 모델 선택 기능에서 작업별로 사용할 모델을 지정할 수 있다. ## 이용 방법 - Claude Sonnet 5는 GitLab AI Gateway를 통해 즉시 사용할 수 있다. - 다른 모델과 마찬가지로 GitLab Credits를 사용한다. - 신규 사용자는 GitLab Duo Agent Platform 무료 체험 또는 GitLab Free 등급에서 시작할 수 있다. - 기존 GitLab Premium 및 Ultimate 구독자는 구독에 포함된 GitLab Credits를 이용할 수 있다. 실무에서는 반복적인 리팩터링, 테스트 생성, 장애 분석처럼 빈번한 개발 작업에 Sonnet 5를 기본 모델로 사용하고, 높은 추론 능력이 필요한 장기 작업에만 Opus 4.8을 선택하는 방식이 비용과 품질의 균형을 맞추는 방법이다.

원문 읽기(새 탭에서 열림)

AI 에이전트DevSecOpsgitlab-duo-agent-platformai-gateway+2

gitlab·2026년 6월 29일·3분 읽기큐레이션 요약

Git 2.55.0의 새로운 기능은 무엇인가?

Git 2.55.0은 커밋 수정, 대규모 저장소 성능, 여러 원격 저장소 관리, 로그 가독성을 개선한 릴리스입니다. 특히 `git history fixup`, Linux용 내장 fsmonitor, 원격 그룹 대상 `git push`, `git log --graph`의 레인 폭 제한이 눈에 띕니다. 또한 Git 코드베이스의 Rust 도입과 부분 클론에서의 `git grep`, `git cherry` 성능 개선도 주요 변경 사항으로 소개됩니다. ## `git history fixup`으로 기존 커밋 수정 - 기존 방식은 다음 두 단계가 필요했습니다. ```bash git commit --fixup=<commit-id> git rebase -i --autosquash <commit-id>^ ``` - Git 2.55에서는 스테이징된 변경 사항을 지정한 커밋에 바로 반영할 수 있습니다. ```bash git history fixup <commit-id> ``` - 대화형 리베이스 없이 커밋을 수정할 수 있어 절차가 간단해집니다. - 수정된 커밋을 포함하는 다른 로컬 브랜치도 함께 갱신됩니다. - 따라서 스택형 브랜치에서 중간 커밋을 수정하면 관련 브랜치가 자동으로 재배치됩니다. ## Linux용 내장 fsmonitor 데몬 - 대규모 모노레포에서는 `git status`가 전체 작업 트리를 탐색해야 하므로 느려질 수 있습니다. - `core.fsmonitor`를 활성화하면 파일 시스템 변경을 백그라운드에서 감시하고, Git이 변경 가능성이 있는 파일만 확인할 수 있습니다. - 기존 내장 fsmonitor는 Windows와 macOS만 지원했지만 Git 2.55부터 GNU/Linux도 지원합니다. - Linux에서는 권한 상승이 필요한 `fanotify` 대신 `inotify`를 사용합니다. - 저장소의 모든 디렉터리에 감시자를 등록하므로, 큰 저장소에서는 감시자 수 제한을 초과할 수 있습니다. - 필요하면 다음 커널 설정을 늘려야 합니다. ```text fs.inotify.max_user_watches ``` ## 원격 그룹으로 한 번에 push - 기존에는 원격 그룹을 `git fetch`에서만 사용할 수 있었습니다. - 다음과 같이 원격 그룹을 설정합니다. ```bash git config set remotes.forks "origin upstream" ``` - Git 2.55부터 그룹 전체에 브랜치를 push할 수 있습니다. ```bash git push forks main ``` - 지정한 브랜치가 그룹에 포함된 각 원격 저장소로 독립적으로 전송됩니다. - 각 원격 저장소의 `remote.<name>.push` 매핑과 mirror 설정도 개별적으로 적용됩니다. ## `git log --graph`의 레인 폭 제한 - `git log --graph`는 브랜치와 병합 관계를 ASCII 그래프로 표시합니다. - 기여자가 많거나 병렬 브랜치가 많은 저장소에서는 그래프가 지나치게 넓어져 가독성이 떨어질 수 있습니다. - Git 2.55는 그래프의 레인 폭을 제한하는 기능을 제공해 복잡한 커밋 이력을 보다 compact하게 표시할 수 있도록 합니다. ## Rust 도입과 부분 클론 성능 개선 - Git 2.55 릴리스의 추가 주제로 Git 코드베이스 내 Rust 사용 확대가 소개됩니다. - 부분 클론 환경에서 `git grep`과 `git cherry`가 더 빠르게 동작하도록 성능 개선이 이루어졌습니다. - 제공된 글 내용에는 Rust 도입 방식이나 각 명령의 구체적인 개선 수치는 자세히 설명되지 않습니다. 대규모 저장소를 사용한다면 Linux에서 `core.fsmonitor=true`를 활성화하고, `inotify` 감시자 제한을 점검하는 것이 좋습니다. 여러 미러나 포크에 동시에 배포하는 팀은 원격 그룹 push를 활용하면 반복 작업을 줄일 수 있습니다.

원문 읽기(새 탭에서 열림)

RustGitLinuxversion-control+2

gitlab·2026년 6월 25일·4분 읽기큐레이션 요약

Google Antigravity 에이전트, GitLab Orbit로 전체 컨텍스트 확보

Google Antigravity에 GitLab Orbit를 연결하면 코딩 에이전트가 단순히 파일과 터미널만 보는 것을 넘어 GitLab의 프로젝트, 의존성, 파이프라인, 머지 리퀘스트, 취약점, 코드 소유권까지 함께 이해할 수 있다. Orbit는 GitLab 데이터를 지식 그래프로 구성하고 MCP를 통해 에이전트에 제공하며, 이를 통해 변경 영향 분석과 코드베이스 탐색 같은 작업의 정확도와 속도를 높인다. 글에 따르면 초기 내부 테스트에서 응답 속도는 최대 11배 빨라지고, 토큰 사용량은 최대 4.5배, 환각은 최대 45배 줄었다. ## GitLab Orbit가 제공하는 컨텍스트 그래프 - GitLab 인스턴스의 다음 요소를 노드와 관계로 색인한다. - 그룹과 프로젝트 - 사용자와 코드 소유자 - 이슈 및 작업 항목 - 머지 리퀘스트 - 파이프라인 - 취약점 - 소스 코드와 프로젝트 간 의존성 - 지식 그래프는 코드 변경과 GitLab 활동을 연결해 에이전트가 시스템 전체의 맥락을 파악하도록 한다. - MCP 도구 두 가지를 제공한다. - `query_graph`: GitLab Orbit의 JSON DSL로 그래프를 질의 - `get_graph_schema`: 사용 가능한 노드 유형, 속성, 관계 확인 - 코드 변경 후 몇 분 내에 그래프를 다시 색인하므로 오래된 위키보다 최신 상태를 반영한다. ## Antigravity 에이전트의 활용 범위 확대 Orbit가 없으면 Antigravity 에이전트는 주로 현재 열려 있는 파일과 터미널에 의존한다. Orbit를 연결하면 다음과 같은 질문에 답할 수 있다. - 특정 모듈에 의존하는 프로젝트와 서비스는 무엇인가? - 해당 프로젝트에 해결되지 않은 취약점이 있는가? - 과거 리뷰 이력과 파일 소유권을 기준으로 적절한 리뷰어는 누구인가? - 특정 그룹에서 파이프라인 실패가 가장 많은 프로젝트는 무엇인가? 에이전트는 브라우저를 오가거나 사용자가 정보를 복사해 주지 않아도 구조화된 그래프 결과를 받아 답변을 생성한다. ## 변경 영향도와 충돌 분석 공유 인증 라이브러리처럼 여러 서비스가 사용하는 코드를 리팩터링할 때 Orbit가 특히 유용하다. - 해당 모듈을 import하는 모든 프로젝트를 조회한다. - 관련 파일을 수정 중인 열린 머지 리퀘스트를 확인한다. - 각 변경 사항의 담당자와 소유자를 찾아낸다. - 리팩터링이 기존 작업과 충돌할 가능성과 사전에 협의해야 할 사람을 한 번에 파악할 수 있다. 기존 에이전트가 파일 자체만 분석하는 것과 달리, 코드 의존성과 진행 중인 협업 작업까지 함께 고려한다는 점이 핵심이다. ## 온보딩과 코드베이스 탐색 익숙하지 않은 서비스에 복귀하거나 새로 합류한 개발자는 에이전트에게 다음 정보를 요청할 수 있다. - 서비스가 의존하는 프로젝트와 모듈 - 주요 진입점 파일 - 최근 일주일 동안 해당 서비스에 열린 머지 리퀘스트 에이전트는 조회 결과를 일회성 채팅 답변이 아니라 다시 볼 수 있는 **Walkthrough Artifact** 형태의 탐색 자료로 만들 수 있다. 그래프가 변경 후 빠르게 갱신되기 때문에 낡은 문서에 의존하지 않고 현재 코드베이스를 기준으로 학습할 수 있다. ## 실시간 의존성 다이어그램 생성 - 기술 리드는 그룹의 서비스 의존성 그래프를 조회한 뒤 Nano Banana Pro를 사용해 아키텍처 다이어그램으로 렌더링할 수 있다. - 특정 보안 취약점이 열려 있는 서비스만 필터링하는 등 범위를 좁혀 새 다이어그램을 만들 수 있다. - 다이어그램의 노드와 연결선은 최신 GitLab 그래프에서 생성된다. - 사용자의 GitLab 권한에 따라 결과가 필터링되므로 접근 권한이 없는 정보가 포함되지 않는다. - GitLab도 Software Architecture Map을 개발 중이지만, 글에서는 Antigravity 환경에서 이 기능을 즉시 사용할 수 있다고 설명한다. ## 설치와 사용 조건 - Antigravity 설정의 **Customization → MCP** 섹션에서 MCP Store를 연다. - **Add MCP**를 선택하고 GitLab Orbit를 추가한다. - 화면 안내에 따라 GitLab 인증을 완료하면 별도 설정 파일이나 터미널 작업 없이 에이전트가 Orbit 도구를 사용할 수 있다. - Orbit는 GitLab Duo Agent Platform과 동일한 컨텍스트 엔진을 사용한다. - 지원 언어는 Ruby, Java, Kotlin, Python, TypeScript, JavaScript, Rust, C#이며 기본 브랜치의 코드를 색인한다. - MCP 질의에는 GitLab Credits가 사용되지만 `get_graph_schema` 호출은 무료다. - GitLab.com의 Premium 및 Ultimate 요금제에서 사용할 수 있으며, 먼저 최상위 그룹에서 Orbit를 활성화해야 한다. ## 실용적인 결론 대규모 GitLab 환경에서 의존성 분석, 보안 점검, 리뷰어 선정, 온보딩을 자주 수행한다면 Orbit를 연결할 가치가 크다. 다만 성능 개선 수치는 초기 내부 테스트 결과이므로 실제 효과는 저장소 규모, 그래프 품질, 질의 설계에 따라 검증하고 GitLab Credits 사용량과 권한 설정도 함께 관리하는 것이 좋다.

원문 읽기(새 탭에서 열림)

모델 컨텍스트 프로토콜DevSecOpsgitlab-duo-agent-platformgitlab-orbit+3

gitlab·2026년 6월 24일·4분 읽기큐레이션 요약

GitLab 패치 릴리스: 19.1.1, 19.0.3, 18.11.6 | GitLab 문서

2026년 6월 24일 GitLab은 19.1.1, 19.0.3, 18.11.6 패치 릴리스를 공개했으며, 여러 보안 취약점과 버그를 수정했다. 자체 호스팅 CE/EE 사용자는 즉시 지원 버전의 최신 패치로 업그레이드해야 하며, GitLab.com은 이미 패치가 적용되었다. GitLab Dedicated 고객은 별도 조치가 필요하지 않다. ## 패치 릴리스와 권고 사항 - 대상 버전: - GitLab 19.1.1 - GitLab 19.0.3 - GitLab 18.11.6 - Omnibus, 소스 설치, Helm 차트 등 배포 방식과 관계없이 취약 버전은 영향을 받을 수 있다. - GitLab은 정기적으로 매월 둘째·넷째 수요일에 패치 릴리스를 제공하며, 고위험 취약점에는 비정기 긴급 패치를 배포한다. - 보안 취약점의 상세 이슈는 패치 릴리스 후 30일이 지나면 공개된다. ## 분석 대시보드 XSS - **CVE-2026-10086**, CVSS 8.7. - GitLab EE의 Analytics Dashboard에서 사용자 입력 sanitization이 충분하지 않았다. - 인증된 Developer 권한 사용자가 다른 사용자의 세션 컨텍스트에서 임의의 클라이언트 측 코드를 실행할 수 있었다. - GitLab EE 16.4 이상 중 다음 버전 이전이 영향받는다. - 18.11.6 - 19.0.3 - 19.1.1 ## Web IDE 자산 처리기의 XSS - **CVE-2026-10712**, CVSS 8.0. - Web IDE workbench의 경로 검증 오류를 악용하면 인증되지 않은 공격자가 사용자의 브라우저 세션에서 임의의 JavaScript를 실행할 수 있었다. - GitLab CE/EE의 다음 버전 이전이 영향을 받는다. - 18.11.6 - 19.0.3 - 19.1.1 - 네트워크를 통한 공격이 가능하지만, 특정 조건과 사용자 상호작용이 필요하다. ## Duo Workflows 정보 노출 - **CVE-2026-12053**, CVSS 7.7. - GitLab EE의 Duo Workflows가 출력 내용을 충분히 필터링하지 못했다. - 조건에 따라 사용자가 프로젝트에 이미 커밋된 민감한 정보를 열람할 수 있었다. - GitLab EE 19.1 계열에서 19.1.1 이전 버전이 영향받는다. ## Virtual Registry 권한 우회 - **CVE-2026-5309**, CVSS 5.4. - Virtual Registry Cleanup Policy API의 권한 검사가 잘못되어 있었다. - 인증된 사용자가 다른 그룹의 가상 레지스트리 정리 정책을 읽거나 수정할 수 있었다. - GitLab EE 18.6 이상 및 19.x의 특정 이전 버전이 영향을 받는다. ## Rapid Diffs의 부적절한 권한 검사 - **CVE-2026-2238**, CVSS 5.3. - 공개 프로젝트에서 인증되지 않은 사용자가 비공개 이슈 참조를 볼 수 있었다. - GitLab CE/EE 17.5 이상 중 18.11.6, 19.0.3, 19.1.1 이전 버전이 대상이다. ## DAST 사이트 프로필 비밀정보 노출 - **CVE-2026-11379**, CVSS 5.3. - DAST 사이트 프로필 관리 기능의 권한 오류로 Developer 권한 사용자가 사이트 프로필의 비밀정보를 탈취할 수 있었다. - GitLab EE 13.11 이상부터 영향을 받으며, 각 유지보수 계열의 최신 패치 이전 버전이 취약하다. ## CI/CD API 로그 정보 노출 - **CVE-2026-8330**, CVSS 4.4. - CI/CD API 엔드포인트의 필터링 부족으로 민감한 정보가 애플리케이션 로그에 기록될 수 있었다. - GitLab CE/EE 9.3 이후의 오래된 버전부터 이번 패치 이전 버전까지 영향을 받는다. - 로그에 노출된 토큰이나 비밀값이 있다면 업그레이드와 함께 해당 자격 증명을 교체해야 한다. ## Snippets 콘텐츠 은닉 - **CVE-2026-1606**, CVSS 4.3. - Snippets의 입력값 검증 오류로 인증된 사용자가 콘텐츠를 숨겨 표시할 수 있었다. - GitLab CE/EE 14.8 이상 중 18.11.6, 19.0.3, 19.1.1 이전 버전이 영향받는다. ## Maven 패키지 보호 규칙 우회 - **CVE-2026-5952**, CVSS 4.3. - Maven Package Registry의 권한 검사 오류로 Developer 권한 사용자가 보호된 Maven 패키지 메타데이터를 덮어쓸 수 있었다. - GitLab CE/EE 17.11 이상 중 최신 패치 이전 버전이 영향을 받는다. ## 그룹 패키지 API 접근 제어 오류 - **CVE-2026-5796**, CVSS 4.3. - Package Registry가 비활성화된 프로젝트의 패키지 메타데이터를 Reporter 권한의 그룹 사용자가 열람할 수 있었다. - GitLab CE/EE 13.6 이상 중 18.11.6, 19.0.3, 19.1.1 이전 버전이 대상이다. ## 권장 대응 - 자체 호스팅 GitLab은 가능한 한 즉시 18.11.6, 19.0.3, 19.1.1 중 지원 중인 계열로 업그레이드한다. - 업그레이드 전 백업과 복구 절차를 확인하고, 업그레이드 후 CI/CD, Package Registry, Web IDE, DAST, Duo Workflows를 점검한다. - 로그나 설정에서 민감정보 노출 가능성이 확인되면 토큰·비밀번호·패키지 자격 증명을 함께 교체한다. - GitLab.com은 이미 수정 버전이 적용되어 별도 조치가 필요하지 않다.

원문 읽기(새 탭에서 열림)

CI/CDgitlabapi-securitycross-site-scripting+4

gitlab·2026년 6월 18일·3분 읽기큐레이션 요약

거버넌스 및 운영을 위한 AI 카탈로그 업데이트

GitLab 19.1은 Duo Flows를 실제 GitLab 이벤트에 따라 자동 실행할 수 있게 하며, AI 자동화를 지속적이고 무인으로 운영할 기반을 제공합니다. 동시에 관리자용 에이전트·플로우 통제, 설정 사전 검증, 승인된 AI 모델 목록 관리 기능을 추가해 엔터프라이즈 환경의 보안성과 신뢰성을 강화합니다. 결과적으로 개발자는 반복적인 수동 실행에서 벗어나고, 관리자는 조직에서 실행되는 AI를 통제할 수 있습니다. ## 이벤트 기반 Duo Flows 자동 실행 - 기존 Duo Flow는 사용자가 GitLab UI에서 멘션, 할당, 리뷰어 지정 등을 직접 수행해야 실행할 수 있었습니다. - GitLab 19.1에서는 다음 이벤트를 트리거로 사용할 수 있습니다. - **머지 리퀘스트 코드 충돌 감지**: 충돌 발생 즉시 요약과 해결 제안 실행 - **Draft에서 Ready for review로 변경**: 자동 컴플라이언스 검사나 사전 병합 체크 실행 - **머지 리퀘스트 승인**: 배포 준비 상태 확인, 컴플라이언스 기록, 인수인계 알림 실행 - **Work item 생성**: 자동 분류, 라벨 지정, 담당 팀 라우팅 실행 - 파이프라인 이벤트는 성공, 실패, 취소 등 특정 상태만 필터링할 수 있습니다. - 실패 시 인시던트 생성 - 성공 시 아티팩트 승격 - 취소 시 별도 후속 처리 - 코드 충돌 감지와 Draft→Ready for review 트리거는 기본 활성화됩니다. - 로컬에서 에이전트를 사용할 때는 패턴 기반 승인 기능을 통해 세션 동안 특정 도구 사용을 일괄 승인할 수 있어, 반복적인 파일 수정이나 `npm install` 과정에서 재승인할 필요가 줄어듭니다. ## 승인되지 않은 에이전트와 플로우 차단 - 인스턴스 관리자와 최상위 그룹 소유자는 조직에서 실행 가능한 AI 콘텐츠의 범위를 제한할 수 있습니다. - **Disable custom agents and flows** - 사용자가 사용자 정의 에이전트와 플로우를 생성하거나 활성화하지 못하게 합니다. - 검토된 기본 제공 콘텐츠 중심으로 사용을 제한합니다. - **Restrict the AI catalog to your group hierarchy** - 자신의 네임스페이스 외부에서 제공되는 AI Catalog 항목을 활성화하지 못하게 합니다. - 커뮤니티 및 서드파티 플로우가 보안 검토 없이 도입되는 것을 방지합니다. - 두 설정을 함께 사용하면 AI 활용은 허용하면서도 검증되지 않은 에이전트가 운영 환경에 확산되는 문제를 통제할 수 있습니다. ## 저장 전에 플로우 설정 검증 - 사용자가 AI Catalog의 플로우를 저장하거나 수정하면 GitLab이 Duo Workflow Service를 통해 설정을 검증합니다. - 누락된 입력값이나 알 수 없는 도구 파라미터 같은 오류가 저장 전에 구조화된 형태로 UI에 표시됩니다. - 잘못된 플로우가 운영 중 처음 발견되는 대신, 설정 단계에서 즉시 수정할 수 있습니다. - 자동 트리거는 잘못 구성될 경우 반복 실행과 불필요한 알림을 일으킬 수 있으므로 사전 검증의 중요성이 큽니다. ## 승인된 AI 모델만 사용하도록 제한 - 공개 베타 기능으로 관리자는 조직에서 사용할 수 있는 AI 모델의 allowlist를 설정할 수 있습니다. - 조직 전체의 기본 모델도 지정할 수 있으며, 사용자는 허용된 범위 안에서 모델을 선택할 수 있습니다. - 데이터 레지던시 요건이나 사내 승인 절차를 통과한 제공업체만 사용하도록 제한할 수 있습니다. - 초기 적용 범위는 GitLab Duo Agentic Chat이며, 향후 다른 기능 영역으로 확대될 예정입니다. ## 운영 환경을 위한 AI 자동화 기반 - 이벤트 기반 실행으로 사람이 버튼을 누르지 않아도 반복적인 검토, 분류, 알림, 배포 후속 작업을 수행할 수 있습니다. - 관리자는 실행 가능한 에이전트·플로우·모델을 통제하고, 개발자는 자동화 설정 오류를 운영 장애 전에 발견할 수 있습니다. - 도입 시에는 먼저 승인된 모델과 콘텐츠 범위를 정한 뒤, 실패 파이프라인이나 머지 리퀘스트 준비 완료 같은 명확한 이벤트부터 플로우를 단계적으로 적용하는 것이 좋습니다.

원문 읽기(새 탭에서 열림)

AI 에이전트CI/CDgitlabDevSecOps+3