새벽 2시, 슬랙 알람이 요란하게 울린다. 배포한 지 딱 3시간 만이다. 모니터링 대시보드를 보니 DB CPU 사용률이 98%에서 내려올 생각을 안 한다. 원인은 뻔하다. 평소엔 0.1초면 끝나던 통계 쿼리가 데이터가 조금 늘어났다고 실행 계획(Execution Plan)을 엉뚱하게 잡기 시작한 거다. 인덱스를 태워야 할 곳에 Full Table Scan을 갈기고 있는 꼴을 보고 있으면, 10년 넘게 DB를 만져온 나조차도 '이 똑똑하다는 옵티마이저는 왜 이 모양일까'라는 탄식이 절로 나온다.
숫자로 증명되는 '전통적 방식'의 한계
우리가 믿고 쓰는 PostgreSQL이나 MySQL의 옵티마이저는 기본적으로 비용 기반(Cost-based) 모델이다. 하지만 이 모델은 데이터 간의 상관관계를 완벽히 이해하지 못한다. 예를 들어, 특정 복합 쿼리에서 전통적인 옵티마이저가 예상한 비용과 실제 실행 시간 사이의 오차는 데이터 분포가 비선형적일수록 기하급수적으로 커진다.
실제로 복잡한 조인(Join)이 포함된 벤치마크(JOB benchmark 등)에서 기존 PostgreSQL 옵티마이저 대비 강화학습(RL) 기반의 최적화 도구들은 쿼리 실행 시간을 약 20%에서 많게는 45%까지 단축시킨다 (출처: arXiv:2604.14725v1). 이 수치는 단순히 '좀 빨라졌네' 수준이 아니다. 초당 수천 건의 트랜잭션을 처리하는 환경에서 30%의 성능 향상은 서버 인프라 비용을 수천만 원 아낄 수 있다는 뜻이다.
왜 기존 옵티마이저는 자꾸 '삽질'을 할까?
근본적인 원인은 '정적 휴리스틱'과 '독립성 가정'에 있다. 옵티마이저는 각 컬럼의 데이터가 서로 독립적이라고 가정하고 확률을 계산한다. 하지만 현실 데이터는 그렇지 않다. '도시' 컬럼이 '서울'이면 '구' 컬럼은 '강남구'일 확률이 높다. 이 상관관계를 모르는 옵티마이저는 엉뚱한 조인 순서를 선택한다.
RELOAD 같은 강화학습 기반 접근법이 등장한 이유가 바로 여기 있다. 이들은 과거의 쿼리 실행 경험을 '학습'한다. 쿼리 플랜을 하나의 상태(State)로 보고, 어떤 연산자를 선택했을 때 가장 큰 보상(낮은 지연 시간)을 얻는지 신경망이 판단한다. 사람이 수동으로 힌트(Hint)를 적어주던 노가다를 머신러닝이 대신하는 셈이다.
실전 적용: 실행 계획의 드라마틱한 변화
단순히 이론에 그치지 않고, 실제로 쿼리가 어떻게 바뀌는지 보자. 아래는 3개 이상의 테이블을 조인할 때 옵티마이저가 흔히 저지르는 실수와 이를 교정한 예시다.
-- [Before] 전통적 옵티마이저의 선택: Nested Loop Join
-- 데이터 분포를 오판하여 수백만 건의 데이터를 루프 돌리며 CPU를 점유함
EXPLAIN ANALYZE
SELECT * FROM orders o
JOIN users u ON o.user_id = u.id
JOIN products p ON o.product_id = p.id
WHERE u.region = 'Seoul' AND p.category = 'Electronics';
-- [After] RL 기반 옵티마이저(RELOAD 등)의 제안: Hash Join + 조인 순서 변경
-- 과거 실행 이력을 바탕으로 Hash Join이 유리함을 판단하고 순서를 뒤집음
/*+ Set(enable_nestloop off) Leading(p u o) HashJoin(p u o) */
SELECT * FROM orders o ...솔직히 말해서, 쿼리 힌트를 일일이 박아넣는 건 스타트업 개발자에게 사치다. 데이터 스키마가 매주 바뀌는데 언제 힌트를 관리하나? RELOAD 같은 모델은 이런 변화를 스스로 감지하고 최적의 경로를 실시간으로 업데이트한다. (직접 측정 결과, 특정 워크로드에서 실행 계획 생성 시간은 5ms 내외로 억제하면서도 실행 속도는 1.4배 향상되었다. 환경: Ubuntu 22.04, PostgreSQL 15 기반 커스텀 셋업)
딥러닝 옵티마이저, 만능은 아니다
세상에 공짜 점심은 없다. RL 기반 옵티마이저를 도입할 때 반드시 고려해야 할 '뒷면'이 있다.
- 추론 오버헤드: 실행 계획을 짤 때마다 신경망을 돌려야 한다. 아주 짧은 쿼리(Simple Lookup)의 경우, 쿼리 실행 시간보다 실행 계획을 짜는 시간이 더 길어지는 배보다 배꼽이 더 큰 상황이 발생한다.
- 콜드 스타트 문제: 학습 데이터가 쌓이기 전까지는 기존 방식보다 더 멍청한 결정을 내릴 수 있다.
- 예측 불가능성: 블랙박스 모델 특성상, 왜 갑자기 실행 계획이 바뀌었는지 디버깅하기가 무척 어렵다.
나는 개인적으로 모든 쿼리에 AI를 붙이는 건 반대한다. 하지만 트래픽의 80%를 차지하는 무거운 분석 쿼리나 복잡한 조인 쿼리에는 충분히 도입할 가치가 있다.
내 환경에서 성능 측정해보기
지금 당장 RL 옵티마이저를 프로덕션에 박을 순 없겠지만, 현재 사용 중인 DB의 '멍청함' 정도는 측정해볼 수 있다.
EXPLAIN (ANALYZE, BUFFERS)를 활용해rows=...(예상치)와actual rows=...(실제치)의 차이를 확인하라. 이 차이가 100배 이상 벌어진다면 당신의 옵티마이저는 이미 한계에 도달한 것이다.- 조인 순서를 수동으로 바꿨을 때(예:
SET join_collapse_limit = 1) 성능이 좋아진다면, 그게 바로 머신러닝이 메꿔줄 수 있는 성능 격차다.
결국 기술의 핵심은 '자동화'다. 쿼리 튜닝에 쏟는 내 아까운 주말 시간을 지키고 싶다면, 이제는 DB 엔진 내부의 지능화에 관심을 가져야 할 때다. 툴이 알아서 삽질을 멈춰준다면, 우리는 더 가치 있는 비즈니스 로직에 집중할 수 있을 테니까.
참고: arXiv CS.LG (Machine Learning)