AI 검토로 버그가 너무 많이 발견되어 PostgreSQL 19 출시일이 11월 19일로 변경됨

PostgreSQL 19는 이미 출시되었어야 했다. Postgres 18은 2025년 9월 25일에 배포되었고, 19 버전 역시 같은 가을 시즌에 맞춰 진행되고 있었다. 새로운 PostgreSQL 19의 출시일은 2026년 11월 19일이며, 그 과정에서 여덟 개에서 열 개의 주요 기능이 제외되었다.

그 이유가 사람들이 논쟁하는 부분이다. EDB에서 근무하는 오랜 커미터인 Peter Eisentraut는 10월 9일에 LLM(대규모 언어 모델)-지원 코드 검토가 되돌림(revert)의 일부 원인이라고 썼다. 그의 말에 따르면, 검토 문제는 “훨씬 더 빨리 발견될 수 있으며, 그러면 약 40개의 결함 보고서 목록을 응시하게 됩니다.” [The Register]는 AI 검토자가 인간이 수정할 수 있는 것보다 더 많은 버그를 발견했다는 제목으로 이 내용을 보도했다.

내가 알기로 이것은 기계 검토가 분류(triage) 작업을 하는 사람들의 속도를 앞지르면서 출시 일정이 눈에 띄게 변경된 최초의 주요 오픈 소스 데이터베이스 사례이다. 아래는 무엇이 바뀌었는지, 그리고 만약 프로덕션 환경에서 Postgres를 운영한다면 내가 어떻게 할지에 대한 내용이다.

새로운 PostgreSQL 19 타임라인

RC1 발표와 Christophe Pettus의 일정 비교를 참고하면 다음과 같다:

Beta 4 노트(https://www.postgresql.org/about/news/postgresql-19-beta-4-released-3386/)에서 대규모 되돌림(reverts) 목록을 확인할 수 있습니다:

• SQL/PGQ 속성 그래프 쿼리
• 데이터 체크섬의 온라인 활성화 및 비활성화
• UPDATE/DELETE ... FOR PORTION OF (시간적 업데이트)
• ALTER TABLE ... MERGE PARTITIONS 및 SPLIT PARTITIONS
• pg_get_role_ddl(), pg_get_tablespace_ddl(), pg_get_database_ddl()

Pettus의 게시물에는 더 많은 내용이 추가되었는데, 이들은 이전에 되돌려졌거나 조용히 처리된 항목들입니다: GROUP BY ALL, 비(non-plain) pg_dumpall 출력 형식, 그리고 배치형 외래 키(foreign-key) 빠른 경로. 마지막 것이 가장 심각합니다. Amit Langote의 되돌림 커밋은 이 버그가 "버퍼링된 검사를 수행하지 못하게 하여, 트랜잭션이 오류 보고 없이 영구적인 외래 키 위반을 커밋할 수 있게 할 수 있다"고 경고했습니다.

REPACK (CONCURRENTLY)는 범위 축소와 함께 살아남았으며, Pettus의 조언은 이 전체 사가에서 최고의 문장입니다: "테이블을 재작성하는 모든 것의 1.0 버전을 사용할 때처럼 사용하세요: 백업이 있는 대상에 대해서."

AI 검토는 어떤 종류의 버그를 발견했나?

Eisentraut에 따르면 두 가지 유형입니다. 일부 기능들은 "베타 기간 동안 빠르게 수정하기 어려웠을 상당한 아키텍처 결함"을 가지고 있었습니다. 나머지 부분은 엣지 케이스(edge cases)의 긴 꼬리였으며, 각각은 수정하기는 쉽지만 집합적으로 베타 기간을 소모하게 만들었습니다.

제가 인상 깊게 본 수치는 Pettus에게서 나왔습니다. Robert Haas는 8월 25일 -hackers에 "심각한 패치 콘테스트" 스레드를 시작했고, Claude를 이용해 v19 패치를 포스트-프리즈 버그 수정 기준으로 순위를 매기도록 했습니다. REPACK은 데이터 손실을 포함하여 28개의 수정 사항으로 나왔고, 온라인 체크섬은 약 25개, FOR PORTION OF는 17개, SQL/PGQ는 17개, RI 배치 처리는 약 16개였습니다. Noah Misch는 Claude Opus 5를 사용하여 늦은 8월에 마스터(master) 브랜치에 대한 별도의 검토를 진행했습니다.

SQL/PGQ는 설계 문제로 인해 발생했습니다. Pettus가 설명했듯이, 전제 조건은 CREATE PROPERTY GRAPH 시점에만 확인되었고 그 이후에는 제거될 수 있었습니다. Haas는 "이러한 유형의 문제는 확정된 기능에서는 완전히 용납할 수 없는 것 같다"라고 썼습니다. 모델은 이러한 패턴을 플래그 할 수 있습니다. 하지만 여전히 사람이 이것을 삭제해야 하는 이유로 삼을지 결정해야 하며, 그 규모가 15,859줄에 달합니다.

Eisentraut는 이것이 "분위기만으로 코딩(vibe coding)" 때문이 아니라고 명확히 했습니다. 이러한 기능들 대부분은 도구들이 리뷰를 잘 수행하기 이전에 작성되었습니다. 바뀐 것은 "특정 기능이 작성되고 커밋된 이후에 실질적인 품질 기준 자체가 높아졌다"는 점입니다.

오늘날 사용 중인 Postgres에도 항상 버그가 있었을까요?

부분적으로는 그렇지만, 아무도 이를 큰 소리로 말하려 하지 않는 것 같습니다.

되돌려진(reverted) 코드는 대부분 배포되지 않았기 때문에 18 버전에는 SQL/PGQ 버그가 포함되어 있지 않습니다. 하지만 Pettus에 따르면, RI 배치 처리 코드 테스트 중 발견된 캐스트-캐시 무효화(cast-cache invalidation) 버그는 18.6에도 영향을 미치는 것으로 밝혀졌습니다. 그리고 2026년 보안 로드는 더 많은 것을 보여줍니다: 8월까지 40개가 넘는 CVE가 수정되었으며, 그중 28개는 8월 13일 배포에서만 나왔고, 18.6 버전 노트에는 Claude 지원 및 OpenAI Codex 보안 지원 연구원들이 보고자로 언급되었습니다. 이 모든 것이 현재 사람들이 프로덕션 환경에서 사용하는 버전에 존재하고 있었습니다.

Hacker News 스레드는 바로 이 지점에서 의견이 갈렸습니다. 한 진영은 버그가 항상 존재했으며 우리가 단지 더 일찍 발견하는 것뿐이라고 주장합니다. 다른 진영은 "인간이 고칠 수 있는 것보다 많은 버그"라는 것이 인간이 검증할 수 있는 보고서의 양이 많다는 것을 의미한다고 말합니다. 한 댓글 작성자의 일화는 다음과 같습니다: "보고된 82개의 버그 중 실제로 버그였던 것은 6~8개에 불과했다." 아무도 이러한 내용을 분류하는 데 걸리는 시간을 예산 책정하지 않습니다.

제 생각은 이렇습니다. '오탐(false-positive)' 주장은 Postgres에는 맞지 않습니다. 이것들은 쓰레기 같은 보고서가 아니었습니다. 커미터들이 이를 확인하고, 수정하거나, 심지어 전체 기능을 되돌렸습니다. 문제는 Postgres가 고정된 연간 일정을 유지한다는 것이며, 느린 단계는 버그를 찾는 것에서 버그를 수정하는 것으로 이동했다는 것입니다.

PostgreSQL 18에 머무르는 것이 좋을까요?

네. 지연이 없었더라도 제가 그렇게 말했을 것이고, 이번 지연 덕분에 더 쉬워졌습니다.

• 18.x 버전: 유지하세요. 2030년 11월 14일까지 지원됩니다. RC 2 노트에 대규모 수정 사항이 포함되어 있다고 언급했으므로, 11월 12일 마이너 버전을 적용하세요.
• 14.x 버전: 이것은 시급합니다. Postgres 14는 2026년 11월 12일에 지원 종료되므로, 19 GA(General Availability)보다 일주일 앞섭니다. 19 RC로 가지 말고 18로 가세요.
• 15부터 17 버전: 서두를 필요가 없습니다. 지금은 18 버전을 계획하거나, 아니면 19.2 정도까지 기다리세요.
• 19 기능을 사용하여 새로운 것을 구축하는 경우: 스테이징 환경에서 RC1을 테스트하고, 절대로 프로덕션 환경에서는 테스트하지 마세요. 프로젝트 자체의 문구는 RC1이 '거의 동일(mostly identical)'하며, '동일(identical)'하지 않다고 합니다.

어쨌든 저는 첫 몇 번의 19 마이너 버전을 기다릴 것입니다. Eisentraut는

패키징 경로를 조정하세요. Debian 및 Ubuntu에서는 postgresql.conf가 /etc/postgresql/에 위치하므로, 설정 파일들을 가리키려면 -o/-O 옵션이 필요합니다. --check가 잡아낼 두 가지 새로운 하드 블로커는 다음과 같습니다: 캐리지 리턴(carriage returns) 또는 라인 피드(line feeds)를 포함하는 데이터베이스, 역할 또는 테이블스페이스 이름, 그리고 "반환되어야 할 행을 제외할 수 있다"고 설명된 inet/cidr에 대한 btree_gist 인덱스입니다. 만약 두 번째 문제가 있다면, 오늘 날짜 18일 기준으로 정확성 버그(correctness bug)가 존재합니다.

실제 테스트 업그레이드를 거친 후, 이전에 조정했다면 max_locks_per_transaction 값을 높이세요. 잠금 할당 방식이 변경되어 기본값이 64에서 128로 바뀌었으며, 설명에 따르면 동일한 용량을 유지하려면 설정값을 "반드시 두 배로 늘려야" 합니다.

귀하의 코드베이스에 대한 AI 코드 리뷰가 의미하는 바

Postgres는 오픈 소스 분야에서 가장 신중한 코드 검토 과정을 거칩니다. 만약 LLM(대규모 언어 모델) 지원 패스가 커밋 담당자들에게 이미 해당 검토를 통과한 기능들에 대해 "40개"에 달하는 결함 보고서를 전달할 수 있다면, 어떤 코드베이스도 안전하다고 할 수 없습니다. Postgres 팀은 적어도 나중에 배포하고 패치하기보다는 되돌리는(revert) 규율을 갖추었습니다.

따라서: AI 리뷰가 Postgres에서 이 많은 버그를 발견한다면, 귀하의 코드베이스에서는 무엇을 발견할 것이라고 생각하십니까? 그리고 그에 대해 기능을 되돌릴지, 아니면 일정에 맞춰 배포하고 희망만 할 것입니까?

출처

• Peter Eisentraut: 사기는 개선될 때까지 롤백은 계속될 것이다
• PostgreSQL 19 RC 1 출시
• PostgreSQL 19 Beta 4 출시
• PostgreSQL 19 릴리스 노트
• PostgreSQL 버전 관리 정책
• Christophe Pettus: 19번째 신경쇠약
• The Register: AI 검토자가 인간이 고칠 수 있는 것보다 더 많은 버그를 발견하여 Postgres 19 지연
• LWN: Eisentraut: 사기는 개선될 때까지 롤백은 계속될 것이다
• Hacker News 토론