사기가 나아질 때까지 되돌리기는 계속된다

PostgreSQL 19는 베타 시작 이후 집계 방식에 따라 주요 기능 약 8~10개를 되돌렸으며, 일부는 베타 후반에 제외됨 LLM 보조 코드 리뷰가 과거에는 수년에 걸쳐 발견했을 경계 사례의 결함을 빠르게 찾아내면서, 이미 작성하고 커밋한 기능에 적용되는 실질적인 품질 기준이 높아짐 Vulnpocalypse 대응으로 숙련 개발자들이 보안 수정에 집중하면서 베타 중 추가 리뷰와 테스트가 줄었고, 이것이 뒤늦은 문제 발견과 기능 되돌리기에 영향을 주었을 가능성이 있음 PostgreSQL의 “모든 것이 모든 것과 함께 작동한다”는 특성은 기능 개발에 큰 부담을 주며, LLM 보조 퍼징 도입과 더 견고한 내부 인터페이스가 필요함 되돌린 기능 다수가 돌아올 것이라는 기대 속에, PostgreSQL 19에는 REPACK CONCURRENTLY, 시퀀스 논리 복제, pg_plan_advice를 이용한 플래너 힌트 같은 주요 기능이 남아 있음 이례적으로 많았던 기능 되돌리기 PostgreSQL에서는 릴리스 주기마다 기능을 한 개 정도 되돌리는 일이 있을 수 있지만, PostgreSQL 19에서는 베타 시작 이후 주요 기능 약 8~10개가 되돌려졌고 일부는 상당히 늦은 시점에 제외됨 되돌려진 일부 기능의 개발자 또는 커미터였던 Peter Eisentraut의 개인적인 회고로, 관련 개발자들이 충분히 돌아볼 시간을 갖지는 못한 상태임 직접 참여하지 않은 기능에도 일부 분석을 확장하지만, 원인은 기능마다 서로 다른 조합일 수 있음 코드 품질 부족도 가능한 원인에서 제외할 수 없으며, 개발 과정에서 배우고 개선해야 함 개발이 순조롭게 진행되면서 너무 어렵거나 기한 안에 끝내기 어려운 기능을 여러 개 시도한 일이 우연히 겹쳤을 가능성도 있음 LLM 리뷰가 뒤늦게 높인 품질 기준 일부 기능에는 베타 기간에 빠르게 고치기 어려운 중대한 아키텍처 결함이 있었지만, 비교적 무해한 경계 사례 문제도 길게 이어졌음 과거라면 이후 5년 동안 차츰 발견하고 수정했을 문제가 LLM 보조 코드 리뷰로 훨씬 빠르게 드러날 수 있음 결함 보고서가 40개가량 쌓이면, 각각 평균 세 줄만 고치면 되더라도 보고서마다 처리에 필요한 고정적인 작업 부담 때문에 시간이 부족해짐 되돌려진 기능 대부분 또는 전부는 현재만큼 LLM 리뷰가 유용하지 않던 시기에 작성되어, 작성과 커밋 이후에 실질적인 품질 기준이 높아진 상황임 LLM 리뷰 역량이 지금 속도로 계속 향상...