데이터베이스나 백엔드 관련 직무를 준비하는 취업 준비생의 프로젝트를 점검하다 보면 SQL 쿼리는 충분히 작성할 수 있는데, 이 쿼리가 왜 느린가를 설명하는 단계에서 막히는 경우가 있습니다. JOIN과 GROUP BY, 서브쿼리까지 사용해 원하는 결과를 만들었고 기능도 정상적으로 동작합니다. 그런데 데이터가 수십만 건으로 늘어난 뒤 조회 시간이 길어졌을 때 어느 부분부터 확인해야 하는지, 인덱스를 추가했는데 왜 성능이 거의 달라지지 않았는지, 실행계획에서 어떤 항목을 봐야 하는지를 질문하면 다시 SQL 문장만 수정하는 경우가 있습니다. 반대로 인덱스를 추가하면 빨라진다, Full Scan은 느리다처럼 튜닝 관련 용어는 알고 있지만 실제 데이터를 이용한 전후 비교가 없는 프로젝트도 많습니다. 테이블에 데이터가 몇백 건 인 상태에서 인덱스를 만들면 실행시간 차이가 거의 나타나지 않을 수 있고, 특정 인덱스를 추가했다고 해도 데이터 분포나 조회 조건 때문에 데이터베이스가 해당 인덱스를 선택하지 않을 수도 있습니다. 인덱스를 많이 만들면 읽기 성능에는 도움이 되는 상황이 있더라도 저장공간과 INSERT·UPDATE 비용이 늘어날 수 있습니다. SQL 튜닝 실습의 핵심은 복잡한 쿼리를 만드는 데 있지 않습니다. 먼저 느린 상황을 재현하고, 실행계획을 이용해 데이터베이스가 실제로 어떤 순서와 방식으로 데이터를 읽는지 확인한 뒤, 인덱스나 SQL 구조를 변경하고 같은 조건에서 다시 비교해야 합니다. 그래야 빨라진 것 같다가 아니라 어떤 원인이 있었고 무엇을 수정했는지를 설명할 수 있습니다. 예를 들어 주문 데이터가 100만 건 있고 특정 고객의 최근 주문을 조회하는 쿼리가 느리다고 가정할 수 있습니다. 처음에는 전체 테이블을 많이 읽고 있었는지, 고객 ID와 주문일 조건에 적합한 접근 경로가 없는지, JOIN 이후 중간 결과가 지나치게 커지는지, 정렬과 집계에서 시간이 많이 소비되는지를 나누어 확인할 수 있습니다. 수정 이후에는 동일한 데이터와 같은 조건으로 실행계획과 실행시간, 읽은 행 수를 다시 확인해야 합니다. SQL 튜닝 포트폴리오에서 중요한 것은 인덱스를 몇 개 만들었는지가 아니라 실행계획으로 원인을 찾고, 변경 전후를 같은 조건으로 검증해 병목이 실제로 줄었는지를 보여주는 것입니다.
이번 글에서는 취업 준비생이 SQL 튜닝을 실습할 때 확인해야 할 부분을 실행계획, 인덱스, 병목 세 가지 기준으로 나누어 정리하겠습니다.
실행계획은 SQL 문장이 실제로 어떤 순서와 방식으로 처리되는지 확인하는 출발점입니다
- SQL이 느리다면 문장보다 데이터베이스가 실제로 수행한 작업부터 확인할 필요가 있습니다
SQL만 읽어보고 성능을 판단하면 실제 데이터베이스가 선택한 처리 방법과 다르게 추측할 수 있습니다. 같은 SQL이라도 테이블의 데이터량과 값의 분포, 인덱스 유무와 통계정보 등에 따라 실행 방식이 달라질 수 있기 때문입니다.
실행계획 실습에서는 다음 내용을 연결해서 볼 수 있습니다.
- 어떤 테이블부터 접근하는지 확인합니다.
- 전체 데이터를 읽는 구간이 있는지 살펴봅니다.
- 인덱스를 사용하는 구간과 사용하지 않는 구간을 구분합니다.
- JOIN이 어떤 순서로 진행되는지 확인합니다.
- 정렬과 집계가 어느 단계에서 발생하는지 살펴봅니다.
- 예상보다 많은 행을 처리하는 지점을 찾습니다.
예를 들어 주문 테이블에서 특정 사용자 한 명의 주문을 조회하는데 전체 데이터에 가까운 행을 읽고 있다면 단순히 SELECT 칼럼을 줄이는 것으로는 큰 차이가 없을 수 있습니다. 사용자 ID 조건을 이용해 데이터를 빠르게 좁힐 수 있는 접근 경로가 있는지부터 확인해야 합니다. 이런 과정을 포트폴리오에 남기면 SQL 튜닝 경험이 쿼리를 수정했다가 아니라 데이터베이스가 어떤 방식으로 SQL을 처리하는지 분석한 경험으로 보입니다.
- 실행계획의 비용값과 실제 실행결과는 같은 의미로 받아들이지 않는 것이 좋습니다
실행계획에는 데이터베이스가 예상한 처리량과 비용, 접근 방식이 표시될 수 있습니다. 하지만 예상값과 실제 실행 과정은 데이터 분포와 통계정보 등에 따라 차이가 발생할 수 있기 때문에 숫자 하나만 보고 성능을 판단하기 어렵습니다.
- 예상 실행계획: SQL을 실행하기 전에 옵티마이저가 선택할 것으로 예상한 처리 경로를 보여줍니다.
- 실제 실행정보: 쿼리가 수행된 이후 실제 처리 행 수와 소요시간 등을 확인할 수 있는 환경에서는 예상과 실제를 비교하는 데 활용할 수 있습니다.
- 예상 행 수: 옵티마이저가 해당 단계에서 처리할 것으로 판단한 데이터 규모입니다.
- 실제 행 수: 실제 실행 결과에서 해당 연산이 처리한 데이터 규모입니다.
- 차이가 큰 구간: 통계정보와 조건 선택도, 데이터 분포 등을 추가로 살펴볼 필요가 있는 지점이 될 수 있습니다.
예를 들어 옵티마이저는 특정 조건에서 100건 정도를 예상했는데 실제로는 수십만 건을 처리한다면 이후 JOIN 방식이나 접근 경로 선택에도 영향을 줄 수 있습니다. 따라서 실행계획에서는 Index Scan이니까 정상, Full Scan이니까 비정상처럼 하나의 연산 이름만 보는 방식보다 전체 처리 흐름과 데이터량을 함께 보는 편이 좋습니다.
- 실행계획을 읽을 때는 가장 많은 데이터를 처리하는 구간부터 좁혀보는 방식이 효율적입니다
처음 실행계획을 보면 여러 단계와 수치가 한 번에 나타나기 때문에 어디를 봐야 할지 어려울 수 있습니다. 이때 모든 항목을 동시에 해석하기보다 처리량이 크거나 예상보다 시간이 많이 소비되는 부분부터 원인을 좁힐 수 있습니다.
실습에서는 다음 내용을 확인할 수 있습니다.
- 가장 많은 행을 읽는 연산을 찾습니다.
- 필터 적용 전후 데이터량이 크게 달라지는지 확인합니다.
- JOIN 직전에 중간 결과가 과도하게 커지는지 살펴봅니다.
- 불필요한 정렬이나 임시 작업이 발생하는지 확인합니다.
- 같은 테이블을 반복해서 읽는 부분이 있는지 살펴봅니다.
- 수정 이후 동일 지점의 처리량이 실제로 줄었는지 비교합니다.
예를 들어 주문과 주문상품, 상품 테이블을 조인하는 쿼리에서 JOIN 전에 주문 기간을 충분히 좁히지 못하면 필요 없는 과거 주문까지 대량으로 읽은 뒤 뒤늦게 필터링할 수 있습니다. 이 경우 문제는 최종 SELECT 문이 아니라 데이터를 줄이는 시점과 접근 경로에 있을 수 있습니다. 이런 분석 과정을 남기면 실행계획 화면을 캡처한 것보다 실제로 무엇을 읽고 판단했는지가 더 명확하게 드러납니다.
- 좋은 실행계획 실습은 변경 전과 변경 후를 같은 조건에서 비교합니다
SQL 튜닝 프로젝트에서 가장 아쉬운 부분은 수정 전 실행계획만 보여주고 최종적으로 얼마나 달라졌는지를 남기지 않는 경우입니다. 실행계획은 문제를 찾는 도구이면서 동시에 변경 효과를 확인하는 자료가 될 수 있습니다.
- 변경 전 상태: 어떤 접근 방식과 JOIN 순서가 선택되었는지 기록합니다.
- 문제 지점: 과도한 행 읽기와 불필요한 정렬 등 병목으로 의심되는 부분을 정리합니다.
- 변경 작업: SQL 구조나 인덱스, 조건 등을 수정합니다.
- 변경 후 상태: 같은 데이터와 조건으로 실행계획을 다시 확인합니다.
- 최종 검증: 처리 행 수와 실행시간, 결과 데이터의 정확성을 함께 비교합니다.
예를 들어 인덱스를 추가한 뒤 전체 테이블 읽기에서 인덱스 기반 접근으로 바뀌었다고 해도 최종 응답시간이 거의 같을 수 있습니다. 그렇다면 실제 병목이 JOIN이나 정렬, 다른 쿼리에 있었는지를 다시 확인해야 합니다. 포트폴리오에서는 실행계획 캡처 → 문제 추정 → 수정 → 재실행계획 → 결과 비교의 흐름이 보여야 분석 과정이 선명해집니다.
인덱스는 많이 만드는 기능이 아니라 필요한 데이터를 더 적은 범위에서 찾도록 접근 경로를 설계하는 요소입니다
- 인덱스 실습은 조회 조건과 데이터 분포를 함께 보는 것에서 시작하는 편이 좋습니다
SQL 튜닝을 공부하면 느린 쿼리에 인덱스를 추가하는 것부터 떠올리기 쉽습니다. 하지만 모든 칼럼에 인덱스를 만들 수는 없으며 어떤 조건으로 데이터를 자주 찾는지와 값이 어떻게 분포되어 있는지를 함께 봐야 합니다.
인덱스 실습에서는 다음 내용을 확인할 수 있습니다.
- WHERE 조건에서 자주 사용하는 칼럼을 구분합니다.
- JOIN에 사용되는 키를 확인합니다.
- 데이터 값이 얼마나 다양하게 분포되어 있는지 살펴봅니다.
- 전체 데이터 가운데 실제 조회하는 범위가 어느 정도인지 확인합니다.
- 여러 조건이 함께 사용되는 패턴을 정리합니다.
- 인덱스 추가 전후 실행계획을 비교합니다.
예를 들어 회원 상태가 정상, 휴면, 탈퇴 세 종류밖에 없는데 대부분이 정상 회원이라면 상태 칼럼 하나에 인덱스를 만들었다고 항상 큰 효과가 발생한다고 단정하기 어렵습니다. 반대로 고객 ID처럼 많은 값이 존재하고 특정 고객 한 명만 조회하는 조건이라면 적절한 인덱스를 통해 검색 범위를 크게 줄일 수 있는 상황이 생길 수 있습니다. 따라서 인덱스 실습에서는 생성 문법보다 어떤 쿼리를 위해 왜 해당 칼럼을 선택했는지를 먼저 설명할 수 있어야 합니다.
- 단일 인덱스와 복합 인덱스는 사용하는 쿼리 조건에 따라 효과가 달라질 수 있습니다
실제 SQL에서는 하나의 칼럼만 조건으로 사용하는 것보다 고객 ID와 날짜, 상태처럼 여러 조건을 함께 사용하는 경우가 많습니다. 이때 각각 단일 인덱스를 만들 것인지와 여러 칼럼을 하나의 복합 인덱스로 구성할 것인지는 실제 조회 패턴을 기준으로 판단해야 합니다.
- 단일 인덱스: 특정 칼럼을 독립적으로 자주 검색하는 쿼리에 활용할 수 있습니다.
- 복합 인덱스: 여러 칼럼이 함께 사용되는 반복적인 검색 조건에서 후보가 될 수 있습니다.
- 칼럼 순서: 어떤 조건이 자주 사용되고 데이터를 얼마나 빠르게 줄일 수 있는지 등을 함께 고려해야 합니다.
- 정렬 활용: 조회 조건과 ORDER BY 패턴에 따라 인덱스가 정렬 작업에도 영향을 줄 수 있습니다.
- 불필요한 복합 인덱스: 실제 쿼리에서 거의 사용되지 않는 조합이라면 유지비용만 늘어날 수 있습니다.
예를 들어 customer_id와 order_date를 이용해 특정 고객의 최근 주문을 자주 조회한다면 해당 쿼리 패턴에 맞는 복합 인덱스를 비교해 볼 수 있습니다. 하지만 날짜만 검색하는 쿼리가 매우 많다면 같은 인덱스가 모든 상황을 해결한다고 볼 수는 없습니다. 이런 차이를 이해하면 인덱스 이름을 외우는 것보다 실제 workload에 맞는 접근 경로를 설계한 경험으로 튜닝 실습을 발전시킬 수 있습니다.
- 인덱스를 추가했다면 읽기 성능뿐 아니라 쓰기 작업에 미치는 영향도 함께 확인하는 편이 좋습니다
인덱스는 조회 성능 개선에 활용될 수 있지만 데이터를 INSERT 하거나 UPDATE, DELETE 할 때는 인덱스도 함께 관리해야 합니다. 따라서 많이 만들수록 항상 좋은 구조가 되는 것은 아닙니다.
프로젝트에서는 다음 내용을 비교할 수 있습니다.
- 인덱스 추가 전 조회시간을 기록합니다.
- 인덱스 추가 후 실행계획 변화를 확인합니다.
- 같은 조회에서 처리 데이터량이 줄었는지 비교합니다.
- 데이터 INSERT 작업에서 차이가 생기는지 살펴봅니다.
- 사용하지 않는 인덱스가 늘어나지 않는지 확인합니다.
- 최종적으로 필요한 인덱스만 유지할 근거를 정리합니다.
예를 들어 조회 화면 하나를 빠르게 만들기 위해 여러 개의 인덱스를 추가했는데 해당 테이블이 초당 많은 데이터를 저장하는 로그성 테이블이라면 쓰기 성능까지 함께 고려해야 할 수 있습니다. 이렇게 장단점을 비교하면 인덱스를 추가해서 빨라졌다보다 조회와 변경 작업 사이에서 어떤 선택을 했는지를 설명할 수 있습니다.
- 인덱스가 있는 데 사용되지 않는다면 쿼리와 데이터 조건을 다시 확인해야 합니다
인덱스를 생성했는데 실행계획에서 사용하지 않는다고 해서 데이터베이스가 잘못된 것은 아닙니다. 옵티마이저는 데이터량과 조건, 비용 등을 기반으로 더 적절하다고 판단한 경로를 선택할 수 있습니다.
- 선택도가 낮은 경우: 조건을 만족하는 데이터가 너무 많다면 전체 접근이 더 효율적이라고 판단될 수 있습니다.
- 테이블이 작은 경우: 전체 데이터를 읽어도 비용이 크지 않아 인덱스 이점이 작을 수 있습니다.
- 조건 표현 문제: 칼럼에 함수나 변환이 적용되면 기존 인덱스 활용 방식에 영향을 줄 수 있습니다.
- 복합 인덱스 조건 문제: 인덱스의 칼럼 구성과 실제 검색 조건이 잘 맞지 않을 수 있습니다.
- 통계정보 문제: 데이터 분포 변화가 충분히 반영되지 않았다면 옵티마이저 판단과 실제 데이터 상태가 차이 날 수 있습니다.
따라서 실습에서는 인덱스를 생성한 뒤 반드시 실행계획을 다시 확인하는 과정이 필요합니다. 인덱스 생성 자체보다 데이터베이스가 실제로 어떤 접근 경로를 선택했고 그 선택이 처리량과 시간에 어떤 영향을 줬는지가 튜닝 포트폴리오에서 더 중요한 내용입니다.
병목은 SQL 문장 하나가 아니라 데이터량과 JOIN, 정렬, 애플리케이션 호출까지 전체 흐름에서 찾아야 합니다
- 병목 분석에서는 먼저 느리다는 상태를 측정 가능한 기준으로 만드는 것이 중요합니다
조회가 느리다는 표현만으로는 무엇을 개선해야 하는지 판단하기 어렵습니다. 같은 SQL도 데이터 크기와 동시 사용자 수, 캐시 상태와 시스템 자원에 따라 체감 속도가 달라질 수 있기 때문에 실습 조건을 일정하게 만들어야 합니다.
병목 실습에서는 다음 내용을 기록할 수 있습니다.
- 테스트 데이터 규모를 일정하게 유지합니다.
- 실행 전후 시간을 같은 방식으로 측정합니다.
- 첫 실행과 반복 실행 결과 차이를 확인합니다.
- 반환되는 데이터 건수를 기록합니다.
- 실행계획에서 처리되는 주요 행 수를 함께 남깁니다.
- 수정한 요소를 한 번에 하나씩 구분해 비교합니다.
예를 들어 쿼리 A는 2초, 쿼리 B는 0.5초라고 기록하는 것만으로는 부족할 수 있습니다. 같은 데이터와 동일한 조건인지와 결과 건수도 같은지, 인덱스 캐시 등 반복 실행에 따른 차이는 없는지를 함께 확인해야 비교 의미가 생깁니다. 이렇게 기준을 정하면 SQL 튜닝이 느낌에 의한 수정이 아니라 측정 가능한 성능 실험으로 바뀝니다.
- SQL 자체의 병목과 데이터 접근 병목은 수정해야 하는 위치가 다릅니다
느린 SQL이라고 해서 항상 문장을 짧게 다시 작성해야 하는 것은 아닙니다. 문법 구조보다 데이터 접근 방식이나 JOIN 과정에서 훨씬 많은 작업이 발생하는 경우도 있습니다.
- 조건 병목: 필요한 데이터를 초기에 충분히 줄이지 못해 많은 행을 처리합니다.
- JOIN 병목: 큰 테이블끼리 결합하면서 중간 결과가 지나치게 커질 수 있습니다.
- 정렬 병목: 많은 데이터를 ORDER BY 하거나 GROUP BY 하면서 추가 작업이 발생합니다.
- 접근 경로 병목: 적절한 인덱스가 없어 반복적으로 많은 데이터를 읽습니다.
- 반복 호출 병목: 애플리케이션에서 동일하거나 유사한 SQL을 과도하게 여러 번 실행합니다.
예를 들어 상품 목록 100개를 조회한 뒤 각 상품별 상세정보를 별도 SQL로 다시 요청한다면 하나의 SQL 실행시간은 짧아도 전체 화면에서는 많은 DB 호출이 발생할 수 있습니다. 이 경우에는 특정 SQL 튜닝보다 애플리케이션의 데이터 조회 구조를 개선하는 것이 더 큰 효과를 만들 수도 있습니다. 따라서 병목 분석에서는 개별 쿼리와 전체 요청 흐름을 함께 볼 필요가 있습니다.
- 튜닝 프로젝트에서는 한 가지 원인만 가정하지 않고 후보를 하나씩 제거하는 과정이 중요합니다
느린 쿼리를 보면 가장 먼저 인덱스를 추가하는 방식으로 접근하기 쉽습니다. 하지만 실제 병목이 잘못된 JOIN이나 과도한 결과 반환에 있다면 인덱스만 추가해서는 큰 개선이 나타나지 않을 수 있습니다.
원인 분석에서는 다음 과정을 연결할 수 있습니다.
- 실행계획으로 가장 많은 작업이 발생하는 지점을 찾습니다.
- 필요 이상으로 많은 행을 읽는지 확인합니다.
- JOIN 조건과 테이블 관계가 정확한지 살펴봅니다.
- 불필요한 칼럼과 결과 데이터가 포함되는지 확인합니다.
- 인덱스가 현재 조회 패턴과 맞는지 검토합니다.
- 한 가지 변경 후 같은 조건으로 결과를 다시 측정합니다.
예를 들어 JOIN 결과가 예상보다 수십 배 늘어난다면 새로운 인덱스를 만드는 것보다 테이블 관계와 JOIN 조건부터 확인해야 합니다. 반대로 JOIN 구조는 정상인데 특정 테이블에서 대부분의 데이터를 반복해서 읽고 있다면 인덱스 후보를 검토할 수 있습니다. 이 과정을 기록하면 SQL 튜닝 경험이 인터넷에서 본 방법을 적용했다가 아니라 여러 원인 가운데 실제 병목을 좁혀간 경험으로 발전합니다.
- 포트폴리오에서는 얼마나 빨라졌는지보다 왜 빨라졌는지를 설명할 수 있어야 합니다
튜닝 프로젝트에서 실행시간이 5초에서 0.5초로 줄었다는 결과는 눈에 잘 띕니다. 하지만 데이터량과 측정 조건이 명확하지 않거나 원인 설명이 없다면 해당 수치만으로 역량을 판단하기 어렵습니다.
- 실습 환경: DBMS와 데이터 규모, 주요 테이블 관계를 기록합니다.
- 초기 문제: 어느 쿼리가 어떤 조건에서 느렸는지 설명합니다.
- 원인 분석: 실행계획에서 어떤 병목을 확인했는지 정리합니다.
- 개선 작업: 인덱스나 SQL 구조 등 어떤 요소를 왜 변경했는지 기록합니다.
- 재검증: 동일한 조건에서 실행계획과 시간을 다시 비교합니다.
- 남은 한계: 데이터 규모 확대나 동시접속 환경 등 현재 실습에서 충분히 검증하지 못한 영역을 구분합니다.
이 구조가 있으면 성능 수치가 크지 않더라도 지원자가 튜닝 과정을 어떻게 접근했는지 알 수 있습니다. 특히 면접에서도 인덱스를 넣어서 빨라졌습니다보다 실행계획에서 전체 데이터 접근을 확인했고, 조회 패턴에 맞는 인덱스를 적용한 뒤 처리 행 수와 실행시간을 다시 비교했다고 설명할 수 있습니다.
- conclusion
SQL 튜닝을 취업 준비 과정에서 실습할 때 가장 피해야 할 방식은 느린 쿼리를 하나 만들고 인덱스를 추가한 뒤 실행시간이 줄었다는 결과만 남기는 것입니다. 실제 튜닝은 어떤 쿼리가 느리다는 사실에서 끝나는 것이 아니라 데이터베이스가 그 SQL을 어떤 방식으로 처리하고 있는지 확인하고, 여러 병목 후보 가운데 실제 원인을 좁혀 적절한 수정 방법을 선택하는 과정에 가깝습니다. 실행계획에서는 SQL 문장만 보고 예상한 것과 실제 처리 방식이 같은지 확인해야 합니다. 어느 테이블부터 읽는지와 몇 건의 데이터를 처리하는지, JOIN과 정렬은 어느 단계에서 발생하는지를 확인하면 튜닝의 시작점을 더 구체적으로 정할 수 있습니다. 인덱스에서는 많을수록 좋다는 접근을 피하는 것이 중요합니다. 조회 조건과 데이터 분포, JOIN 패턴을 기준으로 필요한 접근 경로를 설계하고 실제 실행계획에서 해당 인덱스가 사용되는지 확인해야 합니다. 동시에 INSERT와 UPDATE 같은 쓰기 작업과 저장공간에도 영향을 줄 수 있다는 점을 함께 고려해야 합니다. 병목 분석에서는 하나의 SQL 내부뿐 아니라 애플리케이션에서 얼마나 자주 호출되는지와 어떤 크기의 결과를 반환하는지까지 볼 필요가 있습니다. SQL 한 번은 빠르더라도 동일한 요청이 반복되면 전체 서비스는 느릴 수 있기 때문입니다. 반대로 실행계획에서 특정 단계가 대부분의 처리량을 차지한다면 해당 부분을 중심으로 원인을 좁힐 수 있습니다.
최종적으로 확인할 항목은 다음과 같습니다.
- 실행계획에서 테이블 접근 순서와 처리 행 수를 설명할 수 있는지 확인합니다.
- 예상 처리량과 실제 처리량의 차이를 비교했는지 살펴봅니다.
- 조회 패턴을 기준으로 인덱스를 선택한 근거가 있는지 확인합니다.
- 인덱스 적용 이후 실행계획이 실제로 달라졌는지 점검합니다.
- JOIN과 정렬, 반복 호출 등 다른 병목 가능성도 함께 확인했는지 살펴봅니다.
- 동일한 데이터와 조건으로 변경 전후 성능을 재검증했는지 확인합니다.
SQL 튜닝 실습 흐름은 다음과 같이 연결할 수 있습니다.
- SQL 기본 문법 → 테이블 관계 이해 → 충분한 테스트 데이터 구성 → 느린 쿼리 재현 → 기준 실행시간 측정 → 실행계획 확인 → 처리 행 수·JOIN·정렬 분석 → 병목 후보 분류 → 인덱스 설계 → SQL 구조 수정 → 동일 조건 재실행 → 실행계획 변화 확인 → 성능·정확성 재검증 → 쓰기 성능 영향 확인 → 튜닝 전후 문서화 → 포트폴리오와 면접 연결
결국 취업 준비생에게 필요한 SQL 튜닝 실습은 데이터베이스 전문가 수준의 모든 내부 구조를 외우는 것이 아닙니다. 실행계획에서는 데이터가 실제로 어떻게 처리되는지 읽고, 인덱스에서는 조회 패턴에 맞는 접근 경로를 설계하며, 병목 분석에서는 느려지는 원인을 측정과 비교를 통해 좁혀갈 수 있어야 합니다. 이 세 과정이 하나의 실습 안에서 연결되어 있다면 단순히 SQL을 작성할 수 있다는 설명을 넘어, 성능 문제가 발생했을 때 원인을 분석하고 변경 결과를 검증한 경험으로 포트폴리오와 면접에서 더 구체적으로 보여줄 수 있습니다.