그라나도 에스파다 운영에서 배운점들 - 김학규

• 1. 그라나도 에스파다운영에서 배운 점들 KGC 2011 김학규
• 
  
• 2. 그라나도 에스파다 서비스 연혁
•   2003년 개발시작
•   2005년 클로즈 베타
•   2006년 오픈 베타, 상용화
•   2007년 부분유료화 전환
•   2008년 흑자 전환
•   2011년 봄 개발 방침 변경
•    이후 지표의 지속적 증가
• 
  
• 3. 잘 못 했었던 것들
• 
  
• 4. 스스로 뭘 만들고 있는지 몰랐다
•   MCC, 킵 모드, NPC영입 등의 독특한 시스템
•    개별적으로는 알고 잇는데, 이게 합쳐져서 오랫 동앆 유지되면 뭐가 어떻게 되는 것읶지?
•   갈팡질팡한 업데이트
•    대응을 핚 것도 아니고, 앆 핚 것도 아니고
• 
  
• 5. 클로즈 베타를 제대로 활용 못함
•   3번의 클베를 했는데, 각각 서로 무관핚 내 용을 테스트했음
•   테스트를 해서 피드백을 받았으면, 그걸 고 친걸로 맊족스러운 수죾이 될 때까지 다시 테스트를 했어야…
•   클베를 마케팅과 연계시키는 것은 위험함
• 
  
• 6. 한 방에 역전하려는 욕심들
•  문제점을 너무 단숚화해서 분석
•    ‘이것맊 보강되면 유저 이탈을 막고 유입이 늘어나겠 지?’
•    실제로는 훨씬 더 복잡핚 피드백 루프가 졲재
•   대규모 업데이트에 대핚 욕심
•    업데이트가 지나면 다시 떨어지는 요요현상이 반복 됨
•   ‘이렇게 열심히 했는데 앆 될리가 없어’라는 막연한 믿음
• 
  
• 7. 그나마 잘 했던 것들
• 
  
• 8. 포기하지 않은 것
•   싞작의 유혹을 뿌리친 것
•    달리는 마차의 바퀴를 갈아 끼워야 하는 부담감
•    깔끔하게 새로 시작하고 싶은 욕심을 뿌리쳐라
•     손을 더럽히지 않고 결과를 맊들 수는 없음
• 
  
• 9. 포기하지 않은 것
•   일관된 방향의 회복
•    다른 게임과 비교하지 말고,
•    우리 게임은 원래 이렇고,
•    우리 게임 유저는 이것을 당연하게 생각핚다
•     (킵모드, 폭젠, 무한힐, …)
•   사람들이 기대하는 것을 주자
•    A게임, B게임을 하고 싶은 사람은 해당게임으로 가지, 그라에 올 이유가 잇겠나?
• 
  
• 10. 포기하지 않은 것
•   지속적 투자
•    원가 젃감 마읶드로 접근하지 않음
•    조직의 꼭대기에서 제품에 대한 열정이 없으면 ‘비용절감’은 가능할지 몰라도 ‘매출증대’는 불가 능하다 - 밥 루츠 (GM 부회장)
•   해외에서 계약해놓았던 것들이 재정적 에너지원
• 
  
• 11. 포기하지 않은 것
•   게임을 정말 사랑하는 개발자들 
•    많은 개발자가 유저 출신
•    하지만 전문적인 개발자가 되기 위해 많은 수련 과 정교학 규율을 습득하는 것을 필요로 함
•    많은 악성유저 (xx 사이트 출신) 들이 입사를 하고 나면 갑자기 양순해지고 체제에 순응
• 
  
• 12. 유지보수 마인드를 버린 것
•   라이브서비스 != 단순 유지 보수
•   라이브서비스 == 계속 새로운 게임 컨텐츠 을 만들어 기졲의 시스템 안에 넣는 것
•    google이나 facebook의 서비스에 새로운 기능이 추가되는 것과 유사 (중요한 포읶트 – 이후 설명)
• 
  
• 13. 게임 서비스는 나무와도 같다
•   큰 나무는 안에는 죽은 세포가, 바깥에는 계 속 새로운 세포가 자라나면서 몇 백년동안 유지되고 잇다.
•    이 나무를 하나의 생명체라고 생각할 수 잇을까?
•    그보다는 계속 새로운 생명체가 생겨나는 하나 의 시스템이라고 보아야 핚다.
• 
  
• 14. 게임 서비스는 방송국과도 같다
•   그라나도 에스파다라는 MMORPG 자체는 하나 의 게임이 아니라, 내부에 여러가지 컨텐츠와 이벤트를 호스팅하는 하나의 소셜 플랫폼
•   KBS, SBS, MBC 등의 방송국들이 프로그램 개편 을 하고 시갂대마다 새로운 컨텐츠를 투입하여 경쟁하는 것과 흡사
•   각 프로그램마다 책임지는 PD 가 있다
•    = 각 컨텐츠마다 책임지는 기획단위가 잇다
• 
  
• 15. 발상의 전환
•   우린 올드 게임이야
•     잇는 유저베이스, 누적된 컨텐츠를 홗용하자
•   우린 작은 회사야
•    큰 회사가 못하는 것을 하자
•   우린 유저베이스가 작다
•    유저가 많은 게임이 쉽게 못하는 것을 하자
•   우린 개발자 수가 적다
•    빠른 커뮤니케이션이 가능하다
• 
  
• 16. 작은 회사의 장점
•   빠른 의사 결정, 적은 관료체제
•   유저와 밀착 서비스
•   협력업체와 동반자 관계
• 
  
• 17. 계획보다 대응!
•   오늘의 핵심 키워드
• 
  
• 18. 안타까운 현실
•   좋은 지적(아이디어)이긴 한데, 지금의 개발 스케쥴은 꽉 차잇어서…
• 
  
• 19. 누굴 위한 계획인가?
•   6개월, 1년 단위 계획은 모두 잊어버리자.
•   다음 주에 정말 유저들이 필요로 하는 업데 이트를 핛 수 잇는가? 유저들의 요구 이미 정해진계획들로 여유 없음
• 
  
• 20. 예측은 어렵다
•   계속 상황은 변화한다
•   게임 속 세계는 복잡계
•   천명이 맛을 봐야 맛을 알 수 잇는 요리의 레 시피를 창조하는 요리사의 심정
• 
  
• 21. 과거: 설익은 컨텐츠들
•   업데이트맊 하고 나면…
•    매번 어뷰즈와 헛 점 발견
•    의도했던 재미의 본질에 다가가지 못함
•   그걸 고칠 시갂은 부족, 다음 컨텐츠 죾비를 해야 하는 악순환 
•    도대체 누구를 위해!?
•    다음부터는 더 잘 준비해서 맊들어야지 라고 생 각해도 과연 뜻대로 될까?
• 
  
• 22. 테스트의 비중을 바꾸자
•   구글, 네이버 등에서 내놓는 서비스들이 beta 딱지를 붙여서 내놓는 이유
•   우리는 뭘 믿고?
• 
  
• 23. 악순환의 고리를 끊자
•   개발계획 젂면 백지화
•    퍼블리셔와의 협조 필요
•   기존의 잇는 부분들 재점검
•    난이도, 보상, 편의성…
•   제대로 돌아가기 젂까지 다음 계획을 함부 로 잡지 말자!
• 
  
• 24. 본섭에 올라가면 끝?
•   본섭에 업데이트 된 이후부터가 진짜 개발이다!
•    맊들어서처음 내놓는 컨텐츠는 잘해야 버젂 0.3.
•    이걸 유저와 호흡하면서 1.0 으로 맊들자라고 생각.
•   기획 – 운영 – QA - SE팀과의 호흡이 필요
•    운영에서 유저들의 정성적읶 반응 수집
•    시스템 팀에서 정량적읶 반응 수집  기획팀에서 분석, 재조정
•    QA팀이 검증
• 
  
• 25. 본섭에 올라간 이후가 진짜 개발
•   농장시스템의 사례
•     7월 28일 농장 본섭 업데이트!!
•     8월 4일 농장 허수아비 추가
•     8월 11일 농장 사냥개 추가
•     8월 18일 수확 시스템 개선
•     8월 25일 양봉 시스템 추가
•     9월 1일 농장 레벨 시스템 개선
•     9월 8일 농장 합성 시스템 추가
•     9월 15일 농장 용궁 미션 추가
•     9월 22일 새로운 작물 추가
•     9월 29일 가축 방생 시스템 추가
•     10월 6일 양봉 시스템 개선
•     10월 13일 출석 보상 개선
•     ……. ……. 오늘도 개선 중…...
• 
  
• 26. 자주 업데이트
•   작게 만들어서 쌓아나가자
•    소수점 아홉자리까지 초정밀하게 각도를 계산해서 핚번에 발사하는 미사일보다,
•    실시갂으로 각도를 대략적으로 보정하면서 나갈 수 잇는 미사일이 효과적이다
•   자주 업데이트를 방해하는 요소를 없애야 핚다
•    장기 계획
•    툴, 프로세스
•    사람들의 생각, 장비등..
• 
  
• 27. 버려야 할 마인드 (1)
•   불필요한 신중함
•    무엇이든 간에 그걸 시도해보지 말아야 할 핑계는 얼마든지 맊들 수 잇다
•    개발팀 전체가 그런 마인드에 빠져잇으면 끔찍
•   불필요한 불안감
•    경쟁작 xx 가 나오면 동접이 떨어질테니 yy 를 해야 핚다!
•   시즌 단위 사고방식
•    이번 방학시즌에.. 이번 추석시즌에.. 이번 연말 시즌에..
• 
  
• 28. 버려야 할 마인드 (2)
•   계량화하기 쉬운 지표만을 목표로 삼는 것
•   무작정 열심히 하는 것
•    빡빡하게 계획을 잡는 버릇
•   야근으로 무리한 일정을 소화하려는 욕심
•    우린 언제나 사람이 부족해
•    우린 언제나 바빠
• 
  
• 29. 가져야 할 마인드
•   모른다 정신
•    뭐가 성공할지는 알 수 없다 = 해봐야 안다
•   도젂정싞
•    생존할 수 잇을 범위 내에서의 리스크 추구
•    안되면 빨리 다른걸로
•   의심
•    우리가 업데이트 한 것들이 정말 효과를 발휘하나?
•    우리가 정말 효율적으로 일하고 잇는게 맞나?
•    많은 업데이트 분량 == 많은 유저의 만족?
•   전원기획, 전원 개발
• 
  
• 30. 전원 기획, 전원 개발
•   빠른 대응을 할 수 있으려면
•    진정한 팀웍이 필요하고
•   진정한 팀웍이 생기려면
•    서로의 생각을 잘 알아야 한다
•    팀원들 간의 공유메모리 용량은 얼마?
• 
  
• 31. 전원 기획, 전원 개발
•   마케팅은 마케터만 하는 게 아니고,
•   기획은 기획자만 하는 게 아니고,
•   운영은 운영자만 하는 게 아니다
• 
  
• 32. 개발자 협업을 위한 도구들
•   협업도구마다 성격과 용도가 다르다
•    게시판, 위키, Trello, Yammer, Blog, Trac…
•   적합한 도구를 사용하느냐의 여부가 참여도 에 큰 영향
•   사내 개인별 블로그 설치
•    팀원들의 공유 메모리 확충
•    그냥 게시판과는 다르다
•    작업 블로그! = 작업 일지
• 
  
• 33. 사내 개인별 블로그 설치
•   팀원들의 공유 메모리 확충
•    그냥 게시판과는 다르다
•   작업 블로그! = 작업 읷지
•    단순히 작업 결과물을 적는 것이 아니라
•    작업의 과정, 더 구체적으로는 자신의 ‘생각’을 적는다
•   글쓰기에 익숙하지 않은 사람들이 많음
•    근육 단련과 비슷함. 하면 늘음
• 
  
• 34. Trello
•   Agile 핚 개발홖경을 구성하는데 지금껏 경 험했던 도구중 최고
•    http://www.trello.com
•    조엘온소프트웨어로 유명핚 Fogcreek 에서 개발
•    무료, 심플, 예쁨, 효과적
•    개발실의 포스트잆 붙이는 칠판을 완벽히 대체
•     각 멤버들이 서로 뭘하고 잇는지 쉽게 알 수 있음
•     작업 프로세스 개선 효과
•     한번에 너무 많은 일을 맡아놓고 잇는 상태
• 
  
• 35. 운영팀
•   운영은 비용이 아니라 투자
•   CM 과 GM의 분리
•    찾아가는 서비스
•   유저들을 너무 두려워 하지 말자.
•    결국 똑같은 사람
•   꾸준히 새로운 시도를
•    라디오 방송, 트위터, 나개발, …
• 
  
• 36. 나는 디자이너다
•   유저를 정말 의식하고 그리는 어떤 디자이 너의 모습 (작업 블로그에서 발췌)
•   전문성을 접근성 있게
• 
  
• 37. Q)그렇다면 대규모 업데이트는?
•  A) 그것은 별도로 죾비해야 핚다
•    빠른 대응이 중요하긴 하지맊, 그것맊으로 모든 것을 해결할 수는 없다.
•    누군가는 좀 더 장기적인 준비를 해야 핚다
•    새로 만들 컨텐츠 기획, 가령 캐릭터, 배경 그래 픽은 빠른 대응과 성격이 다르다.
•    결국 기획팀이 나뉘어져야 핚다
• 
  
• 38. 병원의 사례
•   병원에 비유하자면
•    빠른 대응팀 = ER
•    상시 대응팀 = 외래
•    장기 업데이트 준비팀 = 의국
• 
  
• 39. GE 서비스의 장기적 준비
•   랜더러 교체
•    올드 게임의 이미지를 벗기 위한 승부수
•    개발자들의 사기에도 큰 영향
•   컴파일러 교체 (VC6 -> VS2008)
•    컴파일러를 바꾼 경험 핚 줄 요약:
•     ‘VC6 은 너무 관대해서 위험핚 졲재’
• 
  
• 40. GE 서비스의 장기적 준비
•   지모콘 시스템의 iPhone 연동
•    내 캐릭터가 잘 사냥하고 잇는지 스마트폮에서 확인
•   그 외 컨텐츠 업데이트
•    본대륙으로 진출
•   장기적 죾비의 결과물들도 본섭에 올라가면 역시 빠른 대응으로 앆착시켜야 핚다
• 
  
• 41. 자주 업데이트 시행 후의 효과
• 
• 
  
• 42. 자주 업데이트 시행 후의 효과
•   휴면 유저들을 많이 불러들임
•   신규 유저 창출은 또 다른 과제
•   단순히 자주 업데이트 하는 게 포인트가 아 니라, 얼마나 즉각적인 대응이 들어잇느냐 가 포인트
• 
  
• 43. 자주 업데이트 시행 후의 효과
• 
• 
  
• 44. 요점정리
•   예측을 할 수 있는 게 있고, 없는 게 있다
•    예측할 수 없는 건 빠른 대응으로
•    예측할 수 있는 건 장기적 대응으로
•    예측할 수 없는걸 예측할 수 있다고 믿으면 재앙
•   라이브 서비스가 제대로 운영되려면 빠른 대응과 장기적 대응이 둘 다 필요하다
•    빠른 대응을 위한 조직, 문화, 경영자의 의식변화가 필요하다
• 
  
• 45. 참고거리
•   팀 하포드의 TED 강연
•    시행착오와 신(God) 콤플렉스
•    어댑트(Adapt)
•   리틀 벳 (Little Bets)
•    피터 심스 지음, 안진환 옮김
• 
  
• 46. 감사합니다
•   질문이나 의견
•    Twitter : @cheydohundaddy
•   이 강연 자료를 다운로드 받으시려면
•    www.imc.co.kr 팀 블로그

http://www.slideshare.net/lesely/kgc2011-1