실무에서의 인덱스 관리 방법이 궁금합니다

Question

안녕하세요 영한님! 강의에서 말씀해 주신 것처럼, 인덱스를 생성한다고 해서 항상 옵티마이저가 해당 인덱스를 사용하는 것은 아니라는 점은 이해했습니다. 그렇다면 실무에서는 특정 인덱스를 어떤 쿼리나 사용 패턴을 고려해서 만들었는지, 그리고 어떤 의도로 설계했는지를 별도로 기록하거나 관리하는 방법이 있을까요? 예를 들어 시간이 지나 다른 개발자가 인덱스를 보더라도, “이 인덱스는 특정 조회 쿼리의 성능을 개선하기 위해 만들었다”와 같은 설계 의도를 파악할 수 있도록 관리하는지가 궁금합니다. 설계 1편에서 소개해 주신 용어 사전처럼 별도의 문서나 규칙을 두고 관리하는 방법이 있는지, 혹은 실무에서 일반적으로 사용하는 다른 방법이 있는지도 궁금합니다!

eggmun · Answer

실무에서는 인덱스의 설계 의도를 별도의 한 가지 방법으로 관리하기보다는, 보통 여러 방법을 함께 사용하는 편입니다. 가장 흔한 방법은 인덱스를 생성하는 DB 마이그레이션 파일이나 PR, 커밋 메시지에 생성 이유를 남기는 것입니다. 예를 들어 user_id + status + created_at 조건으로 주문 목록을 조회하는 쿼리의 성능 개선을 위해 생성 처럼 어떤 쿼리나 사용 패턴을 고려해서 만든 인덱스인지 기록해두는 방식입니다. 이렇게 하면 나중에 다른 개발자가 해당 인덱스가 추가된 커밋이나 PR을 확인하면서 설계 의도를 추적할 수 있습니다. 규모가 있는 프로젝트에서는 ERD, DB 설계 문서, Wiki 등에 주요 인덱스와 목적을 따로 정리하기도 합니다. 다만 모든 인덱스를 별도 문서로 관리하면 실제 DB와 문서가 서로 달라질 가능성이 있기 때문에, 보통은 마이그레이션 코드와 Git 이력을 기준으로 관리하고 중요한 내용만 문서화하는 경우가 많은 것 같습니다. 또 단순히 “조회 성능 개선용”이라고 적기보다는 실제로 어떤 쿼리를 위해 만들었는지 남겨두는 것이 더 도움이 됩니다. 예를 들어 WHERE user_id = ? AND status = ? ORDER BY created_at DESC 같은 대상 쿼리를 함께 기록해두면 나중에 인덱스의 컬럼 구성이나 순서를 이해하기도 훨씬 쉬워집니다. 그리고 시간이 지나면서 데이터 분포나 쿼리 패턴이 바뀔 수도 있기 때문에, 인덱스를 만들 당시의 의도뿐 아니라 실제 실행 계획이나 Slow Query 등을 통해 해당 인덱스가 여전히 효과적인지 주기적으로 확인하는 것도 중요합니다.