AI 튜닝안, 운영 반영 전에 필요한 근거
느린 SQL과 실행 계획을 AI에게 보여 주면 인덱스 추가나 힌트, SQL 재작성 같은 튜닝안을 빠르게 얻을 수 있습니다. 이제는 SSMS의 GitHub Copilot 에이전트 모드처럼 쿼리를 직접 실행하고 실행 계획까지 분석하는 도구도 있습니다. 하지만 튜닝안을 얻는 것과 운영 DB에 반영하는 것은 별개의 일입니다. 이 도구도 스키마를 바꾸는 작업은 사용자 승인을 거쳐 진행하며, 운영 반영 여부는 결국 DBA가 판단해야 합니다.
그렇다면 DBA는 무엇을 확인해야 AI가 만든 튜닝안을 승인할 수 있을까요? 운영 반영 전에는 다음 3가지 질문에 답할 수 있어야 합니다.
- 결과 일치: 바꾼 SQL이 이전과 같은 결과를 돌려주는가?
- 실측 성능: 옵티마이저의 예상 비용뿐 아니라 실제 실행에서도 빨라지는가?
- 인덱스 영향도: 새 인덱스가 같은 테이블을 읽는 다른 SQL의 실행 계획에 어떤 영향을 주는가?
특히 인덱스 영향도는 튜닝 대상 SQL만 살펴봐서는 알 수 없습니다. SQL 하나가 빨라져도 같은 테이블을 읽는 다른 SQL이 느려진다면, 그 영향을 확인하지 않은 채 반영하기는 어렵기 때문입니다. 같은 테이블을 참조하는 SQL을 찾아 실행 계획을 하나씩 비교해야 하므로, 3가지 검증 가운데 가장 많은 시간이 드는 작업이기도 합니다.
ExTuner AI는 이 검증을 튜닝 과정에 포함한 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가지: 결과 일치, 실측 성능, 인덱스 영향도
추천안이 정해졌다고 곧바로 운영에 반영하는 것은 아닙니다. 이제 담당자는 결과가 같은지, 실제로 빨라졌는지, 다른 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. 승인과 이력 관리: 담당자의 결정과 권고안 파일
이 근거들을 검토한 뒤 담당자는 승인, 재튜닝, 반려 중 하나를 선택합니다. 근거가 부족하면 다시 튜닝을 요청하고, 운영 환경에 맞지 않으면 반려할 수 있습니다. 튜닝 요청 권한과 승인 권한을 나눠 부여할 수 있으므로, 요청과 최종 판단을 서로 다른 담당자가 맡는 절차도 지원합니다.
승인 이후에는 튜닝안을 기존 변경 관리 절차로 넘길 수 있도록 권고안 파일을 제공합니다. .sql 파일에 인덱스 생성 DDL과 변경 SQL을 실행 순서대로 정리하고, 성능 비교와 변경 근거를 주석으로 붙입니다. 따라서 먼저 수행해야 할 작업까지 확인해 변경 관리 절차에 첨부할 수 있습니다. 승인은 운영 DB에 자동 반영한다는 뜻이 아니라, 검토를 마친 권고안을 운영 반영 절차로 넘기는 단계입니다.
이 결정의 근거는 작업 이력에도 남습니다. 요청부터 승인까지 사람이 한 작업과 AI가 한 작업을 구분해 기록하고, 누가 어떤 근거로 승인했는지 확인할 수 있도록 합니다. 운영에 반영한 뒤에는 성능을 다시 수집해 튜닝 단계의 측정치와 비교하며, 반영 후 비교 결과까지 같은 이력에 남깁니다.
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년 넘게 쌓아 온 튜닝 사례를 정제해 판단 기준으로 사용합니다.
AI는 과거 튜닝 사례와 DBMS 지식, 실행 계획 패턴을 담은 지식 베이스를 참고해 튜닝안을 만듭니다. 튜닝 결과도 다시 수집해 사례로 쌓으므로, 운영 과정에서 참고할 판단 근거가 늘어나는 구조입니다.
이 기준은 대안 생성뿐 아니라 단계별 검수에도 쓰입니다. 내부 처리는 튜닝 요청 접수 → 정보 수집 → 분석 → SQL 튜닝 → 튜닝 검수 → 실행과 실행 계획 확인 → 권고안 검토와 승인이라는 7단계로 나뉩니다. 앞의 6단계는 AI가 처리하고, 마지막 검토와 승인은 담당자가 맡습니다. 이 중 분석부터 튜닝 검수까지는 LLM 에이전트가 담당하며, 각 단계의 결과가 컨설턴트가 정의한 검수 기준을 통과해야 다음 단계로 넘어갑니다.
5. 튜닝 운영의 변화: 사후 대응에서 정기 관리로
처음의 질문으로 돌아가면, AI가 만든 튜닝안을 승인하는 데 필요한 것은 제안 자체가 아니라 검증 근거입니다. ExTuner AI는 결과 일치와 실측 성능, 인덱스 영향도를 운영 DB 밖에서 확인해 튜닝안과 함께 제공합니다. 담당자의 판단을 대신하는 것이 아니라, 판단에 앞서 반복해야 했던 검증 작업을 줄이는 방식입니다.
이 반복 작업이 줄면 튜닝 대상을 관리하는 방식도 달라질 수 있습니다. 문제가 생긴 SQL만 그때그때 손보는 대신, 부하 상위 SQL을 정기적으로 수집하고 검토할 수 있기 때문입니다. 같은 절차를 배포 예정인 신규 SQL에도 적용하면 운영에 올라간 뒤에야 성능 문제를 발견하는 일도 줄일 수 있습니다.
정기 관리에서도 중요한 것은 변경 근거를 남기는 일입니다. 어떤 SQL을 왜 바꿨는지는 승인 이력에 남고, 운영 반영 후 성능도 튜닝 단계의 측정치와 비교할 수 있습니다. 튜닝안을 만드는 데서 끝나지 않고, 검증과 승인, 반영 후 확인까지 이어지는 운영 절차로 관리하는 것입니다.
FAQ
Q1. 어떤 환경을 지원하나요?
Oracle Enterprise 환경을 지원하며 고객사 내부에 온프레미스로 설치합니다.
Q2. 운영 DB에 부하가 생기지 않나요?
운영 DB에서는 튜닝 대상을 찾기 위한 성능 데이터 조회만 합니다. SQL 재실행과 측정, 검증용 인덱스 생성은 지정한 개발 또는 스테이징 DB에서 진행합니다.
Q3. AI가 튜닝안을 운영에 자동으로 반영하나요?
자동으로 반영하지 않습니다. 담당자가 승인한 튜닝안은 실행 순서가 정리된 권고안으로 제공되고, 운영 반영은 기존 변경 관리 절차에 따라 진행합니다.
Q4. 어떤 방식으로 튜닝하나요?
인덱스 추가와 힌트, SQL 재작성을 조합합니다. 하나의 SQL에 전략이 다른 대안을 여러 개 만들고, 각 대안을 실제로 실행해 측정한 결과로 추천안을 정합니다.
Q5. 튜닝해도 빨라지지 않으면 어떻게 되나요?
대안을 실행해도 개선되지 않으면 ‘개선 없음’으로 표시돼 튜닝이 끝난 SQL과 구분됩니다. 실패하거나 취소된 작업도 목록에 상태별로 따로 남습니다.
결과 일치와 실측 성능, 영향 범위까지 확인한 튜닝안만 운영에 반영하세요. ExTuner AI 도입과 PoC는 아래에서 문의할 수 있습니다.
출처
함께 보면 좋은 아티클
