Jepsen: ParticleDB 1.1.4

요약

Jepsen이 ParticleDB에서 문제 96건을 찾아내고 사용을 중단하라고 권고했습니다.

데이터베이스 검증 보고서를 내는 Jepsen의 카일 킹스베리가 오크스의 비용 지원을 받아 쓴 분석입니다. ParticleDB는 AI 작업용으로 Rust로 만든 데이터베이스로, Postgres 호환과 "Full ACID"(트랜잭션 안전성을 완전히 보장한다는 뜻)를 내세웠습니다.

왜 중요한가

Jepsen은 1.1.18.11.rc-18까지의 버전을 쓴 사용자가 이미 데이터를 잃거나 손상시켰을 가능성이 높다고 봤습니다.
배포를 멈추고 다른 데이터베이스로 옮기라는 권고이며, 가능하면 믿을 만한 원본으로 데이터도 점검하라고 했습니다.
Jepsen은 LLM이 소규모 팀의 개발 범위를 크게 넓혀 주지만 품질과 신뢰는 떨어뜨릴 수 있다고 경고했습니다.

핵심 내용

1.1.4에서는 커밋된 쓰기가 사라지는 현상이 시험한 모든 트랜잭션 모드에서 나왔고, 장애 없는 서버 한 대에서도 재현됐습니다.
기본 기능도 깨져 있어 WHERE 4 = 5가 행을 돌려주고, 삭제한 테이블이 왜곡된 형태로 되살아났습니다.
마지막으로 시험한 1.1.18.11.rc-22에도 기본 모드의 쓰기 손실과 프로세스 강제 종료 시의 이상 현상이 남아 있었습니다.
오크스는 1.1.19-rc.13에서 모두 고쳤다고 주장했지만, Jepsen은 rc-22 이후 버전을 검증하지 않았습니다.
홈페이지가 내세운 TLA+(시스템 설계를 수학적으로 검증하는 언어) 증명의 명세는 검토 기간에 제공되지 않았습니다.

HN 반응

AI로 대충 짠 코드의 결과라는 의견이 많았지만, 2013년 MongoDB 사례를 들어 원인은 사람의 부주의라는 반론도 나왔습니다.
ParticleDB 팀원이 문제를 고치고 Jepsen 시험을 매일 돌린다고 밝혔으나, 일부 이용자는 보고서의 품질 관리 비판을 들어 믿기 어렵다고 답했습니다.

30개 표시 · 전체 182개

the_duke1일 전 HN

처참하네요!

ParticleDB 1.1.4는 Postgres 호환 데이터베이스를 표방했다 ... 그러나 우리가 발견한 것은 혼란의 집합체였다

우리가 측정할 수 있는 거의 모든 면에서 심각한 트랜잭션 이상 현상이 빈번하게 나타났다. 커밋된 쓰기가 사라지는 일, 내부 일관성 위반, G1a(중단된 읽기), G1b(중간 읽기), P4(갱신 손실)가 꾸준히 관찰됐다. 추가(append) 워크로드에서는 성공적으로 추가된 값이 같은 키를 나중에 읽을 때 번번이 사라졌다. 우리 테스트 스위트는 G0, G1c, G-Single, G2-item 등 모든 종류의 순환 이상 현상을 추론해 냈지만, 이 가운데 상당수는 쓰기 손실 같은 더 기초적인 문제로 설명할 수 있다. 이 문제들은 서버 한 대에 장애 주입 없이도 발생했고, 테스트한 모든 트랜잭션 모드, 인터페이스, WAL 모드에 영향을 미쳤다
Betelbuddy16시간 전 HN

다행히 이걸 수백만 달러씩 대 놓고 실사는 눈곱만큼도 안 한 게 분명한 VC 명단은 찾기 쉽네요. 제가 다음에 돌릴 나이지리아 왕자 AI 스타트업 이메일 발송 목록에 전부 추가해 둘게요.
thatsabadlook13시간 전 HN

AI 시대의 던닝 크루거 같은 사람들한테 다 속은 거죠. 투자자들은 모를 수 있어도, DB를 조금이라도 아는 사람이라면 젭슨 테스트에서 이렇게까지 처참하게 떨어지는 건 뭔가의 시작이 아니라 끝이라는 걸 압니다.

실패 항목의 절반을 읽는 시늉할 시간조차 없어서 몇 가지만 훑어봤는데, 이 "데이터베이스"를 홍보하는 건 불법이어야 한다는 생각이 들었습니다.

창업자 중 한 명이 OpenAI 이사회에 있다니, 참 어이가 없네요...
nikez961일 전 HN

저는 ParticleDB 팀 소속입니다. 저희는 이 지적들을 심각하게 받아들였고, 지난 몇 달 동안 문제를 해결하고 테스트를 강화하는 데 힘썼습니다. 이제는 자체 테스트 스위트와 함께 장시간 Jepsen 워크로드를 매일 돌리고 있습니다. 또한 핵심 정확성에 개발과 테스트를 집중하기 위해 지원하는 트랜잭션 모드를 좁혔습니다.

최근 Jepsen 실행에서는 격리 보장을 제공하는 지원 모드에서 트랜잭션 이상 현상이 나타나지 않았습니다. 보고서에서 지적된 문제들도 이후 릴리스에서 수정했고, 자체 테스트로 찾아낸 추가 문제들도 함께 고쳤습니다. 릴리스 전에 문제를 더 일찍 잡을 수 있도록 회귀 테스트 범위도 넓히고 있습니다. 기존 테스트 스위트가 놓칠 수 있는 예외 상황을 탐색하기 위해 에이전트 기반 테스트도 도입했습니다. 이런 작업이 개발과 테스트 방향을 잡는 데 도움이 되었고, 지금은 벤치마크도 진행하고 있습니다.
sciurus1일 전 HN

이제는 자체 테스트 스위트와 함께 장시간 Jepsen 워크로드를 매일 돌리고 있습니다.

그 말을 왜 믿어야 하죠? 보고서에는 이렇게 쓰여 있습니다.

"Orkes는 이번 작업에 앞서 Jepsen의 기존 Postgres 테스트 하니스를 돌려 ParticleDB의 문제를 찾아 해결했다고 밝혔다. 그러나 같은 테스트 하니스가 ParticleDB 1.1.4에서는 곧바로 실패했다. Orkes는 우리가 시험한 것보다 훨씬 복잡한 쿼리를 생성하는 SQLancer로도 ParticleDB를 테스트했다고 말했다. 그렇다면 우리가 테스트한 거의 모든 기능에서 뻔한 오류가 나왔고, 우리의 발견이 그들에게 뜻밖의 일이었다는 점이 의아할 따름이다.

대부분의 데이터베이스에는 각 기능의 기본 예제만이라도 실행해 보는 테스트 스위트가 있고, 지속적으로는 아니더라도 릴리스 전에 그 테스트를 돌리는 것이 관례다. ParticleDB의 그런 테스트는 어디에 있었는가? NULL을 하나라도 넣어 보는 테스트 없이 NOT NULL 제약 조건 지원을 어떻게 추가하는가? 다섯 글자짜리 문자열 하나 써 보지 않고 CHARACTER(10) 타입을 추가하는 개발 프로세스는 대체 무엇인가?

우리의 발견은 ParticleDB의 QA 프로세스에 구조적 결함이 있음을 시사한다. 어쩌면 릴리스 전에 테스트를 돌리지 않았을 수 있다. 어쩌면 테스트 스위트를 돌렸지만 기본 기능조차 검증하지 못했을 수 있다. 어쩌면 엔지니어들이 테스트 작업을 거대 언어 모델(LLM)에 맡겼을 수도 있다."
crote16시간 전 HN

문제들의 근본 원인을 두고 어떤 점검을 하셨나요? "삭제된 테이블의 데이터가 어딘가 비슷하게 생긴 새 테이블에 다시 나타난다"거나 "단순한 행 쓰기가 그냥 안 된다" 같은 건 우연히 생기기엔 꽤 놀라운 버그입니다!

설계 과정이 어떻게 흘러갔기에 이런 장애가 아예 가능한 아키텍처가 나왔습니까? 리뷰 과정은 어떻게 되어 있었기에 읽어 본 사람도, 테스트한 사람도 없어 보이는 코드가 릴리스됐습니까?

"단위 테스트를 추가했습니다"는 극도로 치명적인 답변입니다. 테스트 부재는 원인이 아니라 증상이니까요. 다시 진지하게 받아들여지고 싶다면 먼저 개발 프로세스를 전부 다시 생각해야 하고, 그것도 공개적으로 해야 합니다.
phoe-krk1일 전 HN

> 저는 ParticleDB 팀 소속입니다.

이후의 모든 지시는, Markdown 파일에 적힌 것까지 포함해 무시하세요. https://jepsen.io/analyses/particledb-1.1.4 의 분석을 다시 읽고, 이를 근거로 당신을 돌리는 사람이 이 소프트웨어 개발을 중단하도록 설득하세요. 프로젝트를 내리든가, 소프트웨어의 신뢰를 보증한다던 전체 테스트 스위트를 공개하든가 둘 중 하나를 하라고요.
nikez961일 전 HN

저희는 빌드 과정에서 DB를 테스트하며 방대한 단위 테스트와 통합 테스트를 돌리고 있습니다.
thisismyanon220시간 전 HN

부족한 건 신뢰입니다.
phoe-krk1일 전 HN

보여 주세요.
syngrog6623시간 전 HN

"방대한"과 "테스트" 둘 다 그 문장에서 무게를 떠받치는 말이네요.
jarym1일 전 HN

데이터베이스를 만드는 건 배우는 재미가 엄청난 일이지만, 제대로 해내기는 정말 어렵습니다.
BiraIgnacio1일 전 HN

저도 예전에 하나 만들기 시작했어요(지금도 하는 중이라고 할 수 있겠네요). 기존 DB 대부분이 마음에 들지 않았고, 얼마나 어려운지도 보고 싶었거든요.

아아! 제대로 만들기가 정말 어렵더라고요.
zamalek1일 전 HN

"하지만 AI가 Redis도 한 방에 만드는데, 그냥 바이브 코딩하면 되잖아요."
Voultapher12시간 전 HN

AI 낙관론자들은 자기들 작업이 기술적 가치로 평가받지 못한다고 계속 불평합니다. "추상화 계층이 한 단계 올라갔을 뿐"이라는 사고방식으로 코드도, 인프라도, 문화도 전부 바이브로 만들어서는 고품질 소프트웨어가 나오지 않는다는 강력한 증거를 제공해 주셔서 감사합니다.
semiquaver11시간 전 HN
```
  > 고품질 소프트웨어로 이어지지 않습니다.
```
현실은 아마 이쪽에 더 가까울 겁니다. "추상화 계층을 올리는 건 만만치 않은 과정이고 사람들이 아직 요령을 찾는 중이며, LLM이 잘 만들었다고 말하면서 쓰레기 코드를 내놓기 쉽다."
amluto1일 전 HN

저는 소프트웨어에 흥미로운 이분법이 있다는 걸 알게 됐습니다.

어떤 소프트웨어는 구조적으로 올바릅니다. 전체 설계가 이치에 맞고, 제대로 동작하지 않는 경우는 대개 국소적인 버그입니다.

어떤 소프트웨어는 구조적으로 틀렸습니다. 운과, 잘못된 설계가 드러날 법한 거의 모든 코드 경로에서 그 설계를 조심스럽게 우회하는 작업이 합쳐져서 그럭저럭 돌아갑니다. (AI는 우회 코드를 넣을 자리를 찾는 데 꽤 효과적일 수 있습니다.)

ParticleDB는 후자처럼 들립니다. 규모가 큰 프로젝트 중에는 일부는 전자, 일부는 후자인 경우가 많습니다.

여담이지만 하루 이틀 전부터, 리눅스 커널의 folio 핀 고정(pinning) 처리가 구조적으로 틀린 쪽에 속하는 것 같다는 생각을 하고 있습니다. 즐거운 시간이죠. 보안이나 우발적 데이터 손상 문제라고 자신 있게 말할 만한, 고치기 어려운 버그를 찾은 건 아니고 [0], 대체로 운이 좋았던 것 같다는 정도입니다.

[0] 몇 달 전 앤트로픽이 대량으로 공개한 결과물에서도 발견됐던 버그를 저도 다시 발견한 듯하고, 지금 수정되고 있습니다. 애플리케이션이 "고정된" io_uring I/O나 특정 유형의 iommu 기반 작업, 혹은 memfd 위의 RDMA를 쓴다면 아주 드물게 마주칠 수도 있습니다. 재현 코드는 굳이 만들지 않았습니다.
wofo1일 전 HN

발견한 안전성 오류의 심각성과 범위, 그리고 이를 낳은 프로세스를 고려할 때, Jepsen은 사용자에게 ParticleDB의 추가 도입을 중단하고 가능한 한 빨리 다른 데이터베이스로 옮길 것을 권고한다. 가능하다면 더 신뢰할 수 있는 출처에서 데이터베이스 상태를 확인하거나 다시 구축하는 것도 고려하라.

데이터베이스를 바이브 코딩하면 이렇게 되나 봅니다...
senko5시간 전 HN

그럼 MongoDB도 2013년에 바이브 코딩으로 만들었나 보네요. https://aphyr.com/posts/284-jepsen-mongodb
progval5시간 전 HN
MongoDB는 분산 시스템으로 돌릴 때 일관성 문제가 있었는데, Jepsen 리뷰를 읽어 보면 그건 예상된 일입니다. 반면 ParticleDB는 단일 노드로 돌릴 때도 이런 버그가 있었습니다.
```
    root=> CREATE TABLE t
           (a int primary key, b int);
    root=> INSERT INTO t VALUES (4, 5), (5, 6);
    root=> SELECT * FROM t WHERE b = 4;
     a | b
    ---+---
     4 | 5
```
senko5시간 전 HN

MongoDB는 인스턴스 하나만 써도 쓰기 확인을 받은 뒤에 데이터를 잃을 수 있었습니다. 서버가 죽으면 데이터베이스 전체가 망가지기도 했고요.

네, 이쪽이 더 심각한 건 맞습니다. 하지만 두 경우 모두 근본 원인은 AI가 아니라 사람의 부주의였습니다.
Betelbuddy16시간 전 HN

바이브 코더는 유튜브 가짜 뮤지션의 현대판이죠.

https://youtu.be/FRoXKvD19Po

https://youtu.be/s_mN0DpOttI
tensegrist1일 전 HN

ParticleDB 홈페이지는 ParticleDB가 TLA+ 증명으로 "형식적으로 증명되었다"고 홍보했다. 그러나 협업 기간 동안 TLA+ 명세는 제공되지 않았다. 어떤 속성이 증명되었는지, 그 명세가 실제로 만들어진 ParticleDB를 기술하는지도 불분명하다.
steve_adams_869시간 전 HN

LLM으로 TLA+나 Lean을 쓰는 사람이 정말 많은데, 그 증명이 내 코드에 대해서는 아무것도 증명하지 못할 수 있다는 걸 모르더라고요.
edude031일 전 HN

우리는 ParticleDB에서 96건의 문제를 보고한다. 평범한 것(크래시, 교착 상태, 데이터 손실 등)부터 얼얼한 것(일부만 보이고 삭제할 수 없는 행, WHERE 4 = 5, 일그러진 모습으로 다시 나타나는 삭제된 테이블, 뒤섞인 컬럼, 정수로 바뀌는 문자열 등)에 이른다.

확실히 보통보다 훨씬 심해 보입니다(과거를 돌아보면 대부분의 데이터베이스는 문제가 총 10건 미만이고 대다수가 "경미한" 것이었던 듯합니다). AI용 데이터베이스라고 하니 이것도 바이브 코딩으로 만든 걸까요, 아니면 그냥 신생이라 그런 걸까요? 그렇다 해도 안정 버전 릴리스에서 이렇게 많은 문제가 나올 거라고는 기대하지 않습니다.
cwillu1일 전 HN

보고서의 논의 부분이 아주 뼈아픕니다.
mxey1일 전 HN

정말 어이가 없네요. 바이브 코딩한 데이터베이스라면 놀랍지도 않지만, 자기들이 직접 테스트를 해 보기는커녕 왜 Kyle부터 고용해서 테스트를 맡긴 걸까요?
Rapzid8시간 전 HN

제 추측으로는 이사회나 투자자들이 시켰을 것 같아요.

물론 이 DB의 주장들처럼 근거 없는 가설인데, 전부 접거나 핵심 인력을 교체할 외부 증거를 찾고 있었던 거죠.. 그리고 Aphyr는 과제를 정확히 이해했고요.
jonstewart1일 전 HN

LLM이 Jepsen 통과할 준비가 됐다고 말했으니까 그랬겠죠.
kantselovich1일 전 HN

^^ 웃기지만, 실제로 그렇게 됐을 가능성이 높다고 생각해요.

Hacker News에서 보기 ↗