거대 언어 모델(LLM) 에이전트가 생성한 Oracle SQL 스크립트는 서류상으로는 완벽해 보일 수 있지만, 실제 운영 환경에서는 문제를 일으킬 수 있습니다. 230만 라인 규모의 레거시 코드베이스에서, AI 기반 에이전트는 존재하지 않는 식별자를 반복적으로 포함하는 실수를 저질렀습니다. 예를 들어, 실제 STATUS_CD 컬럼 대신 POLICY_STATUS를 사용하거나, CUSTOMER 대신 존재하지 않는 CUSTOMERS 테이블을 참조하는 식입니다.

오타를 잡기 위해 UPDATE나 DELETE 문을 직접 실행하는 것은 선택지가 될 수 없습니다. 운영 환경과 유사한 데이터셋에서 이를 실행하면 락(lock)이 발생하고, 시퀀스 번호가 소모되며, 연쇄적인 부작용을 초래할 수 있습니다. 개발자에게는 데이터를 건드리지 않고 이름과 구문을 검증할 방법이 필요합니다. 놀라울 정도로 간단한 해답은 바로 Oracle의 EXPLAIN PLAN 명령어를 린팅(linting) 단계로 재활용하는 것입니다.

EXPLAIN PLAN이 빠른 검증 도구로 작동하는 방식

Oracle이 구문을 받으면 먼저 파싱(parsing)을 수행합니다. 파싱 과정에서 참조된 모든 테이블, 컬럼 및 권한의 존재 여부를 확인한 다음, 실행 계획을 수립하고 이를 시스템 테이블에 기록합니다. 이 명령은 구문을 절대 실행하지 않습니다. 즉, 행이 수정되지 않고, 트리거가 작동하지 않으며, 락도 걸리지 않습니다. 파서가 알 수 없는 객체를 발견하면 몇 밀리초 내에 오류를 발생시킵니다.

이러한 동작 덕분에 EXPLAIN PLAN은 AI가 생성한 SQL을 위한 완벽한 사전 점검(pre-flight check) 도구가 됩니다. 누락된 테이블이나 컬럼이 즉시 보고되므로, 사람이 스크립트를 확인하기 전에 생성 루프에서 오류를 수정할 수 있습니다.

CI 파이프라인에 구축한 워크플로우

  1. 들어오는 스크립트를 개별 구문으로 분할합니다.
  2. 개발 스키마를 대상으로 EXPLAIN PLAN FOR <statement>를 실행합니다.
  3. Oracle이 반환하는 모든 파싱 오류를 수집합니다.
  4. 오류를 LLM에 다시 전달하여 재시도를 요청합니다.

실제로 한 번의 재시도만으로도 대부분의 명명 오류가 해결됩니다. AI는 올바른 스키마를 학습하고 출력을 자동으로 조정합니다. 또한 에이전트를 읽기 전용 모드로 제한했습니다. SELECT와 EXPLAIN PLAN 호출은 허용하되, DDL, DML 및 COMMIT은 차단합니다. 이러한 샌드박스 환경은 AI가 데이터베이스 구조를 탐색하는 동안 데이터가 변경되지 않도록 보장합니다.

이름 확인 외에도, 생성된 실행 계획은 명백한 성능상의 위험 신호(red flags)를 드러냅니다. 구문이 대규모 테이블에서 전체 테이블 스캔(full-table scan)을 유발할 경우, 행을 건드리기 전에 계획에 나타나므로 개발자가 인덱스를 제안하거나 조건절(predicate)을 재작성할 기회를 가질 수 있습니다.

이 접근 방식의 한계

  • 논리적 정확성은 검증되지 않습니다. 올바른 컬럼을 참조하더라도 잘못된 필터를 적용하는 구문은 린팅을 통과합니다.
  • PL/SQL 블록은 범위에서 제외됩니다. 파서는 개별 SQL 구문만 처리하므로, 프로시저 코드는 별도의 검증 경로가 필요합니다.
  • 데이터 수준의 검증이 누락되어 있습니다. 린팅으로는 리터럴 값이 컬럼의 도메인에 부합하는지, 또는 외래 키(foreign-key) 참조가 실제로 존재하는지 알 수 없습니다.
  • 개발 스키마에 국한됩니다. 개발 환경에는 존재하지만 운영 환경에서는 이름이 변경된 테이블과 같이 운영 환경에서만 발생하는 오류는 나중에 발견될 때까지 보이지 않습니다.

이러한 격차가 이 방법의 유용성을 떨어뜨리는 것은 아니며, 단지 그 범위를 정의할 뿐입니다. 대부분의 LLM 생성 DML 스크립트에서 가장 흔한 실패 유형은 오타나 잘못된 객체 이름이며, EXPLAIN PLAN은 바로 그 부분을 잡아냅니다.

다른 데이터베이스 엔진으로의 이식성

동일한 원리가 Oracle 이외의 엔진에도 적용됩니다. PostgreSQL의 PREPARE 문이나 EXPLAIN은 실행 없이 쿼리를 파싱할 수 있습니다. SQL Server는 실제 처리를 건너뛰면서 구문과 객체 이름을 검증하도록 엔진에 강제하는 SET PARSEONLY ON을 제공합니다. 파싱과 실행을 분리하는 모든 RDBMS는 가벼운 린팅 게이트가 될 수 있습니다.

요약

모든 AI 생성 SQL 구문에 EXPLAIN PLAN(또는 그에 상응하는 명령)을 실행하면 데이터베이스 파서를 저비용의 위험 없는 린팅 게이트로 바꿀 수 있습니다. 데이터가 이동하기 전에 가장 빈번한 명명 및 구문 오류를 잡아냄으로써, 레거시 시스템의 안정성을 유지하는 동시에 개발자가 LLM 지원 코딩을 통한 생산성 향상을 누릴 수 있게 해줍니다.