3. 학습 목표
• 라이브 서비스와 프로덕션의 차이를 안다
• 라이브 팀의 역할과 책임을 안다
• 라이브에 있어서 통계 분석이 갖는 의미를 이해한다
• 직접 게임 플레이를 하는 것이 왜 중요한지 안다
• 일의 우선순위를 결정할 수 있다
• 여러 가지 게임 지표를 알고 이해할 수 있다
• 팀워크를 위해서 어떤 자세를 가져야 하는지 이해한다
5. 라이브(Live) 서비스
• 온라인 게임의 경우 오픈(Launch) 이후의 모든 과정
– 만들어진 게임을 더 잘 되도록 하는 것이 목적
• 온라인 게임의 장기 집권을 가능하게 하는 것
– OBT부터는 게임 개발이 아니라 “서비스”라고 생각해야 함
• 계속되는 방어전
• 진정한 개발의 시작
–
–
–
–
버그 수정 및 개선
유저들의 각종 요구사항 처리
차기 업데이트 콘텐츠 개발
이벤트 계획과 실행
• 각종 특수 시즌(여름 방학 등)을 고려
• 경쟁 업체의 신작 또는 대규모 업데이트 고려
7. 달리는 자동차의 바퀴를 교환하는 것과 같음
http://youtu.be/dvBDeaUMddI
8. 라이브 서비스의 자세
• 기존 콘텐츠 개선 > 새로운 콘텐츠 투입
– 콘텐츠를 많이 만들어 서비스를 유지하려고 생각하면 안됨
• 유저의 콘텐츠 소비 속도를 절대로 따라가지 못하기 때문
• 소비형 콘텐츠보다 커뮤니티형 콘텐츠에 집중
– 잘 개선한 콘텐츠 하나가 열 업데이트 안 부럽다
• 유저의 감정 대응도 중요하다고 인식
– 유저의 반응을 살피고 컨트롤하는 것에 집중
– 별일 아닌 것임에도 유저들의 화를 부를 수 있음
• 근거 없는 소문, 타 게임 알바(?)들의 조직적인 방해 가능성
• 솔직하게 원인과 의도를 설명하고 해결 방안을 미리 공지하는 방법
• 경청 그리고 또 경청
– 유저가 원하는 게임 > 개발사가 만들고 싶은 게임
– 유저 자신들의 이야기를 들어주기(소통) 그 자체를 원하는 경우
9. 라이브 팀 구성
• 차기 업데이트를 담당하는 팀(DEV)과 반드시 분리
– 개발 조직을 Short-term팀과 Long-term팀으로 나누는 형태
– 기존의 개발 조직이 담당하면 민첩한 의사 결정이 힘들기 때문
– 자체 문제 해결 능력(개발력)을 갖추는 것도 중요
• (아트 + 프로그램 + 게임 디자인) + 라이브 분석
• DEV팀의 손을 빌리지 않고 긴급한 패치가 가능해야 하기 때문
• 이벤트에 해당하는 콘텐츠를 직접 제작할 정도는 되어야 함
– 라이브 브랜치 책임
• 국가별로 다른 라이브 환경 등
• 민첩한 대응 (긴급 버그 수정 등)
• 이벤트 콘텐츠
이벤트
R
R
Launch
Trunk
이벤트
US LIVE
bug fix
R
버그수정
R
KR LIVE
이벤트
DEV
10. 라이브 팀의 필수 조건
• 빠른 의사결정 프로세스
– 책임과 역할(R&R)을 명확히
• 이에 적합한 팀 구성을 라이브 서비스 시작 전에 미리 하도록
– 의사 결정부터 대응까지의 turn-around time을 최적화를 위해
• (cf.) 게임 제작 프로덕션은 길게 보고 최적화(global optimization)한
다는 면에서 라이브 서비스와 다름
• 위기 대응 매뉴얼
– 일종이 판례집(law reports)
• 라이브 상황에서의 각종 사례와 대응, 그리고 결과
– 라이브팀의 대응 내용과 know-how는 반드시 기록(archiving)
• 관련 인원의 교대(rotation)시 똑같은 실수를 반복할 수 있기 때문
• 유저 관찰
– 통계 분석, 게임 플레이, 커뮤니티 모니터링
11. 통계 분석
• 과거의 분석을 통해 미래의 라이브를 올바르게 이끌기 위함
• 전문적으로 분석할 수 있는 전담 조직 필요
– 수치화된 통계 데이터를 항상 열람 가능하도록
– 의사결정자들이 통계 결과를 받아들이기 어려운 경우가 있음
• 서로 다른 결론의 도출 가능성이 있는 통계 지표는 지양
• 콘텐츠 제작시 어떤 통계 값을 볼 것인지 미리 설계
– 잘 되고 있다는 것을 알기 위해 어떤 지표를 뽑아야 할까?
• (예) 전장 사용률은 전투 깃발 아이템 사용량으로 본다?
• F2P의 경우 연관성이 높은 상품 찾기
– 어떤 아이템으로 구성된 패키지가 잘 팔릴까?
• (예) 바니걸 귀 액세서리 + 수영복이 최고 매출 조합?
• 정량화의 늪에 빠지지 않도록 할 것
– 통계 분석은 서비스를 위한 필요조건이지 충분조건이 아님
– 유저들의 목소리에 대한 근거로 활용해야 함
12. Gameplay First!
• 통계 보다 더 중요한 것
– 라이브 팀 및 콘텐츠 개발자는 반드시 직접 플레이 할 것
– 직접 플레이 해야만 알 수 있는 것들이 있기 때문
• 통계 지표로는 알 수 없는 것들이 존재: 유저의 “감정”에 대한 정보
• 커뮤니티, 게시판 상의 반응을 해석 검증할 필요가 있음
13. Bot(오토) 단속
• 게임에 대한 신뢰를 무너뜨리는 무서운 적
– 라이브 팀은 봇의 영향을 항상 모니터링 하고 대응해야 함
• (예) 게임 내 전체 통화량의 증가 추세 등
– 게임 디자인으로 막는 방법이 가장 효율적
• 단순 반복의 경우 효율이 낮도록 밸런싱
14. 일의 우선 순위
• 4가지 카테고리
– 긴급하고 중요한 일
• (예) 아이템 복사 버그, 지속적 접속 불가 상황
– 긴급하지만 크게 중요하지 않은 일
• (예) UI 스탯 동기화 문제, 인던 몬스터 길찾기 오류 및 끼임 현상
– 긴급하지 않지만 중요한 일
• (예) PvP 밸런싱, 위험요소가 있는 걸레 코드 리팩토링
– 긴급하지도 중요하지도 않은 일
• (예) 시스템 메시지 에러, 특정 메쉬 텍스처 깨지는 경우
• Discussion
– 위의 4가지 경우의 우선 순위는 어떻게 될까?
– 우선순위대로 왜 잘 지켜지지 않을까?
• 우선순위가 잘 지켜지도록 하려면 어떻게 해야 할까?
15. Case-Study
• TERA
–
–
–
–
–
OBT 때의 아카칼리쉬 사건
정식 서비스 시작시 HP 회복 옵션 밸런스 0.1로 너프 사건
만렙 원양어선용 중형 몬스터 드랍률 너프
파멸의 마수 업데이트시 봉인/재봉인 및 명품 아이템 추가
전장 어뷰징을 통한 강력한 전장템 공급 증가
• 질문
– 어떤 문제가 있었기에 이런 결정을 하게 되었을까?
– 이 결정으로 얻은 것과 잃은 것은 무엇일까?
16. 추천 참고 자료
• MMORPG 동접 개선을 위한 개발 이야기
– 여형욱, BDC 2011
– http://m.blog.naver.com/bo0wy19/80143714046
• 그라나도 에스파다 운영에서 배운 점들
– 김학규, KGC 2011
– http://www.slideshare.net/lesely/kgc2011-1
• 던전 앤 파이터의 사례를 통한 게임 운영과 통계
– 윤명진, NDC 2011
– http://ndc.nexon.com/150111779525
• 데이터마이닝 기법을 게임 통계에서 활용해보기
– 김범주, NDC 2012
– http://ndc.nexon.com/150142371049
18. 각종 게임 지표 용어
• MCU: Maximum Concurrent User
– 특정 기간 (보통 24시간 기준) 최대 동시 접속자 수
• UV: Unique Visitor
– 특정 기간 (보통 일주일 기준) 동안의 순 방문자 수
– 재방문율과 이탈율 계산의 기준 지표
• (예) 지난주 UV vs 이번주 UV
• PU: Paying User
– 특정 기간 동안 돈 낸 사람 수
• ARPU: Average Revenue Per User
– 1인당 평균 결제 금액
• ARPPU: Average Revenue Per Paying User
– PU 중에서 1인당 평균 결제 금액
• TS: Time Spent
– 유저의 특정 콘텐츠 플레이 시간
22. Listening Courteously
• 팀의 일원
– 적게는 십수명 많게는 수백명의 팀워크가 필요함
– 게임 제작은 정말 다양한 사람들이 모여서 일하게 됨
• 원만한 대인관계
–
–
–
–
사고 방식이 상당히 다른 아티스트, 게임 기획자와 잘 통해야 함
자신의 실력이 아무리 좋아도, 성격이 나쁘면(?) 협업이 곤란
게임은 혼자서 만들 수 있는 물건이 아니기 때문
핵심 비법은?
• 경청: 귀를 기울여 듣는 습관
• 경청은 동료간 신뢰의 지름길
– Coworker와의 신뢰가 무너지면
• 특정 콘텐츠가 유기성 없이 분리된 느낌으로 그대로 드러남
23. Ownership
• 내 할 일만 하면 된다?
– 물론, 자신의 맡은 업무를 충실히 하는 것은 필요조건
– 자기에게 떨어진 일만 하고 다른 부분은 ‘나몰라라’하는 경우
• 수동적 자세의 월급쟁이는 환영 받지 못함
• 주인 의식(ownership)이 필요
– 일종의 충분조건
• “내가 만드는 작품이다”라는 마인드
• 주인의식은 만드는 과정 속에서 재미를 느낄 수 있어야 가능
• “이렇게 좀 더 바꿔보면 더 재미있지 않을까?”
• 게임 만드는 사람이 재미를 못 느끼면?
– 절대 재미있는 게임이 나오지 못함
24. Leadership
• 다양한 사람들로부터 팀워크를 이끌어 내기 위함
– 존중을 바탕으로 구성원들이 잠재력을 발휘할 수 있도록
• 리더의 진정한 힘은 구성원들의 신뢰에서 우러나옴
– Servant Leadership
• 뛰어난 리더는 다른 구성원들을 섬기는 법부터 배움
• Senior 개발자 이상이라면 꼭 읽어봐야 할 책
고갱님
PD
Developer
Director
Senior Developer
Team Lead
Team Lead
Senior Developer
Director
Developer
PD
호갱님
25. 끝
• 학습 목표 체크
–
–
–
–
–
–
–
라이브 서비스와 프로덕션의 차이
라이브 팀의 역할과 책임
라이브에 있어서 통계 분석이 갖는 의미
직접 게임 플레이를 하는 것의 중요성
일의 우선 순위에 대한 이해
여러 가지 게임 지표에 대한 이해
팀워크를 위한 마음가짐
• Q&A
26. 참고 자료
• 참고 링크
– 성공하는 라이브조직의 6가지 공통점
• http://www.inven.co.kr/webzine/news/?news=56484
– 메이플스토리: 라이브게임 개발스토리
• http://parkpd.egloos.com/3300918
– 70명이 커밋하는 라이브 개발하기
• http://www.slideshare.net/innover/70-20109362
– 작업장(오토) 탐지에 통계 활용의 예
• http://www.slideshare.net/LeeEunJo/r-14930327
– 서번트 리더십
• http://imaginations.tistory.com/19
