QORL, 데이터베이스 튜닝도 RL 문제가 됐다

Postgres보다 빠른 플랜을 학습한 4B 모델

Rohan Bansal의 QORL 실험은 작지만 의미가 크다. 4B급 Qwen 파생 모델을 쿼리 최적화 에이전트로 훈련해, join이 많은 SQL 워크로드에서 Postgres 기본 실행 계획보다 빠른 후보를 찾게 했다. 글의 핵심 수치는 1.81배 기하평균 속도 향상, 전체 워크로드 지연 44.7% 감소다. 제목의 81% faster가 과장이 아니라면, 이는 범용 챗봇의 문제가 아니라 특정 운영 환경에 맞춘 실행 전략 학습의 문제다.

Postgres 최적화기는 수십 년 동안 다듬어진 시스템이다. PostgreSQL 문서의 GEQO 설명이 보여주듯, 조인 수가 늘면 탐색 공간은 폭발하고 플래너는 동적 계획법과 유전 알고리즘으로 후보를 줄인다. QORL은 플래너를 대체하기보다 pg_hint_plan 같은 힌트와 실제 실행 측정을 이용해, 반복 실행되는 쿼리에 대해 더 나은 길을 찾는다. AI가 장애를 고칠수록 엔지니어는 멀어진다, SWE-2가 말하는 코딩 모델의 비용 전선, Qwen 3.8, 추론 프리필이 드러낸 증류의 그림자와 이어지는 질문은 하나다. 모델이 코드를 넘어서 운영의 선택지를 직접 최적화할 수 있는가.

왜 쿼리 최적화가 에이전트 과제인가

쿼리 최적화는 정답을 한 번 맞히는 문제가 아니다. 같은 SQL이라도 데이터 분포, 캐시 상태, 조인 순서, 인덱스, 동시 실행 환경에 따라 결과가 흔들린다. QORL 글은 Join Order Benchmark 논문, pg_hint_plan, Prime Intellect prime-rl, GRPO 논문 같은 도구와 연구를 엮어 에이전트 학습 루프를 만들었다.

핵심은 보상 설계다. 후보 플랜이 Postgres 기본 플랜보다 빠르면 강화하고, 기본 플랜을 반복하거나 유효하지 않은 힌트를 내면 감점한다. 하지만 실행 시간 측정에는 노이즈가 있다. 그래서 QORL은 동일 쿼리의 여러 실행을 비교하고, 5% 이하 차이는 보수적으로 다루며, Linux page cache와 Postgres shared buffers가 만드는 흔들림까지 점검한다. 개발팀 입장에서는 모델보다 실험 하네스가 더 중요한 사례다.

한국 기업에 중요한 이유

국내 서비스의 데이터 비용은 눈에 잘 보이지 않는다. GPU 비용은 주목받지만, 매일 반복되는 리포트 쿼리, 추천 후보 생성, 정산 배치, 로그 분석 SQL도 인프라 예산을 먹는다. QORL식 접근은 대규모 모델을 새로 사는 이야기보다 현실적이다. 이미 있는 Postgres, DuckDB, Spark, ClickHouse 환경에서 반복 워크로드를 모으고, 측정 가능한 보상 함수를 두고, 작은 모델이 힌트나 실행 옵션을 제안하게 만들 수 있다.

다만 이 방식은 운영 자동화의 유혹을 동반한다. 모델이 우연히 빠른 플랜을 찾았다고 곧바로 프로덕션에 넣으면 데이터 분포가 바뀐 날 장애가 난다. Read the Docs DDoS, AI 크롤러 시대의 인프라 경고가 인프라 압력을 말했고, QORL은 내부 데이터 계층의 압력을 말한다. 정답은 에이전트가 아니라, 재현 가능한 벤치마크와 롤백 가능한 배포다.

쿼리 플랜은 에이전트 제품의 좋은 시험대다

코딩 에이전트는 결과가 코드 리뷰로 검증된다. 쿼리 플랜 에이전트는 더 냉정하다. 빨랐는지, 틀렸는지, 비용이 줄었는지가 숫자로 남는다. 그래서 이 영역은 에이전트 평가의 좋은 시험대가 된다. 기업은 "모델이 그럴듯한 설명을 했는가"보다 "동일 데이터와 동일 제한 조건에서 측정 가능한 개선을 만들었는가"를 물어야 한다.

QORL이 보여준 방향은 모델 규모 경쟁과도 다르다. 4B 모델이 특정 도메인에서 훈련되고, 더 큰 모델의 추론 흔적과 실제 실행 보상을 받아, 작은 운영 자동화기로 바뀐다. 이는 에이전트 경제가 거대한 범용 모델 호출만으로 굴러가지 않는다는 신호다.

자주 묻는 질문

Q1: QORL은 Postgres를 대체하나요?

A: 아닙니다. Postgres 플래너 위에서 후보 실행 계획을 찾고 측정하는 접근에 가깝습니다.

Q2: 왜 4B 모델이라는 점이 중요한가요?

A: 특정 업무에 맞춘 작은 모델이 반복 운영 작업에서 경제성을 가질 수 있음을 보여주기 때문입니다.

Q3: 프로덕션에 바로 쓸 수 있나요?

A: 바로 쓰기보다는 읽기 전용 반복 쿼리, 배치, 분석 워크로드에서 검증부터 해야 합니다.

Q4: 가장 큰 위험은 무엇인가요?

A: 실행 시간 측정 노이즈와 데이터 분포 변화입니다. 빠른 플랜이 항상 안전한 플랜은 아닙니다.

Q5: 개발팀은 무엇을 배워야 하나요?

A: 에이전트 성능은 모델만의 문제가 아니라 하네스, 보상, 롤백, 관측성의 문제라는 점입니다.