techlist.io
KREN

CI/CD

102 개의 포스트

gitlab3분 읽기큐레이션 요약

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 구성을 점검한 후 단계적으로 배포할 수 있다.

원문 읽기(새 탭에서 열림)
CI/CDAI 에이전트모델 컨텍스트 프로토콜DevSecOps+2
gitlab3분 읽기큐레이션 요약

버전 업으로 빌드가 깨졌을 때 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처럼 기한이 명확한 환경에서는 고위험 취약점과 전이적 의존성을 우선 대상으로 삼는 것이 효과적이다.

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

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

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 오류 복구, 코드 리뷰처럼 단계가 명확한 업무부터 도입하고, 크레딧 사용량과 승인 지점을 확인한 뒤 적용 범위를 넓히는 방식이 실용적입니다.

원문 읽기(새 탭에서 열림)
CI/CDAI 에이전트gitlab-duo-agent-platformagentic-workflows+3
gitlab4분 읽기큐레이션 요약

그린 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/CD쿠버네티스gitlabDevOps+4
line4분 읽기큐레이션 요약

AI 에이전트끼리 토론한다면? 멀티 에이전트 협업으로 재설계하는 개발 프로세스

AI 코딩의 병목은 코드 생성 속도가 아니라 의도 정의, 가정 검증, 구현 확인, 리뷰 준비를 사람이 직접 조율하는 데 있다. LY Corporation은 이를 해결하기 위해 제안자와 도전자 AI 팀이 스펙·빌드·전달의 세 단계에서 토론하고, 조율자가 수정·상위 보고·진행 여부를 결정하는 파이프라인을 설계했다. 목표는 사람의 판단을 없애는 것이 아니라, 사람이 검토하기 전에 AI가 자신의 작업을 근거와 함께 입증하도록 만드는 것이다. ## 사람이 조율하는 AI 보조 방식의 한계 - 기존 방식에서는 AI가 스펙 작성, 코드 생성, 테스트, PR 설명 등을 빠르게 수행한다. - 그러나 각 단계 사이에서 사람이 다음 작업을 요청하고, 실패 결과를 전달하고, diff와 PR을 검토해야 한다. - 따라서 개별 작업은 빨라져도 의도·구현·검증·리뷰·전달 사이의 조율 비용은 그대로 남는다. - 진정한 생산성 향상은 각 단계를 단순히 가속하는 것이 아니라, 수동 인수인계를 프로세스에서 제거하는 데 있다. ## 제안자와 도전자로 나뉜 AI 협업 - 제안자는 산출물을 작성하고 단계가 진행될수록 이를 발전시킨다. - 도전자는 제안자의 결과를 검증하며, 단계별로 서로 다른 관점에서 문제를 제기한다. - 스펙 단계: 소크라테스식 질문으로 모호성·누락을 찾는다. - 빌드 단계: 테스트와 실행 결과 등 근거를 바탕으로 반론한다. - 전달 단계: 구현과 PR이 최종 리뷰에 충분한지 점검한다. - 역할을 분리하면 하나의 AI가 스펙, 구현, 검증, 리뷰를 모두 낙관적으로 처리하는 문제를 줄일 수 있다. - 사람은 시작 시 의도를 정의하고, 결과를 승인하거나, 해결하기 어려운 문제가 상위 보고될 때 주로 개입한다. ## 스펙·빌드·전달 파이프라인 ### 스펙: 이후 작업의 계약 정의 - 스펙은 다음 내용을 포함한다. - 목표와 제약 조건 - 해석된 요구 사항 - 명시적 가정 - 미해결 질문 - 제안된 접근 방식 - 완료 정의 - 빌드 에이전트는 “합리적으로 보이는” 구현을 임의로 선택하지 않고, 승인된 스펙에서 테스트와 검증 계획을 도출한다. - 스펙이 부실하면 이후 구현과 리뷰의 기준도 불명확해지므로 전체 파이프라인이 약해진다. - 기존 API, 테스트, 의존성, 코딩 관습, Jira·Confluence·설계 문서 등을 조사해 질문과 가정을 구체화한다. ### 빌드: 테스트 우선 구현과 반론 - 제안자는 코드를 수정하기 전에 스펙을 다음 항목으로 변환한다. - 예상 동작 - 에지 케이스 - 추가·수정할 테스트 - 실행 명령 - 도전자는 구현 전이나 구현 중에 검증 설계 자체를 문제 삼을 수 있다. - 제안자가 도전자의 이의를 거부하려면 실행 경로, 컴파일·린트 출력, 실패 테스트 등 구체적인 증거를 제시해야 한다. - 단순히 테스트가 녹색이라는 사실만으로 검증 누락을 숨길 수 없도록 설계됐다. ### 전달: 리뷰 가능한 PR 패키지 - 최종 산출물은 코드뿐 아니라 리뷰어가 신뢰할 수 있는 PR 패키지다. - 패키지에는 다음 정보가 포함된다. - 무엇이 변경되었는가 - 어떤 파일과 영역을 먼저 봐야 하는가 - 어떤 검사와 테스트를 통과했는가 - 남은 위험과 불확실성은 무엇인가 - 도전자가 어떤 문제를 제기했고 어떻게 처리했는가 - 전달 단계의 조율자는 중재자라기보다 출시 가능성을 판단하는 심사위원 역할을 한다. ## 조율자와 구조화된 토론 프로토콜 - 조율자는 제안자와 도전자 사이에서 토론을 관리한다. - 주요 책임은 다음과 같다. - 논의가 주제에서 벗어나면 방향 수정 - 교착 상태 해소 - 산출물 수정 요청 - 안전하지 않은 불확실성의 상위 보고 - 다음 단계 진행 여부 결정 - 스펙과 빌드에서는 수렴을 이끄는 중재자 역할을 하고, 전달 단계에서는 근거가 충분한지 판정한다. - 각 에이전트는 제한된 프롬프트와 자체 컨텍스트를 사용하며, 공통으로 접근하는 것은 워크스페이스·산출물·조율자가 누적한 기록이다. - 에이전트 간 실시간 공동 컨텍스트 대신 구조화된 산출물과 transcript를 통해 협업한다. ## JSON 기반 상태 머신 - 각 토론 라운드는 제안자와 도전자의 교환 및 조율자의 결정을 포함한다. - 에이전트는 긴 에세이가 아니라 조율자가 파싱할 수 있는 엄격한 JSON을 반환한다. - JSON에는 상태, 요약, 전문가 의견, 판단 근거, 요구 사항, 제약, 완료 정의, 가정, 질문 등이 담긴다. - 예를 들어 `/api/search`만 변경할지 인접한 검색 엔드포인트까지 포함할지 불명확하면, 도전자는 범위 경계를 명시적인 질문으로 제기한다. - 모호성이 작고 기존 근거로 안전하게 판단할 수 있으면 제안자가 가정으로 기록하고 진행한다. - 반대로 답이 없으면 위험하거나 파괴적이거나 되돌리기 어려운 문제라면 추측하지 않고 사람에게 상위 보고한다. ## 전문 역할과 근거 중심 검증 - 각 단계에는 목적에 맞는 전문 역할이 배정된다. - `requirements-synthesizer`: 요구 사항 정리 - `security-analyst`: 보안 위험 분석 - `test-coverage-reviewer`: 테스트 범위 검토 - `technical-writer`: 전달 문서 작성 - `evidence-verifier`: 구현과 검증 근거 확인 - 중요한 판단은 직감이 아니라 코드, 테스트, 문서, 실행 결과 같은 근거에 기반한다. - 핵심은 여러 AI를 단순히 병렬 실행하는 것이 아니라, 서로 다른 책임과 관점을 부여해 주장과 반론을 구조화하는 데 있다. ## 실용적인 결론 AI 코딩 시스템을 설계할 때는 코드 생성 에이전트 하나를 더 빠르게 만드는 것보다, 스펙부터 PR 전달까지의 인수인계를 자동화하는 것이 더 큰 효과를 낼 수 있다. 특히 스펙을 계약으로 명확히 만들고, 단계별 도전과 근거 제출을 강제하며, 위험한 가정은 사람에게 상위 보고하도록 구성하는 것이 핵심이다.

원문 읽기(새 탭에서 열림)
CI/CDAI 에이전트코드 리뷰json+3
gitlab4분 읽기큐레이션 요약

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
line5분 읽기큐레이션 요약

코드형 인프라(IaC)로 자동화에서 AI까지: OpenTofu와 ChatOps 도입기

LY Corporation의 LINE Plus SRE 팀은 운영 인프라를 콘솔·스크립트·문서가 아닌 OpenTofu와 Terragrunt 기반의 IaC로 통합했다. 약 1,500개 리소스를 GitOps 방식으로 관리하며, 모든 변경을 PR 리뷰와 CI/CD를 거치게 하고 실제 인프라와 코드의 차이도 자동 감지한다. 핵심은 기존 운영 리소스를 안전하게 import하고, 리소스별 특성과 의존 관계를 반영해 코드·state·실제 인프라를 일치시키는 것이다. ## 운영 규모 확대로 드러난 기존 방식의 한계 - 팀마다 Verda 대시보드, 자체 스크립트, 위키 매뉴얼 등 서로 다른 방식으로 인프라를 관리했다. - 설정 정보도 위키, 개인 문서, GitHub 등 여러 곳에 분산되어 있었다. - 서비스와 리소스가 늘어나면서 다음 문제가 누적됐다. - 변경 이력과 변경 주체를 일관되게 추적하기 어려움 - 동일한 작업을 반복 수행할 때 실수 가능성 증가 - 환경별 설정 차이와 실제 인프라 상태를 파악하기 어려움 - 변경 전 검토와 변경 후 검증이 체계적이지 않음 - 이를 해결하기 위해 인프라의 원하는 상태를 코드로 선언하고, 변경을 자동화·표준화할 필요가 생겼다. ## GitOps로 인프라를 애플리케이션 코드처럼 관리 - 인프라 설정을 Git 저장소에 선언하고 모든 변경을 PR로 진행한다. - 코드 리뷰, CI/CD, 변경 이력 관리 등 애플리케이션 개발 방식을 인프라에도 적용한다. - 콘솔에서 직접 클릭하거나 SSH로 수정하는 방식 대신 다음 흐름을 사용한다. - Git에 코드 변경 - PR 리뷰 - CI/CD를 통한 plan 및 적용 - 실제 인프라와 선언된 상태의 차이 자동 감지 - IaC의 목표는 단순한 자동화가 아니라 인프라를 다음과 같은 엔지니어링 산출물로 만드는 것이다. - 리뷰 가능 - 버전 관리 가능 - 재현 가능 - 변경 이력 추적 가능 ## OpenTofu와 Terragrunt 선택 - **OpenTofu** - Terraform의 오픈소스 포크다. - 기존 Terraform과 동일한 HCL 문법과 프로바이더 호환성을 유지한다. - 기존 Terraform 기반 작성 방식과 모듈 구조를 재사용하기 쉬워 학습 비용이 낮다. - **모듈화** - VM, 로드밸런서, 모니터링 알림 등을 공통 모듈로 분리했다. - 팀별로 모듈에 입력값만 전달해 동일한 구조의 인프라를 생성할 수 있다. - 모듈은 버전으로 관리하며, 새 버전은 필요한 환경에서만 명시적으로 올린다. - **Terragrunt** - OpenTofu의 환경 구성 중복을 줄이는 래퍼다. - 공통 설정은 상위 `root.hcl`에 정의한다. - 각 환경에는 서로 다른 입력값만 남긴다. - 결과적으로 OpenTofu 모듈은 리소스 정의 중복을, Terragrunt는 환경별 설정 중복을 줄였다. ## 기존 리소스의 단계적 IaC 전환 - 이미 운영 중인 약 300대의 VM, 160개의 LB, 350개의 DNS 레코드를 코드 관리 체계로 옮겨야 했다. - 리소스를 하나씩 수동 import하면 시간이 오래 걸리고 실수 가능성이 높기 때문에 자동화된 import 스크립트를 작성했다. - 전환은 두 단계로 진행했다. - **1단계:** 한 서비스를 선정해 import, 모듈, Terragrunt, CI/CD 전체 파이프라인을 검증 - **2단계:** 검증된 모듈과 import 스크립트를 나머지 서비스에 확산 - 운영 중인 인프라에 영향을 주지 않는 것이 가장 중요한 원칙이었다. ## import 스크립트의 표준 흐름 import 스크립트는 다음 과정을 공통 흐름으로 삼았다. - 현재 클라우드 리소스를 조회한다. - IaC로 관리할 대상과 제외할 대상을 구분한다. - 모듈 구조에 맞게 설정을 변환하고 Terragrunt 파일을 생성한다. - 실제 리소스를 OpenTofu state에 연결한다. - `plan` 결과를 확인해 불필요한 변경이 없는지 검증한다. 특히 다음 세 요소를 일치시키는 데 집중했다. - 코드에 선언된 값 - OpenTofu state 파일의 연결 정보 - 실제 클라우드 리소스의 상태 ## import 후 정규화와 가짜 변경 제거 - import를 완료해도 코드, state, 실제 리소스의 값 표현이 다르면 `plan`에서 계속 변경 사항이 나타날 수 있었다. - 예를 들어 네트워크 ID나 이미지 ID가 같은 대상을 가리키더라도 표현 방식이 다를 수 있다. - 이를 방치하면 `plan` 결과를 신뢰하기 어려워지므로 import 후 정규화 과정을 추가했다. - 정규화의 목적은 다음과 같다. - 동일한 리소스를 표현하는 값의 형식 통일 - 불필요한 diff 제거 - 실제 변경과 표현 차이에 따른 가짜 변경 구분 ## 리소스 특성에 따른 개별 import 전략 모든 리소스를 동일한 방식으로 가져올 수 없었기 때문에 리소스 유형과 의존 관계에 따라 import 단위를 달리했다. - **VM** - 개별 인스턴스를 기준으로 import한다. - **로드밸런서** - LB뿐 아니라 리스너와 풀 등 함께 동작하는 하위 리소스를 고려한다. - **DNS** - 존과 레코드의 관계를 유지한다. - **쿠버네티스** - 클러스터와 노드 풀을 어떤 단위로 관리할지 결정한다. - **IMON 알림** - 팀 → 알림 그룹 → 알림 규칙 → 알림 모니터의 계층 관계를 보존한다. - IMON 리소스는 실제 구조와 유사하게 디렉터리를 구성해 소속 관계를 쉽게 확인할 수 있도록 했다. ## 운영 리소스와 자동 생성 리소스의 구분 - OpenStack에는 사람이 만든 VM과 쿠버네티스가 자동으로 만든 VM이 함께 존재했다. - 두 리소스는 외형상 비슷하지만 관리 주체가 다르다. - 쿠버네티스가 관리하는 VM까지 IaC로 가져오면 클러스터의 기대 상태와 OpenTofu 관리 상태가 충돌할 수 있다. - 따라서 네이밍 패턴과 메타데이터를 기준으로 쿠버네티스 생성 VM을 import 대상에서 제외했다. - 모든 리소스를 무조건 코드화하는 것이 아니라, 관리 주체와 생명주기를 먼저 판단하는 것이 중요했다. ## 프로바이더와 리전 차이 해결 - 실제 클라우드와 OpenTofu 프로바이더의 검증·백엔드 동작이 완전히 일치하지 않는 문제도 발견됐다. - **LB 이름의 하이픈·언더스코어 충돌** - 클라우드는 `-`와 `_`를 모두 허용했다. - 그러나 프로바이더 백엔드의 검증 로직은 `_`를 허용하지 않았다. - 기존 LB를 import할 때 오류가 발생했다. - 프로바이더의 validation 로직을 수정해 해결하고, 해당 변경을 프로바이더에 기여했다. - **리전별 UUID 불일치** - 리전마다 `flavor_id`, `image_id`, `network_id`가 달랐다. - import 이후 `plan`에서 실제 변경이 아닌 불필요한 diff가 반복됐다. - 사용자는 사람이 읽기 쉬운 이름을 입력하고, 모듈이 리전별 실제 UUID로 변환하도록 매핑 로직을 추가했다. - 이 방식으로 코드 가독성을 높이고 가짜 변경을 줄였다. ## 실용적인 적용 시사점 - 기존 인프라를 IaC로 전환할 때는 단순히 import 명령을 실행하는 것보다 리소스 분류, 정규화, 의존 관계 분석이 중요하다. - 먼저 하나의 서비스에서 전체 프로세스를 검증한 뒤 다른 서비스로 확산하는 방식이 안전하다. - 자동 생성 리소스는 관리 주체가 다르므로 무조건 import하지 않아야 한다. - 프로바이더가 실제 클라우드의 모든 기존 상태를 완벽히 표현하지 못할 수 있으므로, import 후 반드시 `plan` 검증과 예외 처리가 필요하다. - 최종적으로 IaC의 효과는 코드 작성 자체보다 PR 리뷰, 자동 배포, 상태 차이 감지까지 포함한 운영 프로세스 전체를 표준화하는 데 있다.

원문 읽기(새 탭에서 열림)
CI/CD쿠버네티스infrastructure-as-codegitops+3
gitlab3분 읽기큐레이션 요약

거버넌스 및 운영을 위한 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 자동화 기반 - 이벤트 기반 실행으로 사람이 버튼을 누르지 않아도 반복적인 검토, 분류, 알림, 배포 후속 작업을 수행할 수 있습니다. - 관리자는 실행 가능한 에이전트·플로우·모델을 통제하고, 개발자는 자동화 설정 오류를 운영 장애 전에 발견할 수 있습니다. - 도입 시에는 먼저 승인된 모델과 콘텐츠 범위를 정한 뒤, 실패 파이프라인이나 머지 리퀘스트 준비 완료 같은 명확한 이벤트부터 플로우를 단계적으로 적용하는 것이 좋습니다.

원문 읽기(새 탭에서 열림)
CI/CDAI 에이전트gitlabDevSecOps+3
gitlab4분 읽기큐레이션 요약

GitLab 19.1 릴리스 노트 | GitLab Docs

GitLab 19.1은 GitLab Duo의 보안·거버넌스를 강화하고, 시크릿 탐지와 코드 리뷰 자동화를 개선한 릴리스다. 특히 AI가 시크릿 탐지의 오탐 가능성을 분석하고, 관리자가 Duo 사용과 에이전트 도구 실행을 중앙에서 통제할 수 있게 됐다. 또한 규정 준수 템플릿, Code Owner 자동 리뷰어 지정, 기능 브랜치의 전체 커밋 대상 시크릿 검사 등이 추가됐다. ## GitLab Duo 기반 시크릿 오탐 탐지 - GitLab Duo Agent Platform에서 시크릿 탐지 결과의 오탐 여부를 자동 분석하는 기능이 정식 출시됐다. - 보안 스캔 후 각 **Critical·High 심각도** 시크릿 취약점을 자동으로 분석한다. - 취약점 상세 화면에서 개별 항목을 수동으로 분석할 수도 있다. - 분석 결과는 취약점 리포트에 기존 심각도, 상태, 수정 정보와 함께 표시된다. - 코드 문맥과 취약점 특성을 기반으로 실제 시크릿일 가능성에 대한 AI 설명을 제공한다. - 신뢰도 점수를 통해 보안팀이 검토 우선순위를 정할 수 있다. - 오탐 조사에 드는 시간을 줄이고, 실제 보안 위험에 집중하도록 돕는다. - GitLab Ultimate에서 제공된다. ## GitLab Duo 항상 켜기 설정 - 관리자가 인스턴스 전체 또는 최상위 그룹에서 GitLab Duo를 **Always on**으로 설정할 수 있다. - 항상 켜짐 상태에서는 그룹·하위 그룹·프로젝트 소유자가 Duo를 비활성화할 수 없다. - 기존의 **Always off** 설정과 대칭적인 기능으로, 조직 차원의 AI 사용 정책을 일관되게 적용할 수 있다. - 규제 산업이나 여러 자회사·사업부에서 공통 AI 도구 사용을 보장해야 하는 경우 유용하다. - 인스턴스 또는 최상위 그룹의 GitLab Duo 설정에서 가용성을 Always on으로 지정한다. - Premium 및 Ultimate에서 제공된다. ## Code Owner 자동 리뷰어 지정 - 기존에는 CODEOWNERS 파일이 있어도 머지 리퀘스트마다 리뷰어를 수동 지정해야 했다. - 이제 변경된 파일과 일치하는 모든 Code Owner를 리뷰어로 자동 지정할 수 있다. - 머지 리퀘스트가 준비 상태로 생성되거나, Draft에서 Ready 상태로 전환될 때 동작한다. - 사용자가 이미 리뷰어를 지정했다면 자동 지정은 건너뛰고 기존 선택을 유지한다. - `Settings > Merge requests > Automatic reviewer assignment`에서 활성화할 수 있다. - Premium 및 Ultimate에서 제공된다. ## 규정 준수 프레임워크 템플릿 - Compliance Center에서 사전 정의된 템플릿으로 규정 준수 프레임워크를 생성할 수 있다. - 요구사항과 통제 항목을 일일이 수동 작성하지 않아도 된다. - 템플릿을 미리 보고 이름, 설명, 색상을 수정한 뒤 그룹에 적용할 수 있다. - ISO 27001:2022, SOC 2, FedRAMP, NIST, CIS, TISAX 등 총 19개 템플릿이 제공된다. - 베타 기능이며 GitLab Ultimate에서 제공된다. ## 기능 브랜치 시크릿 탐지 범위 개선 - 이전 버전에서는 새 브랜치의 최신 커밋만, 기존 브랜치는 가장 최근 푸시만 검사했다. - 과거 커밋에 포함된 자격 증명이 탐지되지 않은 채 공유 브랜치나 운영 환경으로 유입될 수 있었다. - GitLab 19.1부터는 기능 브랜치가 기본 브랜치에서 분기된 시점부터 최신 커밋까지 모든 커밋을 검사한다. - 시크릿이 개발 초기 단계에서 발견되므로 자격 증명 교체와 사고 대응 비용을 줄일 수 있다. - Free, Premium, Ultimate 모든 등급에서 제공된다. ## GitLab Duo 에이전트 도구 승인 가드레일 - 관리자가 Duo 에이전트의 도구별 실행 정책을 설정할 수 있다. - 각 도구에 다음 세 가지 모드 중 하나를 지정한다. - **Allow**: 승인 없이 실행 - **Ask**: 실행 직전에 사용자 승인 필요 - **Deny**: 실행 차단 - 이전에는 프로젝트에서 AI 에이전트를 승인하면 쓰기 작업이나 삭제 같은 민감한 도구도 추가 검토 없이 실행될 수 있었다. - `Ask` 도구가 호출되면 인라인 승인 카드가 표시되고, 사용자가 승인해야 실행된다. - Agentic Chat, IDE, Flows에 적용된다. - 모든 승인·거부 결정은 감사 이벤트로 기록된다. - 베타 기능이며 Premium 및 Ultimate에서 제공된다. ## 사용자 지정 AI 에이전트와 외부 기능 제어 - 관리자와 최상위 그룹 소유자가 조직 내에서 사용할 수 있는 AI 에이전트와 플로우를 통제할 수 있다. - 사용자가 사용자 지정 에이전트와 플로우를 생성하거나 활성화하지 못하도록 제한할 수 있다. - 그룹 계층 외부 프로젝트가 소유한 에이전트와 플로우의 활성화도 차단할 수 있다. - 중앙에서 승인한 AI 자동화만 사용하도록 정책을 적용하고, 신뢰할 수 없는 외부 콘텐츠 노출을 줄일 수 있다. - Premium 및 Ultimate에서 제공된다. ## 사용자 지정 플로우 YAML 사전 검증 - AI Catalog가 사용자 지정 플로우의 YAML 설정을 저장하거나 실행하기 전에 검증한다. - 누락된 입력값, 알 수 없는 도구 매개변수, 문법 오류 등을 UI에서 즉시 확인할 수 있다. - 이전에는 CI 작업이 시작된 뒤 런타임에서 오류가 발생해 디버깅이 늦어질 수 있었다. - 유효한 플로우는 기존처럼 저장하고 실행할 수 있다. - Premium 및 Ultimate에서 제공된다. ## Agentic Chat의 패턴 기반 도구 승인 - 릴리스 노트 후반부에서는 Agentic Chat을 위한 패턴 기반 도구 승인 기능도 소개되기 시작한다. - 제공된 내용에서는 기능의 세부 동작과 정책 설정 방식이 생략되어 있어, 구체적인 요건은 전체 릴리스 노트를 확인해야 한다. 이번 릴리스는 AI 기능을 단순히 확대하는 데 그치지 않고, 조직 차원의 사용 강제, 도구별 승인, 외부 에이전트 제한, 감사 기록을 통해 통제 가능한 AI 운영을 강화한 것이 특징이다. 동시에 기능 브랜치 전체 커밋 검사와 자동 Code Owner 리뷰어 지정으로 개발·보안 workflow의 누락도 줄였으므로, GitLab Duo와 보안 스캔을 사용하는 조직이라면 관련 설정을 검토할 만하다.

원문 읽기(새 탭에서 열림)
CI/CDAI 에이전트gitlabyaml+4
aws4분 읽기큐레이션 요약

AWS DevOps Agent, 프로덕션 배포 전 코드 변경 사항 평가를 위한 릴리스 관리 기능 추가(프리뷰) | Amazon Web Services

AWS DevOps Agent에 코드 변경사항을 운영 배포 전에 검토하고 자동으로 테스트하는 릴리스 관리 기능이 프리뷰로 추가되었습니다. 에이전트는 조직의 자연어 기준, 의존성 안전성, 접근 제어, 운영 환경 요구사항을 검토하고 변경사항에 맞는 테스트를 생성·실행합니다. 이를 통해 AI가 생성한 코드 증가로 발생한 리뷰 병목과 운영 환경과 테스트 환경의 차이를 줄이고, 코드 작성부터 배포까지 자동화 수준을 높일 수 있습니다. ## AI 코드 증가로 인한 리뷰와 테스트 병목 - AI 코딩 도구 확산으로 풀 리퀘스트 수가 리뷰·테스트 역량보다 빠르게 증가하고 있습니다. - 일정 압박 때문에 사람이 코드를 충분히 검토하지 못한 채 승인하는 문제가 발생합니다. - 테스트 환경이 운영 환경과 달라 실제 배포 후에야 문제가 발견될 수 있습니다. - AI 모델은 사람이 시간 압박 속에서 놓치기 쉬운 기능 및 보안 문제를 탐지할 수 있어, 빠르면서도 안전한 배포가 중요해졌습니다. ## 릴리스 준비성 검토 - 모든 코드 변경사항을 다음 기준으로 분석합니다. - 운영 환경 요구사항 - 서비스 및 리포지터리 간 의존성 안전성 - 사용자가 정의한 내부 표준과 모범 사례 - AWS Well-Architected Framework에 따른 접근 제어 변경사항 - 여러 리포지터리의 의존성을 분석해 한 서비스의 변경이 다른 서비스에 미칠 영향을 확인합니다. - 별도의 기준을 지정하지 않으면 일반적인 모범 사례를 적용합니다. - AWS가 관리하는 격리 환경에서 애플리케이션을 실행하고 다음을 확인합니다. - 빌드 성공 여부 - 애플리케이션 실행 가능 여부 - 기본적인 사용자 여정과 기능 동작 - 분석 결과는 AWS DevOps Agent 콘솔과 GitHub·GitLab 풀 리퀘스트 댓글에 표시됩니다. - Kiro power 또는 Claude Code 플러그인을 통해 커밋 전에 IDE에서 직접 검토를 실행할 수도 있습니다. ## 조직별 자연어 기준 설정 - AWS DevOps Agent 콘솔에서 `Knowledge` → `Instructions`로 이동해 검토 기준을 편집합니다. - `Release readiness review`에 특정 작업용 지침을 추가할 수 있습니다. - 일반 영어 문장으로 다음과 같은 내부 기준을 정의할 수 있습니다. - 암호화 및 네트워크 접근 규칙 - 로깅과 관측 가능성 요구사항 - 민감 데이터 분류 및 고위험 리소스 식별 - 차단하지 않고 경고만 해야 하는 기준 - 모든 에이전트에 공통 기준을 적용하려면 `All agents` 지침을 수정합니다. ## 자동 릴리스 테스트 - 웹 애플리케이션과 API 애플리케이션을 대상으로 변경사항에 특화된 테스트 계획을 자동 생성합니다. - 정적인 테스트 스위트를 반복 실행하는 대신, 변경 내용과 영향 범위를 분석해 테스트를 구성합니다. - 다음 유형의 문제를 검증합니다. - 기능적 정확성 - 기존 동작의 회귀 - 서비스 간 통합 문제 - 수동 테스트 계획에서 누락될 수 있는 시나리오 - 고객이 제공한 운영 유사 환경에서 병합 전에 테스트를 실행합니다. - 각 실행 결과에는 다음 구조화된 산출물이 포함됩니다. - 메트릭 - 로그 - 트레이스 - 테스트 실행 요약 ## 검토 실행 방법 - 먼저 GitHub 또는 GitLab 리포지터리를 Agent Space에 연결해야 합니다. - 연결된 코드는 인덱싱되며, 리포지터리와 클라우드 리소스 간 의존성을 나타내는 지식 그래프가 생성됩니다. - 웹 앱에서 Agent Space를 선택한 뒤 `Web app` 탭과 `Operator access`를 선택합니다. - 릴리스 준비성 검토는 다음 방식으로 실행할 수 있습니다. - 연결된 리포지터리에 풀 리퀘스트 제출 - 채팅에서 온디맨드 요청 실행 - 채팅에서는 다음과 같이 요청할 수 있습니다. ```text Perform a production risk analysis on my repository branch ``` - 이후 분석할 리포지터리와 브랜치를 지정합니다. - 브랜치 이름, 풀 리퀘스트 번호, 커밋 SHA를 기준으로 분석할 수 있습니다. - 인프라 영향, 설정 변경, 배포 시 발생 가능한 위험을 종합적으로 검토합니다. - 완료 후 후속 질문을 통해 특정 변경사항의 하위 소비자, 영향받는 파일과 줄 번호, 해결 방법을 추가로 확인할 수 있습니다. ## 검토 결과와 보고서 - `Changes` 메뉴의 `Proposed changes` 표에서 실행된 검토를 확인할 수 있습니다. - 카테고리와 상태로 필터링하거나 이름으로 검색할 수 있습니다. - `Timeline` 탭에서는 에이전트가 호출한 도구, 참고한 의존성, 각 단계의 관찰 내용을 시간순으로 확인할 수 있습니다. - `Report` 탭에는 다음 정보가 제공됩니다. - 최종 권고 조치 - 발견된 심각한 문제 수 - 커밋 리비전 - 변경된 파일 수 - 권고 조치는 다음 세 가지 중 하나입니다. - `BLOCK` - `Proceed with Caution` - `Safe to Release` - 보고서의 주요 구성은 다음과 같습니다. - `Analysis`: 권고 조치의 근거와 발견된 위험 - `Issues`: 심각도별 문제 목록 - `Recommendations`: 문제 해결을 위한 구체적인 조치 - `Changes`: 변경된 파일, 변경 유형, 분류, 변경 내용 AWS DevOps Agent의 릴리스 관리 기능은 사람의 리뷰를 완전히 대체하기보다는, AI 생성 코드가 늘어난 환경에서 반복적인 위험 분석과 변경별 테스트를 자동화하는 보조 수단으로 활용하는 것이 적절합니다. 우선 내부 보안·운영 기준을 자연어 지침으로 명확히 정의하고, 풀 리퀘스트 단계에서 릴리스 준비성 검토를 실행한 뒤 운영 유사 환경의 자동 테스트를 병행하는 방식을 권장합니다.

원문 읽기(새 탭에서 열림)
CI/CD옵저버빌리티gitlabgithub+4
gitlab4분 읽기큐레이션 요약

GitLab, 2026 Gartner® DevSecOps 플랫폼 매직 쿼드런트™에서 리더로 선정

GitLab은 Gartner의 2026년 DevSecOps 플랫폼 매직 쿼드런트에서 4년 연속 리더로 선정됐다고 발표했습니다. 글은 AI 코딩 에이전트가 개발 속도는 높였지만 파이프라인, 보안, 배포, 비용 관리 등 후속 단계의 병목을 키웠다고 지적합니다. 이에 GitLab은 소스 코드부터 CI/CD, 보안, 배포, 거버넌스를 통합해 에이전트 시대에 ‘속도와 통제’를 동시에 제공하는 플랫폼을 지향한다고 설명합니다. ## AI 에이전트가 만든 새로운 병목 - 개발자들은 여러 AI 코딩 어시스턴트를 사용하며 코드 생산량이 빠르게 증가하고 있습니다. - 그러나 코드 작성 속도가 빨라져도 전체 소프트웨어 출시 속도가 반드시 개선되지는 않습니다. - 증가한 코드량은 다음 영역에 부담을 전가합니다. - CI/CD 파이프라인 구성 - 보안 취약점 및 보안 경고 처리 - 배포 순서 조정 - 인프라 및 도구 비용 관리 - 한 단계의 속도만 높이면 병목이 다음 단계로 이동하므로, 단순히 코딩 도구를 추가하는 방식으로는 충분하지 않습니다. - GitLab은 이를 “속도와 통제(speed with control)”의 문제로 정의합니다. ## 에이전트 시대의 통제 계층 - 기업은 에이전트가 다음과 같은 작업을 수행하는 방식을 통합적으로 관리해야 합니다. - 누가 에이전트를 실행하는가 - 어떤 데이터에 접근할 수 있는가 - 어떤 작업을 수행할 수 있는가 - 작업 내역을 감사할 수 있는가 - GitLab은 소스 코드 관리, CI/CD, 보안, 배포를 하나의 플랫폼에 통합합니다. - 개발자나 AI 에이전트가 변경 사항을 만들더라도 기존 코드, 파이프라인, 정책을 기준으로 검증한 뒤 배포하도록 지원합니다. - 따라서 GitLab은 에이전트가 생성한 결과를 프로덕션에 적용하기 전에 검증하고 통제하는 중앙 계층을 자처합니다. ## 대규모·규제 환경을 위한 플랫폼 - Ericsson은 GitLab을 통해 배포 시간을 절반으로 줄였다고 소개됩니다. - Southwest Airlines는 24시간 운영되는 항공 시스템에서 미션 크리티컬 소프트웨어를 관리합니다. - Barclays PLC와 같은 규제 산업 기업은 보안·컴플라이언스 요구사항을 유지하면서 소프트웨어를 출시해야 합니다. - GitLab은 다음 배포 형태에서 동일한 플랫폼 및 거버넌스 기능을 제공한다고 설명합니다. - 멀티테넌트 SaaS - 싱글테넌트 SaaS - 자체 관리형(Self-managed) 배포 - 에어갭 환경 및 자체 호스팅 모델 기반 에이전트 - SaaS와 온프레미스 환경 모두에서 AI 기능과 배포 통제력을 유지하는 점을 Gartner가 강점으로 평가했다고 주장합니다. - 외부 도구와 AI 서비스를 연동하면서도 하나의 거버넌스 경계 안에서 관리할 수 있습니다. ## 엔터프라이즈급 가용성과 책임 - 에이전트 작업을 전체 개발 생명주기에 걸쳐 조정하려면 플랫폼의 안정적인 가용성이 필수입니다. - GitLab은 Ultimate 고객을 대상으로 GitLab.com과 GitLab Dedicated에 월간 99.9% 가용성을 약정합니다. - 가용성이 기준 이하로 떨어지면 대상 고객은 향후 청구서에 사용할 서비스 크레딧을 받을 수 있습니다. - GitLab은 이러한 보상 체계가 실제 고객 경험에 대한 플랫폼의 책임을 명확히 한다고 설명합니다. ## 속도와 통제를 강화하는 5가지 혁신 - **차세대 소스 코드 관리** - 머신 규모의 작업을 목표로 설계되었습니다. - 테스트 결과 최대 50배 빠른 실행과 최대 1,000배 적은 네트워크 데이터 전송을 달성했다고 밝힙니다. - **GitLab Orbit** - 코드, 작업 항목, 파이프라인, 배포, 운영 신호를 연결하는 컨텍스트 그래프입니다. - Claude Code와 함께 사용할 경우 동일한 모델과 작업에서 최대 11배 빠른 실행을 제공한다고 설명합니다. - 토큰 사용량은 최대 4.5배, 환각은 최대 45배 줄일 수 있다고 주장합니다. - **보안·거버넌스 에이전트** - 에이전트가 늘어나면서 발생하는 보안 및 컴플라이언스 공백을 관리합니다. - **에이전트 트리거** - 개발자와 에이전트 간 작업 인계를 자동화합니다. - 사람이 각 단계의 진행을 직접 조정하지 않아도 작업 흐름을 연결할 수 있습니다. - **GitLab Flex 계약** - 계약을 변경하지 않고도 제품 및 기능별 GitLab 사용량과 비용 구성을 조정할 수 있도록 지원합니다. ## GitLab이 제시하는 전략적 방향 - GitLab은 기업이 다음 세 가지를 하나의 체계로 확보해야 한다고 강조합니다. - 하나의 통합 플랫폼 - 하나의 컨텍스트 그래프 - 하나의 거버넌스 경계 - 이를 통해 개발자와 AI 에이전트가 함께 소프트웨어를 만들면서도 보안, 정책, 비용, 배포 통제를 유지할 수 있다는 주장입니다. - GitLab은 175개월 이상 연속으로 매달 새로운 기능을 출시하며 혁신을 이어가고 있다고 덧붙입니다. - Gartner의 평가는 GitLab이 단순한 개발 도구가 아니라 전체 소프트웨어 생명주기를 조율하는 DevSecOps 플랫폼으로 자리 잡았다는 점을 반영한다고 설명합니다. 실무적으로는 AI 코딩 도구 도입 자체보다, 생성된 코드의 검증·보안·배포·감사·비용 관리를 하나의 통제 체계로 연결하는 것이 중요합니다. 여러 에이전트를 운영하는 조직이라면 GitLab과 같은 통합 플랫폼을 검토하되, Gartner의 평가와 공급업체의 성능 수치는 실제 환경에서 별도로 검증하는 것이 좋습니다.

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

GitLab 패치 릴리스: 19.0.2, 18.11.5, 18.10.8 | GitLab 문서

2026년 6월 10일 GitLab은 CE/EE용 패치 버전 19.0.2, 18.11.5, 18.10.8을 출시했다. 이번 릴리스에는 계정 탈취, XSS, 서비스 거부, SSRF, 권한 우회 등 다수의 보안 취약점이 포함되어 있어 모든 자체 관리형 설치 환경에 즉시 업그레이드가 권고된다. GitLab.com은 이미 패치가 적용됐으며, GitLab Dedicated 고객은 별도 조치가 필요 없다. ## 패치 릴리스와 업그레이드 권고 - 패치 릴리스는 보안 및 주요 버그를 수정하기 위한 버전이다. - 정기 패치는 매월 둘째·넷째 수요일에 배포되며, 심각도가 높은 취약점에는 비정기 긴급 패치가 제공될 수 있다. - 영향을 받는 버전을 사용하는 모든 설치 유형(Omnibus, 소스 코드, Helm Chart 등)은 가능한 한 빨리 최신 패치 버전으로 업그레이드해야 한다. - 보안 취약점의 상세 이슈는 수정 릴리스 후 30일이 지나면 공개된다. ## 계정 탈취와 권한 검증 문제 - **CVE-2026-6552 — Group SAML Identity API** - GitLab EE 대상 취약점이다. - 그룹 Owner 권한의 인증 사용자가 잘못된 권한 검증을 악용해 다른 그룹 구성원의 GitLab 계정을 탈취할 수 있었다. - CVSS **8.7**로 이번 릴리스에서 가장 심각한 취약점 중 하나다. - **CVE-2026-6269 — Merge Requests API** - CE/EE 모두 영향을 받는다. - Developer 권한 사용자가 숨겨진 머지 리퀘스트를 수정할 수 있었다. - CVSS **5.4**다. - **CVE-2026-6277 — Security Inventory** - GitLab EE 대상이다. - Security Manager가 관련 기능이 비활성화된 상태에서도 프로젝트 보안 설정을 변경할 수 있었다. - CVSS **4.3**이다. - **CVE-2026-6976 — Merge Request diff** - 파일명 처리와 권한 검증 문제로 Developer가 머지 리퀘스트 diff에서 변경 사항을 숨길 수 있었다. - CVSS는 **3.7**로 평가됐다. ## XSS 및 HTML 입력값 검증 문제 - **CVE-2026-10087 — Analytics Dashboard** - GitLab EE 대상이다. - Developer 권한 사용자가 입력값 검증 미흡을 이용해 대상 사용자의 권한으로 임의의 클라이언트 측 코드를 실행할 수 있었다. - CVSS **8.7**이며, 사용자의 상호작용이 필요하다. - **CVE-2026-8589 — 그룹 설정 필드** - GitLab EE 대상이다. - 악의적인 입력을 통해 대상 사용자 계정에 승인되지 않은 이메일 주소를 추가할 수 있었다. - CVSS **7.3**이다. - **CVE-2026-10733 — CI/CD Catalog** - CE/EE 모두 영향을 받는다. - 부적절한 입력값 정제로 인해 인증 사용자가 CI/CD Catalog 페이지에서 서비스 거부를 유발할 수 있었다. - CVSS **4.3**이다. ## 서비스 거부 및 리소스 고갈 - **CVE-2026-7250 — Grape API JSON 파싱 미들웨어** - CE/EE의 API 요청 파싱 과정에서 입력값 검증이 부족했다. - 인증하지 않은 공격자가 조작된 요청을 보내 서비스 거부를 일으킬 수 있었다. - CVSS **7.5**로, 외부에 노출된 API 서버에 특히 중요하다. - **CVE-2026-1500 — Group Placeholder Reassignments API** - 특수하게 제작된 파일 업로드를 처리하는 과정에서 리소스가 과도하게 소비될 수 있었다. - 인증된 사용자가 서비스 거부를 유발할 수 있으며, CVSS는 **6.5**다. ## SSRF와 내부 데이터 접근 - **CVE-2026-9204 — Gitaly 저장소 가져오기** - 저장소 가져오기 과정에서 보조 URL 검증이 충분하지 않았다. - 인증된 사용자가 Gitaly 서버의 임의 파일을 읽거나 내부 네트워크 리소스에 접근할 가능성이 있었다. - CVSS **5.3**이며, 서버 측 요청 위조(SSRF) 유형의 취약점이다. ## 적용 대상 버전 - **19.0.2**: GitLab 19.0 계열의 이전 버전 - **18.11.5**: GitLab 18.11 계열의 이전 버전 - **18.10.8**: GitLab 18.10 계열의 이전 버전 - 취약점별로 GitLab 12.10, 13.1.4, 15.x, 17.x 등 다양한 이전 버전이 영향을 받는다. - 취약점에 따라 GitLab EE만 영향을 받거나 CE/EE 모두 영향을 받는다. 자체 관리형 GitLab 운영자는 현재 버전의 지원 브랜치에 맞춰 19.0.2, 18.11.5, 18.10.8 중 해당되는 버전으로 즉시 업그레이드하고, 외부 공개 API와 Gitaly 접근 로그도 함께 점검하는 것이 좋다.

원문 읽기(새 탭에서 열림)
CI/CDgitlabaccess-controlapi-security+3
line4분 읽기큐레이션 요약

레거시 프로젝트에서 AI 드리븐 프로젝트로 전환, AX 로드맵

AX는 AI 도구를 개별적으로 사용하는 데서 그치지 않고, 개발 사이클 전체를 AI 중심으로 재설계하는 전환 과정이다. 성공적인 전환을 위해서는 보안·컴플라이언스 기반을 먼저 마련하고, 팀 차원의 활용 표준화와 명세 기반 개발 자동화를 단계적으로 추진해야 한다. 특히 SDD와 사람의 승인 게이트를 결합하면 AI의 생산성을 활용하면서도 품질과 통제력을 유지할 수 있다. ## AI 드리븐 프로젝트와 SDD - AI 드리븐 프로젝트는 AI를 스펙 작성, 코드 생성, 테스트, 리뷰, 머지 등 개발 전 과정에 통합하는 방식이다. - 사람은 세부 구현보다 요구사항과 방향 설정, 품질 판단에 집중한다. - 핵심 방법론은 명세 주도 개발(SDD)이다. - 요구사항, 구현 범위, 예외 상황, 검증 기준을 먼저 정의한다. - AI는 명세를 바탕으로 계획을 세우고 코드를 생성·검증한다. - AI는 패턴 완성에는 강하지만 추상적인 의도 파악에는 한계가 있으므로, 명확한 스펙이 결과 품질을 좌우한다. ## 1단계: AI-Ready — 보안과 컴플라이언스 기반 AI 도입 전 민감 정보와 핵심 자산이 외부 모델에 노출되지 않도록 안전한 사용 환경을 구축한다. - API 키, DB 비밀번호, 내부 IP 등의 하드코딩을 제거한다. - Secrets Manager 같은 전용 서비스를 사용하고 런타임에 시크릿을 주입한다. - 이름, 이메일, 전화번호 등 PII는 AI에 전달하기 전에 마스킹하거나 토큰화한다. - 핵심 알고리즘과 경쟁력 있는 아키텍처는 별도 저장소에서 관리하거나 AI 접근 권한을 제한한다. - 초기에는 모든 시스템을 한 번에 이관하기보다 다음을 우선 적용한다. - 핵심 컴플라이언스 요건 선별 - 파일 시스템·네트워크 격리를 통한 샌드박싱 - 격리 상태에서 실제 정보가 노출되지 않는지 검증 - 기대 효과: - 코드와 프로젝트 맥락을 AI에 안전하게 제공 - 디버깅, 문서화, 반복 코드 작성 속도 향상 - 팀원들이 AI를 안전하게 활용하는 경험 축적 ## 2단계: AI-Assist — 팀 단위 활용 표준화 개인별로 제각각인 AI 사용 방식을 프로젝트 공통 워크플로로 통합한다. 이 단계에서 AI는 코드를 직접 작성하기보다 사람이 작성한 코드를 검토하고 보조한다. - 프로젝트 루트에 AI용 가이드라인을 작성한다. - 프로젝트 개요 - 코딩 컨벤션 - 아키텍처 원칙 - 도메인 용어집 - 코드 리뷰, 브레인스토밍, 작업 계획 수립 등에 사용할 표준 프롬프트와 스킬을 구축한다. - `superpowers`와 같은 플러그인을 활용해 다음 작업을 표준화할 수 있다. - `brainstorming` - `writing-plans` - `subagent-driven-development` - CI/CD와 AI를 연동해 PR 생성 시 자동 코드 리뷰를 수행한다. - 스타일 위반 탐지 - 잠재적 버그 확인 - 보안 취약점 점검 - 사람 리뷰어는 반복적인 지적보다 복잡한 비즈니스 로직과 정책 판단에 집중한다. - 측정 가능한 KPI: - 사람이 직접 남기는 반복 리뷰 코멘트 수 - 테스트 커버리지 변화 - 배포 안정성 및 테스트 통과율 - 기대 효과: - 팀 전체의 AI 활용 수준 상향 평준화 - 리뷰어의 인지 부하 감소 - 코드 품질과 컨벤션의 일관성 확보 ## 3단계: AI-Development — 명세 기반 개발 자동화 사람이 작성한 스펙이 AI를 통해 구현 계획, 테스트 계획, 코드, PR로 이어지는 자동화 파이프라인을 구축한다. - 전체 흐름은 다음과 같다. 1. 사람이 요구사항과 범위, 엣지 케이스, 검증 기준을 스펙으로 정의 2. AI가 구현 계획과 테스트 계획 작성 3. AI 서브 에이전트가 계획에 따라 작업을 순차적으로 수행 4. 코드 리뷰 후 PR 생성 및 머지 - 세 개의 Human Gate를 둔다. - **Human Gate 1:** 스펙 검토 및 승인 - **Human Gate 2:** 구현 계획과 테스트 계획 검토 및 승인 - **Human Gate 3:** 최종 코드 검토 및 승인 - AI가 프로젝트에 맞는 코드를 만들 수 있도록 도메인 지식을 구조화한다. - 아키텍처 원칙 - 비즈니스 로직의 예외와 특이사항 - 시스템 구성도 - 기존 스펙 및 기술 문서 - 지식은 전용 디렉터리, AI 커스텀 스킬, RAG 시스템 등을 통해 AI가 필요할 때 조회하도록 구성한다. - `/specs` 같은 디렉터리에 새 스펙 파일이 추가되면 CI가 이를 감지해 다음 단계를 실행하도록 이벤트 트리거를 설정한다. - CI 내부에 Approval Step을 배치해 사람의 승인 없이는 AI가 다음 단계로 진행하지 못하게 한다. - 초기에는 핵심 비즈니스 로직보다 테스트 코드나 보일러플레이트처럼 위험도가 낮은 영역부터 자동화를 적용하고, 신뢰가 쌓이면 AI의 담당 범위를 확대한다. ## 단계적 도입이 필요한 이유 - AI 활용 효과는 팀의 문서화 수준, 테스트 품질, 도메인 복잡도에 크게 좌우된다. - 처음부터 모든 구현을 AI에 맡기면 프로젝트 맥락을 이해하지 못한 코드가 생성될 수 있다. - 낮은 위험도의 테스트와 반복 코드부터 시작하면 품질을 검증하면서 팀의 신뢰를 확보할 수 있다. - 각 단계는 독립적으로도 효과가 있으므로 모든 단계를 한 번에 완료할 필요는 없다. 보안 기반을 먼저 확보한 뒤 프로젝트 규칙과 지식을 문서화하고, 자동 리뷰와 테스트 생성부터 시작하는 접근이 현실적이다. 이후 명확한 스펙과 사람의 승인 게이트를 중심으로 코드 생성 범위를 점진적으로 넓히는 것이 안전한 AX 전략이다.

원문 읽기(새 탭에서 열림)
CI/CDRAG테스트ai-coding-agents+3
gitlab5분 읽기큐레이션 요약

GitLab Orbit 소개

GitLab Orbit은 코드뿐 아니라 머지 리퀘스트, 파이프라인, 배포, 취약점, 소유권까지 연결한 실시간 그래프를 제공해 AI 에이전트가 시스템 전체 맥락을 한 번에 이해하도록 하는 서비스다. 이를 통해 에이전트는 파일을 반복 탐색하는 대신 관계형 질의를 수행하며, 최대 11배 빠르고 토큰 사용량은 4.5배 적어질 수 있다. GitLab은 Orbit이 코드 리뷰와 장애 대응, 보안, 마이그레이션처럼 여러 시스템을 함께 봐야 하는 작업의 정확성과 처리 속도를 높인다고 설명한다. ## 기존 AI 코딩 에이전트의 한계 - AI 에이전트는 코드 작성에는 강하지만 다음 정보를 찾는 데는 취약하다. - 관련 코드와 의존성 - 해당 코드를 실행하는 테스트와 파이프라인 - 실제 배포 환경 - 변경을 요청한 작업 항목 - 관련 팀과 담당자 - 대규모 모노레포에서는 에이전트가 파일을 탐색하는 데 토큰과 시간을 많이 사용한다. - 저장소가 여러 개로 나뉘면 컨텍스트가 부족해져 의존성을 놓치거나, 코드가 겉보기에는 맞지만 실제로는 되돌려지는 결과를 만들 수 있다. - 단순한 검색이나 RAG 방식만으로는 코드와 개발 lifecycle 데이터 사이의 관계를 충분히 복원하기 어렵다. ## 실제 머지 리퀘스트에서의 검증 - 영국 가격 비교 플랫폼 Compare the Market은 79개의 실제 머지 리퀘스트를 대상으로 AI 코드 리뷰의 컨텍스트 검색 방식을 비교했다. - Orbit을 사용한 리뷰어의 정확한 인라인 댓글 비율은 약 70%였다. - RAG 방식은 약 58%에 그쳤다. - 변경 사항 요약에서 핵심 변경을 포착한 비율도 Orbit이 68%, RAG가 66%였다. - RAG는 컨텍스트를 사용하지 않은 방식보다도 낮은 성능을 보였다. - 테스트 결과 Orbit은 단순히 현재 diff를 읽는 것이 아니라 코드베이스의 구조와 변경의 주변 영향을 이해하는 데 효과적이었다. ## 코딩 에이전트의 탐색 비용 감소 - Claude Code 같은 외부 에이전트를 MCP(Model Context Protocol)로 Orbit에 연결할 수 있다. - 에이전트는 다음 질문을 파일을 반복해서 읽으며 추론하지 않고 그래프에 직접 질의한다. - 특정 코드가 어디에 있는가? - 어떤 코드가 이를 의존하는가? - 어떤 테스트와 파이프라인이 이를 검증하는가? - 같은 모델과 같은 작업을 비교했을 때 다음과 같은 개선이 제시됐다. - 최대 11배 빠른 작업 수행 - 최대 4.5배 적은 토큰 사용 - 최대 45배 적은 환각 생성 - 결과적으로 에이전트가 실제 구현 작업을 시작하기 전에 소모하는 탐색 시간이 줄어든다. ## 파이프라인 장애의 전체 영향 추적 - 기존 에이전트는 실패한 파이프라인의 개별 job만 보고 원인을 고립된 문제로 판단하기 쉽다. - Orbit은 실패한 job에서 관련 파이프라인, 머지 리퀘스트, 프로젝트까지 연결해 추적한다. - 예시 질의는 실패한 CI job과 연결된 최근 머지 리퀘스트를 프로젝트별로 조회한다. ```cypher MATCH (job:CiJob {status: "failed", name: $job_name}) -[:RAN_IN]->(pipeline)-[:FOR]->(mr:MergeRequest) RETURN mr.title, mr.author, pipeline.started_at, mr.project_id ORDER BY pipeline.started_at DESC LIMIT 20 ``` - 이 방식으로 여러 프로젝트에서 동일한 장애를 만날 진행 중인 MR을 한 번에 찾을 수 있다. - 여러 팀이 같은 원인을 따로 해결하는 대신, 한 번의 대응으로 문제를 확산시키는 변경까지 파악할 수 있다. ## 취약점의 영향 범위와 담당자 파악 - 취약한 코드 자체를 찾는 것보다, 해당 코드가 시스템 어디까지 퍼졌는지를 확인하는 일이 더 어렵다. - Orbit은 다음 정보를 연결해 보여준다. - 취약한 컴포넌트를 포함한 서비스 - 해당 서비스를 빌드하는 파이프라인 - 실행되는 환경 - 각 구성 요소의 소유 팀 - 보안팀은 CVE가 공개된 직후 영향을 받는 구성 요소와 담당자를 포함한 remediation 계획을 만들 수 있다. - 수작업으로 여러 도구를 조사하는 데 걸리던 시간을 줄여 대응 속도를 높이는 것이 목표다. ## 조직 전반의 질의와 마이그레이션 계획 - Orbit은 고정된 대시보드에 없는 복합적인 질문에도 활용된다. - 예를 들어 팀별 cycle time을 파이프라인 실패율, 배포 빈도와 결합해 조회할 수 있다. - 공용 컴포넌트 마이그레이션에서는 다음 의존성을 한 번에 확인할 수 있다. - 종속 서비스 - 관련 job - 배포 환경 - 담당 소유자 - 숨은 downstream 의존성을 놓쳐 일정이 지연되는 위험을 줄이고, 마이그레이션 범위와 책임자를 구체화할 수 있다. ## Orbit의 기술 구조 - 소프트웨어 개발 lifecycle 데이터를 CDC(Change Data Capture) 방식으로 수집해 ClickHouse에 저장한다. - Rails 내부 API를 통해 12개 언어의 코드를 분석한다. - Ruby, Java, Kotlin, Python, TypeScript, JavaScript - Rust, Go, C#, C, C++, PHP - Cypher와 유사한 DSL, MCP, REST, GitLab CLI를 통해 그래프를 조회한다. - GitLab 자체 환경에서는 4만 개 이상의 프로젝트, 5억 개 노드, 20억 개 엣지를 45분 이내에 인덱싱한다고 설명한다. - 이벤트 기반 엔진이 변경 사항을 즉시 반영해 그래프를 최신 상태로 유지한다. - 인덱싱은 별도 서비스에서 수행되므로 쿼리 트래픽이 GitLab 인스턴스에 직접 부담을 주지 않는다. - GitLab 권한을 그대로 반영하므로 에이전트는 사용자가 UI에서 볼 수 있는 데이터만 조회한다. - 쿼리는 데이터베이스에 실행되기 전에 검증, 실행 계획 수립, 최적화, 보안 검사를 거친다. ## 다양한 사용 방식과 Data Explorer - GitLab Duo Agent Platform의 에이전트는 Orbit을 기본적으로 질의할 수 있다. - Claude Code, Codex, OpenCode 같은 외부 에이전트는 MCP와 GitLab CLI를 통해 연결한다. - 사내 도구나 맞춤형 에이전트는 REST API를 사용할 수 있다. - Data Explorer에서는 에이전트 없이 엔지니어가 같은 그래프를 직접 조회한다. - 장애 조사, 의존성 전파 추적, 반복적인 CI 실패 원인 분석처럼 정해진 프롬프트에 맞지 않는 작업에도 활용할 수 있다. Orbit은 코드 검색 도구라기보다 코드와 개발 lifecycle 전체를 연결하는 지식 그래프에 가깝다. 여러 저장소와 시스템에 걸친 의존성, 장애 영향, 보안 노출, 소유권을 자주 추적해야 하는 대규모 조직이라면 특히 효과가 크며, 도입 시에는 실제 MR 리뷰나 장애 대응 업무를 대상으로 기존 검색·RAG 방식과 정확도 및 비용을 비교해 검증하는 것이 좋다.

원문 읽기(새 탭에서 열림)
CI/CDAI 에이전트모델 컨텍스트 프로토콜graph-database+3
gitlab4분 읽기큐레이션 요약

GitLab: 에이전틱 엔지니어링 시대를 위해 설계되다

GitLab은 AI 코딩의 속도를 늦추기보다, 에이전트가 대규모로 활동해도 통제와 보안을 유지할 수 있는 통합 인프라가 필요하다고 주장합니다. 이를 위해 에이전트 규모의 소스 코드 관리, 전체 SDLC를 이해하는 컨텍스트 그래프, 보안·거버넌스, 작업 오케스트레이션, 유연한 구매 모델을 제공하겠다고 발표했습니다. 결론적으로 GitLab은 인간과 에이전트가 동일한 플랫폼에서 계획·개발·배포·감사를 수행하는 “에이전틱 엔지니어링” 플랫폼을 지향합니다. ## AI 코딩의 확산과 관리되지 않은 혼란 - 조사 대상 1,500명 이상의 개발자와 기술 리더 중: - 조직의 91%가 AI 코딩 도구를 2개 이상 사용 - 54%는 3개 이상 사용 - 일부 고객의 코드베이스는 1년 만에 최대 5배 성장 - 그러나 기존 소프트웨어 생명주기는 인간의 작업 속도를 전제로 설계되어 에이전트 규모의 병렬 작업을 감당하기 어렵습니다. - 주요 문제: - 에이전트가 코드만 알고 전체 SDLC 맥락은 이해하지 못함 - 대규모 모노레포나 여러 저장소에서 컨텍스트가 부족해 작업이 중단됨 - 코드·의존성·배포 변경 속도가 거버넌스보다 빨라짐 - 좌석 수와 크레딧을 미리 구매해야 하는 고정형 계약이 AI 사용량 변동에 맞지 않음 - 응답자의 73%는 코드 유지보수를 걱정했으며, 전체 SDLC에서 생산성 향상을 체감한 비율은 21%에 불과했습니다. ## GitLab의 에이전틱 인프라 구조 GitLab은 소스 코드 관리, CI/CD, 거버넌스, 배포를 하나의 플랫폼에서 제공하며, 현재 5,000만 명 이상의 사용자와 10만 개 조직이 사용한다고 설명합니다. - **모터 시스템**: 소스 코드 관리, 파이프라인, 배포 등 실제 실행 담당 - **신경 시스템**: 에이전트와 개발자가 올바른 판단을 내리도록 전체 맥락 제공 - **면역 시스템**: 모든 작업에 보안과 거버넌스 적용 - **오케스트레이션 시스템**: 전체 생명주기의 작업을 계획하고 조율 - 이 네 요소는 사람이 작업하든 에이전트가 작업하든 동일하게 작동하도록 설계됩니다. ## 차세대 SCM과 에이전트 규모의 동시성 기존 Git은 수백 명의 개발자가 병렬로 작업하는 환경에는 적합하지만, 각 개발자가 수백 개의 에이전트를 실행하는 상황에서는 한계가 발생합니다. - **클론 비용**: 에이전트가 파일 하나를 읽기 위해 저장소 전체를 복제하며, 재시도마다 비용이 반복됨 - **동시성 붕괴**: 수천 개의 세션이 인간 중심으로 설계된 백엔드에 몰려 병목과 불안정성이 발생 - **격리 부족**: 에이전트가 계정과 브랜치 공간을 공유해 작업이 섞이고, 폐기나 추적이 어려움 - GitLab은 Git 프로토콜과의 호환성 및 감사 가능성은 유지하면서, 에이전트 전용 백엔드와 인터페이스를 갖춘 차세대 SCM을 비공개 베타로 공개했습니다. - 초기 내부 테스트 결과: - 토큰 사용량 최대 2배 감소 - 실제 실행 시간 최대 50배 단축 - 네트워크 트래픽 최대 1,000배 감소 ## GitLab Orbit: 전체 SDLC를 연결하는 컨텍스트 그래프 에이전트는 코드를 작성하는 능력에 비해 코드 주변의 시스템과 생명주기를 파악하는 능력이 부족합니다. 이로 인해 잘못된 작업을 반복하거나, 겉보기에는 올바르지만 나중에 되돌려야 하는 결과를 만들 수 있습니다. - **GitLab Orbit**은 코드, 작업 항목, 파이프라인, 배포, 운영 신호를 하나의 실시간 그래프로 연결합니다. - 에이전트는 분산된 정보가 아니라 GitLab의 원천 데이터를 기반으로 추론할 수 있습니다. - 개발자는 Data Explorer를 통해 동일한 그래프를 조회하고 변경 사항이나 장애 원인을 추적할 수 있습니다. - 초기 내부 테스트에서 Orbit을 사용한 에이전트는: - 응답 속도 최대 11배 향상 - 비용 효율 최대 4.5배 향상 - 환각 최대 45배 감소 - Compare the Market의 A/B 테스트에서는 그래프 기반 에이전트가 코드 리뷰 댓글의 정확한 위치를: - 70%의 확률로 지정 - RAG 방식은 58% - 이 테스트는 실제 머지 리퀘스트 79건을 대상으로 진행됐으며, 그래프 기반 컨텍스트가 일반적인 검색 기반 방식보다 높은 정확도를 보였습니다. - Orbit은 현재 공개 베타 단계입니다. ## 에이전트 보안과 거버넌스 GitLab은 에이전트가 코드와 운영 환경에 직접 영향을 미치는 상황을 고려해, 에이전트 자체를 관리하는 기능도 발표했습니다. - 에이전트의 신원과 권한을 관리 - 정책을 적용해 허용 가능한 행동 범위 제한 - 모든 에이전트 작업을 감사 로그로 추적 - 위험한 작업에 승인 절차 적용 - 에이전트용 보안 및 거버넌스 기능은 비공개 베타로 제공될 예정입니다. ## GitLab Duo Agent Platform의 오케스트레이션 - GitLab Duo Agent Platform은 에이전트가 개발자의 작업 흐름을 중단하지 않고 다음 작업을 수행하도록 조율합니다. - 이슈 처리 - 코드 리뷰 - CI/CD 파이프라인 문제 수정 - 플랫폼은 소스 코드, 컨텍스트, 보안 정책을 연결해 단순 코드 생성이 아닌 전체 개발 생명주기 자동화를 목표로 합니다. - 해당 플랫폼은 2026년 1월부터 정식 제공되고 있습니다. ## GitLab Flex와 새로운 구매 방식 - AI 도입 속도와 사용량은 조직마다 크게 달라 기존의 고정된 좌석·크레딧 계약으로 예측하기 어렵습니다. - GitLab Flex는 실제 AI 도입 방식과 사용 패턴에 맞춰 구매할 수 있는 유연한 라이선스 모델입니다. - 현재 주문을 받고 있습니다. ## 실용적인 결론 AI 코딩 도구를 도입하는 것만으로는 에이전틱 엔지니어링의 생산성을 확보하기 어렵습니다. 대규모 동시성을 처리하는 SCM, 전체 SDLC 컨텍스트, 세밀한 권한·감사·승인 체계, 작업 오케스트레이션을 함께 구축해야 하며, GitLab은 이를 하나의 통합 플랫폼으로 제공하려는 전략을 제시하고 있습니다.

원문 읽기(새 탭에서 열림)
CI/CDAI 에이전트gitlabGit+4