측정 가능한 목표를 사람들이 최적화하기 시작하면 그 지표는 쓸모를 잃는다는 굿하트의 법칙은 데이터베이스 벤치마크에도 적용된다. AI 코드 생성이 널리 쓰이면서 ClickBench에서도 특정 쿼리에만 맞춘 최적화가 빨라졌고, 그 결과 벤치마크 점수가 실제 성능을 제대로 나타내지 못할 수 있다는 지적이다.
새로운 문제는 아니다. TPC-D는 과도한 캐싱으로 쿼리 실행 시간이 0에 가까워질 만큼 참가자들이 벤치마크에 최적화한 뒤 폐기됐다. TPC-H는 임시 쿼리(ad-hoc query) 벤치마크임을 명시하고, 작업 부하에 대한 사전 지식을 이용하거나 결과를 캐싱하는 등 여러 최적화를 금지해 이 문제에 대응했다.
글은 오늘날의 ClickBench에서도 비슷한 현상이 나타난다고 설명한다. AI에 쿼리를 빠르게 만들라고 하면 일반적으로 타당한 방법인지 따지지 않고 쿼리 실행을 앞당길 수 있다는 것이다. 예를 들어 pgrust는 문자열 열을 그룹화해 집계할 때 긴 문자열을 살펴보지 않고 해시값만 사용한다. 속도는 빨라지지만 결과가 틀릴 수 있다.
ClickBench의 일부 쿼리는 같은 조건을 반복해서 사용한다. pgrust는 그 조건의 결과를 캐싱해 두 번째 실행부터는 쿼리 비용을 없앤다. 또 사용자 ID별로 묶어 결과를 반환하는 Q17에서는 데이터가 사용자 ID 순으로 대략 정렬돼 있고 쿼리에 ORDER BY 없는 LIMIT이 있다는 점을 이용한다. 어떤 사용자 ID든 결과에 포함될 수 있으므로 데이터 대부분을 읽지 않는다. 이런 세밀한 최적화는 일반적인 사용 사례에서는 유용하지 않을 수 있지만, AI는 개별 쿼리를 자세히 살펴 특정 벤치마크에 맞출 수 있다.
ClickBench 자체에도 허용되는 최적화의 범위가 명확하지 않고, 업데이트 작업이 없으며, 쿼리가 단순하고 조건을 공유하는 등 한계가 있다. 하지만 핵심 문제는 특정 벤치마크에만 있지 않다. 특정 평가에 공격적으로 최적화할수록 그 벤치마크는 유용성을 잃는다. 과거에는 시스템이 고객에게도 유용해야 한다는 요구가 이런 압력을 어느 정도 줄였지만, AI로 빠르게 만든 실행 엔진에는 그 기준이 적용되지 않을 수 있다.
해결책은 분명하지 않다. SQLStorm 제안은 쿼리 수를 수만 개로 늘려 과적합을 어렵게 하려 했다. 그러나 AI 도구를 쓰면 수만 개의 쿼리도 하나씩 분석할 수 있으므로 충분한 방어책은 아니다.
글은 의미 있는 벤치마크라면 TPC-H처럼 임시 쿼리를 사용하고, 사전 지식 활용과 중간 결과 캐싱을 금지해야 한다고 제안한다. 그렇지 않으면 실행 시간이 0에 가까워질 수 있다. 또 업데이트 작업을 포함해야 한다. 그래야 읽기 전용이나 읽기 중심 시스템이 완전한 트랜잭션 지원을 제공하는 시스템보다 언제나 유리해지는 일을 막을 수 있다.
평가할 시스템보다 나중에 벤치마크를 만들고, 평가 때마다 새로운 작업 부하를 생성하는 방법도 제안한다. 머신러닝 대회에서 참가자가 보지 못하는 비공개 테스트 세트로 순위를 매기는 방식이나, 새 질문을 정기적으로 공개하는 LiveBench처럼 데이터베이스 평가에서도 쿼리를 비공개로 두거나 개발용 대표 샘플만 공개할 수 있다. SQLStorm은 이미 쿼리를 생성하므로 새 쿼리 세트를 주기적으로 만드는 일은 비교적 수월할 수 있다. 스키마, 업데이트 작업, 트랜잭션의 다양성도 더 폭넓게 반영해야 한다는 제안이다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요