글로벌 은행의 쿠버네티스 PostgreSQL 전환: CloudNativePG 마이그레이션 전략

Kim Kaluba · 2026년 5월 19일

세계 최대 금융기관 중 하나가 VM 기반 PostgreSQL을 쿠버네티스 네이티브 환경으로 전환하며 데이터베이스 운영을 어떻게 재설계했는지, 그리고 엔터프라이즈 DBA가 이 사례에서 무엇을 배울 수 있는지 살펴봅니다.

글로벌 은행 규모로 데이터베이스를 운영하려면 매우 엄격한 가용성, 컴플라이언스 및 보안 요건을 충족해야 합니다. 한 대형 금융기관이 기존 VM 기반 PostgreSQL 배포 환경을 쿠버네티스로 전환하기로 결정했을 때도 기술적·문화적 과제가 뒤따랐습니다. 그러나 더 안정적이고 확장 가능하며 통제 가능한 데이터베이스 운영 환경을 구축할 수 있다는 가능성은 충분한 전환 동기가 되었습니다.

이 사례는 쿠버네티스 PostgreSQL 도입을 검토하는 기업이 기술 선택뿐 아니라 조직 역량, 마이그레이션 절차, 운영 표준을 어떻게 준비해야 하는지 보여줍니다.

글로벌 은행의 PostgreSQL 전환 사례

이 사례는 암스테르담에서 열린 KubeCon + CloudNativeCon EU 2026 직전의 Data on Kubernetes Day에서 발표되었습니다. 고도로 규제된 금융 환경에서 미션 크리티컬 PostgreSQL 데이터베이스를 마이그레이션한 과정을 실무자의 관점에서 소개한 발표였습니다.

EDB 쿠버네티스 부문 VP 겸 수석 아키텍트이자 CloudNativePG 공동 창립자인 Gabriele Bartolini와 HSBC의 베테랑 DBA Laurent Parodi가 함께 무대에 올랐습니다. 한 사람은 오픈소스 도구를 만든 개발자의 관점에서, 다른 한 사람은 해당 도구로 프로덕션 워크로드를 운영한 엔터프라이즈 DBA의 관점에서 전환 과정을 설명했습니다.

발표 전체 영상은 아래에서 확인할 수 있습니다.

VM 기반 PostgreSQL 운영의 한계

엔터프라이즈 PostgreSQL은 오랫동안 가상머신(VM) 위에서 운영되어 왔습니다. VM 모델은 DBA, 구매 부서, 컴플라이언스 팀 모두에게 익숙하고 감사 절차에도 적합했습니다. 그러나 조직과 데이터베이스 규모가 커지면서 기존 운영 방식의 한계가 드러나기 시작했습니다.

새 데이터베이스 클러스터를 프로비저닝하는 데 며칠에서 몇 주가 걸렸고, 개발·스테이징·프로덕션 환경 사이에는 구성 차이가 발생했습니다. 재해 복구 절차는 복잡하고 수작업 의존도가 높았습니다. 소프트웨어 출시 속도를 높여야 한다는 요구가 커지면서 이러한 운영 방식은 엔지니어링 조직 전체의 병목으로 작용했습니다.

VM 기반 PostgreSQL 운영에서 나타날 수 있는 주요 과제는 다음과 같습니다.

• 애플리케이션 배포 속도를 따라가기 어려운 느린 프로비저닝
• 개발·스테이징·프로덕션 환경 간 구성 드리프트
• 수작업 의존도가 높고 오류 가능성이 있는 페일오버 및 재해 복구
• 데이터베이스를 GitOps 및 CI/CD 파이프라인에 통합하기 어려운 구조
• DBA, 인프라 및 개발팀 사이의 운영 사일로

이러한 한계 때문에 기업들은 PostgreSQL 운영 독립성을 높일 수 있는 대안을 찾고 있습니다. 쿠버네티스가 DBA 커뮤니티의 관심을 받고 CloudNativePG 오퍼레이터 도입이 확대되는 배경도 여기에 있습니다.

CloudNativePG가 제공하는 쿠버네티스 PostgreSQL 운영 모델

CloudNativePG는 쿠버네티스에서 PostgreSQL 클러스터를 운영하도록 설계된 오픈소스 오퍼레이터입니다. 쿠버네티스 컨트롤러가 PostgreSQL의 목표 상태를 지속적으로 확인하고 조정하며, 프라이머리 선출, 동기·비동기 복제, 자동 페일오버, 스위치오버 및 구성 관리를 선언형 방식으로 처리합니다. 이러한 기능을 위해 Patroni나 repmgr 같은 별도 고가용성 프레임워크에 의존하지 않습니다.

DBA의 전문성을 쿠버네티스 내부의 운영 로직으로 구현하면 하이퍼스케일러의 ‘운영의 벽(Operational Wall)’을 낮출 수 있습니다. 이를 통해 개발자에게 필요한 자동화와 기업에 필요한 통제권을 함께 제공하는 DBaaS를 구축할 수 있습니다.

— Gabriele Bartolini, EDB 쿠버네티스 부문 VP 겸 수석 아키텍트

핵심은 쿠버네티스가 단순한 배포 플랫폼이 아니라 지속적으로 상태를 조정하는 시스템이라는 점입니다. 원하는 상태를 정의하면 플랫폼이 실제 상태를 확인하고 차이를 줄이기 위해 계속 작동합니다. 데이터베이스 관점에서는 자가 치유 클러스터, 자동 백업 스케줄링 및 시점 복구(PITR)를 표준 운영 절차에 포함할 수 있다는 의미입니다. 동시에 통제와 컴플라이언스 요건에 맞는 사람의 감독 체계도 유지해야 합니다.

VM에서 쿠버네티스로 PostgreSQL을 전환하는 4단계

Laurent Parodi의 발표는 대형 글로벌 은행에서 실제 전환을 추진한 DBA의 경험을 보여주었습니다. 기존 DBA에게 쿠버네티스 개념, YAML 매니페스트 및 선언형 운영 방식은 낯설 수 있습니다. 따라서 기술 도입과 함께 기존 데이터베이스 전문성을 새로운 운영 환경으로 확장하는 과정이 필요합니다.

이 은행의 VM 기반 PostgreSQL에서 쿠버네티스 네이티브 모델로의 전환은 다음 네 단계로 진행되었습니다.

1. 후보 워크로드 평가 및 개념검증(PoC)

팀은 전면적인 마이그레이션에 앞서 쿠버네티스에 적합한 후보 워크로드를 선정하고 성능 기준을 수립했습니다. 이후 은행의 보안 및 컴플라이언스 요건을 기준으로 CloudNativePG를 검증했습니다. 이 과정은 기술의 적합성과 함께 팀이 해당 환경을 안정적으로 운영할 수 있는지 확인하는 단계였습니다.

2. DBA 역량 강화와 운영 문화 전환

DBA들은 파드, 오퍼레이터, 커스텀 리소스 및 GitOps 워크플로 등 쿠버네티스의 기본 요소를 익혔습니다. 목표는 DBA를 완전히 다른 역할로 바꾸는 것이 아니라, 기존 PostgreSQL 전문성을 쿠버네티스 운영 영역까지 확장하는 것이었습니다.

3. 마이그레이션 도구 검증과 서비스 중단 최소화

기술과 운영 역량에 대한 확신을 확보한 뒤 프로덕션 워크로드 이전을 시작했습니다. CloudNativePG의 임포트 기능을 활용하면 VM 기반 PostgreSQL과 매니지드 클라우드 PostgreSQL을 쿠버네티스로 이전할 수 있습니다. 금융 서비스처럼 중단 허용 범위가 매우 제한적인 환경에서는 복제 상태, 전환 절차 및 복구 계획을 사전에 충분히 검증하는 것이 중요합니다.

4. 단계적 프로덕션 전개와 운영 안정화

마지막 단계에서는 쿠버네티스 네이티브 PostgreSQL을 새로운 운영 표준으로 정착시켰습니다. 적용 범위를 단계적으로 확대하고 CI/CD 및 GitOps 파이프라인을 통합했으며, 새로운 운영 모델에 맞게 온콜 런북을 개편했습니다. 이를 통해 팀은 기존 환경과 같은 수준의 확신을 바탕으로 장애에 대응할 수 있게 되었습니다.

데이터 통제권과 운영 독립성 확보

금융 서비스 분야에서 특히 중요한 주제는 데이터와 데이터베이스 운영에 대한 통제권입니다. 독점적인 DBaaS에 전적으로 의존하면 운영 모델과 업그레이드 주기, 데이터 처리 방식에 대한 선택 범위가 제한될 수 있습니다. 데이터 및 AI 통제 전략을 수립하고 오픈소스 오퍼레이터를 활용해 자체 인프라에서 PostgreSQL을 운영하면 기술 선택권과 워크로드 이식성을 높일 수 있습니다.

규제 기관이 데이터의 저장 위치와 접근 방식을 입증하도록 요구하는 환경에서는 이러한 통제력이 중요합니다. 단일 클라우드 제공업체의 매니지드 데이터베이스에 과도하게 의존할 경우 가격 변경, 기능 지원 종료 및 공급업체 종속의 영향을 받을 수 있기 때문입니다. 쿠버네티스 기반 오픈소스 PostgreSQL 운영 모델은 이러한 위험을 줄이고 인프라 선택의 유연성을 높이는 데 도움이 됩니다.

쿠버네티스 네이티브 PostgreSQL 데이터 보호

같은 행사에서 EDB는 CloudNativePG를 기반으로 한 차세대 쿠버네티스 네이티브 데이터 보호 솔루션을 공개했습니다. 이 솔루션은 네이티브 WAL 스트리밍 기반 보호 기능을 중앙 인터페이스에서 관리하고, FIPS 140-3 보안 표준을 충족하는 종단 간 암호화를 제공합니다. 이를 통해 기업은 개방적이고 이식 가능한 인프라에서 엔터프라이즈급 PostgreSQL 보호 체계를 구축할 수 있습니다.

엔터프라이즈 DBA를 위한 핵심 시사점

• 기존 DBA 전문성을 확장해야 합니다. 데이터베이스 지식을 버리는 것이 아니라 쿠버네티스 운영 역량을 그 위에 더하는 접근이 필요합니다.
• PoC는 중요도가 낮은 워크로드부터 시작해야 합니다. 핵심 시스템을 옮기기 전에 성능, 장애 복구 및 운영 절차를 충분히 검증해야 합니다.
• 선언형 구성으로 환경 간 차이를 줄일 수 있습니다. CloudNativePG의 목표 상태 관리 방식은 구성 드리프트를 예방하고 컴플라이언스 검증을 단순화하는 데 도움이 됩니다.
• 마이그레이션 경로를 사전에 검증해야 합니다. VM과 매니지드 클라우드 PostgreSQL 모두 쿠버네티스로 이전할 수 있지만, 서비스 영향과 복구 가능성을 기준으로 전환 절차를 설계해야 합니다.
• 감사 가능성과 운영 독립성을 함께 고려해야 합니다. 오픈소스 오퍼레이터 기반 운영은 규제 요건을 충족하면서 플랫폼 선택권을 유지하는 데 도움이 될 수 있습니다.

쿠버네티스 PostgreSQL 전환, 이제는 실행 전략이 중요합니다

쿠버네티스는 애플리케이션 플랫폼을 넘어 데이터베이스 운영 환경으로 확장되고 있습니다. 글로벌 은행의 사례는 CloudNativePG가 엄격한 컴플라이언스와 보안 요건을 가진 환경에서도 PostgreSQL 운영 모델의 대안이 될 수 있음을 보여줍니다.

평가, 역량 강화, 마이그레이션, 안정화로 이어지는 단계적 접근은 다른 기업에서도 적용할 수 있습니다. 다만 워크로드 특성, 복구 목표, 보안 정책 및 운영 조직의 준비 수준을 기준으로 도입 범위를 결정해야 합니다. 자세한 내용은 발표 영상과 EDB Postgres® AI for CloudNativePG™ 페이지에서 확인할 수 있습니다.

EDB Postgres AI와 CloudNativePG, 더 알아보기

쿠버네티스 기반 PostgreSQL 전환이나 PoC가 궁금하시다면 EDB Korea로 문의해 주세요.

메일: salesinquiry@enterprisedb.com

원문: From VMs to Kubernetes: A DBA’s Journey in a Large Global Bank (EDB Blog)