본문으로 건너뛰기

4.1 개발과 운영의 선택

PR마다 데이터베이스가 필요한 팀과 장애 직전 상태를 복원하려는 DBA는 요구가 다릅니다. 같은 제품 목록을 제시하면 선택 조건이 흐려집니다. 개발팀은 코드와 접속 정보가 함께 준비되는 시점을 묻습니다. DBA는 어느 데이터 시점까지 복구하며 운영에 어떤 영향을 주는지 묻습니다. 먼저 작업의 완료 조건을 문장으로 작성합니다. 그 조건을 충족하는 생성 모드부터 비교합니다.

이 장의 기준일은 2026-09-30입니다. 아래 두 의사결정 트리는 조건부 후보 선정안입니다. 기존 플랫폼, 데이터 요구, 복구 조건을 기준으로 삼습니다. 제품의 종합 순위가 아니며, 운영 안정성의 우열도 평가를 보류합니다. 사실 대장에는 동일 장애 조건의 HA 시험과 RPO/RTO 비교 결과가 없습니다. 기능이 있다는 사실과 우리 환경에서 목표를 달성한다는 판단을 분리합니다.

평가 항목과 합격 조건​

기능 시험에 필요한 데이터와 성능 리허설에 필요한 데이터를 먼저 구분합니다. 작은 seed로 오류 분기를 재현하는 작업이라면 운영 데이터가 꼭 필요하지 않습니다. 반대로 운영 규모의 쿼리나 마이그레이션을 검증하려면 데이터 크기와 분포가 필요합니다. 기준 시점도 평가 입력으로 지정합니다. GitLab은 DBLab을 운영 규모 데이터의 쿼리와 마이그레이션 검증에 사용합니다. 신뢰도는 높음이며, 고객 자체 개발 문서를 근거로 합니다. 이 사례에서 얻는 선택 근거는 데이터 요구와 검증 용도입니다.

다음 표는 평가 기록의 항목을 나란히 놓은 양식입니다. 점수나 제품별 등급을 부여하지 않습니다. 각 조직은 파일럿 전에 허용 지연과 중단 조건을 정합니다. 같은 입력으로 얻은 결과를 기록합니다. 필수 조건의 충족 여부는 다른 기능의 점수와 별도로 판단하는 방식을 제안합니다.

평가 항목개발 워크플로우 기록운영 안정성 기록
기존 플랫폼Git 저장소, CI, 배포 대상엔진 버전, 운영 서비스, 지원 계약
데이터 범위schema, seed, 데이터 포함 모드기준 시점, 수집 지연, 복구 범위
준비 시간요청, 접속 정보 전달, 첫 SQL 시각복구 시작, SQL 준비, 서비스 확인 시각
변경 반영마이그레이션 파일, 데이터 patch변경 추종 상태, 전환 조건, 복귀 절차
권한요청자, branch 자격증명관리자, 원본 접근, 외부 연결
자원동시 PR 수, 실행 시간, 저장량원본 부하, 공유 자원, 장애 범위
수명PR 종료, 만료, 삭제 완료 시각보존 기간, 복구 증적, 삭제 승인

준비 시간은 생성 API 응답 이후에도 계속 측정합니다. 접속 정보를 받은 뒤 첫 SQL을 실행합니다. 캐시가 준비되기 전후의 쿼리를 따로 기록하도록 제안합니다. DBLab 4.2 발표는 파일 소유권 처리 같은 작업도 clone 준비에 영향을 준다고 설명합니다. 따라서 저장 참조 생성에 관한 설명만으로 애플리케이션의 대기 시간을 계산하지 않습니다. 구체적인 측정 항목은 2.3 준비 시간과 자원 비용에 연결합니다.

개발 워크플로우의 후보 선정​

개발 환경에서는 현재 플랫폼이 제공하는 절차를 먼저 검토합니다. 사용 중인 인증과 배포 구성을 새 제품으로 옮기는 작업도 도입 범위에 포함해야 하기 때문입니다. 다만 기존 플랫폼을 유지하더라도 데이터 요구는 확인합니다. 생성 모드가 요구를 충족하지 못하면 데이터 포함 시험 경로로 다시 분기합니다.

Supabase의 기본 branch는 schema, Edge Functions, 설정을 준비합니다. 운영 데이터와 Storage object는 포함하지 않습니다. Dashboard의 Include data는 PITR add-on을 요구합니다. 디스크와 compute 조건에 따라 비용도 달라집니다. 따라서 Supabase 사용 여부만으로는 데이터 포함 시험의 준비 상태를 판단하기 어렵습니다. 기본 모드에서 seed로 충분한지 먼저 확인합니다. 실제 데이터가 필요하면 선택 옵션의 범위와 비용을 별도로 검증합니다.

PlanetScale Vitess에서는 branch와 deploy request를 검토합니다. 검토 기준은 schema 변경 배포 흐름입니다. 데이터 3-way 머지와는 범위가 다릅니다. PlanetScale Postgres를 사용하는 팀은 별도의 경로를 검토합니다. Postgres의 일반 새 branch는 부모 schema와 data가 없는 빈 DB입니다. backup 복원 경로에는 schema와 data가 포함됩니다. 생성 후 부모와 지속 복제되지 않는다는 조건도 시험의 기준 시점에 반영합니다.

관리형 PostgreSQL의 데이터 포함 시험 후보로는 Neon과 Xata를 비교합니다. Neon의 데이터 포함 branch에는 database, role, extension이 포함됩니다. schema와 data도 포함됩니다. Xata는 PostgreSQL 아래 스토리지 계층의 branching을 설명합니다. 여기서 후보를 좁힌 뒤 지원 확장, 접속 권한, 데이터 반출 조건을 확인합니다. Xata Cloud와 OSS의 구성은 다릅니다. 따라서 관리형 서비스의 설명을 자체 설치 결과로 대체하지 않습니다.

데이터를 기존 환경 내부에 유지해야 한다면 DBLab의 수집과 clone 제공 경로를 검토합니다. 원본의 PostgreSQL major version에 맞는 이미지를 준비해야 합니다. 필요한 extension 바이너리도 준비해야 합니다. 기존 데이터베이스를 유지하더라도 별도 환경을 운영할 책임은 생깁니다. 따라서 생성 주체가 DBA인지 CI인지와 정리 담당자를 함께 정합니다. 자체 운영 후보의 분기는 4.2 온프레미스의 선택에서 이어집니다.

개발 파일럿은 PR 종료 뒤 정리까지 확인하는 것으로 완료 조건을 정하도록 제안합니다. 코드 버전과 branch 식별자를 연결합니다. 애플리케이션에 전달된 접속 정보가 해당 branch를 가리키는지 검사합니다. 생성 중 CI가 취소되거나 삭제 요청이 실패하는 상황도 넣습니다. TTL과 팀별 동시 생성 quota는 이 장의 운영 정책 제안입니다. 앞서 언급한 제품이나 고객의 기본 정책으로 단정하지 않습니다.

운영 안정성과 복구 조건​

운영팀은 현재 플랫폼에서 요구를 충족하는 경로부터 시험합니다. 복구나 성능 리허설을 추가하는 작업의 범위를 구분하기 위해서입니다. 운영 엔진을 마이그레이션하는 작업의 범위도 따로 구분합니다. 현재 플랫폼의 경로가 실패해도 곧바로 다른 제품의 안정성이 높다고 결론 내리지 않습니다. 먼저 실패 원인이 데이터 최신성인지, 자원 경합인지, 복구 시간인지 분류합니다. 이를 다음 후보의 시험 조건에 반영합니다.

Aurora clone은 원본과 변경되지 않은 page를 공유합니다. 별도 volume의 논리적 상태를 제공합니다. DB instance 준비는 저장 공유와 별도 작업입니다. CoW clone에는 개수와 리전 등의 제약이 있습니다. 원본이나 clone의 쓰기 모두 추가 공간을 요구할 가능성이 있습니다. 따라서 운영 리허설에서는 clone의 변경량을 기록합니다. 원본이 갱신되는 동안의 저장량도 기록합니다. 이 설명만으로 모든 공유 자원의 성능 격리를 보장하지 않습니다.

Tiger Cloud는 대상 서비스의 fork 모드를 먼저 확인합니다. 사실 대장의 현행 문서는 Free의 CoW 경로를 설명합니다. Paid의 backup restore 및 WAL replay 경로와 구분합니다. 두 경로는 준비 과정과 과금 범위가 다릅니다. 생성 요청에 같은 fork라는 이름이 붙어도 최근 snapshot인지 지정 시점인지 확인합니다. 이에 따라 최신성과 WAL 재생량을 따로 확인합니다. 공급자 안내 시간은 해당 조건의 설명입니다. 우리 복구 목표의 합격 결과로 옮기지 않습니다.

일반 PostgreSQL에서 DBLab을 검증용으로 채택해도 운영 복구 절차를 별도로 시험합니다. PostgreSQL PITR는 backup과 WAL을 이용한 복구 경로입니다. DBLab의 보존 snapshot이나 branch 포인터와는 구분합니다. 보존 기간은 선택 가능한 과거 범위를 뜻합니다. RPO는 허용 가능한 데이터 손실의 시간 목표입니다. RTO는 복구 시간 목표입니다. 며칠의 이력을 보유한다는 답만으로 두 목표의 달성 여부를 판정하지 않습니다.

복구 파일럿에서는 목표 시점의 사본이 열리는 데 걸린 시간을 기록합니다. 애플리케이션 검증까지 끝난 시간은 구분해서 기록하도록 제안합니다. 데이터 조회 성공 외에 필요한 객체와 설정이 준비됐는지도 확인합니다. 공유 파일이나 origin snapshot을 참조하는 사본은 장애 범위를 먼저 정합니다. 그 뒤 독립 백업으로 인정할지 판단합니다. 계정이나 스토리지의 장애를 포함하는 시험이 없다면 해당 범위의 복구 능력은 미확인으로 남깁니다.

도입 범위와 재평가 조건​

최초 파일럿은 작업 하나로 제한하는 방식을 제안합니다. 예를 들어 마이그레이션 리허설을 선정했다면 대표 변경 파일과 기준 데이터 시점을 고정합니다. 후보마다 실행 조건을 기록합니다. SQL 준비 시간, 원본 영향, 변경 저장량, 정리 완료 여부를 비교합니다. 서로 다른 데이터와 실행 조건으로 얻은 성공 사례를 한 점수표에 합산하지 않습니다. 리허설 결과를 운영에 반영할 때는 검토한 마이그레이션을 다시 실행할지 사전에 정합니다. 데이터 patch를 적용할지도 사전에 정합니다.

개발자가 기다리는 시간을 줄였더라도 DBA의 부담을 확인합니다. 원본 수집이나 장애 대응 부담이 허용 범위를 넘으면 적용 대상을 좁힙니다. 반대로 복구 시험에 합격했더라도 개발자 전체 배포에는 별도의 조건이 필요합니다. PR별 접속 정보 전달과 자동 정리를 준비한 뒤 배포합니다. 지원 계약에서는 담당 주체와 대응 범위를 문서로 확인합니다. 확인되지 않은 지원 품질은 제품 등급에 반영하지 않습니다. 이러한 도입 범위 조정은 이 장의 평가 절차 제안입니다.

운영 기록에는 채택 이유와 함께 재평가 조건을 남깁니다. 데이터 규모, 동시 작업 수, 필요한 확장, 보존 기간이 바뀌면 기존 시험의 적용 범위를 다시 확인합니다. 이후 판단에는 의사결정 트리의 말단에 도달했다는 사실보다 검증 조건과 대상이 필요합니다. 따라서 선택 문서에 버전과 생성 모드, 시험 결과, 담당자를 함께 기록합니다.

참고​