부분과 전체
우리는 전체를 만들지만 항상 부분만을 만들기를 요구받습니다. 이럴 때 우리는 어떻게 전체를 상상할 수 있을까요?
예전에오픈월드 게임 개발에 지레 겁먹은 이야기를 했었습니다. 오픈월드 게임을 좋아해 어지간한 수준 이상이면 주변에 모든 할 일을 다 쓸어 없애느라 메인 퀘스트를 진행하고 게임의 전체 스토리를 보는데 엄청난 시간이 걸리곤 했습니다. 가령 다른 사람들이 대략 스무 시간 정도면 엔딩을 볼 수 있었다는 데스스트랜딩은 80시간 넘게 플레이 하고 나서야 전체 스토리를 다 볼 수 있었고 얼마 전 마무리한 어쎄신크리드 발할라는 150시간 이상 지루한 플레이를 반복한 다음에야 신화 3부작에 의해 오랜 세월에 걸쳐 진행된 어쎄신크리드 세계관을 다시 한 점으로 모아 다음 장으로 넘어갈 수 있게 됐다는 사실을 깨달았습니다. 한번은 각기 다른 두 곳에서 거의 비슷한 질문을 받아 대답하며 서로 좋아하거나 싫어하는 게임 이야기를 나눈 적이 있는데 두 번 중 두 번째 자리에서 제가 오픈월드 게임을 좋아한다고 말하자 상대는 파크라이나 어쎄신크리드 같은 유비소프트 오픈월드 게임을 좋아하지 않는다고 말했습니다.
어쎄신크리드나 파크라이, 그리고 고스트리컨 시리즈로 대표되는 유비소프트 게임을 좋아하지 않는 이유는 넓은 월드에 거의 같은 메커닉으로 만들어진 별 의미 없는 퀘스트로 가득하고 퀘스트 각각에 스토리가 붙어 있기는 하지만 결과적으로 인게임에서 수행하는 여러 행동이 게임마다, 또 같은 게임 안에서도 서로 거의 비슷하기 때문이라는 설명을 들었습니다. 그 설명을 들으며 마음 속으로 세계를 잠시 떠나는 의식에 설명한 좀 덜떨어진 세계라도 그 세계를 받아들이기로 결정하면 파크라이 뉴던 처럼 완전히 멸망한 멍청하기 짝이 없는 수준이 아니라면 어지간한 오픈월드 게임을 재미있게 플레이 할 수 있으며 개인적으로 상대가 좋아하지 않는다고 말한 파크라이 시리즈 중 모던 파크라이로 분류되는 4, 5, 6에 많은 시간을 들여 재미있게 플레이 한 생각을 했지만 이를 입 밖으로 꺼내기는 좀 무리가 있다 싶습니다. 그런 게임이 고객들로부터 어떤 평가를 받는지 이해하지만 다른 한편으로는 여전히 미국 중부 어느 시골 마을을 배경으로 한 파크라이 5는 그 배경 마저 마음에 들어 가솔린을 풀풀 태워 고작 몇 킬로미터를 달리는 삐걱이는 픽업 트럭을 타고 등에는 항상 엽총을 매고 있으며 집 앞에는 빛 바랜 성조기가 걸린 이미지를 즐기기도 했습니다.
물론 솔직히 파크라이 6의 배경인 가상의 섬 야라의 생활은 미국 중부 촌동네 호프 카운티에 비해 훨씬 덜 매력적이었고 그 이국적일 수도 있었던 분위기를 잘 살리지 못했으며 인게임 경험은 여전히 모던 파크라이 이전 시대로부터 거의 발전하지 않았고 퀘스트 각각은 지루하고 등장인물들은 어딘가 고장 나 있을 뿐 아니라 지나치게 작위적인 느낌이 들었던 것도 사실입니다. 게다가 욕을 많이 먹긴 했지만 개인적으로 나쁘지 않다고 생각한 파크라이 5의 스토리에 비해 파크라이 6은 그 시작은 나쁘지 않았지만 결말은 정말 어처구니 없는 막장으로 치달아 분명 그럭저럭 파크라이 스러운 경험이었고 최소한 파크라이 뉴던 보다는 훨씬 나았다고 생각하면서도 그동안 가상의 섬 야라에서 지내 온 시간이 한 순간에 부정 당하는 기분이 들어 뒷맛이 좋지 않았습니다. 이런 좋은 경험과 나쁜 경험 사이에도 여전히 그 광활한 세계 구석구석을 아름답게 만들고 그 안에서 비슷비슷하기는 하지만 여러 인물과 할 일들을 흩뿌린 세계를 만들어냈으며 이런 경험으로 가득한 게임을 짧은 기간마다 계속해서 출시해내는 점은 고객 입장에서 공장식 오픈월드 게임이라고 비판한다 하더라도 게임 만드는 사람 입장에서는 여전히 엄청나고 대단합니다. 여전히 국내에서 오픈월드 게임 개발에 참여할 일이 드물지만 서로 다른 프로젝트를 진행하시는 분들과 만나 오픈월드를 만들려면 무엇을 해야 할까 같은 실질적인 주제로 이야기를 나누기도 하고 또 이따금 진행 상황을 교환하며 우리들이 공장식 게임이라고 비판하던 그런 수준의 게임이라도 만들어내는데 실질적으로 어떤 일이 일어나며 어떤 도전거리가 있는지 전해 듣고 고민하는 것도 이들을 플레이 하는 것 만큼이나 즐거운 일입니다.
개인적으로 오픈월드 게임을 높이 평가하는 이유는 가상 세계가 그럴듯하게 동작하도록 하기 위해 서로 다른 부분 각각이 완결성을 가진 기능으로써 동작하면서 동시에 이들이 모여 상호작용한 결과가 그럴듯한 경험을 만들어 내야 하기 때문입니다. 그럴듯한 결과라는 말로 그 수준을 떨어뜨리기는 했지만 게임에 따라 세계를 구성하는 작은 시스템 하나하나가 완결성 있게 동작함과 동시에 이들이 상호작용한 결과 그 세계를 극한까지 살아 움직이도록 만들기도 합니다. 특히 이미 강산이 한 번 변할 세월보다 더 오래 전에 만들어졌지만 여전히 그만한 완결성을 가진 세계를 재현하지 못한 GTA 5 같은 게임은 주인공을 직접 조작해 세계와 상호작용하고 자동차를 운전하는 핵심 경험 뿐 아니라 거리에 나붙은 간판에 적힌 전화번호에 전화를 걸면 그 모두가 실제 게임 상에서 존재하는 전화번호라거나 한 손으로 스티어링 휠을 잡고 다른 한 손으로 전화를 받는 도중 라디오 채널을 바꾸려고 할 때 반응, 또 세계를 오가는 사람들, 그리고 자동차들의 움직임, 심지어 게임 속 인터넷을 통해 접할 수 있는 다양한 행동에 이르는 지독한 상호작용은 오픈월드 게임 개발에 참여하고 싶었다가도 이내 꼬리를 내리고 얌전히 국내에 흔한 장르를 개발하는데 집중하게 만듭니다.
국내에서 흔히 개발하는 장르는 마치 유비소프트가 만드는 여러 오픈월드 게임들이 서로 거의 비슷한 시스템을 공유하는 것처럼 서로 다른 회사에서 개발하는 서로 다른 프로젝트가 서로 상당히 비슷한 시스템을 공유합니다. 덕분에 프로젝트 몇 개를 거치고 나면 프로젝트 이름도 다르고 추구하는 핵심 재미나 사용하는 아이피가 다르면서도 이를 동작하게 하는 단위 기능은 서로 상당히 비슷해 처음에는 시스템디자인 하는 사람을 고통스럽게 만드는 다양한 요구사항이라고 생각했던 일들이 결국 말이 조금씩 다를 뿐 거의 정답이 있는 문제에 불과하며 다양한 요구사항은 이 정답에 기초해 디테일이 조금씩 다른 결과에 불과하다는 생각을 가지게 됩니다. 물론 이렇게 다양한 요구사항이 결국 정답이 있는 문제에 가깝다는 관점은 설계 업무 수행을 효율적으로 만들어 주고 다른 프로젝트와 차이에 집중하게 만드는 장점이 있지만 때때로 개인적으로 정답에 가깝다고 생각하는 바로 그 정답 자체에 매몰된다면 퀘스트 시스템에 대한 다른 접근에 소개한 것처럼 아예 같은 메커닉을 설계하는 완전히 다른 접근을 경험해볼 기회를 놓칠 위험도 있습니다.
개발 과정에서 요구사항은 항상 불완전합니다. 고객들에게 공개된 엘든링을 보고 게임의 여러 장치, 상징, 스토리가 진행되어 가는 과정들이 중세 연금술의 과정으로부터 모티브를 따 왔을 거라고 해석하기는 아주 어렵지 않고 제작자들이 처음부터 연금술의 과정에 게임의 여러 부분을 대입해 스토리와 시스템, 세계 전체, 그 안에 등장하는 여러 몬스터들을 디자인했을 거라고 예상하기도 어렵지 않습니다. 그런데 실제로는 그렇지 않았을지도 모릅니다. 여러 요구사항은 불완전한 모양으로 이 보스의 전투 패턴은 박자를 맞춰 고객이 예측할 수 있도록 하되 고객이 패턴을 예측했다고 느껴 자신감을 가질 시점에 거의 같은 시작 모션으로 패턴이 다른 공격을 해 고객을 절망에 빠뜨려 달라는 식의 목표는 확실하지만 그 과정이 모호한 모양일 때가 대부분입니다. 그나마 이런 수준으로 요구사항을 받는다면 의도와 결과가 확실하므로 일하기 굉장히 편안 요구사항에 속합니다. 어떤 요구사항은 극히 단편적으로 퀘스트를 수행하는 동안 이번 스텝의 목표인 대상을 쉽게 알아볼 수 있게 해 달라는 식으로 목적만 명시한 채 접수되거나 심지어는 ‘초반 퀘스트 플레이 경험 개선'처럼 애초에 개선 사항을 구체적으로 언급하지 않고 초반 경험이 썩 만족스럽지 않았음을 뭉뚱그려 애초에 이 요구사항을 낸 사람이 어떤 경험을 했을지 짐작하기부터 시작해야 하는 상황도 심심찮게 일어납니다.
우리들이 개발하는 제품은 한번에 마지막 상태를 목표로 진행하지 않기에 개발의 각 시점에 따라 같은 요구사항은 서로 다른 방법으로 개발될 수 있습니다. 게임의 여러 기능이 개발되어 이들을 직접 활용할 수 있는 단계에 들어온 요구사항이라면 기 구축된 시스템에 기반해 요구사항을 수용하기 위해 필요한 최소한의 기능을 추가하거나 최소한으로 기존 기능을 수정하는 수준으로 대응할 수 있습니다. 하지만 개발이 진행되는 동안에는 여러 기능이 아직 개발되지 않았거나 불완전하거나 임시로 기능이 있는 것처럼 보이게 만들었을 뿐 실제로는 기능이 존재하지 않거나 미래에 사용할 수 없는 방법으로 만들어져 있는 등 다양한 제약이 있을 때가 많습니다. 이들을 기 구축된 시스템이라고 생각해 이들을 활용해 요구사항을 달성할 수 있을 거라고 예상하고 설계를 시작했다가 기 구축되었다고 생각한 기능 거의 전부가 이 기능이 있다고 착각하게 만들 의도로 영속적이지 않은 방식으로 만들어진 이른바 임시 기능이라는 사실을 깨달을 때 가볍게 생각했던 요구사항은 갑자기 요구사항 전체에 해당하는 각 단위 기능 하나하나를 바닥부터 다시 구축해야 할 지 나머지 기 구축된 것처럼 보이는 단위 기능과 마찬가지로 이번에도 요구사항 자체를 달성하기는 하지만 영속적인 상태와는 거리가 먼 임시 기능에 가까운 형태로 설계해 제한시간 내 요구사항을 만족하는데 집중할지 고민하게 됩니다.
이럴 때마다 요구사항들이 기 구축된 빌드 상태를 깊이 이해한 상태로 발급 되고 또 기왕이면 미리 생각을 마친 일관된 목표와 정렬된 형태로 발행되면 좋겠다는 생각을 해 보기도 합니다. 영화 업계에서도 스토리보드 수준에서 영화 전체를 거의 완성한 다음 촬영을 시작해 최소한의 기간과 비용으로 촬영을 마치고 바로 후반 작업에 돌입하는 사례가 여럿 나타나고 있으니 게임이라고 그러지 말라는 법이 있을까 하는 생각을 하며 답답한 마음을 가져 보기도 했습니다. 하지만 정작 미리 잘 계획하면 나중에 큰 수정을 피할 수 있을까?라는 질문을 받았을 때 그럴 수 없을 거라고 대답했는데 가장 큰 이유는 우리들이 수행하는 프로젝트 대부분은 거의 장르와 아이피 정도만 확실한 상태로 시작하며 그나마 장르 마저도 종종 프로젝트 킥오프 이후 변경될 때도 있습니다. 이런 상황에서 요구사항이 한 가지 목표에 정렬된 형태로 주어질 가능성은 거의 없다고 봐야 합니다. 또한 영화처럼 그 형식이 거의 정립된 매체와 달리 게임은 여전히 그 형태가 계속해서 변하고 있습니다. 가령 영화는 한동안 커다란 영화관의 어두운 방 안에서 의자에 앉아 정면의 화면을 응시한 채 경험하는 매체라는 형식이 확고히 자리 잡고 있었습니다. 물론 현대에는 보다 작은 스크린, 더 좁고 개인적인 공간, 능동적으로 중간에 상영을 멈출 수 있는 환경으로 바뀌어 이를 감안해야 하지만 여전히 단방향으로 영상이 전달된다는 핵심 형식이 달라지지는 않았습니다.
반면 게임은 겉보기에 비슷한 중세 판타지 배경의 MMO 게임이라 하더라도 어떤 게임은 액션을 중시한 형태, 어떤 게임은 핵 앤 슬래시 기반 플레이를 중시한 형태, 또 다른 게임은 플레이 하는 모습은 기존과 거의 같지만 실상은 여러 부분이 자동화된 매니지먼트 장르에 가까워 이들 각각의 개발 접근은 서로 아주 많은 부분이 다릅니다. 게다가 개발을 시작한 다음에도 시장에는 비슷한 생각을 한 다른 팀의 제품이 계속해서 나타나므로 이들을 살펴보고 적당히 반영하지 않으면 유행에 둔감해지거나 고객들의 습성이 완전히 변했음을 인지하지 못하고 너무 오래된 문법으로 게임을 출시하는 참사를 겪을 수 있습니다. 그래서 그렇지 못해 여러 모로 안타깝지만 처음에 잘 계획한다 하더라도 나중의 큰 변경을 피하기는 어렵다고 생각합니다. 다만 요구사항의 변화는 그나마 게임의 장르, 개발 방향, 시장 상황에 따라 어느 정도 예측 가능한 범위 안에서 나타나는 경우가 많으므로 이 범위를 예상하고 시스템을 구축하거나 요구사항 자체에 집중해 정확히 요구사항 만을 반영하는 결과를 만드는데 집중하고 철저히 미래를 예측하지 않는 접근으로 가장 간결한 시스템을 구축하는 식으로 다양하게 접근할 수 있습니다. 다만 다양한 접근 방식 모두 초반에 잘 구축한 설계 대로 진행할 수 없다는 전제 위에 있습니다.
한편 최근 온보딩 과정에서 여느 프로젝트와 비슷하게 여러 단계를 거쳐 내려와 요구사항이 처음 나타난 맥락을 파악하기 어렵고 또 완결된 기능을 한 번에 요구하기 보다는 미래에 이 기능이 구축되었을 때를 가정해 이 기능이 게임 곳곳에 일으키는 상호작용의 일부분을 이번 마일스톤에 보기를 원하는 식으로 요구사항 하나가 완전히 조각난 상태로 실무 수준에 전달되는 상황을 관찰했습니다. 실무에서는 딱히 창의적인 접근 방식이나 창의적인 인게임 경험을 생각할 것도 없이 그저 ‘퀘스트에 특정 기능을 추가해 달라’는 식으로 접수된 요구사항을 달리 생각해볼 여지도 없이 기계적으로 수행하는 상태에 놓이기 쉽습니다. 이를 수행하는 실무자는 기능의 맥락을 모른 채 설계해야 하고 이 설계는 미래에 알게 될 맥락과 동떨어진 모습일 수 있으며 협업 부서에서 이 기능에 대한 맥락을 요구할 경우 대답할 수 없어 게임디자인의 분업이 만들어낸 비 존중 같은 문제에 쉽게 빠지게 만들 수 있습니다. 또 요구사항이 문제를 해결하기 위한 사고의 결과를 요구하는 대신 그냥 결과를 요구하는 방식으로 주어지기 때문에 생각할 여지 없이 그저 기 구축된 시스템이 이 요구사항을 달성하기 위해 수정되어야 하는 형태를 도출하는데 집중한 나머지 게임디자이너로써 사기를 떨어뜨리는 원인이기도 합니다. 그런 요구사항들이 오가는 소리를 자리에 앉아 듣다가 여러 프로젝트에 걸쳐 반복되는 이런 상황에 어떻게 대응해야 할 지 생각해봤습니다.
어쩌면 정말 모든 계획을 수립하고 계획에 따라 개발해 나가는 것이 가장 이상적일 지도 모릅니다. 하지만 그 곳은 지구 상 어딘가에 존재하는 이상적인 곳일 테고 현대 한국의 수도권에서 일하는 이상 그런 이상적인 곳과는 분명 거리가 있을 테니 우리들이 처한 요구사항의 맥락을 알 수 없고 요구사항은 항상 단위 기능 전체가 아니라 그 기능이 완전히 구현된 상황을 가정하면서도 그 기능이 전혀 개발되지 않은 현재 그 기능이 일으킬 상호작용의 일부에 해당하는 동작 만을 요구하며 요구사항이 게임디자이너에게 문제 해결을 요구하지 않고 이미 결정된 문제 해결 방법을 실행하기를 요구할 뿐인 상황 속에서도 적당한 사기를 유지하며 개발을 계속해 나갈 방법이 필요합니다. 문제를 해결할 궁극적인 방법은 개발팀 전체의 위로부터 요구사항을 만들고 전달하는 방식을 수정해 가는 거라고 생각합니다. 즉흥적인 요구사항이 그 즉흥적 맥락이 제거된 채로 여러 사람에 걸쳐 전달되면 그나마 남아 있던 즉흥적 맥락은 점점 희미해지고 심지어 요구사항 자체도 여러 사람들 거치는 사이에 자의적으로 재해석 되어 결국 맥락도 없이 실무 수준에서 볼 때는 이상한 모양으로 바뀌어 전달될 수 있습니다. 이를 완화하려면 위에서 요구사항과 그 맥락을 실무까지 전달하는 방식 자체를 개선해야 할 겁니다. 하지만 그런 개선은 당분간 일어나지 않을 것이 확실하니 실무 수준에서는 알아서 살아 남을 방법이 필요합니다.
요구사항에 맥락이 없다면 맥락을 상상해 자기 스스로 이 맥락을 신뢰하며 내면화 해야 합니다. 개인적으로 이런 방식을 실무를 하고 있기는 하지만 시공간 상에서 멀리 떨어진 최고 수준의 의사결정자 입장에서 지금 내 앞에 맥락 없는 모양으로 전달된 요구사항의 맥락을 예상해야 합니다. 가령 여러 클래스가 있는 게임에서 어떤 던전에 들어가면 원래 고객이 플레이 하던 클래스가 아닌 미리 설정된 클래스로 플레이 하게 해 달라는 요구사항은 기능 만을 곧이 곧대로 해석하면 조건을 만족할 때 미리 만들어 놓은 클래스 기반의 캐릭터 정보를 가져와 그 캐릭터로 플레이 하게 만들면 됩니다. 하지만 이 요구사항을 설계하기 위해 곰곰이 생각해보면 그냥 다른 클래스 캐릭터로 플레이 하게 해 달라는 요구사항은 생각보다 훨씬 복잡합니다. 일단 우리는 이 다른 캐릭터를 통한 플레이가 원래 내 캐릭터에게 영향을 줘야 하는지 그렇지 않은지 알지 못합니다. 만약 영향을 줘야 한다면 이 플레이를 통해 획득한 보상은 원래 캐릭터에게 전달 되어야 하는데 이는 원래 캐릭터의 성장 상태에 따라 온갖 문제를 일으킬 수 있습니다. 또 우리가 지정한 클래스의 캐릭터로 플레이 할 때 이 플레이가 언제 시작되어 언제까지 유지되어야 하는지, 중간에 플레이가 중단되면 어떻게 처리해야 하는지, 플레이 도중 어떤 인터페이스를 사용 가능하게 하고 또 사용 불가능하게 할 지 등 설계할 때 정의해야 할 규칙은 수없이 많지만 오직 다른 캐릭터로 플레이 하게 해 달라는 맥락 없는 요구사항에 기반해서는 자잘한 세부 요구사항을 정의하기 어렵습니다.
만약 요구사항을 만든 사람과 직접 이야기할 수 있다면 맥락을 직접 확인할 수 있겠지만 지금까지 경험한 프로젝트 대부분에서 그럴 수 있었던 적은 극히 드뭅니다. 그렇다면 스스로 맥락을 만들어 그 맥락에 의존해 기능을 설계할 수 있습니다. 어떤 던전에 들어가면 원래 고객이 플레이 하던 클래스의 캐릭터가 아닌 미리 설정된 클래스와 미리 설정된 캐릭터로 플레이 하게 해 달라는 요구사항은 스토리 상 다른 시간대에서 일어난 사건을 대신 체험하도록 만드는 용도로 사용됩니다. 또 어떤 MMO 게임에서는 여러 클래스의 서로 다른 전투 스타일을 모두 체험해 보고 자신이 선택하고 성장 시킬 캐릭터를 결정하게 만들거나 아직 획득하지 못한 스킬과 아이템을 사용해 보고 성장해 갈 목표를 결정하는데 도움을 주는 일종의 체험 기능을 제공하기도 합니다. 맥락이 거의 없이 요구사항을 전달 받았더라도 이런 가상의 맥락 중 어느 쪽에 더 가까운지는 판단할 수 있을 겁니다. 가령 다른 시간대의 경험을 대신한다면 이 경험에 의한 성장은 고객의 원래 캐릭터에게 전달 되어서는 안되고 이 경험은 던전 입장, 퀘스트 시작에서 퀘스트가 끝나는 시점에 걸쳐 유지되어야 하며 경험이 완결되기 전에 중단된다면 던전 또는 퀘스트의 중단 대응 규칙에 따르면 됩니다. 또 체험 기능이라면 여전히 체험 도중의 성장은 고객의 원래 캐릭터에 전달 되어서는 안되며 이 경험은 체험 기능의 시작, 또는 체험 기능을 제공하는 공간과 연결해 이 공간에 있을 때만 사용할 수 있고 경험이 완결되기 전에 중단될 경우 공간의 중단 대응 규칙에 따라야 합니다.
이런 접근을 통해 요구사항의 불분명한 면을 예상해 실제 개발할 수 있는 설계를 만들어낼 수 있지만 우리들이 런칭에 가까운 시점이 아닌 이상 요구사항을 만족하는데 필요한 단위 기능 중 일부만 사용 가능하고 나머지는 사용 가능하지 않을 수 있습니다. 이 때 요구사항의 달성에 필요한 단위 기능들이 아직 개발되지 않았거나 기능이 개발된 것처럼 보이도록 만든 업계 전문 용어로 가라 상태이거나 영속 가능하지 않은 상태일 수 있습니다. 이를 이유로 요구사항 개발을 거절하는 것도 아주 나쁜 선택은 아니지만 요구사항을 거절한다고 해서 현재 이 요구사항의 구현에 필요한 나머지 단위 기능을 차례로 개발해 나가 결국 이번에 거절한 요구사항을 미래 시점에 기 구축된 여러 기능을 통해 무난히 개발할 수 있으리라 예상해서는 안됩니다. 요구사항은 현재 프로젝트의 실제 개발 상태를 감안하지 않고 나타나며 이는 앞에서 위로부터 개선할 수 있다고 말했지만 위로 올라갈수록 제품의 각 단위 기능이 처한 상황 하나하나를 보기보다는 전체 동작을 보고 짧은 판단에 의해 요구사항을 만들어내기를 반복하는데 가깝습니다. 실무가 처한 상황은 최상위 의사결정자 수준에서 요구사항을 만들어내는데 고려할 중요한 사항이 아닙니다.
개인적으로는 실무가 처한 현실을 딱히 고려하지 않은 요구사항을 접수했을 때 이를 실제 개발 가능한 모양으로 설계할 때 그 시점에 필요한 단위 기능이 충분히 개발되어 있지 않더라도 그 시점에 사용 가능한 기능에 기반해 요구사항을 충족하는데서 시작해 기존 기능을 수정하거나 새로운 단위 기능을 추가해 요구사항을 적당한 선에서 수용하는 개발 과정 중 여러 시점에 따라 같은 요구사항의 수행 방법이 달라질 수 있는 형태의 진행을 추천합니다. 소프트웨어 개발이 여러 단위 기능 각각을 완결성 있게 개발하되 이들의 의존성을 고려해 개발 순서를 결정하고 의존성에 따라 개발해 최종 제품에 도달한다면 게임 소프트웨어는 요구사항은 있지만 이들의 의존성에 대한 깊은 이해 없이 요구사항이 바로 실무 선에 도달하기 때문에 기 구축된 상태를 감안해 영속성 있게 만들 부분과 그렇지 않을 부분을 구분해 요구사항을 만족하는데 집중하기를 반복하며 점점 더 많은 부분이 영속성 있는 모양으로 바뀌어 나가기를 반복해 결국 완성되는 과정으로 만들어진다고 보면 됩니다. 굉장히 비 효율적이라고 느낄 수 있습니다. 사실 비효율적입니다. 딱 봐도 그렇게 까지 오랜 세월에 걸쳐 개발해야 할 것 같지 않은 게임들이 막 7년 걸렸거나 10년 걸렸다고 자랑하는 모습을 보면 이들이 의존성에 대한 고려 없는 요구사항을 그때그때 가능한 수준으로 대응하기를 반복하며 서서히 영속성을 갖춰 나가는 방식으로 개발해 그렇게 오랜 세월을 소모했을 가능성이 높습니다.
게임 소프트웨어가 여느 소프트웨어와 다른 점은 프로젝트를 시작할 때 완결된 요구사항을 가지지 않은 채로 개발을 시작한다는데 있습니다. 개발에 참여하는 사람들이나 최고 의사결정자조차 이 소프트웨어가 완성되었을 때의 모습을 잘 모릅니다. 물론 어떤 비전이나 청사진이 아예 없지는 않겠지만 이는 전체 게임 경험의 어느 한 순간을 나타낼 뿐 그 순간을 지탱하기 위핸 나머지 부분은 실제 구동되는 모습을 봐야 비로소 의미 있는 판단을 할 수 있습니다. 결국 요구사항은 여러 사람을 거치며 아래로 내려오는 동안 즉흥적일 가능성이 높은 맥락이 제거되고 현재 개발 상태를 감안하지 않은 모양으로, 그리고 게임디자이너에게 문제 해결을 요구하는 대신 해결 방식 그 자체를 전달하는 방식으로 개발하고 있습니다. 이 상황에서 우리들은 요구사항을 거절하거나 맥락을 모른 체 이 요구사항이 게임에 적용될 때 일어날 온갖 ‘예외사항'을 찾아내며 고통스러워 하는 대신 가상의 맥락을 가정하고 이 맥락에 따른 전체 시나리오에 기반해 ‘예외사항’ 대신 요구사항을 달성하는데 필요한 ‘기능의 목록’ 모양으로 접근해야 합니다. 그러면 협업 부서에도 맥락을 직접 설명해 이해 수준을 높일 수 있고 협업 목적성을 부여해 협업 저체를 부드럽게 만들 수 있으며 게임디자이너 입장에서 궁극적으로 요구사항의 맥락을 가정하기를 반복해 의도하지 않게 고위 의사결정자와 비슷한 맥락을 도출하는 단계에 이를 수 있습니다.
전체를 이루는 요구사항은 항상 맥락 없이 부분으로만 전달 되어 실무 수준에서 설계하는 사람들을 고통스럽게 만들고 또 개발 상황과 기능 간 의존성을 전혀 고려하지 않아 이를 곧이곧대로 받아들이면 그저 연관성 없는 세부 기능의 나열로 느껴질 뿐일 수 있습니다. 하지만 그런 부분들로부터 가상의 전체를 상상해 맥락을 도출하면 지금까지 예외처리로 느껴지던 부분들이 확실한 이유를 가진 체계적인 기능으로 바뀌며 이 때 도출한 맥락이 실제와 다를 수 있지만 이 차이는 가상의 전체를 여러 차례에 걸쳐 도출해 가는 과정에서 점차 줄어들어 나중에는 맥락 없이 기능을 받아도 전체 제품에서 담당하는 역할을 직관적으로 떠올릴 수 있게 됩니다.
최고 의사결정자 수준에서 전체 그림과 맥락을 포함한 요구사항을 보내 준다면 가장 행복한 개발이겠지만 우리들 수준에서 이를 기대하기 어렵다면 우리들에게 주어진 부분으로부터 전체로 이어지는 맥락을 유추하고 이에 기반해 예외처리가 아닌 필요 기능의 관점에서 설계해 개발하기를 반복하면 결국 전체에 도달할 수 있고 나아가 굳이 이야기하지 않아도 맥락을 직관적으로 인지할 수 있습니다.
이번 48호에도 다섯 가지 다른 이야기를 준비했습니다.
어느 쌀쌀한 아침 출근하며 음악을 듣다가 메시지를 읽으려고 아이폰을 꺼냈습니다. 메시지를 읽고 잠금 키를 눌렀는데 그 다음부터 아이폰은 일단 잠겼지만 그 상태로 화면이 어두워지지 않고 멈췄습니다. 터치가 안 돼 페이스아이디 인식으로 넘어갈 수도 없고 패스코드를 터치할 수도 없었습니다. 대수롭지 않게 그냥 재시작 하면 될 거라고 생각하고 위쪽 볼륨 키와 잠금 키를 동시에 누르고 있었습니다. 이 키는 짧게 누르면 스크린샷으로 동작하지만 꺼질 때까지 길게 누르면 전원이 꺼집니다. 그럼 다시 켜 이 상태를 빠져나갈 수 있을 겁니다.
그런데 아무리 오래 두 키를 누르고 있어도 재시작 되질 않는 겁니다. 아이폰은 종료, SOS, 메디컬 아이디 상태로 넘어갔지만 여전히 화면이 터치되지 않아 아무 조작도 할 수 없었습니다. 지하철이 계속해서 움직이는 동안 같은 조작을 아무리 반복해도 아이폰은 재시작 되지 않았고 이대로 출근할 것인지 아니면 아침부터 애플스토어에 갈 것인지 고민했습니다. 어쩌면 간단한 문제인지도 몰랐습니다. 일단 출근해서 방법을 검색하면 해결할 수 있을지도 몰랐습니다. 하지만 뭔가 더 심각하게 고장난 상태라 해결 방법을 찾지 못한다면 애플스토어 신세를 져야 했습니다. 고민 끝에 출근 대신 바로 애플스토어로 향했습니다.
하지만 아직 이른 아침이라 애플스토어는 개점 전이었고 아이폰이 먹통이 된 상태인 저는 애플스토어가 몇 시에 시작하는지 알아낼 수가 없었으며 불 꺼진 매장 안에 있는 사람들은 개점 준비를 하고 있었지만 잠긴 유리문 안에 있는 그들에게 오픈 시간을 물을 방법도 없었습니다. 애플스토어 앞을 몇 분 동안 얼쩡거리다가 포기하고 다시 회사로 향했습니다.
지난 몇 년 사이에 출시된 아이폰을 사용하시는 분들은 아마 알고 계시겠지만 iPhone이 켜지지 않거나 멈추는 경우에 따르면 아이폰 8 이후부터는 위쪽 볼륨 키와 잠금 키 조합이 아니라 위쪽 볼륨 키 한번, 아래쪽 볼륨 키 한번, 그 다음 잠금 키를 길게 눌러야 전원을 강제로 끌 수 있었습니다. 저는 아이폰 7까지 사용 가능한 방법을 시도했고 덕분에 전원을 끄는 대신 스크린샷을 계속해서 찍기를 반복하고 있었습니다. 출근하고 몇 분 만에 아이폰을 재시작하는데 성공했고 그냥 30분쯤 늦게 출근한 사람이 되는 걸로 끝났습니다.
아이폰을 처음 켜면 별 쓸모 없는 튜토리얼을 하려고 난리인데 정작 이런 중요한 정보는 매뉴얼에서도, 튜토리얼에서도 전혀 알려주지 않습니다. 그리고 미리 알려주지 않은 덕분에 정작 이 정보가 필요한 순간에는 아이폰이 먹통이 되어 정보를 알아낼 방법이 없었습니다. 이런 전자기기의 튜토리얼이 알려줘야 할 미션 크리티컬한 정보는 대체 무엇인가 하는 의문이 들었습니다.
그럼 또 다음 주에 뵙겠습니다. :)
