260개 테이블 중 6개 선택: 텍스트에서 SQL로의 테이블 선택 함정

배경

텍스트에서 SQL로의 시스템은 자연어를 쿼리로 바꿔준다는 강한 인상을 주지만, 실제 배포에서는 거의 아무도 글로 남기지 않는 한 단계가 숨겨져 있습니다. 모델이 어떤 SQL을 생성하기 전에, 시스템은 먼저 그 모델이 어떤 표를 볼 수 있는지 결정해야 합니다. 실제 데이터베이스는 260개의 표를 담고 있을 수 있고, 프롬프트 창에 모든 스키마를 넣을 수 없을 뿐만 아니라 넣어야 할 수도 없습니다. 표를 억지로 채워 넣으면 모델의 주의가 희석되고 지연 시간과 비용이 높아지기 때문입니다. 따라서 시스템은 생성 전에 소수의 후보 표로 좁혀야 합니다.

이 필터링 단계는 거의 항상 검색 문제로 다뤄집니다. 각 표의 스키마를 벡터 임베딩으로 인코딩하고, 사용자 질문으로 그 임베딩을 질의한 뒤 유사도로 란킹한 후 상위 6개의 표를 선택합니다. 이 파이프라인은 데모 환경에서 적절한 성능을 보이는데, 여기서의 스키마는 대체로 정돈되고 이름이 명확하며 깨끗합니다. 질문이 표 이름에 직접 매치되므로 검색의 자연 히트율이 높게 유지되고, 산업계는 이 문제가 이미 해결된 것처럼 조용히 가정해 왔습니다.

심층 분석

저자는 이런 데모 수준의 자신감과 생산 수준의 취약성 사이의 간격을 인지했고, 의도적으로 그 메커니즘을 깨도록 설계된 스키마를 만들어 자신의 라이브러리로 실행했습니다. 결과는 공개하고 싶지 않을 정도의召回 수치였고, 그 수치는 가장 가치 있는 발견으로 드러났습니다. 핵심 문제는 검색의 관련성이 쿼리의 정확성과 같지 않다는 것입니다. RAG 방식의 표 선택은 질문 텍스트와 스키마 사이의 의미적 유사도에 의존하지만, SQL은 실제로 표와 쿼리 의도 사이의 논리적 도달 가능성을 요구합니다.

어떤 표는 이름이나 필드에서 질문과 전혀 공유하지 않더라도 정답에 필수적일 수 있습니다. audit_log라고 이름 붙은 표를 예로 들어みましょう. 이번 달 비밀번호를 변경한 사용자가 몇 명인지에 대한 질문에 답하기 위해, 실제 정답은 user_actions 표에서 action_type이 7로 하드코딩된 레코드에 달려 있을 수 있습니다. 그런데 password나 change라는 단어는 스키마에 전혀 등장하지 않습니다. 텍스트 유사도 검색은 주저 없이 이를 배제합니다. 반대로 이름에 우연히 키워드가 겹치는 표는 순수한 노이즈일 수 있습니다. 외키 관계에서는 상황이 더 악화되는데, 정답은 종종 여러 표를 조인해야 하고, Top-K 검색은 각 표를 독립적으로 채점하여 이웃에 대해 아무것도 알지 못합니다. 따라서 표 A와 함께 표 B를 선택해야 한다는 구조적 종속성을 감지할 수 없습니다.

산업 영향

이 발견은 수많은 기존 텍스트에서 SQL로의 제품의 암묵적 전제를 무너뜨립니다. BI와 데이터 분석 도구를 만드는 회사에게 표 선택은 최종 정확성을 결정하는 상류 게이트입니다. 이 게이트가 실패하면 하류의 SQL 생성이나 오류 수정으로는 회복할 수 없고, 사용자는 그저 자신이 정답 가능한 질문에도 답하지 못하는 시스템을 볼 뿐 그 이유도 이해하지 못합니다.

중소기업과 내부 도구 팀은 특히 노출되어 있습니다. 그들의 데이터베이스는 종종 혼란스러운 명칭, 무거운 역사적 baggage, 매우 은밀한 의미론을 가지고 있어, 의도적으로 깨진 스키마가 가장 잘 작동하는 조건이기 때문입니다. 데모 성능과 실제 경험 사이의 거치는 눈부시게 됩니다. 개발자 커뮤니티에게 이 분석은 모델이 충분히 큰지, 프롬프트를 어떻게 써야 하는지라는 화제에서 벗어나 스키마 검색과 조직화 자체라는 더 근본적이고 덜 연구된 공학적 관심으로 주의를 환기시킵니다.

전망

주목할 몇 가지 방향이 있습니다. 가장 중요한 것은 조인 관계, 제약 조건, 필드 값 분포 정보를 검색에 반영할 수 있는지 여부인데, 이는 텍스트 유사도에만 의존하지 않고 현재 한계를 깨는 열쇠가 될 수 있습니다. 두 번째 질문은 의도적으로 만든 트랩 스키마를 사용해召回의 진짜 하한을 측정하는 전문 평가 벤치마크가 나타날지 여부입니다. 세 번째는 하이브리드 검색과 재정렬이 구조적 종속성을 진짜로 해결할 수 있는지, 예를 들어 먼저 대략적으로 필터링한 뒤 그래프 구조를 활용해 관계를 확장하는 방식입니다.

텍스트에서 SQL로의 시스템을 구축하거나 선택하는 팀에게 가장 실용적인 방법은 데모 스키마 지수를 결론으로 간주하는 것을 멈추는 것입니다. 대신 자신의 데이터베이스 실제 복잡도와 일치하는 데이터로 표召回를 실행하고, 필요한 표가 단순히 선택되지 않을 때 엔드투엔드 정확성이 얼마나 떨어지는지 관찰해야 합니다. 그 수치는 어떤 모델 벤치마크보다 더 많은 것을 말해줍니다.