지난 10년간 PostgreSQL의 메이저 릴리스 시점은 매우 예측 가능했다. 빨라야 9월 중순, 늦어도 10월 중순이었다. 그러나 올해는 다르다. PostgreSQL 19는 11월에야 나올 가능성이 높고, 프로젝트가 출시를 더 미룰 가능성도 완전히 배제할 수 없다. 더 눈에 띄는 것은 베타 기간 막바지에 꽤 큰 기능들이 연달아 되돌려졌다는 점이다. UPDATE/DELETE FOR PORTION OF, SQL 속성 그래프 쿼리(SQL/PGQ), ALTER TABLE의 MERGE/SPLIT PARTITION이 8월 27일에서 9월 15일 사이에 모두 리버트됐다. 기능 동결(매년 4월 8일) 직후의 리버트는 드물지 않지만, 여러 대형 기능이 이렇게 늦은 시점에 한꺼번에 빠지는 것은 이례적이다.
프로젝트에 참여하는 한 개발자는 그 원인을 LLM으로 지목한다. 모든 소프트웨어에는 버그가 있고, PostgreSQL은 CVS에서 변환된 git 이력만 30년을 넘길 만큼 크고 복잡하며 오래된 코드베이스다. 방대한 코드에는 그만큼 많은 버그가 숨어 있었고 이는 늘 사실이었다. 달라진 것은 그 버그를 찾아내기가 비교할 수 없이 쉬워졌다는 점이다. 고치는 일도 쉬워지긴 했지만, 찾는 속도만큼은 아니다.
커밋 통계가 드러내는 변화
숫자를 보면 변화가 분명하다. 2025년 4월 8일부터 9월 25일까지 master 브랜치에는 1037건, REL_18_STABLE에는 724건의 커밋이 있었다. 2026년 같은 기간에는 master에 1443건, REL_19_STABLE에 1169건이 들어갔다. 즉 기능 동결 이후 master에 들어간 커밋 수는 오히려 지난해보다 소폭 줄었는데, 백패치된 커밋은 60% 넘게 늘었다. 이전 릴리스로의 백패치도 마찬가지다. REL_17_STABLE은 2025년 248건이었던 반면, REL_18_STABLE은 2026년 433건으로 74% 넘게 뛰었다.
이 급증을 커미터들이 올해 실수를 더 많이 해서라고 보기는 어렵다. 글쓴이의 판단은 다르다. 커미터들의 보수성은 예년과 비슷했지만, 그들이 저지른 실수 중 훨씬 더 많은 것이 LLM에 의해 빠르게 발견됐다는 것이다. 또한 이는 최신 릴리스에 국한되지 않는다. 인터넷의 수많은 사람들이 LLM으로 찾아낸 버그를 보고하고 있고, 커미터들은 그것을 고치느라 매우 바빴다.
지연의 두 가지 메커니즘
출시가 늦어진 데는 두 가지 요인이 작동한다. 첫째, 발견되는 버그가 훨씬 많아지면서 수정에 드는 시간도 늘었다. LLM이 수정안을 초안으로 작성해줄 수는 있지만 그 패치가 늘 정확하거나 PostgreSQL의 표준에 부합하는 것은 아니다. 결국 사람이 검토하고 커밋해야 하는데, 그 사람들의 역량이 1년 사이에 갑자기 더 똑똑해진 것은 아니다. 둘째, 릴리스에 들어갈 내용을 검토하는 데 썼어야 할 시간이 보안 이슈와 백브랜치 버그 대응으로 빠져나갔고, 그 결과 v19 출시 전에 무엇을 되돌려야 하는지 판단하는 데 더 오랜 시간이 걸렸다.
글쓴이는 이번 지연 자체는 크게 걱정할 일이 아니라고 본다. 길게 보면 짧은 지연이고, 무엇보다 품질에 대한 프로젝트의 집착에서 직접 비롯된 결과이기 때문이다. 오히려 더 불편한 질문은 장기적인 그림에 있다. 사람이 40년간 찾지 못한 버그를 LLM이 능숙하게 찾아내는 상황에서, 과연 이 격차를 따라잡을 수 있을까. 그리고 그 와중에 PostgreSQL은 어떻게 혁신을 이어갈 수 있을까. 글쓴이는 지금으로서는 답을 모른다고 솔직히 인정한다.
흥미로운 역설도 있다. 그는 PostgreSQL 코드베이스를 자신이 다뤄본 가장 깨끗하고 품질 높은 코드로 꼽으며, AI가 버그를 많이 찾아냈다는 사실이 그 평가를 바꾸지 않는다고 말한다. 오히려 코드 품질이 낮았다면 LLM이 찾아내는 결함은 더 많았을 것이라는 논리다. 즉 지금의 홍수는 코드가 나빠서가 아니라, 탐지 도구가 좋아졌기 때문에 드러난 것이다.
한국 실무자에게 주는 함의
이 이야기는 PostgreSQL만의 문제가 아니다. 글쓴이의 표현대로, 앞으로 모든 개발자가 작성하는 모든 기능은 AI의 검증을 받게 되고, 과거라면 영영 묻혔을 결함이 이제는 몇 시간 만에 드러날 수 있다. 데이터베이스를 운영에 쓰는 한국 팀에게 당장의 교훈은 두 가지다. 하나는 메이저 릴리스 일정이 예년처럼 자동으로 맞아떨어진다고 가정한 채 마이그레이션 계획을 짜서는 안 된다는 것, 다른 하나는 마이너·백패치 릴리스의 중요성이 전보다 커졌다는 것이다. 버그가 더 빨리 발견되고 더 활발히 백패치된다는 것은, 안정 브랜치를 꾸준히 따라가며 패치를 적용하는 운영 습관의 가치가 그만큼 올라갔다는 뜻이기도 하다. LLM발 버그 발견은 성숙한 오픈소스 프로젝트에 부담인 동시에, 품질을 끌어올릴 기회라는 양면을 함께 안고 있다.