경험을 구성하는 세 가지 축

세 가지 축 정의하기

지난 주 나는 프로젝트의 방향을 소음에서 소리로 재설정했다. 이번 주에는 자연스럽게 다음으로 넘어오는 질문에 답해야 했다. “이 프로젝트는 장소의 소리를 시각화한다”는 말은 계획이 아니다. 그것은 단지 하나의 문장일 뿐이다. 이것이 내가 실제로 만들 수 있는 무언가가 되려면, 경험을 구체적인 요소로 쪼개고 각각이 무엇을 책임지는지 결정해야 했다.

한 주가 끝날 무렵 경험은 세 가지 요소로 나뉘어 있었다. 나는 그것들을 세 가지 축이라고 부른다.

① 오디오 시각화. 싱가포르 각 지역에서 수집한 소리 데이터는 눈으로 볼 수 있는 무언가로 변환되어야 한다. 파티클, 유체, 색, 움직임으로. 목표는 오디오를 비주얼로 장식하는 것이 아니다. 목표는 소리의 속성인 주파수, 진폭, 리듬이 화면 위 형상을 직접 구동하도록 만드는 것이다. 오디오가 바뀌면 이미지가 바뀐다. 오디오가 멈추면 이미지가 가라앉는다. 헤드폰 없이 화면 앞을 지나가는 사람이 있더라도, 비주얼의 형태만으로 그 장소에 대해 무언가 짐작할 수 있어야 한다.

② 가상 여행. 방문자는 싱가포르를 외부에서 바라보지 않는다. 싱가포르 안으로 걸어 들어간다. 각 지역은 그 앞에 서서 보는 360도 사진이 아니라, 방문자가 이동할 수 있는 인터랙티브 3D 환경이 된다. 이것이 내 대상 독자, 즉 싱가포르를 방문하고 싶지만 그럴 수 없는 사람들, 그리고 출발 전에 도시에 대해 미리 배우고 싶은 사람들에게 응답하는 프로젝트의 부분이다. 평면 이미지는 그 일을 해내지 못한다. 들어갈 수 있는 공간은 해낸다.

③ 체화적 상호작용. 세 번째 축은 몸이다. 마우스와 키보드만으로는 충분하지 않다. 방문자는 손으로 비주얼 안쪽에 다가갈 수 있어야 하고, 몸을 움직여 들리는 소리를 바꿀 수 있어야 하며, 공간이 실제 장소처럼 자신에게 반응한다고 느껴야 한다. 이 축이 이 작품을 화면 안의 경험에서 물리적 경험에 가까운 무언가로 전환시키는 축이다.

세 가지 축을 명명하고 나서 나는 그것들이 어떻게 연결되는지 이해하는 데 시간을 썼다. 답은 중앙의 수렴 지점에 있다. 세 개가 동시에 작동하면 어떤 일이 벌어지는가? 한 방문자가 부기스 지역을 걷고 있다. 녹음에서 나오는 시장의 소음이 그를 둘러싼 수천 개의 파티클을 움직이게 한다. 그가 손을 뻗으면 파티클이 비켜난다. 고개를 돌렸기 때문에 소리가 달라진다. 세 가지 축이 동시에 작동하고 있고, 방문자는 그것들을 세 개의 별개로 인식하지 않는다. 하나의 경험으로 본다. 그것이 목표다.

기술적 타당성 리서치

세 가지 축을 정의하는 것은 쉬운 절반이었다. 더 어려운 질문은 내가 이것들을 실제로 만들 수 있는가였다. 주의 후반부는 각 축에 대한 기술 리서치에 썼다. 특정 도구를 이 시점에 확정하기 위해서가 아니라, 축들이 불가능하지 않은지 확인하기 위해서였다.

오디오 시각화의 경우 파티클 시스템, 유체 시뮬레이션, 그리고 실시간으로 주파수 밴드를 추출하는 FFT 같은 오디오 분석 방법을 살펴봤다. JavaScript 경험이 어느 정도 있었기에 WebGL이 첫 번째 후보였지만, 데스크톱 애플리케이션이 GPU에 더 직접적으로 접근할 수 있는 네이티브 접근도 함께 읽어봤다. 이 시점에 결정하지는 않았다. 두 경로가 모두 존재하며, 둘 다 흥미로운 규모의 오디오 반응형 파티클을 감당할 수 있다는 것만 확인했다.

가상 여행의 경우 질문은 방문자가 이동할 수 있는 3D 공간을 어떻게 만들 것인가였다. 웹에서는 Three.js가 곧장 떠올랐고, 네이티브 애플리케이션을 위한 게임 엔진과 커스텀 렌더러도 살펴봤다. 더 큰 고민은 렌더링이 아니라 콘텐츠였다. 각 지역은 관광용 렌더처럼 보이지 않으면서도 그 장소로 느껴지는 3D 모델을 필요로 한다. 이번 주에 모델링을 시작하지는 않았지만, Blender 같은 도구가 내가 염두에 둔 단순화된 스타일을 만들어낼 수 있는지 확인했다.

체화적 상호작용의 경우 MediaPipe를 살펴봤다. 웹캠만으로 실시간 손 추적이 가능하고, 별도의 장비가 필요 없다. 졸업 작품에서는 이것이 중요하다. 헤드셋이나 컨트롤러가 있어야 작동하는 작품을 원하지 않는다. 방문자가 웹캠이 있는 컴퓨터 앞에 앉으면 바로 작동해야 한다. 다른 선택지도 존재하지만 MediaPipe가 가장 마찰이 적었고, Python과 JavaScript 바인딩이 모두 있어 웹 방향이든 네이티브 방향이든 어느 쪽에도 맞는다.

리서치가 끝날 즈음 나는 어떤 것에 대해서도 단일 도구를 고르지는 않은 상태였다. 내가 확인한 것은 모든 축이 현실적으로 만들 수 있는 최소 한 가지 경로를 가지고 있다는 것, 그리고 세 가지가 같은 애플리케이션 안에서 함께 돌아갈 수 있는 길이 존재한다는 것이었다. 그것만으로 이번 주를 닫기에 충분했다. 계획은 유효하다. 나는 이것을 만들 수 있다. 다음 주는 세 축의 버전을 실제 작동하는 프로토타입에 처음 넣어보는 주가 될 것이다.