AI가 데이터베이스 마이그레이션을 작성하도록 허용하지 마세요

Source: Dev.to

번역하려는 본문을 제공해 주시면 한국어로 번역해 드리겠습니다.

AI‑생성 데이터베이스 마이그레이션의 위험

“그냥 LLM에 물어보는” 시대는 우리를 놀라울 정도로 생산적으로 만들었지만, 동시에 위험하게 안주하게 만들었습니다. 개발자들은 점점 더 중요한 인프라 결정을 생성 모델에 맡기고 있습니다. AI가 React 컴포넌트나 정규식 패턴을 제안하는 것은 비교적 위험도가 낮지만, 데이터베이스 스키마 전환을 AI에게 맡기는 것은 불을 가지고 노는 것과 같습니다.

왜 컨텍스트가 중요한가

AI는 구문적으로 완벽한 SQL을 생성할 수 있지만, 안전한 변경을 위해 필요한 운영 컨텍스트가 부족합니다. 트래픽 패턴, 잠금 메커니즘, 혹은 테이블 잠금이 10분 이상 지속돼서 새벽 3시에 프로덕션 환경이 다운될지 여부를 알지 못합니다.

AI에게 마이그레이션을 생성해 달라고 요청할 때—예를 들어, 5백만 행을 가진 테이블에 기본값을 가진 non‑nullable 컬럼을 추가한다든지—그가 제공하는 코드는 몇 개의 행만 있는 로컬 데이터베이스에서는 즉시 실행될 가능성이 높습니다. 문제는 동일한 스크립트가 프로덕션 환경에 적용될 때 발생합니다.

예시: AI‑생성 마이그레이션 (전)

-- Generated by AI: Simple, clean, and potentially catastrophic
ALTER TABLE orders ADD COLUMN status_code VARCHAR(255) NOT NULL DEFAULT 'pending';

대용량 테이블에서는 이 작업이 전체 테이블 재작성(full table rewrite)을 트리거할 수 있습니다. PostgreSQL 11 이전 버전에서는 기본값을 모든 행에 쓰는 동안 전체 테이블이 잠금됩니다. 트래픽이 많은 애플리케이션은 모든 연결이 해당 잠금 해제될 때까지 기다리면서 504 Gateway Timeout 오류를 발생시킵니다.

Safer Human‑Engineered Migration (After)

-- Step 1: Add the column as nullable first (instant operation)
ALTER TABLE orders ADD COLUMN status_code VARCHAR(255);

-- Step 2: Set the default for future rows
ALTER TABLE orders ALTER COLUMN status_code SET DEFAULT 'pending';

-- Step 3: Update existing rows in small batches to avoid long‑held locks
-- (Typically handled via a background job or scripted loop)

-- Step 4: Add the NOT NULL constraint after data is populated
ALTER TABLE orders ALTER COLUMN status_code SET NOT NULL;

• Step 1 컬럼을 기본값 없이 nullable 상태로 먼저 추가하여 전체 테이블 재작성 없이 즉시 작업을 완료합니다.
• Step 2 향후 삽입되는 행에 원하는 기본값이 자동으로 적용되도록 설정합니다.
• Step 3 기존 행을 작은 배치로 점진적으로 업데이트하여 장시간 락이 걸리는 것을 최소화합니다.
• Step 4 데이터가 안전하게 채워진 후에 NOT NULL 제약조건을 적용합니다.

Real‑World Incidents

우리는 자동화되었거나 계획이 부실한 마이그레이션이 실제로 큰 문제를 일으킨 사례를 찾기 위해 멀리 볼 필요가 없습니다. 마이그레이션과 관련된 다운타임의 가장 유명한 예 중 하나는 2017년 GitLab 장애였습니다. 이 사건은 수동 개입 중 인간 실수에서 비롯되었지만, 데이터베이스 상태의 취약성을 잘 보여줍니다.

최근 몇몇 기술 스타트업은 AI가 생성한 마이그레이션이 컬럼 타입을 (예: INT → BIGINT) 변경하도록 제안하면서, 롤링 배포 중에 기본 ORM이 전환을 어떻게 처리할지 고려하지 않아 “무음” 데이터 손상이 발생했다고 보고했습니다. AI가 작성한 마이그레이션이 새로운 버전의 애플리케이션이 모든 노드에 완전히 배포되기 전에 컬럼을 삭제하면, 그 결과 상태는 500 오류가 연쇄적으로 발생할 수 있습니다.

AI 모델이 놓치는 것

• Lock Hierarchy: 이 ALTER TABLE이 SELECT 쿼리를 차단하나요?
• Replication Lag: 대규모 업데이트가 읽기 복제본을 지연시키나요?
• Deployment Strategy: 이것이 블루‑그린 배포인가, 롤링 재시작인가?

마이그레이션은 단순한 스크립트가 아니라 살아있는 시스템의 두 상태 사이를 연결하는 다리입니다.

모범 사례

AI는 보일러플레이트 작업에 뛰어난 도구입니다. 복잡한 조인 테이블 세트를 스캐폴딩해야 할 경우, AI에게 초기 DDL 작성을 맡기세요. 그러나 코드가 마이그레이션 파일에 손을 대는 순간, “AI” 부분의 작업은 끝납니다. 여러분은 다음을 해야 합니다:

1. 엔지니어로서 마이그레이션을 직접 책임한다.
2. 잠금(lock)을 확인하고 동시 트래픽에 미치는 영향을 이해한다.
3. 실행 계획을 검토하여 작업이 확장 가능한지 확인한다.
4. 프로덕션 규모 데이터 세트에 대해 마이그레이션을 시뮬레이션한 후 프로덕션에 적용한다.

결론

데이터베이스는 애플리케이션의 핵심입니다. 확률 모델이 그것에 대해 심장 수술을 하도록 두지 마세요. AI를 사용해 일상적인 작업을 가속화하되, 실시간 트래픽에 영향을 미치는 스키마 변경과 같은 경우에는 항상 인간 전문가의 판단을 적용하세요.