[EDB KR 블로그]Kubernetes 환경에서 PostgreSQL을 운영하기 위한 고민과 선택들
2026년 02월 04일
김명준 차장 Consultant, Professional Services | EDB 코리아
Kubernetes 환경이 성숙해지면서 PostgreSQL과 같은 전통적인 RDBMS를 Kubernetes 위에서 운영하는 사례는 더 이상 낯설지 않다. 이미 많은 조직이 프로덕션 환경에서 데이터베이스를 컨테이너 기반으로 운영하고 있다.
하지만 실제 운영 경험이 쌓일수록, “Kubernetes에서 PostgreSQL을 운영한다”는 말이 단순히 배포 방식의 변화를 의미하지 않는다는 점이 분명해진다.
이 글은 Kubernetes 환경에서 PostgreSQL을 운영하는 사람이 자연스럽게 거치게 되는 고민과 선택의 흐름을 정리한 기록이다.
1. 첫 번째 관문: “그냥 올리면 안 되는 이유”
Kubernetes에 익숙해질수록, 모든 워크로드를 동일한 방식으로 다루고 싶어진다. 심지어 Postgres는 도커 허브에 공식 이미지를 제공하고 있으니 그 유혹은 더 커질 수밖에 없다. 이미지도 구했으니 그냥 올리면 될 것만 같다. 때문에 여느 프로그램들처럼 PostgreSQL 역시 처음에는 Deployment나 단순한 StatefulSet으로 시작하게 된다.
Deployment의 한계
Deployment는 Stateless 애플리케이션을 전제로 설계된 리소스다.
- 스토리지 구성에 따라 여러 파드가 동일한 PVC를 공유하도록 설정될 수 있다.
- 다중 인스턴스 환경에서는 데이터 락 충돌이나 데이터 손상 가능성이 현실적인 문제가 된다.
- 무엇보다, “네트워크 스토리지의 I/O 지연”과 “동시 쓰기로 인한 데이터 오염(Corruption)”을 막아줄 펜싱(Fencing) 메커니즘이 부재하다.
Deployment는 PostgreSQL의 상태(State)와 스토리지 의존성을 충분히 반영하지 못한다.
결국 선택은 StatefulSet, 그러나 충분하지는 않다
StatefulSet은 이 문제를 어느 정도 해결한다.
- 파드별 고유한 이름과 네트워크 아이덴티티
- 파드마다 독립적인 PVC
- 재시작 이후에도 유지되는 스토리지 연결
하지만 운영을 시작하면 곧 다음 질문이 등장한다. “Primary가 죽으면 누가 승격되는가?”, “Kubernetes는 이 상황을 어디까지 이해하고 있는가?” StatefulSet은 파드의 생명주기를 관리할 뿐, PostgreSQL의 역할(Role)이나 Failover의 의미를 알지 못한다.
2. 고가용성(HA)을 고민하기 시작하면
PostgreSQL을 프로덕션에서 운영한다면, Failover와 데이터 정합성은 선택이 아니라 전제 조건이다. 이 시점부터 Kubernetes 외부에서 검증된 HA 도구들이 검토 대상에 오른다.
repmgr
PostgreSQL 커뮤니티에서 제공하는 repmgr는 비교적 단순한 구조의 도구다.
- Primary/Standby 관리 및 자동 Failover 지원
- 다만 Kubernetes 환경에서는 Witness 노드 구성 필요, Failover 이후 Service/DNS 연계 로직을 별도로 구현해야 함 등 외부 제어 로직이 늘어나는 구조다.
Patroni
Patroni는 VM 환경에서 사실상 표준으로 자리 잡은 PostgreSQL HA 솔루션이다.
- 정교한 리더 선출 및 다양한 장애 시나리오 대응
- 그러나 Kubernetes에 수동으로 적용할 경우 StatefulSet, Headless Service, ConfigMap, RBAC 등 복잡한 구성이 필요하며, DB 클러스터가 하나의 선언적 객체로 보이지 않는다.
이 시점에서 자연스럽게 이런 질문이 나온다. “Kubernetes 위에서, 굳이 Kubernetes답지 않게 운영해야 할까?”
3. Operator를 고민하게 되는 시점
PostgreSQL을 Kubernetes에서 장기적으로 운영하려 한다면, 결국 Operator라는 개념을 마주하게 된다. Operator는 단순한 배포 자동화를 넘어서, 데이터베이스의 상태를 이해하고 장애 상황에 맞게 조정하며 운영자의 개입을 최소화하는 도메인 지식을 포함한 컨트롤러를 제공한다.
서로 다른 Operator들의 접근 방식
PostgreSQL Operator들을 살펴보면, 기능보다 먼저 설계 철학의 차이가 눈에 들어온다.
- 일부 Operator는 Patroni를 사이드카 형태로 포함해 기존 HA 패턴을 유지한다. 이를 위해서는 etcd나 Consul 같은 별도의 DCS(분산 코디네이터)를 관리해야 하는 딜레마가 생긴다.
Kubernetes API 중심 설계라는 선택지: CloudNativePG
CloudNativePG는 PostgreSQL HA를 해결하는 방식으로 기존 HA 도구를 포함하기보다는, Kubernetes API 자체를 중심에 둔다.
- 별도의 DCS 없이 동작
- 파드 내부에 경량화된 Instance Manager 포함
- PostgreSQL 프로세스의 라이프사이클과 클러스터 상태를 Kubernetes와 직접 동기화
이 접근은 “더 많은 기능”보다는 운영자가 관리해야 할 범위를 줄이는 방향에 가깝다.
4. 운영 관점에서 중요해지는 기준들
Kubernetes에서 PostgreSQL을 실제로 운영하다 보면, 다음과 같은 기준들이 점점 중요해진다.
- 장애 이후 얼마나 빠르게 복구되는가
- 데이터 정합성을 어느 수준까지 보장할 수 있는가
- 백업과 복구가 운영 흐름에 자연스럽게 녹아 있는가
- “공포스러운 메이저 버전 업그레이드”를 얼마나 안전하고 자동화된 방식으로 처리할 수 있는가
이 과정에서 pg_rewind를 활용한 빠른 재합류, 설정 기반의 동기식 복제, WAL 아카이빙과 PITR의 일관된 관리 같은 요소들은 운영 난이도를 좌우하는 기준이 된다.
5. 기술지원이 고려 대상이 되는 순간
여기까지는 기술적인 이야기다. 하지만 프로덕션 환경에서는 다른 질문이 반드시 따라온다. “문제가 생겼을 때, 누가 책임지는가?”
데이터베이스는 “잘 동작하는 동안”보다 문제가 발생했을 때 그 가치가 평가된다. 장애 원인 분석, 재현 가능성, 패치와 우회 방안 등 모든 과정에서 **공식적인 기술지원(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의 재조정(Reconciliation) 모델, PostgreSQL의 데이터 정합성 요구사항, 운영 조직이 감당할 수 있는 책임 범위가 충돌하는 지점에서 운영자는 선택을 강요받는다.
어떤 도구를 쓰느냐보다 중요한 것은, 문제가 발생했을 때 어디까지를 시스템에 맡기고 어디부터를 사람이 책임질 것인가다. Operator는 그 경계를 조정하는 도구이고, CloudNativePG는 그중 하나의 선택지다. 기술적 완성도뿐 아니라 “누가 함께 고민해 주는가”라는 질문을 끝내 피할 수 없다는 점만은 분명하다.
메일: salesinquiry@enterprisedb.com
