Google Antigravity로 KCC 작업 마스터하기

1. 소개

이 Codelab에서는 IDE를 에이전트 중심 시대로 진화시키는 에이전트형 개발 플랫폼인 Google Antigravity (문서의 나머지 부분에서는 Antigravity라고 함)에 대해 알아봅니다.

줄을 자동 완성하는 표준 코딩 어시스턴트와 달리 Antigravity는 빌드를 지원하기 위해 계획, 코딩, 웹 탐색까지 할 수 있는 자율 에이전트를 관리하는 '미션 컨트롤'을 제공합니다.

Antigravity는 에이전트 중심 플랫폼으로 설계되었습니다. AI가 코드를 작성하는 도구일 뿐만 아니라 최소한의 인간 개입으로 복잡한 엔지니어링 작업을 계획, 실행, 검증, 반복할 수 있는 자율적인 행위자라고 가정합니다.

학습할 내용

Antigravity 설치 및 구성
Agent Manager, Editor, Browser 등 Antigravity의 주요 개념을 살펴봅니다.
안전하고 규정을 준수하는 방식으로 Google Cloud 리소스를 관리하기 위해 처음부터 프로덕션 등급 KCC 운영 기술 구축

필요한 항목

현재 Antigravity는 개인 Gmail 계정의 미리보기로 제공됩니다. 프리미어 모델을 사용할 수 있는 무료 할당량이 제공됩니다.

Antigravity는 시스템에 로컬로 설치되어 있어야 합니다. 이 제품은 Mac, Windows, 특정 Linux 배포에서 사용할 수 있습니다. 자체 머신 외에 다음이 필요합니다.

Gmail 계정 (개인 Gmail 계정)
Google Cloud 계정 및 Google Cloud 프로젝트
Google Cloud 콘솔 및 Cloud Shell을 지원하는 웹브라우저(예: Chrome)

2. 설정 및 요구사항

프로젝트 설정

Google Cloud 프로젝트 만들기

Google Cloud 콘솔의 프로젝트 선택기 페이지에서 Google Cloud 프로젝트를 선택하거나 만듭니다.
Cloud 프로젝트에 결제가 사용 설정되어 있는지 확인합니다. 프로젝트에 결제가 사용 설정되어 있는지 확인하는 방법을 알아보세요.

이 Codelab은 초보자를 포함한 모든 수준의 사용자와 개발자를 대상으로 합니다.

3. 설치

아직 Antigravity가 설치되어 있지 않다면 Antigravity를 설치하는 것부터 시작해 보겠습니다. 현재 제품은 미리보기로 제공되며 개인 Gmail 계정을 사용하여 시작할 수 있습니다.

다운로드 페이지로 이동하여 케이스에 해당하는 적절한 운영체제 버전을 클릭합니다. 애플리케이션 설치 프로그램을 실행하고 컴퓨터에 설치합니다. 설치를 완료한 후 Antigravity 애플리케이션을 실행합니다.

설정 중 주요 단계:

설정 흐름 선택: 이 Codelab에서는 처음부터 시작하는 것이 좋습니다.
검토 기반 개발 (권장): 이 옵션을 선택합니다. 이를 통해 상담사는 결정을 내리고 사용자에게 돌아와 승인을 받을 수 있으며 이는 인프라 운영에 매우 중요합니다.

그런 다음 에디터를 구성하고 Google에 로그인합니다. 마지막으로 이용약관에 동의합니다.

4. 인프라 설정: GKE 및 구성 커넥터

스킬을 빌드하려면 구성 커넥터 (KCC)가 수동으로 설치되고 네임스페이스 모드로 구성된 Google Cloud 환경이 필요합니다. 이를 통해 GCP 리소스를 Kubernetes 객체로 관리할 수 있습니다.

0단계: 환경 준비하기

1. 클러스터 기본 요건

필요한 기능이 사용 설정된 새 GKE 클러스터를 만듭니다.

# Set your variables
export PROJECT_ID=$(gcloud config get-value project)
export CLUSTER_NAME="kcc-ops-cluster"
export REGION="us-central1"

# Create the cluster
gcloud container clusters create ${CLUSTER_NAME} \
    --region ${REGION} \
    --release-channel "regular" \
    --workload-pool=${PROJECT_ID}.svc.id.goog \
    --logging=SYSTEM \
    --monitoring=SYSTEM

# Get cluster credentials
gcloud container clusters get-credentials ${CLUSTER_NAME} --region ${REGION}

2. 구성 커넥터 연산자 설치

연산자는 설치를 최신 상태로 유지합니다.

# Download the latest Config Connector operator
gcloud storage cp gs://configconnector-operator/latest/release-bundle.tar.gz release-bundle.tar.gz

# Extract the bundle
tar zxvf release-bundle.tar.gz

# Install the operator (Standard Cluster)
kubectl apply -f operator-system/configconnector-operator.yaml

3. 네임스페이스 모드 구성

ConfigConnector 리소스를 만들어 작동 모드를 지정합니다.

# configconnector.yaml
apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnector
metadata:
  name: configconnector.core.cnrm.cloud.google.com
spec:
  mode: namespaced
  stateIntoSpec: Absent

kubectl apply -f configconnector.yaml

4. ID 및 네임스페이스 만들기

이 실습에서는 default 네임스페이스와 전용 Google 서비스 계정 (GSA)을 사용합니다.

# Set your variables
export PROJECT_ID=$(gcloud config get-value project)
export NAMESPACE="default"

# Create the Google Service Account
gcloud iam service-accounts create kcc-identity --project ${PROJECT_ID}

# Grant permissions on the project
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com" \
    --role="roles/owner"

# Grant Metric Writer permissions
gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com" \
    --role="roles/monitoring.metricWriter"

# Bind GSA to KSA via Workload Identity
gcloud iam service-accounts add-iam-policy-binding \
    kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com \
    --member="serviceAccount:${PROJECT_ID}.svc.id.goog[cnrm-system/cnrm-controller-manager-${NAMESPACE}]" \
    --role="roles/iam.workloadIdentityUser"

5. 네임스페이스 구성

네임스페이스를 모니터링하는 ConfigConnectorContext를 만듭니다.

# configconnectorcontext.yaml
apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnectorContext
metadata:
  name: configconnectorcontext.core.cnrm.cloud.google.com
  namespace: default
spec:
  googleServiceAccount: "kcc-identity@${PROJECT_ID}.iam.gserviceaccount.com"
  stateIntoSpec: Absent

kubectl apply -f configconnectorcontext.yaml

6. 설치 확인

컨트롤러가 default 네임스페이스에 대해 준비될 때까지 기다립니다.

kubectl wait -n cnrm-system \
    --for=condition=Ready pod \
    -l cnrm.cloud.google.com/component=cnrm-controller-manager \
    -l cnrm.cloud.google.com/scoped-namespace=default

5. 에이전트 관리자: 미션 컨트롤

Antigravity는 오픈소스 Visual Studio Code (VS Code) 기반을 포크하지만 텍스트 편집보다 에이전트 관리를 우선시하도록 사용자 환경을 대폭 변경합니다. 인터페이스는 Editor와 Agent Manager라는 두 개의 기본 창으로 나뉩니다.

상담사 관리자

Antigravity를 실행하면 일반적으로 에이전트 관리자가 표시됩니다. 이 인터페이스는 관제 센터 대시보드 역할을 합니다. 고급 오케스트레이션을 위해 설계되었으며, 개발자가 여러 작업공간 또는 작업에서 비동기적으로 작동하는 여러 에이전트를 생성, 모니터링, 상호작용할 수 있습니다.

이 뷰에서 개발자는 설계자 역할을 합니다. 이들은 상위 수준 목표를 정의합니다. 이러한 각 요청은 전용 에이전트 인스턴스를 생성합니다. UI는 이러한 병렬 작업 스트림을 시각화하여 각 에이전트의 상태, 생성된 아티팩트 (계획, 결과, 차이점), 인간의 승인을 기다리는 요청을 표시합니다.

6. Antigravity 브라우저 및 아티팩트

Antigravity는 작업을 계획하고 완료하면서 아티팩트를 생성합니다. 리치 마크다운 파일, 아키텍처 다이어그램, 이미지, 브라우저 녹화, 코드 차이점 등이 있습니다.

아티팩트는 '신뢰 격차'를 해결합니다.

이전에는 에이전트가 '버그를 수정했습니다'라고 주장하면 개발자가 코드를 읽어 확인해야 했습니다. Antigravity에서 에이전트는 이를 증명하기 위해 아티팩트를 생성합니다.

아티팩트

Antigravity에서 생성되는 주요 아티팩트는 다음과 같습니다.

Task Lists: 코드를 작성하기 전에 생성된 구조화된 계획입니다.
Implementation Plan: 기술 세부정보가 포함된 설계된 변경사항
Walkthrough: 변경사항 및 테스트 방법 요약
Browser Recordings: UI 확인을 위한 브라우저 세션의 동영상 기록입니다.

Antigravity 브라우저

에이전트가 웹과 상호작용해야 하는 경우 브라우저 하위 에이전트를 호출합니다. 이 하위 에이전트는 클릭, 스크롤, 입력, 콘솔 로그 읽기를 할 수 있습니다. 특수 모델을 사용하여 Antigravity에서 관리하는 브라우저 내에서 열린 페이지에서 작동합니다.

7. 편집기 환경

편집기는 VS Code의 친숙함을 유지합니다. 여기에는 표준 파일 탐색기, 구문 강조 표시, 확장 프로그램 생태계가 포함됩니다.

주요 편집기 기능:

자동 완성: Tab을 눌러 수락한 스마트 추천입니다.
가져올 탭: 누락된 종속 항목을 추가하도록 제안합니다.
명령어 (Cmd + I): 자연어를 사용하여 인라인 자동 완성 기능을 트리거합니다.
에이전트 측면 패널 (Cmd + L): 에이전트 패널을 전환하여 질문하거나 @를 사용하여 파일을 참조합니다.

8. 의견 제공하기

Antigravity의 핵심은 의견을 손쉽게 수집할 수 있다는 점입니다. 이러한 아티팩트는 Google 문서 스타일 댓글로 상담사에게 의견을 제공하는 방법입니다.

계획이나 작업에 댓글을 추가할 때는 댓글을 제출해야 합니다. 이렇게 하면 에이전트가 원하는 방향으로 안내됩니다.

9. KCC Ops 스킬 빌드

이제 플랫폼을 이해했으므로 KCC Ops Skill을 빌드해 보겠습니다.

Kubernetes 구성 커넥터 (KCC)를 사용하면 GCP 리소스를 K8s 객체로 관리할 수 있습니다. 하지만 구성 드리프트, 규정 준수 위반, 실수로 인한 리소스 재생성을 방지하기 위한 안전 레일이 필요합니다.

1단계: 스킬 구조화

작업공간 루트에서 스킬의 디렉터리 구조를 만듭니다.

mkdir -p .agents/skills/kcc-ops/scripts
mkdir -p .agents/skills/kcc-ops/resources/policies/templates
mkdir -p .agents/skills/kcc-ops/resources/policies/constraints

2단계: SKILL.md 작성 (브레인)

SKILL.md은 에이전트의 메타데이터와 핵심 '황금률'을 정의합니다. .agents/skills/kcc-ops/SKILL.md 만들기:

---
name: kcc-ops
description: Assists with Config Connector (KCC) configuration, resource generation, and troubleshooting on Google Cloud.
---

# Config Connector (KCC) Operations Skill

Use this skill to manage Google Cloud resources using Kubernetes-style configuration (Config Connector).

## 🛑 GOLDEN RULE: Separate Generation from Application

**NEVER generate and apply a manifest in a single autonomous step.**

1. **Craft:** Write the generated manifest to a local file.
2. **Analyze:** Present the manifest to the user. Perform Impact Analysis and Dry Runs. Explain the consequences of the change (e.g., "If this topic is deleted, the attached subscription becomes orphaned").
3. **Wait:** Pause execution and explicitly wait for user permission to proceed.
4. **Apply:** Only run `kubectl apply` *after* the user has reviewed the manifest and the impact analysis, and then unequivocally confirmed you should proceed.

## Core Responsibilities

0. **Context Verification**: Verify the execution context (cluster, namespace, GCP project, user account) with the user before performing any operations.
1. **Installation & Health**: Verify KCC is properly installed and healthy on the target cluster.
2. **Resource Inventory**: Query and summarize existing KCC resources within a namespace.
3. **Brownfield Bulk Export (Adoption)**: Export existing GCP project resources into valid KCC YAML manifests.
4. **Manifest Generation**: Generate valid YAML manifests for GCP resources using KCC CRDs.
5. **Impact Analysis**: Identify ancillary services and resources (e.g., Cloud Run, Apps) that depend on a resource being modified.
6. **Change Differentiation**: Generate diff summaries for resource edits to support change control.
7. **Policy Compliance**: Vet KCC manifests against OPA/Gatekeeper policies.
8. **Troubleshooting**: Analyze resource status, and consult the troubleshooting guide to resolve reconciliation issues.

## Guidelines for Operations

### 0. Context Verification

Before performing **any operations or executing commands** (including health checks), you **MUST** verify the current execution context and obtain explicit user confirmation.

1. **Read Context:** Use commands like `kubectl config current-context`, `kubectl config view --minify -o jsonpath='{.contexts[0].context.namespace}'`, `gcloud config get-value project`, and `gcloud config get-value account` to determine the active environment.
2. **Present & Ask:** Show this information to the user clearly (e.g., "I see my context is X, namespace is Y, project is Z, and account is A. Is this correct?").
3. **Wait:** Do not proceed with any other steps or scripts until the user has confirmed or provided corrections.

### 1. Installation & Health Check

Before performing operations, ensure the environment is ready:

- **Automation**: You MUST use `./scripts/check-health.sh` to verify namespaces, controllers, and CRDs. Do not use manual kubectl commands for health checks, as the script enforces standard formatting and context verification.

### 2. Resource Inventory & Discovery

To understand the current state of infrastructure:

- **Automation**: You MUST use `./scripts/inventory.sh` to get a summary table of all KCC resources. Do not use manual kubectl queries, as the script is optimized to securely discover all CRDs with context validation.

### 3. Manifest Structure

- All KCC resources belong to the `cnrm.cloud.google.com` API group.
- Use the `cnrm.cloud.google.com/project-id` annotation for cross-project resource management if not using Namespaced Mode.
- Always include `apiVersion`, `kind`, `metadata`, and `spec`.

### 4. Official Resource Reference (Agent Action)

When generating or troubleshooting manifests, you **must not guess** the API schema. Always consult the [Official Config Connector Reference](https://cloud.google.com/config-connector/docs/reference/overview) for the exact API version, kind, and required fields for the specific resource and cross reference with the official [github repository](https://github.com/GoogleCloudPlatform/k8s-config-connector/tree/master/config/crds/resources).

### 5. Troubleshooting Checklist

When a resource is not reconciling (check `kubectl get <kind> <name> -o yaml`):

- **Ready Condition**: Look for `status.conditions` where `type: Ready` and `status: "False"`.
- **Reason/Message**: Check the `reason` and `message` fields in the status conditions.
- **Consult the Guide**: Immediately check `./resources/troubleshooting-guide.md` for definitions of the error reason (e.g. `DependencyInvalid`, `ManagementConflict`) and follow its resolution steps.
- **Common Issues**:
  - Permissions: The KCC service account lacks IAM roles.
  - Quotas: GCP project quota exceeded.
  - Conflicts: Resource already exists or is managed by another tool.
  - Immutable Fields: Attempting to change a field that requires resource recreation. Look for "Update failed" errors related to immutable fields.
  - Reference Resolution: Check if the resource is waiting for a dependency (e.g., `referenced project not found`).

### 6. Impact Analysis (Ancillary Services)

Before modifying a resource (e.g., GCS Bucket, Pub/Sub Topic), verify whatElse depends on it:

- **Reference Search (Cluster-wide)**: Search for other KCC resources that reference the item.

  ```bash
  # Example: Find resources referencing a bucket named 'my-data-bucket'
  kubectl get-all -n <namespace> -o yaml | grep -C 5 "my-data-bucket"
  ```

- **IAM-based Analysis**: Check for IAM Service Accounts that have roles on the specific resource. A Cloud Run job or GKE Workload Identity might be using those permissions.
- **Common Ancillary Dependencies**:
  - **Storage Buckets**: Look for Cloud Run/GKE mounts (CSI), Cloud Functions triggers, or Dataflow jobs.
  - **Networks**: Check for Firewall rules, Forwarding rules, and GKE cluster assignments.
  - **IAM Policies**: Changing a policy might break access for external applications not managed by KCC.
- **Resource Graph**: Use `gcloud asset search-all-resources` to find resources that might have implicit links.

### 3. Policy Compliance & Best Practices

Evaluate KCC manifests against security and governance policies. The vetting tool supports three source modes:

- **Built-in Mode (Default)**: Uses the skill's high-fidelity `v1beta1` library (300+ Anthos constraints).
  - `Usage: ./scripts/vet-policy.sh <manifest-path>`
- **Remote Mode**: Clones and vets against an external Git repository.
  - `Usage: ./scripts/vet-policy.sh <manifest-path> <repo-url> [git-ref]`
  - ⚠️ **Note**: External libraries like the legacy GCP Policy Library may be out-of-date and cause schema validation errors with modern `gator`.
- **Local Mode**: Vets against a local directory of policies.
  - `Usage: ./scripts/vet-policy.sh <manifest-path> /path/to/local/policies`

**Interaction Model:**

1. Call `./scripts/vet-policy.sh` with the appropriate arguments.
2. Interpret the `=== KCC Best Practices ===` and `=== OPA/Gatekeeper ===` reports.
3. Supplement automated findings with manual review for specific security features not yet covered by OPA (e.g., `publicAccessPrevention: enforced`, `versioning: {enabled: true}`).

  ```bash
  # Run the skill's helper script (repo URL and branch are optional)
  ./scripts/vet-policy.sh manifest.yaml [policy-repo-url] [policy-ref]
  ```

## Skill Assets

This skill includes additional resources to streamline operations:

- **`scripts/`**: Automation scripts (e.g., `vet-policy.sh`, `bulk-export.sh`).
- **`examples/`**: Reference KCC manifests (e.g., `restricted-bucket.yaml`).
- **`resources/`**: Common templates, documentation snippets, and troubleshooting guides (e.g., `troubleshooting-guide.md`).

### 4. Safety Rails for Applying Manifests

Before applying any KCC manifest update to an existing resource, you MUST:

- **Verify Immutable Fields**: Call `./scripts/verify-immutable.sh <manifest-path>` to detect updates to fields (like `location`, `name`, `project-id`) that trigger destructive resource recreation.
- **Explain Impact**: If destructive changes are detected, you MUST warn the user and explain the downtime/data loss implications before requesting approval.

### 5. Emergency Recovery & Troubleshooting

If a resource is stuck in a "Deletion" or "Error" state:

- **Check for Abondon Flag**: Check if the resource has the `cnrm.cloud.google.com/deletion-policy: abandon` annotation. If it does, you will need to remove the annotation and then force delete the resource.
- **Force Delete**: Call `./scripts/force-delete.sh <kind> <name> [namespace]` to bypass Kubernetes finalizers and remove the resource from the cluster.
- **Orphan Warning**: Inform the user that force-deleting a KCC object may leave an orphaned resource in Google Cloud that requires manual cleanup.

### 6. Change Differentiation

When editing an existing resource, always generate a diff to summarize the change for reviewers or Git history:

- **Local Diff**:

  ```bash
  # Diff a local file against the cluster state
  kubectl diff -f modified-resource.yaml
  ```

- **Commit Summary Template**:

  ```text
  [KCC Change] Update <ResourceName> (<Kind>)
  - Field 'spec.foo' changed from 'X' to 'Y'
  - Impact: Ancillary service <ServiceName> will see updated <Config>
  ```

### 9. Best Practices

- **Namespaced Mode**: Prefer namespaced mode for better isolation.
- **Sensitive Data**: Use `spec.credential.secretRef` or similar for sensitive fields.
- **Resource Naming**: Use consistent naming conventions that match your Kubernetes/GCP standards.
- **Annotations**:
  - `cnrm.cloud.google.com/deletion-policy: abandon`: Keep GCP resource on KCC deletion.
  - `cnrm.cloud.google.com/state-into-spec: absent`: Prevents KCC from syncing GCP state back into the Kubernetes object (useful for avoiding reconciliation loops on fields like node counts).

## Common Resource Examples

### Compute Instance

```yaml
apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeInstance
metadata:
  name: instance-sample
  annotations:
    cnrm.cloud.google.com/project-id: "my-project-id"
spec:
  machineType: n1-standard-1
  zone: us-central1-a
  bootDisk:
    initializeParams:
      sourceImage: projects/debian-cloud/global/images/family/debian-11
  networkInterface:
    - networkRef:
        name: default
```

### Storage Bucket

```yaml
apiVersion: storage.cnrm.cloud.google.com/v1beta1
kind: StorageBucket
metadata:
  name: bucket-sample
spec:
  location: US
```

### Pub/Sub Topic & Subscription

```yaml
apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubTopic
metadata:
  name: order-events-topic
---
apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
kind: PubSubSubscription
metadata:
  name: order-processor-sub
spec:
  topicRef:
    name: order-events-topic
  ackDeadlineSeconds: 30
```

3단계: 인벤토리 도구 구현

KCC 리소스를 검색할 .agents/skills/kcc-ops/scripts/inventory.sh를 만듭니다.

#!/bin/bash
# List all resources in the cnrm.cloud.google.com group
KCC_KINDS=$(kubectl api-resources --no-headers | awk '/\.cnrm\.cloud\.google\.com/ {print $1}')
KCC_KINDS_CSV=$(echo "$KCC_KINDS" | paste -sd, -)

printf "%-40s %-30s %-10s %s\n" "KIND" "NAME" "READY" "STATUS/MESSAGE"
kubectl get "$KCC_KINDS_CSV" -A -o custom-columns="KIND:.kind,NAME:.metadata.name,READY:.status.conditions[?(@.type=='Ready')].status,MSG:.status.conditions[?(@.type=='Ready')].message" --ignore-not-found --no-headers

4단계: 정책 심사 로직 추가

.agents/skills/kcc-ops/scripts/vet-policy.sh를 만듭니다. 이 스크립트는 gator를 사용하여 OPA 정책에 대해 매니페스트를 검사합니다.

#!/bin/bash
MANIFEST=$1
SKILL_ROOT=$(dirname "$(dirname "$0")")
POLICY_SRC="$SKILL_ROOT/resources/policies"

echo "=== OPA/Gatekeeper Policy Vetting ==="
if command -v gator >/dev/null 2>&1; then
    gator test -f "$MANIFEST" -f "$POLICY_SRC/templates" -f "$POLICY_SRC/constraints"
else
    echo "Gator not found. Skipping OPA audit."
fi

5단계: 변경 불가능한 필드 보호 구현

이는 중요한 안전 장치입니다. .agents/skills/kcc-ops/scripts/verify-immutable.sh 만들기:

#!/bin/bash
MANIFEST=$1
KIND=$(grep "^kind:" "$MANIFEST" | awk '{print $2}')
NAME=$(grep "name:" "$MANIFEST" | head -n 1 | awk '{print $2}')

# Check for changes in common immutable fields
IMMUTABLE_FIELDS=("location" "project-id" "name" "zone" "region")
TEMP_FILE=$(mktemp)
kubectl get "$KIND" "$NAME" -o yaml > "$TEMP_FILE" 2>/dev/null

for field in "${IMMUTABLE_FIELDS[@]}"; do
    NEW=$(grep "$field:" "$MANIFEST" | awk '{print $2}')
    OLD=$(grep "$field:" "$TEMP_FILE" | awk '{print $2}')
    if [ -n "$NEW" ] && [ -n "$OLD" ] && [ "$NEW" != "$OLD" ]; then
        echo "🚨 WARNING: Immutable field '$field' is changing! Potential resource recreation."
    fi
done
rm "$TEMP_FILE"

6단계: 긴급 복구 (강제 삭제)

.agents/skills/kcc-ops/scripts/force-delete.sh 만들기:

#!/bin/bash
KIND=$1; NAME=$2; NS=${3:-default}
echo "Removing finalizers for $KIND/$NAME in $NS..."
kubectl patch "$KIND" "$NAME" -n "$NS" -p '{"metadata":{"finalizers":null}}' --type=merge
kubectl delete "$KIND" "$NAME" -n "$NS" --wait=false

7단계: 리소스 마무리

모든 스크립트를 실행 가능하게 만듭니다.

chmod +x .agents/skills/kcc-ops/scripts/*.sh

10. 새 스킬 테스트

이제 새 대화를 시작하고 기술을 테스트해 보세요.

검색: @kcc-ops Show me all KCC resources in my cluster.
규정 준수: StorageBucket을 사용하여 파일 bucket.yaml를 만듭니다. 요청: @kcc-ops Vet my bucket.yaml manifest.
안전: bucket.yaml에서 기존 버킷의 location를 업데이트하려고 합니다. 요청: @kcc-ops Verify my bucket.yaml for immutable changes.

에이전트가 올바른 스크립트를 지능적으로 선택하고 SKILL.md의 '황금률'을 따르는 방식을 확인하세요.

11. 에이전트 보안

AI 에이전트에게 터미널 액세스 권한을 부여하는 것은 강력하지만 제어가 필요합니다.

Antigravity - Settings - Terminal로 이동하여 Allow List(허용 목록)와 Deny List(거부 목록)를 살펴봅니다.

허용 목록: 여기에 ls, kubectl get, 스킬 스크립트를 추가합니다.
거부 목록: 에이전트가 항상 권한을 요청하도록 sudo, rm -rf 또는 기타 파괴적인 명령어를 추가합니다.

12. 결론

축하합니다. Antigravity 설치에서 정확도가 높은 KCC Operations Skill 구축으로 전환했습니다.

학습한 내용은 다음과 같습니다.

맞춤 bash 도구로 에이전트를 확장하는 방법
운영 '황금률'을 SKILL.md로 인코딩하는 방법
복잡한 인프라 관리를 위한 안전 장치를 제공하는 방법

다음 단계

OPA 제약 조건을 더 추가하여 resources/policies 폴더를 확장하거나 check-health.sh 스크립트를 추가하여 클러스터 준비 상태 확인을 자동화하세요.