저도 유행 따라 짤방 하나 투척...

TA는 프로그래머인가?

넥슨 컨퍼런스에서 TA에 관한 패널 토크에 패널로 참여를 준비하기 위해서 그래픽 아티스트들이 TA에 대해 어떻게 생각하는지 간단히 조사했던 적이 있었습니다. 당시 조사 자료는 회사 하드 어딘가에 있어서 지금은 기억나지 않지만 가장 인상적이였던 대답은 '프로그래머' 라는 대답이였습니다.

그런데 프로그래머에게 똑같은 질문을 하면 어떤 대답이 나올까요? 아직 설문 조사를 해보진 않았지만 정말 다양한 대답이 나올 것으로 예상됩니다. 하지만 '프로그래머다' 라는 대답은 나오기 힘들 것으로 생각됩니다.

여담이지만 프로그래머들 사이에서도 '프로그래머' 라는 호칭이 붙기 위한 기준이 참 다양하더군요. 경험상 프로그램을 잘 하는 사람일 수록 '프로그래머' 에 대한 기준이 엄격했던 기억이 납니다.

저는 TA가 아티스트라고 생각합니다. 단어에서 이미 답이 나와 있거든요. 테크니컬한 아티스트라는 뜻입니다. (Technical) Artist 라는거죠. 어쨋든 아티스트인데 테크니컬하다는 단어입니다.

비슷한 경우가 또 있는데요, 비주얼 프로그래머라는 역할이 있더군요. 이 사람은 프로그래머입니다. 시각적인 효과에 관련된 프로그래밍을 해서 비주얼 프로그래머라고 부르는 것으로 생각됩니다. 액션 영화에서 무술을 담당하는 무술 연기자는 무술가일까요 연기자일까요? 시작을 무술로 했더도 저는 연기자라고 생각합니다.

그런데 '문법상 TA는 아티스트다' 라는 말을 하려는건 아닙니다. TA가 하는 역할을 자세히 살펴보면 프로그래머는 아니라는 사실을 알 수 있습니다.

TA의 역할 분류

이 중에서 프로그래머라고 볼 수 있는 항목은 쉐이더와 스크립트 툴 정도입니다. 전반적인 TA의 역할은 프로그래머 이외의 것들이 더 많죠.

하지만 쉐이더와 스크립트 역시 프로그래머라고 보기에는 무리가 있다는 생각입니다. 게임에서 쉐이더는 최적화라던가 게임의 그래픽 옵션 연동이라던가 저사양 그래픽카드 지원 등 꽤나 하드코어적인 이슈들이 많아서 프로그래밍만으로 오랫동안 고생해온 사람들에게도 쉽지 않은 일입니다.

스크립트 역시 그래픽 아티스트의 단순 반복 작업을 개선해주는 간단하고 귀여운 것들이라면 상관 없지만 오브젝트를 배치하는 등 게임의 핵심적인 기능을 스크립트 툴로 구현하려고 하는 시도는 좋지 않습니다. 예를 들어 툴을 개발한 스크립터가 퇴사한 뒤에 게임의 핵심적인 기능을 수행하는 툴을 수정하거나 업그레이드 해야할 일이 생기면 곤란해집니다. 아마 대부분의 프로그래머들이 맥스 스크립트 자체를 들여다보는 것을 꺼려할테고 들여다보더라도 조악한 수준의 스파게티 코드를 보면 기겁을 할테니까요. 혹시나 천재적인 스크립터가 아름다운 구조로 툴을 만들었을 수도 있겠지만 그런 사람이라면 맥스 스크립트로 툴을 만들지 않았을거란 생각입니다.

마야의 MEL 스크립트는 그나마 나은듯 하지만 게임 개발 환경에서 핵심적인 기능을  맥스 스크립트에 의존하게 될 경우 치명적인 단점이 또 있습니다. 맥스 자체가 버그 덩어리라는 점입니다. 오브젝트 20개에서 잘 되던 툴이 200개가 되면 메모리 오류가 나면서 맥스가 뻗어버리는 일들이 정말 많거든요. 이런 일이 생기면 오토데스크에 건의해서 맥스를 고쳐달라고 해야할까요?

사실 프로그래머로서 재능이 있는 TA들이 종종 있습니다. 또한 프로그래머 못지 않은 쉐이더 코드를 만들 수 있는 사람들도 있구요. 하지만 예외적인 경우 말고 일반적으로는 TA가 만드는 쉐이더 코드는 프로그래머와 대화하기 위한 도구로 사용하는 것이 가장 바람직하다고 생각합니다.


전부 다 해야 하는건가?

역할 분류를 보면 참 다양한 일을 하는게 TA입니다. 그렇다면 이 모든 것들을 다 해야 할까요? 그렇지 않습니다. 대부분의 경우 현재 팀원의 능력에 맞게 본능적으로 역할을 분배하게 됩니다.

사실 TA라는 명칭이 생기기 전부터 TA의 역할은 누군가에 의해 수행되어 오고 있었습니다. 대부분 경험 많은 그래픽 팀장이나 아트 디랙터에 의해서 작업 효율 향상이라던가 작업 프로세스의 문서화라던가 프로그래머와의 커뮤니케이션이 이루어져 왔습니다.

앞서 적었던 TA의 역할 분류에서 문서화라던가 조율에 관한 부분들은 수 많은 실전 경험 없이는 수행하기 어려운 역할이며 'TA가 교육될 수 있는 것인가' 하는 질문에서 가장 어려운 부분이기도 합니다. 반면에 엔지니어링에 관한 부분은 프로젝트를 수행해본 경험이 별로 없어도 가능하고 교육도 가능합니다.


TA의 성장 트리

요즘 기준에서 TA가 되려면 어떻게 해야하는지를 생각 해보면 두 가지 정도 방법이 있는 것 같습니다.

그런데 여기서는 프로그래머가 TA로 성장하는 것에 대해서는 배제했죠. 그 이유는 TA가 일단 아티스트이기 때문입니다. 과거에는 프로그래머였지만 현재는 아티스트다 라는 경우가 있을 수 있습니다. 그래도 그 사람은 어쨋든 아티스트입니다. TA를 하려면 아티스트에 대한 이해가 더 우선되어야 한다고 생각합니다. 왜냐하면 어쨋든 아티스트이니까요.

아티스트가 아닌 사람이 TA 역할을 하는 것에 대해서는 개인적으로 부정적인 생각입니다. 아티스트가 가려운 곳을 긁어주진 않고 오버 엔지니어링을 하기 쉽거든요.


팀 내 커뮤니케이션

TA는 이처럼 생각보다 넓은 영역의 역할을 수행할 수 있고 그래야 합니다. 하지만 현실은 그렇지 못한 경우가 많습니다. 간단한 예를 한가지 들어보겠습니다.

어떤 개발 팀에 유명한 원화가로 이름을 날리던 사람이 아트 디랙터 역할을 하고 있습니다. 그런데 이 사람은 기술적인 부분이 취약한데다 요즘 개발팀에 TA는 다들 있는거라고 해서 스크립트와 쉐이더를 작업할 TA를 뽑습니다. 신입 TA는 열심히 시키는 대로 툴을 만들고 게임용 쉐이더를 만들지만 게임의 프레임은 안나오고 아티스트들은 버그 많다고 툴은 안씁니다. 또한 파트장 회의라고 해서 기획팀장과 프로그램 팀장과 아트디랙터와 프로듀서가 참여하는 회의체에서 아트디랙터는 기술적인 부분을 몰라서 비 효율적인 진행이 됩니다. 그래서 앞으로 모든 회의마다 TA를 참여시켜야겠다고 생각하지만 비슷한 취지로 추가되어야 할 인원이 갑자기 너무 많아집니다.

쓰고 보니 간단한 예는 아니군요.

기술적인 기반이 없는 사람은 아트 디랙터로 적합하지 않다고 쓴 예는 아닙니다. 저는 오히려 아트 디랙터라면 기술적인 기반보다 아트의 비젼을 제시할 수 있는 능력이 더 중요하다고 생각합니다.

어떤 사람이라도 아트의 감각과 기술적인 능력을 동시에 충분히 가지기란 쉽지 않습니다. 하지만 게임 개발의 아트 팀에서는 이 두 가지 능력이 동시에 필요하기 때문에 해당 팀원들의 스펙에 맞게 유연하게 역할을 조율해야 하고 대부분 그러고 있습니다.

그렇다면 TA가 굳이 아트 디랙터나 그래픽 팀장이 아니더라도 TA의 전체 역할이 잘 수행되려면 어떻게 해야할까요? 전문적인 TA이면서 모든 역할을 하려면 어떻게 해야할까요?

이 질문에 대한 답은 아직까지 확실히 결론이 나지 않았지만 팀내 개발 커뮤니케이션을 개선해서 해결해야 한다고 생각합니다. 개발에 관한 중요한 결정을 몇몇이 결정하고 나머지 사람들은 그저 시키는 일만 군소리 없이 해야하는 폐쇄적인 커뮤니케이션에서는 TA 뿐만 아니라 다른 모든 역할도 제 기능을 못할 것입니다.

반대로 만들려는 게임의 청사진과 의사 결정의 과정이 투명하게 공유되고 활발하게 의견이 오고가는 팀에서라면 말단 신입 TA라도 충분히 조율할 수 있는 여지가 있으며 TA로서 빠르게 성장할 수 있다고 생각합니다.

결국 TA의 역할이 제대로 되기 위해서는 팀내 커뮤니케이션이 중요하다 라는 말인데요, 팀내 커뮤니케이션이 잘 되면 TA만 행복한건 아니겠죠. ^^

ps. 대마왕님 엄청 멋지고 길고 재미있는 글 쓰시는데 저는 언제나 짧고 간단하게 날로 먹습니다.

게임 등급 심의 업무 이양

모두들 아시다시피 작년 말 게임물심의등급위원회(이하 게등위)의 재정 지원을 올 해를 마지막으로 하기로 결정이 내려졌습니다. 모두의 염원대로 게등위가 이제 시한부의 길을 걷게된것입니다. 게등위에서 하던 등급 심의 업무는 문화체육관광부(이하 문화부)에서 지정하는 민간 단체로 이양하기로 되어 있습니다. 문화부는 이 업무를 한국게임산업협회(이하 게임협)에 맡기고자 하는의지를 보이고 있고, 게임협은 심의 기관 설립을 추진중입니다. 별 탈만 없다면 그리 나빠보이지 않는 행보입니다.

사실, 원래는 게등위가 점차적으로 민간 기관으로의 업무 이양을 준비해왔어야 했으나 그러질 않았습니다. 그렇기에 몇 차레의 경고 끝에 재정 지원을 차단하게 된 것이지요. 게임협 역시 마찬가지로 넋놓고 가만히 있었기에 제대로 된 준비가 되어 있지 않은 상태입니다. 때문에 업무의 이양이 탈 없이 이루어 질 지가 걱정이였습니다. 

하지만, 별 탈이 생기려는 움직임이 일어나고 있습니다. 역시나 여성가족부(이하 여가부)에서 이에 제동을 걸고 있는것입니다. 여성가족위원장 최영희(셧다운 제도의 핵심 인물) 의원이 보도자료를 통해 심의 업무를 게임협에 이양하는 것에 대하여 반대 성명을 냈습니다. 참으로 치졸하기 짝이 없는 언론 플레이가 아닐 수 없습니다. 겉으로는 게임협으로의 심의 업무 이양을 반대하고 있지만, 사실상으로는 심의 업무를 여가부에서 가져가겠다는 의지를 표명하고 있음을 알 수 있습니다.

보도자료 전문 : 고양이에게 생선을 맡기는 문광부에 우려를 표한다! 

 사실 여가부에서 그동안 꾸준히 게임으로 마수을 뻗어왔던 것은 다들 아시는 사실입니다. 그렇기에 이런 보도 자료를 낸 것은 그다지 새로울 것도 없습니다. 셧다운 제도를 주도적으로 발의하고, 문화부와의 힘싸움에서 이겨서 시행하는데 성공을 했습니다. 하지만 여가부에서는 이에 그치지 않고 게임 산업에 대한 제어권을 통채로 가져가고자 하는 의지를 항상 보여왔습니다. 

 역시나 그 최종 목적은 돈이겠지요. 사실 그럴수 밖에 없는 것이, 꽤 오래전 부터 여가부에 대한 존폐 논란은 항상 있어왔습니다. (여가부의 폐지 당위성은 이 글에서는 논외로 합니다.) 현 대통령의 공약 중 하나가 "여성부 폐지"였을 정도로 그 위상은 땅에 떨어져있었지요. 현 정부가 시작되면서 여가부가 폐지되지는 않았지만 예산은 95%가 삭감될 정도로 찬밥 신세였습니다. 그렇기에 여가부는 항상 재정적으로 시달려 왔었고, 돈 나올 구멍이 항상 필요했었지요. 그러면서 자연스레 게임을 사냥 목표로 삼게됩니다. 
 게임이야 항시 학부모들의 눈에 가시같은 존재였고 이를 이용하여 청소년을 보호한다는 명분으로 돈을 뜯어내기 위한 작업을 시작합니다. 하지만 반대 여론도 만만치 않기에 나름대로 힘들게 어찌 어찌 셧다운 제도를 발효시킵니다. 적용 범위도 항상 문화부와 싸워와야 했고, 뜻하지 않은 배틀넷의 패기도 만나며 힘든 싸움을 하고 있었습니다. 
 근데 적절한 시기에 대구 중학생 자살 사건이 터집니다. 모든 화살은 게임을 향해 날아오고 있고 여가부 역시 이 여론을 등에 업고 칼날을 더욱 적극적으로 들이 대고 있습니다.

아시다시피 현재 여가부에 의해 강제적 셧다운( 12시부터 6시 사이에 무조건 청소년의 접속 차단)이 시행되고 있습니다. 이제는 거기다가 문화체육관광방송통신위원회(이하 방통위)에 의해 추가적으로 선택적 셧다운(부모의 요구에 의해 접속 시간 차단)의 시행을 앞두고 있습니다. 이제는 교육과학기술부(이하 교과부)에서 연령별 셧다운(연령대별 총 이용 시간 제한)이 추진 준비중에 있습니다. 

 여가부와 방통위의 완력 다툼으로 규제의 칼날을 이중으로 내밀었고, 이제는 교과부에서도 그 칼날을 보태고 있는 것입니다. 책임감 없는 정부 기관들이 근본적인 시스템 수정은 생각하지 않고, 모든 책임을 게임에게 씌우며 마녀 사냥을 본격적으로 시작하고 있는 것입니다.

마치며

 정말로 게임이 청소년에게 근본적인 해가 되는 것일까요? 게임을 하지 않으면 청소년들이 행복해 지는 것일까요? 정부 기관들이 꼼수가 아닌 정말 깊게 생각하고 제도를 시행하는 것일까요? 정말로 그러하다면 게임 업계는 이러한 규제들을 충분히 감내하고 읍참마속하는 심정으로 청소년들의 접속을 차단 할 것입니다. 하지만 누가 봐도 전혀 그런 순수한 의도가 아님을 알 수 있습니다. K-POP보다 4배 이상 외화를 벌어들이는 황금알을 낳는 거위의 배를 가를 속셈이 뻔이 보입니다. 교내 폭력을 바로잡지 못하는 무능한 교육 기관이 책임을 떠 넘기려는 속셈이 뻔히 보입니다. 여론의 뭇매를 피하고 표심을 얻기 위해 마녀 사냥을 하려는 속셈이 뻔히 보입니다. 정부가 진정으로 청소년들을 위하는 정책을 펴고자 한다면 이 어설픈 마녀사냥을 중단하고 제대로 된 정책을 강구해야 마땅 할 것입니다. 

기타 고리들 

정부와 가정의 책임을 왜 게임사에게 넘기나

원래 오늘(27일) 기획 포스팅을 할 예정이었으나 회계 포스팅에 삘이 제대로 꽂혀서 포프님의 눈초리에도 불구하고 그냥 배째고(!) 회계 포스팅을 써봅니다.

지난 회에서는 계정과목에 대한 기초와 더불어 게임개발사 프로젝트의 예산 가운데 가장 큰 비중을 차지하는 급여와 복리후생비에 대해서 살짝 알아봤습니다. 그러면 이번에는 인건비 이외에 또 어떤 비용이 필요한지에 대해서 살펴보도록 하죠.


인건비, 그거 말고 또 뭐가 필요해?

일단 사람을 뽑아서 독립된 개발팀을 운영하려면 일단 업무할 공간이 필요하겠죠. 뭐 소규모 개발팀이 자체 건물을 보유하고 있을리는 만무할 터이니(하지만 창업자가 재벌 아들이라면...?) 당연히 사무실을 임대해야 겠죠. 그러면 월세(임대료)와 관리비가 들어갑니다. 뭐 초기에는 보증금도 필요하지만, 보증금은 나중에 돌려받는 돈이기 때문에 회계상으로는 비용이 아닙니다. '자산'으로 분류되죠.

월세와 관리비는 사무실의 지리적 위치, 규모 등에 따라 좌우되는데요. 다들 아시다시피 강남의 노른자위에 큰 평수를 구하려면 월 천만원씩은 그냥 날아갑니다. 명색이 회사인데 월 천만원 뭐 그정도야... 할 수 있겠지만 천만원이면 하루에 33만원입니다. 아무것도 안해도 그냥 매일 PS3 한 대씩 건물 옥상에서 던진다고 생각하시면 '아 이거 장난이 아니구나'라고 확 와닿을 겁니다. - 만약 옥션 최저가로 구매한다면 금요일 퇴근할 때 한대 더 던질 수 있습니다.

그래서 보통 소규모 신생 개발사들이 구로나 가산 디지털단지로 빠지거나 아니면 지역자치단체 등이 저렴하게 제공하는 건물로 들어갑니다. 이런 곳을 잘 구하면 강남 테헤란로와 비교해서 절반 이하로 비용을 절감할 수 있죠. 물론 그 대신에 명함의 회사주소에서 뿜어져 나오는 '강남간지'는 사라지지만, 그 간지 살리는데 드는 막대한 비용을 생각하면 그냥 돈벌기 전까지는 꾹 참는 것이 좋습니다. 돈도 못벌면서 곧 죽어도 강남에 있어야 한다고 테헤란로에 소규모 개발사 세팅했다가 잘 된 회사는 못 본 것 같군요.

뭐 이런 월세나 관리비는 거의 고정비이기 때문에 예산에 반영하는 건 아주 쉽습니다. 따로 설명할 필요가 없겠죠. 다만 경험에서 우러나오는 팁을 좀 알려드리자면 에어컨을 가동하는 여름철 전기세가 많이 나오기 때문에 다른 때 관리비의 2배 이상 나올 수 있다는 점을 감안하셔야 하고, 전기세, 전화료 등 각종 이용요금은 실제 사용한 달의 다음 달 말일에 납부한다는 점을 감안해서 예산 계획을 짜야 합니다. (전문용어?! 로 M+1월 정산이라고 하죠) 그러니까 예를 들어, 9월 예산 짤 때 "아~ 이 달은 에어컨 별로 안 틀 테니 관리비 적게 나오겠지" 라고 생각하면 오산이라는 뜻입니다. 9월에 날아오는 요금고지서는 8월에 사용한 비용이 청구되는 거니까요.

뭐 이 밖에도 사무실에 들여놓을 PC, 책상, 사무기기 등등이 있지만 뭐 이런건 다들 잘 아실테니 굳이 따로 설명하진 않겠습니다. 다만 경험상 Windows라든지 MS Office 등 소프트웨어는 당장 싸게 산다고 DSP 에디션(한번 설치하면 설치된 시스템에 종속되어 다른 PC에 옮겨서 설치하거나 버전 업그레이드가 불가한 라이선스)으로 구매하는 건 비추입니다. 이런 라이선스는 처음 설치한 PC가 고장나거나 하면 소프트웨어도 무용지물이 되어버리거든요. 그러니까 가급적 영구 라이선스+약간의 추가비용으로 업그레이드가 가능한 라이선스로 구매하시기를 권합니다.


퍼블리셔 못구하면 그냥 자체 서비스 하면 안돼?

소규모 개발사에서 일해보신 분들은 잘 아시겠지만, 게임을 잘 만들어놓아도 퍼블리셔 구하기 정말 힘들죠? 사장님, 개발이사, 사업팀에서 발에 불이 나도록 뛰어다녀도 퍼블리싱 계약 하기가 정말 어렵습니다. 그렇게 몇 개월이 지나면 개발만 열심히 해온 개발자분들은 회의 때 막 이런 이야기를 합니다.
 

자체 서비스... 말은 참 쉽습니다. 하지만 온라인 게임을 직접 론칭해본 분이나, 게임 회사에서 좀 전체적인 관리 업무를 해본 분이라면 온라인 게임을 개발사에서 자체 서비스한다는 게 얼마나 힘세고 강한 일인지 잘 알 겁니다. 이것은 마치 열 한개의 사슬 편지를 입고 힘센 이끼를 잡으러 드라군의 음식물 속으로 들어가는 것에 비유할 수 있죠. (이 개그코드가 뭔지 잘 모르는 분은 '왈도체'를 검색하세요) 그러면, 신생 개발사가 온라인 게임을 자체적으로 서비스하기 위해서 무엇이 필요한지 한 번 짚어볼까요?

▣ 엔진 라이선스 구매비용

요즘 클라이언스/서버 기반의 온라인 게임이 상용 엔진 안쓰고 자체 엔진으로 개발하는 사례는 거의 없죠. 대형 프로젝트에서 쓰는 언리얼이나 크라이는 수십억을 호가하고, 국민 엔진(!) 겜브리오도 대략 2~3억 정도는 있어야 사용할 수 있습니다. 뭐 국산 엔진을 쓰면 더 싸긴 한데 선호도가 그렇게 높지는 않은 것 같더군요. 요즘은 Unity3D 엔진이 뜨고 있기는 한데  C/S 기반의 온라인 게임에서 얼마나 대세가 될지는 아직 모르겠군요. (뭐 제가 있는 회사에서도 Unity3D 엔진으로 C/S 기반의 캐주얼 MMO를 만들고 있기는 합니다만...)

어쨌거나 개발 초기에는 정식 엔진 라이선스 없이 그냥 평가판이나 혹은 어둠의 경로로 구해서 개발을 했다손 치더라도, 최소한 CBT나 OBT 쯤 되면 정식 라이선스를 구매해야만 합니다. 만약 게임브리오 엔진을 쓰고 있었다면 라이선스비로만 대략 3억의 자금이 필요한 거죠. (단, Unity3D 엔진은 라이선스 구매 방식이 좀 독특합니다)


▣ 서비스 인프라 구축비용

C/S 기반의 온라인 게임이라고 해도 소규모 개발팀의 경우라면 프로토타입까지는 서버 접속 없이 클라이언트 상에서 구동되는 스탠드 얼론 방식으로 개발하고, 알파 버전까지는 서버를 붙이더라도 사무실에 PC 몇 대 두고 간소하게 돌리는 것이 일반적입니다. 하지만 CBT, OBT 단계가 되면 불특정 다수로부터 회원 가입도 받아야 하고 동시접속자도 처리해야 하기 때문에 성능 좋은 서버 장비를 구해서 IDC에 입주해야 하고 CDN 서비스도 구축해야 합니다.

일단 서버 장비 구매비용은 서버의 사양과 장비의 숫자, 구매 방식 등에 따라 달라집니다. case by case라서 딱 얼마다라고 말할 순 없지만 서버 운영체제 등을 포함하면 대략 1억원 정도는 있어야 왠만한 동접을 버티는 정식 서비스가 가능합니다. 구매방식은 일시불로 하거나 리스(Lease) 가운데에서 선택할 수 있는데, 리스는 구매 대금을 장기간 나누어서 납부할 수 있어서 일시불처럼 목돈이 없어도 된다는 장점이 있지만, 문제는 신생 개발사는 기업 신용도가 전혀 없기 때문에 담보나 보증을 두지 않는 한 거의 어렵다는 게 문제입니다. 그러니까 일시불 구매를 할 수 밖에 없겠죠.

IDC의 경우는 보통 코로케이션 이용료와 함께 통신요금 납부하듯이 월납으로 납부합니다. 납부할 요금의 종류로는 인터넷 백본 접속료, 랙 사용료, 전력 추가 사용료 등등이 있는데, 이 중에서 백본 접속료가 가장 큰 비중을 차지합니다. KT를 기준으로 백본 접속료는 1Gbps의 경우 2700만원이며, 100Mbps는 370만원, 50Mbps는 274만원입니다. 가장 저렴한 10Mbps 급으로 한다고 해도 기타 필수적인 부가 서비스 요금까지 합치면 매월 300만원 이상은 들어갈 겁니다.

CDN이용료의 경우는 이용량에 따라 요금이 증가하기 때문에 보통 CBT, OBT 초기 또는 대규모 프로모션을 통해 신규 유저들이 많이 유입되는 시기에 요금이 많이 발생합니다. 어떤 서비스를 어떤 요금제로 선택하고 또 유저가 얼마나 많이 다운로드를 받느냐에 따라 요금이 천차만별인데, 시to the망 게임이 아니라면 그래도 월 200~400만원 이상은 발생하며, 신규 유저가 많이 몰리는 시기에는 수천만원까지도 나올 수 있습니다.


▣ 마케팅 비용

게임을 서비스할 때 가장 부담스러운 비용이 바로 마케팅 비용이죠. 퍼블리싱사에서 온라인 게임 마케팅을 해본 분은 알고 있겠지만, 요즘 마케팅 비용 몇 억 써봐야 별로 티도 안납니다. 한 론칭 초기에만 5억 이상은 써야 "아 뭐 그 게임 광고배너 본 것 같아!" 정도의 반응이 나오죠. 네이버 메인에 띄우는 배너의 경우 게재 시간대에 따라 1천만원~2천만원 정도가 드는데, 평균 1500만원으로 잡아도 5억을 다 네이버 메인 페이지 배너에 써봐야 30시간 남짓입니다. 하루 2시간씩 게재한다고 하면 2주 정도 띄우는 거죠. 그런데 현실적으로 광고를 네이버만 할 수도 없고 게임 웹진, PC방 초기화면 광고, 바이럴 마케팅, 론칭 이벤트 경품비, 기타 등등 다 커버하려면 5억이라고 해봐야 얼마 하지도 못합니다.


▣ 콘텐츠 양산 및 서비스를 위한 인력충원

보통 소규모 개발사의 경우 퍼블리싱 계약에 체결되어야 초기 계약금 받은 것을 밑천삼아 인력을 대거 충원해서 정식 서비스를 위한 콘텐츠 양산 체제에 들어가죠. 하지만 자체 서비스를 하겠다면, 이 충원 인력도 자체 비용으로 감당해야 합니다. 게다가 직접 서비스를 하려면 운영팀도 세팅해야 하는데 보통 10명 이상의 GM이 있어야 주말과 심야 시간대에도 최소 1명이 모니터링을 할 수 있죠. 10명이면 평균 급여액을 150만원 정도로만 책정해도 매달 1500만원이 소요되고 이들의 업무용 장비와 복리후생비 등의 부대 비용이 더 소요됩니다.


▣ 자체 서비스, 그럼 얼마나 드는 거지?

그럼 이제 계산을 해 봅시다. 평균 급여액 230만원인 15명의 인력으로 개발기간 2년 동안 CBT 버전까지 개발하는 기본 비용은 대략 이렇게 됩니다.

필수적인 비용만 대력 7억 4천만원이 나오는군요. 금액이 생각보다 좀 적은 이유는 인원이 15명으로 제한되어 있고 부대비용도 낮은 수준으로 잡았기 때문입니다. 실제로는 여기에 그래픽이나 사운드 등 각종 외주 제작비와 추가 인력이 필요한 경우가 많으므로 10억 이상을 쓰게 마련이죠.

그러면 이제 게임의 자체 서비스 단계가 되면 얼마나 비용이 증가하는지 알아봅시다.

3100만원이면 되던 월 비용이 7175만원으로 2배 이상 증가했죠. 게다가 이건 운영팀 인력 10명만 추가한 것으로 가정했을 때입니다. 만약 콘텐츠 양산을 위해 개발팀 인력을 추가한다면 그 인력의 월급+복리후생비 이상의 추가 자금이 필요합니다. 즉 개발팀 규모가 조금만 더 커지면 월 소요 비용 1억이 넘어갈 수 있다는 뜻입니다. 아껴쓰면 2년동안 7억 4천으로도 버틸 수 있었는데, 서비스 단계가 되니까 7억으로는 겨우 반년 남짓 밖에 못버티게 되는 거죠.

게다가 여기에는 아직 엔진 라이선스비와 마케팅비가 반영되지 않았습니다. 반약 엔진 라이선스비가 3억이고 상용화까지 마케팅비를 5억 정도 쓴다고 하면 계산이 어떻게 될까요?

□ 초기 2년 개발 단계 소요비용: 7~10억
□ CBT ~ 상용화 단계 소요비용: 7~10억 (월 7175만원씩 10~12개월)
□ 엔진 라이선스비, 마케팅비: 8억
■ 합계: 22억 ~ 28억 (CBT 단계에서 개발인력 충원시 25~30억)

자, 이렇게 대충 계산기를 두드려봐도, 자체 서비스를 하려면 2년 동안 개발을 위해 투입했던 비용의 두 세배가 넘는 추가 자금을 불과 1년도 안되는 기간 동안 지출해야 합니다. 게다가 이건 어디까지나 비교적 소형 프로젝트의 경우이고 게임 사이즈가 좀 커지면 이보다 훨씬 예산이 크고 아름다워집니다. 뭐 그래도 기필코 자체 서비스를 강행하겠다구요? 뭐 정 퍼블리셔를 구할 수 없다면 시도할 수 밖에 없겠죠. 하지만 그러기 위해서는 최소한 기초적인 회계 감각을 바탕으로 한 예산 관리능력과 자금조달 능력이 뒷받침 되어야만 합니다. 아니 사실 개발팀을 꾸릴 때부터 이러한 능력이 중요하죠.

자, 이제 대충 게임 개발팀 하나를 꾸려나가는데 어느 정도의 자금이 어떻게 소요되고 자체 서비스까지 생각한다면 얼마나 많은 비용이 들어가는지 대충 감이 잡히실 겁니다. 물론 요즘 유행하는 앱 개발이나 웹 게임 개발로 생각하시면 비용이 좀 적게 들어가겠죠. 앞으로 이어질 포스팅에서는 실제 사용 가능한 예산관리 문서양식(엑셀)을 통해서 예산을 계획하고 관리하는 방법에 대해서 포스팅 할 예정입니다.

 

// Read a matrix(3 texture reads) from a texture containing animation data
float4x4 loadBoneMatrix(uint3 animationData,float bone)
{
   float4x4 rval = g_Identity;
   // if this texture were 1D, what would be the offset?
   uint baseIndex = animationData.x + animationData.y;
   // 4*bone is since each bone is 4 texels to form a float4x4
   baseIndex += (4 * bone);
   // Now turn that into 2D coords
   uint baseU = baseIndex % g_InstanceMatricesWidth;
   uint baseV = baseIndex / g_InstanceMatricesWidth;
   // Note that we assume the width of the texture
   // is an even multiple of the # of texels per bone,
   // otherwise we'd have to recalculate the V component per lookup.
   float4 mat1 = g_txAnimations.Load( uint3(baseU,baseV,0));
   float4 mat2 = g_txAnimations.Load( uint3(baseU+1,baseV,0));
   float4 mat3 = g_txAnimations.Load( uint3(baseU+2,baseV,0));
   // only load 3 of the 4 values, and deocde the matrix from them.
   rval = decodeMatrix(float3x4(mat1,mat2,mat3));
   return rval;
}