6.3 실습과 증거 관리
생성 API의 빠른 응답만으로 개발 환경의 준비 시간을 평가하면 첫 쿼리와 복구 단계를 놓칩니다. 부모 삭제 후 자식에 접속한 결과도 이력 만료 이후의 복구를 대신하지 않습니다. 도입 판단에 사용할 시험은 질문을 좁혀야 합니다. 시작 조건과 종료 조건도 실행 전에 기록해야 합니다.
이 장의 다섯 실험은 검증 설계안이며 모두 미실측입니다. 기존 로컬 실습의 기록과 공급사 공개 수치는 이번 비교 결과와 구분합니다. 제품 사실의 기준일은 2026-09-30입니다. 측정할 때는 별도의 실행일과 제품 버전을 기록합니다. 결과가 없는 칸은 0으로 채우지 않습니다.
공통 조건과 실행 경계
시험마다 원본 데이터의 크기와 객체 수, 기준 시점, 생성 모드를 고정하도록 제안합니다. 데이터는 합성 데이터나 검증한 마스킹 데이터를 사용합니다. 운영 원본을 직접 변경하거나 삭제하는 절차는 포함하지 않습니다. 공유 자원에 부하를 가하는 시험은 전용 환경에서 시작합니다. 운영 적용 시험은 별도 승인 범위와 중단 기준을 정합니다.
시간은 요청 전송, API 응답, SQL 접속 성공, 첫 업무 쿼리 완료, 반복 실행 안정화로 나누어 기록합니다. 각 시각의 판정 방법도 명시합니다. 예를 들어 SQL 접속 성공에는 인증과 간단한 조회를 포함합니다. 업무 쿼리 완료에는 결과 검증을 포함하도록 정합니다. API 응답 시각만 제공하는 제품은 나머지 구간을 클라이언트에서 관찰합니다.
Neon 내부 API와 저장소 관찰 명령은 로컬 실습에 연결합니다. 공개 docker-compose는 이미지 테스트용입니다. 사용 가능한 서비스 배포가 목적이 아니라는 공식 README의 조건을 유지합니다. 로컬 엔진 실험과 관리형 서비스 API 시험은 별도 결과로 보존합니다. 같은 저장 엔진을 사용한다는 이유로 endpoint 준비나 관리 기능까지 같다고 평가하지 않습니다.
ZFS와 DBLab의 구성, Dolt 계열의 변경 시험은 온프레미스 대안의 절차를 참고합니다. DBLab에서는 snapshot을 가리키는 branch 포인터와 접속 가능한 clone을 구분합니다. 시간도 각각 기록합니다. Dolt의 충돌 재현 기록을 추가할 경우 같은 cell의 상이한 수정과 서로 다른 column의 수정을 구분합니다. 이 기록은 아래 다섯 실험의 성능 결과에 합산하지 않습니다.
초기 읽기와 공유 자원 실험
Cold query
첫 실험은 생성 완료가 곧 업무 쿼리 준비 완료라는 가설을 검증합니다. 동일 기준점에서 새 branch를 만들고 첫 접속과 지정한 읽기 쿼리를 실행합니다. 데이터 조회 범위와 결과 검증식을 고정합니다. 연결 준비 시간과 쿼리 실행 시간은 분리합니다. 이후 같은 쿼리를 정해진 횟수로 반복해 첫 실행과 후속 실행의 지연을 비교합니다.
Cold의 의미는 캐시 계층별로 기록하도록 제안합니다. 새 compute에서 시작했다는 사실만으로 스토리지 캐시까지 비었다고 표시하지 않습니다. 캐시 상태를 제어하지 못한 계층은 미확인으로 남깁니다. 공급자의 내부 캐시를 임의로 초기화했다는 가정은 배제합니다. 시험 순서가 결과에 영향을 주는지는 독립 실행을 반복해 확인합니다.
API 완료는 빨라도 첫 업무 쿼리가 합격 기준을 넘으면 해당 시나리오의 준비 시간은 미충족으로 판정합니다. 합격 기준은 사용자가 허용하는 대기 시간에서 정하며 제품 공개 수치로 대체하지 않습니다. 현재 결과는 미실측입니다. DBLab 4.2의 파일 소유권 처리와 Tiger의 생성 모드별 준비 차이를 참고합니다. 두 내용은 측정 구간을 분리할 문서 근거로만 사용합니다.
부모 대량 갱신
두 번째 실험은 읽기만 하는 자식의 존재가 추가 보존 공간과 무관하다는 가설을 검증합니다. 같은 기준 데이터에 자식이 없는 대조군과 읽기 전용 자식이 남은 실험군을 준비합니다. 부모에 동일한 갱신 SQL을 실행하고 변경 행 수와 실행 시간을 기록합니다. 각 실행 전후의 부모와 자식 조회 결과도 검증합니다.
논리 데이터 크기와 서비스가 공개하는 저장량을 기록합니다. 부모의 WAL 발생량과 관찰 가능한 입출력도 기록 대상입니다. ZFS에서는 보존된 참조가 이전 block의 해제를 막는다는 설명을 출발점으로 삼습니다. Aurora도 원본 또는 clone의 쓰기가 추가 page 공간을 사용한다는 문서가 있습니다. 두 제품의 실제 증가량이 같다고 가정하지 않습니다.
갱신 직후와 후속 정리 이후는 측정 시점을 구분합니다. Vacuum이나 다른 관리 작업을 실행했다면 명령과 시각을 남깁니다. 청구 지표는 별도 관찰 기간을 정하고 물리 공간과 나란히 기록합니다. 자식의 쓰기량이 0이라는 조건을 확인하지 못했으면 대조 결과에서 제외합니다. 현재 저장량 변화와 원본 지연 결과는 미실측입니다.
동시 branch
세 번째 실험은 branch 간 쓰기 격리가 자원 경합의 부재까지 뜻하는지 검증합니다. 먼저 단일 branch에서 기준 부하를 실행합니다. 이후 같은 기준점의 branch 수를 단계적으로 늘리고 각 branch에 같은 부하를 배정합니다. Compute 크기와 쿼리 동시성을 고정합니다. 원본 또는 기준 환경의 지연도 함께 관찰합니다.
동시 생성과 동시 실행은 두 구간으로 나눕니다. 생성 구간에서는 요청 대기와 실패율을 기록합니다. 실행 구간에서는 처리량과 지연 분포를 기록합니다. 실제 자원 격리가 다른 구성을 같은 조건이라고 표시하지 않습니다. 수명 정책의 동시 생성 quota와 동시 시험 quota를 각각 조정할 근거로 사용합니다. 시험 중단 기준을 넘으면 정리 단계로 전환합니다.
현재 허용 동시 개수와 지연 변화는 미실측입니다. 제품별 quota에 도달한 실패와 공유 자원 경합에 따른 지연을 구분해 기록하도록 제안합니다. 오류 응답을 제외하고 성공 요청만 평균 내면 사용자가 경험한 실패가 사라집니다. 따라서 성공 수와 실패 수를 함께 보고합니다. 생성 실패 뒤 남은 자원도 종료 시점에 조회합니다.
삭제와 이력 만료 실험
원본 또는 조상 삭제
네 번째 실험은 원본 삭제가 항상 허용되고 자식 복구에도 영향이 없다는 가설을 검증합니다. 폐기 가능한 원본에서 자식과 손자 관계를 만들고 계보를 기록합니다. 삭제 전 각 사본의 검증용 데이터를 읽어 기준값을 보존합니다. 직접 부모와 더 위의 조상 삭제는 다른 실행으로 나눕니다. 문서에 따른 예상 동작을 먼저 적습니다.
ZFS에서는 origin 의존성 때문에 삭제 거절도 예상 결과에 포함합니다. 거절을 우회하는 재귀 삭제는 시험 절차에서 제외합니다. Aurora에서는 원본 삭제 후 자식 조회와 청구 귀속을 별도로 관찰합니다. Delta에서는 OSS shallow clone과 Unity Catalog 모드를 분리합니다. Runtime 및 테이블 유형도 기록합니다. Unity Catalog의 참조 보호가 원본 삭제 후 purge에도 같은 보장을 제공한다고 해석하지 않습니다.
삭제가 허용됐으면 자식에서 전체 검증 범위를 다시 읽고 새 쓰기도 확인하도록 제안합니다. 삭제가 거절됐으면 오류 원문과 남은 의존성을 보존합니다. API 성공, 읽기 성공, 참조 해제, 공간 회수, 청구 변화에 각각 결과를 남깁니다. 내부 상태를 조회하지 못한 경우는 미확인으로 표기합니다. 이번 실행을 하지 않은 항목은 미실측으로 표기합니다.
이력 만료 후 복구
다섯 번째 실험은 보존 기간 밖에서도 같은 복구 경로가 유효하다는 가설을 검증합니다. 검증용 데이터를 순서대로 변경하고 각 변경의 성공 응답 시각과 기준점을 저장합니다. 먼저 보존 범위 안의 목표 시점을 복구해 자료와 절차가 유효한지 확인합니다. 이후 같은 목표가 보존 범위를 벗어난 조건에서 복구를 다시 요청합니다.
요청 실패와 목표 시점 불일치를 따로 판정하도록 제안합니다. 복구 API가 다른 시점을 제안하면 원문과 데이터 검증 결과를 함께 남깁니다. 실제 복구 결과가 목표와 다를 때도 같은 내용을 남깁니다. 별도 backup을 사용하는 재시험은 복구 경로가 달라졌음을 표시합니다. 이력 만료 후 복구 성공 사례로 기록할 때도 어떤 보존 자료를 사용했는지 명시합니다.
보존 기간과 RPO를 같은 값으로 해석하지 않습니다. PostgreSQL PITR의 backup과 WAL 조건, cluster와 timeline 관계를 기록합니다. 복구 후 데이터 시점도 대조합니다. 업무 복구가 목적이라면 애플리케이션 검증까지 종료 조건에 포함합니다. 현재 이력 만료 후 복구 성공 여부와 복구 시간은 모두 미실측입니다.
측정 기록과 증거 등급
아래는 대조군과 실험군을 한 실행 단위로 기록할 양식입니다. 예시 수치는 넣지 않았으며 미실측은 아직 실행하지 않았다는 뜻입니다. 조회할 수 없는 서비스 내부 지표는 측정 후에도 미확인으로 남깁니다. 파일 경로에는 보존할 원본 로그와 검증 쿼리의 위치를 기록합니다. 접속 secret이나 원본 개인정보는 제외합니다.
| 기록 항목 | 대조군 | 실험군 |
|---|---|---|
| 실행 ID와 실행일 | 미기록 | 미기록 |
| 제품, 엔진 버전, 생성 모드 | 미기록 | 미기록 |
| 원본 ID와 계보, 기준 시점 | 미기록 | 미기록 |
| 데이터 크기와 객체 수 | 미실측 | 미실측 |
| Compute와 스토리지 구성 | 미기록 | 미기록 |
| 캐시 조건과 관찰 범위 | 미기록 | 미기록 |
| 요청, API 완료, SQL 준비 시각 | 미실측 | 미실측 |
| 첫 쿼리와 반복 쿼리 지연 | 미실측 | 미실측 |
| 동시 개수, 성공 수, 실패 수 | 미실측 | 미실측 |
| 부모 지연과 WAL 발생량 | 미실측 | 미실측 |
| 변경 데이터와 보존 저장량 | 미실측 | 미실측 |
| 삭제, 참조 해제, 회수 시각 | 미실측 | 미실측 |
| 청구 관찰 기간과 요금제 | 미기록 | 미기록 |
| 복구 목표와 결과 기준점 | 미기록 | 미실측 |
| 오류 원문과 로그 경로 | 미기록 | 미기록 |
증거 등급은 단순한 점수 순위로 사용하지 않습니다. 기능 문서는 지원 동작과 제약을 확인하는 근거입니다. 고객 사례는 공개된 업무에서 사용했다는 근거입니다. 동일 조건 측정은 해당 버전과 구성의 결과를 입증합니다. 각 증거는 서로 대신할 수 없으며, 문서의 존재만으로 실제 고객 도입이나 측정 성공을 입증하지 못합니다.
GitLab의 DBLab 사용은 고객 자체 개발 문서에서 확인한 사례로 신뢰도 높음입니다. 운영 규모 데이터의 쿼리와 migration 검증 용도라는 범위를 유지합니다. 이 사례로 제품 간 가용성 순위를 정하거나 GitLab의 모든 CI가 DBLab을 사용한다고 확대하지 않습니다. 공급사 발표 수치를 인용할 때는 공급사 문서 기준이라고 표시합니다. 이번 시험의 측정값과도 분리합니다.
판정문에는 통과한 조건과 남은 불확실성을 함께 적도록 제안합니다. 첫 읽기만 측정했다면 결론도 그 범위로 한정하고 장기 비용이나 복구 성능은 판단을 보류합니다. 다른 실행에서 얻은 빠른 생성 시간과 낮은 저장량을 합쳐 하나의 대표 결과를 만들지 않습니다. 조건이 다른 기록은 보존하되 동일 조건 비교표에서는 구분합니다.
출처 현행화 절차
자료를 갱신할 때는 주장별로 출처 URL, 발행일, 마지막 확인일, 적용 버전과 생성 모드를 기록합니다. 문서에서 발행일을 제공하지 않으면 미표기로 남깁니다. 검색엔진의 수집일은 발행일과 구분합니다. 현재 기능 설명과 과거 고객 사례를 같은 시점의 자료로 묶지 않도록 각 자료의 날짜 역할을 구분합니다.
현행화는 기능 추가나 요금제 변경, Runtime 변경, 시험 실패를 계기로 수행하도록 제안합니다. 기존 URL의 본문을 다시 확인하고 해당 주장을 뒷받침하는 조건이 달라졌는지 비교합니다. 변경된 근거는 이전 확인 기록과 함께 보존합니다. 더 넓은 표현을 발견해도 엔진과 생성 모드가 일치하는지 먼저 확인합니다. 확인 전까지는 기존 미확인을 유지합니다.
수정할 때는 기능표와 함께 관련 도식과 실험의 예상 결과, 보안 검사 항목, 참고 절을 검토합니다. 기능 변경이 시험 조건에 영향을 주면 재실행이 필요한 결과를 표시합니다. 문서 변경 없이 실행 결과가 달라졌다면 버전과 설정 차이를 먼저 조사합니다. 재현하지 못한 원인은 공급사 동작으로 단정하지 않습니다.
최종 검토에서는 모든 제품 사실이 사실 대장이나 확인한 1차 출처에 연결되는지 확인합니다. 미실측 항목과 미확인 기능은 다음 조사 대상으로 남깁니다. 갱신 후에는 링크와 문서 형식을 검증합니다. 새 측정 결과에는 재현 조건과 원본 기록을 첨부해 다음 검토자가 같은 범위를 다시 평가하도록 합니다.