GitLab/모델 컨텍스트 프로토콜

12 개의 포스트

gitlab4분 읽기큐레이션 요약

Claude와 GitLab으로 모든 커밋을 프로덕션까지 안전하게 배포하세요

Claude은 코딩 세션 중 취약점을 발견하고 수정하는 데 유용하지만, 커밋 이후의 병합·의존성·인프라 변경·감사까지 대체할 수는 없다. 글은 Claude Security와 GitLab을 연계해 작성 단계부터 프로덕션 배포까지 보안 검사를 지속하고, 정책을 강제하며, 감사 증거를 자동으로 남기는 방식을 제안한다. Claude가 작성 시점을 담당하고 GitLab이 이후 전체 소프트웨어 공급망을 관리하는 구조다. ## 세션 내 보안 점검에서 강제 가능한 정책으로 - Claude 보안 가이던스 플러그인은 개발자의 코딩 세션 안에서 취약점을 빠르게 찾아 수정하도록 돕는다. - 코드가 세션 밖으로 나간 뒤에는 보안팀이 어떤 검사가 수행됐는지 확인하고 후속 작업을 통제해야 한다. - GitLab 보안 구성 프로필을 사용하면 저장소 외부에서 필요한 스캔을 정의하고 여러 프로젝트와 파이프라인에 일괄 적용할 수 있다. - 병합 요청 승인 정책으로 변경을 작성한 에이전트나 해당 에이전트를 사용한 개발자가 자신의 코드를 직접 승인·병합하지 못하게 할 수 있다. - 해결되지 않은 치명적 취약점이 있는 병합 요청은 지정된 승인자가 승인할 때까지 차단된다. - 취약점 보고서와 보안 대시보드에서 각 취약점이 발견·무시·해결된 상태와 사유를 추적할 수 있다. ## 자동화된 감사 증거와 변경 이력 - SOC 2, PCI DSS, FedRAMP 같은 규정은 에이전트가 작성한 변경도 테스트·검토·승인됐다는 증거를 요구한다. - GitLab은 모든 병합 요청에서 스캔이 실행되도록 보장하고, 결과를 병합 요청과 취약점 보고서에 표시한다. - 파이프라인 로그, 승인 기록, 감사 이벤트를 통해 어떤 변경을 누가 또는 어떤 에이전트가 처리했는지 재현할 수 있다. - 규정 프레임워크별 요구사항에 보안 통제를 매핑할 수 있으며, 각 통제의 통과·대기·실패 상태를 보고서에서 확인할 수 있다. ## 모델로 전송되는 민감 데이터 통제 - 컨텍스트 제외 기능으로 인증 정보, 민감한 파일, 독점 로직, 규제 데이터를 모델에 보내지 않도록 설정할 수 있다. - 자체 관리 환경과 자체 호스팅 모델을 사용하면 코드와 추론 데이터를 조직 경계 안에 둘 수 있다. - 흐름별 허용 모델을 지정하고, 코드가 모델 학습에 사용되지 않도록 제한할 수 있다. - GitLab Duo의 프롬프트 가드레일은 모델에 전달되기 전 코드 제안에서 비밀정보를 탐지한다. - 프롬프트가 접근할 수 있는 콘텐츠를 제한해 프롬프트 인젝션 위험도 줄인다. ## 세션 단위 검사를 넘어선 전체 생명주기 보안 - 세션 기반 검사는 해당 시점의 코드만 다루므로, 이후 공개되는 의존성 취약점이나 이미 커밋된 비밀정보까지 발견하지 못할 수 있다. - GitLab은 다음 영역을 독립적으로 검사한다. - 의존성 취약점 - 컨테이너 이미지 - 인프라스트럭처 코드 - 비밀정보 유출 - 실행 중 애플리케이션에 대한 DAST - 결정론적 스캐너는 동일 코드에 대해 일관된 결과와 CWE 매핑을 제공해 감사에 적합하다. - 반면 비즈니스 로직 오류, 잘못된 권한 검사, 경쟁 조건처럼 일반 스캐너가 놓치기 쉬운 문제는 Security Review Flow가 코드의 의도를 분석해 보완한다. - 글은 Claude의 보안 검사를 인간 코드 리뷰와 다양한 보안 스캐너를 대체하는 수단이 아니라 보조 수단으로 규정한다. ## 사람과 에이전트에 동일한 보안 가드레일 적용 - Claude 플러그인은 Claude가 세션에서 작성·커밋한 코드에 집중한다. - 개발자가 셸에서 직접 작성하거나 세션 내 `!` 셸 이스케이프를 통해 실행한 변경은 플러그인 검토 범위를 벗어날 수 있다. - Claude Security는 개발자나 관리자가 필요할 때 전체 코드베이스 또는 사람이 작성한 코드도 검사할 수 있다. - GitLab의 스캔 실행 정책과 병합 승인 정책은 파이프라인에서 모든 변경에 적용된다. - 따라서 코드 작성자가 사람인지 에이전트인지, 개발자가 별도로 검사를 실행했는지에 관계없이 동일한 통제를 적용할 수 있다. ## 프로덕션에 도달하는 변경 통제 - Claude Security와 GitLab MCP 서버를 연결하면 기존 Claude 기반 개발 흐름을 유지하면서 GitLab의 정책·스캔·감사 기능을 활용할 수 있다. - 모든 기본 브랜치와 대상 프로젝트에 보안 스캔을 강제해 정책 우회를 어렵게 만든다. - 치명적 취약점, 미승인 변경, 누락된 검사 결과가 있는 코드는 배포 전에 차단할 수 있다. - 결과적으로 세션 안의 빠른 AI 보안 지원과 프로덕션 배포 전의 조직 차원 거버넌스를 하나의 흐름으로 결합한다. 실무에서는 Claude를 개발 중 취약점 탐지와 수정에 활용하되, GitLab에서 SAST·의존성·컨테이너·IaC·비밀정보·DAST 스캔과 승인 정책을 중앙 관리하는 구성이 권장된다. 특히 모델에 전송되는 파일을 사전에 제외하고, 에이전트와 사람 모두에게 동일한 승인·감사 규칙을 적용해야 한다.

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

에이전트형 AI, MCP 및 AI 코딩 어시스턴스를 어떻게 거버넌스할 것인가

에이전틱 AI는 코드 제안만 하는 보조 도구와 달리, 도구 호출·설정 변경·머지 리퀘스트 생성·배포까지 수행할 수 있어 기존의 인간 중심 검토 방식만으로는 충분히 통제하기 어렵다. 따라서 조직은 모델 성능보다 에이전트의 신원, 권한 범위, 데이터 접근, 실행 기록을 관리하는 거버넌스 체계를 먼저 마련해야 한다. 핵심은 모든 작업을 막는 것이 아니라, 자율 실행과 인간 승인이 필요한 경계를 명확히 정하고 사후 감사가 가능하도록 만드는 것이다. ## 에이전틱 AI에 별도 거버넌스가 필요한 이유 - 기존 AI 코드 자동완성은 개발자가 제안을 보고 승인하거나 거부하므로, 모든 코드에 인간 검토가 개입한다. - 에이전틱 AI는 테스트 실행, CI/CD 설정 변경, 파일 작성·삭제, 코드 푸시 등 여러 단계를 연속적으로 수행할 수 있다. - MCP(Model Context Protocol)를 사용하면 에이전트가 외부 도구와 데이터에 연결되므로 접근 권한과 실행 범위가 더욱 중요해진다. - 거버넌스의 핵심 질문은 다음과 같다. - 에이전트가 무엇에 접근할 수 있는가? - 어떤 작업을 수행하도록 승인되었는가? - 실제로 어떤 작업을 했으며, 이를 사후에 증명할 수 있는가? - 조사 결과에서도 AI 코드의 장기 유지보수와 기술 부채 증가가 주요 우려로 나타났다. - 개발자·기술 리더의 73%가 AI 생성 코드의 장기 유지보수를 우려했다. - 86%는 명확한 거버넌스가 없으면 기술 부채가 기존 개발 방식보다 빠르게 누적될 수 있다고 답했다. - DevSecOps 전문가의 92%는 AI 생성 코드와 관련된 거버넌스 문제를 경험했다. ## MCP와 에이전트 권한 통제 에이전트가 외부 도구를 호출할 수 있게 되면 권한 관리가 가장 중요한 통제 지점이 된다. - 에이전트와 작업 흐름의 중앙 카탈로그를 운영한다. - 팀마다 임의로 통합 기능을 만들게 하지 않고, 관리자가 승인된 에이전트와 플로우만 조직에 배포한다. - 기존 역할·그룹 구조와 연계해 프로젝트별 사용 범위를 관리한다. - 복합 신원(composite identity)을 사용한다. - 에이전트의 활동을 에이전트 자체의 작업으로만 기록하지 않고, 작업을 요청한 인간 사용자와 연결한다. - 리소스 접근 시 에이전트와 요청 사용자 모두 인증·인가되어야 한다. - 도구별 승인 정책을 설정한다. - 안전한 도구는 자율 실행을 허용한다. - 파일 작성, 리소스 삭제처럼 민감한 작업은 인간 승인 후 실행되도록 한다. - 위험한 도구는 아예 차단할 수 있어야 한다. - 프롬프트 가드레일을 마련한다. - 웹페이지, 이슈 댓글, 외부 파일 등 신뢰할 수 없는 입력이 에이전트의 행동을 조작하는 프롬프트 인젝션을 탐지한다. - 단순히 실행 결과를 기록하는 것을 넘어, 공격 시도를 실행 전에 차단해야 한다. 이러한 통제는 인간 사용자에게 적용하는 역할 기반·감사 가능·일관된 권한 모델과 동일한 수준으로 에이전트에도 적용되어야 한다. ## 데이터 privacy와 자체 호스팅 소스 코드를 외부 AI 서비스에 제공할 때는 데이터 처리와 소유권을 명확히 확인해야 한다. - 공급자가 고객 코드를 모델 학습에 사용하는지 확인한다. - 입력 데이터와 AI가 생성한 출력의 소유권을 확인한다. - 하위 처리자(subprocessor)의 위치와 목록 변경 통지 정책을 검토한다. - 규제 산업에서는 데이터가 조직 외부 인프라로 나가지 않아야 할 수 있으므로 자체 호스팅이 중요한 통제 수단이 된다. - 자체 호스팅을 사용하면 다음을 함께 달성할 수 있다. - 조직이 통제하는 인프라에서 에이전트 실행 - 팀별 사용량과 활동 추적 - 규제기관의 데이터 보관·처리 요구 충족 - BYOM(Bring Your Own Model)을 활용하면 내부 검증을 마친 모델을 연결하고, 특정 에이전트 플로우에만 지정할 수 있다. - 민감한 작업은 신뢰할 수 있는 자체 모델에 고정한다. - 상대적으로 덜 민감한 작업은 관리형 모델을 사용할 수 있다. ## 인간 검토가 필요한 지점 정의 거버넌스는 에이전트의 자율 실행을 전면 금지하는 것이 아니라, 자율성이 끝나고 인간 검토가 시작되는 지점을 결정하는 것이다. - 대화형 작업 - 개발자가 실시간으로 제안을 확인하고 승인·거부한다. - 일반적인 AI 코드 자동완성에 가까운 방식이다. - 자동화·헤드리스 작업 - CI/CD 파이프라인에서 개발자의 실시간 관찰 없이 에이전트가 실행된다. - 실행 전에 도구 승인 절차를 거치거나, 실행 직후 감사 로그를 통해 사람이 검토해야 한다. ### 검토 지점별 통제 방식 - 코드 리뷰 - 에이전트가 생성한 머지 리퀘스트라도 일반 코드와 동일하게 승인 정책을 적용한다. - 지정된 담당자의 승인이 없으면 병합되지 않도록 한다. - 테스트와 검증 - 필수 테스트, 보안 스캔, 품질 검사를 통과해야 다음 단계로 진행하도록 파이프라인에서 강제한다. - 배포 - 운영 배포처럼 영향이 큰 작업은 명시적인 인간 승인을 요구한다. - 도구 실행 - 도구별로 자율 실행, 승인 대기, 실행 차단 중 하나를 지정한다. - 조직 정책 - 팀별 관행에 맡기지 말고 조직 전체의 AI 사용·승인·감사 정책으로 표준화해야 한다. - 이렇게 해야 사용 방식이 일관되고, 감사 담당자가 AI 활용 과정을 검증할 수 있다. ## 실용적인 적용 방향 조직은 에이전트 도입 전에 승인된 에이전트 목록과 모델 목록을 만들고, 사용자·에이전트의 복합 신원, 프로젝트별 권한, 도구별 승인 정책, 데이터 처리 위치를 정의해야 한다. 이후 머지 승인, 보안 스캔, 배포 승인 같은 기존 개발 통제 지점을 에이전트 작업에도 동일하게 적용하고, 모든 실행을 추적 가능한 감사 로그로 남기는 것이 바람직하다.

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

Cursor와 GitLab으로 Java 현대화하기

Java 8에서 21로의 현대화는 단순한 버전 업그레이드가 아니라 빌드·런타임·의존성·API·동시성·테스트·컨테이너·운영 동작을 함께 다루는 복합 작업이다. 따라서 Cursor로 모든 변경을 한 번에 수행하기보다, 작은 문제를 단계적으로 해결하고 GitLab의 이슈 계층, CI/CD, 보안 검사, 코드 리뷰, 영향 분석으로 안전성을 검증해야 한다. 글은 실패한 테스트 수정에서 시작해 품질 게이트를 마련하고, 특정 HTTP 연결 경계를 Java 21 방식으로 현대화하는 흐름을 제시한다. ## Cursor와 GitLab의 역할 분담 - Cursor는 코드베이스 안에서 다음과 같은 집중 작업에 적합하다. - 실패한 테스트의 원인 추적 - 구현 코드와 테스트 분석 - 제한된 범위의 수정안 작성 - 로컬 테스트 실행 - 브랜치와 머지 리퀘스트 생성 - GitLab은 AI가 만든 변경을 소프트웨어 개발 생명주기 안에서 검증하는 역할을 한다. - Epic과 하위 이슈로 현대화 계획을 지속적이고 검토 가능하게 관리 - GitLab MCP 서버로 이슈, 논의, 파이프라인, 의존성 등 프로젝트 문맥을 Cursor에 제공 - CI/CD, 보안 스캔, 코드 리뷰, 코드 소유자 승인, 영향 분석 수행 - Duo Agent Platform의 Code Review Flow와 Developer Flow로 프로젝트별 품질 기준 적용 - AI 에이전트의 속도 자체가 안전성을 보장하지 않으므로, 모든 에이전트 생성 머지 리퀘스트도 일반 변경과 동일한 검증 절차를 거쳐야 한다. ## 예제 시스템과 현대화 범위 - 대상은 Tanuki IoT Platform의 Java HTTP metrics collector다. - 이 컴포넌트는 다음 작업을 수행한다. - 상태 점검 및 유지보수 HTTP 엔드포인트에 `GET` 요청 - 응답 상태와 응답 시간 등의 메트릭 기록 - Rust 기반 metrics-store 백엔드에 `POST /api/metrics` 요청 - 백엔드의 HTTP 응답을 확인 - Java 애플리케이션과 Rust 백엔드 사이의 실제 HTTP 계약이 존재하므로, Java 런타임 현대화가 운영 경계에 미치는 영향을 테스트할 수 있다. - 환경에는 Java 8과 Java 21, Maven, Docker, Docker Compose, GitLab MCP 서버가 필요하다. - 저장소의 `AGENTS.md`에는 프로젝트 구조와 Maven 테스트 명령이 있어 Cursor가 로컬 개발 규칙을 따르는 데 활용된다. ## 실패한 엔드투엔드 테스트 수정 - 문제는 엔드포인트의 기대 HTTP 상태 코드 처리에서 발생한다. - 사용자는 특정 상태 코드를 기대하도록 설정할 수 있다. - 구현은 모든 `2xx` 응답만 성공으로 간주한다. - 따라서 `503`을 정상적인 기대값으로 설정해도 테스트가 실패한다. - 엔드투엔드 테스트는 이미 문제를 드러내고 있었지만 CI/CD 작업이 `allow_failure` 상태여서 실패가 지속적인 경고음으로만 남아 있었다. - Cursor에는 관찰 가능한 문제를 직접 설명하고 다음 순서로 작업하도록 요청한다. - 먼저 분석 작성 - 구현과 실패 테스트 추적 - 수정 적용 - 테스트 재실행 - Cursor는 엔드포인트 설정에서 `HttpCollector`와 실패한 엔드투엔드 테스트까지 경로를 추적해 불일치의 원인을 찾는다. - 집중 테스트와 전체 Maven 테스트가 통과한 뒤 브랜치와 머지 리퀘스트를 만든다. - 테스트가 결정적이고 안정적으로 통과하면, 기존에 실패를 허용하던 엔드투엔드 작업을 필수 검증 단계로 전환할 수 있다. ## 머지 리퀘스트 기반 검증 - 머지 리퀘스트 생성 후 자동으로 다음 검증이 실행된다. - 빌드 - 단위 및 통합 테스트 - 엔드투엔드 테스트 - 보안 스캔 - GitLab Duo Code Review는 프로젝트의 Java 전용 리뷰 지침에 따라 변경을 검토한다. - 리뷰에서 구체적인 문제가 발견되면 Developer Flow를 통해 수정한 뒤 병합한다. - 머지 리퀘스트는 단순한 결과물 제출 수단이 아니라 다음을 수행하는 협업·의사결정 공간이다. - 변경 의도 설명 - 테스트 및 파이프라인 결과 확인 - 리뷰 의견 처리 - 에이전트가 만든 코드의 품질 증거 축적 - 이 단계에서 실제 버그를 런타임 마이그레이션과 섞지 않고 먼저 수정함으로써, 이후 현대화 작업의 행동 기준선과 회귀 방지 테스트를 확보한다. ## Java 8에서 Java 21로 넘어가기 위한 품질 게이트 - Java 21 현대화는 앞선 테스트 버그 수정과 달리 훨씬 넓은 범위를 가진다. - 기존 Java modernization epic에는 다음과 같은 계획 문맥이 포함되어 있다. - 하위 작업 항목 - 팀 논의 - 조사 결과와 관련 머지 리퀘스트 - 과거 파이프라인 기록 - 의존성 정보 - 보안 취약점 및 관련 발견 사항 - 이러한 정보를 Cursor에 제공하면 단순히 소스 코드를 바꾸는 것이 아니라 프로젝트의 개발 이력과 운영 제약을 반영한 변경 계획을 세울 수 있다. - 글의 접근 방식은 전체 마이그레이션을 한 번에 수행하지 않고, 먼저 품질 게이트를 마련한 뒤 영향 범위가 명확한 경계부터 현대화하는 것이다. ## 실용적인 적용 순서 - 먼저 하나의 실패한 테스트나 제한된 버그를 선택한다. - Cursor로 원인 분석, 수정, 테스트 실행을 수행한다. - 변경을 작은 머지 리퀘스트로 제출하고 CI/CD와 자동 리뷰를 통과시킨다. - 그다음 Epic과 이슈, MCP를 통해 Java 21 마이그레이션의 전체 문맥을 연결한다. - 모든 테스트, 보안 검사, 코드 소유자 승인, 영향 분석 결과를 품질 게이트로 사용한다. - 마지막으로 HTTP 연결 처리처럼 하나의 경계를 골라 현대화하고, Java 애플리케이션과 Rust 백엔드 사이의 실제 계약이 유지되는지 검증하는 것이 안전하다.

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

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 비용 절감과 안전한 리팩터링의 기반이 될 수 있다.

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

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로 추가하는 방식이 현실적이다.

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

GitLab 19.2 릴리스 노트 | GitLab Docs

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

원문 읽기(새 탭에서 열림)
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 구성을 점검한 후 단계적으로 배포할 수 있다.

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

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

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

원문 읽기(새 탭에서 열림)
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 방식과 정확도 및 비용을 비교해 검증하는 것이 좋다.

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

에이전트 코딩은 컨텍스트만큼만 훌륭하다

코딩 에이전트의 성능과 신뢰성은 코드 작성 능력보다 프로젝트 생명주기 전반의 맥락을 얼마나 활용하느냐에 달려 있다. 저장소만 보는 에이전트는 컴파일되는 코드를 만들 수 있지만, 이슈 요구사항·CI 규칙·보안 정책·리뷰 기준까지 반영하기 어렵다. GitLab처럼 이슈, 파이프라인, 보안 스캔, 머지 리퀘스트를 연결하면 에이전트가 조직의 가드레일 안에서 작업하고, 리뷰 라운드와 머지까지 걸리는 시간을 줄일 수 있다. ## 저장소만 보는 에이전트의 한계 - 에이전트는 로컬 파일과 사용자가 입력한 프롬프트를 기반으로 코드를 수정하고 빌드를 실행한다. - 코드가 컴파일되더라도 다음 정보를 알지 못할 수 있다. - 이슈의 인수 조건과 구현 메모 - 비기능 요구사항 - CI 설정에 정의된 린터·테스트·품질 기준 - 조직의 코드 리뷰 규칙과 보안 정책 - 결과적으로 “동작하는 코드”와 “팀이 실제로 요구한 변경” 사이에 차이가 생긴다. - 이슈 링크 누락, 새로 추가된 린터 규칙 위반, 승인되지 않은 의존성 추가 같은 재작업이 발생할 수 있다. ## GitLab 이슈를 연결했을 때의 변화 - GitLab MCP 서버를 연결하면 에이전트가 코딩 전에 관련 이슈를 조회할 수 있다. - 이슈의 요구사항, 구현 메모, 라벨, 마일스톤을 확인해 계획에 맞는 수정이 가능해진다. - 예를 들어 Codex는 머지 리퀘스트 설명에 `Closes #32`를 추가해 코드 변경과 이슈의 관계를 명시한다. - Claude Code는 `get_issue`로 버그 리포트를 가져오고, `create_merge_request`로 적절한 참조가 포함된 MR을 생성한다. - 즉, 에이전트의 작업이 단순한 코드 수정에서 프로젝트 계획과 연결된 변경으로 확장된다. ## 머지 리퀘스트 안에서 수행하는 리뷰와 수정 - MR이 생성되면 GitLab의 Code Review Flow가 자동으로 리뷰 피드백을 게시한다. - 에이전트는 MR 내부의 외부 에이전트로 호출되어 다음과 같은 후속 작업을 수행할 수 있다. - 누락된 테스트 추가 - 문서 주석 보완 - 리뷰에서 발견된 검증 로직의 공백 수정 - 수정 사항은 MR 브랜치에 직접 커밋된다. - 새 커밋마다 CI/CD 파이프라인이 자동 실행되므로, 에이전트의 수정 결과를 즉시 검증할 수 있다. - 사람은 다른 도구로 전환하지 않고 MR에서 변경 내용과 파이프라인 결과를 검토한다. - 이 흐름은 리뷰 반복 횟수와 머지까지 걸리는 시간을 줄이는 데 기여한다. ## 플랫폼 전체 맥락과 조직의 가드레일 - 플랫폼 팀은 조직 내 AI 개발 방식에 대해 다음을 결정한다. - 허용할 에이전트 - 에이전트가 접근할 수 있는 도구와 데이터 - 결과물을 검증하는 방법 - 사람의 승인과 판단이 필요한 지점 - DevSecOps 플랫폼에는 에이전트가 필요로 하는 생명주기 정보가 모여 있다. - 이슈 트래커: 요구사항과 우선순위 - CI/CD 설정: 품질 기준과 자동 검증 - 코드 리뷰 지침: 스타일과 개발 표준 - 보안 스캐너: 취약점 정책 - MR: 자동화와 최종적인 사람의 승인 - IDE나 터미널 기반 에이전트가 아무리 뛰어나도 제공된 파일 중심으로만 판단한다. - 반면 플랫폼은 이슈부터 파이프라인, 보안 정책, 배포 대상, 승인 규칙까지 전체 흐름을 볼 수 있다. - 따라서 안전하게 배포되는 결과물은 에이전트 자체의 능력뿐 아니라 플랫폼이 제공하는 가시성과 통제에 좌우된다. ## AI가 코드를 더 많이 만들 때의 보안 영향 - 코드 생성 속도가 빨라지면 새 취약점, 보안 스캔 결과, 수정용 MR도 함께 증가한다. - 기존에는 보안팀이 취약점을 탐지·분류한 뒤 개발자에게 수정 요청을 보내고 기다리는 과정이 병목이었다. - 에이전트가 수정까지 빠르게 수행하면 병목은 “무엇을 고칠까”에서 “어떤 AI 생성 수정 MR을 먼저 사람이 승인할까”로 이동한다. - 우선순위를 정하려면 다음과 같은 전체 맥락이 필요하다. - 프로젝트 전체 코드 - 데이터 흐름 - 실제 배포 환경 - 조직에 적용되는 보안 정책 - 이런 맥락이 있으면 단순한 심각도 점수가 아니라 실제 환경에서의 노출 가능성을 기준으로 취약점을 우선순위화할 수 있다. - GitLab 보안 계층은 프로젝트 맥락을 활용해 오탐을 걸러내고 확인된 취약점을 식별한다. - 확인된 취약점에 대해서는 agentic SAST vulnerability resolution이 취약 코드와 주변 코드를 분석해 수정 MR을 자동 생성한다. - 이후 파이프라인이 수정 사항을 검증하고, 최종 머지 여부는 사람이 결정한다. - 즉, 에이전트가 수정 작업을 담당하더라도 승인과 거버넌스는 사람에게 남는다. ## `AGENTS.md`를 활용한 프로젝트별 지침 - 두 튜토리얼 모두 저장소에 `AGENTS.md` 파일을 두고 에이전트의 행동 지침으로 활용한다. - 이 파일에는 다음과 같은 내용이 포함될 수 있다. - 프로젝트 구조 - 실행해야 할 명령어 - 코드 품질 기준 - 수정해서는 안 되는 파일이나 영역 - Codex와 GitLab 튜토리얼에서는 Rust 에디션, 비동기 동시성 패턴, CI 이미지 고정 정책 등이 정의되어 있었다. - 이를 통해 에이전트가 매번 프롬프트로 설명받지 않아도 프로젝트의 기술적 규칙과 변경 범위를 일관되게 준수할 수 있다. 플랫폼 팀은 에이전트를 단독 코딩 도구로 도입하기보다 이슈·`AGENTS.md`·CI/CD·보안 스캔·MR 리뷰를 연결한 workflow 안에 배치하는 것이 좋다. 에이전트가 더 많은 작업을 자동화할수록 자동 검증은 강화하고, 최종 승인과 책임은 사람에게 남겨야 한다.

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

glab CLI로 AI 에이전트에 GitLab 직접 액세스 권한 부여하기 (새 탭에서 열림)

GitLab CLI(`glab`)를 MCP(Model Context Protocol)와 결합하면 AI 에이전트가 프로젝트 데이터에 직접적이고 구조적으로 접근할 수 있게 되어 개발 워크플로우의 효율성이 극대화됩니다. 이를 통해 개발자는 수동으로 정보를 복사하여 붙여넣는 번거로움을 없애고, 할루시네이션(환각) 없이 실시간 데이터에 기반한 정확한 코드 리뷰와 이슈 관리가 가능해집니다. 결과적으로 AI 에이전트는 단순한 조력자를 넘어 프로젝트의 상태를 직접 파악하고 작업을 수행하는 강력한 도구로 진화합니다. ### MCP를 통한 AI와 GitLab의 연결 * **개방형 표준 활용:** MCP는 AI 도구가 런타임에 외부 기능을 발견하고 사용할 수 있게 해주는 표준 프로토콜로, 이를 통해 AI 어시스턴트가 GitLab 이슈 읽기, MR 댓글 작성, 파이프라인 상태 확인 등을 직접 수행할 수 있습니다. * **간편한 서버 실행:** `glab mcp serve` 명령어를 실행하는 것만으로 MCP 서버를 구동하여 Claude Code, Cursor 등 다양한 AI 클라이언트와 연결할 수 있습니다. * **구조화된 JSON 데이터:** MCP를 통해 호출되는 모든 `glab` 명령은 자동으로 `--output json` 형식을 사용하여, AI 에이전트가 파싱하기 쉬운 깨끗하고 정제된 데이터를 제공합니다. * **안정성 확보:** 터미널의 대화형 입력이 필요한 명령은 제외하고 에이전트 환경에서 신뢰할 수 있게 작동하는 명령 위주로 노출하여 작업 중단 오류를 방지합니다. ### AI 기반 코드 리뷰 자동화 * **전체 컨텍스트 파악:** `glab mr view --comments --unresolved` 명령을 사용하면 MR의 메타데이터, 설명, 해결되지 않은 모든 토론 내용을 단일 JSON 페이로드로 가져와 AI에게 전달할 수 있습니다. * **효율적인 피드백 요약:** 사용자는 여러 탭을 오가는 대신 AI에게 "MR에서 해결해야 할 사항이 무엇인가?"라고 질문하여 우선순위가 지정된 요약과 제안된 변경 사항을 즉시 받을 수 있습니다. * **프로그래밍 방식의 처리:** AI가 피드백을 반영한 후 `glab mr note resolve` 명령을 직접 실행하여 토론을 해결 상태로 변경하는 등 코드 리뷰의 전 과정을 자동화된 루프 내에서 처리할 수 있습니다. ### 실시간 데이터 기반의 이슈 분석 및 디버깅 * **정확한 정보 제공:** 웹 UI에서 텍스트를 복사해 붙여넣는 방식은 정보가 누락되거나 왜곡될 위험이 크지만, `glab`은 이슈 번호, 마일스톤, 라벨 등의 속성을 정확한 구조로 제공합니다. * **훈련 데이터 한계 극복:** AI가 과거의 학습 데이터나 웹 스크래핑에 의존하지 않고, API를 통해 실시간 프로젝트 상태를 조회하므로 파이프라인 실패 원인 분석이나 이슈 분류 시 정확도가 비약적으로 향상됩니다. * **워크플로우 마찰 감소:** 에이전트가 직접 GitLab 데이터를 가져오고 보고하기 때문에 개발자는 정보 전달자 역할에서 벗어나 실제 문제 해결에 더 집중할 수 있습니다. 반복적인 코드 리뷰 분석이나 이슈 트리이징(Triage) 시간을 줄이고 싶다면 `glab` CLI를 MCP 서버로 활용해 보세요. 특히 Claude나 Cursor와 같은 최신 AI 도구를 사용 중이라면, `glab mcp serve`를 통해 AI 에이전트에게 GitLab 프로젝트에 대한 직접적인 실행력을 부여함으로써 진정한 자율 개발 환경을 구축할 수 있습니다.

gitlab원문

GitLab Duo 에이전 (새 탭에서 열림)

GitLab Duo Agent Platform이 MCP(Model Context Protocol)를 지원함에 따라, 이제 개발자들은 Jira와 같은 외부 도구를 AI 개발 환경에 직접 연결하여 사용할 수 있게 되었습니다. 이를 통해 IDE를 벗어나지 않고도 자연어 대화만으로 Jira 이슈를 조회, 생성 및 업데이트하며 프로젝트 관리와 코드 작성을 통합할 수 있습니다. 결과적으로 도구 간의 빈번한 맥락 전환(Context Switching)을 줄여 개발 생산성을 극대화하고 워크플로우를 단순화할 수 있는 강력한 환경을 제공합니다. ### MCP 연동 아키텍처 및 보안 설정 * GitLab Duo Agent Platform은 MCP 클라이언트 역할을 수행하며, Atlassian MCP 서버와 통신하여 Jira 데이터에 접근합니다. * 보안 인증을 위해 Atlassian 개발자 콘솔에서 OAuth 2.0 애플리케이션을 생성해야 하며, `read:jira-work`, `write:jira-work`, `read:jira-user`와 같은 구체적인 API 권한(Scope) 설정이 필요합니다. * 인증 과정에서 콜백 URL(`https://gitlab.com/oauth/callback`)을 등록하고 발급된 Client ID와 Secret을 안전하게 관리해야 합니다. ### GitLab Duo MCP 클라이언트 구성 및 검증 * 프로젝트의 `.gitlab/duo/mcp.json` 경로에 MCP 서버 설정 파일을 생성합니다. 이 파일에는 서버 URL과 앞서 발급받은 OAuth 인증 정보가 포함됩니다. * GitLab 그룹 설정의 'GitLab Duo' 메뉴에서 외부 MCP 도구 허용 옵션(`Allow external MCP tools`)을 활성화해야 정상적으로 작동합니다. * VS Code 내 'GitLab: Show MCP Dashboard' 기능을 통해 연결 상태를 모니터링할 수 있으며, `jira_get_issue`, `jira_create_issue` 등 사용 가능한 도구 목록과 실시간 서버 로그를 확인할 수 있습니다. ### 실무 적용을 위한 주요 활용 사례 * **기획 및 관리 보조:** "할당되지 않은 이슈 목록 보여줘", "우선순위가 높은 이슈 2개를 요약하고 나에게 할당해줘"와 같은 프롬프트를 통해 스프린트 계획을 IDE 내에서 즉시 처리할 수 있습니다. * **코드 맥락 기반 이슈 생성:** 코드 리뷰 중 버그를 발견했을 때, 별도의 브라우저 실행 없이 현재 코드의 맥락을 포함하여 Jira 티켓을 즉시 생성하고 관련 브랜치와 연결할 수 있습니다. * **워크플로우 자동화:** 자연어 요청을 통해 Jira의 복잡한 필드를 자동으로 채우거나, 코드 분석 결과에 따라 관련 블로커(Blocker)를 검색하는 등 지능적인 협업이 가능해집니다. 개발팀은 MCP를 활용해 Jira뿐만 아니라 MCP 규격을 지원하는 다양한 외부 도구를 GitLab Duo에 통합함으로써 커스텀 AI 에이전트 환경을 구축할 수 있습니다. 툴 간 전환 비용을 줄이고 개발 집중도를 높이고 싶다면, 가이드에 따라 `.gitlab/duo/mcp.json` 설정을 완료하고 첫 번째 MCP 워크플로우를 시작해 보시기 바랍니다.