많은 팀이 두 가지 나쁜 아이디어 사이에서 갈등하고 있습니다.

아이디어 #1: 에이전트에게 광범위한 Kubernetes 접근 권한을 부여하고, GPT-5, Claude, 또는 당신이 선택한 모델이 금요일 밤에 멍청한 짓을 하지 않기를 기도하는 것입니다.

아이디어 #2: 인프라에서 에이전트를 완전히 차단하고, 로그를 grep하고, 매니페스트(manifest)를 diff하고, 버전 업데이트를 기억하기 위해 계속해서 사람들을 깨우는 것입니다.

저는 둘 다 틀렸다고 생각합니다.

최근 제가 본 가장 안전한 패턴은 r/openclaw의 스레드에서 나왔습니다:
https://reddit.com/r/openclaw/comments/1v4rkpv/does_anyone_else_manage_their_kubernetes_cluster/

요약하자면 다음과 같습니다:

• OpenClaw는 클러스터 상태와 로그에 대해 읽기 전용(read-only) 권한을 가집니다.
• 비밀 정보(secrets)는 제외됩니다.
• OpenClaw는 풀 리퀘스트(pull requests)를 생성할 수 있습니다.
• Argo CD는 여전히 Git으로부터 배포를 수행합니다.
• 사람은 여전히 검토하고 병합(merge)합니다.

이것은 "에이전트가 운영 환경(prod)에서 마음대로 하게 두는 것"보다 훨씬 더 나은 롤백(rollback) 시나리오입니다.

핵심 아이디어: 에이전트에게 운영 환경 쓰기 권한을 주지 마세요

스레드에서 중요했던 문구는 이것이었습니다:

"그 후 클러스터에 오퍼레이터(operator, openclaw-rocks)와 함께 OpenClaw를 추가했고, 디버깅을 위해 상태와 로그(비밀 정보 제외)를 읽을 수 있는 서비스 계정(service account)과 풀 리퀘스트를 생성할 수 있는 권한을 부여했습니다."

그것이 바로 아키텍처(architecture)입니다.

다음과 같은 방식이 아닙니다:

• 에이전트로부터의 kubectl apply 실행
• 실행 중인 디플로이먼트(Deployments)에 대한 직접적인 패칭(patching)
• 모델이 자신감 있게 말한다는 이유로 운영 노드(production nodes)에 셸(shell) 접속

대신 다음과 같이 합니다:

• Kubernetes에서 읽기
• Git에 쓰기
• GitOps가 배포를 처리하도록 하기

이 분리가 모든 것을 결정합니다.

만약 OpenClaw가 잘못된 변경 사항을 제안한다면, 당신은 다음을 얻게 됩니다:

• diff
• 검토(review) 단계
• 브랜치 보호(branch protection)
• 되돌리기(revert) 경로
• 감사 추적(audit trail)

만약 에이전트가 실행 중인 클러스터를 직접 변형(mutate)한다면, 롤백은 순식간에 엉망이 됩니다.

읽기 전용 Kubernetes 접근 권한의 실제 모습

이 부분은 지루할 수 있지만, 그렇기 때문에 유용한 부분입니다.

최소한의 RBAC 역할은 매우 작을 수 있습니다:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata
...

그 지점부터 조심스럽게 확장해 나갈 수 있습니다.

예를 들어, 에이전트가 쓰기 권한 (write access) 없이 로그와 이벤트를 검사하기를 원한다면 다음과 같이 설정할 수 있습니다:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
...

그런 다음 해당 역할을 전용 서비스 계정 (ServiceAccount)에 바인딩합니다:

apiVersion: v1
kind: ServiceAccount
metadata:
...

이것만으로도 에이전트가 기본적으로 위험해지지 않으면서 유용하게 작동하기에 충분합니다.

읽기 전용 (Read-only) 권한으로 에이전트가 여전히 할 수 있는 일

사람들이 생각하는 것보다 훨씬 더 많은 일을 할 수 있습니다.

get, list, watch 권한을 통해 OpenClaw는 다음과 같은 작업을 수행할 수 있습니다:

• 실패하는 Pod 검사
• 컨테이너 로그 읽기
• 이벤트 (Events)와 재시작 (restarts) 간의 상관관계 분석
• 실행 중인 객체 (live objects)와 Git 매니페스트 (manifests) 비교
• 드리프트 (drift) 감지
• 버전 업데이트 (version bumps) 제안
• Slack 또는 Discord에 클러스터 상태 요약 전송
• 제안된 수정 사항을 포함한 PR (Pull Request) 생성

이것은 "자율적인 SRE가 플랫폼 팀을 대체한다"는 의미가 아닙니다.

그것은 훌륭한 온콜 (on-call) 어시스턴트라는 뜻입니다.

그리고 솔직히 말해서, 이것이 대부분의 팀이 가장 먼저 지향해야 할 자율성의 수준입니다.

읽기 전용이 곧 안전을 의미하는 것은 아니다

이 부분은 사람들이 대수롭지 않게 넘기는 지점입니다.

읽기 전용 권한이라 하더라도 여전히 많은 정보가 노출됩니다:

• 리소스 이름 (resource names)
• 이미지 태그 (image tags)
• 에러 메시지 (error messages)
• 이벤트 이력 (event history)
• 스택 트레이스 (stack traces)
• 환경 참조 (environment references)
• 로그가 정돈되지 않은 경우 고객 식별자 (customer identifiers)가 포함될 수도 있음

따라서 읽기 전용이라고 해서 무해한 것은 아닙니다.

이 방식을 사용할 때도 여전히 다음과 같은 조치가 필요합니다:

• 비밀 정보 제외 (secret exclusion)
• 로그 비식별화 (log redaction)
• 네임스페이스 범위 제한 (namespace scoping)
• 전용 서비스 계정 (dedicated service account)
• 철저한 RBAC 검토 프로세스

진정한 보안 질문은 "우리가 어떤 모델을 사용하는가?"가 아닙니다.

진짜 질문은 다음과 같습니다:

• 에이전트가 무엇을 읽을 수 있는가?
• 에이전트가 어디에 쓸 수 있는가?

그것이 실제 컨트롤 플레인 (control plane)입니다.

PR 리뷰가 안전 작업의 대부분을 수행하는 이유

동일한 스레드의 한 댓글 작성자는 다음과 같이 말했습니다:

"수동 리뷰 단계가 사람들이 생각하는 것보다 훨씬 더 많은 역할을 하고 있습니다. 작년에 제 OpenClaw는 리포지토리에 대한 PR 권한이 있었는데, 머지 큐 (merge queue)가 제가 예상했던 것보다 더 많은 잘못된 출력물을 잡아냈습니다."

이는 제 경험과도 일치합니다.

머지 게이트 (merge gate)는 단순히 형식적인 절차가 아닙니다.

그것은 다음과 같은 것들을 잡아냅니다:

• 기술적으로는 유효하지만 사용자의 환경에는 맞지 않는 Helm 값 (Helm value)
• 잘못된 셀렉터 (selector)를 가진 Kustomize 패치 (Kustomize patch)
• 마이그레이션 노트 (migration note)를 누락한 이미지 버전 업데이트 (image bump)
• 다른 워크로드 (workload)를 고갈시킬 수 있는 리소스 요청 (resource request)
• 명명 규칙 (naming conventions)을 깨뜨리는 "정리" 목적의 리팩토링 (refactor)

만약 에이전트 (agent)가 PR (Pull Request)만 작성한다면, 롤백 (rollback) 전략은 명확합니다:

git revert <commit>
git push origin main

그러면 Argo CD가 클러스터 (cluster)를 마지막으로 정상이었던 상태로 다시 조정 (reconcile)합니다.

이는 에이전트가 수행한 작업을 라이브 클러스터 (live cluster)에 직접 재구성하려고 시도하는 것보다 훨씬 더 극적으로 낫습니다.

에이전트 부분보다 GitOps 부분이 더 중요합니다

Argo CD가 이 과정을 합리적으로 만듭니다.

Git이 신뢰할 수 있는 단일 원천 (source of truth)이라면, 프로덕션 (production) 변경 사항은 검토된 매니페스트 (manifests)를 통해 발생합니다.

전형적인 설정:

argocd app set my-app --sync-policy automated
argocd app set my-app --self-heal

이를 통해 다음과 같은 이점을 얻을 수 있습니다:

• Git에서 클러스터로의 자동화된 동기화 (sync)
• 라이브 상태 (live state)가 일치하지 않을 때의 드리프트 수정 (drift correction)
• 커밋 (commits)과 연결된 깔끔한 배포 경로

하지만 Argo CD가 마법은 아닙니다.

잘못된 PR이 머지 (merge)되면, Argo CD는 그 잘못된 변경 사항을 충실하게 배포할 것입니다.

따라서 안전 모델은 다음과 같습니다:

1. 에이전트가 클러스터 상태를 읽음
2. 에이전트가 Git 변경 사항을 제안함
3. 사람이 차이점 (diff)을 검토함
4. 머지 (merge)가 발생함
5. Argo CD가 동기화 (sync)함
6. 롤백 (rollback)은 Git revert임

이것이 중요한 순서입니다.

Forgejo를 활용한 실질적인 이벤트 흐름

Reddit 설정에서 은근히 흥미로웠던 부분은 Forgejo였습니다.

원문 게시물은 OpenClaw가 Git 이벤트 (events)에 반응하여 코드나 설정 변경 사항을 작성하고, 검토를 위한 PR을 여는 흐름을 설명했습니다.

이는 에이전트를 인프라 (infra) 작업에 연결하는 매우 실용적인 방법입니다.

예를 들어, Forgejo Actions 워크플로 (workflow)는 풀 리퀘스트 (pull requests)와 이슈 (issues)에 반응할 수 있습니다:

on:
  pull_request:
    types: [opened, synchronize, reopened]
...

이제 이 루프 (loop)를 상상해 보세요:

1. 배포 체크 (deploy check) 실패
2. 이슈(issue) 또는 PR에 라벨(label) 추가
3. OpenClaw가 클러스터 상태와 로그를 조사
4. OpenClaw가 조사 결과에 대한 코멘트를 남기거나 수정 PR을 생성
5. 사람이 검토하고 머지(merge)
6. Argo CD가 Git으로부터 배포

이것이 실제 운영 모델 (operating model)입니다.

데모가 아닙니다.

"AI DevOps 에이전트"라는 보여주기식 연극도 아닙니다.

명확한 경계가 있는 깔끔한 워크플로우 (workflow)일 뿐입니다.

왜 Kubernetes MCP 직접 쓰기 권한으로 시작하지 않는가

Kubernetes MCP 서버를 직접 사용하는 것도 당연히 가능합니다.

만약 팀이 클러스터 전반에 걸친 광범위한 작업, Helm, exec, 메트릭 (metrics), 이벤트 (events), 그리고 CRUD 접근 권한이 필요하다면 그것이 적절한 도구가 될 수 있습니다.

하지만 폭발 반경 (blast radius)이 훨씬 더 커집니다.

제가 보는 트레이드오프 (tradeoff)는 다음과 같습니다:

만약 당신의 목표가 "에이전트가 운영 환경(production)의 root 권한을 갖지 않으면서 도움을 주게 하는 것"이라면, OpenClaw + PR + Argo CD 패턴이 더 나은 기본 설정입니다.

에이전트 주도 인프라 변경을 위한 최소한의 롤백 전략

이 시스템을 구축하고 있다면, 첫 번째 버전은 고통스러울 정도로 단순하게 유지할 것을 권장합니다.

1. 에이전트에게 읽기 전용 클러스터 권한 부여

필요한 것만 허용하세요:

• Pods
• logs
• Events
• Deployments
• 아마도 ConfigMaps
• Secrets는 제외
• 쓰기 동사 (write verbs) 제외

2. 에이전트에게 클러스터 쓰기 권한이 아닌 PR 권한 부여

에이전트는 다음을 할 수 있어야 합니다:

• 풀 리퀘스트 (pull requests) 생성
• 코멘트 남기기
• 리뷰 요청
• 아마도 라벨 업데이트

직접 배포할 수는 없어야 합니다.

3. 메인 브랜치 보호

머지 (merge) 시 리뷰가 필요하도록 브랜치 보호 (branch protection)를 사용하세요.

최소한 다음 사항을 포함해야 합니다:

• 필수 리뷰 (required review)
• CI 체크
• 직접 푸시 (direct pushes) 제한

4. Argo CD가 Git으로부터 배포하게 하기

실시간 변경 사항이 대역 외 (out of band)로 발생하지 않도록 하세요.

Git이 배포 API가 되어야 합니다.

5. 롤백이 필요하기 전에 미리 테스트하기

실제로 다음 과정을 연습해 보세요:

git revert <bad-commit>
git push origin main
argocd app get my-app

만약 장애 상황(incident) 중에 롤백이 기억력에 의존해야 한다면, 당신은 롤백 전략을 가지고 있는 것이 아닙니다.

이러한 방식으로 에이전트를 실행할 때 Standard Compute가 적합한 이유

이 Reddit 패턴이 정확히 짚어낸 한 가지는, 유용한 에이전트들은 많은 백그라운드 작업 (background work)을 수행한다는 점입니다.

그들은 로그를 검사합니다.
클러스터 상태를 요약합니다.
매니페스트 (manifests)를 비교합니다.
PR (Pull Request) 초안을 작성합니다.
실패한 체크 (checks)에 대응합니다.
채팅에 업데이트를 게시합니다.

이는 곧 수많은 모델 호출 (model calls)이 발생함을 의미합니다.

만약 당신이 OpenClaw, n8n, Make, Zapier 또는 커스텀 에이전트 워크플로 (agent workflows)를 하루 종일 실행하고 있다면, 토큰당 과금 (per-token billing) 방식은 금방 짜증스러운 일이 됩니다. 사람들은 실행 횟수를 제한하거나, 컨텍스트 (context)를 너무 공격적으로 줄이거나, 혹은 매 루프(loop)마다 비용이 발생한다는 느낌 때문에 유용한 자동화를 꺼버리기 시작합니다.

이것이 바로 이러한 설정에서 Standard Compute가 흥미로운 이유입니다.

Standard Compute는 다음과 같은 기능을 제공합니다:

• 고정된 월간 가격으로 무제한 AI 컴퓨팅 (AI compute)
• OpenAI 호환 API
• 기존 SDK 및 HTTP 클라이언트와의 즉시 사용 가능한 (drop-in) 지원
• GPT-5.4, Claude Opus 4.6, Grok 4.20 간의 동적 라우팅 (dynamic routing)

에이전트 중심의 워크플로에서는 사람들이 인정하는 것보다 예측 가능한 비용이 더 중요합니다. 만약 당신의 인프라 어시스턴트 (infra assistant)가 지속적으로 실행되어야 한다면, "토큰 불안 (token anxiety)"은 매우 좋지 않은 운영 제약 사항이 됩니다.

자세한 내용은 여기에서 확인하세요:
https://standardcompute.com

나의 견해

나는 "완전 자율 인프라 엔지니어 (full autonomous infra engineer)" 설정을 신뢰하지 않습니다.

하지만 다음과 같은 시스템은 신뢰합니다:

• 에이전트가 관찰할 수 있고 (observe)
• 에이전트가 제안할 수 있으며 (propose)
• Git이 변경 사항을 기록하고
• 사람이 이를 승인하며
• Argo CD가 이를 배포하고
• 롤백 (rollback)이 단 한 번의 revert로 가능한 시스템

이것이 바로 이 OpenClaw 설정이 눈에 띈 이유입니다.

화려하지 않습니다.

그저 안전함이 어디에서 오는지에 대해 솔직할 뿐입니다.

그리고 프로덕션 인프라 (production infrastructure)에 있어서는, 지루한 것이 대개 정답입니다.