무슨 일이 있었나
데이터베이스 성능을 비교할 때 자주 인용되는 벤치마크로 ClickBench가 있어요. 최근 이 저장소에 “Remove pgrust: the entry is cheating”, 그러니까 “pgrust 결과를 제거한다: 이 엔트리는 반칙이다”라는 제목의 PR이 올라왔어요. pgrust는 이름만 보면 Rust로 구현한 PostgreSQL 계열 프로젝트로 보여요. 리더보드에 올라간 결과가 규칙을 어겨 얻은 것이라 빼야 한다는 거죠.
구체적으로 어떤 부분이 문제였는지는 PR 토론에서 확인할 수 있어요. 다만 이 사건을 제대로 이해하려면 ClickBench가 어떤 곳이고, 거기서 ‘반칙’이 무슨 뜻인지부터 알아야 해요. 이번 글에서는 그 배경과 함께 벤치마크 반칙이라는 오래된 문제를 같이 짚어 볼게요.
ClickBench가 뭐냐면
ClickBench는 ClickHouse 팀이 2022년에 공개한 분석용(OLAP) 데이터베이스 벤치마크예요. OLAP이 뭐냐면, 쇼핑몰 주문을 한 건씩 저장하는 일(OLTP)이 아니라 “지난달 지역별 매출 합계” 같은 대량 집계를 빠르게 처리하는 데 특화된 시스템이에요.
데이터는 실제 웹 분석 서비스에서 나온 약 1억 행짜리 ‘hits’ 테이블 하나이고, 여기에 43개 SQL 쿼리를 돌려요. 쿼리마다 세 번씩 실행하는데, 첫 번째는 캐시가 비어 있는 상태(cold run)이고 나머지는 데이터가 메모리에 올라온 상태(hot run)예요. ClickHouse, DuckDB, DataFusion, Snowflake, PostgreSQL 등 수십 개 시스템의 결과가 공개 리더보드에 올라가 있어요. 무엇보다 누구나 스크립트를 PR로 제출해서 결과를 추가할 수 있는 열린 구조라는 게 특징이에요.
벤치마크에서 ‘반칙’이란
열린 구조인 만큼 규칙이 중요해요. ClickBench는 시스템을 합리적인 방식으로 설치하고 일반적인 최적화를 쓰는 건 허용해요. 하지만 벤치마크 쿼리 자체를 노린 꼼수는 인정하지 않아요. 벤치마크 세계에서 흔히 반칙으로 보는 유형은 이런 것들이에요.
- 쿼리 결과 캐시: 같은 쿼리의 답을 저장해 뒀다가 두 번째 실행부터 그대로 돌려주는 방식이에요. hot run 수치가 비현실적으로 빨라지죠.
- 쿼리 맞춤형 사전 계산: 43개 쿼리를 미리 알고 그 답이 바로 나오도록 집계 테이블이나 머티리얼라이즈드 뷰(materialized view, 쿼리 결과를 미리 계산해 저장해 둔 테이블)를 만들어 두는 방식이에요.
- 벤치마크 감지: 들어온 쿼리가 벤치마크 쿼리인지 알아보고 특별한 경로로 처리하는 방식이에요.
벤치마크 반칙의 오랜 역사
점수를 부풀리려는 시도는 DB 업계만의 얘기가 아니에요. 2013년쯤 일부 스마트폰 제조사가 벤치마크 앱이 실행되는 걸 감지하면 클럭을 몰래 올린다는 사실이 드러났고, 그 뒤로도 비슷한 이유로 벤치마크 리더보드에서 빠진 기기들이 있었어요. 폭스바겐 디젤게이트도 ‘테스트 상황을 감지해서 다르게 동작한다’는 같은 구조였고요.
DB 업계에는 반대 방향의 역사도 있어요. 1980년대 위스콘신 대학의 데이비드 드윗(David DeWitt) 교수가 상용 DB 성능 비교 결과를 발표한 뒤, 오라클이 라이선스에 ‘허락 없이 벤치마크 결과를 공개하지 말라’는 조항을 넣었어요. 이런 조항을 지금도 ‘드윗 조항(DeWitt Clause)’이라고 불러요. TPC 같은 공식 벤치마크가 감사(audit)를 거친 결과만 인정하는 것도 같은 이유예요.
ClickBench는 반대로 ‘스크립트를 전부 공개하고 누구나 재현하게 하자’는 쪽을 택했어요. 이번 PR을 보면 그런 개방성이 반칙을 미리 막지는 못해도 찾아내는 데는 효과적이라는 걸 알 수 있어요. 스크립트가 공개돼 있으니 누군가 이상한 점을 발견하고 근거를 들 수 있는 거죠.
한국 개발자에게 주는 시사점
DB나 쿼리 엔진을 고를 때 벤치마크 순위는 좋은 출발점이지만 결론이 되어서는 안 돼요. ClickBench도 스스로 한계를 밝히고 있어요. 납작한 테이블 하나만 쓰기 때문에 조인(join)이 많은 일반적인 데이터 웨어하우스 워크로드를 대표하지는 못해요. 여러분 서비스의 데이터 모양과 쿼리 패턴은 전혀 다를 수 있어요.
그래서 실무에서는 벤치마크 결과를 볼 때 설정과 스크립트를 직접 열어 보는 걸 추천해요. 결과 캐시가 꺼져 있는지, 데이터 로딩 단계에 쿼리 맞춤 전처리가 섞여 있지 않은지 확인해 보세요. 그리고 마지막 후보 두세 개는 우리 데이터와 우리 쿼리로 직접 돌려 보는 게 가장 확실해요. 사내 기술 블로그에 성능 비교 글을 쓸 때도 환경과 설정을 투명하게 공개해야 신뢰를 얻을 수 있고요.
새 프로젝트가 “기존보다 N배 빠르다”는 문구를 내세우는 일이 정말 많잖아요. 숫자를 보면 반사적으로 ‘어떻게 측정했지?’부터 묻는 습관이 엔지니어에게 꽤 중요한 역량이에요.
마무리
한 줄로 정리하면, 지표가 목표가 되는 순간 그 지표는 더 이상 좋은 측정 도구가 아니에요. 굿하트의 법칙이 딱 이 얘기죠. 여러분은 기술을 고를 때 공개 벤치마크를 얼마나 믿으시나요? 직접 비교 테스트를 해 봤는데 벤치마크와 전혀 다른 결과가 나왔던 경험이 있다면 공유해 주세요.
🔗 출처: Hacker News