Rust로 다시 태어난 Postgres, 가능성은?
Rust로 재작성된 Postgres(pgrust)가 46,000개 이상의 회귀 테스트를 통과하며 호환성을 입증함
LLM을 활용한 코드 생성 및 재작성 방식에 대한 커뮤니티의 회의론(Skepticism)이 제기됨
프로덕션 환경 도입에 대한 우려와 함께 학습 및 탐색 목적으로는 흥미롭다는 반응이 공존함
LLM 기반 재작성의 신뢰성 논쟁
개발자들은 LLM(Large Language Model)을 활용한 코드 생성 및 재작성 방식의 신뢰성에 의문을 제기하고 있습니다. 특히 AI가 생성한 7,000개 이상의 커밋은 코드 리뷰의 어려움을 야기하며, 실제 프로덕션 환경에서 발생하는 '실제 경험(Real-world Scars)'을 반영하지 못한다는 지적이 있습니다. 이는 테스트 통과 여부와는 별개로 장기적인 안정성과 신뢰성을 확보하기 어렵다는 의견으로 이어집니다.
스레드 기반 아키텍처와 성능 향상
새로운 pgrust 구현은 기존 Postgres의 프로세스당 연결 모델(Process-per-Connection Model) 대신 스레드당 연결 모델(Thread-per-Connection Model)을 채택했습니다. 이를 통해 트랜잭션 워크로드에서 기존 Postgres 대비 50% 향상된 성능을, 분석 워크로드에서는 약 300배 빠른 속도를 보인다고 합니다. 다만, 이 스레드 기반 아키텍처의 변경은 기존 회귀 테스트만으로는 완전히 검증되지 않는다는 의견도 존재합니다.
AGPL 라이선스 변경의 영향
기존 Postgres의 라이선스(PostgreSQL License)에서 AGPL-3.0으로 변경된 점에 대한 논의가 있습니다. AGPL은 오픈소스 소프트웨어의 자유를 강화하는 라이선스로 평가받지만, 기존 소스 코드에서 파생된 경우 원본 라이선스의 적용 여부와 호환성에 대한 우려가 제기되었습니다. 이는 프로젝트의 향후 라이선스 정책 및 커뮤니티 기여에 영향을 미칠 수 있는 중요한 부분입니다.
프로덕션 환경 도입의 현실적 장벽
현재 pgrust는 프로덕션 환경에 바로 적용하기에는 이르다는 것이 중론입니다. 성능 최적화가 미흡하고, 기존 Postgres 확장 기능(Extensions)과의 호환성이 부족하며, AI 코드 생성 방식에 대한 불신이 존재합니다. 따라서 학습 목적이나 특정 니치(Niche) 시장을 위한 탐색적 프로젝트로는 흥미롭지만, 실질적인 비즈니스 가치(Business Case)를 증명하기까지는 시간이 더 필요할 것으로 보입니다.
LLM 활용 코드 리뷰 및 기여의 어려움
LLM이 대량의 코드를 생성하면서 커밋 히스토리(Commit History)를 통한 코드 리뷰가 사실상 불가능해졌다는 지적이 있습니다. 개발자는 수천 개의 커밋을 일일이 확인하기 어렵고, 생성된 코드의 'unsafe' 블록 사용 빈도가 높아 근본적인 아키텍처 개선보다는 단순 트랜스파일링(Transpilation)에 그칠 수 있다는 우려가 제기됩니다. 이는 오픈소스 프로젝트의 투명성과 협업 방식에 대한 새로운 질문을 던집니다.