인덱스 하나 더의 참을 수 없는 가벼움

코딩 에이전트가 만든 PostgreSQL 인덱스는 개별 쿼리에는 적절했지만, 쓰기가 집중되는 테이블에 누적되는 비용을 충분히 고려하지 못함 지원 도구의 tickets 벤치마크에서 인덱스가 16개인 생성 스키마는 수작업 기준 스키마보다 WAL을 1.8배 더 기록하고, 업데이트에 1.9배의 시간이 걸림 인덱스 개수만큼 어떤 컬럼을 인덱싱하는지가 중요함. 수정되는 컬럼에 인덱스가 있으면 HOT 업데이트가 불가능해지고, 새 행이 조건을 충족하는 다른 인덱스에도 쓰기가 발생함 추가 인덱스는 읽기를 크게 가속했지만, 쿼리 조건 불일치와 캐시 압박에서는 반대 결과를 냄. 교차 테넌트 SLA 조회는 111배 느려졌고, 작은 버퍼 풀에서는 물리적 읽기가 6.7배 늘어남 에이전트는 기능 추가 요청에는 대부분 인덱스를 더했지만, 쓰기 성능 검토를 요청하자 문제를 찾아 제거 후보를 제안함. 실제 삭제 전에는 사용 통계와 데이터 무결성 요구를 확인해야 함 실험 범위와 생성 SQL의 품질 검토 과정에서 한 테이블의 인덱스 12개를 제거해야 할 만한 스키마가 등장했고, 다음 스키마에서도 비슷한 패턴이 나타나 코딩 에이전트의 과도한 인덱싱을 측정하기 시작함 모델이 생성한 스키마 30개를 PostgreSQL에 적재하고, 그중 12개에 있는 인덱스 838개를 감사함 확인 가능한 요구사항에 대응하지 않는 인덱스는 10개뿐이었음 네 모델 모두 GIN, GiST, 합리적인 조건의 부분 인덱스, 올바른 순서의 멀티테넌트 복합 키를 구성함 기본 SQL 품질은 1년 전 에이전트 출력보다 크게 좋아졌으며, 문제는 개별 인덱스의 조악함보다 누적 비용에 있었음 가상의 SaaS 여섯 가지를 대상으로 3개 공급사의 모델 4개를 시험함 공유 수신함 기반 지원 도구, 체육관 수업 예약, 제품 분석, 마켓플레이스, 동물병원 관리, 화물 관리 서비스를 사용함 모델 순위보다 데이터베이스에 초점을 맞추기 위해 이름을 Model A~D로 익명화함 한 실행은 Andrey Grunev가 수행했고, 이후 같은 모델의 데이터를 늘리기 위해 추가 실행함 명세에는 PostgreSQL 사용 외에 테이블명, 컬럼, 데이터베이스 제약조건이나 인덱스 평가 계획을 넣지 않음 처음 네 명세는 직접 작성하고 LLM으로 문장만 다듬었으며, 나머지 둘은 짧은 설명을 바탕으로 독립적인 모델이 작성함 한 명세는 다른 것보다 빈약했지만, 검토 후 얻은 지식으로 실험을 오염시키지 않도록 수정하지 않음 매번 ...