관리형 Postgres: Lakebase가 실제로 대신 처리해 주는 작업

모든 Postgres 공급업체는 자사 서비스를 "관리형(managed)"이라고 부릅니다. 하지만 이 단어가 무엇을 의미하는지에 대해서는 의견이 분분합니다. 어떤 곳은 운영체제(OS) 패치만 제공하고 나머지는 데이터베이스 팀에 맡긴다는 의미로 사용합니다. 다른 곳은 팀원 중 누구도 설정 파일을 건드리지 않아도 데이터베이스가 자동으로 확장되고, 장애를 처리하며, 백업을 수행한다는 의미로 사용합니다.

관리형 Postgres는 공급업체가 기본 인프라를 운영하고 패치, 확장, 페일오버(failover), 백업과 같은 핵심 데이터베이스 작업을 처리하는 데이터베이스 서비스입니다. 덕분에 데이터베이스 팀은 유지 관리 작업에 시간을 덜 쓰고 그 위에서 실행되는 애플리케이션을 구축하는 데 더 많은 시간을 투자할 수 있습니다. 공급업체가 이러한 작업을 더 많이 책임질수록 고객이 부담해야 하는 데이터베이스 관리 업무는 줄어듭니다.

Postgres가 AI 애플리케이션으로 영역을 확장함에 따라 이러한 차이는 더욱 중요해집니다. 이제 데이터베이스는 기존의 트랜잭션 워크로드뿐만 아니라 애플리케이션 상태, 대화 기록, 임베딩(embeddings), 에이전트 데이터까지 보관할 수 있으므로, 운영 범위가 단순히 데이터베이스를 계속 실행하는 수준을 넘어섭니다.

Lakebase Postgres는 자동 확장, PostgreSQL 호환성, 복구, Databricks 통합을 결합하여 서버리스 Postgres에 이러한 관리형 접근 방식을 적용합니다. 핵심은 실제로 운영 업무를 얼마나 줄여줄 수 있는가 하는 점입니다.

TL;DR

• 관리형 Postgres는 패치, 확장, 페일오버, 백업과 같은 일상적인 데이터베이스 작업을 데이터베이스 팀의 업무 부담에서 덜어주어야 합니다.
• Lakebase는 자동 확장, scale-to-zero(사용량 제로 시 축소), 자동 스냅샷, 특정 시점 복구(point-in-time recovery), 브랜칭 기능과 함께 pgvector, PostGIS와 같은 인기 익스텐션 지원을 제공하는 서버리스 인프라에서 PostgreSQL을 실행합니다.
• Lakebase는 리전 내에서 대부분의 관리형 Postgres 작업을 처리합니다.

관리형 Postgres의 실제 의미

관리형 Postgres는 데이터베이스의 열쇠를 넘겨주는 것과 같다고 생각하면 됩니다. 팀이 얼마나 많은 권한을 넘겨줄지는 공급업체에 따라 다릅니다. 한쪽 극단에서는 데이터베이스 팀이 여전히 서버, 백업, 페일오버, 확장을 직접 처리해야 합니다. 다른 쪽 극단에서는 완전 관리형 서비스가 기본 인프라뿐만 아니라 팀을 위한 운영 작업까지 모두 알아서 처리해 줍니다. 대부분의 공급업체는 그 중간쯤에 위치하여 VM과 네트워크는 처리하지만 일부 데이터베이스 작업, 확장 결정, 페일오버 구성, 백업 정책 등은 팀의 몫으로 남겨둡니다.

공급업체가 OS 패치만 해주고 "관리형"이라고 부를 수도 있지만, 가용성과 복구 가능성을 유지하는 작업은 여전히 팀의 책임으로 남을 수 있습니다.

패치, 확장, 페일오버, 백업은 이러한 경계를 나누기에 좋은 기준입니다. 또한 관리형 서비스는 보안, 복구, 마이그레이션, AI 워크로드, Postgres 주변의 개발자 도구 중 팀이 여전히 직접 소유하고 관리해야 하는 영역이 얼마나 되는지를 결정합니다.

관리형 Postgres는 공급업체가 데이터베이스 인프라를 운영하고 패치, 확장, 페일오버, 백업과 같은 핵심 운영 작업을 처리하는 서비스입니다. 완전 관리형 서비스는 이러한 작업을 책임지므로, 팀은 Postgres를 실행하고 관리하는 대신 이를 활용한 애플리케이션 구축에 집중할 수 있습니다.

관리형 Postgres가 처리해야 하는 작업

서비스가 이 스펙트럼의 어디에 위치하는지 확인하는 가장 확실한 방법은 다음 네 가지 운영 작업을 팀의 부담에서 덜어주는지 여부입니다.

유지 관리 및 패치

관리형 공급업체는 데이터베이스 팀이 직접 일정을 잡거나 수동으로 실행할 필요 없이 OS 패치, PostgreSQL 마이너 버전 업데이트, vacuum 튜닝과 같은 일상적인 유지 관리를 적용해야 합니다. 이는 모든 작업을 직접 처리해야 하는 자체 호스팅(self-hosted) Postgres와는 정반대입니다. 익스텐션 및 애플리케이션 동작이 변경될 수 있으므로 메이저 버전 업그레이드는 여전히 계획이 필요하지만, 우수한 공급업체는 이러한 개입을 최소화하고 업그레이드 경로를 명확하게 제공합니다.

확장(Scaling)

플랫폼 엔지니어가 수동으로 인프라 크기를 조정할 필요 없이 워크로드에 맞춰 용량이 조정되어야 합니다. 즉, 더 많은 컴퓨팅이나 메모리를 위한 수직 확장(vertical scaling), 읽기 트래픽을 위한 읽기 복제본(read replicas), 그리고 이상적으로는 이러한 결정을 완전히 없애주는 서버리스 확장이 지원되어야 합니다. Lakebase의 오토스케일링이 프로덕션 환경에 적용된 한 가지 예이며, 이는 표준 Postgres보다 5배 빠른 Postgres 쓰기를 지원합니다. 진정한 시험대는 트래픽 급증 시점입니다. 데이터베이스 팀이 사용률을 모니터링하며 크기 조정을 기다리고 있다면, 확장은 여전히 그들의 업무입니다.

고가용성 및 페일오버

인프라 장애가 발생하더라도 대기 중인 엔지니어가 새벽 2시에 수동으로 복제본을 승격할 필요 없이 데이터베이스가 계속 가동되어야 합니다. 일부 공급업체는 자동으로 인계받는 대기 인스턴스를 통해 이를 처리하며, Lakebase와 같은 다른 공급업체는 지속적인 로컬 상태를 유지하지 않으므로 장애가 발생한 컴퓨팅을 즉시 교체합니다. 하지만 모든 공급업체가 동일한 속도로 페일오버를 수행하거나 동일한 수준의 데이터 손실을 방지하는 것은 아닙니다. 어떤 곳은 프로세스 중에 몇 초 분량의 쓰기 데이터를 잃기도 하고, 어떤 곳은 전혀 잃지 않습니다. 따라서 광고 문구를 그대로 믿기 전에 페일오버의 존재 여부와 페일오버가 시작될 때 진행 중인 쓰기 작업에 어떤 일이 일어나는지 등의 세부 사항을 확인해 볼 가치가 있습니다.

백업 및 복구

자동 백업과 지원 티켓을 제출하지 않고도 팀이 직접 실행할 수 있는 복구 프로세스는 기본입니다. 단순히 마지막 스냅샷이 아니라 특정 시점으로 복구하는 PITR(Point-in-Time Recovery)은 오후 한낮에 잘못된 마이그레이션으로 인해 데이터가 손상되었을 때 매우 중요합니다. 전체 리전이 다운되는 것은 더 큰 문제로, 다운타임 시간을 측정하는 복구 목표 시간(RTO)과 감당할 수 있는 데이터 손실량을 측정하는 복구 시점 목표(RPO)로 평가됩니다. 이 두 가지에 대해 정의된 수치가 없는 공급업체는 재해 복구 계획이 있는 것이 아니라 단지 추측만 하고 있는 것입니다.

관리형 Postgres가 데이터를 보호하는 방법

관리형 데이터베이스는 저장(at rest) 및 전송(in transit) 중인 데이터를 암호화하고, 액세스 권한을 제어하며, 데이터 팀에 데이터베이스 활동에 대한 가시성을 제공해야 합니다. 이는 다음을 의미합니다.

• 암호화: 데이터는 디스크에 저장되어 있을 때나 애플리케이션과 데이터베이스 간에 이동할 때 모두 보호되어야 합니다. 확인해 볼 세부 사항은 키를 누가 제어하는가입니다. 일부 공급업체는 암호화를 전적으로 자체 관리하므로, 규정 준수 요구 사항이나 내부 정책에 따라 조직이 키를 보유해야 하는 순간 문제가 발생할 수 있습니다. 고객 관리형 키(Customer-managed keys)를 사용하면 기본 데이터베이스 작업은 공급업체에 맡기면서도 이러한 제어권을 유지할 수 있습니다.
• 액세스 제어: 역할 기반 액세스 제어(RBAC)는 서로 다른 사용자 및 서비스에 서로 다른 권한을 부여하는 기본 작업을 처리하지만, 프로덕션 시스템에는 더 많은 기능이 필요한 경우가 많으며 결제 데이터를 다루는 산업은 PCI DSS와 같은 표준까지 충족해야 합니다. Unity Catalog를 통한 속성 기반 액세스 제어(ABAC)는 역할에만 의존하지 않고 사용자, 리소스 또는 요청의 속성을 고려하여 이러한 정책을 더욱 확장합니다.
• 감사 로깅: 누가, 언제, 무엇을 했는지에 대한 가시성이 없으면 사고 조사가 어려워지고 규정 준수를 증명하기도 힘들어집니다. 감사 로깅은 데이터베이스 위에 별도의 파이프라인으로 구성, 운영 및 유지 관리해야 하는 것이 아니라, 기본적으로 데이터 팀에 데이터베이스 및 관리 활동에 대한 가시성을 제공해야 합니다.

기존 PostgreSQL 데이터베이스를 마이그레이션할 때 고려해야 할 사항

마이그레이션은 새 데이터베이스가 애플리케이션이 의존하는 익스텐션, 구성 또는 PostgreSQL 기능을 지원하지 않는 상황이 발생하기 전까지는 간단해 보일 수 있습니다. 무엇이든 이동하기 전에 애플리케이션이 무엇에 의존하는지 확인하세요. 기존 PostgreSQL 데이터베이스를 마이그레이션할 때 고려해야 할 주요 사항은 다음과 같습니다.

• 호환성: 현재 설정이 새 플랫폼에서 동일하게 작동하는지 확인하세요. 여기에는 PostgreSQL 버전 지원, 사용자 지정 구성, 인프라가 변경되면 유지되지 않을 수 있는 애플리케이션 수준의 가정이 포함됩니다. 표준 Postgres 와이어 프로토콜 호환성은 기존 연결 문자열, 객체 관계형 매퍼(ORM), 드라이버 및 도구가 코드 변경 없이 작동할 가능성이 높음을 의미합니다.
• 익스텐션(Extensions): 마이그레이션 단계는 데이터베이스가 의존하는 모든 익스텐션이 제대로 이전되었는지 확인하는 시점입니다. 따라서 최종 결정을 내리기 전에 실제로 사용 중인 익스텐션과 공급업체의 지원 목록을 대조해 보세요. AI 또는 임베딩 워크로드의 경우 pgvector를 확인해야 하고, 지리 공간 데이터의 경우 PostGIS가 중요하며, 애플리케이션이 의존하는 다른 모든 익스텐션도 대중적인 익스텐션이 당연히 있을 것이라 가정하지 말고 개별적으로 확인하는 것이 좋습니다.
• 마이그레이션 방법: 새 플랫폼에서 내보내고 복구하는 덤프 기반 마이그레이션은 간단하며 소규모 데이터베이스나 계획된 유지 관리 기간에 적합합니다. 논리적 복제(Logical replication)는 소스를 활성 상태로 유지하면서 변경 사항을 대상에 스트리밍하므로, 두 데이터베이스가 동기화되면 훨씬 짧은 중단 시간으로 전환할 수 있습니다. 올바른 선택은 데이터베이스 크기, 쓰기 볼륨, 비즈니스가 감당할 수 있는 다운타임 시간에 따라 달라집니다.
• 검증 및 전환(Cutover): 데이터가 이동했다고 해서 마이그레이션이 완료된 것은 아닙니다. 단순히 행(row) 수가 일치하는 것만으로는 충분하지 않으므로, 새 데이터베이스에서 실제 쿼리 워크로드를 실행하고 소스 데이터베이스와 결과 및 성능을 비교해야 합니다. 쿼리 계획, 응답 시간, 애플리케이션 동작이 모두 안정적으로 유지되어야 합니다. 문제가 발생했을 때 팀이 장애 도중에 대처 방법을 찾느라 우왕좌왕하지 않고 트래픽을 다시 되돌릴 수 있도록, 롤백 경로를 염두에 두고 전환 계획을 세우세요.

Postgres는 AI 애플리케이션에 적합할까요?

애플리케이션에 동일한 시스템 내의 트랜잭션 상태와 벡터 검색이 모두 필요한 경우, Postgres는 AI 애플리케이션에 매우 적합할 수 있습니다. 이는 다음 네 가지 요소로 요약됩니다. 이를 가능하게 하는 확장 기능인 pgvector, 검색을 위한 벡터 검색, 요청 간의 상태를 유지하기 위한 대규모 언어 모델(LLM) 메모리, 그리고 이 두 가지가 동시에 필요한 에이전트 워크로드입니다.

pgvector

pgvector는 Postgres 내부에 벡터 데이터 유형과 유사도 검색 인덱싱을 직접 추가하므로, 임베딩이 별도의 시스템이 아닌 나머지 애플리케이션 데이터와 함께 저장됩니다. 별도의 벡터 데이터베이스를 사용하면 임베딩과 운영 데이터를 동기화하는 작업 자체가 또 다른 엔지니어링 문제가 되지만, pgvector는 전용 벡터 저장소가 필요하지 않은 워크로드에서 이러한 문제를 해결해 줍니다.

벡터 검색 및 시맨틱 검색

pgvector를 사용하면 데이터 세트가 커짐에 따라 임베딩을 저장하고 근사 최근접 이웃(ANN) 인덱스를 사용하여 유사한 벡터를 효율적으로 찾을 수 있습니다. 이를 통해 Postgres 내부에서 시맨틱 검색, 검색 증강 생성(RAG), 의미 기반 매칭이 가능해집니다. 적절한 인덱싱 전략은 여전히 데이터 세트 크기와 쿼리 패턴에 따라 달라지므로, pgvector를 사용하더라도 특정 워크로드에 대한 성능 평가는 여전히 필요합니다.

LLM 메모리

LLM 애플리케이션은 대화 기록, 사용자 기본 설정, 검색된 문서, 도구 결과 등 요청 간의 상태를 유지할 공간이 필요합니다. Postgres는 이 상태를 일반적인 관계형 데이터로 저장할 수 있으며, pgvector는 동일한 데이터베이스에서 임베딩을 처리합니다. 매우 큰 규모에서 전문적인 벡터 검색이 필요한 워크로드의 경우 전용 벡터 데이터베이스가 여전히 적합할 수 있지만, 많은 AI 애플리케이션은 운영 상태와 검색을 함께 유지할 수 있습니다.

에이전트 워크로드

에이전트는 실행되면서 지속적으로 상태를 읽고 업데이트합니다. 대화를 추적하고, 중간 결과를 저장하며, 도구 호출을 기록하므로 데이터베이스는 단순히 컨텍스트를 검색하는 곳이 아니라 에이전트 실행 레이어의 일부가 됩니다. AI 에이전트 워크로드용으로 구축된 데이터베이스는 끊임없이 변하는 트랜잭션 상태와 에이전트가 관련 컨텍스트를 찾는 데 사용하는 검색을 모두 하나의 시스템에서 지원해야 합니다.

애플리케이션 개발을 위한 Postgres

프로덕션 워크로드를 실행하는 것 외에도, Postgres는 팀이 실제로 빌드하는 방식을 지원해야 합니다. 즉, 규모를 확장할 때 연결(connection)이 병목 현상이 되지 않아야 하며, 스키마 변경 사항을 테스트할 때 프로덕션 데이터가 위험에 처하지 않아야 합니다.

연결 관리

Postgres는 한 번에 유지할 수 있는 연결 수에 제한이 있으며, 수평적으로 확장되는 애플리케이션 인스턴스는 컴퓨팅이나 스토리지가 병목이 되기 전에 이 제한에 도달할 수 있습니다. 연결 풀링(Connection pooling)은 각 요청마다 새 연결을 여는 대신 기존에 설정된 데이터베이스 연결을 여러 요청에서 재사용합니다. 관리형 서비스에서 중요한 것은 풀링 기능이 내장되어 있는지, 아니면 팀에서 별도로 운영해야 하는지 여부입니다.

데이터베이스 브랜칭

프로덕션 데이터를 대상으로 스키마 변경 사항을 테스트하는 것은 프로덕션 환경을 위험에 빠뜨리거나, 시간이 지남에 따라 동기화가 어긋나는 스테이징 데이터베이스를 유지 관리해야 함을 의미합니다. 데이터베이스 브랜칭은 기존 데이터베이스 상태 또는 특정 시점 스냅샷에서 격리된 환경을 생성하므로, 개발자는 실제와 유사한 데이터를 대상으로 마이그레이션을 테스트하고, 진화적 데이터베이스 개발과 같이 작업하며, 더 이상 필요하지 않은 브랜치는 삭제할 수 있습니다.

관리형 Postgres 기반 Lakebase를 선택해야 하는 이유

관리형 Postgres가 처리해야 하는 핵심 작업과 비교해 보면 Lakebase의 접근 방식이 더 명확해집니다.

• 서버리스(Serverless): Lakebase는 수요에 따라 자동으로 확장되고 유휴 상태일 때는 0까지 축소되는 서버리스 컴퓨팅에서 PostgreSQL을 실행하므로, 인스턴스 크기를 미리 산정하거나 사용하지 않는 용량에 대해 비용을 지불할 필요가 없습니다. Databricks는 자체 테스트에서 Lakebase를 사용할 때 Postgres 쓰기 처리량이 최대 5배 더 높다고 보고하고 있으나, 결과는 워크로드 및 구성에 따라 다를 수 있습니다.
• PostgreSQL 호환성: Lakebase는 표준 PostgreSQL 연결을 사용하므로, 기존 드라이버, ORM 및 psql, pgAdmin, DBeaver와 같은 도구가 다른 Postgres 인스턴스에 연결할 때와 동일한 방식으로 연결되며, 애플리케이션과 데이터베이스 사이에 독점 프로토콜이 존재하지 않습니다.
• 신뢰성: Lakebase는 별도의 가용 영역에서 보조 컴퓨팅을 실행하고 기본 컴퓨팅에 장애가 발생하면 자동으로 이를 승격하여 연결 엔드포인트를 그대로 유지합니다. 데이터베이스 팀은 장애 발생 시 복제본을 수동으로 승격하거나 애플리케이션을 재구성할 필요가 없습니다.
• 요금제: 영구적으로 프로비저닝된 인스턴스 대신 워크로드에 따라 컴퓨팅 규모가 조정되며, 데이터베이스가 일시 중단되면 요금 청구가 중단됩니다. 스토리지는 별도로 청구됩니다.
• 레이크하우스 통합: Lakebase는 고립된 Postgres 서비스로 작동하는 대신 Databricks 플랫폼의 나머지 부분과 연결됩니다. 동기화된 테이블을 사용하면 맞춤형 동기화 파이프라인 없이도 Unity Catalog 데이터를 Postgres 애플리케이션에서 사용할 수 있으며, 현재 퍼블릭 프리뷰(Public Preview) 상태인 Change Data Feed는 레이크하우스의 후속 처리를 위해 데이터베이스 변경 사항을 노출합니다.

팀이 더 이상 신경 쓰지 않아도 되는 작업

아래 표는 Lakebase가 처리하는 데이터베이스 작업과 데이터베이스 팀이 여전히 담당해야 하는 작업을 보여줍니다.

위의 표에 따라 패치 작업, 확장, 장애 조치, 백업은 모두 자동으로 실행됩니다. 재해 복구는 예외입니다. 아직 프라이빗 프리뷰(Private Preview) 단계이며 AWS에서만 지원되고, 수동 장애 조치 및 고객 관리형 복구 절차가 필요합니다. 여러 리전에 걸친 작업에 Lakebase를 도입하기 전에 이 세부 사항을 꼭 확인해야 합니다. Databricks Lakebase에 대해 자세히 알아보세요.

마치며

"관리형"이라는 단어는 제공업체에 따라 OS 패치만 해주고 끝나는 것부터 프로덕션 데이터베이스 운영의 모든 부담(확장, 장애 조치, 백업, 보안, 마이그레이션, AI 워크로드 및 이와 관련된 모든 개발자 경험)을 책임지는 것까지 그 의미가 다릅니다.

Lakebase는 이러한 기준을 대부분 충족합니다. 패치 작업, 확장, 장애 조치는 팀의 개입 없이 실행되며, 특정 시점 복구 기능이 내장되어 있고, 보안, 확장 기능, 연결 풀링, 브랜칭 기능이 모두 서비스와 함께 제공됩니다. 리전 간 재해 복구는 유일한 예외로, 여전히 프라이빗 프리뷰(Private Preview) 단계이며 수동 장애 조치가 필요하므로 Lakebase가 리전 내에서 제공하는 것과 동일한 자동 보호 기능은 제공되지 않습니다.

관리형 Postgres를 검토 중인 팀에게 중요한 질문은 실제로 운영 업무를 얼마나 덜어낼 수 있는가 하는 점입니다. Lakebase는 리전 내에서 대부분의 작업을 처리하지만, 리전 간 재해 복구는 여전히 팀이 책임을 지고 관리해야 하는 영역으로 남아 있습니다.

자주 묻는 질문(FAQ)

관리형 Postgres와 자체 호스팅 Postgres의 차이점은 무엇인가요?

자체 호스팅 Postgres는 패치 적용, 확장, 장애 조치, 백업 정책, 재해 복구 등 모든 운영 작업을 데이터베이스 팀이 직접 처리하도록 합니다. 반면 관리형 Postgres는 이러한 작업의 일부 또는 전부를 제공업체에 위임하지만, 위임되는 범위는 서비스마다 크게 다릅니다. 부분 관리형 서비스는 인프라만 관리하고 나머지는 고객이 직접 처리하도록 합니다. 일부 완전 관리형 서비스에는 보안 도구, 마이그레이션 지원, 데이터베이스 브랜칭과 같은 개발자 워크플로까지 포함되어 있습니다.

서버리스 Postgres란 무엇인가요?

서버리스 Postgres는 수요에 따라 컴퓨팅 자원이 자동으로 확장되므로, 고정된 인스턴스 크기를 미리 프로비저닝할 필요가 없는 관리형 데이터베이스 모델입니다. 일부 제공업체는 데이터베이스가 사용되지 않을 때 컴퓨팅 리소스를 0으로 축소하는 반면, 다른 제공업체는 최소한의 기본 용량을 유지합니다. 요금은 일반적으로 영구적으로 할당된 인스턴스가 아닌, 실제 사용된 컴퓨팅 자원을 기준으로 책정됩니다.

Postgres에서 데이터베이스 브랜칭은 어떻게 작동하나요?

데이터베이스 브랜칭은 기본 스토리지를 복제하지 않고 데이터베이스의 격리된 기록 중 복사(copy-on-write) 브랜치를 생성합니다. 각 브랜치는 운영 환경에 영향을 주지 않으면서 독립적인 컴퓨팅 및 데이터 변경 사항을 가질 수 있습니다. 개발 팀은 이를 활용해 실제 데이터로 스키마 마이그레이션을 테스트하거나, 풀 리퀘스트별로 브랜치를 생성하거나, 특정 시점으로 브랜치를 복구한 뒤 작업이 끝나면 삭제할 수 있습니다.

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)