지금까지 읽은 Jepsen 보고서 중 가장 충격적이며, 4.5절 “LLM Tradeoffs” 전체를 회사 문에 붙여놓고 싶음. 좋은 구절이 너무 많지만, 4.3절의 이 대목이 핵심을 가장 잘 보여줌.
“대부분의 데이터베이스에는 각 기능의 기본적인 사용 예제라도 검증하는 테스트 모음이 있고, 상시 실행까지는 아니더라도 출시 전에는 실행하는 것이 관례임. ParticleDB에는 그런 테스트가 어디 있었나? NULL 값을 하나라도 삽입하는 테스트 없이 어떻게 NOT NULL 제약 조건을 지원할 수 있나? 다섯 글자짜리 문자열도 넣어보지 않고 CHARACTER(10) 타입을 추가하는 개발 절차는 대체 무엇인가?”
애초에 Orkes가 왜 Jepsen에 의뢰했는지 의문임. 미켈란젤로에게 변기 도색을 맡긴 격인데, 자기 제품의 가장 기초적인 결함조차 어떻게 이토록 모를 수 있을까? 팀 전체가 AI에 대한 망상에 깊이 빠져 에이전트로만 작업을 접하고, 현실과 완전히 단절된 듯한 인상을 받음.
LLM 도입 광풍에 흔히 희생되는 기술 문서 작성도 Kyle이 제대로 평가해줘서 반가움.
지난주 나온 the previous Jepsen report는 같은 업체의 다른 소프트웨어를 다뤘고, 그쪽은 결함이 덜했음. ParticleDB는 Conductor를 지원하기 위한 제품이므로 Conductor를 철저히 검토하려면 함께 살펴보는 게 타당함. Conductor는 다른 데이터베이스도 사용할 수 있고 Jepsen은 Postgres로 테스트했으므로, ParticleDB를 별도로 검사하는 것 역시 합리적임.
알려진 결함을 해결하거나 내부 검토를 요청하기도 전에 외부 컨설턴트부터 부르는 단절을 몇 번 본 적이 있음. 다만 사업 관점에서만 보면 그렇게 나쁜 선택인지 모르겠음. 특정 검토가 필요한데 내부 인력이 시간을 낼 수 없고 정규 인력을 늘리고 싶지도 않다면, 컨설턴트가 기본적인 문제나 이미 알려진 문제까지 찾아내는 것도 나쁘지 않을 수 있음.
상황마다 생각이 달랐으며, 목적에 맞게 돈을 쓰는 것과 무모한 짓 사이의 경계는 모호함.
AI는 보통 무엇이든 과도하게 테스트하려 드는 편임. 이건 AI의 실패보다는 회사가 의도적으로 테스트를 생략한 실패에 더 가까워 보임.
“Jepsen은 ParticleDB의 추가 배포를 중단하고 가능한 한 빨리 다른 데이터베이스로 이전할 것을 권고함.” 배포 중단과 이전이 맞는 결론으로 보임.
데이터베이스 개발사가 기초적인 자체 테스트조차 하지 않고 Jepsen에 의뢰하게 된 경위가 궁금함. 이 경우에는 아마 “LLM이 시켜서”였을지도 모름. LLM에 Jepsen식 분석을 먼저 시켜보지도 않은 걸까? 실제 Jepsen 수준에는 한참 못 미치겠지만, 이 중 상당수는 잡아냈을 듯함. 아니면 LLM이 이미 분석했다고 하자 그대로 믿은 걸까?
그런데 보고서에는 “Orkes는 이번 작업에 앞서 Jepsen의 기존 Postgres 테스트 하네스를 실행해 ParticleDB의 문제를 찾고 해결했다고 밝혔음”이라고 적혀 있음.
나도 보고서에서 다뤄보려고 이 부분을 물어봤음. 같은 Postgres용 Jepsen 테스트를 ParticleDB에 돌렸는데, 데이터베이스를 설정하고 연결하기까지 조금 손이 갔지만 일단 연결되자 온갖 종류의 안전성 위반을 쏟아내기 시작함. 어떻게 통과시켰다는 건지 모르겠음!
“대부분의 Jepsen 분석 때와 마찬가지로 Orkes 엔지니어들은 Conductor에서 발견된 버그의 원인과 해결 방법을 상세히 설명했음. 하지만 ParticleDB에서 발견된 거의 모든 문제에 대해서는 원인이나 해결 방법을 설명하지 못하는 듯했음.” 이 대목은 당혹스러움. 결정론적 시뮬레이션 테스트(DST) 와 Antithesis 같은 도구에 의존하면 버그를 얼마나 줄일 수 있을까? Twitter 분위기만 순진하게 받아들이면 ‘데이터베이스 + AI + DST + 정형 기법 = 버그 소멸’인데, 실제로 어디까지 가능한지 궁금함.
그래도 결국 이런 방식으로 만든 데이터베이스를 신뢰하기는 어려울 것 같음.
DST는 버그를 찾는 데 도움이 됐을 것임. 기본적인 수동 QA만 했어도 도움이 됐을 것임! 대부분은 새 노드를 띄우고 셸에 SQL 쿼리 몇 개만 입력하면 드러나는 문제였음.
하지만 버그 발견과 원인 이해는 다름. 원인을 이해하려면 관련 코드를 읽거나, 적어도 시스템의 동작 원리를 머릿속에 제대로 그릴 수 있어야 함. 대략 2025년까지는 의뢰사들도 버그를 고치려면 보통 코드를 읽고 이해해야 했지만, AI를 쓰면 버그 보고서를 Codex에 붙여 넣고 “고쳐”라고 하면 됨.
직접 겪어보니 실제로 효과는 있음! ParticleDB는 분석을 시작할 때보다 지금 훨씬 안전해졌음. 다만 이런 AI 개발 방식이 사람이 이해하며 개발하는 만큼 견고한 절차라고 보지는 않음. LLM 의존도가 높은 몇몇 의뢰사와 일해보면, “고쳤다”는 버그가 계속 발생하거나 특정 사례만 해결되고 일반적인 발생 패턴은 남거나, 수정으로 더 이상한 동작이 생기는 일이 잦음.
이렇게 쉽게 찾을 수 있는 결함을 모두 놓치고도 보고서에 인용된 주장을 자신 있게 했다는 게 믿기지 않음. 그런 데이터베이스를 홍보한 것부터 의아하며, 분석 비용까지 지불했다는 사실은 더 놀라움. 대체 어떤 동기였다고 보는지 궁금함.
처음부터 끝까지 감으로 개발했다면 왜 LLM에 Jepsen식 분석을 시키지 않았을까? 적어도 그런 검증이 필요하다는 건 알았던 셈임. 마케팅에서 모호한 보장을 그토록 많이 내세울 수 있는 이유는 뭘까? 단순히 경험과 지식이 부족해서인지, 그 이상인지 궁금함.
아쉽지만 Kyle이 이런 질문에 답하는 것은 직업윤리상 적절하지 않을 것 같음. 맡은 일은 데이터베이스의 결함을 찾는 것이었고, 이들에게 지금도 앞으로도 데이터를 맡겨서는 안 된다는 사실을 충분히 보여줬음.
“발견된 안전성 오류의 심각성과 범위, 그리고 이를 만들어낸 개발 절차를 고려해 Jepsen은 ParticleDB의 추가 배포를 중단하고 가능한 한 빨리 다른 데이터베이스로 이전할 것을 권고함. 더 신뢰할 만한 원천 데이터가 있다면 이를 바탕으로 데이터베이스 상태를 검증하거나 재구축하는 것도 고려해야 함.”
Orkes의 동기를 추측하지 않고도 사용자에게 명확히 경고한 셈임. 그래도 이런 일이 애초에 어떻게 벌어질 수 있었는지는 정말 알고 싶음! 어쩌면 그저 “AI 맹신자들이 데이터베이스도 바이브 코딩으로 만들 수 있다고 생각했다”가 전부일지도 모름.
RSS 피드를 만들어 주면 좋겠음. 2014년쯤부터 Jepsen 글을 읽어 왔는데, 이렇게 많은 글을 놓친 줄 몰랐음.
ParticleDB 1.1.4는 Postgres 호환 데이터베이스라고 했지만, 실제로는 혼란의 집합체에 가까웠음. 측정한 거의 모든 측면에서 심각한 트랜잭션 이상 현상이 빈번하게 발생함.
커밋된 쓰기 유실, 내부 일관성 위반, G1a(중단된 트랜잭션 읽기), G1b(중간 상태 읽기), P4(갱신 유실)가 반복적으로 관찰됨. 추가 작업이 성공한 값도 이후 같은 키를 읽으면 사라지곤 했음. G0, G1c, G-Single, G2-item 등 모든 종류의 순환 이상 현상이 추론됐지만, 상당수는 쓰기 유실 같은 더 근본적인 결함으로 설명 가능함. 장애 없는 단일 서버에서도 발생했고, 시험한 모든 트랜잭션 모드·인터페이스·WAL 모드에 영향을 줌.
ParticleDB 팀의 일원임. 결과를 심각하게 받아들여 지난 몇 달간 수정과 테스트 강화에 집중했음. 이제 자체 테스트와 함께 Jepsen 부하 테스트를 매일 지속적으로 실행하고, 핵심 정확성에 개발·검증을 집중하도록 지원 트랜잭션 모드도 줄였음.
최근 실행에서는 격리 수준을 보장하는 지원 모드에서 트랜잭션 이상 현상이 발견되지 않았음. 보고서의 결함과 자체 테스트에서 추가로 찾은 결함도 후속 릴리스에서 수정함. 출시 전에 잡아내도록 회귀 테스트 범위를 넓히고, 기존 테스트가 놓칠 경계 사례를 탐색하는 에이전트 기반 테스트도 도입함. 이 작업을 바탕으로 개발과 테스트를 진행하고 있으며, 현재 벤치마크도 작업 중임.
아마추어가 바이브 코딩으로 만든 건 아닌지 궁금함.
데이터베이스 구현은 배우는 과정이 무척 재미있지만, 올바르게 만드는 일은 정말 어려움.
이 테스트는 출시 전 빌드와 일부 실험적인 동시성 모드를 대상으로 수행됐음. 이후 엔진을 재설계했고 해당 결함은 모두 수정함.
키-값 처리에서는 Redis보다 빠르며, 측정 수치상 ClickBench 최상위권에 오를 만함. 공식 결과 제출도 진행 중임.
소프트웨어에는 흥미로운 구분이 있음. 설계부터 올바른 소프트웨어는 전체 구조가 타당하고, 작동하지 않는 부분도 대체로 국소적인 버그임. 반면 설계부터 잘못된 소프트웨어는 운에 기대거나, 잘못된 설계가 드러날 수 있는 코드 경로마다 우회책을 넣어서 작동함. AI는 이런 우회책을 넣을 위치를 찾는 데 꽤 효과적일 수 있음.
ParticleDB는 후자에 가까워 보임. 대규모 프로젝트 상당수도 두 종류의 부분이 섞여 있음.
지난 하루 이틀 동안 Linux 커널의 folio 고정 처리도 후자에 속하는 것 같다고 고민 중임. 보안이나 우발적인 데이터 손상으로 이어질 법한, 고치기 어려운 버그를 찾은 것은 아니지만, 이 역시 대체로 운이 좋은 덕분처럼 보임.
다만 몇 달 전 Anthropic이 대량으로 공개한 자료에서도 찾았던 버그를 재발견한 듯하며, 현재 수정 중임. 애플리케이션이 memfd에 “fixed” io_uring I/O나 특정 IOMMU 기반 작업, 어쩌면 RDMA를 수행한다면 드물게 마주칠 가능성이 있음. 재현 코드는 따로 만들지 않았음.
Jepsen은 발견한 안전성 결함의 심각성과 범위, 그리고 이를 낳은 개발 과정을 근거로 ParticleDB 추가 배포 중단과 신속한 다른 데이터베이스로의 이전을 권고함. 더 신뢰할 만한 원본이 있다면 데이터베이스 상태를 검증하거나 재구축하는 것도 고려하라고 함.
데이터베이스를 바이브 코딩하면 이런 결과가 나오는 건가 싶음.
ParticleDB 홈페이지는 TLA+ 증명으로 형식적으로 검증됐다고 홍보했지만, 협업 기간 중 제공된 TLA+ 명세는 없었음. 어떤 속성을 증명했는지, 그 증명이 실제 구현된 ParticleDB를 기술하는지도 불분명함.
ParticleDB에서 96개 결함을 발견했다고 함. 충돌·교착 상태·데이터 유실부터, 일부만 보이면서 삭제할 수 없는 행, WHERE 4 = 5, 변형된 모습으로 되살아나는 삭제된 테이블, 뒤섞인 열, 정수로 바뀌는 문자열까지 다양함.
이전 결과를 보면 대부분 데이터베이스는 결함이 10개 미만이고 상당수가 비교적 경미한 편이라, 이번은 확실히 평소보다 심각해 보임. AI용 데이터베이스라 바이브 코딩으로 만든 것인지, 단지 신생 제품이라 그런 것인지 궁금함. 새 제품이라 해도 안정 릴리스에서 이 정도로 많은 결함은 예상하기 어려움.
보고서의 논의 부분은 특히 신랄함.
이 정도로 엉망이라는 게 놀라움. 바이브 코딩한 데이터베이스라면 이상하지 않을 수도 있지만, 자체 테스트부터 해보지 않고 Kyle에게 검증을 의뢰한 이유가 뭘까?
바이브 코딩한 데이터베이스라고 해도 이 정도면 놀라움.
바이브 코딩으로 만들었다는 구체적인 증거가 있을까? 너무나 명백해 보이긴 하지만, 인간의 오만과 심각한 무능만으로 생긴 결과일 가능성은 실제로 배제했는지 궁금함.
요즘처럼 강력한 에이전트가 있는데, 쉽게 잡을 수 있는 결함부터 확인하지 않고 외부 검토를 요청하다니 이해하기 어려움. 지금은 자동화된 버그 탐색을 상당히 깊은 수준까지 진행하고, 전체 테스트를 자체적으로 수행할 수도 있을 듯함.
내가 알기로는 Orkes가 협업 전에 실제로 AI 에이전트에 ParticleDB 자체 테스트를 맡겼음.