구글 리서치가 공개한 Gemini-SQL2가 BIRD 텍스트-투-SQL 벤치마크에서 실행 정확도 80.04%로 1위에 올랐다. OpenAI의 GPT-5.5-xhigh가 약 72.8%, Anthropic의 Claude Opus 4.6이 약 70.9%, Databricks·AWS·Tencent·Alibaba의 모델들이 그 뒤를 한참 떨어진 채 따라간다. 베이스 모델은 Gemini 3.1 Pro다. 상위 LLM끼리 보통 1~3%p 안에서 엎치락뒤치락하는 벤치마크 환경에서 7~10%p의 격차는 흔치 않다.
BIRD가 까다로운 이유는 단순한 문법 매칭이 아니라 "생성된 SQL을 실제로 실행했을 때 정답 데이터가 나오는 비율"을 측정한다는 데 있다. 데이터가 여러 층으로 쌓여 있고, 쿼리에 비즈니스 로직과 도메인 규칙이 섞여 있을 때 LLM이 가장 잘 무너지는 구간이다. 구글 리서치는 "형태만 맞는 SQL이 아니라 실제로 실행되어 의도한 결과를 내는 SQL"이라는 표현을 강조했는데, 이는 사내 데이터 어시스턴트를 운영해본 팀이 가장 민감하게 듣는 표현이기도 하다.
묘하게 인상적인 건 자체 데이터 웨어하우스 진영의 위치다. Databricks와 AWS는 SQL이 가장 무거운 워크로드인 플랫폼을 들고 있고, 텐센트·알리바바도 거대한 사내 데이터를 보유하고 있다. 그런데 이번 리더보드에서는 일반 LLM 베이스를 깐 구글이 압도적으로 앞섰다. 데이터 인접성이 곧 SQL 추론 품질로 직결되지 않는다는, 그리고 모델 품질에서 한 번 벌어진 격차는 도메인 친화성만으로 좁히기 어렵다는 신호다. 구글이 이 기술을 자사 데이터 서비스 전반의 자연어 기능 강화에 쓰겠다고 명시한 점도 같은 맥락에서 읽힌다. BigQuery 콘솔이나 Looker 같은 분석 스택 안에 자연어 인터페이스를 기본 탑재하기 위한 사전 빌드업으로 보면 들어맞는다.
다만 차분히 짚어야 할 부분도 분명하다. 모델은 비공개고, 페이퍼도 아직이다. 외부에서 검증할 수 있는 건 리더보드 숫자 한 줄이다. BIRD가 산업 스키마에 가깝게 설계됐다고는 해도, 실제 사내 데이터 웨어하우스의 dbt 모델 수천 개, 의미가 흐릿한 컬럼 네이밍, 깨진 외래키, 부분 인덱스 같은 노이즈는 또 다른 게임이다. 결제·재무처럼 오답 비용이 큰 도메인에서는 80%라는 수치 자체가 자율 실행을 정당화하지 않는다. 그럼에도 이번 결과는 의미가 크다. 지난 2년간 "데모는 멋지지만 운영은 안 된다"의 대표 사례였던 text-to-SQL이 처음으로 "사람이 매번 다시 짜는 단계"를 넘어선 임계점에 들어섰고, 데이터팀의 가치 무게중심이 쿼리를 짜는 일에서 모델이 짠 쿼리를 검증·관측하는 일로 옮겨가는 흐름을 가속할 전환점이다.