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

조직 전체의 CI 컴포넌트 사용 현황 추적

GitLab 19.0은 CI/CD Catalog에 등록된 공유 컴포넌트의 조직 내 사용 현황을 추적하는 Components Analytics를 제공한다. 모든 요금제에서 컴포넌트별 채택 규모를 확인할 수 있고, Ultimate에서는 어떤 프로젝트가 어떤 버전을 사용하는지까지 조회할 수 있다. 이를 통해 보안 취약점 대응, 구버전 정리, 표준 파이프라인 채택 여부를 수작업 감사 없이 파악할 수 있다. ## 공유 CI의 가시성 문제 - CI/CD Catalog는 재사용 가능한 파이프라인 컴포넌트를 버전별로 배포해 프로젝트가 `include` 한 줄로 사용할 수 있게 한다. - 중앙 배포와 표준화는 가능하지만, 배포 후 다음 정보를 파악하기 어렵다는 문제가 있었다. - 실제로 어떤 프로젝트가 컴포넌트를 사용하는지 - 각 프로젝트가 어느 버전을 사용하는지 - 보안 수정이 적용되지 않은 구버전이 얼마나 남아 있는지 - 공유 컴포넌트의 보안 수정은 기존 사용 프로젝트에 자동 전파되지 않으므로, 취약점 발생 시 조직의 노출 범위를 수작업으로 조사해야 했다. ## Components Analytics의 채택 현황 보기 - `Explore > CI/CD Catalog > Analytics`에서 관리 중인 카탈로그 리소스의 사용 현황을 확인할 수 있다. - 모든 요금제에서 제공되는 고수준 분석 기능은 다음 정보를 보여준다. - 최신 릴리스 버전 - 최근 30일 동안 컴포넌트를 가져간 고유 프로젝트 수 - 해당 버전에서 제공되는 컴포넌트 목록 - 이를 통해 널리 사용되는 컴포넌트와 사실상 사용되지 않는 컴포넌트를 구분할 수 있다. - 유지보수 우선순위 설정, 폐기 계획 수립, 플랫폼 투자 효과 측정에 활용할 수 있다. - 이 고수준 분석 기능은 GitLab 18.9에서 출시되었으며 Free를 포함한 모든 티어에서 제공된다. ## Ultimate의 컴포넌트 사용 상세 조회 - GitLab Ultimate에서는 특정 카탈로그 리소스를 열어 최근 30일간 사용한 프로젝트를 확인할 수 있다. - 프로젝트별로 다음 정보를 제공한다. - 사용 중인 컴포넌트 버전 - 최신 버전 여부 - 구버전 사용 여부 - 예를 들어 v2.1에서 보안 수정이 배포된 경우, 여전히 v1.x에 고정된 프로젝트를 바로 식별할 수 있다. - 관리자는 해당 프로젝트에 머지 리퀘스트를 제안하거나 담당자에게 알림을 보내고, 필요한 경우 문제를 에스컬레이션할 수 있다. - 대규모 리팩터링의 영향 범위, 구버전 폐기 가능 여부, 보안 패치의 실제 적용 여부를 판단하는 데도 유용하다. ## 다른 CI 플랫폼과의 차이 - GitHub Actions는 조직 전체에서 재사용 워크플로와 버전 사용 현황을 보여주는 기본 카탈로그 분석 기능이 없어 별도 도구가 필요하다. - CircleCI Insights는 파이프라인 성능을 분석하지만, 어떤 팀이 어떤 Orb를 어느 버전으로 사용하는지는 제공하지 않는다. - Jenkins Shared Libraries도 사용 현황 추적을 위해 맞춤형 도구를 구축해야 한다. - GitLab은 재사용 가능한 컴포넌트 카탈로그와 사용 현황 분석을 기본 기능으로 결합했다. ## AI 생성 파이프라인에 대한 거버넌스 - AI가 생성하는 파이프라인이 늘어날수록 조직 표준이 실제 운영 환경에 적용되고 있는지 확인하는 기능이 중요해진다. - CI/CD Catalog는 표준 컴포넌트를 배포하고, Components Analytics는 그 표준이 실제로 사용되는지 감사할 수 있게 한다. - Self-Managed 및 Dedicated 고객은 GitLab.com의 컴포넌트를 미러링하거나 자체 컴포넌트를 추가해 규제·에어갭 환경에서도 승인된 표준 집합을 운영할 수 있다. 조직에서 공유 CI 컴포넌트를 운영한다면 Analytics로 채택률과 방치된 컴포넌트를 먼저 파악하고, Ultimate 환경에서는 구버전 사용 프로젝트를 대상으로 보안 패치와 업그레이드를 직접 추진하는 것이 좋다.

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

gitlabCI/CDDevSecOpsyaml+3

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

GitLab Dedicated for Government, 이제 GovRAMP 인증 획득

GitLab Dedicated for Government가 GovRAMP Authorization을 획득해 주·지방 정부기관이 보안과 규정을 충족하는 DevSecOps SaaS를 더 빠르게 도입할 수 있게 됐습니다. 미국 내 데이터 거주성, 단일 테넌트 격리, 프라이빗 네트워킹, GitLab의 완전 관리형 운영을 제공하면서도 인프라 수준의 통제력을 유지하는 것이 핵심입니다. 또한 GitLab Duo 기반 AI 기능을 제공하며, GovRAMP 인증 경계 내 에이전틱 AI 기능도 추후 추가될 예정입니다. ## GovRAMP 인증의 의미 - GovRAMP는 주·지방 정부기관이 클라우드 서비스의 보안성과 규정 준수 여부를 평가할 수 있도록 표준화된 위험 승인 체계를 제공합니다. - 32개 주가 GovRAMP를 채택했으며, 여러 주에서 의무화가 진행 중입니다. - 이번 인증으로 정부기관은 별도의 긴 인증·조달 장벽을 줄이고, 현대적인 소프트웨어 공급망을 더 신속하게 도입할 수 있습니다. - GitLab Dedicated for Government는 정부 데이터와 서비스가 요구하는 높은 수준의 보안, 데이터 주권, 격리 요건을 목표로 설계됐습니다. ## 정부기관의 현대화와 보안 요구 - 주·지방 정부는 하이브리드 및 멀티클라우드 전략을 추진하며 IT 현대화에 대규모 예산을 투입하고 있습니다. - NASCIO의 2025년 조사에서 현대화는 주 CIO들의 주요 우선순위 4위로 상승했습니다. - 기관들은 노후 시스템의 보안 취약점, 제3자 소프트웨어 공급망 위험, 랜섬웨어와 국가 지원 공격에 대응해야 합니다. - GitLab은 인프라를 직접 구축·운영하지 않고도 현대적인 애플리케이션 개발과 엔터프라이즈급 보안·규정 준수를 달성할 수 있도록 이 서비스를 설계했습니다. ## 도구 체인 통합 - GitLab의 2025년 공공 부문 DevSecOps 조사에 따르면: - 60%의 팀이 소프트웨어 개발 도구를 5개 이상 사용합니다. - 53%의 팀이 보안 도구를 5개 이상 사용합니다. - 비효율적인 프로세스와 협업 장벽으로 주당 약 6시간을 잃습니다. - 여러 도구를 사용하는 방식은 비용을 증가시키고, 팀 간 협업과 보안 정책 적용을 복잡하게 하며, 공격 표면을 넓힐 수 있습니다. - GitLab Dedicated for Government는 개발·보안·운영 팀을 하나의 플랫폼과 통합 워크플로로 연결합니다. - 중앙화된 접근 제어와 인증 정책을 통해 제로 트러스트 아키텍처 구현도 지원합니다. - 개방형 API와 통합 기능을 제공하므로 기관은 기존 도구를 한 번에 교체하지 않고 단계적으로 통합할 수 있습니다. ## 데이터 거주성과 보호 - GovRAMP 인증 인프라를 기반으로 하며, 미국 시민으로 접근을 제한하는 요건을 지원합니다. - 고객의 VPC와 GitLab 사이에 프라이빗 연결을 구성해 인터넷에 직접 노출하지 않고 사용자·데이터·서비스를 격리된 인스턴스에 연결할 수 있습니다. - 저장 데이터와 전송 데이터 모두 최신 암호화 표준으로 보호됩니다. - 저장 데이터 암호화에는 고객이 직접 관리하는 AWS KMS 키를 사용할 수 있습니다. - CVE 패치를 지속적으로 적용해 고객이 인프라와 규정 준수 관리 부담을 줄일 수 있습니다. ## GitLab의 완전 관리형 단일 테넌트 운영 - 고객별 물리적 격리를 제공하는 단일 테넌트 구조입니다. - 미국 내에서 호스팅되며 프라이빗 네트워크로 연결됩니다. - 인프라는 GitLab이 완전히 관리하고 운영하므로 정부기관은 자체 인력으로 플랫폼을 구축·유지할 필요가 없습니다. - 기관 직원은 인프라 관리보다 핵심 업무와 미션에 집중할 수 있습니다. - 자체 호스팅보다 총소유비용과 도입 시간을 줄이면서도 GitLab의 개발 생산성, 보안, 규정 준수 기능을 활용할 수 있습니다. ## 네이티브 보안 및 규정 준수 기능 - 소프트웨어 개발 생명주기 전반에 보안과 규정 준수 기능이 통합돼 있습니다. - 기본 제공 보안 스캐너에는 다음이 포함됩니다. - 정적 애플리케이션 보안 테스트(SAST) - 비밀정보 탐지 - 컨테이너 스캔 - 동적 애플리케이션 보안 테스트(DAST) - 의존성 스캔은 직접 의존성과 전이 의존성을 깊이 제한 없이 분석합니다. - 프로젝트 단위뿐 아니라 여러 프로젝트 그룹 전체에서 의존성 목록과 위험 요소를 확인할 수 있어 공급망 위험을 추적하기 쉽습니다. - 보안 결과는 머지 리퀘스트 위젯과 파이프라인 보안 탭에 표시됩니다. - 개발 작업의 맥락에서 한 번의 클릭으로 결과를 분류하고 대응할 수 있습니다. - 사용자 지정 규칙 집합과 보안 정책 자동화를 통해 오탐을 줄이고 일관된 보안 통제를 적용할 수 있습니다. ## 실용적인 결론 보안·데이터 주권 요건 때문에 일반적인 퍼블릭 SaaS 도입이 어려운 주·지방 정부기관이라면 GitLab Dedicated for Government가 적합한 선택지가 될 수 있습니다. 특히 여러 개발·보안 도구를 통합하면서도 미국 내 데이터 저장, 단일 테넌트 격리, 프라이빗 연결, GovRAMP 승인을 동시에 요구하는 조직에 유용합니다.

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

gitlabDevSecOps클라우드 보안software-supply-chain-security+4

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

Codex와 GitLab으로 버그 수정

Codex는 터미널에서 코드를 분석하고 수정·테스트하는 데 강력하지만, 실제 배포에는 이슈 관리, 머지 리퀘스트, CI/CD, 코드 리뷰와 승인 과정이 필요하다. 글은 GitLab과 Codex를 연계해 Rust WebSocket 버그를 수정하고, GitLab MCP로 이슈와 개발 맥락을 반영하며, GitLab Duo Agent Platform의 외부 에이전트로 리뷰 피드백까지 처리하는 흐름을 소개한다. 핵심 결론은 코딩 에이전트의 빠른 구현 능력과 GitLab의 소프트웨어 생명주기 관리 기능을 결합해야 코드 작성부터 운영 배포까지 연결할 수 있다는 것이다. ## Codex와 GitLab을 결합하는 전체 워크플로 - Codex는 저장소 안에서 코드를 읽고, 수정안을 만들고, 명령을 실행하고, 테스트까지 수행한다. - 그러나 코드 작성만으로는 소프트웨어가 배포되지 않는다. - GitLab 이슈 - 머지 리퀘스트 - CI/CD 파이프라인 - 보안 스캔 - 코드 리뷰 - 최종 사람의 승인 등이 필요하다. - 글에서는 Tanuki IoT Platform 프로젝트의 Rust metrics backend를 대상으로 세 가지 활용 사례를 제시한다. - 로컬 Codex로 Rust WebSocket 버그 수정 - GitLab MCP로 이슈 요구사항과 개발 맥락을 Codex에 제공 - GitLab Duo Agent Platform에서 Codex를 외부 에이전트로 사용해 MR 리뷰 피드백 처리 ## 실습 환경과 프로젝트 구조 - 필요한 환경: - 터미널에서 실행 가능한 Codex - 이슈가 포함된 GitLab 프로젝트 - 선택적으로 GitLab MCP 서버와 GitLab Duo Agent Platform - Rust 컴파일러와 Cargo - 프로젝트를 GitLab에 가져온 뒤 로컬에 clone하고 저장소 루트에서 `codex`를 실행한다. - 주요 대상은 `backend/` 아래의 Rust metrics store다. - 센서는 REST API로 측정값을 전송한다. - 대시보드는 WebSocket 스트림으로 실시간 데이터를 받는다. - `AGENTS.md`를 통해 Codex에 Rust 도구 체인, 빌드 명령, 테스트 방법, 코드 품질 기준을 알려줄 수 있다. ## WebSocket 메트릭 필터 버그 재현 - 백엔드는 REST API에서는 메트릭 필터링을 지원하지만, WebSocket 스트림에서는 필터가 제대로 적용되지 않는 문제가 있었다. - 서버 실행: ```bash PORT=9090 cargo run --manifest-path backend/rust-metrics-store/Cargo.toml ``` - 특정 센서와 메트릭을 구독: ```bash websocat 'ws://localhost:9090/ws?sensor=arduino-iot-collector&metric=temperature_celsius' ``` - 같은 센서에 서로 다른 메트릭을 전송한다. ```bash curl -s -X POST http://localhost:9090/api/metrics \ -H 'Content-Type: application/json' \ -d '{"sensor":"arduino-iot-collector","metric":"temperature_celsius","value":23.5}' curl -s -X POST http://localhost:9090/api/metrics \ -H 'Content-Type: application/json' \ -d '{"sensor":"arduino-iot-collector","metric":"humidity_percent","value":61.2}' ``` - 기대 결과는 `temperature_celsius`만 수신하는 것이다. - 실제로는 `humidity_percent`도 스트림에 나타나므로, `/ws`가 `metric` 쿼리 파라미터를 무시하고 있음을 확인할 수 있다. ## 로컬 Codex를 이용한 버그 수정 - Codex에 다음과 같이 작업을 요청한다. ```text I need help with a backend change to add metric filtering to /ws so live streams can be narrowed to one metric. ``` - Codex는 저장소와 `AGENTS.md`를 분석해 다음 작업을 수행한다. - `/ws` 핸들러의 기존 sensor 필터 로직 조사 - 선택적 `metric` 쿼리 파라미터 지원 추가 - 센서와 메트릭 조합에 따른 필터링 구현 - 관련 테스트 추가 - `README.md`와 `AGENTS.md` 등 문서 갱신 - 변경 후 포맷팅, 테스트, 빌드를 실행하고 최종 diff를 검토한다. - 이후 Codex에 브랜치 생성, 커밋, 원격 저장소 push를 맡길 수 있다. ## GitLab 머지 리퀘스트와 CI/CD 검증 - 코드가 MR에 올라가면 GitLab이 이후 생명주기를 담당한다. - 파이프라인에서 다음 검증이 수행된다. - 빌드와 테스트 - 보안 스캔 - Rust 코드 스타일 및 품질 검사 - GitLab Duo Code Review - 배포 후에는 동일한 로컬 테스트를 다시 실행해 sensor와 metric을 모두 지정했을 때 요청한 메트릭만 전달되는지 확인한다. - 검증 결과와 로컬 테스트 내용을 MR에 댓글로 남겨 리뷰 맥락을 공유한다. ## GitLab MCP로 이슈와 요구사항 연결 - 로컬 저장소만 보는 Codex는 GitLab에 있는 다음 정보를 알 수 없다. - 버그 이슈의 상세 내용 - 합의된 기능·비기능 요구사항 - 구현 메모 - 관련 MR 상태 - 파이프라인 상태 - GitLab MCP 서버를 연결하면 Codex가 이슈를 직접 조회할 수 있다. - 이슈에는 다음과 같은 내용이 포함될 수 있다. - 문제 재현 방법 - 기능 요구사항 - 비기능 요구사항 - 필요한 테스트 - `README.md`, `AGENTS.md` 갱신 요구 - 구현 방향에 대한 메모 - 따라서 사용자가 긴 요구사항을 프롬프트에 복사하지 않아도, Codex가 GitLab 이슈를 단일 기준 정보로 활용해 구현할 수 있다. - 이는 단순히 코드를 고치는 것보다 프로젝트의 합의된 요구사항과 개발 프로세스에 맞춘 변경을 가능하게 한다. ## 실용적인 적용 권장 사항 - Codex에는 작업 범위와 기대 동작을 명확히 요청하고, `AGENTS.md`에 빌드·테스트·스타일 규칙을 기록하는 것이 좋다. - 코드 수정 전에는 실제 API와 WebSocket 동작을 명령줄에서 재현해 버그를 객관적으로 확인한다. - GitLab MCP를 사용해 이슈를 직접 참조하게 하면 요구사항 누락을 줄일 수 있다. - Codex가 작성한 코드는 GitLab MR, CI/CD, 보안 스캔, 사람의 리뷰를 거친 뒤 배포해야 한다.

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

gitlabAI 에이전트CI/CDRust+3

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

정책으로 오해를 불러일으키는 취약점 심각도를 수정하는 5가지 방법

CVSS는 취약점의 이론적 특성만 평가하므로, 실제 배포 환경과 노출 정도를 충분히 반영하지 못한다. GitLab의 취약점 관리 정책을 사용하면 CVE·CWE·파일 경로·디렉터리 조건에 따라 심각도를 자동 조정해 조직의 실제 위험 모델에 맞출 수 있다. 이를 통해 대규모 스캔 결과를 수동으로 분류하는 부담을 줄이고, 중요한 취약점에 대응 우선순위를 일관되게 부여할 수 있다. ## GitLab 심각도 재정의 정책의 작동 방식 - 정책은 기본 브랜치의 파이프라인이 실행될 때마다 취약점 결과에 적용된다. - 다음 조건으로 취약점을 선택할 수 있다. - CVE ID - CWE ID - 특정 파일 경로 - 특정 디렉터리 - 제공되는 심각도 조정 방식은 세 가지다. - **Set Severity**: `info`, `low`, `medium`, `high`, `critical` 중 하나로 고정 - **Increase Severity**: 한 단계 상향 - **Decrease Severity**: 한 단계 하향 - 권한이 있는 사용자가 직접 변경한 심각도는 정책보다 우선한다. - 정책으로 변경된 내역은 취약점 이력과 감사 이벤트에 기록되어 변경 이유를 추적할 수 있다. ## 내부 서비스의 낮은 노출 위험 반영 내부 관리자 도구, 개발자용 유틸리티, 배치 작업처럼 외부 트래픽을 받지 않는 서비스는 동일한 CVE라도 공개 API보다 실제 위험이 낮을 수 있다. - `internal/**/*` 같은 내부 서비스 디렉터리를 대상으로 정책을 적용한다. - 특정 CVE가 해당 디렉터리에서 발견되면 심각도를 한 단계 낮춘다. - 예를 들어 `Critical`은 `High`, `High`는 `Medium`으로 조정된다. - 전체 심각도를 무조건 낮추지 않고 상대적인 우선순위를 유지하는 방식이다. - 조직이 내부 배포 환경에서 위험이 낮다고 판단한 CVE 목록으로 값을 교체해 사용해야 한다. ## 운영 코드의 인젝션 취약점 상향 XSS와 SQL 인젝션은 실제 공격에 자주 악용되는 대표적인 취약점이므로, 운영 소스 코드에서 발견되면 기본 CVSS보다 엄격하게 처리할 수 있다. - `CWE-79`(Cross-Site Scripting)와 `CWE-89`(SQL Injection)를 조건으로 지정한다. - `src/**/*` 등 운영 코드 디렉터리에서 발견된 경우 심각도를 `Critical`로 고정한다. - CWE와 경로를 함께 조건으로 사용해 테스트 코드나 비운영 영역의 불필요한 상향을 줄인다. - Critical 취약점에 보안팀 승인을 요구하는 머지 리퀘스트 승인 정책과 결합하면: - 취약점 보고서에서 우선순위가 상향되고 - 검토 없이 해당 코드가 프로덕션에 병합되는 것을 방지할 수 있다. ## 여러 스캐너 간 심각도 통일 SAST, 의존성 스캔, 컨테이너 스캔 등은 같은 CVE를 서로 다른 심각도로 보고할 수 있다. 이 차이는 대응 기준과 승인 임계값을 혼란스럽게 만든다. - 조직이 특정 CVE를 항상 같은 수준으로 처리해야 한다고 판단하면 심각도를 고정한다. - 예를 들어 Log4j 관련 CVE인 `CVE-2021-44228`, `CVE-2021-45046`, `CVE-2021-45105`를 모두 `High`로 설정할 수 있다. - 어떤 스캐너가 발견했는지와 관계없이 동일한 기준을 적용할 수 있다. - 여러 종류의 보안 스캔을 운영하는 조직에서 보고서와 승인 절차를 일관되게 만드는 데 유용하다. ## 실제 악용 정보에 따른 상향 CVSS는 정적인 점수이므로 취약점이 실제 공격에 사용되기 시작했는지 즉시 반영하지 못한다. 이를 보완하기 위해 EPSS와 CISA KEV 같은 위협 인텔리전스를 정책 조건에 활용할 수 있다. - CISA KEV 카탈로그에 등록된 CVE는 실제 악용 사례가 확인된 것으로 보고 `Critical`로 상향할 수 있다. - EPSS가 높은 취약점, 예를 들어 악용 가능성이 `0.5`를 넘는 CVE도 더 높은 우선순위로 처리할 수 있다. - 글에서는 `CVE-2024-3094`, `CVE-2023-4966`, `CVE-2023-22515` 등을 KEV 기반 상향 예시로 제시한다. - 다만 제공된 글 내용은 이 네 번째 예시의 정책 설정 중간에서 끝나 있어, 다섯 번째 방법과 이후 세부 내용은 확인할 수 없다. ## 적용 시 권장 사항 - 심각도 조정은 CVSS를 임의로 왜곡하기보다 배포 위치, 공격 노출도, 실제 악용 여부를 반영하는 조직별 위험 모델로 사용한다. - 디렉터리 조건을 함께 지정해 내부·테스트·운영 코드를 구분한다. - 정책 변경 이력과 수동 재정의 우선순위를 고려해 정기적으로 정책을 검토한다. - Critical 상향 정책은 머지 승인 정책과 연계해 보고서 분류뿐 아니라 배포 통제까지 자동화하는 것이 좋다.

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

gitlabvulnerability-managementyamlsast+4

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

GitLab 패치 릴리스: 18.11.3, 18.10.6, 18.9.7 | GitLab 문서

GitLab은 2026년 5월 13일 보안 및 버그 수정이 포함된 18.11.3, 18.10.6, 18.9.7 패치 버전을 출시했으며, 모든 자체 관리형 설치 환경에 즉시 업그레이드를 권고했습니다. 이번 릴리스에는 인증된 사용자가 악성 JavaScript를 실행할 수 있는 XSS, 인증 없이 서비스를 마비시킬 수 있는 DoS, 권한 검증 오류 등이 수정되었습니다. GitLab.com은 이미 패치가 적용되었고, GitLab Dedicated 고객은 별도 조치가 필요하지 않습니다. ## 릴리스 대상과 업그레이드 권고 - 대상 버전: - GitLab 18.11.3 - GitLab 18.10.6 - GitLab 18.9.7 - CE와 EE 모두에 해당하는 수정이 포함되었습니다. - Omnibus, 소스 설치, Helm 차트 등 특정 배포 방식이 명시되지 않은 취약점은 모든 배포 유형에 영향을 줍니다. - 지원되는 버전을 운영 중인 자체 관리형 GitLab은 가능한 한 빨리 최신 패치 버전으로 업그레이드해야 합니다. - GitLab 패치 릴리스는 매월 둘째·넷째 수요일의 정기 릴리스와, 심각도가 높은 취약점에 대응하는 비정기 긴급 패치로 나뉩니다. - 보안 취약점의 상세 이슈는 패치된 릴리스 후 30일이 지나면 공개됩니다. ## XSS 취약점 수정 - **CVE-2026-7481 — Analytics 대시보드 차트 렌더링** - GitLab EE에 영향. - Developer 권한의 인증된 사용자가 입력값 검증 부실을 악용해 다른 사용자의 브라우저에서 임의 JavaScript를 실행할 수 있었습니다. - CVSS 8.7. - 16.4 이상에서 18.9.7, 18.10.6, 18.11.3 이전 버전에 영향. - **CVE-2026-5297 — 전역 검색** - GitLab CE/EE에 영향. - 인증된 사용자가 조작된 입력을 통해 다른 사용자의 브라우저에서 JavaScript를 실행할 수 있었습니다. - CVSS 8.7. - 15.11 이상에서 수정 버전 이전까지 영향. - **CVE-2026-6073 — Duo Agent 출력 렌더링** - GitLab EE에 영향. - Duo Agent 출력 처리 과정의 입력값 정제 부족으로 XSS가 발생할 수 있었습니다. - CVSS 8.7. - 18.7 이상 버전 중 수정 버전 이전에 영향. - **CVE-2026-7377 — 사용자 지정 Analytics 대시보드** - GitLab EE에 영향. - 인증된 사용자가 대시보드 입력을 조작해 다른 사용자의 브라우저 컨텍스트에서 임의 JavaScript를 실행할 수 있었습니다. - CVSS 8.7. - 18.7 이상 버전 중 수정 버전 이전에 영향. ## 인증 없이 악용 가능한 DoS 취약점 - **CVE-2026-1659 — CI/CD 작업 업데이트 API** - 특수하게 조작된 요청과 불충분한 입력 검증을 이용해 인증 없이 서비스 거부를 일으킬 수 있었습니다. - GitLab CE/EE에 영향. - CVSS 7.5. - **CVE-2025-14870 — Duo Workflows API** - 조작된 JSON 페이로드를 전송해 인증 없이 서비스 거부를 유발할 수 있었습니다. - GitLab CE/EE에 영향. - CVSS 7.5. - **CVE-2025-14869 — 내부 API 엔드포인트** - 특정 API 엔드포인트에 악성 페이로드를 보내 서비스 거부를 일으킬 수 있었습니다. - GitLab CE/EE에 영향. - CVSS 7.5. - **CVE-2026-1184 — Insights 구성** - GitLab EE에서 조작된 파일 업로드와 부적절한 검증을 통해 서비스 거부가 발생할 수 있었습니다. - CVSS 6.5. - 일부 설명에서는 인증 요구 수준이 명시되어 있으므로 외부 파일 업로드 경로를 특히 점검해야 합니다. ## 권한 및 접근 제어 취약점 - **CVE-2026-1322 — GraphQL 토큰 범위 적용** - `read_api` 범위만 가진 OAuth 애플리케이션이 비공개 프로젝트에 이슈를 생성하거나 댓글을 추가할 수 있었습니다. - 인증 및 권한 검증 오류가 원인이었습니다. - GitLab CE/EE에 영향. - CVSS 6.8. - **CVE-2026-4524 — Issues API** - 공개 프로젝트의 기밀 이슈 내용이 적절한 권한 확인 없이 노출될 수 있었습니다. - GitLab CE/EE에 영향. - CVSS 6.5. ## 공개되지 않은 추가 수정 사항 - 글 마지막에는 **CVE-2026-8280 — direct transfer CSV 파서의 DoS 취약점**이 언급되지만, 제공된 본문이 해당 항목 중간에서 끝나 구체적인 영향 버전과 CVSS 점수는 확인할 수 없습니다. 자체 관리형 GitLab 운영자는 먼저 현재 버전을 확인하고 18.9.7, 18.10.6, 18.11.3 중 지원되는 최신 버전으로 업그레이드하는 것이 가장 안전합니다. 특히 외부에 노출된 API, 검색·분석 대시보드, OAuth 토큰, 파일 업로드 기능을 사용하는 환경은 패치 전까지 접근 통제를 강화해야 합니다.

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

gitlabJavaScriptGraphQLoauth+3

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

AI 보조 코딩 시대에 맞춰 파이프라인 경계를 강화하세요

AI 지원 개발로 사람·에이전트·외부 코드가 빠르게 결합하면서, 기존의 문서 중심 보안 정책만으로는 파이프라인을 보호하기 어려워졌다. 글은 GitLab Ultimate이 보안을 별도 포털이 아닌 개발 플랫폼의 통제 영역에 통합해, 모든 변경을 **보고(See)·강제하고(Enforce)·수정하는(Fix)** DevSecOps 제어면을 제공한다고 주장한다. 이 세 요소를 결합해야 AI가 생성하는 코드의 속도와 보안 요구를 함께 충족할 수 있다는 결론이다. ## 모든 프로젝트와 보안 활동을 가시화 - 그룹 보안 대시보드에서 다음 스캐너의 결과를 여러 저장소에 걸쳐 통합해서 확인한다. - SAST - SCA - 시크릿 탐지 - 컨테이너 스캔 - IaC 스캔 - DAST - 퍼징 테스트 - 프로젝트별 위험 추세, 사업부·노출 수준별 위험, 보안 인벤토리를 한 화면에서 확인할 수 있다. - 한 번도 스캔되지 않아 보안 등급이 없는 프로젝트도 식별해 보이지 않는 사각지대를 줄인다. - Credentials Inventory는 인스턴스 전체 토큰의 소유자, 권한 범위, 만료일을 보여준다. - 손상된 토큰이나 아직 활성화된 토큰을 필터링해 사고 중 즉시 폐기할 수 있다. - Token Lifetime Enforcement로 토큰이 관리자가 정한 최대 수명을 넘겨 사용되지 않도록 강제한다. - Audit Event Streaming은 토큰 생성, 권한 변경, MR 승인, 역할 변경 등의 이벤트를 구조화된 타임스탬프와 함께 SIEM으로 실시간 전송한다. - 그룹 단위 SBOM을 이용해 전체 프로젝트 포트폴리오에서 오픈소스 의존성 노출 여부를 검색한다. ## 정책을 파이프라인에서 자동으로 강제 - 문서로만 존재하는 정책은 개발자가 매번 기억하고 설정해야 하므로, 사람이 만든 변경뿐 아니라 AI 에이전트가 만든 변경에도 일관되게 적용하기 어렵다. - Scan Execution Policies는 운영 환경을 대상으로 하는 모든 파이프라인에 SAST, SCA, 시크릿 탐지 작업을 자동 삽입한다. - 프로젝트별 설정이 필요 없다. - 개발자가 보안 작업을 임의로 제거할 수 없다. - `[skip ci]`로 우회할 수 없다. - Pipeline Execution Policies(PEP)는 플랫폼이 관리하는 CI 템플릿을 강제한다. - 팀이 별도로 만든 이른바 섀도 파이프라인도 동일한 접근 권한과 신뢰 수준으로 실행되는 문제를 줄인다. - 프로젝트의 CI 설정에 보안 작업이 빠져 있어도 필수 검사를 실행한다. - MR Approval Policies로 보호 브랜치, 최소 승인자 수, 코드 소유자 승인 요건을 자동화한다. - Compliance Center는 정책을 SOC 2, ISO 27001, NIST, PCI DSS 등의 기준과 연결하고, 실시간 대시보드와 변경 이력 보고서를 제공한다. - Secret Push Protection은 pre-receive hook 단계에서 비밀정보가 Git 이력에 들어가기 전에 푸시를 차단한다. - 문제가 된 파일과 줄, 탐지된 시크릿 유형을 표시한다. - 우회 시도도 기록한다. ## 개발 흐름 안에서 취약점 수정 - MR 보안 위젯은 코드가 기본 브랜치에 병합되기 전에 diff 내부에 SAST, SCA, 컨테이너, IaC, 시크릿 탐지 결과를 표시한다. - 개발자는 별도 보안 포털로 이동하지 않고 현재 MR에서 다음 정보를 확인할 수 있다. - 새로 발생한 취약점 - 취약점이 존재하는 코드 위치 - 수정 방법 - Advanced SAST는 여러 함수와 파일을 가로지르는 데이터 흐름을 분석해, 공격자가 입력값을 추적하는 방식으로 오염된 입력이 최종 사용 지점까지 도달하는 경로를 보여준다. - GitLab Duo Agent Platform은 오탐 가능성을 평가하고 판단 근거를 설명해 불필요한 수동 분류 작업을 줄인다. - GitLab Duo Security Analyst Agent는 CVSS 점수만 보지 않고 악용 가능성, 외부 노출 정도, 비즈니스 맥락을 고려해 취약점의 우선순위를 정한다. - Agentic Vulnerability Resolution은 영향이 큰 SAST 취약점에 대해 수정 MR을 자동으로 생성한다. - 관련 코드 맥락이 함께 포함된다. - 개발자가 변경 내용을 검토하고 기존 승인 절차에 따라 병합한다. - 탐지부터 수정·배포까지 같은 워크플로 안에서 완료할 수 있다. ## AI 시대의 파이프라인 보안 전략 - AI 에이전트가 코드를 생성하고 MR을 열며 변경 사항을 배포하는 속도는 기존 보안 검토보다 빠르다. - 따라서 보안 검사를 개발자에게 맡기거나 별도 대시보드에 의존하기보다, 그룹·플랫폼 수준에서 자동 적용해야 한다. - 효과적인 통제면은 다음 세 요소를 함께 제공해야 한다. - **가시화:** 모든 프로젝트, 토큰, 의존성, 보안 이벤트 확인 - **강제:** 파이프라인과 MR마다 정책을 자동 적용 - **수정:** 코드 변경 지점에서 우선순위화와 자동 수정 수행 실무적으로는 먼저 그룹 단위 보안 대시보드와 SBOM으로 사각지대를 파악한 뒤, 필수 스캔·승인·시크릿 차단 정책을 플랫폼 수준에서 강제하는 접근이 권장된다. 이후 AI 기반 오탐 분류와 자동 수정 MR을 도입하면 개발 속도를 크게 떨어뜨리지 않으면서 보안 부채를 줄일 수 있다.

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

gitlabCI/CDDevSecOpssast+4

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

GitLab Act 2

GitLab은 에이전트 중심의 소프트웨어 개발 시대에 맞춰 회사의 조직과 기술 기반을 동시에 재편하겠다고 밝혔다. 이를 위해 구조조정, 조직 계층 축소, R&D 팀 재편, AI 기반 내부 프로세스 자동화를 추진하며, 플랫폼도 기계 규모의 작업과 전 생애주기 오케스트레이션을 지원하도록 재설계한다. GitLab은 이러한 변화가 개발자의 역할을 없애는 것이 아니라, 복잡한 설계·판단·문제 해결을 담당하는 엔지니어의 중요성을 더욱 높일 것이라고 주장한다. ## 구조조정과 운영 방식의 변화 - 구조조정 계획을 공개적으로 진행하고, 자발적 퇴직 프로그램도 함께 운영한다. - 새로운 회사 구조는 가능한 경우 2026년 6월 1일까지 확정할 계획이며, 지역별 법적 절차가 필요한 경우 해당 절차가 끝난 뒤 변경한다. - 소규모 팀이 있는 국가를 중심으로 운영 국가 수를 최대 30% 줄이고, 해당 시장은 파트너 네트워크를 통해 지원한다. - 일부 조직에서 관리 계층을 최대 3단계 줄여 리더와 실무진 사이의 거리를 좁힌다. - R&D를 약 60개의 소규모·자율 팀으로 재편하고, 각 팀이 기능의 시작부터 끝까지 책임지도록 한다. - 검토, 승인, 인계 같은 내부 프로세스에 AI 에이전트를 도입해 업무 속도를 높이고, 이에 맞춰 역할과 인력 규모를 조정한다. - 구조조정의 최종 범위와 재무 영향은 이사회 승인 후 6월 2일 실적 발표에서 공개할 예정이다. - 회사는 1분기 및 FY27 연간 가이던스를 유지한다고 밝혔다. ## 에이전트 시대에 대한 전략적 관점 - 앞으로 소프트웨어는 사람이 직접 작성하기보다, 사람이 방향과 판단을 제시하고 기계가 계획·코딩·리뷰·배포·복구를 수행하는 방식으로 발전한다고 본다. - 인간은 아키텍처 설계, 고객 문제의 본질 파악, 트레이드오프 판단처럼 높은 수준의 의사결정을 맡는다. - 소프트웨어 생산 비용과 시간이 감소하면 소프트웨어에 대한 수요가 크게 증가할 것으로 전망한다. - 개발자 플랫폼의 경제적 가치가 기존 사용자당 월 수십 달러 수준에서 수백 달러, 장기적으로 수천 달러 수준으로 커질 수 있다고 주장한다. - 자동화가 확대되어도 분산 시스템, 장애 분석, 복잡한 시스템 통합, 모호한 상황에서의 의사결정 등 고난도 엔지니어링 업무는 오히려 늘어난다. - GitLab은 2026년 1월 출시한 Duo Agent Platform의 초기 도입 성과를 바탕으로 에이전트 기능을 더욱 가속화할 계획이다. ## 기계 규모를 위한 인프라 재설계 - AI 에이전트는 동시에 여러 머지 리퀘스트를 생성하고, 지속적으로 파이프라인을 실행하며, 인간 팀보다 훨씬 빠르게 커밋을 발생시킨다. - 기존 Git과 개발 플랫폼은 인간 중심의 작업량을 전제로 설계됐기 때문에 에이전트 수준의 부하를 감당하려면 근본적인 재설계가 필요하다고 본다. - GitLab은 다음과 같은 방향을 제시한다. - Git 자체를 기계 규모의 작업량에 맞게 재설계 - 모놀리식 구조를 현대적인 API 우선·조합형 서비스로 전환 - 에이전트가 인간용 인터페이스를 우회하지 않고 플랫폼의 일급 사용자로 동작할 수 있는 전용 API 제공 - 목표는 에이전트 작업량을 기본값으로 처리할 수 있는 100배 규모의 인프라와 높은 성능·신뢰성을 확보하는 것이다. ## 전체 개발 생애주기의 오케스트레이션 - 단일 에이전트가 코드를 작성하거나 머지 리퀘스트를 만드는 것만으로는 기업의 목표인 안정적인 운영 소프트웨어 제공을 달성할 수 없다. - 오케스트레이션 계층은 여러 에이전트를 조정하고 다음 작업을 담당한다. - 작업 할당 - 상태 관리 - 실행 단계 간 컨텍스트 전달 - 충돌 해결 - 정책 적용 - 중요한 단계에서의 인간 검토 유지 - 기존 CI/CD 파이프라인은 사람이 생성하는 커밋을 안전하게 배포하도록 설계됐지만, 앞으로는 에이전트를 조정하고 결과를 검증하며 가드레일을 적용하는 런타임으로 재구성된다. - 최종적으로 에이전트의 작업을 운영 환경까지 안전하게 연결하는 것이 목표다. ## 연결된 컨텍스트를 경쟁력으로 활용 - 코드 생성 기능 자체는 개발 도구 업체 간에 비슷해져 상품화될 가능성이 높다고 본다. - 차별화 요소는 모델이 활용할 수 있는 기업 고유의 컨텍스트다. - GitLab은 계획, 코드, 리뷰, 보안, 배포, 운영 정보를 프로젝트와 저장소 전체에 걸쳐 연결하는 데이터 모델을 핵심 자산으로 삼는다. - 이 데이터 모델을 API로 제공하면 사람과 에이전트의 모든 작업이 축적되어 시간이 지날수록 더 풍부한 컨텍스트가 만들어진다. - 충분한 컨텍스트가 있으면 에이전트가 불필요한 토큰을 덜 사용하면서도 더 정확한 결과를 낼 수 있다는 설명이다. ## 플랫폼에 내장하는 거버넌스 - 기업이 에이전트의 속도를 활용하려면 동시에 통제력을 유지해야 한다. - 에이전트가 수행할 수 있는 작업이 늘어날수록 다음 기능이 플랫폼의 기본 요소가 되어야 한다. - 누가 무엇을 실행할 수 있는지 정의하는 신원 및 권한 관리 - 어떤 작업이 언제, 왜 수행됐는지 확인하는 감사 기록 - 에이전트와 파이프라인의 행동을 제한하는 정책 집행 - 민감한 코드와 데이터를 적절한 위치에 보관하는 배포 유연성 - 이러한 거버넌스를 별도 제품으로 덧붙이는 대신, 모든 에이전트·파이프라인·머지 리퀘스트가 기본적으로 통과하는 핵심 플랫폼 서비스로 만들 계획이다. ## 하나의 플랫폼, 세 가지 운영 모드 - 글은 GitLab이 기존 소프트웨어를 전면 재작성하지 않고도 에이전트 시대에 대응할 수 있도록 “하나의 플랫폼, 세 가지 모드”라는 방향을 제시한다고 소개한다. - 다만 제공된 본문은 이 항목의 설명이 `T...`에서 중단되어 있어 세 가지 모드의 구체적인 내용은 확인할 수 없다. GitLab의 계획은 단순한 AI 기능 추가가 아니라, 조직 구조·내부 운영·Git 인프라·CI/CD·데이터 모델·거버넌스를 함께 바꾸는 전사적 전환이다. 기업 고객 입장에서는 에이전트의 생산성보다도 권한 통제, 감사 가능성, 컨텍스트 연결, 안정적인 배포를 지원하는지가 도입 판단의 핵심이 될 것으로 보인다.

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

gitlabAI 에이전트CI/CD분산 시스템+4

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

Kubernetes에서 Gitaly로 GitLab 스택 통합하기

GitLab 18.11부터 Gitaly on Kubernetes가 정식 지원되면서, GitLab의 모든 구성 요소를 Kubernetes에서 운영할 수 있게 되었습니다. 기존의 Kubernetes와 VM을 함께 사용하는 하이브리드 구조를 없애고, 인프라 운영과 모니터링을 단일 Kubernetes 환경으로 통합할 수 있습니다. 다만 현재 Gitaly Cluster(Praefect)는 Kubernetes를 아직 지원하지 않아 완전한 고가용성은 제공되지 않습니다. ### Kubernetes 환경에 맞춘 Gitaly의 변화 - Git 작업은 메모리 사용량이 크고 패턴을 예측하기 어렵습니다. - Gitaly는 Git 프로세스를 별도 cgroup에서 실행해 메모리 초과로 프로세스가 종료되더라도 주 Gitaly 프로세스가 영향을 받지 않도록 합니다. - Kubernetes에서 이 구조를 구현하기 위해 다음 작업이 필요했습니다. - `containerd` 환경에서 cgroupfs에 쓰기 권한을 부여 - init container로 `/sys/fs/cgroup`를 마운트 - 해당 경로를 쓰기 가능하도록 설정 - 이를 통해 Git 프로세스의 OOM(메모리 부족) 종료가 Gitaly 전체 장애로 이어지는 것을 방지합니다. ### Pod 재시작과 서비스 중단 문제 - VM에서는 Omnibus가 Gitaly 바이너리를 교체하고 소켓을 유지한 채 graceful reload를 수행할 수 있습니다. - Kubernetes에서는 Helm 업그레이드, 노드 드레이닝, 설정 변경 등으로 StatefulSet Pod가 교체되면 프로세스가 강제 종료된 뒤 재시작됩니다. - Gitaly Sharded처럼 자체 고가용성을 제공하지 않는 구성에서는 이 방식이 일시적인 중단을 일으킬 수 있습니다. - 이를 보완하기 위해 Rails 등 Gitaly 클라이언트의 요청 재시도 시간을 설정할 수 있게 했습니다. - Gitaly가 재시작되는 동안 요청을 재시도 - 사용자는 짧은 시간 동안 약간 높은 지연을 경험할 수 있음 - 재시작이 완료되면 요청은 최종적으로 성공 ### 업그레이드 중에도 높은 성공률 유지 - VM 기반 Gitaly와 Kubernetes 기반 Gitaly에서 일반적인 Git 작업을 실행한 뒤, 테스트 중간에 업그레이드를 수행하는 벤치마크를 진행했습니다. - 두 환경의 요청 성공률은 거의 동일했습니다. - Kubernetes에서는 Pod 종료 시 프로세스가 즉시 끝나고 소켓도 닫히지만, 클라이언트 재시도 덕분에 대부분의 요청이 성공했습니다. - 모든 작업에서 100% 성공률을 보장하려면 Gitaly Cluster(Praefect)가 필요합니다. - 그러나 Praefect는 현재 Kubernetes를 지원하지 않으며, Kubernetes 지원의 정식 제공을 준비 중입니다. ### 인프라 통합의 효과 - 기존 하이브리드 배포 사용자는 Gitaly를 VM에서 Kubernetes 클러스터로 이전할 수 있습니다. - 별도의 Gitaly VM fleet를 유지·모니터링할 필요가 없어집니다. - GitLab 전체를 Kubernetes가 관리하는 단일 환경으로 통합할 수 있습니다. - Kubernetes를 이미 운영 중인 신규 GitLab 사용자도 Helm chart를 통해 Kubernetes 네이티브 방식으로 GitLab을 배포할 수 있습니다. ### 설치 방법과 배포 형태 - 권장 설치 방법은 GitLab Helm chart를 사용하는 것입니다. - 설치 전 Gitaly on Kubernetes 공식 문서를 확인해 주요 설정과 일반적인 문제를 검토해야 합니다. - Gitaly는 두 가지 형태로 배포할 수 있습니다. - 전체 GitLab 설치의 일부로 배포 - 외부 Gitaly 구성 요소로 별도 배포 - 구체적인 설정 방법과 주의사항은 Gitaly on Kubernetes 문서에서 각 시나리오별로 제공합니다. ### 실용적인 결론 GitLab을 Kubernetes 중심으로 운영하는 팀이라면 Gitaly를 클러스터로 통합하는 것이 운영 복잡성을 줄이는 현실적인 선택입니다. 다만 무중단 고가용성이 반드시 필요한 환경은 Praefect의 Kubernetes 지원 여부를 확인한 뒤 도입을 결정하는 것이 좋습니다.

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

gitlab쿠버네티스Gitgitops+4

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

유출된 개인 액세스 토큰 하나로 소유자가 접근할 수 있는 모든 프로젝트가 노출되어서는 안 됩니다. 세분화된 PAT는 각 토큰의 권한을 해당 작업에 맞게 제한합니다.

GitLab은 개인 액세스 토큰(PAT)을 작업별·리소스별로 제한하는 세분화된 PAT를 베타로 공개했습니다. 토큰이 특정 프로젝트의 특정 리소스에서 필요한 작업만 수행하도록 설정해, 유출 시 피해 범위를 전체 계정이 아닌 해당 작업과 프로젝트로 줄이는 것이 핵심입니다. 다만 현재 REST API의 약 75%만 지원하므로 정식 출시 전까지는 운영 환경 사용을 권장하지 않습니다. ## 광범위한 PAT의 보안 위험 - `api`나 `read_api`처럼 넓은 범위의 스코프는 사용자가 접근 가능한 여러 프로젝트와 그룹에 권한을 부여합니다. - 하나의 토큰으로 소스 코드 조회, 파이프라인 수정, 컨테이너 레지스트리 접근, CI/CD 변수 복호화 등을 모두 수행할 수 있습니다. - 토큰이 유출되면 공격자가 해당 사용자가 접근 가능한 전체 프로젝트를 악용할 수 있습니다. - 토큰의 권한이 특정 작업이 아니라 사용자 계정에 묶여 있어 피해 범위가 커집니다. ## 작업별 최소 권한 부여 - 세분화된 PAT는 자동화 작업마다 별도의 토큰을 발급하는 방식입니다. - 토큰이 접근할 수 있는 범위를 다음처럼 지정할 수 있습니다. - 개인 프로젝트만 - 사용자가 속한 모든 프로젝트와 그룹 - 선택한 특정 프로젝트와 그룹 - 접근 가능한 리소스별로 권한을 독립 설정할 수 있습니다. - Issues - Merge Requests - Pipelines - Repositories - Container Registry 등 - 각 리소스에 대해 `Create`, `Read`, `Update`, `Delete` 권한을 개별적으로 부여합니다. ## 컨테이너 레지스트리 활용 예시 - 컨테이너 이미지를 빌드하고 업로드하는 파이프라인에는 전체 `api` 토큰 대신 특정 프로젝트의 Container Registry용 토큰을 발급합니다. - 해당 토큰에는 필요한 `Create`와 `Read` 권한만 부여할 수 있습니다. - 토큰이 유출되어도 피해 범위는 전체 프로젝트나 계정이 아닌 해당 프로젝트의 컨테이너 레지스트리로 제한됩니다. ## 토큰 감사와 추가 보호 장치 - 토큰 목록 화면에서 기존 PAT와 세분화된 PAT의 전체 스코프 및 리소스별 권한을 확인할 수 있습니다. - 과도한 권한을 가진 토큰을 보안 검토 중 쉽게 식별할 수 있습니다. - 토큰 만료 기간 제한과 자동 폐기 기능을 함께 사용하면 도난된 토큰의 악용 시간을 줄일 수 있습니다. - 작업별 토큰을 사용하면 유출 이후 조사와 대응 범위도 해당 작업과 프로젝트로 좁힐 수 있습니다. ## 베타 단계의 지원 범위와 제한 - 세분화된 PAT는 현재 REST API 엔드포인트의 약 75%를 지원합니다. - 향후 나머지 REST API와 GraphQL 지원 범위를 확대할 예정입니다. - 정식 출시 전까지는 프로덕션 워크로드에 사용하지 않는 것이 권장됩니다. - 베타 기간에는 기존 PAT와 세분화된 PAT를 동시에 생성해 호환성과 권한 모델을 평가할 수 있습니다. ## 생성 방법 - **User Settings → Personal Access Tokens**로 이동합니다. - **Generate token** 메뉴에서 **Fine-grained token**을 선택합니다. - 접근 가능한 프로젝트·그룹과 리소스별 권한을 설정합니다. - 지원 리소스와 관리자 제어 항목은 GitLab의 세분화된 PAT 문서에서 확인할 수 있습니다. 실무에서는 자동화 작업마다 별도 토큰을 만들고, 특정 프로젝트와 필요한 리소스의 최소 권한만 부여하는 방식이 권장됩니다. 베타 기간에는 프로덕션 적용을 피하고, 먼저 테스트 환경에서 기존 PAT와의 호환성 및 API 지원 범위를 검증하는 것이 안전합니다.

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

gitlabGraphQLrest-apiapi-security+3

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

Claude Code와 GitLab: 실제 배포로 이어지는 세 가지 워크플로

Claude Code는 코드 작성과 디버깅을 빠르게 수행하지만, 실제 배포에는 CI/CD, 보안 검사, 코드 리뷰, 승인 등 추가 과정이 필요하다. 이 글은 Claude Code와 GitLab을 결합해 버그 수정부터 머지 리퀘스트, 검증, 리뷰, 배포까지 연결하는 세 가지 워크플로를 소개한다. GitLab MCP와 Duo Agent Platform을 활용하면 AI가 로컬 코드뿐 아니라 이슈와 과거 개발 맥락까지 반영할 수 있다. ## 코드 수정과 GitLab 검증 파이프라인 연결 - C++로 작성된 Arduino IoT Collector가 `/dev/ttyACM0` 장치가 없을 때 충돌하는 버그를 예제로 사용한다. - `cmake`로 프로젝트를 빌드하고 실행해 문제를 재현한다. - Claude Code에 버그 수정을 요청하면 코드베이스를 탐색해 `main.cpp`의 `std::runtime_error` 예외가 애플리케이션을 즉시 종료시키는 원인임을 찾는다. - 수정 방향은 예외로 프로세스를 중단하는 대신 사용자 친화적인 설정 오류를 기록하고 애플리케이션은 계속 실행하도록 바꾸는 것이다. - 수정 후 Claude Code 또는 직접 Git 명령으로 다음 작업을 수행한다. - 수정 브랜치 생성 - 변경 사항 커밋 - 원격 저장소에 푸시 - 머지 리퀘스트 생성 - MR이 생성되면 GitLab이 자동으로 다음을 수행한다. - 빌드 및 테스트를 위한 CI/CD 파이프라인 실행 - 새 취약점이 추가되지 않았는지 보안 스캔 - GitLab Duo Code Review를 통한 코드 정확성 및 스타일 검토 - 코드 리뷰에는 프로젝트의 C++ 개발 규칙과 사용자 정의 리뷰 지침도 적용할 수 있다. ## GitLab MCP로 이슈와 개발 이력 활용 - 로컬 저장소만 이용하면 Claude Code가 버그 리포트, 디버깅 논의, 과거 MR의 해결 방식 등을 알 수 없다는 한계가 있다. - GitLab MCP Server를 연결하면 Claude Code가 GitLab의 SDLC 맥락을 함께 조회할 수 있다. - 관련 이슈와 설명 - 이슈 댓글 및 논의 - 과거 머지 리퀘스트 - 유사한 버그의 수정 이력 - 프로젝트 내 개발 정보 - GitLab 인스턴스 또는 최상위 그룹에서 MCP Server를 활성화한 뒤, Claude Code에 HTTP 방식으로 추가한다. ```bash claude mcp add --transport http GitLab https://gitlab.example.com/api/v4/mcp ``` - 새 Claude Code 세션에서 `/mcp`를 실행하고 브라우저 OAuth 인증을 완료한다. - MCP 도구 목록과 서버 버전을 질의해 연결 상태를 확인할 수 있다. - MCP는 Claude에 추가적인 맥락을 제공할 뿐 권한을 상승시키지 않는다. - Claude Code는 인증한 사용자가 원래 접근할 수 있는 프로젝트와 이슈만 볼 수 있다. - GitLab의 프로젝트·그룹 멤버십과 가시성 설정을 우회하지 않는다. - 별도의 관리자 권한을 자동으로 부여하지 않는다. ## Claude Code와 GitLab Duo Agent Platform의 역할 분담 - Claude Code는 터미널이나 IDE에서 코드 탐색, 버그 수정, 기능 구현을 담당한다. - GitLab은 변경 사항을 실제로 출하하기 위한 중앙 플랫폼 역할을 한다. - CI/CD - 보안 검사 - 코드 리뷰 - 승인 절차 - 감사 가능한 변경 이력 - 세 번째 워크플로에서는 GitLab Duo Agent Platform의 외부 에이전트가 Claude를 활용해 MR의 코드 리뷰 피드백을 직접 반영한다. - 따라서 개발자가 리뷰 댓글을 수동으로 해석하고 수정하는 대신, 에이전트가 MR 맥락에서 코드를 변경하고 후속 검증까지 진행할 수 있다. ## 필요한 개발 환경 - 터미널에서 실행 가능한 Claude Code - 버그와 기능 제안 이슈가 등록된 GitLab 프로젝트 - 필요에 따라 GitLab MCP Server와 GitLab Duo Agent Platform 외부 에이전트 - C++ 예제 실행 시: - CMake - Make - gcc 또는 clang++ - Java 프로젝트를 다룰 경우 Maven - 예제 프로젝트를 클론한 뒤 `claude` 명령으로 Claude Code를 실행하고 프로젝트 목적을 먼저 질의할 수 있다. 실무에서는 Claude Code를 코드 작성과 문제 해결에 사용하고, GitLab을 CI/CD·보안·리뷰·승인의 통합 관문으로 두는 방식이 효과적이다. 특히 GitLab MCP를 연결하면 AI가 단순히 현재 파일만 보고 추측하지 않고, 실제 이슈와 과거 변경 이력을 근거로 더 일관된 수정을 제안할 수 있다.

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

gitlab코드 리뷰claude-codec-plus-plus+4

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

팀 협업을 재편하는 8가지 에이전틱 AI 패턴

17개 에이전틱 AI 플랫폼을 분석한 결과, 팀 협업을 혁신하는 핵심은 개별 에이전트의 성능보다 팀 전체의 업무 흐름을 얼마나 일관되게 연결하느냐에 있다. 특히 에이전트는 진행 상황 공유, 업무 배정, 커뮤니케이션, 권한 관리, 개발·배포 거버넌스를 지원하며 팀의 속도와 판단력을 높이고 통제력을 유지하게 한다. 글은 이러한 기능을 8가지 패턴으로 정리하고, 소프트웨어 개발 생명주기 전체가 하나의 플랫폼에 통합된 GitLab이 에이전트 협업에 구조적 강점을 가진다고 주장한다. ## 1. 진행 상황 자동 공유 - 에이전트가 실시간 작업 데이터를 바탕으로 진행 상황과 상태 보고서를 자동 생성한다. - 일정 지연, 차단 요소, 위험 요소를 사전에 감지해 관련 담당자에게 전달한다. - 정기 상태 회의나 수동 확인 절차를 줄이고, 필요한 사람에게 필요한 정보만 제공한다. - 팀이 더 빠르게 움직이고, 업무 상황을 더 정확하게 파악할 수 있다. ## 2. 사람 간 업무 라우팅 - 대기열에 쌓인 업무를 담당자의 기술, 현재 업무량, 프로젝트 맥락에 따라 자동 배정한다. - 계획 수립 시점에만 업무를 조정하는 것이 아니라, 프로젝트 진행 중에도 지속적으로 부하를 균형 조정한다. - 에이전트가 왜 특정 담당자에게 업무를 배정했는지 근거를 공개한다. - 사람이 최종 배정 전에 개입하고 수정할 수 있어 자동화와 통제력을 함께 확보한다. ## 3. 팀 커뮤니케이션 지원 - 채널, 메시지 스레드, 회의 녹화 내용을 요약해 핵심 결정과 논점을 전달한다. - 새로 참여한 구성원도 전체 대화 기록을 직접 읽지 않고 업무 맥락을 파악할 수 있다. - 반복 질문과 역할 간 재설명을 줄이고, 동기식 회의 대신 비동기 요약을 활용한다. - 정보 공유 속도와 의사결정 효율을 높인다. ## 4. 채팅 안의 역할별 에이전트 - 팀이 이미 사용하는 Slack 등의 커뮤니케이션 도구 안에 전문 에이전트를 배치한다. - 온보딩 질문, IT 장애 처리, 영업 브리핑 등 역할별 업무를 대화 흐름에서 바로 수행한다. - 예를 들어 메시지에 이모지 반응을 추가하는 것만으로 추적 티켓을 생성할 수 있다. - 별도 포털이나 도구로 이동하지 않아도 대화가 곧 업무 실행의 출발점이 된다. ## 5. 공유되는 대화 맥락 - 에이전트가 여러 사람이 참여한 대화의 스레드와 파일을 지속적으로 인식한다. - 한 사람이 에이전트에게 제공한 정보와 지식이 팀 전체에 공유된다. - 새 구성원이나 다른 에이전트도 이전 작업이 끝난 지점에서 바로 이어서 작업할 수 있다. - 구성원마다 같은 문제를 반복해서 설명하거나 중복 프롬프트를 작성하는 일을 줄인다. ## 6. 역할 기반 접근 제어(RBAC) - 에이전트가 부여받은 역할에 허용된 데이터와 기능만 접근하도록 제한한다. - 권한은 단순한 시스템 단위가 아니라 필드 수준까지 세밀하게 적용될 수 있다. - 권한이 없는 데이터는 에이전트가 읽거나 추론하거나 조작할 수 없다. - 모든 에이전트의 작업을 기록해 규정 준수와 감사에 필요한 추적성을 제공한다. ## 7. 통제된 에이전트 실행 환경 - 에이전트를 코드와 마찬가지로 개발·테스트·운영 환경을 거쳐 배포한다. - 초기 개발 단계에서는 격리된 샌드박스를 사용해 에이전트 간 충돌을 방지한다. - 관리형 승격 파이프라인을 통해 검증되지 않은 에이전트가 운영 환경에 진입하지 않도록 한다. - 운영 중인 에이전트에 대한 무분별한 업데이트가 실제 업무를 중단시키는 위험도 줄인다. ## 8. 에이전트 공동 개발 - 여러 구성원이 에이전트를 공동 소유하고 수정·유지보수할 수 있다. - 역할별 권한을 부여하고, 공유 개발 공간에서 실시간으로 에이전트를 디버깅한다. - 표준화된 프로토콜을 사용해 서로 다른 사람이 만든 에이전트의 호환성을 유지한다. - 에이전트 개발을 개인 작업이 아니라 버전 관리와 협업이 필요한 팀 활동으로 만든다. ## 경쟁 환경에서 드러난 흐름 - 에이전트는 별도 애플리케이션보다 팀이 이미 일하는 채팅 도구 안으로 이동하고 있다. - 조직 규모가 커질수록 권한, 감사 로그, 배포 통제 같은 거버넌스가 필수 요소가 된다. - 에이전트 제작 역시 공동 소유, 협업 수정, 감사 가능한 버전 관리가 기본 기능이 되고 있다. - 상태 회의, 수동 확인, 역할 간 반복 설명 같은 ‘조정 비용’을 에이전트가 줄이기 시작했다. - 경쟁력은 가장 강력한 단일 에이전트보다 여러 에이전트와 사람을 일관된 팀 경험으로 연결하는 데서 나온다. ## 아직 부족한 통합형 거버넌스 - 분석된 플랫폼에서 가장 드문 기능은 다음 요소를 하나로 연결하는 통합 환경이다. - 실행 환경 그룹화 - 에이전트 카탈로그 공유 - 관리형 배포·승격 파이프라인 - 대부분의 플랫폼은 권한 관리나 배포 관리 등 거버넌스의 일부만 해결한다. - 개발부터 운영까지 에이전트를 안전하게 만들고 공유하고 배포하는 전체 흐름을 연결한 사례는 많지 않다. ## GitLab에 대한 시사점 - GitLab은 소프트웨어 개발과 배포 전 과정이 하나의 플랫폼에 있어 에이전트를 외부에서 덧붙일 필요가 적다. - GitLab Duo Agent Platform은 기존 워크플로를 규칙으로 활용하고, 조직의 맥락과 지식을 공유하며, 가드레일로 실행을 통제하는 방향을 취한다. - 따라서 코드 작성뿐 아니라 계획, 개발, 테스트, 보안, 배포 등 전체 DevSecOps 생명주기에서 에이전트를 조율할 수 있다는 것이 글의 결론이다. 팀에 에이전트를 도입할 때는 개별 자동화 기능보다 공유 맥락, 투명한 업무 배정, 세밀한 권한, 테스트·승격 파이프라인, 공동 유지보수 체계를 먼저 설계하는 것이 바람직하다. 그래야 속도 향상뿐 아니라 보안과 책임성까지 확보할 수 있다.

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

gitlabAI 에이전트DevSecOpsgovernance+3

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

Atlassian이 여러분의 데이터를 학습에 사용합니다: GitLab으로 거부하세요

Atlassian은 2026년 8월 17일부터 Jira, Confluence 등 클라우드 제품의 메타데이터와 인앱 콘텐츠를 AI 서비스 학습에 기본적으로 활용할 예정이다. Free·Standard·Premium 고객은 메타데이터 수집을 끌 수 없고, Enterprise 고객만 옵트아웃할 수 있어 데이터 거버넌스와 규제 준수에 큰 부담이 생긴다. 글은 이러한 옵트아웃 기본 정책과 달리, GitLab은 요금제와 관계없이 고객 데이터를 수집하거나 AI 학습에 사용하지 않는 접근을 취한다고 설명한다. ## Atlassian의 데이터 수집 정책 변경 - 수집 대상은 크게 두 가지다. - **메타데이터**: 스토리 포인트, 스프린트 날짜, SLA 값, 작업 분류, Teamwork Graph 및 연결된 외부 앱의 운영 신호 - **인앱 콘텐츠**: Confluence 페이지, Jira 이슈 제목·설명·댓글 등 사용자가 작성한 내용 - Atlassian은 학습 전에 데이터를 비식별화하고 집계한다고 설명한다. - 수집 데이터는 최대 7년 보관될 수 있다. - 옵트아웃하면 인앱 데이터는 30일 이내 삭제되고, 관련 모델은 90일 이내 재학습된다고 안내한다. - 고객 관리 암호화 키, Government Cloud, Isolated Cloud, HIPAA 적용 고객은 수집 대상에서 제외된다. ## 요금제에 따른 옵트아웃 문제 - 모든 클라우드 고객에게 데이터 수집이 기본 활성화된다. - Free, Standard, Premium 고객은 메타데이터 수집을 비활성화할 수 없다. - Enterprise 고객만 옵트아웃할 수 있으며, 최소 801명의 사용자가 필요하고 별도 가격이 적용된다. - 결과적으로 데이터 보호가 기술 설정이 아니라 고비용 Enterprise 요금제로의 업그레이드 여부에 달려 있다. - Atlassian이 과거에 밝혔던 “고객 데이터를 AI 서비스 학습이나 개선에 사용하지 않는다”는 입장과도 달라졌다. ## 비식별 메타데이터도 민감할 수 있는 이유 - 스토리 포인트, 스프린트 속도, SLA 지표는 개별적으로는 민감하지 않아 보일 수 있다. - 그러나 장기간 축적하면 다음 정보를 추론할 수 있다. - 조직의 프로젝트 구조 - 팀별 생산성과 성과 패턴 - 릴리스 및 업무 처리 주기 - 운영 방식과 병목 구간 - 데이터가 비식별화되더라도 여러 신호를 결합하면 조직의 운영 특성을 재구성할 수 있으므로, 비식별화가 곧 비민감성을 의미하지는 않는다. ## Atlassian 생태계에서 커지는 데이터 범위 - Jira와 Confluence는 스프린트 계획, 버그 추적, 릴리스 관리, 보안 티켓, 사고 보고서, 내부 문서의 시스템 오브 레코드로 사용된다. - Bitbucket과 Bamboo까지 함께 사용하면 다음 정보도 데이터 흐름에 포함될 수 있다. - 소스 코드 관련 메타데이터 - CI/CD 구성 - 프로젝트 계획과 기술 문서 - Teamwork Graph 커넥터를 통해 Slack, Figma, Google Drive, Salesforce, ServiceNow 같은 외부 서비스의 관계·활동 신호도 연결될 수 있다. - 따라서 보안·컴플라이언스 팀은 Atlassian 제품 내부뿐 아니라 연결된 제3자 서비스까지 포함해 데이터 흐름을 검토해야 한다. - Data Center·Server에서 Atlassian Cloud로 이전하려는 조직은 클라우드 전환과 AI 학습 데이터 제공 문제를 함께 판단해야 한다. ## 옵트아웃 기본 정책의 거버넌스 공백 - 약관 변경만으로 데이터 처리 방식이 바뀌면 고객이 직접 변경 사항을 발견하고 위험을 평가해야 한다. - 다음 항목이 기존 계약 및 내부 정책과 일치하는지 확인해야 한다. - 데이터 처리 계약(DPA) - “메타데이터”의 정의 - 제3자 앱에서 유입되는 데이터 범위 - 보관 기간과 삭제 절차 - AI 모델 재학습 및 삭제 방식 - 조직의 법무·보안팀이 민감하다고 판단하는 정보가 Atlassian의 “비민감 메타데이터” 정의와 다를 수 있다. ## 규제 산업이 재평가해야 할 사항 - 금융 서비스 기업은 SR 11-7, DORA 등에 따라 외부 기술 제공업체의 데이터 처리와 통제를 문서화하고 감사 가능하게 관리해야 한다. - 공공 부문은 NIST 800-53과 FISMA에 따라 민감 데이터의 이동과 접근을 통제해야 한다. - 의료 분야에서는 HIPAA에 따른 제3자 데이터 처리 검토가 필요하다. - EU AI Act 적용 조직은 미국식 옵트아웃보다 유럽 규제 환경의 옵트인 동의 기대와 충돌할 가능성을 검토해야 한다. - 기존에 Atlassian의 데이터 처리 방식을 평가했다면, “고객 데이터를 학습에 사용하지 않는다”에서 “기본적으로 사용한다”로의 변경은 공급업체 위험평가와 관련 문서의 갱신 사유가 된다. ## GitLab의 대안적 접근 - GitLab은 고객 데이터에 대해 다음 원칙을 제시한다. - 고객 데이터 수집 없음 - 고객 데이터로 AI 모델 학습 없음 - 요금제와 관계없이 동일한 데이터 보호 원칙 적용 - 핵심 차이는 데이터 보호를 Enterprise 같은 특정 고가 요금제의 기능으로 제한하지 않는다는 점이다. - 글은 CTO와 CISO가 AI 도입을 규제기관, 이사회, 고객에게 설명할 수 있어야 하며, 이를 위해 명확하고 조건 없는 데이터 처리 약속이 필요하다고 주장한다. ## 실용적인 대응 - 2026년 8월 17일 이전에 Atlassian 데이터 흐름과 연결 앱 목록을 재검토한다. - Jira·Confluence의 콘텐츠뿐 아니라 Teamwork Graph가 가져오는 외부 서비스 메타데이터도 목록화한다. - DPA, 개인정보 처리방침, 보안 정책, 규제 준수 문서를 변경된 정책과 대조한다. - Enterprise 업그레이드, 예외 환경 사용, 플랫폼 이전 등 가능한 대응책의 비용과 위험을 비교한다. - AI 기능을 도입할 때는 옵트아웃 가능 여부보다 처음부터 고객 데이터를 학습에 사용하지 않는 공급업체 정책을 우선 검토하는 것이 권장된다.

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

gitlab클라우드 컴퓨팅jiradata-privacy+3

gitlab·2026년 4월 29일원문

GitLab을 사용하여 소프트웨어 개발을 쉽게 가르치는 방법 (새 탭에서 열림)

워싱턴 대학교의 Stephen G. Dame 강사는 'GitLab for Education' 프로그램을 활용해 대규모 소프트웨어 개발 강의의 과제 배포 및 피드백 과정을 효율적으로 관리하고 있습니다. GitLab의 그룹 및 하위 그룹 구조를 통해 복잡한 권한 설정을 체계화하고, 실제 현업과 유사한 워크플로우를 교육 현장에 도입하여 학생들에게 실무적인 개발 환경을 제공하는 것이 핵심입니다. 이를 통해 교강사는 행정적 부담을 줄이면서도 학생 개개인에게 구체적이고 맥락 있는 코드 리뷰를 전달할 수 있습니다. ### 그룹 및 하위 그룹을 활용한 체계적 구조 설계 * GitLab의 고유한 '그룹(Groups)' 및 '하위 그룹(Subgroups)' 기능을 사용하여 대학 부서, 강의, 역할별로 계층적인 구조를 설계합니다. * 최상위 그룹(예: UWTeaching) 아래에 개별 강의 하위 그룹을 두고, 그 안에 강의 자료, 학생 전용 그룹, 채점자 그룹 등을 구분하여 관리합니다. * 권한 상속 기능을 활용해 학생들에게는 '리포터(Reporter)' 권한을 부여함으로써, 강의용 템플릿 코드를 복제(Clone)하거나 가져올(Pull) 수는 있지만 원본 소스에 직접 푸시(Push)할 수는 없도록 제어합니다. * 학생들은 개인별 비공개 저장소를 생성하여 자신의 버전 히스토리를 관리하고, SSH 키 설정을 통해 로컬 환경이나 가상 머신에서 원활하게 작업할 수 있습니다. ### REST API 기반의 관리 자동화 * 수강생이 많은 대규모 강의의 경우, GitLab REST API와 Python 스크립트를 활용해 학생별 하위 그룹 생성 및 멤버 추가 과정을 자동화할 수 있습니다. * 학생의 사용자 이름을 기반으로 개인별 비공개 하위 그룹을 생성하고, 학기 종료 시점에 맞춰 권한이 자동으로 만료되도록 '만료일(Expiration date)'을 설정하여 보안을 유지합니다. * 이러한 자동화 워크플로우는 수동 관리에서 발생할 수 있는 실수를 방지하고 교강사가 교육 콘텐츠에 더 집중할 수 있는 시간을 확보해 줍니다. ### 머지 리퀘스트(Merge Request)를 통한 실무형 피드백 * 학생들은 과제 제출 시 '머지 리퀘스트(MR)'를 생성하며, 강사는 이를 통해 변경된 코드의 차이점(Diff)을 한눈에 확인하고 검토합니다. * 강사는 특정 코드 라인에 직접 인라인 댓글을 남겨 단순히 틀린 부분을 지적하는 것을 넘어, 왜 수정이 필요한지 맥락 있는 피드백을 제공합니다. * 학생들은 실제 현업의 필수 프로세스인 버전 관리와 코드 리뷰를 자연스럽게 경험하며 추상적인 개념이 아닌 실전적인 개발 습관을 체득하게 됩니다. ### 실용적인 권장 사항 처음 GitLab을 교육에 도입한다면 단일 강의 그룹과 기본 과제 템플릿으로 간단하게 시작하여 점진적으로 구조를 확장하는 것이 좋습니다. 'GitLab for Education' 프로그램을 신청하면 Ultimate 등급의 기능을 무료로 사용할 수 있으므로, 무제한 리뷰어 설정과 추가 컴퓨팅 리소스를 활용하여 교육의 질을 높일 것을 추천합니다.

gitlab데이터베이스 설계오픈 소스Python+3

gitlab·2026년 4월 29일원문

GitLab 패치 릴리스: 18.11.2, 18.10.5 | GitLab 문서 (새 탭에서 열림)

GitLab은 GitLab Dedicated 고객의 재해 복구(DR) 목표인 RTO(복구 목표 시간)와 RPO(복구 지점 목표)를 안정적으로 달성하기 위해 관측성(observability) 간극을 해결한 18.11.2 및 18.10.5 패치 버전을 출시했습니다. 이번 릴리스는 보안 수정 사항을 포함하지 않는 대신, 시스템의 안정성을 저해하는 다수의 회귀 버그와 성능 이슈를 해결하는 데 집중했습니다. 사용자들은 이번 업데이트를 통해 AI 기능의 호환성을 높이고 특정 상황에서 발생하는 시스템 부하 문제를 해소할 수 있습니다. ### 주요 기능 개선 및 버그 수정 * **AI 및 GitLab Duo 기능 강화**: 셀프 호스팅 모델을 사용하는 환경에서도 Code Suggestion 기능을 사용할 수 있도록 지원을 추가했으며, Duo Core 사용자가 코드 리뷰 기능을 차질 없이 사용할 수 있도록 개선했습니다. * **시스템 성능 및 안정성 최적화**: 특정 사용자를 차단(Ban)할 때 Sidekiq 리소스 사용량이 급증하는 스파이크 현상을 해결하여 백그라운드 작업의 안정성을 높였습니다. * **관측성 지표 추가**: 동기화되지 않은 데이터의 가장 오래된 시간을 추적하는 `*_oldest_unsynced_time` 메트릭을 추가하여 시스템 상태 모니터링을 더욱 정교화했습니다. * **UI 및 워크플로우 개선**: 워크 아이템 페이지 로드 시 기존 필터를 초기화하여 사용자 경험을 개선했으며, 실패한 재할당 작업을 다시 시도할 수 있는 GraphQL mutation을 도입했습니다. ### 인프라 및 환경별 특이 사항 * **데이터베이스 및 마이그레이션**: 18.10.5 버전에서 이미 삭제된 테이블을 참조하는 마이그레이션을 건너뛰도록 수정(BBM)하여 업데이트 오류를 방지했습니다. * **Geo 및 설치 환경 호환성**: Geo 보조(Secondary) 노드에서 불필요한 워커 실행을 방지하도록 수정했으며, 상대 경로(Relative URL)를 사용하는 설치 환경에서 OAuth 탐색이 실패하던 문제를 해결했습니다. * **기능 롤백**: 18.11.2 버전에서는 역할 및 권한 활성화와 관련된 리팩토링(ia-refactor-role-permission-enablement) 내용을 이전 상태로 되돌려 안정성을 우선시했습니다. ### 업데이트 가이드 및 권장 사항 * **다운타임 발생 유의**: 단일 노드 인스턴스의 경우 마이그레이션이 완료될 때까지 서비스 가동이 중단되므로 작업 시간을 사전에 확보해야 합니다. * **제로 다운타임 업그레이드**: 다중 노드 환경에서는 GitLab의 표준 제로 다운타임 업그레이드 절차를 따르면 서비스 중단 없이 패치를 적용할 수 있습니다. * **사후 마이그레이션 실행**: 두 버전 모두 업그레이드 프로세스 종료 후 실행해야 하는 '사후 배포 마이그레이션(Post-deploy migrations)'을 포함하고 있으므로, 관리자는 업그레이드 완료 후 해당 작업이 정상적으로 수행되었는지 확인해야 합니다.

gitlab옵저버빌리티GraphQLdatabase-migrations+4

gitlab·2026년 4월 28일원문

대규모 환경에서 CI/CD 관측성을 구축하는 방법 (새 탭에서 열림)

GitLab 셀프 매니지드 환경에서 CI/CD 가시성을 확보하는 것은 대규모 데브옵스 플랫폼의 성능 최적화와 안정적인 운영을 위한 필수 과제입니다. 이 글은 Prometheus와 Grafana, 그리고 전용 익스포터를 활용하여 원시 파이프라인 데이터를 실시간 대시보드로 변환하고 의사결정에 필요한 핵심 통찰을 얻는 기술적 방법론을 제시합니다. 이를 통해 기업은 인프라 투자 효율성을 높이고 병목 현상을 체계적으로 해결할 수 있는 데이터 기반의 관리 체계를 구축할 수 있습니다. ### 실시간 통찰을 위한 다층적 대시보드 구성 효과적인 CI/CD 옵저버빌리티를 위해 다음과 같은 네 가지 핵심 대시보드를 구성하여 운영 가시성을 확보합니다. * **파이프라인 개요 대시보드:** 전체 실행 횟수, 시간 흐름에 따른 성공/실패율, 평균 소요 시간 추이를 시각화합니다. 상태별 색상 코딩을 통해 플랫폼 팀이 성능 저하를 즉각적으로 감지할 수 있도록 합니다. * **작업(Job) 성능 대시보드:** 개별 작업의 실행 시간 분포(히스토그램)와 가장 느린 상위 10개 작업을 분석합니다. 프로젝트 및 스테이지별 실패 히트맵을 통해 최적화가 필요한 병목 지점을 특정합니다. * **러너 및 인프라 대시보드:** Node Exporter의 호스트 지표(CPU, 메모리, 디스크)와 파이프라인 대기 시간을 결합하여 분석합니다. 인프라 포화도와 작업 지연의 상관관계를 파악하여 러너 스케일링이나 인스턴스 업그레이드 등의 용량 계획 수립에 활용합니다. * **배포 빈도 대시보드:** 환경별 배포 횟수와 소요 시간을 추적하여 DORA 지표를 관리합니다. 엔지니어링 리더십은 이를 통해 릴리스 속도와 메인 브랜치 대비 커밋 지연 상태(Environment Drift)를 점검할 수 있습니다. ### 옵저버빌리티 구현을 위한 핵심 기술 스택 GitLab의 원시 데이터를 수집하고 시각화하기 위해 두 가지 주요 익스포터와 컨테이너 기반 인프라를 사용합니다. * **GitLab CI Pipelines Exporter:** GitLab API를 통해 파이프라인 소요 시간, 작업 상태, 배포 정보 등 CI/CD 관련 핵심 메트릭을 수집합니다. * **Node Exporter:** 러너가 실행되는 호스트의 하드웨어 및 OS 지표를 수집하여 인프라 수준의 통찰을 제공합니다. * **Grafana 파일 기반 프로비저닝:** 모든 대시보드를 코드로 관리하고 자동으로 배포하여 여러 환경에서 일관된 모니터링 환경을 유지합니다. 프로젝트나 브랜치별 필터링을 위한 변수 설정이 가능합니다. ### 엔터프라이즈급 Kubernetes 배포 아키텍처 대규모 환경에서는 확장성과 보안을 위해 Kubernetes 클러스터에 각 컴포넌트를 분리된 Deployment로 배포하는 것이 권장됩니다. * **네임스페이스 및 보안 관리:** `gitlab-observability`와 같은 전용 네임스페이스를 생성하고, GitLab API 접근을 위한 Personal Access Token(`read_api` 권한)을 Kubernetes Secret으로 안전하게 관리합니다. * **익스포터 배포:** `gitlab-ci-pipelines-exporter`를 Deployment로 구성하고, ConfigMap을 통해 수집 대상 프로젝트 및 설정을 주입합니다. * **데몬셋 활용:** `Node Exporter`는 DaemonSet으로 배포하여 클러스터 내 모든 노드의 메트릭을 빠짐없이 수집합니다. * **Prometheus 통합:** 수집된 모든 메트릭은 Prometheus로 집계되며, 이를 Grafana의 데이터 소스로 연결하여 시각화 체계를 완성합니다. 대규모 CI/CD 환경을 운영하는 조직이라면 단순한 로그 확인을 넘어, 이와 같은 통합 옵저버빌리티 스택을 구축할 것을 권장합니다. 특히 인프라 비용 최적화와 개발 생산성 향상을 목표로 한다면, DORA 메트릭과 인프라 지표를 연계한 분석이 병목 현상 해결의 결정적인 열쇠가 될 것입니다. 중간 규모 이하의 환경이나 PoC 단계에서는 Docker Compose를 통해 빠르게 프로토타입을 구축해본 후 Kubernetes로 확장하는 전략이 효과적입니다.

gitlab쿠버네티스옵저버빌리티CI/CD+4