오늘 구매할 책의 종류는 '오라클 SQL'입니다. 책을 사러 동네서점에 갑니다. 그리고 서점 입구를 들어가면 수 십만 권의 책들이 빼곡히 진열되어 있습니다. 하지만 원하는 책을 사기엔 오랜 시간이 걸리지 않습니다. 종류별로 책이 잘 분류되어 있기 때문입니다. 제일 먼저 찾아야 할 부분은 '분류'입니다. 컴퓨터는 기호 'I'입니다. 해당 분류 지역으로 이동했다면 그다음은 구역을 찾아야 합니다. '12번'은 데이터베이스를 모아둔 분류 안에 구역입니다. 그다음은 서가입니다. '8번' 책꽂이를 찾으면 책 제목이 '가나다' 순으로 정렬되어 있습니다. 많은 책들 사이로 단 5분 만에 원하는 책을 찾았습니다. 이는 방대한 데이터베이스가 특정 데이터를 찾는 방법인 '인덱스(index)' 방식과 동일합니다.

두꺼운 책을 찾는 인덱스

인덱스 방식을 한글로 풀어내면 '색인'이라고 합니다. 이 방식은 이미 책에서 사용하고 있는 편리한 방법입니다. 영어 사전은 꽤 두껍습니다. 약 3,000장 이상의 페이지로 구성되어 있습니다. 그런데 사전을 뒤적이며 단어를 찾는 시간은 생각보다 오랜 시간이 필요하지 않습니다. 그 비법은 '색인'입니다. 만약 'code'를 찾는다면 알파벳 순서대로, 'c'를 먼저 찾고 순서대로 정리되어 있는 'o', 'd', 'e'를 찾으면 쉽게 찾아낼 수 있습니다. 색인은 글들이 유기적으로 연결하여 한눈에 그 구조를 파악할 수 있게 도와주는 역할을 합니다.

만약에 영어 사전에서 색인이 없다면, 어떤 일이 일어날까요? 만약 단어를 하나 찾아야 한다면 첫 페이지부터 끝까지 한 장 한 장 넘겨가며 모든 글자를 살펴봐야 하는 비효율적인 일을 하게 됩니다. 순서 없이 써놓은 일기장을 뒤적거리면서 떠오르지 않는 생각들을 찾는 답답함과 다를 게 없을 것입니다.

인덱스를 사용하지 않으면

인덱스 사용하지 않으면, 할인매장에 수북이 쌓여있는 재고떨이 옷 속에서 맘에 드는 디자인과 사이즈를 찾아 파헤치는 구매자들의 거친 손길처럼 데이터베이스에서 데이터를 찾게 됩니다. 옷이라는 분류만 있을 뿐 상세하게 정렬되지 않은 이 방식은 혼란스럽고 효과적이지 않습니다. 쓰레기를 정리하면 재활용 센터가 되는 것처럼 쏟아지는 디지털 데이터를 정리하면 데이터베이스가 된다고 이전 시간에 배웠습니다.

그런데 정리정돈 이외에 한 가지 더 해야 할 작업이 있습니다. 바로 순서대로 '정렬'을 하는 것입니다. 데이터가 많지 않을 때는 단순히 종류별로 모아 두고 필요할 때마다. 찾아서 사용해도 큰 문제는 없습니다. 어질러진 좁은 방 안에서 양말을 찾는 것처럼 그때마다 뒤적거려도 금세 찾을 수 있습니다. 하지만 그 방의 크기가 아마존만큼 거대 해진다면, 문제가 발생합니다. 운이 좋으면 발아래 곧바로 찾을 수도 있겠지만, 운이 나쁘면 양말을 찾으러 다닌 시간이 몇 달이 소요될지는 모릅니다. 이렇게 인덱스 없이 모든 데이터를 탐색하는 풀스캔(ful lscan)은 시간과 자원을 낭비하게 됩니다.

인덱스가 필요하지 않을 때도 있습니다.

데이터베이스도 아주 작은 수준이라면, 인덱스를 사용하지 않는 것이 유리합니다. 우선 인덱스를 생성하면 약 10%의 저장공간이 발생합니다. 색인을 해서 데이터를 따로 저장해야 합니다. 그리고 인덱스를 올바른 방법으로 사용하지 않을 경우 오히려 성능의 저하가 발생할 수 있습니다. 그렇기 때문에 규모가 아주 작은 데이터베이스는 인덱스를 사용하지 않아도 충분합니다. 시골의 작은 슈퍼마켓처럼 말이죠.

시골에 작은 구멍가게에는 단골 동네 주민들이 애용하는 쉼터입니다. 어린아이부터 나이 지긋한 어르신들까지 가게 앞 평상에 앉아 잠깐 쉬어갑니다. 이 작은 가게는 택배 대행, 은행, 술집, 놀이터의 역할을 해냅니다. 그리고 동네 주민들이 애용하는 사랑방입니다. 마을과 바깥 세계를 이어주는 연결점이기도 한 역사와 추억이 담긴 곳입니다. 재밌는 풍경은 주인 할머니가 없더라도, 각자 물건을 사고 돈을 계산대에 올려두고 가는 손님입니다. 물건은 몇 안 되는 기호식품이 전부입니다. 라면, 담배, 과자가 가장 많이 팔립니다. 오래된 이 가게에는 따로 정리하지 않아도 손님들은 어디에 무엇이 놓여 있는지 압니다.

구멍가게를 대형마트처럼 상세하게 정렬하여 인덱스 관리한다면 오히려 손해일 것입니다. 사람들은 예전부터 물건들의 익숙한 자리를 감으로 외워 왔기 때문에 물건들이 가나다 순으로 정렬되어 있다고 해도 속도의 차이는 별반 다르지 않습니다. 그리고 정렬을 관리하기 위해서는 노동이 필요로 하는데 주인 할머니의 기력은 한계가 있습니다. 오히려 잘못된 인덱스 사용은 이처럼 역효과가 발생할 수 있습니다. 이럴 때는 그냥 그대로 두는 것도 좋을 때가 있습니다.

인덱스가 필요 없던 시절

카카오톡에서 소비되는 하루에 대화 건수는 약 110억 건이라고 합니다. 그 많은 대화 풍선 속에서도 내가 현재 집중하고 있는 메시지는 인덱스 기술을 통해 몇 초만에 곧 보내고, 받고 있습니다. 분명 인덱스는 빅데이터 시대에 없어서는 안 될 꼭 필요한 기술입니다. 하지만 가끔은 인덱스가 없어도 더 적은 데이터로 더 많이 대화하지 않아도 진실한 한 두 마디로 위로가 되던 그 시절 그때가 그립습니다.

* 참조자료

- <구멍가게 이야기>, 박혜진, 책과함께

-<Database Internals>, Alex Petrov , O'Reilly

keyword

고코더 IT 분야 크리에이터 소속 직업 개발자

내가 하고 싶은 일, IT 개발자 저자

IT 에세이 작가, 현업 개발자, 코딩 강사, 강연자, 파워블로거 | 출판, 강연, 방송, 인터뷰등 제안 연락주세요. "gocoder@kakao.com"

구독자 4,116

매거진의 이전글 디지털 쓰레기를 정리하면 '데이터 베이스'가 된다? 코딩이란? "컴퓨터에게 쓰는 편지" 매거진의 다음글

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari