WBS 리포트

지식 경제부에서 국내 기술로 세계적인 소프트웨어를 만들어보겠다는 일념으로 시작한 WBS프로젝트가 이번 3차를 마지막으로 종료되었다. 알티베이스는 티베로,  ETRI, KT와 함께 컨소시엄을 구성하여 주제 발굴에서 프로젝트 수주를 하게 되었다. 프로젝트의 시작을 앞두고 잠시 숨돌릴 틈이 생기게 되자 이를 기록으로 남겨야 한다는 의무감이 느껴져 이렇게 WBS 리포트를 남기게 되었다.

1. 현실인식

이 프로젝트는 사실 한국의 대표적인 DBMS 개발업체인 알티베이스, 큐브리드, 티베로 3사가 뜻을 모은 프로젝트였다. 그러나 큐브리드는 개발 주체가 NHN에 있었기 때문에 실질적인 참가는 불가능했지만 과제선정이 가능하도록 큰 힘을 보태주었다. 오픈소스 DBMS인 큐브리드를 제외한 나머지 알티베이스, 티베로는 과제선정 뿐 아니라 수주에도 좋은 관계를 지속하며 결실을 이루어 내었다.

시장에서는 이들은 치열한 경쟁을 하는 업체들로 알려져 있지만 이 프로젝트만큼은 힘을 합칠만한 충분한 개연성, 좀 더 정확하게 말하자면 공감된 현실인식이 있었다. 그것은 국내 DBMS시장을 점유율 기준으로 바라볼 때 외산 제품이 거의 95%정도를 차지하고 있고 단 한번도 국산 DBMS가 5%의 시장 점유를 넘어선 적이 없다는 현실에서 중요한 기업, 국가의 자산인 정보를 국내 기술로 담아두지 못하는 것에 대한 반성이 주가 되고 있었다.

사실 이렇게 된 연원은 우리가 시기를 놓쳤기 때문으로 분석하고 있다. DBMS라는 제품은 데이터를 안전하고 정확하게 처리해야 하기 때문에 상당히 오랜 기간 개발에 공을 들여야만 한다. 또한 대부분의 업무에서 DBMS를 사용하고 있는 만큼 무수한 경우에도 사용자가 원하는 결과를 내어 주어야 하기 때문에 기능과 성능이 고객을 만족시킬 수 있는 수준에 이르기 위해서는 고객과 개발사간의 상호 인내와 노력이 필요하게 된다.

지금 한국은 물론 전 세계적으로 가장 점유율이 높은 오라클도 이러한 과정을 거쳐왔다. 오라클이 1970년대 말 세상에 등장했을 때의 이름은 오라클이 아니었다. 이 이름은 1983년 국방부 프로젝트명을 따서 변경한 것으로 알려져 있다. 그만큼 오라클은 결국 미국인의 세금으로 운영되는 미 국방성이라는 고객을 통해 험난한 시장 경제의 경쟁에서 데이터베이스라는 제품을 키워냈고 상용화에 대한 수준을 높여왔다.

반면 우리나라의 데이터베이스역사는 거의 밀레니엄과 함께 시작했다. 한국의 DBMS 개발의 선두주자인 알티베이스조차 ETRI산하의 ‘바다’라는 프로젝트의 결과물을 토대로 2000년대 문을 열게 되었으니 오라클에 비해 거의 20년이 늦은 시점이었다. 이 때 오라클은 이미 버전이 8이었으니 이것은 직장인과 유치원생과의 싸움 정도라고 할 수 밖에 없는 상황이었다. 지난 십여년간 이 격차는 좁혀지지 않고 있었다.

그러나 세상은 항상 변화하고 있고 항상 사람들은 변화 속에서 기존 질서를 변화시킬 틈을 찾아내곤 했다. 스마트폰을 통해 센서가 생활 속으로 들어오게 되었고 센서를 통해 더 많은 일을 할 수 있음을 감지하기 시작했다.

미국의 벨연구소의 김종훈 사장은 작년 가을 한국을 방문하여 “길게 보면 곳곳에 센서가 장착되는 센서 네트워크 사회로 갈 것이다. 심지어는 인체에도 센서가 장착될 것이다. 모든 것이 스마트해지고, 서비스도 스마트해질 것이다.”라는 말을 남겼다. 다시 말해 센서는 향후 IT는 물론 세상을 변화시킬 동인 중 하나가 될 것이다.

2. 센서 DBMS

이러한 변화에서 한국의 DB쟁이들은 하나의 길을 찾게 된다. 데이터 관점에서 센서를 바라본 것이 그 시작점이다. 센서의 역할은 주기적으로 일정한 데이터를 계속해서 생산하여 서버로 전달하게 된다. 이 센서 데이터는 시작과 끝이 없는 성격을 지닌다. 지금까지 DBMS를 다루는 데이터는 트랜잭션이라는 단위가 있었다. 전형적인 예로 은행에 돈을 이체하는 것을 생각해 보면 이체를 시작할 때 돈을 보내고 받으면 끝이 난다. 하지만 센서는 계속해서 데이터를 흘려보낸다. 그래서 센서 데이터는 기본적으로 Streaming(흐름)이다.

센서 데이터의 또 다른 특징은 대부분의 데이터가 의미가 없다는 것이다. 가령 일정 온도를 유지해야 하는 곳에 온도 감지 센서를 달아놓은 경우를 생각해 보자 이 경우 대부분 정상 수치를 나타내다가 문제가 발생하면 이를 감지하는 것이 주된 역할일 것이다. 센서는 이 문제 상황을 알아내기 위해 24시간 계속해서 데이터를 인식해서 보내게 된다. 하지만 사람들이 의미를 두는 것은 언제 발생할 지 모르는 문제 상황 때의 데이터 뿐이다.

센서 데이터의 마지막 특성은 초대용량이라는 것이다. 센서 하나만 해도 끊임없이 데이터를 보내고 있는데 보통 센서는 상당히 많은 수를 설치하여 중앙에서 이 데이터를 집적하게 된다. 그러므로 굳이 설명을 하지 않아도 엄청난 양의 데이터가 쌓일 것은 짐작이 가능하다. 요약해 보면 센서 데이터는 수 많은 센서를 통해 끊임없이 생성되기 때문에 초 대용량이지만 대부분의 데이터는 의미가 없다고 할 수 있다.

그런데 지금까지 이 센서 데이터를 관리 하는 방식은 이러한 센서 데이터의 특성에 맞게 진행되었다기 보다는 기존의 SW를 조합하는 수준에 머무르고 있다. 일단 센서를 설치된 지역 등의 단위로 나누어 센서 데이터를 1차적으로 받아들이는 게이트웨이가 존재하였다. 이 게이트웨이는 센서 데이터를 받아들여 서버로 그대로 전송하게 된다. 그러면 서버는 이 데이터를 저장하여 주기적으로 데이터를 조회하여 현재까지 수집된 데이터에서 이상 징후가 있는지를 파악하게 된다.

이러한 구조는 데이터의 관리와 전송이라는 측면에서 개선의 필요성이 제기된다. 우선 센서데이터는 초대용량이기 때문에 이 모든 데이터를 저장하고 관리하는데 비용이 많이 들게 됨은 물론 저장 이후 문제상황을 알아보기 위해 조회하는데 있어서도 성는 문제가 발생하게 된다. 또한 센서에서 데이터베이스로 저장되기 까지 전송되는 비용이 커지게 된다. 이러한 문제점들로 인해 각종 응용분야에서 센서를 이용하는데 있어 장벽이 되어 산업 전반에 확산하는 걸림돌이 되어 온 것도 사실이었다.

그래서 이러한 문제점을 해결하고자 센서DBMS라는 프로젝트를 구상하게 되었고 요즘 이슈화 되고 있는 Big Data의 한 축으로서 시장을 선점하는 효과를 통해 국내 DBMS시장에서 국산 제품의 점유율을 높이는 기폭제 역할을 노리게 되었다. 센서DBMS의 기본 구상은 센서 데이터의 선처리를 통해 의미 있는 데이터만을 저장소로 보내 전송 및 저장되는 데이터의 양을 파격적으로 줄이는 것이다.

그래서 센서 데이터를 1차적으로 수집하던 게이트웨이에 컴퓨팅 능력을 부여하고 관리주체가 부여하는 규칙(rule set)을 통해 데이터를 걸러내게 되고 의미 있는 데이터가 있다면 이를 저장소로 보내어 문제상황을 인지할 수 있게 해 준다. 이 컴퓨팅 능력을 지닌 게이트웨이를 mRouter라고 명명하였고 이 mRouter가 할 수 있는 일은 그저 정해진 온도보다 달라졌는지를 인지하는 단순한 것을 넘어 이전 1시간 동안의 평균에 비해 최근 1분간의 평균이 어느 정도 달라졌는지 그리고 그 변량이 허용치를 넘었을 경우 시간간격을 더 좁게 하여 값을 수집한다던가 하는 정도의 지능적인 감지 및 제어가 가능하게 된다.

WBS 프로젝트는 기본적으로 상용화를 전제로 하고 있다. 그래서 센서DBMS 컨소시엄에서는 통신사업자인 KT와 함께 시범 서비스를 진행할 계획을 일찌감시 가지고 있다. 소프트웨어의 완성은 개발실이 아니라 현장에서 이루어진다는 것은 십 수년간의 경험을 통해 잘 알고 있기 때문에 이 중요한 기회를 비즈니스로 연계시키기 위한 거점 프로젝트 형식으로 시범 서비스를 수행하려 하는 것이다. 이미 KT는 다년간의 경험을 통해 멀티테넌트 환경의 ASP 서비스를 진행해 왔기 때문에 이 플랫폼과 센서 DBMS의 비즈니스 모델을 연결하려 하고 있다.

3. Big Data

올해 IT전망을 다루는 매체에서 꼭 빠지지 않는 키워드는 단연 Big Data라 할 수 있다. 그런데 Big Data라는 용어는 이제 개념화되고 있는 단계이고 아직 그 Use Case가 명확하게 드러난 것은 아니다. Big Data라는 개념도 아직 명확하게 정의되지는 않았지만 IDC에서 정의한 바에 따르면 다양한 데이터로 구성된 방대한 볼륨의 데이터로부터 고속 캡쳐, 데이터 탐색 및 분석을 통해 경제적으로 필요한 가치를 추출할 수 있도록 디자인 된 차세대 기술과 아키텍쳐가 바로 Big Data라고 한다. 그리고 Big Data에 포함되는 데이터는 기존 부터 다루어 왔던 Structured Data는 물론 SNS Feed, 동영상과 같은 Unstructured Data, 그리고 센서정보, 통화 기록(CDR) 등의 Semi-Structured Data를 모두 포괄하고 있다.

Big Data를 처리하기 위한 기술적인 논의는 여전히 진행 중이지만 개인적으로는 하나의 솔루션으로 이 방대한 종류의 데이터를 포괄할 수 있을 것이라 생각하지는 않는다. 오히려 각 Data의 성격에 맞는 솔루션들을 집합하여 Big Data를 다루어야 한다는 생각을 가지고 있다. 센서를 통해 수집되는 정보는 대표적인 Semi-Structured Data이다. 지금까지 Structured Data를 관계형 데이터베이스에서 다루었다면 Semi-Structured Data는 센서DBMS와 같은 솔루션을 통해 다루어야 한다.

현재 Big Data는 공룡같은 외국 벤더들만이 향유하고 있는 상황이지만 국산 DBMS업체들이 만나 진행하고 있는 센서DBMS도 사실 그 내용을 살펴보면 Big Data인 것이다. 물론 이 프로젝트를 구상하는 단계에서 Big Data라는 용어는 알지 못하였지만 한국의 DB쟁이들이 내다본 미래의 방향은 틀린 것이 아니었음을 알 수 있다.

게다가 센서DBMS의 경우 데이터를 저장한 이후 이것이 의미있는지를 살펴보는 전형적인 방식에서 벗어나 데이터가 의미가 있는지를 먼저 판단한 후 의미 있는 데이터를 선별하여 저장한다는 발상의 전환이 돋보이는 방식이고 이는 향후 Big Data시대에서도 경쟁력을 담보한다고 생각한다.

지금까지 WBS 프로젝트에서 센서DBMS라는 과제의 탄생과 수주를 경험한 사람의 입장에서 이 의미를 같이 공유하기를 바라며 기술해 보았다. 센서 DBMS은 사실 수주하는 것 보다 그 실행과 비즈니스로의 이행이 더욱 중요하고 더 큰 의미를 가진다. 이는 비단 국민의 세금으로 운용되는 프로젝트의 의미를 떠나 한국의 DB쟁이, IT인들이 자신들의 이해관계를 뒤로한 채 힘을 합쳐 미래를 준비하고 국내 시장을 지켜보겠다는 어떤 의미에서 역사 의식이 발현된 중요한 시도라고 생각한다. 그럼에 있어 앞으로 이 프로젝트를 진행해 나갈 알티베이스, 티베로, ETRI, KT 그리고 이에 관계된 모든 사람들의 앞으로 2년 동안의 건투를 빌면서 글을 마치고자 한다.