처음 회고해볼 시기는 2006 년 ~ 2007 년이다. 엔트리브 소프트(Ntreev Soft, 이하 엔트리브)에 입사하여 트릭스터(Trickster) 프로젝트에 몸담고 있었을 때로 이 블로그를 시작하기 전이다. 개발자로서 레벨도 높지 않아 관점도 다양하지 못했던 시기이며, 기간도 길지 않았고 이젠 오래되어 기억도 가물해진 기간이다. 하지만 최근 프로젝트를 수행하며 가장 많이 떠올랐고, 실제로 참조가 되었던 시기이므로 첫 회고로 부족함이 없다고 생각된다.

새로운 시작 : 엔트리브 소프트를 선택했다.

게임 디자이너로서 6년차 되던 해, 엔트리브에 입사하였다. 세번째 회사인 엔트리브는 경험의 확장을 위해 선택한 회사이다. 이 선택을 설명하기 위해 첫 두 회사를 서술하자면 , 첫 회사인 고누소프트와 두 번째 회사인 거피게임즈 (Guppy Games)는 둘 다 신생 개발사였고, 게임 디자인 분야의 인적 구성이 유사했다. 자유롭고, 좋은 의미로 가족 같아 편안한 회사였다. 게임을 완성해 출시하는 데에는 큰 부족함이 없는 회사였지만, 팀과 경영진의 게임적 유전자는 부족했다. 한국의 게임 산업이 온라인 중심으로 재편되며 커지기 시작했을 때였기 때문에 당연한 것으로 생각되었다. 물론 아쉬웠다.

어쨌거나 두 번째 회사는 다른 회사로 인수 합병되어 팀은 해산되었고, 이직을 할 수 밖에 없는 상황이되었다.

그러한 아쉬움 때문에 새 회사를 선택하는데 가장 중요한 것은 뿌리깊은 게임 개발사였다. 엔트리브는 게임업계 입문 시절 가장 가고 싶었던 손노리의 혈통을 가진 회사로, 분사 후 팡야로 크게 성공하고 한참 세를 펼쳐나가던 때였다.

엔트리브에 성공적으로 채용되었으나, 한가지 아쉬움이 있었다. 프로젝트였다. 신규 개발 프로젝트를 지원했으나 아쉽게도 면접 결과 주어진 제안은 라이브 서비스중인 트릭스터 였다. 아쉽지만 나쁘지 않았다. 이전 회사에서 게임의 초기 개발 ~CBT까지 경험하였지만 본격적인 라이브 서비스를 해 본 경험이 없었기 때문이다.

헬게이트는 그렇게 열렸다.

트릭스터 & 팀은 어땠는가?

트릭스터는 재미있는 게임이었다. 실적도 나쁘지 않았다. 팡야에 비하면 국내 인지도는 낮았고, 수출된 국가 수도 턱없이 적었지만 (팡야가 이상하게 많은 거다) 팡야에 준하는 매출을 내고 있었다. 그만하면 나름 알짜 프로젝트가 아닐까 생각되었다.

하지만 개발팀에 희망의 기운이 가득해 보이지는 않았다. 우선 개발실에 인적 자원이 적었다. 많은, 주로 경력이 긴 개발자들은 신규 프로젝트로 옮겨가고 비교적 새롭게 합류한 사람들이 주류를 이루고 있었다. 또한 적지 않은 사람들이 신규 프로젝트로 전환 배치되길 희망했다. 얼마 안 되는 자원들은 주로 유료 상품 개발에 투입된 것으로 보였다. 한 단면을 보자면 유료 상품용 그래픽 리소스는 거의 매달 추가되었으나, 정규 컨텐츠용 리소스 추가는 거의 볼 수 없었다.

무엇을 했는가? 이벤트를 비롯한 데이터 관리

트릭스터는 이벤트가 많았다. 크든 작든 거의 매달 있었다. 한 달에 2번 점검. 한번은 이벤트가 올라가고, 다른 한번은 이벤트가 내려가고 피에스타 (카우레벨 스타일의 이벤트 맵)맵이 열린다. 팀에 합류한 시점에 이미 이것은 정형화 되어 있었다. 그 이벤트를 만드는 것이 당시 트릭스터 기획팀의 주 업무였으며, 시스템 디자이너인 본인의 주 작업은 그 데이터를 관리하는 것이었다.

당시의 판단 : 불만 가득했다.

왜 정규, 신규 컨텐츠가 아닌 일회성 이벤트에 집중하는가? 이것이 가장 큰 불만이었다. 입사 후 한달 가량 플레이 해본 트릭스터는 크고 작은 많은 문제가 보였다. 캐릭터 레벨에 비해 컨텐츠는 부족하여 레벨이 높아지면 닥사만 남는 것 이라던가, 고렙으로 갈수록 특정 직업은 죽어가고, 어떤 직업은 점점 날아다니는 현상이 있었다. 안타깝게도 날아다닌다는 게 극딜 세팅으로 원킬 몰이사냥을 하는 지라, 잘못하면 폭사했다. 어느 쪽이든 안타까웠다. 이러한 많은 문제를 뒤로한 체, 2 주 하고 나면 사라지는 이벤트만 계속 만드는 모습이 좋게 보이진 않았다. 이벤트의 양식도 모두 연속 퀘스트의 반복 수행으로 이루어져 비슷비슷해 보였다.

다시 생각해 보기 : 어른의 사정을 헤아려본다면..

돌이켜 보자면, 이는 팀 의사결정자들의 고육지책이 아니었을까? 그리고 상황을 고려했을 때 나름 합리적이지 않았을까? 라는 생각을 해본다. 팀 전체의 자원 운영은 어떤 어른의 사정이 있었는지 잘 모르겠지만, 이벤트 중심의 라이브 서비스는 주어진 자원으로 할 수 있는 거의 유일한 것으로 판단된다.

긍정적으로 보자면 이벤트는 비교적 광범위하게 적중했다. 캐릭터 레벨에 비해 부족한 아이템 컨텐츠가 부족한 환경으로 인하여 이벤트 아이템이 꽤 광범위하게, 중 ~고렙 모두에게 적합할 수 있었다. (다른 말로, 이벤트템이 오버밸런스라고 할 수 있다.) 여기에 이들 아이템이 거래 가능하기 때문에 코어유저는 부캐릭을 이용하여 추가적으로 획득해 두기도 하고, 후일을 도모하며 사고 파는 일도 많이 보였다. (쌓아두기, 매점매석, 시세조작) 즉, 이벤트 하나 하나가 게임 월드에 끼치는 영향이 컸다고 회상한다. (제살이 많이 깎였다.)

괄호를 치고 마음의 소리를 적었지만, 그마저도 없었다면 트릭스터는 몇 달씩의 없데이트를 겪었을것이다. 혹, 전력을 집중해서 컨텐츠를 만들었더라도 소수의 유저에게만 적중되어 효과가 크지 않았을 가능성도 크다고 본다.

또한 돌이켜보면 배울만한 것도 있었는데 이는 따로 정리하겠다.

하지만 그 이상의 아쉬운 것 : 사람, 보람, 노가다

몇 보 양보해서 프로젝트에는 괜찮았을지 모른다. 하지만 프로젝트의 구성원들에겐 좋지 않았다고 이야기 하겠다. 다른 이들의 속을 확실히 알 수는 없지만, 적어도 본인에겐 좋지 않았다.

게임 개발의 시간에서 지적으로 즐거운, 창조적이고 생산적인 일을 하는 시간은 그리 길지 않다. 그의 몇 배의 시간이 구현하고 테스트하고 다듬기를 반복하는데 소비된다. 고되지만 노가다는 아니다. 그 고됨은 나, 혹은 내가 참여하여 디자인한 게임의 요소에 기인한 것이기 때문이며 그렇기 때문에 할 수 있고 보람이 생기며 자긍심이 올라간다. 반대의 경우는? 참담해진다.

이벤트 일색이라 하더라도 그를 디자인 하는 과정이 있었다면 즐거웠을지도 모른다. 어떻게 하면 더 전달이 잘 되고, 퀘스트 동선이 매끄럽고, 깨알 같은 디테일을 살릴 수 있을까 고민하며 데이터 작업을 하고 테스트를 반복했다면 나름의 보람이 있었을 것이다. 안타깝게도 그렇지 못했다. 구현의 고민이라도 있었다면 일말의 재미라도 찾을 수 있었을 것이다. 그마저도 부족했다. 수행한 대부분의 작업은 과거 사용되었던 이벤트의 재사용이었기 때문이다. 좀 더 심한 것은 로컬라이징 데이터 작업이었다. 여기엔 일절 디자인 요소가 존재하지 않았다.

작업의 한 단면을 간단히 적어보자면 다음과 같다 :
1. 한국판 데이터 (한국어 문자열과 시스템 스크립트가 혼합된)를 추출하여 번역을 보내고
2. 받아온 번역된 문자열을 시스템 스크립트와 분리하여 (왜냐면, 번역 작업자가 스크립트를 하나도 안 건드렸다는 보장이 없기 때문이다.번역을 하다가 delete 를 하나 더 눌러 스크립트에 적힌. 를 지우고, 일본어 문자열의 다른 점을 찍었다고 해 보자. 그날은 눈 빠지는 거다. 프로그래머의 디버그 지원은 당연히 상상해본 적 없다. 물론 스트링셋의 변환 문제도 있다. 더 이상 자세한 설명은 생략한다.)
3. 한국 데이터에 조합하여 해당 국가용 최종 데이터를 만들어 입력한다. 번역할 내용이 없는 데이터는 한국 데이터를 뒤진다.
국가에 따라 버전이 달랐기 때문에 데이터 양식이 달라진 경우도 있기 때문에 기계적인 작업을 기계적으로 작업할 수 없다. 분량도 적지 않았는데, 매달 한번씩 3개국의 퀘스트 업데이트가 있었고, 저 기간 동안 영문판과 태국어판이 신규로 제작되었다.

1시간을 노가다 할 거라면, 노가다를 자동화 해 줄 무언가를 한 시간 동안 만드는 공돌이스러움으로 업무의 단조로움을 줄이고 생산성을 높이려는 행위가 그나마 정신적인 피폐함을 달래주었다. 이 시기에 대량의 데이터를 다루는 법, 파싱 스킬, 오토 핫키 (…) 사용법을 획득했다. 하지만 이 또한 몇 달이었다.

]3 오토 핫키는 딱 저런 느낌이었다. 밤 새 돌아간 스크립트가 잘못되었다면… (c) Walt Disney

업무 환경 : INI Tool

당시의 트릭스터는 Ini Tool 이라는 자체 데이터 툴을 사용하고 있었다. 지금은 당연하다고 할 수 있지만, 당시에는 툴이 있다는 것 자체만으로도 놀라웠다.

이전 프로젝트의 데이터 작업은 다음과 같았다.

엑셀에서 작업 -> CSV로 저장 -> Mysql에 올리기 / 혹은 CSV 파일 자체를 서버에 업로드

게다가 이 툴은 꽤 유연했다. 데이터 작업자가 데이터 항목을 만들고 수정하는 것은 물론, 데이터 양식을 생성 및 관리할 수 있는 기능을 가지고 있었다.

하지만 단점이 만만치 않았다. 웹 기반이었기 때문에 지속적인 데이터 작업을 하기엔 심히 느렸고, 편집 기능 부족했다. 엑셀 등의 외부 툴과 병행하기엔 대규모 데이터 입출력 지원이 용이하지 않았다. (엑셀 임포터가 있었으나 팀에 들어간 시점부터 나갈 때까지 망가진 체로 방치되었다.)

무척 좋지 않은 작업 환경이었지만, 이 경험은 던전스트라이커의 데이터 양식과 툴을 만드는데 결정적인 도움을 주었다. 다른 자리에서 구체적으로 기술해보겠다.

끝

결과적으로, 새벽에 총알택시를 타고 퇴근 하는 생활을 몇 달 지속하며 손목에 무리가 왔고 오른손에서왼손으로 마우스를 옮기고, 마우스를 트랙볼로 바꾸어 가며 태국어 버전과 영어 버전 데이터 작업을 끝내고, 퇴사를 각오하고 팀을 옮겼다.

]4 당시에 빌려 썼던 켄싱턴 익스퍼트의 조작감(특히 볼 주변의 휠!)은 지금도 종종 생각난다. 빌려주신 Sopepos님께 감사를. (c)Kensington

2006년 ~ 2007년. 다시 생각하기 싫은, 재미와 보람을 찾기 힘든 암흑기라고 생각했으나, 아이러니하게도 이 시기의 경험은 2009년에 새 게임을 백지부터 개발하기 시작했을 때 가장 크게 도움이 되었다. 게임이 만들어져 돌아는 것을 넘어, 유지보수를 할 때까지 고려할 수 있는 시각을 갖게 된 것이다. 뭐 거창할 것 없이 “ 기획자를 갈아 넣는” 일이 생기지 않았으면 좋겠다는 생각이 그것이다.

뭐 업무 관련 기록만 했기 때문에 생략되었지만, 트릭스터 기획팀은 꽤 즐거운 팀이었다.

그리고 사족이지만 트릭스터팀의 이런 상태가 지속되지는 않았다. 이후 자체 서비스로 전환하고 고렙 컨텐츠 추가 및 초반 리뉴얼등이 수행되었고, 툴도 버전업 되고 버그도 고쳐졌다고 들었던 것 같다. 아마 갈려 나가는 노가다꾼은 줄고, 참여하는 디자이너가 늘지 않았을까 생각해본다.

무슨 글 하나 적는데 한 달이 넘어가는군요. 오래간만에 글을 쓰니 무뎌짐이 확연히 느껴집니다. 게다가 오래 된 내용을 꺼내는 것 역시 쉽지가 않았습니다. 앞으로 멈춤 없이, 더 열심히 해야겠습니다.

중간에 좋은 의미로 재촉해주시고 기억을 꺼내 재구성하는 자리를 마련해 주신 기웅님과 함께 해주신 시흥님께 감사의 말씀을 드리며 글을 마무리 합니다.