AI 튜닝안을 바로 반영하기 어려운 이유
성능 문제가 생긴 SQL을 튜닝하기 위해 실행 계획과 함께 AI에게 먼저 물어보는 일이 흔해졌습니다. 인덱스를 추가하거나 힌트를 넣으라는 답이 몇 초 만에 나오고 왜 그렇게 바꾸라고 하는지 설명도 함께 제공되기 때문입니다. 이런 흐름을 보여 주듯, 실무자와 경영진 2,162명이 참여한 조사 결과를 담은 Redgate의 2026년 보고서에서는 DB 관리에 AI를 활용한다는 응답이 전년 15%에서 44%로 늘었습니다.
하지만 실무자들은 운영 DB에 반영하는 단계에서 망설이곤 합니다. 답이 그럴듯해 보여도 정말 맞는지는 따로 확인해야 하기 때문입니다. 2026년 Stack Overflow 개발자 설문에서도 AI 결과를 ‘쉽게 검증할 수 있을 때 믿는다’는 응답은 48%였지만, 중요한 업무 결정까지 믿는다는 응답은 6.6%에 그쳤습니다.
DB에 연결해 작업을 수행하는 AI 도구에도 실행 전 승인 절차가 마련되어 있습니다. 예를 들어 SSMS의 GitHub Copilot 에이전트 모드는 쿼리를 실행하고 실행 계획을 분석할 수 있지만, 기본적으로 각 쿼리나 명령을 실행하기 전에 사용자 승인을 요청합니다. 다만 승인 절차가 있다는 것과 제안의 타당성이 검증됐다는 것은 다릅니다. 담당자에게는 승인해도 되는지 판단할 근거가 필요합니다.
그런데 SQL 튜닝안은 사람이 읽어 보는 것만으로는 맞는지 판단하기 어렵습니다. 같은 SQL이라도 테이블의 데이터 양과 분포, 통계 정보, 바인드 변수 값에 따라 옵티마이저가 고르는 실행 계획이 달라질 수 있기 때문입니다. SQL을 재작성한 튜닝안은 문장만 보고 이전과 같은 결과를 돌려주는지 확신하기도 어렵습니다. AI가 제안한 튜닝안도 해당 환경에서 실행해 검증한 결과가 없다면, 운영 반영의 근거로 삼기에는 부족합니다. 그렇기에 운영 반영을 판단하려면 다음 3가지를 확인할 필요가 있습니다.
- 결과 일치: 같은 데이터와 바인드 값으로 실행했을 때, 변경 전후 SQL이 같은 결과를 반환하는가?
- 실측 성능: 동일한 검증 조건에서, 변경 후 SQL의 실제 실행 지표가 원본보다 개선되는가?
- 인덱스 영향도: 새 인덱스가 같은 테이블을 참조하는 다른 SQL의 실행 계획과 성능에 어떤 영향을 주는가?
특히 인덱스 영향도는 튜닝 대상 SQL만 살펴봐서는 판단하기 어렵습니다. 새 인덱스가 같은 테이블을 참조하는 다른 SQL의 실행 계획까지 바꿀 수 있기 때문입니다. 따라서 관련 SQL의 실행 계획을 비교하고, 성능이 저하되는 SQL이 있다면 그 범위와 실행 빈도, 업무 중요도를 함께 검토해야 합니다. 관련 SQL이 많을수록 확인 부담도 커집니다.
ExTuner AI는 이 3가지 검증을 튜닝 과정에 포함한 SQL 튜닝 자동화 솔루션입니다. AI가 부하 SQL을 분석해 튜닝안을 만들고 운영 DB가 아닌 별도의 검증용 DB에서 결과 일치와 실측 성능, 인덱스 영향도를 확인합니다. 담당자는 이렇게 얻은 근거를 튜닝안과 함께 검토하고 승인 여부를 정합니다.
1. 튜닝안 생성: 부하 상위 SQL 추출부터 대안 실측까지
ExTuner AI는 튜닝할 SQL을 찾는 작업부터 대안을 생성하고 실행해 비교하는 작업까지 하나의 흐름으로 연결합니다. 부하 상위 SQL을 작업 큐에 모으고, 각 SQL의 튜닝 대안을 만든 뒤 검증용 DB에서 실행해 비교합니다. 운영 개요 화면에서는 대기 중인 SQL과 작업 슬롯별 진행 상태, 처리가 끝난 SQL 목록을 한눈에 확인할 수 있습니다.
1-1. 튜닝 대상 선정: 부하 상위 SQL 자동 추출
튜닝 대상을 매번 직접 찾는 대신 매일 또는 매주 반복 실행하도록 일정을 설정할 수 있습니다. 정해진 시각이 되면 운영 DB의 V$SQL과 AWR에서 실행 통계를 조회하고, Elapsed Time이나 CPU Time 같은 지표를 기준으로 부하 상위 SQL을 추려 작업 큐에 넣습니다. AWR을 사용할 수 없는 환경에서는 V$SQL만으로도 수집할 수 있습니다. 예외로 등록한 SQL과 이미 튜닝한 SQL은 수집 대상에서 제외해 중복 분석을 줄입니다.
V$SQL은 공유 SQL 영역에 있는 SQL 커서의 실행 통계를 제공하는 뷰입니다. AWR은 성능 통계를 주기적으로 수집·보관하는 리포지터리로, 수집된 SQL의 과거 실행 통계를 확인할 수 있습니다. AWR을 활용한 SQL 통계 조회에는 Oracle Diagnostics Pack 사용 권한이 필요합니다.
정기 수집 외에 개별 SQL을 지정해 튜닝을 요청할 수도 있습니다. 목록에서 SQL을 선택하면 실행 계획과 성능 추이, 바인드 변수를 확인한 뒤 튜닝을 요청할 수 있습니다. 목록에 없는 SQL은 직접 입력하고 실행에 필요한 바인드 값을 지정하면 됩니다. 이를 통해 현재 부하가 큰 SQL뿐 아니라 운영 배포를 앞둔 신규 SQL도 검증용 DB에서 점검할 수 있습니다.
작업 큐에 들어온 SQL은 정기 수집과 개별 요청에 관계없이 등록 순서대로 처리됩니다. 우선 확인해야 할 SQL이 생기면 담당자가 대기 순서를 조정할 수 있으며, 필요에 따라 작업을 잠시 멈출 수도 있습니다.
1-2. 대안 생성과 실측: 전략이 다른 튜닝안 비교
튜닝이 시작되면 AI는 실행 계획과 통계 정보를 분석해 병목을 찾고 인덱스 추가와 힌트 적용, SQL 재작성을 조합해 접근 방식이 다른 대안을 만듭니다. 옵티마이저의 예상 비용은 통계 정보를 바탕으로 계산한 추정치라 실제와 다를 수 있으므로, 각 대안을 검증용 DB에서 직접 실행해 실제 실행 지표를 비교합니다.
추천안 선정에는 Buffer Gets를 사용합니다. Buffer Gets는 SQL 실행 과정에서 발생한 논리적 읽기의 블록 수를 의미합니다. ExTuner AI는 대안별 Buffer Gets를 비교해 가장 적은 안을 추천안으로 표시합니다. 담당자는 이 추천안이 논리적 블록 접근량을 기준으로 선정됐다는 점을 고려해, Elapsed Time 등 다른 실측 지표도 함께 살펴 성능 변화를 판단합니다.
Buffer Gets는 개선 여부를 분류하는 기준으로도 사용합니다. 원본 SQL 대비 Buffer Gets가 1% 이상 감소한 대안이 없으면 ‘개선 없음’으로 표시합니다. 여기서 ‘개선 없음’은 Buffer Gets 감소 기준을 충족한 대안이 없다는 뜻이며, 튜닝 목록에서는 이를 튜닝 완료·실패·취소와 구분해 집계합니다.
대안 생성과 실측이 진행되는 동안에는 작업 슬롯에서 현재 수행 중인 작업을 확인할 수 있습니다. ‘인덱스·조인 순서를 조정한 개선안을 생성하고 있습니다’와 같은 안내로 진행 상황을 보여 줍니다. 작업이 끝나면 담당자는 튜닝 목록에서 처리 결과를 확인하고, 다음 단계에서 검토할 튜닝안을 선택합니다.
2. 승인 근거 3가지: 결과 일치, 실측 성능, 인덱스 영향도
추천안이 정해졌다고 곧바로 운영에 반영하는 것은 아닙니다. 추천안은 검증용 DB에서 측정한 Buffer Gets를 기준으로 선정한 안이므로, 담당자는 결과 일치 여부와 다른 실측 지표, 관련 SQL에 대한 영향을 함께 살펴 운영 반영 여부를 판단해야 합니다. 검토 화면에서는 이 판단에 필요한 Before/After SQL과 실행 계획, 실측 결과, 결과 일치 여부, AI가 설명한 변경 이유를 한곳에서 볼 수 있습니다. 그래서 요청자와 승인자가 다르더라도 같은 근거를 보고 검토할 수 있습니다.
2-1. 결과 일치와 실측 성능: Before/After 비교
먼저 튜닝 대상 SQL이 어떻게 바뀌었는지 확인합니다. 튜닝안을 열면 추천안과 나머지 대안이 탭으로 나뉘고 각 대안에는 무엇을 왜 바꿨는지 설명이 함께 표시됩니다. 담당자는 이 설명과 비교 결과를 살펴 추천안을 검토하거나 다른 대안을 선택할 수 있습니다. 검토할 핵심은 다음 두 가지입니다.
- 결과 일치: 검증에 사용한 데이터와 바인드 값으로 튜닝 전후 SQL을 실행해 결과 전체를 비교합니다. 결과가 일치하지 않는 대안은 튜닝안으로 표시하지 않습니다.
- 실측 성능: 검증용 DB에서 측정한 Buffer Gets와 Elapsed Time 등을 비교합니다. 실행 계획도 Before/After로 나란히 볼 수 있어 실측 지표와 함께 조인 방식이나 접근 경로의 변화를 살펴볼 수 있습니다.
변경 내용을 자세히 확인하려면 Before/After SQL에서 색으로 표시된 줄을 보면 됩니다. 긴 SQL 전체를 다시 읽지 않고도 수정된 부분을 찾을 수 있으며 실행 계획 역시 Plan Diff 버튼으로 차이를 비교할 수 있습니다.
2-2. 인덱스 영향도: 같은 테이블을 참조하는 SQL의 실행 계획과 성능 변화
튜닝 대상 SQL의 결과와 성능을 확인했더라도, 인덱스를 추가하는 안이라면 검토가 더 필요합니다. 새 인덱스가 같은 테이블을 참조하는 다른 SQL의 실행 계획에도 영향을 줄 수 있기 때문입니다. ExTuner AI는 운영 DB에서 수집한 SQL 중 해당 테이블을 참조하는 조회 SQL을 찾아 후보 인덱스 적용 전후의 예상 실행 계획을 비교합니다. 이를 위해 검증용 DB에 후보 인덱스를 Invisible Index로 임시 생성하고, 인덱스 사용 설정을 달리해 실행 계획의 변화를 확인합니다.
예상 실행 계획이 달라진 SELECT 문은 인덱스 적용 전후로 한 번씩 실행해 성능을 비교합니다. 예상 실행 계획이 같은 SQL은 별도 비교 실행 없이 ‘영향 없음’으로 분류합니다. 여기서 ‘영향 없음’은 예상 실행 계획의 변화가 확인되지 않았다는 뜻이며, 비교 실행으로 성능 변화가 없음을 확인했다는 의미는 아닙니다.
Invisible Index는 기본적으로 옵티마이저가 사용하지 않는 인덱스입니다. 검증 시 OPTIMIZER_USE_INVISIBLE_INDEXES 설정을 켜면 옵티마이저가 이 인덱스도 고려해 실행 계획을 세웁니다. 이를 통해 후보 인덱스 사용 설정에 따른 실행 계획 변화를 확인할 수 있습니다.
분석 결과는 ‘저하’, ‘실측불가’, ‘개선’, ‘변화 없음’, ‘영향 없음’으로 구분됩니다. 이 중 예상 실행 계획이 달라진 SQL은 비교 실행 후 Buffer Gets의 증감에 따라 분류하며, 실행을 완료하지 못한 경우에는 ‘실측불가’로 표시합니다.
비교 실행에는 가장 최근에 캡처된 바인드 값을 사용합니다. 비교 실행을 완료한 SQL의 Buffer Gets와 Elapsed Time은 인덱스 적용 전후에 각각 측정한 실측값입니다.
담당자는 유형별 탭에서 검토할 SQL을 추리고, 개별 SQL의 실측 지표와 실행 빈도를 함께 살펴 인덱스의 영향을 판단할 수 있습니다. 특히 저하로 분류된 SQL은 업무 중요도까지 고려해 검토할 필요가 있습니다.
검증용으로 생성한 인덱스는 분석이 끝나면 자동으로 삭제하며, 분석 과정에서 데이터를 변경하는 DML은 실행하지 않습니다. 이 분석은 수집된 조회 SQL의 실행 계획과 성능 변화를 확인하는 절차이므로, 인덱스 추가에 따른 INSERT·UPDATE·DELETE의 처리 부담과 저장 공간은 운영 반영 전에 별도로 검토해야 합니다.
2-3. 승인과 이력 관리: 담당자의 결정과 권고 문서
검증 근거를 검토한 뒤 담당자는 승인, 재튜닝, 반려 중 하나를 선택합니다. 추가 검증이나 다른 접근이 필요하면 재튜닝을 요청하고, 운영 환경에 적합하지 않으면 반려할 수 있습니다. 튜닝 요청 권한과 승인 권한을 나눠 부여할 수 있어 요청과 최종 판단을 서로 다른 담당자에게 맡길 수도 있습니다.
ExTuner AI는 검토한 튜닝안을 기존 변경 관리 절차에서 활용할 수 있도록 권고 문서를 제공합니다. 권고안 화면에서 Markdown 형식의 .md 파일로 내려받을 수 있으며, 튜닝 전후 SQL과 실행 계획, 성능 비교, 원인 분석, 적용에 필요한 인덱스 정보를 한 문서에서 확인할 수 있습니다. 담당자는 이 문서를 변경 관리 기록에 첨부하거나 팀과 공유할 수 있습니다. 제품에서 승인하더라도 운영 DB에 자동으로 반영되지는 않으며, 승인한 튜닝안은 기존 운영 반영 절차를 거쳐 적용합니다.
승인·반려 결과와 이를 처리한 담당자는 기록으로 남습니다. 튜닝 실행 결과도 SQL별 이력으로 보관되며, 각 이력에는 당시의 SQL과 실행 계획, 성능 수치, 요청자가 기록됩니다. 이를 통해 같은 SQL의 튜닝 시점과 횟수, 회차별 성능 변화, 승인·반려 기록을 나중에도 확인할 수 있습니다.
3. 운영 DB 보호: 검증 환경 분리와 내부 데이터 처리
여러 튜닝 대안과 관련 SQL을 실행해 비교하려면 검증 작업을 어디서 수행하는지도 중요합니다. 운영 DB에서 직접 측정하면 SQL의 반복 실행과 후보 인덱스 생성이 서비스에 부하를 줄 수 있기 때문입니다.
ExTuner AI는 운영 DB의 정보 수집과 튜닝안의 실행·측정을 서로 다른 DB에서 수행하는 구성을 권장합니다. 이 구성에서는 운영 DB에서 튜닝 대상 선정과 분석에 필요한 정보를 조회하고, 튜닝 대안의 SQL 실행과 후보 인덱스 생성은 고객이 지정한 개발 또는 스테이징 DB에서 진행합니다. 운영 DB에 접속하는 전용 계정에는 인덱스 생성 등 객체 생성 권한을 부여하지 않습니다.
결과 비교 화면 상단에는 대상 인스턴스와 실행 인스턴스가 구분되어 표시됩니다. 담당자는 어느 DB에서 수집한 SQL을 어느 DB에서 검증했는지 확인할 수 있습니다. 쿼리 타임아웃 값과 Invisible Index 생성 허용 여부도 표시되어 실측 결과와 검증 조건을 함께 살펴볼 수 있습니다.
검증 SQL에는 타임아웃을 적용하고, 모듈 태깅으로 검증 작업을 구분해 관리합니다. 검증 결과를 운영 반영 판단에 활용할 수 있도록 검증용 DB의 데이터 규모와 분포, 통계 정보, 주요 실행 조건은 운영 환경과 가깝게 구성하는 것이 좋습니다.
검증 작업의 위치뿐 아니라 AI가 정보를 처리하는 위치도 중요합니다. ExTuner AI는 AI 모델을 포함한 모든 구성 요소를 고객사 내부에 온프레미스로 설치합니다. AI 추론과 SQL 검증도 내부 환경에서 수행하며, 이 과정에서 사용하는 SQL과 실행 계획, 통계 정보, 바인드 값 등은 외부로 전송하지 않습니다.
4. 튜닝안 생성의 기반: 엑셈 컨설팅 사례와 단계별 검수
앞서 살펴본 실측과 영향도 분석은 생성된 튜닝안을 검증하는 절차입니다. 그렇다면 AI는 어떤 지식과 기준을 바탕으로 병목을 분석하고 대안을 만들까요?
ExTuner AI는 엑셈 DB 성능 컨설팅 조직이 금융·공공·통신 현장에서 20년 넘게 쌓아 온 튜닝 사례를 분석과 대안 생성에 활용합니다. 이러한 사례는 DBMS 지식, 실행 계획 패턴과 함께 지식 베이스로 정리되어 있으며, AI는 이를 참고해 병목을 분석하고 튜닝 방향을 도출합니다. 고객사에서 진행한 튜닝 결과도 해당 고객사 내부의 지식 베이스에 축적되어 이후 튜닝에 참고할 근거로 활용됩니다.
컨설팅 경험은 대안을 만드는 과정의 검수에도 반영됩니다. 분석·SQL 튜닝·튜닝 검수 단계에는 컨설턴트가 정의한 검수 기준을 적용하며, 각 단계의 결과가 해당 기준을 통과해야 다음 단계로 진행합니다.
전체 처리 과정은 튜닝 요청 접수 → 정보 수집 → 분석 → SQL 튜닝 → 튜닝 검수 → 실행 검증 → 권고안 검토와 승인의 7단계로 구성됩니다. 요청 접수부터 실행 검증까지는 시스템이 자동으로 수행하며, 이 가운데 분석·SQL 튜닝·튜닝 검수는 LLM 에이전트가 담당합니다. 마지막 권고안 검토와 승인은 담당자가 맡습니다.
생성 과정에서 검수를 마친 대안은 실제 실행을 통한 검증으로 이어집니다. 컨설팅 지식과 단계별 검수는 대안을 만드는 기반이며, 운영 반영 판단에는 실제 실행으로 확인한 검증 근거가 함께 필요합니다.
5. 튜닝 운영의 변화: 사후 대응을 넘어 정기 관리로
지금까지 살펴본 것처럼, AI가 만든 튜닝안을 승인하려면 제안 내용과 함께 이를 뒷받침하는 검증 근거가 필요합니다. ExTuner AI는 결과 일치와 실측 성능, 인덱스 영향도에 대한 검증 결과를 튜닝안과 함께 제공합니다. 반복적인 분석·검증 작업은 자동화하고, 담당자는 검증 조건과 결과를 살펴 운영 반영 여부를 판단합니다.
반복 작업의 부담이 줄면 튜닝 대상을 더 꾸준히 관리할 수 있습니다. 문제가 생긴 SQL에 대응하는 것에 더해, 부하 상위 SQL을 정기적으로 수집하고 검토하는 방식입니다. 배포 예정인 신규 SQL에도 같은 절차를 적용해 운영 반영 전에 실행 계획과 실측 지표를 점검할 수 있습니다.
정기적인 관리에는 판단 근거를 남기는 일도 중요합니다. 튜닝 이력과 권고 문서에는 회차별 변경 제안과 검증 결과가 남습니다. 승인·반려 기록도 확인할 수 있습니다. 이를 실제 운영 반영 내역과 함께 관리하면 이후 성능이 달라졌을 때 당시의 변경 내용과 판단 근거를 다시 살펴볼 수 있습니다.
ExTuner AI는 대안 생성부터 검증, 검토·승인과 이력 관리까지 하나의 흐름으로 연결합니다. 담당자는 어떤 변경이 제안됐는지, 어떤 조건에서 결과 일치와 실측 성능을 검증했는지, 다른 SQL에는 어떤 영향이 있었는지를 근거로 튜닝안을 검토하고 승인할 수 있습니다.
FAQ
Q1. 어떤 환경을 지원하나요?
Oracle Database 11gR2 이상 Enterprise Edition의 단일 인스턴스 및 RAC 환경을 지원합니다. AI 모델을 포함한 모든 구성 요소를 고객사 내부에 온프레미스로 설치하며, 폐쇄망 환경에도 설치할 수 있습니다.
Q2. 운영 DB의 부하는 어떻게 줄이나요?
정보 수집과 튜닝안의 실행·측정을 서로 다른 DB에서 수행하는 구성을 권장합니다. 이 구성에서는 운영 DB에서 분석에 필요한 정보를 조회하고, 튜닝안 실행과 후보 인덱스 생성은 고객이 지정한 개발 또는 스테이징 DB에서 진행합니다.
운영 DB에 접속하는 전용 계정에는 인덱스 생성 등 객체 생성 권한을 부여하지 않습니다. 정기 정보 수집 일정은 업무 부하가 적은 시간대로 조정할 수 있습니다.
Q3. AI가 튜닝안을 운영에 자동으로 반영하나요?
자동으로 반영하지 않습니다. 담당자가 검증 조건과 결과를 검토해 승인 여부를 결정하고, 운영 반영은 기존 변경 관리 절차에 따라 진행합니다. 튜닝안과 검증 결과는 Markdown 형식의 .md 권고 문서로 내려받아 활용할 수 있습니다.
Q4. 어떤 방식으로 튜닝하고 추천안을 선정하나요?
인덱스 추가와 힌트 적용, SQL 재작성을 조합해 접근 방식이 다른 대안을 만듭니다. 각 대안을 검증용 DB에서 실행하고, 측정한 Buffer Gets가 가장 적은 안을 추천안으로 표시합니다. 담당자는 Elapsed Time 등 다른 실측 지표도 함께 살펴 성능 변화를 판단합니다.
Q5. ‘개선 없음’은 어떤 의미인가요?
원본 SQL 대비 Buffer Gets가 1% 이상 감소한 대안이 없다는 뜻입니다. Elapsed Time이 줄었더라도 이 기준을 충족하지 못하면 ‘개선 없음’으로 분류될 수 있습니다. 실패하거나 취소된 작업은 튜닝 목록에 별도 상태로 표시합니다.
ExTuner AI를 도입하고 결과 일치와 실측 성능, 영향 범위까지 확인한 튜닝안을 운영에 반영해 보세요.
👉🏻 ExTuner AI 문의하기
출처
함께 보면 좋은 아티클
