이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
쿼리 튜닝 사례 중 하나는 주문 목록 조회 API 응답 시간이 트래픽 증가 후 급격히 늘어난 문제였습니다. 슬로우 쿼리 로그에서 해당 쿼리를 찾고 EXPLAIN으로 실행 계획을 보니 주문 상태와 사용자 ID를 동시에 필터링하는 구간에서 풀 스캔이 발생하고 있었습니다.
복합 인덱스를 추가했습니다. 사용자 ID와 주문 상태를 조합한 복합 인덱스를 생성하고 나니 인덱스 범위 스캔으로 전환되면서 실행 시간이 수십 배 개선됐습니다. 인덱스 컬럼 순서도 중요해서, 선택도가 높은 컬럼을 앞에 두는 것이 효율을 높였습니다.
쿼리 재작성도 병행했습니다. 서브쿼리로 구성된 집계 부분을 조인 방식으로 변경하면서 옵티마이저가 더 효율적인 실행 계획을 선택했습니다. 같은 결과를 내는 여러 표현 방식 중 실행 계획이 더 좋은 것을 선택하는 연습이 쌓이면서 감이 좋아졌습니다.
쿼리가 느리다는 문제를 해결하려고 조회에 사용되는 컬럼에 인덱스를 추가했는데, 해당 테이블에 데이터 쓰기가 많은 상황이라 인덱스 유지 비용으로 인해 전체 성능이 오히려 나빠지는 경험을 했습니다. 읽기 성능을 높이려고 인덱스를 추가하면 쓰기 성능에 영향을 줄 수 있다는 것을 그때 처음 실감했습니다. EXPLAIN으로 실행 계획을 확인하는 것과 함께 테이블의 읽기와 쓰기 비율을 파악하는 것이 인덱스 전략을 결정하는 기준이 된다는 것을 배웠습니다. 인덱스를 늘리는 것이 항상 좋은 것이 아니고, 어떤 쿼리가 얼마나 자주 실행되는지를 보고 인덱스의 효과가 비용보다 큰 경우에만 추가하는 것이 맞다는 것을 이 경험에서 배웠습니다.
API 응답이 느린 원인을 추적하다가 루프 안에서 쿼리가 반복 실행되는 N+1 문제를 발견한 경험이 있습니다. 목록을 가져오는 쿼리 한 번과 각 항목의 상세 정보를 가져오는 쿼리가 항목 수만큼 실행되고 있었는데, 데이터베이스 쿼리 로그를 보지 않았다면 발견하기 어려웠을 문제였습니다. 조인을 사용해서 목록과 상세 정보를 한 번의 쿼리로 가져오도록 바꾸니 API 응답 시간이 크게 줄었습니다. 성능 문제를 쿼리 튜닝으로만 접근하는 것보다 쿼리가 몇 번 실행되는지를 먼저 확인하는 것이 더 효과적인 경우가 있다는 것을 이 경험에서 배웠습니다. 쿼리 실행 횟수와 각 쿼리의 실행 시간을 함께 파악하는 것이 성능 문제의 원인을 정확히 진단하는 방법이라는 것을 알게 됐습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 DBA 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.