gitlab2026년 7월 16일

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 기능을 조직 단위로 통제하는 것이 적합합니다.

yamlgitlabmodel-context-protocolvulnerability-management+4

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

yamlai-agentgitlabci-cd+4

github2026년 6월 9일

일회성 프롬프트에서 워크플로로: GitHub Copilot CLI에서 커스텀 에이전트를 사용하는 방법 (새 탭에서 열림)

GitHub Copilot CLI의 커스텀 에이전트는 반복적인 터미널 작업과 팀의 개발 규칙을 Markdown 기반 워크플로로 표준화하는 기능이다. 저장소에 에이전트 프로필을 두면 팀의 도구, 코딩·보안·접근성 기준, 출력 형식을 버전 관리하며 CLI·IDE·GitHub 전반에서 일관되게 사용할 수 있다. 따라서 일회성 프롬프트를 반복하는 대신 검토 가능하고 재사용 가능한 전문 에이전트를 구축할 수 있다. ## 커스텀 에이전트의 개념 - 커스텀 에이전트는 특정 작업에 특화된 Copilot 에이전트다. - Markdown 파일인 에이전트 프로필에 다음 내용을 정의한다. - 에이전트의 역할과 전문 영역 - 사용할 수 있는 도구 - 따라야 할 개발·보안·접근성 기준 - 실행 범위와 안전장치 - 결과물의 형식 - 일반적인 코드 정리 에이전트와 달리, 팀의 포맷 규칙·접근성 표준·리뷰 절차·보안 요구사항을 매번 동일하게 적용할 수 있다. - 프로필이 저장소에 포함되므로 코드처럼 리뷰·수정·공유·버전 관리가 가능하다. ## 에이전트 프로필 구성 프로필은 YAML frontmatter와 지침 본문으로 구성된다. - `name`: 에이전트 이름 - `description`: 에이전트의 목적과 역할 - `model`: 사용할 Copilot 모델 - `tools`: 코드베이스 검색, 파일 수정, 테스트 실행, 터미널, 웹 요청 등 허용할 도구 - 본문 지침: - 에이전트의 전문성 - 작업 절차 - 출력 형식 - 금지 사항과 안전 규칙 예를 들어 접근성 전문가 에이전트는 WCAG 2.1/2.2의 A·AA·AAA 등급을 기준으로 웹 UI를 검토하고, 디자인·개발·QA에 적용 가능한 실무 지침을 제공하도록 설정할 수 있다. ## GitHub Copilot CLI에서 사용하는 방법 - 터미널에서 GitHub Copilot CLI를 실행한다. - `/agent` 슬래시 명령을 사용해 원하는 커스텀 에이전트를 선택한다. - 대상 저장소의 `.github/agents` 디렉터리에 프로필을 만든다. - 파일 확장자는 `.agent.md`를 사용한다. 예: - `.github/agents/accessibility.agent.md` - `.github/agents/security-audit.agent.md` - CLI는 정의된 도구와 지침에 따라 스크립트 실행, API 호출, 저장소 분석 등을 반복 가능한 방식으로 수행한다. ## 자동화할 수 있는 보안 감사 글에서는 보안 점검을 대표적인 커스텀 에이전트 활용 사례로 제시한다. - 여러 저장소에서 팀의 표준 보안 도구를 실행한다. - `gitleaks`: 비밀·자격 증명 탐지 - `trivy`: 파일 시스템 및 컨테이너 취약점 검사 - `semgrep`: 정적 분석 - `gh`: GitHub 설정 및 의존성 검토 - `jq`, `git`: 결과 처리와 저장소 작업 - 결과를 `Critical`, `High`, `Medium`, `Low` 심각도로 분류한다. - 담당자와 다음 조치를 포함한 PR용 체크리스트로 출력한다. - 저장소에 이미 존재하는 설정 파일을 우선 사용한다. - `.semgrep.yml` - `.trivyignore` - `.gitleaks.toml` - 도구가 설치되지 않은 경우 결과를 추측하지 않고 “검사 범위의 공백”으로 기록한다. - 토큰이나 자격 증명 등 민감한 정보는 출력에서 마스킹한다. - `CODEOWNERS`가 없으면 경로별 기본 담당 팀을 매핑해 후속 조치를 명확히 한다. ## 커스텀 에이전트의 장점 - 반복 작업을 자동화해 명령어 재실행과 컨텍스트 재설명을 줄인다. - 팀 표준을 프롬프트가 아닌 저장소 파일로 관리할 수 있다. - 결과 형식과 품질 기준이 일관된다. - CLI에서 시작한 작업을 IDE와 GitHub의 리뷰·PR 흐름으로 자연스럽게 연결할 수 있다. - 에이전트 설정 자체를 코드 리뷰 대상으로 삼아 변경 이력과 책임 소재를 남길 수 있다. 반복적으로 수행하는 보안 검사, 접근성 검토, 테스트 실행, 로그 분석 같은 작업부터 `.github/agents`에 에이전트로 정의하는 것이 좋다. 특히 허용 도구, 민감 정보 처리, 실패 시 동작, 결과 형식을 명확히 작성하면 Copilot CLI를 단순한 명령어 생성기가 아니라 팀 표준을 실행하는 재사용 가능한 워크플로 엔진으로 활용할 수 있다.

yamlmarkdowngithub-copilot-clisast+4

toss2026년 6월 8일

Skill 품질 관리를 위한 Rubric 설계와 시스템 구현 (새 탭에서 열림)

Skill은 코딩 에이전트가 개발 과정에서 호출해 사용하는 문서형 도구이므로, 내용이 좋아도 호출되지 않으면 아무런 가치가 없다. 글은 Skill 품질을 6개 섹션 30개 항목으로 평가하고, 형식처럼 결정적으로 검증할 수 있는 항목은 규칙 기반으로, 호출 적합성처럼 의미 판단이 필요한 항목은 LLM 기반으로 분리해야 한다고 주장한다. 특히 BLOCKER가 하나라도 있으면 F 등급으로 처리해 Merge 차단 여부를 단순하게 판단하는 것이 핵심이다. ## Skill 평가가 어려운 이유 - Skill은 컴파일이나 테스트처럼 명확한 통과·실패 기준이 없다. - 결함이 있어도 호출되지 않거나, 호출돼도 효과가 없는 상태로 조용히 남을 수 있다. - 대표적인 문제는 다음 두 가지다. - **트리거 실패**: 호출 조건을 본문에 작성하고 `description`에는 적지 않아 에이전트가 Skill을 호출하지 못하는 문제 - **형식 위반**: `name`이 kebab-case가 아니거나, `name`과 폴더명이 달라 Skill 자체가 인식되지 않는 문제 ## 규칙 기반 검사와 모델 기반 검사의 분리 - 형식·구조처럼 결과가 명확한 항목은 정규식, 카운트, AST 파싱 등 결정적 도구로 검사한다. - 트리거의 의미나 설명의 충분성처럼 문맥 판단이 필요한 항목은 LLM이 평가한다. - 30개 평가 항목은 다음처럼 나뉜다. - 규칙 검사 17개 - 모델 검사 13개 - 역할을 섞으면 문제가 발생한다. - 결정적 결함을 LLM에 맡기면 애매한 상태를 통과시키는 False Negative가 생긴다. - 의미적 판단을 정규식으로 처리하면 표현의 다양성을 놓쳐 False Positive가 늘어난다. - 규칙 검사는 비용이 거의 없어 모든 PR에서 실행할 수 있고, LLM 검사는 규칙 검사를 통과한 Skill에만 적용해 비용을 줄인다. ## 6개 섹션 30개 항목의 평가 구조 - 각 항목은 `BLOCKER`, `MAJOR`, `MINOR` 심각도를 가진다. - 결과는 S부터 F까지 5단계 등급으로 표시한다. - `BLOCKER`가 하나라도 있으면 무조건 F다. - 세부 등급은 작성자에게 상태를 알려주는 신호로 사용하고, 실제 Merge 차단은 F 여부만으로 결정한다. - 이 방식은 등급의 미세한 차이를 두고 불필요하게 논쟁하는 일을 줄인다. ## 타당성: Skill이 정말 필요한가 - Skill을 만들 만한 가치가 있는지 평가한다. - 핵심 질문은 다음과 같다. - 반복적으로 발생하는 작업인가? - 코딩 에이전트가 일반적인 지시만으로 처리하기 어려운가? - Skill로 만들어 제공할 때 지속적인 이점이 있는가? - 일회성 작업이나 에이전트에게 그대로 시켜도 되는 작업은 Skill로 만들 필요가 없다. - 다른 섹션이 이미 만들어진 Skill의 품질을 점검한다면, 타당성 섹션은 애초에 만들지 말았어야 할 Skill을 걸러내는 역할을 한다. - 이 섹션에는 3개 항목이 있으며 모두 MAJOR 수준이다. ## 구조: 형식 오류를 결정적으로 차단 - 구조 섹션은 8개 항목으로 구성되며, 그중 5개가 BLOCKER다. - 예시로 다음을 검사한다. - frontmatter 존재 여부와 YAML 파싱 가능 여부 - `name`의 kebab-case 준수 여부 - `name`과 폴더명 일치 여부 - `description` 길이가 1~1024자 범위인지 여부 - 본문에 허용되지 않은 XML 태그가 포함됐는지 여부 - 구조 검사는 전부 규칙 기반으로 처리하며 LLM을 사용하지 않는다. - frontmatter 자체가 파싱되지 않는 경우에는 즉시 반환하지만, 그 외 오류는 가능한 한 끝까지 검사한다. - 여러 오류를 한 번에 반환해 PR 작성자가 한 번의 피드백으로 모두 수정할 수 있도록 설계했다. - 형식 검사는 정교함보다 매번 동일한 결과를 내고 누락 없이 동작하는 것이 중요하므로, 단순한 구현을 유지한다. ## 트리거: Description에 WHAT과 WHEN을 함께 작성 - 에이전트는 Skill을 호출할지 결정할 때 이름과 `description`만 본다. - Skill 본문은 호출이 결정된 뒤에 읽힌다. - 따라서 본문에만 다음과 같은 조건을 작성하면 호출되지 않는다. - “언제 사용하는가” - “어떤 상황에서 호출하는가” - `Use when ...` - `description`에는 Skill이 무엇인지뿐 아니라 언제 사용해야 하는지도 포함해야 한다. - 트리거 섹션은 6개 항목으로 구성되며, 본문에만 트리거 조건이 있는 경우 BLOCKER로 처리한다. - 처음에는 `when`, `use when`, “할 때”, “사용 시” 같은 표현을 정규식으로 검사했지만 한계가 있었다. - 한국어 표현을 놓치면 잘못된 BLOCKER가 발생한다. - 이모지, 완곡한 표현, 다양한 문장 구조를 모두 규칙으로 포괄하기 어렵다. - 최종적으로는 “Description이 본문의 트리거 조건을 의미적으로 충분히 포함하는가?”를 LLM이 판단하도록 전환했다. ## 운영 방식과 설계 원칙 - BLOCKER 구조 오류는 LLM 평가 전에 차단해 불필요한 모델 호출을 줄인다. - 구조 검사 결과를 오류 목록으로 한 번에 제공해 수정 비용을 낮춘다. - 복잡한 전략 패턴 같은 확장 설계보다 현재 요구사항에 맞는 단순한 검사 코드를 우선한다. - 규칙 기반과 모델 기반의 책임 영역을 명확히 나누는 것이 Rubric 전체의 핵심 원칙이다. 실무에서는 먼저 frontmatter, 이름 규칙, 폴더 구조 같은 형식 검사를 자동화하고, 이를 통과한 Skill에 대해서만 트리거 적합성과 내용 품질을 LLM으로 평가하는 방식을 권장한다. 특히 `description`에는 Skill의 기능(WHAT)과 사용 시점(WHEN)을 모두 명시해야 하며, BLOCKER 하나만으로도 배포나 Merge를 막도록 운영하면 호출되지 않는 Skill을 조기에 줄일 수 있다.

yamlllmpythoncoding-agents+3

gitlab2026년 5월 26일

몇 분 만에 코드베이스 전체의 보안 스캐너 검사 완료 (새 탭에서 열림)

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

yamlgitlabci-cdsast+4

gitlab2026년 5월 21일

조직 전체의 CI 컴포넌트 사용 현황 추적 (새 탭에서 열림)

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

yamlgitlabci-cddevsecops+3

gitlab2026년 5월 13일

정책으로 오해를 불러일으키는 취약점 심각도를 수정하는 5가지 방법 (새 탭에서 열림)

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

yamlgitlabvulnerability-managementsast+4

github2026년 5월 7일

GitHub 에이전틱 워크플로의 토큰 효율성 향상 (새 탭에서 열림)

GitHub Agentic Workflows는 반복 실행되는 CI 자동화인 만큼 토큰 비용이 누적되기 쉬우며, YAML과 실행 로그를 분석하면 이를 체계적으로 줄일 수 있다. GitHub는 토큰 사용량을 표준화해 수집하고, 감사·최적화 워크플로를 통해 불필요한 MCP 도구를 제거하거나 GitHub CLI로 대체했다. 그 결과 동작을 바꾸지 않고도 요청당 수천 토큰을 절약할 수 있었다. ## 토큰 사용량을 표준화해 기록 - Claude CLI, Copilot CLI, Codex CLI 등 에이전트 프레임워크마다 로그 형식이 달라 사용량 비교가 어려웠다. - 인증 정보를 에이전트에 직접 노출하지 않도록 사용하는 API 프록시를 활용해 모든 실행의 토큰 사용량을 한 형식으로 수집했다. - 각 워크플로는 `token-usage.jsonl` 아티팩트를 생성한다. - API 호출별 입력 토큰 - 출력 토큰 - 캐시 읽기·쓰기 토큰 - 모델과 제공업체 - 호출 시각 - 실행 로그와 이 데이터를 결합해 워크플로별 일반적인 토큰 소비 패턴과 이상 실행을 파악했다. ## 감사·최적화 워크플로로 자동 개선 - **Daily Token Usage Auditor** - 최근 실행의 토큰 사용량을 워크플로별로 집계한다. - 사용량이 급증한 워크플로, 비용이 큰 워크플로, 비정상적인 실행을 탐지한다. - 예를 들어 평소 4번의 LLM 턴으로 끝나던 작업이 18턴까지 늘어난 경우를 표시한다. - **Daily Token Optimizer** - 감사 결과가 나온 워크플로의 YAML과 최근 로그를 분석한다. - 불필요한 동작과 구체적인 최적화 방안을 GitHub Issue로 제안한다. - 감사·최적화 도구 자체도 에이전트 워크플로이므로 사용량을 함께 측정할 수 있고, 이를 통해 개선 작업이 반복되는 순환 구조를 만든다. ## 사용하지 않는 MCP 도구 제거 - LLM API는 상태를 유지하지 않기 때문에 MCP 도구의 함수명과 JSON 스키마가 매 요청에 포함되는 경우가 많다. - GitHub MCP 서버의 도구가 40개라면 매 턴마다 10~15KB의 스키마가 추가될 수 있다. - 실제로 두 도구만 사용하는 에이전트라면 나머지 38개 도구의 스키마는 매번 순수한 오버헤드가 된다. - 도구 설정과 실제 호출 기록을 대조하면 장기간 사용되지 않은 도구를 식별할 수 있다. - 스모크 테스트에서는 사용하지 않는 MCP 도구를 제거해 요청당 컨텍스트를 8~12KB 줄였고, 동작 변경 없이 실행당 수천 토큰을 절약했다. ## 데이터 조회를 GitHub CLI로 대체 MCP 호출은 단순한 데이터 조회에도 LLM의 판단 과정을 요구한다. - 에이전트가 도구를 선택하고 인자를 구성한 뒤 결과를 받는 과정 전체가 추가 LLM 호출이 된다. - 이 과정에서 도구 스키마, 인자 JSON, 응답 데이터가 모두 토큰을 소비한다. - 반면 `gh pr diff` 같은 GitHub CLI 명령은 결정적인 API 요청이므로 LLM 추론 단계가 필요 없다. GitHub는 두 가지 방식으로 MCP 데이터 조회를 CLI로 옮겼다. - **에이전트 실행 전 데이터 다운로드** - 항상 필요한 PR diff, 변경 파일 목록 등을 에이전트 시작 전에 `gh` 명령으로 가져온다. - 결과를 작업 공간 파일에 저장하고 에이전트가 파일을 읽도록 한다. - MCP 호출과 별도 추론 라운드트립을 제거하며, 에이전트가 Bash 도구를 활용해 데이터를 효율적으로 처리할 수 있다. - **에이전트 내부 CLI 프록시** - 실행 중 어떤 데이터를 가져올지 에이전트가 결정해야 하는 경우 사용한다. - 인증 토큰을 노출하지 않는 투명 HTTP 프록시가 CLI 요청을 GitHub API로 전달한다. - 에이전트는 `gh pr view --json` 같은 명령을 실행하고 구조화된 결과를 받는다. - 보안상 “에이전트에 비밀정보를 직접 제공하지 않는다”는 원칙을 유지하면서 토큰 사용량을 줄인다. ## 효율성 측정에서 고려할 요소 단순히 토큰 개수만 비교하면 최적화 효과를 정확히 판단하기 어렵다. - 모델별 토큰 가격이 다르다. - Claude Haiku와 Sonnet은 비슷한 토큰 수를 사용할 수 있지만 Haiku가 토큰당 약 4배 저렴하다. - 이를 반영하기 위해 모델과 토큰 종류에 가중치를 적용한 **Effective Tokens(ET)** 지표를 사용한다. ```text ET = m × (1.0 × I + 0.1 × C + 4.0 × O) ``` - `m`: 모델 비용 배수 - Haiku = 0.25 - Sonnet = 1.0 - Opus = 5.0 - `I`: 새로 처리한 입력 토큰 - `C`: 캐시에서 읽은 토큰 - `O`: 출력 토큰 - 출력 토큰은 입력 토큰보다 비용 영향이 크므로 4배 가중치를 적용한다. - 따라서 최적화가 토큰 수를 줄였는지뿐 아니라, 더 저렴한 모델을 사용했는지와 작업 품질을 유지했는지도 함께 평가해야 한다. 반복 실행되는 에이전트 워크플로는 먼저 사용량을 관측하고, 실제 사용 도구만 남기며, 결정적인 데이터 조회를 CLI나 사전 다운로드로 이동하는 방식이 효과적이다. 특히 MCP를 편리하다는 이유로 전체 등록하기보다 워크플로별 최소 도구만 구성하고, ET 같은 비용 반영 지표로 품질 저하 없이 최적화되는지 검증하는 것이 권장된다.

yamlllmmodel-context-protocolgithub-actions+3

gitlab2026년 4월 16일

CI 전문가 및 데이터 분석가 AI 에이전트, 개발 격차 해소 겨냥 (새 탭에서 열림)

GitLab 18.11 버전에서 새롭게 출시된 'CI Expert Agent'와 'Data Analyst Agent'는 AI로 인해 급증한 코드 생산량과 이를 뒷받침하지 못하는 기존 시스템 사이의 간극을 메우는 데 집중합니다. 이 에이전트들은 GitLab Duo Agent Platform을 기반으로 개발되었으며, 외부 도구와 달리 GitLab 내부의 실제 파이프라인 데이터와 개발 주기 맥락을 실시간으로 파악하여 맞춤형 해결책을 제시합니다. 결과적으로 개발팀은 복잡한 CI 설정이나 데이터 분석에 소요되는 시간을 획기적으로 줄이고 실제 혁신과 배포에 더 집중할 수 있게 되었습니다. ### 효율적인 파이프라인 구축을 위한 CI Expert Agent (Beta) 개발자가 코드를 작성한 후 실제 실행 가능한 파이프라인을 구축하기까지 발생하는 병목 현상을 해결합니다. * **저장소 자동 분석:** 저장소 내 코드를 직접 검사하여 사용된 언어와 프레임워크, 테스트 환경을 스스로 감지합니다. * **YAML 자동 생성:** 수동으로 `.gitlab-ci.yml` 파일을 작성할 필요 없이, 해당 프로젝트에 최적화된 실행 가능한 빌드 및 테스트 구성을 즉시 제안합니다. * **대화형 가이드:** Agentic Chat을 통해 파이프라인의 각 단계가 왜 필요한지 평이한 언어로 설명해주어, CI 설정 경험이 적은 개발자도 쉽게 이해할 수 있습니다. * **맥락 기반 최적화:** GitLab 내부에서 실행되므로 과거 파이프라인의 성공 및 실패 패턴을 학습하여 팀의 작업 방식에 맞게 지속적으로 개선됩니다. ### 자연어 기반 데이터 분석을 지원하는 Data Analyst Agent (GA) 소프트웨어 개발 수명 주기(SDLC)에서 발생하는 방대한 데이터를 복잡한 쿼리 없이 자연어로 간단히 분석할 수 있게 돕습니다. * **자연어 질의 및 시각화:** "MR 리뷰에 시간이 얼마나 걸리나요?"와 같은 질문을 던지면 즉시 데이터를 분석하여 시각화된 차트와 답변을 제공합니다. * **역할별 맞춤 인사이트:** 엔지니어링 매니저는 사이클 타임을, 개발자는 플래키(Flaky) 테스트 패턴을, 플랫폼 엔지니어는 러너 활용률을 즉각적으로 파악할 수 있습니다. * **확장된 분석 범위:** 정식 출시(GA) 단계인 이번 버전에서는 MR과 이슈를 넘어 프로젝트, 파이프라인, 개별 작업(Jobs)까지 분석 범위가 대폭 확대되었습니다. * **쿼리 호환성:** 생성된 GLQL(GitLab Query Language)은 복사하여 대시보드나 마크다운 문서 등 GitLab 내 어디서든 재사용할 수 있습니다. ### 통합 플랫폼 환경에서의 실용적 가치 GitLab은 AI가 단순히 코드 작성을 돕는 수준을 넘어, 생성된 코드를 안전하게 배포하고 그 성과를 측정하는 전 과정을 가속화해야 한다고 강조합니다. CI Expert Agent와 Data Analyst Agent는 GitLab 플랫폼의 고유한 데이터를 직접 활용하므로 별도의 외부 도구 동기화가 필요 없으며, 사용할수록 팀의 특성에 맞는 정교한 어시스턴트로 진화합니다. 현재 GitLab Duo Agent Platform 무료 체험을 통해 이러한 에이전트들의 성능을 직접 경험해 볼 수 있습니다.

yamlgitlabai-mldevops+4

gitlab2026년 3월 25일

자동 종료 정책으로 대규모 취약점 노이즈 관리하기 (새 탭에서 열림)

GitLab의 자동 취약점 상태 해제(auto-dismiss) 정책은 보안 스캐너에서 발생하는 막대한 양의 노이즈를 효과적으로 관리하여 보안팀이 실제 중요한 취약점에 집중할 수 있게 돕습니다. 테스트 코드, 외부 라이브러리, 자동 생성된 파일 등 실제 수정이 필요 없는 항목들을 정책에 따라 자동으로 제외함으로써 보안 심사 효율을 높이고 개발 부서와의 마찰을 줄일 수 있습니다. 이 기능은 단순히 경고를 숨기는 것이 아니라 해제 사유를 투명하게 기록하고 대규모 프로젝트에 일관된 기준을 적용한다는 점에서 핵심적인 보안 운영 도구입니다. ### 자동 취약점 상태 해제의 필요성과 장점 * **트리아지(Triage) 노이즈 제거:** 테스트 코드나 벤더링된 의존성 파일에서 반복적으로 발생하는 불필요한 보안 경고를 자동으로 처리하여 보안팀의 업무 과부하를 방지합니다. * **조직적 일관성 유지:** 조직 전체에 공통적으로 적용되는 오탐(False Positive) 기준을 중앙에서 정책으로 관리하여 모든 프로젝트에 일관되게 적용할 수 있습니다. * **감사 투명성 및 데이터 보존:** 스캐너 제외 방식과 달리, 해제된 취약점도 보고서에 기록으로 남으며 정책 링크와 해제 사유가 포함되어 사후 검토 및 감사가 용이합니다. ### 정책 작동 원리 및 적용 단계 * **YAML 기반 정책 정의:** 취약점 관리 정책 파일에 파일 경로, 디렉토리명 또는 특정 식별자(CVE, CWE)를 매칭 기준으로 설정하고, 해제 사유(예: 테스트 용도, 완화 제어 등)를 명시합니다. * **정책 활성화:** GitLab의 '보안 > 정책' 메뉴에서 취약점 관리 정책을 새로 생성하고 머지 요청(MR)을 통해 활성화합니다. * **파이프라인 연동:** 기본 브랜치 파이프라인이 실행될 때마다 정책이 적용되며, 실행당 최대 1,000개의 일치하는 취약점을 자동으로 '해제(Dismissed)' 상태로 변경합니다. * **결과 분석:** 취약점 보고서에서 '해제됨' 상태로 필터링하여 정책이 의도대로 작동했는지 확인하고 보안 임팩트를 측정할 수 있습니다. ### 주요 활용 사례 및 구성 시나리오 * **테스트 및 스펙 코드 제외:** `test/**/*`, `spec/**/*` 등 테스트 디렉토리에서 발견되는 하드코딩된 자격 증명이나 안전하지 않은 픽스처 관련 경고를 '테스트 사용' 사유로 자동 해제합니다. * **외부 의존성 및 벤더링 코드 관리:** `vendor/`, `node_modules` 등 직접 수정 권한이 없거나 상류(Upstream)에서 관리되는 외부 코드의 취약점을 필터링합니다. * **알려진 오탐 CVE 처리:** 조직 환경에서 위협이 되지 않는 것으로 확인된 특정 CVE 번호를 식별자로 등록하여 반복적인 수동 개입을 방지합니다. * **자동 생성된 코드 예외 처리:** Protobuf, gRPC, OpenAPI 생성기 등이 만든 파일(`**/*.pb.go` 등)에서 발생하는 수정 불가능한 패턴을 관리 대상에서 제외합니다. * **인프라 수준의 완화 조치 반영:** WAF(웹 방화벽)나 런타임 보호 도구에 의해 이미 방어되고 있는 XSS(CWE-79), SQL 주입(CWE-89) 등의 취약점에 '완화 제어 적용' 사유를 부여합니다. 효율적인 보안 운영을 위해서는 무분별한 경고 확인보다 정교한 정책 수립이 중요합니다. 처음에는 테스트 디렉토리와 같이 명확한 영역부터 자동 해제 정책을 적용해보고, 점진적으로 오탐으로 확인된 CVE나 CWE로 범위를 넓혀가며 보안 팀의 생산성을 극대화할 것을 추천합니다.

yamlgitlabdevsecopsvulnerability-management+3

github2026년 3월 16일

초보자를 위한 GitHub: GitHub Actions 시작하기 (새 탭에서 열림)

GitHub Actions는 GitHub에 내장된 CI/CD 및 자동화 플랫폼으로, YAML 워크플로를 통해 반복 작업과 배포 과정을 자동화한다. 저장소 이벤트가 발생하면 가상 실행 환경에서 작업을 수행하며, 글에서는 새 이슈에 `triage` 라벨을 자동으로 붙이는 첫 워크플로를 만드는 과정을 설명한다. 핵심 구성 요소는 이벤트(`on`), 실행 환경(`runs-on`), 작업(`jobs`), 단계(`steps`), 권한(`permissions`)이다. ## GitHub Actions의 역할 - GitHub Actions는 지속적 통합·지속적 배포(CI/CD)와 자동화를 위한 플랫폼이다. - YAML 파일로 다음과 같은 작업을 자동화할 수 있다. - 취약점 검사 - 테스트 실행 - 릴리스 생성 - 팀에 업데이트 알림 - 배포 프로세스 - 워크플로는 저장소에 저장되며, 코드 푸시·풀 리퀘스트·이슈 생성·예약된 시간 등의 이벤트로 실행된다. - 이벤트가 발생하면 GitHub가 가상 환경을 준비하고 정의된 작업을 자동으로 실행한다. ## 워크플로를 구성하는 요소 - **이벤트(Event)** - 워크플로를 시작시키는 저장소 활동이다. - 예: 코드 푸시, 풀 리퀘스트 생성, 이슈 생성, 브랜치 병합 - **실행기(Hosted runner)** - 워크플로의 작업을 실행하는 가상 머신이다. - GitHub가 제공하는 Ubuntu, Windows, macOS 실행기를 사용할 수 있다. - 필요하면 자체 호스팅 실행기를 구성할 수도 있다. - **작업(Job)** - 하나의 실행기에서 수행되는 단계들의 묶음이다. - **단계(Step)** - 셸 명령을 실행하거나 미리 만들어진 재사용 가능한 액션을 호출한다. ## Actions 탭과 워크플로 템플릿 - 저장소의 **Actions** 탭에서는 현재 저장소에 등록된 워크플로를 확인할 수 있다. - **New workflow**를 선택하면 저장소에 적합한 추천 템플릿을 확인할 수 있다. - 템플릿은 YAML 편집기로 열리며, 기본적으로 다음 세 영역을 포함한다. - `name`: 워크플로의 목적을 설명하는 이름 - `on`: 워크플로를 실행할 이벤트 - `jobs`: 실제 작업 내용 ## YAML 워크플로 파일 작성 - 워크플로 파일은 저장소의 `.github/workflows` 디렉터리에 `.yml` 확장자로 저장한다. - 파일명은 `build-and-test.yml`, `security-scanner.yml`처럼 역할을 바로 알 수 있게 작성하는 것이 좋다. - 예제에서는 `label-new-issue.yml` 파일을 만들고 새 이슈에 라벨을 자동으로 추가한다. - 워크플로 이름은 다음과 같이 지정한다. ```yaml name: Label New Issues ``` ## 이슈 생성 이벤트 설정 - `on` 키워드로 워크플로의 실행 조건을 정의한다. - 다음 설정은 이슈가 새로 생성될 때만 워크플로를 실행한다. ```yaml on: issues: types: [opened] ``` - GitHub Actions는 다양한 이벤트와 세부 이벤트 유형을 지원하므로, 작업 목적에 맞는 트리거를 선택할 수 있다. ## 작업 환경과 권한 설정 - `jobs` 아래에 작업 이름을 지정한다. - `runs-on: ubuntu-latest`는 GitHub가 제공하는 최신 Ubuntu 실행기를 사용한다는 의미다. - 작업이 저장소를 읽고 이슈 라벨을 수정하려면 적절한 권한을 명시해야 한다. ```yaml jobs: label-issues: runs-on: ubuntu-latest permissions: issues: write contents: read ``` - `issues: write`는 이슈를 수정할 수 있는 권한이다. - `contents: read`는 저장소 콘텐츠를 읽을 수 있는 권한이다. - 작업 수준에서 `permissions`를 지정하면 해당 작업의 액션과 명령에 그 권한이 적용된다. ## 저장소 확인과 라벨 추가 단계 - `steps`에는 작업에서 순서대로 수행할 동작을 작성한다. - `actions/checkout@v6` 액션으로 저장소 코드를 실행 환경에 내려받는다. - 이후 GitHub CLI를 사용해 새 이슈에 `triage` 라벨을 추가한다. ```yaml steps: - name: Checkout repository uses: actions/checkout@v6 - name: Add triage label env: GH_TOKEN: ${{ secrets.GITHUB_TOKEN }} ISSUE_NUMBER: ${{ github.event.issue.number }} LABEL: "triage" run: gh issue edit "$ISSUE_NUMBER" --add-label "$LABEL" ``` - `uses`는 GitHub Marketplace의 미리 만들어진 재사용 액션을 호출한다. - 저장소 체크아웃 - Node.js 설정 - 기타 반복적인 개발 작업 등에 활용할 수 있다. - `run`은 실행기에서 셸 명령을 직접 실행한다. - `GH_TOKEN`에는 GitHub가 제공하는 `GITHUB_TOKEN`을 사용한다. - `${{ github.event.issue.number }}`는 이벤트 정보에서 새로 생성된 이슈 번호를 가져온다. - `gh issue edit` 명령은 해당 이슈에 `triage` 라벨을 추가한다. 처음에는 GitHub Actions의 템플릿을 활용해 간단한 이벤트 기반 자동화를 만들어 보는 것이 좋다. 이후 이벤트 조건, 최소 권한, 재사용 액션과 직접 실행 명령을 조합하면 테스트·보안 검사·이슈 관리·배포까지 확장할 수 있다.

yamlci-cdgithubgithub-actions+2

github2026년 3월 6일

GitHub Security Lab의 오픈 소스 (새 탭에서 열림)

GitHub Security Lab은 오픈 소스 AI 프레임워크인 **Taskflow Agent**와 웹 보안 감사용 taskflow를 활용해 80건 이상의 취약점을 발견했으며, 그중 상당수는 인증 우회와 민감 정보 노출처럼 영향도가 높은 취약점이었다고 설명합니다. 이 방식은 대형 단일 프롬프트 대신 여러 단계의 작업을 YAML로 정의하고, LLM의 분석 결과를 데이터베이스로 전달해 반복적·구조적인 보안 감사를 수행합니다. 프레임워크와 taskflow는 공개되어 있어 GitHub Copilot 사용자는 자신의 저장소에서도 실행할 수 있습니다. ## 오픈 소스 AI 보안 감사의 성과 - 새로운 taskflow는 웹 애플리케이션 취약점 탐색에 특화되어 있습니다. - 지금까지 80건 이상의 취약점을 보고했으며, 작성 시점에 약 20건이 공개되었습니다. - 발견된 취약점의 상당수는 다음과 같은 고위험 유형입니다. - 인증 또는 권한 우회 - 다른 사용자로 로그인할 수 있는 문제 - 다른 사용자의 비공개 데이터에 접근하는 정보 노출 - 글에서 제시한 사례로는 다음이 언급됩니다. - 전자상거래 애플리케이션의 장바구니에서 개인식별정보(PII) 접근 - 채팅 애플리케이션에서 어떤 비밀번호를 사용해도 로그인 가능한 문제 - 연구자들은 기존에 악용 가능성이 불분명한 후보를 검증하는 데 쓰던 시간을 줄이고, 실제 결과를 수동 검증하고 보고하는 데 더 집중할 수 있게 되었다고 설명합니다. ## 자신의 저장소에서 실행하는 방법 - `GitHubSecurityLab/seclab-taskflows` 저장소에서 Codespace를 시작합니다. - 초기화가 끝난 뒤 다음 명령을 실행합니다. ```bash ./scripts/audit/run_audit.sh myorg/myrepo ``` - 중간 규모 저장소에서는 실행에 한두 시간이 걸릴 수 있습니다. - 완료되면 SQLite 뷰어가 열리고, `audit_results` 테이블에서 `has_vulnerability` 열이 체크된 행을 확인합니다. - 실행에는 GitHub Copilot 라이선스가 필요하며, 프리미엄 모델 요청 할당량을 많이 사용할 수 있습니다. - LLM 결과는 비결정적이므로 같은 코드베이스를 여러 번 검사하는 것이 권장됩니다. - 서로 다른 모델을 사용하면 결과가 달라질 수 있습니다. - 예시로 GPT 5.2와 Claude Opus 4.6을 각각 사용할 수 있습니다. - 비공개 저장소도 지원하지만, Codespace 설정을 수정해 접근 권한을 별도로 부여해야 합니다. ## Taskflow의 구조 - Taskflow는 LLM에 수행시킬 작업 목록을 YAML로 정의한 파일입니다. - `seclab-taskflow-agent`가 다음 기능을 담당합니다. - 작업을 순차적으로 실행 - 앞선 작업의 결과를 다음 작업에 전달 - 여러 구성 요소에 같은 작업을 비동기적으로 반복 실행 - 템플릿 프롬프트에 구성 요소별 정보를 삽입 - 저장소 감사는 일반적으로 다음 단계로 나뉩니다. - 저장소를 기능별 구성 요소로 분할 - 각 구성 요소의 진입점, 신뢰할 수 없는 입력, 요구 권한, 역할 등을 분석 - 분석 결과를 `repo_context.db` 같은 데이터베이스에 저장 - 저장된 컨텍스트를 사용해 취약점 후보를 생성 - 후보별로 세부 검증을 수행 - 현재는 각 구성 요소에 대해 일반적인 보안 문제를 제안하는 작업과, 제안된 문제를 정밀하게 검증하는 작업이 사용됩니다. - 특정 취약점 유형에 집중하는 별도의 taskflow도 추가할 수 있습니다. ## 하나의 거대한 프롬프트 대신 여러 작업을 사용하는 이유 - LLM의 컨텍스트 창에는 한계가 있습니다. - 복잡한 작업을 하나의 프롬프트에 모두 넣으면 일부 단계가 누락되거나 제대로 수행되지 않을 수 있습니다. - 작업을 분리하면 다음과 같은 장점이 있습니다. - 각 단계의 결과를 개별적으로 확인 가능 - 실패하거나 잘못된 단계를 디버깅하기 쉬움 - 이전 분석 결과를 후속 작업의 컨텍스트로 재사용 가능 - 여러 코드 구성 요소에 동일한 분석을 일관되게 적용 가능 - 더 큰 컨텍스트 창을 지원하는 모델에서도, 작업 흐름을 통제하고 검증하기 위해 taskflow 방식이 유용하다고 설명합니다. ## 일반 보안 코드 감사에서의 과제 - 초기에는 CodeQL 경고 분류처럼 범위와 판단 기준이 명확한 작업에 Taskflow Agent를 사용했습니다. - 이후 특정 경고에 한정하지 않고 일반적인 취약점까지 찾는 방식으로 확장했습니다. - LLM에 더 많은 자유를 주면 다음 문제가 커집니다. - 환각 - 오탐 - 검증하기 어려운 취약점 보고 - CodeQL 경고 분류가 효과적이었던 이유는 지시와 판정 기준이 엄격하고, 각 단계에서 결과가 요구사항을 충족하는지 확인할 수 있었기 때문입니다. - 따라서 목표는 LLM이 다양한 취약점을 자유롭게 탐색하게 하면서도 taskflow 설계와 프롬프트 엔지니어링으로 환각과 오탐을 통제하는 것입니다. ## 실용적인 권장 사항 실제 프로젝트에 적용할 때는 한 번의 실행 결과를 확정적인 보안 보고서로 취급하지 말고, 여러 모델과 반복 실행으로 후보를 수집한 뒤 사람이 재현 가능성과 악용 가능성을 검증하는 것이 좋습니다. 또한 저장소 전체를 한 번에 분석하기보다 기능별 구성 요소와 단계별 taskflow로 나누면 결과를 추적하고 수정하기 쉽습니다.

yamlllmopen-sourcegithub-copilot+4

datadog2026년 3월 4일

에이전트를 위한 MCP 도구 설계: Datadog의 MCP 서버 구축을 통해 배운 교훈 (새 탭에서 열림)

AI 에이전트를 위한 관측성(Observability) 인터페이스 구축 시, 단순히 기존 API를 그대로 노출하는 방식은 컨텍스트 창의 한계와 비용 문제로 인해 한계가 명확합니다. Datadog은 MCP(Model Context Protocol) 서버를 구축하며 데이터 포맷 최적화, SQL 기반 쿼리 도입, 도구의 효율적 관리라는 세 가지 핵심 설계를 통해 에이전트의 작업 효율을 극대화했습니다. 결과적으로 이러한 설계 변경은 에이전트의 추론 정확도를 높이는 동시에 토큰 사용량을 줄여 운영 비용을 절감하는 효과를 가져왔습니다. ### 컨텍스트 창 효율성 극대화 * **데이터 포맷 최적화**: JSON은 프로그래밍 방식에는 적합하지만 토큰 소모가 큽니다. 평면적인 데이터에는 CSV(토큰 약 50% 절감)를, 계층 구조가 있는 데이터에는 YAML(약 20% 절감)을 사용하여 동일한 컨텍스트 내에 더 많은 정보를 담았습니다. * **필드 트리밍**: 에이전트에게 불필요한 필드를 기본 출력에서 제거하고 필요한 경우에만 요청하게 함으로써, 동일한 토큰 예산 내에서 레코드 수용량을 최대 5배까지 늘렸습니다. * **토큰 기반 페이지네이션**: 레코드 개수 단위로 데이터를 끊어 보내는 전통적인 방식 대신, 실제 소비되는 토큰량을 기준으로 응답을 제한하여 에이전트의 컨텍스트 창이 예기치 않게 가득 차는 문제를 방지했습니다. ### 단순 조회를 넘어선 SQL 기반 쿼리 도입 * **서버 측 집계**: 에이전트가 수천 개의 로그를 직접 내려받아 트렌드를 분석하는 대신, 서버에서 SQL을 실행하여 요약된 결과만 받도록 개선했습니다. * **비용 및 성능 개선**: SQL을 통해 꼭 필요한 필드만 선택(SELECT)하고 행을 제한(LIMIT)함으로써, 평가 시나리오에서 실행 비용을 약 40% 절감하고 정답률을 높였습니다. * **에이전트 적응력**: AI 에이전트는 SQL 작성에 매우 능숙하며, 이를 통해 컨텍스트 윈도우에 들어갈 데이터를 스스로 세밀하게 제어할 수 있게 되었습니다. ### 도구 비대화 방지 및 관리 전략 * **유연한 도구 설계**: 개별 API 엔드포인트마다 도구를 만드는 대신, 하나의 도구가 여러 유즈케이스를 처리할 수 있도록 스키마를 범용적으로 설계하여 도구의 총 개수를 줄였습니다. * **도구 세트(Toolsets) 분리**: 모든 도구를 한꺼번에 노출하지 않고, 핵심 도구와 특정 워크플로우를 위한 선택적 도구 세트를 구분하여 에이전트의 혼란을 방지하고 컨텍스트 소모를 최소화했습니다. * **도구 계층화**: "어떻게 작업을 수행할지"를 묻는 도구와 실제 동작 도구를 분리하여 검색 효율을 높였습니다. 다만, 이 방식은 레이턴시 증가라는 기회비용이 발생하므로 신중한 적용이 필요합니다. AI 에이전트를 위한 도구를 설계할 때는 인간 사용자를 위한 API 설계와는 다른 접근이 필요합니다. 에이전트가 데이터를 직접 처리하게 두기보다, 서버 측에서 데이터를 가공하고 요약할 수 있는 강력한 쿼리 기능을 제공하고 전송 포맷을 최적화하는 것이 성능과 비용 측면에서 모두 유리합니다.

yamldatabase-designdatadogobservability+4

github2026년 2월 5일

실무에서의 지속적인 AI: 에 (새 탭에서 열림)

소프트웨어 개발에는 테스트·빌드처럼 규칙으로 자동화할 수 있는 작업뿐 아니라, 코드의 의도와 맥락을 해석해야 하는 작업도 많다. GitHub가 제안하는 **Continuous AI**는 CI를 대체하지 않고, 자연어로 정의한 기대사항을 에이전트가 지속적으로 검토하도록 해 문서 불일치, 성능 회귀, 버그 추세 분석 같은 판단 중심 업무를 자동화한다. 다만 에이전트의 권한과 산출물을 명시적으로 제한해 개발자의 검토와 통제를 유지하는 것이 핵심이다. ## CI가 해결하지 못하는 판단 중심 업무 - CI는 테스트, 빌드, 포맷팅, 정적 분석처럼 결과를 이진적으로 판단할 수 있는 작업에 적합하다. - 테스트가 통과했는지 - 빌드가 성공했는지 - 정해진 린트 규칙을 위반했는지 - 반면 다음과 같은 문제는 단순한 규칙이나 휴리스틱만으로 판단하기 어렵다. - 문서의 설명과 실제 구현이 서로 다른 경우 - 접근성 린터는 통과하지만 사용자에게 여전히 혼란스러운 문구 - 메이저 버전 변경 없이 의존성의 플래그 동작이 바뀐 경우 - 반복문 안에서 정규식을 컴파일해 발생하는 미묘한 성능 저하 - 실제 제품과 상호작용해야만 드러나는 UI 동작 변화 - 이런 문제는 코드가 의도와 일치하는지, 사용자 경험이나 성능에 문제가 없는지를 해석해야 한다. - GitHub Next는 코드 생성 중심의 AI에서 나아가, 개발자의 인지 부담이 큰 반복 업무를 대신 처리하는 방향을 제시한다. ## Continuous AI의 개념 - Continuous AI는 CI를 대체하는 새로운 제품이 아니라 자동화 패턴이다. - 핵심 구조는 다음과 같다. - **자연어 규칙** - **에이전트의 추론** - **저장소 안에서의 지속적 실행** - 개발자는 코드에 대해 “무엇이 참이어야 하는가”를 자연어로 정의한다. - 에이전트는 저장소를 분석한 뒤 다음과 같은 검토 가능한 산출물을 만든다. - 수정 제안 - 풀 리퀘스트 - 이슈 - 댓글 또는 토론 - 프로젝트 활동·품질 관련 인사이트 - 예시로는 다음과 같은 워크플로가 있다. - 문서와 구현의 차이를 찾아 원인을 설명하고 수정안 제시 - 매주 프로젝트 활동, 버그 증가 추세, 코드 변경량이 급증한 영역 요약 - 핵심 경로의 성능 회귀 탐지 - 사용자 흐름에서 의미상 회귀가 발생했는지 확인 - 실제 워크플로는 한 문장으로 완성되지 않는다. 개발자와 에이전트가 의도, 제약 조건, 허용 가능한 결과를 반복적으로 조정하며 만든다. ## YAML과 자연어의 역할 분담 - 문제가 명확한 규칙으로 표현된다면 YAML, 스키마, 린터, 기존 CI가 여전히 가장 적합하다. - 그러나 “문서와 코드가 불일치하면 찾아서 수정하라”와 같은 요구는 정규식이나 스키마만으로 의미를 보존하기 어렵다. - 자연어는 코드의 의미와 개발자의 의도를 설명하는 데 유리하다. - 따라서 Continuous AI는 YAML 기반 CI를 대체하는 것이 아니라, CI가 다루기 어려운 의미·맥락 중심의 자동화를 보완한다. ## 권한과 안전한 산출물 - 에이전트는 기본적으로 저장소에 읽기 전용 권한만 가진다. - 명시적으로 허용하지 않는 한 다음 작업을 수행할 수 없다. - 이슈 생성 - 풀 리퀘스트 생성 - 파일이나 콘텐츠 수정 - **Safe Outputs**는 에이전트가 만들 수 있는 산출물과 조건을 명시하는 결정적 계약이다. - 워크플로를 정의할 때 개발자는 에이전트가 어떤 결과를 만들 수 있는지와 그 제약을 지정한다. - 예상 밖의 동작에 대비해 다음 안전장치를 둔다. - 출력 정제 - 명시적 권한 관리 - 전체 활동 기록 및 감사 가능성 - 제한된 권한으로 인한 예측 가능한 영향 범위 - 따라서 목표는 AI가 개발을 자율적으로 장악하는 것이 아니라, 개발자가 정한 경계 안에서 반복적인 판단 업무를 수행하게 하는 것이다. ## 개발자의 검토를 유지하는 방식 - 에이전트는 자율적으로 커밋을 확정하는 대신, 개발자가 검토할 수 있는 형태로 결과를 제출한다. - 가장 일반적인 출력은 풀 리퀘스트이며, 기존의 코드 리뷰 방식과 자연스럽게 연결된다. - 개발자는 AI가 생성한 결과를 검토하고, 자신의 판단과 취향을 최종적으로 유지한다. - 장기적으로는 개발자가 계속 직접 수행할 일과 AI에 위임할 일을 구분하는 것이 중요하다. 실무에서는 먼저 읽기 전용 분석과 보고서 생성부터 도입하고, 결과의 품질이 검증된 뒤 이슈 생성이나 풀 리퀘스트 작성 권한을 제한적으로 부여하는 방식이 안전하다. 결정적 규칙은 CI에 남기고, 의도·맥락·해석이 필요한 업무만 자연어 기반 에이전트 워크플로로 확장하는 것이 바람직하다.

yamlai-agentgithubcode-review+3

gitlab2026년 1월 14일

플로우 이해하기: 멀티 (새 탭에서 열림)

GitLab Duo Agent Platform의 '플로우(Flows)'는 여러 전문 AI 에이전트가 협업하여 복잡한 개발 과업을 자율적으로 수행하는 멀티 에이전트 워크플로우 시스템입니다. 사용자와 대화하며 협력하는 개별 에이전트와 달리, 플로우는 특정 이벤트에 의해 트리거되어 백그라운드에서 분석부터 실제 구현 및 결과 도출까지 엔드 투 엔드(end-to-end) 작업을 독립적으로 처리합니다. 이를 통해 개발자는 반복적인 파이프라인 관리나 단순 구현 업무에서 벗어나 보다 고차원적인 설계에 집중할 수 있는 자율형 자동화 환경을 구축할 수 있습니다. ### 에이전트와 플로우의 차이 및 주요 특징 * **자율성:** 에이전트가 사용자와 상호작용하며 실시간으로 도움을 준다면, 플로우는 사용자를 대신해 독립적으로 워크플로우를 완수하는 데 초점을 맞춥니다. * **플랫폼 통합:** 별도의 외부 인프라 구축 없이 GitLab 플랫폼의 컴퓨팅 자원에서 직접 실행되는 내장형 시스템입니다. * **비동기 및 이벤트 기반:** 멘션(@), 담당자 할당, 리뷰어 지정 등의 이벤트로 트리거되며, 작업이 진행되는 동안 개발자는 다른 업무를 중단 없이 수행할 수 있습니다. * **기본 및 커스텀 옵션:** GitLab이 직접 관리하는 생산 준비 완료 단계의 '기본 플로우'와 팀의 특정 요구에 맞춰 구성하는 '커스텀 플로우'를 모두 지원합니다. ### 커스텀 플로우의 활용과 트리거 방식 * **팀 맞춤형 자동화:** 조직 고유의 보안 정책 검토, 특정 기술 스택에 맞춘 코드 리뷰, API 문서 자동 생성 등 범용 AI가 해결하기 어려운 구체적인 워크플로우를 자동화할 수 있습니다. * **다양한 실행 경로:** 이슈나 머지 리퀘스트(MR)에서 `@flow-name`으로 멘션하거나, `/assign @flow-name` 명령어를 통해 담당자 또는 리뷰어로 지정하는 즉시 실행됩니다. * **실제 활용 사례:** 핀테크 기업의 경우 컴플라이언스 플로우를 구축하여, 모든 MR에 대해 PCI-DSS 위반 여부를 스캔하고 보안 코딩 표준 준수 여부를 확인한 뒤 자동으로 보고서를 게시하도록 설정할 수 있습니다. ### YAML 기반의 플로우 설계 및 구성 요소 * **구조적 정의:** 플로우는 YAML 구성을 통해 정의되며 구성 요소(Components), 프롬프트(Prompts), 라우터(Routers), 도구 모음(Toolsets)으로 이루어집니다. * **에이전트 컴포넌트:** 워크플로우의 각 단계를 담당할 에이전트의 유형과 동작 방식을 정의하며, 특정 AI 모델의 행동 지침을 프롬프트 ID로 연결합니다. * **강력한 도구 연결:** `get_issue`, `create_commit`, `create_merge_request`와 같은 GitLab API 도구를 에이전트에게 부여하여 실제로 코드를 수정하고 저장소에 반영할 수 있는 권한을 제공합니다. * **전문성 주입:** 프롬프트 템플릿 내에 도메인 지식(예: 여행 예약 시스템의 특수성)과 코드 표준을 명시하여 AI가 조직의 맥락에 맞는 최적의 결과물을 내놓도록 정교하게 제어합니다. 단순한 코드 생성을 넘어 복잡한 프로세스의 완전 자동화를 목표로 한다면, 팀 내에서 가장 반복적으로 발생하는 작업부터 커스텀 플로우로 전환해 보길 권장합니다. 처음에는 GitLab에서 제공하는 기본 플로우로 기능을 탐색한 뒤, 점진적으로 팀의 정책이 반영된 YAML 정의 플로우를 확장해 나가는 것이 생산성 향상에 가장 효과적입니다.

yamlai-agentgitlabreact+4