NDC Replay

쉽게 따라 할 수 있는 “꽤” 훌륭한 유저 동향 분석 시스템
김호연
네오플
현재 던전앤파이터 개발실에서 근무하고 있고, 웹 개발을 담당하고 있음, 과거 넥슨에서 웹 개발자로 근무 하면서 다양한 게임 웹 개발에 참여했음
라이브 게임 서비스에서 게임을 즐기는 유저들의 목소리를 효과적으로 들을 수 있는 방법에 대해 이야기 합니다. 던파에서 개발한 유저 모니터링 시스템을 공개하고 개발과정 개발방법 등과 함께 유저 커뮤니티 분석 노하우, 실제 서비스에 반영된 사례들을 공개해서 라이브 게임에 빠르게 반영할 수 있는 실질적인 도움을 얻을 수 있을 수 있을 것이라고 생각합니다.
[새 창에서 슬라이드 보기]
안녕하세요. 네오플 던파 개발실에서 근무하고 있는 김호연이라고 합니다. 본격적으로 발표를 시작하기 전에 혹시 앞 발표부터 연속해서 듣는 분 계신가요? 손 한번 들어봐 주시겠어요? 그 앞 발표도 들으신 분 계세요? 혹시? 거의 없네요. 바로 앞 발표가 저희 팀장님 발표였고, 그 앞 발표도 저희 팀원들 발표였는데, 부분부분 제 세션에 대해서 광고를 많이 했다고 하더라고요. 원래 여기는 광고해준다더니 조금 실망스럽네요. 라고 써있는데, 생각보다 너무 많은 분들이 팀장님 발표를 듣고 들어와 주신 것 같습니다. 앞선 발표마다 조금씩 소개 된 유저 모니터링 시스템이 있는데, 이 시스템에 대해서 본격적으로 소개하려고 이 자리에 나왔습니다. 저는 현재 던파 개발실에서 개발자로 근무하고 있고, 주로 하는 일은 게임 개발이든 업무든 던파 개발에 있어서 시간이 오래 걸리거나 병목 현상을 보이는 부분들을 해결하는 업무를 주로 하고 있습니다. 오늘의 주제는 던파를 즐기는 유저 분들의 목소리를 좀더 잘 듣기 위해서 저희 팀에서 개발한 유저 모니터링 시스템에 대해서 소개하고 개발 방법에 대해서 공유하는 자리입니다. 이 시스템의 특징은 쉽게 개발할 수 있으면서 누구나 효율적으로 유저 커뮤니티를 살펴볼 수 있는 특징이 있기 때문에 이 부분에 중점을 맞춰서 얘기할 예정입니다. 본격적으로 발표를 시작할 텐데요. 보통 넥슨에서 퍼블리싱 하는 게임들은 매주 목요일에 패치를 진행합니다. 패치를 진행하는 날에는 다양한 문제가 생기고, 당연히 점검이 연장이 되고, 유저들의 불만이 폭주하는 날들이 많죠. 그날은 다행히도 무사히 게임 서버를 오픈했었습니다. 모두들 즐겁게 퇴근을 했고 문제는 다음날 벌어졌습니다. 출근을 했는데 게임 실행이 되지 않는다는 소식을 들었습니다. 이때까지만 해도 저희는 당황하지 않았고 평소처럼 원인 찾기에 나섰습니다. 던파는 약 9년 된 게임이기 때문에 동접, 클라이언트 덤프 시스템, 게임 도달률 등 서비스 안정성 관련해서 수 많은 지표를 가지고 있습니다. 이 수많은 지표를 살펴보았지만 도무지 원인을 알 수 없었고 심지어 재현조차 쉽지 않았습니다. 왜냐면 전체 유저가 이런 현상을 겪는 게 아니라 일부 유저만 이런 현상을 겪고 있었거든요. 이 오류를 수정하기 위해서 저희 팀원들이 전부 투입되었지만 해결책을 찾는 게 쉽지 않았죠. 그런데 어떤 팀원이 이런 글을 공유합니다. 실행 폴더 이름을 바꾸면 된다는 글이 있는데요. 저희는 참 멘붕을 겪었지만 그 게시글에 보니 잘 된다는 댓글들이 보이기 시작하더군요. 아까 팀장님 발표 들으신 분들은 아시겠지만 그 수많은 댓글들이 하나하나 늘 때 마다 저희 팀원들은 멘붕을 더해갔습니다. 저희는 실행폴더 이름을 변경하는 것이 오류와 관련된 내용임을 직감할 수 있었고, 그것을 하나의 단서로 문제를 해결할 수 있었습니다. 이후 재발 방지도 할 수 있었죠. 또 하나는 작년에 기억에 남는 게시글이 하나 있었는데요. 버그 리포팅을 주제로 한 게시글이였습니다. 게시글 중 일부를 발췌해서 적어보았습니다. 원래 이 게시글이 굉장히 길거든요. 이 분이 실제로 이거를 다 테스트해서 하나하나 게시물에 작성을 했기 때문에 중요한 부분만 발췌해서 적어놓았습니다. 앞에서부터 결론이 명확하죠. 코딩하는 분들을 위해 쉽게 결론부터 말하자면 오버플로우 입니다. 데미지 수치가 32768%이상이면 발생. 게임 많이 하시거나 개발자 분들은 32767, 32768에 대해서 굉장히 잘 알고 계실 텐데요. 결론부터 말한 오버플로우 문제가 맞습니다. 이분 게시글을 추적해 보면 여러 가지 좋은 버그를 제보해주신 게 많은데, 이분이 해결해주신 버그가 참 많아요. 이 자리를 빌어 다시 한번 감사 드리겠습니다. 루리웹의 달시계님. 우리는 게임을 파악하기 위해 다양한 통계 지표를 가지고 있습니다. 기본적인 동접, 경제, 버그 등등 게임을 표현하는 수 많은 데이터를 쌓고 측정합니다. 하지만 우리가 의도적으로 만들어 놓은 데이터로는 모든 것을 케어할 수 없습니다. 게임 개발자도, 기획자도, 디자이너도 유저와 같이 환경을 갖춰서 똑 같은 게임을 즐길 수 있지만 저희는 유저와 같아질 수 없습니다. 게임을 만드는 저희와 유저가 영원히 같아질 수 없다는 부분이 있다는 점은 매우 중요합니다. 그래서 우리는 게임 유저들의 경험이, 그들이 생각이 필요합니다. 우리는 한 가지를 인정하고 시작해야 합니다. 유저들은 우리와 다른 의미에서 전문성을 가지고 있다는 점이죠. 아쉽지만 우리가 만든 게임에 대해서 우리는 생각보다 무지합니다. 그리고 유저들은 생각보다 훨씬 더 똑똑합니다. 1만 시간의 법칙 아시죠? 1만 시간 동안 던파를 집중해서 한 것 같은 분들이 굉장히 많습니다. 우리는 그런 유저들이 가지고 있는 생각을 잘 케어해야 합니다. 하나 걱정하지 않으셔도 될 부분은 저 똑똑하신 유저 분들도 저희 게임 회사에 입사하시면 저희와 비슷해집니다. 자신이 관여한 컨텐츠를 개발할 분들은 유저 반응을 보기 위해서 인터넷 커뮤니티를 살펴보곤 합니다. 우리가 심각한 버그가 있는지, 아니면 정말 큰 문제가 있는지 알아볼 수 있는 방법은 던파 커뮤니티 유저들의 글을 보면 됩니다. 문제가 생기거나 게임이 안되면 게시판이 난리가 나거든요. 던파 커뮤니티를 돌면서 동향을 파악하는 일은 객관적으로 가장 쉬운 방법입니다. 하지만 편향적인 정보가 많으니 개인이 알아서 판단해야 되는 문제가 있습니다. 위 내용을 염두 해두고 정리했던 요구사항입니다. 정확히는 저희 팀장님께서 제게 내려주신 요구사항인데요. 위와 같은 구체적인 요구사항에 힘입어 다음과 같은 목표를 도출해 낼 수 있었습니다. 우리의 핵심 목표는 ‘인터넷 커뮤니티를 돌면서 의미 있는 정보를 찾아내는 수고를 덜어내자’ 입니다. 일반적으로 유저 동향을 파악하기 위해서는 여러 사이트를 돌면서 각종 게시판을 돌아봐야 되고, 원하는 글을 찾아야 되고, 그 글을 또 읽을 다음에 그 중에 의미 있는 정보를 찾아서 개발실에 공유해야 합니다. 저희는 이 시간을 줄이는 걸 핵심 목표로 잡았죠. 처음에는 많은 욕심이 있었습니다. 개발자이기 때문에 자신이 아는 지식과 새롭게 얻은 지식을 실무에 적용하고 싶은 마음이 정말 많았죠. 이런 다양한 개발자적인 욕심을 뒤로하고 저희는 위에 있는 핵심 목표에 집중하기로 합니다. 절대 기술적 난이도가 높아서 시도하지 않은 것이 아닙니다. 이 장소에 저희 팀장님이 계시거든요? 다시 한번 말씀 드리지만 기술적 난이도와 전혀 상관 없습니다. 먼저 사이트에 접근해서 각종 게시판을 돌면서 게시물에 접근하는 시간을 줄여보도록 하겠습니다. 단지 유저 동향을 파악하는 게 목적이었기 때문에 던파와 관련된 모든 사이트, 카페, 수많은 게시판을 다 수집할 필요는 없습니다. 자유게시판, 토론게시판, 공략게시판, 팁 게시판, 소감 게시판 등 유저 의견이 주로 소통하는 게시판을 선정해서 작업했습니다. 그림에서 확인하실 수 있는데, 크롤러는 각 사이트 별로, 네이버는 각 카페 별로 한 개씩 동작하면서 게시글을 수집합니다. 크롤러가 반복해서 동작하는 간격, 게시판 별로 몇 페이지까지 수집할 건지를 조절해서 이 크롤러를 동작시켜서 게시물을 수집했습니다. 이 방식이 약간 게으른 편이 있고, 놓치는 게시물이 있을 수 있는데, 이런 부분은 너그럽게 놓아주도록 하였습니다. 저희 목표는 어디까지나 동향파악이었으니까요. 그렇게 수집된 게시글은 각종 게시판과 함께 다음과 같이 저희 사이트에서 볼 수 있습니다. 왼쪽 상단에 게시판 메뉴를 보면 어떤 사이트에 어떤 게시판들이 수집 대상인지, 가장 최근의 수집 시간은 언제인지 알 수 있습니다. 화면에 보시면 아시겠지만 전반적으로 UX는 저희가 업무에서 주로 사용하는 outlook 방식을 차용했고, 디자인은 저희가 사용한 컨트롤이 제공하는 테마를 그대로 사용했습니다. 그 내용은 뒤에 좀더 이어서 설명 드리겠습니다. 각종 사이트에서 게시판에 접근하는 작업시간까지를 줄일 수 있었습니다. 이제 다음 목표인 내가 원하는 글을 검색하는 시간을 줄여야 합니다. 이쯤에서부터는 인덱싱에 대해서 고민을 해야 됩니다. 수집한 데이터를 원하는 글에서 검색하기 위해서 네이버나 구글만큼 뛰어난 검색엔진은 아니지만 별 다른 지식이 없으면서도 쉽게 사용할 수 있는 full text 검색 엔진이 필요하다는 결론이 나왔습니다. 처음에는 저희 My SQL full text 엔진을 사용했었습니다. 검색 엔진을 사용하겠다는 결정만 내리고 어떤 제품을 사용하기 전에 저희 팀원들이 너무 빠르게 개발을 완료하는 바람에 어쩔 수 없어 My SQL full text 엔진을 사용해 보았습니다. 저희가 DB를 먼저 My SQL로 사용하고 있었기 때문에 접근이 용이해서, 사실은 시간이 촉박해서 내린 결정이었죠. rㅏㄴ단한 쿼리를 이용해서 테스트할 때 가지만 해도 괜찮았고 기능적인 큰 문제도 없었습니다. 쿼리에 대해서는요. 하지만 다른 인덱스와 복합 인덱스 설정이 잘 되지 않았고, 무엇보다 실제 환경에 갔을 대 성능 문제가 많이 있어서 제외됐습니다. 그 다음에 대상으로 올랐던 게 Sphinx와 Lucene인데, Sphinx는 대표적으로 N-gram 검색을 이용해서 검색을 하고 Lucence은 형태소 분석을 이용해서 검색을 할 수 있습니다. 저희는 검색 엔진 개발자가 아니기 때문에 충분한 검색 엔진에 대해서 이해가 없었고, 개발자 특성상 저희가 잘 모르는 부분이 있는 것보다 확실하게 아는 부분을 찾자. 라는 생각에 의해서 N-gram 검색을 사용하기로 결정했습니다. 마침 Sphinx는 설치형 프로젝트이고 몇 가지 설정을 통하면 My SQL과 쉽게 연결해서 인덱싱할 수 있다는 특징이 있습니다. 이제 게시글을 수집해서 게시글을 검색하는 부분까지는 시간을 단축시킬 수 있었습니다. 다음 남은 부분은 글을 읽고 의미 있는 정보를 찾아주는 부분인데, 가장 핵심적인 부분이라고 할 수 있습니다. 그리고 가장 어려운 부분입니다. 사실 사람보다 기계가 더 잘 할 수는 없습니다. 엄청난 기술력이 있다면 비슷한 수준으로 할 수 있는 있지만 필요한 부분이 너무 많죠. 그래서 저희는 아주 약간의 노동력을 이 시스템에 추가했습니다. 저희 팀에 소속되어 있는 이 분도 이 자리에 계시는데요. 한 분이 좋게 말하면 정원사가 되어 정원을 가꾸는 역할, Gardening이라고 하죠. 이 gardening 작업을 한동안 수행했습니다. 일명 키워드 관리 작업을 수행했는데요. 이 작업은 왼쪽에서 볼 수 있듯이 평소에 관심 있을 것 같은 상식 키워드와 패치마다 관심사가 변하는 시즌 별 키워드를 등록하는 일입니다. 먼저 상식 키워드를 보시면 버그, 버그 발생, 주요 키워드, 팅, 렉, 최적화, 과거와의 비교, 패치/점검 등등 주로 문제점과 관련된 키워드죠. 시즌 별 키워드는 패치 때마다 업데이트 되는 내용이 주를 이룹니다. 4월 28일에 남거너 2차 각성, 5월 22일에는 거대 빙고, 드래곤 던전 등. 이런 키워드들을 상식 키워드는 한번에 작업해두고 시즌 별 키워드는 거의 매일 패치 날 아침에 출근해서 작성하곤 합니다. 맨 오른쪽에 있는 성의글을 보시면 이런 gardening 작업을 통해서 학습된 다른 분이 작업하신 키워드를 엿볼 수 있습니다. 게시글 중에 성의글이 있는 특징을 잘 잡아내신 것 같습니다. 화면만 보면 이게 어떻게 동작하는지 잘 가늠이 되지 않는데요. 키워드 동작 방식은 다음과 같습니다. ‘거너 AND 2각’ 이라는 키워드로 등록해서 클릭하면 화면에서 ‘거너 AND 2각’이라고 써있는 쿼리가 요청이 됩니다. 이와 유사한 방식으로 ‘0429남거너 2차각성’을 클릭하면 거너 AND 2각 OR 디스트로이어 OR 레이븐 OR 커맨더 OR 프라임 이라는 쿼리가 완성 되서 한번에서 서버가 응답해서 받게 되어 있습니다. 여기서 저희는 이 시스템의 핵심 노하우를 살펴볼 수 있습니다. 버그 발생 주요 키워드를 예로 살펴보겠습니다. 평소에 유저 커뮤니티를 살펴보신 분이라면 너무 쉽게 이런 특징들을 찾아낼 수 있을 것이고, 그렇지 않은 분이라도 시스템에서 게시글 검색을 통해 충분히 이런 글을 학습할 수 있습니다. 버그 발생 주요 키워드. 나만그, 나만안, 나만이, 는현상. 대충 감이 잡히시죠? 혹시 모르실까봐 제가 밑에 설명을 적어 두었는데요. ‘나만그’는 나만그래, 나만그러냐, 나만그러네, 나만그런가, 나만 그럼. ‘나만안’은 나만안되나, 나만안되냐, 나만 안들어가지냐. 이런 방식으로 동작하게 되어 있습니다. 이 화면은 저희가 키워드 검색을 추구하고 나서 만든 페이지인데요. 처음에 시스템 목표는 의미 있는 정보를 찾아주는 도구가 아니었습니다. 의미 있는 정보를 쉽게 찾아줄 수 있도록 돕는 도구였습니다. 게시판별 보기, 키워드 검색 기능을 개발한 뒤에는 지체 없이 서비스를 0.1 ver 으로 1차 오픈 했습니다. 아까 말씀 드린 대로 평소에, 혹은 오늘 아침에 등록되어 있는 키워드 덕분에 유저 모니터링 시스템에 접근하면 누구나 간단하게 키워드를 클릭하면 게시판 동향을 알 수 있게 됩니다. 앞에 발표를 들으신 분들은 아시겠지만 많은 분들이 좋아하셨죠. 하지만 아직 우리에게는 남겨진 숙제를 해결하지 못했습니다. 키워드 별로 현재 유용한 글을 찾아볼 수 있게 되었지만, 아직 의미 있는 정보를 골라주지는 못했습니다. 의미 있는 정보를 골라주기 위해서는 이 시스템을 사용하는 사용자들의 힘이 필요했기 때문에 저희에게는 서비스 오픈 후 약간의 기다림이 필요합니다. 유저 모니터링 시스템을 공개하고 사용자들이 학습이 될 무렵 저희는 사용자들의 상호작용을 이끌어 내기 위한 기능을 몇 개 추가했습니다. 화면에서 볼 수 있는 태그 기능인데요. 이 태그 기능에 대해서 하나씩 설명 드리도록 하겠습니다. 첫 번째는 즐겨찾기 기능입니다. 지금 보면 ‘모두 던파 개발자를 죽입시다.’ 라고 쓰여있는 게시글을 누가 즐겨찾기를 해놨는데요. ‘이 기능은 그냥 읽어 볼만해’ 라고 생각될 때 쉽게 클릭할 수 있는 용도로 개발되었습니다. 저기 보이는 게시글 옆에 별표만 클릭하면 즐겨찾기에 자동으로 등록이 되게 되어있습니다. 그리고 게시글에 대해 부연설명이 필요할 때 설명을 적을 수 있는 메모기능. 게시글에 대해 전문적으로 볼 필요성이 있거나 다른 조직에 공유해야 될 때 사용하는 태그기능. 이렇게 태그된 글을 저희 던파 개발실 들어오는 입구에 설치되어 있는 모니터에 다음과 같이 서비스 됩니다. 사용자들의 관심을 이끌어내기 위함이죠. 가뭄에 콩나듯 보이는 칭찬글을 걸어서 사기 진작에 도움이 되기도 하고요. 이제 의미 있는 정보를 전달한다는 목표를 다음과 같은 작업을 통해서 달성할 수 있었습니다. 물론 여러 사용자들의 도움은 필수였죠. 다음은 저희가 유저 모니터링을 개발하고 운영하면서 해결했던 문제점 몇 가지를 공유하려고 합니다. 제가 아까 앞 팀장님 발표를 듣고 있는데, 팀장님이 오늘 발표한 내용 중에 거의 대부분이 저희 파트에서 개발한 내용이에요. 어떤 분이 그러시더라고요. 저 디자인이 왜 그러냐고. 저희가 개발자만 3명이 있습니다. 정확히는 저를 제외한 개발자 2명이 거의 모든 부분을 개발하고 저는 입만 놀리는 역할을 하고 있죠. 개발자만 있어서 생기는 가장 큰 문제는 디자인입니다. UX는 생각도 못하고요. UI부터 어떻게 할지 막막했습니다. 저희는 간단하게 웹에서도 데스크탑 UI를 쉽게 사용할 수 있는 자바스크립트 프레임워크를 사용하도록 했습니다. 바로 Sencha 제품을 활용한 방식이었는데요. 홈페이지에 방문하면 cross browsing. 강력한 기능. 안 되는 게 없어요. 여러 가지 장점이 써 있습니다. 저희는 저희가 필요한 부분만, 데스크탑 프로그램처럼 보일 수 있는 컨트롤이 있고, 저희가 UI 작업을 하지 안 해도 되고, 모바일까지 쉽게 적용할 수 있네. 라고 해서 별다른 고민 없이 sencha를 선택했습니다. 그리고 이를 바탕으로 모바일 페이지를 나름 쉽게 만들 수 있었습니다. 어차피 클라이언트 단에서 데이터를 저장하고 활용하는 방식은 비슷합니다. 사용하는 컨트롤을 변경하고 환경에 맞추는 작업을 조금만 해주면, 저희의 경우는 하루 정도 한 분이 작업해서 가능했던 것 같은데, 쉽게 모바일 서비스를 전환할 수 있습니다. 다음은 짤방 무시 기능인데요. 이게 들어간 사유가 조금 웃겨요. 가끔 저희는 그냥 유저가 써 놓은 글들을 보고 싶을 뿐인데, 주위에 계신 동료 분들이 저를 이상하게 쳐다보고 가는 경우가 생깁니다. 더 큰 문제는요. 이게 짤방은 좀 문제가 있는데 내용이 괜찮은 경우가 있어요. 내용을 안 볼 수도 없고, 삭제할 수도 없는 난감한 상황이 펼쳐지죠. 이를 위해 이 태그가 표시된 글은 저희 사이트에서 이미지가 표시되지 않습니다. 게시글만 보이죠. 물론 관리자는 볼 수 있습니다. 그리고 게시물 중에 게시판을 어지럽히는 글이나 도배글 등. 안 보이게 할 필요성이 있다고 해서 휴지통 기능도 추가했습니다. 마지막인데요. 저희가 이렇게 유저 모니터링 시스템을 개발하고 효과적이라고 생각됐던 부분을 간단하게 적은 것입니다. 유저 모니터링 시스템을 개발하면 내가 보고 싶은 반응을 빠르게 한 곳에서 볼 수 있고요. 특별한 노하우 없이 누구나 현재 커뮤니티 분위기를 알 수 있고, 기존 시스템에서 확인하기 어려운, 앞에서 설명 드렸던 문제점을 잘 알 수 있고요. 때로는 정확한 해결책을 갖고 있거나 실마리를 제공합니다. 예상치 못한 문제를 빠르게 감지할 수 있는 경우도 많죠. 이렇게 효과적인 유저 모니터링 시스템을 개발하게 도와준 저희 팀장님께 너무 감사 드리고요. 이상으로 제 발표를 마치도록 하겠습니다.
질문 중에 “개발 기간은 얼마나 걸렸나요? 개발하면서 특별히 어려운 점은 없으셨는지요?”
실제로 개발에 걸리는 시간은 1~2달 정도면 충분합니다. 2~3명의 개발자가 있고 이러한 과정을 다 알고 있다고 치면요. 잘 모르시면 제게 따로 연락 주시고요. 
“크롤링할 때 이미지도 수집을 하나요? 링크만 저장하나요?”
저희는 링크만 저장합니다. Html을 그대로 DB에 넣어서 html 그대로 표시하고 있습니다. 저희 목적인 유저 동향 파악 외에 신경 쓰는 작업들은 대부분 안 했습니다. 안 하는 방향으로 많이 작업을 진행했고요.
“아까 키워드 검색하실 때 and와 or을 쓰시던데, 특정 키워드를 피하는 기능이 있나요?”
있습니다. 검색엔진은 전부다 – 기호를 아마 쓸 텐데, 이 키워드는 빼달라는 기능이 있습니다. 그런데 쓸 필요는 없어요. 실제로 해보시면 아시겠지만 몇 가지 검색어를 조합해서 사용하더라도 충분히 강력하기 때문에.
“Sencha를 써본 기억으로는 어렵고, 느리고, 구렸던 것 같은데 힘들거나 느리거나 하지는 않았나요?” 
저희가 처음 사용할 때는 어럽고, 느리고 구렸습니다. 그런데 지금은 조금 많이 낫더라고요. 원래 버그기 굉장히 많아서 저희도 이 버그 잡느라고 몇 일을 고생한 적이 있었는데요. 최근에 5. 버전인가? 기억이 잘 안 나는데 그 버전 나오고 나서는 버그도 많이 잡고, 고쳐서 수정해서 냈더라고요. 지금은 많이 괜찮은 것 같습니다.
“기능을 추가하거나 스펙을 정할 때 어떤 식으로 고려되나요? 모든 기능이 처음에 다 들어가지는 않았을 거 같은데. 
질문이 굉장히 많은데, 기능을 추가하거나 스펙을 정할 때는 팀장님이 시키는 대로 합니다. 농담이고요. 팀장님이랑 아까 발표 들으신 분은 아시겠지만 메일로 이런 기능 요청이 많이 와요. 의견 쓰기 게시판도 있고요. 그런 것들을 요청하고, 저희가 주로 많이 보기 때문에, 보면서 ‘이거 필요할 거 같은데’ 해서 단계적으로 추가하죠. 처음에 키워드 작업까지만 해서 오픈을 했고요. 그 이후에 많은 개발은 거의 저희의 의견 반, 다른 분들이 이거 넣어주세요. 다 넣어줄 수는 없고요. 저희도 시간이 없으니까. 
“툴 전담 개발자라면 좀 심심하지 않나요?”
이거는 좀 대답하기 어려운 문제인 것 같은데. 심심하지는 않습니다.
“인덱싱 성능이 모자라다고 하셨는데, 어느 정도 부하가 걸렸나요? 분당 몇 건 정도 걸렸나요?”
이게 설명하다가 말았는데, MySQL full text 엔진이 복합 인덱스를 잡게 되면 성능이 좋지 않아요. 인덱스 복합 설정이 안 되거든요. 그런데 저희는 이 검색을 하려면 흐름에 따라서 봐야 하기 때문에 날짜가 기본 검색으로 들어가야 되는데, 이 날짜 검색과 텍스트 검색 엔진이 같이 동작을 하기 시작하면 굉장히 느려집니다. 그래서 사용할 수가 없어서 배제했고요.
“검색 후 보여지는 글들을 문서로 추출하는 기능은 개발 예정에 없으신가요?”
하고 싶지 않아서… 처음에 제가 개발적인 욕심을 많이 줄였다고 했는데, 저도 더 많은 게시물을 수집하고, 특정 단어만 추출을 해서 흐름을 보인다던가. 이런 많은 거를 개발하고 싶었는데 포기한 게 많죠. 어디까지나 기술적인 문제가 아니라 시간이 없으니까요. 저도 가정이 있고.
질문은 여기까지인 것 같네요. 다 대답했습니다. 수고하셨습니다.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
