AI 코딩 에이전트가 데이터베이스 마이그레이션을 작성하고 있습니다. 이것이 운영 환경을 망가뜨리는 이유

요약 (TL;DR): 세 가지 독립적인 데이터 포인트가 하나의 결론으로 수렴합니다. 최첨단 LLM (Frontier LLMs)은 현실적인 기업용 SQL 벤치마크에서 단 10~~24%의 점수만을 기록하며, 동일한 프롬프트를 바꾸기만 해도 정확도가 10~~20%포인트씩 요동칩니다. 동시에 코딩 에이전트(coding agents)는 현재 운영 환경의 마이그레이션(migrations) 중 상당 부분을 작성하고 있습니다. 해결책은 AI 사용을 중단하는 것이 아닙니다. AI가 생성한 DDL을 풀 리퀘스트(pull-request) 시점에 락 그래프 시뮬레이터(lock-graph simulator)를 통해 실행하여, 운영 환경에서 조용히 실패할 마이그레이션이 머지(merge)되기 전에 탐지되도록 하는 것입니다.

코딩 에이전트가 데이터베이스 마이그레이션이 포함된 풀 리퀘스트(pull request)를 생성합니다. 문법적으로 완벽하고, 린트(lint)를 통과하며, 테스트 스위트(test suite)를 통과하고, CI(지속적 통합)도 초록불입니다. 하지만 그 직후, 운영 환경의 10억 행 규모 테이블에 락(lock)을 걸어버려 그 뒤에 대기 중인 모든 쿼리를 중단시킵니다. 당신의 파이프라인(pipeline) 중 그 무엇도 이를 예측하지 못했습니다. 파이프라인의 그 어떤 것도 운영 환경의 락 그래프(lock graph)를 읽지 않기 때문입니다. 이것이 2026년의 새로운 데이터베이스 리스크 형태입니다. 구문 분석에 실패하는 나쁜 SQL이 아니라, AI 에이전트가 작성하고 인간이 대충 훑어보았으며, 실제 운영 상태(live production state)와 대조하여 검증하는 절차가 전혀 없었던 그럴듯한 SQL이 문제입니다.

AI가 생성한 SQL이 정확히 이런 종류의 작업에서 신뢰할 수 없다는 증거는 단순한 일화가 아닙니다. 2018년 텍스트-투-SQL(text-to-SQL) 벤치마크인 Spider 1.0에서 GPT-4o는 86.6%를 기록했습니다. 하지만 실제 기업 워크플로우를 반영하도록 설계된 2024년 벤치마크인 Spider 2.0에서 동일한 GPT-4o는 10.1%를 기록했습니다. 2025년 8월에 공개된 BIRD-Interact의 전체 600개 문제 세트에서는 가장 뛰어난 최첨단 LLM (frontier LLM)이 16.33%를 기록했습니다. 이러한 벤치마크 점수가 하락하는 것과 같은 시기에, 코딩 에이전트는 공개된 GitHub 커밋(commits) 약 20개 중 1개를 작성했습니다. 그 커밋 중 일부는 운영 마이그레이션입니다. 벤치마크 성능과 실제 운영 배포(production deployment) 사이의 간극은 그 어느 때보다 크며, 여전히 벌어지고 있습니다.

세 가지 데이터 포인트, 하나의 궤적

중요한 세 가지 벤치마크는 Spider 2.0 (ICLR 2025 Oral), BIRD-Interact (ICLR 2026, 2025년 6월과 8월 두 단계로 출시), 그리고 EMNLP Findings 2025 SQL2NL의 paraphrase-robustness (의역 강건성) 논문입니다. 각 벤치마크는 서로 다른 실패 모드 (failure mode)를 측정합니다. 이들은 함께 하나의 궤적을 설명합니다. 즉, 벤치마크가 실제 운영 (production) SQL 작업에 가까워질수록, 최첨단 LLM (Large Language Model)의 정확도는 더 급격히 무너집니다.

이 벤치마크들 전반에 걸쳐 나타나는 패턴은 극명합니다. 2018년 Spider 1.0 싱글샷 (single-shot) 벤치마크에서 GPT-4o는 86.6%에 도달합니다. 2023년 BIRD 싱글샷 벤치마크에서 o1-preview 에이전트는 73%에 도달합니다. 엔터프라이즈급인 Spider 2.0에서 GPT-4o는 10.1%로 떨어지며, o1-preview 코드 에이전트는 21.3%에 도달합니다. BIRD-Interact 전체 600개 세트에서 가장 뛰어난 LLM은 16.3%에 머물렀고, a-mode 분할(split)에서의 Claude 3.7 Sonnet은 17.8%에 머물렀습니다. 벤치마크가 실제 엔터프라이즈 SQL에 가까워질수록, 최첨단 LLM의 정확도는 60~70 퍼센트 포인트(percentage points) 하락합니다.

Spider 2.0: 엔터프라이즈 워크플로우의 붕괴

xlang-ai 그룹에서 개발하여 ICLR 2025에 발표된 Spider 2.0은 실제 엔터프라이즈 데이터베이스 사용 사례에서 추출한 632개의 문제입니다. 이 데이터베이스들은 1,000개 이상의 컬럼 (column)을 포함하며 BigQuery 또는 Snowflake 환경에 존재합니다. 논문에 따르면 GPT-4o는 10.1%, o1-preview는 17.1%, 그리고 o1-preview를 기반으로 구축된 코드 에이전트 프레임워크 (code-agent framework)는 21.3%를 기록했습니다. 동일한 논문에서 같은 모델로 보고한 Spider 1.0의 비교 수치는 각각 86.6% (GPT-4o)와 91.2% (코드 에이전트)였습니다. 2023년의 이전 현실적 벤치마크인 BIRD는 73%였습니다. Spider 1.0에서 Spider 2.0으로 넘어가는 것은 동일 모델 기준 약 70 퍼센트 포인트의 하락을 의미합니다. 아키텍처 (architecture)는 변하지 않았습니다. 벤치마크가 실제 업무와 매핑되는 방식으로 더 어려워진 것입니다.

BIRD-Interact: 멀티턴의 붕괴

bird-bench의 BIRD-Interact는 text-to-SQL을 상호작용적 태스크 (interactive task)로 재정의합니다. 모델은 단일 샷 생성 (single-shot generation) 대신 대화형 (c-Interact) 또는 에이전트 방식 (a-Interact) 세션을 통해 작동합니다. 논문에 따르면, 2025년 6월 출시 기준으로 o3-mini는 c-Interact에서 24.4%의 성공률 (Success Rate)을 기록했고, Claude 3.7 Sonnet은 a-Interact에서 17.78%를 기록했습니다. 2025년 8월에 600개의 전체 문제 테스트 세트가 공개되었을 때, 측정된 가장 우수한 모델은 16.33%였으며, c-Interact와 a-Interact 분할은 각각 약 10% 수준에 머물렀습니다. 논문은 "상호작용 시간 스케일링 (Interaction-Time Scaling)", 즉 모델에게 더 많은 턴 (turns)을 제공하는 것이 도움이 된다는 점을 식별했습니다. 하지만 이것이 프런티어 LLM (frontier LLMs)의 마케팅에서 제시하는 수준의 정확도 수치에 도달하게 하지는 못했습니다.

SQL2NL: 패러프레이즈 붕괴 (the paraphrase collapse)

Safarzadeh, Oroojlooy, 그리고 Roth의 EMNLP Findings 2025 논문은 의미를 바꾸지 않고 프롬프트 (prompt)를 패러프레이즈 (paraphrase, 바꾸어 말하기)할 때 어떤 일이 발생하는지 테스트합니다. 연구진은 스키마 정렬된 SQL-to-NL 파이프라인 (pipeline)을 사용하여 어휘적으로는 다르지만 의미론적으로 동일한 프롬프트를 생성한 다음, 동일한 기본 쿼리 (query)에 대한 정확도를 측정합니다. LLaMa 3.3 70B는 패러프레이즈된 Spider 쿼리에서 77.11%에서 66.9%로 10.23포인트 하락했습니다. LLaMa 3.1 8B는 62.9%에서 42.5%로 20.4포인트 하락했습니다. GPT-4o mini는 "불균형적으로 큰 영향을 받았습니다." 논문이 도출한 해석은 직설적입니다: 최첨단 모델들은 표준 벤치마크 (benchmarks)가 시사하는 것보다 훨씬 더 취약합니다 (brittle). 데이터 분석가가 아닌 제품 관리자 (product manager)가 동일한 프롬프트를 다시 표현하는 것만으로도 정확도가 두 자릿수만큼 변동합니다.

한편, 에이전트들은 마이그레이션을 작성하고 있습니다

두 번째 데이터 포인트는 독립적으로 추적됩니다. Claude Code는 2025년 2월에 출시되어 2025년 5월에 일반 가용성(General Availability) 단계에 도달했습니다. 2026년 초, Anthropic의 텔레메트리(Telemetry) 보고서에 따르면 Claude Code는 모든 공개 GitHub 커밋의 약 4%를 작성하고 있습니다. JetBrains 2026 개발자 설문조사(Developer Survey)에 따르면 직장 내 GitHub Copilot 채택률은 29%이며, Cursor와 Claude Code는 각각 18%입니다. 이는 모든 종류의 코드를 합산한 수치입니다. 해당 커밋 중 데이터베이스 마이그레이션(Database Migration) 파일이 차지하는 비중이 어느 정도인지에 대한 공개된 세부 분석은 없지만, 기본 비율을 고려할 때 그 절대적인 수치는 결코 작지 않습니다. 15명에서 60명 규모의 엔지니어링 SaaS 팀이 일주일에 한두 개의 마이그레이션을 배포하고, 엔지니어의 절반이 일정 비율의 시간 동안 코딩 에이전트(Coding Agent)를 사용한다면, AI가 초안을 작성한 DDL(Data Definition Language)이 지속적으로 생성되고 있다는 뜻입니다.

코딩 에이전트는 텍스트-투-SQL (Text-to-SQL) 벤치마크 모델과 달리 저장소(Repo)에 접근할 수 있습니다. 이전 마이그레이션을 읽을 수 있고, ORM(Object-Relational Mapping) 정의를 읽을 수 있으며, 테스트 스위트(Test Suite)를 읽을 수 있습니다. 이는 에이전트의 하한선(Floor)을 높여줍니다. 하지만 벤치마크 수치를 넘어서는 상한선(Ceiling)을 높여주지는 못하는데, 그 이유는 에이전트가 할 수 없는 부분이자 텍스트-투-SQL 모델도 할 수 없는 부분이 바로 프로덕션 잠금 그래프(Production Lock Graph)를 읽고 ACCESS EXCLUSIVE 잠금이 얼마나 오래 유지될지 추정하는 것이기 때문입니다. 그 정보는 저장소에 들어있지 않습니다.

벤치마크가 측정하는 것과 놓치는 것

위의 세 가지 벤치마크는 SQL 생성 문제의 서로 다른 단면들을 측정합니다. 하지만 그중 어떤 것도 마이그레이션이 프로덕션 환경을 중단시킬지 여부를 결정짓는 단 하나의 단면은 측정하지 못합니다.

	벤치마크가 테스트하는 것	프로덕션(Production)에서 요구하는 것
입력(Input)	스키마(Schema) + 자연어(NL) 질문	스키마(Schema) + 실시간 프로덕션 상태 + 워크로드(Workload)
...

벤치마크의 성공은 생성된 SQL이 동시 읽기 작업(Concurrent readers)이 없고, 쓰기 트래픽(Write traffic)이 없으며, 락(Lock)을 보유한 장시간 실행되는 분석 쿼리(Long-running analytical queries)가 없고, 수십억 개의 행을 가진 프로덕션 테이블(Production tables)이 없는 참조 데이터베이스(Reference database)를 대상으로 정확한 결과를 생성함을 의미합니다. 반면 프로덕션에서의 성공은 생성된 DDL이 풀 드레인(Pool drain)으로 이어지지 않는 시간 범위 내에서 ACCESS EXCLUSIVE를 획득하고, 힙(Heap)을 재작성하지 않고도 새로운 제약 조건(Constraint)을 검증하며, 반대편의 복제본(Replicas)을 건강한 상태로 유지함을 의미합니다.

벤치마크가 완벽하더라도 마이그레이션은 여전히 장애(Outage)를 일으킬 수 있습니다. Railway의 2025년 12월 8일 사고는 어떤 LLM이라도 올바르게 생성할 것이고 어떤 벤치마크에서도 성공으로 점수를 매길 ADD COLUMN (null 허용 컬럼 추가) 작업이었습니다. DDL은 정확했습니다. 장애의 원인은 waitMask 규칙이 장시간 실행되는 읽기 작업(Long-running reader)과 상호작용했기 때문입니다. NL2SQL 문헌 중에는 이를 평가하는 벤치마크가 없습니다.

시스템적 위험(Systemic-risk) 논거

세 가지 사실이 동시에 존재하며, 이들의 조합은 2026년에 새롭게 나타났습니다.

첫째, 현실적인 엔터프라이즈 SQL에 대한 프런티어 LLM(Frontier LLM)의 정확도는 10%에서 24% 사이에 머물러 있습니다. 이 수치는 다음 분기에 80%로 급등하지 않을 것입니다. Spider 1.0과 Spider 2.0 사이의 격차는 모델 세대를 거치며 지속되었으며, 각각의 새로운 벤치마크는 성능 한계치(Ceiling)를 향한 경주보다는 능력을 추적하도록 설계되었습니다.

둘째, 동일한 프롬프트를 바꾸어 말하는 것(Paraphrasing)만으로도 정확도가 10~20포인트 정도 변합니다. 에이전트에게 "sessions 테이블에 null 허용되는 archived_at 타임스탬프를 추가해줘"라고 요청하는 프로덕션 개발자와, "타임스탬프를 통해 세션을 소프트 삭제(Soft-delete)해줘"라고 요청하는 개발자는 동일한 마이그레이션을 설명하고 있는 것입니다. 한 명은 작동하는 마이그레이션을 얻게 되지만, 다른 한 명은 그렇지 못할 수도 있습니다. 팀은 어떤 재표현(Rephrasing)이 모델의 패러프레이즈 매니폴드(Paraphrase manifold)에서 정확한 쪽에 안착할지 미리 알 수 없습니다.

셋째, 코딩 에이전트(coding agents)가 측정 가능한 비율로 마이그레이션(migrations)을 작성하고 있습니다. 공개된 GitHub 커밋의 4%가 발표된 최저치이며, 대부분의 운영(production) 마이그레이션이 존재하는 비공개 저장소(private repos)의 실제 수치는 알려져 있지 않습니다. DBA 수준의 인간이 작성 루프(authorship loop)에 포함되지 않은 채 git push에 도달하는 DDL(Data Definition Language)의 인구는 2023년 이후 실질적으로 증가했습니다.

각 데이터 포인트 자체는 방어 가능합니다. AI 코딩은 유용하며, 벤치마크(benchmarks)는 벤치마크이고, 모든 ML(Machine Learning) 시스템에는 견고성 격차(robustness gaps)가 존재합니다. 하지만 이들이 결합되면 머지(merge)에 도달하는 운영 환경에 안전하지 않은(production-unsafe) 마이그레이션의 기본율(base rate)에 측정 가능한 변화를 일으킵니다. Railway의 사후 분석(post-mortems)이 공개된 이유는 Railway가 사후 분석을 작성하기 때문입니다. 동일한 패턴이 기록되지 않은 채 다른 많은 기업에서도 실행되고 있습니다.

"AI 사용을 중단하라"가 아닌 대안

연구 커뮤니티가 암묵적으로 지지하는 대응책인 "에이전트를 DDL 작성에 배치하기 전에 벤치마크가 포화될 때까지 기다려라"는 어떤 엔지니어링 조직도 채택할 정책이 아닙니다. 에이전트는 유용하고, 생산성 향상은 실재하며, 이를 포기하는 팀은 그렇지 않은 팀에게 뒤처지게 됩니다. 문제는 에이전트의 출력물과 운영 환경 사이에 어떤 검증(check)이 위치하느냐 하는 것입니다. 이 질문은 머지 시점뿐만 아니라 런타임(run time)에도 적용됩니다. 에이전트가 라이브 데이터베이스에 대해 구문을 실행할 수 있게 되면, 어떤 구문을 실행할지 결정하는 계층(layer)이 필요합니다.

풀 리퀘스트(pull-request) 시점의 락 그래프 시뮬레이터(lock-graph simulator)가 하나의 해답입니다. 이 검증 단계는 DDL이 인간에 의해 작성되었는지 에이전트에 의해 작성되었는지 알 필요가 없습니다. 제안된 DDL을 읽고, 대상 스키마(schema)에 대해 요구되는 락 레벨(lock levels)을 파싱하며, 운영 환경의 pg_locks 및 pg_stat_activity의 현재 상태를 읽은 다음, 추정된 락 윈도우(lock window)가 임계값을 초과하면 머지를 거부합니다. 이 검증은 작성자(authorship)와 무관합니다. 이 검증이 마이그레이션을 잡아내는 이유는 에이전트가 생성했기 때문이 아니라, 마이그레이션 자체가 안전하지 않기 때문입니다.

세 가지 벤치마크 실패 모드는 각각 특정 클래스의 락 그래프 누락(lock-graph miss)에 대응합니다:

Spider 2.0 enterprise complexity (기업용 복잡성): 에이전트가 수천 개의 컬럼이 있고 유용한 인덱스가 없는 테이블에 대해 조인(join)을 실행합니다. 락 시뮬레이터(lock simulator)는 순차 스캔(sequential scan)을 감지하고, 현재 트래픽 대비 ACCESS SHARE 유지 시간을 추정하여 차단합니다.
BIRD-Interact multi-turn drift (멀티턴 드리프트): 에이전트가 여러 번의 개선(refinement) 단계를 거친 후, 개발자가 요청한 것과 미묘하게 다른 DDL을 생성합니다. 즉, 메타데이터만 변경하는 방식이 아닌 힙(heap)을 다시 쓰는 ALTER TABLE을 실행하는 것입니다. 시뮬레이터는 이 재작성(rewrite)을 감지하고 차단합니다.
SQL2NL paraphrase brittleness (의역의 취약성): 동일한 개발자가 같은 질문을 두 가지 다른 방식으로 던졌을 때, 서로 다른 두 개의 마이그레이션이 생성되고 그중 잘못된 것을 병합(merge)합니다. 시뮬레이터는 프롬프트(prompt)가 아니라 DDL을 평가합니다. 이 벤치마크의 격차는 시뮬레이터에게 보이지 않습니다.

이 세 가지 중 어떤 것도 시뮬레이터에 의해 해결되지 않습니다. 첫 번째는 인덱스 설계와 테이블 아키텍처의 문제이며, 시뮬레이터는 이를 수정하려 하지 않습니다. 두 번째는 개발자가 병합 전에 차이점(diff)을 읽느냐의 문제이며, 이는 어떤 도구로도 대체할 수 없습니다. 세 번째는 프롬프트 엔지니어링(prompt engineering)의 문제입니다. 시뮬레이터가 하는 일은 SQL을 생성한 프로세스가 벤치마크에 정확하든 아니든 상관없이, 그 결과물을 가져와 운영 상태(production state)와 대조하여 평가하는 것입니다. 이 검증은 누가 DDL을 작성했는지와 관계없이 정당합니다. 그것이 핵심입니다.

이 검증이 기존 스택과 다른 이유

AI가 생성한 코드를 둘러싼 모든 기존 가드레일(guardrail)은 코드 표면(code surface)을 대상으로 합니다. 린터(Linters)는 구문 오류를 잡아냅니다. 단위 테스트(Unit tests)는 동작 회귀(behavioral regressions)를 잡아냅니다. CI는 컴파일 실패를 잡아냅니다. 이 중 어느 것도 운영 데이터베이스를 살펴보지 않습니다. 린트를 통과하고, 테스트를 통과하며, CI를 통과한 AI 작성 마이그레이션은 CI 환경이 가시성을 확보하지 못한 데이터베이스에 배포됩니다. 시뮬레이터는 기존 스택이 남겨둔 구체적인 구멍, 즉 테스트 환경이 재현할 수 없는 운영 락 그래프(production lock graph)를 메워줍니다.