스크랩

Postgres를 Rust로 통째로 재작성한 pgrust, 회귀 테스트 100% 통과까지 왔다

Postgres를 Rust로 통째로 재작성한 pgrust, 회귀 테스트 100% 통과까지 왔다

핵심 요약

Postgres를 Rust로 재작성하는 프로젝트 pgrust가 의미 있는 이정표에 도달했어요. Postgres 18.3 호환을 목표로 하는 이 프로젝트는 46,000개 이상의 회귀 쿼리에서 Postgres의 예상 출력과 100% 일치하는 결과를 냈습니다. 단순히 비슷하게 동작하는 수준이 아니라, 기존 Postgres 18.3 데이터 디렉터리에서 그대로 부팅할 수 있는 디스크 호환성까지 갖췄다는 점이 인상적이에요.

pgrust는 무엇을 노리는 프로젝트일까?

pgrust의 목표는 단순한 '언어 갈아타기'가 아니에요. 30년 된 Postgres의 동작은 그대로 유지하면서, 내부 구조를 더 쉽게 바꿀 수 있는 기반을 만드는 것이 핵심입니다.

  • 목표 대상은 Postgres 18.3이며, 실제 Postgres 회귀 테스트를 동작 기준으로 삼음
  • 기존 Postgres 18.3 데이터 디렉터리에서 그대로 부팅 가능한 디스크 호환성 제공
  • Rust와 AI 보조 프로그래밍을 활용해 기존에는 손대기 어려웠던 깊은 서버 변경을 탐색

특히 원저자가 Hacker News에서 밝힌 아직 미공개 버전의 성과가 흥미로운데요. Postgres의 프로세스당 연결 모델 대신 연결당 스레드 모델을 구현했고, 트랜잭션 워크로드에서 Postgres보다 50% 빠르며 분석 워크로드에서는 약 300배 빠르다고 주장합니다. ClickHouse와 비교하면 아직 2배 느리지만, 따라잡을 수 있다고 보고 있어요.

아직은 실험 단계, 제한 사항도 분명해요

기대만큼 주의할 점도 확실합니다.

  • 프로덕션 준비 상태가 아니며, 성능 최적화도 아직 되어 있지 않음
  • 기존 Postgres 확장과 PL/Python, PL/Perl, PL/Tcl 같은 절차 언어 확장은 일반적으로 호환되지 않음
  • 일부 번들 contrib 모듈은 이미 포팅됐고, 시간이 지나며 호환 범위가 넓어질 수 있음
  • 라이선스는 AGPL-3.0으로, Postgres의 관대한 라이선스와 다르다는 점도 체크 포인트

직접 실행해보기

가볍게 맛보고 싶다면 두 가지 방법이 있어요.

  1. WebAssembly 데모: 브라우저에서 바로 pgrust.com에 접속
  2. Docker 이미지: malisper/pgrust:v0.1 이미지로 실행 (latest도 현재 같은 릴리스를 가리키지만, 고정 릴리스는 v0.1)
docker run -d --name pgrust -e POSTGRES_PASSWORD=secret malisper/pgrust:v0.1
docker exec -it -e PGPASSWORD=secret pgrust psql -h 127.0.0.1 -U postgres

소스 빌드도 가능한데, vendored Postgres 18.3 공유 디렉터리를 지정해 cargo build로 빌드하고, pgrust 자체의 --initdb로 데이터 디렉터리를 생성하는 방식이에요. 회귀 테스트는 저장소의 scripts/run-regression 스크립트로 직접 돌려볼 수 있습니다.

앞으로의 로드맵

로드맵에는 Postgres의 오래된 아키텍처 한계를 정면으로 건드리는 항목들이 담겨 있어요.

  • 멀티스레드 Postgres 내부 구조
  • 내장 연결 풀링 (PgBouncer 같은 별도 도구 없이!)
  • JSON 중심 워크로드 지원 개선
  • 빠른 포크와 브랜칭 워크플로
  • no-vacuum 설계를 포함한 저장소 실험
  • 잘못된 쿼리와 AI 생성 SQL을 위한 런타임 가드레일
  • 갑작스러운 나쁜 실행 계획 전환 감소

커뮤니티의 시선: 기대와 회의 사이

Hacker News에서는 뜨거운 토론이 벌어졌어요. 긍정적인 쪽에서는 "LLM으로 빠르게 프로토타입을 만들어 아키텍처 변경(스레딩 모델, 의존성 교체 등)의 가능성을 검증하는 흥미로운 개념 증명"이라고 평가합니다. 이미 많은 설계 결정이 내려진 소프트웨어를 재작성하는 것은 처음부터 만드는 것보다 훨씬 수월하다는 의견도 있고요.

반면 회의적인 목소리도 만만치 않습니다.

  • OLTP 50% 개선 수치에 대해 "MVCC를 깨는 절충이 숨어 있거나 fsync 설정 차이일 수 있다"는 의심
  • 회귀 테스트는 나쁜 I/O 패턴을 잘 잡아내지 못한다는 지적
  • 연결당 스레드 모델은 성능에는 유리하지만, 확장이 세그폴트를 내면 프로세스 하나가 아니라 데이터베이스 전체가 죽을 수 있다는 우려
  • 한 사람이 주도하는 대규모 재작성 프로젝트의 지속 가능성 문제

에디터의 한 줄 정리

pgrust는 당장 프로덕션에 쓸 물건은 아니지만, "AI 보조 프로그래밍으로 100만 줄 규모의 레거시 시스템을 재작성하고 재설계까지 시도할 수 있는가"라는 질문에 대한 가장 구체적인 실험 사례 중 하나예요. 회귀 테스트 100% 통과라는 검증 가능한 기준을 세웠다는 점만으로도 지켜볼 가치가 충분합니다.


원문: https://news.hada.io/topic?id=31296