LLM이 만든 SQL을 실행 전 정적 검증하기

LLM이 만든 SQL을 실행 전 정적 검증하기

LLM이 만든 SQL에 DROP TABLE이 섞여 있는 걸 실행 직전에 발견했다. 프롬프트에 “SELECT만 써”라고 지시해도 종종 무시됐다. 실행 전에 기계적으로 걸러내는 검증 레이어를 만들었다.

1. 서론 (Introduction)

• 문제/상황 (Problem): LLM이 의도치 않게 DML(INSERT, UPDATE, DELETE, DROP 등)이 포함된 SQL을 생성했다. 프롬프트 지시만으로는 100% 막을 수 없었다.
• 목적 (Purpose): SQL 텍스트를 검사해 위험한 패턴을 실행 전에 차단하고, 심각도별로 FAIL/WARN/OK를 구분한다.
• 대상 (Target Audience): LLM 생성 SQL을 자동으로 실행하는 파이프라인을 안전하게 만들고 싶은 개발자.

2. 방법 및 과정 (Methods & Process)

• 배경 조사 및 데이터 (Data Collection): 대표 SQL 4종으로 판정 로직을 검증했다.

  샘플	내용	판정
  정상 SELECT+LIMIT	SELECT id, name FROM users LIMIT 10;	OK
  LIMIT 없는 SELECT	SELECT id, name FROM users WHERE active = 1	WARN
  DELETE 포함	DELETE FROM orders WHERE id = 42;	FAIL
  세미콜론 2개 이상	SELECT 1; DROP TABLE users; SELECT 2;	FAIL

• 접근 방법 (Approach Methods):
  • [방법 1]: 정규식으로 INSERT/UPDATE/DELETE/DROP/CREATE/ALTER/TRUNCATE 키워드를 검출하면 즉시 FAIL 처리한다.
  • [방법 2]: 세미콜론이 2개 이상이면 멀티스테이트먼트로 간주해 FAIL 처리하고, SELECT인데 LIMIT 절이 없으면 WARN으로 낮춰서 통과는 시키되 로그에 남긴다.
• 분석 및 해결 프로세스 (Analysis Flow):
  • 도구/기술: Python re 모듈 기반 정규식 매칭. 별도 SQL 파서 의존성 없이 문자열 검사만으로 구현.
  • 주요 단계: DML/DDL 키워드 검출 $\rightarrow$ 세미콜론 개수로 멀티스테이트먼트 검출 $\rightarrow$ SELECT + LIMIT 유무 확인 $\rightarrow$ ("FAIL"|"WARN"|"OK", reason) 반환.
  • 결과 도출 및 검증: 4개 샘플 모두 의도한 판정(OK/WARN/FAIL/FAIL)이 그대로 나왔다. DELETE와 DROP이 섞인 멀티스테이트먼트 샘플은 DML 검출 단계에서 먼저 걸러졌다.

3. 결과 (Results)

• 분석 결과 요약: 정상 SELECT+LIMIT은 OK, LIMIT 누락 SELECT는 WARN, DELETE 포함 문장과 세미콜론 2개 이상 멀티스테이트먼트는 둘 다 FAIL로 정확히 분류됐다. DML 키워드 검출이 멀티스테이트먼트 검사보다 먼저 걸리기 때문에 위험 패턴이 섞인 경우 가장 심각한 사유로 즉시 차단된다.

4. 인사이트 및 액션 (Insights & Action)

• 인사이트 (Insight): LLM이 만든 코드는 실행 전 정적 검증이 필수다. 프롬프트 지시는 확률적이고 검증 레이어는 결정론적이다. 확률에 기대지 말고 코드로 강제해야 한다.
• 실행 방안 (Action Plan): 금지 키워드 목록과 LIMIT 임계치를 설정값으로 분리하면 코드 변경 없이 운영 환경별로 다른 정책을 적용할 수 있다.
• 한 줄 결론 (Key Takeaway): LLM 생성 SQL은 실행 전에 반드시 정적 검증을 거쳐야 한다. 프롬프트 지시만으로는 부족하다. 샘플 코드
• 다음 스텝 (Next Step): 정규식 매칭은 주석 안의 DROP이나 문자열 리터럴 안에 든 DELETE 같은 오탐에 취약하다. 토큰 타입까지 구분하는 진짜 SQL 파서로 교체해 오탐률을 낮추는 게 남은 과제다.