시중의 일반 AI 모델에게 슬로우 쿼리 튜닝을 요청하면 손쉽게 FORCE INDEX 나 조인 힌트를 추천합니다. 단일 쿼리 단위의 즉각적인 실행 속도는 개선될지 몰라도, 대규모 프로덕션 환경을 경험해 본 엔지니어라면 이 방식이 얼마나 위험한지 잘 알고 있습니다. Giip의 AI Harness는 쿼리 생성 및 튜닝 시 쿼리 힌트 사용을 원칙적으로 금지 합니다. 30년 넘게 미션 크리티컬 대규모 서비스를 운영하며 축적한 엔지니어링 원칙이 AI의 행동 반경(Harness)으로 강하게 통제되고 있기 때문입니다. 1. 동일한 스키마라도 데이터 분포(Distribution)는 살아 움직입니다 동일한 게시판 테이블이라도 국가, 서비스 성격, 트래픽 유입 경로에 따라 데이터 볼륨과 카디널리티(Cardinality)는 완전히 다릅니다. 선택도(Selectivity)의 역전: 데이터가 적을 때는 최적이었던 Index Seek + Key Lookup 이 데이터가 수천만 건으로 불어나거나 특정 조건의 데이터 편중(Skew)이 발생하면 수많은 Random I/O를 유발해 시스템을 마비시킵니다. CBO(비용 기반 옵티마이저)의 자율성 보장: 일정 임계점(Tipping Point)을 넘어서면 오히려 Index Scan 이나 Clustered Index/Table Scan 을 통한 Sequential I/O가 훨씬 빠르고 안정적입니다. 쿼리 힌트는 옵티마이저의 정상적인 판단을 강제로 차단하여, 서비스 성장에 따라 자가 치유(Self-adapting)할 수 있는 기회를 영구히 박탈합니다. 2. 인덱스 수명 주기(Lifecycle)와 애플리케이션의 위험한 결합 대규모 데이터베이스는 끊임없이 진화합니다. 비즈니스 요구사항에 맞춰 새로운 복합 인덱스를 생성하고, I/O 비용을 줄이기 위해 중복되거나 미사용(Unused) 인덱스를 정리하는 DDL 작업이 일상적으로 일어납니다. 런타임 에러 유발: 소스 코드나 쿼리에 특정 인덱스 힌트가 하드코딩되어 있다면, DBA가 ...