예시 답변 1
약 103초
설계 원칙→성능 문제 탐지→튜닝 방법→결과 결
RDBMS 설계와 성능 튜닝 경험은 졸업 프로젝트에서 초기 스키마 설계의 문제로 쿼리 속도가 기대보다 크게 느려지는 상황을 분석하고 개선한 것이었습니다. 테이블 구조를 너무 단순하게 설계했다가 조회 시 불필요한 풀 스캔이 반복되는 것을 EXPLAIN 결과로 확인했습니다.
정규화 수준 조정으로 과도하게 나뉜 테이블에서 조인이 많이 발생하는 경우 일부를 역정규화해 조회 성능을 높이는 판단을 했습니다. 인덱스 설계는 자주 쓰이는 검색 조건 컬럼에 인덱스를 추가하고, 인덱스가 오히려 쓰기 성능을 낮추는 테이블에서는 사용 패턴을 분석해 인덱스를 줄이는 방향으로 조정했습니다.
쿼리 자체의 문제도 원인이 되는 경우가 많아 N+1 쿼리 패턴을 발견하고 JOIN으로 대체하는 리팩터링을 적용했습니다. 성능 개선 전후를 수치로 비교하는 것이 팀원에게 변경 이유를 설명하는 가장 명확한 방법이어서, 개선 전후 쿼리 실행 시간을 기록해 문서화했습니다.
정규화 조정과 인덱스 설계가 RDBMS 성능 튜닝의 핵심이라는 결론을 갖고 있습니다.
이 결의 특징
초기 스키마 설계 문제로 쿼리 속도가 기대보다 크게 느려지는 구체적 상황을 분석한 흔적이 있습니다. EXPLAIN 결과로 풀 스캔이 반복되는 것을 확인하고 정규화·인덱스 설계로 개선한 구체적 과정이 드러납니다.
이 결이 통하는 자리
N+1 쿼리 패턴을 발견해 JOIN으로 대체하고 쿼리 실행 시간을 숫자로 비교해 문서화했다는 구체적 수치 대비가 있을 때 통합니다. 혼자 완주한 경험은 없다는 한계까지 인정했을 때 신뢰가 쌓이는 결이 보입니다.