NDC Replay

유저동향분석 시스템 개발 노하우
김호연
넥슨
넥슨 라이브웹개발팀, 네오플 던파개발실 등에서 개발자로 근무했으며, 현재 넥슨 인프라기술팀에서 게임 유저 반응을 확인할 수 있는 시스템을 개발 중입니다.
유저동향분석시스템(14년 NDC 발표)을 발표하고 나서 많은 질문을 받았습니다.<br/> "네이버 카페는 어떻게 로그인 하나요?", "게시글의 실시간 수집은 어떻게 하나요?" 등등 자주 질문받은 내용을 토대로 실제 코드와 함께 유저보이스 시스템 개발에 대해 공유합니다. 그리고 여러 게임을 대상으로 유저동향분석 시스템을 새롭게 개발하면서 얻은 노하우와 서비스 경험, 현재 활용하고 있는 영역에 대해서 공유합니다.<br/>개발 언어는 Python을 사용하고, docker나 AWS(amazon web service) 등에 관한 내용이 있지만, 특별한 지식이 없어도 들을 수 있는 수준 입니다. <간단히 게시판 데이터 수집, 적재, 활용을 하고 싶거나, 텍스트 분석을 해서 어떻게 활용하는지 궁금하신 분들, 유저 동향을 어떤 방식으로 알아낼 수 있는지 궁금하신 분> 들이 청강하면 도움이 될 것입니다.
[새 창에서 슬라이드 보기]
안녕하세요. 지금부터 '유저 동향 분석 시스템 개발 노하우'라는 주제로 발표를 시작하겠습니다. 저는 넥슨 코리아 인프라 기술 팀에서 개발자로 근무하고 있고요. 김호연이라고 합니다. 2014년 NDC에는 쉽게 따라 할 수 있는 꽤 훌륭한 유저 동향 분석 시스템이라는 발표를 했었고요. 혹시 이 자리에 그때 그 발표를 들으신 분이 혹시 계신가요? 계시면 혹시 손을 한 번 들어봐 주시겠어요? 어유 거의 없네요 다행히. 그때 당시랑 약간 비슷한 내용이 있긴 한데 그때보다 좀 더 개발된 부분이 있어서 조금 더 추가된 부분이 있고 그때 당시에는 던전앤파이터라는 하나의 게임을 대상으로 유저 동향 분석 시스템을 개발하고 초기 버전을 공유를 해서 발표를 진행했었는데요. 지금은 넥슨에서 서비스하거나 개발하고 있는 모든 게임을 대상으로 유저 동향 분석 시스템을 개발을 하고 있고요. 시스템을 개발하고 나서 여러 사내 직원분들께 설명을 드리다 보니 그분들이 많이 질문하시는 것도 많고 개발적으로 궁금해하시는 분들도 많아서 이런 분들을 좀 취합해서 FAQ 형식으로 오늘 발표를 진행하려고 합니다. 그럼 발표를 본격적으로 시작하도록 하겠습니다.

작년 10월 말쯤 있었던 일입니다. 저는 평소처럼 출근을 해서 아주 성실하게 근무를 하고 있었습니다. 하하

갑자기 시스템에서 게시글 중에 핵이라는 단어를 포함하고 있는 게시물들이 급격히 증가하고 있다는 알림을 받았습니다.

게시글 제목들을 보면 여기 “핵 공유하는 곳 같은데” “핵인지 모르겠지만 일단 신고요.” “이거 핵 어떻게 하면 되나요?” 등등의 유저들의 조심스러운 반응이 시작되고요. 그리고 나서는 여기 보면 약간 강하게 "저는 끝까지 투쟁할 겁니다." 등등 약간 화남을 표시하는 유저들도 하나둘씩 생겨나기 시작합니다.

이런 이슈들이 계속되고 개발사에 문제 공유가 되고 나면은 긴급하게 패치를 진행하게 됩니다. 긴급 패치를 진행하고 나면 아주 잠시간의 평화가 찾아옵니다.

하지만 그것도 잠시 이번에는 뒤를 이어서 '튕', '팅' 관련, 게임 접속 불가에 대한 키워드들이 급격하게 증가하기 시작합니다.

이젠 튕기는 상황에 대한 게시글들이 올라오기 시작했습니다. “진짜 왜 팅기는지”, “튕김 현상이 왜 자꾸 벌어지는지”에 대한 문의들도 있고 중간에 보시면 “도서관 어뷰징 사용자 제재 관련 GM님 글 보라고 7번째 올리는 글” 이 게시글 내용을 보면은 실제 긴급 패치를 진행하고 나서 어떤 새로운 어뷰징 방식이 생겼는데 이런 것이 어떤 원리를 이용해서 어떤 버전 차이를 이용해서 사람들이 악용을 하고 있는지 사례를 설명하고 어떻게 획득할 수 있는지를 자세히 아주 적어놓은 글이었습니다. 그리고 “튕김, 크래시 문제/접속 불가 현상 해결책”이라는 게시글도 눈에 띄는 게시글 중 하나였습니다.

이렇게 긴 내용의 게시글이었는데요. 정말 세심하게 어떻게 대응하는지 핸드폰에 따라 해결 방법이 다른 부분에 대한 내용도 포함하고 있는 아주 유용한 게시글입니다.

아까 그 게시물 중 일부를 발췌해 보았습니다. 안드로이드에서 튕기는 문제를 해결하는 반면 특별히 노트 시리즈를 위한 방법을 따로 추가해 놓은 게시물입니다. 시작을 보면 집단지성의 힘을 보여주신 여러분들께 글 정리 및 링크만 했고 이론은 이렇습니다라고 쓰여있는데 이런 방법으로 대부분의 튕김 문제를 해결했다는 문구도 굉장히 중요합니다. 해결 방법을 추적해보면 역으로 문제의 원인을 떠올리거나 중요한 힌트가 되는 경우가 많기 때문에 노트 시리즈 같은 특정 기기에서만 벌어지는 현상에 대해 추적하기가 어려운 편인데 이럴 때 이런 게시글은 정말 여러 면에서 도움이 되는 게시물입니다.

제가 지난 발표 때 사용한 문구 중 하나인데요. 여전히 우리는 우리가 만든 게임에 대해 유저와 다른 생각을 가지고 있습니다. 위에서 사용한 게시물을 예로 보면 저런 집단 지성을 억지로 만들 수 없을 뿐만 아니라 “이렇게 하면 해결될 거야”라는 접근 방식도 개발자와 유저와 접근 방식, 생각 자체가 다릅니다. 이런 사례를 통해 우리는 생각보다 우리의 게임에 대해 유저가 더 많이 알고 있다는 점을 알 수 있습니다.

유저 동향 분석 시스템을 처음 만들었을 때는 던전앤파이터라는 게임 하나를 대상으로 만들었습니다. 국내에서 워낙 인기가 많은 게임이었고 여러 개의 커뮤니티를 가지고 있는 게임이었기 때문에 게시글을 한 번에 모아서 보는 기능에 집중했었습니다. 여러 게시판을 돌지 않아도 한 번에 검색되는 기능만으로도 사내 여러 조직에서 굉장히 유용한 기능이라고 판단을 했고 굉장한 인기를 많이 끌었습니다. 그러면서 저도 모르게 유저 동향 분석은 게시글이 꼭 많아야지만 유용하다라는 선입견을 가졌던 것 같습니다.

또 다른 하나의 착각은 모바일 게임은 게시글 양이 적다고 생각했던 점입니다. 저는 PC 온라인 게임을 지원하는 조직에 있는데 당연히 PC 온라인 게임을 대상으로 유저 동향 분석 시스템을 개발했고 PC 온라인 게임이 아시다시피 많은 수가 있지 않기 때문에 금방 모든 수의 PC 게임을 지원할 수 있게 되었습니다. 당연히 불안해지기 시작했고요. 다들 잘 알고 계시겠지만 PC 게임 출시와 모바일 게임 출시는 이제 비교도 안 될 정도로 양에서 많은 차이를 보이고 있습니다. 모바일 게임 커뮤니티를 수집, 시작하기 전까지도 의문이 많았습니다. 그런데 막상 수집을 알아보니 헝그리앱이라는 유명한 모바일 게임 전문 커뮤니티가 있고 네이버 카페도 요즘 SDK를 지원하면서 모바일 게임이 출시되면은 네이버 공식 카페를 만드는 게 무조건 당연한 일이 되어가고 있습니다. 결국 제 생각보다 모바일 게임 커뮤니티는 충분했습니다.

아까 처음에 핵 키워드가 갑자기 치솟았다고 설명한 그래프인데요. 아까는 가려져 있었지만 이 그래프의 수치를 살펴보면 평소에도 20개밖에 되지 않고 실제 핵 키워드가 치솟더라도 약 150개 정도밖에 되지 않는 것을 확인할 수 있습니다. 그래도 이게 문제라는 걸 확실히 알아볼 수 있는데요. 이 부분을 다른 게임과 비교해보면 

게시글 수가 많은 피파온라인이나 게시글 수가 적은 도미네이션즈나 결국 “평소 수량 대비 해당 키워드 수치가 급증했을 때 문제야”라고 판단되는 부분이기 때문에 ‘핵’, ‘팅’ 키워드에 대해 이슈가 생겼을 때 치솟는 이슈의 흐름은 유사합니다. 이는 게시글이 아주 많든 적든 최소 적당량의 게시글만 있다면 얼마든지 유용한 정보로 사용할 수 있다는 점을 보여줍니다.

결론은 요즘 엄청난 규모의 모바일 게임들이 출시를 하고 있는데 결국은 모바일 게임도 게시글을 수집하고 분석할만한 충분한 가치가 있다는 점입니다. 그럼 어떻게 하면 될까? 이게 바로 오늘의 주요 내용입니다.

첫 번째는 데이터 수집하기입니다. 시작이 반이라고 유저 동향 분석을 위해서는 데이터 수집이 시작이라고 할 수 있고 내용의 거의 반 이상을 차지합니다. 그만큼 기초가 되는 부분이기 때문에 차근차근 설명해보도록 하겠습니다.

먼저 수집 대상은 게시판 형태의 게임 커뮤니티는 전부 수집합니다. 특정 게임 게시판이, 특정 게임에 대한 게시판이 아니더라도 게임 얘기가 있는 일부 게시판도 전부 수집하고 있습니다. 수집 대상은 페이스북이나 페이스북 그룹이나 페이지도 포함하고 있고 약간 게시판 형태와 다른 형태지만 트위터와 구글 플레이 앱 리뷰, 아이폰의 앱 리뷰도 함께 수집하고 있습니다.

많은 분들이 다 알고 계시지만 그래도 잠시 설명을 드리자면 크롤러의 기본 요소는 웹 요청을 하고 그 결과를 받아서 파싱을 하고 우리가 원하는 공간에 저장을 하는 것입니다. 웹 요청 부분을 좀 더 자세히 보면은 우리 코드에 의해서 요청을 하지만 특정 다른 곳에 존재하는 서버에게 요청을 하는 것이기 때문에 언제 서버가 응답할지 응답하는 시간을 예측할 수 없습니다. 그리고 요청을 하고 결과를 받을 때 네트워크 자원을 이용하는 것 외에는 우리 로컬 자원을 거의 이용하지 않기 때문에 웹 요청 같은 경우에는 특정 한 서버에서 여러 개의 웹 요청을 잘 제어해서 한 번에 보낼 수 있는 게 굉장히 중요한 요소 중에 하나입니다. 그리고 파싱은 어떻게 보면 특정 사이트의 html 탬플릿인데 한 번 개발해 주면 저의 경험상 1년에 한두 번 정도? 외에는 한두 번도 좀 많은 것 같고 한 번 정도? 외에는 교체할 일이 거의 없기 때문에 잘 사용할 수 있습니다. 일반적인 크롤러가 이런 특징과 흐름을 가지고 있다면 게시판 크롤러는 약간 다른 형태를 가지고 있습니다.

만약 커뮤니티 중에 로그인을 해야지만 꼭 볼 수 있는 게시물이 있다면 제일 먼저 1회 로그인을 해야 합니다. 다음에는 게시물 리스트 페이지에 웹 요청을 하고 게시물 리스트를 파싱한 뒤에 게시글 정보와 url을 얻고 게시물을 다시 웹 요청을 해서 파싱을 하고 완성된 게시글의 정보를 저장하는 구조입니다. 보통 일반적인 게시판 형태를 수집할 때는 이런 흐름을 따라서 수집을 하게 됩니다. 더 자세히 설명해 보면

게시판 수집은 크게 게시물 리스트를 수집하는 함수와 게시물을 수집하는 함수로 나눌 수 있습니다. 

먼저 게시물 리스트 수집 함수를 설명하기 전에 잠깐 게시물 리스트가 어떤 형태인지 살펴보겠습니다. 그림을 보, 화면에 지금 보이시는 게시판 리스트의 일반적인 페이지, html 페이진데요 게시물 리스트에는 중요한 정보들이 있는데 게시물 번호, 제목, 조회 수, 작성자, 좋아요 또는 추천 수 등이 포함되어 있습니다. 게시물 번호가 간호 위의 사례처럼 명시적으로 보이지 않는 경우가 있는데 이런 경우에는 보통 게시물 url에 유니크 키로 참조하고 있기 때문에 게시물 번호를 알 수 있습니다. 이 중에 게시물 번호는 DB에 게시물이 수집된 적이 있는지 없는지 판단하는 중요한 정보이기 때문에 중요하고 또 게시물 제목이나 댓글 수 같은 경우는 해당 게시물을 한 번 더 수집할 것인지 말 것인지를 결정하는 중요한 요소 중 하나입니다. 게시물 수집 함수의 로직은 다음과 같습니다.

게시물 리스트의, 저장하고 있는 게시물 리스트의 url을 웹 요청을 하고 좀 전에 보여드린 형태의 게시물 html을 받아옵니다. 게시물 번호와 제목, 조회 수 등등 수집할 수 있는 모든 정보를 최대한 수집한 다음에 제일 먼저 게시물이 DB에 있는지 확인을 하고 게시물이 수집된 적이 없다면 게시물 수집 함수에 게시물 정보와 함께 작업을 넘깁니다. 그리고 게시물이 DB에 있는 경우라면 제목이나 댓글 수가 변했는지를 확인합니다. 만약 제목이 변했다면은 게시글의 내용도 변했을 거라는 판단 아래 다시 한 번 게시물 수집 함수에 게시물 수집을 요청하고요. 댓글 수가 변한 경우에도 게시물 수집 함수에서 댓글을 포함해서 수집하기 때문에 게시물 수집 함수를 다시 호출합니다. 그리고 다음에는 조회 수나 추천 또는 좋아요가 변했는지를 확인하고 변했다면 DB에 업데이트하는 형식으로 구성되어 있습니다. 이 절차 게시판 리스트 수집 함수의 전체적인 프로세스이고 다음은 게시글 수집 함수를 살펴보도록 하겠습니다.

흔히 우리가 알고 있는 게시물 형태는 이 그림과 같습니다. 독립적인 url을 가지고 있고 게시물 리스트의 비해서 좀 더 구체적인 정보를 가지고 있습니다. 이미 게시물 리스트에서 게시물에 대한 정보를 최대한 가져왔기 때문에 댓글이나 본문, 게시글 리스트에 없는 정보들만 따로 수집해서 아니 파싱 해서 수집합니다. 가끔 보면 조회 수나 추천 수가 게시물 리스트에는 없고 게시물에만 있는 경우도 있는데 이런 경우에도 게시물에서 수집을 진행합니다. 그리고 댓글도 한 번에 웹 요청을 통해 한 번에 수집할 수 있는 게시물이 있고 댓글만 따로 웹 요청을 해야 되는 경우도 있는데 이런 경우에도 그냥 댓글 수집 함수에서 함께 처리합니다. 게시물 수집 함수 로직은 다음과 같습니다.

게시글의 url을 웹 요청을 해서 게시물 html을 받아옵니다. 리스트로부터 전달받은 게시물에서 게시물 정보를 포함해서 부족한 부분을 파싱 해서 게시물 정보를 완성을 하고요. 댓글에 변경이 있다면 혹은 처음 요청이라면 댓글도 요청을 해서 수집을 하고 최종적으로 DB에 없으면은 Insert를 하고 DB에 있으면은 업데이트하는 구조로 되어있습니다. 게시물 리스트 수집 함수와 게시물 수집 함수는 보통 사이트 별로 각기 다른 형태를 가지고 있기 때문에 사이트 별로 만들어서 유지하고 있습니다. 그럼 이 두 개의 함수를 어떻게 묶어서 사용하면 될까요?

가장 간단한 방법 중 하나는 사이트마다 수집하는 크롤러를 작성하는 방식입니다. 파이썬을 예로 들면 위에 보시는 것처럼 while loop를 돌면서 해당 시간에 수집할 목록을 가져옵니다. 그리고 수집을 진행하는데 수집 진행은 여기 보시면 페이지가 있는데 게시물 양에 따라서 평소에 자동으로 페이지를 조절합니다. 게시물의 많은 페이지는 한 번에 세네 개 페이지라든지 게시물이 적은 페이지는 한 번에 한 개 페이지라든지 수집을 할 양을 정해놓고 약간 느슨하게 조절을 하면은 거의 대부분의 실시간으로 게시글을 수집할 수 있습니다.

저희도 처음에는 이런 방식으로 여러 개의 사이트의 게시글을 수집했습니다. 저희가 현재 약 400개가량의 게시판을 수집하고 있는데 거의 100개 되기 전까지는 이런 방식을 통해 수집을 진행했었습니다. 그림에서처럼 피온 수집기는 피파온라인 홈페이지에 있는 게시판들을 전부 수집하는데요. 자유 게시판, 질문 게시판 등등 사이트에 있는 게시판을 다 수집을 하고 서든어택 수집기는 서든어택 홈페이지에 있는 커뮤니티 게시글을 수집합니다. 이렇게 사이트별 파이썬 스크립트를 다 전부 모아서 독커 이미지로 만들고 이것을 AWS 서버 인스턴스 위에 배포합니다. 독커라는 것은 최근 유행하고 있는 가상화 시스템인데요. 저희는 되게 유용하다고 생각돼서 크롤러 외에도 전체 시스템에 독커 이미지를 적용을 해서 독커를 적용을 해서 사용하고 있습니다.

이 부분이 약간 길어질 것 같아서 잠시 물 한 잔만 마시고... 한동안 좀 전에 설명드린 방식으로 사이트별 크롤러를 개발해서 운영했었는데 운영하면서 몇 가지 어려운 부분들이 생기기 시작했습니다. 첫 번째는 실시간 수집 관련 내용입니다. 커뮤니티 동향을 살펴보기 위해서는 실시간성이 굉장히 중요한데 여기에 어려움이 있었습니다. 예를 들어 헝그리앱 사이트를 예를 들면은 헝그리앱 사이트에는 특정 하나의 게임만 있는 게 아니라 여러 개의 게임을 포함하고 있는 마치 포털과 같은 사이트입니다 예를 들어서 헝그리앱의 안에 있는 A게임과 B게임의 게시물에 둘 다 이상이 있으면은 게시물 양이 폭발하게 되고 헝그리앱 사이트만 게시물이 폭발하게 되면은 위와 같은 형태로 구성을 해놓으면 대응하기 매우 어렵습니다. 그리고 위에처럼 위의 실시간 수집 문제처럼 실시간으로 수집 못했거나 아니면 장애가 있거나 이런 경우에는 중단된 기간이 있어서 실시간 수집 외에는 빠진 부분을 수집해야 하는 상황이 생기는데 이럴 때에도 게시물 복구 스크립트를 따로 작성하거나 아니면 현재 돌아가고 있는데 크롤러들의 리퀘스트 양을 고려해서 장비를 분배해야 되는, 수동으로 분배해야 되는 어려움이 있습니다. 이게 게시판이 늘어나면 늘어날수록 계속 손이 많이 가는 구조여서 계속 어려움 중에 하나였습니다. 그리고 확장의 편의성인데 헝그리앱 사이트의 수집이 느려지면은 헝그리앱 사이트 수집기를 하나를 늘리면 되고 카페의 수집기가 느려지면은 카페의 수집기를 하나 늘리면 되긴 하는데 이게 사이트가 계속 많아지다 보면은 수작업으로 관리하는 게 점점 더 어려워지고 또 이것도 배치도 수작업으로 해야 되는 문제가 있어서 ‘아 이제 더 이상 한계가 왔다 이제는 좀 변경해야겠다’라는 생각이 들었고 다른 방식의 크롤러를 고려하기 시작했습니다. 그래서 작업 큐가 있고 이를 분산해서 작업을 진행할 수 있는 방식을 고려하기 시작했는데

저희는 파이썬이라는 언어를 주로 사용하고 있는데 마침 파이썬에는 Celery라는 매우 유명한 분산 작업 큐 모델의 라이브러리가 존재하고 있었습니다. 마침 Celery가 우리의 목적과 거의 적합했기 때문에 Celery를 이용한 크롤러를 고민하기 시작했고 이 그림과 같은 구조의 시스템으로 변경되었습니다. 중앙에 보이는 게 작업 큐인데 작업 큐에 들어가는 작업의 단위는 아까 위에서 설명드렸던 게시물 리스트 수집 함수와 게시물 수집 함수입니다. 작업의 단위가 게시물 리스트랑 게시물이 지속적으로 쌓이게 되어 있고 가끔 복구 게시물이 있는 경우에도 복구 게시물 작업이 해당 작업 큐에 쌓이게 되어 있습니다. 어차피 이 함수들을 그대로 사용했기 때문에 Celery로 변환하는데 큰 비용이 들지 않았습니다. 그리고 간혹 복구작업이 있는 경우에도 작업 큐에 쌓아두고 신경을 안 써도 되기 때문에 굉장히 부담이 줄어들었고 작업 큐에 작업이 많은 경우에만 그러니까 한 가지 작업 큐만 보고 있으면은 이런 경우에는 사이트가 전체 느려진 거기 때문에 워커, 크롤러를 하나 더 스케일 아웃하는 형식으로 스케일 아웃에 대한 부담도 많이 줄여놨습니다. 그리고 크롤링 작업을 하다 보면은 상대, 필연적으로 이제 상대 서버에 대한 부담을 줄이기 위해서 너무 많은 요청을 하면 안 되기 때문에 그런 옵션이 필요한데 Celery에는 rate_limit이라고 해서 이 함수에 대한 제한을 걸어둘 수 있습니다. 여기 상단에 보시면은 rate_limit='1/s'라고 써있는데 “1초에 한 번만 이 함수를 수행할 수 있다”라는 뜻입니다. 그리고 왼쪽에 보시면은 할 일 찾기라는 부분이 있는데

이 서비스는 주기적으로 루프를 돌면서 데이터베이스의 다음 할 작업이 무엇인지 물어보고 작업 큐에 추가하는 역할을 합니다. 데이터베이스에는 작업 url, 다음 작업 예정 시간, 최근 작업 시작 시간 등등 작업에 관련된 정보들이 추가되어 있고요. 하나의 로우로 관리되고 있습니다. 할 일 찾기 로직은 데이터베이스에서 다음 작업 예정 시간과 현재 시간을 비교해서 해당 작업을 큐에 추가하는 역할입니다.

게시물 실시간성을 위해서 크롤러는 보통 1페이지만 수집합니다. 대신 새롭게 수집된 게시물이 하나의 페이지에서 70% 이상일 때는 다음 작업시간을 1분으로 설정을 하고 50% 이상일 때는 4분으로 설정하고 아무리 게시물이 없는 경우에도 무조건 한 시간에 최소 한 번은 꼭 이 게시물을 살펴볼 수 있도록 구성했습니다.

그리고 혹시라도 게시물이 수집되지 못하거나 댓글이 뒤늦게 업데이트 되는 경우를 대비해서 하루에 한 번 새벽 2시경에 게시판 리스트를 전부 돌면서 어제의 게시물 중에 혹시 빠진 게시물이 없나 확인하고 변경된 점이 있다면은 재수집합니다.

이젠 데이터 수집은 완료했고 다음은 수집된 데이터를 저장하는 부분에 대해서 설명드리려고 합니다.

게시글 저장에 대한 흐름은 다음과 같습니다. 먼저 크롤러가 게시글을 수집해서 MariaDB에 저장을 합니다 저희는 보통 InnoDB 스토리지 엔진을 기본으로 사용하고 있는데 데이터를 하나의 로우라고, 로우 데이터라고 생각을 해서 저장만 하는 용도로 사용하고 있기 때문에 InnoDB를 주로 사용하고 있습니다. 그리고 저장된 데이터 중에서 게시글 제목, 본문, 댓글 등과 같은 텍스트만 따로 풀 텍스트 엔진인 Sphinx를 이용해서 인덱싱하고 있습니다.

게시물 테이블을 살펴보면은 특별한 부분이 있는 건 아니고 저희가 흔히 생각하는 게시판 형태의 게시물을 하나의 로우에 넣고 있습니다. 댓글과 부가정보는 JSON type으로 하나의 필드로 넣고 있고 간혹 특이한 케이스가 생기는데 예를 들어서 게시물 번호랑 게시물 ID 같은 경우에는 이게 이 게시물이 DB에 이미 있는 게시물인지 아닌지를 판단하는 중요한 정보 중에 하나인데 간혹 게시물 번호가 없는 사이트들이 있습니다. 구글 플레이 앱 리뷰 같은 게 대표적인 경운데요. 게시물 번호가 숫자가 아니라 유니크 스트링 키를 가지고 있습니다. 이런 경우에도 이 스트링 키를 그냥 해시로 변형을 해서 임의의 유니크한 숫자를 만들어낸 다음에 저장했습니다. 기존 게시물 테이블과 다른 형태의 게시글이긴 하지만 큰 프로세스 안에서 대부분 통할 수 있도록 똑같이 저장을 했습니다.

최근까지는 기본 Sphinx를 사용했다가 최근에 Sphinx RT라는 방식으로 변경 중입니다. 그림에서 보는 것처럼 Sphinx는 실시간 검색을 지원하기 위해서 새로운 게시물이 생기면은 이를 추가하기 위해서 기존 인덱스를 똑같이 복사를 하고 그 파일에 새롭게 추가된, 증문된 내용을 더해서 하나의 합친 파일을 만든 다음에 기존 인덱스와 교체하는 방식으로 증문 검색을 지원하고 있습니다. 기존, 예전에 던파를, 던파 대상으로 개발했을 때는 가상 머신이 아니라 실제 물리적 머신에서 사용했기 때문에 이런 이슈에 대해서 되게 크게 생각하지 않았는데 저희가 지금 전체 시스템을 AWS 상에서 사용하고 있다 보니까 AWS는 iops라고 해서 io에 대한 비용을 따로 체크를 해서 io를 많이 쓰면은 비용을 점점 더 많이 내는 구조입니다. 그래서 저희가 저희 팀에서 사용하는 io에 지불하는 비용이 점점 많아져서 다른 방식을 고민하게 됐습니다. 그래서 보면은 Sphinx RT라고 해서 Sphinx 내에서 리얼타임 방식으로 지원하는 방식이 있어서 이 방식을 지원하기 시작했는데 일부는 RAM에 저장하고 있다가 RAM 제한을 벗어나는 게시글들이 있으면은 파일로 저장하는 구조입니다. 이런 구조를 통해 로테이트가 일어나지 않기 때문에 io 사용량을 줄일 수 있었고 또 기본 Sphinx에는 원본 텍스트를 또 Sphinx 파일에 저장해야 되는 이슈가 있었는데 Sphinx RT 같은 경우에는 필드 타입에서 원본 텍스트를 저장하지 않아도 되는 필드 타입이 있어서 이거를 사용해서 좀더 io를 줄일 수 있었습니다.

이제 데이터를 수집하고 저장했으니 마지막으로 핵심 부분인 어떻게 활용하는가에 대한 내용이 남아있습니다.

잘 안 보이는데 실제 서비스 구성 화면을 보면 이렇게 되어있습니다. 왼쪽에는 키워드 관련 메뉴가 있어서 특정 주제에 따라서 원하는 주제를 클릭하면은 중앙 영역에 게시물 리스트들이 표현이 되고 이 게시물 리스트 중에 보고 싶은 게시물을 선택하면은 오른쪽에 게시물이 보이는 구조입니다. 전반적으로 지난 발표 때와 서비스 화면은 크게 달라지지 않았는데 새롭게 개편을 준비하고 있긴 하지만 그래도 위 그림처럼 주제별로 게시글을 탐색하는 데는 아웃룩 구조가 가장 최적화된 구조라고 생각을 해서 프론트엔드를 변경하더라도 아마 기본 탬플릿 형식은 아웃룩 구조를 따라갈 것 같습니다.

키워드 사용 예는 다음과 같습니다 폴더는 특정 주제에 대한 내용이고 그 아래 키워드들은 해당 주제와 관련 있는 키워드들입니다. 예를 들어 맨 앞에 렉을 살펴보면은 렉이라는 주제에 대해 살펴보다 보면 유저 게시글 중에 ‘느려’, ‘느림’, ‘렉걸’ 관련 키워드들이 자주 출연하기 때문에 이런 게시글들을 모두 포함해서 한 번에 검색할 수 있도록 지원하고 있습니다. 그리고 

말로만 설명하니까 이게 동작 설명이 굉장히 어려운데 예를 들어서 위에 있는 의문의 재능 폴더는 다음과 같이 동작합니다. 교본을 검색하고 그중에서 전투 교본인 경우를 제외합니다. 그리고 ‘아벨의’ 또는 ‘의문의’를 OR 검색을 하고 최종적으로 전부 OR 처리를 해서 표시하는 방식입니다.

원래 커뮤니티를 평소에 살펴보신 분들이라면 이 화면만으로도 벌써 많은, 많이 짐작하셨을 텐데요. 보통 버그 관련해서 게시글들을 살펴보면은 ‘고쳐’, ‘나만그’, ‘나만안’, ‘나만이’ 등의 키워드들이 자주 출연합니다. 예를 들면 ‘나만그’라는 검색어는 저희는 N-gram 검색을 이용해서 한 글자씩 모두 인덱싱 하고 있기 때문에 ‘나만 그래?’, ‘나만 그러냐?’, ‘나만 그러네’, ‘나만 그런가’, ‘나만 그럼?’ 등등의 게시글들이 전부 출연하도록 되어있습니다. 그리고 저희는 매일 오전 8시에 어제 기준으로 조회 수가 높은 게시글들을 메일을 통해 발송하고 있는데요. 조회 수뿐만 아니라 댓글 수, 유니크 댓글 수 기준으로 메일을 보내봤지만 조회 수랑 비교해서 중복된 게시글들이 많았고 사이트 별로 조회 수 높은 게시글 다섯 개씩만 보내도 충분히 이슈가 된 게시글들을 전부 캐치할 수 있었기 때문에 따로 지원하지 않았고 혹시 더 보고 싶으다면은 인기글 더 보기 기능을 통해 전체 어제 인기 글들을 한 번에 볼 수 있도록 지원하고 있습니다.

그리고 일 별로 주제별 카운트를 확인할 수 있는데요. 이런 부분은 평소와 비교해서 특정 이슈가 부각되는지 게시글 양이 늘었는지를 판단하는 중요한 지표로 사용했습니다.

좀 더 예를 들어보면 아까 초반에 사용했던 그래프를 다시 꺼내오겠습니다. “지금 문제가 있다는 거를 언제 알림을 주면 좋을까?”라는 부분은 언제나 고민 포인트 중 하나입니다. 현재 커뮤니티상에 이슈가 있긴 하지만 이게 실제 이슈가 있는 건지 급작스럽게 늘어나고 있는 건지 등등을 판단해서 알림을 보내야 하기 때문입니다. 보통 크게 이슈가 터질 때의 흐름을 보면은 최초 이슈가 발생을 하고 나서 이 그림처럼 급격하게 이슈가 증가하는 것을 볼 수 있습니다. 게임 별로 이슈가 정점에 이르기 전에 알림을 주는 것은 굉장히 중요한 부분인데요.

시간의 흐름 별로 살펴보면은 이런 그림이 됩니다. 그림을 살펴보면 아시겠지만 두 시간 전에 ‘빽섭’과 ‘백섭’이라는 키워드가 처음 출연을 하고 시간이 점점 줄어들 때마다 순위가 상승하는 모습을 확인할 수 있습니다. 이럴 때 순위가 상승할 때 개발팀에 알림을 주면은 더 이슈가 크기 전에 아니면 혹은 문제를 더 빨리 대응할 수 있는 좋은 자료가 됩니다.

그리고 저희는 특정 키워드가 이슈가 있을 때 이를 알려주는 기능을 운용 중에 있는데요. 이 그림처럼 키워드들에 대해 이 키워드가 언제 최초에 발생했는지 아니면 지난 2주 동안 흐름이 혹시 어땠는지 그리고 해당되는 게시물들은 어떤 게시물들이 있는지 확인할 수 있도록 메일을 통해 알림을 주고 있습니다. 이런 메일을 처음 받아보면은 이런 몇 가지 포함돼있는 부가적 정보들을 통해서 사람이 봤을 때 “아 이게 지금 정말 이슈구나 아니구나”를 정말 쉽게 판단할 수 있습니다.

이런 방식으로 서비스를 하기 위해서는 노이즈 제거 작업을 진행해야 합니다. 왜냐면 핵 관련 키워드에 대해서 검색을 하게 되면 저희가 원하는 거는 핵 관련 그야말로 핵을 쓰는 관련 게시물일 텐데요. 실제 검색 결과에는 ‘핵잼’, ‘핵심’ 이런 다른 단어에 의해서 검색 결과가 나타나는 경우가 많습니다. 저희는 단어 사전을 이용해서 이런 노이즈를 제거하고 있는데 이 내용은 저희 팀의 이태윤 님께서 내일 이 자리에서 ‘실시간 트렌딩 키워드 뽑아내기’라는 주제로 발표를 진행할 예정입니다. 이 부분에 대해서는 태윤 님이 잘 설명해 주실 것입니다.

언제 게시글을 수집하면 효과적인가에 대한 해답은 아마 다들 알고 계신 그대로일 겁니다. 라이브 서비스 중인 게임은 대규모 패치거나 서비스 이상이 있기 전에 수집할 수 있으면 당연히 제일 좋을 거고요. 기존과 비교할 수 있을 테니. 아직 라이브 하지 못한 서비스들도 베타서비스 때부터 지원을 하면은 많은 효과를 보고 있습니다.

마지막으로 오늘의 결론입니다. 유저 동향 분석을 위해서 게시물을 수집하고 분석하는 것은 가장 기초적이면서도 큰 비용 없이 효과적으로 유저 피드백을 받을 수 있는 좋은 도구입니다. 게시물 수집을 고려해보고 함께 수집 또는 분석에 대해서 함께 빠져보자는 게 오늘의 결론입니다. 그리고 혹시 작게 써놨는데 시간이 부족해서 구축할 수 없거나 잘 안되거나 잘 모르겠거나 이러면 저희 회사에 연락하시면은 개발사들에게도 충분히 이런 시스템을 제공하고 있습니다.

네 이상으로 오늘 발표를 마치겠습니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
