주식 분석용으로 쓰던 SQL이 있었습니다. 개인 분석용이라 느려도 그냥 쓰고 있었는데, 약 54초나 걸리던 쿼리였습니다. SQL Plan Studio의 AI 조언 기능을 테스트해 볼 겸 돌려봤더니, LAG 함수와 파티션 프루닝을 제안하더군요. 결과? 54초가 2.9초로 줄었습니다. 솔직히 놀랐습니다. AI도 튜닝을 제법 하네요.
•
SQL Plan Studio는 PostgreSQL과 MySQL의 복잡한 실행계획을 보기 쉽게 정리해주어 쿼리 성능 분석과 튜닝에 도움을 주는 무료 도구입니다.
음. 튜닝도 AI가 제법 잘 하네요. 그러면 이제 SQL 튜너는 필요없을까요?
저는 여전히 필요하다고 생각합니다. 다만 예전처럼 모든 SQL을 꼼꼼하게 분석하는 방식보다는, 튜닝 지식을 바탕으로 AI를 잘 활용할 줄 아는 튜너가 필요해지지 않을까 싶습니다.
AI가 LAG 함수와 파티션 프루닝을 제안했고, 54초짜리 쿼리가 2.9초로 줄었습니다. 결과는 훌륭합니다. 하지만 이게 정말 최선일까요? 다른 데이터 상황에서도 잘 작동할까요? 운영 환경에 반영해도 문제없을까요?
이런 질문에 답하려면 실행 계획을 어느 정도 읽을 줄 알아야 하고, 인덱스가 대략 어떻게 동작하는지 이해해야 하고, 조인 알고리즘을 이해하고, 병목이 어디서 생기는지 찾을 수 있어야 합니다. AI가 답을 주더라도, 그게 맞는지 틀린지 판단하는 건 결국 사람의 몫이니까요.
또한 보안 이슈로 AI가 닿지 못하는 사이트도 많이 있으니까요.
추신.
1.
그래서 저는 지금 이런 기본 지식을 정리한 책을 마무리하고 있습니다. 『SQL TUNER for PostgreSQL 기본원리편』이라는 제목으로요. AI 시대에도 여전히 필요한, 검증의 기준이 되어줄 원리들을 담으려 합니다.
2.
Claude의 OpenClaw에 대해 들어보니.. 지식과 경험도 필요 없을 가능성이 생길까란 생각도 드네요.
아래는 실제 사례입니다.
실제 사례
개선전 SQL의 실행계획(54초)
•
보시는 거처럼 파티션 테이블이 포함되어 있고 실행계획이 길어 분석이 좀 귀찮습니다.
실행계획
SQL Plan Studio의 AI 조언을 돌려 봤습니다. 아래와 같은 조언이 나왔네요.
•
3번의 SQL 재작성 부분은 개인적인 로직이라 일부러 생략했습니다.
AI 조언 결과
AI 조언 결과가 제법 정확합니다. 제 생각도 크게 다르지 않으므로 재작성해준 SQL을 그대로 실행했습니다.
•
54초 SQL이 2.9초로 단축되었습니다.(당연히 재작성된 SQL의 결과는 이전 SQL의 결과와 동일했습니다.)
AI 조언대로 처리한 실행계획