Markov logic network을 Apple Siri에 적용하는 아이디어

출퇴근 시간에 자주 방문하는 Datanami라는 블로그가 있다. 여기 pabii처럼 수준 낮은 블로그가 아니라, 기자가 직접 발로 뛰면서 신기술을 최대한 자세하게 설명하는 블로그라서 항상 기대를 갖고 새 글을 기다리는 곳이다.

지난번에는 Markov Logic Network (MLN)라는 DB 설계 & 처리 구조에 활용되는 컨셉을 설명하는 본 적이 있는데, 처음 저 개념이 나왔던 2006년부터 지금까지 다양한 연구가 이뤄졌고, 실제로 쓰이는 곳도 엄청나게 많아졌다. 저 아래에 소개하는 Apple의 Siri에 적용하는 아이디어, 배터리 활용 최적화, RAM 활용 최적화 등등 다양한 곳에서 저런 개념이 활용되고 있는데, 정작 MLN 이라는 용어를 알고 제대로 이해하는 사람들은 극소수인 것 같아서 필자의 짧은 이해를 공유해보고자 한다.

모델을 이해하기 위해서는 먼저 MLN의 핵심 개념인 Markovian information structure을 이해해야 한다. Markov 라는 수학자가 만든 이 컨셉을 제대로 이해못하는 분들을 위해서 애시당초 Markov process라는게 무슨 뜻이고, 어디에 쓰이는지 최대한 수식 없이 간단히 정리해보겠다. (어찌됐건 필자의 박사 전공에서 쓴 시뮬레이션을 한 마디로 요약 정리하면 Markovian Programming이다.)

 

Markov (information) process

주식 가격을 생각해보자. 오늘 주가가 10,000원인데, 어제 12,000원에서 오늘 10,000원으로 떨어진 경우와, 어제 8,000원이었는데 오늘 10,000원으로 오른 경우를 놓고 볼 때, 상승 모멘텀과 하락 모멘텀이 과연 내일 주가에 어떤 영향을 미칠까? Markov process는 과거 주가의 움직임을 바탕으로 오늘 주가가 x원이 될 때, 이미 내일 얼마가 될지에 대한 모든 정보가 그 x원에 담겨있다는 가정에서 출발한다. 말을 바꾸면, 하락 모멘텀으로 or 상승 모멘텀에 관계없이 오늘 10,000원이 되는 순간, 내일 y원이 될 가능성이 a%, z원이 될 가능성이 b%로 결정된다는 뜻이다. (학문적으로는 History independent라고 표현한다 – 물론 상식적으로 좀 받아들이기 힘든 가정일 수 있는데, 수학 모델링은 이렇게 단순한데서 시작해서 복잡한 걸 집어넣는거다.)

(Source: Wikipedia)

위의 그래프를 보면, 이 전에 Bear market이었건, Bull market이었건 상관없이, 오늘 주식 시장이 Stagnant market이었다면 내일 Bear가 될 확률은 40%, Bull이 될 확률을 2%가 된다. (나머지 58%가 그대로 Stagnant에 머물러 있는 확률이라고 생각하면 된다. 다른 경우의 수가 없으니까.)

참고로 증권사 퀀트들이 파생상품 모델링을 할 때 위의 Markov process에 기반한 Brownian motion (주가 수익률이 정규분포)과 Poisson (주가 수익률이 포아송분포) 을 섞어서 가격을 계산한다. 그리고 MCMC (Markov Chain Monte Carlo) Simulation이라는 건 이런 Markov process로 된 특정 데이터 셋에 나올 수 있는 모든 경우를 다 살펴보는 방식으로 시뮬레이션을 해 보는 걸 말한다. 그렇게 가능한 조합을 다 뽑아내면, 주가가 x원에서 출발해서 1주일 후에 y원이 될 확률이 얼마인지 계산할 수 있다는 개념이다.

물론 주가에 모멘텀이 없다고 가정하는 모델링이 완벽하다고 생각하진 않는다. 실제로 모멘텀이 나타나는 걸 증명한 사례도 많고, 그걸 저런 기본형 모델에 추가하는 작업이 모델 변형의 출발점이라고 생각하면 된다. 필자의 박사 시절 연구 중 한 분야는 기습적인 주가 대폭락을 Poisson 분포로 모형화한 다음, 그 원인이 될 만한 내용이 변하면 Poisson 분포 형태가 어떻게 변하는지, 그 때 금융시장에 어떤 영향을 미치는지를 살펴보는 것이었다.

뭔가 복잡하게 써놨지만, 요지는 간단하다. 랜덤 분포에서 과거 값은 아무 소용없고, 현재 값이 모든 미래의 가능성을 결정한다는 수학 개념이라고 보면 된다. MLN에서 쓰이는 부분은 Bull – Stagnant – Bear market 간 서로 확률적으로 연결된 고리를 네트워크로 바꾸고, 그 네트워크를 데이터 처리 작업에 적용했다고 보면 된다. 그런 연결 고리를 만드는게, 특히 확률적인 연결 고리를 만드는게 도대체 어떻게 DB 설계, 데이터 처리에 도움이 되냐고?

 

Markov Logic Networks (MLN)

MLN의 포인트는 확률로 가능성을 구분하는 아이디어를 Network으로 그리고, 그걸 데이터 베이스 Join하는데 적용하는 부분에 있다. 데이터로 XYZ같은 작업을 해야 인공지능이라는게 나온다는 건 이미 다 알고 있을 것이고, 결국 데이터로 내 목적에 맞는 모델링을 하기 위해서는 회사 DB에 있는 데이터 중 일부를 뽑아서 정리를 해야한다. 보통은 DB하나 안에 여러개의 Table이 있고, 내가 원하는 데이터는 몇 개의 Table을 겹치는 작업 (Join)을 해야 뽑아낼 수 있다. (그래서 Data Scientist의 필수 스킬 중 하나가 SQL인 것이다.)

그런데 이런 Join 작업이 사실 굉장히 시간 낭비인 경우가 많다. 데이터 테이블이 커질수록 Join에 시간이 많이 걸리는 것은 당연한 일이고, 메모리 상에서 두 개 이상의 테이블을 모두 불러와 매칭 시켜야되기 때문에 필요한 하드웨어적 계산 비용이 기하급수적으로 증가할 수 밖에 없다.

(Source: Wikipedia)

위의 그림을 보자. D 테이블에 있는 데이터를 이용해서 A-B 그룹과 E-C 그룹을 묶는게 Join 작업의 요지다. 실제 이뤄지는 작업은 A-B, A-D, B-D 이렇게 3개의 연결을 묶어서 A-B-D 를 잇는 대형 테이블을 메모리에 얹은 다음, A-B-D와 E를 잇고, A-B-D-E에서 다시 C를 잇는 작업을 진행한다. 당연하겠지만 이렇게 여러개의 테이블을 묶는 작업을 하면 계산 비용 or 작업 비용이 엄청나게 클 것이다.

좀 더 기발하게 처리할 수 있는 방법은 없을까?

일단 그림에서 A, B, C, D, E를 빼놓고 단순하게 5개의 동일한 동그라미가 연결된 상태라고 생각해보자. Network Theory에서 봤던 걸 떠올리면 된다. 이 때 어느 Node가 더 연결이 강하고, 어느 Node가 더 연결이 약한지는 그 Node에 얹혀있는 가중치 값들로 결정된다. (인스타그램 알고리즘 설명 포스팅 참조)

똑같은 컨셉으로 데이터 테이블을 묶는다고 생각해보자. 어떤 테이블들은 강하게 묶여야할만큼 교차점이 많고, 또 어떤 테이블들은 연결고리가 느슨할 수도 있다. 또 여러개의 테이블들이 같이 묶여야 유의미한 거대 테이블을 만들어 낼 수 있는 경우도 있다. (인스타그램 알고리즘 설명 포스팅에서에서 Shapley value 설명 참조) 새롭게 추가되는 데이터가 있다면 Node간 가중치가 바뀔수도 있고, 심지어는 Node가 새로 추가될 수도 있다.

다시 A, B, C, D, E를 불러들이자. 위의 그림만 놓고보면 왜 단순하게 테이블들을 하나하나 연결하는 작업을 하는지 답답함이 생길 수 밖에 없다. 위에서 보면 D가 가운데에 있고, A-B-D는 서로 묶여 있는 구조가 보이기 때문이다. 저 작업을 하는 기존 시스템은 그런 그림은 없고, 단순하게 A-B, A-D, B-D… 순서로 데이터 테이블들을 연결시켜 나갈 뿐이다. 이런 답답함에 대한 해결책은 바로 “위에서 내려다보는” 구조를 도입하면 된다. 어떻게? 데이터를 단순하게 테이블에 저장시켜놓고 끝나는게 아니라, 테이블 네트워크의 Node와 가중치를 먼저 계산해서 네트워크 구조를 이용한 Join 작업을 실행하면 된다.

말은 쉽지, 실제로 쉽게 적용될 수 있나? 당연히 Network를 먼저 계산해서 완성하는 작업이 더 무거운 계산일 수도 있기 때문에 모든 경우에 적용할 수는 없다. 이런 작업이 실이득이 있는 경우는 당연히 Join 구조가 복잡한 대용량 데이터 밖에 없을 것이다.

 

실무 활용 – Apple’s Siri

어디에 비슷한 아이디어가 적용된 곳이 있을라나 싶어서 검색해보니 Apple의 Siri가 데이터를 처리하는 방식이 딱 위의 MLN이라고 한다. 링크건 글에 자세한 내용을 못 찾아서 Siri의 서비스 구조를 보고 역추적을 해 봤다. 어차피 음성을 처리해서 유사한 파트를 찾아서 매칭하는 작업을 하는 음성인식 챗봇이 모두 LSTM (Long-Short Term Memory)이다. 따라서 특정 시퀀스로 바뀌는 단어의 조합이 다른 조합보다 더 자주 나타난다는 걸 매칭하려는 작업에 가능성의 조합을 모두 다 따질 수는 없으니까, 효율적으로 조합을 따지기 위해서 새로운 단어가 더 입력될 때마다 매칭하는 문장 셋이 들어간 DB의 크기를 팍팍 줄여나가는 작업에 쓰이면 딱 좋겠다 싶었다.

(Source: Apple)

좀 더 쉽게 설명하면, 문맥/현재 작업에 맞춰 전체 DB에 있는 문장 중 일부만 뽑아놓고 “답장 대기 중” 상태로 있다가, 이번 문장에 나오는 단어들을 보고 답장을 위한 Table 결합체 (Join으로 만든 Table)를 작은 크기로 & 빠른 속도로 찾아내는 작업이라고 보면 된다.

Apple의 Siri처럼 실시간으로 수천만명의 유저 로그가 쌓이고 필요한 답장, 답변, 작업의 종류가 다양하다면 이런식으로 확률 게임을 해서 작업을 최대한 효율적으로 진행하는 아이디어는 시스템 속도 향상 + 자원 배분 효율화에 엄청나게 큰 솔루션이 될 수 있다.

같은 아이디어를 배터리 활용 최적화, RAM 관리 최적화에도 그대로 적용할 수 있다. 안드로이드 스마트폰을 쓰는 유저들은 폰 사용 초반에는 버벅거림을 느끼다가, 시간이 지나면서 버벅거림이 사라지는 걸 느낄 것이다. (물론 아주 많은 시간이 지나고나면 재부팅, 초기화를 시켜줘야할만큼 느려지는 건 “쓰레기”가 많이 쌓여서 그런거다 ㅋ) 실제로 유저들의 사용 패턴을 보고 자주 활용하는 앱들을 백그라운드에 그냥 띄워놓는게 아니라, 시스템 자원에 쉽게 로드될 수 있도록 pre-load 상태로 두고 있고, 이런 방식으로 백그라운드에 있는 앱들에게 주는 RAM이나 전력 값을 적절하게 배분할 수 있게 된다. 사용자 입장에서는 간단해보이는 배터리 최적화지만 뒤에서는 이런 수학적인 개념이 활용되고 있는 것이다.

알려진 인공지능이라는게 결국 데이터 매칭 작업이라는 걸 이해하고 나면, 새로운 데이터 관리 방법이 어떤 방식으로 쓰이게 될지 곰곰히 따져보는 것도 그렇게 어려운 일이 아니게 된다.

 

나가며 – 한국 블로거 vs. 실리콘 밸리 블로거

비전문가의 블로그 임에도 Datanami를 즐겨 읽는 이유 중 첫번째로 집필진의 이해도를 꼽는다. 정식 신문사 기자도 아니고 단순 블로거 팀인데 딥러닝이 머신러닝의 여러 테크닉 중 하나라는 인식, 인공지능은 데이터 기반의 자동화라는 인식, 기술 이해를 위한 적절한 수학 지식 등등, 데이터 사이언스 주제로 글을 쓸 수 있는 내공을 단단히 갖추고 있더라. 보통 한국의 여느 신문기사나 블로그를 읽으면 디테일이 틀렸거나, 이해도가 엉망인채 Buzzword만 여러번 나열했다는 느낌을 받는 경우가 많은데, Datanami에서 그런 경험을 하는 경우는 매우 드물다. (필자의 포스팅 중에 한국의 한심한 실태에 대한 지적질이 절반을 넘는게 좋은 예시다.)

처음에는 가까이 지내는 기자 친구들한테 추천해줬던 블로그인데, 다들 뭔말인지 하나도 모르겠다고 다시 한국말로 풀어서 설명해달라고들 불평하는 경우가 잦았다. (실제로는 어설프게나마 한국말 번역 페이지도 있는데 말이다ㅋㅋ 정확하게는 한국말이 아니라 비수학적 용어를 써달라는 뜻이겠지.) 블로그 수준이 높으니 이해를 못하는건 백보 양보해서 받아들일 수 있지만, 그래도 한국에서 관련 기사나 블로그 글을 쓰시는 분들께 간곡하게 부탁드리고 싶다. 그냥 베껴쓰기 하지말고, 제발 좀 이해하고 쓰시라고. 정말 모르겠으면 주변에 잘 아는 사람들한테 물어보고 난 다음에 써주시면 안 될까? 잘 아는 사람들이 그렇게 없나? 영어권의 어느 블로거보다 더 저질의 지식을 가진 한국 메이져 신문사 기자의 글을 보는 것, 그 글에 지인의 이름이 실린 걸 보는 것, 그런 글 내용의 사실 관계를 확인해달라는 요청을 받는 것, 그 정도 수준의 외부 관계자를 만나는 것도 지겹고, 또 괴로운 일이다.

필자의 사업 모델을 한국 VC들에게 이야기하면 뭔 말인지 모르겠다는 표정이거나, “뭔가 될 것 같은데, 뭔 말인지는 잘 모르겠네요. 일단 인공지능 쓰는거죠?”라는 얕은 지식 수준을 스스로 드러내는 경우가 많다. 얼마전에 실리콘 밸리에서 좀 이름있는 VC 한 분과 연락이 닿아 비지니스 모델을 설명했더니, “안드로이드 시스템은 어떻게 뚫는다치고, 그런 메가 데이터용 DB는 어떻게 설계했습니까? 모델링쪽 내공은 이해가 되는데, 그정도 실시간 대용량 데이터 처리하는 DB 셋팅 하실 Data Engineering 실력은 없는 것 같은데요?” 라고 묻더라. 사업 시작하고 지금까지 만난 VC들에게서 받은 가장 날카로운 질문이었다. 내가 이래서 CTO 뽑거든.

한국이어서, 실리콘 밸리여서 수준이 다른걸까? 글쎄… 요즘은 정말 “왜 한국은 2류일까?” 라는 글에서 말했던 한국 비지니스 업계 평균의 지식 수준과 지식을 얻으려는 노력 수준 자체에 대한한 의구심이 더 많아지고 있는 것 같다. 코드나 베껴서 빨리빨리 (Read 대충대충 or 그럴듯하게)만 생각하는 그들에게 무슨…..