제목만 보고 또 바이브 코딩으로 만든 기능과 저품질 결과물을 비판하는 글인 줄 알았음. 그런데 최근 PostgreSQL 19의 기능은 LLM의 도움 없이 작성됐다는 다른 글을 읽었던 게 떠올라 궁금해졌음.
제대로 이해했다면, LLM이 과거보다 더 많은 버그를 출시 전에 찾아내서 PostgreSQL 19가 늦어진다는 내용임. 이건 좋은 일 아닌가? AI ‘때문’이라기보다 AI ‘덕분’에 늦어지는 것으로 보임.
제목은 그야말로 낚시성 제목임.
이번 Postgres 개발 주기가 강제로 안정화 단계에 들어간 셈인데, 견고한 기반 위에 새 기능을 쌓을 수 있으니 모두에게 좋은 결과일 수 있음. 다만 원하는 속도로 새 기능을 넣지 못하는 개발자들은 답답할 만함.
pgsql 19에서는 새 기능보다 버그 수정을 더 많이 해주면 좋겠음. 새 기능을 버전 20으로 미룰 절호의 기회라고 봄.
글쓴이도 버그를 더 많이 발견한 것 자체는 좋게 보는 듯함. 출시 지연은 전체적으로 보면 길지 않고, 프로젝트가 품질을 중시해서 생긴 일이므로 크게 우려하지 않는다고 했음.
다만 방대한 버그 수정 대기열을 한정된 인원의 코드 검토자가 처리해야 한다는 점을 걱정하는 것 같음. 인간이 찾지 못했던 40년 치 버그를 LLM이 찾아낼 수 있다면, 이를 어떻게 따라잡으면서 PostgreSQL의 혁신도 이어갈지 아직 답이 없고 많은 이들이 해결책을 찾느라 애쓰고 있다는 내용임.
LLM을 싫어하는 편이지만, 이건 괜찮아 보임. 저품질 결과물이 넘쳐나고 품질보다 속도를 우선하는 시대에 품질을 택하는 방향은 바람직함.
LLM을 속도보다 품질 향상에 쓰자고 적극 주장해 왔지만, 막상 해보니 꽤 버거움. 내가 유지보수하는 시스템은 상당히 잘 만들어졌고, 견고하고 품질 높은 시스템을 작성한다는 평가도 여러 번 받았음. 그런데 LLM으로 점검하자 수정할 항목이 100개 이상 쌓였고, 그제야 추가 버그 탐색을 멈췄음.
심각한 버그도 있지만 실제로는 거의 마주치지 않을 경계 사례도 많음. Postgres 개발자들의 기준은 나보다도 높을 것임. LLM이 제안하는 수정은 표면적인 경우가 많아서, 시스템 전체를 이해하면 더 적은 수정으로 근본 원인을 해결할 수 있을 듯함. 하지만 이런 분석과 판단은 아직 사람이 주도해야 하며 상당한 노력이 필요함.
지금도 시스템은 충분히 잘 돌아가고, 모든 변경에는 기본적인 위험이 따름. 제안된 수정 중에는 회귀 버그를 만들거나 현 상태보다 낫다고 확신하기 어려운 것도 있음. 다른 할 일도 산더미라 한 번에 3~5개씩 천천히 처리하고 있으며, 이를 이유로 출시를 막지는 않음. 사실상 버그 보고와 수정안으로 자기 자신에게 서비스 거부 공격을 가한 뒤, 정말 중요한 것을 골라내는 새로운 종류의 판단이 필요해짐.
보안 버그를 제외하고, 충분히 오랜 시간과 넓은 설치 기반에서 아무도 영향을 받지 않았다면 그 버그를 정말 버그라고 봐야 할까?.
보고가 없다고 피해도 없는 것은 아님. 데이터베이스 버그는 비결정적이고 드문 조건에서만 발생하는 경우가 많아 재현하기 어려움.
버그가 맞음. 특히 의도치 않은 관찰 가능한 동작에 이미 사용자가 의존하게 됐고, 그것이 새 기능이나 성능 개선을 막는다면 더욱 그럼. 하이럼의 법칙에 해당함.
얼마나 오래여야 할까? 작년에 내 blogging engine에서 28년 동안 잠복해 있던 버그가 발생했음.
균형은 필요하지만, 신뢰성이 핵심인 데이터베이스에서는 특히 좋은 일로 보임. 최근 어디선가 “소프트웨어에 버그가 몇 개 있을지 직접 선택할 수 있는 시대”라는 취지의 문구를 읽었음. 조금 과장이긴 해도, 역사상 손꼽히게 좋은 버그 탐지·수정 도구를 쓸 수 있게 됐다는 핵심에는 동의함. 소프트웨어 엔지니어들은 시간이 주어지면 버그 없는 소프트웨어를 만들 수 있다고 해왔는데, 지금이 그 기회임.
지금은 LLM으로 상상 가능한 모든 기능을 만드는 게 유행이지만, 열기가 가라앉으면 속도도 줄어들 것임. 대부분의 분야에서는 모든 기능을 만드는 것이 바람직하지 않다는 걸 깨닫게 될 것임. 이후 소프트웨어 안정성이 크게 높아지고, 서버 취약점이 계속 발견되면서 로컬 실행이나 종단 간 암호화 소프트웨어를 더 선호하는 시대가 오기를 바람.
기능 추가 이외의 LLM 활용을 더 많이 논의하면 좋겠지만, 지금의 규칙은 사실상 그런 논의를 막는다고 느낌. 자세히 밝힐 수 없는 사정으로 직장에서 LLM을 쓰지 못하지만, 쓸 수 있더라도 새 기능을 잔뜩 추가하는 데 쓰고 싶지는 않음. 코드·보안·접근성 검토, 테스트에 과도하게 집착하지 않는 선에서의 테스트 작성, 개발 보조 도구 제작처럼 반복적이고 일상적인 작업에 활용하고 싶음. 특히 당장의 불편을 해결하고 생산성을 높이는 작고 일회성에 가까운 도구를 만드는 데 잘 맞을 듯함.
이런 면에서 using LLMs to reduce your maintenance burden와 using LLMs to build slower but better에 공감함.
이 글과 반응을 보니 마음이 복잡함. 나도 예전에는 새로운 NoSQL에 눈길이 갔지만, 이제는 “표준이고 견고한 Postgres를 그냥 쓰자”는 쪽으로 바뀌었음. Postgres가 새로운 데이터베이스 패러다임을 대부분 흡수해 온 만큼 기능과 복잡성도 계속 늘었고, 언젠가는 수정 작업이 임계점에 도달할 수밖에 없었음.
LLM이 없는 세계에서 Postgres 개발자들이 버그 수정 대기열을 더는 감당할 수 없어 다음 릴리스를 안정화와 개선, 버그 제거에 집중하겠다고 했다면 어땠을까? 개발자들은 이전에도 이런 결정을 환영했고, Apple이 수정에 집중한 릴리스를 예고할 때도 마찬가지였음.
대형 프로젝트가 속도를 늦추고 안정성과 품질에 집중하는 건 새로운 발상이 아님. AI 도구를 이 방향에 쓰는 것은 훌륭하지만, AI가 품질 중시라는 새로운 시대를 열었다는 해석은 설득력이 약함. Postgres가 Particle DB처럼 기능을 늘리는 대신 품질에 LLM을 투입한 것은 칭찬할 만하지만, 우선순위를 정한 것은 인간이며 LLM 이전에도 가능했던 선택임.
실제 수정의 성격도 궁금함. 이 도구들은 잘 알려진 안티패턴에는 집착할 정도로 민감하지만, 코드를 줄이고 구조를 혁신해 특정 부류의 실패를 통째로 없애는 능력은 아직 대체로 부족해 보임.