SQL에서 점검할 항목을 찾고, 상세 설명으로 위치를 확인한 뒤, 메인 SQL에서 해당 줄을 보며 수정 작업을 이어갑니다.
AI SQL Checker는 SQL CHECKER의 필수·권장 규칙을 기준으로 성능·정합 위험을 점검하는 기능입니다. Choice가 항목별 최초 판정을 내리고, Fast·Deep 상세 분석이 그 판정의 근거와 관련 SQL 위치를 다시 검토합니다.
이 소개에서는 **샘플06(복합점검)**을 사용했습니다. 등록된 GPT 설정으로 실제 API를 호출했으며, Choice는 jev-1.13.0, Fast는 gpt-6-luna입니다. Deep은 이번 사례에서 호출하지 않았습니다.
1. 한눈에 보는 작업 흐름
샘플 SQL → 메타정보 제공 → Choice 점검 → Fast 상세 분석 → 메인 SQL에서 검토
단계 | 확인할 내용 |
Choice | 어느 점검 항목에 해당하는가? |
Fast·Deep 상세 분석 | 실제 SQL의 어느 부분을 확인해야 하는가? 최초 판정의 근거가 있는가? |
메인 SQL 검토 | 설명을 보면서 수정할 위치를 쉽게 찾을 수 있는가? |
2. 샘플06으로 점검 시작하기
SQL 헤더의 더보기 메뉴에서 **샘플06(복합점검)**을 불러옵니다. SQL 입력창에서 마우스 오른쪽 버튼을 눌러 AI SQL Checker를 실행합니다.
샘플06은 세 개의 집계 SELECT를 UNION ALL로 연결한 SQL입니다. 조인 별칭, 날짜 조건의 컬럼 변환, OUTER JOIN 필터, 반복 집계를 함께 검토할 수 있습니다.
샘플06을 불러온 메인 SQL 화면
확인할 곳: SQL 원문과 우측 상단의 GPT 설정입니다. 이 사례에서는 SQL 실행이나 성능 측정 대신 SQL 점검 기능을 사용합니다.
샘플06 SQL 원문 보기
3. 오브젝트 메타정보를 함께 제공하기
시작 안내에서 메타 정보 제공 후 점검을 선택합니다. Fast 모델이 SQL에 사용된 관계를 추출하고, 기존 Object 조회 기능으로 테이블·컬럼·자료형·NULL 허용 여부·인덱스 정의를 읽어 점검에 사용합니다.
메타정보 제공 여부를 선택하는 안내 창
이번 실행에서는 다음 3개 테이블의 메타정보를 제공했습니다.
•
startdbpg.tr_ord_big
•
startdbpg.ms_mbr
•
startdbpg.ms_shop_big
메타정보 없이 시작하려면 SQL만 점검을 선택할 수 있습니다. 이 경우 제공되지 않은 테이블 구조나 인덱스를 실제로 확인한 것으로 해석하지 않아야 합니다.
4. Choice 결과에서 점검할 항목 좁히기
Choice는 각 항목을 점검 필요 / 점검 통과 / 해당 없음 / 판단 불가로 분류합니다. 자동 점검을 끈 항목은 점검 제외로 표시됩니다.
점검 필요 5개로 필터링한 Choice 결과
이번 실제 실행 결과는 전체 30개 중 점검 필요 5개, 점검 통과 5개, 해당 없음 20개입니다. 판단 불가와 점검 제외는 각각 0개였습니다.
•
상단 pill을 선택하면 해당 판정의 항목만 목록에 표시됩니다.
•
필수·권장은 점검의 구분이며, 성능·정합 pill은 점검 유형입니다.
•
Choice 탭에서는 질문과 선택지의 기준을 확인합니다. 이 단계에서는 SQL 위치가 아직 분석되지 않았습니다.
•
항목 설명의 보기를 누르면 기준과 관련 학습 링크를 확인할 수 있습니다.
5. Fast 상세 분석으로 위치와 이유 확인하기
점검 필요 pill을 마우스 오른쪽 버튼으로 눌러 Fast로 모두 점검하기를 선택합니다. 한 항목만 분석하려면 목록의 번개 버튼을 누릅니다.
점검 필요 pill의 Fast 일괄 상세 분석 메뉴
같은 모드로 이미 분석한 항목이 있으면 기존 항목도 다시 분석하거나 건너뛰기를 선택할 수 있습니다. 성공한 모드의 버튼에는 체크 표시가 남습니다.
Fast 분석 결과와 SQL 17행·26행 하이라이트
이번에는 점검 필요 5개 모두에서 Fast가 최초 판정의 근거를 확인했습니다.
항목 | Fast가 확인한 원문 위치 | 검토할 내용 |
C01. WHERE 절 컬럼 변형 | 17행, 26행 | 날짜 컬럼을 TO_CHAR로 변환한 비교 조건 |
C03. 날짜 자료형·형식 불일치 | 17행, 26행 | TIMESTAMP 컬럼의 문자 변환과 비교 방식 |
J02. 자기 자신 비교 조인 | 5–6행 | o1.mbr_id를 자기 자신과 비교하여 m1과 연결하지 않는 조건 |
J05. OUTER JOIN 참조집합 필터 위치 | 19행 | 오른쪽 테이블의 WHERE 조건으로 미매칭 행이 제외되는 구조 |
S06. 반복 집계 UNION ALL | 14–18행, 25–27행 | 같은 원본의 반복 집계를 통합할 수 있는지 검토할 후보 |
S06의 블록들은 조인·필터·집계 단위가 서로 다릅니다. 반복 조회 후보라는 뜻이며, 결과 의미를 확인하지 않고 하나의 집계로 합쳐도 된다는 결론은 아닙니다.
최초 판정과 상세 검토를 구분하기
•
근거 확인: 상세 AI가 최초 판정의 근거를 확인했습니다.
•
판정 재검토: 상세 AI가 최초 판정과 다른 판단을 했습니다. 최초 판정은 자동으로 바뀌지 않습니다.
•
판단 보류: 정보가 부족하거나 근거를 확인하지 못했습니다.
이번 실행에서는 판정 재검토 사례가 나오지 않았습니다. 다른 SQL이나 실행에서는 결과가 달라질 수 있습니다. 목록의 선택 확률은 실제 결함이나 성능 저하의 확률을 뜻하지 않습니다.
6. 메인 SQL에서 결과를 보며 검토하기
하단 메인 SQL에서 검토를 누르면 결과 창이 작은 비모달 검토 창으로 바뀝니다. 메인 SQL을 수정하면서 점검 원문과 설명을 함께 확인할 수 있습니다.
판정·항목 콤보와 Fast 설명이 있는 검토 창
검토 창에서는 먼저 판정 콤보로 범위를 좁히고, 옆 항목 콤보에서 확인할 항목을 고릅니다. 항목이 한 번씩만 나오므로 여러 모드의 결과 때문에 목록이 늘어나지 않습니다.
•
Choice: 모든 항목의 최초 판정과 점검 기준을 확인합니다.
•
번개: 해당 항목에 저장된 Fast 상세 분석을 봅니다.
•
두뇌: 해당 항목에 저장된 Deep 상세 분석을 봅니다.
완료한 상세 분석만 탭으로 표시됩니다. 항목을 고르면 Deep → Fast → Choice 순으로 기본 선택하며, 탭은 자유롭게 바꿀 수 있습니다. 이번에는 Fast까지만 수행했으므로 Choice와 번개 탭이 표시됩니다.
같은 줄을 메인 SQL에서도 찾기
이 사례에서는 J02. 자기 자신 비교 조인을 선택하고 검토 창의 SQL 6행을 확인했습니다.
검토 창의 조인 문제와 메인 SQL 6행의 파란색 참조 하이라이트
검토 원문에서는 Fast가 찾은 5–6행을 표시하고, 메인 SQL에서는 선택한 6행을 파란색으로 강조합니다. 검토 창에 포커스가 있어도 메인 SQL의 표시가 유지되어 수정할 위치를 바로 찾을 수 있습니다.
원문 설명 → 문제 줄 선택 → 메인 SQL 위치 확인 → 사용자가 수정하는 흐름으로 이어집니다. 전체 점검 결과 버튼으로 큰 Checker 화면에 돌아가도 분석 결과는 유지됩니다.
검토 창은 점검 당시 SQL을 보관합니다. 줄번호 연동은 내용 매칭이 아니므로, 메인 SQL의 줄을 추가·삭제한 뒤에는 같은 번호가 다른 구문을 가리킬 수 있습니다. 메인 SQL을 수정하면 기존 참조 줄 강조는 해제됩니다.
7. 이번 사례의 검증 범위
항목 | 수행 내용 |
점검 SQL | 프로그램에 등록된 샘플06 원문 |
메타정보 | 실제 DB에서 3개 테이블의 컬럼·인덱스 정보를 조회 |
테이블 추출 | 등록된 GPT Fast 모델의 실제 API 호출 |
최초 판정 | Jev 1.13의 실제 API 호출, 30개 항목 |
상세 분석 | GPT-6 Luna 실제 API 호출, 점검 필요 5개 |
메인 줄 강조 | 현재 프로그램의 참조 줄 표시가 6행에 생성됨을 확인 |
Deep·SQL 실행·성능 측정 | 이번 사례의 검증 범위에 포함하지 않음 |
검증 일시: 2026-10-31, 한국 시간. API 결과는 실제 실행값입니다. 이미지는 해당 결과를 현재 프로그램의 Qt 위젯에 표시해 렌더링했습니다. 데스크톱 제어 연결 제한으로 마우스 자동 조작이나 네이티브 창 녹화를 수행한 것은 아닙니다. 메뉴 장면과 메인·검토 창 동시 장면은 실제 위젯 렌더를 합성했습니다.
