종료되지 않는 모바일 앱 요구사항의 추억

작년(2023년) 초에 겹치지 않는 UID를 수동 생성하는 요구사항을 소개했습니다. 이 글의 사례 자체는 별로 중요하지 않고 엔지니어 관점에서 기술적으로 해결해 앞으로 수많은 시간을 절약할 수 있는 요구사항을 다른 부서 사람들이 수동으로 대응하게 만들어 앞으로 수많은 시간을 낭비하게 만들고 또 실수를 유발해 거대한 비용을 낭비하려는 시도와 이를 지금 생각하면 조금 공격적인 방법으로 틀어 막은 이야기라는 점이 중요합니다.

이런 이상한 시도는 인터넷에서 흔히 접하는 능력 있는 엔지니어님들의 말씀과 상당히 다른 경험이어서 처음엔 우리들이 지금 무슨 일을 당하고 있는 것인지 잘 인식하기조차 힘들지만 조금만 시간이 지난 다음 돌아보면 인터넷에서 흔히 접하곤 하는 능력 있는 엔지니어님들을 만나 우리들이 함께 일할 수 있는 가능성은 생각보다 그리 높지 않다는 사실을 알 수 있습니다. 엔지니어님들이 중요한 의사결정을 하고 우리들의 생산성이 이에 따라 큰 영향을 받으며 나악 우리들의 생산성은 프로젝트의 개발비용을 통제하는데 엄청난 영향을 끼쳐 결국 프로젝트의 성공과 실패를 나누게 되지만 지금 당장의 의사결정이 거기까지 영향을 기친다는 사실을 인지하기는 쉽지 않습니다. 그러니 위에 소개한 기술적으로 대응할 문제를 사람이 직접 해결하도록 만드는 이상한 시도가 일어날 수 있게 됩니다.

오늘은 오래 전에 모바일 게임을 만들다 맞닥뜨린 이상한 요구사항을 소개할 작정인데 앞서 작년에 소개한 사례가 엔지니어 관점에서 기술적으로 해결해 미래의 큰 비용을 절약하고 필요 없는 실수를 절약할 수 있는 방법이 있음에도 이를 다른 부서에 수동으로 수행하도록 요구하는 것이었다면 이번에는 기획 관점에서 기술적인 이해가 부족한 상태에서 겪은 한 가지 경험을 기술적으로 가능하다고 믿고 이를 요구하며 여러 부서에 큰 비용을 낭비하게 만든 사례입니다.

현대에 모바일 게임은 이를 실행하는 기계가 빠르게 강력해지며 여러 제한으로부터 자유로워집니다. 처음 PC MMO 게임을 만들던 프로젝트를 떠나 본격적으로 모바일 게임을 만들기 시작할 때 서버를 개발하던 분들로부터 자주 들은 설명은 당시 모바일 게임 서버는 일종의 프로시저와 데이터만으로 구성된 데이터베이스 서버에 가깝다는 것입니다. 그래서 어지간한 로직을 클라이언트에서 수행하고 그 결과를 서버에 보내면 서버는 데이터베이스 프로시저 수준에서 이를 검증해 검증을 통과하면 바로 데이터베이스에 기록하고 이를 바탕으로 다른 클라이언트에 수행 결과를 전파합니다. 이 전파 역시 서버 입장에서는 아무 것도 하지 않고 기다리다가 다른 클라이언트가 상태를 요청하면 방금 업데이트 된 결과를 돌려주는 방식으로 동작합니다. 이런 상황에서 저를 포함한 기획팀은 종종 서버에서 본격적인 연산을 수행한 다음 그 결과를 클라이언트에 돌려주는 전통의 방식으로 동작할 것을 가정한 로직을 제안하곤 해 이를 기술적으로 올바른 모양으로 고치는데 시간을 사용했습니다.

애초에 전통의 MMO처럼 서버가 어지간한 로직을 모두 수행하고 결과만 돌려주는 익숙한 방식으로 만들지 않은 이유는 그렇게 만들면 클라이언트가 서버와 상시 통신을 유지해야 했기 때문입니다. 이미 서버와 상시 통신을 유지하는 게임에서조차 플레이어들의 모든 이동을 하나하나 서버와 동기화하며 엄청난 데이터를 사용해 고객들의 통신 요금을 낭비하는 대신 최소한의 데이터만 서버에 보내고 서버는 이 데이터를 기반으로 플레이어 각자의 위치, 상태, 행동을 시뮬레이션 하며 일정 시점마다 클라이언트가 보내 온 새로운 데이터와 비교해 시뮬레이션 결과와 차이를 보정한 결과를 클라이언트에 보내 동기화 했습니다. 그래서 통신 상황이 각기 다른 클라이언트를 서로 동시에 보고 있으면 서로의 동작이 완전히 일치하지 않는 모습을 쉽게 볼 수 있지만 실제로 게임을 실행하는 고객 개개인들이 그렇게 옆에 딱 붙어서 게임을 할 일은 그리 많지 않아 실제로는 동기화가 조금씩 틀어진다는 사실을 눈치 채기는 쉽지 않았고 시뮬레이션 경험이 쌓이며 데이터를 최소한만 주고 받아도 어지간한 동기화가 모두 잘 맞는 지경에 이릅니다. 처음 본격적으로 모바일 게임을 만들 때 서버를 거의 데이터베이스만 덜렁 남긴 모양에 가깝게 만든 이유 역시 게임 장르의 특징 상 상시 서버와 연결을 유지할 필요가 없었고 그렇다면 서버가 모든 로직을 직접 실행할 필요가 없었으며 그렇다면 서버가 할 일은 사실상 결과를 검증하고 저장하는 것 뿐이었기 때문입니다. 이런 접근은 고객들의 통신 요금을 절약하기 위함이었습니다.

시간이 흐르며 통신 비용이 급격히 낮아졌고 또 도시와 가까운 어지간한 장소, 또 어지간한 지하나 터널에서도 통신이 끊기지 않게 되어 이전 MMO 게임을 만들 때와 마찬가지로 서버와 상시 연결을 유지하도록 할 수 있게 되어 접근 방법은 조금 달라졌습니다. 또한 프로세서, 메모리, 스토리지를 훨씬 더 많이 사용할 수 있게 되면서 여러 제한이 점점 줄어듭니다. 특히 모바일 게임에서 화면을 그리기 위해 드로우 콜을 극도로 줄여 사용해야 했는데 이는 겉으로는 똑같이 보이는 화면을 만들기 위해 사람이 손으로 에셋을 모두 튜닝해 더 적은 드로우 콜을 사용하도록 하기를 요구했습니다. 더 강력한 장비에서는 사람이 직접 이런 일종의 최적화 작업을 하는 대신 성능에 의존해 더 적은 개발 비용으로 같은 화면을 보여줄 수 있었지만 모바일 환경에서는 성능 개선이 더 중요했기 때문에 인력을 투입해 기술적 제한을 이해한 사람이 그에 맞는 에셋을 제작하게 했습니다.

가령 PC 환경에서는 한밤의 공성전 장면에서 주인공을 둘러싼 수많은 병사들이 하나하나 성을 향해 달려가고 사다리를 오르고 성 앞을 막아 선 적 병사들과 싸우는 모습을 클라이언트에서 직접 하나하나 재생하게 만들었지만 모바일에선 똑같이 만들었더니 1프레임이 나와 도저히 봐줄 수 없었습니다. 그래서 수많은 병사들을 하나로 묶어 병사 수 십 명이 애니메이션 하나로 움직이게 만들기를 반복해 프레임을 올렸는데 분명 보기에는 똑같았지만 성능이 극적으로 개선됩니다. 하지만 병사 하나하나가 따로 움직일 때는 몇몇 병사들의 움직임이 어색해 이들이 성의 다른 곳을 공격하게 만드는 의사결정을 하기 쉬웠지만 병사들이 한 덩어리로 묶여 움직이는 순간부터 그런 의사결정은 비용이 극도로 비싸졌고 누구도 함부로 그런 의견을 내지 않았습니다.

이제 이런 제한이 상당히 줄어들어 강력한 성능을 보이던 콘솔 기계와 거의 2-3년 이내로 성능 차이가 줄어들어 이전 만큼 지독하게 최적화에 매달릴 필요가 줄어들었습니다. 여전히 최신의 강력한 기계와 비교하기는 어렵지만 모바일 기계에서 동작하는 게임 화면을 그대로 큰 모니터로 보내 띄워 놔도 어지간한 사람들은 이 화면이 모바일 기계에서 그려진 것인지 콘솔 기계에서 그려진 것인지 확신을 가지고 구분하기는 쉽지 않을 겁니다. 하지만 여전히 모바일 기계는 이 기계가 사람들의 손 위에서 배터리에 근거해 동작하며 게임을 구동해야 할 뿐 아니라 다양한 다른 프로세스를 함께 구동해야 하는 기계라는 사실 때문에 생기는 근본적인 제한은 남아 있습니다. 게임이 아무리 잘 돌아가도 근본적으로 이 기계는 과거의 ‘전화’로부터 발전해 왔으며 현대에 이 기계로 온갖 작업을 다 처리하지만 여전히 이 기계의 핵심은 ‘전화’ 기능입니다. 여전히 이 모바일 기계는 아래쪽에 마이크, 위쪽에 작은 스피커가 달려 있어 입과 귀에 갖다 대고 다른 사람과 대화할 수 있으며 이 구성은 앞으로도 한동안 달라지지 않을 겁니다. 이런 하드웨어의 특징 뿐 아니라 근본적으로 이 기계가 전화이기 때문에 전화는 다른 모든 기능에 우선해 동작하는데 이 기계에서 무엇을 하고 있었든지 간에 전화가 걸려 오면 그 작업을 멈추고 전화 기능으로 전환해 전화 통화에 집중하게 되어 있고 이는 현대에 아무리 발전한 어떤 모바일 기계라도 똑같습니다.

이 말은 게임 상에서 무슨 일을 하고 있었든지 간에 전화가 걸려 오면 전화로 전환해야 했고 그 사이에 게임은 고객으로부터 입력을 받지 못하거나 통화가 계속되는 동안 데이터 통신이 불가능해지거나 전화 통화를 우선 처리하려는 OS에 의해 종료될 수도 있었습니다. 한동안은 모바일 게임이 애초에 상시 연결을 요구하지도 않았고 이에 맞춰 높은 집중과 관여를 요구하지도 않았지만 여러 기술이 발전하면서 이전에 PC 게임을 만들 때와 마찬가지로 좀 더 높은 집중과 관여를 요구하는 모양으로 변해 갔는데 이 때 걸려 온 전화는 고객을 실망시키기에 충분합니다. 이제 한 5%만 더 깎으면 지난 한 시간에 걸쳐 공략한 던전 보스를 끝장낼 수 있는 상황이었는데 이런 중요한 상황을 알 리 없는 누군가가 전화를 걸어와 이 상황을 방해한다면 게임 입장에서 이 상황을 처리해줄 방법이 없습니다. 운이 좋아 짧은 통화로 끝났다면 바로 게임으로 돌아와 보스의 장판을 회피할 기회가 있을지도 모릅니다. 운이 조금 나빴더라도 통화가 짧았다면 바로 게임으로 돌아와 죽은 자신을 보고 바로 부활해 보스에게 달려가 막타를 노릴 수 있을 수도 있습니다. 그런데 운이 나빠 통화가 길어진다면 상황이 급격히 나빠질 수도 있는데 통화가 길어지고 이 사용자가 전화통화 뿐 아니라 다른 작업을 할 수도 있겠다고 예상한 OS가 모바일 기계의 응답성을 유지하기 위해 게임을 메모리에서 내린 다음 게임으로부터 처리 요청을 무시하기 시작할 수 있고 시간이 더 지나면 게임을 종료해 버릴 수도 있습니다. 이런 동작은 아직 통화가 끝나지 않은 사이에 뒤에서 조용히 일어날 겁니다.

이 운 나쁜 고객이 통화를 마치고 다시 게임으로 돌아오려 할 때 게임이 그저 메모리로부터 내려가 있었다면 검은 화면에 잠시 멈췄다가 보스와 싸우던 던전이 나타날 수도 있습니다. 하지만 운이 나쁘다면 게임으로 전환하자 제작사와 퍼블리셔 로고가 나타나고 서버 선택과 계정 선택을 거친 다음 던전 밖으로 쫓겨난 자신을 발견하고 지난 한 시간 동안의 노력이 물거품이 되어 버린 현실을 마주하게 될 수도 있습니다. 이런 동작은 기계가 아무리 발전하더라도 이 기계가 근본적으로 전통의 ‘전화’에 기반하고 있기 때문에 절대 회피할 수가 없습니다. 과거에 모바일 게임은 언제든 통신이 끊길 수 있는 상황에 대응해야 했고 이제 모바일 게임은 언제든지 OS에 의해 멈춰지거나 종료될 수 있는 상황에 놓입니다. 이전에 비해 고객에게 좀 더 집중할 것을 요구하지만 이런 상황을 피할 수 없는 이상 고객의 노력이 전화 한 방에 수포로 돌아가 큰 실망을 주는 상황을 제작사 입장에서 회피하기는 정말 쉽지 않습니다. 한번은 던전 관련 회의 도중 이 이야기가 나왔는데 어떤 주니어님이 ‘중요한 전투 중에는 전화를 무시할 수 없느냐’는 말씀을 하셔서 어두운 방 안의 모든 사람들을 얼어 붙게 만든 적도 있습니다. 기술적으로 거의 불가능하지만 만약 가능하다 하더라도 게임이 동작하는 기계의 근본적인 기능에 함부로 손대려는 어떠한 시도라도 성공하고 또 이 성공을 플랫폼 홀더가 눈치 채는 순간 우리는 즉시 검수 거절의 철퇴를 맞게 됩니다.

하지만 어떻게든 방법을 찾아낸 우리들은 전화를 막는 대신 던전을 유지하는 방법을 고안합니다. 이전 시대의 MMO 게임들은 어떤 이유로든 던전에서 튕기면 그 던전의 진행상황을 잃곤 했습니다. 컴퓨터가 다운되거나 게임이 크래시되거나 인터넷 연결이 끊기는 등 여러 가지 이유로 게임이 중단될 수 있었는데 이 고객이 상황을 회복한 다음 다시 게임을 시작하면 던전 입구에서 재시작했고 던전의 진행상황은 사라졌습니다. 던전에 아무도 남아 있지 않으면 던전을 없애는 규칙에 의해 이미 던전 인스턴스는 사라졌고 지난 한 시간 넘게 한 노력은 완전히 사라집니다. 그 노력과 함께 던전 안에서 사용한 모든 포션과 아이템 비용은 사라졌지만 이를 통해 아무 것도 얻지 못했으며 심지어 던전 입장권도 사라져 있을 때도 있었습니다. 하지만 이런 상황을 개선하기 위해 던전 인스턴스를 제거하는 규칙을 훨씬 느슨하게 바꾸고 던전 입장권은 던전 입장 시점이 아니라 던전 보상을 습득하는 시점으로 바꿔 던전 입장권이 일종의 보상 교환권으로 동작하게 바꿔 억울하게 입장권을 잃는 상황을 없앴습니다. 어떤 이유로든 고객이 게임에서 나가더라도 던전은 일정 시간 유지되며 재접속 하면 진행 상황이 유지된 던전의 그 자리부터 다시 진행할 수 있었고 최악의 경우 보스로부터 죽어 바닥에 누워 있을 수는 있었지만 아예 던전 바깥으로 튕겨 모든 진행 상황을 잃지는 않게 됐습니다.

이쯤 되자 기획팀의 어느 높은 분은 모바일 게임을 플레이 하면서도 어지간해서는 게임을 실행할 때 제작사 로고부터 시작하는 상황을 잘 겪지 않게 됐고 자신이 게임을 실행하는 기계가 여전히 모바일 기계이며 모바일 기계의 근본적인 한계를 안고 있다는 사실을 잊어버린 것 같습니다. 어느 날 이 분은 모든 시스템디자인의 컨텍포인트 또는 헬프데스크 역할을 하던 저에게 자신의 지난 며칠 동안의 경험을 이야기하기 시작합니다. 자신이 아이패드에서 다른 모바일 게임을 플레이 하고 있었는데 아이패드로 게임도 하고 유튜브 영상도 보고 메신저도 사용하고 사진도 찍기를 반복했으며 페이스타임 통화도 했지만 게임으로 돌아가자 게임은 잠깐 동안 로딩 화면에 멈춰 있다가 다시 이전에 플레이 하던 필드로 돌아가기를 반복했고 이를 여러 번 경험해 보니 이 과정이 굉장히 편리했다는 것입니다. 실은 어지간히 규모가 큰 모바일 게임은 일단 실행하면 제작사와 퍼블리셔 로고가 나오고 게임 로고가 나오고 로딩을 거친 다음 로그인 과정을 거치고 서버를 선택하고 멋진 3D 배경을 불러와 카메라로 이를 훑는 타이틀 화면에 도착해 화면을 더치할 것을 요구한 다음 화면을 터치하면 캐릭터를 선택하고 확인 버튼을 터치하고 로딩을 거치는데 운이 나쁘면 이 사이에 데이터 업데이트 몇 기가를 받은 다음에야 간신히 게임을 시작할 수 있습니다. 이 과정은 생각보다 길어 아무리 자신이 이 게임에 많은 자원을 투자하기로 마음 먹었다 하더라도 지하철 한 역을 이동하는 시간 동안 게임이 시작되지도 않는 경험을 하게 만들기 일쑤입니다.

때문에 이런 초반 과정을 단축해야 한다는 문제의식은 이전부터 있어 왔습니다. 그런데 이 분이 체험하신 동작은 적어도 그 경험에만 집중한다면 훌륭했고 만약 이 동작을 우리가 흉내 낼 수 있다면 이들처럼 우리도 모바일 게임이 가지는 근본적인 문제를 완화할 수 있을른지도 모릅니다. 하지만 기획팀 입장에서는 이런 동작이 기술적으로 가능한지 알 수가 없었습니다. 또한 제가 직접 이 동작을 재현해보려고 여러 차례 시도했지만 명백히 다른 앱으로 전환했다가 짧은 시간 안에 돌아온 경우를 제외하면 항상 그 게임은 제작사 로고부터 시작했고 저는 그 분의 경험을 재현할 수가 없었습니다. 아이패드로 게임을 실행하다가 카메라 앱으로 전환하면 종종 메모리가 부족해 카메라 앱이 실행되다가 크래시 된 다음 스프링보드로 돌아왔고 이 때 게임을 실행하든 카메라 앱을 실행하든 양쪽 모두 종료된 상태여서 처음부터 다시 시작해야만 했습니다. 예외가 있다면 게임을 실행해 플레이 하다가 아이패드를 바로 잠그거나 다른 작업을 수행하지 않고 스프링보드로 돌아온 다음 아이패드를 잠그면 다음 번 잠금 해제 직후 게임이 잠깐의 로딩을 거친 다음 이전 상태로 돌아가는 모습을 볼 수는 있었습니다. 이런 여러 차례의 시도 끝에 그 분이 경험한 동작은 그들이 어떤 기술적 도약을 한 것이 아니라 우연한 상황이 겹쳐 며칠에 걸쳐 게임 앱이 완전히 종료되지 않았을 것 같다는 의견을 냈지만 그 분의 경험에 대한 믿음은 아주 단단했고 뭐라도 해야만 하는 상황이라는 사실을 깨달았습니다.

제 관점에서 이 요구사항은 달성하기 불가능해 보였고 이미 이 요구사항을 문서로 만들어 리드 엔지니어에게 보내면 어떤 반응을 보일지 머릿속에 그려집니다. 이런 상황에서 이 일을 팀의 다른 누군가에게 할당할 수는 없었습니다. 그래서 제가 수행하기로 하고 요구사항과 이에 따른 동작을 정의한 기획서를 작성한 다음 이런 동작이 맞는지 확인해 엔지니어 부서에 보냈고 그 사이에 저는 정말로 그런 동작이 가능한지 기술 문서를 찾아보며 모바일 기계에서 동작하는 애플리케이션이 그 스스로 메모리에서 내려가지 않거나 그 스스로 메모리에서 내려간 상태이더라도 최소한의 과정을 거쳐 다시 이전 상태로 복구 될 방법이 있는지 찾아봤는데 제한적으로 가능한 시나리오가 있었지만 요구사항의 수준에 도달하지는 못할 것 같았습니다. 당연히 한 시간이 채 지나기도 전에 이전에도 이런 상황을 여러 차례 겪어 이미 저와 불가능한 요구사항에 대한 피드백을 주고 받는데 익숙한 리드 엔지니어님이 나타나 이야기를 시작합니다. 아마 팀에 다른 분께 이 일을 할당했다면 좀 더 무서운 얼굴로 그 분을 찾아갔을지도 모르지만 제 자신은 헛소리를 거의 하지 않으며 함부로 대하기에는 한가닥 한다는 사실이 이미 팀에 알려져 있어 그런 일이 일어나지는 않았습니다. 결론은 간단했고 이미 예상했습니다. 그런 일관된 동작은 현재 기술적으로 불가능합니다.

이제 한 편이 된 엔지니어님과 저는 요구사항을 주신 분께 이 상황을 인식 시키고 요구사항을 다른 방법으로 접근해야 하며 이를 위해 기획팀에서 적절한 제안을 만들 시간이 필요하다는 사실을 설득하려고 노력했습니다. 앞에서 OS나 앱 크래시, 네트워크 순단 같은 이벤트에 의해 던전 진행 상황을 완전히 잃던 것을 던전 인스턴스를 삭제하는 규칙을 훨씬 느슨하게 변경해 - 대신 운영 비용이 증가했지만 - 경험을 개선할 수 있었고 이번에도 비슷한 요령으로 대안을 찾을 수는 있을 거라고 생각했습니다. 대강 이전에 앱이 종료된 방법에 따라 고객의 경험을 예상한 다음 제작사 로고부터 띄우는 완전 처음부터 실행할 상황과 이 모든 상황을 건너 뛴 다음 이전 상태로 바로 복구하는 상황을 구분해 각각을 수행할 수는 있을 것 같았습니다. 하지만 이런 제안에도 불구하고 요구사항을 내신 분은 완강했고 기술적 한계를 이해하거나 납득하려 하시는 것 같아 보이지 않았습니다. 다행히도 서로의 이야기가 반복되기 시작했음은 모두가 납득해 일단 요구사항을 유지한 채 다음에 이야기하자고 말하며 자리를 마무리했지만 여전히 이 불가능한 요구사항은 우리들의 업무 목록에 남아 있었습니다. 당시 저는 여러 가지 이유로 인프라 부서 이외에는 아무도 가지고 있지 않았던 지라, 컨플루언스의 어드민 권한을 가지고 있었는데 그냥 며칠 지나면 잊어버릴 테니 그때까지 기다렸다가 기록을 슬쩍 지워버릴까 하는 생각도 했으나 실행하지는 않았습니다.

결국 기술적으로 불가능한 이 요구사항은 실행되지 않았고 계속해서 우선순위가 낮아졌고 제 스스로도 그 일의 우선순위가 올라가 마일스톤 목표 범위에 들어가지 않도록 태스크 목록을 관리했습니다. 결국 요구사항을 내신 분은 몇 주가 지나자 자신이 제안한 불가능한 요구사항에 대해 완전히 잊어버렸고 그 분이 그 게임을 플레이 하시는 모습을 그분 뒤를 지나다니며 여러 차례 살펴봤지만 제작사 로고가 뜨는 모습을 여러 번 목격할 뿐이었습니다. 어느 날 저는 몸과 마음이 완전히 파괴되어 팀을 떠났고 그 요구사항의 향방을 알 길이 없어졌습니다. 하지만 지금도 가끔 그 요구사항은 어떻게 되었을까 궁금해졌고 이번에도 어느 무더운 금요일에 퇴근하며 지하철 에스컬레이터 위에 서 있다가 생각 나 이 글을 적어 보았습니다.

무엇이 잘못되었던 것일까요. 그 분의 요구사항일까요, 아니면 기술적 한계를 받아들이지 않으려는 자세일까요, 아니면 기술적 한계에도 불구하고 방법을 찾아내기 위해 좀 더 노력하지 않은 게임디자인의 문제일까요, 아니면 기술적 한계를 명백히 파악하고 이를 설명한 엔지니어의 문제일까요. 아니면 던전 인스턴스를 유지하는 사례처럼 경험을 개선할 기회를 놓친 것일까요? 지금은 알 수 없게 됐습니다. 올해(2024년)에는 오랜 개발 기간을 거쳐 게임이 출시된다는 모양이니 한번 살펴봐야겠습니다.