Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
PostgreSQL 19의 출시가 지연된 배경을 다루며, LLM 기반 코드 검토가 수십 년 된 코드베이스에서 버그를 발견하는 속도가 인간 커미터들의 수정 속도를 능가했음을 보여줍니다. 이는 소프트웨어 엔지니어링의 병목 현상이 코드를 작성하는 것에서 '검증' 단계로 이동하고 있음을 시사합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기포스트그레SQL 19(PostgreSQL 19)는 원래 10월에 출시될 예정이었다. 하지만 출시는 11월 19일로 연기되었고, 세 가지 주요 기능이 되돌려졌으며, 프로젝트의 백패치 커밋 비율은 전년 대비 74% 급증했다. 그 원인은 무엇일까? LLM(대규모 언어 모델) 기반 코드 검토가 수십 년 된 코드베이스에서 버그를 발견하는 속도가 프로젝트의 인간 커미터들이 분류하고 수정할 수 있는 속도보다 빨랐기 때문이다. 포스트그레SQL 커미터인 Robert Haas는 자신의 10월 블로그 게시물에서, 이 코드를 검토하는 인간들은 2025년과 2026년 사이에 지능이 더 높아지지 않았다고 언급했다.
이 이야기는 AI가 무언가를 망가뜨린 것에 대한 이야기가 아니다. 이것은 소프트웨어 엔지니어링의 병목 현상이 코드를 작성하는 것에서 검증하는 것으로 이동했다는 가장 명확한 증거이다.
Robert Haas blog post: Postgres 19 is late, and it's AI's fault
Robert Haas의 블로그에서 원본 게시물 보기 →
이 이야기는 10월 16일, The Register의 보도를 통해 첫 번째 Hacker News 스레드에 올라왔다. 2주 후, Haas 자신의 블로그 게시물은 785점의 두 번째 스레드를 기록하며, 그 달 최고 참여도를 가진 프로그래밍 이야기 중 하나가 되었다.
PostgreSQL Global Development Group은 2026년 4월 8일에 버전 19의 기능 동결(feature freeze)을 선언했습니다. 이후 과정은 일상적인 베타-릴리스 주기를 거치는 것이었습니다. 하지만 8월 27일부터 9월 15일 사이에 세 가지 주요 기능이 철회되었습니다: UPDATE/DELETE FOR PORTION OF, SQL Property Graph Queries (SQL/PGQ), 그리고 ALTER TABLE MERGE/SPLIT PARTITION. 총적으로 베타 기간 동안 약 8개에서 10개의 주요 기능이 되돌려졌습니다.
수치들이 그 이야기를 말해줍니다. 기능 동결 시점부터 9월 25일까지의 변화는 다음과 같습니다:
Haas는 코드베이스가 더 버그가 많아진 것은 아니라고 주장합니다. 커밋 작성자들은 이전 연도와 마찬가지로 2026년에도 매우 신중했습니다. 바뀐 점은 LLM(대규모 언어 모델) 지원 검토 덕분에 핵심 팀 외부의 사람들도 버그를 찾고 보고하는 것이 훨씬 쉬워졌다는 것입니다. 이들 도구가 존재하기 수년 전에 작성된 코드에 숨어 있던 많은 버그들이 그 대상이었습니다. Neon의 상세 분석은 커밋 통계를 통해 이러한 패턴을 확인시켜 줍니다: 마스터 전용 커밋은 실제로 약간 감소했지만, 폭발적인 증가는 오로지 백패치에 집중되어 있었는데, 이는 이미 배포된 코드에 존재했던 버그들을 수정하는 패치들이었습니다.
ℹ️ PostgreSQL 19 RC2는 11월 12일로 예정되어 있으며, GA(General Availability)는 2026년 11월 19일로 계획되어 있습니다. 같은 날짜에 PostgreSQL 14도 지원 종료(end of life)를 맞이합니다. 공식 일정 업데이트는 10월 10일 pgsql-hackers 메일링 리스트에 게시되었습니다.
핵심적인 긴장 관계는 이렇습니다. LLM은 기계 속도로 결함을 발견할 수 있지만, 그 결함을 수정하는 과정 자체에는 여전히 인간의 판단이 필요합니다. 모든 버그 보고서에는 컨텍스트를 이해하고, 심각도를 평가하며, 수정할지 아니면 롤백(revert)할지 결정하고, 패치(patch)를 작성하거나 검토하며, 다른 부분을 망가뜨리지 않았는지 검증하는 커미터(committer)의 작업이 필요합니다. LLM은 수정을 초안으로 작성할 수는 있지만, Haas가 지적했듯이 이러한 수정 사항들이 항상 정확하거나 PostgreSQL 표준을 준수하는 것은 아닙니다.
이것이 바로 **검증 병목 현상(verification bottleneck)**입니다. 코드, 버그 보고서 또는 패치를 생성하는 것(Generation)은 저렴하고 빨라졌습니다. 하지만 무언가가 정확하고 안전하며 배포 준비가 되었음을 확인하는 과정인 검증(Verification)은 여전히 비싸고 느린데, 이는 선형적으로 확장되지 않는 인간의 전문 지식에 의존하기 때문입니다.
Postgres 사례는 가장 순수한 예시입니다. 왜냐하면 AI의 기여가 코드 생성 자체가 아니었기 때문입니다. 아무도 SQL/PGQ를 단순히 '느낌으로 코딩(vibe-coded)'하여 존재하게 만든 것이 아닙니다. 이 기능들은 전통적인 방법을 사용하여 숙련된 인간 커미터들에 의해 설계, 구현 및 검토되었습니다. LLM은 저자가 아닌 리뷰어로서 등장했습니다. 그들은 수십 년간의 인간 검토 과정에서 놓쳤던 버그들을 찾아냈고, 바로 그 폭주하는 양의 버그 보고서가 릴리스 일정을 망가뜨린 원인이었습니다.
검증 병목 현상은 소프트웨어 생태계의 모든 계층에 영향을 미치고 있습니다.
오픈 소스 프로젝트들이 침수되고 있다. Linux Foundation survey에서 234명의 유지보수자(2026년 10월)를 대상으로 실시한 조사에 따르면, 기여자 수가 50명을 초과하는 프로젝트의 경우, 유지보수자들은 들어오는 코드 변경 사항 중 거의 3분의 1이 품질이 낮거나 AI가 생성한 것이라고 추정했습니다. 번아웃(Burnout)은 대규모 프로젝트 유지보수자들에게 코드 품질보다 더 큰 우려거리로 떠올랐습니다. 약 4분의 1의 프로젝트는 AI 지원 코드를 위한 검사 절차를 아예 갖추고 있지 않습니다.
View the full Linux Foundation report coverage →
볼륨이 감당할 수 없는 수준에 이르자 GitHub는 2026년 2월, 리포지토리 레벨의 PR(Pull Request) 제어 기능을 출시했습니다. 이제 유지보수자는 풀 리퀘스트를 완전히 비활성화하거나, 기존 협업자에게만 제한하거나, 열려 있는 외부 PR의 개수를 제한할 수 있습니다. 여러 유명 프로젝트들은 더 나아가고 있습니다: tldraw는 모든 외부 PR을 자동 닫으며, Ghostty는 승인된 이슈에 대해서만 AI 생성 PR을 허용하고, Sindre Sorhus는 자신의 모든 리포지토리에서 외부 PR을 비활성화했습니다.
엔터프라이즈 팀들도 같은 벽에 부딪힙니다. 500명의 개발자와 300명의 엔지니어링 리더를 대상으로 설문조사를 실시한 Qodo의 2026년 AI 코드 품질 현황 보고서는 두 그룹 모두가 AI 생성 코드를 검토하고 검증하는 것을 **최고의 배포 병목 현상(top delivery bottleneck)**으로 지적했으며, 각각 26%를 차지했습니다. 이는 AI 출력에 대한 신뢰, 보안 및 규정 준수, 비용보다 높은 수치입니다. 한편, 개발자의 36%는 검토 시간이 항상 그랬던 것과 같다고 말하지만, 더 많은 인지적 노력을 요구한다고 답했습니다. AI가 작성한 PR은 깔끔한 diff(차이점), 적절한 포맷팅 등 세련되어 보이지만, 검토자는 어떤 대안들이 고려되었는지 또는 어떤 가정이 전제되었는지 알 수 없습니다.
한 Signadot 분석에 따르면 다음과 같습니다: 풀 리퀘스트를 제출하는 비용은 기본적으로 0에 도달했습니다. 하지만 이를 검토하는 비용은 전혀 변하지 않았습니다.
⚠️ 반(反)통념적 관점 (Contrarian Corner): 'AI가 너무 많은 버그를 발견했다'는 프레이밍은 도구 자체에 대한 과대평가를 불러일으킵니다. 이들 버그 중 상당수는 이미 수년 전에 더 나은 정적 분석(static analysis)이나 충분한 검토 시간만 있었다면 잡혔을 것입니다. 진정한 제약 요인은 항상 PostgreSQL이 대부분의 대규모 오픈소스 프로젝트와 마찬가지로, 코드베이스가 요구하는 것보다 훨씬 적은 커미터(committer)를 가지고 있다는 점이었습니다. AI는 새로운 병목 현상을 만든 것이 아니라, 기존 인력 부족 문제를 부인할 수 없게 만들었을 뿐입니다. 문제는 프로젝트들이 이 상황에 대응하여 커미터 역량 강화에 투자할지, 아니면 그럴 필요가 없는 검증 자동화(verification automation)를 구축할지에 달려 있습니다.
여러 방향에서 데이터가 수렴하고 있습니다:
CircleCI의 2026년 소프트웨어 배포 현황 (State of Software Delivery) 보고서는 커지는 괴리를 지적했습니다. 팀들은 더 많은 코드를 생산하지만, 실제로 출시하는 코드는 줄어들고 있다는 것입니다. 파이프라인은 입력(input) 단계에서는 넓지만, 출력(output) 단계에서는 좁아지고 있습니다.
Qodo의 설문조사에 따르면, 조직의 89%가 AI 관련 프로덕션 사고를 경험했으며, 엔지니어링 리더 중 현재 프로세스가 품질 및 거버넌스에 충분하다고 답한 곳은 단 3.7%에 불과했습니다. 절반 미만의 조직만이 중앙 집중식 AI 코딩 표준을 갖추고 있거나 AI 관련 코드 품질 추세에 대한 가시성을 확보하고 있습니다.
Linux Foundation의 연구는 AI 사용자들이 코딩 시간이 약 절반으로 줄었고 검토 시간은 40% 이상 단축되었다고 보고했지만, 이러한 생산성 증가는 프로젝트가 아닌 개인에게 귀속된다고 지적했습니다. 유지보수자들은 여전히 같은 대기열에 직면해 있으며, 이제는 더 많고 빠른 기여자들로 채워지고 있습니다.
Aviator engineering blog은 이러한 역설을 포착했습니다. 팀들은 그 어느 때보다 많은 코드를 출시하지만, 검토 대기열은 증가하고 사이클 시간은 느려지고 있습니다.
ℹ️ Haas 통계: PostgreSQL 19 브랜치에서 마스터 전용 커밋(Master-only commits) 건수는 실제로 전년 대비 소폭 감소했습니다. 폭발적인 증가는 백패치(back-patches), 즉 이미 출시된 코드에 존재했던 버그를 수정하는 패치였습니다. AI 검토는 새로운 코드에서 새로운 버그를 발견하지 못했습니다. 인간이 할 수 없었던 속도로, 오래된 코드에서 오래된 버그를 찾아냈을 뿐입니다.
Haas의 게시물에 대한 Hacker News 스레드는 785점과 463개의 댓글을 기록하며 하루 대부분 동안 메인 페이지에 올랐습니다. 커뮤니티의 반응은 눈에 띄게 분열되었습니다.
한쪽 진영은 이 지연을 진정으로 긍정적인 것으로 간주합니다. 가장 많은 공감을 얻은 댓글에서는 기술 부채(technical debt)를 상환하는 것은 항상 좋은 일이라고 주장했습니다. 여러 실무자들은 비슷한 경험을 공유했는데, 자체 코드베이스에 AI 리뷰를 사용해 수동 검토를 거쳤음에도 살아남았던 버그들을 발견한 경우였습니다.
반면 회의적인 진영은 AI 리뷰가 실제로 중요도가 높은 버그를 발견하는 것인지, 아니면 비례적 이점 없이 커미터(committer) 시간을 소모시키는 낮은 심각도의 발견물 홍수를 만들어내는 것인지를 의문을 제기합니다. 한 댓글 작성자는 발견된 버그들이 LLM에 버튼을 누르는 것만으로 수정할 수 있는 종류가 아니라, 리뷰어가 디자인 트레이드오프(design tradeoffs)를 깊이 고려해야 하는 종류라고 지적했습니다.
이러한 분열은 병목 현상 가설(bottleneck thesis)과 정확히 일치합니다. 두 진영 모두 더 많은 버그가 발견되고 있다는 점에는 동의하지만, 인간 검증 단계가 이를 처리할 만큼 확장될 수 있는지에 대해서는 의견이 갈립니다.
Neon blog: Postgres 19 is late, and it's AI's fault — detailed commit statistics analysis
만약 엔지니어링 팀을 운영한다면, Postgres 19 이야기는 세 가지 즉각적인 시사점을 가집니다:
