SQL 쿼리 튜닝은 실행 계획 읽기부터 시작한다

SQL 쿼리 튜닝은 실행 계획 읽기부터 시작한다

쿼리 튜닝은 한 번 정리하고 끝나는 주제가 아니라, 서비스를 만들고 운영하는 동안 계속 다시 마주치는 판단 기준입니다. 처음에는 작은 불편처럼 보여도 시간이 지나면 장애 대응, 유지보수, 비용, 사용자 경험에 직접적인 영향을 줍니다. 그래서 이 글에서는 거창한 이론보다 실제 작업 전에 확인할 기준과 바로 적용할 순서를 중심으로 정리합니다.

왜 지금 확인해야 하나

문제가 작을 때는 사람의 기억과 임시 대응으로도 버틸 수 있습니다. 하지만 사용자가 늘거나 기능이 많아지면 같은 방식은 금방 한계에 부딪힙니다. 기준이 없으면 매번 다른 사람이 다른 방식으로 판단하고, 그 결과는 코드와 운영 문서 곳곳에 흩어집니다.

특히 쿼리 튜닝처럼 여러 팀원이 함께 영향을 받는 항목은 초기에 기준을 잡아두는 편이 좋습니다. 나중에 고치려면 기존 코드, 문서, 배포 방식, 사용자 안내까지 함께 수정해야 할 수 있기 때문입니다.

먼저 볼 신호

아래 항목 중 하나라도 반복된다면 개선할 시점으로 볼 수 있습니다.

• 같은 문제가 두 번 이상 다른 화면이나 기능에서 반복된다.
• 담당자만 알고 있는 수동 절차가 있다.
• 실패했을 때 원인을 확인하는 데 필요한 로그나 기록이 부족하다.
• 변경 전후의 차이를 숫자나 체크리스트로 설명하기 어렵다.
• 문제를 고친 뒤에도 재발을 막는 장치가 남지 않는다.

이 신호들은 모두 “현재 방식이 개인의 기억에 기대고 있다”는 뜻에 가깝습니다. 개인의 기억은 빠르지만 오래가지 않고, 팀이 커질수록 쉽게 끊깁니다.

적용 순서

가장 현실적인 출발점은 문제를 작게 쓰는 것입니다. 예를 들어 “운영이 어렵다”가 아니라 “장애 발생 후 원인 로그를 찾는 데 20분 이상 걸린다”처럼 적어야 합니다. 이렇게 쓰면 어떤 정보를 남겨야 하는지, 어떤 자동화를 붙여야 하는지, 어떤 문서를 고쳐야 하는지가 훨씬 선명해집니다.

다음으로 현재 절차를 그대로 기록합니다. 이상적인 절차를 새로 만들기 전에 지금 사람들이 실제로 어떻게 일하는지 먼저 적어야 합니다. 그래야 불필요한 단계와 꼭 남겨야 할 단계를 구분할 수 있습니다.

그 뒤에는 반복되는 판단을 체크리스트로 바꿉니다. 실행 계획에서 full scan, join 순서, estimated rows를 확인하면 병목의 실체가 보입니다. 이 기준을 문서나 PR 템플릿, 배포 체크리스트, 모니터링 대시보드 안에 넣어두면 개인의 숙련도 차이를 줄일 수 있습니다.

마지막으로 한 번에 크게 바꾸지 말고 다음 작업부터 적용합니다. 이미 진행 중인 모든 일을 동시에 고치려 하면 부담이 커지고, 결국 규칙이 흐려집니다. 새 작업 하나에 적용하고, 효과가 있으면 범위를 넓히는 편이 오래 갑니다.

자주 놓치는 점

좋은 기준은 길고 복잡한 문서가 아닙니다. 오히려 너무 긴 문서는 읽히지 않습니다. 담당자가 바뀌어도 같은 판단을 할 수 있을 정도의 문장, 실패했을 때 바로 확인할 수 있는 링크, 실행 여부를 확인할 수 있는 체크박스가 더 유용합니다.

또 하나 중요한 점은 예외를 기록하는 것입니다. 모든 상황을 규칙으로 막을 수는 없습니다. 다만 예외가 발생했을 때 왜 예외로 처리했는지 남겨두면, 나중에 같은 상황을 만났을 때 훨씬 빠르게 판단할 수 있습니다.

마무리

SQL 쿼리 튜닝은 실행 계획 읽기부터 시작한다의 핵심은 더 많은 도구를 붙이는 데 있지 않습니다. 문제를 관찰 가능한 형태로 만들고, 반복되는 판단을 문서와 시스템 안으로 옮기고, 다음 사람이 같은 품질로 이어갈 수 있게 만드는 일입니다. 작게 시작해도 꾸준히 남기면 운영 품질은 분명히 달라집니다.