4B 모델이 Postgres 쿼리 플랜을 81% 이겼다 — 조건을 읽어야 하는 수치

결론부터: 수치는 진짜다. 단 “최대 15개 후보 중 최고”다

“4B 파라미터 모델이 짠 쿼리 플랜이 Postgres 플래너보다 81% 빠르다”는 문장이 돌고 있습니다. 이 수치는 지어낸 것이 아닙니다. 원문 제목이 그대로 「Postgres보다 81% 빠른 쿼리 실행 계획을 생성하도록 4B 모델 훈련하기」이고, 본문은 같은 값을 기하평균 1.81배 가속으로도 적습니다(1.81배 가속 = 81% 빠름, 같은 말입니다). 총 실행 시간은 44.7% 줄었습니다.

근거도 빈약하지 않습니다. 모델은 Qwen 3.8 4B-Distill, 벤치마크는 IMDb 기반 Join Order Benchmark 113개 쿼리, 방법은 pg_hint_plan으로 조인 순서와 스캔 방식을 바꿔 실제 실행 시간을 재는 방식입니다. 실험 코드도 qorl 저장소에 공개돼 있습니다.

이 81%는 쿼리 하나마다 최대 15개 계획을 만들어 그중 제일 빠른 것을 고른 값입니다. 조건을 떼고 인용하면 숫자만 남고 비용이 사라집니다.

다만 숫자가 맞다고 해서 그대로 갖다 쓸 수 있는 것은 아닙니다. 원문도 이 점을 스스로 밝힙니다 — 제목의 81%는 세 번의 실행에서 최대 15개 후보를 시험하고 그중 고른 계획의 성능입니다. 운영에서 쿼리 하나에 15번 실행을 태울 수 있는지가 곧 재현 가능성을 가릅니다. 그래서 아래에서는 이런 주장을 받았을 때 조건을 확인하는 절차와 그때 필요한 도구를 정리합니다.

헷갈리기 쉬운 또 다른 81%

같은 “81”이 전혀 다른 맥락에서도 돌아다닙니다. Spring 공식 블로그의 LLM-as-a-Judge 글(Christian Tzolov, 2025년 11월 10일)은 정교한 심판 모델이 사람의 판단과 최대 85%까지 일치하며, 이는 사람끼리의 일치도인 81%보다 높다고 적고 있습니다.

주의할 점은 이 85%/81%가 텍스트 응답 품질 평가의 일치율이라는 것입니다. 쿼리 실행 속도와는 단위도 대상도 다릅니다. 두 숫자가 같은 81이라고 해서 하나가 다른 하나의 출처라고 단정할 수는 없고, 그렇게 추정할 근거도 이 글에는 없습니다. 다만 같은 숫자가 다른 맥락에서 재사용되고 있지 않은지 의심하는 것이, 수치를 검증하는 가장 싼 첫 단계입니다.

소형 모델 성능 주장 검증 3단계

1단계 — 재현 가능한 좌표가 있는가

논문 링크, 리포지토리, 실행 명령, 데이터셋 이름 중 최소 두 개가 있어야 합니다. “포럼에서 본 수치”, “어떤 트윗에 따르면” 은 원자료가 아니므로 숫자 자체를 옮기지 않는 편이 안전합니다.

2단계 — 비교군의 조건을 맞췄는가

쿼리 플랜 비교라면 통계 정보(ANALYZE) 최신 여부, 인덱스 구성, 캐시 워밍업, 동일 하드웨어가 전제입니다. 이 중 하나만 어긋나도 수십 퍼센트는 쉽게 흔들립니다. 플래너를 이겼다는 주장은 대개 플래너가 불리한 상태로 실행됐는지부터 봐야 합니다.

3단계 — 비결정성을 어떻게 처리했는가

LLM 출력은 비결정적입니다. Spring 블로그가 지적하듯 ROUGE·BLEU 같은 전통 지표는 맥락 있는 응답 평가에 부족하고, 사람 평가는 비싸고 느리며 확장되지 않습니다. 그래서 같은 프롬프트를 N회 반복해 분산을 함께 보고하지 않은 단일 수치는 신뢰 구간이 없는 값입니다.

로컬에서 소형 모델을 직접 돌려 재현하려는 개발자라면 OS 단위 대응 일정도 같이 챙기는 편이 좋습니다. 더 자세한 내용은 iOS 27·macOS 27 총정리 — 2026년 9월 개발자가 지금 대응할 것을 참고하세요.

검증용 스택: 무엇을 붙일 것인가

직접 재현하려면 (1) 모델을 굴릴 경로, (2) 출력 품질을 자동 채점할 평가 계층, (3) 반복 실행 인프라가 필요합니다. 선택지별 용도와 주의점입니다.

선택지	무엇에 쓰나	구매 포인트	추천 대상	주의점
오픈소스 사전학습 LLM(셀프호스팅)	4B급 소형 모델을 직접 로드해 플랜 생성 재현	라이선스 비용 없이 가중치 확보 — 가성비 관점에서 출발점	사내 데이터를 외부로 못 보내는 팀	모델 자체는 무료여도 GPU·운영 인력은 비용
매니지드 LLM API	비교군 대조용 상위 모델 호출	무료 체험 구간이 있는지 결제 전 확인	인프라 없이 며칠 안에 결론이 필요한 팀	토큰 과금이라 반복 N회 실행 시 비용 급증
자체 평가 계층(LLM-as-a-Judge)	응답 품질을 코드로 채점·회귀 테스트	Spring AI Recursive Advisors처럼 예제 구현이 공개된 프레임워크를 고를 것	JVM 기반 백엔드를 이미 쓰는 팀	심판 모델도 틀린다 — 사람 검수 표본 필요
상용 LLM 평가 SaaS	대시보드·추적 일괄 제공	할인 조건과 로그 보관 정책을 계약 전 확인	평가 파이프라인을 만들 여력이 없는 팀	프롬프트·출력이 외부에 저장됨

왜 오픈소스 경로가 먼저인가

Salesforce 블로그(2024년 5월 13일)는 모델을 처음부터 학습시키는 대신 사전학습된 오픈소스 LLM을 쓰는 쪽이 대다수 기업에 더 합리적인 선택이라고 정리합니다. 근거로 드는 것은 높은 학습 비용, 법무 승인 절차, 확장·갱신의 어려움, 환경 부담입니다. 핵심은 밑바닥부터 학습하지 않고도 자사 데이터를 얹어 커스터마이즈할 수 있다는 점입니다. 쿼리 플랜처럼 스키마 의존도가 극단적으로 높은 작업일수록, 범용 대형 모델보다 자사 스키마·통계를 컨텍스트로 넣은 소형 모델이 유리할 여지가 있습니다. 다만 이것은 구조적 가능성이지 측정된 결과가 아니므로, 도입 전 반드시 자체 워크로드로 재확인해야 합니다.

가장 추천하는 조합

조건이 “사내 DB 스키마를 외부로 보낼 수 없고, 주장을 직접 재현해야 한다”라면 오픈소스 사전학습 모델 셀프호스팅 + 자체 LLM-as-a-Judge 평가 계층 조합이 맞습니다. 모델 가중치에 라이선스 비용이 들지 않아 반복 실행 비용을 GPU 시간으로 고정할 수 있고, 평가 계층을 코드로 두면 같은 측정을 몇 번이든 재현할 수 있기 때문입니다.

반대로 “일주일 안에 도입 여부만 판단하면 된다”면 매니지드 API로 소규모 대조만 돌리고, 결과가 유의미할 때 셀프호스팅으로 넘어가는 순서가 낭비가 적습니다. 어느 쪽이든 먼저 확인할 것은 모델이 아니라, 그 81%라는 숫자가 어떤 조건에서 나왔는지입니다. 조건을 못 찾으면 그 수치는 도입 근거로 쓰지 마세요.

참고 자료

– Postgres보다 81% 빠른 쿼리 실행 계획을 생성하도록 4B 모델 훈련하기 (GeekNews)
– polyphilz/qorl — 실험 코드
– 3 Reasons an Open-Source LLM is an Easier Path for your Business
– LLM Response Evaluation with Spring AI: Building LLM-as-a-Judge Using Recursive Advisors