추측이지만, 지금 발견되는 버그는 LLM에 버튼 하나 눌러 고칠 종류가 아니라 설계상의 절충점을 깊이 검토해야 하는 종류일 듯함. 특히 데이터베이스나 프로그래밍 언어 코드베이스에는 이런 문제가 더 많다고 봄.
실제 리뷰에서는 “다른 기능과 동작이 다른데, 목표가 X면 잘못이고 Y면 어느 정도 맞으며, Z라는 목표와 J라는 용도에는 완벽하지만 I에는 맞지 않는다”는 식의 문제를 자주 만남. 조건이 Q라면 12개월 전의 근본적인 결정을 재검토하고, 사용자가 원하는 동작부터 관계자들과 논의한 뒤 설계의 절충점을 따져야 할 수도 있음.
덧붙이자면 이조차 LLM에 아주 후한 평가임. LLM이 이 맥락을 이렇게 간결하게 정리해 준다면 내일이라도 다른 직업을 찾겠지만, 지금은 여러 차례 프롬프트를 넣어 맥락을 모은 뒤 사람끼리 추가로 논의할 필요가 있는지 직접 판단해야 함.
소프트웨어 개발에서 지금 가장 어려운 경계가 바로 여기라고 봄. LLM에 하루 종일 버그를 고치게 해도 실제 문제 대부분은 무엇을 의도했는가에 달려 있음. 데이터베이스나 언어 구현뿐 아니라 제품 설계에서도 흔한데, 코드 리뷰에서 드러나지 않을 뿐임. 모든 기능이 완벽하게 작동해도 작업 흐름이나 UI가 사용자의 삶을 편하게 해주지 못하거나, 기능 추가와 수정으로 기괴하게 비대해질 수 있음.
순수한 코드 문제에서는 Fable급 모델부터 “잠깐, 여기서는 엄청나게 단순화할 수 있겠는데”라며 한발 물러서는, 이른바 AGI의 조짐을 가끔 보게 됨. 하지만 제품 수준의 대대적인 단순화를 모델이 먼저 밀어붙이는 경우는 거의 없음.
AI가 찾아낸 버그를 고치려면 내가 감당할 의향이 있는 범위보다 훨씬 많은 코드를 수정해야 하는 경우가 잦음. 그렇게 큰 새 코드는 제대로 검토하기도 어렵고, 원래 고치려던 버그보다 더 많은 버그를 넣을 가능성이 큼. 결국 제품에 미치는 실제 영향을 평가한 뒤 해당 버그 보고를 무시하는 경우가 많음.
도구로 버그와 누락된 테스트를 샅샅이 찾아낼 수 있게 되면 몰랐다는 변명을 하기 어려워짐. 정적 분석을 갖춘 강타입 언어에서 타입 오류를 내놓고 변명하기 어려운 것과 비슷함.
과거에는 최소한의 구현으로 출시했을 기능마다 추가 시간이 들어가게 됨. 전반적으로 더 나은 결과이긴 하지만, 이것을 생산성 향상으로 받아들일지는 별개임.
사람이 고칠 수 있는 것보다 버그가 많다면, 분류하고 진짜 버그인지 검증할 수 있는 양도 넘을 가능성이 큼. 쓰레기를 넣고 쓰레기를 쏟아내는 방식은 곤란함. 이 엄청난 저품질 생성물 홍수를 감당해야 하는 오픈소스 유지관리자들이 안쓰러움.
AI가 사실상 무한히 많은 버그를 찾을 수 있다는 논의를 봤음. 실제 사용에 영향을 줬을지, 누군가 알아차리기라도 했을지와 상관없이 더 찾아낼 버그는 언제나 있음.
몇 주 전 LWN에서 이 문제를 다룬 기사를 읽었음. 버그 자체가 늘어난 것인지, AI 때문에 기존보다 더 많이 알게 된 것인지 확신하지 못한 채 논쟁 중이었음. 어느 쪽이든 아쉽지만 충분히 이해할 만한 결정임.
후자에 가깝다고 봄. 특히 C로 작성된 오래된 오픈소스 Unix 소프트웨어에는 수년 뒤에야 발견되는 버그가 곳곳에 숨어 있음. Postgres 같은 일반적인 Unix 시스템 소프트웨어는 미묘한 버그가 없다고 확신할 수 없는 방식으로 작성되므로, 그런 버그가 있다고 가정해야 함.
토큰을 충분히 쓰면 해당 코드베이스에서 어느 쪽인지 판별할 수 있음.
AI 시대에는 QA가 프로젝트의 병목이자 진짜 가치의 원천이 되고 있음. AI는 테스트의 좋은 기초를 만들 수 있지만, 최첨단 모델도 떠오르는 것만 시험한다는 점에서는 사람만큼, 어쩌면 조금 더 부족해서 도움이 필요함. 대신 문제가 발견된 뒤 해결해 나가는 능력은 아주 뛰어남.
AI가 SaaS를 없앨 것이라는 예측과 달리, 오히려 SaaS의 입지가 더 단단해질 것으로 봄. 작은 가게가 프롬프트로 업무 시스템을 만들 수는 있어도 직접 QA까지 하고 싶어 하지는 않을 것임. SaaS 업체가 더 많은 코드와 QA를 맡게 되면, 작은 사업자가 이를 AI로 재현할 때 감당해야 할 검증 부담도 지금보다 커짐.
오늘날 프롬프트로 데이터베이스를 만들 수는 있지만, Postgres처럼 검증된 데이터베이스를 즉석에서 만들 수는 없음. 회사의 가장 중요한 데이터를 어디에 저장할지 결정하기 전에, 프롬프트 하나와 수십억 시간의 실사용 검증 사이에 놓인 간극을 신중히 따져야 함.
설계 단계의 유지관리보다는 운영 중 동작에 가까운 이야기지만, 내가 일하는 SaaS 회사에서는 이런 방향을 설득하려고 함. 가장 싸고 빠른 시장은 “다음 규칙을 따르는 업무 시스템처럼 행동해”라는 프롬프트 중심의 조악한 시스템이 잠식하며 가격 경쟁으로 치달 것임.
반면 우리가 원하는 고객 대부분은 업무 규칙을 예고 없이 위반하는 시스템을 원하지도, 감당하지도 못한다는 사실을 결국 깨닫게 될 것임. 고객 항의, 엉망인 데이터, 소송으로 이어지기 때문임. 규칙을 코드로 명시하고 강제하면서 감사 가능성과 설명 가능성까지 갖추는 것이 차별점이자 경쟁 방어력과 고객 유지력의 원천이 됨.
따라서 운영 환경에서 LLM을 쓰는 범위를 제한하고, 설계 단계에서 신뢰할 수 있는 결정론적 시스템을 만드는 데 활용하도록 집중할 전략적 근거가 있음.
결제·세금 신고·금융·규제 업무에서는 작은 실수의 파급력도 AI로 술집 할인 전단을 만드는 것과 비교할 수 없을 만큼 큼. 작은 낚시용품점도 결국 Square에 돈을 낼 것임.
그렇다면 현재 Postgres에도 사람이 고칠 수 있는 것보다 많은 버그가 있다는 뜻 아닌가? 그냥 출시하면 됨. 소프트웨어는 완벽할 수 없고 늘 개선 중임. 대부분은 사소한 예외 상황일 듯하며, 너무 많은 구멍을 한꺼번에 막으려다 개발이 지체되는 것 같음.
오래된 코드베이스에 AI 리뷰를 돌려 온갖 흥미로운 문제를 찾고 있어서 놀랍지 않음. AI가 품질 기준을 크게 높이고 있으며, 기존 코드에서 보완해야 할 부분도 많음.
Fable이 Linux 커널 버그를 처리한 결과를 보면, 보고한 82건 중 실제 버그는 6~8건뿐이었음. 나머지는 이미 수정됐거나 최신 버전에서 해결됐거나 아예 지어낸 내용이었으므로, 사람이 이 더미를 걸러내기 전까지는 회의적임.
Postgres의 오래된 문제들을 해결하려고 직접 재작성과 아키텍처 재설계를 진행하고 있어서 조금 다른 관점이 있음. 지금 많은 버그가 발견되는 근본 원인은 제한적인 Postgres 테스트 모음이라고 봄. AI는 이미 존재하던 버그를 드러낼 뿐임.
Postgres는 주로 기능별 회귀 테스트에 의존함. 이런 테스트는 SELECT 'Hello, World' LIKE '%Hello%'가 여전히 참을 반환하는지 확인하기에는 좋지만, 특정 함수에 2MB 넘는 문자열을 전달했을 때 버퍼 오버플로로 데이터베이스가 죽는 식의 예외 상황을 찾는 데는 약함. 지금까지는 위험한 변경을 최소화하고 사람이 많이 검토하는 방식으로 버그를 막았지만, 그 과정에서 놓친 빈틈이 많았던 셈임.
Postgres 팀은 AI에 회의적이지만, 나는 AI로 결정론적 시뮬레이션 테스트, 차등·커버리지 유도 퍼징, 정형 검증을 확대해 좋은 결과를 얻고 있음. pgrust를 테스트하면서 Postgres 핵심부에서 약 50개의 버그를 찾았으며, AI 코드 리뷰가 아니라 더 발전된 테스트를 AI로 수행해 발견한 것임. 모두 AI 이전부터 존재하던 기법이지만 Postgres 핵심 개발에서는 본격적으로 활용되지 않고 있음.
지금은 정형 검증에 집중하고 있음. C와 Rust 함수를 Lean으로 변환하는 컴파일러를 만들고, 두 함수의 동작이 같다는 증명을 LLM에 작성시키고 있음. 지금까지 Postgres 64만 줄 중 6만 7천 줄, 약 10.5%에 해당하는 코드의 동작 일치를 검증함. Postgres는 isspace()로 공백을 제거하지만 pgrust는 ASCII 공백만 제거하는 파싱 함수의 미세한 차이까지 찾아냄. 기존 회귀 테스트나 사람의 리뷰로는 찾기 어려운 차이임. 이런 철저함 덕분에 수동 테스트보다 더 많은 버그를 잡는다는 확신이 생기며, 현재로서는 전체 코드베이스로 확대하지 못할 이유가 보이지 않음. 다만 시간이 오래 걸림. https://github.com/malisper/pgrust https://malisper.me/the-four-horsemen-behind-thousands-of-po...
여기서 재구축이란 C에서 Rust로의 변환을 뜻하는 건가? Postgres의 C 함수를 보고 동일성을 증명한다면서, 라이선스는 AGPL이고 Postgres 저자들은 명시하지 않아 혼란스러움.
LLM을 리뷰어로 쓰면서 코딩에는 쓰지 않는다면 결함 제로에 도달하는 데 훨씬 오래 걸릴 듯함.
이번 여름에 둘 다 써봤는데 끝없는 수정 악순환에 빠졌음. 리뷰 에이전트가 버그를 찾으면 코딩 에이전트가 과도하게 복잡한 방식으로 고치다가 새 버그를 만들고, 리뷰 에이전트가 그것을 찾으면 코딩 에이전트가 수정하면서 또 버그를 만드는 식임. 매번 그렇지는 않았지만 무시하기 어려울 만큼 자주 발생함.
코딩 과정과 리뷰 과정은 서로 독립적이며, 그렇게 유지하는 편이 좋을 듯함. 코딩은 작업 범위가 여기저기로 퍼지는 반면 리뷰는 더 집중된 작업이므로, 리뷰에 더 똑똑한 모델을 쓰는 비용을 들일 가치도 있음.