By Woojin Kim in Office Life — 13 Dec 2024

절망의 벽

프로젝트 내에 수직계열화된 단위 조직은 종종 그 효율성에도 불구하고 목적 달성에 실패합니다. 충분한 자원을 투입했음에도 이들이 실패하는 원인은 무엇일까요?

게임을 만들다 보면 어느 시점에 지금까지 만든 결과를 뛰어 넘는 완전히 새로운 결과를 내야 하는 순간이 있습니다. 흔히 GDC 같은 곳에 나와 발표하는 대단한 게임디자이너들을 보면 처음부터 게임의 모든 요소에 의도를 가지고 지독한 탑다운 방식으로 만들어지는 것이야 말로 게임 소프트웨어라고 생각할 수 있고 실제로 어느 정도 그런 속성을 가지고 그런 방식으로 개발되는 사례도 있습니다. 하지만 또 다른 경우에는 그저 회사의 다음 프로젝트를 개발하기 위해 원하지 않았지만 프로젝트를 시작해 필요 이상의 기대를 받아 이를 충족하기는 해야 하지만 탑다운으로 내려 보낼 아무런 목표도 의지도 없는 분이 프로젝트를 총괄할 수 있고 이 역시 그리 드물지 않습니다. 요구사항이 탑다운으로 전달되어 개발할 경우 저와 같이 시스템디자인 역할로 게임의 여러 부분을 요구사항에 맞게 설계하고 설계의 구현에 따라 양산 파이프라인을 구축하며 이 과정에서 일어나는 문제를 해결하고 또 서로 다른 부서들 사이에 인터프리터 역할을 하는 사람은 일하기 훨씬 편합니다. 이미 프로젝트 리더십은 자신이 원하는 바를 뚜렷하게 알고 있으며 이를 잘 표현하든 잘 못 표현하든 저는 그 요구사항을 올바르게 접수할 것이기 때문입니다. 만약 프로젝트 리더십과 저 사이에 의사소통에 실패하더라도 지속적인 진행 상황 보고를 통해 의사소통의 실패를 최대한 빨리 눈치 채고 이를 수정할 수도 있습니다. 이 과정은 제 입장에서 일하기 아주 편한 환경입니다.

반면 그렇지 않은 경우, 그러니까 탑다운이 아닌 바텁업 방식으로 개발해야 하는 상황이 있고 제 개인적인 경험 상 후자의 방식으로 개발한 프로젝트가 더 많았습니다. 리더십은 프로젝트에 대한 비전을 가지고 있지 않을 때가 많았고 회사 역시 우리들에게 뚜렷하게 원하는 것이 없었습니다. 처음에는 프로젝트를 시작해 많은 사람들에게 긴 기간에 걸쳐 큰 돈을 투입하는 회사 입장에서 우리들에게 요구하는 바가 별로 없다는 사실에 충격을 받기도 했지만 회사 입장에서 우리들에게 원하는 것은 출시와 수익일 뿐 이를 실행하는 우리들이 만든 제품이 어떤 모양을 가지고 있든 그것은 그리 중요한 문제가 아니라는 사실을 인정할 수밖에 없었습니다. 이는 프로젝트를 맡은 리더십이나 고위 의사결정자들 역시 마찬가지입니다. 이들 역시 회사 또는 경영진의 결정에 의해 피칭을 준비해 프로젝트를 킥오프 했지만 사실 명확한 요구사항 없이 그저 장르와 장르의 특성에 기반한 주로 ‘뻔한 요구사항’ 수준의 요구사항만을 가지고 프로젝트를 시작할 때가 많고 이 상태는 생각보다 오래 지속되곤 합니다. 이런 상태로 개발하면 뭔가 큰 일이 날 것 같지만 실제로는 오히려 아무 일도 일어나지 않는데 시작 멤버들이 올바른 사람들을 데려와 개발하기 시작했다면 높은 수준의 요구사항이 불분명함에도 불구하고 대강 그럴듯하게 돌아가는 빌드 수준에 도달하고 이를 적극적으로 주의 깊게 들여다보고 빌드를 직접 만져보지 않는 이상 아무 일 없이 순조롭게 개발되고 있다고 판단할 수밖에 없습니다. 그도 그럴 것이 높은 수준의 요구사항이 없다 하더라도 일단 기반 장르가 MMO라면 우리들은 이전에 다른 프로젝트에서 해 왔던 것처럼 이 게임을 만들고 있을 테고 최소한의 설정에 기반한 에셋이 생산되면 이를 기반으로 특색 없는 게임을 만들어내기까지는 어렵지 않게 도달할 수 있기 때문입니다.

이런 개발 진행을 통해 초반 얼마 동안은 개발이 순조롭게 이루어지고 있다고 경영진에게 보고하는데 문제가 없겠지만 마일스톤이 조금 더 니가면 경영진은 서서히 이 제품의 유니크 셀링 포인트, 또는 엣지 따위로 불리는 이 제품만의 특징을 요구하기 시작할 겁니다. 사실 처음부터 뚜렷한 욕망에 의해 비롯된 강력한 요구사항이 탑다운 방식으로 각각의 작업자에게 도달해 개발하고 있다면 애초에 경영진은 이런 주제의 의문을 가지지도 않을 겁니다. 이미 보고 중에 욕망에 기반한 요구사항이 묻어나고 이를 본 경영진은 그들 스스로 이 제품의 특성을 추론해 납득할 수 있기 때문입니다. 다만 혹시 모를 잘못된 추측에 대비해 자신의 생각을 프로젝트 리더십을 통해 확인하는 정도면 충분하며 굳이 없는 특징을 쥐어 짜기 위해 여러 사람들을 괴롭힐 필요가 없습니다. 하지만 앞서 말한 개인적으로 경험한 더 여러 프로젝트에서는 한창 개발이 진행되어 분명 동작하는 빌드가 있음에도 불구하고 이 빌드가 시장에 이미 공개된 여느 게임과 별로 다르지 않아 제품의 특징에 의문을 가질 수밖에 없는 상황을 더 많이 겪어 왔고 이런 상태가 유지되고 있으면 경영진은 본격적으로 이 제품의 이른바 엣지, 그리고 이를 반영한 개발 계획을 요구하기 시작합니다. 하지만 리더십은 이런 요구에 대해 스스로 의미 있는 답변을 할 수 없을 가능성이 높은데 이런 경영진의 질문과 요구에 스스로 응할 수 있는 리더십이었다면 우리들이 바텀업 방식으로 제품의 여러 부분을 개발하고 있지 않았을 것이기 때문입니다.

전통의 MMO 개발 방식에 기반해 생각해보면 게임은 크게 흔히 전투라고 부르는 코어 메커닉과 이 전투를 둘러싼 나머지 부분으로 구분할 수 있습니다. 흔히 코어 메커닉을 전투라고 부르는 것과 비슷하게 전투를 둘러싼 나머지를 이른바 시스템, 메타, 컨텐츠 등 다양한 이름으로 나눠 부르는데 코어 메커닉을 제외한 나머지 구성요소는 제품이 시장에 나가 고객들을 맞이하기 위해 반드시 필요하지만 프로젝트 리더십이나 회사의 경영진들은 이런 요소들에 별 관심을 가지지 않는다는 특징이 있습니다. 주로 프로젝트의 고위 의사결정자에서 시작해 회사 경영진에 이르는 분들은 게임의 특징을 찾아내기 위해 코어 메커닉, 이른바 전투 경험을 살펴보기 시작하며 이 기능의 개발에 연관된 여러 사람들을 깊은 고통의 수렁에 빠뜨립니다. 현대에도 여전히 그 기반 장르가 MMO인 이상 코어 메커닉은 몇 가지 완성된 정답이 있고 우리들이 할 일은 이들 중 하나 또는 그 이상을 선택해 제품 전체에 걸쳐 어울리는 모양으로 구현해 내는 것입니다. 여러 차원에 걸쳐 메커닉을 분류할 수 있지만 이들을 기반 장르인 MMO를 기준으로 아주 거칠게 분류한다면 하나의 직선을 기준으로 한 쪽 끝에는 리니지가 있고 반대쪽 끝에는 엘든링이 있다고 생각하면 됩니다. 이 두 가지 극단적인 사례가 양쪽 끝에 있고 이 사이에 다양한 스펙트럼에 걸쳐 다양한 방식의 코어 메커닉을 가진 사례들이 위치하며 우리들이 할 일은 우리가 개발 중인 제품의 코어 메커닉이 이 스펙트럼 중 어느 정도에 위치할지를 결정하는 것입니다. 그리고 스펙트럼 상의 그 위치를 선택한 이유를 시장 상황, 개인의 욕망, 팀의 소망, 프로젝트의 현실 따위를 결합해 올바른 모양으로 말할 수 있으면 경영진을 설득하고 이에 기반해 회사의 마케팅 부서가 준비하도록 만들 수 있습니다.

물론 실제로는 이 정도로 단순하지는 않습니다. 코어 메커닉의 스펙트럼에서 어느 한 지점을 선택하기 위해 우리들은 이미 각자가 스스로 고객으로써 집에서 플레이 해 온 다양한 게임 경험과 이에 기반한 욕망을 어지러이 말하기 시작하고 이런 경험에 기반한 단 한 가지 메커닉을 탑다운 방식으로 전달된 뚜렷한 요구사항 없이 개발하다 보면 코어 메커닉은 게임의 궁극적인 목표에 잘 어울리지 않는 그저 동작하는 스펙트럼 상의 어느 한 점에 위치한 게임이 될 뿐입니다. 우리가 이 상황에서 프로젝트 전체의 개발 진행을 잠시 중단하고 그 사람이 프로젝트의 리더십이 아닐지라도 프로젝트 구성원 중 누군가의 욕망을 투영해 이를 설명할 수 있는 모양의 메커닉을 만들어내고 이 과정에 필요한 연구 개발 시간을 확보할 수 있다면 비록 리더십에 의해 탑다운으로 아무 요구사항도 받지 못했다 하더라도 리더십이 경영진에게 보고할 소위 엣지를 가진 코어 메커닉 플레이 경험을 만들 수 있을 겁니다. 하지만 프로젝트 킥오프가 일어나자마자 즉시 마일스톤을 시작해 뭐라도 결과를 뽑아 내야 하는 상황에서 이미 한참 여러 마일스톤이 경과된 상황에 코어 메커닉을 재정립하려고 하더라도 프로젝트 전체의 업무를 중단 시킬 방법은 없습니다. 그래서 그렇잖아도 코어 메커닉 스펙트럼 상에서 누군가의 욕망을 반영한 적당한 지점을 확정하고 이를 빌드로 만들어내며 이를 둘러싼 여러 가지 요소에 대한 요구사항, 이들을 뒷받침할 에셋 규격 따위가 변할 수밖에 없는 상황 속에서도 나머지 부서의 업무를 멈출 수 없기에 코어 메커닉의 변화 또는 확정에 따라 나머지 모든 요소들에 대한 요구사항이 크게 변경되어 회사에게는 부담을, 프로젝트를 수행하는 개개인에게는 마음에 상처를 주게 됩니다.

구성원들에게 상처를 조금 주기는 하겠지만 어쨌든 경영진을 설득하기에 충분한 수준으로 기술된 적어도 리더십은 아닐 것이 확실한 누군가의 욕망과 이를 뚜렷하게 반영한 빌드, 그리고 이에 기반한 개발 계획은 프로젝트가 남은 기간 동안에도 계속해서 회사의 투자를 받으며 개발을 이어 나갈 수 있게 만들 것이 확실합니다. 하지만 만약 이 단계에 도달하는 기간이 길어지면 이 프로젝트는 회사와 경영진들을 걱정 시키고 또 프로젝트의 구성원 개개인의 사기를 떨어뜨립니다. 이런 상황을 해결하는 여러 가지 방법이 있는데 그 중 하나는 프로젝트의 다양한 구성원들이 각자의 위치에서 자기 자신의 욕망을 투영한 요구사항을 바텀업 방식으로 개발하는 것입니다. 이들이 모여 조화로운 게임이 만들어질 가능성이 높지는 않지만 적어도 기반 장르로 MMO를 선택했으면서도 초반에 누군가의 뚜렷한 욕망에 기반한 요구사항에 기반해 개발하지 않은 이도 저도 아닌 도저히 상품화 할 실마리를 찾기 어려워 보이는 뻔한 빌드를 개발하는 대신 구성원 각자의 욕망이 마구 뒤섞인 어처구니 없는 빌드를 만들어낼 수는 있습니다. 그리고 이 난장판 속에서 조화를 만들고 맥락을 찾아내고 앞으로 지속할 기능과 그렇지 않을 기능을 판단하는 일은 비록 프로젝트를 시작할 때 자기 자신의 욕망에 기반한 높은 수준의 요구사항을 제안하는데 실패한 리더십이라도 상대적으로 낮은 난이도에 기반해 해낼 수 있는 종류의 업무에 가까워집니다. 또한 이 과정에서 각자의 욕망을 투영한 기능을 바텀업 방식으로 개발한 경험을 끝까지 해 낸 게임디자이너들은 이 과정에서 다른 탑다운 방식의 개발팀에서 일하는 것 보다 훨씬 더 큰 성장을 기대할 수 있습니다.

하지만 현실은 이 둘 중 어느 쪽에도 속하지 않을 때가 더 많으며 이도 저도 아닌 무의미한 개발을 반복하는 동안 사기가 낮아지고 개발 속도가 느려지며 어떤 사람들은 마음이 너무 지친 나머지 프로젝트를 떠나기도 합니다. 이 상황은 프로젝트 리더십이나 각 하위 조직의 개인들 양쪽 모두 뚜렷한 욕망을 가지고 있지 않을 때 일어납니다. 과거에 이 업계는 게임이라는 주제에 대한 일종의 열정을 가진 사람들, 그리고 소수의 천재들에 의해 시작되었기에 단위 조직의 개인들이 가진 욕망이 더 뚜렷했습니다. 시간이 지나며 업계를 일궈낸 천재들이 떠나고 보통 사람들이 그 자리를 대신하며 업계 전체가 성숙기에 접어들었고 과거에 욕망을 따라 업계에서 일하기 시작한 사람들에 비해 이제 이 일을 다른 여느 직업과 마찬가지인 소프트웨어 제품을 개발하는 일로 접근하는 사람들이 늘어납니다. 이는 성숙기에 접어든 어느 산업에서라도 일어날 수 있는 당연한 일로 만약 이런 상황을 회피할 생각으로 이른바 열정이 있는 사람들에 한해 구인하려고 하면 그 누구도 채용할 수 없어 프로젝트를 이어갈 수 없는 당연한 상황에 빠지게 될 겁니다. 프로젝트가 처한 이런 고약한 상황을 돌파할 수 있는 한 가지 방법은 그나마 프로젝트 구성원들을 잘 뒤져 누군가 마음 속에 작은 욕망의 불꽃을 아직 가지고 있는 사람을 찾아내 그 욕망에 기반한 혁신을 해 내는 겁니다. 경영진들의 지적질에 신경 끄고 욕망이 없는 리더십의 걱정에도 신경 끄고 그저 욕망이 있는 누군가의 요구사항을 신뢰하고 이에 기반한 설계를 만들어 이를 개발하면 그때까지 우리들이 만들어낼 수 없으리라고 생각했던 특별한 경험을 하게 만드는 빌드를 개발해낼 수 있습니다.

이런 경험을 만들기 위해 수행하는 뻔하고 또 잘못된 접근 중 하나는 코어 메커닉 자체로부터 이른바 엣지를 찾아내야 한다고 생각한 나머지 코어 메커닉을 개발하는 일 자체를 목표 삼아 태스크포스를 구축하는 것입니다. 이런 임시 조직은 종종 ‘코어 TF’ 또는 ‘전투 TF' 같은 이름으로 불릴 수 있는데 일단 이들의 긍정적인 점은 이들이 의도에 따라 개발해낼 수 있는 모든 구성요소를 단위 조직에 수직계열화 해낸 결과입니다. 이들은 그들 중 누군가가 아직 꺼지지 않은 욕망의 불씨를 가지고 있다면 이에 기반해 아주 빨리 코어 메커닉을 만들어낼 가능성이 있습니다. 그럼에도 불구하고 이런 접근을 뻔하고 또 잘못됐다고 생각하는 이유는 과거 MMO 기반 게임이 일단 전투만 만들어지면 나머지 구성요소는 구색만 맞춰 나열하면 어쨌든 동작하는 게임 경험을 만들 수 있었던 것에 비해 현대에는 코어 메커닉은 이전보다 훨씬 적은 부분을 담당하며 다른 구성요소가 코어 메커닉과 유기적으로 연계되어 있지 않으면 고객들의 눈높이를 맞출 수 없기 때문입니다. 이제 그 비즈니스모델의 수명이 끝나 고객들로부터 나쁜 평가를 받는 현대 리니지라이크 장르의 시초라고 할 수 있는 리니지M은 코어 전투 메커닉과 이를 둘러싼 게임의 나머지 부분이 황당할 정도로 유기적으로 잘 결합된 결과라고 생각합니다. 코어 메커닉인 전투와 이 전투에 의한 정치적, 경제적 결과에 도달하는 과정을 가속하기 위해 이를 둘러싼 다양한 기능들이 오직 캐릭터의 성장과 이를 통한 코어 메커닉 플레이의 개선에 초점을 맞추고 있으며 이 과정에 필요하지 않은 그 어떤 기능도 게임에 살아남지 못했습니다. 그렇게 완성한 결과가 비록 지금은 비즈니스모델의 수명이 다했지만 출시부터 지금에 이르기까지 거대한 경제적 성과와 긍적적일 수도 있고 부정적일 수도 있는 다양한 사회적 효과를 만들어냅니다. 이런 맥락에서 마치 20년 전에 기반 장르로 MMO를 선택한 다음 이 위에서 동작하는 게임 경험을 만들기 위해 초반에 오직 코어 메커닉 개발에만 집중하고 나머지 요소들과의 유기적인 연계를 신경 쓰지 않는 개발 방법은 설사 이를 통해 어떤 의미 있는 결과를 도출하는데 성공한다 하더라도 경영진은 고사하고 그 개발에 참여한 구성원들조차도 설득하기 어려울 겁니다.

그렇다면 뭘 어쩌란 말인가요. 우리들이 하루하루 꾸역꾸역 개발해 나가는 빌드는 아무리 생각해도 경영진은 고사하고 개발에 참여하는 우리들 하나하나조차 설득할 수 없는 그저 기반 장르로 선택한 MMO 이상도 이하도 아닌 뻔한 빌드에 불과하고 이를 바라보는 우리들의 사기는 하루하루 감소하고 있습니다. 우리들이 아무리 짚단으로 활주로와 관제탑 모형을 만들어 놓고 기다려도 결코 물자를 실은 비행기가 도착하지 않는 것과 같이 올바른 방법으로 개발하지 않는 이상 우리들이 아무리 노력해도 우리들이 원하는 혁신을 가져올 만한 요구사항, 누군가의 욕망, 또는 광기에 어린 요구사항이 탑다운으로 나타날 가능성은 없습니다. 만약 그런 일이 가능했다면 우리들이 애초에 이런 상황에 빠지지도 않았을 것이 분명하기 때문입니다. 우리들이 극도로 기민한 개발을 통해 결과를 도출할 수 있는 모든 기능을 포함한 수직계열화된 단위 조직을 구축해야 하는 것은 맞습니다. 이 조직을 통해 아주 기민하게 요구사항에 대응하고 그 결과를 만들어내며 이 과정에서 쓸모없는 의사소통, 무의미한 설득 같은 모든 절차를 생략할 수 있기 때문입니다. 다만 그 목표가 코어 메커닉에 특색을 만들어내기 위함에 국한되어서는 안됩니다. 우리들을 설득할 수 있는 것은 통합된 게임 경험이며 단지 코어 메커닉을 구축하는데 머물러서는 이 개발에 참여한 개개인들조차 설득할 수 없을 겁니다. 그런 이유로 보통 이런 태스크포스 조직은 뭔가 동작하는 결과를 내기는 하지만 그 결과를 성공적이라고 해석하기는 어려울 때가 많습니다.

그러면 뭘 어쩌란 말인가요. 큰 조직에서 일어날 수밖에 없는 낭비를 최소화하기 위해 개발에 필요한 모든 기능을 수직계열화한 조직을 통해 개발하되 이 조직의 목표가 코어 메커닉을 도출하는데 그치지 않고 코어 메커닉을 포함한 플레이 경험을 구축하는데 초점을 맞춰야 합니다. 코어 메커닉을 만든다면 그저 기반 장르인 MMO의 일반적인 특징과 기술적인 한계에 따른 뻔한 결과를 만들어낼 수밖에 없습니다. 코어 메커닉으로 범위를 한정한 채 생각해서는 그 한계를 결코 넘을 수 없습니다. 하지만 목표를 아주 조금 넓혀 코어 메커닉을 통해 경험할 수 있는 컨텐츠를 포함한 일정 시간 동안의 플레이를 만들어내는 것으로 목표를 수정하면 이 결과에 기반해 조직 구성원들을 납득 시킬 수 있을 뿐 아니라 코어 메커닉과 이를 둘러싼 게임의 나머지 부분들이 유기적으로 결합된 결과에 도달할 가능성이 더 높아집니다. 말을 복잡하게 했지만 그냥 뻔한 언어로 표현하면 전투 만든다고 다 함께 동굴에 들어가 백날 전투 만들어 봐야 누군가를 설득할 만한 의미 있는 결과물에 도달하기 아주 어려우며 이는 심지어 개발에 참여한 자기 자신들조차 설득하기 어려울 가능성이 높습니다. 게임은 코어 메커닉 만으로 이루어지지 않으며 코어 메커닉과 유기적으로 연결된 나머지 부분들이 함께 동작하는 경험으로 이루어지기 때문입니다. 또 다시 그냥 뻔한 언어로 표현하면 전투 만든다고 동굴에 들어가는 대신 전투 경험을 포함한 특정 던전을 개발하기 위한 목적으로 다 함께 동굴에 들어간다면 이는 성공 가능성이 있습니다.

이전에 어떤 모바일 게임을 개발하며 비슷한 상황에 처한 이야기를 해보겠습니다. 우리는 이미 원작의 코어 메커닉을 가져와 개발하고 있는 상황이었는데 그렇잖아도 기반 장르를 MMO로 설정한 상황에서 별다른 이른바 엣지를 만들어내기 어려운 상황에서 코어 메커닉 조차 우리들의 욕망이나 프로젝트 리더십의 욕망이 아닌 그저 원작의 메커닉을 그대로 가져와야 하는 상황에서 우리들은 그저 동작하는 빌드를 만들 뿐 프로젝트의 비전을 제시해 개발팀의 사기를 끌어올리는데 어려움을 겪고 있었습니다. 원작에는 고객들에게 상당한 인상을 준 부분이 있었는데 이 부분은 우리의 개발 계획으로 미루어 훨씬 나중에 개발해야 했습니다. 우리들만이 가진 코어 메커닉의 특징을 만들어내려는 시도를 해야 할 지 고민하는 상황에서 개발력을 집중할 대상을 코어 메커닉으로 한정하는 대신 이에 기반해 동작하는 고객이 처음으로 만나 강한 인상을 받은 원작의 바로 그 부분을 개발하는 것으로 여러 기능을 수직계열화 한 조직의 목표를 설정합니다. 우리들은 코어 메커닉을 개발하는데 그치지 않고 이를 둘러싼 개념 상 던전으로 구분되는 그 무언가와 그 안에서 동작하는 코어 메커닉을 둘러싼 여러 장치들을 함께 개발해야 했습니다. 덕분에 수직계열화의 대상이 된 인원이 좀 늘어나 소위 태스크포스의 의미에 비해 조직이 좀 더 커져 부담스럽기는 했지만 앞서 설명한 대로 우리들이 연구개발에 몰두하는 사이에 나머지 인원의 업무를 중단할 수 없기 때문에 이 조직은 그 스스로 모든 기능을 수직계열화 하기 보다는 모든 기능을 수직계열화 할 권한이 있는 사람들과 욕망이 있는 사람을 합친 모양으로 구성되어 이 조직에서 내린 결정을 가장 높은 우선순위로 조직 밖에서 개발하는 방식으로 운용합니다.

우리들은 원작을 플레이 한 고객들이 처음으로 아주 강렬한 인상을 받은 경험을 완전히 다른 기반 위에서 재현해야 했습니다. 이야기하기 쉽게 그 던전 이름을 말하고 우리가 그걸 개발한 이야기를 하면 좋겠지만 정말로 그러면 회사로부터 전화를 받거나 귀하의 건승을 기원하는 무서운 서류를 받을 위험이 있으니 그럴 수는 없고 그 던전 이름을 ‘절망의 벽’이라고 불러 보겠습니다. 이 이름은 그 어떤 프로젝트와도 관계 없으며 특정 제품의 일부를 연상 시킬 가능성이 있지만 이는 의도가 아니며 우연히 이와 같거나 비슷한 이름의 기능 또는 컨텐츠를 포함하는 제품이 존재한다 하더라도 우연의 일치일 뿐입니다. 이 절망의 벽과 비슷한 장치는 그리 고유한 것은 아니었습니다. 10년의 밤에 소개한 프로젝트가 처음 대규모 행사에 참가해 영상을 공개할 때도 비슷한 장치를 사용했습니다. 기반 장르로 MMO를 선택했고 배경이 중세 판타지인 게임이라면 다들 생각해 볼 법 한 바로 그것입니다. 바로 공성. 다시 한 번 말하지만 이는 그리 특별한 것은 결코 아닙니다. 가령 저 유명한 영화 반지의 제왕 여러 부분에서 공성이 등장하며 이 장면은 수많은 사람들이 등장하는 거대한 장면으로 보는 사람을 압도하기에 충분했습니다. 그나마 여러 영화에서 비슷한 장치를 너무 많이 사용한 끝에 이런 장면 자체가 고객들에게 너무 많이 스포일 되어 더 이상 예상한 목표를 달성하지 못하게 되기는 했습니다.

우리가 만들어야 할 것은 가칭 ‘절망의 벽’이라는 던전이었는데 이 던전의 핵심 경험은 기반 장르로 MMO를 선택해 주인공 한 명을 조작하는 게임이면서도 공성전이 일어나는 전장 한복판에서 공성을 진행하는 수많은 병사들과 상호작용하는 플레이입니다. 과거에 다른 프로젝트에서 만들었던 공성 장면 역시 플레이어가 포함된 대규모 군대가 적의 견고한 성을 공격하는 상황에 중세에 어울리는 공성 병기들이 돌을 집어던지고 또 다른 병사들이 성문을 향해 파쇄차를 밀고 가며 그 사이에 플레이어는 성문을 여는데 기여하기 위해 먼저 성벽 위에 올라간 다음 적들을 쓰러뜨리고 레버를 돌려 성벽을 여는 장면이 포함되어 있었습니다. 사실 영화에서 이런 장면이 흔하지만 이를 실시간으로 동작하는 게임으로 재현하려고 할 때 영화와는 달리 마주할 문제가 많았는데 가령 이 게임을 구동할 고객들 대부분의 기계 사양에는 한계가 있었고 공성전에 등장하는 그 수많은 병사들 각각이 모두 독립적인 개체로써 전투하도록 만들면서도 고객들의 기계에서 원활하게 동작하도록 만들기는 사실상 불가능했습니다. 또 수많은 병사들 각각이 그럴듯한 모양으로 적들과 싸우도록 만들기 위해 이들을 컷씬을 통해 제어하는 대신 각각이 기능이 조금 제한된 실제 플레이어와 비슷한 방식으로 싸우게 만들어야 했으며 이윽고 성문이 열리는 순간 수많은 병사들이 성문을 향해 달려갈 때 이들이 서로 충돌해 아무도 성문을 통과하지 못하는 아수라장이 만들어지기도 했습니다. 이런 문제들을 해결하기 위해 전투에 임하는 수많은 병사들은 서버에 의해 제어되지 않고 오직 클라이언트에서만 동작하되 클라이언트 기반의 전투 메커닉을 오롯이 가지고 있는 상태로 동작하게 해 실제 플레이어가 전투할 때와 마찬가지로 서로 대미지를 띄우며 그럴듯한 전투를 하면서도 빠르게 동작하게 했습니다. 또 파괴된 성문으로 향하는 수많은 병사들이 서로 충돌해 엉망으로 동작하지 않도록 하기 위해 일시적으로 이들이 성문을 통과할 때 충둘을 꺼 서로 겹치게 만들고 이 때 카메라를 성벽 너머로 넘겨 이들을 클로즈업 하지 않게 해 고객들이 이들이 마구 겹쳐서 성문을 통과하고 있다는 사실을 눈치 채지 못하게 했습니다.

절망의 벽은 과거에 비해 몇 가지 유리한 점이 있습니다. 일단 밤 배경이어서 이전에 만들었던 공성 장면에 비해 굳이 표현하지 않아도 될만한 것들을 어둠 속에 묻어버림으로써 사양 측면에서 더 나았습니다. 또 이전에 비해 성의 규모가 훨씬 줄어들었고 또 등장하는 병사 수 역시 훨씬 줄어들어 어지간한 기계에서 원활하게 돌아가는 수준에 도달할 수 있을 것 같아 보입니다. 물론 사양에 있어서 우리가 처한 문제는 이전에 만들어진 던전 절망의 벽은 윈도우 기계에서 돌아갔지만 우리가 만들어야 하는 똑같은 절망의 벽은 모바일 기계에서 돌아가야 했기 때문에 이런 이점에도 불구하고 우리가 훨씬 더 불리한 상황입니다. 그나마 이전에 만들었던 공성에서 병사 각각을 클라이언트에서만 제어하되 이들도 전투를 하는 장면을 연출했던 것에 비해 병사들이 수 백 명 등장하지만 이들 각각을 별도의 에셋으로 제작하는 대신 이삼십명의 병사를 한 덩어리로 묶어 이들을 한 번에 재생하는 방식으로 성능을 개선합니다. 대신 우리는 한 번 정한 연출을 수정하는데 엄청난 비용을 각오해야 했습니다. 이전에 만들었던 공성에서는 병사들 각각이 클라이언트 기반으로 동작하는 단일 개체였기 때문에 이들의 배치나 행동을 수정하는 비용이 높지 않았습니다. 하지만 드로우콜을 낮추기 위해 이들을 한 덩어리로 묶고 이들 전체를 제어하는 애니메이션으로 움직이게 만든 이상 이들 중 어느 한 명의 동작이나 경로를 수정하려고 하면 애니메이션을 아주 많이 수정해야만 했고 이런 문제 때문에 사실 한 번 만들어진 연출을 결코 수정하지 않았습니다. 수정이 필요한 상황이라면 그 상황을 없애는데 집중했습니다.

이 작업을 시작할 때 우리들은 바닐라 언리얼 엔진 4 이외에는 아무것도 가진 것이 없었기에 어디부터 시작해야 할 지 난감해 하는 상황이었는데 제 선에서 완성된 절망의 벽 시나리오를 단계 별로 구분한 다음 각 단계를 한 주 단위 계획으로 배치해 이 계획을 가지고 매주 개발을 진행하고 상황을 점검한 다음 계획을 유지하거나 수정하고 문제를 해결해 나가는 방식을 선택합니다. 흔히 뭔가 아주 빠른 개발과 피드백을 반복하기 위한 방법 중 스크럼이라는 방법을 사용하곤 하는 것 같고 이 방법을 성공적으로 수행한 프로젝트도 있고 그렇지 않은 프로젝트도 있다고 알고 있지만 결국 누군가는 이 개발 방법의 특징과 목적을 망각한 채 그저 매일 수행하는 회의를 스크럼이라고 부르기도 하는데 그만큼 잘 수행하기 어려운 방식이라는 의미라고 생각합니다. 각자가 맡은 업무와 목표가 명확하다면 굳이 매일 상황을 확인할 필요도 없고 또 그런 밀도 높은 회의를 매일 효과적으로 수행하기 위한 준비를 하다가는 제가 남아나지 않을 것 같아 모두가 모이는 날은 한 주에 한 번, 이 회의를 우리가 만들어야 할 던전 이름인 절망의 벽을 줄여 ‘주간 절벽 회의’로 정합니다. 주간 절벽 회의의 첫 번째 회의에서는 우리들이 만들어야 할 완성된 전작의 모양을 보여주고 각 주 차 별로 달성해야 하는 목표를 브리핑하고 다음 주 이 회의에서 우리들이 직접 실행해볼 수 있어야만 하는 빌드 목표를 설명했는데 여기 모인 사람들이 수직계열화된 실제 작업자가 아니라 그럴 권한을 가진 리드그룹이라는 점이 좀 위험하다는 생각을 했지만 어쨌든 첫 번째 주가 시작됩니다. 최종 목표는 첫 주간 절벽 회의로부터 8주차가 되었을 때 프로젝트 구성원 전체, 그리고 경영진에게 보고할 만한 수준의 플레이 경험을 완성하는 것입니다.

우리들의 전체 상황을 점검하는 주간 절벽 회의는 한 주에 한 번 부닝었지만 각 세부 기능을 개발하고 이들의 제작 방식을 결정하기 위한 회의는 선발적으로 진행했는데 제 취향에 맞춰 어지간한 논의는 회의실에서 하는 대신 항상 제 자리에서 진행합니다. 주변에서 일하는 분들께는 미안하지만 회의실에서 이야기를 하면 일단 앞 뒤에 몇 분 씩 시간 낭비가 일어날 뿐 아니라 누군가는 회의를 준비하고 정리해야 하며 회의에 초대된 사람들 중 의사결정에 직접적으로 필요한 사람이 없는 경우가 많았습니다. 이 때 의사결정에 필요한 사람을 회의에 데려오면 그 때 까지의 진행을 다시 동기화 해야 했고 이는 그렇잖아도 쉽게 늘어지기 쉬운 회의실 회의를 너무나 쉽게 늘어지게 만들었습니다. 반면 각자의 자리에 서서 이야기하면 일단 준비시간이나 정리시간이 거의 필요 없고 이야기 도중 의사결정이 필요할 때 필요한 사람 역시 같은 파티션 안에서 이 이야기를 듣고 있을 가능성이 높으므로 필요한 사람들을 즉시 데려다가 의사결정에 동원할 수 있습니다. 다만 이런 식의 회의가 늘어나면 명백히 주변에서 일하는 사람들을 방해하므로 적당히 해야 했지만 결국 제 취향에 맞춰 어지간한 이야기는 그냥 각자의 자리에 서서 했고 제 개인적인 평가에 따르면 오히려 주변 사람들이 지금 무슨 일이 일어나고 있는지, 어떤 의사결정이 일어났는지 따위를 자연스럽게 전달 받게 되는 장점이 있습니다.

레벨 에셋을 제작하고 서버에 연동된 실제 게임 기반에서 이 레벨에 진입할 수 있게 만들고 이 시점까지 아직 개발되지 않은 퀘스트가 동작하는 것처럼 보이도록 만들기 위한 설계를 만들어 요구사항을 작성에 전달하고 그러는 사이 누군가는 몬스터 에셋에 기반해 실제 동작하는 몬스터를 개발하고 또 다른 누군가는 주간 절벽 회의에 기반해 개발하지 않았다면 앞서 언급한 코어 메커닉 태스크포스에서 그저 공격 애니메이션이나 휘두르고 있었을 전투를 실제 던전 환경에서 몬스터와 싸우는 플레이 시나리오에 맞춰 동작하도록 튜닝합니다. 아직 기능은 없었지만 일단 멀티플레이 환경은 갖추고 있었기에 같은 레벨에 두 명 이상이 들어가 서로 다른 장소에서 협동해 한 가지 목적을 달성하는 플레이를 만들어 우리들의 가능성을 보여주고 또 지독한 최적화를 통해 모바일에서 동작하는 최신 3D 그래픽 기술에 기반하면서도 수많은 병사들이 하나하나 움직이며 공성하는 장면을 충분히 나타낼 수 있는 단계에 진입했습니다. 목표는 8주 안에 개발하는 것이었지만 참여자들의 그리 큰 초과근무를 요하지 않으면서도 용케 그보다 더 일찍 보고 가능한 수준에 도달할 수 있었습니다. 이 빌드는 보고에 활용되었을 뿐 아니라 앞으로 프로젝트 구성원 전체가 이런 규모의 던전을 개발하기 위한 파이프라인을 예측하는데 적용할 수 있는 경험이었고 또 만약 코어 메커닉을 독립적으로 개발했다면 결코 예측할 수 없었을 실제 PvE 전투 상황에서 일어나는 여러 문제를 맞닥뜨리고 이를 코어 메커닉 관점에서 미리 해결할 수 있어 좋았습니다. 보고가 마무리되고 이 개발이 궤도에 오르자 주간 절벽 회의를 마무리했고 이 다음은 본격적으로 이런 물건을 지속적으로 양산하기 위해 우리가 없지만 있는 것처럼 대충 만들었던 여러 부분들을 분리해 서로 다른 사람들에게 업무 모양으로 전달해 최종적으로는 이 절망의 벽 던전 전체가 실제 기능으로 동작하는 상태를 만들며 그와 동시에 이번 경험과 기능을 바탕으로 다른 던전을 개발해 나가는 상태에 접어들며 이 업무로부터 물러났습니다. 이제부터는 이 결과를 보고 각자가 탑다운으로 전달 받는 요구사항에 기반하지 않고서도 개발할 방법에 대한 충분한 힌트를 가진 상태에서 개발할 수 있었습니다.

흔히 예상하는 것과 달리 여러 프로젝트가 뚜렷한 욕망을 가진 개인의 리더십으로부터 시작하지 않습니다. 일단 프로젝트를 킥오프 하기는 했지만 프로젝트에 속한 그 누구도 뚜렷한 욕망, 비전 따위를 가지고 있지 않아 기반 장르만 결정된 채 어떤 특징도 없이 그저 시장에 나와 있는 다른 제품과 비교해 별 다를 것 없는 빌드를 만들기를 반복하며 서서히 지쳐가기 쉽습니다. 이를 눈치 챈 경영진이 개입해 이른바 엣지를 제시하라고 프로젝트 리더십에 압력을 가하면 아무 생각 없이 코어 메커닉으로부터 엣지를 도출하려고 생각하기 쉽고 실제로 이런 일이 자주 일어나지만 개인적인 관점에서 이는 올바른 접근이 아닙니다. 코어 메커닉은 한때 MMO 게임에 핵심이었고 이 기능을 잘 만들고 나머지 기능의 구색만 갖추면 그만이던 시대도 있기는 했지만 최소한 리니지M이 나타나면서 그런 시대는 완전히 막을 내렸습니다. 우리들이 만들어야 하는 것은 코어 메커닉 뿐 아니라 이를 둘러싼 게임의 여러 구성요소가 유기적으로 연결된 하나의 온전한 경험입니다. 이를 위해서는 코어 메커닉으로부터 엣지를 찾기 위해 관련 스탭들을 수직계열화 한 단위 조직을 만들어 동굴 안에 넣는 것 만으로는 부족합니다. 이들은 결과를 내겠지만 이 결과로부터 현대적인 게임의 이른바 엣지를 도출할 수는 없을 겁니다. 그들이 동굴 안에서 만들어낸 코어 메커닉은 현대에 너무나 뻔한 것일 수밖에 없기 때문입니다.

반면 코어 메커닉을 포함한 완결된 플레이 경험을 만든다면 이들을 수직계열화 한 단위 조직을 만들어 동굴 안에 밀어 넣어 놓으면 현대 기준으로 올바른 결과를 얻을 가능성이 상대적으로 높습니다. 리니지M이 게임의 모든 기능들이 유기적으로 연결된 모양을 만들었지만 한 방에 이 단계까지 가는 혁신을 팀에 제시하기는 현실적으로 불가능합니다. 하지만 절망의 벽 사례와 같이 일정 시간 동안 경험할 수 있는 여러 기능이 합쳐진 플레이 경험을 만드는 것을 목적으로 한 단위 조직은 코어 메커닉 만을 만들 때와 달리 게임 전체 경험을 만들어내게 되며 이 결과, 그리고 과정의 경험은 각각 경영진을 설득하고 또 프로젝트 팀이 앞으로 행동할 요령을 전파하는데 크게 기여할 겁니다. 단위 기능을 만들기 위한 수직계열화는 현대에 의미가 크지 않습니다. 일정 시간 동안에 경험할 깊은 경험을 만들어내기 위핸 수직계열화만이 의미 있습니다.

이번 68호에도 지난 2주간 공유한 이야기를 함께 보내 드립니다.