QORL 4B는 PostgreSQL을 이길까? ‘81% 빠른 계획’의 조건

핵심 요약

• 쿼리 계획을 만드는 데 걸리는 시간과 그 계획으로 데이터를 처리하는 데 걸리는 시간은 서로 다른 지표입니다.
• ‘81% 빠르다’는 표현은 실행 시간이 줄었다는 뜻인지, 실행 속도가 높아졌다는 뜻인지에 따라 의미가 달라집니다.
• AI의 최적화 효과를 확인하려면 PostgreSQL의 설정과 데이터를 살피고, 학습에 사용하지 않은 쿼리에서도 검증해야 합니다.
• 실무에서는 모델 추론과 계획 검증 비용까지 포함한 전체 응답 시간이 중요합니다.

같은 SQL도 데이터를 읽고 결합하는 순서에 따라 실행 시간이 달라집니다. QORL 4B의 ‘81% 빠른 쿼리 계획’이라는 주장도 작은 AI가 이 순서를 더 잘 고를 수 있는지에 관한 이야기입니다. 다만 이 문구를 곧바로 ‘우리 서비스도 81% 빨라진다’로 받아들이려면 먼저 확인할 것이 있습니다.

AI가 바꾸려는 것은 데이터베이스의 ‘선택’입니다

PostgreSQL은 SQL을 받으면 데이터를 어떻게 가져올지 결정합니다. 테이블 전체를 읽을지, 인덱스로 필요한 부분을 찾을지 고릅니다. 여러 테이블을 연결하는 조인에서는 어떤 테이블부터 처리할지도 정합니다.

이 일을 맡는 것이 쿼리 최적화기입니다. 목적지까지 갈 경로를 고르는 내비게이션과 비슷합니다. 목적지가 같아도 어떤 길로 가느냐에 따라 도착 시간이 달라집니다.

최적화기는 데이터 통계와 비용 추정치를 바탕으로 계획을 비교합니다. 그런데 특정 값에 데이터가 몰려 있거나 조건 사이에 상관관계가 있으면 처리할 행의 수를 잘못 예상할 수 있습니다. 이 예상이 빗나가면 실제로는 느린 계획을 고르기도 합니다.

AI가 도움을 줄 수 있는 부분이 여기입니다. 데이터와 실행 결과에서 배운 패턴을 바탕으로 더 나은 선택을 도울 수도 있습니다. 다만 ‘AI가 최적화한다’는 말만으로는 무엇을 바꾸는지 알 수 없습니다. 처리할 행의 수를 예측하는지, 후보 계획의 순위를 매기는지, 실행 계획을 직접 제안하는지에 따라 검증할 내용도 달라집니다.

QORL 4B를 평가할 때도 먼저 최적화 과정의 어느 부분을 개선하는가를 알아야 합니다.

‘81% 빠르다’에는 계산식이 필요합니다

먼저 무엇을 측정한 수치인지 구분해야 합니다. 실행 계획을 빨리 만드는 것과 그 계획으로 쿼리를 빨리 실행하는 것은 다른 성과입니다. 계획을 만드는 시간이 줄어도 데이터를 처리하는 시간이 그대로라면 사용자가 느끼는 변화는 작을 수 있습니다.

백분율도 뜻을 따져봐야 합니다. 기준 쿼리를 실행하는 데 10초가 걸린다고 가정해보겠습니다.

• 실행 시간이 81% 줄었다면 결과는 1.9초입니다.
• 같은 작업의 실행 속도가 81% 높아졌다면 결과는 약 5.5초입니다.
• 전체 쿼리의 81%에서 더 빠른 계획을 찾았다는 뜻이라면, 개별 쿼리의 단축 폭은 알 수 없습니다.

세 문장 모두 좋은 결과처럼 들리지만, 실제 뜻은 크게 다릅니다. 위 숫자는 표현에 따라 계산 결과가 어떻게 달라지는지 보여주는 예시입니다. QORL의 측정 결과를 뜻하지는 않습니다.

평균을 어떻게 냈는지도 봐야 합니다. 각 쿼리의 개선 비율을 평균했는지, 전체 작업의 실행 시간을 합산해 비교했는지에 따라 결과가 달라집니다. 원래 매우 느렸던 쿼리 하나를 크게 개선한 경우와 대부분의 쿼리를 조금씩 개선한 경우는 운영자에게도 다르게 다가옵니다.

‘81%’만으로는 얼마나 개선됐는지 확정할 수 없습니다. 무엇을 측정했고 어떻게 계산했는지 함께 알아야 판단할 수 있습니다.

실험에서 좋은 결과가 나와도 서비스에서는 더 살펴야 합니다

비교하려면 먼저 PostgreSQL 쪽 환경을 살펴야 합니다. 버전과 설정은 물론 인덱스 구성과 통계 갱신 상태도 확인해야 합니다. AI 쪽에만 유리한 인덱스가 있거나 기본 최적화기가 오래된 통계를 사용했다면 모델 덕분에 얼마나 나아졌는지 가려내기 어렵습니다.

실행 환경도 같아야 합니다. 같은 데이터와 하드웨어를 사용했는지, 필요한 데이터가 메모리에 올라와 있는지 확인해야 합니다. 실행 순서 때문에 한쪽만 캐시의 이점을 얻지는 않았는지도 봐야 합니다. 비교하는 쿼리가 같은 결과를 반환해야 한다는 것은 기본입니다.

그다음에는 처음 보는 쿼리에서도 효과가 유지되는가를 확인해야 합니다. 학습에 사용한 쿼리와 비슷한 형태에서 성능이 좋았다는 이유만으로 다른 쿼리에서도 잘 작동하리라 보기는 어렵습니다. 테이블 규모가 커지거나 데이터 분포가 달라졌을 때도 유리한 계획을 고를 수 있어야 합니다.

평균만 봐서는 놓치는 결과도 있습니다. 전체 평균은 좋아졌는데 특정 주문 조회가 크게 느려졌다면 서비스에서는 문제가 됩니다. 느린 요청이 몰린 구간을 보여주는 지표와 성능이 가장 크게 나빠진 사례를 함께 봐야 합니다.

저라면 최고 개선율보다 성능이 나빠진 쿼리의 비율과 악화 폭을 먼저 보겠습니다. 잘된 사례만 보고 최적화 도구를 도입할지 결정하기는 어렵기 때문입니다.

작은 모델도 도입 비용은 따로 계산해야 합니다

AI가 더 좋은 실행 계획을 골라도 고르는 데 시간이 듭니다. 요청을 처리하면서 모델 추론을 거치고, 후보 계획을 만들고 검증한다면 그 시간만큼 사용자도 기다려야 합니다.

예를 들어 기존 쿼리를 실행하는 데 100밀리초가 걸렸다고 가정해보겠습니다. AI가 고른 계획으로 실행 시간이 70밀리초가 됐어도, 계획을 고르는 데 50밀리초가 추가된다면 합계는 120밀리초입니다. 실행 단계는 빨라졌지만 전체 응답은 느려집니다.

오래 걸리는 분석 쿼리를 반복 실행할 때는 계산이 달라집니다. 계획을 미리 골라 재사용할 수 있다면, 고르는 데 든 비용을 여러 번의 실행에 나눠 부담할 수 있습니다. 다만 데이터가 바뀐 뒤에도 그 계획이 유리한지는 다시 확인해야 합니다.

그래서 도입을 검토한다면 비용이 많이 들면서 반복 실행하는 쿼리부터 살펴볼 만합니다. 실제 요청에 적용하기 전에 복제 환경에서 결과가 정확한지 확인하고 실행 시간도 비교할 수 있습니다. 도입 후에는 계획을 고르는 데 시간 제한을 두고, 문제가 생기면 기본 최적화기로 돌아갈 수 있어야 합니다.

QORL 4B의 ‘81%’가 실무에서도 설득력을 얻으려면 어떤 지표인지 분명해야 합니다. 같은 조건에서 비교했는지, 추가 비용을 포함해도 성능이 나아지는지 확인할 수 있어야 합니다. 작은 AI가 이런 개선을 이끌 수 있다는 가능성은 흥미롭지만, 운영에서는 그 이득을 반복해서 얻을 수 있어야 합니다. 도입 판단도 가장 느린 쿼리 하나를 크게 줄이는 일과 모든 요청의 지연을 안정적으로 유지하는 일 중 우리 서비스에 무엇이 더 급한지부터 따져야 합니다.