pgrust 개발자임. 제기된 의혹은 대부분 사실이 아니며, 제출한 것은 개발 초기 버전인 pgrust 0.4-preview였음. GitHub에서 논쟁하기보다 0.4를 완성해 공개하는 편이 낫다고 봤고, 어제 소스를 공개한 0.4-beta는 직접 검증할 수 있음.
핵심 의혹은 벤치마크 쿼리별 수작업 코드 사용, 실행 간 결과 캐싱, ClickBench의 43개 쿼리 외에는 지원하지 않았다는 세 가지임. 수작업 코드는 Gravity IR의 성능을 검증하려고 만든 irprobe 코드이며 벤치마크 실행에는 사용하지 않았음. 실제 제출본은 SQL → Gravity IR → 어셈블리로 이어지는 JIT 컴파일 경로를 사용함.
결과 캐시로 지목된 것은 사전 압축에 사용하는 문자열 중 어떤 것이 조건식과 일치하는지 저장하는 캐시임. ClickBench는 이런 중간 데이터 캐싱을 허용하며, ClickHouse에도 유사한 Condition Cache가 있음. 새 제출본에는 모든 캐시와 비활성화 방법을 명시함.
SQL 지원 범위가 좁았다는 비판에는 일부 근거가 있음. 새 JIT 컴파일러가 ClickBench 쿼리를 처리할 정도가 되자 제출했으며, ClickBench에는 SQL 지원 범위에 관한 규정이 없는 것으로 알고 있음. 기존 쿼리 엔진도 함께 배포했으므로 두 줄만 수정하면 더 폭넓은 쿼리를 처리하도록 대체 실행할 수 있었음. 새 0.4-beta는 CTE와 MERGE 관련 일부 버그를 제외하면 모든 Postgres SQL을 지원함.
너무 일찍 제출했고 SQL 지원 범위를 더 넓혔어야 한다는 점은 인정함. 새 제출본으로 복귀하길 바라며, 이상한 부분을 알려주면 수정하겠음. 당시 바이너리도 공개하지만 실제 제출 파일과 동일하다는 것을 직접 증명할 방법은 없음. ClickHouse가 테스트한 바이너리의 SHA를 공개하면 일치할 것임.
소스: https://github.com/malisper/pgrust/releases/tag/v0.4-beta.
당시 바이너리: https://pgrust.com/downloads/archive/2026-09-clickbench-snap....
규칙: https://github.com/ClickHouse/ClickBench/blob/main/README.md.
Condition Cache: https://clickhouse.com/docs/concepts/features/performance/ca....
새 제출본: https://github.com/ClickHouse/ClickBench/pull/2751.
당시 상황을 확인할 수 있도록 0.4-preview 소스도 공개해 줄 수 있는지?
바이너리에 q00.rs~q36.rs 경로가 들어 있는 이유는 무엇인지?
해명을 들어도 여전히 수상하고 기만적으로 느껴짐. 이렇게 미완성이고 특정 벤치마크에 맞춰진 것을 제출하는 목적이 자기 홍보 말고 무엇인지?
벤치마크는 범용 쿼리 엔진을 측정하는 수단이어야지 그 자체가 목표가 되어서는 안 됨. 측정 지표가 홍보용 목표로 변질된 굿하트의 법칙의 전형으로 보임.
ClickBench 외의 다양한 쿼리를 실행할 수 없다면 벤치마크에 제출하지 말아야 함. 목록에 있는 다른 데이터베이스는 온갖 쿼리를 처리할 수 있는데, 초기 0.4 빌드라 기능이 부족했다는 해명 뒤에 숨는 것은 이상함.
프로젝트가 충분히 성숙하기 전에는 재등록을 허용하지 않길 바람. ClickBench만 빠르고 나머지 지원은 불확실한 프로젝트가 몰리면 벤치마크가 쓸모없어짐.
이전 버전의 이름이 무엇인지는 무관함. 의혹의 대상은 직접 제출한 그 버전이며, 문제를 고쳤다는 새 제출본을 내놓았다고 이전 의혹이 거짓이 되는 것은 아님. 직접 제출해 놓고 이제 와서 미리보기 버전이었다며 축소하는 것은 양쪽 이익을 다 취하려는 태도 아닌지?
SQL 지원 범위에 명시적 규정이 없다는 변명은 세제 캡슐을 먹지 말라는 경고문까지 필요한 이유를 보여줌.
예방 차원에서 아예 참여를 금지해야 함. 부정행위 코드가 릴리스에 들어갔다면 코딩 에이전트가 추가한 것을 아무도 검토하지 않았거나, 사람이 알면서 승인한 것임. 전자도 나쁘지만 후자는 악의적임. 어느 쪽도 책임감을 보여주지 못하므로 제품을 홍보할 자리를 내줘서는 안 됨.
ClickHouse 관리자가 원칙을 지키고, 프로젝트와 관리자가 더 성숙할 때까지 pgrust의 복귀를 허용하지 않길 바람.
처음 잘못한 일을 전혀 인정하지 않으면서 저렇게 자신만만한 태도라니 기가 막힘.
“베타를 먼저 내고 코드는 몇 주 뒤에 공개하겠다”는 방식이 직관에 어긋나 보임. 오픈소스에서 흔한 방식인지, 그렇게 하는 이유가 있는지?
대규모 리팩터링을 진행했다가 되돌리는 일이 잦아서 그렇게 해왔음. 공개 버전보다 앞선 내부 개발 버전을 유지하고, 공개적으로 사용할 준비가 되면 소스를 공개함.
바로 이런 개발 방식이 Eric Raymond의 『성당과 시장』 이 다룬 주제임. 성당 방식은 비공개로 개발한 뒤 릴리스와 소스를 함께 내놓고, 시장 방식은 개발 과정을 공개해 항상 최신 코드에 접근할 수 있게 함.
당시 성당 방식의 예는 GCC와 Emacs였고, 시장 방식의 대표는 Linux였음. 성당 방식은 많이 줄었지만 SQLite는 여전히 그런 방식으로 알고 있음. Google의 AOSP도 분명 그러하며, 오픈소스 약속을 형식적으로만 지키는 태도에 더 가까울 수도 있음.
Lua는 릴리스 사이에 비공개로 개발함. 반면 V 언어처럼 거창하게 홍보한 뒤 일부만 작동하는 결과물을 공개해 덜 성공적인 경우도 있음. 아주 흔하지는 않지만 전례 없는 방식도 아님.
정상적인 방식은 아니라고 봄. AI를 과도하게 쓰거나, 특히 Claw/Ralph 반복 실행으로 수천 개 파일을 건드리는 커밋 몇 개만 남기는 새로운 흐름에 가까움. 지난 1년 정도 Show HN에 올라오는 GitHub 프로젝트 중 단일 커밋만 있는 경우가 자주 보임.
기계에게 생각을 맡기기보다 업계가 무엇을 하고 있는지 더 고민해야 함.
요약하면 벤치마크가 무작위화되지 않았고 어디선가 캐시된 결과를 반환한다는 것임. 적어도 일부 벤치마크는 무작위 데이터로 실행해야 한다고 봄.
이렇게 긴 PR 요약을 실제로 읽는 사람이 있는지?
기록으로 남기려는 용도임.
분위기가 너무 공격적임. pgrust가 실패하길 바라는 듯한 태도가 많이 보임. 부정행위였을 수도 있지만 오해였을 가능성도 있음. 이제 오픈소스 버전까지 나왔는데도 왜 이렇게 부정적인지?
해명이 있는 듯해도, 첫인상이 정말 나쁘기는 함.
투명성과 정직성을 온전히 지키지 못하는 데이터베이스 프로젝트를 응원할 생각은 없음. 벤치마크에서도 정직하지 못한 이들에게 누가 데이터를 맡기겠는지? 데이터 손상 버그가 생기면 어떻게 대응할 것이며, 그때는 더 잘 행동하리라는 근거가 있는지? 스스로 실패를 자초한 것이고 우리는 그 과정을 보고 있을 뿐임.
pgrust와 ClickBench를 모르는 경우를 위해 정리하면, pgrust는 PostgreSQL을 Rust로 재구현한 프로젝트이고 ClickBench는 데이터베이스 벤치마크 모음임. 링크는 부정행위 의혹 때문에 pgrust를 벤치마크에서 제거해 달라는 요청으로 연결됨.
제거 요청이라는 표현은 틀림. ClickBench 개발자가 직접 올려 이미 병합한 PR이므로 단순한 요청이 아님.
의혹보다는 발견된 사실에 가까움. 다만 부정행위라는 표현도 정확하지 않을 수 있음. AI가 하던 대로 했고, 사람이 코드를 전혀 살피지 않은 것으로 보임.