SQL 튜닝 기본 개념은 아는데 왜 실무에서는 막막할까?
인덱스, 실행계획, 힌트는 SQL 튜닝에서 익숙한 개념입니다. 그러나 막상 느려진 쿼리를 마주하면, 어디서부터 손대야 할지 막막해집니다. 무엇을 먼저 확인하고, 어떤 기준으로 개선 방향을 정해야 할지 판단해야 하기 때문입니다.
엑셈이 매년 개최하는 Oracle SQL Tuning 기술 세미나는 올해도 많은 관심 속에 진행됐습니다. 지난 3월에 이어 9월에도 신청 시작 후 빠르게 전석이 마감되며 그 관심이 이어졌습니다.
9월 3일 열린 세미나 신청자 중 43.5%가 '기본 개념은 알지만 실무 적용은 어렵다'고 답했습니다.
이러한 고민은 이번 세미나가 다룬 내용과도 맞닿아 있습니다. 첫 세션은 '무엇을 먼저 튜닝할 것인가'라는 질문에서 시작했습니다.
기술을 아는 것과, 그 기술을 어떤 순서로 적용해야 하는지 아는 것은 다른 문제입니다.
세미나는 대상 선정부터 실행계획 해석, 인덱스와 조인, 상황별 판단까지 성능 개선의 순서를 네 단계로 짚었습니다.
1. 무엇을 먼저 고칠 것인가: SQL 튜닝 대상 선정
SQL 튜닝 세미나였지만, 첫 세션부터 튜닝 기법을 바로 다루지는 않았습니다. 먼저 짚은 것은 '무엇을 먼저 튜닝할 것인가'였습니다. 어떤 SQL을 고칠 것인지 정하지 않은 채 시작하면, 개별 쿼리는 빨라져도 시스템 전체의 부하는 그대로 남을 수 있기 때문입니다.
튜닝 대상을 선정할 때는 어떤 기준으로 SQL을 추출하느냐가 중요합니다. 해결해야 할 문제가 CPU 사용률인데 수행 시간이나 I/O를 기준으로 상위 SQL을 뽑는 경우, 목록에 올라온 SQL을 모두 개선해도 정작 CPU 사용률은 내려가지 않을 수 있습니다. 결국 해결하려는 문제에 맞는 기준을 세워야 실제 성능 개선으로 이어질 수 있습니다.
세션에서는 튜닝 대상을 찾는 경로를 크게 세 가지로 정리했습니다. 업무 담당자의 요구사항, Oracle Dictionary View 조회, 그리고 MaxGauge와 같은 성능 관리 솔루션을 통한 추출입니다. 세 경로는 서로를 대체하기보다 보완합니다. 요구사항은 방향을 알려주고, 조회는 근거를 제공하며, 솔루션은 사람이 미처 보지 못한 영역까지 확인하게 합니다.
특히 일반적인 조회만으로 놓치기 쉬운 SQL까지 확인하려면 도구를 활용한 분석이 필요할 수 있습니다. 세미나에서는 그 사례로 바인드 변수 없이 상수를 그대로 사용한 Literal SQL을 소개했습니다. 개별 SQL의 CPU 비중은 0.01~0.02% 수준에 불과해 상위 SQL 목록에서는 눈에 띄지 않았지만, 같은 형태끼리 묶어보자 상위 세 그룹이 전체 CPU의 20%, 15%, 10%를 차지했습니다. 튜닝 대상을 찾을 때 한 가지 목록이나 지표만으로 판단해서는 안 되는 이유입니다.
💡 SQL 튜닝의 시작은 '어떻게 고칠 것인가'보다 '무엇을 먼저 고칠 것인가'를 정하는 것입니다.
2. 왜 그렇게 동작하는가: 실행계획 해석과 힌트
튜닝 대상을 정했다면, 다음은 해당 SQL이 왜 그렇게 동작하는지 확인할 차례입니다. 실행계획은 그 원인을 파악하기 위한 근거가 됩니다.
실행계획을 해석할 때는 옵티마이저의 예상값과 실제 수행 결과를 함께 살펴봐야 합니다. 옵티마이저가 예측한 처리 건수와 실제 처리 건수에 큰 차이가 있다면, 통계정보나 접근 경로가 적절한지 확인해 볼 필요가 있습니다. 세션에서는 DBMS_XPLAN과 10046 Trace를 활용해 실제 수행 통계를 확인하는 순서를 다뤘습니다. 두 방법은 수집하는 정보의 범위가 다릅니다. 어느 하나가 다른 하나를 대체하는 것이 아니라, 무엇을 확인하려는지에 따라 선택하는 문제입니다.
해석이 끝나면 다음은 그 계획을 바꾸는 단계입니다. 힌트는 실행계획을 변경하는 방법 중 가장 직접적인 수단입니다. SQL 문장 자체를 수정하지 않기 때문에 결과 데이터가 달라질 위험 없이 처리 방식만 조정할 수 있습니다.
다만 힌트를 쓴다는 것은 옵티마이저의 판단을 사람이 대신한다는 뜻이기도 합니다. 옵티마이저는 통계정보를 근거로 계획을 세우는데, 그 통계가 실제 데이터 상태와 어긋나 있으면 판단도 함께 어긋납니다. 통계를 갱신하면 되지 않느냐고 생각할 수 있지만, 통계 갱신은 이미 잘 동작하고 있던 다른 SQL의 실행계획에도 영향을 줄 수 있습니다. 문제가 되는 SQL만 골라 힌트로 해결하는 선택이 필요한 이유입니다.
💡 실행계획은 SQL이 왜 그렇게 동작하는지 판단하기 위한 단서이고, 힌트는 그 판단을 실행으로 옮기는 수단입니다.
3. 구조를 알아야 보이는 것: 인덱스와 조인
실행계획을 읽고 힌트로 방향을 잡았다면, 그다음은 데이터에 어떻게 효율적으로 접근할 것인지 살펴볼 차례입니다. 인덱스와 조인은 그 접근 방식을 결정하는 두 축입니다.
인덱스는 데이터를 빠르게 찾기 위한 대표적인 방법이지만, 인덱스가 있다는 사실만으로 효율적인 접근이 보장되지는 않습니다. 같은 컬럼으로 구성된 인덱스라도 어떤 조건이 어떤 순서로 들어오는지에 따라 실제 활용되는 범위가 달라질 수 있습니다. 따라서 단순히 인덱스를 추가하기보다, 이미 구성된 인덱스를 SQL이 어떻게 활용하고 있는지 함께 살펴봐야 합니다. 인덱스가 없어서가 아니라 있는 인덱스를 제대로 활용하지 못해 성능이 저하되는 경우도 있기 때문입니다.
조인도 마찬가지입니다. 어떤 조인 방식을 사용했는지만 확인하는 데서 끝나는 것이 아니라, 여러 테이블을 어떤 순서와 방식으로 연결하는지 함께 살펴봐야 합니다. 데이터에 접근하는 순서와 처리 방식에 따라 성능이 달라질 수 있기 때문입니다. 세션에서는 Nested Loop와 Hash Join, Sort Merge Join을 나란히 놓고 각각이 유리한 조건을 비교했습니다. 처리하는 데이터의 양과 연결 구조에 따라 적합한 방식이 달라지기 때문입니다.
결국 인덱스와 조인을 튜닝하려면 각각의 기능을 아는 것에서 나아가, 실행계획 안에서 데이터가 어떤 경로로 처리되는지 읽을 수 있어야 합니다.
4. 정답은 코드가 아니라 상황에 있다: SQL Tuning 방법론
대상을 정하고, 실행계획을 읽고, 접근 구조를 파악했다면 이제 어떻게 고칠 것인가가 남습니다. 마지막 세션에서 다룬 것이 이 지점입니다.
SQL 튜닝에는 모든 상황에 통하는 하나의 정답이 있지 않습니다. 같은 SQL 구조나 튜닝 기법도 처리해야 할 데이터의 양과 실행 환경에 따라 성능에 미치는 영향이 달라지기 때문입니다. 특정 기법을 정답처럼 적용하기보다, 현재 성능 문제의 원인과 데이터 처리 과정을 먼저 파악하고 그에 맞는 방법을 선택해야 합니다.
세미나에서 다룬 스칼라 서브쿼리 사례가 이를 잘 보여줍니다. 50만 건을 추출해야 하는 상황에서는 스칼라 서브쿼리가 성능 저하의 원인이 될 수 있지만, 반대로 10건만 추출하는 상황에서는 효율적인 방법이 될 수 있습니다. 한쪽에서 원인이었던 기법이 다른 쪽에서는 해법이 된 것입니다. 무엇을 쓸 것인가보다 지금 처리하는 데이터가 어떤 상태인지를 판단 기준으로 삼아야 합니다.
결국 이번 세미나가 짚은 SQL 튜닝의 핵심은 개별 기법보다 성능 문제를 바라보는 순서에 있습니다. 무엇을 먼저 튜닝할지 대상을 정하고, 실행계획을 통해 원인을 파악한 뒤, 인덱스와 조인 등 데이터 처리 구조를 살펴보고, 마지막으로 현재 상황에 적합한 방법을 선택하는 과정입니다.
이러한 판단을 위해서는 무엇보다 현재 시스템의 상태를 정확하게 파악할 수 있어야 합니다. exemONE Observability는 이 지점에서 출발합니다. DB를 포함한 IT 인프라 전반의 성능 데이터를 한곳에서 확인할 수 있도록 통합해, 무엇이 달라졌고 어디에서 지연이 발생하는지를 먼저 보여줍니다. 최종 판단은 사람의 몫이지만, 필요한 정보가 갖춰져 있다면 문제를 파악하고 해결 방향을 정하는 과정은 훨씬 빨라집니다.
엑셈은 앞으로도 다양한 DBMS를 주제로 실무에 필요한 기술과 노하우를 지속적으로 공유할 예정입니다.
오는 11월 5일에는 『PostgreSQL Wait Interface』 저자들과 함께하는 PostgreSQL 기술 웨비나가 온라인으로 진행됩니다. 사전 신청은 9월 29일부터 엑셈 홈페이지에서 오픈될 예정입니다.
웨비나에 앞서 주제를 미리 살펴보고 싶다면, 『PostgreSQL Wait Interface』 출간 인터뷰에서 책의 주요 내용을 먼저 확인해 보세요.
SQL 성능부터 IT 인프라 전반까지 통합 관리가 궁금하다면?
함께 보면 좋은 아티클
