Giip AI Harness가 쿼리 힌트(Query Hint)를 배제하는 이유

この文書の適用条件

そのまま実行できるコマンド

# 대상: 애플리케이션 및 저장 프로시저 소스 코드 리포지토리
# 권한: 리포지토리 읽기 권한
# 변경 작업: 없음(검색만 수행)
# Production 실행: 해당 없음(로컬 또는 CI에서 실행)

# 실행계획을 강제하는 대표적인 패턴을 코드 전체에서 검색한다
# WITH (INDEX(...)) / FORCESEEK / FORCESCAN / 명시적 조인 힌트(LOOP|HASH|MERGE) / OPTION(FORCE ORDER)
grep -RniE "with[[:space:]]*\([[:space:]]*index[[:space:]]*\(|forceseek|forcescan|force[[:space:]]*order|loop[[:space:]]+join|hash[[:space:]]+join|merge[[:space:]]+join" --include=*.sql --include=*.cs --include=*.ts .

-- 대상: SQL Server 2008 이상 / Amazon RDS for SQL Server / Azure SQL
-- 권한: VIEW DEFINITION
-- 변경 작업: 없음(참조만)
-- Production 실행: 가능
SELECT
    o.name       AS object_name,
    o.type_desc  AS object_type
FROM sys.sql_modules AS m
INNER JOIN sys.objects AS o
        ON o.object_id = m.object_id
WHERE m.definition LIKE '%INDEX(%'
   OR m.definition LIKE '%FORCESEEK%'
   OR m.definition LIKE '%FORCESCAN%'
   OR m.definition LIKE '%FORCE ORDER%'
ORDER BY o.name;

-- 대상: SQL Server 2008 이상 / Amazon RDS for SQL Server / Azure SQL Managed Instance
-- 권한: VIEW SERVER STATE(Azure SQL Database는 VIEW DATABASE STATE)
-- 변경 작업: 없음(참조만)
-- Production 실행: 가능
SELECT
    OBJECT_NAME(i.object_id)   AS table_name,
    i.name                      AS index_name,
    ius.user_seeks,
    ius.user_scans,
    ius.user_lookups,
    ius.user_updates,
    ius.last_user_seek,
    ius.last_user_scan,
    ius.last_user_lookup
FROM sys.indexes AS i
LEFT JOIN sys.dm_db_index_usage_stats AS ius
       ON ius.object_id   = i.object_id
      AND ius.index_id    = i.index_id
      AND ius.database_id = DB_ID()
WHERE i.object_id = OBJECT_ID('dbo.SampleTable')
ORDER BY i.name;

結果の読み方

こういう状況で使います

• 동일한 기반 AI 모델에 같은 슬로우 쿼리를 넣어도, 사용하는 도구에 따라 제안 내용이 다르다
• AI가 제안한 FORCE INDEX나 조인 힌트를 적용한 직후에는 빨라지지만, 데이터량이 늘어난 몇 달 뒤 CPU·I/O가 급증한다
• 사용률 지표만을 근거로 미사용으로 판단한 인덱스를 삭제했더니, 특정 쿼리·저장 프로시저가 즉시 예외를 일으켰다
• 인덱스를 재설계하거나 DDL을 변경할 때마다 애플리케이션 쪽과의 조율이 필요해 작업이 지연된다

考えられる原因（可能性の高い順）

1. 01

   데이터 분포 변화에 따른 선택도(Selectivity)의 역전

   동일한 스키마라도 국가, 서비스 성격, 트래픽 유입 경로에 따라 데이터 볼륨과 카디널리티는 달라집니다. 데이터가 적을 때 최적이었던 Index Seek + Key Lookup은, 행 수가 수천만 건 규모로 늘거나 특정 조건에 데이터가 편중(Skew)되면 대량의 랜덤 I/O를 유발합니다. 일정 임계점(Tipping Point)을 넘어서면 Index Scan이나 Clustered Index Scan을 통한 순차 접근이 오히려 더 빠르고 안정적인 경우가 적지 않습니다. 힌트는 이 전환을 CBO가 판단하지 못하도록 고정해 버립니다.

2. 02

   인덱스 수명 주기와 애플리케이션 코드의 위험한 결합

   대규모 데이터베이스는 복합 인덱스의 신설과, 중복되거나 미사용(Unused)인 인덱스의 정리를 지속적으로 수행합니다. 특정 인덱스를 가리키는 기술이 소스 코드나 저장 프로시저에 하드코딩되어 있으면, 그 인덱스를 변경·삭제하는 순간 운영 환경에서 즉각적인 런타임 예외(인덱스를 찾을 수 없음 등)가 발생합니다. 대규모 서비스 현장에서는, 사용률 지표만으로 미사용 인덱스를 정리했다가 특정 코드·쿼리가 그 인덱스를 강제로 참조하고 있어 즉시 예외가 발생하는 사례가 실무에서 드물지 않습니다.

3. 03

   모델의 차이가 아니라 Harness의 차이

   범용 파운데이션 모델은 눈앞의 쿼리 텍스트만 보고 국소적 최적화(Local Minima)를 시도합니다. Giip AI Harness는 특정 인덱스를 강제하는 것, 정적인 데이터셋을 전제로 한 튜닝, 인덱스 변경 시 애플리케이션이 깨지는 리스크를 피하기 위해, 힌트를 쓰지 않고 CBO의 판단 여지를 남기는 제약을 AI의 행동 반경(Harness)에 직접 넣어 두고 있습니다.

確認手順

1. 1

   코드베이스 내 계획 강제 힌트를 전수 검색한다

   参照のみ

   위 grep 패턴으로 애플리케이션과 저장 프로시저 양쪽에서 WITH (INDEX(...)), FORCESEEK/FORCESCAN, 명시적 조인 힌트, FORCE ORDER를 검색합니다.

2. 2

   인덱스 실사용 통계를 확인한다

   参照のみ

   sys.dm_db_index_usage_stats로 조회·갱신 횟수와 마지막 참조 시각을 확인합니다.

3. 3

   DMV 카운터의 초기화 여부를 확인한다

   参照のみ

   최근 서비스 재시작·장애조치·인스턴스 재생성 시각을 확인하고, 관측 기간이 그 이후로 한정되어 있지 않은지 확인합니다. 관측 기간이 짧으면 "사용률 0"은 판단 근거로 충분하지 않습니다.

4. 4

   추정 행 수와 실행계획의 선택도를 비교한다

   参照のみ

   실행계획의 추정 행 수와 실제 행 수를 비교해, 데이터 분포 편중에 따른 선택도 역전이 일어나지 않았는지 확인합니다.

5. 5

   Sargability를 저해하는 요소를 확인한다

   参照のみ

   WHERE절의 열에 함수를 적용하거나 암시적 형변환이 발생하는 등, 인덱스를 사용할 수 없게 만드는 작성 방식이 없는지 확인합니다.

対応方法

これで解決しない場合に確認すること

• 삭제 예정 인덱스가 실행계획 캐시에 남아 있지 않은지 확인했는가

  sys.dm_exec_query_stats와 sys.dm_exec_sql_text를 함께 사용해, 최근 실행된 쿼리의 실행계획에 해당 인덱스에 대한 참조가 없는지 확인합니다.

• 동일한 패턴의 힌트가 다른 리포지토리·다른 저장 프로시저 그룹에도 남아 있지 않은지 전수 확인했는가

  한 리포지토리에서 발견되지 않았더라도, 다른 배치 처리나 다른 팀이 관리하는 저장 프로시저에 같은 작성 방식이 남아 있을 수 있습니다.

• 통계 정보의 갱신 시각이 오래되지 않았는지 확인했는가

  CBO의 판단은 샘플링된 통계 정보에 기반합니다. 통계가 오래되어 있으면 힌트를 제거해도 CBO가 올바른 선택도로 판단할 수 없습니다.

この文書の根拠と限界

よくある質問

この文書がカバーする質問

• 왜 AI마다 SQL 튜닝 제안 내용이 다른가
• 쿼리 힌트를 쓰면 어떤 리스크가 있는가
• 인덱스를 삭제하기 전에 무엇을 확인해야 하는가

リスク表示の意味

• 参照のみデータと設定を変更しません。
• 低影響は限定的ですが、権限と負荷の確認が必要です。
• 中性能・ロック・コストに影響する可能性があります。
• 高障害・データ損失・復旧作業が発生する可能性があります。
• 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

Giip AI Harness는 생성·제안하는 SQL에 FORCE INDEX나 명시적인 조인 순서 힌트를 포함시키지 않는 것을 설계상의 제약으로 두고 있으며, 성능 개선 제안은 인덱스 설계 재검토, 통계 정보 정비, 쿼리의 Sargability 확보 등 CBO의 판단을 저해하지 않는 수단으로 한정합니다. 또한 인덱스 수명 주기 변경(신설·통합·삭제)을 검토할 때는, 특정 시점의 사용률 통계뿐 아니라 해당 인덱스를 강제로 참조하는 코드가 남아 있지 않은지 전수 검색을 함께 수행하는 것을 운영상의 전제로 삼고 있습니다.

関連サービス

• データベース性能チューニング
• AIインフラ運用