지난 2009년 5월 19일 NHN은 보도자료 배포를 통하여 자사의 새로운 게임 유통 서비스인 '아이두게임iDoGame'을 발표했다. 기존 한게임HanGame이 보유하고 있는 유저 풀User Pool을 기반으로 아마추어 게임 개발자들과 이를 연결시켜주겠다는 취지의 서비스인 아이두게임은 최근 IT 업계의 화두인 애플Apple의 앱스토어App Store 전략을 온라인 게임 버전으로 특화시켜낸 것 처럼 보이지만, 전용 게발툴인 게임 오븐Game Oven(2009. 6. 9. 현재 Beta Release Ver 1.00)을 위시한 개발자 지원 정책을 발표하면서 손쉬운 온라인 게임 개발 환경 지원을 통한 아마추어 개발자들의 적극적인 참여를 유도하고 있다.


아이두게임의 지원 정책

현재 NHN에서 밝힌 아이두게임의 개발자 지원 정책을 정리하자면, 손쉬운 형태의 통합 게임 개발툴인 게임 오븐의 무상 제공, 한게임이 보유하고 있는 게임 인프라스트럭쳐Game Infrastructure 제공, 일일 최고 동접자를 기준으로 한 포인트 누적과 상금(현금)의 지급을 내세우고 있다. 이와 더불어 개발자 커뮤니티의 운영, 게임에 필요한 리소스들을 확보하여 오픈소스Open Source화 하여 개발 저변을 확대한다는 목표하에 서비스를 진행시키고 있다.

이는 아마추어 게임 개발에서 오는 어려움들인 제작 자체의 난이도 문제를 전용 개발 툴로 해결하고, 한게임의 막강한 인프라스트럭쳐와 리소스 확보를 통하여 아마추어 게임 개발자들의 온라인 게임 개발 장벽을 낮추며, 또한 실적에 따른 현금 보상을 통하여 실력만 있다면 각 아마추어 팀들이 수익 사업을 펼칠 수도 있도록 하여 긍정적인 유인으로 작용할 수 있도록 한다는 것으로 해석 할 수 있다. 이를 통하여 한게임은 다양하고 아이디어 넘치는 신규 게임 발굴 및 능력있는 개발자에 대한 인재 풀을 형성할 수 있으며, 또한 이후 적용 될 것으로 보이는 부분유료화 모델, 인게임 애드In Game Ad. 등을 통하여 서로가 상생할 수 있는 비지니스 모델을 구축할 것으로 보여진다.


NHN의 함정

NHN 의 입장에서는 아마추어 개발자들을 통하여 신선한 게임을 발굴해내고 그에 따른 상업적인 이익을 취하겠다는 생각은 나쁘지 않아보인다. 사실 아이두게임을 통해 NHN이 상업적으로 당장에 취할 수 있는 이득은 없는 것이 사실이다. 하지만 NHN에 대한 기업 이미지(특히 개발자들을 중심으로 암암리에 퍼져있는 NHN의 독점적인 위치를 등에 업은 횡포에 대한 이미지)를 개선하는 효과를 가져올 수 있다는 면에 있어서는 대단히 긍정적이다. 또한 앞으로의 아이두게임의 사업 확장을 통하여 앱스토어와 같은 개발자-유통사-소비자 상생의 생태계Eco System가 형성될 수만 있다면 NHN으로써는 아이두게임의 소기의 목적을 달성하게 될 것이다.

하지만, 이를 위해서는 넘어야 될 산이 수도 없이 많다. 무엇보다 지금까지 발표 된 아이두게임의 여러 정책들은 아마추어 제작자 위주의 정책들이 우선이며, 때문에 개발자-유통사-소비자 모델이 아닌, 단순한 게임 공모전과 비슷한 분위기가 흐르고 있다. 흥미위주의 아마추어 개발자들의 참여는 성공적으로 이끌어냈지만, 진정한 비즈니스 모델을 구축하기 위해서는 좀 더 상위 클래스-준 프로, 또는 영세 개발자 집단-의 개발자들을 아이두게임으로 끌어들일 필요가 있으나, 지금과 같은 정책으로는 이들을 잡기에는 역부족이다.

공모전은 어디까지나 이벤트일 뿐

상위 클래스의 개발 집단의 참여를 위한 유인으로 아이두게임 리그 같은 공모전 보다는 성공적인 수익 모델을 제시해 주는 것이 훨씬 효과적이다-이는 이미 애플의 앱스토어 정책으로 그 효과가 입증되었다. 아이두게임에서는 '인기 보너스' 제도를 통하여 보상을 지급한다고 밝히고 있지만, 이 역시 공모전의 상금의 개념으로 봐야 할 뿐, 상업적/준상업적 게임의 수익과 직결시키기에는 무리가 많다.


상업적인 접근의 한계

자, 여기 영세한 규모의 게임 제작 그룹이 있다. 기획 1, 그래픽 1, 프로그래밍 1, 총 3인으로 구성된 팀으로, 각자 일당 백의 실력을 가지고 있으며, 화려한 개발 이력을 거치며 게임 업계에서 생활해왔지만, 힘든 월급쟁이 생활과 자신이 하고 싶은 것을 만들고 싶다는 욕망에 각자 회사를 박차고 나와 팀을 결성했다. 이들의 목표는 아이두게임에 자신들이 개발한 게임을 런칭하여 "인기 보너스"를 통하여 수익을 얻는 것. 자, 이들은 과연 자신들의 욕망과 성공을 동시에 거머쥘 수 있을까?

NHN 에서 제시한 "인기 보너스"는 '일일 최고 동시 접속자 수' * 100원을 기준으로 볼 때, 일일 최고 동접자 수가 1,000명씩 한달(30일 기준)을 유지할 경우 이들의 한달 평균 수익은 약 300만원을 예상할 수 있다. 여기에 상금에 붙게되는 세금(총 금액의 22% = 약 66만원)을 제하고 나면 약 230만원 정도를 만질 수 있게 된다. 즉, 동시 접속자가 1,000명이 한달간 유지된다고 했을 때, 팀원 1명이 받게되는 금액은 월 약 77만원 정도가 되게 된다. 여기에 게임을 개발하는데 들어가는 각종 비용과 시간은 전혀 고려되지 않았다(실질 소득은 더욱 줄어든다는 이야기다).

동시 접속자 수 기준 포인트 누적 시스템

그렇다면 동시 접속자 수를 10배인 10,000 명으로 유지시키는 초 대박 게임을 만들면 어떻게 될까? 마찬가지의 계산으로 1인당 돌아가게 되는 금액은 월 약 770만원이 된다. 오, 이거 괜찮은걸? 이라고 생각하는 순간 함정은 시작된다. 일일 동시 접속자 1만명을 유지시키는 MMO 게임도 손에 꼽는 마당에 (아직까지는)조악한 개발 툴을 가지고 열정과 끈기로로 만든 게임이 과연 일일 동시 접속자 수를 1만명에 도달이나 할 수 있을까 하는 경험적인 문제가 생각을 가로막는다. 사실 잔인한 이야기지만, 1만이나 1천은 커녕 1백도 도달하기 힘들다. 어째서일까?

아이두게임의 모든 게임들은 한게임에서 서비스된다. 국내 계정 수만 3천만이라는 숫자는 어마어마한 분명 어마어마한 잠재 시장이지만, 이는 곧 한게임에서 서비스 중인 다른 여러 게임들(MMORPG 부터 고스톱/포커 등의 보드 게임 까지)과 경쟁을 벌여야 한다는 것을 의미하기도 한다. '당신이 세달 정도의 기간동안 9M/M을 투입하여 만든 조악한 게임은 미안하지만 몬스터 헌터 프론티어 온라인Monster Hunter Frontier Online, 테라Tera, C9, 혹은 한게임 포커와 경쟁을 해야 한다'라는 것은 곧 그 게임들과 경쟁해서 그들의 유저를 조금이라도 더 가져와야 된다는 이야기이다. 이런 상황에서 과연 일일 동접 1천이 가당키나 한 이야기일까?

당신이 아무리 잘났어도 이런건 혼자 못 만든다

아이두게임이 보다 안정적으로 성공하기 위해서는 한게임의 그늘에서 벗어나야 한다-아에 자체로 독립적인 브랜드 전략을 가지고 일이 진행되었어야 위와 같은 사태를 막을 수 있을 것이다. 한게임 내에서의 서비스는 이러한 독소 요소를 가지고 있으며, 이를 해결하지 못하면 아이두게임 자체의 성패에 큰 영향을 미칠 수 있다는 것을 알아야 한다.


NHN의 전략적 오류

위에서 이야기 한 대로, 아이두게임에서의 상업적인 접근은 당장에 힘들며, 때문에 아마추어 개발자 이상의 개발자들을 끌어모으기에는 많은 무리가 따른다. 결국 온라인 공모전과 같은 분위기가 지속되면 생태계는 활성화 될 수 없는 것은 불보듯 뻔하다. 공모전이란 것은 무엇보다 사용자가 배제되어 있으며, 이에 흥미를 가질만한 대상도 아마추어 풀 이상이 형성되기도 힘들다, 인력 풀이 고정되어 있으면 결국에는 도태되기 마련이다.

아이두게임이 소기의 목적을 달성하기 위해서는 개발자들에게 지금보다 좀 더 구체적인 희망을 보여줄 필요가 있다. 이를 위해서 NHN은 제작자와 사용자를 어떻게 연결 시켜줄 것인가에 대한 고민, 국내에서는 부족하기만 한 개발 인력 풀을 어떻게 확보해야 할 것인가에 대한 고민, 그리고 이들이 실질적으로 원하는 것이 무엇인가에 대한 고민이 필요하다-이에 대한 고민으로 나온 것이 고작 연회비 면제, 게임 심의 비용 부담 인 걸 보면 한심해서 말이 안 나올 지경이긴 하지만...

아이두게임에는 미안하지만 아직은 인디 게임의 희망은 되지 못한다(사실 개인적으로 아이두게임의 정책 방향이 앱스토어 모델 보다는 벨브Valve의 스팀Steam 모델이 되었으면 어떨까 생각을 해 보지만 이건 또 이것 나름대로 문제가...). 하지만, 무엇이 되었든 간에, 간만의 좋은 사업이 준비되지 못한 정책들로 인하여 좌초되는 일은 없길 바랄 뿐이다.

크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by Irene

2009/06/10 00:18 2009/06/10 00:18
, , , , , , ,
Response
2 Trackbacks , 8 Comments
RSS :
http://www.heartcomplex.net/blogs/rss/response/528

이상한 의사 결정 과정.

얼마전 회사의 로컬 및 해외 마케팅 담당에게 해외 업체에서 메일이 왔다는 이야기와 함께 메일 전문을 나에게 보여주었다. 내용인 즉, 우리 회사의 명함과 데모 CD를 이번 지스타에서 받아보았으며, 혹시 아이폰 게임 제작에 관심이 없겠냐는 것.

결론부터 이야기하자면 회사의 윗분들은 그다지 생각도 안 해보고 '관심 있으니 구체적으로 이야기 해 보자'며 답장을 보낸 상태다. 회사의 입장이 별로 좋지 않기 때문(이번달 전체 사원들의 급여는 일부만 지급되었다)에 다급한 입장은 납득할 만 하지만, 단순히 그것 때문에 벌써부터 아이폰/아이팟 터치 용 게임 어플을 제작하겠다고 단가 등을 타진하며 시끄럽게 굴고 있다.

그 난리를 옆에서 좀 떨어져서 지켜보고 있자면 어처구니가 없어서 헛웃음이 나올 지경인데, 현재의 회사 상황에 대해서는 단지 급하다는 점 이외에 개발 가능 여부나 MM의 투입, 필요 예산과 제작시 얻을 수 있는 이익에 대한 고려가 전혀 없이 무작정 '돈되는 일이면 한다'라는 주먹구구식의 의사 결정을 하고 있기 때문이다.

사실 회사는 게임 제작이 주 분야가 아닌 웹 에이전시 및 출판 디자인이 전문인 회사였다. 게임 관련 사업부를 운영한것은 이제 1년 남짓으로 그나마의 전문 분야도 설치형 게임이 아닌 Adobe 사의 Flash와 Action Script를 위주로 한 Flash Game이 전문 분야이다. 즉, 게임 제작에 대한 경험도 아직 부족할 뿐더러, App SDK를 이용한 소프트웨어 제작은 회사 내 경험자가 단 한명도 없다-아니 애초에 Mac을 사용해 본 유저가 개발자 중에서는 전무하며, 유저 경험도 단 한명만이 아이팟 터치를 가지고 있을 뿐이다.

개발 환경에 대해서 그닥 밝지 않은 사람들을 구성하여 해당 소프트웨어를 제작한다고 하는 것만으로도 충분한 위험 요소가 되겠지만, 사실 이것보다 더 많은 위험 요소가 존재한다, 자금 사정에 여유가 없는 회사 사정은 이미 앞서 이야기 했으며, 이와 얽혀서 게임 제작 프로젝트는 벌써 1인당 할당 프로젝트가 4개를 넘어가고 있다(15명 남짓한 인원에 팀 전체 프로젝트는 약 10여개가 진행중이다). 스케쥴에 따른 우선순위에 맞춰서 투입 인력이 일주일마다 바뀌는 일도 예사이기 때문에 모 포털에 납품하려는 서비스는 그래픽 디자인이 일정치 않는다는 이유로 클레임과 런칭 일정 연기가 된 것도 벌써 네달이 다 되어가고 있는 형편이다.

이런 문제들에 비하면 부서간 반목이나, 책임전가 등의 행태는 차라리 애들 장난 같은 일에 불과하다.

이 와중에 경영진은 '돈만 맞으면 한다'라고 전략 결정을 내린 것이다.

장기적인 측면에서의 기술 획득을 위한 전초전이라고 생각한다면야 그리 기분 나쁠 것도 없겠지만, 진짜로 별로인 것은 회사가 위급하니 독인지 사과인지도 가리지 않고 먹으려고 덤벼드는 행태이다. 현재 진행중인 다른 프로젝트와의 관계, MM 배치, 인력 구성, 보유 기술등을 고려한다면 저렇게 쉽사리 진행하자는 말이 단번에 나오지는 않을 것이다-어느정도 쉽게 나왔냐면 그 메일을 보자 마자 1초의 고민도 없이 단번에 대답했다고 한다.

그나마 다행인 건 예상으로 그 발주 업체는 아마도 우리 회사가 충분히 만족 할 만한 금액을 제시하진 않을 것이란 것 정도이다. 아니, 제발 어처구니 없는 가격을 제시해 주길 바란다. 진심으로.

크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by Irene

2008/12/14 14:11 2008/12/14 14:11
, , , ,
Response
No Trackback , No Comment
RSS :
http://www.heartcomplex.net/blogs/rss/response/487

이 문건은 회사 내부에서  이슈추적과 개발 프로세스와 관련한 의견을 취합하기 개인적으로 작성했던 문서로, 겸사겸사 스스로의 생각도 정리하자는 의미에 비중을 둔 문서였다. 여러가지 사정으로 문서 자체는 지금 현재로써는 회사 내부의 여러사람들에게 묵살당한 모양이지만, 행여나 비슷한 고민을 하는 분들이 계시다면 한번 생각을 공유해 보았으면 하는 생각에 전문을 올려본다.

----

이슈 트래킹을 왜 쓰는가에 대한 고민과 어떻게 쓰는가에 대한 고민이 필요하다고 생각 함.


  1. 일차적 이용 목적

    • 버그 발견 시 해당 버그에 대한 단일 리포트 창구 필요
    • 취합된 버그에 대한 발견-처리-결과에 대한 개별 프로세스별 정확한 통제(Control) 및 관리(Management) 목적
    • 문제가 되는 이슈의 통계 처리를 통한 개발 진척사항 및 마일스톤의 관리 - 업무 중복의 회피
    • 커뮤니케이션의 극대화
  2. 쓸 수 있는 App

    • 맨티스(Mantis) : 전형적인 이슈 트래킹 어플리케이션. 이슈 리포트에 대한 세부적인 옵션 컨트롤이 가능하며, 간단한 기능과 한글화가 장점. 단점으로는 지나치게 많은 리포트 옵션과 시각적으로 깔끔하지 못한 인터페이스-현재 사내 서버에 Mantis가 설치 되어 있으나 사실상 용도 폐기 상태 임.
    • 트랙(Trac) : 이슈 트래킹 및 프로젝트 매니지먼트 기능 등이 결부되어 있는 어플리케이션. SVN과 연동하여 개발 소스에 대한 열람이 자유롭고, Wiki를 통한 프로젝트 문서화가 손쉽다는 점, 마일스톤 및 연표 기능으로 프로젝트 진행 상황 확인이 용이하며 인터페이스가 깔끔함. 단점으로는 현재 최신 버전에 대한 한글 버전이 존재하지 않음(한글화는 Ver 0.10.4에서 종료. 현재 릴리즈 된 버전은 0.11.4, Ver 0.12 부터 다국어 지원 예정)-대표적인 Trac 사용 프로젝트(국내)의 예로 태터 앤 컴퍼니의 텍스트 큐브 개발 페이지(http://dev.textcube.org/) 및 제로보드 개발 페이지(http://trac.zeroboard.com/trac/wiki).
    • 버그질라(Bugzilla) : 해외 오픈소스 계열 이슈 트래킹 어플리케이션 중 가장 유명한 어플리케이션으로 모질라 재단, NASA 등의 프로젝트에서 사용중이며, 강력한 통계 처리 기능이 장점. 사용이 복잡하고 한글화가 전혀 되어있지 않다는 점이 가장 큰 단점
  3. 프로세스 중 적용 범위 (1차)

    • 이슈 트래킹 : 버그 및 개선 사항에 대한 '보고 - 처리 과정 - 결과 확인' 의 프로세스에 대한 통제
    • 제품 품질 완성도에 대한 정량적인 측정 : 버그 발생 및 처리, 잔여 이슈에 대한 정략적인 측정
    • 난립되어 있는 문서의 통일 : 각종 양식의 버그 리포트의 통폐합
  4. 프로세스 최종 적용 범위

    • 프로젝트 별 난립되어 있는 문서의 템플릿 통일화
    • 수동적이고 책임 회피적인 업무 진행에서, 전체 구성원의 책임감 고양 및 자발적인 업무 참여 유도
    • 전체적인 프로젝트 제작 프로세스에 대한 재 검토 및 효율화를 위한 개선
    • BPR(Business Process Reengineering)
  5. 도입 시 장기적으로 예상되는 문제점과 해결 방안

    • 관리자 부재로 인한 개점휴업 상태 발생 : 관리 담당자의 지정 및, 각 프로젝트 참여자의 의무 사용 독려(자율적인 참여 방식과 더불어 강제적인 사용 의무화 방안도 포함 되어야 함 : 갱신 사항에 대한 메일링 리스트 확인, RSS 리더의 강제 등록 등으로 이슈가 발생하고 등록되는 즉시 각 구성원이 최대한 빠르게 파악 할 수 있는 시스템 구성은 별도의 문제임)
    • 발생된 이슈에 대한 사용자 전체의 적극적인 참여를 어떻게 이끌어 낼 것인가? : 이슈 트래킹을 이용하는 기본 프로세스는 상명하달 식의 업무 구조가 아닌, 개인이 각자 일을 찾아서 진행하는 '자발적 참여'를 전제로 함. 수동적이고 피동적인 조직 문화를 변경해야 할 필요가 발생 할 수 있음.
    • 변화에 대한 지속적인 수용력 필요 : 이슈 트래킹을 도입하는 것은 작게는 버그 트래킹 프로세스의 변화에서 부터 크게는 전체 프로세스의 변화를 필연적으로 가져오게 될 수 있으나, 각 구성원 전체에 변화에 대한 인식 수용이 없이는 '변화에 대한 저항'이 발생할 가능성이 아주 높음. 지속적인 변화 및 개선에 대한 전 구성원의 공감대가 필요한 사항이며, 관리계층은 이를 뒷받침 해 줄 수 있는 능력을 확보해야 함.
    • 프로젝트 일정에 따른 프로세스 통제가 불가능하게 될 경우 : 일단 그런 상황이 발생하지 않도록 만들어야 하며, 만약 통제 불가피한 상황이 발생할 경우라도 기본적인 프로세스는 유지한다는 의지가 필요

----

아무것도 없는 상태에서 이런 이야기를 꺼내는것도 어려운 일임에도 불구하고 내밀었건만, 이를 관철시키는 것은 더욱더 힘든 이야기라는 사실에 오늘도 잠깐 우울한 기분이 들었던 하루.
크리에이티브 커먼즈 라이센스
Creative Commons License

Posted by Irene

2008/09/17 23:25 2008/09/17 23:25
, , , , , , , , ,
Response
No Trackback , No Comment
RSS :
http://www.heartcomplex.net/blogs/rss/response/482