NDC Replay

'가죽 장화를 먹게 해달라니'
최호영
넥슨코리아
<야생의 땅: 듀랑고>의 게임 로직 구현을 맡고 있는 5년차 프로그래머 입니다. 이전에 참여한 프로젝트: <루니아 전기>
<야생의 땅: 듀랑고> 는 높은 자유도를 표방하는 샌드박스형 게임입니다. 이에 맞추어 미리 정의된 아이템을 유저가 사용하는 것이 아니고, 정해진 시스템 안에서 유저가 원하는 특징을 조합하여 만들어내는 방식의 시스템 구현을 목표로 작업해 왔습니다. 이러한 작업의 과정을 프로토타입부터 현재까지 어떻게 진행해 왔는지 살펴보고 시스템의 장.단점과 작업하면서 어려웠던 점은 무었이었는지를 공유하고자 합니다.
[새 창에서 슬라이드 보기]
안녕하세요, 저는 왓스튜디오에서 프로그래머로 일하고 있는 최호영이라고 합니다. 반갑습니다. 저는 가죽 장화를 먹게 해달라니, 라는 제목으로 발표를 할 건데요. 사실 약간 쇼성 제목이고, 실제 제목은 밑에 있죠. 자유도 높은 아이템 시스템 구현입니다. 그래서 어떻게 구현했는지 공유를 해드리고, 뭔가 비전을 제시한다기 보다는 비슷한 류의 것들을 다시 만들 때 도움이 되는 케이스를 제공하고자 이런 발표를 마련을 했고요. 저를 소개하겠습니다. 저는 만 5년 된 프로그래머이고요. 테크니컬 디자이너라고 붙여 놨는데 이게 뭔가 거창한 건 아니고 얼마 전에 리더님이 한 마디 하시길래 멋있어서 그냥 붙여봤어요. 아이템 시스템이니까요, 아이템 먼저 얘기를 시작해 볼까 하는데요. 아이템이라는 것은 게임 컨텐츠의 기본이 되는 블록이라고 해야겠죠. 이 아이템은 현실적인 요소부터 한 번 보려고 합니다. 우리 속칭 빠로라고 하는 아이템, 다들 아시죠. 아이템이죠. 저희는 아이템으로 해야 되니까. 이 빠로 라는 아이템은 뭐죠? 튼튼하게 만들어서 지렛대로서 활용하기 위해서 만들어진 그런 물건입니다. 이 빠로라는 물건을 주로 어디에 쓰죠 우리가? 빠로는 주로 외계인을 잡는 데 쓰죠. 네, 박사님이에요. 아니면 뭘 부시는 데 쓴다 던지, 가끔 문을 따는 데 쓰시는 분들도 있어요. 이거 되게 소수의 분들이 아주 가끔 못을 뽑는 데도 써요. 빠로는 사실 우리가 알다시피 못을 뽑는 데 쓸려고 만든 물건이라는 것은 알고 있죠. 하지만 결국 용도는 사용자가 결정하는 겁니다. 외계인을 잡을 때 쓸 수도 있고, 못을 뽑을 때 쓸 수도 있죠. 근데 게임에서는 좀 달라요. 여기 나오는 아이템은 마비노기 영웅전의 미국 서비스인 빈딕터스에서 만우절 이벤트로 푼 거래요. 빠로인데요, 빠로에요. Crow bar. 빠로인데 사실 뭐 잘 보이시진 않겠지만 써 있는 설명들을 읽어보면 우리가 흔히 아는 빠로로서의 기능은 아무것도 없어요. 전부 뭐 공격력이라든지, 밸런스, 크리티컬 이런 게 붙어 있습니다. 왜 그럴까요? 게임에서의 아이템의 용도는 개발자가 결정하기 때문이죠. 모든 게임이 그런 것은 아니지만요. 왜 이렇게 할까요? 게임에서는 특히나 마비노기 영웅전 같은 경우는 전투를 하는 게임이에요. 그거 외에 다른 정보가 있을 이유가 없죠. 빠로는 그냥 룩을 위해서, 재미를 위해서 넣은 거지 그 외의 정보는 독입니다. 이런 쓸데없는 정보까지 다 넣어서 관리를 하려고 하면 너무 복잡해져서 이것은 누구나 다 혼란스러워요. 그래서 게이머뿐만이 아니고 그걸 만드는 디자이너, 프로그래머 다 혼란스럽습니다. 그래서 디자이너들도 프로그래머한테 복잡한 시스템을 잘 요구하지 않아요. 서로 암묵적인 합의가 있는 거죠. 우리 다같이 편합시다. 근데, 해달래요. 가죽 장화를 먹게 해달래요. 왜죠? 이런 얘기 하려면 사실 저희 야생의 땅: 듀랑고라는 게임에 대해서 설명을 해야 되는데, 많은 분들이 이번 NDC 기간 동안 이런 저런 얘기를 하실 거에요. 그래서 제가 그것을 다 일일이 Repeat 하는 것은 좀 아닌 것 같고 두 시간 전에 있었던 과거의 세션, 모바일 게임의 다음 혁신, 그리고 바로 전에 있었던 가죽 장화를 먹게 해주세요, 이런 것들이 사실 관련된 세션이었고, 미래에 있는 것은 저희 디렉터 님께서 29일에 하시는 온라인 게임의 창발적 게임플레이 디자인이라는 제목을 한 세션에서도 비슷한 내용을 다룹니다. 게임이 어떤 것을 중점으로 두고 있느냐, 이런 얘기를 하는데, 결론은 그렇대요. 제가 이것을 다 설명하면 좋겠지만 그럴 필요는 없을 것 같아서 이렇게 해 놨고요. 저희 게임에서는 자유도와 창발성이 굉장히 중요한 요소입니다. 그게 유저들을 즐겁게 해 주는 데 도움이 될 거라고 생각을 하고 있어요. 근데 그게 가죽 장화를 먹는 거랑 무슨 상관이 있을까요? 가죽장화를 한 번 보시죠. 대표적인 기호품은 아니죠. 옆에 계시는 분은 그런 것 같긴 한데, 저는 아니에요. 가죽이라 함은 동물의 껍질이죠. 동물을 벗겨낸. 장화라 함은, 이렇게 설명이 있어요. 근데 잘 읽어보시면 별 거 아니지만 밑에 비가 올 때나 말을 탈 때 신는다, 라고 쓰여 있죠. 이게 원래 장화의 용도에요. 가죽 장화라고 해서 가죽이 붙었지만 어쨌든 장화잖아요. 장화의 용도인 거죠. 자, 그러면 가죽 장화라고 함은, 가죽과 장화가 있어요. 그런데 가죽 안에는 먹을 수 있는 포텐셜이 있죠. 실제로 우리가 가죽을 뜯어먹지는 않으니까. 하지만 동물의 일부이므로 사실 칼로리가 있긴 있어요. 그리고 장화라는 아이템은 물론 신기 위해서 만든 거기 때문에 우리는 절대 먹고 싶은 그런 물건은 아니에요. 입에서 가장 멀고, 바닥에 있고. 싫어요. 근데 이런 두 개를 합치면 뭐가 되요? 가죽 장화가 되죠. 근데 우리 게임은 자유도와 창발성을 강조하기 때문에 이 가죽 장화를 가지고 저 먹는 것을 살려보고 싶은 거에요. 그래서 얘를 끓여요. 가죽탕. 되나요? 일반적인 게임에서는 될 수가 없어요. 이미 가죽 장화라는 얘로는 다 합쳐졌기 때문에 얘는 더 이상 먹을 수 있는 속성이 없습니다. 그래서 우리는 똑같이 가죽 장화지만 가죽으로서의 성질을 남겨 주고 싶은 거에요. 그래서 가죽 장화를 끓이면 가죽탕을 만들 수 있고 먹을 수 있게 만들고 싶은 거죠. 여기에서 우리가 굳이 먹지 않아도 되는데 먹을 수 있는 성질을 남겨두어서 그것을 먹을 수 있게 만드는 그런 것을 저는 자유도라고 이해를 했고요. 가죽 자체는 먹을 수 없어요. 하지만 끓이는 행위와 결합이 됐을 때 먹을 수 있다는 가죽탕, 그런 속성이 나온다는 게 저는 창발성이라고 이해를 했습니다. 그래서 가죽 장화를 먹게 해주세요, 라는 말은 저희 아이템 시스템에 있어서 자유도와 창발성을 상징하는 그런 문구에요. 여러 가지 비슷한 자매품들도 있어요. 치즈로 해머를 만들게 해주세요 라든지, 그런 여러 가지가 있었는데 그냥 이것을 선택 한 거고요. 가장 더럽잖아요. 그래서 충격 요법으로 선택을 한 거고, 그렇게 해서 저희는 이 슬로건을 만족시키는 시스템을 만드는 게 목표가 되었습니다. 그러면 가죽 장화를 다시 한 번 볼까요? 가죽의 요소, 따듯함, 질김, 칼로리, 좀 불편하지만 칼로리가 있죠. 장화, 발에 신는 것 있고, 게임을 생각하면 방어도 같은 그런 것들이 있죠. 그래서 우리는 이렇게 여러 가지 속성이 있는 것을 따듯함, 질김, 칼로리, 발에 신는 것, 방어도는 구체적인 수치들이에요. 실제로 우리가 하는 것들이에요. 그래서 우리는 그것을 속성이라고 부릅니다. 그래서 저희 게임 내에서는 Attribute 라고 부르고 있어요. 가죽이나 장화는 구체적인 수치는 아니지만 그것들을 묶어서 설명할 수 있는 추상적인 개념들이에요. 물론 아닐 수도 있지만, 가죽 같은 경우에는 조금 구체적이긴 하지만 그런 것들을 우리는 특성이라고 부르고, 게임 내에서 Tag라고 이름을 붙였습니다. 그래서 결국 얘기하고자 하는 바는 아이템은 특성, 게임 내에서 태그라고 부르는 존재들의 조합인 셈이죠. 그럼 이 아이템을 어떻게 만들어야 될까요? 게임에서 아이템은 어디서나 나와야 되는데. 기존 시스템에서는 아이템이 그냥 데이터에 있어요. 그래서 필요하면 거기서 그냥 겨오거나, 혹은 거기에 랜덤성을 부여해서 적당히 랜덤한 것들을 가져오거나 이런 방식으로 하고 있어요. 마치 황새가 애를 물어다 주는 것과 비슷하죠. 그런데 현실은 그렇지 않아요. 재료의 특성을 유지한다는 것은 마치 부모의 형질을 유전에 의해서 받는 것과 같은 느낌이에요. 그래서 재료의 특성을 유지하기 위해서는 기존의 방식으로 하지 않고 뭔가 거기에다 랜덤성까지 추가 해서 이런 방식으로 생산을 해야 될 것 같죠. 네, 여기 네 쌍둥이가 있어요. 같지만 다르죠. 같은 종류의 특성을 가지고 있을 거에요, 쌍둥이니까. 비슷한 형질을 가지고 있겠죠. 키도 비슷할 거고, 생긴 것도 비슷하지만 분명히 달라요. 저희는 이것을 만들어야 되는 거에요. 가운데 이상한 애가 하나 있죠. 돌연변이에요. 예상치 못한 특성으로 인해서 생긴다고 생각을 합니다. 물론 저희가 정말 돌연변이를 만들 것은 아니고요, 약간 계산된, 그래서 시스템 내부적으로 숨겨져 있다가 어느 순간 유저의 행동에 의해서 툭 튀어나오는 요소들. 그런 것들을 돌연변이라고 부르고 있습니다. 그래서 이런 것을 하려면 어떤 방법들로 생성을 할까요? 첫 번째, 채집이 있죠. 월드 내에서 처음으로 아이템을 유저들이 획득하게 되는 경로입니다. 시스템에서 그냥 생성해서 줘요. 이런 방법도 있고요. 제작 같은 것도 있어요. 뭔가 어떤 아이템을 가공하는 의미도 있고, 요리를 하는 것도 일종의 제작이라고 할 수 있겠죠. 기존의 다른 아이템들을 섞어서 속성을 변형하거나 조합하거나 이런 것들을 제작이라고 하죠. 그런데 이 두 가지가 비슷한 특징이 있어요. 하나는 뭔가 소스가 있어요. 뭔가 데이터가 될 수도 있고, 아이템이 될 수도 있고, 그래서 채집 대상, 어떤 나무에서 나뭇가지를 가지고 온다, 아니면 어떤 돌에서 돌을 뜯어낸다. 특성이 있는 소스가 있습니다. 그럼 그것을 레시피에 넣어요. 그래서 결과로 어떤 아이템이 하나 딱 나오는데 모든 특성을 달고 있겠죠. 레시피는 우리가 채집 레시피, 제작 레시피, 건설 레시피 이렇게 내부적으로 부르고 있는데 이런 종류의 행동을 다 레시피로 퉁 칠 수가 있는 거에요. 그래서 나오는 결과물은 아이템이 될 수도 있고 건축물이 될 수도 있고. 이번 세션에서 건축물에 대해서 다루지는 않지만 저희가 건축물을 아이템과 비슷하게 취급하고 있어요. 그래서 써 놓은 거고요. 근데 레시피가 합쳐놓은 건 좋은데 너무 달라요. 무슨 생각을 하느냐, 어떤 건설을 하느냐, 어떻게 채집하느냐에 따라서 매번 속성을 섞는 방법은 다르게 될 거에요. 그래서 그걸 어떻게 해야 될 지 고민을 했어요. 이거 너무 다양해서 어떻게 해야 될 지 모르겠다. 그냥 코딩을 하자. 디자이너에게 일단 처음을 시켜보자, 해서 일단 감았어요. 물론 코딩을 전문적으로 하지 않는 프로그래머가 아닌 사람들이 코딩을 하는 것에 대해서 어려운 점이 있다는 것은 충분히 알고 있어요. 충분히 알고 있지만 여러 가지 우리가 이 당시에는 프로토타이핑을 하는 기간이었고, 일단 시도를 해 보고, 거기에서 규칙성을 찾아서 뽑아내 보자, 이런 식으로 처음에 시작을 했습니다. 그렇게 해서 저희가 프로토타입을 시작했어요. 프로토타입 Z5라고 이름을 붙였는데, 내부 적으로 여러 단계가 있었지만 처음으로 사내에 공개가 되었던 버전이에요. 그래서 프로토타입 Z5를 기준으로 말씀을 드리겠습니다. 이 Z5에서는 아이템을 아까 얘기했듯이 특성의 조합, 태그의 조합이라고 설명을 했죠. 그래서 통나무라는 아이템이 있을 때 그 특성이 뭐가 있을까, 탈 수 있는, 그리고 칼로 깎을 수 있는 것, 이런 특성들을 가지고 있다고 생각을 했고, 걔네들을 하나의 태그, 특성이라고 지정을 했습니다. 그 특성들은 각기 자신이 관심 있는 속성들이 있는데 탈 수 있는 것 같으면 건조의 정도, 두께 이런 것들이 있고 깎을 수 있는 애는 두께, 단단함. 같은 종류의 속성을 참조하기도 하겠죠, 이런 식으로. 이런 식으로 태그 시스템을 먼저 구성을 했고요 이게 가장 기본이 되는 시스템이었어요. 그래서 이 시스템을 기반으로 채집을 어떻게 하느냐를 한 번 보면, 일단 소나무라는 게 있죠. 소나무 안에는 채집할 수 있는 대상이 여러 개 있을 거에요. 그 중에서 우리는 소나무 가지를 한 번 채집을 해 보겠습니다. 소나무 가지를 유저가 선택하는 순간 생산기가 딱 불러요. 생산기는 그 안에 데이터를 가지고 있어서 내가 이 아이템을 생성하려면 채집 도구가 뭐가 필요하고, 어떤 레시피, 스크립트죠. 어떤 스크립트를 쓸 건지, 이게 originally 어떤 나무로부터 왔는지 뭐 이런 정보들을 어떤 정보를 요구하는 지를 갖고 있어요. 그래서 이것을 가지고 짠 하고 스크립트에 넣으면 저기 bough라고 되어있죠. 저게 이렇게 탁 결과물이 튀어 나오는 거에요. 그 다음에 이 결과물은 나름의 특성을 가지고 있어요. 나뭇가지니까 탈 수 있기도 하고, 나뭇가지니까 때릴 수 있으니까 둔기의 속성도 있고, 막대기도 있고 뭐 여러 가지 있어요. 속성은 또 보시면 알겠지만 좀 바뀌어요. 원래 있는 거랑. 그래서 뭔가 이 레시피를 거칠 때마다 실제 관심 있는 속성들이 조금씩 달라질 수 있기 때문에 속성의 셋이 조금 달라집니다. 그것을 허용하고 있었어요. 그래서 재질은 소나무고요. 이런 방식으로 채집이 이루어졌었습니다. 제작을 한 번 보면요, 아까 딴 소나무 가지 한번 써 볼게요. 소나무 가지가 있고, 어디서 돌날을 주웠어요. 뗀석기의 시기라 돌날이 좋아요. 그래서 날카로움과 날이라는 특성을 따로 가지고 있어요. 이게 비슷한 것 같지만 따로 있는 이유가 나름 있겠죠? 제가 계산 해 놓은 게 아니라서. 그리고 속성으로 이런 경우가 있고, 재질이 돌인 경우가 있고. 그래서 우리가 도끼 레시피에는 요구하는 것들의 슬롯이 있어요. 나는 막대기랑 날이랑 묶을 수 있는 아이템이 있으면 세 가지 섞어서 내가 도끼를 만들어 줄게. 그럼 거기에다가 소나무 가지에는 막대기라는 속성이 있죠. 돌날에는 날이라는 속성이 있고. 그래서 이 세 가지를 묶으면 묶을 수 있는 것을 어디서 갖고 왔어요. 공간이 부족해서 넣기가 좀 그렇더라고요. 그래서 이렇게 원래 있던 것들을 어느 정도 활용을 했지만 새로운 속성을 가지고 새로운 특성을 가진 결과물이 나옵니다. 이 도끼 레시피 같은 경우는 사실 단순한 편의 레시피인데요. 레시피 코드를 대충 보면 이렇게 되어있어요. 결과는 없어요, 사실. 그냥 이런 식으로 했다는 것을 보여드리려고 했던 겁니다. 여기서 주의해서 보셔야 될 것은 별 건 아닌데 속성을 설정하고 가서 태그는 따로 설정해요. 이 기획자가, 디자이너가 의도에 따라서 태그를 그때그때마다 레시피에서 직접 지정하게 되어있고, 재질 같은 경우는 위에 있는 재료들에서 따온다든지 이런 방식을 지금 취하고 있습니다. 그래서 이 정도면 됐겠지, 좀 간단한 것 같지만 어떻게 될 거야, 라고 생각하고 프로토타입으로 사내 테스트를 시작을 했어요. 좋은 돌도끼가 나왔어요. 한 손으로 들 수 있겠네요, 11kg면 그래도, 좀 무겁기는 하지만 재료가 좀.. 아, 재료가 좀 그래요. 사실 제 잘못인 거죠. 원래 재료가 좀 비슷한 게 있으면 합쳐 주고 이래야 되는데 너무 단순한 시스템을 채택하고 검증 같은 걸 잘 안 하다 보니까 똑 같은 재료를 똑같이 이용해서 계속 누적해서 만들 수가 있어요. 그래서 사실 이 아이템은 어떻게 만든 거냐 하면 도끼를 만들면 도끼 안에 막대기 속성이 아직 살아 있어요. 왜냐 하면 도끼도 막대기니까. 그럼 그 도끼를 이용해서 다시 도끼를 만들어요. 뭔가 이상한 것 같지만 시스템은 허용하고 있어요. 그러니까 하는 거죠. 하다 보면 뭐 무게도 올라가고, 다 좋아진대요. 그런 파워 돌도끼, 이런 돌도끼가 나오기도 했고요. 파워 튀김이에요. 되게 좋은 아이템이에요. 우리 게임에서 에너지가 맥스를 100으로 가정하고 있었는데 한 번에 3000을 줘요. 3000 먹어볼 만 하지 않나요? 지방이어도? 이런 식의 아이템들을 나오게 했는데요. 그 외에도 이상한 것들이 있어요. 아까 그 도끼 누적하듯이 누적하면 1억이 넘어요. 참고로 저희는 공격력이 수십 이런 게임이었는데 만드시더라고요. 밑에 거, 네, 생각도 못해 봤어요. 만들어주더라고요. 이 외에도 다양한 사례가 있었는데 사실 이게 좀 시간이 지난 일이라 재미있는 사례들은 많이 잊혀져서 이 정도가 남은 거고요. 하아, 힘들죠. 이게 뭐야, 왜 그랬는지 찾으려면 너무 힘들어요. 왜냐 하면 아이템 히스토리가 다 남아있는 것도 아니고, 이건 시스템에 의해서 만들어 진 거지 유저가 조작을 가한 것도 아니에요. 그렇다 보니까 그 히스토리를 추적하는 것도 너무 힘들고, 어려웠어요. 이유가 뭐냐, 데이터의 파편화가 1번 문제에요. 데이터가 특성, 재질, 속성을 설정하는 것도 있고, 아이템을 생성하는 것도 있고, 이 데이터를 다 다른 파일에 작성해요. 그런데 저희는 아직 프로토타입 시기였기 때문에 툴도 없고, 디자이너 분이 직접 파일을 건드려서 수정을 해야 돼요. 그러니까 매번 아이템을 하나 고칠 때마다 두세 개 이상의 파일을 한꺼번에 고쳐야 되는 거에요. 실수가 일어날 수밖에 없겠죠. 그래서 이런 문제가 생겼고요. 스크립트를 쓰는 것 당연히 문제입니다. 이것은 디자이너 분이 잘못한 게 아니고 사실 제가 잘못한 거죠. 프로그래머가 아닌데 코딩을 하게 했으니까요. 여러 가지 오류가 있을 수 있었어요. 당연한 거죠. 데이터가 발산 하는 것, 아까 공격력 1억이라든지, 아니면 뭐 돌돌돌돌돌돌도끼라든지, 이런 것들이 있겠죠. 이런 것들을 데이터로 컨트롤 할 수 있게 때문에 일어난 일이에요. 무슨 일이 일어날 지 잘 모르고 처음에 디자인을 해야 되니까 이게 나중 가서 걷잡을 수가 없는데 왜 생겼는지도 잘 모르고, 원인 파악도 잘 안 되고 이러니까 컨트롤이 안 돼요. 처음부터 엄격한 룰을 해서 무조건 공격력 100이 넘으면 잘라, 이렇게 만들 수도 있죠. 근데 그러면 재미가 없잖아요. 우리 게임의 특징은 그게 아닌데. 그래서 이것을 어떻게 알까, 시스템 자체는 재미있다는 평을 많이 들었어요, 이 때. 저희도 되게 고무적이었고 기분이 좋았는데, 하지만 테스트를 하면 아이템을 하나 수정할 때마다 에러가 이상한 데에서 툭툭 튀어나오니까 테스트가 너무 비싸요. 디자이너는 죽어요. 너무 힘들어, 제가 보기에도 힘들어 보여요. 이게 문제가 있죠. 그래서 Z5가 끝나고 나서 저희가 데이터 구조를 좀 바꿔 보기로 했어요. 그래서 좀 엄격하게 한 건데요. 예전에는 아이템 안에 속성이 있었고, 걔가 특성이 속성을 그냥 참조하는 수준이었어요. 그러다 보니까 아이템에 속성이 없거나, 이런 일도 생기고, 아니면 우리가 예상치 못한 그런 일들이 발생할 수 있어서 속성을 특성에다 묶어버렸어요, 태그에다가. 그래서 이 특성이 있는 애는 이 속성이 있을 수밖에 없어, 라는 것을 강요한 거죠. 그래서 이런 식으로 해서 엄격한 데이터를 만들었고요. 그 다음에 데이터 입력 툴을 한 번 만들어 봤어요. 제가 개인적으로 한 건데, 웹페이지를 이용해서 만들었는데, 하는 형식은 데이터를 직접 손으로 쓰니까 오류가 많이 일어나잖아요, 복사하기도 하고. 아니면 스크립트 같은 경우도 기본적인 에러를 서버에서 바로 잡아서 여기다가 완료 누르면 자동으로 검증해주고, 이런 식의 시스템을 넣었어요. 그 다음에 validation이라고 부르는 개념을 넣었는데, 툴 타임에 데이터를 분석하는 거에요. 데이터가 많이 파편화되어있다 보니까 그것을 서로 연결을 해서 이게 잘 있나, 이 데이터 있나, 확인하고 이 데이터가 well-formed, 잘 형식에 맞추어져 있는가 이런 것을 확인하는 역할을 했어요. 스크립트도 validation을 해야겠어요. 근데 이게 좀 문제가 있는 게 네 쌍둥이잖아요. 아이템이 비슷한데 다 달라요. 그러니까 우리 스크립트 입장에서 무슨 아이템이 들어올지 사실 알 수 없어요. 대충 비슷하게 들어오겠지 하겠지만 아까처럼 1억짜리 무기가 들어올 수 있고, 뭔가 예상하지 못한 게 들어올 수 있기 때문에 우리가 이것을 툴 타임에 validation을 할 수가 없는 거에요. 얘를 돌려볼 수가 없어요. 그래서 좀 이상한 애를 하나 만들었어요. 얘는 기존의 서버에 있는 시스템에 아이템 클래스를 상속을 받아서 뭔가 아이템인 척을 하지만 사실 아이템은 아니에요. 그리고 얘한테 뭔가 사전 정보를 좀 줘서 너 아마 도끼로 만들었을걸? 이렇게 주면 대충 비슷한 것들을 잘 내놔요. 그래서 얘의 역할은 실제 유의미한 제작 결과를 뱉는 건 아니고요, 그냥 스크립트가 한번 돌아 보는 거에요. 그러면 아주 발산 문제라든지 이런 것은 잡지 못하지만 그래도 어느 정도 스크립트 자체는 테스트할 수 있게 만들어 주는 거죠. 그래서 밸리데이터를 돌리면, 네, 스샷만 올리기 너무 뻘쭘해서 대문자로 크게 한 번 적어 봤어요, VALIDATOR. 보면은 여러 가지 에러 메시지를 내뱉어 주고 있고요. 이것을 활용해서 조금 더 일찍 디자이너가 직접 에러 메시지를 확인하고 뭐가 문제 있는지 확인할 수 있게 만든 거죠. 그리고 뭐 이렇게까지 이런 작업들을 하고 나서 지난 4월말에 사내 테스트를 저희가 했어요. 내부적으로 이제 랩터 빌드라는 이름을 붙이고 사내 테스트를 했는데, 이 사내 테스트를 해보니까 작업 해보면서 데이터로 인한 오류가 사실 꽤 감소했어요. 툴 타임에 오류를 검증하니까 이게 꽤 좋아요. 그래서 테스트 비용도 많이 줄었고, 이상한 뻘짓은 안 해도 되거든요. 그리고 사실 예전에는 스크립트에서 오류가 나면 프로그래머가 가서 도와줘야 돼요. 디버깅을 해 줘야 되고, 여전히 그런 일이 없는 건 아니지만 비교적 많이 감소를 했어요. 그래서 멘붕도 여러모로 감소를 했죠. 근데 이제 이건 좋은 얘기만 써 놓은 거고, 데이터 입력 툴은 실패했어요. 제가 아까 만든 웹페이지 같은 경우는 이렇게 일일이 입력할 수 있는데 대량의 데이터를 가지고 작업해야 되는 디자이너 입장에서는 하나씩 클릭해서 입력하고 형식에 맞춰서 입력하는 건 너무 의미가 없는 거에요. 그래서 이건 하기가 너무 힘들어요. 그래서 엑셀 같은 툴을 이용해서 대규모 데이터로 호환하거나 이런 게 아니면 사실 별로 의미가 없더라고요. 그래서 약간 뻘짓이 되었는데, 이런 일이 있었고. Validator는 잘 동작하고 있어요, 좋아요. 그런데 실패하는 케이스를 발생하기 시작해요. 이전에는 좀 단순한 방식으로 스크립트를 썼다면 이제 우리 게임은 디자이너에게 자유도를 높게 주는 게 의도 중 하나이기 때문에 스크립트 안에서 여러 개를 시도하는데 안에 분기점이 있어요. 뭐 일 때는 뭐 하고, 뭐 일 때는 뭐 하고, 그러면 validator는 의미 있는 데이터를 내보내는 애가 아니기 때문에 그 분기점 중 언제나 고정된 한 가지 루트만 타게 되어있어요. 그래서 그 루트가 아닌 다른 루트로 가는 데에서 에러가 나면 이것을 잡을 수가 없는 거죠. 그런 문제가 있고, 심지어 분기가 랜덤이에요. 그러면 이것을 어떻게 할 수가 없어서 5%의 확률을 잡기 위해서 validator 100번 돌려요. 되게 이상한 짓인데 그거라도 해야 되겠다 싶어서 한 거에요. 그러다 보면 이제 여러 번 하다 보면 잡히기도 하고, 아니기도 하고 이런 식으로 했었거든요. 이런 실패 케이스가 발생을 하고, 사실 제일 큰 문제인데 아까 얘기했다시피 태그에다가, 특성에다가 속성을 묶어 버렸거든요. 그러면서 구조가 되게 엄격해지고 딱딱해졌어요. 그래서 재미가 없어지는 거죠. 언제나 기대하던 특성이 있으면 그 속성은 있게 마련이거든요. 그래서 새로운 뭔가 잉여력이 없는 거에요. 언제나 딱 기대하던 데이터만 있어요. 그렇기 때문에 기획 디자이너가 의도한 기획 데이터만 있고 해서 사실상 창발성이 없어진 거에요. 자유도를 억지로 디자이너가 디자인 상에서 만들 수는 있지만 시스템상에서는 많이 없어진 거죠. 그래서 세 번째 이터레이션을 시작합니다. 요즘 한창 하고 있는 일이고요. 그래서 속성을 결국 예전에 Z5 방식으로 다시 한 번 돌려봤어요. 그래서 돌리되, 그대로 가면 안되겠죠. 그래서 특성이 관심을 갖지 않는 애들은 예전에는 그냥 가지지 않았어요, 아이템이. 나는 걔 관심 없는데 그냥 버리거나 아예 세팅하지 않거나 그랬어요. 근데 이제는 기본값들을 다 가지고 있고 언제든지 접근하면 그 데이터가 없더라도 데이터에 설정된 기본값들을 가져온다든지, 아니면 차후에는 레시피 같은 데에서 특별히 디자이너가 지정하지 않아도 정해진 식으로 속성들을 자동으로 어느 정도 개설해 준다든지, 그래서 디자이너가 레시피에서 의도하지 않은 것, 레시피 밖에서 다른 시스템으로 의도할 수 있지만 레시피 안에서 의도하지 않은 것들이 일어나게 만들어서 창발적인 요소를 만들려고 하는 거에요. 유도하는 거고, 그 유도는 사실상 여기서 주요하게 발휘되는 건데요. 지금까지는 특성, 그러니까 특성들을 기획자가 레시피에서 의도적으로 붙였어요. 그래서 이 레시피를 통과하면 날카로움이 있겠구나, 도끼가 있겠구나, 근데 그것을 하면 창발적인 요인이 나오지 않아서 속성 조건을 만족하며 자동으로 붙는 그런 특성을 만들려고 하고 있습니다. 만들고 있고요. 그래서 비교적 간단한 규칙으로 만들되, 이것을 유지를 하는 것 만으로도 충분히 유저들이 창발성을 느낄 수 있도록, 그래서 예상하지 못했던 내가 다른 재료로 만들었을 때 이 특성이 나오지 않았는데, 어느 날 이것으로 만드니까 나오더라. 이런 요소들을 만들어서 뭔가 창발적인 플레이에 기여할 수 있도록 만들었습니다. 그리고 스크립트를 여전히 쓰고 있어요, 사실. 이유가 뭐냐 하면, 이쯤 오면 버릴 것도 같은데, 여전히 규칙을 찾기가 너무 힘들어요. 그리고 이것을 빼는 순간 디자이너에게도 자유도를 너무 뺏는 셈이 되어서 이것을 최대한 유지하려고 노력하면서 하니까 이게 좀 어떻게든 엄격하게 해볼까, 하고 만드는 것들입니다. 사용법을 최대한 단순하게 만들어요. 모든 디자이너에게 노출되는 클래스는 전부 랩핑합니다. 전부 랩핑해서 딱 필요한 메소드, 딱 필요한 항목들만 쓸 수 있게 하고요, 그게 아니면 툴 타임에서 체크할 수 있는 exception이 나도록 만들었어요. 그래서 최대한 단순하게 만들고 그 다음에 이 두 줄이 있잖아요, 코드가. 위에 줄이 제 옛날 거고, 아래 줄이 새 방식이에요. 별 거 아니죠, 사실. 딱 보면 별 거 아니에요. 근데 별 거 아니더라도 이 정도라도 최대한 되게 편하게, 디자이너가 특별히 신경 쓰지 않고 그냥 생각하는 대로 쓰면 되게 만들려고 되게 노력을 하고 있습니다. 그 다음에 스크립트의 분기점 아까 얘기 했었잖아요. validation이 계속 실패하는 이유에 대해서도 많은 고민을 하고 있는데 저희가 일단 생각하고 있는 방법은 분기점을 사용하는 방식을 규격화하는 거에요. 그래서 디자이너 분과 상의를 해서 분기점이 일반적으로 이렇게 이렇게 쓰이더라, 라고 하는 형식을 만들고 애초부터 그 데이터를 받으면 그것을 분석해서 우리가 밸리데이터에서 분기점을 따라서 다 한번씩 훑을 수 있게 만들 수 있도록 하려고 해보고 있습니다. 얘는 아직 작업이 안 된 상태고, 저희가 가정만 하고 있는 거고요. 그 다음에 조금 더 희망하는, 원하는 작업인데 발산에 대한 것은 아직도 해결이 안 되었어요. 물론 디자이너가 개인적인 룰을 이용해서 막을 수는 있겠지만 한계가 있기 때문에 그 검증해 주는 것을 만들고 싶은 거에요. 그래서 어떤 레시피를 통과해서 제작이나 이런 것을 했을 때 나오는 결과를 우리 일반적으로 어떤 범주의 것을 랜덤 요소를 결정해서 탁 수치가 나오죠. 근데 그렇게 하지 않고 가상의 아이템을 만들어서 그 범위 자체를 포함하고 있게 만드는 거죠, 그 아이템이. 그것을 다시 어디 집이나 메모리나 이런 데에 넣어 놓고 얘를 이용해서 계속 다시 생산하는 거에요. 다른 레시피 또 돌려보고, 들어갈 수 있는 것 또 돌려보고, 이것을 자동으로 오랫동안 해 보면서 혹시 내가 이 아이템이 과거에 만든 히스토리에 같은 레시피를 쓴 적이 있었는데 그 레시피에 넣었던 것보다 지금의 범위가 더 넓다, 그럼 발산인 거죠. 그런 경우를 체크하는 방식의 툴을 만들고 싶은데 이게 언제 사실 시간이 오래 걸리는 일이라서 실제로 할 수 있는지는 잘 모르겠어요. 근데 하고 싶은 툴입니다. 여기까지가 이제 제가 작업했던 것들, 이런 거였고요. 작업을 하면서 가장 크게 느낀 건 소통이었어요. 사실 느끼셨는지 모르겠는데 저는 프로그래머 세션인데도 불구하고 사실 PT의 반 정도를 디자인을 설명하는 데 썼어요. 이런 디자인을 만들었고, 이게 왜 그랬고, 이거는 제가 디자이너와 소통한 제 업무 대비 비중이랑 비슷해요, 사실상. 제 업무의 반을 그 정도에 쓴 거죠. 그만큼 중요합니다. 왜냐 하면 이런 복잡도가 높고 자유로운 시스템들은 서로 그 의도를 공유하지 않으면 어떻게 해결을 할 수가 없어요. 계속 문제가 생기면 재작업을 해야 되는데 복잡한 시스템은 재작업이 너무 비싸요. 그것을 최대한 막기 위해서 계속 소통을 해야 되고, 계속 얘기를 해야 됩니다. 해서 좀 작은 단위로, 우리는 아이템을 작업하고 있어, 라는 TF로 묶어서 작업을 하기도 하고, 이런 방식을 이용해서 최대한 소통을 많이 하는 게 중요했던 것 같습니다. 보시면 알겠지만 복잡한 시스템, 자유도가 높고 창발성이 요구되는 시스템은 작업자의 실수를 잡아줘야 돼요. 이것은 실수는 누구라도 당연히 하는 것이기 때문에 툴이 잡아줘야 하는 거고 그 툴을 처음부터 이 시스템을 디자인할 때부터 감안을 해야 된다고 생각합니다. 처음에는 그러지 않아서 이 시스템을 만들 때 초반에 되게 고생을 했어요. 그래서 이런 툴을 먼저 감안을 하고 작업을 했으면 좋겠다. 그리고 사실 세 번째 말도 되게 당연한 얘기인데 이것을 굳이 꺼내는 이유는 시스템이 복잡하고 커지면 이터레이션을 내리게 하게 돼요. 하고 싶어 져요. 아, 나 이것까지 더 구현하고 테스트하고 싶은데, 이거 더 해보고 싶은데, 근데 그 욕심을 복잡할수록 오히려 더 버려야 된다는 생각이 들었어요. 이게 하면 할수록 재 작업의 비용이 너무 크기 때문에 최대한 욕심을 많이 자제하고, 제가 욕심을 되게 많이 부리는 편이거든요. 그래서 욕심을 최대한 자제하고 작업하는 게 굉장히 중요하다고 느꼈습니다. 저의 발표는 여기까지고요, 들어주셔서 감사합니다. 
질문이 별로 없네요. 1등이 제 생일을 축하한대요. 제가 오늘 생일이거든요. 감사합니다. 굳이 축하를 받고 싶어서 읽어 봤어요.
“창발성을 위해서 돌돌돌돌돌도끼 식의 제작을 다시 활용할 생각은 없나요? 굳이 막아야 할 이유도 없을 것 같은데”
이 방식 자체를 막는 건 아니에요. 그러니까 원래 재료를 다시 넣고 다시 넣고 하는 것 자체를 막겠다는 것은 아니고요. 돌돌돌돌도끼는 막겠죠. 이름이 너무 이상하잖아요. 그래서 그런 것은 막겠지만 그런 방식은 유지하려고 노력은 하는데, 이것을 발산하지 않게 시스템적으로 잘 컨트롤을 하겠다는 거지, 막겠다는 뜻은 아닙니다.
“첫 번째 이터레이션은 3개월이라고 했는데, 두 번째는 얼마나 걸렸나요?” 
이게 약간 애매한 부분이 있는 게 첫 번째를 하고 두 번째로 할 때 여러 가지 바뀐 것들이 굉장히 많았어요. 언어도 바뀌고, 그 때는 프로토타입이었기 때문에 이 쪽 지금 우리가 사내 테스트를 한 랩터빌드라는 버전은 리테일 버전이에요. 프로덕션이에요. 그래서 바뀌는 게 많았다 보니까 비교하기가 애매한 부분은 있는데 어쨌든 한 6개월 걸렸나요? 7개월? 그 정도 걸린 것 같아요.
“창발성을 높였을 경우에 버그가 많이 발생하지 않나요?”
네, 많이 나죠. 그게 문제에요. 그것을 해결하기 위해서 열심히 오늘도 노력하고 있습니다. 
“가죽 장화 100개 먹은 업적이라도 혹시 있나요?”
아... 아직은 없어요. 네, 그렇습니다.
“찰리 채플린과 협의했나요?”
추천이 0이다. 뭔지 모르겠어요, 무슨 뜻이죠? 아, 그렇네요. 그 장면 저도 찾아서 봤었네요. 협의하지 않았습니다. 협의하기 힘들 더라고요. 만나기가 좀 비싼 분이에요. 그렇습니다. 
사실 시간은 제가 빨리 끝난 편이라서 되게 많이 남았는데, 질문이.. 추천이 0개지만 남아있는 것들이 있어서 마저 읽기는 할게요. 
“PPT에 있는 것 이외에도 기획자의 스크립트 개발 포화를 줄일 수 있는 방법을 더 갖고 계신가요?”
 사실 아직 없습니다. 지금 나와있는 것만 해도 다 구현해본 것이 아니라서, 저것을 해 보고, 나오는 문제점을 보고 다시 시도를 해야겠죠. 지금은 없습니다.
“개발사, 개발팀마다 툴이 있는데 이것을 공유, 공동 발전시켜 개발사의 노하우로 만드는 경우는 많이 못 봤습니다. 이것은 어떻게 생각하세요?”
네, 같이 하면 좋겠죠. 근데 사실 현실적으로 힘든 것을 다 알잖아요, 우리가. 그게 쉬운 일은 아니죠. 그렇게 하는 게 좋다고 생각합니다, 저의 생각을 물어보셨으니까.
“DSL이라는 책을 재미있게 읽었습니다. 강연 내용에서 스크립트의 얘기가 많이 나왔는데 구체적인 구현 방식이나 제작 도구들에 대한 경험이나 조언을 들을 수 있을까요?”
는 되게 개인적인 얘기거나 혹은 제가 답변해 드릴 수 없는 얘기가 될 것 같아서 넘어가겠습니다.
“현실 이론이 기반된 기초 과학적 재료를 기반으로 생산할 수 있나요?”
의도하는 바입니다만 그게 실제로 얼마나 구현이 될 수 있을지는 잘 모르겠습니다. 그렇다고 저희가 아주 과학적인 시스템을 디자인하는 것은 아니고 재미있는 시스템을 디자인 하는 거니까요.
TITLE	TITLE	TITLE	TITLE
TITLE	TITLE	TITLE	TITLE
전체보기
