AI가 만든 SQL UPDATE, 실행 전 대상 행을 확인하는 4단계

AI가 작성한 SQL은 문법이 그럴듯해도 어떤 행이 바뀌는지가 틀릴 수 있습니다. 특히 UPDATE의 WHERE 조건이 빠지거나 날짜 범위가 어긋나면 예상보다 많은 행이 변경됩니다. 이 글은 실제 데이터베이스에 쿼리를 실행한 후기가 아니라, 가상 주문 테이블을 기준으로 검수 순서를 설명합니다. 예시는 PostgreSQL 문법입니다.

1. 변경 요청을 행 조건으로 번역하기

가상의 요청은 “2026년 10월 1일 이후 접수됐고 상태가 pending인 주문만 reviewed로 바꾸기”입니다. AI에게 바로 UPDATE를 요구하기 전에 테이블·날짜 기준·기존 상태·새 상태를 분리해 적습니다. 날짜의 포함·제외 경계도 결정해야 합니다. 타임존이 섞인 시스템에서는 화면 날짜와 저장 시각이 다를 수 있으니 실제 스키마를 먼저 확인하세요.

2. 같은 WHERE로 SELECT부터 확인하기

SELECT order_id, created_at, status
FROM orders
WHERE created_at >= DATE '2026-10-01'
  AND status = 'pending';

반환 행의 개수와 표본을 업무 요청서와 대조합니다. SELECT가 보이는 행과 실제 변경 대상은 권한·트리거·동시 수정 등 환경에 따라 차이가 날 수 있으므로, 이 단계만으로 안전을 보장한다고 생각하면 안 됩니다. 조건이 모호하면 쿼리를 실행하지 말고 담당자에게 기준을 확인합니다.

3. 테스트 환경에서 변경 행을 확인하기

PostgreSQL의 UPDATE ... RETURNING은 실제 갱신된 행의 값을 반환할 수 있습니다. 운영 DB에서 시험 삼아 실행하라는 뜻이 아닙니다. 복제된 테스트 환경과 적절한 권한에서 예상 범위인지 확인하세요. 트리거나 외부 시스템 연동이 있다면 롤백만으로 그 외부 부작용까지 취소된다고 가정하면 안 됩니다.

BEGIN;
UPDATE orders
SET status = 'reviewed'
WHERE created_at >= DATE '2026-10-01'
  AND status = 'pending'
RETURNING order_id, status;
ROLLBACK;

PostgreSQL은 명시적 트랜잭션 밖의 명령이 성공하면 자동 커밋될 수 있습니다. ROLLBACK은 해당 트랜잭션의 데이터베이스 변경을 되돌리지만, 이미 커밋된 변경에는 적용되지 않습니다. 운영 변경은 백업·승인·변경 창구 등 조직 절차를 따르세요.

4. AI에게 검수 질문까지 함께 시키기

“PostgreSQL용 UPDATE를 초안으로 제안하되 바로 실행하지 마세요. 먼저 동일 WHERE의 SELECT, 예상 변경 행 확인 방법, 날짜 경계·NULL·권한·트리거에 관한 반례를 설명해 주세요. 스키마가 없으면 임의로 열 이름을 확정하지 마세요.”

검수의 핵심은 AI가 SQL을 빨리 쓰는지가 아니라, 수정 대상 행을 독립적으로 확인하고 되돌릴 수 있는 운영 절차가 있는지입니다. 쿼리의 문법 검토와 업무 규칙 검토를 분리하면 실수를 발견하기 쉽습니다.

공식 참고: PostgreSQL SELECT, PostgreSQL UPDATE, PostgreSQL 트랜잭션 안내. 확인일: 2026-10-31. 표의 이름·조건·날짜는 설명용 가상 예시이며 실제 실행 결과를 뜻하지 않습니다.