HashMap을 직접 구현해야 한다는 과제가 생각보다 쉽지 않았다.
Key와 Value가 객체로 이루어진다는 기본 개념은 이해했지만,
이 객체들을 내부적으로 배열로 관리할지, List로 할지, 아니면 LinkedList를 사용할지 결정하는 부분에서 상당히 고민이 많았다.
특히, 각 자료구조가 갖는 시간 복잡도와 메모리 특성을 고려하면서 최적의 선택을 하는 게 어려웠다.
또한 해시 함수와 충돌 해결 방법에 대한 이해가 부족해 전체 설계를 구체화하는 데 시간이 걸렸다.
먼저 Key와 Value를 함께 담을 수 있는 객체를 만들었다.
그 객체들을 담을 배열을 선언하고, 기본적인 저장 공간을 마련했다.
값을 찾거나 삭제할 때는 Key 값을 하나하나 순회하면서 일치하는 인덱스를 찾는 방식을 사용했다.
이 과정에서 배열 크기 변경이나 리사이징에 대해서는 신경 쓰지 못해 단순 구현에 집중했다.
처음부터 해시 테이블의 특성을 살린 해시 함수나 버킷 구조를 적용하지 않아 순회 시간이 길어진 것을 체감했다.
가장 아쉬운 점은 해시 함수의 핵심 역할을 전혀 활용하지 못한 것이다.
이 때문에 불필요한 선형 탐색(순회)을 반복하며 값을 찾고 삭제하고 등록하는 비효율적인 작업이 반복되었다.
조건에 맞게 해시 충돌을 해결하거나, 적절한 해시 함수를 설계하는 등의 작업에 대해 생각조차 하지 못했다는 점이 너무 아쉽다.
이런 점들이 전체 성능에 큰 영향을 미친다는 걸 체감했다.
자료구조 이름인 'HashMap'에 그 해답이 숨어 있다는 것을 다시금 깨달았다.
'Hash'의 의미를 좀 더 깊이 이해했다면 불필요한 순회를 크게 줄일 수 있었을 것이다.
해시 함수가 데이터를 빠르게 접근하도록 돕는 핵심 역할을 한다는 점을 체감하며,
직접 구현해보면서 해시 함수 설계와 충돌 처리에 대한 필요성을 절실히 느꼈다.
또한, 객체를 저장하는 구조를 잘 선택하는 것이 성능과 직결된다는 점도 알게 되었다.
이 경험을 통해 HashMap과 같은 자료구조가 어떻게 효율성을 달성하는지 몸으로 느끼게 되었다.