학교 졸업하고 나서 일하기 시작한 첫 해에는 회사에서 지급해 준 키보드를 별 불만 없이 사용했습니다. 그러던 어느 날 프로그래머 한 분이 사용하시는 키보드를 봤는데 여러 모로 마음에 들었습니다. 일단 회사에서 지급해 준 키보드를 사용하지 않아도 된다는 것을 알게 됐고 키보드에도 개인의 취향을 반영할 수 있다는 것을 알게 됐으며 오른쪽 숫자 키패드나 펑션 키 배열이 반드시 필요하지는 않을 수 있다는 생각을 처음 하게 되었습니다.

그 키보드가 뭔지 알아보니 해피해킹 키보드 프로페셔널이라는 키보드였는데 그 때 내 월급으로는 정말 엄청나게 비싼 물건이었습니다. 큰 맘 먹고 키보드를 주문했고 그 후로 지금까지 같은 키보드를 계속해서 사용해 오고 있습니다. 이제 너무 오랫동안 사용해 와서 이런 배열에 완전히 익숙해지기도 했고 또 이 배열 때문에 이보다 키가 더 많은 키보드를 사용할 때 너무 번잡하고 복잡하고 또 손을 너무 많이 움직여야 해서 힘들다는 느낌을 받을 때도 있습니다.

이 키보드는 원래 방향키를 쓸 일이 거의 없는 터미널 환경에서 주로 사용한다고 알려져 있는데 다른 키보드에 비해 키 수가 적은 특징과 터미널 환경이 바로 연결되는 것은 아닙니다. 또 윈도우 환경이나 엑셀 같은 오피스 앱 사용에도 적합하지 않다고 알려져 있는데 이 역시 꼭 그렇지는 않습니다. 이 키보드를 사용해 오면서 유일하게 곤란했던 순간은 키보드를 샀던 첫 번째 직장을 그만 두고 두 번째 직장에 출근했을 때 팀에서 카트라이더 할 때 뿐이었습니다. 상하좌우 방향키로 조작해야 했는데 이 키보드로는 방향키 각각을 펑션키 조합으로 입력할 수는 있었지만 민첩하게 입력할 수는 없었습니다. 이 사용 사례를 제외한 나머지 상황에서는 알려진 것 만큼 윈도우 환경이나 오피스 앱에 사용하기 불편하지 않습니다. 이 키보드 이야기를 하면 자주 나오는 일종의 미신을 좀 설명해 보겠습니다.

먼저 이 키보드에는 오른 편에 숫자 키패드가 없는데 흔히 숫자 키패드가 없으면 숫자를 민첩하게 입력하기 어렵다고 알려져 있어 키패드 없는 키보드에 관심을 가지는 분들에게 겁을 주곤 합니다. 실은 은행 처럼 아예 본격적으로 숫자를 수동으로 입력해야 하는 상황이 아니라면 숫자를 많이 입력할 일은 생각보다 많지 않습니다. 심지어 엑셀을 사용할 때도 작업 대부분은 워크시트를 가공하고 계산 과정을 입력하고 수식을 만들거나 스크립트를 작성하는 작업이 대부분이고 숫자를 직접 키패드를 타이핑 해서 입력할 일은 거의 없습니다.

다음으로 첫 번째 줄이 펑션 키가 아니라 숫자 키가 배치되어 있는데 펑션 키는 오른쪽 구석에 있는 Fn 키와 숫자 키를 조합해서 입력합니다. 펑션 키를 자주 사용해야 하는 사용 시나리오에는 불편하다고 알려져 있습니다. 그런데 실제로는 펑션 키를 더 빨리 입력할 수 있는데 이유는 손이 숫자 키 윗 줄까지 올라갈 필요가 없기 때문입니다. 문자와 숫자를 타이핑하다가 펑션 키를 입력해야 하면 펑션 키가 분리되어 있는 키보드는 손이 숫자 키보다 더 윗 줄까지 올라가야 하고 심지어 숫자 키와 펑션 키 사이에 공간이 넓은 키보드도 있어 오히려 시간이 더 오래 걸리고 불편합니다. 펑션 키를 입력할 때 숫자 키가 배치된 첫 번째 줄에서 조작을 마칠 수 있어 빠르게 타이핑하는 상황에 펑션 키를 섞어 입력할 때 더 빨리 입력할 수 있습니다.

또 페이지업, 페이지다운, 홈, 엔드 키가 분리되어 있지 않아 문서 작성에 불편하다고 알려져 있습니다. 이 미신 역시 다른 문자와 숫자를 타이핑 하는 상황에서 이 키들이 엔터 키 오른쪽에 분리된 키보드라면 홈이나 엔드 키를 누르려면 오른손이 상당히 먼 거리를 움직여야 합니다. 문서를 작성할 때 이번 줄을 타이핑 하다가 줄 맨 앞으로 돌아가야 할 때 홈 키를 찾으려면 다른 키보드는 오른손이 엔터 키 너머 머나먼 곳까지 가야 하지만 이 키보드에서는 문자를 타이핑 하던 위치에서 거의 이동하지 않은 채로 바로 홈 키를 입력할 수 있습니다. 홈, 엔드, 페이지업, 페이지다운 모두 오른손이 거의 움직이지 않은 상태로 입력할 수 있습니다. 그래서 타이핑과 커서 내비게이션 키를 빠르게 섞어 입력해야 할 상황에서 오히려 훨씬 빠르게 작업할 수 있습니다. 이 경험은 마우스 커서 조작 인터페이스가 키보드 중간에 박혀 있는 씽크패드를 사용할 때 타이핑 도중 마우스 커서를 움직이더라도 손을 거의 움직이지 않고 키보드와 마우스를 전환할 수 있는 경험과 비슷합니다.

또 이 키보드는 주로 마우스를 거의 사용하지 않는 시나리오에 더 유용하다고 알려져 있지만 실제로 이 키보드는 오히려 마우스를 자주 사용하는 사람들을 위한 키보드입니다. 위에서 커서 내비게이션 키나 펑션 키를 입력하기 위해 손이 거의 이동할 필요가 없다고 이야기했는데요. 특히 숫자 키패드와 커서 내비게이션 키가 별도 영역을 차지하지 않는데 그 결과 평소에 커서 내비게이션 키를 입력할 때 손이 이동할 위치에 마우스가 있습니다. 이 말은 오른손 기준으로 엔터 키보다 고작 몇 센티미터 옆으로 이동하면 바로 마우스를 잡을 수 있다는 의미입니다. 그래서 키보드와 마우스를 번갈아 가며 조작할 상황에도 씽크패드 키보드만큼 완벽하지는 않지만 상당히 빨리 입력 도구 사이를 전환할 수 있습니다.

한국어 사용자 입장에서 캡스락 자리는 캡스락이 차지하기에는 너무 좋은 자리입니다. 이 키보드는 따로 설정하지 않아도 처음부터 그 자리가 캡스락이 아니라 컨트롤 키입니다. 윈도우 기준으로 키보드 맨 아랫 줄에 컨트롤 키가 위치한 여느 키보드와 비교해 복사, 붙여 넣기 같은 반복 작업을 할 때 왼손 손목이 거의 꺾이지 않아 피로감이 훨씬 적습니다. 여기서 조금 더 나가면 왼손으로 컨트롤 키와 다른 키를 조합해서 입력할 때 훨씬 편하고 컨트롤, 알트, 시프트 키를 동시에 입력할 때도 시프트 키와 컨트롤 키가 키보드 왼쪽 바깥에 붙어 있어 손날로 누르면 돼 이상한 손 모양을 만들 필요가 없습니다.

이런 특징은 윈도우에서는 불편하다거나 엑셀을 사용하기 어렵다거나 커서 내비게이팅이 어렵다거나 하는 이 키보드 이야기만 나오면 반사적으로 딸려 나오는 미신과는 전혀 다를 뿐 아니라 이 키 배치를 통해 얻을 수 있는 강력한 생산성을 가립니다. 만약 키보드에 돈을 좀 낼 생각이 있고 또 초반의 ‘낯선 경험'을 마주할 여유가 있다면 미래의 강력한 생산성 향상과 편리함을 얻을 수 있는 이 키보드를 추천합니다. 다만 종종 다른 사람이 내 키보드를 사용할 일이 있는 협업 환경에서는 내 자리에 찾아온 손님을 당황하게 만들 수도 있습니다. 이럴 때를 대비해 손님용 키보드를 별도로 준비해 두는 것을 추천합니다.

게임에서 물체와 상호작용 하는 장면을 만들 때 대략 세 가지 방법을 고려할 수 있습니다. 상호작용은 게임 상에서 플레이어가 게임 월드에 배치된 어떤 사물이나 사람을 대상으로 미리 약속된 행동을 상황을 말합니다. 가령 플레이어가 문을 조작해 문을 열거나 나무에 열린 과실을 따거나 바닥에 떨어진 아이템을 줍거나 NPC와 서로 눈을 마주치며 대화하는 상황들을 모두 상호작용 한다고 표현합니다. 또 지나가는 자동차를 세우거나 그 자동차 문을 열거나 그 안에 있는 사람에게 주먹을 날린 다음 그 사람을 끌어내린 다음 그 차에 올라 타는 행동도 모두 자동차와 상호작용 한다고 말할 수 있습니다. 지난번에 마스토돈에서 두 가지 방법을 간단히 설명했는데 여기에 하나를 추가해 모두 세 가지 방법을 설명하고 상황에 따라 어떤 방법을 선택해야 할 지도 함께 고민해 볼 작정입니다.

첫 번째 방법. 물체에 가까이 다가가 상호작용을 시도하면 상호작용 대상 물체와 플레이어의 애니메이션이 애초에 맞지 않을 거라고 가정하고 이들이 서로 맞지 않아도 크게 이상하지 않은 애니메이션을 사용하는 겁니다. 주로 MMO 장르에서 동시에 여러 플레이어가 상호작용을 시도할 것으로 예상되는 대상에 이런 방법을 사용합니다. MMO 장르에서 퀘스트를 플레이 하다 보면 텍스트 상으로는 부서진 울타리를 수리하라고 하지만 막상 울타리에 다가가 상호작용을 시도하면 플레이어는 뭔가 어설픈 이상한 애니메이션을 재생하고 그 사이에 부서져 있던 울타리는 터미네이터 마냥 알아서 재조합되곤 합니다.

이렇게 만든 이유는 MMO 장르에는 이런 퀘스트가 수 없이 많은데 퀘스트 각각의 상황 마다 잘 맞는 애니메이션을 만들어 사용하기에는 비용이 엄청나게 높고 또 여러 플레이어가 동시에 상호작용을 시도하기 때문에 이들모두가 상황에 맞는 애니메이션을 정확히 재생하려고 하면 멀티플레이 환경에서 이들이 모두 겹쳐 이상하게 보일 것이기 때문입니다. 하지만 결국 이 방법을 남발하다 보면 게임이 좀 싸 보이고 결국 MMO 장르에서 물체와 상호작용이 전반적으로 어설퍼 보이는 인식을 만들었습니다.

두 번째 방법. 이런 상황에서 몇몇 MMO들은 적어도 상호작용 하는 대상과 플레이어 각각이 재생하는 애니메이션이 서로 한 가지 행동과 그 행동의 결과를 표현하는 형태로 함께 재생되게 만들기 시작합니다. 가장 흔한 형태는 던전에서 바닥에 설치된 커다란 스위치를 당겨 문을 여는 것입니다. 스위치 같은 상호작용 대상은 초기 MMO 장르에서 잘 시도하지 않았는데 이유는 조작되는 방향이 있기 때문입니다. 그저 울타리를 수리하거나 사과나무 주변에서 대강 뭔가 하는 척만 하면 됐던 상황과 달리 스위치는 켜진 상태와 꺼진 상태가 확실히 구분되어야 하고 스위치를 조작할 때 이상해 보이지 않으려면 스위치 방향과 플레이어의 방향이 잘 정렬되어 있어야 하고 플레이어가 스위치를 조작하는 애니메이션을 시작하면 동시에 스위치 역시 플레이어에 맞춰 애니메이션을 함께 재생해야 어색해 보이지 않습니다.

이를 달성하기 위해 먼저 플레이어가 스위치를 조작하는 애니메이션과 조작되는 스위치 애니메이션이 서로 완전히 동시에 재생될 것을 예상한 애니메이션을 제작합니다. 다음으로 레벨에 스위치를 설치할 때 스위치를 조작하기 시작할 위치와 방향을 설정해야 하고요. 인게임에서 플레이어가 스위치 근처에 다가가 상호작용을 시작하면 플레이어는 먼저 미리 지정해 놓은 스위치 조작 위치까지 자동으로 걸어서 이동한 다음 방향을 맞춰 선 채로 상호작용 애니메이션을 재생하기 시작합니다.

플레이어는 이미 위치와 방향이 정렬된 상태로 애니메이션을 재생하므로 여기 맞춰 스위치가 움직이는 애니메이션을 재생하면 마치 플레이어가 스위치를 당기는 것 같은 모습을 꽤 그럴싸하게 표현할 수 있습니다. 또한 위에서 이야기한 울타리 사례와 달리 같은 메커닉을 여러 장소에 재사용 할 수 있어 그럴싸한 모습을 보여줌과 동시에 높지는 않은 제작 비용을 유지할 수 있고요.

마스토돈에서 이야기하지 않은 세 번째 방법은 완전히 컷씬으로 만드는 것입니다. 멀티플레이 환경에서 사용하려면 고려할 점이 많습니다. 특히 플레이어 한 명이 대상과 상호작용 하고 있을 때 주변의 다른 플레이어들에게 이 상황이 어떻게 보여야 할 지, 또 동시에 여러 플레이어가 같은 대상에 상호작용 할 수 있을지 등을 정의해야 합니다. 하지만 싱글플레이 게임이라면 상황을 단순하게 유지하면서도 가장 그럴 듯한 상호작용을 표현할 수 있습니다.

두 번째 사례에서 설명한 스위치를 조작하는 경우를 완전히 컷씬으로 만든다면 플레이어가 상호작용할 대상 근처에 다가가 상호작용을 시도하면 인게임 화면에서 컷씬 화면으로 전환해 아티스트가 미리 제작한 가장 완벽한 스위치 당기는 애니메이션을 컷씬을 통해 재생합니다. 특히 인게임 화면과 컷씬 화면 사이에 전환이 자연스럽게 일어나면 유저는 이 화면이 조작 가능한 인게임 상황인지 조작 불가능한 컷씬 상황인지 구분하기도 어렵습니다.

이런 특징 때문에 MMO 게임에 비해 싱글플레이 게임의 연출이 더 훌륭하고 이는 싱글플레이 게임이 주로 출시되는 콘솔 환경과 연결되어 ‘콘솔 게임이 더 훌륭하다’ 같은 인식을 만들기도 합니다. 하지만 처음에 울타리 사례를 설명하며 모든 상황에 맞는 애니메이션을 만들기 위해서는 높은 비용이 필요하다는 이야기를 했는데 싱글플레이 게임이 그렇게 멋진 장면을 보여줄 수 있는 이유는 이들의 제작비가 엄청나게 높기 때문이기도 합니다.

실은 이 세 가지 방법 외에도 두 번째 방법과 비슷하지만 상호작용 하는 도중에도 플레이어를 조작해 상호작용을 취소하거나 상호작용이 일어나는 도중에 동작의 방향을 전환하는 등 더 높은 요구사항을 충족하는 방법들이 있지만 이쪽은 본격적으로 게임의 핵심 메커닉의 요구사항에 연결된 경우가 많아 이 글에 묶어 설명하기에는 무리가 있습니다. 요약하면 상호작용은 크게 방향성 없는 방법, 방향성 있는 방법, 완전히 컷씬을 통하는 방법의 세 가지가 있고 상황에 맞게 사용해야 덜 어색하고 또 제작 비용을 너무 높이지 않을 수 있습니다.

지난번에 복잡한 그림을 이번에는 어떤 도구를 사용해서 그리면 좋을지 고민하다가 머메이드를 추천 받아 사용했었습니다. 그 때 작업에도 머메이드를 유용하게 사용했을 뿐 아니라 그 후에도 머메이드로 그리기 어려운 몇 가지 상황을 제외하고 어지간한 다이어그램은 머메이드로 그리게 됐는데 사용에 익숙해짐에 따라 여러 모로 생산성이 높아졌습니다. 지난번 머메이드 사용기에 이어 오늘은 머메이드를 사용할 때 회의 상황에서 회의 진행과 동시에 머메이드로 그림을 그려 진행 도중에 바로바로 공유해 생각을 확인하고 의견을 정리하며 회의 종료와 동시에 이 모든 것을 한 번에 공유할 수 있는 민첩한 사용 시나리오를 소개하겠습니다.

일단 머메이드에 대해 짧게 소개하면 온라인에서 키보드만으로 여러 가지 다이어그램을 그릴 수 있는 도구입니다. 가령 플로우차트를 그린다면 파워포인트나 비지오, 피그잼, draw.io 같은 도구를 사용할 텐데 이 도구들은 모두 다이어그램을 마우스로 그려야 합니다. 마우스 사용에 문제가 있는 것은 아니지만 마우스로 도형을 선택해 캔버스에 떨어뜨린 다음 적당한 크기로 설정하고 그 키보드로 돌아와 그 안에 적당한 텍스트를 쓰기를 반복하고 이들 사이에 화살표 도구를 가져와 연결해야 합니다. 별 것 아닌 뻔한 다이어그램인데도 생각보다 익숙하고 빠르게 그리기 어렵습니다.

이런 상황에서 머메이드는 도형을 배치하고 그 안에 텍스트를 넣고 도형을 연결하는 과정 모두를 문자로 정의할 수 있어 마우스에 완전히 손 대지 않고서도 다이어그램을 그릴 수 있습니다. 특히 머메이드를 지원하는 위키 환경에서 다른 도구 없이 문서 중간에 다이어그램을 포함하거나 마크다운 문서 중간에 이미지 파일 도움을 받지 않고 다이어그램을 포함 시킬 수 있어 굉장히 편리합니다.

이전에 복잡한 플로우차트를 그릴 때 머메이드를 사용하면서 체험한 가장 큰 장점은 다이어그램에 논리적인 오류가 없는지 검토하는 것이었습니다. 일단 그림이 복잡해지면 보는 사람을 쉽게 현혹 시킵니다. 사실은 화살표를 따라 가며 내용을 점검하면 그리 복잡한 그림이 아닌데도 일단 보는 사람을 주눅 들게 만들어 오류 점검을 어렵게 합니다. 반면 머메이드로 그린 플로우차트는 사람 눈을 현혹시키는 복잡한 그림을 보는 대신 다이어그램을 구성하는 문자에만 집중해 각 노드 사이에 관계가 올바른지, 필요한 모든 노드가 연결되었는지를 파악하고 검토할 수 있어 완성된 다이어그램에 높은 자신감을 가질 수 있었습니다.

복잡한 다이어그램을 그려 낼 수 있을 뿐 아니라 실시간으로 회의를 진행하는 도중 회의 내용을 다이어그램으로 그릴 때 머메이드 만한 대안이 없었습니다. 게임 개발 팀에서 여러 협업 부서가 모인 회의를 할 때 기획팀은 대부분 회의를 이끌어 가는 역할을 합니다. 회의를 주최하고 회의를 진행 시키며 회의가 끝나면 이를 정리해 공유하고 회의 결과에 포함된 액션 플랜이 잘 진행되는지 확인해 결과를 뽑아 내는 매니지먼트 역할도 해야 합니다. 여기서 회의 자체에만 집중해 보면 회의를 진행하면서 동시에 내용을 기록해야 하는데 이미 여기까지만 해도 내가 말할 때, 다른 사람이 말할 때를 구분하지 않고 내용을 잘 요약하고 정리하는 기술이 필요합니다. 물론 이는 반복 연습을 통해 익숙해질 수 있습니다.

그런데 이렇게 회의 내용을 실시간으로 정리 하다 보면 같은 내용을 그림으로 그려 놓으면 이를 텍스트로 설명할 때보다 더 잘 설명할 수 있을 것 같은 느낌을 받을 때가 있습니다. 하지만 회의는 내가 그림 그릴 동안 기다려 주지 않기 때문에 쉽게 그림을 그리기는 어렵습니다. 이전에는 아이패드에 재빨리 그림을 그리기도 했는데 이걸 나중에 회의록에 포함하려면 다시 그려야 할 때가 많았고 급하면 그냥 그 그림을 첨부하기도 했지만 별로 효과적이지 않았습니다. 그렇다고 회의 도중에 그림을 그리겠다고 마우스를 잡는 순간 이미 회의 진행을 따라가지 못하게 될 수 있고 내용을 놓치거나 의견을 놓칠 수 있습니다.

이 때 머메이드를 사용한다면 키보드에서 손이 떠나는 위험을 감수하지 않고서도 적당한 수준의 그림을 거의 시간을 들이지 않고 만들어낼 수 있습니다. 컨플루언스나 노션 같은 웹 도구에 회의 내용을 타이핑 하고 있다면 옆에 브라우저 하나를 더 열어 서로 옆에 두고 다른 한 쪽에는 머메이드 에디터를 띄워 두 브라우저 사이를 오가며 그림을 그릴 수 있습니다. 이야기가 진행되면 한 쪽 브라우저로 이동해 이야기를 정리하고 누군가 비슷한 이야기를 반복하거나 주제와 거리가 먼 이야기를 하기 시작하면 재빨리 다른 브라우저로 전환해 그림을 그리기를 반복할 수 있습니다. 이 때 갑자기 회의가 유효하게 진행되더라도 재빨리 브라우저를 전환하면 그만입니다. 마우스나 애플펜슬을 내려놓고 키보드로 돌아오는 시간을 낭비하지 않아도 됩니다.

이런 사용 사례를 주변 사람들에게 몇 번 보여주면 누구나 머메이드의 매력에 빠질 수밖에 없습니다. 테이블 반대쪽에서 보면 그저 랩탑 키보드를 두드리고 있을 뿐이지만 회의가 끝날 때 쯤 되면 회의록과 함께 서로 이야기하던 주요 내용을 포함한 다이어그램이 함께 완성되어 있습니다. 팀에도 이런 사용 사례를 직접 보여주며 영업했는데 이 참에 온라인에도 영업합니다. 머메이드 진짜 괜찮으니 다이어그램 그릴 일이 많다면 고려해보세요. 정말 괜찮고 편리하고 강력합니다.

소위 게임디자이너로 분류되는 직군의 사람들은 당연히 엔지니어 직군에 비해 기술적인 이해도가 떨어진다고 알려져 있습니다. 한편 게임디자이너들이 엔지니어 직군에 비해 가지는 강점은 의도를 스스로 정의하고 그 의도를 설명할 수 있는 것입니다. 이는 강점이나 특징이라기 보다는 게임디자이너의 의무이자 존재 이유라고도 말할 수 있습니다. 하지만 팀에서 주니어 디자이너들은 종종 스스로 의도를 만들어낼 만한 상황에 놓이지 않기 때문에 요구사항을 정의하더라도 요구사항의 목적과 의도를 제대로 이해하지 못해 개발을 진행 시키는데 어려움을 겪기도 합니다.

몇몇 온라인 게임 프로젝트에 참여하면서 자주 마주친 사례 중 하나는 초반에 서버에 저장할 정보와 클라이언트에 저장할 정보를 정의하는 것입니다. 한때 서버에 정보를 저장하는데 비용이 높아 플레이어의 성장과 인벤토리 상태를 제외하고는 도통 서버에 정보를 저장하기 어렵던 시대가 있었습니다. 이 시대에는 게임의 단축키 설정마저도 클라이언트에 기록해 다른 컴퓨터에서 게임을 실행하거나 PC방에서 좀 플레이 하려면 처음 한동안을 단축키 설정을 하며 시간을 낭비하기도 했습니다. 시간이 흘러 비정형 데이터를 저장하는 방법이 등장해 이전 시대에 비해 정보를 서버에 저장하는데 이전 시대만큼 반발을 겪지 않지만 여전히 이전 시대의 습관이 남아 어떤 정보를 서버에 기록해 사용하는 기계에 관계 없이 항상 같은 경험을 주려는 의도를 의심 받을 때가 있습니다. 이는 특히 온라인 게임의 구성에 대한 이해 수준이 아직 높지 않은 분들이 협업을 진행하는데 어려움을 겪게 만들기도 합니다.

어느 날 엔지니어로부터 ‘플레이어 캐릭터의 현재 위치를 서버에 저장해야 하나요?’라는 질문을 받았습니다. 이 질문의 의미는 플레이어는 계속해서 이동하는데 이동할 때마다 현재 위치를 서버에 저장할 필요가 있느냐는 것입니다. 또 한편으로는 플레이어가 접속을 종료했다가 다시 접속하면 어디서 게임을 다시 시작해야 하는지 알고싶다는 의도가 포함되어 있습니다. 하지만 엔지니어도 게임디자이너도 당장의 궁금함을 주고 받을 뿐 그 궁금함 너머의 정확한 의도를 주고 받는데 익숙하지 않으므로 이런 질문을 받은 게임디자이너를 당황 시킬 수 있습니다.

플레이어의 현재 위치를 서버에? 왜? 그냥 다른 사람들에게 실시간으로 동기화 되니 애초에 서버에 있는 정보 아닌가? 그걸 저장? 저장하는 것과 저장하지 않은 것 사이에 무슨 차이가 있지? 같은 질문을 머릿속에 떠올리며 ‘확인해본 다음 알려주겠다’고 답할 텐데 이 상황에 올바른 대응이기는 하지만 답변을 할 수 있었다면 장기적으로 협업 부서들 사이에 신뢰를 조금 올리는데 도움이 되었을 겁니다. 정확한 의도를 담아 질문을 주고 받으면 가장 좋지만 그건 꽤 고급 기술이니까 나중에 기회가 있을 때 이야기하기로 하고 여기서는 어떤 정보를 서버에 기록해야 할 지 말 지를 결정하는 요령을 설명하겠습니다.

온라인 멀티플레이 게임은 크게 두 가지 측면에서 정보 저장 여부를 검토해야 합니다. 첫째. 플레이어가 게임을 중단했다가 재시작 할 때 어디서 어떻게 시작할 것인지에 따라 다릅니다. 온라인 멀티플레이 게임은 플레이어가 게임에 접속해 있든 말든 어쨌든 게임 세계는 계속해서 움직이고 있습니다. 반면 플레이어는 24시간 365일 게임에 접속해 있지는 않기 때문에 게임에 재접속 할 때 어디서 어떻게 재시작 할 지 정의해야 합니다. 가령 종료한 그 자리에서 재시작 할 수 있습니다. 규칙 자체는 가장 단순하고 또 이해하기도 쉽습니다.

하지만 종료한 자리 근처에 선공 몬스터가 돌아다니고 있거나 PvP를 허용하는 지역이라면 규칙은 그리 단순하지 않을 수 있습니다. 클라이언트 로딩이 끝나기 전에 다른 플레이어나 몬스터에 의해 플레이어가 이미 죽어 있을 수도 있고 다른 플레이어의 전투 한 복판에 갑자기 나타날 수도 있습니다. 물론 이 상황 자체를 게임의 일부로 정의할 수도 있지만 그렇지 않다면 일시적으로 플레이어를 보호해 불리함을 줄이는 복잡한 규칙을 마련해야 합니다.

한편 종료한 자리에서 바로 재시작 하면 그 장소에 도달하기 위한 비용을 원활하게 부과할 수 없게 됩니다. 마을에서 어떤 사냥터까지 이동하는데 높은 비용을 요구하고 있다고 하면 그 사냥터에서 하는 플레이는 이 곳에 도달하는데 사용한 비용만큼의 효율을 얻을 수 있어야 합니다. 만약 누군가 그 사냥터에서 더 이상 마을에 돌아가지 않고 플레이를 지속할 수 있는 효율에 다다랐다면 이 플레이어는 이제부터 이 사냥터에 도달하기 위해 부과하던 비용을 더 이상 지출하지 않고 사냥터를 사용할 수 있게 됩니다. 그래서 종종 플레이 하던 레벨만 기록했다가 게임을 재시작 하면 레벨 입구로 돌려 보내거나 아예 마을로 돌려 보내 이동 비용을 다시 부과하기도 합니다.

둘째. 유저가 서로 다른 장치를 통해 게임에 접속할 때 서로 같은 경험을 줄 것인지 여부에 따라 다릅니다. 아주 먼 과거에는 유저 한 명이 게임을 실행할 수 있는 기계가 한 대 뿐인 경우가 많았습니다. PC 한 대, 콘솔 한 대 같은 식으로요. 하지만 PC방이 생기면서 유저 한 명이 두 대 이상의 기계를 통해 게임에 접근할 수 있게 되었습니다. 또 현대에는 PC와 모바일 기계를 각각 사용해 게임에 접속할 수 있기도 합니다. 그래서 서로 다른 기계를 통해 게임에 접근할 때 같은 경험을 줄 지 여부에 따라 서버에 기록할 정보가 달라집니다. 가령 기계마다 사양이 다르므로 그래픽 옵션을 서버에 기록할 필요는 없을 겁니다. 반면 단축키 설정이나 게임플레이 옵션은 기계가 달라지더라도 적어도 PC끼리는 같은 환경을 원할 가능성이 높으니 서버에 기록해 두면 PC방에 가서도 설정을 다시 조절하는데 시간을 쓸 필요 없이 바로 게임을 시작할 수 있을 겁니다.

정리하면 플레이어가 서버에 재접속 할 때 어떤 상태로 게임을 재시작 해야 하는지에 따라, 유저가 서로 다른 기계를 통해 게임에 접속할 때 얼마나 같은 경험을 하게 해 줄 지에 따라 서버에 기록할 정보가 달라질 수 있습니다. 가장 이상적인 상황은 엔지니어와 게임디자이너가 서로 질문을 주고 받을 때 질문의 의도를 명확히 하는 것이지만 실생활에서 그러기 어렵다면 이 두 가지 조건을 고려해 의도를 만들고 이에 따른 기술적인 의사결정을 할 수 있습니다.

몇몇 프로젝트에서 리드 시스템 디자인 역할을 해 왔는데 처음에는 이 역할을 잘 이해하지 못했습니다. 개인 기여자 역할을 할 때는 개발팀 안에서 적어도 시스템 디자인이나 문제해결 분야에서는 약하지 않은 역할을 해 왔다고 생각합니다. 그래서 리드 역할을 맡기 시작할 때는 이 역할이 개인 기여자 역할의 연장이라고 생각했습니다. 이전의 개인 기여자 역할에 추가로 함께 일하는 다른 개인 기여자 분들께 업무를 분배하고 또 진행 상황을 관찰하고 도움이 필요한 시점을 관찰해 적당한 때 개입해 일을 원활하게 진행 시키는 것을 주요 임무로 받아들였습니다.

하지만 시간이 흐르면서 리딩에 개인 기여자로서 역할 비중이 일정 수준 이상인 이상 이전보다 일을 못하는 개인 기여자일 뿐 리드 역할은 제대로 수행하고 있지 못하다는 사실을 깨달았습니다. 팀으로 일이 몰려들고 있었지만 뭐가 더 중요한지, 그렇지 않은지 파악하기도 어려웠고 또 우선순위를 결정하기도 어려웠습니다. 이는 제 스스로가 최소한 프로젝트 수준의 의도를 파악하지 못하고 있다는 의미입니다. 결과적으로 팀 구성원들은 항상 높은 업무 강도에 시달려야만 했고 그렇다고 팀 밖으로부터 좋은 평가를 받지도 못했습니다. 뭔가 돌파구가 필요했고 결국 개인 기여자 입장의 업무를 더 많이, 아주 많이 줄이기에 이릅니다.

몇 년 전부터는 모든 구성원들이 중요한 일을 담당하고 있어 더 이상 할당할 사람이 없거나 빨리 처리할 수 있는 작은 일을 스스로에게 할당하고 프로젝트에 있어 중요하고 복잡한 일은 최대한 직접 담당하지 않으려고 노력하고 있습니다. 팀을 리딩하기 위해 직접적인 업무를 수행하는 것 보다 중요한 것은 팀으로 밀려 들어오는 일의 우선순위를 파악해 일의 동시성을 줄이는 것입니다. 모든 일은 하나하나가 당장 처리해야 할 것처럼 몰려들지만 실제로는 전혀 그렇지 않습니다.

적어도 프로젝트 수준, 혹은 회사나 시장 수준에서 바라보면 이들 중 정말로 중요한 일과 그렇지 않은 일을 어느 정도는 구분할 수 있는데 이 구분에 따라 한정된 자원 안에서 일을 순서에 따라 진행할 수 있습니다. 다만 이러기 위해서 직접적인 업무 이전에 밀려드는 업무를 파악하고 프로젝트나 회사 수준의 목표에 더 가까운 일과 그렇지 않은 일을 구분하고 이 구분을 팀 안팎에 공유해 동의를 얻는데 집중해야 합니다.

또 구성원들이 일하는 과정을 관찰하며 내가 알고 있는 삽질을 시도하려고 할 때 이를 막거나 막지 않는 결정을 해야 합니다. 프로젝트 관점에서는 예상되는 삽질을 막아야 합니다. 개발 비용을 절약할 수 있습니다. 하지만 팀이나 구성원 개인 관점에서는 직접 삽질을 해야만 얻을 수 있는 경험이 있다고 생각합니다. 만약 팀이나 프로젝트 차원에서 이 비용을 감당할 수 있다면, 또한 그만한 의미가 있는 삽질이라고 생각한다면 고의로 개입하지 않고 삽질이 일어나게 두기도 합니다. 이런 결정은 팀이 경험할 일과 경험하지 않을 일을 어느 정도 결정하는 일로 팀 전체의 성장에 관여한다고 생각합니다. 이런 결정을 위해서 스스로가 개인 기여자로써 업무와 어느 정도는 거리를 두고 팀과 프로젝트와 회사와 시장을 관찰해야 했습니다.

최근에 팀에 참여하신 분야가 다른 주니어님께 할당할 일을 선택해야 했는데 그 쪽 부서로부터 받은 의견은 자잘한 업무부터 시작하면 좋을 것 같다는 것입니다. 제 관점에서는 좋은 방법이 아니라고 생각합니다. 물론 아주 작고 간단한 일부터 시작해 요령과 시야를 서서히 키워 가는 것도 틀린 방법이 아닙니다. 하지만 감당할 수 있는 범위 안에서는 더 중요하고 더 큰 일을 할당해 시작부터 좀 더 큰 목표에 도전하고 더 큰 어려움을 겪으며 한번에 더 많이 성장할 수 있다고 생각합니다. 이를 감당할 만 할 거라고 예상하니까 함께 일하기로 결정한 것이기도 하고요. 그래서 가장 작은 일보다는 좀 더 복잡하고 중요한 일을 할당하고 나는 원래 주니어님께 드릴 만한 일처럼 보이는 더 작은 일을 담당하기로 했습니다.

지라를 영문 버전 그대로 사용해 보면 태스크 이름에 해당하는 말이 ‘Summary’임을 할 수 있습니다. 한국어 버전에서는 ‘요약’이라고 나타나는데 영문 의미와 다르지 않습니다. 이 이름을 곧이곧대로 받아들이면 작업 내용의 ‘요약’을 입력하는 곳이라고 할 수 있습니다.

종종 프로젝트 전체에서 태스크 이름을 정하는 모습을 관찰해 보면 이 필드 이름이 ‘요약’임을 잘 인식하지 않는 것 같은 모습이 눈에 띕니다. 작업에 관련된 사람들끼리 작업 이름을 줄여 부르는 말을 그대로 요약에 사용해 다른 사람들은 이 작업 내용과 목표를 쉽게 이해할 수 없기도 합니다. 일단 지라에서 흔히 ‘제목’이라고 인식하는 그 칸은 작업의 요약을 기입하는 곳입니다. 요약은 말 그대로 작업 내용을 짧게 줄인 것입니다. 그래서 요약은 프로젝트 구성원들 누구나 요약을 읽고 이 작업의 목표와 작업이 완료되었을 때 일어날 일을 상상할 수 있는 모양이어야 합니다.

가령 현 시점에 더 이상 유효하지 않은 지라 태스크를 정리하는 작업이 있다고 해 봅시다. 간단히 요약에 ‘지라 태스크 정리’라고 쓸 수도 있습니다. 하지만 이 요약을 요약이라는 관점, 작업의 목표를 파악할 수 있어야 한다는 요구사항, 그리고 작업이 완료되었을 때 일어날 일을 상상할 수 있는 모양이어야 한다는 점을 감안해 다시 읽어보면 그리 좋은 요약이 아니라는 것을 알 수 있습니다. 일단 태스크 정리가 뭘 하는 것인지 알 수 없습니다. 정리는 태스크 요약이나 설명을 수정하겠다는 이야기인지 유효하지 않은 태스크를 삭제하거나 아카이빙 하겠다는 이야기인지 아니면 마감 날짜나 마일스톤을 수정하겠다는 이야기인지 알 수가 없습니다.

또 무엇을 위한 정리인지도 알 수 없습니다. 새 마일스톤 계획을 수립하기 위해 유효한 태스크만 남기겠다는 이야기인지 또 정리의 기준을 알 수도 없습니다. 이 요약은 ‘마일스톤 2에 완료되지 않은 태스크 중 향후 6개월 안에 진행할 가능성이 없는 태스크 아카이빙’처럼 조금 길지만 더 구체적으로 작성하는 것이 좋습니다. 일단 어떤 태스크가 해당되는지 이해할 수 있고 태스크가 어떻게 되는지 알 수도 있으며 태스크를 선정할 판단 기준도 대략이나마 파악할 수 있게 됩니다.

한번은 ‘A기능에 B기능 연동’과 ‘C기능 리뉴얼’이라는 태스크 요약을 보고 마음이 아주 불편했습니다. 직접 담당하는 일이 아니어서 뭐라고 말하기 난감한 입장이어서 더더욱 불편했습니다. 일단 ‘A기능에 B기능 연동’은 위에서 설명한 관점에 의하면 일단 두 기능이 연동된다는 말의 의미를 알 수 없습니다. 물론 이 작업에 직접 관여하는 사람들은 의미를 이해할 겁니다. 하지만 프로젝트 구성원 모두에게 그 수준의 이해도를 요구할 수 없습니다. 또한 이 태스크의 연동 작업이 완료되면 제품이 어떤 모습이 되는지, 또 제품에 어떤 기능이 추가되는지도 전혀 알 수 없었습니다.

이 요약은 ‘A 웹사이트에 B 방법을 사용해 로그인’과 비슷한 모양으로 고치는 것이 좋습니다. 이제 이 작업이 완료되면 어떤 제품에 무슨 기능을 사용할 수 있게 되는지 알 수 있게 되었습니다. 이제 ‘연동’은 이 작업을 설명하는데 사용하거나 이 작업의 하위 작업 중 하나가 될 수는 있을 겁니다.

‘C 기능 리뉴얼’ 역시 같은 관점으로 볼 때 좋은 요약이 아닙니다. 리뉴얼이 일어난 C 기능이 어떤 모습이 될 지, 왜 이 작업을 해야 하는지 알 수가 없습니다. 또 리뉴얼이라는 말 자체가 아무런 의미가 없습니다. 이 요약은 ‘인게임의 C 기능 UI에 신규 UI 테마 적용’과 비슷한 형태로 수정해야 합니다. 일단 어디에 무슨 일이 일어나는지 알 수 있게 됐고 UI가 바뀌는 작업이니 담당자나 작업 규모를 대략이나마 예상할 수 있습니다. 또 이 작업의 목적과 이유 역시 예상할 수 있고요. 지난 주에 인게임 UI 테마를 모두 교체하기로 결정해 시안이 나와 있다는 사실을 알고 있으니 그 시안을 적용하는 업무일 겁니다. 리뉴얼은 업무 규모나 범위, 목적을 파악할 수 없었지만 이제는 이들 모두를 예상할 수 있게 되었습니다.

결론. 흔히 태스크 이름이라고 생각하는 필드의 정확한 역할은 ‘요약’으로 작업 내용을 요약하는 필드입니다. 작업을 추상적으로 표현하거나 작업자들이 줄여 부르는 말로 표현하는 곳이 아닙니다. 요약을 통해 작업의 목적, 작업이 완료된 후에 제품의 변화를 파악할 수 있으면 좋습니다. 요약을 통해 작업 내용을 예상하거나 상상할 수 없다면 뭔가 잘못 된 신호로 인식해야 합니다.

한동안 구현 비용이 낮고 1인칭 게임에 잘 어울리며 유저에게 강한 인상을 주는 게임 규칙을 조사한 적이 있습니다. 1인칭 게임은 특히 전 세계의 온갖 사람들이 연구해 별의 별 희한한 게임 규칙이 많지만 그 중에 인상 깊었던 것은 개리모드의 넥스트못 붕 하나인 셀레네 델가도 또는 오붕가입니다. 게임 모드라고 부르기에는 내비게이션이 있는 아무 레벨에나 스폰 시켜 놀 수 있지만 이 넥스트봇의 존재 자체가 플레이 스타일을 강제하기 때문에 게임 모드로 인식하고 있습니다. 처음 이 게임 모드를 알게 된 것은 우연히 이 영상을 봤기 때문입니다. (주의: 무서울 수 있음!)

딱히 대단한 기능이 있는 것은 아니지만 플레이어가 이 얼굴에 닿으면 바로 죽습니다. 개리모드에는 메타 플레이가 없어 죽어도 딱히 손해 볼 것은 없지만 게임 상에서 플레이어가 죽는 상황을 피하기로 약속하고 이 규칙을 받아들이면 닿을 때 죽는다는 단순한 규칙이 게임 전체를 이끌게 됩니다.

이 얼굴은 플레이어를 직선 상에서 발견하면 플레이어를 향해 이동해 오는데 아무 움직임 없이 그저 가까워지는 이동 방법 자체가 무서운 느낌을 줍니다. 또 다가오면서 이 넥스트봇이 만들어지게 된 일종의 괴담인 셀레네 델가도라는 사람의 실종 정보를 말하는 소리와 함께 다가오는데 한국어 청자 입장에서 알아들을 수 없는 말을 반복하며 웅얼 거리는 소리 역시 유쾌한 느낌을 주지는 않습니다.

결정적으로 이 얼굴은 레벨에 일단 스폰 시켜 놓으면 계속해서 플레이어를 쫓아오며 게임을 그만 두기 전까지 끝나지 않습니다. 이런 규칙들로 인해 처음 영상을 보고 무척 당황스러웠고 개리모드에 넥스트봇을 떨궈 놓고 맵을 뛰어다니기 시작하고 나서야 이 단순한 규칙이 이렇게 무서울 수 있다는 사실을 체험했습니다.

한편 인터넷 상의 사람들은 이 셀레네 델가도보다는 비슷한 규칙으로 동작하는 오방가를 더 즐겨 플레이 하는 것처럼 보였습니다. 한쪽은 사람 이름이고 다른 한쪽은 대상을 정확히 지칭하는 단어여서 직접 비교하긴 좀 그렇지만 구글 트렌드에 넣어 보면 현재에 가까워질수록 오방가에 대한 검색이 더 많습니다. 플레이 영상을 찾아봐도 오방가 쪽이 압도적으로 많고요. 처음 접한 것이 셀레네 델가도 였기 때문에 왜 사람들이 좀 덜 무섭게 생긴 오방가를 더 즐겨 플레이할지 궁금했습니다. 기왕 무서운 얼굴이 쫓아오는 플레이를 할 작정이라면 더 무섭게 생긴 셀레네 델가도가 쫓아오는 편이 더 신날 텐데 말입니다.

그러다가 유저들의 리액션이 포함된 영상을 보면서 몇 가지 가정을 해봤습니다. 일단 오방가는 영어 화자 입장에서 셀레네 델가도와 비교해 아주 유명한 사람을 패러디 한 것입니다. 명백히 접근성이 높습니다. 또 계속해서 소리를 내는 셀레네 델가도에 비교해 오방가는 소리를 내지 않습니다. 계속해서 플레이를 반복해 보면 셀레네 델가도가 내는 소리는 처음에는 무섭지만 나중에는 짜증납니다. 반면 오방가는 아무 소리도 내지 않아 방심하고 있다가 순식간에 뒤에서 다가와 플레이어들을 한방에 다 죽이기도 합니다. 그래서 반복해서 플레이할 때는 오방가 쪽이 오히려 더 무서웠습니다.

셀레네 델가도가 플레이어를 뚫려 있는 직선 상에서 발견하면 바로 따라오는데 비해 오방가는 플레이어를 발견하더라도 거리가 멀다면 바로 다가오지 않고 플레이어가 보이지 않는 위치로 이동해 기다립니다. 이 동작은 플레이어들이 오방가가 어디 있는지 찾아 나서도록 만들고 안전하게 숨어 있는 상황을 스스로 깨뜨리게 만듭니다. 그 후 소리 없이 나타나기 때문에 반복 플레이 상황에서 훨씬 재미있게 느낄 수 있습니다.

또 오방가는 꽤 높이까지 점프할 수 있고 느슨한 물리 판정 덕분에 원래는 올라갈 수 없는 곳에 종종 올라갑니다. 그래서 높은 곳에서 방심한 플레이어들을 당황하게 만들 수 있습니다. 점프 뿐 아니라 게임 상에 주로 사용하는 좁은 복도보다 약간 더 큰 크기 때문에 어설프게 도망치다가는 예상 밖의 장소에서 스쳐 죽을 수 있어 이 특징을 파악하고 나면 오방가가 등 뒤에 아주 가까이 따라오는 상황이 훨씬 더 무섭게 느껴질 겁니다.

결론. 오방가와 셀레네 델가도는 서로 비슷한 메커닉이지만 인터넷 상에서는 오방가가 더 인기있는 것 같은데 일단 소리가 없고 플레이어와 거리가 멀어지면 아예 플레이어가 보이지 않는 위치로 이동하며 느슨한 물리 판정이 우연한 동작을 만들고 아주 유명한 사람의 패러디라는 점 때문인 것 같습니다. 이 모드를 눈여겨 본 이유는 1인칭 또는 3인칭 게임을 만들 때 가장 간단한 모양을 개발해 테스트 하는 사람들에게 강한 인상을 남길 방법을 찾으려 했기 때문이었는데 이 조사를 실제 개발에 사용할 일이 일어나지는 않았습니다. 하지만 미래에 기회가 되면 비슷한 모드를 게임에 넣어 볼 작정입니다.

애플 오토메이션 사례 모음에서 오토메이션 공용환경 소개를 하면서 글로벌 변수를 저장할 수 있더라도 네임스페이스 개념이 없어서 서로 다른 여러 숏컷에서 사용하는 변수가 한 곳에 섞여 있으면 찾기 어렵다는 이야기를 했습니다. 그래서 텍스트 타입 변수에 숏컷 하나에서 사용하는 글로벌 변수를 JSON 모양으로 만들어 읽고 쓰는 딕셔너리 읽고쓰기 숏컷을 만들어 사용했는데 알고 보니 Toolbox Pro for Shortcuts 앱에서 처음부터 글로벌 변수를 JSON 모양으로 읽고 쓰는 기능을 지원하고 있었습니다. 다음부터 당연히 있을 법한 뭔가를 만들어야 할 때는 당연히 그 기능이 있을 거라는 가정을 하고 한번 더 찾아봐야겠다는 교훈을 얻었습니다.

그런데 이 JSON 읽고 쓰는 기능을 사용하다 보니 개행문자가 들어간 JSON을 제대로 처리하지 못하는 것 같습니다. 값에 개행문자가 들어 있으면 JSON 전체를 텍스트로 판정해 읽어올 수가 없었습니다. 전에 만들어 놨던 딕셔너리 읽고쓰기 숏컷을 다시 사용할지 잠깐 고민했지만 당연히 Toolbox Pro for Shortcuts 앱 기능이 훨씬 속도가 빨랐고 개행문자가 들어갈 상황을 회피해 가며 사용하기로 합니다. 아이디어는 JSON을 쓰기 전에 개행문자를 검사해 <br /> 모양으로 바꿔 기록했다가 읽어올 때 다시 개행문자로 바꿔 표시하는 겁니다. 그런데 리스트 타입을 개행문자를 포함한 텍스트로 바꾸려고 보니 뭔가 예상대로 동작하지 않았습니다.

그래프	결과	설명
		출력 변수에 줄바꿈이 없는 텍스트가 들어가기를 원합니다.
		이 List에 있는 각 항목을 위 출력에 한 줄로 넣고 싶습니다.
		List의 각 항목마다 순회하며 출력에 텍스트를 합쳤습니다.
		위 반복이 끝난 다음 찍어봤습니다. 의도하지 않은 줄바꿈이 들어가 있는 상로 보입니다.
		줄바꿈 문자를 바꾸려고 시도해봤습니다. \n 문자를 매칭했는데 이게 아닌 모양입니다

의도는 리스트를 읽어 반복하며 출력 변수에 리스트의 각 요소를 합쳐 한 줄 짜리 텍스트로 만드는 겁니다. 하지만 출력 변수를 찍어 보니 의도하지 않은 개행문자가 들어 있는 것처럼 보였습니다. 그래서 개행문자를 찾아 바꿔 봤는데 여전히 동작하지 않는 것 같습니다. 이 상태로 JSON에 넣으면 오동작 하는 상황이어서 저 의도하지 않은 개행문자를 없앨 방법을 찾아야 했습니다.

그래프	결과	설명
		위 문제 상황과 똑같이 시작합니다.
		리스트 아이템을 반복하는 동안 Combine Text를 해도 결과가 원하는 텍스트 형식이 아니라 리스트 형식인 것 같아 빼버렸습니다. 빼도 결과는 같았습니다.
		텍스트 형식으로 합쳐지기를 원하지만 이건 텍스트 형식이 아니라 여전히 리스트 형식인 것 같습니다.
		리스트를 Cobine Text로 다시 합쳐봤더니 원하는 모양으로 합쳐졌습니다.

알고 보니 리스트 타입 변수의 각 요소를 순회하며 값을 읽어 이들을 다른 변수에 합치면 합쳐진 결과 역시 여전히 리스트 타입인 것 같았습니다. 출력 변수를 찍을 때 의도하지 않은 개행문자가 들어간 것처럼 보이는 이유는 이게 개행문자가 아니라 리스트 타입 변수를 화면에 찍으려 하자 리스트 각 구성요소를 출력할 때 개행문자로 구분한 것이기 때문입니다. 그래서 여전히 리스트 타입인 것으로 예상되는 출력 변수를 개행문자로 구분해 합쳐서 찍어 보니 이번에는 텍스트 타입으로 바뀌어 있었습니다.

그래프	결과	설명
		반복할 것 없이 그냥 리스트를 Cobine Text에 넣었다 빼면 텍스트 형식으로 바뀌어 문자열 매칭을 할 수 있었습니다.

결국 리스트 각 구성요소를 순회할 필요도 없이 처음부터 Combine 노드를 사용해 리스트의 각 구성요소를 합치면 텍스트 타입이 되고 이 상태에서 개행문자를 치환하면 의도한 대로 동작합니다.

결론. 리스트 구성요소를 순회하며 값을 읽어 이들을 연결해도 연결한 결과가 여전히 리스트 타입이기 때문에 여기에 문자열 치환을 하려 해도 예상대로 동작하지 않습니다. 값을 찍어 보면 개행문자를 포함한 것처럼 보이지만 실은 리스트 타입을 화면에 표시할 때 개행문자를 포함해 표시할 뿐입니다. 문자열 치환을 하고 싶으면 리스트 타입에 Combine 노드를 사용해 타입을 바꾼 다음에 해야 합니다.

게임을 플레이 하다 보면 같거나 거의 같은 메커닉이 대칭으로 설치되어 있는 것을 가끔 볼 수 있습니다. 문 하나를 여는 스위치가 문 양쪽에 하나 씩 놓여 있거나 스위치 두 개가 동시에 켜져 있어야 문이 열리거나 다음으로 진행하기 위해 양쪽에 있는 발판에 올라가 있어야 하는 식입니다. 대칭으로 설계된 메커닉은 레벨디자인 상의 균형을 맞추기 위해, 두 번째 스위치를 찾기 위해 방 안을 조금 더 둘러보도록 만들기 위해, 또 멀티플레이 환경에서 둘 이상의 플레이어가 각자 적절한 동작을 하도록 유도하는 일종의 퍼즐 요소로써 사용됩니다.

최근에 플레이 한 스팀 버전 갓오브워 초반에 레벨 전체의 큰 테마가 좌우 대칭으로 만들어진 레벨이 등장합니다. 이 레벨은 호수를 가운데 두고 주요 장소가 양쪽에 거의 대칭에 가깝게 배치되어 있습니다. 호수 중앙에는 퍼즐이 놓여 있고 호수 주변 전체를 탐험하며 퍼즐을 풀어야 합니다. 퍼즐의 결정적인 힌트는 특정 장소에 좌우 대칭으로 배치된 스위치를 각각 작동 시키면 나타나는데 실은 이런 기믹은 상호작용을 한 번만 해도 전체 힌트를 볼 수 있게 만들어도 됩니다. 이 기믹을 스위치 두 개로 나눈 이유는 레벨디자인 상의 균형을 맞추기 위한 것으로 예상합니다.

멀티플레이 환경에서 문 하나를 열기 위해 스위치 두 개를 대칭으로 배치해 놓기도 하는데 이는 두 가지 상황에 대응할 수 있습니다. 스위치 두 개 모두를 작동 시켜야 문을 열 수 있는데 만약 이 스위치 두 개를 동시에 동작시켜야 한다면 이 기믹은 명백이 둘 이상의 플레이어가 함께 플레이 할 것을 요구합니다. 핵미사일 발사 메커닉에 두 사람이 동시에 열쇠를 돌릴 것을 요구하는 것과 비슷합니다. 그런데 이 기믹에 항상 플레이어 두 명 이상이 도달할 것을 확신할 수 없다면 스위치 각각을 따로 조작하더라도 둘 다 조작되기만 하면 문이 열리도록 설정할 수도 있습니다. 둘 이상의 플레이어가 이 기믹에 도달한다면 조금 더 빨리, 조금 더 편하게 문을 열 수 있고 혼자 도달했다 하더라도 스위치 각각을 차례로 조작해 문을 열 수 있습니다.

개인적으로는 명확히 플레이어 두 명 이상이 제한된 시간 안에 조작하기를 의도한 기믹이 아니라면 굳이 대칭으로 조작해야 할 기믹을 설치할 필요는 없다고 생각합니다. 한 번만 해도 상관 없는 같은 조작을 두 번 시켜서 얻을 이득이 없습니다. 그저 레벨디자인을 테스트 할 때 같은 동작을 테스트하는 수고가 늘 뿐입니다. 만약 싱글플레이 환경에서 대칭 기믹을 사용해야 한다면 양쪽에서 서로 다른 정보를 얻거나 양쪽에서 서로 다른 보상을 받도록 하는 정도의 수고는 해야 한다고 생각합니다.

한번은 글 쓸 거리가 너무 없어 칭얼거리다가 이대로 가다가는 주말에 글 쓸 거리가 완전히 떨어지겠다는위기감이 들어 글로 보고 싶은 주제가 있으면 알려 달라고 요청한 적이 있습니다. 그 때 받은 주제 중 디지털 쓰레기에 대해서 썼는데 다만 지금 다시 보니 같은 주제로 한번 더 생각해서 이야기를 다시 쓰면 좋겠다 싶습니다. 오늘은 다른 한 가지 주제인 ‘OTT의 시대지만 우리는 여전히 영화관에 간다’를 제목으로 생각해 보려고 합니다.

이 약자가 무엇을 의미하는지는 알지만 정확히 무슨 약자인지는 몰라 검색했습니다. 셋탑박스를 탑이라고 줄여 불렀기 때문에 셋탑박스보다 더 나은 뭔가를 의미하기 위해 지금의 약자가 된 모양입니다. 뭔가를 뛰어넘는다는 의미로 ‘Over'를 사용한 것을 보니 어떻게 봐도 ‘영국 석유’지만 다른 약자라고 주장하는 회사 BP가 생각납니다. 어쨌든 방송사가 원하는 컨텐츠를 보내주는 이전 시대의 시청 장치와 비교해 사용자가 원하는 컨텐츠를 보내주는 장치나 서비스를 말하는 것 같습니다.

이 서비스 덕분에 이전 시대와 달리 영화관에 훨씬 덜 가게 됐습니다. 이전 시대에는 그나마 영화관에 지금보다는 더 자주 갔지만 코비드 시대를 지나가면서 영화관에 거의 가지 않게 됐습니다. 실은 마스크를 쓰고 말 없이 가만히 앉아 앞을 보기만 하는 영화관 환경은 바이러스 전파가 잘 일어나지 않는다고 합니다. 하지만 코비드 시대 초기에 워낙 강력한 제한 정책을 시행하며 한 번 바뀐 습관은 다시 원래대로 잘 돌아오지 않습니다.

한편 이전 시대에 영화관에서 느끼던 불편한 점들을 다시 한 번 떠올린 계기가 되기도 했습니다. 분명 영화관에서는 집에서 같은 영상을 볼 때와 비교해 다른 경험을 할 수 있기는 합니다. 가령 내가 웃거나 우는 장면에서 다른 사람들이 보이는 비슷한 반응을 보며 동질감을 느끼고 또 몇 시간에 걸쳐 아무 말 없이 온전히 화면과 소리, 때로는 감각에 집중하는 시간을 보낼 수 있습니다. 하지만 주변에서 사람들이 부스럭거리는 소리, 영화관에서조차 대화를 이어가고 또 채팅을 하는 밝은 불빛에 눈 앞에 어두운 반점이 생기기도 하고 또 누군가는 전화 통화를 하고 또 다른 누군가는 20분에 한번 씩 밖에 나갔다 오기도 하는 등 온전히 영상과 소리에 집중하기 쉽지 않은 환경이기도 합니다.

집에서 영화를 보기 시작하자 좋은 경험과 별로 좋지 않은 경험 모두를 할 수 없게 됐지만 한편으로는 집에서 영화를 보기 때문에 할 수 있는 경험이 생겼습니다. 영화관에서는 두 시간 내내 온전히 집중하며 그 시간 동안 집중을 유지하지 못하는 사람들로부터 방해를 받았지만 이번에는 내 스스로가 영화를 보며 드는 생각과 감정을 그 자리에서 타임라인에 토해내고 사람들로부터 공감을 받았습니다. 다른 사람들과 함께 영화를 보며 함께 울고 웃는 경험과는 달랐지만 여전히 사람들과 감정을 공유하며 영화를 볼 수 있었습니다.

또 내 필요에 따라 재생을 잠깐 멈추고 화장실에 다녀오거나 물을 마실 수도 있었습니다. 물 마실 때 달그락거리는 소리가 날까봐 조심해서 마시는 대신 그냥 멈춰 놓고 편안히 물 마시고 돌아와 이어서 영화를 볼 수 있게 됐습니다. 어떻게 보면 더 이상 영화관에서처럼 집중하지 않게 됐지만 다른 한편으로는 이렇게 영화를 보는 경험도 그리 나쁘지 않았습니다.

하지만 이렇게 해서 영화관에 완전히 안 가게 됐나 하면 그렇지는 않습니다. 이전 시대에 비해서는 훨씬 적지만 어쩌다 영화관에 갑니다. 먼저 감정을 공유할 수 있기는 하지만 그 영화를 동시에 함께 보는 사람들과 비언어적인 방법으로 나누는 것과는 다릅니다. 이번에 유튜브를 통해 헤어질 결심을 보며 온갖 감정을 느꼈는데 그 감정을 타임라인에 토해냈지만 뭔가 그것 만으로는 부족했습니다. 만약 영화관에서 다른 사람들과 이 영화를 봤다면 분명 거기서만 느낄 수 있을 감정이 있었을 겁니다.

또 온갖 요소들로부터 쉴 새 없이 방해를 받는 상황에서 시작부터 끝까지 제작자가 의도한 온전한 경험을 얻으려면 여전히 영화관에 가야 합니다. 영화관에서 영화를 보는 경험이 제작자의 의도와 가깝다기보다는 현대에 영화 시작부터 끝까지 온전한 감정의 변화를 시간에 맞춰 느끼기 위해서는 영화관처럼 방해 요소들로부터 어느 정도 통제된 환경이 필요합니다. 그런 환경을 집에 구축할 수 없지는 않을 겁니다. 하지만 영화관이 이런 통제에 명백히 더 유리하다고 생각합니다.

결론. 온갖 서비스를 통해 원하는 영화를 어렵지 않게 볼 수 있고 이전 시대에 비해 온갖 장점이 있으며 영화를 보는 습관이 완전히 바뀌었습니다. 하지만 여전히 영화관에서만 느낄 수 있는 통제된 경험이 있어 이를 기대하며 영화관에 갑니다. 만약 어느 순간 집에서 이런 통제된 환경과 감정을 공유할 방법이 생긴다면 어쩌면 그때는 정말로 영화관에 가지 않을 지도 모르겠습니다.