빅데이터 DB, 어떻게 진화할 것인가

테크플래닛2013서 전문가 패널토의 열려

온라인과 오프라인 경험을 아우르며 콘텐츠 이용간 상거래 경험을 가미한 통합 서비스가 주목받는 추세다.

유튜브 영상 속 상품에 대한 구매 링크나 방문 매장에서의 디지털 쿠폰 사용과 같은 시나리오가 유망 사업 기회로 떠올랐다. 이같은 상황은 서비스 운영에 필요한 IT 측면에서 데이터인프라에 기존 관계형 데이터베이스(DB)를 넘어선 유연성과 확장성을 요구한다.

이에 따라 SQL로 대표되는 관계형DB의 한계에 따라 하둡파일시스템(HDFS)같은 분산 환경에 기반한 NoSQL 기술이 대안으로 관심을 받기 시작했다.

14일 서울 삼성동 코엑스인터콘티넨탈호텔 '테크플래닛2013' 현장에선 온오프라인 통합 서비스 제공을 위해 데이터인프라를 활용하는 방안을 주제로 한 패널 토의가 열렸다.

분산 데이터 인프라에 경험이 많은 국내외 전문가와 현업의 실무를 경험해 본 스타트업의 IT 담당자가 SQL과 NoSQL 선택에 따른 고민을 나누고 유연한 서비스 환경을 확보하기 위한 노하우를 공유하기 위해 함께 자리했다.

패널 토의는 박태웅 전 KTH 부사장(이하 박태웅)이 발제와 진행을 맡았다. 패널로 ▲외부 개발자들과 상생 에코시스템 조성을 맡아온 전윤호 SK플래닛 CTO ▲구글 빅쿼리 개발을 담당한 코리 프랜츠메이어 구글 클라우드플랫폼 헤드 ▲클라우데라 엔지니어인 마이클 스택 아파치 H베이스 프로젝트 의장 ▲배달의민족 서비스업체 우아한형제들 공동창립자인 윤현준 CTO, 4명이 참석했다.

현장에서 전 CTO(이하 전윤호)는 새롭게 필요해진 데이터인프라를 운영하고 외부 파트너들에게 이를 제공하는 상황을 대변하는 기술전문가로 나왔다. SK플래닛은 상거래와 위치정보, 콘텐츠 및 모바일 연계 서비스를 다양한 시나리오로 엮기 위한 시스템 개발 과정을 겪었다.

윤 CTO(이하 윤현준)는 초기 수요가 폭증한 이래 계속 많은 데이터가 쌓이는 배달의민족 서비스 운영업체 입장에서 이를 효과적으로 다룰 방안을 고민하는 스타트업들의 고민을 화두로 던졌다.

프랜츠메이어는 구글의 빅쿼리를 포함한 클라우드서비스를 통해 크고 작은 기업들이 새로운 데이터인프라 수요에 대응할 수 있는 가능성을 설명했다. 스택 의장(이하 스택)은 아파치 프로젝트의 여러 분산데이터처리기술들은 저마다의 배경을 갖고 등장한 기술이며, 만능은 아니라고 지적했다.

토의에선 SQL로 처리되던 관계형DB 중심 시스템에서 당면한 문제를 NoSQL이라 불리는 분산 데이터인프라에서 극복할 수 있지만 그 자체가 어떤 상황에나 들어맞는 만병통치약은 아니라는 데 의견이 모였다. 더불어 확장성에 대응하는 측면의 클라우드 서비스 도입시 효과와 필요성도 사업자가 당면한 상황에 맞춰 결정하라는 원론적 답변이 나왔다.

기존 것이나 새로운 기술이나 사용자 증가에 맞춘 확장, 서비스 안정성, 운영과 관리 효율성을 모두 만족할 수 있을지는 여러 요소를 면밀히 검토해야 한다는 얘기다.

또 클라우드에 올린 데이터의 이동성과 안정성에 대한 전제를 단정하기 보다는 비즈니스 특성에 적합한지를 판단해 도입여부를 결정하는 게 적합하다는 조언도 나왔다.

아래는 토의 내용을 정리한 것이다.

박태웅 : 이 자리에서 토의할 주제는 마케팅 속임수로 쓰이는 것 아니냐는 지적을 받기도 하는 빅데이터다. 사실 빅데이터에 대한 멋진 정의가 있다. 이를테면 '10대들의 섹스'같은 것이란다. 왜냐면 다들 그것에 대해 말 하지만 아무도 어떻게 하는지는 모르는 것, 하지만 다들 하고 있다고 생각해서 '나도 한다'고 말하는 것이란 공통점이 있다는 점 때문이다.

이제부터 제가 '그것'이라고 말하면 빅데이터니까, 다른 것이라고 오해하지 마시라. 여기 패널구성을 보면 알겠지만 전윤호는 역할상 서비스제공자 입장에서 주로 말할 것이고, 프랜츠메이어와 스택은 데이터 플랫폼과 툴 제공자 입장에서 얘기할 것이다.

프랜츠메이어 : 여러 플랫폼 사용자를 아우르면서 확장성있는 서비스를 만들기 위해서는 업계에 상용화된 애플리케이션프로그래밍인터페이스(API)를 많이 쓰는 게 좋다. 확장성 대응이나 업무에 필요한 기능 구현이 쉽다.

일례로 자체 지급결제 인프라를 제공하는 '구글월렛'은 서비스운영자 측이 구매와 과금 시스템을 어떻게 만들지 고민할 필요를 없앤다. 같은 맥락에선 분석서비스 '빅쿼리'도 하나의 API다. 그리고 온오프라인간 경계를 넘어서 모바일에 초점을 맞추는 추세가 늘었는데 API를 활용시 이를 따라가기 유리하다.

스택 : 온오프라인에서 콘텐츠서비스를 할 수 있게 해주는 환경을 관리하는 과정만으로도 많은 데이터가 발생한다. 사람들이 빅데이터라 지칭하는 것이 그런 쪽일 수 있다. 빅데이터를 관리하기 위해 필요한 툴로 하둡의 H베이스를 내놨다.

아파치 재단 외에 내가 일하고 있는 회사 클라우데라에서는 임팔라같은 하둡기반 SQL 인터페이스 제공 기술도 다룬다. 하지만 이런 기술보다는 향후 '데이터허브'를 지원해 사람들이 원하는 곳에 데이터를 놓고 필요한 소프트웨어(SW) 도구를 제공해 폭증하는 데이터에서 길을 찾아갈 수 있도록 하는게 더 중요할 듯하다.

전윤호 : SK플래닛은 꽤 규모가 큰 서비스 회사다. 자체 빅데이터, 하둡 인프라도 있고 SAS같은 툴로 분석도 하고, 맵리듀스로 코딩하는 사람들도 있다. 많은 서비스 개발해오면서, 데이터를 잘 활용하려할 때 괴리를 느꼈다.

과거 애플리케이션 개발자들은 구축할 DB가 오라클이냐 마이SQL이냐 정도만을 고민했다. 그런데 데이터사이즈가 커지니, 구글과 아파치 재단의 두 분 말씀대로 고려할 솔루션이 여러가지다. 앱 개발시 범용성을 포기하고 규모가변성을 얻으려고 NoSQL을 쓰고자 하면 관계형DB의 표준 인터페이스(SQL)와 달리 어떤 장단점과 한계가 있을지 이해하고 골라야 한다. 서비스에 집중해야 할 사람들에게 어려운 일이다.

(프랜츠메이어, 스택에게) 사용법이 어렵고 추상화 수준이 상이한 (NoSQL) 기술들이 향후 관계형DB처럼 몇가지로 수렴해 표준 인터페이스로 수렴할지, 그런 트렌드가 나타나고 있는지 묻고 싶다.

프랜츠메이어 : 구글에서도 SQL(인터페이스) 쪽으로 왔다. 대다수 사람들이 (하둡을 다루면서도) 맵리듀스 프로그래밍을 할 능력이 없었기 때문이다. SQL은 여기 참석자들 대부분이 쓸 수 있을만한 언어다. 비즈니스유저들도 SQL로 질의를 표현할 수 있다.

구글은 빅쿼리를 통해서, 밖에선 하이브나 다른 오픈소스 플랫폼에서 빅데이터 위에 SQL 인터페이스를 채택하는 게 트렌드같다. 다만 여기서 한계는 빅데이터 특성에 기반한 자체 신기능 개발이다. 그래프분석 같은 작업은 SQL만으로 안 된다. 그런 식의 구조가 갖춰져 있지 않다.

통계분석을 첨단화하려면 R같은 언어가 필요하다. 앞으로는 사람들이 질의 유형에 익숙해지고 그게 쌓이면 데이터 유형별로 SQL이나 통계적 질의가 표준화될 듯싶다. 그리 되기까지 시간이 걸리겠지만.

스택 : 하둡 영역에선 페이스북의 사례가 있다. 기술적으로 해박한 페이스북 엔지니어들은 H베이스를 채택했다. 하지만 그들만한 지식이 없는 (페이스북의) 다른 조직들은 인프라를 다룰 충분한 자원이 없었다. 그래서 SQL이 다시나온거다.

아파치에도 피닉스라는 인큐베이터 프로젝트가 있는데, 앞으로 아파치 일반프로젝트로 나온다. 과거 오라클 리얼애플리케이션클러스터(RAC)에선 못했던 기능을 많이 내놓는다. 여기에 SQL 인터페이스를 설치하고 하둡의 맵리듀스 인터페이스를 낯설어하는 사람에게 익숙하고 편안하면서도 새로운 데이터 처리기술 쓸 기회를 준다. 표준화 과정에서 NoSQL 시스템이 다 없어지진 않겠지만 대세의 윤곽은 SQL과 경쟁 심화 과정에 드러날 듯하다.

전윤호 : 얼마전에 페이스북 컨퍼런스를 봤다. SQL 쓰는 게 편한 점도 있지만 NoSQL을 추구하면 관계형DB의 장점을 희석시키는 경우도 있는 듯하다. 오버헤드가 늘어난다든지. 마이SQL이나 오라클DB로 못하는 일을 NoSQL로 하려 했을 때, '그냥 쓰라'고 하는 게 얼마나 범용적인 사례에 맞는 방식이 될 수 있을까.

스택 : 그 대부분은 관계형DB에서 익숙한 기능 상당부분을 확장성 제약 때문에 포기하는 경우에 해당한다. 확장성에 문제가 없다면 관계형DB를 떠날 필요 없이 머무르면 된다. 온라인과 오프라인 세계를 아우르는 작업에 연관지어 생각해 보면 내재적 문제는 빅데이터다. 데이터를 관계형DB에 다 담아낼 수 없는 내재적 문제가 있다.

질문은 단순히 (저장소로) 어떤 NoSQL을 쓸거냐가 아니라 더 확대돼야 한다. SQL만으로 해결하지 못하는 데이터, SQL만으로 불충분한 것이 빅데이터다. 그래서 광범위한 (하둡 데이터플랫폼 등) 광범위한 툴셋이 필요해진 거다. 물론 저장소의 확장성 문제가 우선적이지만, 빅데이터 대응 기술 도입시 다른 (문제들에 대한) 해결과제도 마련되지 않을까.

프랜츠메이어 : 전적으로 비즈니스요건에 달렸다. 툴을 요건에 맞춰 결정해야한다. 큰 처리량이 필요하다면 관계형DB, 응답 지연시간이 짧은 트랜잭션이 필요하다면 NoSQL 중에 구글DB나 H베이스다. 하지만 이를 쓰려면 많은 걸 포기해야 한다. 많은 것들이 서비스로 제공되는 추세다. 스타트업 창업자들이 하드웨어 구축 없이 API로 서비스에 접근한다. DB 관리나 인덱서에 대한 걱정도 없다. 내가 원하는 질문에 집중할 수 있게 해준다.

질문으로 되돌아가보면, 빅쿼리같은 서비스에 확장기능을 더해 레귤레이션 쿼리, 텍스트마이닝도 가능케 할 수 있다. SQL로 답할 수 없는 다양한 질문이 있다. 감성 분석, 엔티티 추출, 스토어 네임태그 등이다. 여기엔 별도의 툴이 필요하다. 여기 모인 사람들 전부 학부생때 흘려들은 통계학을 다시 공부해야 할 때다.

윤현준 : 대규모 데이터가 발생하는 서비스를 운영하는 스타트업 입장에서 현실적인 질문을 좀 하고 싶다. 매달 250만건의 주문량 등을 포함해 서비스 사용자들이 행동하고 실행하는 정보들을 계속 로그로 쌓고 있다. 아직 관계형DB로 처리중이다.

더 고차원 정보를 만들어내거나 사용자 특성 분류를 처리해보고 싶다. 유연한 확장과 외부 환경과 결합된 고차원 정보를 만들어 사업적으로, 사용자나 사회학적으로 이용 가능한 데이터를 생산하고 싶다. 그런데 서비스 복잡도가 높아져 단일 사용자 처리비용이 기하급수적으로 늘어버린다.

프랜츠메이어에겐 구글클라우드플랫폼의 빅쿼리같은 서비스로 이런 니즈에 대응한 성공사례가 있는지 묻고싶다. 스택에겐 우리같은 스타트업이 많은 데이터를 즉각적으로 분석 가능한 방법이 있을지 추천 바란다.

프랜츠메이어 : 배달의민족을 운영하는 우아한형제들도 사업영역이 리테일이니, 그 쪽으로 생각해 보겠다. 빅쿼리로 시장분석 우수사례가 있는데 사용자들이 구입한 상품을 들여다보는 게 있다. 예를 들어 피자를 주문시 코카콜라와 같이 주문하는 경우, 레드와인과 같이 사는 경우, 그런 것을 빅쿼리에서 명확히 분석할 수 있다.

하지만 내가 피자와 바베큐를 샀는데, 근처에 사는 사람중에 비슷한 상품을 산 사람이 얼마나 있는지 또는 그들이 얼마나 자주 이런 소비행태를 보이는지는 빅쿼리에서 할 수 없다. R이나 그래프분석 같은 기술로 구현해야 한다. 리테일 분야 고객들이 그런 기술을 사용 중이다.

스택 : 관계형DB를 '스위스 다용도칼'처럼 쓰는건 아닌가 싶다. 사실 우아한형제들이 그런 상황으로 인한 문제를 겪는 유일한 업체는 아닐 거다. 과거 사례들을 통해 배울 내용이 많을 듯하다.

로그 분석은 간단히 시작하는 게 좋다. 일부 간단한 워크로드를 관계형DB에서 다른 시스템으로 옮겨 본다든지. 플룸이나 다른 로그분석 도구가 있다. HDFS같은 인프라로 스트리밍을 하면 된다. 비즈니스 규모가 늘면 간단히 그 인프라를 늘리면 된다.

그리고 가맹점에 원하는 정보를 하루 1번씩 정리해 내보내고. 대량메일전송시스템을 따로 만들어서 HDFS상에서 H베이스 기반 또는 더 간단한 방식으로 웹페이지에 (결과분석)서비스를 해보길 제안한다. 모든 엔지니어링이 그렇듯 단순한 걸로 시작해 점진적으로 키워가는 게 좋다. 나중에 장애 내구성까지 갖추려면. 업계에 유사 경험이 꽤 많을 듯하니 찾아보길.

전윤호 : 프랜츠메이어에게 묻고 싶다. 아마존웹서비스(AWS)같은 프라이빗클라우드를 우리도 쓴다. 자체적으로 서드파티들에게 추천알고리즘을 제공하는 서비스도 운영 중이다. AWS같은 인프라를 쓰는 건 리눅스 가상머신(VM)돌리는 용도일 때 (자체 인프라 쓰는 경우와) 큰 차이를 보이진 않는다.

그런데 플랫폼이나 데이터 분석, 데이터스토리지같은 고수준 기능을 클라우드업체에 의존하게 되면 여러 문제가 있을 것 같다. 비용의 많고 적음이나 개인정보를 저장할 수 있느냐 등과 같은 국가적인 규제요건 등. 아까 얘기한 것처럼 NoSQL이나 데이터분석처럼 질의를 던지는 인터페이스가 표준화되지 않은 상태일 경우, 특화된 기능을 제공하는 클라우드를 쓰면 서비스에 종속되는 문제도 있겠다. 다른 클라우드로 가려할 땐 서비스를 대폭 고치지 않으면 안 된다든지. 서비스제공사 입장에선 고려할 수밖에 없는데. 어떻게 보나. 프랜츠메이어 : 좋은 프로그래밍 디자인이 필요하다. 하나의 시스템에 다른 곳으로 데이터를 옮기는 건 항상 힘든 일이다. 어떤 의사결정이든 종속성은 생긴다. 구글 데이터스토어에 넣든, 빅쿼리에 두든, H베이스에 담든지. 그 결정된 환경에서 다른 환경으로 옮기는 것은 (클라우드에서 다른 인프라로 옮기는 것과 마찬가지로) 문제가 된다.

다시 비즈니스요건으로 돌아가길 제안한다. 재정적으로 타당성이 있는지, 자본과 운영비용이 적절할 것인지. 스타트업 입장이라면 H베이스에 적용시 충분한 인력이 있는지 등을 고려해야 할 것이다. 아주 큰 조직이라면 모든 시스템에 대응할 인적 자원을 보유했을지라도, 일단 결정을 내리면 어느쪽이든 같은 문제는 생긴다고 봐야 한다. 물론 구글 서비스에 담기로 한다면 우리야 좋겠지만.

스택 : 상황에 따라 다르다. 데이터센터운영시 필요한 서비스를 제공하는데 인력확보와 자체장비를 구입해 투자비가 는다 싶으면 클라우드가 나을 거다. 하지만 대형 서비스 운영시 법적 규제가 있고 신용카드 정보 등 유출시 문제가 큰 데이터를 다루려면 타사 인프라를 못 믿을 수도 있다.

한 곳에 올인할 필요는 없다고 생각한다. 구글 인프라에 오픈소스 시스템을 설치하든, AWS에 오픈소스 패키지를 넣고 맵리듀스를 다른 곳에 설정하든, 특정 서비스 구현시에만 연계하든, 이런 식으로 탄력적으로 운영할 수도 있다.

클라우드 시장에서 구글, 아마존, 랙스페이스 등은 서로 경쟁해 가격이 계속 떨어질 거다. 나쁜 일은 아니다. 다만 서비스 운영비에 대한 사각지대를 주의해야 한다. 자체 데이터센터를 갖추는 게 낫더라도 시간당 머신의 가격과 감가상각, 장애시 대응 위한 인건비 등을 모두 감안해야 한다.

박태웅 : 시간이 모자른데 너무빨리 지나갔다. 기술 발전을 보면 사실 결국 마지막엔 범용기술이 표준화되고 쓰기 쉬워진다. 정말 중요한건 그걸 어디에 왜 쓰는지 아는 것이다. 빅데이터가 대세인 건 사실인데, 중요한 건 올바른 질문을 해야 옳은 답이 나온다는 점이다. 그게 빅데이터 사용법이다.

데이터가 정말 압도당할 것처럼 많은 듯해도, 좋은 질문으로 걸러내면 정작 답은 단순할 것이란 얘기가 있다. 이런 측면도 고민해봐야 할 듯 싶다. 여러분들이 어른이 돼서 다 섹스를 할 수 있게 됐듯이 빅데이터도 쓸 수 있을 것 같다. 중요한 발언을 해주신 패널 분들께 박수를 부탁드린다.