SQL 튜닝을 AI에게 맡긴다는 것
SQL 성능 튜닝은 오랫동안 사람의 일이었습니다. 인덱스 추천이나 실행 계획 분석 같은 도구가 도움을 주긴 했지만, 느려진 쿼리를 어디서부터 봐야 할지, 무엇이 문제인지 짚어내는 일은 늘 DBA가 직접 해왔죠. 도구는 보조였을 뿐, 튜닝의 중심은 언제나 사람이었습니다.
그런데 최근 SSMS(SQL Server Management Studio)에 GitHub Copilot 채팅이 들어오면서, 현장에서 비슷한 궁금증이 생겼습니다. "이젠, 튜닝까지 맡겨도 되나?" 코드를 짜주는 건 봐왔지만, 실행 계획을 읽고 병목을 찾는 일까지 믿고 넘겨도 되는지는 또 다른 문제입니다.
엑셈의 신간 『GitHub Copilot 채팅과 함께하는 SQL 튜닝 가이드』는 이 질문에서 출발합니다. SQL Server를 오래 다뤄 온 두 저자가 같은 SQL을 직접 튜닝해보고, 다시 Copilot과 함께 튜닝한 결과를 나란히 비교한 책입니다. 그 답을 따라가기 전에, 먼저 SQL 성능 문제가 왜 그렇게 손이 많이 가는 일인지부터 짚어보겠습니다.
1. SQL 성능 문제는 왜 손이 많이 갈까
실무에서 SQL 성능 문제는 깔끔하게 풀리는 일이 드뭅니다. 쿼리 한 줄이 느린 게 아니라 데이터 분포·인덱스 설계·실행 계획이 서로 얽혀 있어서, 어디서부터 봐야 할지 가려내는 것부터 일이기 때문입니다. SQL Server를 다루다 보면 한 번쯤 겪어봤을 상황들입니다.
- 같은 쿼리인데 어떤 날은 빠르고 어떤 날은 유독 느린 경우
- 데이터가 쌓이자 잘 돌던 쿼리가 어느 순간 느려진 경우
- 인덱스를 분명히 만들어 뒀는데도 옵티마이저가 Table Scan을 고르는 경우
이런 문제는 실행 계획을 한 줄씩 살펴보며 원인을 추적해야 풀립니다. 경험 많은 DBA일수록 빨리 짚어내지만, 그래도 시간과 집중력을 꽤 잡아먹는 일이죠.
그래서 자주 부딪히는 문제를 미리 유형별로 알아두면 한결 수월합니다. 이 가이드는 현장에서 자주 만나는 다양한 성능 이슈를 인덱스와 접근 경로, 실행 계획, 쿼리 구조와 서브쿼리, 통계 정보, 파티션과 원격 쿼리 등 10개 유형 67개 사례로 나눠 정리했습니다. 자신이 겪는 문제가 어디에 해당하는지 짚어가며 읽을 수 있습니다.
2. AI에게 어떻게 물어봐야 잘할까
그렇다면 이런 문제들을 AI로는 어떻게 풀까요? 이 책은 단순히 GitHub Copilot 사용법을 가르치는 데 그치지 않습니다. 실제 SQL 성능 문제를 앞에 두고 AI를 어떻게 활용하는지, 그 과정을 사례로 보여줍니다.
저자들은 SSMS에 Copilot 채팅을 붙여 실제 튜닝에 투입했습니다. 채팅 창에서 직접 물어볼 수도 있고, 편집기 안에서
Alt + /로 인라인 채팅을 띄워 작성 중인 쿼리를 그대로 둔 채 물어볼 수도 있습니다. 여기서 핵심은 활성 문서 참조입니다. 지금 편집기에서 보고 있는 SQL 스크립트를 AI가 함께 읽어, 코드 맥락에 맞는 답을 내놓는 방식이죠. "현재 작업 중인 SQL 구문을 컨텍스트로 전달하는 것이 GitHub Copilot 채팅 활용의 핵심"이라고 짚는 대목이기도 합니다.실제로 저자 김성식 님은 최근 컨설팅 현장에서 수백 라인의 저장 프로시저를 GitHub Copilot 채팅으로 활용해보며 그 가치를 확인했다고 합니다. 저자 이병찬 님이 특히 인상 깊었다고 꼽은 지점도 여기였습니다.
이병찬: 가장 놀랐던 점은 복잡한 SQL의 구조를 파악하는 능력이었습니다. 수백, 수천 라인이 넘는 SQL을 사람이 직접 눈으로 따라가려면 시간과 에너지가 많이 듭니다. 하지만 AI는 매우 빠르게 구조를 파악하고, 더 넓은 시각에서 튜닝 방안을 제시합니다.
다만 같은 도구라도 어떻게 묻느냐에 따라 답이 크게 달라집니다. 좋은 질문과 모호한 질문을 나란히 놓고 그 차이를 보여줍니다.
모호한 질문 | 좋은 질문 |
매출 데이터를 한눈에 볼 수 있게 만들어줘 | Sales.SalesOrderDetail 테이블에서 가장 최근 주문 10건을 조회하는 SQL 쿼리를 작성해 줘 |
많이 팔린 제품을 알려줘 | 2023년 한 해 동안 OrderQty 합계가 가장 높은 제품(ProductID) 10개를 보여줘 |
가장 바쁜 영업사원 알려줘 | 매출 상위 10명의 영업사원을 표로 보여줘. 표에는 ID·이름·매출액 컬럼이 포함되어야 해 |
책에서 정리한 프롬프트 작성 원칙은 다섯 가지입니다. ① 자연스럽고 이해하기 쉽게(속어·전문 용어 피하기), ② 명확하고 구체적으로(충분한 세부 정보), ③ 컨텍스트 제공(시간·대상 테이블 등 추가 정보), ④ 예제 사용(이전 응답을 기반으로 이어가기), ⑤ 출력 형식 정의(표·목록 등 원하는 형태 지정).
결국 AI에게 묻는 일도 'DB를 아는 사람'이 더 잘합니다. 무엇을 어떤 맥락에서 물어야 하는지 아는 만큼 답의 수준도 달라지니까요.
3. 수동 튜닝과 AI 협업, 결정적 차이는
이 책의 가장 큰 특징은 따로 있습니다. 같은 SQL을 기존의 수동 튜닝과 AI 협업, 두 방식으로 나란히 비교한다는 점이죠. 결과만 보여주는 게 아니라 두 과정을 나란히 펼쳐 놓고 어디서 갈리는지를 짚습니다. 실제 사례 두 가지로 살펴보겠습니다.
사례 ① 조건절 컬럼이 가공됐을 때 (사례 14)
WHERE Col1 = 'A' AND Col2 + Col3 = '00'처럼 조건절 컬럼에 연산이 들어가는 경우입니다. 흔하지만 의외로 자주 놓치는 패턴입니다.왜 인덱스를 못 탈까
인덱스는 컬럼의 '원래 값' 순서로 정렬돼 있습니다. 그런데 WHERE 절에서 컬럼을 함수나 연산으로 가공하면(Non-SARGable), 옵티마이저 입장에서는 정렬된 값이 더 이상 유효하지 않습니다. 결국 인덱스를 두고도 전체를 훑게 됩니다.
Copilot에게 비효율 원인을 분석해 달라고 하면, 연산식을
Col2 = '0' AND Col3 = '0'으로 분리해 인덱스 세 키를 모두 타도록 바꿔 줍니다. 그 결과 논리적 읽기가 4,097에서 4로, CPU 시간이 545ms에서 0ms로 떨어졌습니다.사례 ② IN 조건이 인덱스를 못 살릴 때 (사례 13)
gid IN (...) 필터가 NL 조인 안에서 제대로 걸리지 않아, 후행 테이블을 IN 조건 수만큼 반복해서 읽던 경우입니다. AI에게 분석을 맡기자 조인 방식을 HASH JOIN으로 바꾸는 안을 제시했고, 논리적 읽기가 43,244에서 4,408로 약 10분의 1로 줄었습니다.두 사례 모두 흐름은 같습니다. 수동으로 풀면 원인을 찾기까지 시간이 걸리지만 한번 알면 깊이 남고, AI는 출발이 빠른 대신 왜 그런지 직접 확인하지 않으면 실력으로 쌓이지 않습니다.
구분 | 사람이 직접 튜닝 | AI와 함께 튜닝 |
출발 | 실행 계획을 직접 해석, 시간이 걸림 | 1차 진단을 빠르게 제시 |
원인 파악 | 직접 추적해 깊이 남음 | 제안을 받되 검증이 필요 |
강점 | 데이터 분포·업무 맥락 이해 | 반복 작업과 후보 탐색 |
주의 | 경험에 따라 편차 | 그대로 쓰면 위험, 최종 판단은 사람 |
그래서 저자 두 분에게 "사람과 AI 튜닝의 결정적 차이가 무엇이었는지" 물었습니다. 두 분이 짚은 지점은 조금 달랐습니다.
김성식: 둘의 가장 큰 차이는 결과물의 일관성이라고 생각합니다. 사람이 직접 튜닝하면 엔지니어의 경험과 지식, 문제 접근 방식에 따라 결과가 달라집니다. 같은 SQL이라도 누구는 인덱스 관점에서, 누구는 쿼리 구조 개선에 집중하니까요. 반면 AI와 협업하면 특정 개인의 경험이나 성향에 의존하지 않고, 다양한 관점의 개선 방안을 일관되게 제시받을 수 있습니다.
이병찬: 직접 해보니 가장 큰 차이는 결과 자체보다 그 결과에 도달하는 방식이었습니다. AI가 SQL 구조를 요약해 주고 병목이 의심되는 부분과 개선 방향을 빠르게 제시해 주니, 사람은 처음부터 모든 가능성을 탐색하기보다 검증과 판단에 더 집중할 수 있었습니다.
4. 그래서, 맡겨도 될까
저자들이 내린 결론은 분명합니다. 맡길 수는 있지만, AI가 내놓은 답을 그대로 믿어서는 안 된다는 겁니다.
GitHub Copilot 채팅은 쿼리 구조, 실행 계획, 데이터 분포 등 다양한 정보를 활용해 분석하지만, 때로는 단어 간의 연관성에 의존한 잘못된 추론을 수행하기도 합니다. 그래서 그럴듯한 제안을 그대로 적용하면 오히려 문제가 되기도 합니다. 저자 김성식 님은 이 한계를 이렇게 설명합니다.
김성식: AI는 본질적으로 토큰 예측 기반 모델이기 때문에, 추론 과정에서 잘못된 결론에 도달하는 경우도 있었습니다. 그래서 AI가 제시한 결과를 그대로 적용하기보다는, 엔지니어의 경험과 분석으로 검증하고 최종 의사결정을 내리는 과정이 반드시 필요합니다. 결국 지금의 AI는 숙련된 엔지니어를 대체하는 존재라기보다, 분석 속도와 검토 범위를 크게 넓혀 주는 강력한 협업 도구에 가깝다고 느꼈습니다.
물론 어떻게 묻느냐는 여전히 중요합니다. 다만 그만큼 중요해진 건, 여러 제안 중 무엇을 고르고 그 결과를 어떻게 해석하느냐입니다. 저자들이 수동 튜닝 과정을 끝까지 보여주는 이유도 여기에 있습니다. AI의 답을 검증할 수 있는 사람이 되어야, AI를 제대로 쓸 수 있기 때문입니다.
5. 저자 인터뷰: AI 시대에도 변하지 않는 것
AI가 튜닝까지 도와주는 시대에, 정작 변하지 않는 건 무엇일까요. 이 책을 쓴 두 저자에게 집필 계기부터 AI 시대 DBA의 일까지 들어봤습니다.
Q. 두 분은 어떤 일을 해오셨나요?
김성식: NMS(Network Management System) 개발자로 출발해, SQL Server 유지보수 전문업체에서 데이터베이스 운영과 유지보수 경험을 쌓았습니다. 지금은 엑셈 DB 성능 마스터팀에서 SQL Server 유지보수·구축, 성능 최적화, 장애 분석을 비롯한 SQL Server 전반의 기술 업무를 맡고 있고, 전작 『SQL Server 튜닝 가이드』를 집필했습니다.
이병찬: 컴퓨터공학을 전공하고 생성형 AI 챗봇 솔루션 개발팀을 거쳐, 현재 엑셈에서 SQL Server 컨설팅과 데이터베이스 성능 모니터링 솔루션 지원을 맡고 있습니다. AI 솔루션 개발을 통한 경험과 SQL Server를 튜닝하며 쌓은 경험을 합쳐 이 책에 참여했습니다.
Q. 전작도 있는데, 이번엔 왜 GitHub Copilot 채팅을 함께 다뤘나요?
김성식: 전작 『SQL Server 튜닝 가이드』가 이기종 DB를 다루는 분들도 SQL 성능 최적화의 핵심 개념과 실무 노하우를 빠르게 익히도록 돕는 길잡이였다면, 이번 책은 시대의 흐름에 맞춰 GitHub Copilot 채팅을 SQL Server 성능 최적화 도구로 활용하는 사례와 그 가능성을 공유하고 싶었습니다.
이병찬: 요즘은 어떤 분야든 AI를 빼고 이야기하기 어렵습니다. 전작 이후 집필 방향을 논의하던 중 새 버전 SSMS에 GitHub Copilot 채팅 기능이 추가됐다는 걸 보게 됐어요. '이게 정말 튜닝에 도움이 될까' 하는 호기심으로 테스트해 봤더니 기대 이상으로 잘 해내서, 빠르게 책 주제로 정했습니다.
Q. AI 시대에 DBA의 일은 어떻게 바뀔까요? 후배들에게 한마디 부탁드립니다.
김성식: GitHub Copilot 채팅은 시니어 엔지니어에게는 든든한 부조종사, 주니어 엔지니어에게는 좋은 멘토이자 학습 도구가 될 겁니다. 예전에는 경험 많은 선배에게서만 얻던 관점과 노하우를 이제 AI로 더 빨리 접할 수 있죠. 하지만 AI의 답이 늘 정답은 아닙니다. 앞으로의 경쟁력은 지식의 양이 아니라, AI가 내놓은 결과를 비판적으로 검증하고 현장에 맞게 적용하는 판단력에 달려 있습니다. AI 시대에도 엔지니어의 가치는 사라지지 않습니다.
이병찬: 업무 방식은 분명 달라지겠지만, 일의 본질은 크게 바뀌지 않는다고 봅니다. 기술은 늘 발전해 왔고, 그때마다 새 도구에 빠르게 적응한 사람이 더 좋은 기회를 얻었습니다. 이 책을 통해 AI를 단순히 '쓰는' 사람이 아니라 '활용하는' 사람이 되시면 좋겠습니다.
6. 이런 분께 권합니다
- SQL Server를 운영하며 성능 튜닝을 직접 하는 DBA·개발자
- AI를 실무에 어떻게 붙일지 구체적인 사례가 필요한 분
- 수동 튜닝의 기본기와 AI 활용법을 한 번에 익히고 싶은 분
67개 사례마다 실제 성능 이슈 SQL을 제시하고, 기존 방식의 수동 튜닝과 AI 협업 개선을 함께 담았습니다. 책에 실린 QR로 3장의 SQL 실습 스크립트도 다운받아 직접 확인해보세요.
이 책에는 엑셈이 29개국 1,000여 고객사와 DB 성능을 다뤄 온 경험이 고스란히 담겨 있습니다. 'AI에게 SQL 튜닝을 맡겨도 될까.' 그 답이 궁금하다면, 지금 저자 분들의 경험을 직접 확인해 보세요.
함께 보면 좋은 아티클
