오픈서치로 시작한 임시변통 로그 집계 환경

게임을 서비스 할 때 로그는 고객들의 말과 행동의 차이를 인식해 앞으로 서비스 해 나갈 방향을 설정하는데 엄청난 도움을 주는 수단입니다. 서비스를 지속하기 위해 직접 이야기하는 고객들의 의견을 적극적으로 들어야 하지만 동시에 로그를 통해 실제 게임에 일어나고 있는 일을 확인해 이들 사이의 차이가 생기는 이유를 어느 정도 설명할 수 있어야 합니다. 그렇지 않으면 어느 한 쪽에만 의존하다가 잘못된 의사결정을 내려 고객 입장에서는 누가 봐도 명백히 이상한 정책을 밀어붙이다가 서비스를 망가뜨릴 수도 있습니다. 어느 게임이라도 서비스 중이라면 로그를 꽤 잘 남기고 있을 테고 개발 중이라도 로그를 붙여 개발 도중에 수행하는 여러 테스트로부터 직접 보이지 않는 사람들의 행동을 밝혀내고 있습니다.

주로 큰 회사에서는 로그 수집, 분석, 의사결정지원 등을 수행하는 별도 부서가 있고 이들이 생산하는 정보는 기밀에 해당했기 때문에 개발팀에 소속된 스탭들이 쉽게 보기는 어려웠습니다. 개발팀에서는 그저 전담 부서에서 제공한 인터페이스를 통해 로그를 보내고 로그가 정상적으로 남는지 확인하며 로그에 남길 상황과 값들을 정의하는 정도가 로그에 대해 할 수 있는 일의 거의 전부였습니다. 사실 로그에 기반한 보고서가 기밀인 이유는 사용자 수, 매출 같은 숫자들을 유추할 수 있기 때문인데 이를 머리로는 이해하지만 이것 때문에 개발팀이 로그 전체에 접근할 수 없는 상황을 이해하기는 쉽지 않습니다. 처음에는 순진하게 미래에 개발팀에서도 로그에 접근할 수 있을 거라고 예상하고 고객들의 행동을 따라갈 수 있도록 준비했지만 막상 서비스를 시작하자 우리들은 로그에 접근할 권한이 전혀 없었고 전담 부서에 아주 구체적으로 보고 싶은 데이터 모양을 전달해야만 상당한 시일이 흐른 다음에야 정제된 데이터를 볼 수 있을 뿐이었습니다.

개인적으로 로그 데이터 분석은 시도와 실패를 계속해서 경험해 가는 과정을 통해 올바른 방법을 탐색할 수 있다고 생각합니다. 대략 답해야 하는 질문을 알고는 있지만 애초에 이 질문이 올바른 질문인지, 이 질문에 답하면 의사결정에 도움을 받을 수 있을지는 데이터를 직접 봐야 알 수 있습니다. 그런데 외부 부서에 원하는 데이터 모양을 정확히 요청하면 정확히 그 모양으로만 데이터를 받을 수 있는 환경에서는 시도와 실패 사이 간격이 너무 길어 그 업무에만 집중할 수 없었습니다. 또 외부 부서에 협조 요청을 하는 형태로 일을 진행하다 보면 서로의 우선순위가 달라 너무 늦은 시점에 회신을 받기도 하고 또 여러 가지 시도에 위축되기도 해서 결국은 로그로부터 도움을 받으려고 하던 생각을 접게 만듭니다. 다른 팀들도 비슷한 상황이었는지 로그를 보는 대신 커뮤니티에 올라오는 고객들의 목소리에 집중했는데 이 목소리는 의미가 없지는 않지만 로그와 함께 교차 검증하지 않은 채로 의사결정에 사용하면 위험합니다.

한편 작은 팀이나 작은 회사에서는 로그를 별도로 관리할 조직이 없고 또 로그 탐색을 전담할 사람을 설정하기도 어려워 이 업무 전체가 기획팀에 할당될 때가 많았습니다. 많았다기보다는 항상 그랬습니다. 한번은 인게임에서 일어나는 온갖 이벤트를 텍스트 형식으로 남겼는데 명절 연휴 동안 서버를 열어 사전 신청한 고객들을 대상으로 비공개 테스트를 한 적이 있는데 테스트 기간 동안 게임 서버의 남은 스토리지가 로그 텍스트 파일로 가득 차 서비스가 중단된 적도 있습니다. 임시로 매일 사용자가 가장 적은 시간대에 로그를 다른 기계로 보내고 게임 서버로부터 삭제했는데 한 기계에 모인 텍스트 파일은 거대한 크기였고 별 생각 없이 이 데이터를 엑셀로 불렀다가 엑셀은 이런데 쓰라고 만든 도구가 아니라는 사실을 아주 처절하게 배웁니다.