Text to SQL이 왜 잘 안될까? ~ Giljae Joo (주길재)

LLM(Large Language Model)의 등장으로 데이터 접근 방식도 변해야 한다고 생각한다. 데이터베이스 분야외에 다른 분야는 LLM을 위한 변화가 이미 시작되었다.

프론트엔드 관점에서는 Perplexity, GPT 검색과 같은 AI 에이전트 및 스크래퍼를 지원하기 위해 명확한 제목, 구조화된 섹션, 풍부한 스니펫을 통해 "LLM 검색"이 가능하도록 설계되어가고 있다.

AI가 콘텐츠를 더 효과적으로 요약, 추출을 할 수 있게 하기 위함이다.

백엔드 관점에서는 백엔드에서 만들어지는 API 디자인은 AI 에이전트가 분석하고 사용할 수 있도록 명확한 주소와 메타데이터를 갖춘 MCP과 같은 프로토콜로 전환되고 있다.

프론트엔드, 백엔드를 지나 이제 데이터베이스의 차례이다.

레거시 데이터베이스에서 작업한 경험이 있으신 분들은 아마 알고 있을 것이다. 데이터베이스는 자가 설명적이지 않다. 데이터베이스의 스키마를 보고 무엇을 의미하는지 알기가 어렵다.

Fullname이라면 유추할 수 있지만, 축약어를 사용한다면 더더욱 판단하기가 어렵다.

예를 들어, order라는 테이블이 있다고 하면 이 테이블이 고객의 주문서를 담고 있는 것인지, 구매 주문서인지 이름만 봐서는 판단하기 어렵다. 이는 데이터베이스가 안고 있는 오래된 문제이다.

이제는 LLM이 데이터베이스에서 제공하는 맥락만으로 데이터에 대한 이해를 해야 한다. 사람도 헷갈리는데 혼란스럽지 않을까?

여기서 "Text to SQL"의 허점이 발생한다. 지금은 사용자가 자연어를 사용하여 데이터를 뽑는 시대가 열리고 있다.

"지난 분기 각 매장의 총 수익을 보여주세요." 라고 질문을 하면,

위에 맞는 적절한 SQL 쿼리를 실행하고 그 결과를 차트에 표시해야 한다. 이런 상황을 고려하지 않은 LLM 태생 이전에 디자인한 데이터베이스로 이 질문에 대한 정확한 SQL을 만들 수 있을까?

생각보다 이 문제는 어려운 문제이다.

누군가는 이렇게 얘기할 수 있다. LLM에 데이터베이스의 전체 스키마를 전달하고, SQL 쿼리를 생성하도록 요청하면 되지 않느냐고...

테이블 이름, 컬럼명 그리고 관계에 대한 정보가 있어도 LLM은 사용자의 질문에 정확하게 답변하는 SQL쿼리를 생성하지 못할 수 있다.

대부분의 데이터베이스 스키마에서 테이블과 컬럼명은 그 자체로 설명적이지 않기 때문이다. 때로는 개발자 조차도 스키마 이해에 어려움을 겪기 때문에 AI가 이해할 수 있을 것이라고 기대할 순 없다.

위에서 언급한 대로 고객 주문과 구매 주문이 각각 어떤 테이블에 있는지 이해하지 못하면 파악할 수 없다. 이 상황은 데이터베이스가 클수록 상황은 더 나빠진다.

일반적인 코드 생성 문제와는 달리 이 문제는 단순하게 텍스트 설명에서 코드를 생성하는 것 이상이다. 모델은 데이터베이스 구조, 데이터 유형, 테이블 간의 관계 등을 알고 있어야 하기 때문이다.

비즈니스의 전문화된 용어를 데이터베이스의 구조로 번역하는 방법에 대해 모델을 훈련시켜야 할 수 도 있다. 모델이 전반적인 비즈니스를 이해하고, 데이터 구조를 이해한 상태에서 사용자의 질문에 답할 수 있어야 하는 경우가 대부분이기 때문이다.

어떤 상황에서 LLM이 힘들어하는지 살펴보자.

LLM은 필드 이름의 의미가 중요하다. 이름이 모호하면 추측하게 되고, 잘못된 이해를 할 수 있다. 예를 들어 "가치"라는 필드가 있으면, 이 필드는 "원화"라는 의미도 담고 있어야 한다. "가치_원" 으로 표현되어야 LLM이 이해할 수 있을 것이다.

일관된 데이터 형식도 중요하다.
"구매날짜 = 2025-09-18"
"주문날짜 = 2025/09/18"

위 처럼 데이터 형식이 서로 다르면, 일관된 형태로 답을 하기가 어렵다.

그리고 회사내부에서 사용하는 용어, 지표, 명명 규칙을 LLM은 알지 못한다.

1. 재구매 고객: 최소 3개월 이상 구매한 고객
2. 이탈 고객: 3개월 이상 로그인을 안한 고객

회사내에서는 위 용어에 대해 정의를 내렸지만, 데이터베이스에서는 해당 데이터가 존재하지 않는다. 여러 데이터를 기반으로 애플리케이션 계층에서 계산을 해야 하기 때문이다.

이럴 경우 LLM은 추론할 수 없다. 이런 용어의 논리를 명확하게 정리하지 않으면, LLM은 올바른 의견을 낼 수 없다.

반면, LLM의 등장 이전에 우리가 해왔던 것들을 생각해보자.

이전 글에도 작성했지만, SQL과 코드에서 필드 이름을 축약어를 선호했기에 짧은 이름을 주로 사용한다. 가독성보다 최적화를 선택했다.

여러가지 이유, 제약이 있을테고, 이는 타당한 엔지니어링 결정일 수 있지만 스키마를 의미적으로 추론하기 어렵게 만든 것은 사실이다.

그럼 우리는 앞으로 어떻게 해야 할까?

MCP 스타일 표준 관점에서 접근을 해야 할 것이다. 기계가 이해할 수 있는 친화적인 스키마 설계가 필요하다.

즉, 데이터베이스를 설계하는 방식에 변화가 필요하다. 아래처럼 우선 시작해봐야하지 않을까?

끝으로, Text to SQL에서 질의에 대한 답이 이상하다면, LLM의 문제로 바라볼 것이 아니라. 스키마 설계를 의심해야 한다. 우리는 LLM을 염두해서 설계하지 않았기 때문이다.

Text to SQL에서 정확도를 높이려면 시스템이 접근할 수 있는 정보의 범위를 좁히는 것도 중요하다. 성공적인 Agent는 엄격한 범위 설정이 중요하다. 정확성이 입증된 후에만 확대하는 것이 효과적이다.

다음 글에서는 스키마 설계에 대한 부분을 다룰 생각이다.

Giljae Joo (주길재)