LLM SQL 자동화에 AST 검증 게이트를 두는 법

LLM에게 “이번 달 데이터를 요약할 SQL을 만들어 줘”라고 맡기고 자동 실행까지 연결하면, 파라미터화만으로는 충분하지 않아요. 파라미터화는 WHERE id = ?처럼 값이 쿼리 문법을 바꾸지 못하게 막습니다. 하지만 모델이 DELETE, DROP, 다른 테이블 조인처럼 쿼리의 구조 자체를 바꾸는 문제까지 막지는 못해요.

직접 만들어 보니, 자동화의 경계는 SQL 문자열을 받는 지점이 아니라 실행을 허용하는 지점에 두는 편이 이해하기 쉬웠어요. 모델은 초안을 만들고, 워크플로우는 검증하고, 데이터베이스는 검증을 통과한 요청만 실행하는 구조예요.

LLM SQL 초안→AST 파싱→정책 검증→파라미터 바인딩→실행

AST(Abstract Syntax Tree)는 SQL을 단순 문자열이 아니라 명령, 테이블, 열, 조건식으로 나눈 구조예요. 그래서 SELECT만 허용할지, 접근 가능한 테이블을 3개로 제한할지, LIMIT를 필수로 할지 같은 규칙을 코드로 확인할 수 있어요.

테스트해 보면 첫 번째 게이트는 문법 파싱이에요. 파싱에 실패한 SQL은 실행하지 않습니다. 두 번째 게이트에서는 statement가 정확히 1개인지 확인해요. 세 번째 게이트에서는 허용한 명령이 SELECT 하나인지 검사할 수 있어요. 네 번째 게이트에서는 테이블과 열 이름을 허용 목록에 대조합니다.

적용해 봤더니 프롬프트에 “조회만 생성하세요”라고 쓰는 것보다 정책이 훨씬 명확해졌어요. 프롬프트는 모델의 행동을 유도하지만, AST 검증은 실행 경로를 실제로 차단해요. 둘은 대체재가 아니라 역할이 달라요.

n8n에서는 AI 노드 뒤에 코드 노드나 별도 검증 API를 두는 방식으로 구성할 수 있어요. 검증 결과는 allow, reason, normalizedSql처럼 3개 필드로 남기면 실패 원인을 추적하기도 편합니다. allow가 거짓이면 다음 데이터베이스 노드로 넘기지 않는 흐름이에요.

• ✓파라미터화는 값 보호
• ✓AST는 구조 검증
• ✓실행 권한은 별도 정책

돌려 보니 중요한 점은 허용 목록을 처음부터 넓게 잡지 않는 것이었어요. 필요한 테이블 1개와 조회 명령 1개로 시작한 뒤, 실제 업무 요청이 생길 때마다 규칙과 테스트를 함께 추가하는 편이 안전합니다. 라이프케어로그에서 플랜씨(plan-c)처럼 로그인 없이 계산 결과를 다루는 도구를 만들 때도, 자동화가 다루는 데이터 범위와 실행 권한을 분리해 두면 운영 판단이 단순해져요.