프로젝트로 돌아가기

사내·개발 중

NL2SQL Quality

일상적인 질문을 보안·자산 데이터를 조회하는 SQL로 바꾸는 사내 서비스의 품질을 개선했습니다.

사용자의 일상적인 질문을 업무용 PostgreSQL 조회 SQL로 바꾸는 사내 서비스입니다. OMNIGuard 단일 제품에서 시작해 성과를 바탕으로 다른 제품군까지 담당을 넓히며, 약 600개 테이블의 기존 화면·로그·SQL에서 정답 조건을 복원하고 답안 예시, 기본 지시, 평가 질문을 설계했습니다.

기간
2026.06 - 2026.08
담당 범위
업무 SQL 분석 · prompt 설계 · 평가
프로젝트
LSware 사내 프로젝트
저장소
비공개 리포지토리

답안 예시보다 제품의 정답부터 복원했습니다

클라론엑스는 사용자가 평소 쓰는 말로 질문하면 보안 제품과 사내 자산 정보를 찾아주는 서비스입니다. 데이터베이스 구조를 모르는 사용자에게도 현재 설치 상태와 최신 이력에 맞는 답을 돌려줘야 했습니다.

LSware에서는 먼저 OMNIGuard 단일 제품을 대상으로 답안 예시(Few-shot)를 추가하는 일을 맡았습니다. 초기 성과를 인정받아 같은 개선 과정을 다른 제품군까지 넓혔습니다. 답안 예시는 사용자의 질문과 정답 SQL을 한 쌍으로 묶어 AI에 보여주는 자료지만, 대상은 충분히 문서화되지 않은 약 600개 테이블의 업무 DB였고 어떤 테이블과 조건이 정답인지 알려 주는 자료도 정리돼 있지 않았습니다.

처음에는 어디서부터 정답을 정해야 할지 막막했습니다. SQL이 실행되더라도 삭제된 정보나 오래된 이력을 고르면 사용자에게는 오답이기 때문에, 예시를 늘리기 전에 실제 제품 동작에서 정답 조건부터 복원해야 했습니다.

답을 검증하는 흐름

모호한 질문을 검증할 수 있는 검색 결과로 바꾸는 과정

  1. 01

    사용자 질문

    같은 뜻의 다양한 표현

  2. 02

    업무 규칙

    로그·DDL·기존 SQL로 확인

  3. 03

    AI 지시와 예시

    System Prompt + Few-shot

  4. 04

    생성 SQL

    문법과 업무 의미 확인

  5. 05

    실행과 사람 검토

    PostgreSQL 결과까지 확인

정답 SQL을 공통 규칙과 질문별 패턴의 두 층으로 나눴습니다

생성된 SQL이 실행되더라도 삭제된 데이터나 오래된 이력을 고르면 업무상 오답입니다.

약 600개 테이블에서 삭제 데이터 제외, 최신 이력 선택, 읽기 전용 조건은 여러 질문에 공통이었지만 JOIN과 집계 방식은 질문마다 달랐습니다.

공통 조건은 시스템 프롬프트에, 질문별 JOIN과 집계는 Few-shot 예시에 넣었습니다. AI는 질문 후보를 만드는 데만 사용하고 정답 SQL은 기존 화면·로그·실행 결과로 사람이 확인했습니다.

  • 기존 화면에서 삭제·기간·최신 상태 조건 복원했습니다.
  • 내부 유사 작업의 30~40개 수준보다 넓은 질문–SQL 예시 약 176개와 홀드아웃 평가 80문항 작성했습니다.
  • 공통 규칙을 뺀 구성과 규칙·예시를 함께 쓴 구성을 같은 기준으로 비교했습니다.

공통 규칙이 없을 때는 기준 충족률이 약 30~40%였지만, 규칙과 예시를 함께 적용하자 정의한 80문항 모두에서 기대 SQL 기준을 충족했습니다.

예시의 개수보다 재사용할 규칙과 질문별 패턴의 경계를 나누는 일이 품질에 더 큰 영향을 줬습니다.

DDL 밖의 업무 규칙을 실행 로그에서 찾았습니다

약 600개 테이블에는 이름이 비슷한 현재·이력 테이블과 선언된 관계만으로 용도를 판단하기 어려운 구조가 있었습니다. DDL만으로는 실제 화면이 어떤 조건으로 데이터를 고르는지 확정할 수 없었습니다.

필요한 로그는 사내 Linux 환경에 있었고, 처음에는 제 계정에 접근 권한이 없었습니다. 내부 테이블명과 SQL 원문을 외부 자료에 공개할 수도 없었습니다.

조사 목적과 확인 범위를 상사에게 설명해 접근 권한을 받은 뒤, 화면 동작과 그때 기록되는 DB 로그를 연결하고 DDL·기존 SQL과 교차 확인했습니다.

  • 특정 화면 동작과 발생한 쿼리를 연결해 기록했습니다.
  • 현재·이력, 논리 삭제, 제품 설치 판별 조건 추출했습니다.
  • 확인한 근거를 데이터 모델 가이드와 인수인계 문서로 정리했습니다.

복원한 규칙은 시스템 프롬프트와 Few-shot, 평가 기준의 근거로 사용했습니다. 내부 로그 자체는 공개하지 않고 포트폴리오에는 조사 방법과 확인한 규칙의 종류만 적었습니다.

문서가 부족한 환경에서는 이상적인 구조를 추측하기 전에 실제 동작에서 확인 가능한 근거를 모아야 한다는 점을 배웠습니다.

답안 예시(Few-shot)를 약 176개 구축했고, 예시와 분리한 홀드아웃 평가 80문항 모두에서 기대 SQL 기준을 충족했습니다.

사내 프로젝트이므로 리포지토리, SQL, 프롬프트, 평가 데이터는 공개하지 않습니다.

문서가 부족할 때 이상적인 구조를 추측하기보다 로그와 실제 동작에서 근거를 찾게 됐습니다. 또한 예시를 늘리기 전에 오류 유형과 평가 기준부터 정의하게 됐습니다.

80/80은 한정된 사내 제품 범위와 평가셋에서 얻은 결과입니다. 다른 고객 스키마나 모든 자연어 질문에 대한 일반적인 정확도를 뜻하지 않습니다.

  • Few-shot과 홀드아웃 질문의 의미적 유사도를 점검하고 더 엄격한 조건에서 재평가
  • 다른 도메인에서도 같은 절차가 재현되는지 검증
  • 필요 시 실행 성공률·의미 오류·latency·cost 측정