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