PostgreSQL 핵심 커미터 로버트 하스(Robert Haas)가 10월 30일 블로그에 올해 메이저 버전이 왜 늦어지는지 설명하는 글을 썼다. 지난 10년간 PostgreSQL 메이저 버전은 9월 중순에서 10월 중순 사이에 나왔지만, PostgreSQL 19는 11월로 넘어갈 가능성이 높고 프로젝트 측이 더 미룰 수도 있다. 그가 든 이유는 한 줄로 요약된다.
“The short answer is that LLMs happened.”(간단히 말해, LLM이 등장했다는 것이다.)
하스는 현재 데이터브릭스(Databricks)의 시니어 프린시펄 소프트웨어 엔지니어다. 이 글은 그의 개인적인 판단이며, 새로운 출시 일정은 제시하지 않았다.
마지막 한 달 동안 주요 기능 세 개가 철회됐다
기능 동결(feature freeze)은 매년 4월 8일이며, 동결 이후 기능을 철회하는 일 자체는 드물지 않다. 올해 다른 점은 시기와 규모다. 8월 27일부터 9월 15일 사이에 주요 기능 세 개가 연달아 되돌려졌다.
UPDATE/DELETE FOR PORTION OF- SQL 속성 그래프 쿼리(SQL/PGQ)
ALTER TABLE ... MERGE PARTITION / SPLIT PARTITION
하스에 따르면 예년에도 철회는 있었지만, 이렇게 늦은 시점에 큰 기능 여러 개를 한꺼번에 빼는 일은 드물었다.
커밋은 60% 늘었지만 커미터가 부주의해진 것은 아니다
그는 집계 기간을 매년 4월 8일부터 9월 25일로 고정하고 두 해의 수정량을 비교했다. 지난해 REL_18_STABLE에 들어간 커밋은 724개, 올해 REL_19_STABLE에 들어간 커밋은 1169개로 60% 넘게 늘었다. 직전 안정 브랜치로 보면 지난해 REL_17_STABLE이 248개, 올해 REL_18_STABLE이 433개로 74% 넘게 증가했다.
하스는 커밋이 늘어난 것이 개발자들의 코드 품질이 나빠진 탓이라고 보지 않는다. 커미터들의 신중함은 예년과 비슷하고, 달라진 것은 발견 단계라는 것이 그의 판단이다. 많은 사람이 LLM으로 PostgreSQL의 버그를 찾아 곧바로 제보하기 시작했다.
“What's different now is that it's become vastly easier to find those bugs.”(지금 달라진 점은 그런 버그를 찾기가 훨씬 쉬워졌다는 것이다.)
이 인과 설명에는 빈틈이 있다. 커밋 기록에는 버그를 누가 어떤 도구로 찾았는지가 남지 않고, 글에도 LLM 제보가 차지하는 비중은 나와 있지 않다. 위의 증가율은 실측치이고, ‘주된 원인은 LLM’이라는 것은 베테랑 커미터의 관찰이다.
병목은 사람이 하는 검토
지연은 두 단계로 일어난다. 첫째, 버그가 많아지면 수정에 시간이 더 든다. LLM이 패치 초안을 쓸 수는 있지만 패치가 반드시 맞다고도, 프로젝트 규정에 맞는다고도 할 수 없고, 결국 커미터가 하나하나 검토한 뒤에야 병합할 수 있다. 둘째 단계는 더 눈에 띄지 않는다. 새 버전의 내용을 검토하는 데 썼어야 할 시간을 보안 문제와 구 브랜치의 결함이 차지하면서, 어떤 기능을 철회할지 판단하는 일도 뒤로 밀렸다.
며칠 전 화제가 된 Epoch AI의 Firefox 실험과 나란히 놓고 볼 만하다. Epoch가 측정한 것은 공격 쪽으로, GLM 5.3으로 패치가 공개된 뒤의 시간 창 안에 익스플로잇을 쓰게 했고 버전당 연산 비용은 약 1000달러였다. 하스가 말하는 것은 유지보수 쪽이다. 같은 능력이 수십 년 된 프로젝트에 적용되면 제보량이 먼저 늘고, 코드를 검토할 수 있는 사람의 수는 그만큼 늘지 않는다. 양쪽에 공통된 변수는 취약점을 찾는 비용이며, 이 비용이 수정 비용보다 빠르게 떨어졌다.
중국 팀에게도 먼 이야기가 아니다. 적지 않은 클라우드 데이터베이스 제품이 PostgreSQL을 기반으로 자체 개발하고 있어, 업스트림 반영량이 60~70% 늘면 다운스트림에서 패치를 따라가는 작업량도 그만큼 커질 수 있다. 영향이 얼마나 될지는 아직 어느 업체도 수치를 내놓지 않았다.
40년치 누적 문제가 장기적 부담이다
하스는 이번 지연 자체에는 크게 긴장하지 않는다. 긴 호흡으로 보면 오래 늦어지는 것이 아니며, 품질을 고집하는 프로젝트의 태도에서 비롯된 일이라고 말했다. AI가 이런 문제를 찾아냈다고 해서 코드베이스의 품질에 대한 평가가 바뀐 것은 아니라는 점도 강조했다.
그를 불안하게 하는 것은 그다음이다. 이 프로젝트에는 사람이 찾지 못한 버그가 약 40년치 쌓여 있고, LLM은 그중 상당수를 캐낼 수 있다. 그의 표현으로는 “how are we ever going to catch up”(우리가 어떻게 따라잡을 수 있을까)이다. 앞으로는 모든 새 기능이 AI의 검토를 거치게 될 텐데, 이는 부담이면서 코드를 더 탄탄하게 만들 기회이기도 하다. 그는 해법을 내놓지 않았고, 자신을 포함해 많은 사람이 방법을 찾고 있다고만 말했다.
PostgreSQL 19가 정확히 언제 나올지는 릴리스 팀의 다음 공지를 기다려야 한다.
참고 출처: 로버트 하스 개인 블로그, CocoLoop, Epoch AI 공개 실험 보고서. 브랜치별 커밋 통계는 하스의 글이 제시한 집계 기준을 따랐으며 별도로 재계산하지 않았다.