사기가 나아질 때까지 리버트는 계속됩니다

PostgreSQL 19 베타 기간에 주요 기능 8~10개가 리버트된 배경을 개발자 Peter Eisentraut가 돌아봅니다. LLM 보조 코드 리뷰로 결함이 더 빨리 드러난 점과 보안 작업으로 줄어든 리뷰·테스트 시간을 원인으로 들며, 퍼징 확대와 실험적 기능 상태 도입을 개선 과제로 제안합니다.

주제: PostgreSQL 코드 리뷰 데이터베이스

에디터 노트

리버트가 몰린 직접적인 배경으로는 결함의 증가만큼이나 검토 일정의 압박이 설득력 있습니다. 글은 보안 대응으로 줄어든 베타 리뷰와 LLM 보조 리뷰가 찾아낸 결함을 함께 원인으로 제시하지만, 기능별로 어느 요인이 얼마나 작용했는지는 밝히지 않습니다. 댓글에서는 코드 작성 시점이 바이브 코딩 이전이라는 설명에 이견이 나옵니다. 다만 반론은 바이브 코딩의 시작 시점을 다투고, 다른 댓글은 LLM이 사람이 놓친 버그를 찾는 경험을 보탭니다. 퍼징과 실험적 기능 상태는 글이 제시한 개선 방향이지만 적용 방식은 아직 정해지지 않았습니다. 품질 기준이 높아진 상황에서 출시 일정을 유지하려면 리뷰 시간을 어떻게 확보할지가 남은 과제입니다.

AI 요약

PostgreSQL 19는 베타 기간이 시작된 뒤 주요 기능 8~10개를 브랜치에서 되돌렸습니다. Peter Eisentraut는 자신이 개발하거나 커밋한 기능도 리버트된 상황을 설명하며, 원인이 기능마다 다를 수 있다고 전제합니다. 코드 품질이 충분하지 않았거나 기능 자체가 예상보다 어려웠을 가능성도 있다고 짚습니다.

결함 발견 속도와 리뷰 여력

일부 기능에는 구조적인 결함이 있었지만, 비교적 가벼운 엣지 케이스도 많이 발견됐습니다. 과거에는 뒤늦게 알려져 수년에 걸쳐 수정했을 결함이 LLM 보조 코드 리뷰로 빠르게 드러나면서, 수정 목록이 수십 건으로 불어났다는 설명입니다. 결함마다 수정 자체는 작더라도 검토와 처리에 드는 고정 비용이 쌓여 마감 전에 끝내기 어려워졌습니다. 영향을 받은 기능 대부분은 LLM 보조 리뷰가 지금처럼 유용해지기 전에 작성됐으므로, 기능을 커밋한 뒤 실질적인 품질 기준이 높아졌다고 봅니다. 따라서 이번 리버트의 대부분은 '바이브 코딩' 탓이 아니라는 게 Eisentraut의 판단입니다.

또 다른 배경으로는 PostgreSQL 보안 취약점 대응 작업인 'Vulnpocalypse'를 듭니다. 기능 동결이 시작된 4월부터 최근 보안 릴리스가 나온 8월까지 시니어 개발자 다수가 보안 수정에 투입됐고, 베타 기간에 평소 진행하던 추가 리뷰와 테스트가 줄었습니다. 8월에 리뷰가 다시 늘면서 문제가 늦게 발견됐고, 그 결과 리버트도 베타 후반에 몰렸을 가능성이 있습니다. Eisentraut는 두 달가량 더 시간을 들였다면 일부 작은 문제를 고칠 수 있었겠지만, 커뮤니티는 출시 일정을 늦추기보다 유지하는 쪽을 택했다고 설명합니다. 결함의 긴 꼬리가 얼마나 이어질지도 미리 알기 어렵다고 덧붙입니다.

복잡한 조합과 개발 절차

PostgreSQL은 기능이 다양한 맥락에서 함께 작동해야 합니다. 예를 들어 SQL 기능 하나만 봐도 도메인과 복합 타입, NOT NULL 제약, 삭제 후 다시 추가한 열, 열 순서를 바꿔 재연결한 파티션, 뷰, 보안 정의 함수, 트리거가 조합될 수 있습니다. 사람이 모든 경우를 직접 나열하고 테스트하기는 어렵지만 LLM 보조 퍼징은 이런 문제를 빠르게 찾을 수 있다고 봅니다. 앞으로는 퍼징을 기능 개발 과정에 포함하고, 내부 인터페이스도 더 견고하게 만들어 조합마다 새로운 상호작용 문제가 생기는 일을 줄여야 한다고 제안합니다. 다만 '모든 것이 모든 것과 작동하는' PostgreSQL의 특성은 유지하고 싶다고 말합니다.

또한 기능을 처음부터 완성된 상태로 커밋하는 대신 '실험적' 상태로 넣고 메인 트리에서 성숙시키는 방안도 검토할 수 있다고 제안합니다. 일부 리버트 기능에 도움이 됐을 방식이지만, 아직 적용 방법을 정하지 못했고 관련 오해도 있었다며 구체적인 개선 과제로 꼽습니다. 그는 리버트된 기능 다수가 머지않아 돌아올 것으로 기대합니다. PostgreSQL 19에는 REPACK CONCURRENTLY, 시퀀스 논리 복제, pg_plan_advice의 플래너 힌트 같은 기능이 남아 있으며, 추가 검토를 거쳐 안정성이 높아졌다고 설명합니다.

Lobsters 반응

@Two9A — LLM 보조 코드 리뷰 이야기는 들었지만, 이번 일이 바이브 코딩 때문이 아니라는 설명을 전적으로 믿기는 어렵습니다.
- @refi64 — 당시 LLM이 코드를 잘 작성하지 못했다는 점만으로도 해당 코드는 사람이 썼다고 볼 수 있습니다. LLM은 큰 코드베이스 깊숙한 곳의 버그를 찾는 데는 꽤 능숙합니다. curl 유지보수자 사례 등에서도 널리 다뤄졌습니다. 마케팅을 위해 능력을 부풀리는 곳도 있지만, 사람 눈을 피한 버그를 LLM이 찾아내는 일 자체는 놀랍지 않습니다.
- @dualvariable — 저도 코드베이스에 익숙해지려고 직접 코드를 쓰곤 합니다. 제 코드에 LLM을 적용하면 실수와 2차 버그를 많이 찾고, 대개 맞는 지적이라 인정하게 됩니다. 물론 틀리는 경우도 있습니다.
- @SamRW — 바이브 코딩은 이미 3년쯤 전부터 가능했을 겁니다.
@felipe — 리버트 목록을 확인했는데 FOR PORTION OF 업데이트와 삭제 지원도 포함돼 있었습니다. 시간 테이블 사용성이 좋아질 것으로 기대했는데 아쉽습니다.
@fuzzy — 글을 빠르게 읽고 LLM 측면을 확인한 뒤 Claude에게 사기와 관련한 내용을 요약해 달라고 했습니다. 요약은 지지에 대한 감사, 작업이 돌아올 것이라는 확신, 건설적이고 미래를 향한 태도에 한정됐습니다.
- @prime — LLM이 출력한 내용을 인용하는 것은 이 사이트 댓글에 건설적으로 보탤 내용이 아닙니다. 저도 가입 첫 달에 그렇게 했다가 더 나은 태도를 배웠습니다. 조금이라도 깊이 있게 참여할 수 있을 때만 글을 쓰는 편이 낫습니다.

원문: Peter Eisentraut 블로그 / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗