Feyn AI의 SQRL — 데이터베이스를 먼저 살피는 Text‑to‑SQL 모델

SQRL 한 줄 요약: SQL을 쓰기 전에 DB를 본다

기존 Text-to-SQL(자연어를 SQL로 변환) 시스템은 대부분 "번역"처럼 다룹니다. 사용자의 한국어/영어 질문을 SQL 한 줄로 옮기는 것이 전부입니다.

Feyn AI(Y Combinator 투자사)는 이 관점을 바꿉니다. 자연어 질문을 SQL로 바꿔주는 모델 패밀리 SQRL(SQRL, "Squirrel")을 공개했습니다. SQRL의 핵심 아이디어는 단순합니다. 쿼리를 만들기 전에 데이터베이스를 점검(inspect)하라는 것입니다. 모호한 부분을 미리 확인하고, 실제 데이터가 답할 수 있는 질문만 SQL로 만듭니다.

플래그십 모델 SQRL-35B-A3B는 BIRD Dev 벤치마크에서 실행 정확도(execution accuracy) 70.6%를 달성했습니다. 같은 환경에서 평가한 Claude Opus 4.6의 68.77%를 살짝 앞섭니다. SQRL-4B, SQRL-9B, SQRL-35B-A3B 세 체크포인트가 모두 Hugging Face에 오픈 라이선스로 공개되어 있습니다.

왜 "맞는 SQL"이 "틀린 답"을 내는가

SQL은 문법적으로 완벽해도 결과가 틀릴 수 있습니다. 흔한 실패 사례를 보면:

• 잘못된 테이블을 조인해 행이 중복되거나 누락됨
• 컬럼 이름은 맞지만 의미가 다른 열을 사용함
• 실제 저장값과 다른 값으로 필터링 (예: "Alameda" vs "Alameda County" vs "ALAMEDA")
• 어떤 조인이 1:N 관계인지 모르고 합계를 잘못 계산함

BIRD 벤치마크(Benchmark for BIrd)는 이런 종류의 실패를 측정하도록 설계됐습니다. 실제 도메인 데이터베이스에 일부러 불완전한 값, 모호한 열, 미묘한 관계를 섞어 놓았습니다. 평가는 SQL을 실제로 돌려서 반환된 행(row)이 정답과 같은지 비교합니다. SQL 구문이 옳은지는 중요하지 않습니다. 결과가 같은지가 점수입니다.

Feyn 팀의 결론은 이렇습니다. 답을 모르는 정보가 이미 데이터베이스 안에 있다. 모델에게 "물어볼 권한"만 주면 된다.

SQRL의 작동 방식: 두 가지 액션, 다섯 번의 점검

SQRL은 입력을 받습니다.

1. 사용자의 자연어 질문
2. 데이터베이스 스키마(테이블·컬럼 정보)
3. (선택)질문에 대한 단서(evidence)

이 정보로 충분히 답할 수 있으면 곧바로 최종 SQL을 내보냅니다. 여전히 애매한 부분이 남아 있으면, 읽기 전용(read-only) 쿼리를 실행해 결과를 확인한 뒤 최종 SQL을 작성합니다. 점검할지 말지는 모델이 스스로 결정합니다. "단일 테이블 행 개수 세기"처럼 단순한 질문은 즉시 답하고, 컬럼 의미가 모호한 질문은 먼저 살펴봅니다.

두 가지 액션 태그

SQRL이 출력하는 응답에는 두 종류의 블록이 등장합니다.

• <sql> 블록 — 데이터베이스에 observation(관찰 결과)을 요청
• <answer> 블록 — 최종 SQL을 확정(commit)

하네스(harness, 실행 환경)는 <sql> 블록을 read-only 모드로 실행하고, 반환된 행들을 <observation> 태그로 감싸 모델에 다시 돌려줍니다. 이 과정을 최대 다섯 번까지 반복할 수 있지만, 대부분의 질문은 그보다 적은 단계에서 끝납니다.

두 전통적 전략을 한 모델에 합치다

Text-to-SQL에는 두 가지 전통적 흐름이 있었습니다.

• Single-shot 모델: 한 번에 SQL을 끝까지 만듭니다. 빠르고 저렴하지만, 모든 걸 스키마만으로 추론하니 논리 오류가 숨어듭니다.
• Frontier 파이프라인: 컨텍스트를 검색하고, 후보 SQL 여러 개를 생성·비평해 고릅니다. 정확도는 높지만 질문마다 비싼 모델을 여러 번 호출해야 해서 핫 패스(실시간 경로)에 두기 어렵습니다.

SQRL은 이 둘을 하나의 모델에 합칩니다. 쉬운 질문은 짧게 가고, 애매한 질문만 점검 비용을 치릅니다. 즉, 비용은 필요한 만큼만 발생합니다.

"언제 점검할지"를 어떻게 학습시켰나

모델에게 DB 접근 권한을 줬다고 해서 알맞게 사용하지는 않습니다. 점검 행동 자체를 따로 학습시켜야 했습니다. Feyn 팀은 다음 절차를 따랐습니다.

1단계. 데이터 정제

BIRD와 Spider 학습 데이터에서 시작해, 참조 정답 SQL이 실행 자체를 실패하는 예제를 제거했습니다. 그다음 세 개의 모델 judge가 남은 쌍을 검토해, "질문 그대로는 답할 수 없는" 쿼리(예: 정답이 NULL인 경우)를 걸러냈습니다. 테스트용 분할은 held-out Spider와 BIRD dev를 합쳤고, 나머지는 학습에 사용했습니다.

2단계. 35B Teacher를 CISPO로 직접 학습

35B-A3B teacher 모델은 CISPO(Clipped Importance Sampling Policy Optimization)라는 강화학습 방법으로 훈련됐습니다. CISPO는 일반적인 정책 비율(policy ratio)이 아니라 중요도 샘플링 가중치(importance-sampling weights)를 클리핑하는 방식입니다. 드물지만 결정적인 토큰의 학습 신호를 잘 보존하는 것이 특징입니다.

각 질문당 8개의 trajectory(전체 시도)를 생성하고, 모든 최종 SQL을 실행해 정답과 결과가 일치하면 보상을 줬습니다. 표현이 다르든 같든, 반환된 행이 같은지만 보는 이진(binary) 신호입니다.

3단계. "혼합 영역"에서만 학습

그룹 상대 정책 최적화는 그룹 안에 정답·오답이 섞여 있어야 신호가 생깁니다. 8개가 전부 정답이거나 전부 틀린 시도는 학습에 도움이 안 됩니다. 그래서 Feyn은 8개 중 일부만 성공한 "혼합 영역(mixed zone)" 샘플에서만 학습했습니다. 이로써 teacher 모델은 "어떤 결정이 도움됐는지"를 명확히 구분할 수 있었습니다.

4단계. Distillation으로 작은 모델 만들기

배포를 위해 teacher의 전체 trajectory(추론 과정 + 탐색 쿼리 + observation + 최종 SQL)를 샘플링하고, 최종 SQL이 올바른 결과를 낸 실행만 골라 약 10,200개 예제를 만들었습니다. 4B와 9B 학생 모델은 이 trajectory로 fine-tune된 뒤, 동일한 CISPO 실행 보상으로 한 번 더 다듬었습니다. SQRL의 베이스 모델은 Qwen3.5 / Qwen3.6 계열입니다.

성능 비교: BIRD Dev 실행 정확도

아래는 Feyn 팀이 보고한 BIRD Dev 실행 정확도입니다. 평가 방식은 동일하게 "참조와 같은 결과를 반환하면 정답"입니다.

특히 주목할 점은 4B 모델이 68.80%로 Opus 4.6과 동률이라는 사실입니다. 이 정도 크기는 일반 GPU 한두 장으로도 자체 호스팅이 가능해서, 스키마·쿼리·observation이 모두 사용자 인프라 안에서 처리됩니다. 데이터가 외부로 나가지 않는 환경을 만들 수 있다는 뜻입니다.

직접 써보기: vLLM으로 SQRL-9B 서빙

Feyn 팀은 용도별 권장 체크포인트를 이렇게 안내합니다.

• SQRL-9B — 기본 추천 (정확도·비용 균형)
• SQRL-4B — 가장 빡빡한 예산, 자체 호스팅 우선
• SQRL-35B-A3B — 최고 정확도

9B 모델은 오픈소스 서빙 라이브러리 vLLM으로 띄울 수 있습니다.

vllm serve feyninc/sqrl-9b \
  --served-model-name sqrl-9b \
  --gpu-memory-utilization 0.90 \
  --max-model-len 32768

애플리케이션 루프 요약

1. DB 실행은 항상 read-only로 유지 (INSERT/UPDATE/DELETE 차단)
2. 모델이 <answer>를 내기 전까지 각 <observation>을 모델에 다시 전달
3. 최대 5번까지 점검 반복 허용

자주 묻는 질문 (FAQ)