NC

데이터 분석가들이 가장 선호하는 언어, R. 1편에서는 R의 특징과 인기 요인을 다뤘는데요.

2편에서는 엔씨소프트 데이터분석팀 이은조 팀장이 엔씨소프트에서 R을 실제로 사용해 데이터를 분석하는 과정을 설명해 드리도록 하겠습니다.  ( ͡° ͜ʖ ͡°)

엔씨소프트 데이터분석팀에서 진행하는 분석 프로젝트는 크게 1) 탐사 분석 2) 예측 모델링 3) 시스템 혹은 서비스 개발 단계로 나눌 수 있습니다.

1단계인 탐사 분석은 말 그대로 초기 분석 방향조차 정해지지 않은 단계에서 다양한 탐사를 위해, 혹은 예측 분석에 앞서 예측 대상이 갖고 있는 패턴이나 특징을 찾는 것이죠.

최근에 진행한 ‘진성 유저 지표 프로젝트’를 예로 들면, 진성 유저가 무엇인지 구체적인 기준을 정하기 위해 현재 유저들의 패턴이나 활동 현황을 탐사하는 과정이 이에 해당합니다.

각 유저들의 플레이 시간과 레벨, 주 활동 지역 등의 분포를 보거나 좀 더 복잡하게는 직업별, 레벨별 잔존율이나 ARPU(*유저 1명이 특정 기간 동안 지출한 평균 금액)를 비교하거나 반대로 ARPU별 레벨 분포나 주 활동 지역, 보유 아이템 등을 확인하는 등등이 모두 탐사 분석이죠.

과거에는 OLAP라는 시스템을 이용해서 탐사 분석을 했습니다. OLAP는 미리 다양한 분석 상황을 큐브 형태로 구축한 후 분석하는 시스템을 말합니다. 따라서 이 큐브에 들어갈 데이터마트(datamart)가 굉장히 잘 구축된 상황에서는 굉장히 효율적으로 작업을 할 수 있죠.

그래서 제조업이나 금융업처럼 도메인의 특성상 데이터 종류의 변화가 크지 않은 분야나, 비즈니스 변화가 빠르지 않았던 과거에는 데이터마트를 이용한 방법이 효과적이었죠.

하지만 지금처럼 변화가 빠른 시대, 특히나 게임처럼 몇 개월 단위로 대규모 콘텐츠 업데이트가 이뤄지는 분야에서는 탐사 분석 전에 모든 가능한 데이터를 OLAP로 구성해서 활용하는 건 현실적으로 불가능합니다.

예를 들어 엔씨소프트의 경우 매일 수백만 명의 유저에 대해 수십~수백 억 건의 로그 데이터를 이용해서 수백 개 이상의 통계 항목을 집계하고 있습니다. 그런데 만약 게임이 업데이트가 되면, 업데이트와 관련해 탐사가 필요한 모든 경우의 수에 대해 다시 수백만 명의 유저에 대한 큐브를 새롭게 만들어야 하죠.

아마 OLAP을 구축해본 DBA (DataBase Administration / 데이터베이스 관리자) 분들이라면 차원 테이블의 스키마(*DB에서 자료의 구조와 표현 방법, 자료 간의 관계를 형식 언어로 정의한 구조)가 변경될 때마다 OLAP을 재구성하느라 밤을 새본 경험이 한 두 번씩은 있을 것 같네요…

또 애로사항 중 하나는 데이터를 분석하는 사람과 데이터를 추출하는 사람이 분리돼 있는 경우가 많다는 거죠. 이럴 땐 아래와 같은 상황을 종종 볼 수 있습니다.

분석 담당자가 분석을 하다가 다른 데이터가 추가로 필요해서 추출 담당자에게 데이터를 추가로 요청한다 -> 추출 담당자가 전달한 데이터를 분석가가 확인 후 ‘어, 내가 요청한 거랑 데이터가 다르네? 다시 뽑아줘요’ -> 추출 담당자는 ‘님아, 요청을 애초에 제대로 했어야죠’ -> 그럼 분석가는 ‘아니 당신이 제대로 이해 못한 거잖아’ (무한반복)

위의 과정이 몇 번이고 반복되며 시간만 속절없이 흐르고…그럼 결국 ‘아놔 저 사람이랑 짜증나서 일 못 하겠네!’하며 ‘술이나 마시러 가자!’ 뭐 이렇게 되는 거죠.

이런 사태를 미연에 방지하기 위해, 데이터분석팀에서는 하둡(Hadoop/대용량 데이터 처리 기술)을 데이터웨어하우스(DW)로 운영할 수 있게 해주는 Hive라는 시스템을 이용해 분석가들이 데이터를 직접 추출하고 R에서 다양한 탐사 분석을 수행합니다.

처음엔 데이터 추출까지 해야 하니 일이 늘어난 것처럼 느껴질지 모르지만, 조금만 익숙해지면 오히려 불필요한 시행 착오를 줄일 수 있어 효과적일 뿐만 아니라 데이터에 대한 신뢰도가 높아져 정확한 분석이 가능합니다.

더 나아가 리눅스 명령어 라인 툴인 Bash shell도 활용하고 있죠. 분석가들이 좀 더 효율적으로 일하려면 서버에서 기본적인 데이터 처리 및 자동화를 직접 할 수 있어야 하기 때문입니다.

비록 최근에 다양하고 세련된 여러 가지 분석 솔루션들이 나오고 있지만, 효율성이나 유연성 측면에서 볼 때 아직까지는 Hive + Bash shell + R 조합을 능가하지는 못하는 것 같습니다(*물론 익숙하다는 전제 하예요).

또한 효과적인 탐사 분석을 위해서는 적절한 시각화가 매우 중요합니다. 앞서 언급했듯, R은 이런 데이터 시각화를 통한 탐사 분석에 아주 강력한 장점을 갖고 있어서 이 단계에서 가장 중요한 역할을 수행하죠.

탐사 분석을 통해 예측 대상 및 패턴이 어느 정도 파악되면 이제 예측 모델링을 진행합니다. 보통 데이터 마이닝 혹은 기계 학습이라고 하는 작업들이 여기에 해당하죠.

진성 유저 지표 프로젝트의 경우, 유저들을 유형별로 분류하기 위한 분류 모델을 만드는 작업입니다. R에는 다양한 데이터 마이닝 알고리즘이 있고, 사용법도 어렵지 않죠. 그래서 데이터분석팀에서는 예측 모델을 생성하고 그 성능을 측정하는 작업을 모두 R에서 수행합니다.

마지막으로 전 단계에서 만든 예측 모델을 실제 서비스에 적용할 수 있도록 서비스 개발에 돌입합니다.

진성 유저 지표 서비스를 예로 들자면, 먼저 유저들의 플레이 데이터를 예측 모델에서 사용할 수 있는 형태로 정제하는 데이터 전처리 모듈, 이 데이터로 각 유저들이 어떤 유형인지를 기계 학습을 통해 자동으로 분류하는 모듈, 분류 결과를 서비스하는 모듈을 만들게 되는데 이중 기계 학습 모듈을 R로 개발합니다.

R은 통계 분석용 도구이기도 하지만, 동시에 프로그래밍 언어이기 때문에 이렇게 시스템 모듈을 개발하는 것도 가능하죠. 특히 탐사 분석이나 예측 분석에서 사용한 코드를 상당 부분 재활용할 수 있는데, 이 점은 실전에서 큰 장점이 됩니다.

왜냐하면 분석가가 만든 코드를 개발자가 다시 포팅(*기존의 코드를 다른 컴퓨팅 환경에서 동작할 수 있도록 수정하는 것)할 필요가 없기 때문이죠. 포팅 과정에서 잘못 구현하거나 버그가 발생할 가능성이 크게 낮아지는 것은 물론이고요.

이렇듯 R은 단순히 시각화를 통한 탐사 분석이나 보고서에 쓸 차트를 그리는 용도뿐 아니라, 예측 모델을 만들고 이를 실전 서비스로 구현하는 데까지 전반적으로 활용되고 있습니다.

다음 편에서는 데이터 분석을 할 때 필요한 두 가지 요소에 대해 다뤄보도록 하겠습니다.