[개발자와 화해하기] 데이터를 정리하는 법 (1) : index 이해하기

기획자와 개발자들은 협업하며 종종 부딪힌다.

정리되지 않은 수많은 아이디어들을 한아름 들고 오는 기획자.

이것도 안되고, 저것도 안된다고 하는 개발자. 

둘은 오늘도 서로에게 고개를 저으며 한숨을 내쉰다. 

 

이런 세상의 수많은 기획자와 개발자들 사이 갈등 속 각자 나름의 사정은 천차만별이지만, 근본적인 원인은 크게 다르지 않다.

바로 ‘서로가 서로의 일을 모른다’는 것

 

 

우리들은 서로의 일을 조금이나마 이해해 보려 노력할 필요가 있다.
서로를 이해하고 상대방이 바라보는 곳을 함께 바라볼 수 있어야 발전적인 대화가 가능하다.  

 

별 헤는 밤을 기획하면서 나 역시도 개발자들과 수없이 부딪히곤 했고, 다양한 방식으로 문제를 해결해 나가려 노력했다.
이 글에서는 별 헤는 밤 프로젝트를 진행하며 생겼던 사례들을 살펴보며, 초보 기획자의 입장에서 우리의 개발자들을 이해하는 시간을 가져보고자 한다. 

---

보기 편한 데이터

토이 프로젝트를 진행하며 우리들은 다양한 데이터들을 흔히 EXCEL을 통해 관리하곤 한다.
당장 SQL을 편안하게 사용할 수 있을 만큼 배우기도 어렵고, 그런 와중에 우리에게 친근한 EXCEL은 여전히 강력한 기능들을 손쉽게 다룰 수 있게끔 지원한다. (하지만 언젠가 우리는 SQL로 전환해야 할 수도 있다.)
특히 데이터를 빠르게 검색하고, 정렬하고, 눈앞에서 비교할 수 있는 기능은 우리의 작업 효율성을 크게 증대시킨다.

 

그렇다면 이러한 관점에서, '다음 두 개의 예시 중 더 편리하게 정리된 데이터는 무엇일까?'

예시 1

예시 2

우리들은 흔히 '예시 1'로 답한다. 각각의 개체가 보유한 속성을 파악하기도 쉽고, 각각의 속성에 필터를 걸고 정렬해 비교해 보기도 쉽다는 이유에서다. 하지만 우리의 DB에는 데이터가 EXCEL에서 보이는 것처럼 저장되지 않는다. 

 

DB를 이해하기 위해 기초부터 짚어보는 것은 지금은 잠깐 생략하기로 하고, 개발자들이 혹시 이런 요청을 해 올때가 있었는지 생각해보자.

개발자 1 : '예시 1'의 데이터를 '예시 2'처럼 바꿔서 전달해 주실 수 있을까요?

개발자 2 : 애초에 그냥 기획쪽에서 '예시 1'의 데이터를 '예시 2'처럼 저장하셔서 관리하면 안되나요?

 

'개발자 1'의 요청은 한 번쯤이라면 납득할 만 하다. EXCEL의 함수들을 잘 다룰 줄 몰라도 데이터의 양이 그렇게 많지 않다면 수작업으로 진행할 수도 있고, 몇 가지 기능만 알아도 금방 할 수 있다.
하지만 기존의 속성을 수정하거나 삭제할 수도 있고, 새로운 속성이 추가될 수도 있다. 이처럼 지속적인 업데이트가 이뤄지는 데이터라면 매번 이 작업을 진행하는 것은 여간 번거로운 일이 아닐 수 없다.

 

'개발자 2'의 요청은 '대체 왜?'라는 의문이 들 수 있다. (말하는 방식도 아주 밉상이다.) 우리는 앞 단락에서처럼 예시 1이 훨씬 편리한 데이터라고 생각해왔다. 예시 2는 우리가 보기에 전혀 효율적인 데이터 관리 방식이 아닌데 대체 왜 개발자들은 이런 요청을 해올까?

---

찾기 편한 데이터

개발자들이 '예시 2'와 같은 데이터를 원하는 이유는 데이터 인덱스(index)와 밀접한 관련이 있다. 인덱스란 추가적인 쓰기 작업과 저장 공간을 활용하여 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조이다. 인덱스에 대해 좀 더 자세히 알아보고 싶다면 다음 글을 참고해 봐도 좋을 것 같다.

 

[Database] 인덱스(index)란?

 

위 글에서 설명된 것 처럼, 우리가 책을 볼 때에도 원하는 내용을 찾기 위해 종종 목차를 활용한다. 또 소제목 등을 훑어보며 찾고자 했던 내용에 더 빨리 접근할 수 있다. 인덱스는 이러한 목차와 같은 기능을 한다.
만약 목차가 여러 페이지에 나눠져 있다면 페이지를 왔다갔다 하며 찾아보는 것은 많은 시간이 들게 할 수 있다. 따라서 목차는 가능한 한 페이지에서 확인할 수 있도록 해야한다.

 

다시 '예시 1'의 데이터를 보자. 

예시 1

우리는 '4족보행' 속성과 '알을 낳음' 속성이 있는 개체의 명칭이 무엇인지 알기 위해서 '속성2' 열(Column)을 쭉 확인해서 '4족보행'에 해당하는 '강아지'와 '도마뱀'을 찾고, '속성3' 열(Column)에서 두 개체에 해당하는 정보를 확인해 '알을 낳음' 속성이 있는 '도마뱀'을 찾아낼 것이다.

그리고 '예시 2'의 데이터를 보자.

예시 2

같은 데이터를 확인하기 위해 우리는 '속성' 열(Column)을 쭉 확인해서 '4족보행'과 '알을 낳음'이 함께 있는 '도마뱀'을 찾아낼 수 있다.

그렇다면 다시 돌아가서 '위의 두 예시 중 더 편리하게 정리된 데이터는 무엇일까?'

 

어쩌면 이제는 마냥 '예시 1'이라 답하기 어렵다. (물론 이 글을 쓰는 내가 이야기에 이런 방향성을 부여했기 때문이기도 하다.) DB에서 우리가 원하는 데이터를 찾는 방법은 위와 유사한 부분이 많다. 방대한 데이터의 경우, '예시 1'처럼 페이지가 많아질 수록 시간복잡도가 비약적으로 증가해 검색이 굉장히 느려지는 결과를 초래할 것이다.

 

따라서 빠른 검색을 요하는 경우 대부분 '예시 2'의 방식을 사용해 DB에 데이터를 저장해 두고 있다. 그러나 앞서 알아보았듯 우리는 '예시 1'의 방식을 원하기도 한다. 따라서 한 쪽 업무 파트에서 이러한 방식의 변환을 맡고 있는 경우도 있고, 사용하는 Tool에 따라 자연스럽게 양 쪽으로 변환을 해 주는 경우도 있다. 하지만 상대방이 왜 이런 데이터 정리 방식을 원하는 지 알면 좀 더 좋은 의미의 협업을 해 나갈 수 있을 것이다.

 

이제 '개발자 1'과 '개발자 2'의 요청이 이해가 되는가? 그렇다면 이 글은 소기의 목적을 이뤘다고 할 수 있다. 다음 글에서는 이해의 깊이를 더하기 위해, B-Tree에 대해 알아보고자 한다.

 

---

별 헤는 밤으로 바로가기!

별 헤는 밤: 밤하늘, 별자리, 여행정보와 날씨예보까지 - Google Play 앱