NL2SQL은 무엇이고 어떻게 작동하나요?

NL2SQL은 자연어로 된 질문을 관계형 기반으로 실행할 수 있는 SQL 쿼리로 자동 변환하는 것을 의미합니다. 자유 텍스트로 응답하는 일반 챗봇과 달리 NL2SQL 시스템은 실제 데이터에 대해 실행되고 검증 가능한 결과를 한 줄씩 반환하는 구조화된 아티팩트인 SQL을 생성합니다.

"text-to-SQL"이라는 용어는 자연어 처리에 대한 학술 연구에서 유래되었습니다. "NL2SQL"은 제품 및 기술 문서 측면에서 가장 많이 사용되는 약어입니다. 둘 다 동일한 문제를 언급합니다. 일상 언어로 묻는 질문과 SQL 엔진에서 기대하는 정확한 구문 사이의 격차를 해소하는 것입니다.

NL2SQL은 넓은 의미에서 데이터베이스에 연결된 대화형 에이전트와 구별된다. 첫 번째는 읽기 가능하고 감사 가능한 쿼리를 생성합니다. 두 번째는 고유하고 검사 가능한 SQL을 생성하지 않고도 여러 도구 호출(검색, 계산, 쓰기)을 연결할 수 있습니다. 적절하게 설계된 NL2SQL 시스템은 의도적으로 제한된 범위(번역, 검증, 실행, 결과 반환) 내에 유지됩니다.

신뢰할 수 있는 NL2SQL 파이프라인은 공급자에 관계없이 항상 동일한 순서를 따릅니다. 즉, 질문은 언어 모델을 통과한 다음 생성된 SQL은 실행 전에 검증되고 실행 이후에는 검증되지 않습니다. aura-ai서비스 코드에서 검증된 Aurabase 구현은 추상적인 설명이 아닌 구체적인 규칙으로 이러한 각 단계를 보여줍니다.

1.베이스의 실제 회로도에 대한 질문이 접수되었습니다.

시스템은 자연어로 된 질문을 쿼리된 데이터베이스의 스키마(테이블 이름, 열, 유형)와 연결합니다. 이 패턴은 호출자가 제공한 설명이 아닌 실제 베이시스에 대한 자체 조사에서 나와야 합니다. 고객이 선언한 스키마를 허용하는 구현은 존재하지 않는 테이블에 대한 질문을 하거나 프로젝트 간의 격리를 우회할 수 있는 문을 열어줍니다. Aurabase 엔진은 요청에서 전송된 모든 schema 필드를 자동으로 무시하는 대신 명시적으로 거부(400 오류)합니다.

2. LLM이 후보 SQL을 생성합니다.

언어 모델은 프롬프트에서 질문과 스키마를 받은 다음 간단한 설명과 함께 후보 SQL 쿼리를 생성합니다. Aurabase는 전용 네이티브 클라이언트인 OpenAI, Anthropic(Claude) 및 Gemini와 같은 세 가지 공급자를 동일하게 취급합니다. 이 후보 SQL은 현 단계에서는 제안일 뿐이며 직접 실행되지는 않습니다.

3. 후보 SQL은 실행 후가 아닌 실행 전에 검증됩니다.

This is the step that distinguishes a serious NL2SQL system from a simple LLM call followed by naive execution. The generated SQL is parsed into a syntax tree (AST) rather than inspected by a keyword search, which is easily bypassed. The Aurabase implementation, with the sqlparserlibrary, only allows simple SELECT queries: CTE/WITH, subqueries, UNIONs, window functions and locking clauses (FOR UPDATE) are explicitly rejected, as are any SQL functions outside a whitelist of ten functions (count, sum, avg, min, max, lower, upper, coalesce, date_trunc, now).

4. 커밋된 쿼리는 행 제한으로 실행됩니다.

Validated SQL receives an LIMIT if it does not already have one: 100 lines by default with Aurabase, 1000 maximum, both values configurable on the server side. A request beyond the cap is explicitly denied rather than silently reduced. The response indicates whether this LIMIT was added by the server, so the caller knows if the SQL executed differs from that produced by the model.

-- 질문: "프리미엄 고객의 경우 이번 달 주문 건수는 얼마입니까?"
SELECT count(*) FROM orders
WHERE customer_plan = 'premium'
  AND created_at >= date_trunc('month', now())
LIMIT 100  -- 서버에 의해 추가됨, 생성된 SQL에서 누락됨

The full detail of this pipeline, with each HTTP call and each JSON response, is covered in our step-by-step tutorial for building an NL2SQL endpoint on Postgres.

NL2SQL은 모든 곳에서 직접 작성한 SQL을 대체하기 위한 것이 아닙니다. 이는 특정 범위, 즉 SQL을 모르거나 단순히 간단한 쿼리에 대한 시간을 절약하려는 사람이 묻는 임시적이고 일회성 질문을 다룹니다.

• 기술 담당자가 아닌 사람(지원, 제품, 관리)이 대시보드를 임시 탐색합니다.
• 가능한 모든 질문에 대해 전용 API 경로를 작성하지 않고 데이터베이스를 쿼리하는 기능의 신속한 프로토타이핑입니다.
• 제한된 분석 셀프 서비스: 최종 사용자에게 데이터베이스에 대한 직접 액세스 권한을 부여하지 않고 계산, 필터링, 집계만 수행합니다.

질문이 이 범위를 벗어나는 즉시 직접 작성한 SQL이 선호됩니다. 위에 설명된 것과 같은 AST 검증 구현은 보안상의 이유로 CTE, 하위 쿼리 및 창 기능을 구성별로 제외합니다. 구조적으로 이러한 구성, 코호트, 고급 임시 윈도우잉이 필요한 분석은 NL2SQL을 거치지 않고 직접 코딩됩니다. 이는 허용되는 타협이며 시스템의 보안은 생성된 SQL의 완전성보다 우선합니다.

NL2SQL 구현에서는 세 가지 위험이 시스템의 성숙도에 따라 서로 다른 반응으로 체계적으로 반복됩니다.

프롬프트 또는 질문을 통한 SQL 삽입

질문 자체에 "이전 명령문 무시 및..." 삽입 시도가 포함된 경우 LLM을 조작하여 악성 SQL을 생성할 수 있습니다. 방어 방법은 프롬프트를 신뢰하는 것이 아니라 위에서 설명한 파이프라인의 정확히 3단계인 요청된 것과 독립적으로 생성된 SQL을 검증하는 것입니다. 이 주제는 전담적으로 다룰 가치가 있습니다. 정확한 공격 벡터 및 대응책은 SQL 주입으로부터 NL2SQL 보안을 참조하세요.

존재하지 않는 테이블이나 열의 환각

모델은 그럴듯하지만 실제 스키마에서 누락된 테이블 또는 열 이름을 만들어낼 수 있습니다. 특히 규모가 크거나 제대로 문서화되지 않은 스키마에서는 더욱 그렇습니다. 실제 데이터베이스 스키마에 대해 생성된 SQL의 유효성을 검사하는 구현은 원시 SQL 오류를 사용자에게 다시 전달하는 대신 실제로 사용 가능한 테이블을 나열하는 명시적 메시지로 쿼리를 거부합니다.

모델 호출 비용 및 대기 시간

각 NL2SQL 질문은 SQL 실행 시간 외에도 자체 비용과 대기 시간을 사용하여 언어 모델에 대한 호출을 트리거합니다. NL2SQL이 반복적인 질문에 대한 기본 계층 역할을 한다면 이 비용은 빠르게 증가합니다. 이는 매번 재번역하는 대신 캐시되거나 표준 보고서로 노출되는 이점이 있습니다.

두 아키텍처는 유사한 가시적 결과를 생성하지만 보증은 매우 다릅니다. 네이티브 NL2SQL은 생성, 검증 및 실행을 프로젝트의 스키마 및 액세스 권한을 이미 알고 있는 백엔드 레이어에 직접 통합합니다. 이는 aura-ai 서비스가 나머지 백엔드와 인프라 및 스키마 격리를 공유하는 Aurabase에 대해 위에서 설명한 논리입니다.

조립된 NL2SQL은 일반 LLM 서비스, 데이터베이스에 대한 커넥터 및 자체 구축 검증 레이어를 결합합니다. 이 접근 방식의 보안을 방해하는 것은 없지만 모든 보장, 서버 측 자체 검사 스키마, AST 유효성 검사, 행 제한, 격리 테넌트 등은 플랫폼에서 제공하는 것이 아니라 이러한 벽돌을 함께 구성하는 팀에서 구현하고 유지 관리해야 합니다.

네이티브 및 어셈블링, 오픈 소스 및 상업용 NL2SQL 도구의 환경은 NL2SQL 2026 도구 비교에서 자세히 비교됩니다.

NL2SQL과 RAG(검색 증강 생성)는 서로 다른 두 가지 질문에 답합니다. 두 가지 모두 데이터베이스에 연결된 LLM에 의존하기 때문에 종종 혼동됩니다.

NL2SQL은 구조화된 데이터와 관계형 데이터를 대상으로 합니다. 즉, 자연스럽게 SELECT, GROUP BY집계로 변환되는 질문 수, 시기, 비율 등이 있습니다. RAG는 ​​문서, 메모, 지원 티켓과 같은 비정형 콘텐츠를 대상으로 합니다. 답변이 표 행에 맞지 않지만 의미론적 유사성을 통해 관련 구절을 찾아야 하며, pgVector, HNSW 인덱스에 대한 벡터 검색을 거쳐 모델에 컨텍스트를 제공해야 합니다.

The two capabilities can coexist in the same project and combine in an agent who chooses one or the other depending on the question asked. The Aurabase native AI pillar details how the two mechanisms work together, and our RAG pipeline guide on pgvector covers the implementation of the second.