|
| |
| 1990년대 초반 Web이 국가기관, 연구소, 학교 등 제한된 영역에서 탈피하여, 기업들의 홈페이지및 상업활동에 본격적으로 활용되기 시작한 이후로, Web은 Role과 Technologies 측면에서 많은 발전을 이루어왔다. 초창기 Web의 Role은 기업의 회사소개서(Vision, 서비스분야 및 상품, 조직, 찾아오는 길 등)를 일반 대중에게 알리는 홍보자료 수준의 ‘One way, 단순 정보 전달 방식’이었다. 반면, 최근에는 2000년대 초반부터 불기 시작한 Web 2.0 바람과 더불어, 포탈 등 전문 Web 서비스 업체 뿐만 아니라 일반 기업에서도 고객의 적극적인 참여를 유도하여 기업의 연구활동, 경영혁신까지도 이루어내는 ‘Interactive, 협업 체계’ 방식으로 발전하였다. 이러한 Role의 변화와 더불어 기술도 단순 HTML에서 Rich Internet |
저자소개: 이보현
(現) (주)이큰아이즈 대표이사 |
프로젝트 :
ㆍAssetPLUS 홈페이지 및 CRM 시스템 개발
ㆍ티켓링크 정산시스템
ㆍ대한항공 Internet Booking Systems 및 신화물 시스템
컨설팅 & 구축
ㆍ포항제철 차세대 정보전략 발전방향(ISP) 컨설팅 등 |
강 의 :
ㆍ티켓링크 Data Modeling 강의
ㆍ서강정보공학회 e-business 환경에서 CRM 구현과
DW Architecture 구축 강의
ㆍ고려해운 DFD와 Data Model 강의
ㆍ연세대, 경희대 등 Data Model 강의 등 다수 | | |
Application, Ajax, RSS 등이 발전하였으며 발전하였으며, 이제는 기업 내부 응용프로그램들도 대부분 Web Technology를 이용하여 개발되고 있다.
그러나, 이러한 Web의 엄청난 확산을 보면서 한가지 아쉬운 점이 있다. James Martin의 정보시스템 방법론인 “Information Engineering”에 의하면, 기업을 이루는 핵심 구성 요소는 ‘Data’와 ‘Activity”이다. 그리고, 기업이 경쟁력을 갖추기 위해서 Activity는 비즈니스 환경변화에 효과적으로 적응할 수 있도록, ‘Dynamic’하고 ‘Flexibility’를 가져야 하며, 이를 위해서는 Activity에 비해 쉽게 변하지 않는 특성이 있는 기업의 Data를 “잘 정의한” Data Model이 매우 중요하다. 이러한 관점에서 지금의 홈페이지를 포함한 Web Application 구축 과정을 보면 Web 시스템의 문제점을 엿볼 수 있다. 가장 일반적인 문제점으로 Data Modeling이라는 핵심 Task가 사라졌다는 것이다. 대형 프로젝트 몇몇을 제외하고는 설계자(또는 전문 Data Modeler)가 기업의 Web 전략 실행 방안을 고려한 Data Model을 수행하고, 현업과 비즈니스 전문가가 기업의 전략 또는 To Be 업무 프로세스를 제대로 반영하고 있는지에 대하여 Review를 하는 과정 등이 생략되어 있다. 대신 각자 개발자가 자신의 영역에서 필요한 데이터를 생성하고 프로그램을 개발한다. 결과적으로 데이터의 이중관리로 인한 중복성 문제, 불일치 문제 뿐만 아니라 향 후의 확장성이나 고려될 틈이 없다. 때로는(보지 않고는 믿기 어렵지만) 권한 등급별 User ID를 Program Source에 코딩해 놓는 경우도 있다. 이러한 연유로 홈페이지가 6개월 또는 1년마다 옷을 갈아 입을 때, 기존의 데이터 모델도 완전히 무시되고 또 다시 날림공사로 만들어진다. 이러한 형태의 프로젝트로 인하여 기업이 지불해야하는 대가는 생각 외로 매우 크다. 기업은 프로세스의 변경이나, 업무 변경시 프로그램을 대폭 수정해야 하며, 때로는 데이터 모델의 유연성 문제로 인하여 시스템을 재구축해야 하는 경우도 발생한다. 또한, 개발자간 인수인계 또는 지식전달 과정에서 매우 많은 시간과 비용이 필요하다. 또한 시스템 관리자과 개발자는 비즈니스 로직을 이해하는 데 많은 시간이 소요되기도 한다. 그러나 가장 크고 심각한 문제는 서비스를 빨리 런칭할 수 없다는 것이다. 과거 Internet Service 운영 경험에 비추어 보면, 경쟁사가 새로운 서비스를 런칭하면, 1-2주내에 동일한 서비스를 만들어 제공해야 하는 경우가 있다(소위 물타기이다). 이때 잘 정의된 Model이 없다면 시간과 비용이 배로 들며, 이 후 런칭시에는 이미 상당수의 고객이 떠나가거나, 경쟁사의 서비스가 자리를 잡은 상태이다.
이러한 현상들의 원인은 Web의 Role이 과거 ‘One way, 단순 정보 전달 방식’에서, 많은 데이터를 바탕으로 서비스를 제공하는 ‘Interactive, 협업 체계’로 변화되었음에도 불구하고, Web 구축에 관련한 이해당사자들의 개념은 진화하지 못한것에 기인한다.
요즘 웹 세상에서 가장 많이 회자되는 단어 중 하나가 바로 ‘Web 2.0’이다. 그러나 실제로 ‘Web 2.0’이 처음 기대대로 많은 성과를 내는 곳은 그리 많지 않은 것이 현실이다. Web 2.0이 제대로 성과를 내지 못하는 이유에는 기술, 환경, 서비스 등 다양한 분야에서 찾을 수 있겠지만, 필자의 생각으로는 그 근간을 이루는 ‘Data Modeling’ 기술의 부재도 그 원인중의 하나이다. Web 2.0의 실체에 대해서는 논란이 많이 있지만 교집합을 이루는 특성을 보면 “자발적인 참여와, 정보의 공유, 그리고 개방을 통한 의사소통”이다. 이러한 Web 2.0을 시스템 의미를 전환하면 Flexibility, Personalization, Interface이다. 즉, 사용자의 참여를 유도하기 위해서는 의견제시, 정보의 분류 및 검색 등에 사용자의 의견이 반영될 수 있도록 시스템과 Data 구조가 유연해야 한다. 또한, 수 많은 정보와 서비스 중에서 효율적이고 효과적인 Web 활동을 위해서는 사용자마다의 특성과 환경을 고려한 서비스 구조 또는 형태가 제공되어야 한다. 그리고, 당연히 공유 및 공개를 위해서는 Interface되는 Data가 잘 정의되고 표준화되어야 한다. Web 2.0이라는 사용자 중심의 Web 서비스가 사용자와 함께 꽃을 피우기 위해서는 위의 속성을 고려한 Data Modeling 이 필수적이다.
본 원고에서는 Web 2.0을 보다 실용적인 형태로 구현할 수 있는 몇 가지 방법을 Data Modeling 관점에서 제시하고자 한다.
<게시판>
게시판은 가장 일반적이면서 폭넓게 사용되는 사용자 참여 형 서비스로, 특정 주제별로 구성/운영되며, 자유로운 글쓰기가 가능한 서비스다. Web 2.0 시대에는 이러한 게시판 서비스가 발전하여 사내에서는 지역, 취미 등 다양한 형태의 ‘동호회’, ‘경영혁신활동’ 또는 ‘프로젝트 별 정보방’ 등으로 활용되며, 외부의 Web 서비스 세상에서도 다양한 ‘토론방’, ‘카페’ 등으로 발전되어 활용된다.
이러한 게시판 유형의 서비스는 사용자의 다양한 요구와 환경변화를 지속적으로 수용해야 한다는 것이다. 과거에는 기업 또는 서비스업체에서 주어진 ‘주제’ 또는 ‘방’에서만 활동해야 했다. 새로운 방을 만들고 활동을 하기 위해서는 프로그래머들이 프로그램을 수정 해야 했다.
그런데 지금은 어떠한가? 사용자들이 관리자에게 ‘방’ 개설을 요청하거나 더 나아가 사용자들이 스스로 ‘방’을 만들고, 멤버를 모으고 활동을 한다. 이러한 것을 자유롭게 하는 기술이 바로 ‘Template 기술’ 또는 ‘Metadata Modeling 기술’이다. Metadata는 Data에 대한 Data를 기록 관리하는 방법이다. 요즈음, 기업의 Data 표준화 Project에서 많이 이용되고 있으며, Oracle 등과 같은 DBMS가 테이블, 칼럼을 관리하는 것도 Metadata를 관리하는 것이다. 이러한 방법에 따라서 ‘방’과 같은 게시판 마다의 데이터 저장소를 만들고, 이러한 데이터 서비스를 위한 프로그램을 만드는 것이 아니라, 방을 만들 수 있는 구조 자체를 모델링 하고 이를 서비스하는 프로그램으로 개발하는 것이다.
회사의 동호회를 중심으로 예를 들어보자. 프로그램 개발 당시에 회사에 농구, 축구, 야구 동호회가 있었고, 각 동호별 활동 지원을 위해 별도의 게시판을 운영하기 위해서 다음과 같이 3개의 게시판 엔티티타입을 만들고 시스템을 개발하였다. 그리고 각 게시판마다 참여회원을 ‘Child’ 엔티티타입으로 모델링 하였다. |
| <그림 1> 동호회 Data Model A |
| 이러한 기업에서 최근 정부의 녹색 바람을 타고 자전거 모임이 형성되고 이를 위한 게시판이 필요하게 되었다. 이러한 경우, <그림 1>과 같은 Data Model로 이루어진 시스템이라면 <자전거 동호회> 엔티티타입과 <자전거 동호회 회원> 엔티티타입을 추가하고 프로그램을 수정하여야 한다. 반면, 요즘 인터넷 또는 인터넷 서비스 기업들은 어떤가? 사용자가 요구하면 시삽 담당자 정보만 제공하면 바로 뚝딱 만든다. 정말로 뚝딱 만들어 준다. 심지어는 사용자가 스스로 만들기도 한다. 어떻게 이것이 가능한가? 이러한 시스템은 대체로 다음과 같은 데이터 구조로 이루어져 있다. 즉, 동호회 자체를 데이터로 갖는 엔티티타입(또는 테이블)인 ‘동호회’ 엔티티타입을 추가하고, 동호회 별로 이루어진 게시판을 <동호회 소식>이라는 엔티티 타입으로 통합하였다. 그리고, ‘동호회’별로 관리하던 회원을 <회원>엔티티타입을 추가하고 이를 <동호회> 관계성을 관리하는 <동호회 별 회원>이라는 엔티티타입으로 구성하였다. |
| <그림 2> 동호회 Data Model B |
이러한 구조의 장점은 동호회가 추가되거나 폐지되어도 프로그램의 수정이나 추가 개발이 거의 필요 없이, 관리자 또는 운영자가 동호회를 신설하고 운영할 수 있다(이를 위해서는 프로그램 측면에서도 약간의 추가 손질이 필요하다). 또한, 카페의 특성을 하나 추가한다고 했을 때, 한번의 개발 또는 수정과정을 통하여 모든 카페에 적용할 수 있다. 예를 들어 부운영자를 추가하기로 한 경우, 한번의 프로그램 수정으로 모든 동호회에 적용할 수 있다. 그리고, 직원이 퇴사를 할 경우, <동호회별 회원> 하나의 엔티티타입 정보만 수정하면 되므로 운영도 훨씬 편리할 뿐만 아니라, 관리자의 실수에 의한 누락 등으로 인한 정보의 불일치도 해결 할 수 있다.
<폭소노미(Folksonomy)>
폭소노미는 대중분류법으로 자유롭게 선택된 키워드를 이용하여, 구성원이 함께 정보를 체계화하는 방식이다. 즉, 웹 페이지에 올라와 있는 정보나 관련 주제를 고전적인 분류기반의 디렉터리로 나누는 것이 아니라 키워드(꼬리표, 태그)에 따라 구분하는 새로운 분류 체계를 의미한다. 이러한 꼬리표는 사람들이 직접 만들 수도 있고, 인공지능 엔진이 자동으로 생성할 수도 있다. 폭소노미는 웹 2.0세대가 추구하는 네트워크 지향 웹 형성에 있어 가장 기초적 역할을 수행하는 것이기도 하다.
가장 대표적인 사이트가 바로 ‘delicious’이다. |
<그림 3> delicious
‘delicious’는 위 그림에서 보는 바와 같이 사용자가 글을 올리면서 자기의 글에 대한 태그(Tags)를 1개 이상 등록한다. 사용자는 모든 정보를 이 태그를 기준으로 볼 수 있다. 예를 들어, 위 화면 중 두 번째 글인 ‘Bank of Imagination’ 글을 읽고 유익하고, 특히 ‘design’과 관련된 추가 글을 보고 싶다면 글 오른쪽에 있는 ‘Design’이라는 태그를 클릭하면 이에 해당하는 모든 글이 제공된다.
과거에는 정보 분류 체계를 서비스 제공업자가 몇몇의 키워드를 제공한 반면, 지금은 그 분류 기준을 사용자들이 직접 지정하고 관리하는 형식으로 변경된 것이다. 이러한 트렌드는 우리 주위에 깊숙이 들어와 활용되고 있다. 예를 들어, 부동산 사이트의 경우에도 과거의 지역별, 금액별, 평형 별 분류에서, ‘편의시설이 좋은 집’, ‘시세보다 저렴한 매물’, ‘깨끗하게 올 수리’등 테마 별 부동산 검색이 가능하다.
이러한 폭소노미와 관련된 Data Modeling 기법을 다음의 ‘문화상품과 관련된 간단한 사례를 중심으로 알아보자 요즘 문화 분야 중 가장 인기 있는 뮤지컬의 경우 다음 그림에서 보는 바와 같이 크게 5가지의 테마 별로 분류하여 고객들에게 제공한다.
| <그림 4> 뮤지컬 폭소노미 |
| 이러한 서비스들은 보통 다음과 같은 데이터 모델을 가지고 서비스되고 있다. |
| <그림 5> 뮤지컬 Data Model A |
그러나, 위의 모델에 근거한 서비스들은 대부분, 일반적으로 서비스 주체가 과거보다 약간 폭넓게(장르 1, 장르 2, 장르 3) 정의한 단어 또는 주제에서 선택할 수 밖에 없다. 하나의 상품별로 하나 또는 2-3개의 테마를 정해놓고 서비스가 운영되고 있다. 결국 겉으로는 Web 2.0을 표방하지만 실제로는 Web 1.0을 벗어나지 못한 모습들을 종종 볼 수 있는데 그런 이유 중 하나가 바로 이런 Data Model에 기인한다. 예를 들어, 뮤지컬 난타의 경우, 위의 어떤 분류 기준에 들어갈 것인가? 순수 국내 창작품이므로 창작뮤지컬에 포함될 것이다. 또한, 대사가 없으니 넌버벌 퍼포먼스이기도 하다. 그리고 마지막으로 부모와 학생들도 함께 볼 수 있으니, 이동/가족에도 포함되어야 한다. 이러한 비즈니스 환경하(여기까지의 업무 요건 하에서는)에서 위 그림과 같은 데이터 모델도 괜찮다. 그러나 어떤 고객이 이 난타를 보고 외국인에게 추천할만한 작품이라는 추천을 한다면 어떻게 할 것인가? 장르 3 Column에서 ‘아동/가족’을 빼고 외국인을 넣을 것인가?
이러한 요건을 수용하고 폭소노미가 제대로 운영되기 위해서는 다음 그림과 같이 데이터 모델 자체가 Flexibility를 보장하는 것이 매우 중요하다. 이러한 Flexibility 를 보장하기 위해서는 분류기준이 하나 이상 가능해야 하며, 분류기준도 사용자가 등록할 수 있어야 한다. |
| <그림 6> 뮤지컬 Data Model B |
|
즉, 사용자가 주제를 정하고, 상품과 서비스를 사용자의 주제에 따라 분류하고 제공할 수 있어야만 사용자의 참여를 유도할 수 있으며, 고객의 취향 파악도 가능하여, 상품 Sales Power도 높일 수 있을 것이다. |
출처: 개발자 천국을 꿈꾸는 국내 최대의 IT 포탈 DEVPIA |