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

pgsql의 새로운 LLM 보조 코드 리뷰 절차를 길게 설명한 뒤 “내가 보기에는 적어도 대부분 바이브 코딩 때문은 아님”이라고 하는데, 완전히 납득되지는 않음.

본문을 보면 충분히 타당한 설명 아닌가? 되돌린 기능 대부분은 지금처럼 LLM 보조 리뷰가 유용해지기 훨씬 전에 작성됐고, 당시라면 수년에 걸쳐 발견하고 고쳤을 경계 사례의 결함들이 한꺼번에 드러났다는 것임. 보고서가 40건쯤 쌓이면 각각 평균 세 줄만 고치면 되더라도 건별 처리 비용 때문에 시간이 부족해짐. 즉, 작성·커밋 이후 품질 기준이 높아진 셈임.
당시 LLM의 코드 작성 능력을 고려하면 사람이 작성한 코드이며, 통상적인 바이브 코딩에 해당하지 않음. 또 curl 관리자의 사례처럼 LLM의 버그 탐지 능력은 널리 확인되고 있음. 마케팅 목적으로 과장하려는 쪽도 있겠지만, 방대한 코드 속에서 사람이 놓치는 결함은 많으므로 복잡한 데이터베이스 내부에서 LLM이 버그를 찾는 건 놀랍지 않음.

나도 바이브 코딩에 반대하지만, LLM 리뷰는 바이브 코딩과 다르며 LLM을 가장 잘 활용할 수 있는 용도 중 하나임. 맥락과 코드에 대한 통제권은 직접 유지하면서, 코드 흐름을 폭넓게 추적하고 사소한 부분까지 짚어 주는 강력한 리뷰어를 얻을 수 있음.
윤리적 이유로는 여전히 사용에 반대하는 편이지만, 기술적으로는 사람이 직접 작성한 코드에서 놓친 버그를 여럿 잡아내는 모습을 직접 봤음. 사람의 리뷰를 대체하지 않는 한 바이브 코딩과 동급으로 보지 않음.

바이브 코딩이 나온 지도 벌써 3년쯤 됐는데, 적어도 당시에도 가능하기는 하지 않았을까?

되돌린 변경 목록을 확인해 보니, 안타깝게도 FOR PORTION OF를 이용한 갱신·삭제 지원도 포함돼 있음. 시간 이력 테이블을 더 편하게 다룰 수 있기를 정말 기대했는데 아쉬움.

글을 빠르게 읽으며 LLM 관련 부분을 눈여겨본 뒤, Claude(Sonnet 5.5, medium)에게 사기 측면을 요약해 달라고 요청함. 요약은 “지원에 대한 감사, 작업이 다시 돌아올 것이라는 확신, 건설적이고 미래지향적인 어조 정도로 한정됨”이었음.

LLM 출력을 인용하는 것만으로는 이 사이트의 댓글 토론에 건설적으로 기여하기 어려움. 나도 가입 첫 달에 그렇게 했다가, 조금 더 깊이 있게 참여할 수 있을 때만 댓글을 쓰라는 더 나은 원칙을 배웠음.