모놀리식 이미지의 종말: PostgreSQL 18과 쿠버네티스의 동적 확장(Dynamic Extensions)
작성자: Ramalingam Srinivasan
작성일: 2026년 2월 23일
EDB는 데이터베이스 서버, 특히 AI 분야에서 가능한 기술적 한계를 끊임없이 넓혀가고 있습니다. 조직이 확장됨에 따라 거대한 워크로드를 처리할 뿐만 아니라 불변성(Immutability), 선언적 관리(Declarative Management), 분리된 아키텍처(Decoupled Architecture)라는 클라우드의 핵심 원칙을 수용하는 시스템이 필요합니다.
하지만 지난 수년 동안 쿠버네티스 환경에서 AI/벡터(Vector) 서비스와 같은 현대적이고 복잡한 워크로드를 도입하는 데 있어 하나의 고질적인 운영 장애물이 있었습니다. 바로 ‘강력한 확장성’과 ‘엄격한 불변성’ 사이의 충돌입니다.
오늘 포스팅에서는 곧 출시될 PostgreSQL 18과 EDB Postgres® AI (EDB PG AI)에서 이 문제를 해결한 근본적인 기술적 돌파구를 소개하고자 합니다. 데이터베이스 코어와 쿠버네티스 오케스트레이션 계층 모두를 아우르는 이중 혁신을 통해, 이제 확장 모듈(Extensions)을 동적이고 안전하며 진정한 클라우드 네이티브 방식으로 사용할 수 있는 새로운 시대가 열렸습니다.
기업 입장에서 이는 곧 비즈니스 민첩성으로 직결됩니다. 모놀리식(Monolithic) 데이터베이스 이미지를 다시 빌드하느라 중요한 AI 서비스 출시를 몇 주씩 미루는 대신, 이제 팀은 pgvector와 같은 고부가가치 기능을 단 몇 분 만에 배포할 수 있으며, 강력한 보안 태세를 유지하면서도 시장 출시 속도를 높일 수 있습니다.
운영의 장벽: 확장성과 불변성이 충돌할 때
PostgreSQL의 확장성은 PostGIS, TimescaleDB, pgvector와 같은 강력한 도구를 통합할 수 있게 해주는 가장 큰 장점 중 하나입니다. 그러나 쿠버네티스와 같은 클라우드 네이티브 환경에서 이러한 확장 모듈을 관리하는 운영상의 복잡성은 역사적으로 마찰의 원인이 되어 왔습니다.
EDB의 핵심 전략은 타협할 수 없는 베스트 프랙티스, 특히 불변의 인프라(Immutable Infrastructure) 위에 구축되었습니다. 이 근본적인 쿠버네티스 원칙은 컨테이너 이미지가 배포된 후에는 엄격하게 읽기 전용(Read-only) 상태를 유지할 것을 요구합니다.
기존의 확장 모듈 관리 방식은 다음과 같은 심각한 운영 저해 요소를 유발했습니다.
- 모놀리식 이미지: 서드파티 확장 모듈을 실행하는 유일한 방법은 PostgreSQL 오퍼랜드(Operand) 이미지에 이를 직접 포함하는 것이었습니다.
- 높은 오버헤드: 이는 이미지 크기를 비대하게 만들고 확장 모듈 선택의 유연성을 떨어뜨렸습니다.
- 보안 부채: 사용자는 불필요한 라이브러리가 포함된 커스텀 이미지를 직접 유지 관리해야 했으며, 이는 보안 공격 표면을 넓히고 CVE(취약점 탐지) 추적을 복잡하게 만들었습니다.
우리는 불변성 원칙을 엄격히 준수하면서도 동적인 확장 모듈 로딩을 달성할 방법이 필요했습니다. 기존의 모놀리식 방식은 기능 요청이 있을 때마다 위험하고 느린 풀스택 재빌드를 반복해야 했기에 지속 가능하지 않았습니다.
기술적 돌파구: PostgreSQL 18과 Kubernetes 1.33의 이중 혁신
전체 클라우드 네이티브 스택의 미래를 열어줄 주요 개선 사항들이 마침내 모습을 드러내고 있습니다.
1. PostgreSQL 코어에서의 확장성 분리: extension_control_path
확장 제어 경로(Extension Control Path)는 PostgreSQL 및 EDB PG AI 데이터베이스가 확장 모듈의 제어 파일(.control)을 찾는 디렉터리와 메커니즘입니다. 이 파일들은 확장 모듈의 설치 방법, 버전, 종속성을 정의하는 필수 메타데이터입니다.
기본적으로 제어 파일은 설치 경로의 SHAREDIR/extension 디렉터리에 위치해야 합니다. 하지만 CloudNativePG와 같은 불변 환경에서 이 표준 디렉터리는 읽기 전용이므로 런타임에 설치하는 것이 불가능합니다.
EDB의 전문가들은 이를 해결하기 위해 PostgreSQL 18에 적용될 중요한 패치를 개발하여 제안했습니다. 이 패치는 새로운 설정 옵션(GUC)인 extension_control_path를 도입합니다. 이 옵션을 통해 사용자는 확장 제어 파일을 위한 추가 디렉터리를 여러 개 지정할 수 있습니다.
단순해 보이는 이 변화는 혁신적입니다. PostgreSQL이 시스템 전체 경로가 아닌 여러 외부 디렉터리에서 제어 파일과 공유 라이브러리를 찾을 수 있게 함으로써, 확장 모듈을 코어 서버 이미지로부터 완전히 분리할 수 있게 되었습니다. 이는 운영 복잡성과 비용을 획기적으로 줄여줍니다.
2. 쿠버네티스 ImageVolume을 이용한 불변 마운트
데이터베이스가 새로운 경로를 탐색할 수 있게 되었다면, 이제 기본 컨테이너 이미지를 수정하지 않고도 확장 파일을 동적으로 주입할 방법이 필요합니다.
쿠버네티스 1.33에서 베타 단계에 진입할 예정인 ImageVolume 기능이 이를 해결합니다. ImageVolume을 사용하면 컨테이너 이미지를 실행 중인 포드(Pod) 내부에 읽기 전용 불변 볼륨으로 마운트할 수 있습니다.
이를 통해 PostgreSQL 확장 모듈을 독립적인 OCI(Open Container Initiative) 준수 컨테이너 이미지로 패키징하고, 이를 CloudNativePG 클러스터의 특정 디렉터리에 마운트할 수 있게 되었습니다.
심층 분석: 동적 확장 아키텍처의 구조
엄격한 불변성을 유지하면서 어떻게 런타임 유연성을 확보하는지 아래 아키텍처 흐름을 통해 살펴보겠습니다.
- 3.1 트리거 (The Trigger): 모든 것은 사용자의 의도에서 시작됩니다. 복잡한 스크립트를 작성하는 대신, 클러스터 매니페스트의
.spec.postgresql.extensions섹션에 필요한 확장 모듈을 정의하기만 하면 됩니다. 이 선언적 접근 방식은 요구 사항의 버전 관리와 재현성을 보장합니다. - 3.2 소스 (The Source): 확장 모듈은 더 이상 모놀리식 데이터베이스 이미지 내부에 갇혀 있지 않습니다. 대신 레지스트리에 저장된 독립적이고 최소화된 OCI 준수 이미지(예: 경량 pgvector 컨테이너)로 패키징됩니다. 이는 확장 모듈의 라이프사이클을 코어 데이터베이스와 완전히 분리합니다.
- 3.3 메커니즘 (The Mechanism): CloudNativePG 오퍼레이터는 쿠버네티스 ImageVolume 기능을 활용하여 이러한 아티팩트를 가져옵니다. 중요한 점은 기존 방식처럼 “설치”하는 것이 아니라, 확장 이미지를 포드에 읽기 전용 볼륨으로 직접 마운트한다는 것입니다. 이를 통해 코어 PostgreSQL 컨테이너는 수정되지 않은 불변 상태를 유지합니다.
- 3.4 보안 격리 (Secure Isolation): 컨테이너 내부에서 확장 파일은 시스템 전체 경로가 아닌 격리된 특정 디렉터리에 배치됩니다. 이는 시스템 경로를 깨끗하게 유지하고 서로 다른 확장 모듈이 코어 서버 파일과 충돌하지 않도록 보장합니다.
- 3.5 동적 구성 (Dynamic Configuration): 마지막으로 오퍼레이터는 파일 시스템과 데이터베이스 사이의 간극을 메웁니다. PostgreSQL 18의 새로운
extension_control_path와 기존dynamic_library_path설정을 동적으로 업데이트합니다. 이 구성을 통해 PostgreSQL은 마운트된 새 위치의 제어 파일을 마치 기본 시스템 파일인 것처럼 인식하고 로드합니다.
CloudNativePG: 선언적·동적 관리의 실현
CloudNativePG 오퍼레이터는 수동 작업을 선언적 코드로 변환하여 원활한 통합을 자동화합니다.
- OCI 아티팩트: 확장 모듈은 최소 크기의 OCI 이미지로 패키징됩니다 (예: pgvector 이미지는 단 1.6MB).
- 선언적 배포: 사용자는 클러스터 매니페스트에 필요한 확장 모듈을 정의하기만 하면 됩니다.
- 자동 구성: 오퍼레이터가 이미지를 읽기 전용 볼륨으로 마운트하고, 마운트된 경로를 포함하도록 PostgreSQL GUC 설정을 자동으로 업데이트합니다.
전략적 영향: 비즈니스 가치(ROI)
이러한 기술적 분리는 단순한 운영 최적화 그 이상입니다. 시장 출시 속도를 높이고 복잡성을 줄임으로써 측정 가능한 비즈니스 가치를 제공합니다.
- 시장 출시 속도 가속화 (민첩성): 확장 모듈의 동적 설치를 통해 배포 시간을 수주에서 수분으로 단축하여 AI/벡터 검색과 같은 고부가가치 기능의 출시를 앞당깁니다.
- 보안 및 규정 준수 회복탄력성: 코어 데이터베이스 이미지는 최소한의 상태로 안정적으로 유지됩니다. 확장 모듈 패치를 독립적으로 적용할 수 있어 공격 표면이 줄어들고 유지보수 시간이 최소화됩니다.
- 운영 효율성 증대: 수많은 커스텀 모놀리식 이미지를 관리할 필요가 없어지므로, 플랫폼 엔지니어는 가치가 낮은 유지보수 작업 대신 전략적 아키텍처 설계에 더 많은 시간을 할애할 수 있습니다.
새로운 시대를 위한 베스트 프랙티스
분리된 미래로 나아가면서 다음과 같은 핵심 확장 모듈 관리 원칙을 준수하는 것이 중요합니다.
- 보안 우선: 꼭 필요한 경우가 아니면 확장 모듈을
trusted로 표시하지 마십시오. 권한 상승을 방지하기 위해 설치 스크립트를 엄격하게 보호해야 합니다. - 스키마 유연성: 이동 가능한(relocatable) 확장 모듈의 경우, 스크립트에서 스키마 참조를 하드코딩하지 말고
@extschema@치환자를 사용하십시오. - OCI 준수: 쿠버네티스 환경의 경우, 호환성을 위해 표준 레이아웃(
share및lib디렉터리)을 갖춘 OCI 준수 확장 이미지를 게시하는 것을 권장합니다.
결론
PostgreSQL 18의 구성 가능한 확장 경로와 쿠버네티스 1.33의 ImageVolume 기능의 만남은 획기적인 이정표입니다. 이 혁신은 EDB PG AI 배포가 엔터프라이즈급 클라우드 네이티브 데이터베이스 관리의 표준임을 다시 한번 입증합니다.
확장 모듈을 위한 1급 아티팩트로 OCI 이미지를 수용함으로써, 우리는 쿠버네티스 환경에서 불변하면서도 유연한 EDB Postgres 경험을 제공하고 있습니다. 쿠버네티스 기반 Postgres 전략 최적화에 대해 궁금한 점이 있다면 언제든 EDB에 문의해 주시기 바랍니다.
메일: salesinquiry@enterprisedb.com
