개발을 하다 보면 언젠가는 반드시 “쿼리가 너무 느립니다”라는 이야기를 듣게 된다. 특히 제조·MES·PLM 같은 대용량 데이터를 다루는 프로젝트에서는 SQL 성능 문제가 생각보다 자주 발생한다. 나 역시 삼성 계열 프로젝트를 진행하면서 데이터 조회 속도 문제를 여러 번 경험했다. 처음에는 단순히 서버 문제라고 생각했지만, 실제 원인은 SQL 구조나 인덱스 문제인 경우가 많았다. 오늘은 실무에서 Oracle 쿼리가 느릴 때 실제로 가장 먼저 확인하는 것들을 경험 기준으로 정리해보려고 한다.
💻 가장 먼저 보는 건 Index 사용 여부
쿼리가 느릴 때 실무에서 가장 먼저 확인하는 건 인덱스(Index) 사용 여부다.
처음 개발 공부할 때는 데이터가 많지 않아서 성능 차이를 크게 느끼기 어렵다. 하지만 운영 환경에서는 데이터가 수십만 건, 많게는 수천만 건 이상 쌓이는 경우도 있다.
이런 상황에서 인덱스 없이 조회하면 데이터베이스가 전체 데이터를 모두 검색하게 된다. 이를 Full Scan이라고 한다. 데이터 양이 많아질수록 속도 차이는 엄청나게 커진다.
예전에 MES 품질 데이터 조회 기능을 개발했을 때도 특정 조회 화면이 너무 느려서 원인을 확인해본 적이 있었다. 처음에는 서버 문제라고 생각했는데 실제로는 WHERE 조건 컬럼에 인덱스가 없었던 게 원인이었다.
인덱스를 추가한 뒤 조회 속도가 눈에 띄게 빨라졌고, 그 이후부터는 성능 이슈가 발생하면 가장 먼저 실행계획과 인덱스를 확인하는 습관이 생겼다.
특히 Oracle에서는:
- WHERE 조건 컬럼
- JOIN 조건 컬럼
- 자주 조회되는 컬럼
위주로 인덱스를 확인하는 경우가 많다.
🔑 실행계획(EXPLAIN PLAN)은 거의 필수다
실무에서는 단순히 SQL 문만 보는 것이 아니라 실행계획(EXPLAIN PLAN)을 같이 확인하는 경우가 많다.
실행계획은 Oracle이 해당 SQL을 어떤 방식으로 처리하는지 보여주는 정보다. 쉽게 말하면:
- Index Scan 사용 여부
- Full Table Scan 여부
- JOIN 방식
- 예상 비용
같은 내용을 확인할 수 있다.
처음에는 실행계획 화면이 너무 복잡하게 느껴졌는데, 계속 보다 보니 어느 정도 패턴이 보이기 시작했다.
특히 Full Table Scan이 발생하면 대부분 성능 이슈 가능성을 의심하게 된다. 물론 데이터 양이 적으면 큰 문제가 없을 수도 있지만, 운영 데이터가 많아질수록 속도 차이가 커진다.
예전에 반도체 데이터 파싱 프로젝트를 진행할 때도 특정 배치 프로그램 속도가 너무 느려서 실행계획을 확인했는데, 불필요한 Full Scan이 여러 번 발생하고 있었다.
쿼리 조건을 수정하고 인덱스를 정리한 뒤 처리 시간이 크게 줄어든 경험이 있다.
실무에서는 결국:
- “쿼리가 왜 느린지”
- “DB가 어떤 방식으로 처리하는지”
를 이해하는 게 중요했다.
📊 WHERE 조건과 JOIN 구조도 굉장히 중요하다
생각보다 SQL 성능은 작은 차이에서도 크게 달라진다.
특히 WHERE 조건 작성 방식이 중요하다. 예를 들어 함수 사용이나 불필요한 조건이 들어가면 인덱스를 제대로 타지 못하는 경우가 발생할 수 있다.
예를 들어:
WHERE TO_CHAR(CREATE_DATE,'YYYYMMDD') = '20260514'이런 방식은 인덱스 활용이 어려워질 수 있다.
실무에서는 가능하면:
WHERE CREATE_DATE BETWEEN ...같이 범위 조건 형태로 많이 수정한다.
또 JOIN 구조도 중요하다. 테이블 개수가 많아질수록 JOIN 비용이 커지기 때문에:
- 불필요한 JOIN 제거
- 필요한 데이터만 조회
- SELECT * 지양
같은 부분을 계속 신경 쓰게 된다.
실제로 운영 프로젝트에서는 작은 SQL 수정 하나로 조회 속도가 몇 배 빨라지는 경우도 있었다.
그 이후로는 단순히 “동작하는 SQL”보다:
👉 “운영에서도 버틸 수 있는 SQL”
이 더 중요하다는 걸 많이 느꼈다.
💡 실무에서 가장 중요했던 건 결국 경험이었다
처음에는 SQL 튜닝이 굉장히 어렵게 느껴졌다. 하지만 여러 운영 이슈를 경험하면서 점점 공통 패턴이 보이기 시작했다.
특히 실무에서는:
- Index
- 실행계획
- Full Scan
- JOIN 구조
- 데이터 건수
이 다섯 가지를 정말 자주 보게 된다.
그리고 결국 중요한 건 “완벽한 이론”보다:
👉 실제 운영 환경에서 문제를 해결해본 경험
이라는 것도 많이 느꼈다.
운영 프로젝트는 속도 문제 하나가 현업 업무 전체에 영향을 줄 수 있기 때문에, 성능 개선은 생각보다 훨씬 중요한 영역이었다.
🔥 마무리
Oracle 쿼리가 느릴 때는 단순히 서버 성능만 의심하기보다, 인덱스 사용 여부와 실행계획을 먼저 확인하는 것이 중요하다. 특히 제조·운영 프로젝트에서는 데이터 양이 많기 때문에 작은 SQL 구조 차이도 큰 성능 차이로 이어질 수 있다.
실무를 경험하면서 가장 크게 느낀 건 결국 “잘 동작하는 SQL”보다 “운영에서도 안정적으로 빠른 SQL”이 훨씬 중요하다는 점이었다.
