Kubernetes에서 PostgreSQL 운영하기: StatefulSet부터 CloudNativePG까지
2026년 02월 04일
김명준 차장 Consultant, Professional Services | EDB 코리아
Kubernetes 환경이 성숙해지면서 PostgreSQL과 같은 전통적인 관계형 데이터베이스 관리 시스템(Relational Database Management System, RDBMS)을 Kubernetes에서 운영하는 사례는 더 이상 낯설지 않습니다. 이미 많은 조직이 프로덕션 환경에서 데이터베이스를 컨테이너 기반으로 운영하고 있습니다.
하지만 실제 운영 경험이 쌓일수록 “Kubernetes에서 PostgreSQL을 운영한다”는 말이 단순히 배포 방식의 변화를 의미하지 않는다는 점이 분명해집니다. 데이터 정합성, 장애 조치, 백업과 복구, 업그레이드, 기술지원까지 함께 고려해야 하기 때문입니다.
이 글에서는 Kubernetes PostgreSQL 운영 과정에서 자연스럽게 마주하는 고민과 선택의 흐름을 정리합니다. Deployment와 StatefulSet의 한계부터 고가용성(High Availability, HA) 도구, PostgreSQL Operator, CloudNativePG, 운영 기준과 기술지원까지 단계별로 살펴봅니다.
1. Kubernetes PostgreSQL 운영에서 단순 배포가 어려운 이유
Kubernetes에 익숙해질수록 모든 워크로드를 동일한 방식으로 다루고 싶어집니다. Postgres는 Docker Hub에 공식 이미지를 제공하므로 이러한 유혹은 더 커질 수밖에 없습니다. 이미지를 확보했으니 그대로 배포하면 될 것처럼 보이기 때문입니다. 이에 따라 다른 프로그램과 마찬가지로 PostgreSQL도 처음에는 Deployment나 단순한 StatefulSet으로 시작하는 경우가 많습니다.
Deployment로 PostgreSQL을 운영할 때의 한계
Deployment는 상태 비저장(Stateless) 애플리케이션을 전제로 설계된 리소스입니다.
- 스토리지 구성에 따라 여러 파드가 동일한 PVC를 공유하도록 설정될 수 있습니다.
- 다중 인스턴스 환경에서는 데이터 잠금 충돌이나 데이터 손상 가능성이 현실적인 문제가 됩니다.
- 무엇보다 네트워크 스토리지의 I/O 지연과 동시 쓰기로 인한 데이터 손상(Corruption)을 막아줄 펜싱(Fencing) 메커니즘이 없습니다.
따라서 Deployment는 PostgreSQL의 상태(State)와 스토리지 의존성을 충분히 반영하지 못합니다.
StatefulSet이 필요하지만 충분하지 않은 이유
StatefulSet은 이러한 문제를 어느 정도 해결합니다.
- 파드별 고유한 이름과 네트워크 아이덴티티
- 파드마다 독립적인 PVC
- 재시작 이후에도 유지되는 스토리지 연결
하지만 운영을 시작하면 곧 다음 질문이 등장합니다. “Primary가 중단되면 어떤 인스턴스가 승격되는가?”, “Kubernetes는 이 상황을 어디까지 이해하고 있는가?” StatefulSet은 파드의 생명주기를 관리할 뿐, PostgreSQL의 역할(Role)이나 Failover의 의미를 알지 못합니다.
2. PostgreSQL 고가용성을 위한 repmgr와 Patroni 검토
PostgreSQL을 프로덕션에서 운영한다면 Failover와 데이터 정합성은 선택 사항이 아니라 전제 조건입니다. 이 시점부터 Kubernetes 외부에서 검증된 HA 도구들이 검토 대상에 오릅니다.
repmgr 기반 PostgreSQL HA 구성
PostgreSQL 커뮤니티에서 제공하는 repmgr는 비교적 단순한 구조의 도구입니다.
- Primary/Standby 관리 및 자동 Failover 지원
- 다만 Kubernetes 환경에서는 Witness 노드 구성이 필요하고, Failover 이후 Service/DNS 연계 로직을 별도로 구현해야 하는 등 외부 제어 로직이 늘어나는 구조입니다.
Patroni를 Kubernetes에 적용할 때의 구성 요소
Patroni는 VM 환경에서 사실상 표준으로 자리 잡은 PostgreSQL HA 솔루션입니다.
- 정교한 리더 선출 및 다양한 장애 시나리오 대응
- 그러나 Kubernetes에 수동으로 적용하면 StatefulSet, Headless Service, ConfigMap, RBAC 등 복잡한 구성이 필요하며, DB 클러스터가 하나의 선언적 객체로 보이지 않습니다.
이 시점에서 자연스럽게 이런 질문이 나옵니다. “Kubernetes에서 굳이 Kubernetes답지 않게 운영해야 할까?”
3. PostgreSQL Operator와 CloudNativePG를 선택하는 이유
PostgreSQL을 Kubernetes에서 장기적으로 운영하려 한다면 결국 Operator라는 개념을 마주하게 됩니다. Operator는 단순한 배포 자동화를 넘어 데이터베이스의 상태를 이해하고, 장애 상황에 맞게 조정하며, 운영자의 개입을 최소화하는 도메인 지식을 포함한 컨트롤러를 제공합니다.
PostgreSQL Operator마다 다른 설계 방식
PostgreSQL Operator들을 살펴보면 기능보다 먼저 설계 철학의 차이가 눈에 들어옵니다.
- 일부 Operator는 Patroni를 사이드카 형태로 포함해 기존 HA 패턴을 유지합니다. 이를 위해서는 etcd나 Consul 같은 별도의 분산 구성 저장소(Distributed Configuration Store, DCS)를 관리해야 하는 딜레마가 생깁니다.
Kubernetes API 중심으로 설계된 CloudNativePG
CloudNativePG는 PostgreSQL HA를 구현하기 위해 기존 HA 도구를 포함하는 대신 Kubernetes API 자체를 중심에 둡니다.
- 별도의 DCS 없이 동작
- 파드 내부에 경량화된 Instance Manager 포함
- PostgreSQL 프로세스의 라이프사이클과 클러스터 상태를 Kubernetes와 직접 동기화
이 접근은 더 많은 기능을 추가하기보다는 운영자가 관리해야 할 범위를 줄이는 방향에 가깝습니다.
4. Kubernetes PostgreSQL 운영 시 확인해야 할 핵심 기준
Kubernetes에서 PostgreSQL을 실제로 운영하다 보면 다음과 같은 기준이 점점 중요해집니다.
- 장애 이후 얼마나 빠르게 복구되는가
- 데이터 정합성을 어느 수준까지 보장할 수 있는가
- 백업과 복구가 운영 흐름에 자연스럽게 녹아 있는가
- “공포스러운 메이저 버전 업그레이드”를 얼마나 안전하고 자동화된 방식으로 처리할 수 있는가
이 과정에서 pg_rewind를 활용한 빠른 재합류, 설정 기반의 동기식 복제, WAL 아카이빙과 특정 시점 복구(Point-in-Time Recovery, PITR)의 일관된 관리 같은 요소는 운영 난이도를 좌우하는 기준이 됩니다.
5. CloudNativePG 기술지원을 고려해야 하는 시점
여기까지는 기술적인 이야기입니다. 하지만 프로덕션 환경에서는 다른 질문이 반드시 따라옵니다. “문제가 생겼을 때 누가 책임지는가?”
데이터베이스는 잘 동작하는 동안보다 문제가 발생했을 때 그 가치가 평가됩니다. 장애 원인 분석, 재현 가능성, 패치와 우회 방안 등 모든 과정에서 공식적인 기술지원(Supportability)은 더 이상 부차적인 요소가 아닙니다.
현실적으로 Kubernetes 환경에서 PostgreSQL Operator에 대해 국내에서 상업적 기술지원을 받을 수 있는 선택지는 매우 제한적입니다. 이 중 EnterpriseDB(EDB)는 CloudNativePG에 대해 세 가지 버전의 오퍼레이터를 대상으로 전문 기술지원을 제공하고 있습니다.
- EDB Postgres® AI for CloudNativePG™ Global Cluster (멀티 마스터 클러스터)
- EDB Postgres® AI for CloudNativePG™ Cluster (엔터프라이즈 기능 구현)
- CloudNativePG (커뮤니티 버전)
6. 오픈소스 PostgreSQL과 상업적 기술지원의 차이
이 지점에서 흔히 등장하는 반론이 있습니다. “오픈소스인데 커뮤니티로 충분하지 않나?” 이 질문 자체는 틀리지 않습니다. 실제로 많은 환경에서는 커뮤니티 기반 운영으로도 충분합니다. 다만 다음과 같은 전제 조건이 필요합니다.
- 장애를 내부에서 분석·재현할 수 있는가
- 커널, 스토리지, 네트워크까지 포함해 문제를 좁혀갈 수 있는가
- 책임을 내부 조직이 감당하고 근본 문제를 해결할 준비가 되어 있는가
이 조건이 충족된다면 기술지원은 선택 사항일 수 있습니다. 그러나 그렇지 않다면 기술지원은 비용이 아니라 리스크 관리 수단이 됩니다.
Kubernetes PostgreSQL 운영 전략을 정리하며
Kubernetes에서 PostgreSQL을 운영하는 일은 단순히 새로운 기술을 도입하는 문제가 아닙니다. Kubernetes의 재조정(Reconciliation) 모델, PostgreSQL의 데이터 정합성 요구사항, 운영 조직이 감당할 수 있는 책임 범위가 충돌하는 지점에서 운영자는 선택을 요구받습니다.
어떤 도구를 사용하느냐보다 중요한 것은 문제가 발생했을 때 어디까지 시스템에 맡기고 어디부터 사람이 책임질 것인지 정하는 일입니다. Operator는 그 경계를 조정하는 도구이고, CloudNativePG는 그중 하나의 선택지입니다. 기술적 완성도뿐 아니라 “누가 함께 고민해 주는가”라는 질문을 끝내 피할 수 없다는 점만은 분명합니다.
Kubernetes PostgreSQL 운영 FAQ
Kubernetes에서 PostgreSQL을 Deployment로 운영하면 안 되나요?
Deployment는 Stateless 애플리케이션을 전제로 하므로 PostgreSQL의 상태와 스토리지 의존성을 충분히 반영하기 어렵습니다. 스토리지 구성과 다중 인스턴스 운영 방식에 따라 잠금 충돌이나 데이터 손상 위험도 고려해야 합니다.
StatefulSet만으로 PostgreSQL 고가용성을 구현할 수 있나요?
StatefulSet은 파드별 고유한 네트워크 아이덴티티와 독립적인 PVC를 제공하지만 PostgreSQL의 Primary·Standby 역할이나 Failover 의미를 이해하지는 못합니다. 따라서 프로덕션 고가용성을 위해서는 데이터베이스 상태를 인식하는 별도의 운영 체계가 필요합니다.
PostgreSQL Operator는 어떤 역할을 하나요?
PostgreSQL Operator는 데이터베이스 상태를 이해하고 장애 상황에 맞게 조정하는 도메인 지식을 포함한 컨트롤러입니다. 단순 배포 자동화를 넘어 클러스터 운영 과정에서 관리자의 개입을 줄이는 역할을 합니다.
CloudNativePG는 별도의 DCS가 필요한가요?
본문에서 설명한 CloudNativePG 접근 방식은 Kubernetes API 자체를 중심에 두며 별도의 DCS 없이 동작합니다. 파드 내부의 Instance Manager가 PostgreSQL 프로세스의 라이프사이클과 클러스터 상태를 Kubernetes와 직접 동기화합니다.
Kubernetes PostgreSQL 운영에서 기술지원을 고려해야 하는 이유는 무엇인가요?
프로덕션 장애가 발생하면 원인 분석, 재현, 패치와 우회 방안 마련이 필요합니다. 이러한 업무를 내부에서 감당하기 어렵다면 공식 기술지원은 장애 대응 책임과 운영 리스크를 관리하는 수단이 될 수 있습니다.