PostgreSQL 19, LLM이 버그를 쏟아내면서 11월로 연기
- PostgreSQL 19 릴리스가 11월로 밀림. 지난 10년간 9월 중순에서 10월 중순 사이에 나오던 릴리스 주기가 처음으로 어긋남
- 8월 27일에서 9월 15일 사이에 UPDATE/DELETE FOR PORTION OF, SQL/PGQ, ALTER TABLE MERGE/SPLIT PARTITION 등 대형 기능 3개가 베타 막바지에 리버트됨. 기능 동결 직후 리버트는 흔하지만 이렇게 늦게 여러 개가 빠지는 건 이례적임
- 2025년 4월 8일에서 9월 25일 사이 master 브랜치 커밋은 1037건, REL_18_STABLE은 724건이었는데, 2026년 같은 기간에는 master 1443건, REL_19_STABLE 1169건으로 백패치 커밋이 60% 넘게 늘어남
- REL_17_STABLE 248건이던 것이 1년 뒤 REL_18_STABLE 433건으로 74% 넘게 증가함. LLM으로 버그를 찾은 인터넷 사용자들의 리포트가 쏟아진 결과임
- 작성자 Robert Haas는 지연 원인을 두 가지로 봄. LLM이 만든 수정안도 사람이 검토해야 하고, 릴리스에 들어갈 코드를 살필 시간이 보안 이슈와 백브랜치 버그 대응으로 빠졌음. 40년치 버그를 어떻게 따라잡을지는 아직 답이 없음
Hacker News opinions
진짜 문제는 검증 확장인 것 같음. 발견은 더 이상 병목이 아닌데, 같은 소수 메인테이너가 리포트 검증하고 패치 리뷰하니까 버그 리포트가 늘어난다고 수정이 빨라지진 않더라.
AI는 버그 찾기 같은 읽기 작업엔 좋은데 기능 추가 같은 쓰기 작업은 검증이 훨씬 어렵다고 봄.
검색 작업의 흔한 오류는 누락인데 그건 확인하기 진짜 어려움. 기능은 직접 실행해보면 해피 케이스는 확인되니까 사정이 다름.
이건 AI가 코드를 쓴 게 아님. 지연 공지에서 코드는 AI 없이 작성됐다고 분명히 했고 AI는 리뷰와 버그 발견에만 관여했음. Postgres에 slop 이슈가 있었다는 식으로 말하는 건 틀렸음.
나는 AI 훨씬 전에 Postgres RC에서 malformed json이 jsonb 쓸 때 서버 프로세스를 segfault 내서 클러스터 전체가 내려간 버그를 찾았음. 그때는 기능을 뜯어내는 대신 그냥 고쳤는데 이번엔 과잉 반응처럼 보임.
RC 단계에서 세그폴트가 나오면 기능을 뜯어내는 게 거의 유일한 선택지임.
사람 손이 부족해서 새 기능이 예전만큼 테스트되지 못한 게 문제임. LLM이 기존 코드에서 보안 이슈까지 계속 찾아내니 백로그를 먼저 정리하는 게 맞고 그게 끝나면 일정도 돌아올 거임.
나는 AI의 사회적, 지적 영향에 별로 긍정적이지 않음. 그래도 시그널 품질이 높다면 혁신을 잠시 멈추고 버그 카운트를 태우는 게 낫다고 봄.
시그널 품질이 뭔지는 모르겠음. 버그가 유효해도 사소하고 우선순위가 낮을 수 있음. 모든 버그를 고칠 필요는 없다는 게 함정임.
이게 오히려 좋은 거 아닌가. 릴리스 주기가 좀 흔들리는 것보다 40년간 숨어 있던 버그를 고치는 게 나음.
지연이 고품질 리포트 때문인지 저품질 리포트 트리아지 부담 때문인지 글이 명확하지 않음.
우리 회사도 보안 작업이 폭증해서 기능 개발을 전면 중단했음. 이 파도를 넘기면 더 안전한 소프트웨어로 갈 수 있겠지만 지금은 정신없음.
바이브 코딩 열풍인데 Postgres 대안이 안 나온 게 신기함.
왜 나오겠음. Postgres는 무료고 잘함. pgrust 같은 대안도 있지만 논쟁적임. 바이브로 프로젝트를 만들 수는 있어도 유지할 수는 없음.