1.1 데이터 환경의 준비 비용
새 코드가 실행되더라도 검증에 필요한 데이터가 준비되었는지는 별도로 확인해야 합니다. 입력값 몇 개로 기능을 확인하는 시험과 운영 규모의 검증은 완료 조건이 다릅니다. 운영 규모의 검증에는 쿼리나 마이그레이션 시험이 해당합니다. 이 장에서는 데이터 환경 요청자가 무엇을 시험하려는지 먼저 구분합니다. 이어서 DBA가 어떤 상태까지 준비한 뒤 작업을 넘겨야 하는지 설명합니다. 준비 비용에는 생성 명령의 실행 시간과 기준 데이터 선정이 포함됩니다. 접속 확인, 검증 조건 기록, 사용 후 정리도 포함합니다.
시험 목적과 데이터 범위
기능 시험을 설계할 때는 필요한 입력과 예상 결과부터 적습니다. 예를 들어 주문 상태 변경 기능을 시험한다고 가정합니다. 정상 상태, 취소 상태, 허용하지 않는 전이를 표현한 seed를 준비합니다. 이 seed로 시험하고 결과를 대조하는 절차를 제안합니다. 이 경우 준비 목표는 시험에서 지정한 상태를 재현하는 것입니다. 운영 데이터 전체의 크기를 그대로 가져오는 요구와 구분해야 합니다. 여기의 주문 예시는 시험 요구를 설명하기 위한 가정입니다. 특정 고객의 도입 사례가 아닙니다.
Supabase의 기본 branch는 schema, Edge Functions와 설정을 준비합니다. 운영 데이터와 Storage object는 포함하지 않습니다. 따라서 preview를 만든 뒤에도 운영 데이터의 준비 여부는 별도로 확인해야 합니다. 필요한 데이터는 별도의 시험 준비 항목으로 정해야 합니다. Dashboard의 Include data는 PITR add-on이 필요한 선택 경로입니다. 기본 동작과 구분합니다. 이 옵션에는 더 큰 디스크와 원본에 맞춘 compute가 관련됩니다. 따라서 기본 preview와 비용 조건을 구분합니다.
운영 규모 시험에서는 확인할 질문이 달라집니다. GitLab의 공식 개발 문서는 DBLab을 운영 규모 데이터의 검증 도구로 설명합니다. 검증 대상은 쿼리와 마이그레이션입니다. 사실 대장이 확인한 범위는 이 검증 용도입니다. GitLab의 모든 CI 작업이 DBLab을 사용한다고 확대하지 않습니다. 모든 기능 시험에 운영 사본이 필요한지도 이 근거만으로 판단할 수 없습니다. 공개 사례의 신뢰도는 높음입니다. 고객 자체의 개발 문서에서 실제 사용 근거를 확인한 경우에 해당합니다.
시험 계획에는 기능의 결과를 비교할지, 운영 규모에서 변경 작업을 검토할지 먼저 명시하도록 권합니다. 후자의 경우 데이터의 크기와 분포, 기준 시점, 실행 환경을 검토 기록에 남기는 편이 적절합니다. 물리 수집은 해당 시점의 page 상태와 통계를 보존하는 데 유리합니다. 다만 실행 계획과 실행 시간의 동일성을 보장하지 않습니다. 설정, 버전, 하드웨어와 부하도 영향을 줍니다. 사본에서 얻은 결과로 운영 환경을 예측할 때는 이 조건을 함께 제시합니다.
코드 준비와 데이터 준비의 연결
다음 그림은 이 노트가 제안하는 검증 준비 흐름입니다. 코드 checkout과 애플리케이션 배포, 데이터 준비를 별도 작업으로 표시합니다. 두 경로가 만나는 지점에서는 접속 대상과 시험 입력을 확인합니다. 아래의 분기는 제품 우열이나 반드시 거쳐야 할 구현 단계를 나타내지 않습니다. 데이터 요구를 결정한 뒤 해당 요구에 맞는 환경을 연결하기 위한 설계안입니다.
작업 요청에는 코드 버전과 데이터 기준점을 함께 적도록 권합니다. 가령 같은 마이그레이션을 두 번 시험한다고 가정합니다. 첫 시험 뒤의 데이터 상태를 이어 쓸지 처음 상태에서 다시 시작할지부터 정해야 합니다. 두 시험의 결과를 비교하려면 시작 조건을 기록해야 하기 때문입니다. 이 원칙은 특정 branch 제품의 reset 기능을 전제하지 않습니다. 필요한 시작 상태를 제공하는 경로는 다음 단계에서 선택합니다. 새 사본, 복원 또는 시험 데이터 재구성 중에서 선택합니다.
데이터 범위에는 테이블의 내용 외에 접속과 실행에 필요한 항목도 포함합니다. 다만 복제되는 객체의 범위는 확인된 사실에 한정합니다. Supabase는 branch별 API 자격증명을 제공합니다. branch에 설정한 secret은 다른 branch에서 자동으로 사용하지 않습니다. DBLab은 clone 생성 시 접속 자격증명을 지정합니다. 원본의 PostgreSQL major version에 맞는 이미지를 선택합니다. 이 사실로 확인할 수 있는 범위는 위에 명시한 동작까지입니다. 모든 role, extension 바이너리와 외부 설정의 복제 방식은 별도 확인이 필요합니다.
인수인계 문서에는 데이터 준비 책임자와 애플리케이션 연결 책임자를 적도록 제안합니다. DBA가 SQL 접속까지 확인했더라도 애플리케이션의 endpoint는 연결 단계에서 대조해야 합니다. 시험 대상의 이름, 기준 시점, 연결 설정을 한 기록으로 남깁니다. 그러면 준비 완료가 무엇을 뜻하는지 검토하기 쉬워집니다. 이는 이 노트의 운영 설계 제안입니다. 앞서 언급한 고객사의 내부 운영 정책을 재현한 설명은 아닙니다.
준비 완료의 측정 경계
Branch 생성 API가 성공한 시점과 SQL을 실행할 환경이 준비된 시점은 구분합니다. 사실 대장의 생성 시간 판정은 조건부입니다. 일부 메타데이터 작업의 성질을 접속 가능한 환경 전체로 확대하지 않는다는 의미입니다. DBLab 4.2의 설명에는 파일 소유권 처리 작업이 등장합니다. 이 작업은 clone 준비 시간에 영향을 줍니다. Tiger의 fork 문서는 CoW 경로와 backup restore 및 WAL replay 경로를 구분합니다. 같은 생성 요청처럼 보여도 완료 전 작업의 범위가 다릅니다.
이 차이를 기록하기 위해 다음 측정 항목을 제안합니다. 제품 문서의 완료 상태 이름은 제각각입니다. 따라서 로컬 실험에서는 관찰한 이벤트를 직접 적습니다. 표의 단계는 시험 기록의 대조 항목입니다. 모든 제품의 내부 실행 순서를 확정한 목록은 아닙니다. 특히 첫 SQL의 성공과 애플리케이션의 정상 성능 도달은 구분해 기록합니다.
| 관찰 항목 | 기록할 이벤트 | 함께 기록할 조건 |
|---|---|---|
| 생성 요청 | API 호출과 응답 | 생성 모드, 기준 시점 |
| SQL 접속 | 인증 후 SQL 성공 | Endpoint, compute 구성 |
| 첫 시험 쿼리 | 최초 실행 완료 | 쿼리와 캐시 조건 |
| 반복 시험 | 지정한 반복 실행 완료 | 동시 작업, 실행 환경 |
DBA가 준비 시간을 비교할 때는 데이터 크기와 파일 수를 기록해야 합니다. 필요한 WAL 재생, compute 기동, 부하도 기록해야 합니다. 어느 제품이 더 빠른지 판단하려면 같은 완료 조건으로 측정해야 합니다. 공급사 안내 시간은 자체 측정 결과와 구분해 적습니다. 이 영역의 사실 대장에는 공통 조건의 자체 측정 결과가 없습니다. 따라서 초 단위의 제품 순위나 데이터 크기와 무관한 준비 시간은 이 장의 제시 범위에서 제외합니다.
초기 데이터 준비를 마친 환경의 생성 시간은 최초 원본 수집부터 잰 시간과 구분합니다. 이 구분도 측정 설계에 포함합니다. 비교 기록에는 측정 시작 전에 무엇을 준비했는지 적습니다. 저장소 구성, 기준 사본, 이미지와 접속 설정의 준비 여부를 남깁니다. 그러면 후속 실험에서 같은 범위를 재현하기 쉬워집니다. 구현 단계별 분석은 Part 2에서 이어갑니다. 여기서는 시험 담당자에게 넘길 상태를 먼저 정의합니다.
사용 기간과 자원 비용
초기 저장 데이터를 공유하는 것과 환경의 총비용이 없는 것은 다른 주장입니다. Aurora clone은 변경되지 않은 page를 공유합니다. 원본이나 clone에 쓰기가 발생하면 새 page 공간이 필요해집니다. ZFS도 보존된 참조가 남아 있으면 이전 block을 해제하지 못합니다. 자식이 읽기만 한다는 이유로 추가 저장량을 항상 0으로 계산하면 누락이 생깁니다. 부모 변경 후에도 유지되는 공간을 빠뜨리기 때문입니다. 실제 청구 규칙은 제품별로 따로 확인합니다.
Compute의 사용과 변경 데이터, 보존 이력, 서비스 과금도 구분합니다. Tiger의 현행 문서는 CoW 스토리지와 전통적인 복원 경로의 과금 범위를 나누어 설명합니다. 이 차이 때문에 같은 공급사의 fork라도 생성 모드를 기록해야 합니다. 한편 Neon의 과금 설명 역시 저장량과 branch 수명 등을 검토하는 근거로 사용합니다. 다만 이 장에서는 변동 가능한 단가나 특정 환경의 월 비용을 제시하지 않습니다.
시험을 위한 비용 기록에는 요청부터 삭제까지의 기간을 포함하도록 제안합니다. 결과 검토를 기다리느라 유지한 시간, 재시험을 위해 보존한 데이터, 사용 후 남은 사본을 구분합니다. 환경 개수와 함께 목적, 소유자, 만료 예정 시각도 적는 방식이 적절합니다. 특정 TTL이나 quota 값을 제품의 권장값으로 제시할 근거는 없습니다. 고객사의 실제 정책으로 제시할 근거도 부족하므로 그 값은 팀의 시험 요구에 맞춰 정합니다.
이 설계에서 절감 여부를 비교할 대상은 같은 시험 목적을 충족하는 준비 절차입니다. 작은 seed로 충분한 시험과 운영 규모 사본이 필요한 시험은 구분해 비교합니다. 각 시험에 필요한 데이터 범위와 준비 완료 상태를 정합니다. 그런 다음 생성, 실행, 보존, 정리 비용을 기록합니다. 이어지는 Branch와 인접 개념에서는 이 요청을 표현할 동작을 살펴봅니다. snapshot, clone, replica, backup 중 어떤 동작이 적절한지 검토합니다.