하나의 게임을 개발하기 위해서는 기획자와 디자이너, 프로그래머 등 여러 분야의 전문가가 필요하다. 모든 일이 다 그렇겠지만, 게임 역시 작은 업데이트를 라이브 게임에 적용하기 위해서는 엄청난 시간과 코스트를 들여야 한다. 서로 다른 직군의 사람들이 한 곳에 모인다면 그 어려움은 말할 것도 없다.
개발자들은 게임이 라이브 되고 나서 유저들의 불편을 최소화하기 위해 계속해서 체크하고 개선 작업을 진행한다. 하지만 개발자 자신들의 불편 사항에 대해서는 돌아보지 않는다. 그런데 일을 하다보면 간혹 실제 업무가 아닌 부차적인 부분으로 인해 시간을 버리는 경우가 꽤나 자주 발생한다. 그래서 업무의 편의성을 극대화 하기 위한 수단으로 '툴'이 있다.
팀원들의 업무 효율을 끌어올릴 수 있는 '좋은 툴'이란 어떠한 것이며, 어떻게 제작해야 할까? 이에 대한 해답을 넥슨코리아 박경재 피파실 실장이 NDC2014에서 제시했다. 2004년에 넥슨에 입사한 그는 카트라이더, 에버플래닛, 던전앤파이터 개발 담당을 거쳐 현재는 '피파온라인3'를 맡고 있다.
금일 강연에서 그는 세부적인 카트라이더나 에버플래닛에서 만든 툴 제작 사례가 아닌 '게임 개발 시 동료가 겪는 불필요한 괴로움을 해결할 수 있는 툴에 대한 마음가짐'에 대해 짚었다. 본격적인 툴 제작 설명에 앞서 퀘스트와 맵 에디터, 소셜 게임과 관련된 사례가 소개되었다.
◆ 기획자와 아티스트 그리고 프로그래머의 복잡한 일상
■ 사례1: 퀘스트
기획자는 자신이 구상한 퀘스트를 바로 볼 수가 없다. 기획자가 쉽게 다룰 수 있는 툴이 없기 때문. 그래서 일반적으로 기획자는 프로그래머에게 엑셀 파일을 전달한다. 프로그래머는 이를 수동으로 작업, 기획자에게 다시 전달한다.
받은 것을 토대로 기획자는 테스트 서버에서 플레이를 하는데, 버그 없이 한 번에 완벽하게 구현되기는 쉽지 않다. 그래서 또 다시 엑셀 파일을 프로그래머에게 주게 된다. 이 과정이 무한 반복되면서 수 많은 중간 작업들이 발생하게 된다.
■ 사례2: 맵 에디터
개발자들의 필요에 의해 수 많은 맵 에디터가 제작됐다. 하지만 그 중에는 몇 년 전에는 잘 동작했지만 담당자가 퇴사한 이후에 유지보수가 되지 않아 삐걱거리는 것들이 많다. 어떤 맵은 아예 열수도 없고 어떤 맵은 파일이 깨지기도 한다. 이럴 때 개발팀은 "최대한 그 상태 그대로 조심히 써봐라"고 한다.
■ 사례3: 소셜 게임
아티스트는 자신이 디자인한 집이 기존 게임에 들어가면 어떻게 보일까 궁금해 한다. 그래서 이를 확인하기 위해서는 프로그래머에게 요청해야 한다. 프로그래머는 테스트 빌드를 만들어 준다. 처음부터 완벽하게 될 거라고 생각하지는 않았지만 그래도 좌절스럽다. 무엇이 문제일까? 알고보니 '이미지'가 imige로...... 다시 수정해서 적용했더니 제대로 된 집이 구현되었다!
이러한 일들은 실제 라이브 중인 상당수의 팀에서 일어나고 있는 사례다. 공통점은 제대로 된 툴이 없다는 점, 부족한 부분을 각자의 희생으로 메꾼다는 것, 그리고 오랫동안 현 상태를 유지한다는 것이다.점이다.
그렇다면 왜 고치지 않는 것일까? 이에 대해 프로그래머는 "툴이 좀 개발이 덜 된건 알지만, 툴 기획하고 만들 시간에, 게임 피쳐를 하나라도 더 추가하는게 나을거 같은데요", 기획자와 아티스트들은 "(좀 불편하기는 하지만) 지금 툴로 충분히 일은 다 되요. 잘 쓰고 있습니다" 라고 말하기 때문이다.
대부분의 기획자와 아티스트들은 불편을 잘 이야기 하지 않는다고 한다. 정확히는 이야기 하지 못한다. "좀 힘들어도, 어짜피 업무는 적응해야 하는 것이고, 내가 불편하다고 해서 게임 업데이트를 늦출 순 없으니까요"라는 것. 즉, 그들은 정확하게 입력하지 못한 자신의 숙련도에 문제가 있다고 생각해버린다
기획자가 직접 메모장을 열어서 코드작업을 하는 것이 좋은 일일까? 복잡한 과정이 팀원 간의 협업을 강화시켜줄까? 스치기만 해도 날라가는 툴이 신중한 결과물을 만드는 훈련일까? 대답은 "NO"이다. 실제 제작과정이 아닌 다른 작업에서 시간을 쏟는 것은 시간 낭비이다. 그들은 자신이 가장 잘 하는 자기 일에 집중할 수 있어야 한다.
"자신이 가장 잘하는 일에 집중하고 최선을 다하는 것은 좋은 툴과 툴을 만드는 프로그래머의 역할이라고 생각합니다"
◆ 모두에게 득되는 좋은 툴 만들기
■ 1단계: 타이밍
그렇다면 툴은 언제 만들어야 할까? 아직 본격적인 개발에 들어가지 않은 팀일 경우, 대다수가 프로토타이핑 때부터 툴을 만들려고 하는 경향이 있다고 한다.
하지만 프로토타이핑 기간에는 만들어질 게임의 모습이 미확정이며, 작업 프로세스 역시 정해지지 않았다. 이 단계에서는 1시간, 1분 1초의 시간과 빠른 의사결정 전환이 중요하기 때문에 툴 제작에 투자하는 것은 좋지 않다고 박경재 실장은 말했다.
프로토타이핑을 마치고 프리 프로덕션 단계에 돌입하기 전 그 사이에 재정비하는 의미로 툴 개발을 하는 것이 툴을 만드는 최적의 시기이다.
이미 라이브 업무를 진행중인 팀이라면 정답은 뻔하다. 지금 당장이다. 대규모 업데이트나 큰 프로젝트가 있는 상태가 아니라면 문제점을 발견했을 때 즉각적으로 이에 대해 수정하는 것이 가장 이상적이라는 것.
■ 2단계: 주체
툴 제작 시기를 정했다면 다음은 '누가 만들 것이냐'는 점을 고민해야 한다. 현재 대부분의 개발팀에서는 "툴 만들면서 게임 분위기 좀 익혀 보세요"라는 이유로 신입사원들에게 맡기고 있다.
물론 신입사원들에게는 성장 경험이 될 수는 있다. 하지만 '좋은 툴'을 만들기 위해서는 다른 직군의 업무 방식에 대한 이해도와 프로세스 전체를 보는 시야가 요구된다. 그래서 그는 "리드 혹은 시니어 프로그래머"가 툴을 제작하는 것이 좋다고 제안했다.
■ 3단계: 사전 조사
자신의 팀에 최적화 된 툴을 위해서는 현재 상황을 파악해야 한다. 현재 쓰고 있는 툴에 대한 피드백을 모으는 것이 기본 작업. 그런데 단순한 불편함을 고치는데서 툴 제작을 그치면 안된다.
왜일까? 인터뷰의 한계가 있기 때문이다. 인터뷰를 통해 들은 정보는 부족하거나 불분명한 경우가 많다. 툴을 만들었던 프로그래머 앞에서 쓴 소리를 하기란 쉽지 않기에 대부분의 사람들이 "그럭저럭 만족해요"라고 답한다는 것.
그래서 단순히 피드백을 모으고 인터뷰를 하는 것에서 나아가 기획자와 아티스트, 프로그래머가 각자 어떻게 일하고 있는 지를 관찰할 필요가 있다. 시연하는 것을 보는 것도 좋고, 프로그래머가 다른 직군의 일을 직접 해 보면 더할 나위 없아 좋다.
이러한 과정을 통해 인터뷰 내용의 실제 의미를 파악할 수 있으며, 말하지 못했던 속사정을 알 수 있다. 문제의 진짜 원인에 근접하게 되는 것이다.
■ 4단계: 우선 순위
할 목록이 완성되면 어떠한 일부터 해야할 지를 결정해야 한다. 가장 먼저 작업에 착수해야 하는 부분은 툴이 없으면 개발이 불가능한 것이다. 이와 더불어 작업 프로세스가 복잡한 것 위주로 우선적 개발에 들어가야 하며, 그 다음으로는 자동화 가능한 일을 수동으로 하고 있던 것을 개선해야 한다.
많은 작업이 있기 때문에 큰 계획을 세우는 것이 필요하다. 하지만 이에 앞서 작은 것부터 하나씩, 꾸준히 만들어 가는 것이 중요하다. 복잡한 프로세스를 간소화 해보겠다고 하지만 생각보다 복잡하다. 그래서 보통 이 타이밍에 포기한다.
명심할 점은 "모든 프로세스 전체를 커버하는 툴을 처음부터 만들려고 하지 말라"는 것. 프로세스 개선이라는 거창한 목표로 시작해서는 안된다. 중요한 건 순간 순간의 단축이다. 가장 짜증이 나고 가장 어려움을 느끼는 그런 부분을 찾아 시간을 줄여주는 것만으로도 충분히 좋은 툴이 될 수 있다.
■ 5단계: 포커스
아티스트와 기획자, 프로그래머가 원하는 '편한 방법'은 모두 다르다. 이에 대한 인지가 없다면 편리한 좋은 툴이 될 수 없다. 각자에게 익숙한 도구와 비슷하게 만들어주는 것이 좋다.
예를 들어, 코드를 보려고 할 때 사전을 뒤지는 것이 아니라 자동완성 기능으로 바로 찾을 수 있는 기능을 넣었다고 생각해보자. 단순히 이 작업만 떼어서 보면 2-3초 가량의 시간을 단축한 것에 불과하지만, 누적되면 엄청난 시간과 에너지가 절약되는 것이다.
그래서 이 기능이 어느 직군의 사람이 사용할 것이냐를 파악하고 포커스를 맞춰야 '좋은 툴'이 된다.
■ 6단계: 주의
툴의 자유도를 높이고 강력한 기능을 추가하기 위해 다소 불편하게 툴을 짤 때가 있다. 하지만 사람들은 결코 좋아하지 않는다. 이 단계에서 프로그래머들은 "이 정도면 눈구나 쓸 수 있는거 아니야?"라고 불만을 가질 수도 있다.
이에 대해 박경재 실장은 "프로그래머는 다른 직군보다 로직의 구조와 흐름, 게임 메카닉에 대한 이해와 숙련도가 월등히 뛰어납니다"고 말했다. 프로그래머는 다른 직군에 비해 로직에 대한 이해도가 높으며, 그들의 기준으로만 툴을 만들 경우 다른 직군에서는 불편함을 느낄 수 있다는 것.
그리고 이러한 차이는 단시간에 훈련을 통해 좁혀질 수 없다. 그렇기에 동료에게 교육을 해서 그 간극을 좁히려고 노력하기 전에, 현 상황에서 기획자나 아티스트가 쓰기 가장 좋은 툴을 만들려고 노력해야 한다.
배우지 않아도 쓸 수 있는 툴이 가장 좋은 툴이라는 것의 그의 의견이다.
■ 7단계: 제작 후
그때그때의 필요에 따라 작은 툴을 만들면 처음에는 좋다. 당장 해야되는 일을 보다 쉽게 만들기 때문에 편리하다. 하지만 이러한 작은 툴들은 갈수록 유지관리가 어려워지는 문제점을 가진다.
게임을 예로 들어 생각해보자. 패치 이후부터 특정 아이템의 성능이 떨어진다면, 유저들은 그 아이템을 사용하지 않게 된다. 툴 역시 마찬가지이다. 기획자와 아티스트들의 Tools 폴더에는 수십 개의 툴이 있지만,지금은 쓰이지 않고 방치되는 것들이 많다. 아예 동작되지 않는 것들도 상당수다.
그래서 만들어진 툴에는 반드시 관리 책임이 따라야 한다. 제공하는 툴에 대해서는 시작과 끝을 명확하게 하고, 만들어진 툴은 항상 돌아갈 수 있도록 관리해야 한다.
■ 8단계: 피드백
툴이 완성되었고 사람들이 이를 사용하고 있다면, 의도하던 대로 툴이 사용되고 있는지 수시로 체크하는 것도 필요하다.
피드백은 인터뷰나 관찰 등을 통해서도 가능하며, 온라인 게임에서 시도하고 있는 분석툴을 적용해보는 것도 좋다. 이를 통해 각 메뉴별 사용정보를 수집해서, 어떤 기능을 언제, 어느 시점에, 얼마만큼의 빈도로 쓰는지를 파악할 수 있다.
이러한 분석을 토대로 프로그래머가 생각했던 작업 흐름과 실제 사용에서의 차이를 파악할 수 있는 것이다. 툴을 만드는 노력만큼, 결과 측정과 이후의 업데이트에도 신경써야 한다고 박경재 실장은 권유했다.
◆ 가장 중요한 것은 '동료에 대한 존중'
툴 제작에 대한 설명을 마치면서 박경재 실장은 "가장 중요한 것은 동료에 대한 존중"이라고 말했다.
팀의 동료들이 일하는 모습을 관심을 가지고 살피고, 그들이 어려워 하는 일을 찾는 것이 좋은 툴을 만드는 핵심 포인트다. 조그만 도움으로도 일하는 방식이 크게 바뀔 수 있다. 그리고 이런 잡다한 과정이 사라지면 개발자들은 '게임 자체'에 더 집중할 수 있게 된다.
좋은 툴과 프로세스는 미처 느끼지 못했던, 말하지 못했던 어렵고 힘든 개발 문화를 바꿔줄 수 있는 좋은 계기가 된다. 그렇기 때문에 게임에서의 사용자 경험에 대해 생각하고 고민하는 만큼, 동료들의 작업 환경에 관심을 가져야 한다는 것이 그의 입장.
"라이브 중인 조직이 건강하게 유지될 수 있는 보이지 않는 힘이 되어줄 것입니다"
KaEnn@inven.co.kr