103편 · 약 14분

PLOP: SQL 쿼리 플랜에서 LLM 시맨틱 연산자 배치를 최적화하는 방법

요약

SQL에 자연어 조건을 섞어 쓸 수 있게 해주는 시맨틱 연산자(semantic operators)는 강력하지만 비용이 크다. FILTER(문서가 환경 관련 내용을 담고 있는가?)처럼 LLM을 호출하는 조건 하나가 수백 개의 행을 처리할 때 수 달러를 소비할 수 있다. 이때 핵심 질문은 "LLM 연산자를 쿼리 플랜의 어느 위치에 두어야 비용이 최소화되는가?"다. PLOP(Placement and Optimization of LLM Operators in Plans)은 이 배치 문제를 동적 프로그래밍(DP)으로 풀어 쿼리 플랜 탐색 공간을 체계적으로 최적화한다. 44개 쿼리·5개 스키마 벤치마크(SemCEB)에서 최대 1.5× 속도 향상, 4.3× 비용 절감을 달성한다.

배경: 시맨틱 연산자와 LOTUS

시맨틱 SQL이란

전통적인 SQL 연산자는 정확한 조건을 평가한다(price > 100, category = 'books'). 시맨틱 연산자는 이 경계를 넘어 자연어 명세를 조건으로 받아들인다.

SELECT doc_id, title
FROM documents
WHERE sem_filter(content, '환경 오염에 관한 내용을 담고 있는가?')

LOTUS(Stanford Future Data Lab, VLDB 2025)는 이런 시맨틱 SQL을 Python DataFrame API로 구현한 오픈소스 프레임워크다. sem_filter, sem_join, sem_agg, sem_topk 등의 연산자가 LLM 호출로 변환된다.

왜 배치가 중요한가

시맨틱 연산자의 LLM 호출 비용은 처리하는 행 수에 정비례한다. 10만 행짜리 테이블에 sem_filter를 적용하면 10만 번 LLM을 호출해야 한다. 그런데 sem_filter 앞에 선택도가 높은 일반 SQL 조건(WHERE year > 2020)을 먼저 적용해 행 수를 1만으로 줄이면 LLM 호출도 1만 번으로 줄어든다.

문제는 "어떤 순서로 어떤 조건을 배치해야 하는가"를 결정하는 비용 모델이 없었다는 점이다.

PLOP의 설계

배치 공간의 정의

하이브리드 쿼리 플랜에는 두 종류의 연산자가 섞인다:

전통 연산자: 인덱스 스캔, 조건 필터, 해시 조인 등. 비용은 행 수에 비례하되 단가가 매우 낮다.
시맨틱 연산자: LLM 호출 기반. 단가가 수천 배 높지만 선택도가 높을 수 있다.

PLOP은 이 연산자들의 실행 순서를 배치 변수로 놓고, 최적 순서를 DP로 탐색한다.

입력

하이브리드 SQL 쿼리

↓

연산자 분리
(전통 vs 시맨틱)

↓

선택도·비용 추정

PLOP 최적화

DP 플랜 탐색

↓

비용 함수 평가
행수 × 단가

↓

최적 배치 순서 결정

실행

전통 연산자 먼저

↓

행 수 최소화

↓

시맨틱 연산자
(LLM 호출 최소화)

PLOP 쿼리 플랜 최적화 흐름

비용 모델

PLOP의 비용 함수는 세 항목으로 구성된다:

cost(plan) = Σ (rows_in × unit_cost) for each operator

rows_in: 해당 연산자에 진입하는 행 수. 이전 연산자들의 선택도 곱으로 결정된다.
unit_cost: 전통 연산자는 나노초 단위, LLM 호출은 토큰 가격 기준.

시맨틱 연산자의 선택도는 사전에 정확히 알 수 없으므로, PLOP은 카디널리티 추정기(cardinality estimator)를 별도로 학습한다. 이 추정기가 SemCEB 벤치마크의 핵심 과제다.

DP 탐색

연산자 순서 탐색은 비트마스크 DP로 구현된다. n개 연산자의 배치 공간은 n!이지만, DP는 공유 서브플랜을 재활용해 O(2^n × n)으로 줄인다. 실제 쿼리에서 n ≤ 8이 대부분이므로 탐색은 수 밀리초 내에 완료된다.

SemCEB: 카디널리티 추정 벤치마크

왜 새 벤치마크가 필요했나

기존 카디널리티 추정 벤치마크(JOB, STATS-CEB 등)는 전통 SQL 조건만 다룬다. 시맨틱 조건의 선택도는 자연어 명세의 의미에 따라 결정되므로, 전통적 히스토그램·샘플링 방법으로는 추정이 어렵다.

SemCEB(arXiv:2606.23081, June 2026)는 44개 쿼리와 5개 스키마(뉴스 기사, 법률 문서, 상품 리뷰, 학술 논문, 소셜 미디어)에 걸쳐 시맨틱 조건의 참 선택도를 레이블링한 벤치마크다.

추정 방법 비교

논문은 여러 카디널리티 추정 방법을 SemCEB 위에서 비교한다:

방법	Q-Error 중앙값	비용
무선택도 가정 (0.5)	4.2×	없음
소규모 LLM 샘플링	1.8×	낮음
PLOP 학습 추정기	1.3×	낮음
진짜 LLM 전수 실행	1.0× (정답)	매우 높음

PLOP 추정기는 소규모 샘플(행의 5%)에 LLM을 적용해 선택도를 추정한 뒤 플랜 최적화에 반영한다. 비용은 전수 실행의 5%에 불과하면서 Q-Error는 1.3× 수준이다.

성능 평가

PLOP 비용 절감 효과 (쿼리 유형별)

주요 결과

비용: 최악 배치(Naive) 대비 최대 4.3× 절감. sem_filter가 많은 쿼리에서 특히 효과적이다.
속도: 최대 1.5× 처리 속도 향상. 전통 연산자를 먼저 실행해 LLM 호출 대기 병목을 줄인다.
플랜 탐색 시간: 쿼리당 평균 3.2 ms. 쿼리 실행 시간 대비 무시할 수 있는 수준이다.

실제 적용 시나리오

문서 검색·분류 파이프라인

뉴스 기사나 법률 문서에서 특정 주제의 글을 찾는 파이프라인에서 PLOP이 가장 효과적이다.

-- 최적화 전: sem_filter가 모든 행에 적용됨
SELECT * FROM articles
WHERE sem_filter(content, '기후 정책 관련 내용') -- 10만 행 LLM 호출
AND published_date > '2024-01-01'

-- 최적화 후 (PLOP이 결정한 순서):
SELECT * FROM articles
WHERE published_date > '2024-01-01' -- 먼저 날짜 필터로 2만 행으로 축소
AND sem_filter(content, '기후 정책 관련 내용') -- 2만 행만 LLM 호출

이 순서를 인간이 수동으로 결정하면 되지 않냐고 할 수 있지만, 조건이 여러 개이고 sem_join처럼 두 테이블이 엮이는 경우 최적 순서는 비용 모델 없이는 직관적으로 알기 어렵다.

sem_join 최적화

두 테이블을 자연어 조건으로 조인하는 경우, PLOP은 조인 전에 각 테이블에 단일 테이블 필터를 먼저 적용한다.

SELECT a.id, b.id
FROM articles a, companies b
WHERE sem_join(a.content, b.description, '이 기사가 이 기업을 언급하는가?')
-- 조인 대상 행 수가 클수록 비용 폭발적 증가

PLOP은 이 경우 양쪽 테이블에 가능한 전통 필터를 먼저 적용해 행 수를 줄인 뒤 sem_join을 수행하도록 플랜을 재작성한다.

LOTUS 생태계와의 관계

PLOP은 LOTUS 위에서 동작하는 쿼리 최적화 레이어로 설계되었다. 사용자는 LOTUS API를 그대로 사용하고 PLOP 옵티마이저를 활성화하기만 하면 된다.

import lotus
from lotus.models import LM

lm = LM("gpt-4o-mini")
lotus.settings.configure(lm=lm, enable_plop=True)  # PLOP 활성화

# 기존 LOTUS 코드 그대로 사용
result = (
    df
    .sem_filter("환경 관련 내용인가?")
    .sem_topk("가장 중요한 기사 10개", k=10)
)

내부적으로 PLOP은 연산자 DAG를 분석해 비용 최적 실행 순서를 자동으로 결정한다.

한계와 향후 과제

PLOP이 다루지 못하는 영역도 있다:

선택도 추정 오차: 5% 샘플 기반 추정이 실제와 크게 다를 때 최적 플랜이 틀릴 수 있다.
동적 데이터: 데이터가 실시간으로 변하면 통계가 빠르게 낡아진다.
모델 비용 변동: LLM 가격이 바뀌면 비용 모델을 재보정해야 한다.
비용과 품질의 트레이드오프: 선택도 높은 LLM 연산자를 뒤로 미루면 중간 결과의 품질이 달라질 수 있다. PLOP은 현재 비용만 최적화하며 품질 저하를 보정하지 않는다.

정리

PLOP은 "SQL + LLM"이 단순한 가능성이 아니라 운영 비용까지 고려해야 하는 엔지니어링 문제라는 점을 구체화한다. 시맨틱 연산자를 어디에 두느냐라는 단순해 보이는 질문이 비용 면에서 4배 이상의 차이를 만들어낼 수 있다. SemCEB는 이 최적화를 평가할 수 있는 공개 기반을 제공하며, 앞으로 LLM 연산자 비용 모델 연구의 출발점이 될 것으로 보인다.

References

Patel et al., "PLOP: Placement and Optimization of LLM Operators in Plans," arXiv:2604.09944, April 2026. https://arxiv.org/abs/2604.09944
Patel et al., "SemCEB: A Benchmark for Cardinality Estimation of Semantic Operators," arXiv:2606.23081, June 2026. https://arxiv.org/abs/2606.23081
Patel et al., "LOTUS: Enabling Semantic Queries with LLMs Over Tables of Unstructured and Structured Data," VLDB 2025. https://arxiv.org/abs/2407.11418