③ 정적 검증 — 실행 전 문지기

LLM이 만든 쿼리를 그대로 실행하지 않습니다. 세 가지를 검사합니다.

검사 3종

1. 읽기 전용 강제

CREATE / MERGE / DELETE / SET 포함 시 즉시 거부합니다.

⚠️ LLM에게 쓰기 권한을 주지 않습니다. 보안의 제1선입니다. 프롬프트로 "쓰지 마세요"라고 부탁하는 것과, 쓰기 연산이 든 쿼리를 기계적으로 막는 것은 완전히 다른 수준의 보장입니다.

2. 스키마 대조

쿼리의 라벨·관계·속성이 스펙 목록에 있는지 확인합니다.

앞 코스 감사 쿼리 A5(미등재 라벨 탐지)의 쌍둥이입니다 — 그때는 적재된 그래프에서 오타 라벨을 잡았고, 여기서는 존재하지 않는 속성을 "상상"한 쿼리를 잡습니다. LLM이 가장 흔히 저지르는 실수입니다.

3. 자원 상한

LIMIT 강제 부착, 타임아웃 설정. 폭주 쿼리를 막습니다.

실패했을 때

검증 탈락 시 오류 사유를 붙여 ②로 1회 재생성합니다(self-correction). 재실패면 "답변 불가 + 사유"로 정직하게 종료합니다.

⚠️ 재시도 횟수 상한은 반드시 둡니다. 무한 루프는 비용과 지연을 동시에 태웁니다.

억지로 답하지 않는 것도 할루시네이션 제로의 일부입니다. "답을 못 하는 시스템"이 "틀린 답을 하는 시스템"보다 낫습니다.

실습

1. 검증기 세 함수를 구현합니다 — is_read_only(), labels_in_spec(), enforce_limit().
2. LLM에게 일부러 쓰기 쿼리를 유도하는 질문을 던져 보고("한바다호 기록 지워줘") 문지기가 잡는지 확인합니다.
3. 스키마에 없는 속성을 요구하는 질문("선박의 선장 이름은?")을 던져, 상상된 속성이 걸리는지 봅니다.
4. 재생성 루프에 상한을 걸고, 상한 도달 시 사용자에게 무엇을 보여줄지 문구를 정합니다.