gitlab2026년 7월 27일

GitLab의 Claude Opus 5: 어려운 작업을 위해 설계된 추론 (새 탭에서 열림)

Anthropic의 Claude Opus 5가 GitLab Duo Agent Platform에 출시되어 복잡하고 중요한 개발 작업에 더 깊은 추론 능력을 제공한다. GitLab 내부 평가에서 작업 해결률 93.3%를 기록해 Opus 4.8의 73.0%보다 크게 향상됐으며, 속도도 유지했다. 일상적인 작업에는 Sonnet 계열을, 대규모 리팩터링·장기 디버깅처럼 실패 비용이 큰 작업에는 Opus 5를 선택하는 전략이 권장된다. ## 복잡한 작업에서 강화된 추론과 정확성 - 여러 파일을 수정하는 기능 개발, 대규모 리팩터링, 장기간의 커밋 이력을 추적하는 디버깅에 적합하다. - 내부 평가에서: - Opus 5 작업 해결률: **93.3%** - Opus 4.8 작업 해결률: **73.0%** - 두 모델 모두 시도한 작업의 완료율은 **100%** - 단순히 작업을 끝내는 것을 넘어, 결과가 검증된 올바른 해결책인지에서 큰 차이를 보였다. - 부분적인 패치나 반복적인 재프롬프트가 줄어들어, 결과물을 바로 머지할 가능성이 높아진다. - 예시로 5개 파일을 수정하고 새로운 공개 타입과 설정 필드를 추가해야 하는 CLI SSO 인증 기능을 완전히 구현하고 커밋한 뒤 머지 리퀘스트까지 생성했다. ## 코드 리뷰와 멀티 에이전트 협업 - 실제 버그를 잘 포착하면서도 오탐이 적어, 개발자가 불필요한 경고를 검토하는 시간을 줄인다. - 여러 에이전트를 동시에 실행할 때 각 에이전트가 서로의 작업을 덮어쓰거나 충돌시키는 문제를 줄인다. - Writer-verifier 패턴을 활용할 수 있다. - 한 에이전트가 코드를 작성한다. - 다른 에이전트가 결과를 검증한다. - 검증을 통과한 결과만 최종 작업에 반영한다. - 장시간 자율 실행하거나 여러 에이전트를 병렬로 운영하는 환경에서 특히 효과가 크다. - GitLab Credits 사용량 상한을 설정해 병렬 에이전트 작업의 비용이 예산을 초과하지 않도록 제한할 수 있다. ## 깊은 추론을 유지하면서도 빠른 실행 - GitLab의 고난도 벤치마크에서 95번째 백분위 실행 시간은 다음과 같다. - Opus 5: **768초** - Opus 4.8: **784.98초** - Sonnet 4.6: **982.57초** - Opus 5는 Opus 4.8보다 **2.2% 빠르고**, Sonnet 4.6보다 **21.9% 빠르다**. - 복잡한 장기 작업에서도 실행 시간이 지나치게 늘어지는 상황을 줄여 보다 예측 가능한 결과를 제공한다. ## 작업별 모델 선택 - 모든 개발 작업에 가장 강력한 모델을 적용하기보다 작업의 복잡도에 따라 모델을 선택해야 한다. - **Sonnet 계열** - 일상적인 개발 작업 - 빠른 코드 생성과 수정 - 비용 효율성이 중요한 반복 작업 - **Opus 5** - 대규모 리팩터링 - 어려운 버그 추적 - 여러 파일과 시스템에 걸친 기능 구현 - 잘못된 판단을 다시 되돌리는 비용이 큰 작업 - 모델은 GitLab 인스턴스에서 직접 선택할 수 있다. - 모델이 달라도 GitLab Duo Agent Platform의 컨텍스트 계층, 정책 검사, 감사 추적 인프라는 동일하게 적용된다. ## GitLab Duo Agent Platform에서의 이용 - Claude Opus 5는 GitLab Duo Agent Platform에서 사용할 수 있으며 GitLab Credits로 과금된다. - 신규 사용자는 무료 체험을 시작할 수 있다. - GitLab Premium 또는 Ultimate 구독자는 포함된 GitLab Credits를 활용해 Duo Agent Platform을 활성화할 수 있다. 복잡하고 실패 비용이 큰 작업에는 Opus 5를 우선 적용하고, 반복적인 일상 개발에는 Sonnet 계열을 사용하는 혼합 전략이 가장 실용적이다. 다만 제시된 성능 수치는 GitLab의 내부 평가 결과이므로, 실제 도입 전에는 팀의 코드베이스와 작업 유형을 기준으로 별도 검증하는 것이 좋다.

ai-agentcode-reviewrefactoringgitlab-duo-agent-platform+4

gitlab2026년 7월 20일

GitLab Transcend 해커톤: 개발자들이 GitLab Orbit에서 만든 것 (새 탭에서 열림)

GitLab Orbit 해커톤은 코드·머지 리퀘스트·파이프라인·배포·소유권을 연결한 실시간 코드 그래프가 AI 에이전트의 시스템 이해 문제를 해결할 수 있음을 보여줬다. 1,576명이 참가해 265개 프로젝트를 만들었고, 참가자들은 변경 영향 분석, 테스트 최적화, 마이그레이션 비용 산정, 보안 취약점 추적 같은 반복적인 실무 문제에 집중했다. 특히 에이전트의 실행 속도뿐 아니라 근거와 책임성을 확보하는 것이 중요하다는 점이 강조됐다. ## GitLab Orbit와 해커톤 규모 - GitLab Orbit는 다음 정보를 관계형 그래프로 연결하고 최신 상태로 유지한다. - 소스 코드와 의존성 - 머지 리퀘스트 - CI 파이프라인 - 배포 정보 - 팀과 코드 소유권 - AI 에이전트는 코드 작성에는 강하지만, 변경 사항이 시스템 전체에 미치는 영향 파악에는 취약하다. - Orbit를 사용하면 “무엇이 이 변경에 의존하는가”, “어떤 테스트가 영향을 받는가”, “문제 발생 시 담당 팀은 누구인가” 같은 질문을 단일 쿼리로 처리할 수 있다. - 해커톤에는 1,576명이 등록했고, 265개의 Showcase Track 프로젝트가 제출됐다. - 별도로 26명의 기여자가 Orbit 코드베이스에 61개의 개선 사항을 병합했다. ## 개발자들이 가장 많이 해결하려 한 문제 - 70개 팀이 변경 사항의 잠재적 영향 범위를 분석하는 도구를 만들었다. - 하위 호출자 - 영향받는 파이프라인 - 관련 팀과 소유자 - 30개 이상의 팀은 코드베이스 온보딩과 이해를 돕는 도구를 개발했다. - 그 밖에도 다음 문제가 주요 주제로 등장했다. - 장애의 근본 원인 분석 - 아키텍처 드리프트 탐지 - 불안정한 파이프라인 진단 - 여러 저장소에 걸친 CVE 추적 - 공통점은 기존에는 Git, CI, 배포 도구, 대시보드에 흩어진 정보를 사람이 직접 조합해야 했다는 점이다. - Orbit는 단순히 에이전트를 자동화하는 것이 아니라, 실행에 필요한 시스템 맥락과 통제 수단을 함께 제공한다. ## 시스템 통합과 자동화 ### Sankofa: 상황별 세 가지 에이전트 - 기술 구현 부문 우승작이다. - 사용자의 업무 상황에 따라 세 에이전트가 작동한다. - **Radar**: 머지 리퀘스트가 열리면 변경의 영향 범위와 관련 파이프라인, 담당 팀을 분석한다. - **Guide**: 이슈가 할당되면 작업 시작에 필요한 요약 보고서를 작성한다. - **Shield**: 보안 취약점이 발생하면 코드 그래프를 한 번 탐색해 취약점의 전파 경로를 추적한다. - 취약점의 영향을 여러 저장소와 의존성에 걸쳐 수동으로 추적하던 작업을 자동화했다. ### Stayed Shipped: AI 코드의 실제 운영 여부 추적 - AI 에이전트가 지난달 병합한 변경 중 실제 운영 환경에 남아 있는 비율을 확인한다. - 이후 시니어 개발자가 조용히 수정하거나 대체한 변경도 추적한다. - 기존 대시보드가 제공하지 못하는 “AI가 만든 코드가 실제로 살아남았는가”라는 지표를 제시한다. ## 마이그레이션 비용과 작업 계획 ### Carver: 레거시 마이그레이션 견적 - 디자인·사용성 부문 우승작이다. - 사용자가 원하는 마이그레이션을 입력하면 Orbit의 의존성 그래프를 분석해 다음을 산출한다. - 작업 단위 수 - 예상 기간 - 수행 순서 - 위험 요소 - 예시로 AngularJS에서 Angular로의 전환을 약 9주간의 인력 작업과 약 10달러의 생성 비용으로 추정한다. - 테스트되지 않은 핵심 서비스처럼 위험도가 높은 부분은 별도로 표시한다. - Orbit에서 실제 서비스를 찾지 못하면 임의의 수치를 만들지 않고 사용자에게 실제 코드 위치를 확인한다. ### Marshal: 조직 전체의 자율 마이그레이션 - 조직 단위 목표를 선언하면 영향받는 저장소를 찾고 작업 순서를 계획한다. - 작업을 여러 웨이브로 나누어 머지 리퀘스트를 생성하고, 대상 저장소가 누락되지 않았는지 확인한다. - Carver가 통제 가능한 견적과 설명에 집중한다면, Marshal은 최대한의 자율 실행을 지향한다. ## 영향 기반 테스트와 정밀한 리팩터링 ### CrossCut: 변경에 필요한 테스트만 실행 - 영향력 부문 우승작이다. - 머지 리퀘스트에서 변경된 심볼을 찾고, Orbit의 호출 그래프를 따라 실제로 영향을 받는 테스트를 계산한다. - 모델의 추측 없이 그래프 탐색만으로 테스트 파이프라인을 구성한다. - 대규모 또는 여러 저장소에 걸친 테스트 스위트에서 CI 실행량을 90% 이상 줄일 수 있다. ### OrbitWeaver: 의존성 순서를 반영한 리팩터링 - 벡터 유사도 검색이 아니라 정확한 영향 범위를 사용한다. - 영향을 받는 모든 파일을 매핑하고 의존성 순서에 따라 수정한다. - 단순한 의미적 유사성보다 실제 코드 그래프가 안전한 자동 리팩터링에 적합하다는 점을 보여준다. ## 시맨틱 웹과 에이전트 거버넌스 ### Transcend: Orbit 위에 새로운 추론 계층 구축 - 아이디어 품질 부문 우승작이다. - Orbit API를 단순히 호출하는 대신 OWL, SPARQL, RDF를 활용한 시맨틱 웹 기반 추론 엔진을 추가했다. - 기본 API만으로는 어려운 다음 작업을 수행한다. - 전이적 폐쇄 계산 - 코드베이스와 외부 지식 그래프의 조인 - 코드와 관련 논문, 저자, 발표 연도의 연결 - 예를 들어 코드베이스가 구현한 지식 그래프 임베딩 기법의 클래스명과 이를 뒷받침한 논문 정보를 함께 조회한다. ### Universal Agent OS: 에이전트의 책임성과 검증 - 에이전트 자체보다 에이전트를 통제하는 거버넌스 계층을 만든다. - 다음 절차를 강제한다. - 먼저 사용자 인터뷰 수행 - 코딩 전 계획 수립 - 의사결정 근거 보존 - 결과 검증 - AI가 작성하는 코드의 비중이 커질수록 빠른 실행보다 누가 어떤 근거로 결과를 승인했는지가 중요해진다는 문제의식을 담고 있다. ## Orbit 자체에 대한 커뮤니티 기여 - Contribute Track에서는 26명이 Orbit에 직접 61개의 머지 리퀘스트를 병합했다. - 주요 개선 내용은 다음과 같다. - C++20 concepts 지원 - Go 패키지 선언 지원 - Kotlin 코루틴 지원 - Ruby 람다 지원 - 온톨로지 수정 - CI에서 발생하던 SIGPIPE 버그 수정 - 첫 Orbit 쿼리 튜토리얼 작성 - `max_depth`와 `max_hops` 차이를 포함한 문서 정리 - 참가자들은 Orbit를 활용한 애플리케이션뿐 아니라 기반 플랫폼 자체도 개선했다. 실무에서는 AI 에이전트에 코드를 바로 작성하게 하기보다, 먼저 변경 영향 분석·관련 테스트 선택·소유 팀 확인·근거 기록을 Orbit로 연결하는 것이 효과적이다. 특히 대규모 저장소에서는 정확한 의존성 그래프가 CI 비용 절감과 안전한 리팩터링의 기반이 될 수 있다.

ai-agentmodel-context-protocolgitlab-orbitsparql+4

gitlab2026년 7월 20일

GitLab Duo로 작업 항목 할당 자동화 (새 탭에서 열림)

GitLab Duo Agent Platform의 새로운 **“Work item created” 트리거**는 작업 항목이 생성되는 즉시 플로우를 실행해 자동으로 분류하고 담당자를 배정한다. 이를 통해 사람이 일일이 팀원의 업무량과 가용성을 확인하던 과정을 없애고, 대규모 작업도 몇 초 안에 일관되게 라우팅할 수 있다. 예시에서는 GitLab Orbit과 두 개의 에이전트를 활용해 업무량이 가장 적은 팀원에게 새 이슈를 자동 배정했다. ## 수동 담당자 배정의 한계 - 새 이슈가 생성될 때마다 담당자가 팀원의 현재 업무량과 우선순위를 확인해야 한다. - 회의, 휴가, 휴식 시간 등으로 인해 배정이 지연될 수 있다. - 작업량이 증가하면 업무가 특정 팀원에게 몰리거나 초기 트리아지가 늦어진다. - 기존 GitLab Duo Flow는 멘션, 수동 할당, 리뷰어 지정 등 사람의 행동이 있어야 시작할 수 있었다. - 따라서 자동화된 배정 로직이 있어도 마지막 실행 단계는 수작업으로 남아 있었다. ## “Work item created” 트리거의 동작 - 프로젝트에서 새 작업 항목이 생성되는 순간 플로우를 자동 실행한다. - 별도의 멘션이나 UI 조작 없이 백그라운드에서 지속적으로 동작한다. - 조직이 정의한 조건에 따라 작업을 분류하고 적절한 담당자에게 라우팅한다. - 개발자는 반복적인 배정 업무보다 판단과 창의성이 필요한 작업에 집중할 수 있다. ## 자동화로 얻는 효과 - **즉각적인 트리아지:** 작업 생성 직후 배정이 시작된다. - **확장성:** 작업이 한 건이든 수백 건이든 담당자의 추가 개입 없이 처리한다. - **균형 잡힌 배정:** 팀원의 현재 미해결 작업 수와 가용성을 기준으로 배정할 수 있다. - **일관성:** 사람이 매번 판단하던 기준을 에이전트가 동일하게 적용한다. - **반복 업무 감소:** 팀 리드가 업무량을 확인하고 수동으로 라우팅하는 시간을 줄인다. ## 두 에이전트로 구성한 자동 배정 플로우 예시 프로젝트는 `Intra-account-transfers`이며, 플로우 이름은 `Work item assigner`다. - 프로젝트에서 “Work item created” 트리거를 활성화한다. - 첫 번째 에이전트는 GitLab Orbit을 사용해 조직 내 각 리소스의 미해결 작업 수를 조회한다. - 두 번째 에이전트는 업무량이 가장 적은 팀원을 식별하고 새 작업 항목의 담당자로 지정한다. - 배정 절차와 도구 사용 방법은 각 에이전트의 프롬프트에 정의된다. - 트리거가 플로우 전체를 실행하므로 별도의 수동 시작 작업이 필요하지 않다. ## 실행 과정과 결과 - 새 이슈를 생성하면 트리거가 즉시 `Work item assigner` 플로우를 실행한다. - 플로우 활동 로그에서 각 단계의 진행 상황을 확인할 수 있다. - 첫 번째 에이전트가 최상위 그룹 내 사용자의 미해결 작업 수를 집계한다. - 두 번째 에이전트가 가장 적은 업무량을 가진 팀원을 선택한다. - 예시에서는 William이 담당자로 선정되었고, 이슈에 자동으로 할당되었다. ## 확장 가능한 개선 방향 - **HR 또는 휴가 시스템 연동:** MCP를 통해 PTO 기간을 조회하고 휴가 중인 팀원을 배정 대상에서 제외할 수 있다. - **캘린더 연동:** 회의 일정과 실제 가용 시간을 확인해 더 정확한 담당자 배정이 가능하다. - 업무량뿐 아니라 전문 분야, 우선순위, 프로젝트 소속 등의 조건을 추가해 라우팅 기준을 고도화할 수 있다. ## 실용적인 결론 반복적인 이슈 배정이 병목이 되는 팀이라면 “Work item created” 트리거와 업무량 조회 에이전트를 결합하는 것이 효과적이다. 초기에는 미해결 작업 수처럼 단순하고 검증 가능한 기준으로 시작한 뒤, 휴가·캘린더·전문성 정보를 MCP로 추가하는 방식이 현실적이다.

ai-agentmodel-context-protocolworkflow-automationgitlab-duo-agent-platform+3

gitlab2026년 7월 16일

포레스터 컨설팅: GitLab Duo 에이전트 플랫폼, 400% 투자 수익률 달성 (새 탭에서 열림)

GitLab Duo Agent Platform 도입 기업은 3년간 400%의 투자수익률(ROI)과 750만 달러의 순현재가치(NPV)를 달성했으며, 투자금 회수 기간은 6개월 이내로 분석됐다. 효과는 단순한 코드 생성 속도 향상에 그치지 않고, 개발자 온보딩·코드 리뷰·보안 취약점 수정·대규모 마이그레이션 등 소프트웨어 생명주기 전반에서 나타났다. 다만 수치는 4개 기업의 경험을 바탕으로 구성한 가상 조직의 사례이므로 모든 기업에 동일하게 적용된다고 보기는 어렵다. ## 분석 대상과 투자 구조 - Forrester Consulting은 금융 서비스, 소프트웨어 개발, 엔터테인먼트, 보험 업계의 의사결정권자 4명을 인터뷰했다. - 인터뷰 결과를 바탕으로 다음과 같은 복합 조직을 구성했다. - 연 매출 30억 달러 - 직원 3,000명 - GitLab Duo Agent Platform 사용자 수가 3년간 150명에서 250명으로 증가 - 3년간 위험 조정 비용은 약 190만 달러였다. - 소비 크레딧: 130만 달러 - 구현 및 운영 관리: 58만 9,000달러 - 파일럿, 교육, 지원에 필요한 내부 인력 비용 포함 - 총 편익은 940만 달러로 산정됐다. - 투자 대비 수익률: 400% - 순현재가치: 750만 달러 - 투자금 회수 기간: 6개월 미만 ## 도입 전: 수작업과 전문 인력 의존 - 빌드, 코드 리뷰, 보안 작업이 수작업 중심으로 운영됐다. - 신규 개발자가 코드베이스나 사내 규칙을 이해하려면 선임 엔지니어의 직접적인 지원이 필요했다. - 보안 취약점 수정은 관련 지식과 맥락을 가진 소수의 전문가가 처리할 때까지 대기열에 쌓였다. - 개발자들은 코드를 작성하는 시간보다 코드 리뷰와 문제 해결에 더 많은 시간을 소모했다. - 비공식적인 지식 공유와 특정 인력에 대한 의존성이 전체 개발 흐름의 병목으로 작용했다. ## 개발자 온보딩과 코드 이해 가속 - 신규 개발자의 온보딩 시간이 80% 단축됐다. - IDE와 저장소에 통합된 에이전트형 채팅이 코드 구조, 프로젝트 규칙, 작업 맥락을 설명했다. - 신규 인력이 선임 개발자를 매번 호출하지 않고도 낯선 코드베이스를 스스로 탐색할 수 있었다. - 이 효과로 3년간 약 58만 2,000달러의 비용 절감이 발생한 것으로 추정됐다. ## 마이그레이션 기간 단축 - 온프레미스 GitLab에서 GitLab SaaS로 이전하는 대규모 마이그레이션을 수행했다. - 당초 8개월로 계획했던 작업이 2개월 만에 완료됐다. - 파이프라인 실패 원인을 진단하고 실시간으로 해결하는 데 GitLab Duo Agent Platform을 활용했다. - 전체 일정이 75% 단축됐으며, 인건비 약 15만 7,000달러를 절감했다. ## 보안 및 QA 대응 효율 향상 - 보안 엔지니어와 QA 엔지니어는 업무 시간의 약 40%를 절약했다. - 플랫폼이 오류와 취약점의 원인을 상황에 맞게 설명하고 수정 방안을 제안했다. - 이로 인해 문제 해결 과정에서 선임 엔지니어에게 의존하는 정도가 줄었다. - 3년간 약 130만 달러의 인건비 절감 효과가 산정됐다. - 취약점 대응이 대기열 중심의 처리에서 즉각적인 진단과 수정 방식으로 바뀌었다. ## 개발자 생산성과 배포 속도 향상 - 각 개발자는 주당 업무 시간의 약 20%를 기능 개발에 더 사용할 수 있게 됐다. - 에이전트형 채팅과 AI 에이전트가 다음 작업을 지원하거나 자동화했다. - 코드 리뷰 - 테스트 작성 및 실행 - 오류 분석 - 트러블슈팅 - 전체 개발자에게서 발생한 생산성 향상 효과는 약 740만 달러로 추정됐다. - 일부 기업에서는 수주가 걸리던 기능 릴리스가 수일 내 완료되는 사례도 보고됐다. - 연구는 코드 생성 자체보다, 생성된 코드가 리뷰·테스트·보안 검증·배포로 이어지는 전체 흐름의 개선이 더 큰 경제적 효과를 만든다고 설명한다. ## 정량화되지 않은 추가 효과 - 여러 AI 개발 도구를 GitLab 기반 플랫폼으로 통합해 중복 비용을 줄일 가능성이 있다. - 개발자 만족도와 업무 경험이 개선될 수 있다. - 팀 간 지식 공유가 쉬워져 특정 전문가에 대한 의존성이 낮아질 수 있다. - 이러한 효과는 이번 재무 모델에는 포함되지 않았다. ## 연구 결과를 해석할 때의 주의점 - 이 연구는 GitLab이 의뢰하고 Forrester Consulting이 수행했다. - 결과는 인터뷰한 기업들의 경험과 이를 바탕으로 만든 복합 조직에 근거한다. - Forrester는 다른 조직이 동일한 ROI를 얻을 것이라고 보장하지 않는다. - 따라서 실제 도입 시에는 사용자 수, 기존 도구 비용, 교육·운영 인력, 보안 프로세스, 개발 병목을 기준으로 별도 측정해야 한다. 기업이 에이전트형 개발 플랫폼을 검토할 때는 코드 생성량만 평가하기보다 온보딩 시간, 리뷰·테스트 소요 시간, 취약점 수정 시간, 배포 주기, 마이그레이션 기간을 함께 측정하는 것이 바람직하다. AI의 투자 효과는 개별 개발자의 속도보다 소프트웨어 전체 생명주기에 얼마나 깊게 통합되는지에 따라 커진다.

ai-agentdevsecopscode-reviewcontinuous-integration+3

gitlab2026년 7월 16일

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

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

ai-agentci-cdgitlab-duo-agent-platformagentic-workflows+3

gitlab2026년 7월 8일

AI 에이전트를 활용해 GitLab의 레이트 리미팅을 마이그레이션한 방법 (새 탭에서 열림)

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

ai-agentobservabilitygitlab-duo-agent-platformredis+4

gitlab2026년 6월 30일

GitLab의 Claude Sonnet 5: 더욱 안정적이고 효율적으로 (새 탭에서 열림)

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

ai-agentdevsecopsgitlab-duo-agent-platformai-gateway+2

gitlab2026년 6월 18일

거버넌스 및 운영을 위한 AI 카탈로그 업데이트 (새 탭에서 열림)

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

ai-agentgitlabci-cddevsecops+3

gitlab2026년 6월 18일

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와 보안 스캔을 사용하는 조직이라면 관련 설정을 검토할 만하다.

ai-agentgitlabci-cdyaml+4

gitlab2026년 6월 10일

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 방식과 정확도 및 비용을 비교해 검증하는 것이 좋다.

ai-agentmodel-context-protocolcontinuous-integrationgraph-database+3

gitlab2026년 6월 10일

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은 이를 하나의 통합 플랫폼으로 제공하려는 전략을 제시하고 있습니다.

ai-agentgitlabci-cdgit+4

gitlab2026년 6월 9일

미토스급 Claude Fable 5, GitLab Duo Agent Platform에 출시 (새 탭에서 열림)

Anthropic의 Claude Fable 5가 GitLab Duo Agent Platform에 추가되어 복잡한 작업을 장시간 자율적으로 수행하고, 첫 시도에서 더 정확한 결과를 내도록 지원한다. 멀티파일 리팩터링, 장애 분석, 인프라 코드 작성, 코드 리뷰 등에서 반복 작업과 사람의 감독 부담을 줄이는 것이 핵심이다. 이 모델은 2026년 6월 9일부터 모든 GitLab 요금제와 배포 방식에서 AI Gateway를 통해 제공된다. ## 첫 시도 정확도 향상 - 복잡하고 요구사항이 명확한 문제에서 한 번에 작동하는 구현을 완성할 가능성이 높아졌다. - GitLab Duo Agentic Chat에서 사용자와 모델 사이의 재질문·수정 횟수를 줄인다. - 특히 다음과 같은 반복 비용이 큰 작업에 효과적이다. - 여러 파일에 걸친 대규모 리팩터링 - 장애 및 인시던트 조사 - Infrastructure as Code 정의 - 기술 이미지, 웹 애플리케이션, 상세한 스크린샷을 이전 모델보다 정확하게 해석하며 더 적은 출력 토큰을 사용하는 경우도 있다. ## 장시간 자율 에이전트 실행 - Claude Fable 5의 가장 큰 변화는 장기 목표를 유지하는 자율성이다. - 수백만 토큰에 걸친 작업에서도 지시를 따르며, 여러 날 동안 진행되는 복합 작업을 수행할 수 있다. - 자체 검증 루프를 통해 오류를 찾아 수정하고, 작업이 제대로 진행되는지 확인한다. - 여러 저장소나 서비스로 나뉘는 병렬 작업에서 하위 에이전트를 안정적으로 실행하고 유지한다. - 기존에 사람이 중간 점검하거나 프롬프트를 다시 입력해야 했던 Duo 에이전트 작업을 끝까지 진행할 수 있다. - 결과적으로 팀은 에이전트 실행마다 투입해야 하는 감독 비용을 줄이고, 비동기적으로 결과를 검토할 수 있다. ## 코드 리뷰와 장애 대응 개선 - 버그 탐지 재현율이 향상되어 이전 모델이 놓치던 문제를 더 많이 발견한다. - 코드 경로를 더 깊게 분석하고, 예외 상황과 엣지 케이스를 일관되게 식별한다. - GitLab Merge Request 리뷰에서 일반적인 지적보다 실행 가능한 코드 리뷰 의견을 제공한다. - CI/CD를 운영하는 플랫폼 엔지니어에게는 다음과 같은 효과가 기대된다. - 결함이 운영 환경에 배포되기 전 발견 - 장애 원인 분석 시간 단축 - 평균 복구 시간(MTTR) 감소 - 저장소 이력과 변경 맥락을 활용한 정밀한 인시던트 조사 ## 어려운 문제에 활용하는 전략 - 단순 반복 업무만 테스트하면 모델의 장기 자율성과 문제 해결 능력을 충분히 확인하기 어렵다. - 이전 AI 모델로는 처리하기 어렵다고 판단했던 문제를 맡기는 것이 권장된다. - 에이전트가 작업 범위를 정하고, 필요한 경우 명확화 질문을 한 뒤 실행하도록 할 수 있다. - 활용 사례로는 다음이 제시된다. - 복잡한 멀티파일 리팩터링 - 저장소 이력을 포함한 운영 장애 조사 - AI가 정확히 처리할지 확신하기 어려워 직접 작성하던 기능 구현 ## 제공 범위 - Claude Fable 5는 2026년 6월 9일부터 GitLab Duo Agent Platform에서 제공된다. - 모든 GitLab 요금제와 배포 모델에서 GitLab AI Gateway를 통해 사용할 수 있다. - 무료 사용자는 Duo Agent Platform 무료 체험을 시작할 수 있다. - GitLab Premium 또는 Ultimate 가입자는 포함된 GitLab Credits를 사용해 Duo Agent Platform을 활성화할 수 있다. 실제로 도입할 때는 단순 코드 생성보다 장애 분석, 대규모 리팩터링, 복잡한 CI/CD 개선처럼 장시간 추론과 여러 단계의 검증이 필요한 업무부터 시험하는 것이 효과적이다. પરિણામ물은 비동기 검토가 가능하더라도 운영 배포 전에는 기존 코드 리뷰와 테스트 절차를 유지하는 것이 바람직하다.

ai-agentci-cddevsecopscode-review+4

gitlab2026년 5월 21일

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`로 재현 가능한 개발 환경을 제공하는 것이 중요합니다. 자동화 결과를 그대로 병합하기보다는 에이전트가 남긴 변경 내용과 충돌 해결 근거를 리뷰하는 방식으로 도입하는 것이 안전합니다.

ai-agentgitlabdevsecopsgit+4

gitlab2026년 5월 18일

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 여부만 확인하지 말고, 비대화형 실행에서도 권한 제한, 승인 정책, 프롬프트 인젝션 방어, 감사 추적이 일관되게 작동하는지 검증해야 한다. 특히 사람이 지켜보지 않는 환경에서도 동일한 보안 모델이 유지되는지가 핵심 평가 기준이다.

ai-agentci-cddevsecopsgovernance+3

gitlab2026년 5월 18일

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

ai-agentgitlabci-cdrust+3