VM에서 쿠버네티스로: 글로벌 대형 은행 DBA의 여정
Kim Kaluba · 2026년 5월 19일
세계 최대 금융기관 중 하나가 PostgreSQL을 쿠버네티스에 네이티브로 들여오며 데이터베이스 운영을 어떻게 다시 설계했는지, 그리고 모든 엔터프라이즈 DBA가 여기서 무엇을 배울 수 있는지 살펴봅니다.
글로벌 은행 규모로 데이터베이스를 운영한다는 것은, 지구상에서 가장 엄격한 수준의 가동률(uptime), 컴플라이언스, 보안 요구사항 아래에서 일한다는 뜻입니다.
그래서 한 대형 금융기관의 팀이 기존 VM 기반 PostgreSQL 배포를 버리고 쿠버네티스로 옮기기로 결정했을 때, 그 과정에 따르는 기술적·문화적 도전은 결코 가벼운 것이 아니었습니다. 그럼에도 더 안정적이고, 더 확장 가능하며, 더 안전한 환경이라는 가능성은 모든 망설임을 넘어설 만큼 매력적이었습니다.
여기서 얻은 교훈은, 같은 전환을 고민하는 모든 기업에게 값을 매길 수 없을 만큼 귀중합니다.
객석을 기립하게 만든 발표
이 이야기는 Data on Kubernetes Day에서 발표되었습니다. 암스테르담에서 열린 KubeCon + CloudNativeCon EU 2026 바로 직전에 함께 개최된 부대 행사였죠. 발표는 고도로 규제된 환경에서 미션 크리티컬 데이터베이스를 마이그레이션한 과정을, 실무자의 눈높이에서 솔직하게 풀어낸 자리였습니다.
EDB의 쿠버네티스 부문 VP 겸 수석 아키텍트이자 CloudNativePG 오퍼레이터의 공동 창립자인 Gabriele Bartolini가, 세계 최대 은행 중 하나인 HSBC의 베테랑 DBA Laurent Parodi와 함께 무대에 올랐습니다. 두 사람은 이 이야기를 양쪽 관점에서 들려주었습니다. 한 명은 오픈소스 도구를 만든 사람으로서, 다른 한 명은 그 도구에 자신의 프로덕션 워크로드를 건 엔터프라이즈 운영자로서 말이죠.
발표 전체 영상은 아래에서 보실 수 있습니다.
VM은 왜 뒤로 밀려나고 있을까
엔터프라이즈 PostgreSQL은 역사 대부분 동안 다른 모든 엔터프라이즈 데이터베이스가 살던 곳, 즉 가상머신(VM) 위에서 동작해 왔습니다. VM 모델은 익숙하고 편안했으며, 감사(audit)도 가능했습니다. DBA도 이해했고, 구매 부서도 이해했고, 컴플라이언스 팀도 이해했습니다. 하지만 조직이 커지면서 균열이 드러나기 시작했습니다.
새 데이터베이스 클러스터를 프로비저닝하는 데 며칠에서 몇 주가 걸렸습니다. 환경 간 구성 드리프트(configuration drift)는 골칫거리였습니다. 재해 복구는 복잡하고 수작업이 많았습니다. 그리고 클라우드 속도로 더 빠르게 소프트웨어를 출시하라는 압박이 커지면서, 낡은 운영 모델은 엔지니어링 조직 전체의 발목을 잡는 요인이 되어 갔습니다.
이런 발목 잡기를 일으키는 VM의 핵심 문제들은 다음과 같습니다.
- 애플리케이션 배포 속도를 따라가지 못하는 느린 프로비저닝 주기
- 개발·스테이징·프로덕션 환경 간의 구성 드리프트
- 수작업에 의존해 오류가 잦은 페일오버 및 재해 복구 절차
- 데이터베이스를 최신 GitOps·CI/CD 파이프라인에 통합하기 어려운 점
- DBA, 인프라, 개발 팀 사이에 생기는 운영 사일로(silo)
위와 같은 한계를 고려하면, 조직들이 더 나은 길을 찾는 것은 놀라운 일이 아닙니다. 쿠버네티스가 DBA 커뮤니티에서 이토록 인기를 얻고 있는 이유, 그리고 CloudNativePG 오퍼레이터가 성장하는 이유가 바로 여기에 있습니다.
CloudNativePG: 더 나은 길
CloudNativePG 오퍼레이터는 데이터베이스의 이런 발목 잡기를 없애기 위해 처음부터 목적에 맞게 설계되었습니다. VM 시대의 아키텍처에 쿠버네티스를 억지로 덧붙인 다른 오퍼레이터들과 달리, CloudNativePG는 쿠버네티스 컨트롤러를 PostgreSQL의 권위 있는 운영 두뇌로 다루도록 밑바닥부터 설계되었습니다. Patroni나 repmgr 같은 외부 의존성 없이, 프라이머리 선출, 동기·비동기 복제, 자동 페일오버, 스위치오버, 구성 관리를 네이티브하고 선언적(declarative)으로 처리합니다.
DBA의 지능을 쿠버네티스 내부의 운영 두뇌로 심어 넣으면, 하이퍼스케일러의 ‘운영의 벽(Operational Wall)’을 허물 수 있습니다. 그렇게 하면 개발자가 쓰기에 충분히 자동화되어 있으면서도, 기업이 통제하기에 충분히 주권적인 DBaaS가 만들어집니다.
— Gabriele Bartolini, EDB 쿠버네티스 부문 VP 겸 수석 아키텍트
핵심은, 쿠버네티스가 단순한 배포 플랫폼이 아니라 조정 루프(reconciliation loop)라는 점입니다. 원하는 상태(desired state)를 한 번 정의해 두면, 플랫폼은 그 상태를 달성하고 유지하기 위해 끊임없이 작동합니다. 데이터베이스 관점에서 이는 자가 치유(self-healing) 클러스터, 자동 백업 스케줄링, 시점 복구(point-in-time recovery)가 예외가 아니라 기본이 된다는 뜻입니다. 물론 통제와 컴플라이언스 요건을 보장하기 위해 필요한 만큼의 사람의 감독은 함께 갑니다.
DBA의 여정: 회의론자에서 옹호자로
대형 글로벌 은행 내부에서 들려준 Laurent Parodi의 이야기는, 순수하게 이론적인 발표에는 흔히 빠져 있는 현장감을 더해 주었습니다. DBA들이, 충분히 이해할 만하게도, 쿠버네티스를 회의적인 시선으로 바라봤습니다. 그들의 전문성은 수년에 걸쳐 전혀 다른 운영 모델 위에서 쌓아 올린 것이었기 때문입니다. 쿠버네티스 개념과 YAML 매니페스트, 그리고 선언형 철학을 새로 배우는 일은, 처음에는 어렵게 익힌 숙련을 버리고 불확실한 신세계로 뛰어드는 것처럼 느껴졌습니다.
Bartolini는 이 역학에 대해 폭넓게 글을 써 왔으며, 업계의 한 단계를 “역설적(paradoxical)”이라고 표현했습니다. 점점 더 많은 팀이 쿠버네티스에서 Postgres를 성공적으로 운영하는 한편, 다른 많은 팀은 여전히 이 전환에 저항하고 있다는 것이죠. 익숙한 검증 방식으로 되돌아가 보는 과정은 긴장을 누그러뜨리고, 새로운 접근법의 타당성과 신뢰성을 입증해 줍니다.
VM 기반 PostgreSQL 배포에서 쿠버네티스 네이티브 모델로 가는 이 은행의 여정은 하루아침에 이루어지지 않았습니다. 이 글로벌 은행에서는 그 여정이 의도적으로 설계된 네 단계로 펼쳐졌습니다.
1. 평가 및 개념검증(PoC)
전면적인 마이그레이션에 착수하기 전에, 팀은 쿠버네티스에 적합한 후보 워크로드를 식별하고, 성능 벤치마크를 수립하고, 은행의 엄격한 보안·컴플라이언스 요건에 맞춰 CloudNativePG를 스트레스 테스트했습니다. 이 단계는 기술 그 자체뿐 아니라, 그 기술을 효과적으로 운영할 수 있다는 팀의 역량에 대한 확신을 쌓는 과정이었습니다.
2. 팀 역량 강화 및 문화적 전환
어떤 플랫폼 마이그레이션이든 가장 큰 도전은 기술적인 부분이 아니라 사람입니다. DBA들은 파드(pod), 오퍼레이터, 커스텀 리소스, GitOps 워크플로 같은 쿠버네티스 기본 요소에 능숙해져야 했습니다. 목표는 DBA를 플랫폼 엔지니어로 바꾸는 것이 아니라, 이미 가진 전문성을 확장하는 것이었습니다.
3. 마이그레이션 도구 및 무중단 임포트
확신이 서고 역량이 다져지자, 팀은 운영 중인 워크로드를 옮기기 시작했습니다. CloudNativePG의 임포트 기능 덕분에 VM 기반 배포는 물론 매니지드 클라우드 서비스에서도 쿠버네티스로 마이그레이션할 수 있었습니다. 그것도 애플리케이션을 중단하지 않고서 말이죠. 24시간 365일 돌아가는 금융 서비스 환경에서는 결코 타협할 수 없는 요건입니다.
4. 프로덕션 전개 및 운영 안정화
마지막 단계는 쿠버네티스 네이티브 PostgreSQL을 새로운 표준으로 자리 잡게 하는 것이었습니다. 적용 범위를 점진적으로 넓히고, CI/CD와 GitOps 파이프라인을 통합했으며, 새로운 운영 모델에 맞게 온콜(on-call) 런북을 다시 작성했습니다. 그 결과 팀은 예전 방식에서 가졌던 것과 동일한 자신감으로 장애에 대응할 수 있게 되었습니다.
데이터 주권: 숨은 이점
반복해서 떠오른, 특히 금융 서비스 분야에서 깊이 공감을 산 주제 하나는 바로 주권(sovereignty)입니다. 하이퍼스케일러의 독점적 DBaaS가 당신의 데이터베이스를 관리하는 순간, 당신은 운영 모델과 업그레이드 주기, 그리고 궁극적으로 데이터 자체에 대한 통제권을 넘겨준 셈이 됩니다. 오픈소스 오퍼레이터로 자신의 인프라 위에서 PostgreSQL을 쿠버네티스로 운영하면, 그 통제권을 되찾고 데이터 주권을 회복할 수 있습니다.
이는 데이터가 어디에 위치하고 어떻게 접근되는지에 대한 입증된 통제를 규제 당국이 요구하는 상황에서 엄청나게 중요합니다. 또한 경쟁 측면에서도 중요합니다. 단일 클라우드 제공업체의 매니지드 데이터베이스 서비스에 전적으로 의존하는 조직은, 몇 년 뒤 실질적인 영향을 미칠 수 있는 가격 변동, 기능 지원 종료, 그리고 종속(lock-in)에 그대로 노출되기 때문입니다.
차세대 엔터프라이즈 데이터 보호
같은 행사에서 EDB는 CloudNativePG를 기반으로 한 차세대 쿠버네티스 네이티브 데이터 보호 솔루션을 미리 선보였습니다. 컨테이너 이전 시대를 위해 설계된 레거시 백업 도구를 과감히 넘어선 이 솔루션은, 네이티브 WAL 스트리밍을 통한 무손실에 가까운(near-zero data loss) 보호를 단일 중앙 인터페이스에서 관리하며, FIPS 140-3 보안 표준을 충족하는 종단 간(end-to-end) 암호화를 제공합니다. 선택지를 저울질하는 글로벌 은행에게 이는 매우 중요합니다. 독점적이고 폐쇄적인 하이퍼스케일러 클라우드에 종속되는 대신, 개방적이고 이식 가능한 인프라 위에서 엔터프라이즈급 보호를 제공하기 때문입니다.
DBA가 지금 당장 쿠버네티스 작업에 적용할 수 있는 핵심 시사점은 다음과 같습니다.
- DBA는 자신을 완전히 새로 만들 필요가 없습니다. 데이터베이스 전문성을 버리지 않고 그 위에 쿠버네티스 역량을 확장하면 됩니다.
- 개념검증(PoC)은 중요도가 낮은 워크로드부터 시작하세요. 1티어 시스템을 옮기기 전에 먼저 확신을 쌓아야 합니다.
- CloudNativePG의 선언형 모델은 구성 드리프트를 구조적으로 불가능하게 만듭니다. 이는 컴플라이언스 팀에게 큰 이점입니다.
- VM 호스팅 PostgreSQL과 클라우드 매니지드 PostgreSQL 모두에서 쿠버네티스로 옮기는 무중단에 가까운 마이그레이션 경로가 이미 존재합니다.
- 주권과 감사 가능성(auditability)은 쿠버네티스의 큰 이점이며, 규제 요건을 충족하도록 설계된 오픈소스 오퍼레이터 모델의 자유로움도 함께 따라옵니다.
앞으로의 길
이제 흐름은 더 이상 추측의 영역이 아닙니다. 쿠버네티스는 애플리케이션 워크로드의 기본 플랫폼이 되었고, 데이터베이스도 그 뒤를 따르고 있습니다. 가장 높은 위험을 감수하며 데이터베이스를 운영하는 사람들 사이에서 그 확신은 점점 더 커지고 있습니다.
세계에서 가장 까다로운 규제 환경 중 하나의 내부에서 회의론자에서 옹호자로 변해 간 Laurent Parodi의 여정은, CloudNativePG가 지금까지 확보한 가장 설득력 있는 증거입니다. 운영 모델이 글로벌 은행 규모에서, 그러한 컴플라이언스와 보안 제약 아래에서 버텨 낸다면, 쿠버네티스가 미션 크리티컬 PostgreSQL을 감당할 준비가 되었는가라는 질문에는 이미 답이 나온 셈입니다. 남은 것은 실행뿐입니다.
Laurent가 걸어간 길, 즉 평가하고, 역량을 키우고, 마이그레이션하고, 안정화하는 과정은 반복 가능합니다. 도구는 이미 존재하고, 패턴은 문서화되어 있으며, 오퍼레이터는 프로덕션에서 검증되었습니다. 늘 그렇듯 가장 어려운 부분은 첫걸음이었습니다. 이 발표는 그 첫걸음을 떼기 좋은 출발점입니다. 이 이야기에 대해 더 알고 싶다면 영상을 보거나, 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)
