TL;DR
이 글은 LLM에 데이터베이스 스키마를 제공해 자연어 질의를 자동으로 SQL로 변환하고 read-only로 실행해 결과를 사람이 읽기 쉬운 문장으로 반환하는 내부용 질의 봇 아키텍처를 제안한다. 핵심은 run_query 같은 단일 도구 호출 인터페이스를 통해 모델과 DB 실행 지점을 분리하고, DB 수준의 읽기 전용 권한과 프롬프트 내 민감정보 금지 규칙으로 안전성을 확보하는 것이다. 비용 절감을 위해 스키마 정리, 투패스 축약, 쿼리 및 프롬프트 캐싱을 권장하며, 작성자는 이 프로토타입을 하루 만에 구현했다고 밝힌다.
섹션별 상세
- 전체 구현은 하루 만에 가능했다. — 저자가 'All in all, the entire implementation took one day'라고 직접 기술한 문장과 개발자가 AI가 코드를 많이 작성해 준 덕분이라고 밝힌 서술.
pg_dump -W --schema-only mydatabase > schema.sql이 명령은 데이터베이스의 스키마만 추출해 파일로 저장하는 초간단 절차를 수행한다. 스키마 파일을 LLM에 제공하면 테이블 구조와 컬럼 타입을 모델이 참고하므로 잘못된 컬럼명을 사용한 쿼리 생성 확률이 떨어진다. 운영 비용을 낮추려면 인덱스·제약·주석 같은 불필요한 메타데이터를 제거해 전달하는 것이 권장된다.
- LLM은 데이터베이스 스키마를 제공하면 SQL을 정확히 생성할 수 있다. — 글의 핵심 통찰 섹션과 실행 예시: pg_dump로 스키마 추출 후 Claude/ChatGPT에 업로드해 'Write a query to find all users who signed up last week' 같은 질의를 테스트하라고 권장함.
SELECT s.id, s.title, s.price_currency, s.price, s.store_id FROM public.listings_list s WHERE s.active = 1 AND s.visibility = 1 AND s.state = 0 ORDER BY s.price DESC NULLS LAST LIMIT 5이 쿼리는 현재 유효한 목록 중 가격 상위 5건을 추출하는 예시로, run_query 도구에 전달될 형태를 보여준다. 프롬프트 예제에서는 모델이 스키마를 참고해 정확한 테이블명과 컬럼명을 사용하도록 유도하며 결과는 다시 LLM에 의해 사람이 읽기 쉬운 문장으로 포맷된다. 실무에서는 LIMIT와 정렬 기준, NULL 처리 등 세부 조건을 명확히 하는 것이 중요하다.
WITH spans AS ( SELECT a.id, a.created, (a.created + (a.duration || ' hours')::interval + a.extra_time) AS ends_at FROM public.auctions_auction a ) SELECT COUNT(*) AS count FROM spans WHERE now() >= created AND now() < ends_at경매가 현재 진행 중인지 계산하려면 created와 duration, extra_time을 합쳐 ends_at을 만든 뒤 now()와 비교하는 패턴이 필요하다. 이 WITH 절 예시는 비즈니스 로직을 SQL로 직접 표현해 모델에게 복잡한 상태 계산을 맡길 때 유용한 템플릿 역할을 한다. 프롬프트에는 이런 비즈니스 규칙을 사전에 명시해야 모델이 올바른 집계와 필터를 생성한다.
- 운영 환경에서는 DB 수준의 읽기 전용 권한, 프롬프트 제한, 쿼리 검증 같은 안전 장치가 필요하다. — Safety Measures 섹션에서 read-only DB 사용자 생성, 프롬프트 내 민감정보 비공개 지시, SELECT 전용 허용 등 구체적 조치를 나열한 부분.
용어 해설
- run_query 도구(run_query)
- — LLM이 생성한 SQL 문자열을 전달받아 데이터베이스에서 읽기 전용으로 실행하고 결과를 반환하는 단일 함수 인터페이스를 가리킨다. 입력은 SQL 쿼리 하나뿐이고 출력은 행/열 형태의 결과이므로 AI와 외부 DB 간 호출 표준을 단순화한다. 이 방식은 모델이 직접 DB를 수정하지 못하도록 제약을 걸고 호출·로깅 지점을 중앙화하기 때문에 운영 환경에서 안전성을 높인다.
- 스키마 덤프(schema.sql)
- — pg_dump 같은 도구로 데이터베이스 스키마만 추출한 파일로, 테이블·컬럼·타입 정보를 LLM에 제공해 정확한 SQL 생성 품질을 높인다. 불필요한 인덱스·제약·주석을 제거하면 컨텍스트 길이를 크게 줄여 토큰 비용을 절감할 수 있다. 질문에 필요한 테이블만 골라 재전송하는 방식으로 비용과 응답 속도를 개선할 여지가 있다.
- 프롬프트 수준 제한 규칙(Prompt-level restrictions)
- — AI에게 허용되는 쿼리 패턴과 금지 항목을 명시하는 규칙 셋으로, 예컨대 SELECT만 허용하고 비밀번호·토큰·해시 같은 민감정보를 절대 반환하지 못하도록 지시한다. 모델이 DB 스키마와 함께 이 규칙을 받으면 생성된 SQL의 안전성과 적합성이 향상된다. 운영 단계에서는 프롬프트와 실행 전후의 검증을 결합해 방어 깊이를 늘릴 필요가 있다.
- 투패스 접근(Two-pass approach)
- — 첫 번째 패스에서 질의와 연관된 테이블 목록만 식별하고 두 번째 패스에서 해당 테이블들만 포함한 축약된 스키마로 정교한 SQL을 생성하게 하는 전략이다. 전체 스키마를 매번 전송하는 대신 관련 범위를 좁혀 토큰 사용량과 비용을 줄인다. 자주 묻는 질문 패턴이 반복될 때 캐싱과 결합하면 비용 효율성이 크게 개선된다.
기술
- PostgreSQL
- pg_dump
- Claude
- ChatGPT
활용 사례
- 고객지원팀이 간단한 사용자·주문·리스트 조회를 직접 수행하도록 하여 개발자 의존도를 낮출 수 있다. 자연어로 질의를 입력하면 시스템이 SQL을 생성해 결과를 반환하므로 비기술직도 데이터 접근성이 개선된다. 이 방식은 실시간 운영 데이터 확인이나 빠른 지표 확인에 유용하다.
- 비즈니스 규칙이 복잡한 집계나 상태 계산을 LLM이 생성한 SQL로 자동화해 시간 소모적인 수동 조사를 줄일 수 있다. 예를 들어 경매의 진행 여부나 특정 카테고리의 활성 리스팅 집계처럼 여러 컬럼을 계산해 판단해야 하는 작업에 적합하다. 다만 민감정보는 반환하지 않도록 규칙을 엄격히 적용해야 한다.
- 자주 반복되는 조회 패턴을 캐싱하면 호출 비용을 줄이고 응답 시간을 개선할 수 있다. 스키마 축소와 투패스 접근을 결합하면 토큰 사용량을 상당히 낮출 수 있으며, 운영 모니터링·리포트용 쿼리 템플릿으로 활용하면 효율성이 올라간다.
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
