GCP와 AWS는 Text2SQL을 이렇게 푼다

RAG, IR, Semantic Layer로 완성된 엔터프라이즈급 해법

by 다이노

Oct 10. 2025

“지난달 매출 알려줘.” 이 단순한 말 한마디가 데이터베이스에게는 꽤 복잡한 요청이다.

AI는 이 문장을 SQL이라는 언어로 번역해야 한다.

그런데 문제는, 기업의 데이터 구조는 생각보다 훨씬 복잡하다는 것이다.

테이블이 수백 개, 이름도 제각각, 심지어 “매출”이라는 단어가 어떤 칼럼을 의미하는지도 사람마다 다르다.

그래서 Text2SQL은 생각보다 자주 틀린다.

오늘은 Google과 AWS와 같은 빅테크 들이 이 문제를 어떻게 풀어나가는지 정리해보겠다.

‘AI가 멍청해서’가 아니다.

Text2SQL이 어려운 이유는 아래처럼 단순하지 않다.

“매출”이 어떤 테이블의 어떤 열을 뜻하는지 애매하다.

“지난달”이라는 말도 날짜 포맷마다 다르다.

테이블 구조가 너무 크면 AI가 다 읽기도 전에 토큰 한도를 초과한다.

LLM은 종종 테이블 이름을 지어내기도(할루시네이션) 한다.

구글과 아마존은 AI의 성능을 높이기 보다, 실수해도 괜찮은 구조에 집중하고 있다.

문제의 해결법을 AI에서 찾는게 아닌 시스템에서 해결하는 것이다.

Google의 방식: 맥락은 줄이고, 의미를 고정하라

Google Cloud 팀이 Text2SQL을 다루는 방식을 한문장으로 하면 다음과 같다.

AI에게 모든 걸 알려주려 하지 말자. 필요한 맥락만 주자.

2_Text-to-SQL_at_Google_Cloud.max-2200x2200.jpg

Google의 Text2SQL 아키텍쳐

RAG + Schema Retrieval

AI에게 전체 데이터베이스를 보여주는 대신, 질문과 관련된 상위 몇 개 테이블·컬럼만 찾아서 준다.

그 덕분에 AI는 덜 헷갈리고, 더 빠르고 정확하게 SQL을 만든다.

Semantic Layer

“매출”, “활성 고객” 같은 비즈니스 용어를 정확한 데이터 컬럼과 연결한 semantic layer을 만들어 둔다.
그래서 AI가 테이블 이름을 추측할 필요가 없이 바로 원하는 필드를 찾을 수 있다.

Self-Repair (자가 수정)

AI가 SQL을 잘못 만들면, 시스템이 스스로 오류 메시지를 다시 AI에게 돌려보낸다.

AI는 그 피드백을 보고 쿼리를 수정한다.
“틀린 문제 다시 풀기” 하는 것과 비슷하다.

결과적으로 구글은 “LLM이 잘못될 수 있음을 전제로 설계”한 셈이다.

AI가 완벽하다고 믿지 않고, 잘못된 부분을 감싸는 구조로 신뢰성을 높였다.

AWS의 방식: AI를 ‘번역기’처럼 다루라

AWS는 훨씬 더 공학적인 접근을 택한다.
하나의 긴 파이프라인으로 Text2SQL을 처리한다.

아마존의 Text2SQL 아키텍쳐

1. 사용자가 자연어로 질문
2. 시스템이 관련 스키마와 지표를 검색 (RAG)
3. 질문이 모호하면, AI가 추가 질문을 던짐 (ex. “지난달? 어떤 지역 기준인가요?”)
4. 정리된 내용을 기반으로 프롬프트 생성
5. LLM 응답을 여러개 생성 후 가장 일관된 응답을 선택(self-consistency)
6. SQL을 실제 DB에 테스트 → 오류 발생 시 다시 수정 요청(self-repair)
7. 검증 통과 후 최종 실행