CloudNativePG 의 미래, 그리고 나의 미래

들어가며

평소 올리던 튜닝 케이스나 테스트 기록과는 결이 조금 다른, 일기장에 가까운 글을 하나 남겨 보려고 합니다. 특정 기술 문제를 파고드는 기록이 아니라, 요즘 제가 가장 관심 있게 지켜보고 있는 CloudNativePG 라는 프로젝트에 대한 생각을 정리한 글입니다.

CloudNativePG 는 요즘 업무 시간 중 짬이 날 때마다 테스트해 보고 있는 대상이기도 합니다. 로컬에 kind 기반 테스트 환경을 꾸려 두고 operator 를 직접 빌드해서 배포해 보고, 열린 이슈들을 들여다보며 기여할 만한 지점을 찾는 일을 반복하고 있습니다. 들여다볼수록 이 프로젝트가 가려는 방향이 앞으로 데이터베이스 운영이 갈 방향과 겹쳐 보인다는 생각이 짙어졌습니다.

그래서 이 기록을 남기는 목적은 두 가지입니다. 하나는 CloudNativePG 의 미래와 발전 가능성에 대해 지금 시점의 제 생각을 남겨 두는 것이고, 다른 하나는 앞으로 이 프로젝트를 더 주의 깊게 들여다보고 깊게 파보겠다는 저 자신과의 약속을 여기에 박아 두는 것입니다. 치열하게 고민해 보겠다는 선포이기도 합니다. 그래서 CloudNativePG 가 Graduated 로 가는 흐름에 맞춰, 저도 함께 깊어지겠다는 약속을 여기에 남겨 보고자 합니다.

데이터 주권

CloudNativePG 의 미래를 낙관하는 첫 번째 이유는 데이터 주권(data sovereignty)이라는 흐름입니다.

EU Data Act 같은 규제가 자리를 잡으면서, 데이터를 어디에 두고 누가 통제하는가라는 질문이 유럽을 중심으로 점점 무거워지고 있습니다. 매니지드 DBaaS 는 분명 편하지만, 데이터와 운영 가시성(메트릭, 로그, 백업)이 특정 클라우드의 콘솔 안에 갇힌다는 대가가 따릅니다. 옮기고 싶어도 옮길 수 없는 상태, 이른바 락인입니다.

이 맥락에서 Kubernetes 위의 PostgreSQL 은 단순한 기술 선택이 아니라 주권 회복의 수단이 됩니다. Kubernetes 가 인프라를 추상화해 주기 때문에, 그 위에서 CloudNativePG 로 돌아가는 PostgreSQL 은 퍼블릭 클라우드든 프라이빗 데이터센터든 동일한 선언적 매니페스트로 옮겨 다닐 수 있습니다. 올해 3월 KubeCon EU 의 Open Sovereign Cloud Day 에서 Floor Drees 와 Gabriele Bartolini 가 발표한 “Beyond the DBaaS Trap: Achieving Data Sovereignty With Kubernetes and CloudNativePG” 가 정확히 이 이야기를 다룹니다.

Open Sovereign Cloud Day 발표 영상입니다.
https://www.youtube.com/watch?v=lgVyxUOsJVE

데이터 주권이 화두가 될수록 프라이빗 환경에서 DBaaS 수준의 운영 경험을 재현할 수 있는 도구가 필요해지고, 지금 그 자리에 가장 가까이 서 있는 것이 CloudNativePG 라고 생각합니다.

Crunchy PGO 와의 아키텍처 차이

CloudNativePG 를 지지하는 두 번째 이유이자, 제가 가장 무게를 두고 싶은 부분입니다. Kubernetes 위에서 PostgreSQL 을 돌리는 operator 는 여럿 있지만(Crunchy PGO, Zalando, StackGres 등), CloudNativePG 가 사실상 표준의 자리로 가고 있다고 보는 근거는 아키텍처 그 자체에 있습니다. 비교 대상으로는 가장 오래되고 성숙한 경쟁자인 Crunchy Data 의 PGO 를 놓고 보겠습니다.

두 operator 의 갈림길은 하나의 질문에서 시작됩니다. 고가용성(HA)의 두뇌를 어디에 둘 것인가.

Crunchy PGO 는 이 역할을 Patroni 에게 맡깁니다. Patroni 는 Kubernetes 이전 시대부터 VM 환경에서 PostgreSQL HA 를 책임져 온 검증된 도구지만, 그 자체가 Python 으로 짜인 별도의 분산 시스템입니다. PGO 는 모든 데이터베이스 Pod 안에 Patroni 를 함께 태워서, 리더 선출과 failover 를 Patroni 의 합의 로직에 맡깁니다.

CloudNativePG 는 반대 방향을 택했습니다. 외부 HA 도구를 아예 쓰지 않고, HA 로직을 operator 안에 직접 구현했습니다. 클러스터 상태의 유일한 진실원본은 Kubernetes API 서버 자체입니다. Patroni 가 필요로 하는 별도의 DCS(etcd, Consul) 계층이 존재하지 않습니다.

이 선택이 만드는 차이를, 각 operator 가 PostgreSQL 클러스터를 제어하는 구조로 정리해 봤습니다. 위에서 아래로 “누가, 무엇을 거쳐, Pod 를 관리하는가” 의 흐름입니다.

Crunchy PGO 의 제어 구조

operator
   ↓  StatefulSet 을 사이에 둔 간접 관리
StatefulSet (pod-0, pod-1 … ordinal 순서)
   ↓
Pod ×N  =  Patroni + PostgreSQL + pgBackRest + 확장들
   ↕  리더 선출·합의            ← HA 판단은 각 Pod 안의 Patroni 가 수행
DCS (Patroni 가 바라보는 별도 상태 저장소 계층)

CloudNativePG 의 제어 구조

operator  ↔  Kubernetes API (유일한 진실원본)   ← HA 판단은 operator 가 수행
   ↓  StatefulSet 없이 Pod/PVC 직접 생성·관리
Pod ×N  =  Instance Manager (PID 1) + PostgreSQL
   ·  장애 시 operator 가 각 Pod 의 LSN 비교 → 가장 앞선 replica 승격

같은 PostgreSQL 클러스터를 놓고도 PGO 는 operator 와 Pod 사이에 StatefulSet 이, Pod 아래에 DCS 라는 합의 계층이 하나씩 더 끼어 있고, HA 판단 주체가 모든 Pod 안에 분산되어 있습니다. CloudNativePG 는 그 두 계층이 없고 HA 판단이 operator 한 곳에 모입니다.

이 구조 선택은 연쇄적으로 다른 차이를 만들어 냅니다.

Pod 관리 방식. PGO 는 Kubernetes 의 표준 부품인 StatefulSet 으로 Pod 를 관리합니다. 반면 CloudNativePG 는 StatefulSet 을 쓰지 않고 Pod 와 PVC 를 operator 가 직접 하나하나 관리합니다. StatefulSet 의 서수(ordinal) 기반 로직으로는 “어느 replica 의 WAL 이 가장 앞서 있는가” 를 알 수 없지만, Pod 를 직접 관리하면 failover 시점에 각 인스턴스의 LSN 을 비교해서 데이터 유실이 가장 적은 replica 를 승격시킬 수 있습니다. DBA 입장에서 보면 데이터베이스를 아는 사람이 failover 를 설계했다는 신호로 읽힙니다.

인스턴스 관리. 각 Pod 안에서는 Go 로 작성된 Instance Manager 가 PID 1 로 떠서 PostgreSQL 프로세스를 직접 거느립니다. startup, readiness, liveness probe 가 전부 데이터베이스의 실제 상태를 아는 프로브로 Kubelet 과 연동됩니다. 사이드카로 얹힌 감시자가 아니라, 컨테이너의 본체가 곧 관리자인 구조입니다.

operand 이미지. 아키텍처 철학은 이미지 크기에서 그대로 드러납니다. PGO 의 데이터베이스 이미지에는 Patroni(와 Python 런타임), pgBackRest, pgAudit, 각종 확장이 한 이미지에 동봉되어 약 625개 패키지가 들어 있습니다. CloudNativePG 의 이미지에는 PostgreSQL 만 들어 있고 약 140개 패키지입니다. 2026년 5월 기준 CVE 스캔 결과도 Critical 2건에 High 156건 대 Critical 0건에 High 4건으로 갈립니다. 필요한 확장은 이미지를 다시 굽는 게 아니라 OCI volume 으로 Cluster 매니페스트에 선언만 하면 붙습니다. 공격이 발생할 수 있는 지점이 그만큼 적고, 패치 부담도 구조적으로 작을 수밖에 없습니다.

운영 부담. PGO 를 운영한다는 것은 Kubernetes 에 더해 Patroni 라는 또 하나의 분산 시스템을 모니터링하고 디버깅하고 업그레이드한다는 뜻입니다. CloudNativePG 는 그 계층이 없어서, 장애가 숨을 곳도 그만큼 적습니다. API 서버가 죽는 극단적인 상황에서는 무리하게 failover 를 시도하지 않고 데이터 보호를 우선하도록 설계되어 있는데, 클러스터 상태를 신뢰할 수 없는 상황에서 승격을 강행하는 것이 더 위험하다는 판단입니다. 이 보수적인 선택도 DBA 로서는 마음에 듭니다.

메이저 버전 업그레이드. PGO 는 PGUpgrade CRD 를 통한 오프라인 업그레이드가 기본이고 롤백이 없습니다. CloudNativePG 는 pg_dump 방식, 논리 복제를 이용한 온라인 방식, 자동 롤백이 지원되는 in-place pg_upgrade 까지 세 가지 경로를 제공합니다.

라이선스와 거버넌스. PGO 의 컨테이너 이미지는 Crunchy Developer Program 약관(50인 초과 조직은 상용 계약 필요) 아래에 있고 공개 거버넌스가 없습니다. CloudNativePG 는 Apache 2.0 에 CNCF 소속으로 공개 로드맵과 공개 거버넌스를 갖추고 있으며 OpenSSF Baseline 인증도 받았습니다. 최근 18개월만 놓고 봐도 GA 릴리스 횟수가 약 4회 대 18회이고, CloudNativePG 는 6~8주 케이던스를 한 번도 거르지 않았습니다.

축	Crunchy PGO	CloudNativePG
HA 두뇌	Patroni (별도 분산 시스템)	operator 내장, Kubernetes API 가 유일한 진실원본
Pod 관리	StatefulSet (ordinal 기반)	Pod/PVC 직접 관리, LSN 기반 승격
인스턴스 관리	Patroni 사이드카	Go Instance Manager 가 PID 1
operand 이미지	약 625개 패키지 (도구 동봉)	약 140개 패키지 (PostgreSQL 만)
CVE (2026-05 스캔)	Critical 2 / High 156	Critical 0 / High 4
확장 추가	이미지에 빌드	OCI volume 선언
백업	pgBackRest 이미지 내장	volume snapshot + CNPG-I 플러그인 (Barman Cloud)
메이저 업그레이드	오프라인, 롤백 없음	3가지 경로, in-place 는 자동 롤백
라이선스/거버넌스	Developer Program 약관, 비공개 거버넌스	Apache 2.0, CNCF, OpenSSF Baseline
릴리스 (18개월)	GA 약 4회, 최장 공백 8개월	GA 약 18회, 6~8주 케이던스

Patroni 를 오래 다뤄 온 팀이라면 PGO 쪽이 익숙할 수 있고, PGO 가 나쁜 operator 라는 얘기도 아닙니다. 다만 “Kubernetes 를 신뢰하고 그 위에 최소한의 것만 얹는다” 는 CloudNativePG 의 설계가 Kubernetes 라는 플랫폼의 결에 더 맞고, 그래서 시간이 지날수록 격차가 벌어질 것이라고 생각합니다. 이 비교의 상세한 근거는 CloudNativePG 공동 창시자 Gabriele Bartolini 의 CloudNativePG and Crunchy PGO: an honest, opinionated comparison(2026-05) 에서 확인할 수 있습니다.

HSBC 사례

아키텍처가 좋다는 것과 실전에서 통한다는 것은 다른 문제인데, 올해 3월 KubeCon EU 의 Data on Kubernetes Day 에서 그 간극을 메워 주는 발표가 나왔습니다. HSBC 의 DBA Laurent Parodi 와 CloudNativePG 공동 창시자 Gabriele Bartolini 가 함께 올라온 “From VMs to Kubernetes in a Large Global Bank: A DBA’s Journey” 입니다. 세계 최대급 은행이 PostgreSQL 을 VM 에서 Kubernetes 로 옮긴 여정을 DBA 의 시점에서 풀어낸 발표입니다.

Data on Kubernetes Day 발표 영상입니다.
https://www.youtube.com/watch?v=m0LBKjlxrog

EDB 의 리캡 글
https://www.enterprisedb.com/blog/vms-kubernetes-dbas-journey-large-global-bank

발표를 보면서 제가 요약해 둔 내용은 이렇습니다.

• Multi-tenant 클러스터로 구성했습니다. 하나의 Kubernetes 안에 여러 팀의 PostgreSQL 클러스터가 동시에 같은 k8s 환경에 존재할 수 있습니다.
• VM 시절에는 패치가 가장 큰 골칫거리였는데, Kubernetes 위의 PostgreSQL 에서는 rolling 방식으로 가볍게 패치할 수 있게 되었습니다.
• namespace 별로 image catalog 를 저장해서 버전을 컨트롤할 수 있게 구성했습니다. 팀마다 어떤 PostgreSQL 이미지 버전을 쓸지 독립적으로 관리됩니다.
• 한 Kubernetes 안에서 각 클러스터를 독립적으로 관리할 수 있게 구성했습니다.
• 패치를 자동화해서 기본적으로는 월별 패치를 진행하되, critical 한 CVE 가 발생하면 몇 시간 내로 패치를 배포할 수 있는 대응 체계를 갖췄습니다. 발표자의 표현을 빌리면, 이제는 패치가 전혀 두렵지 않은 수준까지 올라왔다고 합니다.

VM 시절의 HSBC 가 겪던 문제는 애플리케이션 배포 속도를 못 따라가는 느린 프로비저닝, dev 와 staging 과 production 사이의 설정 드리프트, 수동이라 실수가 끼어드는 failover 와 DR, 그리고 DBA 와 인프라와 개발 사이의 사일로입니다.

이 발표에서 저에게 가장 크게 와닿은 건 “시간 단위 패치” 였습니다. VM 위에서 PostgreSQL 마이너 패치를 해 본 DBA 라면 이게 어떤 의미인지 압니다. 점검 공지, 다운타임 협의, 순서 짜기, 새벽 작업까지, 그 모든 것이 rolling patch 한 번으로 접히는 세계가 은행이라는 가장 보수적인 환경에서 실제로 돌아가고 있다는 이야기입니다.

가용성

HSBC 의 “패치가 두렵지 않다” 는 말을 가능하게 하는 것이 CloudNativePG 의 가용성 설계입니다.

마이너 버전 패치나 이미지 교체는 rolling update 로 이뤄집니다. replica 들을 하나씩 새 이미지로 갈아 끼운 뒤 마지막에 primary 를 switchover 하는 방식이라, 클라이언트가 체감하는 중단은 수 초 수준의 전환 한 번으로 줄어듭니다. primary 에 장애가 나면 다음 흐름이 사람 개입 없이 이어집니다.

primary 장애 감지
    ↓
각 replica 의 LSN 비교 → 가장 앞서 있는 replica 를 자동 승격
    ↓
옛 primary 는 pg_rewind 로 새 primary 의 replica 로 재편입

VM 시절의 HA 는 Pacemaker 든 repmgr 이든 Patroni 든, DBA 가 밤에 깨어나 상태를 확인해야 안심이 되는 무언가였습니다. CloudNativePG 의 HA 는 Kubernetes 의 reconciliation loop 그 자체입니다. 선언된 상태와 실제 상태가 어긋나면 수렴할 때까지 operator 가 알아서 움직입니다. “가용성을 운영한다” 에서 “가용성이 선언되어 있다” 로 문장의 주어가 바뀌는 것이고, 저는 이 주어의 교체가 앞으로 DBA 라는 직업의 일하는 방식을 바꿀 것이라고 생각합니다.

Sandbox 에서 Graduated 로

CloudNativePG 는 2025년 1월 21일 CNCF Sandbox 에 합류했고, 지금은 Incubation 신청이 진행 중입니다. CNCF 프로젝트 건강 점수는 81점(Excellent)이고, 최근 1년 기여자 수는 26%, 기여 조직 수는 30% 늘었습니다. GitHub star 는 8천을 훌쩍 넘겨 PostgreSQL operator 중 가장 많습니다.

물론 아직 Sandbox 단계입니다. 하지만 데이터 주권이라는 화두가 커질수록 프라이빗 환경의 PostgreSQL 표준에 대한 수요는 늘 것이고, HSBC 같은 대형 금융기관의 프로덕션 사례가 쌓일수록 Incubation 을 지나 Graduated 까지 가는 길은 시간문제라고 확신하는 편입니다.

그리고 이 기록의 진짜 결론은 프로젝트가 아니라 저에 관한 것입니다. 저는 그 흐름에 맞춰서 함께 성장할 예정입니다. 지금처럼 로컬 환경에서 operator 를 빌드하고 부수면서 동작 원리를 익히고, 이슈를 읽고, 언젠가는 제 코드가 이 프로젝트에 머지되는 것까지를 목표로 두고 있습니다. CloudNativePG 가 Graduated 배지를 다는 날, 일기장 같은 이 글을 다시 꺼내 읽으면서 그동안 저는 얼마나 깊어졌나 되짚어 볼 수 있었으면 합니다. 그러려고 오늘 여기에 적어 둡니다.