데이터이야기
DB 노하우, 데이터직무, 다양한 인터뷰를 만나보세요.
소셜 미디어 시대 실시간으로 사용 경험을 읽다 소셜 오피니언 실시간 모니터링 Alert 시스템 기업이나 제조사들이 소셜 미디어를 통해 토해내는 자사 제품에 대한 고객의 의견에 촉각을 곤 두세우는 시대다. 기술전문가 과정 10기에게 우승 트로피를 안긴 ‘소셜 오피니언 실시간 모니터 링 Alert 시스템’은 오픈소스인 하둡 에코시스템을 통해 소셜 미디어상의 자사 제품에 대한 의견 을 실시간으로 수집해 문제가 될 만한 소셜 오피니언을 경고해준다. 여력이 부족한 중소기업이 나 스타트업들이 기업 이미지나 브랜드 인지도 제고에 활용할 수 있을 것으로 기대된다 The Challenges 2주간의 이론교육 과정을 마치고, 우리 조는 그날 바로 프로젝트 아이템 선정 작업에 들어갔다. 다양한 아이디어가 나왔 고, 그 중 조원들이 많은 관심을 가지고 있었던 소셜 미디어에 초점을 맞춰 실시간 데이터 분석을 하기로 했다. THE APPROACH 조원 다섯 명 모두 현업에서 SI 프로젝트를 진행하고 있고, 지방에 거주하시는 분도 있어 평일에는 따로 소집을 하지 않고 주말에만 모여서 프로젝트를 진행하기로 했다. 분석은 실시간 분석이 가능한 스파크 플랫폼 으로 선정했다. 수집기는 스파크 API에서 제 공하는 트위터 관련 API를 사용해 구현했고, 수집된 트윗이 문제가 되는 트윗인지 구별하 는 분석기로는 머신러닝(기계학습)의 모델 을 활용했고, Spark MLlib의 Naive Bayes를 사용해 모델을 만들었다. 수집기를 통해 수집된 트윗은 스파크 스트리밍(Spark Stream)을 통해 실시간으로 HDFS와 머신러닝 모델에 보내지도록 구성했다. 머신러닝 모델은 트윗이 문제가 되는지 아닌지를 판별해 문제가 되는 트윗(예: 내 아이폰 배터리가 폭발했어요, 내 갤럭시 S6가 자동으로 재부팅이 계속 되요 등)이면 시각화 부분으로 보내도록 했다. 자바 개발자와 아키텍트 역할을 하는 팀원들이 있어서 큰 문제없이 진행됐으나, 학습에 필요한 데이터 수집을 수동으로 진행해 시간이 많이 걸리고 데이터 양도 적어서 이 부분은 향후 개선의 여지가 있음을 실감했다. 사실 프로젝트 구상 단계 에서는 단순히 텍스트 매칭를 통해 결함 정보 여부를 판단하려 했으나, 우연히 접하게 된 사이트에서 MLlib에 대해 알게 되어 시도해 보았다. THE OUTCOME 짧은 시간이었지만 모든 조원들이 일요일 새벽까지 프로젝트에 적극적으로 참여해 좋을 결과를 얻은 것에 만족한다. 다만 아쉬운 점은 충분한 학습 데이터 수집을 통한 머신러닝 모델의 정확도를 개선할 필요가 있다는 점이다. 특히 언어별 충분 한 학습 데이터를 만들어 영어 외에도 대응이 필요함을 실감했다.[기술10기] 소셜 오피니언 실시간 모니터링 Alert 시스템
잘못된 소셜 오피니언 바로잡기
트위터나 페이스북 혹은 인스타그램 등의 소셜 미디어를 통해 자신의 의견을 가감없이 표현하는 사람들이 많아지고 있다. 소셜 미디어의 특성상 확산 및 전파 속도는 매우 빠르며, 트렌드 리더나 에반젤리스트, 얼리어댑터 소셜 오피니언의 파급 력은 매우 크다.
기업이나 제조사의 입장에서는 고객의 소셜 미디어를 통한 자사 제품에 대한 의견에 주목할 수밖에 없다. 그런데 대기업 이 아닌 중소기업이나 스타트업의 경우에는 제품이나 서비스에 대한 고객의 소셜 오피니언을 모니터링 하기가 쉽지 않은 것이 현실이다. 이에 오픈소스인 하둡 에코시스템을 통해 소셜 미디어상의 자사 제품에 대한 의견을 실시간으로 수집해 문제가 될 만한 소셜 오피니언을 경고해 주는 프로젝트를 구상하게 됐다.
제품에 대한 고객 의견이 소셜 미디어에 올라오면 적극적으로 잘못을 바로 잡고, 정말 제품의 문제라면 빠른 패치나 조기 대응을 통해 적극적인 고객과의 소통을 이룰 수 있는 기반을 마련함으로써 기업의 이미지나 브랜드 인지도를 제고할 수 있을 것이다.
처음에는 프로젝트의 뼈대를 잡는 아키텍처를 수립하는 데 많은 대화를 나누었다. 아키텍처를 수립하는 기본이 되는 원칙 은 최대한 심플하게 구성하자는 것이었다. 하둡 에코시스템의 특성상 다양한 시스템이 유기적으로 맞물려 작업이 수행되 는데, 관리 포인트도 함께 증가하게 되는 문제가 있어 최대한 스파크(Spark: 인메모리 분석 프레임워크) 하나로 해결하려 고 노력했다.
스파크의 장점은 여러 다양한 모듈을 가지고 있어 프로젝트 진행시 다른 하둡 에코시스템을 필요로 하지 않는다는 점이 다. 참고할 만한 내용이 거의 없어 구현하는데 어려움이 많다는 단점이 있음에도 우리는 스파크 사이트의 API 문서와 샘플 예제와 씨름하면서 머리를 뜯어가며 코딩을 해 나갔다.
소프트웨어 개발자라면 잘 알 것이다. 이것 저것 해봐도 안되는 기능이 결국 구현되어 동작할 때의 희열을 말이다. 우리는 그런 기쁨을 만끽하며 한편으로는 프로젝트의 동시 진행을 위해 수집기, 분석기, 시각화 모듈로 나누고, 병렬로 진행을 했 다. 팀원간 커뮤니케이션은 모바일 커뮤니티를 만들어 진행 사항과 이슈 사항을 서로 공유했다.
기계학습 모델까지 수용 ‘해 볼 만한 도전’
머신러닝 모델을 만들기 위한 수집 대상 은 트위터로 정했고, 아이폰과 갤럭시라 는 단어가 언급된 트윗을 수집해 학습 데 이터를 만들었다. 학습 데이터는 일일이 수작업으로 진행했는데, topsy.com에서 관련 트윗을 조회해 수집, 분류했다.
사실 초기 구상 당시에는 머신러닝을 포 함시키지 않았지만 단순히 텍스트 매칭 방식으로 결함의견 여부를 판단하는 것 은 실용적이지 못한 방식이라고 판단했 다. 여기에 Spark MLlib에서 쉽게 텍스 트를 분류(Text Classification)해주는 Naive Bayes 모델에 대해 알게 되면서 조원들 간에 ‘한번 해 볼만 하다’는 공감대가 형성되어 추가한 것이다. 학습 데이터 수집에 대한 부담이 상당하므로, 모델을 생성하고 활용하는 기능을 구현하는 것과 학습 데이터 수집의 역할을 분리해 진 행했다.
트위터에 올려진 트윗 내용을 하나씩 보면서 제품에 대한 긍정적인 문장과 결함으로 추정되는 부정적인 문장을 아이체킹 을 통해 하나씩 엑셀에 정리해 나갔다. 예상했던 대로 이 부분을 수작업으로 진행하다 보니 진척도 더디고, 기계학습 데이터 양이 절대적으로 적어서 모델의 정확도에도 영향을 미쳤다. 머신러닝의 모델을 만들 때 학습 데이터를 어떻게 만드는가가 핵심이라는 것을 프로젝트 말미에 깨달았다.
세 파트로 나눠 팀원 간 독립작업 수행
머신러닝 모델은 사전에 학습 데이터를 통해 생성했고, 모델을 수시로 갱신할 수 있도록 모델을 재생성해 실행하는 쉘스 크립트를 서버에 두어 필요시 구동할 수 있도록 했다. 스파크 스트리밍에서 데이터를 수신하는 부분과 모델을 호출해 분 석을 수행하는 부분, 결과를 MySQL에 전송하는 부분은 각각 인터페이스를 정의해 부분별 개발 팀원간에 독립적인 작업 이 가능토록 했다.
시각화 부분은 MySQL과 Tomcat, Java와 HTML을 활용해 구성했다. 데이터베이스로 HDFS를 사용할 것인지 MySQL 을 사용할 것인지에 대해 논의가 있었으나, 추가 설치에 대한 부담은 있더라도 단순 조회 속도는 더 빠를 것으로 보이는 MySQL을 선정했다.
데이터 구조는 최대한 단순히 설계하되 세 가지 통계 차트를 구현해 무엇을 보여주고자 하는지 정확 히 전달하고자 했다. 스파크 스트리밍에서 MySQL로 데이터를 전송할 수 있는 인터페이스를 만들어 활용했고, HTML에서 는 AJAX를 활용해 2초마다 데이터를 갱신토록 했다.
학습 데이터 부족 문제는 향후 개선과제로
생소한 자료 구조도 문제지만, 학습 데이터가 부족한 상황에서 개발을 하다 보니 분석 결과에 대한 검증이 불가능했다. 향 후 프로젝트에서 머신러닝을 도입하고자 할 때에는 학습 데이터를 확보할 수 있는지 여부가 가장 중요하다는 것을 알게 됐다.
시각화를 구성하며 HTML/JS로 구현하는 것이 빠르게 개발할 수 있다는 장점이 있지만 일반적인 HTML으로 구현시 푸시 방식으로 데이터를 전달할 수 없어 냉정한 의미에서 실시간 조회가 아니라는 점이 한계였다. HTML5가 등장하며 푸시가 가능한 웹 소켓이 소개됐다는 것을 알고 있으나, 이번 프로젝트에 적용해보지 못해 아쉽다. 실시간으로 웹 상에서 정보를 조회할 수 있다는 것은 스파크 스트리밍 등 실시간 플랫폼을 기반으로 하는 시스템에서는 커다란 장점임에 틀림없다.
다른 조들과 마찬가지로 우리 역시 주중에 프로젝트에 많은 시간을 내는 것이 어려웠다. 지방에 근무하는 팀원도 있어 잦 은 미팅은 사실상 불가능했다. 때문에 아키텍처 설계 단계부터 역할 배분을 고려해 절차와 구성을 설계하고, 인터페이스 를 명확히 하는 것을 염두에 두었다. 다행히 수집, 분석, 시각화로 데이터 흐름이 명확해졌고 각 단계별로 활용하는 도구가 구분되어 있어 개발 업무를 동시에 진행하는 것은 어렵지 않았다. 주말에만 모여서 작업하는 것을 원칙으로 하되 원활한 커뮤니케이션을 위해 모바일에 문의사항 및 진행사항을 공유했다.
이번 빅데이터 프로젝트를 완료하며 무엇보다도 자발적으로 헌신해 주신 조원 모든 분들께 감사의 말씀을 드리고, 이번 프로젝트를 계기로 모두들 한 단계 성장했음을 느꼈을 것이다. 각자 스스로 동기를 부여하고 즐겁게 프로젝트를 수행하면 서 서로가 희생한 것이 긍정적인 영향을 미쳐 좋을 결과가 되지 않았나 생각된다.
빅데이터 관련 기술이 더 많이 보급되어 우리가 사는 세상을 더 스마트하게 하고, 평등하게 하는데 일조했으면 한다. 더불 어 오픈소스 IT 솔루션을 통해 한국 사회에서 여러 모로 열악한 중견, 중소업체들이 글로벌 강소 중소기업들로 업그레이드 되기를 바란다.