• 주제: 처음 만드는 건데 실수 좀 할 수 있죠
  • 강연자 : 박소현 Park, Sohyun | 넥슨코리아 / NEXON KOREA
  • 권장 대상 : 학생 , 개발자 지망생
  • 난이도 : 사전지식 불필요


  • [강연 주제] 많은 학생 게임 개발팀이 갈등으로 팀이 와해 되거나, 게임을 완성하지 못하고 프로젝트를 마칩니다. 이전에는 '팀 운이 좋지 않아서', '시기가 좋지 않아서'라고 생각했지만, 프로젝트를 마치고 한 발자국 떨어져 생각해보니, 우리가 경험이 적고 서툴러서 실수가 많았다는 것을 알 수 있었습니다. 이 발표를 통해서 게임 개발을 시작하려는 분들에겐 덜 실수 할 수 있는 팁을, 유경험자분들께는 공감을 드리는 내용이 되었으면 합니다.

    "처음 하는 건데 실수 좀 할 수 있죠"

    사람은 누구나 실수를 할 수 있다. '실수'에서 배우는 자세가 중요하다. 실수를 되풀이하지 않기 위해 실수를 분석하고, 이에 대한 해결 과정과 개선 방법을 찾아나가는 일은 매우 중요하다. 그래서 프로젝트를 되돌아보는 '포스트모템'은 성공과 실패 모두 해볼 가치가 있을 정도로 중요한 일이다. 물론 게임 개발에 있어서도 말이다.

    아마추어 개발자, 팀이 게임을 완성하지 못하고 개발을 마치는 경우가 많다. 당시에는 시간이 부족했다거나, 운이 좋지 않았다는 이유를 들 수 있었겠지만, 박소현 개발자의 경우는 시간이 지나 뒤돌아보니 '경험이 부족해서 일어난 일'이라고 생각할 수 있게 됐다. 이번 강연에서 박소현 개발자는 지난 프로젝트 3종에 대한 포스트 모뎀을 하며 실수가 일어난 원인을 분석하고, 이를 해결하거나 개선했던 사례들을 소개했다.

    ▲ 사례로 제시된 3종의 프로젝트



    ■ 게임 구상 단계에서의 실수 바로잡기

    첫 번째 사례는 '게임 구상 단계에서의 실수'다. 게임 개발 전 아이디어를 구상하고 팀을 꾸린 상황에서의 실수다. 아이디어를 구체화하지 않고 대략적인 상태로 팀원을 모았고, 팀원과 컨셉을 구체화하는 회의가 있었다. 이야기를 하다 보니 컨셉에 대한 원하는 바와 생각의 차이가 많았다. 이를 조율하는 과정에서 결과적으로 양보와 타협으로 마무리가 되오 개발이 이어졌다. 결과적으로, 각자 만족스럽지 못한 컨셉을 가지고 게임 개발에 돌입하게 된 셈이다.

    ▲ 아이디어를 보고 사람마다 생각이 다를 수 있다.

    아이디어에 모두가 공감할 순 있지만, 합의가 되지 않을 수 있다. 사람마다 생각하는 바가 다르기에, 기대하는 바도 다르다. 그래서 이를 맞추기가 어려웠던 셈이다. 박소현 개발자는 이러한 문제를 해결한 발전 방법으로 '아이디어를 시스템으로 구체화한 문서'를 작성하고 팀원을 모집했다.

    준비된 문서에는 아이디어와 게임 시스템이 명확히 제시되어 있었고, 이를 참고하여 작업 방향을 결정했다. 이미 대부분이 결정되어 있었으므로, 딱히 합의가 필요하지 않고 바로 개발에 착수할 수 있었다. 아이디어를 최대한 구체화하여 팀을 결성하면 팀 빌딩 과정에서 기대가 비슷한 팀원을 구할 수 있고, 이를 통해 좀 더 빠르게 개발에 착수할 수 있던 셈이다.

    ▲ 아이디어 구체화로 좀 더 빠르게 개발에 착수할 수 있었다.

    이미 팀이 꾸려진 상태에서도 합의 과정을 줄이기 위한 방법이 없는 건 아니다. 랜덤으로 꾸려진 팀에서는 이미 '장르'가 결정되어 있었고, 레퍼런스를 선정하는 과정이 필요했다. 당시 박소현 개발자는 모두가 플레이해본 게임으로 레퍼런스를 선정했고, '스킬'에 차별점을 주기로 결정했다. 모두가 잘 알고 있는 속담을 제시하여 하루 만에 컨셉과 구체화를 마치고 개발에 착수했다.

    게임 구상 단계에서, 팀을 빌딩하기 전이라면 아이디어를 구체화하면 기대가 비슷한 팀원을 구할 수 있다. 빌딩이 되어있다면 모두가 겪어본 경험이나 정보를 제시하면 쉽게 공감대가 형성되고, 서로 이해하기가 쉽다. 이를 통해 게임 구상 단계에서 좀 더 매끄럽게 개발 과정으로 넘어갈 수 있다.

    ▲ 공감대를 형성하면 좀 더 매끄럽게 이해하고 구상단계를 매끄럽게 완료할 수 있다.


    ■ 프로토타이핑 과정 개선하기

    두 번째 사례는 '프로토타입'단계에서 실수다. 대부분의 게임을 게임 구상 단계를 마치고 프로토타이핑을 한다. 프로토타입은 최소한의 기능만으로 게임의 검증하는 단계다. 이는 재미가 될 수 있고, 게임의 시스템이나 의도가 될 수 있다. 실수했던 사례에서는 주관적인 재미만을 찾아서 결론을 내지 못했다. 재미를 느끼는 기준 역시 사람마다 다르고, 결과 판단이 어려운 상당히 막연한 기준이라고 할 수 있다. 때문에 프로토타입이 예정보다 매우 길어지게 됐다.

    다음 프로토타입에서는 '재미' 대신, '의도'를 기준으로 프로토타입을 평가했다. 특정 영역의 시간을 늘리게 만드는 '슬로우 스킬'을 제작한 프로토타입에서는 플레이어가 스킬로 적의 공격을 막고 새로운 공격을 할 수 있는지, '의도'를 평가했고 이는 결과 판단이 쉬웠다. 이를 통해 이전보다 뚜렷한 목표와 결과를 도출해낼 수 있었다. 이러한 과정은 현업에서도 비슷하게 이뤄지고 있으며, 전투와 게임 규칙, 그리고 이를 합친 형태를 검증하며 마일스톤마다 검증할 부분을 결정하기도 한다.


    또 다른 실수도 있었다. 프로토타이핑 과정이 길어지는 과정에서 다른 팀원에게 공백이 생겼다. 프로토타입 과정 동안 다른 작업이 없던 아트 팀은 기약 없는 대기가 길어졌다. 이를 해결하기 위해 시니어 개발자들에게 조언을 구한 결과, 다른 프로토타입을 동시에 진행해보는 해답을 찾을 수 있었다.

    플레이 프로토타입이 진행되는 동안 아트 팀은 아트 프로토타입을 진행하는 방법이다. 아트팀은 별개의 프로토타입을 진행하여 어셋을 만들며 스펙을 결정하거나 게임의 분위기나 컨셉에 어울리는 풍취를 만드는 추가 작업을 진행할 수 있었다.




    ■ 떨어지는 사기와 열정을 줄여보자

    세 번째는 '열정 유지'에 대한 부분이다. 게임 개발 기간이 지날수록 열정은 감소한다. 특히나 학생이나 아마추어 개발의 경우 정해진 보상(월급, 복지)이 없는 프로젝트고, 결과만을 기대하면서 열정을 기반으로 개발해야 하는 프로젝트일수록 더욱 심하다. 이는 자연스러운 일이며, 누구를 탓할 수 없는 일이며 개인이 해결하기는 어려운 부분이다. 구조적으로 완화를 할 수 있는 방법을 강구하는 것이 옳다.

    과거 프로젝트에서 이러한 열정이 잘 유지된 사례를 살펴보면, '무언가 결과물을 확인할 때' 팀원들과 자신의 열정이 상승했다. 크고 작은 결과물이 나올 때 팀의 의욕이 상승했고, 결과물이 나오면 진행에 대한 믿음이 생기고 작업할 때 몰랐던 개선점이 보이며 열정이 상승한 것을 볼 수 있었다. 열정 감소를 늦추려면 성취감을 얻는 게 중요하다는 교훈이다.


    박소현 개발자는 이에 대해서 ▲작은 목표 자주 가지기, ▲진행 상황에 대한 시각적 공유, ▲정기적인 빌드와 다 함께 플레이, ▲분업구조 만들기까지 네 가지 방법을 제시했다. 욕심을 줄인 작은 목표는 달성이 쉬운 편이며, 작은 목표라도 달성하면 성취감을 느낄 수 있었고 새로운 목표의 동기가 되기도 한다.

    진행 상황을 시각적으로 공유하는 건 더 많은 정보를 담을 수 있다. 그림이나 영상은 보기가 쉽고, 전체적인 게임의 모습을 볼 수도 있어서 협업에 대한 성취감을 얻을 수 있다. 다만 시각적인 자료는 준비가 어렵고 오래 걸릴 수 있어서 공유할 빈도나 중요도를 고려해 적절한 수단을 선택하는 게 좋다.


    정기적인 빌드와 다 함께 플레이하는 부분도 중요하다. 회사에서는 PM(프로젝트 매니저)가 빌드와 플레이 일정을 조절하고 있지만 아마추어 팀에서는 빼먹기 쉬운 일이다. 개발중인 게임을 플레이하는 건 아주 큰 동기부여가 될 수 있다. 추가적으로 빌드에서만 확인되는 개선점과 버그가 있기도 하다.

    개인 작업물이 게임에 빠르게 적용되면 성취감도 좋지만 업무 효율도 늘어난다. 게임 디자이너가 데이터 조립을 하면 에디터에서 바로 결과가 확인 가능하다는 점도 장점이며 이러한 분업 구조를 채용한 회사도 적지 않다. 다만 규모가 작고 기간이 짧은 프로젝트의 경우는 이러한 '구조'를 만드는 비용이 오히려 더 커서 가성비가 나오지 않을 수 있다.



    ■ 실수해도 괜찮아


    강연의 끝에서 박소현 개발자는 실패 사례도 포스트모템해야 한다는 점을 깨달았다고 전했다. 잘한 것을 다음에도 잘하려면, 그리고 같은 실수를 줄이려면 성공 사례뿐 아니라 실패 사례도 돌아봐야 한다는 것이다. 당연한 일이 될 수 있지만 일반적으로 개발 공부를 할 때는 잘 된 사례만 보고 분석할 수 있다. 다만 그렇지 않은 사례를 포스트모템을 하는 건 출시했을 때만큼의 큰 성장 계기가 될 수도 있다.

    우리는 모두 실수를 할 수 있다. 하지만 그래도 괜찮다. 다만 실수를 실수에서 끝내지 않고, 문제나 개선책을 개인에서 찾는 게 아니라 '전체'에서 파악하려는 노력이 필요하다. 전체의 모습을 보려고 한다면 과거에는 '운이 좋지 않아서', '시간이 없어서'라며 지나갔던 일이 실수였고 개선할 수 있다는 점을 돌아볼 수 있다.