2.3 준비 시간과 자원 비용
분기 API가 빠르게 응답해도 테스트 작업은 늦게 시작할 수 있습니다. 분기 대상 저장 상태가 준비된 뒤에도 compute 기동, 복구, 접속 준비가 남기 때문입니다. 테스트 결과를 기다리는 개발자와 공유 스토리지 사용량을 관리하는 DBA는 완료 시각을 다르게 봅니다. 준비 시간을 비교하려면 각자가 기다리는 사건을 같은 측정 기록에 표시해야 합니다.
비용도 같은 방식으로 나눕니다. 초기 데이터 공유, 사용 중인 compute, 부모와 자식의 변경은 각각 다른 비용 항목에 연결됩니다. 보존 이력과 branch 수명도 별도 비용 항목에 연결됩니다. 이 장은 2026-09-30에 확인한 문서의 범위를 기준으로 측정 설계를 제안합니다. 공통 조건의 자체 성능 측정과 실제 청구 검증은 미확인입니다. 아래 공급사 안내는 측정 결과를 대신하지 않습니다.
준비 시간의 네 경계
측정 시작은 클라이언트가 생성 요청을 보낸 시각 t0로 정합니다. 이후 분기 완료, SQL 준비, 첫 업무 쿼리 완료, 워밍업 완료를 서로 다른 사건으로 기록합니다. 이 네 경계는 비교 실험을 위해 정의합니다. 특정 공급사의 API 상태를 그대로 옮긴 분류는 아닙니다. API가 요청 접수와 작업 완료를 구분한다면 작업 완료를 기준으로 분기 완료를 기록합니다.
| 단계 | 종료 사건 | 기록할 시간 |
|---|---|---|
| 분기 완료 | 생성 작업의 완료 상태 확인 | t1 - t0 |
| SQL 준비 | 인증 후 사전에 정한 확인 SQL 성공 | t2 - t0 |
| 첫 쿼리 | 첫 대표 업무 쿼리 완료 | t3 - t2 |
| 워밍업 | 정한 반복 부하의 안정 기준 충족 | t4 - t2 |
SQL 준비 검사에는 실제 사용자가 사용할 인증과 연결 경로를 적용합니다. 서버 상태 표시만 보는 검사와 애플리케이션 계정으로 SQL을 실행하는 검사는 구분합니다. 확인 SQL은 작게 유지합니다. 첫 업무 쿼리의 대상 데이터를 미리 읽지 않도록 설계합니다. 확인 단계에서 워밍업까지 수행하면 첫 쿼리 측정의 의미가 달라집니다.
워밍업 완료는 반복 횟수만으로 임의 판정하지 않습니다. 시험 전에 사용할 쿼리 집합, 동시 연결 수, 지연 또는 처리량의 안정 기준을 정하도록 제안합니다. 첫 결과를 받은 시각과 안정 기준을 만족한 시각을 함께 기록합니다. 그러면 접속은 빠르지만 대표 부하의 준비는 늦은 상황이 구분됩니다. 사용자가 허용할 대기 시간을 어느 단계에 적용하는지도 명시합니다.
분기 작업과 compute 준비가 내부에서 겹쳐 실행되는 제품도 있습니다. 이런 제품도 측정 기록에는 관찰 가능한 경계를 남깁니다. 네 시간을 모두 더해 총 준비 시간으로 계산하지 않습니다. 위 표의 SQL 준비 시간은 요청 이후의 누적 시간입니다. 첫 쿼리 시간은 SQL 준비 이후의 구간 시간입니다. 단계별 구간과 최종 누적 시간을 구분하면 같은 기동 지연을 두 번 계산하는 오류를 피합니다.
공급사 수치와 비교 조건
Tiger의 fork 문서는 Free 경로를 CoW로 구분합니다. Paid 경로는 backup restore와 WAL replay로 구분합니다. 공급사 문서 기준 안내 시간은 각각 약 3090초와 통상 520분 이상입니다. 이는 해당 생성 모드의 안내 범위입니다. SQL 준비, 첫 업무 쿼리, 워밍업을 동일 조건에서 측정한 비교 결과는 아닙니다. 각 fork의 구현은 요금제 이름 외에 생성 모드도 확인해야 합니다.
DBLab 4.2의 설명에는 clone 준비 중 파일 소유권 처리도 포함됩니다. 하부 snapshot 작업의 비용이 작더라도 전체 준비 시간과 데이터 구성의 관계는 따로 확인해야 합니다. 이 때문에 파일 수와 WAL 재생, compute 조건을 시험 항목으로 둡니다. DBLab의 upgrade 경로는 pg_upgrade --link를 사용합니다. 따라서 업그레이드를 항상 전체 데이터 재작성과 같은 비용으로 계산하지 않습니다.
비교 실험에서는 데이터 크기 외에도 객체 수, 기준 시점, 생성 모드를 기록하도록 제안합니다. compute 크기와 동시 요청 수도 기록합니다. 최신 시점에서 만든 branch와 최근 snapshot에서 만든 branch를 같은 조건으로 놓을 수는 없습니다. 그렇게 비교하면 최신성을 얻기 위한 준비 작업을 빠뜨립니다. 목표 데이터를 먼저 맞추고, 그 조건에서 각 단계의 시간을 비교해야 합니다.
Cold와 warm이라는 이름에도 관찰 범위를 붙입니다. 새 compute에서 실행한 첫 쿼리인지 시험 기록으로 구분합니다. 한 차례 동일 쿼리를 실행한 뒤의 쿼리인지도 구분합니다. 전체 스토리지가 cold였다고 표현하려면 모든 저장 계층의 캐시가 비어 있었는지 확인해야 합니다. 실행 순서와 재사용한 자원이 드러나도록 조건을 적으면 결과의 재현 범위를 설명하는 데 도움이 됩니다.
평균 시간과 함께 반복별 실패 및 재시도 횟수를 보존하는 방법도 제안합니다. 성공한 요청만 모으면 느린 준비 때문에 중단한 요청이 비교에서 사라집니다. 생성 요청 시작부터 실제 시험 시작까지 사용자가 경험한 대기를 계산합니다. 그중 서비스 응답 지연과 클라이언트의 재시도 간격을 구분합니다. 이 측정 설계는 공급사 간 순위를 미리 정하지 않습니다.
Compute 수명과 Scale-to-zero
Neon의 비용 설명은 compute 사용량과 storage 사용량을 별도 항목으로 다룹니다. 포함량을 초과한 branch 수명과 restore history도 별도 항목으로 다룹니다. compute는 CU-hours로, 추가 branch는 branch-hours로 설명합니다. 이 구분에서 compute가 정지한 시간과 branch가 존재한 시간은 다릅니다. Scale-to-zero가 적용되더라도 보존 중인 데이터를 확인해야 합니다. 해당 요금제의 다른 항목도 별도로 확인해야 합니다.
Xata OSS의 공개 구성에는 비활성 branch를 정지하는 CloudNativePG plugin이 포함됩니다. 다시 깨우는 SQL gateway도 포함됩니다. 이 구조는 실행 수명을 branch 수명과 분리하는 사례입니다. 자체 호스팅에서는 PostgreSQL 프로세스 정지 여부를 관찰해야 합니다. 전체 Kubernetes 및 스토리지 비용의 감소 여부는 별도로 관찰해야 합니다. 실제 절감액은 배치와 자원 할당을 검증한 뒤 확정합니다.
업무 시간에만 사용하는 preview를 가정하면 생성부터 삭제까지의 기간과 실제 실행 기간을 각각 기록합니다. 다음 날 재접속할 때는 최초 생성 시험과 별도로 재개 시간을 측정합니다. compute를 계속 실행하는 정책과 정지하는 정책을 비교합니다. 이때 첫 요청의 대기와 실행 자원 사용량을 함께 보는 방법입니다. 정지 조건은 제품 설정과 작업 패턴에 맞춰 검증합니다.
Neon의 compute 분리와 재개 과정의 상세는 다음 문서에 연결합니다. Autoscaling과 Scale to Zero에서 설명합니다. 여기서는 비용 보고서에서 실행 시간과 존재 시간을 나누는 데 집중합니다. 조사용 branch는 프로세스가 계속 필요하지 않아도 데이터 보존 목적이 남는 경우가 있습니다. 이때는 그 사유와 보존 종료 시각을 기록하는 정책을 제안합니다.
환경을 재개할 때마다 준비 비용을 다시 관찰할 필요도 있습니다. 예를 들어 자주 중단되는 테스트 흐름에서는 재개 대기가 작업 전체의 대기에서 차지하는 비중을 따로 계산합니다. 이 결과를 확인한 뒤 정지 정책을 조정해야 합니다. compute 운영 방식은 분기 생성 시간과 재개 대기를 함께 고려해 결정합니다. 비용 단위와 대기 시간의 측정 범위가 다르므로 둘을 동일한 숫자로 환산하지 않습니다.
부모 변경과 이력 보존
자식에 쓰기가 없어도 전체 저장량은 증가할 수 있습니다. Aurora는 원본 또는 clone의 쓰기에 따라 새로운 page 공간이 필요하다고 설명합니다. ZFS도 snapshot이나 clone이 이전 블록을 참조하는 동안 그 블록을 보존합니다. 부모의 상태가 바뀌어도 자식이 요구하는 과거 상태를 유지해야 합니다. 이 점을 비용 분석에 포함해야 합니다.
측정에는 부모만 변경하는 시험, 자식만 변경하는 시험, 양쪽을 변경하는 시험을 구분하도록 제안합니다. 각 시험은 같은 기준 상태에서 시작합니다. 변경 전후의 저장량과 보존 중인 참조를 기록합니다. 자식의 자체 변경량이 작게 보여도 공유 저장소 전체의 증가량을 함께 기록합니다. 어떤 지표가 자식만 나타내고 어떤 지표가 공유 집합을 나타내는지 먼저 확인합니다.
Neon의 저장 구조에서도 자식 분기점에 필요한 조상 이력이 보존 대상입니다. 따라서 자식의 새 데이터가 적어도 조상 이력의 수명을 함께 고려해야 합니다. 다만 특정 layer의 크기를 관리형 서비스 청구량으로 바로 치환하지 않습니다. 내부 저장 구조의 설명과 공급사가 정의한 사용량 집계는 서로 다른 근거로 확인합니다.
이력 보존 시험에는 현재 데이터 크기를 고정한 상태에서 반복 갱신하는 시나리오를 포함하도록 제안합니다. 최종 행 수가 같아도 과거 상태의 보존 요구가 달라지는지 관찰하기 위해서입니다. 업무 목적이 끝난 branch를 유지하는 정책과 바로 정리하는 정책도 비교합니다. 이때는 현재 데이터 크기에 더해 보존 기간 동안의 누적 저장량을 기록합니다.
삭제 시험에서는 삭제 요청 접수, 객체 삭제 확인, 남은 참조 확인을 따로 관찰합니다. 저장량 변화와 청구 지표 반영도 따로 관찰합니다. 이 구분은 모든 제품이 같은 비동기 정리 구조를 가진다는 주장이 아닙니다. 삭제 API 성공만으로 공간 회수와 비용 감소를 판단하는 일을 막기 위한 시험 설계입니다. 실제 회수 시간은 해당 제품과 생성 모드에서 확인한 값으로만 보고합니다.
물리 저장량과 청구량
Snowflake는 표준 테이블 clone에서 참조하는 저장량과 소유하는 저장량을 구분합니다. 기존 micro-partition을 공유하는 양과 비용을 귀속하는 기준은 서로 다른 개념입니다. 이 사례는 사용자가 조회하는 데이터의 크기와 물리적으로 존재하는 데이터를 구분할 필요를 보여 줍니다. 서비스가 청구하는 데이터도 구분해야 합니다. 같은 용량 단위가 표시되어도 지표의 정의를 함께 읽어야 합니다.
Tiger의 문서는 CoW 경로의 high-performance storage 과금 기준을 설명합니다. 이 경로에는 부모와 달라진 chunk를 과금합니다. 전통적인 경로에는 전체 서비스 스토리지를 과금한다고 설명합니다. tiered data에는 별도 공유 규칙이 있습니다. 따라서 제품별 비용 표를 작성할 때는 생성 모드와 스토리지 종류를 함께 적습니다. 전체 DB 크기에 단일 단가를 곱하는 계산이 해당 서비스의 모든 비용을 설명한다고 가정하지 않습니다.
예산 모델에서는 실행 자원, 보존 데이터, 복구 이력을 각자의 사용량 단위로 계산하도록 제안합니다. 서비스의 추가 branch 항목도 해당 사용량 단위로 계산합니다. 이들을 합칠 때는 같은 비용이 중복 포함되지 않았는지 확인합니다. 자체 호스팅에는 초기 기준 사본을 준비하고 유지하는 자원도 별도 항목으로 둡니다. 관리형 서비스가 내부적으로 제공하는 작업과 직접 운영하는 작업을 비용 표에서 대응시켜야 합니다. 그래야 비교 범위가 맞습니다.
운영 결정에는 준비 시간과 수명당 비용을 함께 제시합니다. 짧게 존재하지만 실행 자원을 많이 쓰는 환경을 구분해 기록합니다. 오래 보존하면서 거의 실행하지 않는 환경도 나누어 기록합니다. 문서상의 빠른 생성 수치만으로 월 비용을 추정하지 않습니다. 선택한 모드의 실제 사용량과 청구서를 대조한 뒤 적용 범위를 정합니다.