Google Cloud 운영을 위한 AI 자동화 공식 Agent Skills와 운영지식 스킬

 

처음에는 단순한 “프롬프트 템플릿 모음” 정도로 보는데, 실제로는 Google이 다음 방향을 공식화한 사례에 가깝습니다.

• AI Agent는 이제
  • 거대한 범용 컨텍스트를 계속 넣는 방식이 아니라
  • 작업 단위별 “압축된 전문지식(skill)”을 필요 시 로드하는 구조로 간다
• Google Cloud 운영 지식 자체를
  • Agent 친화적 형태로 재구성하기 시작했다
• 문서 중심이 아니라
  • “행동 가능한 운영 지식(executable operational knowledge)” 중심으로 이동한다

이게 핵심입니다.

왜 기존 RAG보다 중요한가

기존 방식

Agent
  ↓
Vector Search
  ↓
긴 문서 검색
  ↓
관련 부분 추출
  ↓
LLM 입력

문제

• 문서가 너무 김
• 불필요한 정보 많음
• 컨텍스트 낭비
• 최신 운영 패턴 반영 어려움
• 제품별 Best Practice가 균일하지 않음

300x250

google/skills 방식

Agent
  ↓
필요한 Skill만 선택
  ↓
압축된 운영지식 로딩
  ↓
즉시 실행

즉

• 검색(Search) 중심이 아니라
• “Capability Injection” 구조입니다.

이 차이가 큽니다.

Skill 구조의 핵심 개념

보통 구조는 이런 형태입니다.

skills/
 ├── bigquery/
 │    ├── SKILL.md
 │    ├── examples/
 │    ├── scripts/
 │    └── references/
 │
 ├── gke/
 ├── cloud-run/
 └── gemini-api/

왜 SKILL.md가 중요한가

여기 핵심은 단순 설명 문서가 아닙니다.

SKILL.md는 사실상

Agent Runtime Instruction

역할을 합니다.

예시 개념

# BigQuery Optimization Skill

## When to use
- Query cost optimization
- Partition tuning
- Slow queries

## Recommended steps
1. Check partitioning
2. Verify clustering
3. Use dry-run
4. Estimate bytes scanned

## Avoid
- SELECT *
- Unbounded scans

이렇게 되면 Agent는

• 언제 써야 하는지
• 어떤 절차를 따라야 하는지
• 어떤 실수를 피해야 하는지

를 매우 짧은 토큰으로 학습합니다.

“운영 플레이북”의 AI화

기존 운영 문서

위키
Runbook
Confluence
PDF
장문의 가이드

↓

Agent Skills

행동 가능한 최소 운영지식

으로 압축됩니다.

보안 관점에서 매우 중요한 이유

이 구조는 보안 운영에도 엄청 중요합니다.

 

왜냐하면 보안은 원래

• Runbook
• 대응 절차
• 점검 기준
• 운영 가이드
• 예외 처리
• 승인 정책

이 매우 많기 때문입니다.

기존 SOC 운영

1. SIEM 경고 발생
2. 분석가가 Wiki 검색
3. 대응 절차 확인
4. 수동 대응

Skill 기반 SOC

1. Agent가 Alert 분석
2. 필요한 Detection Skill 로딩
3. 대응절차 자동 실행
4. 결과 요약

실제 보안 Skill 예시

예시

skills/
 ├── wazuh-triage/
 ├── elastic-edr-hunting/
 ├── ransomware-response/
 ├── phishing-analysis/
 ├── cloud-iam-review/
 └── kubernetes-security/

예시 SKILL.md

# Kubernetes Security Review

## When to use
- New cluster onboarding
- Security audit
- Incident review

## Checks
- RBAC excessive privilege
- Anonymous API access
- Pod security policy
- Privileged containers
- HostPath usage

## Commands
kubectl auth can-i --list
kubectl get clusterrolebindings

이런 구조는 보안 자동화와 굉장히 잘 맞습니다.

MCP와의 차이

많이 혼동하는 부분입니다.

MCP

MCP는

"도구 연결 프로토콜"

입니다.

• DB 연결
• Slack 연결
• Browser 연결
• Shell 연결

같은 “Tool Access Layer” 입니다.

Skills

Skills는

"행동지식/운영지식"

입니다.

• 무엇을 해야 하는지
• 어떤 순서로 해야 하는지
• 어떤 실수를 피해야 하는지

를 제공합니다.

둘의 관계

실제 Agent 구조

Agent
 ├── MCP (도구 접근)
 └── Skills (운영지식)

즉

• MCP = 손발
• Skill = 업무지식

에 가깝습니다.

앞으로 중요한 흐름

Google 방향성을 보면

문서 검색 시대
→
Skill Injection 시대

로 가고 있습니다.

 

그리고 이것은

• OpenAI
• Anthropic
• Google
• Cursor
• Claude Code
• Devin 계열

모두 동일한 방향으로 가고 있습니다.

실무적으로 가장 중요한 포인트

사실 기업 입장에서 핵심은 이것입니다.

"사내 운영지식을 Skill로 변환"

사내 보안점검 절차
장애 대응 절차
계정 승인 프로세스
배포 정책
IAM 정책
인프라 표준

↓

AI Agent Skill

이게 앞으로 기업 AI 내재화의 핵심 중 하나가 될 가능성이 매우 큽니다.

• 보안 점검 자동화
• SIEM 운영
• 정책 관리

같은 것들은 전부

Skill화하기 좋은 영역

입니다.

 

특히

• 반복 대응
• 운영 절차
• 점검 기준
• 승인 프로세스

가 명확하기 때문입니다.

현실적인 사내 적용 구조 예시

[LLM Agent]

 ├── MCP
 │    ├── Slack
 │    ├── Wazuh
 │    ├── Kubernetes
 │    ├── Jira
 │    └── GitLab
 │
 └── Skills
      ├── Incident Response
      ├── IAM Audit
      ├── Malware Triage
      ├── VPN Account Review
      └── Kubernetes Hardening

이 구조가 앞으로 매우 일반화될 가능성이 높습니다.

 

google/skills는 단순 문서 저장소가 아니라

"운영지식을 AI Agent 실행 단위로 재구성하는 시작점"

이라는 점이 진짜 중요합니다.

 

google/skills는 단순한 문서 저장소가 아니라, AI 에이전트가 Google Cloud 작업을 더 정확하고 일관되게 수행하도록 돕는 “작업별 지식 패키지” 모음으로 보는 것이 가장 적절합니다.

핵심은 아주 단순합니다.

• 예전 방식은 에이전트가 긴 문서, 위키, 매뉴얼을 계속 읽어야 했습니다.
• skills 방식은 작업에 필요한 지식만 짧고 구조화된 형태로 꺼내 씁니다.
• 그래서 에이전트는 “모든 것을 기억하는 것”이 아니라, 필요할 때 필요한 절차만 불러와 행동하게 됩니다.

이 구조는 특히 클라우드 운영, 배포, 장애 대응, 보안 점검처럼 정답은 있는데 실수 가능성이 높은 업무에서 효과가 큽니다.

왜 이런 방식이 필요한가

AI 에이전트가 실제 운영 업무를 할 때 흔히 생기는 문제는 다음과 같습니다.

1. 문서가 너무 길어서 핵심이 묻힙니다.
2. 같은 작업도 담당자마다 수행 방식이 달라집니다.
3. 작은 설정 실수 하나가 비용 증가, 장애, 보안 문제로 이어집니다.
4. 범용 에이전트는 “그럴듯한 답”은 잘 내지만, 운영 표준을 항상 따르지는 못합니다.

google/skills는 이 문제를 줄이기 위해, 각 작업을 짧은 실행 지침 형태로 쪼갭니다.

 

즉, 에이전트는 “Google Cloud 전체를 아는 똑똑한 AI”가 아니라, BigQuery용 작업 지식, GKE용 운영 지식, Cloud Run용 배포 지식, Gemini API용 연동 지식을 필요할 때 꺼내 쓰는 구조가 됩니다.

skills의 기본 구조

보통 skill은 다음 같은 생각으로 구성됩니다.

- 언제 이 스킬을 써야 하는가
- 무엇을 먼저 확인해야 하는가
- 어떤 순서로 작업해야 하는가
- 자주 생기는 실수는 무엇인가
- 필요하면 어떤 명령이나 점검 항목을 써야 하는가

즉, 단순 설명이 아니라 행동 지침(runbook)에 가깝습니다.

 

예를 들면 이런 식입니다.

# BigQuery Query Optimization Skill

## 사용 시점
- 쿼리 비용이 클 때
- 성능이 느릴 때
- 파티션/클러스터링 여부를 점검해야 할 때

## 우선 점검
1. 파티션 필터가 있는가
2. SELECT *를 쓰고 있지 않은가
3. 불필요한 전체 스캔이 있는가
4. 클러스터링을 활용할 수 있는가

## 주의사항
- 대용량 테이블에 무조건 전체 스캔을 걸지 말 것
- 비용 추정 없이 실행하지 말 것

이런 문서는 길지 않지만, 에이전트가 실제로 행동할 때는 매우 강력합니다.

google/skills가 중요한 이유

이 저장소의 가치는 “문서를 예쁘게 정리했다”가 아닙니다.
진짜 가치는 에이전트에게 전문 운영 지식을 작은 단위로 주입하는 표준 방식을 보여준다는 데 있습니다.

즉, 다음과 같은 변화가 일어납니다.

• 문서 중심 → 작업 중심
• 범용 지식 → 도메인 특화 지식
• 긴 매뉴얼 → 짧은 실행 규칙
• 검색 후 판단 → 사전 정리된 절차에 따른 실행

이건 단순 생산성 향상이 아니라, 운영 품질의 표준화에 가깝습니다.

BigQuery 쿼리 작성 보조

이 예시의 핵심은 “쿼리를 만들어준다”가 아닙니다.
핵심은 비용과 성능까지 고려한 쿼리 작성 습관을 에이전트에 주입한다는 점입니다.

일반적인 범용 에이전트

• SELECT *를 자주 만듭니다.
• 파티션 필터를 빼먹을 수 있습니다.
• 결과는 맞지만 비용이 큽니다.
• 전체 테이블 스캔을 유발할 수 있습니다.

skills를 적용한 에이전트

• 먼저 테이블이 파티션되어 있는지 봅니다.
• 쿼리에 파티션 조건이 들어갔는지 확인합니다.
• 필요한 컬럼만 선택하도록 유도합니다.
• 클러스터링을 고려합니다.
• 실행 전에 비용 추정을 확인하는 습관을 넣습니다.

실제로 달라지는 점

예를 들어 사용자가 다음처럼 요청했다고 해보겠습니다.

“지난 30일간 주문 데이터를 분석하는 쿼리 만들어줘”

범용 에이전트는 단순히 orders 테이블에 대해 날짜 조건만 붙인 쿼리를 줄 수 있습니다.
하지만 BigQuery용 스킬이 있으면 다음을 먼저 챙깁니다.

• 날짜 필터가 파티션 컬럼과 맞는가
• SELECT * 대신 필요한 컬럼만 뽑는가
• 집계가 가능한 위치에서 먼저 줄일 수 있는가
• 대용량 조인 시 조인 키와 순서를 어떻게 둘 것인가

즉, 결과적으로 더 싸고 더 빠른 쿼리가 나올 가능성이 높아집니다.

GKE 운영 작업

GKE는 단순 배포 도구가 아니라, 실제로는 클러스터, 네임스페이스, RBAC, 리소스 제한, 롤아웃 전략, 관측성이 모두 맞물린 운영 영역입니다.

스킬이 없을 때

에이전트가 “배포해드릴게요”라고 하면서도

• 네임스페이스 확인을 생략하거나
• 리소스 requests/limits를 대충 잡거나
• 롤아웃 중단 조건을 고려하지 않거나
• readiness/liveness probe 점검을 빼먹을 수 있습니다.

스킬이 있을 때

GKE 스킬은 에이전트가 작업 전에 다음 순서를 따르도록 돕습니다.

1. 대상 클러스터와 네임스페이스 확인
2. 현재 배포 상태 확인
3. 리소스 요청량과 제한 확인
4. 롤아웃 전략 확인
5. 모니터링 및 로그 확인 포인트 확인
6. 문제 발생 시 롤백 기준 확인

실제 예시

사용자가 이렇게 말합니다.

“GKE에 새 서비스 배포해줘”

에이전트는 바로 배포하지 않고 먼저 확인합니다.

• 어떤 네임스페이스에 넣을지
• 서비스 계정은 무엇인지
• CPU/메모리 요청량은 충분한지
• HPA를 쓸지
• ingress 설정이 필요한지
• 배포 후 어떤 메트릭을 볼지

즉, 스킬은 배포 명령 자체보다 배포 전후 체크리스트를 자동으로 떠올리게 만드는 장치입니다.

Cloud Run 배포

Cloud Run은 비교적 단순해 보이지만, 실무에서는 다음이 중요합니다.

• 환경변수 구성
• 런타임 설정
• 트래픽 분배
• 롤백 전략
• 관측 지표
• 권한과 인증

스킬이 주는 가치

에이전트가 Cloud Run 배포를 도울 때는 단순히 “배포 명령”만 주는 것이 아니라, 아래를 함께 생각하게 됩니다.

• 새 리비전을 올리기 전에 확인할 것
• 트래픽을 100% 바로 넘길지, 점진 배포할지
• 실패 시 이전 리비전으로 되돌릴 기준은 무엇인지
• 로그와 메트릭은 어디서 확인할지
• 외부 공개 여부와 인증은 어떻게 둘지

체감되는 효과

Cloud Run은 보통 빠르게 배포할 수 있어서, 오히려 작은 실수가 더 자주 발생합니다.
스킬이 있으면 에이전트가 배포 절차를 기계적으로 따라가므로:

• 누락된 설정 감소
• 롤백 준비 누락 감소
• 관측 포인트 누락 감소

이런 효과가 납니다.

Gemini API 연동

Gemini API 관련 스킬은 특히 반복 작업에 유용합니다.

반복되는 질문

실무에서는 매번 비슷한 고민이 생깁니다.

• 어떤 모델을 써야 하는가
• 프롬프트는 어떻게 구성해야 하는가
• 응답 길이는 어떻게 제한할 것인가
• 스트리밍이 필요한가
• 안전성 설정은 어떻게 둘 것인가
• 호출 실패 시 재시도 전략은 무엇인가

스킬이 있으면

에이전트가 단순히 API 예제를 복사하는 대신, 다음을 반영할 수 있습니다.

• 목적에 맞는 모델 선택
• 최소한의 프롬프트 구조
• 재시도 및 예외 처리
• 토큰/비용 고려
• 입력 검증
• 출력 형식 고정

즉, Gemini API 스킬은 “API를 호출하는 코드”를 넘어서,
안정적으로 운영 가능한 연동 방식을 반복 사용하게 해 줍니다.

온보딩 / 인증 / 네트워크 관측

이 영역은 특히 기업 환경에서 중요합니다.
신규 작업자가 처음 어떤 시스템을 다룰 때 필요한 정보는 대개 “전체 문서”가 아니라 “당장 필요한 절차”입니다.

온보딩

• 어떤 계정이 필요한지
• 어떤 권한을 먼저 받아야 하는지
• 접근 승인 절차는 무엇인지
• 초기 점검 순서는 무엇인지

인증

• 서비스 계정 생성 기준
• 키 관리 방식
• 토큰 사용 방식
• 비밀 정보 보관 방식

네트워크 관측

• 어떤 로그를 봐야 하는지
• 연결 실패 시 어디부터 확인할지
• DNS, LB, ingress, firewall 중 무엇을 먼저 볼지
• latency, error rate, packet loss 중 어떤 지표가 중요한지

이런 내용은 사람마다 기억하기 어렵기 때문에, 스킬 형태가 매우 잘 맞습니다.

작업 흐름 예시를 더 현실적으로 풀어보면

사용자가 이렇게 요청했다고 가정해 보겠습니다.

“GKE에서 새 서비스 배포해줘”

이때 에이전트의 흐름은 다음과 같습니다.

1단계: 작업 분류

에이전트는 이 요청이 “GKE 배포 작업”임을 인식합니다.

2단계: 관련 스킬 로드

GKE 관련 스킬을 불러와서 다음을 확인합니다.

• 배포 전 체크리스트
• 리소스 요구사항
• 네임스페이스 규칙
• probe 설정
• 롤백 조건
• 관측 포인트

3단계: 실제 도구 실행

이제 필요한 경우 MCP나 다른 툴을 사용해 실제 GKE API, kubectl, 배포 파이프라인과 연결합니다.

여기서 중요한 점은

• 스킬은 판단 기준
• 도구는 실행 수단

이라는 분리입니다.

즉, 스킬이 “무엇을 확인해야 하는지” 알려주고, MCP나 외부 툴이 “실제로 무엇을 실행할지” 처리합니다.

4단계: 결과 검증

배포 후에는 다음을 확인합니다.

• Pod가 정상 기동했는가
• readiness probe가 정상인가
• 로그 에러가 없는가
• 트래픽이 제대로 들어오는가
• 이전 버전보다 문제가 없는가

이 전체 흐름이 표준화되면, 에이전트는 단순한 자동화 도구가 아니라 운영 보조자가 됩니다.

체감 효과를 더 구체적으로 보면

1. 컨텍스트 절약

긴 매뉴얼을 계속 붙이지 않아도 됩니다.
에이전트는 필요한 스킬만 불러와서 작업합니다.

2. 일관성 향상

사람마다 다른 습관이 줄어듭니다.
표준 절차를 따르게 되므로 결과 편차가 줄어듭니다.

3. 오류 감소

특히 다음 같은 실수를 줄이는 데 효과적입니다.

• 파티션 필터 누락
• 과도한 권한 사용
• probe 설정 누락
• 롤백 미준비
• 관측 포인트 누락

4. 도메인 특화 품질 향상

범용 에이전트는 뭐든 할 수 있지만, 깊이는 부족할 수 있습니다.
스킬은 특정 작업에 대한 깊이를 보완합니다.

보안 관점에서 보면 더 의미가 큽니다

사용자 환경처럼 보안과 운영이 함께 있는 조직에서는 skills 방식이 특히 유용합니다.

왜냐하면 보안 업무는 본질적으로 반복되는 절차와 판단 기준의 집합이기 때문입니다.

예를 들면

• 계정 승인 절차
• 접근 권한 점검
• 사고 대응 절차
• 로그 확인 순서
• 예외 승인 기준
• 클라우드 보안 설정 검토
• Kubernetes 하드닝 점검

이런 것들은 모두 스킬로 만들기 좋은 대상입니다.

보안 운영에 적합한 스킬 예시

- IAM Review Skill
- Cloud Audit Log Triage Skill
- Kubernetes Hardening Skill
- Incident Triage Skill
- Ransomware Response Skill
- Phishing Analysis Skill
- Secret Exposure Check Skill

이런 스킬이 있으면 에이전트는 단순히 “의심됩니다”라고 말하는 수준을 넘어서,
어떤 순서로 확인하고 어떤 기준으로 판단할지까지 따라갈 수 있습니다.

MCP와의 관계를 다시 정리하면

많이 헷갈리기 쉬운 부분이라 한 번 더 정리하면 좋습니다.

MCP

• 외부 시스템과 연결하는 통로입니다.
• GCP API, Slack, GitHub, Kubernetes, 로그 시스템 등을 실제로 조작하게 해 줍니다.

Skills

• 그 도구를 어떻게 쓸지 알려주는 운영 지식입니다.
• 배포 전에 무엇을 확인해야 하는지
• 어떤 순서를 따를지
• 어떤 실수를 막아야 하는지 알려줍니다.

즉

• MCP는 손
• Skills는 머리 속의 절차서

에 가깝습니다.

둘은 경쟁 관계가 아니라 서로 보완 관계입니다.

실제 조직에 적용하면 어떤 모습이 되는가

사내에서 가장 현실적인 구조는 다음과 같습니다.

Agent
 ├─ MCP 연결
 │   ├─ Kubernetes
 │   ├─ Cloud Logging
 │   ├─ Slack
 │   ├─ Ticket System
 │   └─ Git Repository
 │
 └─ Skills
     ├─ 배포 절차
     ├─ 장애 대응
     ├─ IAM 점검
     ├─ 보안 검토
     └─ 운영 표준

이 구조의 장점은 아주 분명합니다.

• 도구는 여러 개인데 절차는 하나로 모을 수 있습니다.
• 담당자마다 다른 방식으로 일하지 않게 됩니다.
• 신규 담당자도 같은 기준으로 움직일 수 있습니다.
• 자동화 품질이 일정해집니다.

 

google/skills를 한 문장으로 정리하면, AI 에이전트가 Google Cloud 작업을 수행할 때 필요한 운영 지식을 작은 단위의 실행 규칙으로 분해해, 필요할 때만 불러 쓰게 만든 공식 스킬 체계라고 볼 수 있습니다.

조금 더 실무적으로 말하면

• 긴 문서를 계속 읽게 하는 방식이 아니라
• 작업별 핵심 절차만 꺼내 쓰게 해서
• 더 정확하고 더 일관되고 더 안전한 행동을 유도하는 구조입니다.

특히 BigQuery, GKE, Cloud Run, Gemini API처럼 반복성이 강하고 실수 비용이 큰 영역에서 효과가 크고, 계정 관리, 사고 대응, 클라우드 통제, 하드닝 점검 같은 업무를 스킬화하기에 매우 적합합니다.