1

Intro

2019-08-10 작성한 노트에서 발췌

우리가 사는 도시는 더 이상 건물들과 길들, 구성원들 사이에서 입에서 입으로 전해지는 이야기들, 물리적으로 존재하는, 그래서 만지고 보고 들을 수 있는 사물들만으로는 설명할 수 없는 곳이 되었다. 끊임없이 새로 생겨나고 사라지는 거리의 상점들, 갑자기 모이는 사람들과 그곳에서 열리는 행사들, 아는 이가 아무도 없는 곳으로의 계획된 여행. 물리적인 도시가 형체 없는 정보로 바뀌고, 정보들이 모인 곳에 사람들이 모인다.

정보의 저장, 흐름이 사람들을 모은다면, 이렇게 생겨난 공간들 또한 도시를 이룬다고 볼 수 있지 않을까? 도시의 구성원들은 수많은 웹사이트들, 게임들에 접속한다. 이 공간들은 물리적인 도시들과는 다른 규칙들을 따를지도 모르겠으나, 사람과 사람, 혹은 사람과 공간을 이루는 요소들 사이에 상호작용이 이루어질 수 있다는 점에서, 그리고 그 공간에 머무는 시간 동안 어떤 종류의 경험이 이루어질 수 있다는 점에서 도시를 연장한다고 볼 수 있겠다. 그렇다면, 우리가 사는 도시는 서로 다른 규칙들로 이루어진 도시 조각들의 연결로 이루어졌다고 말할 수 있지 않을까?

우리가 거닐고 있는 도시는 도시의 정보가 모여있는 새로운 공간의 개수 만큼의 다른 겹을 가지고 있다. 혹은, 우리가 스크롤을 내리며 눈으로 훑는 도시들 중에 어떤 도시는 실제로 거닐 수 있는 공간을 가지고 있다.

도시, 게임.

2019-08-05 작성한 노트에서 발췌

도시에서의 경험은 도시를 방문하는 사람들이 이해할 수 있는 언어(음성이나 문자 언어든, 공간 언어든, 도시를 이해할때 사용하는 모든 언어를 말한다)의 폭, 그리고 도시에 대해 알고 있는 정보를 기반으로 이루어진다. 비슷한 구도로, 게임에서의 경험은 플레이어들이 게임 내에서 받아들이고 이해할 수 있는 정보의 폭, 그리고 플레이어들이 이미 알고 있는 정보들을 기반으로 이루어진다.

우리가 직접 도시 속을 돌아다니면서 경험하는 것을 도시 경험이라 하자. 게임에서도 도시 경험을 이야기할 수 있을까? 게임에도 플레이어가 머무는 필드들이 있고, 플레이어는 키보드나 컨트롤러를 조작해서 필드 사이를 돌아다닐 수 있다. 게임과 실제 세계 사이에 차이가 있다면, 게임 플레이를 위해서는 게임사에서 운영 중인 서버와 플레이를 위해 사용하는 기기가 게임과 플레이어 사이를 추가로 매개해주어야 한다는 점이 있겠다. 플레이어가 받아들이는 정보의 폭은 전적으로 게임 클라이언트에 달려있다. 구체적으로는, 게임 서버에서 전송받은 정보를 해석하기 위해 게임 클라이언트가 들고 있는 규칙 해석 방법에 달려있다. 플레이어들이 알고 있는 정보는 게임을 설치하면서 기기(혹은, 로컬)에 다운로드한 정보를 기반으로 한다.

게임 내에 신규 코스튬이 업데이트된 상황을 상상해보자. 플레이어들은 게임 업데이트를 통해 코스튬의 정보를 로컬에 새로 내려받는다. 게임 플레이 중 신규 코스튬을 입은 플레이어를 만나면 서버는 상대 플레이어가 입고 있는 코스튬 종류에 대한 정보를 클라이언트에 보내고, 클라이언트는 이를 해석해서 로컬에 있는 정보 중 신규 코스튬에 해당하는 정보를 상대 플레이어에 입혀서 화면에 보여준다. 만일 업데이트를 받지 않은 플레이어가 있다면 무슨 일이 생길까? 서버는 신규 코스튬 정보를, 예를 들어 클라이언트에 저장된 33번째 옷을 화면에 띄우라는 정보를 보냈는데, 업데이트 누락으로 클라이언트에는 32번째 옷 정보까지만 존재한다면, 클라이언트는 서버의 정보를 해석하는 도중 오류를 발생시킬 것이다.

게임마다 작동 방식이 다를 수 있고, 그렇기 때문에 신규 코스튬을 화면에 보여주는 과정이 다를 수 있다. 앞선 예시처럼 오류가 발생한 상황에서 이 오류에 대한 처리 방식도 서로 다를 것이다. 어떤 게임은 업데이트를 받지 않으면 게임 실행을 하지 못하게 막을 것이고, 어떤 게임에서는 알 수 없는 옷을 보여줘야 하는 상황에서는 기본 옷을 보여주도록 할 것이다. 만일 이 오류를 신경써서 대비해두지 않았다면 신규 코스튬을 입은 유저를 만나자마자 게임이 다운되어 버릴 수도 있다. 서로 다른 게임은 서로 다른 도시를 이룬다. 게임의 작동 방식은 도시의 기반을 이루는 규칙과도 같다.

도시를 게임으로 보자면 주어진 신체가 클라이언트, 도시가 서버, 신체의 감각기관이 서버로부터 정보를 받아들이는 기능을 수행하는 것으로 생각해볼 수 있지 않을까? 그렇다면, 우리 몸의 업데이트는 어떤 식으로 이루어지며, 우리가 미리 들고 있는 정보는 어떻게 관리되는 걸까?

공간, 번역.

2019-08-08 작성한 노트에서 발췌

돌아다니며 머물렀던 공간들을 각각 하나의 방이라고 상상해보자. 그리고 방 사이를 오가는 데에 걸리는 시간이 대중교통, 보행을 통해 걸리는 시간이라고 상상해보자. 그렇다면 도시에서 방문한 공간들을 여러 방들이 엮여있는, 하나의 집으로 볼 수 있을 것이다. 공간 안에 동선을 설정해두고 동선 위를 움직이는 사람이 겪는 매 순간의 경험들을 시간에 따라 길게 펴서 나열하면 시간 축을 깊이로 하는 기다란 선형 공간을 만들 수 있다. 몸을 1과 3/4바퀴만큼 돌려야 원래 보이던 풍경을 볼 수 있던 꿈을 꾸었다면 꿈에서의 각도를 현실 공간의 어떤 개념에 맵핑시킬 방법을 정해서 두 공간을 같은 언어로 이야기하는 것도 가능할 것이다.

같은 공간도 바라보는 주체에 따라 다르게 받아들일 수 있다. 자전거를 타고 이동하는 사람들과 자동차를 타고 이동하는 사람들은 속도 차이로 인해 도시를 다르게 이해한다고 한다. 사람들과 고양이들은 도시 내에서 움직여 다닐 수 있는 공간이 다를 테니 도시 공간의 연결관계를 다르게 이해할 것이고, 뛰어난 후각을 가진 개들은 공간에 후각 정보를 맵핑하여 이해할 것이다.

하나의 주체도 같은 공간을 여러 관점으로 바라볼 수 있다. 처음 가보는 맛집에 방문한 상황을 상상해보자. 누군가는 이곳을 온라인 상에서 검색해본 여러 다른 맛집들 사이의 순위를 떠올리며 바라볼 것이고, 누군가는 이곳을 걸어가면서 봤던 지도 상의 한 지점으로 바라볼 것이고, 누군가는 맛집이 위치한 동네의 공기, 걸어가며 마주친 풍경들의 시퀀스, 근처 빵집의 빵 굽는 냄새 같은 디테일로 맛집을 바라볼 것이다.

우리는 무수히 많은 공간들과 이를 바라볼 수 있는 무수히 많은 관점들 속에서 살아가고 있다. 공간 번역가들은 여러 공간-관점들 사이에서 의미 있는 상호작용이 일어날 수 있도록 연결 짓는 사람들이다. 도시 내의 업무 공간들과 주거 공간들 사이의 관계를 엮어 새로운 시설을 지어야 한다는 제안을 하는 건축가도 공간 번역가다. 지도 어플을 보고 걷는 사람들은 화면 공간 위의 점, 선, 면을 도시 공간과 본인의 위치에 맵핑시키고 있으므로 여기에선 어플을 디자인한 사람이 공간 번역가다.

공간 번역가들은 어떤 정보를 어떻게 정의된 공간에 어떻게 맵핑할지, 이를 통해 공간 경험을 어떻게 설명할 수 있을지 생각해볼 필요가 있다. 가상공간에서의 경험과 현실 공간에서의 경험의 상호작용이 점점 늘어나고 있는 시대에는 이에 걸맞은 공간 번역가들이 필요할 것이다.

행동, 버그.

2019-08-18 작성한 노트에서 발췌

현실에서 일어나는 일들은 물리법칙들과 같은 어떤 규칙들에 기반하고 있다. 이 규칙들을 관리하는 누군가가 존재하는 것은 아니지만 규칙들이 서로 충돌하거나 미처 처리하지 못한 예외 상황들이 있을지도 모른다는 걱정을 할 필요는 없을 것이다. 예를 들어, 가만히 있다가 위로 점프를 했더니 갑자기 바닥에서 튕겨져 나와서 몸 반쪽이 천장에 끼면 어떡하지- 하는 걱정은 하지 않아도 된다.

누군가가 만들어놓고 관리하고 있는 규칙들을 기반으로 하는 도시에서는 얘기가 다르다. 관리자들이 충분히 꼼꼼하게 규칙을 정비해놓지 않았다면 어제는 멀쩡히 다른 사람들이 보였다가도 오늘은 아무도 보이지 않는다든지, 특정 위치에 갔더니 한참 멀리 떨어진 장소에서의 이야기가 들린다든지, 몸의 일부가 바닥에 끼어 움직이지 못한다든지, 이런 예상하지 못했던 일들이 일어날 가능성이 있다. 이런 일들을 오류, 혹은 버그라고 부르도록 하자. 버그들의 이유를 분석해보면 지정해둔 규칙을 따랐기 때문이겠지만, 규칙을 따르는 것은 규칙을 만든 사람의 의도대로 상황이 흘러가는 것과 별개의 이야기다. 사소한 버그들은 사용자를 잠시 혼란스럽게 하는 선에서 끝나겠지만 어떤 버그는 사용자에게 관리자의 권한을 부여 해버리거나 사용자의 정보들을 복구 불가능할 정도로 망가뜨리거나, 어쩌면 도시 전체를 마비시켜버릴 수도 있을 것이다.

일상에서 크고 작은 버그들이 발견될 것이고, 어떤 도시에서는 이런 버그들이 빠르게 관리될 것이다. 어떤 도시는 특정 버그로 기억될 것이고, 나라마다 법규가 다르듯이 이런 버그들은 도시의 정체성을 결정짓는 요소 중 하나가 될 것이다. 도시의 사람들은 버그를 통해 도시와 상호작용한다.

도시, 기억.

2019-08-31 작성한 노트에서 발췌

가상 도시에서의 주민들은 몸과 기억이 분리될 수 있다는 사실에 익숙할 것이다. 몸 어딘가를 다치면 스스로 고치거나, 다른 주민들이나 도시의 관리자에게 고치는 방법을 물어보거나, 정 안되겠으면 새 몸을 찾으면 된다. 몸에는 연속성이 없어도 경험에는 연속성이 있으므로, 몸을 바꾸면 몸에 새겨진 기억들은 사라지겠지만 경험으로부터 비롯된 기억들은 새 몸에 공유될 것이다.

도시 자체가 다치거나 고장나는 것은 개별 주민이 다치는 것과는 사뭇 다른 양상을 띤다. 어떤 도시는 스스로 고치기도, 관리자의 영향 아래에서 부분적으로 격리된 상태로 복구되기도 할 것이다. 하지만 새 몸을 찾는 건? 도시의 연속성은 도시를 이루는 장소들이 유지되고, 사라지고, 새로 생겨나는 그 모든 역사로 부터 비롯된 현재의 상태 뿐만 아니라 도시를 이루는, 혹은 잠시 도시를 스쳐가는 모든 주민들의 경험과도 엮여있다. 장소들의 생성, 철거는 도시 관리자들이 기록을 남겨 추후 확인할 수 있지만, 장소들에서 일어난 개인의 경험들은 특별히 기록을 남겨놓지 않는 이상 주민들의 기억에만 남아있으므로, 도시의 기억은 사실상 주민들의 기억의 집합이라고 볼 수도 있겠다. 도시의 연속성을 위해서는 도시를 이루는 장소 뿐만 아니라 도시를 구성하던 주민들도 필요하므로, 도시가 새 몸으로 이전하는 건 그리 단순한 일이 아니다.

도시는 주민들의 기억을 들고있고, 주민들의 기억은 도시의 기억을 이룬다. 어떤 도시는 기억을 들고 있는 장소가 파괴되어 연속성을 잃고, 어떤 도시는 주민들의 기억이 파괴되어 연속성을 잃는다. 도시 구조상의 문제로 주민들이 다치는 것이 확인되면 도시의 관리자는 구조를 수정해야 하고, 수정하는 동안은 도시의 일부 장소들에 접근하는 것이 불가능해지기도 하므로 구조 수정에는 조심스럽게 접근해야 한다. 주민들의 기억을 관리하는 사람은 실질적으로는 도시의 기억을 관리하는 사람이라고 볼 수 있으며, 기억에 접근하거나 기억의 위치를 옮기거나 수정하는 중 잘못하여 기억을 파괴하는 일이 발생하지 않도록 각별한 주의를 기울여야 한다.

도시, 보기.

2019-09-06 작성한 노트에서 발췌

물리적인 세계에서의 도시는 그 모습을 보여주는 데에 디테일의 제한이 없다. 건물을 설계하고 시공하는 과정에서 얼마나 디테일을 신경써서 표현할지, 도시의 사람들이 이 디테일을 어디까지 볼지에 대해 고민하긴 해도 이미 만들어놓은, 그래서 눈 앞에 존재하는 디테일이 사람들에게 전달되는 과정에서 누락이 생기면 어떻게 할지에 대해 고민하지는 않을 것이다. 수 mm 단위로밖에 오차가 나지 않는 타일 바닥의 틈, 자연석의 무늬가 그대로 살아있는 벽, 매끈하게 마감된 콘크리트 벽, ...

가상 도시에 자연석으로 만든 벽이 세워져있다면 우리는 이걸 어떻게 '보는' 걸까? 저 멀리 자연석 벽이 보이기 시작한다고 가정해보자. 어딘가에 자연석 벽의 디테일과 벽의 위치가 정보 형태로 저장되어 있다가, 정보가 어떤 방식으로든 내 화면에 나오기 바로 전의 원본 정보들이 모이는 저장소로 흘러들어오고, 그곳에서 내 위치와 벽의 위치를 고려하여 벽의 정보를 화면에 표시하기 위한 형태로 변환된 뒤, 벽이 화면에 나타난다. 화면에는 해상도가 있고, 벽의 정보가 아무리 디테일해도 화면에 표시되는 영역이 좁으면 딱 그 영역 만큼으로 벽의 정보가 변환된다. 벽의 정보가 너무 크면 이를 변환하는 데에 시간이 걸릴 것이고, 걸린 시간만큼 화면에 나타나는 데에 딜레이가 생긴다. 앞서 두루뭉술하게 벽의 정보가 저장소로 흘러들어간다고 했는데, 어떻게 생긴 경로를 거치는지에 따라 추가적으로 시간이 들어갈 수도 있다. 벽 하나를 보기 위해 시각적인 정보 손실이 일어나고 일부 시간이 소요되는 것이다.

이는 물리적인 도시를 설계하는 데에 고려할 필요가 없는 것들이었다. 벽 한 두 개 정도를 화면에 표시할 때는 벽의 디테일한 정도와 벽이 화면에 나오기까지의 시간에 대해 걱정할 필요가 없겠지만, 자칫 잘못하면 벽의 개수가 늘어나는 만큼 정보를 저장하는 데에 더 큰 공간이 필요할 것이고, 정보들이 이동하는 데에 걸리는 시간도 늘어날 것이며, 정보를 화면에 그려주는 데에 걸리는 시간도 늘어날 것이다. 규모에 대한 감을 더 쉽게 잡기 위해 벽 대신 나뭇잎을 가지고 생각해보자. 나뭇잎 하나를 보여주는 건 문제가 되지 않겠지만 수 천 개의 나뭇잎이 붙어있는 나무는 어떨까? 그런 나무가 수 천 그루 있는 언덕이 있다면? 그런 언덕이 도시에 수 천 개 존재한다면? 여기서 재미있는 건, 내 시야 안에 수 천 개의 언덕이 다 들어오지 않을 때 보이지 않는 언덕의 나뭇잎들은 어떻게 처리할지 생각해보아야 한다는 점이다. 이 나뭇잎들은 분명히 도시에 존재하므로, 이에 대한 정보가 어딘가에는 있어야 한다. 그런데 나는 이 나뭇잎을 보고 있지 않으므로 당장 화면에 그려줄 때 고려할 필요가 없다. 언덕 하나를 화면에 그리는 데에 1/100초가 걸린다면 언덕 1000개를 그리는 데에는 10초가 걸린다. 나에게 보이는 언덕이 하나밖에 없다면 언덕 1000개를 다 그려주는 건 내가 도시를 보는 데에 지장을 주는 일이 된다. 그렇다면 언젠가 볼지도, 혹은 영영 보지 않을지도 모르는 나뭇잎들을 어떻게 해야 하는 걸까? 물리적인 도시에서는 내가 시공한 건물에 찾아오지 않을지도 모르는 사람들에 대해 고민하며 시공을 할 일이 있었던가?

시점, 필터.

2019-10-03 작성한 노트에서 발췌

1인칭 시점으로 앞을 보면서 가다가, 시야 오른쪽 일부에 내가 사용할 수 있는 물건들의 목록이 나타나고, 그 중 원하는 물건을 선택해서 장착하면서 동시에 앞을 보면서 나아가는 것을 멈추지 않는다. 어떤 곳에서는 시점이 나를 이탈하여 시야에 내 모습이 비스듬히 내려다보이기도 하고, 위에서 바로 아래로 내리 꽂아서 보기도 하고, 좌우방향의 움직임에 제약을 두는 대신 내가 움직이는 세상을 평면에 투영하여 전체적으로 조망하기도 한다.

앞으로 나아가는 나를 비스듬히 내려다보고 있는데 시야에 덩치 큰 바위나 나무가 나타나 내가 가려지면 어떻게 해야 할까? 시야에서 내가 갑자기 사라져버리면 움직이는 나와 이를 보고있는 시점이 분리되어버렸다는 인상을 받을 수도 있는 것이고, 이를 완화하기 위해서는 시점과 내가 분리되는 것을 어떻게든 막아야 하며, 그래서 나와 내 시점 사이에 장애물이 나타나면 갑자기 장애물의 존재가 사라지거나, 반투명하게 바뀌어버리거나, 내 실루엣의 외곽선이 장애물을 뚫고 나타나거나 할 수도 있다.

어떤 곳에서는 특정 대상들만 빛나게 보이기도 하고, 원하는 길만 다른 색으로 표시되기도 한다. 앞을 보고 이동하면서 동시에 내 주변에 존재하지 않는 것, 혹은 보고 있지 않은 것에 대해 보인다는 듯이 생각할 수 있고, 이것이 행동에 바로 반영된다. 내 주변에 있는 것들을 나에게 보여주기 위해 열심히 정보를 퍼다 나르면서 리소스를 쓰고 있는데, 정작 이것들에는 관심을 쏟지 않고 내 앞에 없는 것들의 정보에 관심이 있다니. 보고 있지 않은 것들을 기반으로 생각하려면 이들의 정보가 얼마나 디테일하게, 얼마나 빨리 갱신되는지에 대해 생각해봐야 할지도 모르겠다.

도시, 기억.

2019-11-03 작성한 노트에서 발췌

주민들을 규격에 맞추려는 정책을 펴는 도시, 규격을 주민들에 맞춰 확장하는 정책을 펴는 도시. 도시가 어떤 특성을 가지는지는 주민들의 행동에 따라 정책이 어떻게 바뀌는지 관찰하면 알 수 있다.

도시는 주민들의 행동을 어떻게 관찰하는가? 도시에 접속해있는 주민이 받아들이는 정보, 생성해내는 정보를 전부 수집하여 이를 로그로 남기고 추후에 분석하는 것이 가장 이상적이겠지만, 모든 주민들로부터 비롯된 정보를 모아두기 위해서는 큰 저장공간이 필요하고, 이 정보들을 분석하기 위한 방안까지 마련해야 하므로 현실적이지 못하다(게다가 '전부' 수집한다는 것은 무엇인가에 대해 고민해볼 필요도 있다.). 그러므로 특정 상황들에 대한 부분적인 정보들만을 추려서 이를 기록해두고, 추후에 이를 주기적으로 분석해서 그 결과를 기록해두는 시스템을 마련하는 것이 더 현실적이다.

어떤 정보를 수집하는지, 이를 어떻게 분석하는지, 분석 결과를 어떻게 정책에 반영하는지가 도시의 기반을 이룬다고 할 수 있겠다.

충돌 없는 도시.

2019-02-27, 2019-03-18 작성한 노트들을 재조합

1

우리는 도시를 볼 수 있다. 그렇기 때문에 도시에 있는 사람들, 시설들, 자동차들, 건물들과 충돌하기 전에 보고 피하는 것이 가능하다. 그렇다면, 충돌이라는 개념이 존재하지 않는 도시에서는 피하기 위한 목적으로 무언가를 보지 않아도 되는 것이 아닐까? 피하기 위해 본다는 건 다시 말하면 내 근처에 있는 물체 중 가까운 미래에 내 몸이 위치할 공간과 같은 공간에 도달할 수 있는 무언가가 있다는 걸 알아채기 위해 본다는 말이다. 충돌이 없는 도시에서는 어떤 물체가 나랑 같은 공간을 점유해도 문제가 발생하지 않을 테니, 내 주변 물체들을 잘 보지 않아도 괜찮고, 그러므로 주변 물체들의 시각 정보가 느린 간격으로 업데이트 되어도 상관 없을 것이다. 그렇다면 시각 정보를 제공하는 측, 그리고 시각 정보를 판단하는 측 양쪽 모두 정보 제공과 판단에 들어가는 리소스를 줄일 수 있을 것이므로 도시 운영 비용이 절감될 것이다.

2

가까이 있는 물체들과 충돌하지 않을 것이므로, 우리는 집중해서 보고 싶은 것들 외에는 열심히 보지 않아도 괜찮다. 원래라면 멀리 있는 전광판을 보고 있다가 갑자기 눈 앞에 공이 날아오면 이를 보고 피해야 했는데, 이제는 무시하고 전광판을 계속 쳐다봐도 된다. 교실에서 수업을 듣다가 기지개를 펴도 옆에 있는 창문이나 옆자리에 앉은 친구와 충돌할 것을 걱정하지 않아도 괜찮다. 멀리 있는 물체든 가까이 있는 물체든 내가 관심 가지지 않는 것들은 디테일하게 표현될 필요가 없다. 인테리어는 보려고 하는 자들의 전유물이 될 것이고, 공간에 관심이 없는 사람에게는 텅 빈 창고나 바로크 양식으로 꾸며진 홀이나 둘 다 비슷하게 보일 수도 있다(이 사람에게 '공간'이란 도대체 무엇일까?). 대부분의 물체에 간소화된 디테일을 적용하는 것만으로도 도시를 경험하는 것이 가능할테니, 도시 운영 비용을 추가적으로 절감하는 것이 가능하다.

3

충돌이 없어 도시를 보지 않아도 된다면, 충돌이 가정된 모든 요소들을 다시 설계할 필요가 있다. 사람들이 많이 타고 있는 엘리베이터를 그냥 보낼 필요도, 계단에서 앞 사람의 속도에 맞춰 따라 걸을 필요도 없다. 꽉 찬 지하철에서 여섯 명의 사람들과 접해있을 필요도 없고, 환승 통로 반대편에서 오는 사람들과 부딪칠 걱정을 하지 않아도 된다. 복도의 폭이 90cm보다 좁아도 된다. 벽에도 부딪치지 않기 때문에 복도라는 개념이 필요한지도 잘 모르겠다. 아무리 높이 점프해도 천장에 닿지 않는다. 그렇다면 바닥은 있을 필요가 있는가?

보이지 않는 도시는 휴먼 스케일이 재정의된 도시이기도 하다.