Kyverno vs OPA Gatekeeper, 2026년에는 뭘 쓸까
쿠버네티스 admission 정책 엔진 이야기가 나오면 결국 Kyverno와 OPA Gatekeeper 두 개로 좁혀진다. 몇 년 전에는 "Gatekeeper 쓰면 뭔가 있어 보인다"는 분위기였는데, 최근 우리 팀에서 클러스터 3개에 적용해보고 나니 생각이 좀 바뀌었다. 이번 글은 그 판단 근거를 정리한 것이다.
결론부터 말하면, 순수 K8s admission만 필요한 상황에서는 지금 시점에 Kyverno가 손이 훨씬 덜 간다. 다만 그렇다고 Gatekeeper가 죽은 프로젝트냐 하면 그건 또 아니다.
정책 언어부터 갈린다
Gatekeeper는 Rego를 쓴다. OPA 진영에서 오래 굴려온 언어라 표현력은 확실히 강력하다. 대신 팀 안에 Rego 아는 사람이 한두 명이면 그 사람이 병목이 된다. 실제로 우리 팀에서도 "이 Constraint 왜 이렇게 짜져 있어요?"라는 질문에 답할 수 있는 사람이 나 혼자였고, 내가 휴가 가 있는 동안 SRE 팀에서 Rego 수정을 못 해서 정책 하나가 3일 동안 broken 상태로 방치된 적이 있다.
Kyverno는 그냥 YAML이다. 쿠버네티스 매니페스트 다루듯이 정책을 쓴다.
apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
name: require-team-label
spec:
validationFailureAction: Enforce
rules:
- name: check-team
match:
any:
- resources:
kinds: [Deployment, StatefulSet]
validate:
message: "team 라벨은 필수입니다"
pattern:
metadata:
labels:
team: "?*"Gatekeeper로 같은 걸 하려면 ConstraintTemplate 하나, Constraint 하나, 그리고 Rego 코드가 필요하다. 러닝 커브도 그렇지만 리뷰 코스트가 다르다. YAML PR 리뷰는 팀 누구나 할 수 있는데 Rego PR 리뷰는 그렇지 않다.
Mutation을 실제로 쓰느냐
이게 실무에서 은근히 중요한 갈림길이었다. Kyverno는 mutation이 GA고 validation과 같은 ClusterPolicy 리소스 안에 같이 산다. Sidecar 자동 주입, 기본 리소스 리밋 세팅, 라벨 자동 추가 같은 걸 정책 하나로 처리할 수 있다.
Gatekeeper의 mutation은 별도 CRD(Assign, AssignMetadata)로 분리돼 있고 2026년 기준으로도 GA가 아니다. 문서상으로는 되는데 실제 프로덕션에서 mutation을 적극적으로 쓰는 Gatekeeper 사례를 별로 못 봤다. 반면 Kyverno는 mutation을 안 쓰는 배포가 오히려 드물다.
우리 팀도 처음엔 mutation 없이 validation만 하려 했는데, 반년 지나니까 "이 라벨 없는 리소스가 계속 들어오는데 자동으로 붙여줄 수 없나?"라는 요구가 반복적으로 나왔다. 그때부터 Kyverno로 옮기는 게 눈에 들어오기 시작했다.
리소스 사용량과 성능
여기서 Gatekeeper가 유리하다. 컨트롤러 + audit 합쳐서 대략 270MB 정도 쓴다. Kyverno는 컨트롤러가 4개(admission, background, cleanup, reports)로 쪼개져 있어서 총합 600MB 근처 간다.
작은 클러스터에서는 이게 눈에 띈다. 노드 3~4대짜리 개발 클러스터에 Kyverno 깔면 시스템 파드 비중이 확 늘어난다. 반대로 노드 수십 대 이상 프로덕션에서는 사실상 차이가 무의미하다.
정책 개수가 100개를 넘어가기 전까지는 두 엔진 다 kubectl 응답 지연이 체감되지 않는다. 100개 넘어가면 둘 다 admission latency가 슬슬 붙기 시작하는데, 이건 정책 개수 문제지 엔진 문제가 아니다.
Policy Report와 감사 대응
컴플라이언스팀에서 "위반 리소스 리스트 뽑아 달라"고 요청이 오면 이게 생각보다 크게 느껴진다.
Kyverno의 PolicyReport CRD는 Kubernetes Policy Working Group의 표준이다. kubectl get polr -A 한 줄이면 클러스터 전체 위반 현황이 나온다. 대시보드 도구들도 이 표준을 물고 있어서 Grafana에 붙이기도 쉽다.
Gatekeeper는 자체 status 메커니즘을 쓰는데 PolicyReport 호환이 아니고 2026년 기준으로도 GA가 아니다. 감사 리포트를 사람이 손으로 정리하는 상황이 생긴다. 우리는 이걸 매 분기마다 스크립트로 긁어야 했다.
그럼 Gatekeeper는 언제 쓰나
플랫폼�t�^ K8s 하나가 아니라 Terraform, 마이크로서비스 API, CI 파이프라인까지 다 정책 하나로 묶고 싶을 때는 Gatekeeper(정확히는 OPA)가 이긴다. Rego 정책을 K8s에도 쓰고 API 게이트웨이에도 쓰고 IaC 파이프라인에도 쓸 수 있다. 이건 Kyverno가 못 하는 영역이다.
또 정책 로직이 정말 복잡한 경우, 예를 들어 여러 리소스를 참조하면서 상태를 계산해야 하는 정책은 Rego의 표현력이 필요하다. Kyverno도 CEL이나 JMESPath로 어느 정도 커버되지만 진짜 프로그래밍 로직에 가까운 정책은 Rego가 편하다.
우리 팀은 뭘 골랐나
결과적으로 Kyverno로 옮겼다. 이유는 세 가지였다. 첫째, 팀 전체가 YAML은 편해도 Rego는 부담스러워했다. 둘째, mutation을 쓸 일이 반년 안에 무조건 생겼다. 셋째, PolicyReport로 감사 대응이 자동화됐다.
Gatekeeper를 안 쓰는 게 아니라, 지금 시점에 K8s admission 하나만 놓고 보면 Kyverno가 유지보수 부담이 적었다는 이야기다. 만약 조직 전체가 이미 OPA 생태계를 쓰고 있다면 굳이 Kyverno로 바꿀 이유는 없다.
혹시 팀에서 이미 하나 쓰고 계신 분들, 옮긴 경험이나 옮기다 실패한 경험 있으면 댓글로 공유해주시면 감사하겠습니다.
참고 자료
태그: Kyverno, Gatekeeper, OPA, Kubernetes, 정책엔진, DevSecOps