오픈소스 데이터베이스 PostgreSQL에서는 발견 속도가 빨라진 만큼 검토할 일도 늘었다. 주요 기여자이자 코드 반영 권한을 가진 로버트 하스는 10월 30일 개인 블로그에 올린 글에서, 대규모 언어모델(LLM)로 찾은 버그 제보가 늘면서 PostgreSQL 19의 출시 준비와 기존 버전 유지보수가 동시에 압박받고 있다고 설명했다.
하스는 11월 출시를 예상하면서 추가 연기 가능성도 열어 뒀다. 지난 10년간 대체로 9월 중순부터 10월 중순 사이에 새 주요 버전을 내던 흐름과 비교하면 늦어진 셈이다. 하스가 지목한 원인은 오류를 잔뜩 만드는 자동 생성 코드가 아니다. 이미 있던 오류까지 찾아내는 능력이 좋아졌는데, 안전한 수정인지 판단하는 사람의 시간이 그만큼 늘지는 않았다는 것이다.
수정량은 출시 준비 중인 버전과 기존 버전에서 함께 늘었다
하스는 두 해의 같은 기간인 4월 8일부터 9월 25일까지 코드 변경을 기록한 커밋 수를 비교했다. 2025년 출시를 준비하던 18 버전의 안정화 브랜치에는 724건, 2026년 19 버전에는 1,169건이 반영됐다. 약 61.5% 늘어난 수치다. 브랜치는 특정 버전을 따로 관리하는 코드 갈래이며, 새 개발 코드의 수정을 그 갈래에도 적용하는 작업을 백패치라고 한다.
이미 배포된 직전 주요 버전도 비슷했다. 2025년의 17 버전에는 248건, 2026년의 18 버전에는 433건이 반영돼 약 74.6% 증가했다. 다음 버전의 완성도를 높이는 일에 더해, 사용자가 지금 운영하는 버전의 문제를 고치는 일도 함께 늘어난 것이다.
커밋 수를 버그 수나 작업 시간으로 읽으면 안 된다. 한 번의 수정에 여러 커밋이 필요할 수 있고, 같은 수정이 여러 버전으로 옮겨질 수도 있다. 하스의 집계는 유지보수 활동이 얼마나 늘었는지 보여 준다. 증가분 전체가 LLM 때문이라는 실험 결과는 아니며, 원인 해석은 그가 현장에서 관찰한 제보 증가에 근거한다.
베타 후반에 큰 기능을 빼는 결정까지 늦어졌다
신규 기능을 받아들이는 시점이 끝나면 개발자는 출시할 기능을 다듬고 문제를 줄이는 데 집중한다. 하스에 따르면 PostgreSQL의 연례 기능 동결일은 4월 8일이다. 그런데 이번에는 8월 27일부터 9월 15일 사이에 큰 기능 세 묶음이 되돌려졌다. 동결 직후 기능을 빼는 일은 드물지 않지만, 베타 후반에 여러 기능을 함께 제외한 것은 이례적이라는 설명이다.
제외 대상은 시간 구간의 일부에만 데이터를 수정·삭제하는 기능, SQL로 그래프 관계를 질의하는 기능(SQL/PGQ), 나눠 저장한 테이블의 구획을 합치거나 쪼개는 기능이다. 특정 기간의 계약 내용을 바꾸거나 데이터 사이 연결을 조회하는 새 기능을 기다렸다면, 베타에서 보였다는 이유만으로 19 버전 도입 계획에 넣기 어려워졌다.
공식 베타 4 발표도 안정성과 예측 가능한 출시 일정을 위해 일부 기능을 제거했다고 밝혔다. 추가 개발과 검토를 거쳐 이후 주요 버전에 포함할 가능성을 남겨 둔 결정이지, 다음 버전에 반드시 돌아온다는 약속은 아니다. 하스는 기존 버전의 보안 문제와 버그를 처리하느라 새 버전에 들어간 기능을 검토할 시간이 줄었고, 무엇을 빼야 할지 판단하는 데도 시간이 더 걸렸다고 봤다.
수정안을 만드는 일과 반영을 책임지는 일은 다르다
LLM은 문제를 지적하는 데서 그치지 않고 수정 코드도 제안할 수 있다. 그렇다고 검토가 끝나는 것은 아니다. 제안이 문제를 제대로 고치는지, 다른 동작을 깨뜨리지 않는지, 프로젝트의 작성 규칙에 맞는지 사람이 확인해야 한다. 하스는 오류 발견과 수정이 모두 쉬워졌지만, 쉬워진 정도가 같지는 않다고 설명했다.
특히 기존 버전에 옮길 수정은 현재 개발 중인 코드에서 통과하는지만 봐서는 부족하다. 버전마다 코드와 지원하는 동작이 다르기 때문이다. 버그 하나를 찾은 성과가 여러 버전의 검토 업무로 이어질 수 있다. 제보가 늘면 검토자는 새 기능의 출시 준비와 기존 사용자의 문제 해결 사이에서 시간을 나눠 써야 한다.
이 사례를 제품 개발에 적용하면, 자동으로 찾은 문제나 생성한 코드의 양만 세는 방식으로는 출시 속도를 설명하기 어렵다. 제보가 실제 오류로 확인되기까지 걸리는 시간, 수정 검토가 대기하는 시간, 기존 버전으로 옮기는 데 드는 일을 함께 봐야 한다. 발견 도구를 도입한 뒤 출시가 잠시 느려져도 곧바로 도구의 실패나 개발자의 생산성 저하로 결론낼 수 없는 이유다.
하스는 이번 지연 자체를 크게 우려하지는 않았다. 품질을 위해 출시를 늦추는 선택으로 봤다. 더 어려운 질문은 오래된 코드에서 계속 나오는 결함을 고치면서 새 기능을 개발할 여력을 어떻게 남기느냐다. PostgreSQL 19를 기다리는 쪽에서는 출시 전망과 최종 기능 목록을 구분하고, 새 기능을 전제로 한 도입 일정은 정식 릴리스에 남은 기능을 확인한 뒤 잡는 편이 맞다.
출처: Robert Haas, Postgres 19 is late, and it’s AI’s fault · PostgreSQL 19 Beta 4 발표