스크립트
00:00:00누군가 Rust로 Postgres를 재구축했는데, 출시된 버전이 무려 46,000개의 Postgres 회귀 테스트 쿼리를 모두 통과했다고 합니다.
00:00:08일반 PSQL과도 잘 작동하고, 기존 Postgres 18.3 데이터 디렉토리도 불러올 수 있죠.
00:00:14생산 환경에서 바로 써도 될 것 같지만, 실제로는 그렇지 않습니다.
00:00:17하지만 이 프로젝트의 가장 흥미로운 버전은 아직 출시조차 되지 않았습니다.
00:00:21도대체 무엇을 보고 있는 걸까요? Postgres의 미래일까요, 아니면 단순한 AI 실험일까요?
00:00:30이것이 왜 중요한지 이해하려면, 먼저 현재의 문제를 알아야 합니다.
00:00:36Postgres는 역대 최고의 데이터베이스 중 하나라는 사실을 부정할 수 없죠.
00:00:40하지만 거의 40년에 달하는 아키텍처와 약 100만 줄의 C 코드를 안고 있기도 합니다.
00:00:46모든 클라이언트 연결마다 별도의 백엔드 프로세스가 생성됩니다.
00:00:49이러한 격리는 유용하지만, 메모리 오버헤드가 커지고 커넥션 풀링 사용에 대한 압박이 있으며,
00:00:56병렬 작업 간 상태 공유가 어렵다는 단점도 있습니다.
00:01:00PGRust는 다른 길을 선택했습니다.
00:01:02Postgres의 동작과 클라이언트 경험, 디스크 형식은 유지하면서 내부 엔진만 Rust로 교체하는 것이죠.
00:01:09이건 Postgres 확장 프로그램이 아닙니다.
00:01:11단순히 기능을 얹은 것도 아니죠.
00:01:13완전히 별개의 구현체로서 Postgres처럼 동작하려 노력하는 프로젝트입니다.
00:01:18며칠 전 다뤘던 Bun이 전체 코드베이스를 Rust로 재작성한 것처럼, 요즘 Rust 재작성 사례가 많이 보입니다.
00:01:25관련 영상은 여기 어딘가에 링크해 둘게요.
00:01:27자, 이론상으로는 그럴듯한데 실제로 Postgres처럼 느껴질까요?
00:01:31제대로 테스트해 보지 않았거든요.
00:01:32워크플로우를 효율화하는 코딩 도구에 관심이 있다면 구독해 주세요.
00:01:36관련 영상을 계속 올리고 있습니다.
00:01:38공식 Docker 이미지를 실행하고, 완전히 일반적인 PSQL 클라이언트로 접속해 보겠습니다.
00:01:43커스텀 설정은 전혀 없습니다.
00:01:44자, 접속했습니다.
00:01:46먼저 버전을 확인해 볼까요.
00:01:48보시는 것처럼 PGRust 최신 버전이라고 나옵니다.
00:01:53이제 테이블을 만들고 데이터를 삽입한 뒤, 쿼리 실행 계획을 살펴보겠습니다.
00:01:59터미널에서 바로 실행해 보죠.
00:02:01겉보기에는 Postgres와 전혀 다를 게 없습니다.
00:02:05같은 클라이언트, 같은 SQL, 같은 결과값이 나오니까요.
00:02:08쿼리 플래너가 인덱스 스캔을 선택했고, 실제 실행 통계까지 제공하는 모습입니다.
00:02:14이제 좀 더 흥미롭게 만들어 보죠. 10만 개의 행을 삽입하고 다른 쿼리를 실행해 보겠습니다.
00:02:20데이터 10만 행을 생성해서 준비했습니다.
00:02:23여기에 넣어보겠습니다.
00:02:25도대체 이 모든 게 무슨 의미일까요?
00:02:27좋은 질문입니다.
00:02:28현재의 초기 버전에서는 일반 Postgres보다 드라마틱한 성능 향상을 보기는 어렵습니다.
00:02:35더 큰 성능 향상은 아직 공개되지 않은 개발 버전에서 다루는데, '연결당 스레드' 모델을 채택하고 있죠.
00:02:43하지만 이 모든 것이 단순한 부분 구현이 아님을 증명합니다.
00:02:47공식 Postgres 회귀 테스트 스위트 46,000개를 모두 통과했습니다.
00:02:53실제 와이어 프로토콜을 사용하며 쿼리 플래너와 스토리지 엔진도 제대로 작동합니다.
00:02:59진짜 데이터베이스 서버인 셈이죠.
00:03:01단지 Rust로 쓰여있을 뿐입니다.
00:03:03이대로 발전한다면 속도 측면에서 상당한 성능 향상을 기대할 수 있습니다.
00:03:08그럼 여기서 드는 의문은, 왜 Postgres 확장 프로그램을 만들지 않았을까 하는 점입니다.
00:03:12확장 프로그램은 원래 Postgres 코어 위에 얹히는 방식이기 때문입니다.
00:03:16코드를 수정할 수 있는 포크(Fork) 방식도 있지만, 동일한 아키텍처를 물려받아 업스트림 Postgres를 계속 따라가야 하는 영원한 숙제를 안게 되죠.
00:03:25CockroachDB나 YugaByte 같은 사례가 있지만, 이들은 독립적인 분산 데이터베이스입니다.
00:03:31완벽한 드롭인(Drop-in) 호환성이 주된 목표는 아니죠.
00:03:35PG Rust는 다른 길을 갑니다.
00:03:37실제 Postgres의 동작 방식을 사양으로 삼고 있습니다.
00:03:41현재 릴리스는 Postgres 18.3을 타깃으로 합니다.
00:03:44기본 회귀 테스트와 격리 테스트를 통과했으며, 기존 Postgres 18.3 데이터 디렉토리를 불러올 수 있을 정도로 호환됩니다.
00:03:53더 큰 실험은 공개되지 않은 별도 버전에서 진행 중인데, Postgres의 '연결당 프로세스' 모델을 '연결당 스레드' 모델로 완전히 교체했다고 알려져 있습니다.
00:04:05기존 모델에서는 연결마다 고유한 프로세스가 생성됩니다.
00:04:09새 모델에서는 동일 프로세스 내의 각 스레드가 연결을 처리합니다.
00:04:14이렇게 하면 연결당 오버헤드가 줄고 데이터베이스 내 여러 부분이 정보를 공유하기 쉬워집니다.
00:04:21물론 여기엔 트레이드 오프가 존재하겠죠?
00:04:24별도의 프로세스는 연결 간에 유용한 안전장치를 만들어줍니다.
00:04:28하나의 프로세스가 실패해도 그 격리 덕분에 피해를 줄일 수 있죠.
00:04:32하지만 스레드 모델에서는 불안정한 확장 프로그램이나 메모리 버그가 서버 전체에 영향을 줄 수 있습니다.
00:04:38그러니 연결당 스레드가 무조건 좋은 것은 아닙니다.
00:04:41새로운 가능성을 열어주지만, 일부 안전장치를 제거할 수도 있으니까요.
00:04:45그다음은 이야기의 두 번째 큰 축인 AI입니다.
00:04:49마이클 말리스와 제이슨 시벨은 재작성 속도를 높이기 위해 코딩 에이전트를 적극 활용했습니다.
00:04:54공개된 버전은 의도적으로 기존 Postgres 구조를 많은 부분 따르고 있습니다.
00:04:59더 큰 아키텍처 변경을 시도하는 곳은 공개되지 않은 버전입니다.
00:05:03결국 진짜 실험은 'Rust로 Postgres를 더 빠르게 만들 수 있는가?'가 아닙니다.
00:05:08AI 덕분에 이렇게 대규모 재작성이 가능해졌을 때, 개발자들이 내부 아키텍처를 다시 생각할 수 있는가에 가깝습니다.
00:05:16그 정도로 AI가 깊게 관여했기 때문이죠.
00:05:19자, 이게 상황을 바꿀까요?
00:05:20그럴지도 모릅니다.
00:05:21이 부분은 좀 더 신중히 생각해야 합니다.
00:05:25출시된 버전은 최적화가 많이 된 상태는 아닙니다.
00:05:28주요 성능 수치는 아직 직접 테스트해 볼 수 없는 연결당 스레드 버전에서 나온 결과거든요.
00:05:36개발 측은 트랜잭션 워크로드에서 약 50% 향상된 성능을 주장합니다.
00:05:40분석용 워크로드에서는 Postgres보다 300배 빠르다고도 하죠.
00:05:45숫자는 놀랍지만, 그 결과를 뒷받침할 코드는 검증이나 벤치마크를 위해 공개된 상태가 아닙니다.
00:05:53그러니 여전히 추측이 많이 섞여 있는 거죠.
00:05:57온라인상 반응을 보면 거의 50대 50으로 나뉘어 이런 식의 질문들이 오가고 있습니다.
00:06:03방금 보신 것들은 GitHub의 이슈들입니다.
00:06:05이런 질문도 있죠, 그렇죠?
00:06:08아주 합리적인 질문입니다.
00:06:10이슈를 살펴보면 개발자들은 진지하게 이 작업을 완수하려는 의지를 보이고 있습니다.
00:06:15확실한 통계가 없다고 해서 그 수치들이 거짓이라는 의미는 아닙니다.
00:06:17다만 아직은 확실한 사실이 아닌 유망한 주장으로 받아들여야 한다는 뜻이죠.
00:06:20솔직히 정확한 배수가 가장 중요한 부분은 아닐 수도 있습니다.
00:06:24아이디어가 실제로 작동하는지 확인하기 위해 Postgres 프로젝트 전체를 바꿀 필요는 없으니까요.
00:06:28그 자유로움이 어떤 벤치마크 결과보다 더 가치 있을지도 모릅니다.
00:06:34PG Rust를 포함한 Rust 재작성에 대한 개발자들의 반응은 정말 뜨겁습니다.
00:06:38주요 Hacker News 토론은 수백 개의 포인트와 댓글을 받았지만, 여전히 반응은 엇갈립니다.
00:06:44양측 모두 타당한 논리를 펼치고 있죠.
00:06:50첫째, 회귀 쿼리를 모두 통과한 것은 진지한 성과입니다.
00:06:52Postgres 호환성을 주장하는 프로젝트는 정말 많습니다.
00:06:56그 말은 사실 거의 아무 의미가 없을 수도 있죠.
00:06:59하지만 PG Rust는 명확한 타깃이 있습니다.
00:07:01실제 Postgres 테스트가 곧 심판이니까요.
00:07:04이 재작성의 속도는 코딩 에이전트가 대규모 인프라 실험 비용을 완전히 바꿀 수도 있음을 시사합니다.
00:07:07한때 너무 비싸서 시도조차 못 했던 아이디어들이 이제는 가능해지고 있습니다.
00:07:13물론 다른 측면에서는, 테스트 통과가 곧 생산 환경에서의 신뢰를 의미하는 것은 아니라는 의견도 있습니다.
00:07:19그런 테스트들은 수년간의 복구, 복제 테스트나 쉬지 않고 몇 달씩 돌아가는 데이터베이스 운영을 대신할 수 없으니까요.
00:07:24알려진 테스트를 다 통과해도 누구도 예상 못한 상황에서 무너질 수 있습니다.
00:07:31수십만 줄의 코드를 생성하는 것과 확장 프로그램 호환성은 또 다른 거대한 장벽이죠.
00:07:37자, 그럼 운영 중인 Postgres 클러스터를 PG Rust로 교체해야 할까요?
00:07:42아니요, 절대 안 됩니다.
00:07:45프로젝트 자체가 프로덕션 수준이 아닙니다.
00:07:49그건 명시된 사실이죠.
00:07:51최적화도 완전히 되지 않았습니다.
00:07:53생태계도 미완성이죠.
00:07:54하지만 시도해 볼 가치는 있을까요?
00:07:56당연하죠.
00:08:02데이터베이스, Rust, 쿼리 실행, 호환성 테스트나 AI 개발에 관심이 있다면 직접 확인해 보세요.
00:08:03Docker 이미지를 실행하고,
00:08:03클라이언트 라이브러리를 테스트하며 소스를 읽어보는 것만으로도 의미가 있습니다.
00:08:10결론을 댓글로 남겨주세요.
00:08:16이 프로젝트는 어디로 향하고 있을까요?
00:08:18앞으로 더 많은 걸 Rust로 재작성하게 될까요?
00:08:20결과를 지켜보죠.
00:08:21이런 코딩 팁이 유익했다면 BetterStack 채널을 구독해 주세요.
00:08:23다음 영상에서 뵙겠습니다.
00:08:26시청해 주셔서 감사합니다.