--- title: "Postgres를 Rust로 다시 쓴 pgrust, 회귀 테스트 4만6000개 100% 통과" published: 2026-07-09T06:18:19.000Z canonical: https://jeff.news/article/4867 --- # Postgres를 Rust로 다시 쓴 pgrust, 회귀 테스트 4만6000개 100% 통과 Postgres를 Rust로 다시 구현하는 pgrust가 Postgres 18.3 기준 회귀 테스트 4만6000개 이상에서 기대 출력과 일치했다. 기존 Postgres 18.3 데이터 디렉터리로 부팅할 수 있을 정도의 디스크 호환성도 내세우지만, 아직 프로덕션용도 아니고 성능 최적화도 끝나지 않았다. - Postgres를 Rust로 다시 구현하는 pgrust가 꽤 큰 마일스톤을 찍었음 - 목표 버전은 Postgres 18.3이고, Postgres의 실제 회귀 테스트를 기준점으로 삼고 있음 - 이번 공개에서 내세운 숫자는 4만6000개 이상의 회귀 쿼리 100% 통과 - 그러니까 “대충 Postgres 비슷한 SQL 서버”가 아니라, Postgres가 기대하는 출력과 최대한 똑같이 맞추는 쪽으로 가고 있음 - 더 흥미로운 건 디스크 호환성까지 주장한다는 점임 - pgrust는 기존 Postgres 18.3 데이터 디렉터리에서 부팅할 수 있다고 설명함 - 데이터베이스 재구현에서 이건 꽤 센 주장임. 쿼리 문법만 흉내 내는 것보다 훨씬 아래 레이어를 맞춰야 하니까 - 다만 “가능하다”와 “운영에서 믿고 쓴다”는 완전히 다른 얘기라, 여기서 바로 갈아타자는 분위기는 아님 > [!IMPORTANT] > 이번 뉴스의 핵심은 Rust로 DB를 만들었다가 아니라, Postgres의 실제 회귀 테스트 4만6000개 이상에서 기대 출력과 일치했다는 점임. 데이터베이스 호환성 얘기에서 테스트 통과 숫자는 그냥 장식이 아님. - 프로젝트의 목표는 Postgres의 겉모습을 유지하면서 내부를 더 바꾸기 쉽게 만드는 쪽에 가까움 - “Postgres-shaped behavior”를 유지하고, 진짜 Postgres 테스트를 오라클처럼 쓰겠다는 방향임 - 구현 언어로 Rust를 쓰고, AI 보조 프로그래밍도 활용해서 서버 내부의 더 깊은 변경을 탐색한다는 설명이 붙어 있음 - 요즘 유행하는 “Rust로 다시 쓰면 안전해짐” 정도의 얘기보다, 기존 DBMS의 구조적 한계를 건드려보겠다는 색이 강함 - 로드맵에 올라온 아이디어들은 꽤 공격적임 - 멀티스레드 Postgres 내부 구조 - 내장 커넥션 풀링 - JSON-heavy 워크로드 지원 개선 - 빠른 fork와 branching 워크플로 - no-vacuum 스토리지 설계 같은 저장소 실험 - AI가 만든 SQL이나 나쁜 쿼리를 런타임에서 막는 guardrail - 갑자기 나쁜 실행 계획으로 튀는 현상을 줄이는 것 - 그런데 아직 프로덕션용은 아님. 이건 프로젝트 쪽에서도 분명히 선을 그음 - 성능 최적화가 아직 끝나지 않았다고 밝힘 - 기존 Postgres 확장과 PL/Python, PL/Perl, PL/Tcl 같은 절차형 언어 확장은 일반적으로 호환되지 않음 - 일부 bundled contrib 모듈은 이미 포팅됐지만, 확장 생태계 전체를 기대하면 아직 이른 단계임 > [!WARNING] > Postgres 확장에 기대는 서비스라면 지금 pgrust는 실험 대상으로 봐야 함. 회귀 테스트 통과와 확장 생태계 호환은 완전히 다른 산임. - 그래도 개발자 입장에서는 직접 만져볼 수 있는 재료가 꽤 있음 - WebAssembly 데모가 있고, Docker 이미지도 제공됨 - `malisper/pgrust:latest`는 현재 같은 릴리스를 가리키지만, 출시 이미지로는 `v0.1`을 고정해서 쓰는 흐름임 - Postgres 18 `psql` 클라이언트가 필요하고, 경로가 다르면 `PGRUST_PSQL`로 지정할 수 있음 - 이 프로젝트가 재밌는 이유는 “Postgres를 대체할 수 있나?”보다 “Postgres 내부를 어디까지 다시 설계할 수 있나?”에 있음 - Postgres는 워낙 성숙한 시스템이라, 호환성을 깨면 실험이 쉬워지고 호환성을 지키면 실험이 어려워짐 - pgrust는 어려운 쪽, 즉 기존 동작을 테스트로 맞춰가면서 내부 실험을 하겠다는 길을 택한 셈임 - 성공하면 Rust 기반 데이터베이스 구현체 하나가 생기는 데서 끝나지 않고, Postgres 자체의 미래 설계 논의에도 꽤 자극이 될 수 있음 --- ## 기술 맥락 - pgrust가 고른 핵심 전략은 “새 데이터베이스를 만들자”가 아니라 “Postgres처럼 동작하게 만들자”예요. 왜냐하면 데이터베이스에서는 SQL 한 줄의 미묘한 결과 차이도 실제 서비스 버그가 되기 쉬워서, 호환성 없는 재작성은 실무 가치가 확 떨어지거든요. - 그래서 Postgres 회귀 테스트를 오라클처럼 쓰는 선택이 중요해요. 4만6000개 이상의 쿼리에서 기대 출력과 일치했다는 건, 구현체 내부가 Rust로 바뀌었더라도 바깥에서 보이는 동작은 Postgres에 맞춰가고 있다는 뜻이에요. - 디스크 호환성도 같은 맥락이에요. 기존 Postgres 18.3 데이터 디렉터리에서 부팅할 수 있다면, 단순 SQL 호환을 넘어서 저장 구조와 메타데이터 해석까지 맞춰야 해요. 이게 되는 순간 마이그레이션 실험의 난이도와 의미가 확 달라져요. - 반대로 확장 호환성은 아직 큰 빈칸이에요. Postgres를 실무에서 쓰는 팀들은 확장, contrib 모듈, PL/Python 같은 절차형 언어에 기대는 경우가 많거든요. pgrust가 프로덕션용이 아니라고 선을 긋는 이유도 여기서 꽤 설득력이 생겨요. - no-vacuum 설계나 멀티스레드 내부 구조 같은 아이디어는 Postgres의 오래된 운영 부담을 건드리는 쪽이에요. 이런 실험은 기존 C 코드베이스에서 바로 하기 어렵기 때문에, Rust 재구현을 통해 더 과감한 내부 변경을 탐색하려는 흐름으로 보면 돼요. ## 핵심 포인트 - pgrust는 Postgres 18.3 호환을 목표로 하는 Rust 기반 Postgres 재구현 프로젝트다. - 4만6000개 이상의 Postgres 회귀 쿼리에서 기대 출력과 일치했다는 게 이번 핵심 마일스톤이다. - 기존 Postgres 18.3 데이터 디렉터리에서 부팅 가능한 디스크 호환성을 주장한다. - 확장 기능과 PL/Python, PL/Perl, PL/Tcl 같은 절차형 언어 확장은 아직 일반적으로 호환되지 않는다. - 프로젝트가 노리는 방향은 멀티스레드 내부 구조, 내장 커넥션 풀링, JSON 워크로드 개선, no-vacuum 스토리지 실험 같은 꽤 큰 수술이다. ## 인사이트 이건 당장 Postgres를 대체하겠다는 뉴스라기보다, Postgres의 동작을 그대로 맞춰가며 내부 구현을 Rust로 바꿔보는 실험이 4만6000개 테스트 지점을 통과했다는 신호에 가깝다. 데이터베이스 쪽에서는 호환성 테스트를 어디까지 통과했는지가 말뿐인 재작성과 진짜 시스템 실험을 가르는 선이라 꽤 흥미롭다.