GitLab

135 개의 포스트

about.gitlab.com/blog

태그로 필터

gitlab4분 읽기큐레이션 요약

몇 분 만에 코드베이스 전체의 보안 스캐너 검사 완료

GitLab 19.0의 보안 구성 프로필은 프로젝트별 `.gitlab-ci.yml` 수정 없이 조직 전체에 보안 스캐너를 중앙에서 적용할 수 있게 한다. 이를 통해 SAST, 의존성 스캐닝, 비밀 탐지를 수백~수천 개 프로젝트에 몇 분 안에 배포하고, AI로 빨라진 개발 속도에 따른 보안 적용 누락을 줄일 수 있다. GitLab Ultimate 사용자는 보안 인벤토리에서 여러 프로젝트에 기본 프로필을 일괄 적용해 일관된 보안 검사 범위를 확보할 수 있다. ## 수동 스캐너 설정의 한계 - 프로젝트마다 `.gitlab-ci.yml`을 직접 수정하는 방식은 규모가 작을 때만 관리하기 쉽다. - 조직과 저장소가 늘어나면 다음과 같은 설정 드리프트가 발생한다. - 팀마다 서로 다른 SAST 규칙을 사용한다. - 새 프로젝트에는 의존성 스캐닝을 추가하지만 기존 프로젝트에는 적용하지 않는다. - 파이프라인 수정 과정에서 실수로 보안 스캐너 설정이 삭제된다. - 중앙 현황판이 없으면 어떤 프로젝트가 검사 중인지, 어떤 프로젝트가 누락됐는지 파악하기 어렵다. - AI를 활용한 코드 생성과 빠른 배포로 프로젝트·파이프라인 수가 증가하면서 보안 적용 범위의 격차가 더 커지고 있다. ## 보안 구성 프로필의 개념 - 보안 구성 프로필은 스캐너의 종류와 실행 조건을 중앙에서 정의하는 설정 묶음이다. - 그룹 수준에서 프로필을 한 번 설정한 뒤 여러 프로젝트에 일괄 적용할 수 있다. - 프로젝트별 YAML 파일에 SAST, 비밀 탐지, 의존성 스캐닝을 각각 추가할 필요가 없다. - GitLab은 권장 설정을 반영한 스캐너별 기본 프로필을 제공한다. - 따라서 YAML을 직접 작성하지 않고도 몇 분 안에 조직 전체의 스캐닝을 시작할 수 있다. ## 스캔 트리거와 보안 범위 기본 프로필은 스캐너별로 여러 실행 트리거를 활성화한다. - **머지 리퀘스트 파이프라인** - 열린 머지 리퀘스트 브랜치에 새 커밋이 푸시될 때 자동 실행된다. - 해당 머지 리퀘스트에서 새로 유입된 취약점에 초점을 맞춘 결과를 제공한다. - 기존 취약점으로 인한 불필요한 경고를 줄이고 개발자가 수정해야 할 문제를 명확히 한다. - **기본 브랜치 파이프라인** - 변경 사항이 기본 브랜치에 병합되거나 직접 푸시될 때 실행된다. - 보안 팀이 기본 브랜치의 전체적인 보안 상태를 지속적으로 확인할 수 있다. - **비밀 탐지의 푸시 보호** - 비밀 탐지는 위 두 트리거에 더해 푸시 보호를 제공한다. - 파이프라인 완료를 기다리지 않고 `git push` 과정에서 API 키나 토큰 등을 실시간으로 검사한다. - 비밀이 저장소에 들어가기 전에 푸시를 차단한다. - 이벤트 기반 기능이므로 보안 인벤토리에 일반적인 스캔 날짜가 표시되지 않는다. ## 실제 활용 사례 - **대규모 프로젝트의 검사 범위 표준화** - 보안 팀은 보안 인벤토리에서 모든 프로젝트의 스캐너 적용 여부와 실패 상태를 한눈에 확인할 수 있다. - 여러 프로젝트를 선택한 뒤 기본 프로필을 일괄 적용할 수 있다. - 개별 `.gitlab-ci.yml`을 수정하지 않고도 머지 리퀘스트와 기본 브랜치에서 SAST, 비밀 탐지, 의존성 스캐닝을 실행할 수 있다. - **코드 취약점의 조기 발견** - 개발자가 API 구현 중 안전하지 않은 역직렬화 패턴을 추가하면 SAST가 머지 리퀘스트 파이프라인에서 이를 탐지한다. - 코드가 승인·배포되기 전에 수정할 수 있어 사고 대응보다 훨씬 적은 비용으로 문제를 해결할 수 있다. - **감염된 의존성 차단** - 잠금 파일에서 의존성 버전을 업데이트하면 의존성 스캐닝이 변경된 패키지를 검사한다. - 악성 코드가 포함된 패키지 버전을 병합 전에 탐지해 빌드 서버나 운영 환경에 확산되는 것을 막는다. - **비밀 정보의 저장소 유입 방지** - 개발자가 디버깅 중 API 키를 커밋하려 하면 푸시 보호가 실시간으로 푸시를 차단한다. - 보안 티켓 생성이나 사후 자격 증명 교체가 필요해지기 전에 문제를 해결할 수 있다. ## 적용 방법과 상태 확인 - 보안 구성 프로필은 GitLab Ultimate의 GitLab.com, Self-Managed, Dedicated 환경에서 사용할 수 있다. - 적용 절차: 1. 그룹에서 **Secure > Security inventory**로 이동한다. 2. 적용할 프로젝트를 선택하거나 전체 프로젝트를 선택한다. 3. **Bulk Action > Manage security scanners**를 선택한다. 4. **Apply default profile to all**을 선택한다. - 적용 후 **Tool Coverage** 열에서 상태를 확인할 수 있다. - 녹색 막대: 스캐너가 완전히 활성화됨 - 부분 막대: 일부 트리거만 활성화됨 - 회색 막대: 아직 설정되지 않음 - 기존 `.gitlab-ci.yml` 설정과 프로필 기반 설정은 함께 사용할 수 있다. - 두 설정이 병존하는 전환 기간에는 보안 인벤토리의 상태 표시가 실제 결합 상태를 정확히 반영하지 않을 수 있으므로, 개별 프로젝트의 **Security Configuration** 페이지에서 프로필 상태를 확인하는 것이 권장된다. 조직 규모가 크거나 프로젝트 생성 속도가 빠르다면, 프로젝트별 YAML 관리보다 보안 구성 프로필을 기본값으로 적용하는 편이 효율적이다. 우선 보안 인벤토리에서 적용 누락 프로젝트를 확인한 뒤 기본 프로필을 일괄 적용하고, 이후 부분 적용·실패 상태를 정기적으로 점검하는 방식이 실용적이다.

원문 읽기(새 탭에서 열림)
gitlab4분 읽기큐레이션 요약

SBOM 기반 종속성 스캔으로 공급망 위험 줄이기

오늘날 소프트웨어 공급망에서는 직접 선언한 패키지만 확인하는 기존 방식으로는 취약점의 유입 경로와 실제 위험 범위를 파악하기 어렵다. GitLab 19.0의 SBOM 기반 의존성 스캐닝은 직접·간접 의존성을 모두 목록화하고, 취약 패키지가 어떤 경로로 포함됐는지와 애플리케이션에서 실제 사용되는지를 분석한다. 이를 통해 개발자는 병합 전에 문제를 수정하고, 보안팀은 실제 노출 가능성이 높은 취약점부터 대응할 수 있다. ## SBOM 기반 의존성 스캐닝의 동작 방식 - 프로젝트의 서드파티 라이브러리와 패키지를 분석해 CycloneDX 형식의 SBOM을 생성한다. - 생성된 구성 요소를 GitLab Advisory Database와 대조해 알려진 취약점을 탐지한다. - 결과는 다음 위치에 표시된다. - 취약점을 유발한 변경 사항이 포함된 머지 리퀘스트 - 취약점 대시보드 - 보안 보고서 - SBOM과 의존성 스캐닝 보고서는 기계 판독이 가능해 컴플라이언스 보고나 다른 공급망 보안 도구와 연계할 수 있다. ## 전이 의존성의 유입 경로 추적 - 직접 추가한 패키지뿐 아니라 여러 단계로 중첩된 전이 의존성까지 분석한다. - 예를 들어 `library-a → library-b → library-c` 구조에서 `library-c`에 취약점이 있으면, 해당 패키지가 어떤 의존성 체인을 통해 들어왔는지 보여준다. - 취약점이 발견된 패키지를 직접 수정할지, 상위 의존성을 업데이트할지 등 적절한 개입 지점을 판단할 수 있다. ## 실제 코드 사용 여부에 따른 우선순위 지정 - 매니페스트나 빌드 파일에 존재한다고 해서 모든 의존성이 애플리케이션에서 실행되는 것은 아니다. - Java, JavaScript/TypeScript, Python 프로젝트에서는 코드가 취약 패키지를 직접 `import` 또는 `require`하는지 확인한다. - 취약점별로 도달 가능성(reachability) 상태를 표시해 다음을 구분한다. - 애플리케이션 코드가 실제로 사용하는 취약 의존성 - 전이적으로 포함됐지만 코드에서 참조되지 않는 의존성 - 개발팀은 실제 노출 가능성이 높은 취약점에 우선 대응하고, 사용되지 않는 패키지의 문제는 상대적으로 낮은 우선순위로 관리할 수 있다. ## 지속적인 취약점 탐지 - 모든 머지 리퀘스트와 파이프라인 실행 시 의존성을 검사한다. - 새로운 보안 권고가 발표될 때도 분석기를 실행할 수 있다. - 개발이 중단된 프로젝트라도 운영 중이라면 새로운 취약점이 발생할 수 있으므로 지속적인 스캔이 중요하다. ## 지원되는 생태계와 파일 형식 - 이번 릴리스는 24개 이상의 패키지 생태계를 지원하며, 향후 지원 범위가 확대될 예정이다. - 패키지 관리자의 빌드 도구를 재현하기보다 lockfile과 의존성 그래프를 직접 분석하므로 새로운 언어와 파일 형식 지원을 추가하기 쉽다. - 지원되는 lockfile이나 의존성 그래프가 없으면 다음과 같은 매니페스트 파일을 분석한다. - `pom.xml` - `requirements.txt` - Gradle 빌드 파일 - 매니페스트 기반 분석은 직접 의존성만 확인하고 전이 의존성은 파악하지 못할 수 있어, 전체적인 분석 정확도와 범위는 lockfile 기반 방식보다 낮다. - 따라서 가능한 경우 lockfile을 사용하는 것이 권장된다. ## 중앙 집중식 보안 정책 적용 - 프로젝트마다 `.gitlab-ci.yml`을 직접 수정하면 설정 누락, 구성 불일치, 감사 과정의 사각지대가 발생할 수 있다. - GitLab 19.0에서는 보안 구성 프로필을 사용해 의존성 스캐닝을 한 번 설정하고 여러 프로젝트에 적용할 수 있다. - 스캔 실행 정책과 파이프라인 실행 정책을 이용하면 그룹 또는 인스턴스 수준에서 보안 기준을 강제할 수 있다. - 수백 개의 프로젝트에도 각 저장소의 CI 설정을 개별적으로 수정하지 않고 동일한 의존성 검사 정책을 적용할 수 있다. ## 도입 대상과 마이그레이션 - SBOM 기반 의존성 스캐닝은 GitLab Ultimate 고객에게 제공된다. - GitLab.com에서 사용할 수 있으며, GitLab Dedicated와 self-managed 환경에는 표준 릴리스 일정에 따라 제공된다. - 기존 Gemnasium 분석기에서 이전할 때는 전환 기간 동안 두 분석기를 동시에 실행해 결과를 비교할 수 있다. - 신규 도입 팀은 GitLab의 설정 튜토리얼과 기술 문서를 통해 지원 언어, 구성 방식, 고급 옵션을 확인할 수 있다. 실무적으로는 먼저 lockfile을 저장소에 포함하고, SBOM 스캔을 머지 리퀘스트와 정기 파이프라인에 연결하는 것이 좋다. 이후 도달 가능성 정보를 기준으로 실제 코드가 사용하는 취약점부터 우선 처리하고, 조직 전체에는 그룹 또는 인스턴스 수준의 실행 정책으로 스캔을 강제하는 방식이 효과적이다.

원문 읽기(새 탭에서 열림)
gitlab4분 읽기큐레이션 요약

MR을 수동 작업에서 자동화된 워크플로로 전환하기

GitLab 19.0은 AI를 코드 작성 단계에만 사용하는 것을 넘어, 머지 리퀘스트(MR) 생성부터 리뷰 대응·충돌 해결·리베이스·병합까지 전체 lifecycle을 자동화합니다. Developer Flow가 단일 AI 에이전트로 확장되어 반복 작업을 대신 수행하고, 개발자는 방향 설정과 검토에 집중할 수 있습니다. 이를 통해 MR 처리 과정의 수작업과 개발자의 대기 시간을 줄이는 것이 핵심입니다. ## MR 전체를 담당하는 Developer Flow - 기존 Developer Flow는 이슈를 기반으로 MR을 생성하는 데 초점을 맞췄습니다. - GitLab 19.0에서는 생성 이후의 작업까지 같은 MR 안에서 이어서 처리합니다. - 다음과 같은 방식으로 실행할 수 있습니다. - 이슈의 **Generate MR** 버튼 사용 - 이슈나 MR에 **Duo Developer 서비스 계정** 할당 - 이슈 또는 MR의 댓글에서 새로운 `@mention` 트리거 호출 - 에이전트는 별도의 새 MR을 만드는 대신 기존 MR을 계속 수정하며 작업합니다. - 다음 작업을 자동으로 수행할 수 있습니다. - 여러 차례에 걸친 리뷰 피드백 반영 - 장기간 유지된 브랜치의 병합 충돌 해결 - 익숙하지 않은 코드베이스 조사 - 구현 방식 평가 및 결과 보고 - 지나치게 커진 MR 분할 - 새로운 기능의 처음부터 끝까지 구현 ## 단일 에이전트와 개발 환경 구성 - Developer Flow는 `read`, `grep`, `edit`, 명령 실행 등 전체 개발 도구를 사용할 수 있는 단일 에이전트 루프로 재구축되었습니다. - 에이전트가 작업 단계마다 어떤 도구를 사용할지 직접 판단하므로, 특정 순간의 코드 생성이 아니라 MR 전체에 참여할 수 있습니다. - `AGENTS.md`를 읽어 다음과 같은 프로젝트별 정보를 반영합니다. - 잘 알려지지 않은 Bash 명령 - 코딩 규칙과 프로젝트 관례 - 환경별 주의사항 - 아키텍처 결정 사항 - `agent-config.yml`은 에이전트가 실제로 작업을 완료할 수 있도록 개발 환경을 준비합니다. - 필요한 의존성 설치 - 도구 및 설정 구성 - 테스트 실행 - pre-commit hook 실행 - 이를 통해 에이전트가 프로젝트 표준에 맞지 않는 코드를 작성해 후속 재작업을 만드는 문제를 줄입니다. ## AI를 활용한 병합 충돌 해결 - MR의 충돌 화면과 merge checks 위젯에 베타 기능인 **Resolve with Duo** 버튼이 추가되었습니다. - 에이전트는 다음 과정을 수행합니다. - MR의 의도 파악 - 양쪽 브랜치의 변경 내용 분석 - 적절한 해결 전략 선택 - 충돌 파일 수정 - 수정 사항 커밋 및 푸시 - 작업 후에는 발견한 충돌과 해결 방식을 MR 댓글로 요약합니다. - 해결이 안전하지 않다고 판단하면 임의로 수정하지 않고, 처리가 어렵다는 사실을 알립니다. - 특히 여러 릴리스 브랜치에 백포트하거나 연쇄적으로 MR을 관리하는 팀에서 반복적인 충돌 해결 비용을 줄일 수 있습니다. ## 한 번의 클릭으로 리베이스와 병합 - GitLab 19.0에는 베타 기능인 **One-click rebase and merge**가 추가되었습니다. - semi-linear history나 fast-forward 방식에서는 기존에 리베이스 후 결과를 기다렸다가 다시 병합해야 했습니다. - 이제 리베이스와 병합을 한 번의 작업으로 처리할 수 있습니다. - 이 기능은 Free, Premium, Ultimate 모든 요금제에서 제공됩니다. ## 개발자 역할의 변화 - AI 에이전트는 코드 작성, 리뷰 피드백 반영, 충돌 해결처럼 판단이 필요한 작업을 수행합니다. - 리베이스와 같은 반복적인 절차는 자동화 기능이 처리합니다. - 개발자는 작업 실행 과정에 직접 매달리기보다 방향을 제시하고 결과를 검토하며 최종 결정을 내리는 역할에 집중할 수 있습니다. - GitLab은 이를 개발자가 “루프 위에 머무는” 방식이라고 설명합니다. ## 사용 조건과 적용 방법 - 새로운 Developer Flow 기능은 GitLab Duo Agent Platform의 Premium 및 Ultimate에서 사용할 수 있습니다. - 기존 고객은 Duo Agent Platform 무료 평가판으로 체험할 수 있습니다. - GitLab 19.0 이전 버전에서는 `@mention` 워크플로를 사용하기 위해 트리거를 수동 설정해야 할 수 있습니다. - Free 사용자는 별도 절차를 통해 GitLab Duo Agent Platform을 신청할 수 있습니다. 실무에서는 `AGENTS.md`에 프로젝트 규칙과 테스트 방법을 명확히 기록하고, `agent-config.yml`로 재현 가능한 개발 환경을 제공하는 것이 중요합니다. 자동화 결과를 그대로 병합하기보다는 에이전트가 남긴 변경 내용과 충돌 해결 근거를 리뷰하는 방식으로 도입하는 것이 안전합니다.

원문 읽기(새 탭에서 열림)
gitlab3분 읽기큐레이션 요약

GitLab Duo Agent Platform Self-Hosted를 위한 더 많은 AI 모델

GitLab 19.0은 GitLab Duo Agent Platform Self-Hosted에서 사용할 수 있는 오픈소스 AI 모델을 확대해, 에어갭·규제 환경에서도 더 강력한 에이전트 기능을 제공한다. 기업은 데이터와 소스 코드를 외부 API로 전송하지 않고도 작업 유형과 인프라에 맞는 모델을 선택할 수 있으며, 필요하면 GitLab 관리형 모델과 자체 호스팅 모델을 혼합할 수도 있다. ## 규제·에어갭 환경의 AI 제약 - 데이터 레지던시, 네트워크 격리, 규제 준수 때문에 소스 코드를 외부 클라우드 API로 보낼 수 없는 조직이 대상이다. - 완전한 에어갭 환경에서는 인터넷과 외부 API를 사용할 수 없으므로, 자체 인프라에서 실행하는 오픈소스 모델이 사실상 유일한 선택지다. - 기존에는 이런 환경이 최신 AI 기능 도입에서 뒤처지거나, 모든 작업에 하나의 모델만 사용해야 하는 문제가 있었다. ## GitLab 19.0의 오픈소스 모델 확대 GitLab은 Duo Agent Platform의 실제 에이전트 작업에 필요한 다음 기준을 바탕으로 모델을 평가했다. - 여러 단계의 도구 호출 및 작업 수행 - 지시사항 준수 - 코드 생성 품질 - 대규모 diff와 여러 파일로 구성된 코드베이스에 대한 추론 새롭게 지원되는 모델은 다음과 같다. - Mistral Devstral 2 123B - GLM-5.1 - Kimi-K2.6 - MiniMax-M2.7 이를 통해 단순 작업에는 효율적인 모델을, 복잡한 에이전트 작업에는 더 강력한 모델을 선택하는 방식의 운영이 가능해진다. ## 온프레미스 및 가상 인프라 배포 - 권장 방식은 자체 하드웨어에서 vLLM을 사용해 모델을 제공하는 것이다. - 모든 추론이 조직 내부에서 실행되므로 소스 코드와 데이터가 외부로 나가지 않는다. - 전용 GPU를 직접 구매하기 어려운 팀은 GPU가 연결된 프라이빗 클라우드의 가상 머신에서 모델을 실행할 수 있다. - 이 방식은 필요할 때만 GPU 용량을 확보하면서도 데이터 격리 정책을 유지할 수 있다. ## 배포 환경별 모델 선택 - **완전한 에어갭 환경** - 자체 추론 하드웨어에 오픈소스 모델을 배포해야 한다. - 모델별 GPU·하드웨어 요구사항을 사전에 확인해야 한다. - **하이브리드 환경** - 기능별로 자체 호스팅 모델과 GitLab 관리형 모델을 혼합할 수 있다. - AI Gateway 설정을 통해 어떤 기능이 어떤 모델을 사용할지 구성한다. - **온라인 라이선스 환경** - 사용량 기반 모델을 이용할 수 있다. - 자체 호스팅 모델과 GitLab 관리형 모델을 함께 사용하는 구성이 가능하다. ## 이용 조건 - 오프라인 라이선스 고객은 GitLab Duo Agent Platform Self-Hosted 애드온이 필요하다. - 온라인 라이선스 고객은 사용량 기반 모델을 사용할 수 있으며, 자체 호스팅·GitLab 관리형 모델의 하이브리드 구성이 가능하다. ## 실용적인 권장 사항 완전한 네트워크 격리와 데이터 보안이 중요하다면 vLLM 기반의 자체 GPU 인프라에 지원 모델을 배포하는 것이 적합하다. 반면 작업별 성능과 운영 비용을 균형 있게 관리하려면, 민감한 코드는 자체 호스팅 모델로 처리하고 일반 작업이나 고난도 작업은 GitLab 관리형 모델로 분리하는 하이브리드 구성을 검토할 수 있다.

원문 읽기(새 탭에서 열림)
gitlab3분 읽기큐레이션 요약

GitLab Secrets Manager로 CI/CD 자격 증명 관리

GitLab Secrets Manager는 CI/CD 자격 증명을 GitLab 내부에서 안전하게 관리하도록 지원하는 기능으로, GitLab 19.0에서 공개 베타로 제공됩니다. 비밀 값을 프로젝트·그룹 구조와 파이프라인의 브랜치·환경 조건에 따라 최소 범위로 제공해 유출 시 피해를 줄이고, 생성·변경·사용 이력을 감사 로그로 추적할 수 있다는 것이 핵심입니다. 기존 외부 보안 저장소와 달리 별도의 권한 체계와 운영 시스템을 추가로 관리하지 않아도 됩니다. ## CI/CD 변수와 외부 보안 저장소의 한계 - 개발자는 자격 증명을 `.env`, 설정 파일 또는 CI/CD 변수에 임시로 저장하기 쉽습니다. - 프로젝트나 그룹 수준의 CI/CD 변수는 값을 마스킹할 수 있지만, 기본적으로 여러 작업에 주입되어 최소 권한 원칙을 위반할 수 있습니다. - 파이프라인 접근 권한이 있는 사용자가 변수 값을 읽을 가능성도 있습니다. - 별도 Vault를 사용하면 비밀을 CI/CD 설정에서 분리할 수 있지만 다음과 같은 운영 부담이 생깁니다. - 별도 인증 방식 관리 - GitLab과 다른 권한 모델 유지 - 여러 시스템의 감사 로그 상관관계 분석 - 조직·역할 변경 시 권한 동기화 ## GitLab Secrets Manager의 사용 방식 - Secrets Manager는 OpenBao를 기반으로 GitLab에 통합된 네이티브 기능입니다. - `.gitlab-ci.yml`의 `secrets:` 키워드로 작업에 필요한 비밀을 선언합니다. ```yaml deploy: secrets: DATABASE_PASSWORD: gitlab_secrets_manager: name: db-password script: - deploy --password $DATABASE_PASSWORD ``` - 기본적으로 비밀 값은 임시 파일에 기록되고, 해당 파일 경로가 작업 범위의 환경 변수로 전달됩니다. - 값 자체보다 파일 경로를 전달하면 하위 프로세스, 크래시 덤프, 텔레메트리 등에 비밀이 노출될 가능성을 줄일 수 있습니다. ## 기존 GitLab 권한 모델 활용 - 그룹과 프로젝트 구조가 비밀의 격리 경계로 사용됩니다. - 사용자·그룹·역할별로 읽기, 생성, 수정, 삭제 권한을 설정할 수 있습니다. - 그룹 수준에서 만든 비밀은 하위 프로젝트들이 상속받아 공통 자격 증명을 한 번만 정의할 수 있습니다. - 사용자가 프로젝트에서 제거되면 해당 프로젝트의 비밀 접근 권한도 즉시 사라집니다. - 별도 보안 시스템에서 GitLab의 조직 구조와 권한을 다시 구성하고 동기화할 필요가 없습니다. ## 브랜치와 환경별 최소 권한 범위 - 각 비밀은 해당 비밀이 필요한 작업에만 제공됩니다. - 접근 여부는 다음 작업 속성으로 결정됩니다. - 대상 환경 - 실행 브랜치 - 브랜치 보호 여부 - 환경과 브랜치에는 와일드카드를 사용할 수 있습니다. 예를 들어 `production/*`과 같은 규칙을 지정할 수 있습니다. - 보호된 브랜치에서 `production/*` 환경으로 실행되는 작업에만 비밀을 제공하도록 조건을 조합할 수 있습니다. - 작업 실행 시 백엔드가 작업의 신원, 브랜치, 환경을 검증한 뒤 비밀을 반환합니다. - 작업 종료 후 비밀은 러너에 남지 않으며, 로그에서는 값이 마스킹됩니다. - 자격 증명이 유출되어도 접근 가능한 시스템 범위가 좁아져 회전, 조사, 복구에 필요한 작업이 줄어듭니다. ## 파이프라인과 연결된 감사 추적 - 프로젝트·그룹 비밀의 생성, 수정, 삭제 이벤트가 GitLab의 기존 감사 로그에 기록됩니다. - CI/CD 파이프라인에서 비밀을 읽은 이벤트에는 원본 파이프라인 ID와 작업 ID가 포함됩니다. - 따라서 별도 CI 시스템, 보안 저장소, ID 제공자의 로그를 수동으로 조합하지 않고도 비밀 사용 경로를 추적할 수 있습니다. - 감사 로깅은 현재 self-managed 배포에서 제공되며, GitLab.com 지원은 공개 베타 기간 중 추가될 예정입니다. ## 공개 베타와 기존 도구와의 연계 - GitLab.com 및 self-managed 환경의 Premium·Ultimate 사용자가 공개 베타에 참여할 수 있습니다. - GitLab Dedicated 지원은 추후 제공될 예정입니다. - 베타 기간에는 무료이며, 정식 출시 후에는 GitLab Credits를 통해 유료 제공됩니다. - HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, Google Cloud Secret Manager 통합도 계속 사용할 수 있어 기존 시스템에서 단계적으로 전환할 수 있습니다. 실무적으로는 광범위한 CI/CD 변수를 먼저 점검하고, 배포 환경·브랜치별로 필요한 비밀을 Secrets Manager로 이전하는 것이 좋습니다. 특히 운영 자격 증명은 보호된 브랜치와 특정 `production/*` 환경에만 연결해 유출 시 피해 범위를 제한하는 방식을 권장합니다.

원문 읽기(새 탭에서 열림)
gitlab4분 읽기큐레이션 요약

GitLab 19.0 | GitLab 문서

GitLab 19.0은 그룹 단위 AI 코드 리뷰 지침, 사용자 정의 작업 항목, Secrets Manager 오픈 베타 등 협업·보안 기능을 확장한 릴리스입니다. 또한 GitLab Duo를 에이전트 중심으로 강화하고, SBOM 기반 의존성 스캔을 정식 제공하며, 사용량 기반 과금과 새로운 모델·트리거를 도입했습니다. 이번 릴리스는 여러 프로젝트를 아우르는 표준화와 에이전트 기반 개발 자동화에 초점을 둡니다. ## 그룹 단위 GitLab Duo 코드 리뷰 지침 - 기존에는 프로젝트별로만 `.gitlab/duo/mr-review-instructions.yaml`을 설정할 수 있었습니다. - 이제 그룹과 하위 그룹 전체에 공통 리뷰 지침을 적용할 수 있습니다. - 그룹 내 특정 프로젝트를 템플릿으로 지정하면, GitLab Duo가 그룹 지침과 개별 프로젝트 지침을 결합해 코드 리뷰를 수행합니다. - Code Review Flow와 GitLab Duo Code Review 모두 지원합니다. - Premium·Ultimate 등급에서 GitLab.com, Self-Managed, Dedicated 환경에 제공됩니다. ## 사용자 정의 작업 항목 유형 - 프로젝트에서 `Issue`, `Task` 외에 `User Story`, `Bug`, `Maintenance` 같은 작업 항목 유형을 직접 생성하거나 이름을 변경할 수 있습니다. - 각 유형은 고유한 이름과 아이콘을 가지며, 사용자 정의 필드와 상태 라이프사이클을 지원합니다. - 저장된 보기와 이슈 보드에서도 유형을 기준으로 작업을 관리할 수 있습니다. - 최상위 그룹 또는 조직에서 설정한 유형 구성이 하위 프로젝트로 전파됩니다. - 프로젝트별로 특정 유형을 활성화하거나 비활성화할 수 있으며, 유형을 비활성화해도 기존 작업 항목에는 영향을 주지 않습니다. ## GitLab Secrets Manager 오픈 베타 - 기존 폐쇄형 베타에서 Premium·Ultimate 고객 대상 오픈 베타로 확대되었습니다. - GitLab.com과 GitLab Self-Managed에서 사용할 수 있습니다. - 프로젝트 및 그룹 Owner가 CI/CD 시크릿을 GitLab에 저장·조회·참조할 수 있습니다. - 시크릿은 프로젝트 또는 그룹 범위로 제한되며, 명시적으로 요청한 파이프라인 작업만 접근할 수 있습니다. - 아직 베타 지원 정책이 적용되므로 운영 환경에 사용하기 전 안정성과 제한 사항을 검토해야 합니다. ## GitLab Duo Developer의 MR 자동화 - 이슈 할당, `Generate MR` 선택, 이슈·MR 토론에서의 `@mention` 등 여러 방식으로 Developer를 실행할 수 있습니다. - 피드백, To-do, 디자인 관련 질문을 코드 변경, 후속 MR, 조사 요약으로 전환할 수 있습니다. - `AGENTS.md`와 `agent-config.yml`을 설정하면 커밋 전에 테스트와 검사를 실행하도록 구성할 수 있습니다. - 최상위 그룹 또는 인스턴스 관리자가 Developer Flow를 활성화하면 대상 프로젝트에 멘션 및 할당 트리거가 자동으로 추가됩니다. ## SBOM 기반 의존성 스캔 정식 제공 - Maven, Gradle, Python 프로젝트에서 직접 선언한 의존성뿐 아니라 전이 의존성까지 분석합니다. - lockfile이나 해석된 의존성 그래프가 없으면 Maven·Gradle·Python 도구를 자동 실행해 전체 그래프를 생성합니다. - v2 Dependency Scanning 템플릿을 포함하는 것 외에 별도 설정이 거의 필요하지 않습니다. - 의존성 해석이 불가능한 경우 `pom.xml`, `requirements.txt`, `build.gradle`, `build.gradle.kts`를 분석하는 매니페스트 스캔으로 대체됩니다. - 매니페스트 스캔은 직접 의존성만 제공하므로, 전이 의존성까지 확인하려면 lockfile·그래프 파일 또는 의존성 해석 기능이 필요합니다. - Ultimate 등급 기능입니다. ## GitLab Duo Core의 사용량 기반 과금 - GitLab Duo Core가 19.0부터 사용량 기반 과금으로 변경됩니다. - Web IDE와 데스크톱 IDE의 Code Suggestions 사용량이 GitLab Credits를 소비합니다. - Duo Chat은 GitLab Duo Agent Platform 기반의 에이전트 방식으로 변경됩니다. - GitLab UI나 데스크톱 IDE에서 Chat을 사용하려면 인스턴스 또는 최상위 그룹에서 Agent Platform을 활성화해야 합니다. ## 코드 검색과 MR 자동화 트리거 - 정확한 코드 검색 결과를 `repo:` 구문으로 특정 저장소에 한정할 수 있습니다. - 예를 들어 `def authenticate repo:my-group/my-project`처럼 검색하면 지정한 저장소의 결과만 확인할 수 있습니다. - 부분 경로나 패턴을 사용해 여러 저장소를 한 번에 검색할 수도 있습니다. - Draft MR이 리뷰 준비 상태로 전환될 때 Flow나 외부 에이전트를 실행하는 `Merge request ready` 이벤트 트리거가 추가되었습니다. - 프로젝트의 `AI > Triggers`에서 설정하며, `merge_request_ready_flow_trigger` 기능 플래그 뒤에 있고 기본값은 비활성화입니다. ## GitLab Duo Agent Platform의 모델 확장 - Claude Opus 4.7을 Agent Platform에서 사용할 수 있습니다. - 복잡한 다단계 작업, 지시 준수, 결과 검증이 필요한 CI/CD, 코드 리뷰, 취약점 수정 플로우에 적합하도록 개선되었습니다. - GitLab Self-Managed용 Duo Agent Platform은 자체 호스팅 Gemini 모델도 지원하기 시작했습니다. - 제공된 글 내용은 Gemini 지원이 여러 플로우를 지원한다는 설명 중간에서 끝나므로, 세부 지원 범위는 공식 문서를 확인해야 합니다. ## 릴리스의 방향 - 여러 프로젝트에 공통 AI 리뷰 정책과 작업 유형을 적용해 그룹 단위 표준화를 강화했습니다. - 에이전트가 이슈와 MR에서 직접 코드를 수정하고 검증하는 개발 흐름을 확대했습니다. - SBOM 및 전이 의존성 분석으로 공급망 보안 가시성을 높였습니다. - Duo 사용량 기반 과금과 Secrets Manager 베타 도입에 따라 비용 및 운영 정책 검토가 중요해졌습니다. 도입 시에는 그룹 공통 리뷰 지침과 작업 유형을 먼저 표준화하고, SBOM 스캔에서 전이 의존성 해석이 실제로 활성화되었는지 확인하는 것이 좋습니다. Secrets Manager와 새로운 Agent Platform 기능은 베타·기능 플래그 상태와 과금 영향을 검증한 뒤 점진적으로 적용하는 것을 권장합니다.

원문 읽기(새 탭에서 열림)
gitlab3분 읽기큐레이션 요약

조직 전체의 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 환경에서는 구버전 사용 프로젝트를 대상으로 보안 패치와 업그레이드를 직접 추진하는 것이 좋다.

원문 읽기(새 탭에서 열림)
gitlab3분 읽기큐레이션 요약

BYOK를 넘어: AI 에이전트에 거버넌스가 중요한 이유

BYOK와 로컬 모델 실행은 AI 모델 선택권을 넓히지만, 기업 환경에서 필요한 거버넌스까지 해결하지는 못한다. AI 에이전트가 CI/CD 파이프라인에서 빌드를 실행하고 설정을 변경하며 배포까지 수행하려면 접근 권한, 승인 절차, 감사 기록, 보안 통제가 플랫폼 차원에서 보장되어야 한다. 글은 GitLab Duo CLI와 Duo Agent Platform이 이러한 통제를 대화형 환경뿐 아니라 비대화형 CI/CD 실행에도 적용한다고 설명한다. ## BYOK와 로컬 모델의 한계 - GitHub Copilot CLI의 BYOK 기능은 개발자가 원하는 모델 제공자를 사용하거나 모델을 로컬에서 오프라인으로 실행할 수 있게 한다. - 이는 데이터 주권과 모델 선택 측면에서 유용하지만, 조직 전체에 어떤 모델을 강제할지 결정하거나 에이전트의 행동을 감사하는 기능과는 별개다. - 개인 개발자의 터미널 사용을 넘어, 여러 프로젝트와 릴리스 주기에서 AI가 자동화 작업을 수행하려면 추가적인 통제가 필요하다. ## 대화형 AI와 자동화된 에이전트의 차이 - 대화형 코딩 도구는 개발자가 매 단계에서 결과를 검토하고 승인하는 것을 전제로 한다. - 반면 자동화된 AI 에이전트는 사람의 확인 없이 테스트 실행, 설정 변경, 보안 검증, 배포 같은 여러 단계를 수행할 수 있다. - 따라서 중요한 질문은 다음과 같이 바뀐다. - 에이전트가 어떤 데이터와 시스템에 접근할 수 있는가? - 어떤 작업을 수행하도록 허가되었는가? - 실제로 어떤 행동을 했고, 그 이유를 입증할 수 있는가? - 특히 CI/CD 안에서는 개발자가 프롬프트 인젝션이나 비정상적인 모델 행동을 실시간으로 감지할 수 없으므로, 보안 통제가 플랫폼에 내장되어야 한다. ## GitLab Duo CLI의 거버넌스 방식 - GitLab Duo CLI는 개발자 터미널뿐 아니라 보안, 검증, 컴플라이언스, 배포 자동화까지 지원하도록 설계되었다. - 헤드리스 모드를 제공해 대화형 승인 없이 스크립트와 CI/CD 파이프라인에서 실행할 수 있다. - 대화형 모드에서는 사람이 승인하기 전까지 작업을 실행하지 않는 human-in-the-loop 방식을 적용한다. - GitLab Duo Agent Platform에 프롬프트 인젝션 탐지가 포함되어 악의적인 입력이 에이전트의 동작을 바꾸는 위험을 줄인다. - 복합 ID(composite identity)로 에이전트의 접근 범위를 명시적으로 허가된 리소스로 제한하고, AI가 수행한 작업을 감사 가능하게 만든다. - `AGENTS.md`와 `SKILL.md` 같은 사용자 정의 지침 파일을 통해 에이전트가 수행할 수 있는 작업과 금지된 행동을 팀 차원에서 정의할 수 있다. ## CI/CD 파이프라인 자동화의 핵심 과제 - 활용 사례로는 스프린트 종료 시 고장 난 파이프라인을 분석하거나, 여러 단계로 구성된 개발 작업을 자동 처리하는 것이 제시된다. - 그러나 파이프라인 내부에는 매번 결과를 검토할 개발자가 없기 때문에 개인별 설정만으로는 충분하지 않다. - 모든 프로젝트와 환경에서 동일하게 적용되는 권한 제어, 실행 기록, 프롬프트 인젝션 방어가 필요하다. - 모델이 예상과 다르게 행동했을 때 원인을 추적하고 책임을 확인할 수 있는 감사 로그도 중요하다. ## 모델 유연성과 데이터 주권 - 기업은 모델 선택권과 오프라인 실행 기능을 통해 민감한 데이터를 직접 관리하는 인프라에 둘 수 있다. - GitLab Duo CLI는 자체 호스팅 모델과 GitLab 호스팅 모델을 함께 사용할 수 있도록 지원한다. - 민감도가 높은 작업은 자체 인프라에서 처리하고, 일반 작업은 호스팅 모델을 사용하는 방식으로 유연성과 통제력을 조정할 수 있다. - 다만 글은 모델 선택보다 그 위에 있는 거버넌스 구조가 실제 프로덕션 도입 가능성을 결정한다고 강조한다. ## 실용적인 판단 기준 AI 에이전트를 CI/CD에 도입할 때는 지원 모델이나 BYOK 여부만 확인하지 말고, 비대화형 실행에서도 권한 제한, 승인 정책, 프롬프트 인젝션 방어, 감사 추적이 일관되게 작동하는지 검증해야 한다. 특히 사람이 지켜보지 않는 환경에서도 동일한 보안 모델이 유지되는지가 핵심 평가 기준이다.

원문 읽기(새 탭에서 열림)
gitlab4분 읽기큐레이션 요약

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 승인을 동시에 요구하는 조직에 유용합니다.

원문 읽기(새 탭에서 열림)
gitlab4분 읽기큐레이션 요약

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, 보안 스캔, 사람의 리뷰를 거친 뒤 배포해야 한다.

원문 읽기(새 탭에서 열림)
gitlab3분 읽기큐레이션 요약

정책으로 오해를 불러일으키는 취약점 심각도를 수정하는 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 상향 정책은 머지 승인 정책과 연계해 보고서 분류뿐 아니라 배포 통제까지 자동화하는 것이 좋다.

원문 읽기(새 탭에서 열림)
gitlab4분 읽기큐레이션 요약

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 토큰, 파일 업로드 기능을 사용하는 환경은 패치 전까지 접근 통제를 강화해야 합니다.

원문 읽기(새 탭에서 열림)
gitlab4분 읽기큐레이션 요약

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을 도입하면 개발 속도를 크게 떨어뜨리지 않으면서 보안 부채를 줄일 수 있다.

원문 읽기(새 탭에서 열림)
gitlab5분 읽기큐레이션 요약

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·데이터 모델·거버넌스를 함께 바꾸는 전사적 전환이다. 기업 고객 입장에서는 에이전트의 생산성보다도 권한 통제, 감사 가능성, 컨텍스트 연결, 안정적인 배포를 지원하는지가 도입 판단의 핵심이 될 것으로 보인다.

원문 읽기(새 탭에서 열림)
gitlab3분 읽기큐레이션 요약

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 지원 여부를 확인한 뒤 도입을 결정하는 것이 좋습니다.

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