이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
SQL 튜닝 경험에서 가장 먼저 확인하는 것은 실행 계획입니다. EXPLAIN 명령으로 쿼리가 어떤 순서로 실행되는지를 보면 풀 스캔이 발생하는 지점을 빠르게 찾을 수 있고, 인덱스가 타지 않는 이유도 파악됩니다.
인덱스 설계가 성능에 가장 큰 영향을 줬습니다. WHERE 절과 JOIN 조건에 자주 등장하는 컬럼에 인덱스를 추가하면 조회 속도가 크게 달라졌고, 반대로 쓰기가 많은 테이블에 인덱스가 과도하면 INSERT 성능이 오히려 저하되는 경우도 경험했습니다.
쿼리 자체를 재작성하는 것도 효과적이었습니다. 서브쿼리 대신 JOIN으로 변경하거나 불필요한 DISTINCT를 제거하는 것만으로도 실행 시간이 줄었습니다. N+1 패턴이 숨어 있는 경우는 ORM 레이어를 검토해 한 번의 쿼리로 묶는 방식으로 해결했습니다.
SQL 튜닝 경험에서 ORM을 사용할 때 생기는 맹점을 경험했습니다. ORM으로 코드를 작성하면 SQL을 직접 쓰지 않아도 데이터를 다룰 수 있어 편리한데, 실제로 어떤 쿼리가 실행되는지를 확인하지 않으면 성능 문제를 늦게 발견하게 됩니다. 연관 데이터를 가져올 때 N+1 쿼리가 발생하는 것을 모르고 지나쳤다가 데이터가 늘어나면서 느려지는 것을 뒤늦게 확인했습니다. ORM 레이어가 생성하는 실제 SQL을 로깅하도록 설정하고 정기적으로 확인하는 습관을 들이게 됐는데, 코드 수준에서는 단순해 보이는 로직이 DB에서는 복잡한 쿼리로 변환되는 경우가 있다는 것을 배웠습니다. SQL 튜닝 능력은 쿼리를 직접 작성하는 능력뿐 아니라 어떤 쿼리가 실행되고 있는지를 지속적으로 관찰하는 습관도 포함된다는 것을 이 경험에서 배웠습니다.
SQL 성능 문제를 인덱스로 해결하는 과정에서 예상치 못한 부작용을 경험했습니다. 조회가 느린 쿼리에 인덱스를 추가하니 해당 쿼리의 속도는 빨라졌는데, 같은 테이블에 데이터를 쓰는 작업의 속도가 저하됐습니다. 인덱스가 많아질수록 데이터를 삽입하거나 수정할 때 인덱스도 함께 갱신해야 하기 때문에, 읽기 성능과 쓰기 성능 사이에 트레이드오프가 있다는 것을 직접 경험했습니다. 이 경험에서 인덱스를 추가하기 전에 해당 테이블의 읽기와 쓰기 비율을 먼저 파악하는 것이 중요하다는 것을 배웠습니다. 읽기가 훨씬 많은 테이블이라면 인덱스 추가의 효과가 크지만, 쓰기가 많은 테이블에서는 인덱스가 오히려 부담이 될 수 있다는 것을 알게 됐습니다. SQL 튜닝은 특정 쿼리 하나가 아니라 전체 워크로드를 고려해야 한다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 여기어때 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.