엔터프라이즈 환경을 위한 Workflow
* 지난 글
: LLM System Design: 엔터프라이즈 규모에서 고려해야 할 핵심 요소들
https://brunch.co.kr/@dr-jenna/12
자연어로 입력된 질문을 SQL 쿼리로 변환하는 NL2SQL(Text-to-SQL) 기술은 엔터프라이즈 데이터 활용에서 중요한 역할을 한다. 사용자는 복잡한 데이터베이스 스키마를 몰라도 자연어로 질의할 수 있고, 시스템은 자동으로 올바른 SQL을 생성해 실행한다. 그러나 이를 정확하고 안정적으로 구현하기 위해서는 단순한 LLM 서빙 이상의 아키텍처적 고민이 필요하다. 이번 글에서는 NL2SQL 시스템 설계 시 고려해야 할 워크플로우와 핵심 전략을 살펴본다.
NL2SQL 시스템의 비기능 요구사항은 다음과 같다.
- 지연 시간(latency): SQL 생성 및 실행까지 몇 초 이내로 완료되어야 한다.
- 처리량(throughput): 동시에 다수의 사용자 요청을 처리할 수 있어야 한다.
- 정확도(accuracy): 스키마 링크(schema linking)와 SQL 생성이 정확해야 한다.
- 확장성(scalability): 수백 개 테이블, 수천 개 컬럼을 가진 대규모 데이터베이스를 다룰 수 있어야 한다.
사용자 쿼리 입력
쿼리 리라이트 및 키워드 분석
의도 분석 → chit-chat, 일반 질의, NL2SQL task로 라우팅
임베딩: rewritten query 임베딩
테이블 선택(Table selection): Faiss 기반 dense search, Euclidean distance 계산
컬럼 선택(Column selection): 동일 방식으로 후보 컬럼 추출
Few-shot 예제 선택: 유사 쿼리–SQL 쌍 검색 (dense search)
SQL 생성: vLLM 기반 코드 특화 LLM으로 SQL 생성
SQL 검증: syntax 및 semantic 체크
SQL 실행: DB에서 실행
폴백(Fallback): 실패 시 SQL 재생성 (최대 N회)
NL2SQL에서는 세 가지 인덱스를 별도로 관리한다.
Table Index: table name, columns, row count, primary key, foreign keys, DDL, sample rows
Column Index: table name, column name, data type, numeric ranges, PK 여부, FK 여부, top-k frequent values(enum)
Few-shot Index: table name, natural language query, correct SQL
입력 데이터: Excel 파일(샘플 데이터), 각 테이블 DDL, few-shot examples, gold standard set
전략: Schema-aware retrieval & generation
모델: vLLM 기반 코드/SQL 특화 LLM
서비스: FastAPI App Server
데이터 파이프라인: Datalake/S3 → Airflow → DB rebuild + schema analysis → index 생성
모니터링: MLflow 기반 학습/평가 추적
Execution accuracy: SQL 실행 결과와 ground truth 결과 비교
Schema linking accuracy: 테이블/컬럼 매핑 정확도 평가
스키마 검색 최적화: Table/Column/Few-shot 인덱스 별도 관리, 후보 수 축소, FK 그래프 기반 프루닝.
병렬 검색: 테이블/컬럼/샷 검색을 동시에 처리하고 SLA 초과 시 빠른 타임아웃 적용.
쿼리 실행 최적화: SQL 파서/AST 검증으로 빠른 실패 감지, 실행 결과 캐시, 자주 쓰는 쿼리 머티리얼라이즈드 뷰.
LLM 효율화: 불필요한 스키마 정보 제거 후 최소 컨텍스트 투입, speculative decoding, 구조화 출력(JSON/AST).
운영 측면: 독립적인 오토스케일링(table/column/few-shot 백엔드 vs LLM 서빙), 멀티 리전 DB 리플리카 운영.