게임 제작의 복잡성에 대한 이해

게임 제작에 참여하거나 게임 제작을 관리하는데 있어서 필히 이해하고 넘어가야 하는 것 중 하나가 게임 제작의 복잡성이다. 다들 비디오 게임 개발이 어렵고 복잡하다고 관념적으로 생각하지만, 의외로 이를 충분히 이해하는 모습을 보이는 경우는 찾아보기 어렵다.

게임 제작의 복잡성에 대한 이해도가 낮은 경우 심심치 않게 보이는 입장이 바로, 게임 제작을 파트 혹은 시스템 별로 모듈화 하여 제작할 수 있다는 믿음이다. 모듈화가 성공하기 위해서는 각 모듈에 대한 규격화가 필수지만, 게임 제작에서 파트 혹은 시스템을 규격화 하는 것은 매우 어렵고 개인적으로는 불가능에 가깝다고 여기기도 한다.

게임 제작은 왜 복잡한가?

다들 알다시피 (비디오) 게임은 한가지 요소가 아닌 여러 복합 요소를 조합하여 제작하는 매체이다. 게임 제작을 진행하는 대표적인 파트는 크게 게임 디자인, 프로그램, 아트, 사운드로 나뉘곤 하는데, 이들 파트는 전체적인 게임 비전을 바탕으로 하나의 프로젝트로 묶여서 개발이 진행된다.

각 요소가 유기적으로 연결되기 위해서는 제작 초기부터 각종 사양과 명세를 각 파트가 협의하고 조정하면서 진행되어야 한다. 아트 퀄리티를 높이기 위해서는 이를 받쳐주는 프로그램 파트의 적극적인 기술 지원이 필요하다. 프로그램 역시 게임을 구현하기 위한 리소스 규격과 완성된 리소스를 아트 파트와 사운드 파트로부터 받아야 개발을 진행 시킬 수 있다.

게임 디자인 파트는 모든 파트와의 협력을 통해 게임을 구체화 시켜야 한다. 때문에 파트 간의 커뮤니케이션은 절대적이고, 하나의 목표를 정할 때 어느 한 부서만 독단적인 의사 결정이 불가능하다-캐릭터 디자인 하나를 결정하기 위해서 그다지 필요 없다고 여겨지는 프로그램이나 사운드 파트까지 포함한 모든 파트가 검토하고 조율해야 하는 과정을 거쳐야만 한다.

Bungie Ltd. – videogameschronicle.com

이것만으로도 게임 제작은 복잡성을 띄지만 불난 집에 기름을 붙는 게임 제작의 특수 요인1이 존재한다. 다른 산업 프로젝트와 달리 소프트웨어 개발 프로젝트를 순식간에 난장판으로 만드는 이 요인은 바로 이것이다.

게임 개발의 개발 명세는 프로젝트가 종료 될 때 까지도 확정이 불가능하다

아무리 세부 목표를 잘 잡고, 게임 디자인과 개발 명세가 명확하게 나온 프로젝트라고 하더라도 이는 첫 구현 이후 폐기 될 가능성이 매우 높다 – 그리고 그 이유는 “생각한 만큼 재미가 없어서”가 될 것이다.

게임 제작은 (소프트웨어 개발과 마찬가지로) 구현 → 확인 → 수정을 반복하는 과정의 연속이다. 이 일은 사실 제작자가 스스로 납득할 만한2 상태가 될 때 까지 무한 반복될 수 있다.

단순히 사이클을 반복하는 것 만으로 끝나는 것이 아니다. 작은 수정 하나가 미치는 영향은 모든 파트에서 검토되어야만 한다. 때문에 게임 개발에서 수정을 부담스러워하는 분위기가 팀을 잠식하는 것은 순식간이다.

게임 시스템에 의한 복잡도의 증가

위와 같은 이유로 단순한 게임을 만든다고 해도 복잡도가 상당하다. 하지만 여기서 끝나지 않는다.

게임은 최소 1개에서 수십 가지의 시스템(혹은 룰)이 유기적으로 동작하는 형태로 만들어진다. 게임 시스템은 독립적으로 움직이기 않기 때문에(애초에 독립적으로 움직이는 게임 시스템은 게임 내에서 의미가 없다) 탑재되는 시스템의 수량은 게임 제작의 복잡도에 즉각적인 영향을 미친다.

이는 간단한 수학 공식으로 표현 가능하다. 각 시스템을 Node 로 둔 정방형 형태의 구조를 생각해 보자. 각 Node 는 서로 다른 Node 에 모두 연결이 된다고 가정해 보자(정다각형에 가능한 모든 대각선을 만든다고 생각하면 된다). 이때의 모든 Node 간의 관계선의 수(복잡도) 공식은 아래와 같다.3

# nodes = 게임에 포함 된 게임 시스템의 수
# lines = 관계의 총 수(복잡도)
lines = nodes(nodes-1)/2

게임 시스템이 하나라고 가정 했을 때, 관계 복잡도는 0이지만, 2개일 때는 1, 5개 일 때는 10이 된다, 그리고 100개 일 때의 관계 복잡도는 무려 4,950에 이른다.

게임 시스템125102550100
관계 복잡도0110453001,2254,950
게임 시스템의 수와 관계 복잡도 간의 관계

곧 게임 시스템의 증가는 게임 제작을 어렵게 만드는 매우 큰 요인이 된다. 전체 게임 제작의 난이도를 결정 짓는 것은 결국 게임 제작 파트의 필요 커뮤니케이션 수와 게임 시스템의 관계로 부터 도출되는 복잡도에 기인한다 할 수 있다.

대책은 없는 것인가?

게임 개발이 복잡하다는 것은 대규모 게임 제작을 진행하기 훨씬 전 부터 있어왔던 문제이다. 이를 해결하기 위해 처음에는 크런치 Crunch 같은 지속적이지 못한 극약 처방부터 애자일, 스크럼, 칸반, CI, DevOps 같은 여러 대안들이 십수년 전 부터 나오고 지금도 더 나은 방안을 찾기 위해 모두가 노력 중이며, 결실을 맺은 조직도 많이 존재한다.

필요한 것은 복잡도를 해결하기 위해 노력도 좋지만 복잡도를 상수로 두되, 게임 제작의 결과를 어떻게 만들지에 대해 포커스를 맞추는 것이다. 게임 개발의 복잡성은 일종의 고정 비용으로 인정하자.

복잡도를 줄이기 위해, 혹은 복잡도를 무시하고 게임 개발 프로세스의 모듈화를 가져오는 일은 하면 안된다. 각 파트의 모듈화가 가능한 시점은 규격이 크게 바뀌지 않을 정도로 완성된 이후에나 가능한 일이며, 상기한 여러 이유로 인해 그 규격을 미리 잡는 것은 거의 불가능한 일 중 하나이다 – 규격화 된 공장제 양산 게임을 만든다면 모를까.


  1. 개인적으로 이건 소프트웨어 개발의 전반적인 요인이라 생각한다.

  2. 게임 퀄리티 뿐만 아니라 스튜디오 경영상의 문제 등 온갖 것들에 대한 납득을 의미한다

  3. 이 공식은 조직의 수가 증가함에 따라 커뮤니케이션 복잡도가 증가함을 나타낼 수도 있다

NDC 2021 강연 시청 로그

2021년 6월 9일(수) 부터 6월 11일(금) 까지 진행 된 NDC 의 세션 중 시청한 세션에 대한 간단한 기록을 남기기 위해 작성하는 글. 매우 많은 세션이 있었지만 이 중 현재 9개 정도의 세션만 시청을 한 상태.

NDC의 전체 세션 목록은 NDC 공식 홈페이지에서 확인 가능.

게임 PD가 되어보니

게임 PD, 디렉터, 프로듀서 등의 직군을 희망하거나 현재 해당 직군에 몸담고 있는 사람에게만 유용할 것으로 생각 될 수 있으나, 사실 내용은 게임 제작에 몸담고 있는 전체 구성원이 게임을 제작하면서 진지하게 같이 고민해야 할 필요가 있는 부분에 대한 이야기를 하고 있다. 게임을 어떻게 만들건데? 라는 건 어쨌든 구성원 전체의 고민과 노력이 모여서 만들어지는 것이므로.

로컬라이징 노하우 공유

로컬라이징에 대한 내용은 사실 해당 분야를 직접 경험한 소수의 인재만 노하우를 가지고 있기 때문에 이런 세션은 존재만으로도 큰 의의가 있다고 생각. 사실상 경험을 바탕으로 한 팁에 가까운 내용이고, 때문에 모든 케이스에 범용적으로 적용하긴 어려울 수 있으나, 최소한 문제 해결에 대한 힌트는 될 수 있지 않을까 한다.

게임의 성공을 만드는 전투 디자인 DNA: 스킬 네트워크를 활용한 전투 디자인 분석

성공한 게임 디자인을 통계를 바탕으로 한 빅 데이터로 분석하고 이를 다시 역으로 게임 디자인에 적용한다는 지점에 있어서 빅 데이터의 한계(결국 과거를 바탕으로 미래를 예측한다는 지점) 때문에 ‘설마 되겠어?’ 싶었던 강연. 하지만 중반 이후의 분석 결과 내용을 보고 ‘와, 저게 된다고?’ 싶었다. 역시 여유 있는 집안이 이런 걸 해줘야. (…)

하지만 아마, 만능은 아닐 것. 결국 게임 제작은 여러 복합적인 요소가 얽혀있는 문제이기 때문에 ‘새로운 이야기’를 전달하기 위해서는 이 내용만으로는 좀 모자르지 않을까 한다. 낡은 비유를 하자면 은총알 같은 존재가 아닐까 싶다.

좀 아쉬운 부분은 분석 결과에 대해 게임 디자인적인 언어로 번역이 다시 필요한 게 아닐까 싶은 지점이 있었단 것. 그러니깐 결국 게임 디자인은 어떠한 체험과 선택을 하게 만들 것인가? 라는 부분이 존재한다고 했을때, 이 분석이 가지는 의의는 과연 무엇이었을까? 같은 생각이다.

게임 테스트 자동화 5년의 기록, <리니지M>과 <리니지2M>의 자동테스트 회고

본격 ‘와, 저게 된다고?’ 시즌 2. 젠장, 우리는 아직도 빌드 나오면 사람 갈아 넣는데. (눈물)

테스트 자동화 뿐만 아니라, 프로젝트에서 사람 갈아 넣는 부분을 최대한 자동화 해야 한다는게 요즘 신조인지라 여러모로 부럽기만 한 내용의 세션이었음.

<쿠키런: 킹덤> 감정을 움직이는 사랑받는 게임 만들기 – 쿠키런 킹덤 4년, 게임 개발 분투기

올해 초, 꽤 인상 깊게 즐겼던 ‘쿠킹덤’의 제작 포스트모템. 프로젝트에 대한 발표자들의 애정이 느껴지는 세션이었다.

다만, 저걸 곧이곧대로 믿으면 안된다. 결국 중요한 건, 방식이 아니라, 얼마나 끝까지 프로젝트에 애정을 가지고 고민하고, 움직이느냐 인거지, 세부적인 설정을 하네, 컨셉 아트를 그리네, 프로토타입을 하네 등등의 지엽적인 부분만 체크하면 곤란할 것.

제한된 선택지로 유저가 주인공이 되는 시나리오 만들기 – TRPG 시나리오의 구성 방식을 기반으로

사실 TRPG를 이용하는 등의 기술적인 부분 보다는 게임 시나리오, 그리고 그에 연관된 시스템들을 통해 어떻게 유저에게 이야기를 전달해야 하나 같은, 세션 내용 너머 지점에 대한 이야기가 좀 더 흥미롭게 다가왔다. 관련한 내용을 동료들과 고민하면 좋겠단 생각이 들었던 세션 중 하나.

사수 없는 밸런스 디자이너를 위한 전투, 성장 밸런스 설계 방향 노하우 공유

이 세션 역시 정작 밸런스 설계 방법 보다는 ‘처음 해보는, 아무것도 모르는 일을 맨 땅에 헤딩 하면서 좀 덜 다치는 방법’에 대한 내용이 더 끌렸다. 의외로 다들 문제를 해결하는 방법에 대해 참 많이 어려워 하더라고.

커뮤니케이션이라는 함정에 빠진 기획자

이 세션을 본 날 비슷한 함정에 빠질 뻔 한 동료에게 바로 이 세션 영상을 보길 권했다.

뭐, 물론 그렇다고 함정에서 성공적으로 빠져나왔느냐 하면, 트랩 카드가 너무 강려크 했다는게 함정이지.

게임 서버를 품은 쿠버네티스 – 데브시스터즈가 게임 인프라를 쿠버네티스에서 운영하는 방법

최신 유행 개발 프로세스인 데브 옵스를 성공적으로 정착시킨 사례를 소개하는 세션. 쿠버네티스는 이번에 처음 알았습니다 그려. (…)

내용은 지금 진행 중인 프로젝트에서도 필요한 부분이라 관련 분야에 대한 관심이 지속 증폭 중. 이런 내용을 같이 이야기 할 수 있는 사람이 주변에 존재하지 않는게 좀 아쉽긴 합니다만.

당신은 게임 개발자입니까?

게임 개발자의 정의에 대한 논란은 사실상 대한민국의 게임 산업이 급격하게 성장하기 시작한 2000년대 초 부터 있어오지 않았나 합니다. 그 이전의 국내의 게임 산업이란 것은 아직 체계화 되어 있지 않았었고, 당연히 분업화도 정확하게 이뤄지지 않은 상태로 걸음마를 떼고 있는 중이었습니다.

물론 기초적인 수준의 기획 / 프로그램 / 그래픽 아트 / 사운드의 분업화는 있었지만, 요즘처럼 세분화되고, 다양한 전문 분야로 나눠지지는 않았습니다. 이런 시기에 게임 회사에 다니는 대부분의 종사자들은 게임 개발자일 수 밖에 없었을 겁니다(물론 경영지원파트를 따로 두는 정말 몇 안되는 경우를 제외하곤 말이지요).

Global Game Jame Anntwerp (http://www.ggjantwerp.com)

게임 산업이 발전하고, 비디오 게임 제작이 예전과는 다르게 매우 복잡한 형태를 띄기 시작하면서 게임 개발자의 직무 분업화는 복잡해지고 정교해졌습니다. 기획은 게임 디자인 영역 뿐만 아니라, 비즈니스, 개발 관리, 게임 제작 디렉션, 프로덕션 등으로 분화되기 시작했고, 프로그램의 경우도, 클라이언트, 서버, 엔진, 툴, DB 등으로 점차 분류를 다양화하기 시작했지요. 그래픽이나 사운드의 경우도 마찬가지로 예전에는 1 ~ 2 인의 작업자가 모든 과정에 관여했다면, 지금은 각 과정에 대해 전문적으로 업무를 진행하는 직군이 생기기 시작했습니다.

추측하건데, 게임 개발자의 정의에 대한 논란은 산업이 성장하면서 게임 개발의 분업화, 세분화가 일어면서 덩달아 시작되지 않았나 합니다. 여기에 더해, 타 분야(일반 소프트웨어 직군, 문화 예술 직군, 경영 경제 직군 등)와의 인적, 물적 교류가 활발히 일어나기 시작하면서, 각 분야 별로 서로 다른 개발자 기준이 논란을 가속 시킨 것 아닌가 합니다 – 거기에 특정 핵심 직군의 비대칭적인 몸값 형성으로 발생한 인사 관리/비용 관리 측면의 ‘가르기’가 게임 개발자의 의미를 한정적으로 만드는데 일조하고 있습니다.

2021년 연봉 인상 레이스. 개발직과 비개발직을 나누는 이유야 분명 있겠지요.
출처: 향이네 DB

일반인들이 생각하기에, 소프트웨어 개발은 프로그래머인 개발자들이 핵심이라 생각합니다. 비디오 게임도 일종의 소프트웨어이니 당연히 게임 개발의 중심에도 프로그래머가 있습니다. 하지만, 현대의 비디오 게임 산업 체계에서 제작되는 게임은 프로그래머 만으로 제작되기에는 많은 한계가 있음엔 분명합니다. 이런 의미에서 “게임 개발자”는 게임의 개발에 직 간접적으로 참여하는 모든 직군(과격하게 이야기하자면 경영지원 직군의 인력까지 포함한)에게 주어져야 하는 타이틀이라 생각합니다.

게임 개발에 참여하고 있는 구성원의 게임 개발자로서의 자각은 매우 중요한 문제입니다. 보통 자신이 만드는 게임에 대한 비전이 명확하지 않은 작업자는 작업 방향을 잡지 못하고 이로 인해 작업 비용과 결과물에 심각한 문제를 일으키는 경우가 허다합니다. 하물며 게임 개발자로 자각이 없는 개발자는, 자신이 만든 결과물이 실제 게임과 관계 없거나 사용상 문제가 있는 경우가 매우 많습니다. 대부분의 경우 결과물의 의도와 목적이 “게임 제작”이 아닌 “자신의 개인적인 만족”에 향해 있는 걸로 보이지요. 이는 게임의 완성도를 저해하는 매우 큰 이유 중 하나 입니다.

이런 일이 발생하는 이유를 고민해보자면, 결국 게임 개발에 대한 명확한 인식 부재, 자신은 게임 개발자가 아니기 때문에 최종 결과물인 게임에 대한 책임은 존재하지 않는다는 생각의 흐름에서 비롯되었다 봅니다. “게임 개발은 게임 개발자(에 해당하는 프로덕션 파트와 일부 프로그래머)가 만드는 거고, 나야 그냥 단순 잡부 1이지” 같은 생각도 마찬가지 입니다.

게임 제작에 직간접적으로 관여하는 모든 참여자는 게임 개발자입니다. 기획, 프로그램, 그래픽 아트, 사운드 뿐만 아니라, 프로젝트 매니지먼트, QA, 사업 계획, 경영 관리, 경영 지원1 모두 게임을 개발하는 개발자입니다.

A game developer can range from one person who undertakes all tasks to a large business with employee responsibilities split between individual disciplines, such as programming, design, art, testing, etc.

Wikipedia: Video game developer

  1. 이런 것 까지? 라고 생각되시나요? 하지만 국내외의 게임개발컨퍼런스의 발표 카테고리를 보신다면 오히려 이런 직군들이 게임 개발자에서 빠지는게 오히려 이해가 안되실 겁니다.