PostgreSQL 19, LLM 코드 리뷰로 8~10개 기능이 되돌려지며 2026년 11월로 연기

PostgreSQL 19가 대략 2026년 11월 19일로 연기되었고, 8~10개의 주요 기능이 릴리스에서 제외되었습니다. LLM 지원 코드 리뷰가 프로젝트의 인간 커미터가 마감 전에 분류하고 수정할 수 있는 것보다 더 많은 결함을 발견했기 때문입니다. PostgreSQL 글로벌 개발 그룹은 이러한 되돌림을 AI가 작성한 코드 때문이 아니라 주기 중반에 높아진 품질 기준 때문이라고 설명합니다.

PostgreSQL 19, 2026년 9월 말/10월 초에서 11월 19일로 연기

PostgreSQL 글로벌 개발 그룹은 PostgreSQL 19를 원래 목표였던 2026년 9월 말 또는 10월 초에서 2026년 11월 19일경으로 연기했습니다. 연기와 함께 개발자들은 8~10개의 주요 기능을 릴리스에서 제외하고 PostgreSQL 20으로 미뤘습니다.

선도적인 PostgreSQL 커미터이자 EDB(PostgreSQL 지원 및 컨설팅 회사)의 부사장인 Peter Eisentraut는 비정상적으로 많은 되돌림이 적어도 부분적으로는 개발자들이 실행한 LLM 코드 리뷰 때문이라고 설명했습니다.

LLM 지원 리뷰가 기능이 이미 커밋된 후 품질 기준을 높임

Eisentraut는 2026년 10월 9일 블로그 게시물 "The reverts will continue until morale improves"에서 발표한 설명에서 되돌려진 작업을 두 가지 범주로 나눴습니다.

첫 번째 범주는 진정한 아키텍처 결함입니다. 일부 되돌려진 기능은 "베타 기간 동안 빠르게" 수정하기 어려운 심각한 아키텍처 문제가 있었습니다.

두 번째 범주는 긴 꼬리(long tail)입니다. LLM 지원 코드 리뷰는 이전 주기에서는 개발자들이 출시 후 5년 동안 버그 수정으로 표면화될 때까지 알아차리지 못했을 "다양한 가장자리 경우와 관련된 비교적 무해한 문제"를 많이 발견했습니다. Eisentraut는 그로 인한 작업량을 다음과 같이 설명했습니다.

"LLM 지원 코드 리뷰를 사용하면 이런 종류의 문제를 훨씬 더 빨리 찾을 수 있고, 그러면 40개의 결함 보고서 목록을 마주하게 됩니다. 각각 평균 3줄 수정만 필요하더라도 각각을 처리하는 데는 고정된 오버헤드가 있고, 결국 시간이 부족해집니다."

문제는 PostgreSQL 19의 주요 기능이 작성되었을 때 LLM 지원 코드 리뷰가 지금보다 덜 능숙했다는 점입니다. 리뷰 도구는 코드가 이미 커밋된 후 출시를 앞둔 몇 달 동안 개선되었습니다. Eisentraut는 이를 일회성 불일치로 설명했습니다.

"효과적인 품질 기준이 기능이 작성되고 커밋된 시점 이후에 높아졌습니다. LLM 지원 코드 리뷰의 능력이 현재 속도로 계속 향상되지 않는 한, 이 상황은 향후 개발 주기에서 자연스럽게 해결될 것입니다."

PostgreSQL 커미터들에 따르면 되돌림은 "바이브 코딩"이 아님

Eisentraut는 AI 생성 코드가 되돌림을 초래했다는 해석을 명시적으로 거부했습니다. 그는 대부분의 새 기능이 작성되었을 때 해당 기술이 없었기 때문에 되돌림이 개발 과정의 "바이브 코딩" 때문이 아니라고 밝혔습니다. 결함은 AI가 인간이 작성한 코드를 리뷰하여 발견한 것이지, AI 저작으로 인해 발생한 것이 아닙니다.

SQL/PGQ가 PostgreSQL 19에서 제외된 기능 중 하나

PostgreSQL 19에서 제거된 기능 중 하나는 2023년 SQL 표준의 일부가 된 SQL 속성 그래프 쿼리(SQL/PGQ) 지원입니다. SQL/PGQ는 엣지로 연결된 노드 간의 관계를 탐색하는 구문을 제공합니다. PostgreSQL 구현은 해결되지 않은 문제로 인해 제거되었습니다.

PostgreSQL 기여자 Tom Lane은 되돌림 전에 이 기능에 대해 경고했습니다. 2026년 9월에 그는 다음과 같이 말했습니다.

"이 시점에서 v19에 이 기능을 포함하면 v20까지 수정할 수 없는 출시 후 버그가 발견될 것이라고 저녁 식사를 걸겠습니다."

PostgreSQL 19는 여전히 REPACK CONCURRENTLY를 제공하며 견고할 것으로 예상

연기와 되돌림에도 불구하고 Eisentraut는 PostgreSQL 19가 여전히 "훌륭한 릴리스"가 될 것이라고 말했습니다. 확인된 하이라이트 중 하나는 디스크 공간을 회수하는 데 사용되는 테이블 잠금 VACUUM FULL 작업을 피하는 REPACK CONCURRENTLY입니다. 그는 또한 추가 검토가 이점을 제공한다고 주장했습니다. "그리고 모든 추가 검토 덕분에 매우 견고할 것입니다."

되돌려진 기능은 이제 PostgreSQL 20에 포함될 것으로 예상

PostgreSQL 19에서 되돌려진 기능은 PostgreSQL 20에 포함될 가능성이 높습니다. 이는 불과 몇 달 전에 발표된 계획을 뒤집는 것입니다. 개발자들은 PostgreSQL 20에 새 기능 없이 버그 수정만 포함될 것으로 예상했습니다. 이제 PostgreSQL 20은 이전 릴리스에서 남은 새 기능을 포함할 가능성이 높습니다.

PostgreSQL의 역사는 프로젝트가 출시에 대해 보수적인 이유를 설명

PostgreSQL은 1986년 Michael Stonebraker에 의해 처음 제안되었습니다. 1994년 Andrew Yu와 Jolly Chen이 쿼리 언어 POSTQUEL을 SQL로 대체했고, 1995년 데이터베이스는 더 허용적인 라이선스로 무료 제공 및 수정 가능하게 되었으며 PostgreSQL로 이름이 바뀌었습니다. 이후 빅 3 하이퍼스케일러가 구축한 서비스와 사용 가능한 와이어 호환 분산 시스템 덕분에 전문 개발자들 사이에서 가장 인기 있는 데이터베이스가 되었습니다.

댓글러들은 AI 시대의 병목은 코딩이 아니라 QA라고 주장

지연에 대한 Hacker News 토론은 한 가지 주제로 수렴했습니다. AI는 결함 발견을 저렴하게 만들고 결함 해결을 비싸게 만들어 릴리스 일정의 제약이 품질 보증이 된다는 것입니다.

한 댓글러는 AI 리뷰가 표면화하는 버그는 LLM이 버튼 하나로 수정할 수 있는 종류가 아니라고 주장했습니다. 설계 판단이 필요하기 때문입니다.

"제 추측이지만, 발견되는 버그는 LLM에 버튼을 눌러 수정할 수 있는 종류가 아니라 리뷰어가 설계 트레이드오프를 깊이 고려해야 하는 종류일 것입니다. 데이터베이스나 프로그래밍 언어 코드베이스에는 그런 것이 더 많다고 생각합니다."

또 다른 댓글러는 이러한 변화를 그럴듯한 부인 가능성의 상실로 설명했습니다. 도구가 포괄적으로 버그와 누락된 테스트 케이스를 발견할 수 있게 되면 팀은 더 이상 기본 기능을 출시하고 결과를 미룰 수 없습니다. 결과적으로 기능당 더 많은 시간이 소요되고 릴리스가 더 나은데도 덜 생산적으로 보입니다.

세 번째 댓글러는 QA가 지속적인 가치가 있는 곳이라고 주장했습니다.

"QA는 AI 시대에 프로젝트의 병목이 되고 있으며, 진정한 가치의 원천입니다. AI는 좋은 테스트 기반을 구축할 수 있지만 최첨단 모델도 테스트에 도움이 필요합니다. 인간이 떠오르는 것만 테스트하는 것과 본질적으로 비슷하거나 조금 더 나쁘기 때문입니다."

같은 댓글러는 이것이 SaaS를 죽이는 것이 아니라 강화한다고 주장했습니다. 프런트 오피스 시스템을 프롬프트로 만들 수 있는 소규모 비즈니스도 QA를 원하지 않을 것이기 때문입니다. QA 부담은 코드 양에 따라 증가합니다. PostgreSQL과의 비교는 직접적입니다. "오늘날 데이터베이스를 프롬프트로 만들 수 있다 해도, Postgres처럼 테스트되고 QA된 것을 프롬프트로 만들 수는 없습니다."

반론: AI는 사실상 무한한 수의 버그를 찾을 수 있음

토론에서 반복되는 반론은 AI 리뷰에는 자연스러운 중단점이 없다는 것입니다. 한 댓글러가 말했듯이, "AI는 말 그대로 무한한 수의 버그를 찾을 수 있습니다. 실제 세계 사례에 영향을 미치거나 발견되었을지 여부와 관계없이 항상 더 많은 버그가 있습니다."

이는 다른 댓글러가 제기한 명백한 질문으로 이어집니다. 현재 릴리스에 이렇게 많은 잠재 버그가 있다면 이미 프로덕션에 있는 버전도 마찬가지일 것입니다. "그렇다면 기존 Postgres 버전도 인간이 수정할 수 있는 것보다 더 많은 버그가 있을 가능성이 높다는 뜻 아닌가요? 그냥 출시하세요. 소프트웨어는 완벽하지 않으며 항상 진행 중입니다."

반론: AI 버그 보고서는 여전히 인간의 분류가 필요

여러 댓글러는 원시 AI 출력이 결함 목록이 아니라고 경고했습니다. 한 명은 AI 도구가 Linux 커널에서 82개의 버그를 보고했지만 실제로는 6~8개만 진짜였던 이전 사례를 인용했습니다. 나머지는 이미 수정되었거나 최신 버전에서 수정되었거나 조작된 것이었습니다. 결론은 인간이 분류하기 전에는 회의적이어야 한다는 것입니다.

다른 사람들은 같은 선을 중단 이유가 아니라 프로세스 규칙으로 그었습니다.

"버그를 찾기 위해 AI를 사용하는 것(작성하는 것이 아니라)은 훌륭한 사용 사례입니다. 숙련된 리뷰어가 있어도 눈이 많을수록 거의 항상 좋습니다. 단, 편집되지 않은 AI '버그 보고서'를 이슈로 올리지 마세요. 개발자에게 던지기 전에 인간이 실제 문제인지 확인해야 합니다."

한 댓글러는 또한 프레임의 잠재적 이해 충돌을 지적하며, Eisentraut의 고용주인 EDB가 AI 중심 Postgres 제품을 마케팅한다는 점을 언급하고 AI 이전에는 PostgreSQL에서 아무것도 작동한 적이 없었는지 수사적으로 물었습니다.

더 깊은 주장: PostgreSQL의 테스트 스위트가 근본 원인

PostgreSQL의 Rust 재작성 작업을 하는 댓글러는 가장 기술적으로 구체적인 반론을 제시했습니다. AI가 버그를 만드는 것이 아니라 가장자리 경우를 겨냥하도록 설계되지 않은 테스트 스위트를 드러내는 것이라고 주장했습니다.

"대부분 Postgres는 각 기능을 테스트하기 위해 개별 회귀 테스트에 의존합니다. 회귀 테스트는 기능이 깨지지 않도록 하는 데는 좋지만 ... 가장자리 경우를 다루는 데는 실제로 그렇게 좋지 않습니다 (2MB가 넘는 문자열을 특정 함수에 전달하면 버퍼 오버플로가 발생하여 DB가 충돌합니다)."

그 댓글러는 재작성 과정에서 핵심 PostgreSQL에서 약 50개의 버그를 발견했다고 보고했습니다. AI를 사용하여 AI 이전의 기술(결정적 시뮬레이션 테스트, 차등 커버리지 가이드 퍼징, 형식 검증)을 확장했습니다. 가장 공격적인 예는 C 및 Rust 함수를 Lean으로 변환하는 컴파일러로, LLM이 두 구현이 동일하다는 증명을 작성하는 것입니다. 작성 시점에 코드베이스의 10.5%(640k줄 중 67k줄)가 동등함이 검증되었으며, PostgreSQL이 isspace()를 사용하여 공백을 제거하는 반면 재작성은 ASCII 공백만 제거하는 파싱 함수와 같은 세부적인 발견이 있었습니다.

PostgreSQL 19 지연이 AI 지원 엔지니어링에 주는 신호

PostgreSQL 19 지연은 성숙한 오픈 소스 프로젝트에서 반복될 가능성이 높은 패턴의 초기 구체적인 예입니다. AI 리뷰는 결함 해결 비용보다 훨씬 빠르게 결함 발견 비용을 낮추므로, 제약 조건이 코드 작성에서 발견 사항 판정으로 이동합니다. PostgreSQL의 대응(알려진 결함이 있는 작업을 출시하는 대신 다음 주요 버전으로 기능을 되돌리는 것)은 보수적인 선택이며, 위험한 변경을 최소화하고 인간 리뷰에 크게 의존하는 프로젝트의 오랜 관행과 일치합니다.

Eisentraut 자신의 예측은 이 효과가 과도기적이라는 것입니다. 불일치는 코드가 작성된 후 리뷰 능력이 향상되었기 때문에만 존재합니다. LLM 리뷰 능력이 현재 속도로 계속 향상된다면, 향후 개발 주기는 처음부터 새로운 품질 기준에 따라 작성될 것이며 사후에 맞춰질 필요가 없습니다.

PostgreSQL 19 지연이 AI 지원 엔지니어링에 주는 신호

PostgreSQL 19 지연은 성숙한 오픈 소스 프로젝트에서 반복될 가능성이 높은 패턴의 초기 구체적인 예입니다. AI 리뷰는 결함 해결 비용보다 훨씬 빠르게 결함 발견 비용을 낮추므로, 제약 조건이 코드 작성에서 발견 사항 판정으로 이동합니다. PostgreSQL의 대응(알려진 결함이 있는 작업을 출시하는 대신 다음 주요 버전으로 기능을 되돌리는 것)은 보수적인 선택이며, 위험한 변경을 최소화하고 인간 리뷰에 크게 의존하는 프로젝트의 오랜 관행과 일치합니다.

Eisentraut 자신의 예측은 이 효과가 과도기적이라는 것입니다. 불일치는 코드가 작성된 후 리뷰 능력이 향상되었기 때문에만 존재합니다. LLM 리뷰 능력이 현재 속도로 계속 향상된다면, 향후 개발 주기는 처음부터 새로운 품질 기준에 따라 작성될 것이며 사후에 맞춰질 필요가 없습니다.