예시 답변 1
약 88초
문제 상황 → 분석 → 최적화 조치로 닫는 결
`MySQL` 성능 최적화 경험이 있습니다. 학부 프로젝트에서 게시판 서비스를 구현했는데, 데이터가 5만 건 이상 쌓이자 목록 조회 쿼리 응답이 눈에 띄게 느려졌습니다.
EXPLAIN 으로 실행 계획을 확인했더니 Full Table Scan이 발생하고 있었고, created_at 컬럼에 인덱스가 없는 것이 원인이었습니다. 인덱스를 추가한 뒤 응답 시간이 1.8초에서 0.08초로 줄었습니다. 이후 복합 인덱스 적용도 시도해봤는데, 조건절에 쓰는 컬럼 순서를 잘못 잡으면 인덱스가 활용되지 않는 케이스도 직접 확인했습니다.
MongoDB 는 사이드 프로젝트에서 사용했는데, Aggregation Pipeline 에서 `$lookup` 단계가 느린 경우를 겪었습니다. 연결되는 컬렉션에 인덱스가 없어서 생긴 문제였고, createIndex 로 해결했습니다. 두 DB 모두 결국 실행 계획을 먼저 보는 것이 최적화의 시작이라는 걸 배웠습니다.
이 결의 특징
최적화를 감이 아니라 EXPLAIN으로 실행 계획을 먼저 확인하는 절차로 짚고, 복합 인덱스 실수 사례까지 포함하는 결이다.
이 결이 통하는 자리
성능 최적화 경험을 결과 수치만으로 답하기 쉬운 질문에서, 진단 절차를 먼저 밟는 방식이 통하는 자리다.