밀피유의 이야기

라이트스피드의 개발 도구인 EMT는 게임 개발이 어떤 식으로 변화해 가고 있는지를 알아보는데 도움이 되었습니다. EMT는 그냥 Entity Modelling Tool의 약자입니다. 간단히 엔티티를 그리는 도구라는 의미입니다. 라이트스피드에서 어떤 기능은 엔티티 간에 관계로 이루어집니다. 미리 만들어진 여러 가지 기능을 상속해 새로운 기능을 만들어내는데 사용하거나, 새로운 기능을 프로그래머 손을 빌리지 않고 빨리 프로토타이핑 하는데 사용할 수도 있습니다.

게임 상에 동굴이 하나 있는데, 동굴을 바위로 막아 놓고 바위를 굴려서 치우면 동굴에 들어갈 수 있도록 하고 싶다고 칩시다. 바위 모델이야 어디서든 주워올 수 있겠지만 바위에 물리도 붙여야 하고 배치도 해야 하는 등 기획자 혼자서 할 수 있는 일이 별로 없습니다. 결국 기획자는 방금 이야기한 내용을 손가락 아프게 기획서로 만들거나, 입 아프게 프로그래머에게 이야기해야 합니다. 더 골때리는 건 바위를 만들어놓고 보니 구려서 도로 치워야 하는 상황입니다. 두 사람과 두 파트를 거친 이터레이션은 '동굴 앞을 바위로 막아봤더니 구리더라'라는 시행착오에 의한 교훈을 남기기는 했지만 생각보다 많은 자원을 소모해 버렸습니다.

대신 EMT에서는 미리 만들어진 기능을 이리 저리 붙여서 동굴 앞을 막은 바위를 만들 수 있습니다. 일단 바위 모델을 하나 만들고 모델 애셋을 지정해 줍니다. 그럼 일단 게임 상에 바위 모델이 나타납니다. 이걸 적당하 배치해 놓고 피직스 모델을 상속해 줍니다. 피직스 모델에는 충돌 모형이나 무게, 중력 따위를 설정할 수 있습니다. 여기까지 진행하면 기획자는 다른 자원 없이 동굴 입구를 막은 바위를 만들어볼 수 있고 아까와 똑같은 '동굴 앞을 바위로 막아봤더니 구리더라'라는 교훈을 얻었지만 이번에는 자원을 훨씬 덜 소모했습니다.

사실 위에서 간단히 바위에 모델 애셋 지정하고 피직스 모델 떨구는 걸로 끝난 동굴 앞 바위 막기는 실제로는 훨씬 더 복잡한 과정을 감추고 있습니다. 모델은 라이트를 받아 그림자도 그려야 하고 텍스처는 어떻게 할 것이며 바위가 굴러갈 때 이펙트는 어떻게 할 것이며 피직스 모델은 하위에 복잡한 물리 속성을 감추고 있기까지 합니다. 대신 기존에는 이 모든 과정을 다른 스텝의 도움을 받아야 했다면 이제는 잘 추상화된 모델을 끌어다 붙여 놓기만 하면 프로토타이핑이 가능해졌다는 점에 의미가 있습니다.

이렇게 해 봤는데 혹시 '동굴 앞을 바위로 막아봤더니 재밌더라'라는 교훈을 얻으면 그때부터는 본격적으로 다른 스텝들에게 일을 맡기면 됩니다. 이펙터가 바위가 굴러가는 그럴싸한 이펙트를 만들고 원화가와 모델러가 동굴 앞을 막고 있을만한 그럴싸한 바위를 만들어내면 됩니다. 이건 확실히 게임에 들어갈 거고 '혹시 이거 안 들어갈까' 조마조마하며 만들지 않아도 됩니다.

기획자가 다른 스텝과 의사소통을 할 때도 훨씬 편하게 할 수 있습니다. 위에서 '동굴 앞을 바위로 막아 보자'는 내용의 기획서를 사람들에게 돌리는 것과 실제 작업할 사람들을 불러 모아 놓고 동굴 앞을 막은 바위를 게임상에서 직접 보여주며 '이런걸 만들거에요'라고 이야기하는 것 사이에는 말로 다 하기 어려울만큼 많은 차이가 있습니다. 작업자들 머리 속에는 뭘 만들어야 하는지에 대한 확실한 목표가 시각적으로 공유되어 기획서에 적힌 글자 쪼가리를 잘 못 이해해 일어나는 낭비를 줄일 수도 있습니다.

게임 개발에 많은 시행착오가 필요하다는 것은 분명한 사실이지만 이 시행착오를 최소화하고 작업자들이 모두 확실히 같은 목표를 머릿속에 넣고 작업을 진행하도록 하는 과정에 EMT 같은 도구가 큰 역할을 할 수 있을 겁니다. :)

전에 일하면서 가장 귀찮고 짜증 났던 것이 바로 ‘주둥이 기획자’입니다. 이게 뭐냐면, 도통 문서나 자료를 가지고 일하지 않는 기획자를 말합니다. 기획을 입으로 하고 입으로 판단하고 입으로 일을 진행합니다. 위에서 이 사람들의 특징을 벌써 이야기해 버렸는데, 문서나 자료가 별로 없습니다. 다른 작업자들이 참고할 만한 자료가 별로 없기 때문에 언제나 작업자들은 기획자에게 질문을 할 수밖에 없습니다. 물론 이건 꽤 좋은 상황이고, 작업자들이 아무 것도 안 하고 멈춰 있는 상황이 생기기도 합니다. 이러면 프로젝트 기간이 마구 늘어나기 시작합니다.

그래서 이런 ‘주둥이 기획자’를 싫어했습니다. 그리고 웬만하면 완성된 문서를 가지고 일하려고 했습니다. 간단한 사항도 문서로 정리하고 싶었고 웬만한 규모가 있는 기획도 문서를 가지고 진행하려고 노력했습니다. 이런 방법의 장점은 작업자에게 막막한 상황이 잘 생기지 않는다는 점입니다. 무엇을 어떻게 할지에 대한 궁금한 점은 모두 문서에 적혀 있을 테니까요. 이런 방법의 단점은 작업자에게 막막한 상황이 그래도 생긴다는 점입니다. 충분한 시간과 고민을 가지고 기획서를 만든다면 모를까, 그렇지 못한 대부분의 상황에서 기획자는 중요한 설계와 작은 구멍을 놓치게 됩니다. 그러면 여전히 작업자가 보기에 작업하기 참 막막한 상황이 되지요.

바쁜 팀에서 일하면서 어느 순간 저 자신이 주둥이로만 일하고 있다는 사실을 발견했습니다. 문서나 자료는 별 거 없었고 시간을 투자한 고민은 제 머리 속과, 디렉터와 커뮤니케이션으로만 진행되고 있었습니다. 그리고 그 결과는 작업자들에게 주둥이로만 전달됐습니다. 당연하게도 주둥이로 전달하는 데는 또 다른 한계가 있습니다. 문서라면 비교적 체계적으로 이야기할 수 있는 내용도 주둥이로 떠들면 엉망진창이 된다는 점입니다. 그리고 더 골 때리는 점은 주둥이로 떠들 시간밖에 주어지지 않는다는 점이지요.

이런 상황에서 다행인 것은 작업자들이 주둥이로 거지같이 이야기해도 잘 알아듣고 작업이 진행된다는 점입니다. 내가 주둥이로 뭘 떠들고 있는지 나 자신도 알 수 없어서 ‘내가 볼’ 기획서를 내가 만들고 앉아 있는 상황이 생기는 이 마당에 작업이 진행되고 있다는 점은 꽤 신기합니다.

사실 게임 개발처럼 요구사항이 하루에도 몇 번씩 바뀌는데다가 어느 정도 개발이 진행되기 전까지는 방향성조차 모호한 상황에서는 완결된 문서를 가지고 일을 진행시키려는 것 자체가 욕심일지도 모르겠습니다. 하지만 이전에 그렇게도 싫어하던 주둥이로만 일하는 기획자가 알고 보니 내 자신이었다는 점은 꽤 쇼킹했습니다.

개발팀 내에서 그림도 아니고 코드도 아닌 나머지 산출물은 통상 기획자들이 만들어 냅니다.코드도 아니고 그림도 아닌 산출물에는 문서가 있는가 하면 게임에 들어가는 여러 가지 텍스트도 있습니다. 이 게임에 들어가는 텍스트는 이름이 될 수도 있고 대사가 될 수도 있고, 때때로는 기나긴 문장이 될 수도 있는데, 그래픽 디자이너나 프로그래머의 작업이 아닌 것은 확실하기 때문에 기획자들이 담당하나 봅니다.

그래서인지 기획자들은 수학적인 센스도 필요하지만 언어적인 센스도 필요하다고들 이야기합니다. 저도 그렇게 생각합니다. 아니, 했습니다. 보통은 지독하게 사무적인 말투로 글을 쓰지만 가끔은 부드러운 말투로 글을 써야 할 때도 있고, 게임에 들어갈 아이템이나 사람 이름을 정하기 위해 돌지도 않는 머리를 쥐어 짜야 할 때도 있습니다. 이런 일을 잘 하기 위해서는 언어적 센스가 필요합니다.

자 그러면, 이 언어적 센스를 가진 사람이 기획자여야 하는가 하면 꼭 그렇지는 않습니다. 저는 원래 기획자는 언어적 센스가 필요하다고 생각했는데, 저는 말 하는 센스가 엉망 진창입니다. 같은 말을 어렵게 말하기도 하고 문장을 길게 쓰는 나쁜 버릇도 있습니다. 상황을 재미있고 조리 있게 설명하는데 서투르고 재미있는 표현이나 감각적인 단어를 사용하지도 못합니다. 이거 큰일입니다. 기획자가 이래서야 게임에 쓸만한 텍스트가 들어가는 것을 기대하기는 애초에 틀린 것 같습니다.

그러다가, 두 번 정도 생각을 바꿀 계기가 있었습니다. 한 번은 게시판에 아이디어 공모 이벤트를 했습니다. 사실은 우리가 아이디어가 부족해서라기보다는 당시에 장기간 아무 이벤트 없이 게시판을 방치하는 것이 애매해서 뭐든 게시판에서 할 수 있는 적당한 이벤트를 생각하다 보니 아이디어 공모가 된 것이었는데, 아이디어 자체는 대부분 팀에서 이미 고민해본 것들이라 별 도움이 되지 않았지만 연령대가 낮은 유저들의 센스를 엿볼 수 있었습니다. 방패를 들고 상대의 공격을 막는 스킬을 넣어 달라던 한 유저가 지은 스킬 이름은 ‘산성’이었던 것이 기억에 남습니다.

어제 게임에 들어갈 캐릭터의 대사를 만들어야 할 일이 생겼습니다. 대사라고 해봐야 대강 상황에 따라 두 세 마디 만들고 말 작정이었는데, 프로그래머가 이 캐릭터의 애니메이션 마다 각기 다른 말을 넣는 것이 어떠냐고 제안해 왔습니다. 그도 괜찮겠다 싶어 준비해 달라고 했는데, 제게 돌아온 것은 프로그래머가 ‘대충 입력 해놨다’는 애니메이션에 따른 대사였습니다. 그런데 프로그래머가 대충 썼다는 대사는 생각보다 훨씬 재미있었습니다. 왠지 대사를 하는 캐릭터가 꿈틀거리는 기분이 들고 말로만 듣던 캐릭터가 실제로 느껴지는 기분도 듭니다. 고민 끝에 말이 틀린 부분을 조금 수정해서 그대로 가기로 했습니다. 프로그래머의 언어 센스가 저보다 훨씬 더 재미있었습니다.

과연 제 머리로만 고민해서 ‘산성’ 같은 괴상한 센스를 생각해낼 수 있었을까요. 아니면 제 머리로만 고민해서 재미있는 대사를 쓸 수 있었을까요. 결코 아니었을 겁니다. 팀에는 굳이 기획자가 아니더라도 재미 있는 언어 센스와 재미 있는 아이디어를 가진 사람들이 바글거리고 그런 요소를 갖추지 못했다고 해서 기획자로 문제가 있는 것이 아닌가 하는 의문은 접어 두기로 했습니다. 도움을 받을 수 있는 나보다 나은 사람이 팀에 있다면 그게 뭐든지 간에 그들의 도움을 받는 편이 낫다고 생각합니다.

결국 제게 부족한 언어적 센스를 필요로 하는 순간에 직군을 가리지 않고 팀 내의 누구에게라도 도움을 청하게 되었습니다. 새로운 망치 이름을 정할 때도 돌아다니며 여러 사람들에게 물어봤는데, 시각이 각기 다른 사람들이 말하는 의견은 정말 흥미로웠습니다. 결론은 이렇습니다. 기획자가 센스가 부족하다면 함께 일하는 모든 사람들로부터 도움을 받을 수 있으며 그렇게 할 때 오히려 결과가 더 좋은 경우가 많았습니다.

이건 요새 일하는 모습. :(

뭔가를 고민 없이 만드는 것은 참 쉬운 일입니다. 전 프로젝트에서 그런 사례가 많았습니다. 디렉터가 '우편 시스템을 넣자'라고 이야기하면 우편 시스템에 필요한 기능이 뭔지 파악한 다음 그냥 만들었습니다. 보내는 사람, 받는 사람, 메시지, 보낼 아이템이나 게임 머니, 몇 가지 예외 사항 정도를 준비하고 UI를 담당하시는 분이 UI를 만들어 주시면 프로그래머가 게임에 붙였습니다. 별로 이상하다고 생각하지도 않았고, 별로 이상한 점도 없었습니다. 유저들도 별로 이상하지 않게 받아들였습니다.

생각해 보면 어이 없는 것들을 간과하고 있었습니다. 애초에 '왜 우편 시스템을 넣어야 하지?'라는 원초적이고 기본적인 의문을 갖지 않았습니다. 이 시스템이 유저에게 주는 가치, 게임에 주는 영향에서부터 생각을 시작했해야 했습니다. 목적과 가치가 분명해지만 분명 개선이 가능했을 겁니다.

근래에 방 만들기 다이얼로그를 정의하다가 비슷한 경험을 했는데, 이 방 만들기 다이얼로그는 다른 게임에서도 널리 사용되는 모양입니다. 제목을 넣고, 게임 모드를 고르고, 비공개로 설정하고 싶으면 비밀번호를 설정한 다음 확인 단추를 누르면 끝나는 아주 간단한 다이얼로그입니다. 별 생각 없이 전작에 사용된 다이얼로그를 그대로 가져와야겠다고 생각했는데, 넣고 보니 무난합니다. 참 무난합니다. 유저에게 어떤 가치를 줄지, 게임에 어떤 영향을 끼칠지에 대한 고민 없이, 한마디로 아무 생각 없이 들어간 다이얼로그는 아무런 개선이나 혁신도 없었습니다.

정말로 아무 생각 없이 그냥 넣으려고 하는 것이 아니라면 뭐든 만들어 넣으려고 고민할 때는 유저에게 어떤 가치를 주어야 하는지, 줄 수 있는지를 고민하는데서 시작하는 것이 어떨까 하는 생각이 들었습니다.

'갈아 엎는다'는 표현을 사용합니다. 지금까지 개발한 결과물의 상당 부분을 다시 만드는 과정을 그렇게들 이야기하더군요. 내부적으로는 아주 많은 부분을 바꾸지만, 그 결과는 지금과 크게 다르지 않은 경우가 많아서, 바쁜 개발팀에서 시도하기에 쉽지 않습니다. 웬만하면 갈아엎을 일이 생기지 않는 개발 체계와 과정을 만드는 것이 좋고, 혹시 갈아엎어야만 할 일이 생겼다면 최대한 빨리 갈아 엎어야 합니다. 갈아엎어야만 할 문제를 건드리지 않고 라이브까지 끌고 가면 더 이상 손을 쓸 수 없는 일이 생깁니다. 오늘은, 갈아엎어야 할 일을 가만 놔뒀다가 영원히 손쓸 수 없게 된 이야기를 해 보려고 합니다.

전에 이야기한 적이 있는데, 예전에 만들던 게임에 등장하는 몬스터들은 눈이 안 달려 있어서, 스스로 주변 지형을 보고 길을 찾지 못합니다. 그래서 몬스터들이 주변 지형을 인식할 수 있도록 그래픽 데이터로 만들어진 지형 정보를 기계가 인식할 수 있는 정보로 바꿔 줘야 했습니다. 이 작업을 하는데는 크게 두 가지 방법이 있습니다. 흔히들 '패스 엔진'이라고 부르는, 그래픽 데이터를 정해진 규칙에 따라 이동할 수 있는 지역과 그렇지 않은 지역을 구분하는 방법과, ... 무식하지만 사람이 직접 몬스터가 이동할 수 있는 지역을 정해주는 방법입니다.

사실, 어째서 후자의 방법을 사용하게 되었는지, 그 의사결정 과정에 대해서는 잘 모릅니다. 전자의 방법에는 엔진을 구입하는데 약간의 - 전체 개발비용에 상대적인 비용 - 비용과, 이 비용을 사용하는데 필요한 행정적인 절차가 있었고, 후자의 방법에는 개발팀을 투입해 직접 데이터를 입력하게 해야 했는데, 약간의 비용과 행정적인 절차보다는 개발팀의 인력을 사용하는 편이 더 낫다고 생각한 모양입니다. 그리하여, 개발팀이 노가다로 데이터를 입력하기 시작했습니다.

처음에는 지형 정보를 언리얼 에디터에 띄워놓고, 언리얼 스크립트로 액터를 하나 정의한 다음, 이 액터를 맵 위에 포인트 단위로 찍고, 포인트 사이의 관계를 연산한 결과를 저장한 다음, 몬스터가 이동할 때 이 결과를 참고하게 해놨습니다. 맨 처음에는 한 맵에 찍혀 있는 모든 포인트 사이의 이동 가능한 결과값을 모두 저장해놨는데, 데이터 크기는 엄청났지만 속도는 빨랐습니다. 데이터를 입력하는 사람들 이외의 모든 사람이 만족했지요. 하지만, 점 단위로 지형 정보를 분석하게 만들어놨더니, 절벽이나, 계단 같은 지형에서 자주 문제가 생겼습니다. 개선에 개선을 거듭해서 결국 실린더 모양으로 만들었는데, 이 과정 각각에서 지형 정보의 형식을 바꿀 때마다 모든 지형 정보를 다시 입력해야 했습니다. 기획팀이 주로 이 작업을 담당했는데, 나중에는 견디다 못해 아르바이트 작업자를 고용하기까지 했습니다. 참고로, 이 사람들 일당이 기획팀원들 일당보다 많았다고 합니다. :(

사실, 이 각각의 과정에서 '우리 이제 노가다 그만하고 그냥 엔진 사자'란 이야기가 수십번 나왔습니다. 개발이 진행되면 진행될수록 엔진 사서 붙이고 관계된 부분을 '갈아엎는'데 드는 자원과 리스크가 점점 커졌기 때문에, 시간이 지날수록 이런 푸념이 무의미하다는 것은 말하는 우리들 스스로가 더 잘 알고 있었습니다. 이렇게 진행된 프로젝트는 결국 라이브에서 밀려드는 버그를 감당할 수 없는 지경이 됐는데, 유저들이 가장 많이 경험하는 버그인 '스킬을 사용할 수 없습니다'와, '대상이 보이는 장소로 이동하세요'로 돌아왔습니다. 이 문제는 사람이 찍다 보니 지형을 이루는 실린더가 연결되지 않아 생기는 문제인데, 눈으로 보기에는 뻔히 몬스터가 앞에 있지만 그 몬스터가 서 있는 위치와 내 위치 사이에 연결되는 실린더가 없어, 서로 동떨어져 있는 것으로 착각하고 있는 상황입니다. 이 문제는 그때그때 문제가 일어나는 지점의 스크린샷을 받아 그 부분의 지형 정보를 보강하는 식으로 처리했지만, 실수는 도처에 널려 있었고, 버그가 알려진지 1년이 다 되어 가지만, 이제는 알긴 아는데, '절대로 고칠 수 없는 버그'가 되어 버렸습니다.

듣자 하니, 이제 이 문제를 수정하기 위해 강력한 특단의 조치가 진행되고 있다고 합니다. 올해 말 정도면 그 실체가 드러날 모양인데요, 이 경우로부터 배워야 할 교훈은 게임을 만들다가, '갈아엎어야 한다'는 느낌이 오면 최대한 빨리 갈아엎으라는 것, 그리고 '인력'을 쉽게 생각하지 말아야 한다는 것의 두 가지입니다.