에이전트가 만든 DB 마이그레이션: 데이터 보존을 검수하는 순서

생성된 변경 파일은 실행 계획의 초안입니다

코딩 에이전트가 모델 필드를 바꾸고 마이그레이션 파일까지 작성하면 리뷰는 데이터가 변하는 지점으로 이동합니다. Prisma의 현행 안내는 새 구조를 먼저 추가한 뒤 기존 사용을 옮기고 오래된 구조를 제거하는 방식을 설명합니다. PostgreSQL 문서는 스키마 변경별 잠금과 변환 조건을 제공합니다. 이 글은 특정 ORM 명령을 따라 하기보다 생성된 변경의 데이터 의미를 검수하는 기준에 초점을 둡니다.

• Prisma · Expand-and-contract migrations
• PostgreSQL · ALTER TABLE

예를 들어 가상의 주문 테이블에서 결제 여부를 상태 열로 바꾼다고 하겠습니다. 새 열에 기본값을 지정해 마이그레이션이 성공하더라도 이미 결제된 주문이 모두 미결제로 해석될 수 있습니다. 기존 값을 어떤 새 값으로 옮길지, 알 수 없는 상태를 어떻게 보관할지 정해야 합니다. 정상 사례뿐 아니라 과거 수동 수정과 누락 레코드도 변환 규칙에 포함합니다.

행 개수보다 업무 의미가 보존됐는지 확인합니다

변경 전후 총행 수가 같다고 데이터가 보존된 것은 아닙니다. 고객별 주문 금액, 상태별 건수, 참조 관계가 끊긴 행, 빈 값의 분포와 중복 키를 함께 비교하세요. 시간대나 소수 정밀도가 바뀌는 변환은 원래 표현을 복원할 수 있는지도 확인해야 합니다. 비교 질의는 에이전트가 작성할 수 있지만 무엇이 같아야 하는지는 사람이 업무 규칙으로 정의합니다.

복제 환경에는 빈 테스트 DB보다 실제 운영의 크기와 분포를 반영한 자료가 필요합니다. 민감한 값을 제거하되 오래된 상태, 큰 고객사, 긴 문자열 같은 경계는 유지합니다. 전체 데이터 사용이 어렵다면 부족한 분포를 따로 밝히고 생성 샘플로 보완하세요. 샘플에서 성공한 시간을 그대로 운영 소요 시간으로 제시하지 않는 것이 중요합니다.

운영 중 새로 들어오는 쓰기도 변환 대상입니다

기존 데이터를 채우는 동안 애플리케이션이 계속 쓰면 스냅샷 이후의 행이 누락될 수 있습니다. 새 구조 추가, 이전 데이터 채우기, 신규 쓰기 반영, 읽기 전환, 옛 구조 제거를 단계로 나누고 각 단계의 완료 조건을 정합니다. 중단 후 재실행해도 같은 결과가 되도록 처리 범위를 기록하고, 마지막 대조에서 놓친 행을 확인할 방법을 준비합니다.

큰 테이블의 변경은 코드가 짧아도 잠금 대기와 서비스 지연을 일으킬 수 있습니다. PostgreSQL의 해당 버전 문서에서 잠금 수준과 테이블 재작성 가능성을 확인하고, 작은 배치와 제한 시간을 포함한 실행 계획을 검토하세요. 인덱스나 제약조건 변경의 특성도 서로 다릅니다. 모든 DDL을 하나의 트랜잭션에 넣으면 항상 더 안전하다고 일반화하지 않습니다.

되돌릴 수 없는 지점을 배포 전에 표시합니다

열을 삭제하거나 여러 값을 하나로 합친 뒤에는 역방향 SQL만으로 원래 정보를 되살릴 수 없을 수 있습니다. 복구에 필요한 백업, 변경 이후 발생한 거래의 보존과 이전 애플리케이션의 호환성을 함께 확인합니다. 복구 연습에서 어떤 시점의 데이터로 돌아가는지와 그 사이의 쓰기를 어떻게 처리하는지가 설명되어야 실제 복구 계획으로 사용할 수 있습니다.

• 생성 SQL에 예상하지 않은 삭제·형식 축소·기본값 변경이 없는가
• 업무 합계와 관계를 확인할 전후 비교가 있는가
• 변환 도중의 쓰기와 중단 후 재실행을 검증했는가
• 되돌릴 수 없는 단계와 복구 방법을 승인 전에 확인했는가