Agent Registry 스킬 GA: 미검사 리비전과 기본 버전 전환 점검

스킬 패키지의 버전 검토와 배포 선택을 표현한 생성 이미지. 실제 Google Cloud 화면이나 공식 구성도는 아니다.

Google Cloud는 November 6, 2026 Agent Registry의 독립 스킬(standalone skills)을 정식 출시했다. 스킬의 보안 검사와 거버넌스 기능도 같은 날 발표했다. Agent Registry 전체는 이미 6월에 정식 출시됐으며, 이번 변화의 중심은 스킬 패키지를 버전별로 등록하고 검토하는 절차다. CMEK 기능은 여전히 Preview로 구분된다. 공식 릴리스 노트

에이전트가 읽는 지시문과 실행 스크립트를 팀 안에서 배포한다면, 이제 패키지 업로드와 운영 적용 사이에 검토 단계를 설계할 수 있다. 특히 이전 리비전의 검사 여부, 검사 완료와 발견 사항, 실제 배포된 버전을 따로 확인해야 한다.

1. 스킬 이름과 배포 리비전을 구분한다

독립 스킬은 루트의 SKILL.md와 선택적 스크립트·자료를 담은 ZIP 패키지다. A2A Agent Card 안에서 기능을 설명하는 인라인 스킬과는 다르다.

Agent Registry에서 Skill은 이름과 메타데이터, 기본 리비전 포인터를 가진다. SkillRevision은 특정 버전의 변경 불가능한 패키지다. 내용을 고칠 때는 기존 리비전을 덮어쓰지 않고 새 리비전을 올린다. 리비전을 명시하지 않은 사용·다운로드는 defaultRevision이 가리키는 버전을 받는다. 스킬 구조

따라서 배포 기록에는 ‘어떤 스킬을 썼다’에서 멈추지 말고 다음을 남기는 편이 좋다.

소스 커밋과 ZIP 패키지의 해시

프로젝트·위치·스킬 ID·리비전 ID

검사 결과와 검토자

기본 리비전을 바꾼 시점

에이전트가 실제로 가져간 리비전

명시적 리비전에 고정한 소비자는 기본 포인터를 바꿔도 그대로 남을 수 있다. 반대로 기본 포인터를 따르는 소비자는 다음에 패키지를 가져올 때 변경 영향을 받을 수 있다. 실제 로딩·캐시 방식은 소비자 구현에서 확인해야 한다.

2. 검사 완료를 안전 판정으로 읽지 않는다

검사는 지시문·스크립트·지원 자료의 정보 유출, 노출된 자격증명, 프롬프트 인젝션 등을 살핀다. 새 스킬을 만들 때 검사 정책을 지정하지 않으면 ENABLED_BLOCKING이 적용된다. 기존 스킬은 현재 scanningConfig.policy를 별도로 확인해야 한다. 차단 정책은 발견 사항이 있는 리비전의 다운로드를 막고, 발견 사항이나 대기 중인 검사가 있는 리비전을 기본 버전으로 승격하지 못하게 한다.

scanResult.scanState가 SUCCEEDED라는 것은 검사 실행이 끝났다는 뜻이다. 보안 문제가 발견돼도 이 상태가 될 수 있으므로 scanResult.findings도 함께 확인해야 한다. LLM 기반 검사에는 오탐·누락과 부정확한 설명이 있을 수 있다고 Google은 명시한다. 검사와 결과 확인

리비전의 ACTIVE 상태 역시 보안 검사 통과를 뜻하지 않는다. 패키지 형식 검증 뒤 리비전이 활성화돼도 보안 검사는 비동기로 진행된다. 리비전 수명주기

실무 검토에서는 발견 사항의 파일·행 번호를 원본과 대조하고, 실행 경로와 권한을 확인한다. 결과가 비었다고 해서 무제한 네트워크 접근이나 운영 자격증명을 허용할 근거가 생기는 것은 아니다. 패키지 검토와 실행 환경의 최소 권한·격리 정책은 함께 유지해야 한다.

3. 기존 리비전에는 검사가 소급되지 않는다

기존 스킬에서 검사를 켜거나 정책을 바꿔도 이미 만들어진 리비전을 자동으로 다시 검사하지 않는다. 검사를 끈 상태에서 올린 내용을 검사하려면 새 리비전을 만들어야 한다. 정책 변경의 적용 범위

현재 기본 리비전에 발견 사항, 대기 중인 검사, 실패하거나 완료되지 않은 검사 결과가 있으면 ENABLED_BLOCKING으로의 정책 변경은 FAILED_PRECONDITION으로 실패한다. 먼저 검사가 완료됐고 발견 사항이 없는 리비전을 기본값으로 준비해야 한다. 이미 ENABLED_BLOCKING인 스킬에서는 발견 사항이나 대기 중인 검사가 있는 리비전으로 기본 포인터를 바꾸는 작업도 거절된다. 기본 리비전·정책 갱신 조건

운영 중인 스킬은 다음 순서로 이관 계획을 세운다.

현재 정책과 기본 리비전, 소비자가 고정한 과거 리비전을 조회한다.

검사하지 않은 패키지와 발견 사항이 있는 패키지를 분리한다.

현재 정책 전환 조건을 확인하고, 승인된 검증 환경에서 검사 가능한 새 리비전을 준비한다.

비동기 검사가 끝난 뒤 발견 사항을 검토한다.

검토된 리비전으로 기본 포인터와 소비자 설정을 맞춘다.

다운로드·로딩·대표 작업을 확인한 뒤 운영에 적용한다.

이는 제안하는 배포 절차이며, 기존 모든 스킬에 한 번의 정책 변경 명령을 일괄 실행하라는 뜻은 아니다. 실패를 없애려고 검사를 끄기보다 먼저 어떤 기본 리비전과 검사 상태가 전제 조건을 막는지 확인하자.

4. 먼저 조회 명령으로 현재 상태를 확보한다

아래는 공식 문서의 조회 명령 형태다. PROJECT_ID, LOCATION, SKILL_ID, REVISION_ID를 실제 대상 값으로 바꿔 사용한다. 수동 등록한 스킬의 조회 ID에는 private- 접두사가 포함되므로 콘솔에 표시되는 값을 확인한다.

첫 조회에서는 scanningConfig.policy와 defaultRevision을, 두 번째 조회에서는 리비전 상태와 scanResult를 확인한다. 출력과 패키지 자체에 업무 정보가 포함될 수 있으므로 CI 로그에 전체 내용을 무조건 공개하지 않는다. 스킬 조회 · 리비전 검사 결과 조회

업로드 ZIP 자체의 압축된 크기는 최대 1 MB다. 검사 활성화 시에는 압축 해제 후 전체 10 MB, 개별 파일 1 MB 제한도 확인한다. 패키지 수집 제한 대형 샘플이나 생성 산출물을 넣은 패키지는 INVALID_ARGUMENT 또는 UNSUPPORTED_FORMAT으로 막힐 수 있다. RUNNING, FAILED, UNSUPPORTED_FORMAT, DISABLED를 자동 배포의 합격 상태로 취급하지 않는 것이 안전하다. 검사 크기 제한과 상태

5. 등록 권한과 배포 권한을 한꺼번에 주지 않는다

Google의 관리 문서는 조회, 수정·삭제, IAM 정책 관리에 필요한 역할을 구분한다. 조직에서 사용하는 실제 역할과 커스텀 역할을 확인하고, 런타임 에이전트에 관리 권한까지 넘겨야 하는지 따져야 한다. 스킬 관리 역할 · IAM 접근 제어

예를 들어 패키지를 만드는 CI, 발견 사항을 검토하는 담당자, 기본 리비전을 바꾸는 배포 작업, 패키지를 소비하는 에이전트를 구분할 수 있다. 한 주체가 내용을 수정하고 검사 정책을 낮춘 뒤 곧바로 운영 기본값까지 바꾸지 않도록 권한을 설계하는 것이 목적이다.

다만 기본 역할만 나눠 부여한다고 이 분리가 자동으로 구현되지는 않는다. 기본 리비전과 검사 설정은 모두 스킬 갱신에 해당한다. 검사 정책을 낮추지 못하도록 조직 정책을 적용하고 배포 승인 절차를 함께 설계해야 한다. 상세 Finding 조회도 일반 Viewer 조회와 구분된다. 공식 안내는 Agent Registry API Admin 역할을 제시하므로, 검토 편의를 위해 관리자 권한을 일괄 부여하지 말고 필요한 권한을 확인한다. 역할별 범위 · 발견 사항 조회

조직 정책으로 검사 설정을 강제할 때도 기존 스킬의 상태를 먼저 확인한다. Agent Registry는 Skill 대상의 커스텀 Organization Policy 제약을 지원하지만, 정책 적용만으로 기존 패키지가 재검사되거나 정리되지는 않는다. 조직 정책 적용 범위

도입 전에 남길 체크리스트

독립 스킬 패키지와 A2A 기능 설명을 구분했는가?

현재 기본 리비전과 소비자가 고정한 리비전을 파악했는가?

이전 미검사 패키지의 새 리비전 생성 계획이 있는가?

검사 완료 상태와 발견 사항을 함께 확인하는가?

정책 변경 실패와 비동기 검사 대기를 배포 파이프라인에서 처리하는가?

검토자·배포자·런타임의 권한이 목적에 맞게 나뉘어 있는가?

문제가 생겼을 때 되돌릴 리비전도 검사·검토돼 있는가?

이번 기능은 에이전트 스킬을 파일 복사로 배포하던 과정을 버전과 검사 기록이 남는 절차로 바꾸는 데 의미가 있다. 도입 여부를 검토할 때는 기능 목록보다 ‘어떤 패키지를 누가 검토했고, 어떤 에이전트가 실제로 쓰는가’를 추적할 수 있는지부터 확인하자.

이 글은 November 8, 2026 확인한 공식 공개 문서를 바탕으로 작성했다. 실제 Google Cloud API 호출, 스킬 업로드·스캔, IAM·조직 정책 변경은 실행하지 않았다. 조회 명령은 문서 기반 예제이며 실제 프로젝트 실행 결과를 제시한 것이 아니다.