Kyverno vs OPA Gatekeeper, 2026년 지금 뭘 쓸까

정책 엔진 선택 얘기를 팀 내부에서 다시 꺼내게 됐다. 작년까지는 "우린 OPA 이미 다른 서비스에도 쓰니까 Gatekeeper로 가자" 정도의 결론으로 대충 정리됐는데, 최근 몇 달간 상황이 좀 바뀌었다. Kyverno 쪽 문서와 릴리즈 노트를 다시 훑어보고, 그 사이 Gatekeeper도 뭐가 바뀌었나 확인해봤다. 결론부터 말하면, 지금 새 클러스터에 policy engine을 새로 붙인다면 나는 Kyverno를 쓴다. 그런데 그 이유가 좀 뻔한 얘기(Rego 어렵다, YAML 쉽다)만은 아니어서 정리해둔다.

뭐가 실제로 갈리는가

정책 언어 얘기는 이미 다들 안다. Kyverno는 CRD YAML로 policy를 쓰고, Gatekeeper는 Rego + ConstraintTemplate으로 쓴다. 이건 취향 문제가 아니다. Rego는 학습 곡선이 있고 그 곡선을 넘긴 사람이 팀에 있어야 한다. 우리 팀엔 없었다. 그래서 첫 번째 Constraint 하나 짜는 데 며칠이 걸렸다. Kyverno는 처음 policy 짜는 사람이 kubectl explain 한 번 쳐보고 바로 쓴다.

그런데 이건 초반에만 유효한 얘기다. Policy가 20개, 50개 넘어가면 얘기가 달라진다. Rego는 재사용 단위가 명확하다. 함수, 패키지, import. Kyverno의 YAML은 재사용을 하려면 policy를 파일 단위로 복사하거나 template variable로 뽑아내야 하는데, 이게 쌓이면 좀 지저분해진다. Kyverno 2026 시점에는 이 부분이 많이 개선됐고 exceptions, contexts 같은 개념이 잘 잡혔지만, 순수 표현력만 놓고 보면 Rego가 여전히 위다.

성능은 신경 써야 한다

2026년 기준 리소스 사용량을 보면 Gatekeeper 컨트롤러 전체가 약 270MB 근처, Kyverno가 약 600MB 정도 나온다. 두 배 넘게 차이 난다. 노드 규모가 작거나 클러스터가 여러 개면 그냥 넘길 수치는 아니다.

우리 팀에서는 dev/staging 포함해서 15개 정도 클러스터를 굴리는데, 클러스터당 300MB의 오버헤드 차이는 컨트롤 플레인에 몰릴 때 신경 쓰인다. 특히 Kyverno는 admission 처리 지연이 policy 수에 비례해서 붙는다. 100개 넘어가는 policy를 몰아넣으면 P99 admission latency가 눈에 띄게 튄다. 이걸 완화하려면 policy를 잘 쪼개고 background scan을 분리해야 하는데, 이 튜닝을 처음 하는 사람에겐 삽질이다.

Gatekeeper는 admission 요청 처리를 Rego evaluator가 하는 구조라서 policy 수가 늘어도 상대적으로 완만하게 증가한다. 대신 constraint sync가 늦으면 신규 constraint가 즉시 안 잡히는 문제가 있는데, 이건 sync period 설정으로 대응한다.

Mutation은 이제 둘 다 되지만

예전엔 mutation은 Kyverno의 강점이었다. 지금은 Gatekeeper도 mutation을 지원한다. 다만 Kyverno는 mutation이 GA 상태고 ClusterPolicy 하나 안에서 validate와 mutate를 같이 정의한다. Gatekeeper는 Assign, AssignMetadata라는 별도 CRD를 써야 하고, 이 조합이 아직 좀 어색하다.

실무에서 mutation을 많이 쓰는 케이스가 있다. 이미지 registry mirror 강제 삽입, imagePullSecrets 자동 부착, sidecar 자동 주입(Istio 안 쓸 때) 같은 것들. 이런 걸 자주 하는 팀이면 Kyverno 쪽이 훨씬 편하다.

PolicyReport 표준

이건 좀 최근에 무게가 실린 얘긴데, Kyverno가 만드는 PolicyReport CRD가 Kubernetes Policy Working Group의 표준이 됐다. 즉 여러 툴이 이 형식을 소비한다. Falco, Trivy 같은 것들이 자기 결과를 PolicyReport로 밀어넣고, Kyverno 것과 합쳐서 대시보드에 뿌린다.

Gatekeeper는 자체 status 필드에 결과를 남긴다. 이걸 PolicyReport로 변환하는 별도 exporter가 있긴 한데, 표준 파이프라인은 아니다. 다중 툴을 붙일 계획이면 이게 은근히 크다. 우리 팀은 policy-reporter를 UI로 쓰는데, Kyverno + Trivy가 자동으로 한 화면에 뜨는 게 편했다.

그래서 뭘 고르나

내가 지금 판단하는 기준은 이렇다.

Kubernetes 안에서만 policy를 관리할 거고, YAML로 정책 짜는 게 팀에 잘 맞고, mutation과 정책 리포트가 중요하면 Kyverno가 편하다. 표준 워크플로우와 잘 맞고, 학습 곡선이 낮다. 리소스는 좀 먹지만 대부분 클러스터에서 감내할 수준이다.

반대로 Rego를 이미 CI, gateway, 다른 서비스에 쓰고 있고, 여러 시스템에서 정책을 같은 언어로 재사용하고 싶고, 관리하는 클러스터 리소스가 빡빡하면 Gatekeeper가 낫다. 표현력이 필요한 복잡한 정책도 Rego 쪽이 유리하다.

우리 팀은 이번에 Kyverno로 새로 붙였다. 이유는 정책 리포트 통합이 컸다. Trivy operator 결과와 admission policy 결과를 한 대시보드에서 보는 게 운영팀 온보딩을 확 편하게 만든다. 대신 policy 개수가 늘어가면서 성능 튜닝을 언제 시작할지 고민 중이다. 이건 좀 더 써보고 별도로 정리할 생각이다.

여러분 팀은 어떤 걸 쓰고 계신가요? 특히 policy 개수 100개 넘게 굴리는 케이스에서 어떻게 튜닝하는지 궁금합니다.