예측 모델을 이용한 서비스 개발 시 알아야할 것들 #2
데이터 조사 및 탐사 분석
2. 데이터 조사 및 탐사 분석
예측 대상과 목표가 정해지면 이제 목표를 달성하는데 필요한 데이터가 충분한지 조사해야 합니다. 이 때 충분하냐의 의미는 단순히 데이터의 양을 의미하는 것이 아닙니다. 데이터에 포함된 정보의 질이 중요합니다. 가령, 내일의 주가를 예측하기 위해 내가 사용할 수 있는 데이터가 과거 주가 정보 밖에 없다면 이게 1년치가 되었든 100년치가 되었든 불가능한 임무이므로 과감히 포기해야 합니다. 간혹 'LSTM으로 주가 예측을 하려는데 어떻게 해야 할까요?' 류의 질문들이 커뮤니티에 올라오곤 하는데 연습용으로 해볼수는 있겠으나 실용적으로 보면 쓸데없는 짓입니다. 주가는 random walk 이며 과거의 시계열 정보 만을 이용해서 미래의 random walk 를 예측하는 것은 불가능합니다. 이렇게 이론적으로만 판단하기 어려운 경우도 있습니다. 이런 경우 필요한 것이 분석가와 도메인 전문가의 경험과 지식입니다.
특히, '예측'의 의미가 무엇인지 명확히 이해하는 것이 필요합니다. 많은 사람들이 데이터 분야에서 얘기하는 '예측'의 의미를 오해합니다. 데이터 분야에서 얘기하는 '예측'은 알 수 없는 미래의 사건을 예견하는 것과는 다릅니다. 예측 모델링은 사실 상 조건부 확률 혹은 조건부 기대값을 계산하는 행위입니다. 다시 말해, 앞으로 어떤 상황이 주어지면 해당 상황과 최대한 비슷했던 과거 사례들의 평균치를 대입하겠다는 뜻입니다 (약간 다른 관점에서 보자면, 예측은 수학 분야에서 얘기하는 '내삽 (interploation)' 의 일종이라고 생각할 수도 있습니다). 그런데 예측의 의미를 오해하면 필요한 데이터를 검토하는 과정에서 잘못 판단할 수 있습니다.
몇 년 전 회사에서 시스템 운영팀장님 한 분이 조언을 구한 적이 있습니다. '블레이드 앤 소울'이란 게임의 약 5년 치 서버 모니터링 데이터가 있는데 이 데이터를 이용해서 앞으로 나올 신규 게임 (리니지M 이었던 걸로 기억함) 운영에 필요한 CPU 코어나 메모리 등을 예측할 수 없겠느냐는 것이었습니다. 만약 정확한 예측이 가능하다면 예산 계획을 세울 때도 도움이 될 뿐더러 클라우드 서비스 같은 임대 서비스를 이용할 때 장기 계약을 통해 좀 더 저렴한 비용으로 계약할 수 있기 때문에 회사 입장에서는 투자/운영 비용을 효율화하는데 매우 유리한 상황이었습니다.
이 경우 예측 대상 (신규 게임의 론칭 후 최소 1년간 시스템 사용량) 과 목표 (필요 리소스를 예측하여 투자/운영 비용 감축하기) 는 비교적 잘 정의됩니다. 또한 얼핏 생각하기에 과거 5년 동안 수백 대의 서버에서 측정된 CPU, 메모리 등의 다양한 리소스 사용량 모니터링 데이터는 예측 목표를 달성하기에 충분한 데이터인 것 같습니다.
그러나 조건부 기대값 혹은 내삽의 관점에서 보면 이 데이터는 예측 모델링을 위해 충분한 데이터가 아닙니다. 이해를 돕기 위해 보유한 데이터와 예측 대상을 가상의 표로 표현하면 다음과 같습니다 (A항목은 블레이드 앤 소울에서 측정된 일별 리소스 사용량, B 항목은 앞으로 예측해야 하는 리니지M의 리소스 사용량을 의미합니다).
날짜 A B
1일차 100 ?
2일차 95 ?
3일차 90 ?
4일차 88 ?
5일차 80 ?
... (약 1800개의 행이 뒤에 더 있음)
이제 데이터에서 부족한 점이 무엇인지 보이시나요? 단순히 생각하면 리니지M의 예상 리소스 사용량을 예측하기 위해 충분한 (약 5년 치의) 데이터가 있는 것처럼 보입니다. 그러나 조건부 기대값을 구한다는 관점에서 생각해 보면, B항목의 1일차 값을 예측하기 위해 주어진 (동일 조건의) 정보는 동일한 행에 있는 A항목의 100이라는 데이터 하나밖에 없습니다. 이 상황에서는 기계 학습을 이용해서 예측 모델을 만드는 시도를 해선 안됩니다. 최소한 다른 다양한 게임들의 리소스 사용량 데이터를 더 확보해야 합니다. 즉, 아래와 같은 표가 만들어질 수 있어야 합니다.
날짜 A B C D E ...
1일차 100 ? 80 94 99 ...
2일차 95 ? 82 90 88 ...
3일차 90 ? 78 85 80 ...
4일차 88 ? 75 80 83 ...
5일차 80 ? 70 79 80 ...
...
위와 같은 데이터가 있다면 각 열에 해당하는 게임의 특성(장르, 론칭 시기, 타겟 유저층 등등)을 이용해서 B 게임에 대한 예상 리소스를 예측할 수 있습니다. 물론 이렇게 데이터가 마련되더라도 정확한 예측은 쉽지 않지만 적어도 풀어볼 만한 문제는 되는 것이죠. 예를 들어 중국의 텐센트 같은 경우 매번 출시를 앞둔 게임에 대해 매출이나 성공 가능성에 대한 예측을 하는데 이건 이미 수백 개의 게임을 운영한 경험과 데이터를 보유하고 있기 때문에 가능한 일입니다.
한편, 경험과 지식만으로 데이터가 충분한지 판단을 하기 어려운 상황도 있습니다. 이런 경우 필요한 것이 탐사 분석입니다. 흔히 탐사 분석이라고 하면 데이터 모델링 단계에서 데이터의 특성을 파악하는 작업으로 생각합니다. 하지만 서비스를 개발할 때에는 프로젝트의 가능성을 검토하는 일종의 PoC (Proof of Concept) 역할도 합니다.
이런 목적의 탐사 분석을 할 때에는 과도한 노력을 투입하지 않도록 주의해야 합니다. 많은 분석가들이 초반 탐사 분석 단계에서 너무 깊이 들어가는 바람에 길을 잃곤 합니다. 때론 데이터를 샅샅이 훑어 보는 대신 아주 간단한 예측 모델을 시도해 보는 것만으로도 충분한 경우도 있습니다. 그 동안의 제 경험 상 실제 데이터가 충분한 정보를 담고 있는 경우, 아주 간단한 모델링 만으로도 어느 정도 좋은 결과가 나옵니다. 이 단계에서 형편없는 결과가 나오는데 복잡한 전처리 작업과 최신 알고리즘을 적용한다고 갑자기 예측이 잘 되는 경우는 극히 드뭅니다. 오히려 첫 시도에서 꽤 나쁘지 않은 성능이 나왔는데, 그 이후에 여러 가지 튜닝을 해도 잘 개선이 안 되는 경우가 더 빈번합니다.
예전에 엔드포인트라는 보안 솔루션에서 남기는 로그 데이터를 이용해서 비정상 활동을 탐지하는 서비스를 만드는 것이 가능한지에 대한 컨셉 검증 목적의 탐사 분석을 한 적이 있습니다. 이를 위해 Doc2Vec 을 써서 간단한 임베딩 모델을 만든 후, 모델을 통해 생성되는 임베딩 벡터들을 이용해서 각 PC 사용자들을 구분할 수 있는지 그리고 동일 PC 에서도 근무 패턴이 바뀐 시점 전후를 감지할 수 있는지 검증하는 실험을 진행했습니다. 실험 결과 시스템 보안 로그를 이용하면 PC 사용자의 평소 사용 패턴을 어느 정도는 구분이 가능하다는 점을 확인할 수 있었습니다. 이를 위해 저희가 투입한 자원은 실원 10여명의 PC 에서 생성되는 몇 주치의 보안 로그와 한 명의 분석가였습니다. 비록 다른 이유로 인해 이 프로젝트를 더 진행하지는 않았지만, 아마 이 탐사 분석 단계에서 모델 결과가 안좋게 나왔어도 프로젝트를 조기에 멈췄겠죠.
더 나아가 확보 가능한 다른 데이터는 없는지 조사하는 것이 필요합니다. 많은 AI 전공자들이 어떤 모델링 알고리즘을 사용할지에 집중하느라 확보할 수 있는 데이터가 뭐가 있는지에 대한 고민은 상대적으로 소홀한 경우가 많습니다.
2008년에 크리스 앤더슨은 '이론의 종말 (end of theroy, https://www.wired.com/2008/06/pb-theory/)' 이라는 글에서 많은 데이터로 인해 이론(모델)이 쓸모없어지는 세상을 얘기했습니다. 다소 극단적이기에 많은 논란을 유발한 주장이었죠. 당연히 데이터가 넘쳐나는 현재에도 모델은 필요합니다. 하지만 여기에는 중요한 교훈이 있습니다. 좋은 데이터는 세련된 알고리즘을 대체할 수 있습니다.
(반드시 그런 것은 아니겠지만) 그 동안 제가 경험한 바에 의하면, 지금 보유한 데이터에 대해 나이브한 방법을 써서 적당히 괜찮은 (이를 테면 100점 만점에 70점 정도가 되는) 성능이 나오지 않는다면, 아무리 더 좋은 학습 알고리즘을 쓰더라도 서비스에 사용될 수준의 (100점 만점에 95점 이상이 되는) 좋은 모델을 만들 가능성은 대단히 낮습니다. 더 좋은 모델을 적용하겠답시고 최근 Arxiv 에 올라온 논문을 들여다 보기에 앞서 목표 수행에 적절한 데이터가 더 없는지 검토해야 합니다.
대체로 연구실에서는 모델링에 더 집중할 수밖에 없습니다. 데이터를 유연하게 확보하기 어렵기도 하고, 연구실 자체가 실용적인 문제보다는 좀 더 이론적인 문제에 도전하는 것이 일반적인 역할이기 때문이죠. 그러나 회사에서는 그렇지 않습니다.
물론 회사에서도 대개 예측 모델을 이용한 프로젝트를 시작할 때 이미 이러이러한 데이터를 이용해서 저러저러한 서비스를 만들어야 하는 상황이 주어집니다. 그렇다보니 우리는 무의식적으로 현재 보유한 데이터 내에서 어떻게든 데이터를 변형하거나 모델을 설계해서 목표에 끼워맞추려고 합니다. 하지만 조금만 시야를 돌려보면 회사에는 많은 유용한 데이터들이 숨어 있습니다. 실전 서비스는 캐글과 같은 경진대회와 달리 어떤 조건 내에서 문제를 해결해야 한다라는 제약이 그리 엄격하지 않기 때문에 이런 숨어있는 데이터를 찾는게 문제 해결에 중요한 역할을 합니다.
몇 년 전 모바일 광고 효과를 분석하는 프로젝트를 한 적이 있습니다. 당시 회사 마케팅팀의 고민 중 하나는 광고 어뷰징을 탐지하는 것이었습니다. 대개 모바일 광고는 광고 대행사를 통해 다양한 채널로 광고를 노출하고 광고를 통해 유입된 고객이 앱을 설치하거나 실행할 경우 건별 광고비를 지불하는 방식으로 진행됩니다. 광고 대행사에서는 쿠키나 추적 URL 혹은 앱에 설치된 모듈 등을 통해 고객이 유입되는 경로를 추적하고 이를 통해 광고비를 산정합니다.
그런데 광고 업체 중에서는 실제 고객이 앱을 설치하거나 실행하지 않았는데 마치 그런 것처럼 가짜 이벤트를 생성하는 방식으로 광고비를 부풀리는 경우가 있습니다. 이것을 광고 어뷰징이라고 부릅니다. 광고 어뷰징에는 여러 가지 방법들이 있는데, 당시에는 SDK spoofing 이라는 기법이 특히 심각한 문제였습니다. 비록 광고 대행사에서 어뷰징을 막기 위해 여러 가지 탐지 기법을 적용하고 있었지만 근절하기에는 한계가 있었습니다.
이런 상황에서 저희가 먼저했던 것은 정교한 탐지 모델링이 아니라 추가로 활용할 수 있는 데이터가 더 없는지 조사하는 것이였습니다. 그 동안 마케팅팀에서는 대행사에서 제공하는 광고 이벤트 로그만을 분석에 사용하고 있었지만, 저희는 그 동안 게임 서버나 클라이언트에서 생성되는 다양한 로그 데이터를 이미 분석에 활용하고 있었죠. 따라서 이런 데이터를 광고 어뷰징 탐지에 사용할 수 없을지 검토하였습니다.
마침 마케팅 광고 대행사를 통해 수집되는 이벤트 로그와 게임 서버에서 수집되는 로그를 매칭할 수 있는 정보를 찾아 보니, 게임 클라이언트에서 생성하는 로그 중에서 둘을 매칭할 수 있는 정보를 갖는 로그가 있었습니다. 광고 이벤트 로그에서는 각 사용자를 식별하기 위해 ADID 라는 키를 사용하는데, 이 클라이언트 로그에서는 ADID와 게임 계정 아이디를 같이 남기고 있었죠. 그래서 저희는 이 로그를 이용해 광고비가 집행된 ADID와 매칭되는 게임 계정이 실제 게임 활동을 수행하는지 추적할 수 있었습니다. 위에서 언급한 SDK spoofing 은 가짜 이벤트를 생성하기 때문에 광고 이벤트는 남더라도 게임 서버에서는 아무런 활동 정보가 남지 않는 점을 이용한 것이죠.
결국 광고 이벤트 로그와 게임 로그를 조인하는 SQL 쿼리와 몇 가지 데이터 집계만으로 상당량의 SDK spoofing 을 탐지할 수 있었고, 이를 통해 수 억원이 넘는 광고비를 절약할 수 있었습니다. 저희가 만약 광고 어뷰징 탐지를 위해 정교한 이상 탐지 기법을 만드는데 집중했다면 아마 기존에 광고 어뷰징을 탐지하는 전문 솔루션 업체가 하던 것보다 더 잘하지는 못했을 것입니다. 전문 업체에게는 오랜 기간 축적된 노하우가 있었지만 저희에게는 그들에게 없는 데이터가 있었습니다.
당시 저희가 했던 분석에 대해 좀 더 자세한 내용이 궁금하신 분은 https://danbi-ncsoft.github.io/works/2019/08/06/works-mobile_mkt-1.html 와 https://danbi-ncsoft.github.io/works/2019/08/19/works-mobile_mkt-2.html 를 읽어 보시기 바랍니다.
