커찬님의 면접 결과

인덱스의 개념을 책의 인덱스에 비유해서 설명한 부분과 B+ 트리가 주로 사용되는 자료구조라고 답변한 점이 매우 좋았습니다. 또한 시간복잡도 O(logN)까지 언급하여 기술적 깊이를 보여주신 것도 훌륭했습니다. 다만 인덱스를 구현할 수 있는 다른 자료구조들(해시 테이블, B-트리 등)에 대한 언급이 있었다면 더욱 완성도 높은 답변이 되었을 것 같습니다. 추가로 인덱스의 장단점이나 언제 사용하는 것이 효과적인지에 대해서도 학습해보시면 좋을 것 같습니다.

범위 탐색에 유리하다는 핵심 개념을 정확히 파악하셨고, B+ 트리에서 리프 노드 연결의 목적을 명확하게 설명해주셨습니다. 특정 범위의 시작점을 찾아 연결 리스트를 따라가며 데이터를 조회하는 과정도 논리적으로 잘 설명하셨네요. 다만 순차 접근(sequential access)이나 디스크 I/O 효율성 측면에서의 장점도 함께 언급하시면 더욱 완성도 높은 답변이 될 것 같습니다. 또한 연결 리스트를 통해 정렬된 순서로 데이터에 접근할 수 있다는 점도 추가로 학습해보시면 좋을 것 같습니다.

범위 탐색 시 성능 저하 요인에 대해 잘 파악하고 계시는 것 같습니다. 특히 탐색 범위가 길거나 일부 데이터만 조회하는 경우의 성능 이슈를 정확히 언급해주셨고, MySQL에서 정방향 탐색이 역방향보다 빠르다는 실무적인 지식도 좋았습니다. 다만 답변에서 누락된 중요한 부분이 있는데, 디스크 I/O 측면에서 리프 노드들이 물리적으로 멀리 떨어져 있을 때 발생하는 성능 저하나, 인덱스 페이지가 메모리에서 버퍼풀을 벗어나 디스크 접근이 빈번해지는 상황도 주요 원인입니다. 또한 중간 노드에서 다시 탐색해야 하는 경우나 락 경합 상황 등도 고려해보시면 더욱 완성도 높은 답변이 될 것 같습니다.

물리적 저장소의 순서와 연관지어 설명하려고 노력한 점은 좋았습니다. 하지만 MySQL에서 정방향 탐색이 빠른 실제 이유는 다릅니다. MySQL의 B+ 트리는 리프 노드들이 단방향 연결 리스트로 구성되어 있어서, 정방향으로 탐색할 때는 next 포인터를 따라가면 되지만 역방향 탐색 시에는 매번 부모 노드로 올라가서 다른 경로를 찾아 내려가야 하기 때문에 성능 차이가 발생합니다. 추가로 InnoDB 엔진의 구체적인 구현 방식이나 양방향 연결 리스트 구조에 대해 학습하시면 더 정확한 이해를 하실 수 있을 것 같습니다.

데이터가 row 단위로 저장되고 여러 row가 묶음으로 관리된다는 기본적인 이해는 좋습니다. 하지만 MySQL에서 물리적 저장 순서에 대한 핵심 개념이 빠져있습니다. MySQL의 InnoDB 엔진에서는 데이터가 클러스터드 인덱스(주로 Primary Key) 순서로 물리적으로 저장되며, 이를 페이지(Page) 단위로 관리합니다. 따라서 Primary Key 순서대로 데이터가 배치되어 있고, 각 페이지는 16KB 크기로 고정되어 있다는 점을 알아두시면 좋겠습니다. 클러스터드 인덱스와 페이지 구조에 대해 더 학습하시면 MySQL의 물리적 저장 방식을 더 정확하게 이해할 수 있을 것입니다.