솔직히 말해볼까요.
요즘 주니어들 이력서 보면 가관입니다.
Redis, Kafka, Elasticsearch, Cassandra...
온갖 최신 기술 스택으로 도배가 되어 있죠.
그런데 정작 면접 때 "왜 그 기술을 썼나요?" 라고 물으면 꿀 먹은 벙어리가 됩니다.
"남들이 좋다고 해서요."
"유행이라서요."
저는 이걸 '이력서 주도 개발(RDD)'이라고 부릅니다.
가장 혐오하는 태도죠.
비즈니스 로직도 모르면서 도구만 휘두르는 건, 목수가 망치질도 못하면서 전동 드릴만 사 모으는 꼴입니다.
제가 네이버 검색 서버 최적화 팀에 있을 때, 트래픽이 폭주해서 장애가 터진 적이 있습니다.
원인은 고작 데이터 구조(Data Structure) 선택 실수 하나였습니다.
거창한 분산 시스템의 문제가 아니었습니다.
기본기의 부재가 시스템을 죽입니다.
오늘 이야기는 어디 교과서에 나오는 '정의'가 아닙니다.
제가 현업에서 수없이 깨지고 구르며 정리한, '데이터를 저장하는 태도'에 관한 이야기입니다.
1. 세상에 '만능키'는 없다
코드는 자산이 아니라 부채입니다.
데이터 구조도 마찬가지죠.
모든 상황에 완벽한 단 하나의 저장 방식은 존재하지 않습니다.
이걸 인정하지 않으면 아키텍처는 망가집니다.
가장 쉬운 예로 '책장 정리'를 생각해봅시다.
여러분이 책을 한 줄로 길게 늘어선 선반(Array/List)에 꽂는다고 칩시다.
정렬만 잘 되어 있으면(Sorted), 책을 찾는 건 쉽습니다.
이진 탐색(Binary Search)을 쓰면 되니까요.
하지만 새 책을 사오면요?
그 책이 들어갈 자리를 만들기 위해, 나머지 책들을 전부 한 칸씩 뒤로 밀어야 합니다.
검색(Read)은 빠르지만, 삽입(Write)은 지옥입니다.
반대로, 빈 공간 아무 데나 책을 꽂으면요?
넣는 건 1초면 끝나지만, 나중에 그 책 찾으려면 밤새워야 합니다.
우리는 항상 이 '트레이드오프(Trade-off)'라는 저울 위에 서 있는 겁니다.
2. 해시 테이블: 속도를 위해 공간을 버리다
검색 팀 시절, 가장 많이 다뤘던 게 바로 해시 테이블(Hash Table)입니다.
앞선 예시의 '선반' 대신, 알파벳 'A'부터 'Z'까지 라벨이 붙은 26개의 통(Bucket)을 둔다고 상상해보세요.
작가 이름이 'Kim'이면 'K' 통에 던져 넣으면 끝입니다.
찾을 때도 'K' 통만 뒤지면 되죠.
이론적으로 검색과 삽입 모두 O(1), 즉 즉시 처리가 가능합니다.
완벽해 보이죠?
하지만 여기엔 치명적인 함정이 있습니다.
만약 모든 작가의 성이 'Kim'이라면요?
'K' 통 하나에만 책이 산더미처럼 쌓이고, 나머지 25개 통은 텅텅 빕니다.
이게 바로 '해시 충돌(Hash Collision)'입니다.
결국 한 줄로 세운 선반과 다를 게 없어지죠.
더 큰 문제는 '공간 낭비'입니다.
속도를 높이려면 통(Bucket)을 늘려야 합니다.
데이터가 10개뿐인데 통을 1000개를 만들어두면, 검색은 빠르겠지만 메모리는 낭비됩니다.
제가 SI 프로젝트 할 때, 무턱대고 메모리 캐시 늘렸다가 OOM(Out of Memory)으로 서버 뻗게 만든 후배 뒷수습하느라 주말을 날린 기억이 납니다.
빠른 속도에는 반드시 '메모리'라는 비용 청구서가 따라옵니다.
공짜 점심은 없습니다.
3. 힙(Heap): 완벽한 정렬은 사치다
모든 데이터를 예쁘게 정렬할 필요가 있을까요?
이 질문에 답하지 못하면 불필요한 연산 자원을 낭비하게 됩니다.
예를 들어 '작업 스케줄러'를 만든다고 칩시다.
수천 개의 작업 중 가장 급한 것(우선순위 1등) 하나만 빨리 꺼내면 됩니다.
나머지 2등부터 1000등까지의 순서는 당장 알 필요가 없습니다.
이때 쓰는 게 힙(Heap), 혹은 우선순위 큐(Priority Queue)입니다.
이건 서류 더미를 쌓아두는 것과 비슷합니다.
가장 중요한 서류만 맨 위에 올려두는 거죠.
아래쪽 서류들이 뒤죽박죽이어도 상관없습니다.
맨 위의 것만 처리하고 나면, 그 밑에 있는 것 중 가장 중요한 놈을 다시 맨 위로 올리면 되니까요.
데이터가 들어올 때마다 완벽하게 줄 세우느라(Sorting) CPU를 태우는 건 바보짓입니다.
'적당한 무질서'를 허용하는 것이 오히려 시스템 전체의 효율을 높입니다.
4. 결론: 유행 대신 '비용'을 계산하라
최근 학계에서는 공간과 시간의 균형을 맞추는 새로운 해시 테이블 연구가 계속되고 있습니다.
심지어 작년에는 학부생이 해시 테이블 검색 시간의 한계를 수학적으로 증명해내기도 했죠.
기본적인 자료 구조조차 여전히 진화하고 있다는 뜻입니다.
그런데 현업 개발자인 우리는 어떻습니까?
그저 남들이 쓴다는 이유로 NoSQL을 도입하고, 이유 없이 RDB를 버립니다.
제가 신입들에게 항상 강조하는 원칙은 딱 세 가지입니다.
- 데이터의 접근 패턴을 파악해라. (읽기가 많은가, 쓰기가 많은가?)
- 제약 자원을 확인해라. (메모리가 부족한가, 응답 속도가 중요한가?)
- 가장 단순한 구조부터 검토해라. (배열로 충분한데 맵을 쓰지 마라.)
개발은 코드를 짜는 게 아닙니다.
우리가 가진 자원(시간, 메모리)을 어디에 '베팅'할지 결정하는 과정입니다.
화려한 기술 스택 뒤에 숨지 마세요.
기본적인 리스트와 맵의 차이, 그 미세한 비용 차이를 아는 사람이 결국 살아남습니다.
오늘 작성한 코드, 정말 최선입니까?
한 번 더 의심해보세요.
