SQL 튜닝, 느려진 DB를 6단계로 진단하는 방법

2026.08.23 조회 673

우리비엔씨는 운영 중인 시스템이 느려진 기업과 기관을 위해 SQL 튜닝과 DB 성능 개선을 진행합니다. 느린 쿼리 한 줄만 고치는 것이 아니라 테이블 구조, 인덱스, 뷰, 실행 계획까지 함께 분석하며, 대형 쇼핑몰 뉴퍼마켓의 슬로우 쿼리를 오픈 직전에 수십 분에서 1~2초로 줄인 사례가 있습니다. 이 글은 DB가 느려지는 신호와 원인, 우리비엔씨가 튜닝을 진행하는 6단계, 그리고 의뢰 전에 알아 두면 좋은 내용을 정리했습니다.

시스템 성능 저하 원인

데이터베이스는 구축할 때 한 번 잘 만들면 끝나는 것이 아닙니다. 오픈 첫날에는 테이블마다 데이터가 몇 천 건뿐이라 어떤 쿼리를 써도 빠릅니다. 문제는 데이터가 수십만, 수백만 건으로 쌓인 뒤에 드러납니다. 설계 단계에서 인덱스 전략이나 테이블 관계를 제대로 잡지 못했다면 그때부터 화면 하나 여는 데 몇 초, 보고서 하나 뽑는 데 몇 분씩 걸리기 시작합니다.

반대로 설계를 잘해 두었더라도 서비스가 커지면서 예상하지 못한 조회 방식이 생기고, 사용자가 몰리는 시간대가 바뀌면 다시 튜닝이 필요해집니다. 그래서 우리비엔씨는 데이터베이스 설계와 SQL 튜닝을 따로 떨어진 기술이 아니라 한 세트로 봅니다.

SQL 튜닝 검토 대상 증상

느려지는 모습만 봐도 어디부터 의심해야 할지 어느 정도 방향이 잡힙니다. 상담 때 자주 확인하는 증상과 먼저 살펴보는 곳을 표로 정리했습니다.

이런 증상이라면	먼저 의심하는 곳
특정 화면이나 보고서 하나만 유독 느리다	그 화면이 쓰는 쿼리의 조건절(Where)과 조인(Join), 인덱스를 실제로 타는지 여부
처음엔 빨랐는데 데이터가 쌓일수록 점점 느려진다	테이블 전체를 읽는 풀 스캔, 데이터 증가를 고려하지 않은 인덱스 설계
조회 결과가 비정상적으로 많거나 같은 행이 반복된다	조인 조건 누락으로 생기는 카티션 곱(Cartesian Product)
월말 마감이나 일괄 처리 때만 느리다	대량 집계·배치 쿼리, 같은 시간에 몰리는 작업끼리의 충돌
인덱스를 추가했는데도 그대로다	컬럼을 함수로 감싼 조건, 복잡한 뷰(View) 구조처럼 인덱스를 쓰지 못하게 만드는 쿼리 작성 방식

마지막 줄이 특히 중요합니다. 튜닝 상담에서 흔히 “인덱스만 더 걸면 되는 것 아닌가요?”라는 질문을 받는데, 실제로 원인을 따라가 보면 잘못된 조인 구조나 불필요한 카티션 곱에 있는 경우가 많습니다. 이런 문제는 실행 계획(Execution Plan)을 열어 보지 않으면 찾기 어렵습니다.

카티션 곱 개념 예시 - 주문 10,000행과 상품 5,000행을 조인할 때 조인 조건이 있으면 결과 10,000행, 조인 조건이 빠지면 모든 조합인 5,000만 행이 만들어짐

조인 조건 하나가 빠지면 결과가 수천 배로 불어납니다(설명용 수치). 인덱스를 더해도 해결되지 않는 대표적인 유형입니다

우리비엔씨 SQL 튜닝 6단계

아래는 대형 쇼핑몰 MySQL 운영 시스템의 슬로우 쿼리를 튜닝할 때 실제로 밟은 순서입니다. 테이블 수가 많고 관계가 복잡한 데다 데이터량도 커서, 인덱스 하나 추가로 끝날 문제가 아니었습니다. 지금도 다른 DBMS의 튜닝 의뢰를 받으면 같은 순서로 진행합니다.

우리비엔씨 SQL 튜닝 6단계 흐름도 - 1 구조 파악(ERD 역구성), 2 키와 인덱스 조사(PK, Index, FK 전수 조사), 3 데이터 규모 파악, 4 쿼리 분석(Where 조건절과 Join), 5 문제 지점 탐색(카티션 곱, 인덱스 적절성), 6 실제 튜닝(실행 계획 분석 후 쿼리 수정과 재작성)

느린 쿼리 하나가 아니라, 그 쿼리를 둘러싼 구조부터 봅니다

단계	하는 일	이 단계에서 찾는 것
1. 구조 파악	많은 테이블의 관계를 ERD로 거꾸로 재구성	설계 문서가 없거나 실제 DB와 달라진 부분
2. 키·인덱스 조사	테이블별 PK, Index, FK 전수 조사	빠진 인덱스, 중복되거나 쓰이지 않는 인덱스
3. 데이터 규모 파악	주요 테이블의 데이터 건수와 컬럼 속성 확인	빠르게 늘어나는 테이블, 조회가 몰리는 테이블
4. 쿼리 분석	각 SQL의 조건절(Where)과 조인(Join) 내역 파악	인덱스를 쓰지 못하는 조건, 과도한 조인
5. 문제 지점 탐색	카티션 곱, 인덱스 적절성 조사	느려지는 진짜 원인이 어느 지점인지
6. 실제 튜닝	실행 계획을 분석해 쿼리를 수정하거나 다시 작성	튜닝 전후 실행 시간과 실행 계획 비교

1~3단계에 시간이 꽤 들어갑니다. 쿼리를 바로 고치고 싶은 마음은 이해하지만, 테이블 관계와 데이터 규모를 모르는 상태에서 쿼리만 손보면 한 곳이 빨라지는 대신 다른 화면이 느려지는 일이 생깁니다.

테이블 수십 개가 관계선으로 연결된 업무용 데이터베이스 ERD 예시 - 튜닝 1단계에서 테이블 관계를 이런 관계도로 재구성함

테이블이 많은 업무용 DB의 ERD 예시. 튜닝 1단계에서 이런 관계도부터 다시 그립니다

사례: 뉴퍼마켓 오픈 직전 슬로우 쿼리 튜닝

국내에서 규모가 꽤 큰 쇼핑몰인 뉴퍼마켓(㈜아엠파서블)이 오픈을 앞둔 2023년 1월, 데이터베이스(MySQL 8.0)에서 심각한 성능 문제가 발견됐습니다. 오픈 일정에 지장을 줄 만큼 급한 상황이어서 우리비엔씨가 긴급하게 튜닝 작업에 투입됐습니다.

먼저 전체 데이터베이스 구조를 파악하고 슬로우 쿼리 목록부터 추렸습니다. 이때 원인을 SQL 문장 하나에서 찾지 않고, 테이블 데이터 현황과 PK, Index, View 등 구조 전반을 함께 훑었습니다. 그 결과 많게는 수십 분씩 걸리던 슬로우 쿼리가 1~2초대로 줄었고, 쇼핑몰은 예정대로 오픈했습니다. 뉴퍼마켓은 지금도 안정적으로 운영되고 있습니다.

뉴퍼마켓 슬로우 쿼리 튜닝 결과 - 2023년 1월 아엠파서블 MySQL 8.0, 튜닝 전 수십 분 걸리던 쿼리가 튜닝 후 1~2초로 단축, 테이블 데이터 현황과 PK, Index, View, 실행 계획을 점검

뉴퍼마켓 튜닝 전후. 쿼리 문장이 아니라 DB 구조 전반을 점검해 오픈 일정을 지켰습니다

이 사례가 보여 주는 원칙은 하나입니다. 슬로우 쿼리의 원인은 쿼리 자체보다 그 쿼리를 둘러싼 구조, 즉 인덱스와 뷰와 테이블 관계에 있는 경우가 훨씬 많다는 것입니다. 같은 방식의 튜닝은 삼성생명 재보험 정보관리시스템 구축(2012, SQL Server 2008 R2) 같은 금융권 SI 프로젝트에서도 적용했습니다.

수치 기반 튜닝 목표

“빠르게 해 주세요”만으로는 끝난 건지 아닌지 판단할 수 없습니다. 우리비엔씨는 SQL 쿼리부터 DB 모델까지 파악해 튜닝을 진행할 때 처리 유형별로 아래 응답 시간을 목표로 잡습니다.

처리 유형	예시	목표 응답 시간
OLTP (일상 거래 처리)	화면 조회, 주문·입력·수정 같은 실시간 업무	3초 이내
OLAP·배치 처리	통계·집계 보고서, 월말 마감 같은 일괄 처리	30초 이내

목표를 먼저 정해 두면 어떤 쿼리부터 손댈지 우선순위가 생기고, 튜닝이 끝난 뒤 결과를 확인하기도 쉽습니다.

설계 단계의 튜닝 비용 절감

튜닝은 이미 생긴 문제를 고치는 작업입니다. 그런데 정말 강조하고 싶은 것은 설계 단계입니다. 처음부터 정규화가 제대로 되어 있고, 앞으로 늘어날 데이터량과 조회 방식을 예측해 인덱스 전략을 세워 두면 나중에 튜닝에 드는 비용 자체가 크게 줄어듭니다.

반대로 설계가 부실한 채 서비스만 커지면 테이블 구조를 뜯어고쳐야 하는 상황까지 갑니다. 이때는 튜닝이라기보다 재설계에 가까운 작업이 되어 시간과 비용이 훨씬 커집니다. 그래서 신규 구축이든 기존 시스템 개선이든 항상 “지금 당장”과 “몇 년 뒤”를 같이 놓고 설계를 검토합니다. 우리비엔씨는 한 프로젝트에서 수십억 건 규모의 데이터베이스를 설계·구축한 경험도 있습니다.

지원 DBMS와 프로젝트 실적

특정 DBMS에 묶이지 않고 주요 데이터베이스 전반의 설계·구축·튜닝을 진행합니다. 아래는 각 DBMS로 진행한 우리비엔씨 프로젝트의 예입니다.

DBMS	해당 DBMS로 진행한 프로젝트 예
MySQL / MariaDB	뉴퍼마켓 슬로우 쿼리 튜닝(MySQL 8.0, 2023), 꿈비 매출통합 및 정산시스템(MariaDB 10.9, 2022~2023)
MS SQL Server	삼성생명 재보험 정보관리시스템(2012), 네노바 화훼 수입유통관리 시스템(2025~2026)
Oracle	농협손해보험 재보험 추가업무 개발(Pro*C, 2012~2013)
PostgreSQL	한국에너지공단 자동차 에너지소비효율 시험 DB시스템(2022), 한국지질자원연구원 광산 데이터 추출 및 통합 시스템(2023~2024)
SQLite	진스랩 PCR 유전자 진단키트 분석 소프트웨어(2024) 등 PC 단독 실행형 프로그램

다른 DBMS로 옮기는 마이그레이션도 함께 진행하므로, 오래된 시스템을 새 DB 환경으로 옮기면서 성능까지 손보려는 경우에도 상담할 수 있습니다.

튜닝 상담 전 준비 자료

아래 내용이 있으면 원인 진단이 훨씬 빨라집니다. 모두 갖추지 않아도 괜찮습니다. 모르는 부분은 상담하면서 함께 확인합니다.

느린 화면·보고서 목록과 각각 대략 걸리는 시간
사용 중인 DBMS 종류와 버전 (예: MySQL 8.0, SQL Server 2019)
슬로우 쿼리 로그나 문제가 되는 SQL 문장
주요 테이블의 대략적인 데이터 건수
언제부터 느려졌는지, 그 무렵 바뀐 것 (데이터 이관, 기능 추가, 사용자 증가 등)

자주 묻는 질문

Q. 인덱스만 추가하면 빨라지지 않나요?

인덱스가 빠져서 느린 경우라면 그렇습니다. 하지만 조인 조건이 잘못됐거나 카티션 곱이 생기는 쿼리, 컬럼을 함수로 감싸 인덱스를 쓰지 못하는 쿼리는 인덱스를 더해도 그대로입니다. 오히려 불필요한 인덱스가 늘면 입력·수정이 느려질 수 있어, 실행 계획으로 원인을 먼저 확인합니다.

Q. 다른 업체가 만든 시스템도 튜닝을 맡길 수 있나요?

네. 데이터베이스에 접근할 수 있으면 분석할 수 있습니다. 쿼리를 다시 작성해야 하는 경우에는 프로그램 안의 SQL도 고쳐야 하므로 소스 코드 접근이 필요합니다. 분석 결과 구조 자체에 원인이 있으면 고쳐 쓸지, 다시 설계할지 판단해 함께 말씀드립니다.

Q. 튜닝하면 얼마나 빨라지나요?

시스템마다 원인이 달라 미리 숫자를 약속하기는 어렵습니다. 뉴퍼마켓 사례에서는 수십 분 걸리던 쿼리가 1~2초대로 줄었고, 우리비엔씨는 일상 업무 처리 3초 이내, 집계·배치 처리 30초 이내를 목표로 튜닝합니다.

Q. 튜닝만으로 해결되지 않는 경우도 있나요?

있습니다. 테이블 설계 자체가 업무 흐름과 맞지 않으면 쿼리를 아무리 다듬어도 한계가 있습니다. 이런 경우에는 어느 테이블을 어떻게 바꿔야 하는지 구조 개선 방안을 제안하고, 상담은 대표 개발자가 직접 진행합니다.