[웹기획가이드] 데이터베이스(DB), 어렵지 않아요~!!

오늘은 기획자가 알아야 할 데이터베이스 구조에 대해서 설명 드릴텐데요. 웹기획자가 직접 DB 서버를 설계하거나 혹은 DB 프로그래밍을 하는 경우는 사실상 없다고 볼 수 있습니다.  하지만 기획자 역시도 데이터베이스에 대한 기본적인 이해도는 갖추고 있어야 하며... 개발자들이 주로 사용하는 DB 스키마(Schema), 즉 DB 설계도의 전반적인 흐름 정도는 이해할 수 있는 지식을 갖추셔야 합니다. 

하지만, 대부분의 주니어 기획자들이 그러하듯이, 전문적인 개발 용어들이 나오면 자연스레 위축되곤 하는데, 실상 그 의미를 따져보면 그리 어렵지 않습니다. 이는 데이터베이스 역시도 마찬가지 인데, 데이터베이스란 용어 자체가 명확하지 않을 뿐이지, 이미 여러분들은 데이터베이스의 기본이라 할 수 있는 데이터를 매일같이 접하고 있습니다.

게시판에서 볼 수 있는 여러 정보나, 회원정보들.. 상품 정보들... 이 모든 것들이 데이터베이스를 이루고 있는 기반이라 할 수 있는데 이를 좀 더 정의해본다면 논리적으로 연관된 하나 이상의 자료 모음으로, 그 내용을 고도로 구조화함으로써 검색과 갱신의 효율화를 꾀한 것이며 몇 개의 자료 파일을 조직적으로 통합하여 자료 항목의 중복을 없애고 자료를 구조화하여 기억시켜놓은 자료의 집합체라고 설명할 수 있는데요,

[그림. 1] 데이터베이스를 이루고 있는 요소들..

이러한 설명에서 데이터베이스에 대해 기획자가 알아야 할 포인트는 딱 두 가지!!!  바로 검색과 갱신의 효율화 입니다.  이 함축된 내용을 좀 더 풀어 설명해보면, 검색을 했을 때나 페이지 새로고침을 했을 때, 보다 빠르게 페이지가 노출되게 하기 위한 기획자의 역할을 의미하는데요.  여기서 '아니.. 그건 DB 프로그래밍이 잘 되어 있거나, 좋은서버를 구매하면 되는 일이 아닐까?' 하고 생각하실 분들도 있을 겁니다.

DB의 효율화를 꾀하기 위한 기획자의 참여범위는?

물론, 그 부분은 부정할 수 없는 사실이나, 그 와중에도 기획자에 역할은 분명히 있기 마련이며, 이 역할에 따라 DB의 효율화를 꾀하는 부분에 있어 꽤 중요한 비중을 차지한다는 것을 인식하셔야 합니다. 그럼 여기서 기획자가 DB의 효율화를 꾀하기 위해 필요한 기획적인 참여범위... 어떤 것들이 있을까요? 

 

 

제 관점에서는 크게 두 가지를 보고 있습니다. 첫 번째는 효율적인 데이터베이스의 설계를 위한 데이터의 수집범위를 정의하는 것.. 두 번째는 이렇게 수집한 데이터를 어떻게 운용할 것인가에 대한 운용, 관리정책의 수립이 그것인데, 일반적으로 DB를 설계하는 과정에서 기획자가 할 일이 없다는 통념과 달리, 이 부분에서 기획자의 역할은 절대적이라 할 수 있습니다.


[그림. 2] DB를 접하는 기획자의 역할정의.

 

이러한 과정에서.. 기획자의 참여가 필요한 이유는 바로 개발자와의 원활한 커뮤니케이션을 위한 첫 번째 접근이기 때문이며, 이 같은 접근시도는 기획자와 개발자간의 업무의 공유를 위해서도... 더 나은 기획을 하기 위해서도 반드시 필요한 과정이기도 합니다.  하지만, 앞서 이야기 한 바와 같이, DB의 개발은 개발자의 몫이라는 통념이 있기 때문에.. 기획자 본인이 이러한 롤을 만들어나갈 수 있도록 노력해야 하며, 이를 위해 기획자는 데이터 베이스의 기본 개념을 이해하고 갈 필요가 있습니다.

개념이라고 하면 어렵게 생각하실 수도 있겠지만, 아래의 그림을 보시면 아주 간단하게 이해하실 수 있습니다..  데이터베이스의 운용은 쓰기/저장/읽기/수정 이렇게 네 단계로 구성되어 있습니다.

[그림. 4] 데이터 베이스의 운용단계

 

 
이 같은 네 단계에서 쓰기에서 저장하는 과정과 저장한 데이터를 불러들이는 과정, 그리고 저장된 데이터를 수정하고 이를 다시 저장하는 과정에서 기획자가 판단하고 참여해야 할 부분이 생기게 되는데 예를 들어 데이터를 작성해서 저장하는 과정에서 고민해야 할 정책적인 내용을 살펴보면,

1. 서비스를 구성하는데 있어, 저장해야 할 데이터가 필요한 데이터인가? 필요하지 않은 데이터인가?
2. 1번과 동일한 관점에서 지금 받아야만 하는 데이터인가? 나중에 받아도 되는 데이터인가?

이런 두 가지의 정책이 나올 수 있는데 이 정책은 DB 설계자도.. 개발자도 아닌 기획자가 잡아야 하는 사항이며, 어떤 정책을 선택하느냐에 따라 서비스의 전반적인 운용 프로세스가 좌우되며, 이에 따라 기획 방향이나 개발의 포인트까지도 상당한 영향을 받게되며, 궁극적으로 사용자의 편의성까지도 영향을 받게되는데... 이에 대한 부연설명은 앞선 웹기획가이드인 웹기획자가 알아야 할 프로세스편을 참고하시면 되겠습니다.

만일 이 과정에서 기획자의 참여 없이 DB 설계가 진행된다면, 기획적인 의도가 반영되지 않는 서비스가 나올 수 밖에 없으며, 기획자의 역할은 단지 스토리보드를 그려주는.. 속된 말로 '시다바리'로 전락할 수 밖에 없는거죠.

DB정책의 수립은 기획자의 몫이다.

이러한 우를 범하지 않기 위해 기획자는 정책에 대한 이해도를 높여야 하며 데이터를 성격이나 목적성에 맞게끔 명확히 분류할 수 있는 카테고라이징(Categorizing)에 대한 개념을 가지고 있어야 합니다. 카테고라이징에 대한 부분은 다시 한 번 언급할 기회가 있을테니.. 그 때 다시 말씀드리도록 하겠구요... 데이터 베이스와 관련된 정책의 이해도에 대해 먼저 설명드리면, 데이터 베이스는 간단히 보면 수많은 데이터의 베이스캠프와도 같다고 보시면 되는데, 이 중에서 데이터는 여러분들이 일상적으로 보는 모든 정보가 여기에 해당된다고 앞서 말씀 드렸습니다.

이러한 정보들을 어떻게 사용하느냐에 대한 정책을 수립하는 부분이 바로 기획자의 범주인데.. 예를 들어 게시판에 새 글이 작성되면 보통 N 아이콘이 제목에 붙게 되는데 이 아이콘을 몇 일이나 노출시키느냐도 하나의 정책이라 할 수 있으며, 글 목록 페이지에 몇 자까지의 제목을 노출하고, 몇 자 이상 되면 '...' 으로 표기할 지, 혹은 모든 제목을 다 보여줄지와 같은 부분들이 모두 하나의 정책이라 보시면 되겠습니다.  아주 간단하죠?^^

이런 정책들은 스토리보드라고 하는 화면설계 과정 이전에 모두 정의되어야 하는 부분이며, 그래야만 DB 설계시에 기획적인 정책이 반영될 수 있습니다.  물론 주니어 기획자의 경우, 웹 사이트나 서비스의 모든 정책을 완벽하게 정리하는데에는 분명 한계가 있을 수 있지만... 대부분은 조금만 더 생각해보면 나올 수 있는 지극히 상식적인 범주에 해당되는 만큼.. 기획 시에 생각의 깊이를 가져가신다면 그리 어렵지 않게 데이터베이스의 정책적인 설계를 이끌어 가실 수 있을 겁니다...

 

아울러 이 글을 보시는 여러분들의 공감댓글 한마디가 더 좋은 글이 나오는 원동력이랍니다. 글을 통해 도움이 되셨거나 기획과 관련해 궁금하신 점이 있다면 언제든 댓글 남겨주세요..^^ 

 

야메군이 진행하는 "웹기획 마인드 강좌"는 오프라인 강좌 뿐만 아니라, 온라인 강좌로도 만나보실 수 있습니다. 지식 동영상 스토어 "AirKlass", 지구상 가장 큰 학교 "EDUCAST", 전문가의 지식노하우 플랫폼 "TOC6"에서 강좌를 확인해보세요!! 

야메군. Web와 Mobile, Digital 카테고리 SME(Subject Matter Expert). 웹기획 15년차로 네이버 웹기획자 커뮤니티 "웹(WWW)를 만드는 사람들"에서 운영진으로 활동하고 있으며, 딴지일보를 시작으로 아이러브스쿨, 짱공유닷컴, YES24 등의 회사를 거쳐, 현재는 민간 IT 원천기술 연구소 "Valhalla Lab"에서 Pattern recognition과 Machine learning, Natural Language Processing 기술의 상업적 이용방법에 대해 연구했으며, 2016년 7월 7일, 기획자의 업무능력 향상으로 위한 Guide Book "처음부터 다시배우는 웹기획(정재용, 최준호, 조영수 공저)" 출간.