오픈소스 데이터베이스 포스트그레SQL(PostgreSQL)의 개발 과정은 비교적 안정적인 리듬으로 알려져 있다. 기능 동결(feature freeze) 이후 베타 기간을 거쳐 정식 버전으로 넘어가는 동안, 이미 커밋된 기능이 통째로 제거되는 '리버트(revert)'는 한 개발 주기에 많아야 한 건 정도로 드문 일이었다. 그런데 이번 19 버전에서는 사정이 달랐다. 핵심 커미터 중 한 명인 페터 아이젠트라우트(Peter Eisentraut)는 자신의 블로그에서, 세는 방식에 따라 다르지만 약 8~10개의 주요 기능이 베타 기간에 제거됐고 일부는 베타 후반에 뒤늦게 빠졌다고 밝혔다. 본인이 개발 또는 커밋한 기능도 그 대상에 포함됐다. 왜 이런 이례적인 일이 벌어졌는지에 대한 그의 회고는 특정 프로젝트의 사정을 넘어, 대규모 소프트웨어 개발에서 품질 기준이 어떻게 재조정되고 있는지를 보여준다는 점에서 눈여겨볼 만하다.
아이젠트라우트는 단일한 원인을 지목하지 않는다. 기능마다 서로 다른 요인이 겹쳐 있었다는 것이다. 우선 그는 '코드가 충분히 좋지 않았을 가능성'을 가장 먼저 인정한다. 다른 외부 요인만 탓하는 인상을 주지 않기 위해서다. 또 한동안 순조롭게 성과를 내다 보니 끝내기에는 너무 어려운 기능들을 한꺼번에 시도한 우연의 결과일 수도 있다고 본다. 제거된 기능 중 일부는 베타 기간에 빠르게 고치기 어려운 구조적 결함을 안고 있었지만, 상당수는 특정 조건에서만 드러나는 비교적 사소한 엣지 케이스 문제들의 '긴 꼬리'였다.
LLM 코드 리뷰가 끌어올린 품질 기준
여기서 그가 짚는 핵심 변수는 LLM 기반 코드 리뷰다. 과거였다면 이런 소소한 결함들은 출시 이후 5년에 걸쳐 조금씩 발견되고 수정됐을 것이다. 그런데 LLM의 도움을 받은 리뷰는 같은 문제를 훨씬 빠르게 찾아낸다. 그 결과 개발자 앞에는 갑자기 마흔 건에 달하는 결함 보고서 목록이 쌓인다. 각 건이 평균 세 줄짜리 수정으로 끝난다 해도, 보고를 확인하고 처리하는 고정 비용이 건마다 발생하며 결국 시간이 바닥난다. 문제의 기능 대부분은 LLM 리뷰가 지금만큼 유용하지 않던 오래전에 작성됐다. 즉 커밋 당시의 품질 기준과, 지금 적용되는 기준 사이에 격차가 생긴 셈이다. 그는 이 격차가 미래의 개발 주기에서는 자연스럽게 해소될 문제라고 본다. 또한 이 코드들이 이른바 '바이브 코딩'이 가능해지기 훨씬 전에 작성됐다는 점에서, 이번 사태를 생성형 도구에 기댄 부실한 작성 탓으로 돌리는 해석에는 선을 긋는다.
보안 대응과 맞물린 타이밍
또 다른 요인은 그가 '불나포칼립스(Vulnpocalypse)'라 부른 보안 이슈 대응이다. 19 버전의 기능 동결이 시작된 4월부터 가장 최근 보안 릴리스가 나온 8월까지, 다수의 선임 개발자들이 보안 결함 수정에 묶여 있었다. 그 때문에 베타 기간 중 통상적으로 이뤄지던 추가 리뷰와 테스트가 줄었다가 8월에야 재개됐다. 새로운 문제들이 베타 후반에 뒤늦게 발견되고, 그만큼 리버트도 늦게 몰린 배경이 여기에 있다. 그는 두 달 정도의 시간이 더 있었다면 긴 꼬리의 문제들도 처리할 수 있었으리라 보지만, 커뮤니티는 출시 일정을 미루기보다 지키는 쪽을 택했다. 애초에 그 꼬리가 실제로 얼마나 긴지는 아무도 알 수 없다는 현실적 이유도 있다.
실무자 입장에서 특히 곱씹을 대목은 시스템 복잡도에 관한 성찰이다. 아이젠트라우트는 포스트그레SQL의 매력을 '모든 것이 모든 것과 함께 작동한다'는 말로 요약한다. 가령 어떤 SQL 질의 기능 하나가 도메인 타입과 함께 동작하는지, 그 도메인이 복합 타입 위에 올라가 있고 그 필드 중 하나가 또 도메인이며 NOT NULL 제약이 걸려 있을 때는 어떤지, 거기에 컬럼이 삭제됐다 다시 추가되고, 분리됐다 다른 컬럼 순서로 재결합된 파티션의 일부이며, 트리거에서 호출된 보안 정의자 함수가 사용하는 뷰의 일부라면 어떤지를 모두 따져야 한다. 이런 조합은 사람이 손으로 테스트하거나 열거하는 것 자체가 불가능하다. 그러나 LLM 기반 퍼징은 이런 상호작용의 결함을 빠르게 찾아낸다. 그는 이것이 앞으로 기능 개발의 일부가 돼야 하며, 동시에 내부 인터페이스를 더 견고하게 만들어 조합마다 새로운 상호작용의 가능성이 폭증하지 않도록 해야 한다고 제안한다.
실험적 기능이라는 대안, 그리고 19의 가치
구조적 해법으로 그가 제시하는 것은 '실험적(experimental)' 상태로 기능을 커밋한 뒤 메인 트리 안에서 성숙시키는 방식이다. 커뮤니티가 오래 검토해 온 아이디어로, 이번에 제거된 일부 기능에는 실제로 유용했을 것이라고 본다. 다만 아직 구현 방법을 찾지 못했고, 이와 관련한 오해가 일부 작업에 악영향을 주기도 했다. 그는 이를 앞으로 구체적으로 손봐야 할 과제로 꼽는다. 즉 품질 기준이 올라간 환경에서는 '완성된 것만 넣는' 이분법 대신, 미성숙한 기능을 안전하게 품고 다듬을 중간 단계가 필요하다는 문제의식이다.
이런 진통에도 그는 19 버전이 여전히 매력적인 릴리스가 될 것이라고 말한다. 헤드라인 항목으로 REPACK CONCURRENTLY, 과거 한 번 제거됐다 돌아온 시퀀스의 논리적 복제, 그리고 pg_plan_advice를 이용한 플래너 힌팅을 꼽는다. 무엇보다 추가 검증을 그만큼 많이 거친 만큼 견고할 것이라는 점을 강조한다. 흥미롭게도 그는 몇 달 전만 해도 20 버전은 새 기능 없이 버그 수정만 이뤄질 수도 있다고 전망했는데, 실제로는 상황이 더 빠르게 움직였다. 19에는 당초 기대의 절반 수준의 주요 기능이 담기게 됐지만, 대신 80%쯤 완성돼 남은 부분만 마무리하면 되는 기능 몇 개가 이미 20 버전을 위해 대기 중이라는 것이다. 한국의 운영·개발 실무자에게 이 회고가 주는 함의는 분명하다. AI 보조 리뷰와 퍼징이 결함 발견 속도를 끌어올리면서, 과거에는 수년에 걸쳐 흡수되던 품질 부채가 출시 직전에 한꺼번에 가시화되는 시대가 됐다는 점이다.