예시 답변 1
약 90초
MySQL 인덱스 튜닝 — 느린 쿼리 원인 분석 + 해결
MySQL 운영에서 특정 쿼리가 배포 후 갑자기 느려지는 문제가 가장 어려웠습니다. 슬로우 쿼리 로그를 확인하니 특정 조인 쿼리의 실행 시간이 2~3초로 늘어나 있었고, EXPLAIN 분석에서 풀 테이블 스캔이 발생하고 있었습니다. 데이터 증가로 옵티마이저가 인덱스를 타지 않는 방향을 선택한 것이 원인이었습니다. 해결 방법으로 복합 인덱스를 재설계하고, 쿼리 힌트로 인덱스를 명시하는 방식을 병행했습니다.
MySQL과 MongoDB의 차이 면에서는, MySQL은 스키마가 고정돼 조인 성능 예측이 가능하고 트랜잭션이 강하지만, MongoDB는 도큐먼트 구조라 비정형 데이터나 중첩 구조에 유리합니다. 두 DB를 병행 운영하면서 데이터 특성에 따라 저장소를 선택하는 기준이 생겼고, 이 기준으로 신규 기능 설계 시 DB 선택을 팀에 제안하는 역할을 맡기도 했습니다.
이 결의 특징
슬로우 쿼리 → EXPLAIN → 복합 인덱스 재설계 순으로 진단-원인-해결이 구조화돼 있습니다. MySQL vs MongoDB 차이를 서술할 때 데이터 특성 기준을 본인 기준으로 제시하는 점이 잘 보이고, "DB 선택을 팀에 제안하는 역할"까지 연결해 운영 경험이 개인 역할로 확장되는 흔적이 있습니다.
면접관이 다음에 할 행동
"복합 인덱스 설계 기준이 무엇인가요?"로 이어지는 기술 심화 질문이 자주 나오는 자리입니다. 인덱스 선택 근거와 쿼리 힌트 사용 판단 기준까지 준비된 답변이 있으면 대화가 운영 실력 검증으로 이어집니다.