서론

안녕하세요 konippi 입니다.

Kubernetes 매니페스트에는 컨테이너 이미지뿐만 아니라, 실행 권한, 리소스 양, 장애 발생 시의 동작 등 운영 환경을 좌우하는 설정들이 가득 차 있습니다. 그럼에도 불구하고 PR(Pull Request)에서는 애플리케이션 코드만큼 주의 깊게 검토되지 않아, 과도한 RBAC나 resource requests의 누락 등이 그대로 통과되는 경우가 있습니다.

2026년 5월에 CNCF Blog의 Community Post로 공개된 「Why Kubernetes policy enforcement happens too late—and what to do about it」는 이를 정책의 품질 문제가 아니라, 피드백을 돌려주는 타이밍의 문제로 파악하고 있습니다. 정책이 올바르게 탐지하더라도, CI나 Admission(승인) 단계에서 처음으로 거부될 때쯤에는 개발자가 이미 다른 작업으로 넘어가 있어, 수정을 위해 컨텍스트 스위칭(Context Switching)이 발생하게 됩니다.

그렇다고 해서 모든 검증을 PR로 옮기면 되는 것은 아닙니다. PR에서 빠르게 인지할 수 있도록 하면서도, CI나 Admission을 통한 보증도 남겨두어야 합니다. 본 기사에서는 어디서 평가할 것인가 (Point)와 위반 사항을 어떻게 다룰 것인가 (Action)라는 두 가지 관점에서 이 양립 가능성을 정리합니다.

매니페스트 리뷰는 왜 어려운가

다음 Deployment는 YAML로서에는 올바르지만, 운영 환경에 적용해서는 안 됩니다.

apiVersion: apps/v1
kind: Deployment
metadata
...

이 매니페스트에는 매니페스트 단독으로 판단할 수 있는 문제와, 워크로드(Workload)의 요구사항이 없으면 판단할 수 없는 항목이 혼재되어 있습니다. 예를 들어, privileged 컨테이너가 root 권한으로 동작하고, 변경 가능한 latest 태그를 사용하고 있다는 점은 명확한 리스크입니다. 반면, resource requests / limits, probe, replica 수, PodDisruptionBudget은 워크로드의 SLO나 조직 정책에 비추어 확인해야 합니다.

하지만 실제 리포지토리(Repository)에서는 리뷰 대상이 최종적인 매니페스트가 아닐 수도 있습니다. Helm의 values.yaml이나 Kustomize의 overlay는 템플릿이나 base에 대한 입력값이며, Deployment나 Service의 내용은 렌더링(Rendering) 후에 확정됩니다.

또한, 렌더링 후의 매니페스트만으로는 판단할 수 없는 경우도 있습니다. RBAC의 실효 권한은 Role이나 ClusterRole, 그리고 이들의 Binding 조합으로 결정되며, Custom Resource가 수락될지는 클러스터에 등록된 Custom Resource Definition (CRD)의 스키마나 Admission 설정에 의존합니다. mutating admission에 의해 라벨이나 사이드카(Sidecar)가 추가되면, Git 상의 정의와 API Server에 저장되는 오브젝트(Object)도 달라집니다.

나아가 최종적인 매니페스트가 확정되는 장소도 하나가 아닙니다. Helm이나 Kustomize는 클라이언트 사이드(Client-side)에서 렌더링한 결과를 API Server로 보내지만, kro나 KubeVela와 같은 커스텀 컨트롤러(Custom Controller) 기반의 도구에서는 개발자가 작성하는 것이 추상화된 Custom Resource이며, Deployment 등의 자식 리소스는 클러스터 내부에서 컨트롤러가 전개합니다. 이 경우, 처음에 Admission을 통과하는 것은 추상 리소스이며, 자식 리소스는 전개된 후 각각 별도의 API request로서 Admission을 통과합니다. PR 시점에는 아직 존재하지 않는 자식 리소스를 어떤 Point에서 어떻게 검증할 것인가라는 문제가 추가됩니다.

매니페스트 리뷰의 어려움은 PR에서 변경된 파일, 렌더링 후의 매니페스트, 클러스터에서 실제로 평가되는 상태 사이에 거리가 있다는 점입니다.

두 가지 축: Point와 Action

Gatekeeper나 Conftest와 같은 OPA 기반 도구나, Kubernetes용 정책 엔진인 Kyverno를 사용하면 조직의 규칙을 정책으로 기술하고 평가할 수 있습니다. 하지만 규칙이 존재하는 것만으로는 개발자 경험(Developer Experience)이 바뀌지 않습니다. 어느 시점에 실행할지, 위반 사항을 어떻게 다룰지, 그리고 결과를 어디로 돌려줄지까지 설계해야 합니다.

Point: 어디서 평가할 것인가

CNCF Blog의 서두에서는 정책을 평가하는 장소를 Enforcement locus라고 부르며, 이를 Edit, Review, Pipeline, Admission의 4개 계층으로 정리하고 있습니다. 본 기사에서는 이 평가하는 장소를 Point라고 부릅니다. 이는 Gatekeeper가 gator CLI, admission webhook, audit 등을 Enforcement point로서 API로 정의하는 것과 동일한 개념입니다.

다음 그림은 CNCF Community Post의 enforcement locus를 바탕으로, 저자가 본 기사의 Point를 도식화한 것입니다.

Point가 다르더라도 정책의 목적, 테스트 케이스, 기대하는 pass / fail, 예외 조건은 공유합니다. 반면, 정책 코드(Policy code)를 공통화할 수 있는 것은 아니며, 평가에 사용할 수 있는 정보나 클러스터 상태도 Point마다 다릅니다.

매니페스트(Manifest) 단독으로 판정할 수 있는 규칙은 여러 Point에서 동일한 구현을 재사용하기 쉽지만, 다음 정보에 의존하는 규칙을 빠른 Point에서 평가하려면 fixture나 검증 클러스터(verification cluster)로부터 명시적으로 준비해야 합니다. 준비되지 않을 경우, 운영 환경의 Admission과 동일한 판정이 되지 않습니다.

• API 요청을 보낸 실행 주체 (사용자 또는 ServiceAccount)
• Admission 시 전달되는 업데이트 전의 Kubernetes 오브젝트 (oldObject)
• 클러스터 내에 존재하는 다른 Kubernetes 오브젝트 또는 현재 상태

따라서 빠른 Point에서는 fixture를 사용하여 판정을 근사(approximate)하고, 클러스터 상태가 필요한 최종 판정은 Admission에 남겨둡니다.

정책 언어나 입력 형식이 다른 경우에도, 각 엔진에서 동일한 conformance test를 실행하여 Point에 따라 판정이 어긋나지 않는지 확인합니다. 판정이 일치하지 않을 때는 모델이나 도구를 의심하기 전에 Policy bundle, 렌더링 조건, Kubernetes 버전, 클러스터 상태의 차이를 확인합니다.

Action: 위반을 어떻게 다룰 것인가

예를 들어, 동일한 정책 위반이라도 Review time에서는 PR annotation이나 리뷰 코멘트로 반환하여 논의와 수정을 돕습니다. Pipeline time에서는 CI check 실패로 취급하여 merge를 중단시킬 수 있습니다. 본 기사에서는 이러한 위반 시의 처리를 Action이라고 부릅니다.

Point와 Action은 1 대 1로 대응하지 않습니다. 예를 들어 Pipeline time의 CI job은 PR annotation으로 피드백을 반환할 수도 있고, required status check를 실패시켜 merge를 중단시킬 수도 있으며, 두 가지를 동시에 수행할 수도 있습니다.

Kubernetes나 정책 엔진(Policy engine)도 검증 내용과 위반 시의 처리를 분리하고 있습니다. ValidatingAdmissionPolicy에서는 Policy가 검증 내용을 정의하고, Binding 측의 validationActions가 Deny / Warn / Audit을 지정합니다. 동일한 Admission이라는 Point에서도 Pod Security Admission은 enforce / warn / audit을, Kyverno는 Enforce / Audit을 전환할 수 있습니다. Gatekeeper에서는 동일한 constraint에 대해 Point마다 다른 Action을 설정할 수 있습니다.

빠른 Point는 피드백에, 후속 Point는 강제(enforcement)에 집중하는 경향이 있지만, 위반을 어떻게 반환하고 어떤 조건에서 진행을 멈출지는 도구와 리포지토리, 클러스터 설정에 따라 결정됩니다. 다음 표는 공통의 Kubernetes API를 나타내는 것이 아니라, 각 Point에서 이용할 수 있는 메커니즘의 예시입니다. 예를 들어 Pipeline에서는 CI의 종료 코드와 required status check가 merge를 중단시키고, Admission에서는 Deny가 API request를 거부합니다.

새로운 규칙은, 우선 필요한 지점 (Point)에서 위반 사항을 피드백으로 반환하고, 오탐 (False Positive), 예외, 운영에 미치는 영향을 확인한 다음, 위협 모델 (Threat Model)에 따라 진행을 중단시키는 제어에 사용합니다. 이는 지점 (Point) 간의 일률적인 격상(promotion)이 아닙니다. Kubernetes 공식의 Pod Security Standards 도입 절차는, 동일한 Admission이라는 지점 (Point)에서 warn / audit를 관측한 후 enforce로 넘어가는 방법을 보여줍니다. 반면, Gatekeeper는 Shift-left에서는 deny, Admission에서는 warn이라는 역방향 설정도 예시하고 있습니다. ValidatingAdmissionPolicy가 강제 경계가 되려면, Policy와 Binding, match 조건, validationActions, failurePolicy, parameter를 사용하는 경우의 parameterNotFoundAction이 의도한 대로여야 합니다. Deny와 Warn은 동일한 Binding에서 병용할 수 없습니다. Webhook 타입의 정책 엔진(Policy Engine)에서는 timeout이나 도달 불가능 시의 failure policy, Webhook의 적용 범위도 확인해야 합니다.

3가지 질문

지금까지의 지점 (Point)과 액션 (Action)은 축(axis)의 정의입니다. 이 축 위에서 매니페스트 리뷰를 설계하려고 하면, 순서대로 3가지 질문에 맞닥뜨리게 됩니다.

• 앞선 지점 (Point)에서 deny할 수 있다면, 후속 지점 (Point)을 줄일 수 있는가. CI를 필수 체크로 만들 수 있다면, Admission은 중복되어 보입니다.
• 앞선 지점 (Point)의 판정은 어디까지 신뢰할 수 있는가. PR 상의 판정을 deny로 사용하려면, 후속 단계와 동일한 결과가 반환되어야 합니다.
• AI에게는 무엇을 맡길 수 있는가. 결정론적(Deterministic)인 검증을 토대로, AI를 리뷰의 어느 단계에 배치할 것인가라는 역할 분담의 문제입니다.

여기서부터 Defense in Depth, Shift Left, AI의 분담 순으로 이 3가지 질문에 답해 나가겠습니다.

Defense in Depth

CI가 deny할 수 있다면 Admission은 불필요해 보일지도 모릅니다. 하지만 후속 단계를 남겨두는 이유는 두 가지가 있습니다.

첫 번째는 지점 (Point)의 성격입니다. CI가 대상으로 삼을 수 있는 것은 CI를 통과하는 변경 경로뿐입니다. 로컬에서의 kubectl apply, 컨트롤러(Controller)가 생성하는 리소스 (Resource), 장애 대응 시의 직접 변경은 CI를 거치지 않지만, Admission은 이러한 생성·업데이트 request를 평가할 수 있습니다.

한편, kubectl exec와 같은 조작은 일반적인 매니페스트의 생성·업데이트와는 다른, pods/exec subresource에 대한 CONNECT request입니다. RBAC나 CONNECT를 match하는 Validating Admission Webhook으로 제어할 수 있지만, 허가 후에 컨테이너 내부에서 이루어지는 조작까지는 정적 정책 (Static Policy)만으로 파악할 수 없습니다. 따라서 감사 로그 (Audit Log)와 런타임 보안 (Runtime Security)도 병용합니다.

두 번째는, 모든 제어(Control)에는 고장 모드(Failure Mode)가 있다는 점입니다. branch protection 설정 실수나 CI 중단뿐만 아니라, Admission 정책 자체도 API 오브젝트인 이상 충분한 권한이 있다면 변경이나 삭제가 가능합니다. Kubernetes 1.36에서 alpha로 도입된 Manifest-Based Admission Control은 Admission 정책을 control plane 상의 manifest로 관리하여 API를 통한 변경으로부터 보호합니다. 하지만 이것만으로 CI 설정 실수나 정책 로직의 오류까지 방지할 수 있는 것은 아닙니다. 서로 다른 경로와 고장 모드에 대비하려면 하나의 제어에만 의존하지 않고, 여러 제어를 중첩해야 합니다. 이것이 Defense in Depth (심층 방어)의 개념입니다. Shift Left가 Point 축상에서 피드백의 위치를 이동시키는 것이라면, Defense in Depth는 빠른 체크를 이유로 후속 단계의 제어를 제거하지 않을 것을 요구합니다.

평가는 Admission에서 끝나지 않습니다. CNCF TAG Security의 Cloud Native Security Whitepaper와 Kubernetes 공식 문서에서는 클라우드 네이티브 라이프사이클을 Develop, Distribute, Deploy, Runtime으로 나누고, 모든 단계에서 보안이 필요하다고 명시하고 있습니다. Whitepaper는 Shift Left로 인해 운영 시의 모니터링이 누락될 가능성에도 주의를 촉구합니다. 클러스터에 저장된 이후에는 다음 세 가지가 각각 별도의 대상을 다룹니다.

사후 감사는 변경을 수반하지 않는 위반을 다룹니다. 위반은 새로운 변경뿐만 아니라, 정책의 추가나 강화로부터도 발생합니다. 기존 리소스는 Admission을 다시 거치지 않기 때문에, Gatekeeper의 audit이나 Kyverno의 background scan이 정기적으로 평가합니다. Kyverno의 background scan은 background 평가가 가능한 규칙에 대해, 클러스터 내에 현존하는 리소스의 결과를 PolicyReport에 기록합니다. 이는 기존 리소스를 삭제하거나, Enforce 모드 규칙으로 소급하여 차단하는 것이 아닙니다.

GitOps는 desired state (희망 상태)와 live state (실제 상태)의 차이를 다룹니다. OpenGitOps의 원칙은 실제 상태를 지속적으로 관측하여 바람직한 상태의 적용을 시도하는 것을 Continuous Reconciliation (지속적 조정)이라고 정의합니다. GitOps는 차이(diff)를 검출하여 수렴시키는 메커니즘이며, API request를 즉시 거부하는 강제 경계가 아닙니다. Argo CD에서 live drift를 자동으로 되돌리려면 automated sync와 self-heal 활성화가 필요하며, 복구 범위는 prune, 차이 무시, resource exclusion 등의 설정에도 의존합니다.

Runtime Security (런타임 보안)는 실행 중인 동작을 다룹니다. 프로세스, 파일, system call, 네트워크 통신을 모니터링하여 정적인 매니페스트(Manifest)만으로는 알 수 없는 이상 징후를 검출합니다. 동작 모니터링 외에도, static Pod 등을 통한 Admission 우회에 대비하여 컨테이너 기동 시 검증을 거듭하는 사례가 있습니다.

Shift Left

빠른 Point에서 진행을 멈추기 위해 사용하는 검증은, 무엇을 입력으로 삼고 어느 의존 조건까지 고정할 수 있는지를 나누어 설계합니다. Raw YAML은 그대로 검증할 수 있지만, Helm chart / values나 Kustomize base / overlay로부터 최종적인 Kubernetes object를 평가하는 경우에는 명시적인 전처리 또는 검증 도구 내부에서 후보 매니페스트를 생성합니다.

후보 매니페스트에 대한 스키마 검증(Schema Validation)과 정책 평가(Policy Evaluation)는 입력, 도구, 스키마, Policy bundle을 고정하여 오프라인에서 재현할 수 있습니다. 반면, server-side dry-run은 실제 API Server, CRD, Admission, identity 등에 의존하는 별종의 체크입니다. 각 체크의 결과는 CI Gate의 pass / fail을 직접 구성하며, AI에는 해당 결과를 설명과 수정안의 근거로서 전달합니다. AI 자신의 출력은 합격/불합격 판정에 사용하지 않고 advisory (권고) 피드백으로 취급합니다.

검증 대상 매니페스트를 생성하기

Helm이나 Kustomize 입력을 통해 최종적인 Kubernetes object를 평가할 때는, 클러스터에 적용할 후보 매니페스트 (manifest)를 생성합니다. 생성은 독립적인 CI 단계에서도, 검증 도구의 내부 처리에서도 수행될 수 있습니다. Kyverno CLI는 kustomize build의 출력을 표준 입력 (standard input)으로부터 평가하는 예시를 보여주며, Trivy의 Helm scanner는 values를 사용하여 Chart를 내부적으로 렌더링(rendering)한 후 Kubernetes checks를 실행합니다.

# Helm
$ helm template my-app ./charts/my-app \
--namespace production \
...

CI에서는 Helm / Kustomize의 버전, Chart dependency, remote resource의 revision, 대상 namespace, Kubernetes 버전 및 API capabilities를 고정합니다. Chart가 특정 API의 유무에 따라 분기되는 경우에는 대상 클러스터에 맞춰 --api-versions도 지정합니다. 시간이나 난수에 의존하는 템플릿(template) 또한 동일한 입력으로부터 동일한 결과를 얻을 수 있도록 재검토합니다. 로컬의 helm template는 live cluster를 참조하는 lookup이나 server-side validation까지는 재현하지 않으므로, 생성된 후보 매니페스트만으로 운영 환경 적용을 보장할 수는 없습니다.

--include-crds는 Chart에 동봉된 CRD를 렌더링 결과에 포함합니다. 다만, Helm의 crds/ 하위 항목은 템플릿화되지 않으며, 기존 CRD는 설치(install) 시 skip되고 upgrade / delete 대상도 되지 않습니다. CRD를 업데이트할 경우에는 Chart 본체와는 별도로 lifecycle과 적용 순서를 관리하며, 실제 deployment 절차에 대응하는 검증을 수행합니다.

kro나 KubeVela와 같이 컨트롤러(controller)가 클러스터 내에서 하위 리소스를 전개하는 도구의 경우, helm template에 상응하는 클라이언트 사이드(client-side) 생성이 항상 가능하지는 않습니다. KubeVela의 vela dry-run은 definition을 로컬로 지정하여 오프라인에서 렌더링할 수 있지만, 오프라인 모드에서는 검증 단계가 스킵됩니다. 도구 측의 렌더링 수단으로 후보 매니페스트를 생성하는 경우에도, 참조하는 definition을 클러스터와 동일한 revision으로 고정하고, 그곳에서 확인할 수 없는 검증은 격리된 검증 클러스터에 적용함으로써 보완합니다.

오프라인에서 스키마를 검증하기

생성된 후보 매니페스트를 kubeconform 등에 전달하여, 고정된 OpenAPI / JSON Schema로 표현되는 구조와 타입을 오프라인에서 검증합니다. 이는 API Server의 defaulting, version conversion, CRD conversion webhook, CEL validation, Admission까지 동일하게 재현하는 것은 아닙니다. CI에서는 schema source와 revision 또는 digest를 고정합니다.

$ kubeconform \
-strict \
-summary \
...

Custom Resource를 포함하는 경우에는 신뢰할 수 있는 곳에서 가져온 대응 스키마도 함께 전달합니다. 알 수 없는 리소스나 스키마 취득 실패, parse error는 성공으로 처리하지 않고 체크를 실패 처리합니다. CRD의 신규 생성 또는 업데이트와 그 Custom Resource를 동일한 번들(bundle)로 검증할 경우, server-side dry-run에서는 후보 CRD가 영속화되지 않기 때문에 후속 Custom Resource가 새로운 스키마를 참조할 수 없습니다. 일회성으로 격리된 검증 클러스터에 후보 CRD를 적용하고, Established 상태와 API discovery 반영을 확인한 후 Custom Resource를 검증합니다.

오프라인에서 정책을 평가하기

동일한 후보 매니페스트(manifest)에 대해 조직의 규칙을 Kyverno CLI 또는 Conftest로 평가합니다. Gate의 성패는 스키마 검증(schema validation)과 정책 평가(policy evaluation) 모두로 구성될 수 있으므로, CI에서는 병렬로 실행할 수 있습니다. 단, 스키마 오류로 인한 정책 엔진의 error / skip과 정책 위반(policy violation)은 별개의 결과로 취급합니다.

# Kyverno CLI
$ kyverno apply ./policies --resource rendered.yaml
# Conftest
...

"CIS Benchmark에 따라"라고 AI에게 지시하는 것만으로는 필수 체크나 감사 추적(audit trail)이 되지 않습니다. 중단시키고 싶은 규칙은 불변(immutable)한 Policy bundle로 관리하며, bundle digest, 엔진 버전, 대상 Kubernetes 버전을 기록합니다. Admission에서 유효한 revision과 CI가 평가한 revision이 일치하는지도 확인합니다.

예외 사항에는 이유와 기한뿐만 아니라 대상 resource / namespace, 소유자(owner), 승인자, 티켓(ticket)을 포함합니다. 예외 정의 자체를 보호된 장소에서 관리하여 기한 만료를 자동으로 감지할 수 있도록 합니다.

기존 위반 사항이 많은 환경에서는 처음부터 모든 것을 필수 체크로 설정하면 개발이 중단됩니다. 우선 보호된 base branch나 서명된 artifact를 베이스라인(baseline)으로 삼고, PR에서 새로 추가된 위반 사항만 차단하는 방법이 현실적입니다. 추가할 규칙 자체도 먼저 피드백으로서 관측하고, 오탐(false positive)이나 예외를 확인한 후에 필수 체크로 전환합니다.

필요에 따라 클러스터 의존적 조건 확인하기

실제 클러스터에 등록된 CRD나 Admission까지 포함하여 확인해야 하는 경우에는 전용 검증 클러스터에서 server-side dry-run을 실행합니다. 이는 고정된 입력만으로 완결되는 오프라인 체크가 아니라, 대상 클러스터의 상태에 의존하는 임의의 추가 체크입니다.

$ kubectl apply \
--server-side \
--dry-run=server \
...

이 결과가 운영 환경을 대표하려면 실행 identity, namespace, Kubernetes / CRD / Admission의 revision, Server-Side Apply의 field manager와 live object의 managedFields 등의 조건이 일치하는 범위여야 합니다. 대상이 되는 Admission Webhook은 sideEffects: None 또는 NoneOnDryRun을 선언해야 합니다. 단, 외부 서비스, 시간, 클러스터 상태에 의존하는 판정이 운영 환경의 request와 일치하는 것까지는 보장되지 않습니다.

시간, 외부 서비스, 생성값에 의존하는 mutation은 dry-run과 실제 request에서 결과가 달라질 수 있습니다. dry-run에서 운영 적용까지 클러스터 상태가 변할 가능성도 있으므로, 운영 환경의 Admission은 남겨둡니다.

server-side dry-run으로 확인할 수 있는 것은 주로 인가(authorization), 스키마, Admission, Server-Side Apply의 충돌입니다. 컨트롤러의 reconciliation, scheduling, 이미지의 기동 가능 여부, 실행 시의 동작까지는 보장하지 않습니다. 클러스터 상태의 fixture는 Kyverno CLI와 같은 오프라인 테스트에 사용하며, server-side dry-run의 대용으로 사용하지는 않습니다.

server-side dry-run은 여러 resource를 하나의 트랜잭션(transaction)으로 검증하는 것이 아닙니다. 각 request는 영속화되지 않으므로, 먼저 dry-run한 Namespace나 CRD를 후속 request가 참조할 수도 없습니다. 검증에 필요한 전제 resource는 격리된 검증 클러스터에 사전에 준비합니다. 또한 외부 데이터, 시간, quota, 다른 request와의 충돌에 의존하는 판정은 dry-run과 운영 적용 시 다를 가능성이 있습니다.

AI는 설명과 수정에 사용한다

매니페스트 리뷰에서 AI가 유용한 부분은 기계적인 위반 사항을 개발자의 언어로 변환하는 부분입니다. 예를 들어 privileged: true

가 검출되었을 때, 주변의 RBAC나 volume mount (볼륨 마운트)까지 고려하여 영향을 설명하고, Helm chart (헬름 차트)의 수정 위치를 제안할 수 있습니다. 반면, LLM (거대언어모델)의 출력은 재현성을 보장할 수 없으므로, 스키마 검증 (schema validation), 정책 평가 (policy evaluation), merge (병합) 중단은 결정론적인 (deterministic) 도구에 맡깁니다. AI의 출력은 권고 사항 (advisory)으로 간주하며, 합격/불합격 판정에는 사용하지 않습니다.

AI Reviewer (AI 리뷰어)에게는 raw YAML (가공되지 않은 YAML)뿐만 아니라, 검증 결과를 구조화하여 전달합니다.

{
"source": "charts/api/values.yaml",
"resource": "Deployment/default/api",
...

source와 path의 대응은 정책 엔진 (policy engine)으로부터 자동으로 얻을 수 있다고 단정할 수 없습니다. rendered object (렌더링된 객체)에서 Helm의 values (값)나 template (템플릿), Kustomize의 patch (패치)로 되돌리는 source mapping (소스 매핑)이 없는 경우, AI가 제시하는 수정 대상은 후보로만 취급합니다. AI에게는 문제의 이유, 위반한 정책, 수정 위치 후보, 수정 후의 확인 방법을 반환하게 하고, 정책 엔진의 결과를 근거로서 병기합니다. Amazon Bedrock의 Structured Outputs (구조화된 출력) 등을 사용하여 JSON Schema (JSON 스키마)를 준수하게 하면 후속 처리를 안정화할 수 있지만, 보장되는 것은 형식일 뿐 내용의 정확성이 아닙니다.

2026년의 「Benchmarking AI agent retrieval strategies on Kubernetes bug fixes」에서는, Kubernetes의 실제 PR (Pull Request) 9건을 사용한 소규모 실험을 통해, Agent (에이전트)가 변경의 전파나 시스템 전체의 불변 조건 (invariant)을 간과하고 국소적인 수정에 그치기 쉬운 경향이 있다고 보고되었습니다. Deployment (디플로이먼트)에 runAsNonRoot: true