NL-SQL 성능이 80%면 충분할까?

자연어로 질문하면 SQL을 자동으로 생성해주는 NL-SQL은 정형 데이터 분석과 BI 환경에서 반드시 필요한 기술입니다. 이때 자주 등장하는 질문이 있습니다. “정확도 80%면 실무에서 쓸 만하지 않을까?”

겉으로 보면 꽤 높은 수치처럼 보입니다. 하지만 실제 업무 시나리오를 기준으로 보면, 이 80%는 결코 안전한 숫자가 아닙니다. 예를 들어 특정 업무에서 자주 쓰이는 NL-SQL 질의 유형이 10개 있다고 가정해 봅시다. NL-SQL 정확도가 80%라는 것은 10개 중에서 8개는 정확한 결과를 반환하지만, 2개는 미묘하게 잘못된 결과를 반환한다는 것을 의미합니다. 문제는 이 20%의 오류가 조용히 섞여 들어간다는 것입니다. 

이 경우 이 시스템을 과연 '성공적'이라고 말할 수 있을까요? AI가 확률적인 결과를 제시한다는 것을 고려하면, 서비스 목적에 따라 80%는 적합할 수도 있고 부적합할 수도 있다는 것입니다. 특히 매출, 실적, 운영 지표처럼 의사결정에 직접 영향을 주는 데이터라면, 일부라도 틀릴 가능성이 있다는 사실 자체가 시스템에 대한 신뢰를 무너뜨립니다. 그래서 NL-SQL에서는 '대부분 맞는다'가 아니라, '항상 맞는다'에 가까운 결과가 요구됩니다.

이 글에서는 왜 NL-SQL에서 80% 정확도가 실패에 가까운지, 그리고 어떻게 하면 특정 Use Case 안에서 100%에 수렴하는 성능을 만들 수 있는지 현실적인 접근 방법을 살펴보겠습니다.

NL-SQL

1. NL-SQL 성능이란?

NL-SQL에서 말하는 성능은 하나로 정의하기 어렵습니다. 하지만 일반적으로 다음 세 가지 관점에서 생각해 볼 수 있습니다. 

첫째, Exact Match입니다. 생성된 SQL 문장이 정답 SQL과 문자 단위까지 동일한지를 보는 방식이라고 할 수 있습니다. 아마도 이것은 크게 중요하지 않습니다. 사람마다 SQL 구문을 작성 방식은 다르더라도, 정확한 결과만 반환하면 되기 때문입니다.

둘째, Execution Accuracy입니다. SQL 문장은 달라도 실행 결과가 동일한 레코드 집합을 반환하는지를 평가하는 것이라고 할 수 있습니다. 많은 NL-SQL 평가가 Execution Accuracy를 주로 강조합니다. 하지만 이것만으로는 부족한 경우가 많습니다.

셋째, Business Correctness입니다. 업무 규칙과 비즈니스 의미를 반영했을 때, 결과가 실제 의사결정에 맞는지를 보는 기준이라고 할 수 있습니다. 실제 업무 규칙이 반영되지 않은 '맞는 결과'는 비즈니스적으로 틀릴 수 있기 때문입니다.

결국 NL-SQL의 현실적인 목표는 Execution Accuracy + Business Correctness를 동시에 만족하는 것이라고 할 수 있습니다. 이 기준에서 80% 정확도란, 곧 20% 확률로 비즈니스적으로 잘못된 결과를 보여준다는 의미가 됩니다.

2. NL-SQL은 왜 80%에서 멈출까?

LLM이 NL-SQL에서 틀리는 이유는 SQL 문법을 몰라서가 아닙니다. 대부분의 오류는 질문하는 자연어의 애매함과 스키마·업무 의미에 대한 오해에서 발생한다고 할 수 있습니다. 

예를들어 “지난달 매출”을 구하는 것을 생각해 봅시다. 이 한 문장 안에는 다음과 같은 해석 포인트가 숨어 있습니다.

• 주문일 기준인가, 결제일 기준인가?
• 총매출인가, 순매출인가?
• 환불과 취소는 포함하는가?

이 기준이 명확하지 않은 상태에서 모델이 SQL을 '추측'으로 생성하면, 어떤 날은 맞고 어떤 날은 틀리는 결과가 나올 수 밖에 없습니다. 이것이 바로 NL-SQL이 80% 수준에 머무는 구조적 이유라고 할 수 있습니다. 따라서 NL-SQL 성능을 100%에 가깝게 만들기 위해서는, 표현의 다양성을 허용하되 해석 기준은 고정하는 설계가 필요합니다.

3. NL-SQL 성능을 100%에 수렴시키는 현실적인 방법

1) 비즈니스 규칙을 담은 Semantic Layer 활용

대부분의 NL-SQL 질의는 비즈니스 로직을 전제로 합니다. 하지만 원천 DB 스키마는 조인이 복잡하고, 업무 규칙이 코드나 문서에 흩어져 있는 경우가 많습니다. 이 상태에서 LLM이 원천 테이블을 직접 다루게 하면 오류 가능성이 급격히 높아집니다. 이때 필요한 것이 'Semantic Layer(의미 계층)' 입니다. Semantic Layer는 비즈니스 규칙을 반영한 전처리 테이블이나 뷰로, NL-SQL이 복잡한 스키마가 아니라 정의된 의미를 조회하도록 돕는 역할을 합니다.

예를 들어 매출 계산의 경우, 주문·결제·환불 테이블을 그대로 쓰면 쿼리마다 기준이 달라질 수 있습니다. 반면 net_revenue와 같은 Semantic Layer를 만들어 환불, 취소, 테스트 주문 제외 규칙을 고정하면, “지난달 매출”, “저번 달 실적”, “지난달 얼마 팔았어?”라는 질문이 모두 동일한 결과로 이어질 수 있습니다. Ontology 기반 Knowledge Graph 역시 같은 맥락의 접근이라고 할 수 있습니다. Semantic Layer는 결국 데이터 분석을 위한 비즈니스 기준정보라고 볼 수 있다.

2) 유형별 질의 구조화

대부분의 경우 특정 도메인에서는 질문 유형이 반복됩니다. 매출 조회, Top-N 분석, 기간 비교, 세그먼트 분석 등이 그 대표적인 예라고 할 수 있습니다.

이런 경우 자연어를 그대로 SQL로 생성하기보다는, 질의 의도를 먼저 분류하고, 다음으로 기간/지표/기준값을 추출한 뒤, 마지막으로 검증된 SQL 템플릿에 슬롯을 채우는 방식이 효과적입니다. 예를들어 "Top 10 상품"이라는 질문을 자유 생성 방식으로 처리하면, 어떤 쿼리는 매출 기준, 어떤 쿼리는 수량 기준으로 실행될 수 있습니다. 이것이 또 다른 80% 문제를 만듭니다.

반면 구조화된 접근에서는 다음과 같이 구조화된 템플릿을 활용하면 좋습니다.

• 의도: TOP-N 조회
• 기준: 기간 = 지난달, 지표 = 매출, N = 10
• SQL: 검증된 템플릿 사용

이렇게 하면 표현은 자유롭지만, 결과 기준은 흔들리지 않습니다.

3) 애매한 질문에는 반드시 되묻는 루프 설계

100%에 가까운 성능을 원한다면, LLM이 추측으로 바로 실행하는 것은 최소화해야 합니다. 기준이 불분명한 질문이 들어오면, 실행하지 말고 짧게 되묻는 전략을 포함해야 합니다.

• “주문일 기준으로 볼까요, 결제일 기준으로 볼까요?”
• “환불은 포함할까요?”

이 되묻기 과정은 귀찮아 보일 수 있습니다. 하지만 이는 '그럴듯하지만 틀린 결과'를 제거하거나 '모호한 결과'를 방지하는 가장 강력한 안전장치라고 할 수 있습니다. 조용히 섞여 들어가는 20%의 오류를 없애는 비용이라고 생각하면, 충분히 감수할 만합니다.

결론

특정 Use Case에서 NL-SQL 질의 10개 중 8개만 맞는다면, 그 시스템은 20%의 침묵하는 오류를 품은 위험한 시스템이라고 할 수 있습니다. 반대로 범위를 명확히 정의하고, 의미를 고정하고, 애매함을 제거하며, 검증과 운영 루프를 갖춘다면 NL-SQL은 특정 업무 영역에서 사실상 100%에 가까운 성능에 도달할 수 있습니다.

그리고 그 지점에서야 비로소 NL-SQL은 단순한 편의 기능이 아니라, 의사결정을 맡길 수 있는 데이터 인터페이스가 됩니다.