'포스트그레SQL 19가 늦어진 건 AI 때문'…40년 묵은 코드에서 버그가 쏟아졌다
2026년 11월 3일원작 Robert Haas · Postgres 19 is late, and it's AI's fault ↗
3줄 요약
- AI가 40년 된 포스트그레SQL의 숨은 버그를 대량으로 찾아내 19 버전 출시가 11월로 밀렸다.
- 안정 브랜치 수정은 지난해보다 19는 60%, 18은 74% 넘게 늘었고 기능 세 개가 막판에 빠졌다.
- 찾기는 빨라졌지만 고치고 검토하는 일은 사람 몫이라, 모든 개발자가 수준을 올려야 한다.
포스트그레SQL 주 버전은 10년째 9~10월에 나왔지만 올해 19는 11월로 밀릴 전망이다. 커미터 로버트 하스는 블로그에서 이유를 'LLM이 나타났기 때문'이라고 썼다. 안정 브랜치 수정이 60~74% 늘고 기능 세 개가 베타 막바지에 빠졌다. 해커뉴스 800점 넘는 반응과 함께 개발자에게 무엇이 달라지는지 정리했다.
40년 묵은 코드에서 버그를 찾는 속도가 달라졌다
포스트그레SQL 커미터 로버트 하스는 올해 19 버전이 11월로 밀릴 것 같다며 이유를 '대규모 언어 모델(LLM)이 등장했기 때문'이라고 짚었다. 최근 10년간 주 버전은 9월 중순에서 10월 중순 사이에 나왔다. 코드는 크고 오래됐고, 늘 버그가 있었다. 달라진 것은 그 버그를 찾기가 훨씬 쉬워졌다는 점이라고 했다. 고치는 일도 쉬워졌지만 찾는 만큼은 아니라고 덧붙였다.
숫자로 보면: 되돌려 적용한 수정이 60~70% 늘었다
기능 동결(4월 8일)부터 9월 25일까지 새 기능이 들어가는 메인 브랜치 커밋은 지난해와 비슷했다. 반면 개발 중인 19 안정 브랜치에는 지난해 724건에서 1,169건으로 60% 넘게, 한 단계 앞선 18 안정 브랜치에는 248건에서 433건으로 74% 넘게 수정이 들어갔다. 하스는 커미터가 더 실수했다기보다 평소 같은 실수를 LLM이 빨리 찾아냈다고 본다. 인터넷의 많은 사람이 LLM으로 찾은 버그를 보고하고 있다는 설명이다.
늦은 기능 철회 세 건, 사람의 검토 시간이 병목
8월 27일부터 9월 15일 사이 특정 기간 갱신, SQL 속성 그래프 질의, 파티션 병합·분할 세 기능이 베타 막바지에 빠졌다. 하스는 LLM이 수정안 초안은 쓰지만 정확하거나 프로젝트 규칙에 맞는다는 보장은 없다고 했다. 결국 사람이 검토하고 반영해야 하는데 '그 사람들은 2025년보다 똑똑해지지 않았다'는 말이다. 이전 버전의 보안·버그 수정에 시간이 쓰이다 보니 무엇을 뺄지 정하는 일도 늦어졌다.
Robert Haas · neon.com ↗지연은 문제가 아니라 품질에 신경 쓴 결과
하스는 이번 지연이 긴 편이 아니며 프로젝트가 품질을 중시해서 생긴 일이라고 평가했다. 그는 이번에 결함이 많이 나왔다고 해서 코드베이스에 대한 평가가 달라지지 않는다고도 했다. 자신이 포스트그레SQL 개발자가 된 이유가 본 코드 중 가장 깨끗한 편이어서였다는 것이다. 사람 눈에 더 많은 결함이 보이는 코드였다면 LLM이 찾은 수는 더 컸을 것이라고 적었다.
남은 질문: 40년치 버그를 어떻게 따라잡나
하스가 가장 길게 고민한 대목은 장기 전망이다. 사람이 찾지 못한 40년치 버그를 LLM이 발견할 수 있다면 어떻게 따라잡고, 그러면서 어떻게 혁신을 이어 갈지는 '지금은 모르겠다'고 했다. 많은 사람이 답을 찾으려 애쓰는 중이라고만 적었다. 이 글이 해커뉴스에서 800점 넘게 올라 댓글 480여 개가 붙은 것도 같은 질문이 여러 코드베이스에서 나오기 때문으로 보인다.
Robert Haas · Hacker News · news.ycombinator.com ↗현장 반응 ①: 기술 부채를 갚는 좋은 일
해커뉴스 이용자 BatteryMountain은 150만 줄 규모 자사 시스템에서 지난 1년간 버그와 보안 구멍, 순환 의존성 수천 건을 찾아 고쳤다고 했다. 코드 품질과 테스트 커버리지가 올랐고, 컴파일러 경고를 오류로 다루도록 바꿨다는 이야기다. 사람만으로는 불가능한 작업이었다고 했다. 다른 이용자는 이 일을 '기술 부채 상환'으로 보고, 버그를 안은 채 새 주 버전을 내는 쪽보다 낫다고 평가했다.
Hacker News 이용자 BatteryMountain 등 · news.ycombinator.com ↗현장 반응 ②: 직접 찾아 보니 수확이 엄청났다
tibbar라는 이용자는 올여름 구직 사이에 AI의 도움으로 포스트그레SQL 버그를 찾았더니 직렬화 이상, 외래 키 무결성 문제, 플래너 오류 등 수백 개 후보가 나와 보고할 것을 골라야 했다고 썼다. 실제로 신고한 것은 열두어 건이었다. 그는 이걸 전 세계가 하고 있다고 상상해 보라고 했다. 반면 ltbarcly3 등은 AI 이전에도 베타 막바지에 큰 버그는 나왔다며 원인을 AI로만 돌리는 데 거리를 뒀다.
Hacker News 이용자 tibbar · ltbarcly3 · news.ycombinator.com ↗내 일로 가져오면: 검색은 빨라졌고 검증은 그대로다
한 이용자는 AI가 '이 코드에서 취약점을 찾아 달라' 같은 읽기 위주 검색에는 강하지만 기능 추가 같은 쓰기에는 아직 약하고, 검색은 결과를 확인하기 쉬운 반면 코드 변경은 검증이 어렵다고 짚었다. 하스의 결론도 모든 개발자가 '수준을 한 단계 올려야' 한다는 것이다. 앞으로 짜는 모든 기능이 AI의 눈을 거치고, 예전에는 영영 모르고 지나갔을 문제가 몇 시간 안에 발견될 수 있다는 뜻이다. 그는 이를 도전이자 기회라고 불렀다.
