쿼리 최적화의 미래: 빅데이터에서의 AI 기반 통찰력

쿼리 최적화(Query optimization)는 결코 해결된 문제가 된 적이 없습니다. 데이터베이스가 효율적으로 작동하고 있다고 생각하는 순간, 데이터 볼륨은 세 배로 늘어나고, 액세스 패턴(access patterns)은 변화하며, 갑자기 정성껏 튜닝한 인덱스(indexes)가 득보다 실이 많아지기도 합니다. 수십 년 동안 데이터베이스 엔지니어들은 결정론적 로직(deterministic logic)을 따라 실행 계획(execution plans)을 선택하는 규칙 기반 쿼리 플래너(rule-based query planners)에 의존해 왔습니다. 하지만 이 모델은 현대의 빅데이터 워크로드(big data workloads)의 무게를 견디지 못하고 무너지고 있습니다. AI 기반 쿼리 최적화가 그 해답으로 떠오르고 있으며, 이는 이미 대규모 시스템이 수십억 개의 레코드를 실시간으로 처리하는 방식을 바꾸고 있습니다.

이것은 데이터베이스 관리자(database administrator)를 대체하려는 것이 아닙니다. 그들에게, 그리고 데이터베이스 자체에 근본적으로 더 스마트한 도구 세트를 제공하려는 것입니다.

전통적인 쿼리 플래너가 한계에 부딪히는 이유

모든 관계형 database에는 쿼리 플래너(query planner)가 포함되어 있습니다. 이는 SQL을 읽고, 테이블 통계(table statistics)를 검토하며, 쿼리를 어떻게 실행할지 결정하는 구성 요소입니다. 예를 들어, PostgreSQL의 플래너는 비용 기반 추정(cost-based estimation)을 사용하여 순차 스캔(sequential scans), 인덱스 스캔(index scans), 해시 조인(hash joins), 중첩 루프(nested loops) 중 하나를 선택합니다. 이 시스템은 우아하며 잘 작동합니다. 작동하지 않기 전까지는 말이죠.

문제는 비용 기반 플래너(cost-based planners)가 본질적으로 오래된 통계(stale statistics)를 바탕으로 작동한다는 점입니다. 이들은 마지막 ANALYZE 실행 시 수집된 히스토그램(histograms)과 샘플(samples)을 기반으로 카디널리티(cardinality, 필터가 반환할 행의 수)를 추정합니다. 실제 시스템에서 끊임없이 발생하는 것처럼 데이터 분포(data distributions)가 드리프트(drift)되면, 이러한 추정치는 틀리게 되며 때로는 재앙적인 결과를 초래합니다. 필터가 100개의 행을 반환할 것이라고 믿었지만 실제로는 1,000만 개를 반환하는 플래너는 완전히 잘못된 조인 전략(join strategy)을 선택하게 되며, 200ms짜리 쿼리를 45초짜리 재앙으로 만들어 버립니다.

규모(Scale)는 이러한 취약성을 가중시킵니다. Apache Spark, Trino 또는 BigQuery와 같은 분산 시스템(distributed systems)에서 실행되는 빅데이터 환경에서, 잘못된 계획은 단일 머신의 리소스만 낭비하는 데 그치지 않습니다. 이는 수백 개의 노드 전체로 연쇄 반응을 일으켜 메모리 예산을 초과하고, 클러스터 전체로 퍼져나가는 셔플 병목 현상(shuffle bottlenecks)을 생성합니다.

AI가 최적화 방정식을 바꾸는 방법

AI 기반 쿼리 최적화(AI-driven query optimization)는 단순히 사전에 수집된 통계(statistics)에 의존하는 대신, 과거의 실행 데이터로부터 학습하는 방식으로 작동합니다. 계획이 얼마나 걸릴지 추정하는 대신, 학습된 모델은 이를 예측할 수 있으며, 실행되는 모든 쿼리를 통해 시간이 지남에 따라 해당 예측을 개선할 수 있습니다.

가장 즉각적인 응용 분야는 **학습된 카디널리티 추정(learned cardinality estimation)**입니다. 전통적인 플래너(planners)는 컬럼 히스토그램(column histograms)과 서술어(predicates) 간의 독립성 가정(independence assumptions)을 사용하여 행 수(row counts)를 추정합니다. 하지만 이러한 독립성 가정은 거의 항상 틀립니다. city = 'Jakarta' 및 age > 30 조건으로 필터링하는 쿼리는 통계적으로 독립적이지 않습니다. 인구 통계적 분포는 히스토그램이 포착할 수 없는 방식으로 상관관계(correlated)를 갖기 때문입니다.

머신러닝 모델 — 특히 심층 신경망(deep neural networks)과 그래디언트 부스팅 트리(gradient-boosted trees) — 는 쿼리 로그(query logs)로부터 이러한 상관관계를 직접 학습할 수 있습니다. 일련의 필터 서술어가 주어지면, 학습된 모델은 수학적 허구가 아닌 데이터의 실제 결합 분포(joint distribution)를 고려한 카디널리티 추정치를 반환합니다.

학습된 비용 모델(Learned Cost Models)에 대한 실질적 고찰

아래는 scikit-learn을 사용하여 학습된 비용 모델이 어떻게 구조화될 수 있는지 보여주는 간략한 Python 예시입니다. 실제 운영 시스템에서는 이것이 쿼리 플래너의 최적화 루프(optimization loop) 내부에 위치하겠지만, 핵심 아이디어는 동일합니다:

import numpy as np
from sklearn.ensemble import GradientBoostingRegressor
from sklearn.preprocessing import StandardScaler
...

실제 시스템에서 플래너(planner)는 여러 개의 후보 계획(candidate plans)을 생성하고 이 모델을 통해 각 계획의 점수를 매겨, 예측된 비용(predicted cost)이 가장 낮은 계획을 선택하게 됩니다. 시간이 흐름에 따라 실제 실행 결과가 학습 데이터로 피드백되어 모델은 지속적으로 개선됩니다.

적응형 쿼리 실행 (Adaptive Query Execution): 쿼리 실행 중 반응하기

실행 전에 더 나은 추정치를 학습하는 것은 강력한 방법입니다. 하지만 일부 쿼리 계획 결정은 실제 런타임 데이터(runtime data)를 확인한 후에야 올바르게 내려질 수 있습니다. 여기서 적응형 쿼리 실행 (AQE, Adaptive Query Execution)이 등장하며, 현대의 엔진들은 실행 도중의 수정(mid-flight corrections)을 더 스마트하게 만들기 위해 AQE를 AI와 결합하기 시작했습니다.

Apache Spark 3.x는 AQE를 네이티브로 도입했습니다. 쿼리가 셔플 경계(shuffle boundary)에 도달하면, Spark는 실행을 일시 중단하고 실제 파티션 크기를 조사하여 다운스트림 계획(downstream plan)을 재최적화할 수 있습니다. 즉, 조인 전략(join strategies)을 변경하거나, 작은 파티션들을 병합(coalescing)하고, 데이터 왜곡(skew)을 실시간으로 처리합니다. AI는 이러한 조정이 비용이 많이 들기 전에 언제 필요할지를 예측함으로써, 엔진이 더 빠르게 대응할 수 있도록 사전 배치하는 역할을 수행하여 이를 확장합니다.

아키텍처는 대략 다음과 같습니다. 경량 추론 모델(lightweight inference model)이 쿼리 실행기(query executor)와 함께 실행되면서 중간 결과 크기와 타이밍 신호를 모니터링합니다. 모델이 계획 저하(plan degradation)와 관련된 패턴을 감지하면 — 예를 들어, 과거에 지연 작업(stragglers)을 유발했던 임계값을 초과하는 파티션 왜곡(partition skew) 등 — 피해가 발생한 후 반응하는 대신, 플래너(planner)에 미리 개입하도록 신호를 보냅니다.

인덱스 추천 및 워크로드 인식 튜닝 (Index Recommendation and Workload-Aware Tuning)

개별 쿼리 계획을 넘어, AI는 워크로드 수준에서 데이터베이스를 튜닝하는 방식까지 바꾸고 있습니다. 인덱스 추천(Index recommendation)은 전통적으로 전문가가 수동으로 수행하는 작업이었습니다. 데이터베이스 관리자(DBA)가 느린 쿼리 로그를 검토하고, 빈번한 액세스 패턴을 식별하며, 인덱스 후보를 제안한 다음, 각 인덱스를 유지하는 데 드는 쓰기 오버헤드(write overhead)를 추정하여 판단을 내리는 방식이었습니다.

AI 기반 인덱스 어드바이저(AI-powered index advisors)는 이 전체 루프를 자동화합니다. Microsoft의 DTA (Database Tuning Advisor)와 같은 도구 및 CBot, AutoAdmin과 같은 최신 연구 시스템들은 강화학습 (Reinforcement Learning) 및 워크로드 시뮬레이션 (workload simulation)을 사용하여 수천 개의 쿼리 템플릿에 걸쳐 인덱스 구성을 동시에 평가하며, 쿼리 하나하나를 개별적으로 처리하는 인간 전문가가 놓칠 수 있는 전역적으로 최적화된 인덱스 집합을 찾아냅니다.

-- 예시: 워크로드 인식 인덱스 어드바이저는 반복적인 술어 패턴(predicate patterns)을 보여주는 30일간의 쿼리 로그를 분석한 후 다음과 같은 권장 사항을 제시할 수 있습니다.

...

핵심적인 통찰은 AI 어드바이저가 전체 워크로드 (whole workload) 를 평가한다는 점입니다. 즉, 읽기 속도를 높이기 위해 인덱스를 추가하는 것이 쓰기 속도를 저하시킨다는 점을 이해하며, 단일 쿼리를 고립시켜 수정하는 대신 시스템의 순 처리량 (net throughput)을 최적화합니다.

자연어 쿼리 및 의미론적 최적화 (Natural Language Queries and Semantic Optimization)

AI 기반 쿼리 최적화에서 더욱 놀라운 발전 중 하나는 의미론적 의도 (semantic intent)를 이해하는 쿼리 플래너 (query planner)를 지원하는 자연어 인터페이스의 등장입니다. Text-to-SQL 도구를 구동하는 것과 같은 대규모 언어 모델 (Large Language Models, LLMs)은 제품 관리자의 평이한 영어 질문 — "지난 분기에 가입한 고객 중 3회 이상 구매했지만 60일 동안 재방문하지 않은 고객은 누구인가요?" — 을 의미론적으로 정확하고 최적화된 SQL로 변환할 수 있습니다.

이는 최적화 측면에서 매우 중요한데, LLM이 단순한 SQL 변환으로는 놓칠 수 있는 변환 규칙 (transformation rules)을 적용할 수 있기 때문입니다. 예를 들어, LLM은 쿼리의 의도가 상관 서브쿼리 (correlated subquery) 대신 윈도우 함수 (window function)를 통해 충족될 수 있음을 인식하여, 사용자가 차이를 전혀 느끼지 못하는 사이에 기존보다 수십 배 더 효율적인 실행 계획 (plan)을 생성할 수 있습니다.

-- 단순 변환 (상관 서브쿼리 — O(n²) 성능 위험):
SELECT c.customer_id, c.email
FROM customers c
...

AI로 강화된 쿼리 레이어는 쿼리 라이브러리에 저장된 고성능 쿼리의 패턴으로부터 학습된 재작성 규칙 (rewrite rules)을 적용하여 두 번째 형태를 자동으로 생성할 수 있습니다.

여전히 남아있는 과제들

이러한 모든 유망함에도 불구하고, AI 기반 쿼리 최적화 (AI-driven query optimization)는 즉시 적용 가능한 (turnkey) 솔루션은 아닙니다. 학습된 모델 (Learned models)은 그 이면에 있는 학습 데이터만큼만 성능을 발휘하며, 콜드 스타트 (cold-start) 문제는 실질적인 난제입니다. 쿼리 이력이 없는 새로운 데이터베이스는 학습할 대상이 전혀 없기 때문입니다. 시스템은 AI 구성 요소가 유의미한 가치를 더하기 전까지 규칙 기반 플래너 (rule-based planners)로부터 부트스트랩 (bootstrap)하고 충분한 실행 텔레메트리 (execution telemetry)를 축적해야 합니다.

해석 가능성 (interpretability) 문제도 존재합니다. 전통적인 플래너가 잘못된 결정을 내릴 때, 데이터베이스 관리자 (DBA)는 쿼리 실행 계획 (query plan)을 열어 예상 비용 (estimated costs)을 읽고 왜 잘못된 전략이 선택되었는지 정확히 이해할 수 있습니다. 반면 신경망 (neural network)이 잘못된 선택을 할 경우, 그 추론 과정은 불투명합니다. 이는 디버깅을 현저히 어렵게 만들며, 쿼리 성능이 사용자 경험에 직접적인 영향을 미치는 운영 환경에서 모델 실패에 따른 리스크를 높입니다.

가장 성숙한 구현 방식들은 고전적 플래너 (classical planner)를 폴백 (fallback)으로 유지함으로써 이에 대비합니다. 즉, AI 모델을 사용하여 계획을 선택하되, 실제 비용과 예측 비용을 모니터링하고 모델의 예측이 실제와 크게 벗어날 경우 고전적 계획법으로 되돌아가는 방식을 사용합니다.

결론

AI 기반 쿼리 최적화는 빅데이터 시스템에 있어 미미한 개선이 아닌 진정한 도약을 의미합니다. 학습된 카디널리티 추정 (Learned cardinality estimation), 적응형 실행 중 계획 수정 (adaptive mid-flight plan correction), 워크로드 인식 인덱스 추천 (workload-aware index recommendation), 그리고 의미론적 쿼리 재작성 (semantic query rewriting)은 각각 개별적으로도 영향력이 큽니다. 이들이 결합되어, 데이터베이스가 수동 튜닝 주기 없이도 실행되는 모든 쿼리를 통해 점진적으로 더 똑똑해지는 미래를 가리키고 있습니다.

이러한 변화를 이해하고, 이러한 모델에 입력될 쿼리 실행 텔레메트리 (query execution telemetry)를 수집하기 위해 시스템을 계측 (instrumenting)하기 시작하는 엔지니어와 아키텍트들은 데이터베이스가 확장됨에 따라 복리적인 이점을 얻게 될 것입니다. 만약 오늘날 상당한 규모의 분석 워크로드 (analytical workloads)를 운영하고 있다면, 학습된 쿼리 최적화 (learned query optimization)가 귀하의 스택에 무엇을 제공할 수 있는지 탐색해야 할 시점은 바로 지금입니다. 새로운 시각으로 느린 쿼리 로그 (slow query logs)를 검토하는 것부터 시작하십시오. 그것들은 단순히 해결해야 할 문제일 뿐만 아니라, 사용되기를 기다리고 있는 학습 데이터 (training data)입니다.