월간 보관물: 2013 8월

[WAYLAND] Wayland vs Mir

2013년 3월 즈음에 우분투를 배포하고 있는 캐노니컬(Canonical)에서 뜬금없이 Mir 라는 새로운 윈도우 서버 기술을 발표하였다. 캐노니컬은 Wayland 의 입력 장치 관리 부분이나 모바일 지원 부분이 맘에 들지 않아서 자체 개발하게 되었다는 등의 핑계를 댔지만 사실과는 거리가 멀다. 그리고 과거에도 GNOME-SHELL 이 있음에도 불구하고 Unity 라는걸 자체 개발해서 욕을 먹은 경험이 있기 때문에 이번 문제 또한 보는 시각들이 좋지 않다. 물론 오픈 소스의 가장 큰 장점이 자유로운 발상에 의한 경쟁이긴 한데, 아무래도 캐노니컬은 공정한 경쟁보다는 다른 목적이 있는듯하다.

이 소식을 처음 접하면서 개인적으로 가장 걱정스러웠던 부분은 다른 오픈소스 프로젝트와 달리 윈도우 서버는 연관된 프로젝트들이 굉장히 많고, 각각의 프로젝트들이 새로운 윈도우 서버를 지원하기 위해서는 많은 노력이 필요한데, Mir 의 등장으로 분위기가 어수선하게 되어버렸다는 점이다. 하지만 다행스럽게도(?) GNOME 과 KDE 양쪽 모두 Mir 를 반기지 않는 분위기이고, Mir 지원을 위한 어떠한 노력도 하지 않을 것 같은 분위기여서 Wayland 지원에 큰 영향은 없을 것 같다.

이러한 상황에서도 (이미 예상하고 있었겠지만) 캐노니컬은 13.10 부터 X 윈도우 서버를 Mir 로 대체하기로 했다. 이게 가능한 이유는 기존 어플리케이션이나 쉘 호환성 문제는 X 서버를 에뮬레이팅해주는 XMir 가 있기 때문에 해결 가능하고, 자체 개발하고 있는 Unity 는 Mir 를 직접 지원할 수 있기 때문이다.

캐노니컬이 이렇게까지 하는 이유는 아마 스마트폰이나 스마트TV 같이 앞으로 나올 다양한 컴퓨팅 환경에서 (구글의 안드로이드처럼) 우분투를 적극 활용하려는 욕심이 있기 때문일 것이다. 다양한 컴퓨팅 환경을 효과적으로, 그리고 원하는대로 지원하기 위해서는 윈도우 서버와 쉘에 대한 강력한 영향력이 필수이고, 그렇기 때문에 캐노니컬은 좋지 않은 상황에서도 무리해서 Mir 와 Unity 를 자체 개발할 수 밖에 없었을 것이다.

Advertisements

[WAYLAND] 1. 소개

최근 리눅스 UX 관련해서 가장 화두가 되고 있는 것 중에 하나는 바로 WAYLAND 이다. (WAYLAND 는 기존의 윈도우 매니저를 개발하기 위해 사용해왔던 X11 프로토콜을 대체하는 프로토콜이다.) 대다수의 핵심 UX 관련 프로젝트들(GTK+, Qt, Clutter 등등)이 WAYLAND 를 백엔드로 지원하기 위한 작업들을 진행 중이고, 짧은 시간 동안 상당 부분 진척이 이루어졌다. 이에 WAYLAND 가 무엇인지에 대한 간단한 소개부터 실질적인 컴포지터(GNOME 의 Mutter 같은)를 개발하기 위해 필수적으로 알아야 하는 내용까지 단계별로 소개하는 글을 작성해보도록 하겠다. (필자가 개발 중인 윈도우 매니저 또한 WAYLAND 를 기반으로 하고 있다.)

WAYLAND 등장 배경

WAYLAND 는 2008년 레드햇의 개발자였던 Kristian Hogsberg (이하 KRH) 의 개인 프로젝트로 시작하였다. (현재 KRH 는 인텔에서 근무 중이다.) 그렇다면 왜 기존의 X 가 있었음에도 불구하고 WAYLAND 라는 프로젝트가 등장하였고, 이처럼 급속히 퍼져나가고 있을까? 여기에 대해서는 여러 가지 말들이 있지만 필자가 느끼기에 가장 중요하다고 생각되는 정황적인 이유를 먼저 언급하도록 하겠다. (X 에 대한 자세한 언급은 생략하도록 하겠다. 필자의 관심사항도 아니고, 현재로서는 불필요한 지식들이기 때문이다.)

  • (필자가 보기에 가장 근본적인 이유는) X 코어 개발자들이 지쳤다는 점이다. 거의 25년 전에 설계된 X 에 수없이 많은 확장 기능들을 추가하면서 지금껏 이끌어왔다. 그리고 현재는 사용하지도 않는 기능들이 남아있고, 비슷한 기능을 하는 것들이 여러 개가 동시에 존재하는 경우도 있다. 즉, 현재의 X 를 이용해서 무언가 새로운 것을 하기에는 상황이 너무 좋지 않다는 것이다.
  • (위의 이유와 비슷하게) X 를 이용하는 UX 개발자들 또한 지쳤다는 점이다. 위와 비슷한 맥락의 설계적인 문제나 다른 여러 가지 문제들은 이를 이용해야하는 수많은 개발자들에게도 크나큰 고통을 주고 있다.

사실 현재 X 가 WAYLAND 에서 제공되고 있는 기능들을 전혀 제공하지 못하는 것은 아니다. (심지어 X12 프로젝트 또한 진행 중이다.) 하지만 중요한 것은 이와 같은 여러 가지 이유로 모두가 X 를 버리고 새롭게 시작하기를 원한다는 것이다.

다음은 기술적인 그리고 구조적인 몇 가지 이유를 설명하도록 하겠다.

  • WAYLAND 는 오픈 소스 친화적이고, 최소한만을 유지한다. (KMS (Kernel-Mode Setting) 와 EVDEV, PIXMAN 등 WAYLAND 는 외부 오픈 소스를 최대한 활용하여 내부를 최소한으로 유지한다.)
  • WAYLAND 는 로컬 기반이다. (원격 접속은 클라이언트 계층에서 VNC 같은 프로토콜을 사용하면 된다.)
  • WAYLAND 는 컴포지팅 API 만을 제공한다. (WAYLAND 는 Direct Rendering 과 CSD (Client-Side Decoration) 만을 제공한다. CSD 에 대해서는 반대하는 여론도 많지만, 기본적으로 WAYLAND 는 굉장히 단순해졌다.)

위의 세 가지는 WAYLAND 의 가장 중요한 특징들이다. 그리고 X 는 각각 이와 정반대의 경우에 해당한다. 결론적으로 WAYLAND 가 등장할 수 밖에 없었던 이유를 한 마디로 정리하면, X 는 덩치가 너무 커져서 개발하기 힘드니 WAYLAND 라는 (새로운) 작고 가벼운걸 만들어서 편하게 개발하자라고 할 수 있다.

WAYLAND 기본 구조

X 서버와 WAYLAND 의 가장 기본적인 차이는 X 서버는 독립적인 프로세스이고, WAYLAND 는 라이브러리이다. 즉, WAYLAND 는 컴포지터에 라이브러리 형태로 합쳐져서 동작한다. 그로 인한 동작 과정의 차이는 아래와 같다.

x-architecture

위의 그림은 X 서버의 동작 과정을 간략하게 표현해주는 그림이다. (위의 그림은 WAYLAND 홈페이지에 소개된 것이다.) 그림에 나타난 번호는 X 클라이언트에서 사용자 입력을 받아서 화면을 갱신하는 과정을 순서대로 표현한 것이다. 간략한 설명을 덧붙이면 다음과 같다.

  1. X 서버는 EVDEV 를 통해 커널로부터 사용자 입력을 전달받는다.
  2. X 서버는 사용자 입력을 X 클라이언트에게 전달한다.
  3. X 클라이언트는 필요한 화면을 갱신 후, X 서버에게 알린다.
  4. X 서버는 컴포지터에게 X 클라이언트의 화면이 갱신된 사실을 알린다.
  5. 컴포지터는 X 클라이언트의 갱신된 화면을 최종 화면에 반영 후, X 서버에게 알린다.
  6. X 서버는 KMS 를 통해 갱신된 최종 화면을 프레임버퍼에 반영한다.

이에 반해 WAYLAND 의 동작 과정은 다음과 같다.

wayland-architecture

그림에서 보는 것처럼 WAYLAND 와 컴포지터가 하나로 합쳐져서 불필요하게 IPC 로 메세지를 주고 받는 일이 줄어들었다.

WAYLAND 프로토콜

WAYLAND 는 기본적으로는 윈도우 서버와 클라이언트가 통신하기 위한 프로토콜이다. 아래는 WAYLAND 소스 코드에 포함되어 있는 기본 프로토콜을 정의하고 있는 wayland.xml 의 일부분이다. 이 파일에는 wl_display, wl_registry, wl_shm 과 같은 기본적인 프로토콜들이 정의되어 있다. 이 파일은 RPC (Remote Procedure Call) 의 stub 파일처럼 WAYLAND 컴파일 시에 헤더 파일과 소스 파일로 변환되어, 컴포지터와 클라이언트에서 편리하게 해당 메시지를 주고 받을 수 있도록 도와준다.

<interface name="wl_registry" version="1">
  <request name="bind">
    <arg name="name" type="uint"/>
    <arg name="id" type="new_id"/>
  </request>
  <event name="global">
    <arg name="name" type="uint"/>
    <arg name="interface" type="string"/>
    <arg name="version" type="uint"/>
  </event>
</interface>

WAYLAND 는 여러 개의 인터페이스(interface)를 정의하여 사용할 수 있고, 각각의 인터페이스는 리퀘스트(request)와 이벤트(event)로 구성되어 있다. 리퀘스트는 클라이언트가 서버에게 요청하는 것이고, 이벤트는 서버가 클라이언트에게 요청하는 것이다. 위의 xml 을 보면 wl_registry 라는 인터페이스가 정의되어있고, 여기에는 bind 라는 리퀘스트와 global 이라는 이벤트가 정의되어 있다.

static void
registry_handle_global(void *data, struct wl_registry *registry, uint32_t id, const char *interface, uint32_t version)
{
  ...
}

static const struct wl_registry_listener registry_listener = {
  registry_handle_global
};

wl_registry_add_listener(display->registry, &registry_listener, display);

위의 코드는 클라이언트에서 wl_registry 의 이벤트 핸들러를 등록하는 부분이다. 서버가 클라이언트에게 global 이벤트를 보내면 위의 registry_handle_global() 함수가 호출된다. 아래 코드는 이와 반대로 서버에서 wl_registry 의 리퀘스트 핸들러를 등록하는 부분이다. 클라이언트가 서버에게 bind 리퀘스트를 보내면 registry_bind() 함수가 호출된다.

static void registry_bind(struct wl_client *client, struct wl_resource *resource, uint32_t name, const char *interface, uint32_t version, uint32_t id)
{
  ...
}

static const struct wl_registry_interface registry_interface = {
  registry_bind
};

이와 같은 방식으로 WAYLAND 서버와 클라이언트는 메시지를 주고 받으면서 동작한다. (실제 WAYLAND 와 WESTON 의 컴포지터와 클라이언트 소스를 보면 다양한 인터페이스들이 어떤 식으로 사용되는지 알 수 있다.)

WAYLAND 기본 동작

WAYLAND 에서는 서버와 클라이언트가 기본적으로 하나의 소켓을 통해 여러 가지 인터페이스의 리퀘스트와 이벤트를 주고받는다. WAYLAND 는 이를 편리하게 처리할 수 있도록 몇 가지 자료구조를 미리 정의해두고 있다. wl_connection 객체는 소켓을 통해 편리하게 메시지를 주고 받을 수 있도록 도와주는 객체이고, wl_object 객체는 각각의 인터페이스를 구분해주는 역할을 한다. 이들의 관계를 그림으로 간단히 표현하면 아래와 같다.

wayland-interface

위의 그림에서 왼쪽은 클라이언트이고, 오른쪽은 서버이다. 우선, 클라이언트가 서버로 소켓을 통해 접속을 요청하면 양쪽에 wl_connection 객체가 생성되고, 여기에 필요한 인터페이스를 처리하기 위한 여러 개의 wl_object 가 순서대로 등록된다. 기본적인 등록 과정이 마무리된 후, 만약 클라이언트가 새로운 서피스(surface) 를 만들기 위해 wl_compositor_interface 의 create_surface 리퀘스트를 서버에게 요청하고 싶다면, wl_connection 과 wl_compositor 객체를 이용해 간단히 리퀘스트를 전달할 수 있다. 반대로 서버가 클라이언트에게 지원 가능한 인터페이스 목록을 전달하고 싶다면, wl_registry_interface 의 global 이벤트를 해당 wl_resource 객체를 통해 전달할 수 있다.

WAYLAND 의 가장 기본적인 인터페이스는 wl_display 와 wl_registry 이다. wl_display 는 클라이언트가 서버에 접속하는 순간 바로 생성되어 wl_registry 인터페이스 연결을 돕는 인터페이스이다. 그리고 wl_registry 는 컴포지터가 지원하는 인터페이스들(global)을 연결할 수 있도록 도와주는 인터페이스이다.

전체적인 동작 과정을 간단하게 요약하면 아래와 같다.

  • WAYLAND 서버는 자신이 지원하는 인터페이스들을 global 로 등록해둔다.
  • WAYLAND 서버는 소켓을 열고 대기한다.
  • WAYLAND 클라이언트는 소켓을 통해 서버로 접속한다. (소켓이 연결되고 나면 wl_display 인터페이스를 위한 wl_object 가 서버와 클라이언트에 생성된다.)
  • WAYLAND 클라이언트는 wl_display 인터페이스를 이용하여 wl_registry 인터페이스를 연결한다.
  • WAYLAND 서버는 wl_registry 인터페이스를 통해 global 이벤트를 전달한다. (컴포지터가 지원하는 인터페이스 목록 전달)
  • WAYLAND 클라이언트는 필요한 인터페이스들(wl_compositor_interface, wl_seat_interface 등등)을 연결하여 필요한 동작들을 수행한다.

이상으로 WAYLAND 에 대한 소개를 마무리하도록 하겠다. 다음 글에서는 실질적인 컴포지터를 개발하기 위해 필요한 내용들을 작성하도록 하겠다.

[참고자료]

1. Wayland Homepage, http://wayland.freedesktop.org

2. [PHORONIX] The Wayland Situation: Facts About  X vs Wayland, http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=1

[TECH] 영화를 위한 영상기법

나의 유일한 취미는 영화 감상이다. 특히 화려한 CG 가 들어간 영상물들…참고로 어벤져스는 극장에서만 5번 보았고, 집에서 본 것까지 하면 수십번도 더 본 것 같다. 그래서 시스템 SW 를 주로 연구/개발해오던 나에게 컴퓨터그래픽은 항상 동경의 대상이였고, 지금 하고 있는 프로젝트도 거기에 아주 큰 영향을 받았다. (궁극적으로 오큘러스 리프트나 뇌파 컴퓨팅을 이용하여 매트릭스 같은 가상세계가 만들어진다면 현재 영화에서 사용되는 CG 기술들 중 일부가 실시간으로 적용될 것이다. 대표적으로 실시간 레이트레이싱 기법…)

이번 글에서는 내가 주로 관심을 가지고 있는 3D 모델링, 전역 조명 기법(레이트레이싱), 합성 외에도 전통적으로 사용되어오던 영상기법까지(현재까지 활용되고 있는 기술들 위주로) 두루두루 소개를 하도록 하겠다. 먼저 영상 기법은 크게 SFX(아날로그)와 VFX(디지털) 로 나뉜다. SFX 는 컴퓨터를 이용하지 않고 여러 가지 방법을 이용하여 필요한 영상을 만들어내는 기술이고, VFX 는 컴퓨터를 이용하여 필요한 결과물을 만들어내는 기술이다.

우선 간단히 눈여겨 볼만한 SFX 기술들을 설명하도록 하겠다.

미니어쳐

현재에는 거의 사용이 되지 않지만, 컴퓨터 그래픽이 일반화되기 전에는 특수분장과 더불어 미지의 피조물을 만들어 낼 수 있는 유일한 방법이었다. (참고로, 제임스 카메론이 처음 영화 현장에서 한 일이 미니어처 세트 디자인일이었다고 한다.) 다들 직관적으로 상상할 수 있듯이 실제 크기로 만들기 힘든 피조물들을 작은 크기로 정교하게 만들어 촬영에 활용하는 전반적인 기술들을 의미한다. 아래 그림은 에일리언2 영화 촬영 당시 실제로 사용된 에일리언 퀸의 미니어처이다.

에일리언 미니어쳐

매트 페인팅(Matte Painting)

주로 웅장한 배경을 제작할 때 쓰이는 기술로 사람의 손으로 직접 그리는 방식이다. 디지털 시대 이전에는 다양한 촬영기술과 함께 적용되어 완성된 결과물을 만들어냈지만, 현재에는 포토샵 등의 툴을 이용하여 보다 세밀한 작업이 가능해졌다. 아래 그림은 매트 페인팅 과정과 그 결과물을 보여주고 있다. 사람의 손으로 이렇게까지 정교하게 그릴 수 있다는 사실이 놀랍기만 하다.

매트페인팅

애니메트로닉스

애니메이션(Animation) 과 일렉트로닉스(Electronics) 의 합성어로 간단히 말해, 실제 움직일 수 있는 기계장치를 만들어내는 것이다. 그리고 최근에는 컴퓨터 그래픽과의 연계로 더욱 강력한 능력을 발휘하고 있으며, 대표적으로 최신작인 프로메테우스가 있다. 아래 동영상은 프로메테우스와 다양한 영화에서 사용된 애니메트로닉스 기술 홍보 동영상이다.

다음은 컴퓨터를 이용한 영상 기술인 VFX 에 대해 소개하도록 하겠다.

3D 모델링 & 합성

3D 모델링 및 합성을 위한 가장 기본적인 작업 순서는 다음과 같다.

  • 모델링 .. MAYA 나 3D MAX 와 같은 툴을 이용하여 물체의 외형을 디자인 하는 작업
  • 리깅 .. 모델링 된 캐릭터에 뼈대를 할당하여 움직일 수 있는 상태로 만드는 작업
  • 애니메이션 .. 리깅까지 완료된 캐릭터에 실제로 움직임을 부여하는 작업
  • 렌더링 .. 전역 조명 기법을 이용하여 모델에 실제와 같은 정교한 조명 효과를 입히는 작업
  • 합성 .. NUKE 와 같은 툴을 이용하여 렌더링 결과 이미지와 실사 영상을 합성하는 작업
  • 보정 .. 포토샵과 같은 툴을 이용하여 합성된 결과물을 최종 형태로 다듬는 작업

위의 여섯 과정 중 직관적으로 이해가 안 될 수도 있는 렌더링과 합성에 대해 아래 동영상을 보며 추가로 설명을 하도록 하겠다.

위의 동영상을 보면, 첫 번째로 모델링 된 우주선이 빈 공간을 날아가는 영상을 만든다. 그 뒤에 배경으로 사용될 하늘 영상이 촬영되고, 두 개의 영상이 합쳐진다. 하지만 두 장면이 굉장히 이질적이다. 이유는 배경에 있는 밝은 빛이 우주선에 전혀 영향을 주지 못 하기 때문이다. 그래서 이 우주선에 배경과 유사한 조명 효과를 적용한다. (이게 바로 전역 조명 기법을 이용한 렌더링이다.) 이렇게 만들어진 영상에서는 우주선에 자연스러운 빛이 스며들어 훨씬 더 사실감이 느껴진다.

그렇다면 우리 눈에 실제로 존재하는 것같은 착각이 들게 하는 요소들이 뭐가 있을까? 방금 위에서 설명한 것처럼 (실제 촬영된) 주변 환경과 어울리는 자연스러운 조명이 기본적으로 필요하고 이외에 그림자, 반사 등의 효과들이 큰 영향을 주게 된다. 아래 그림은 합성의 가장 중요한 역할 중에 하나인 그림자 효과를 보여주고 있다.

zaaa

위의 그림에서 가운데 떠있는 물체는 실제로는 존재하지 않는 물체이다. 하지만 자연스러운 조명과 책상 위에 나타난 그림자로 우리의 눈은 쉽사리 착각에 빠지게 된다. 이러한 작업을 가능하게 해주는 합성에도 다양한 툴과 기법들이 있지만 가장 기본적으로는 카메라 트래킹이라는 기술이 이용된다. 카메라 트래킹은 미리 촬영된 2D 영상을 분석하여 촬영 당시 카메라 위치/각도와 (포인트 클라우드를 이용하여) 3D 공간을 복원해낸다. 그리고 이 복원된 3D 세트에 렌더링된 물체를 올리게 되면 위의 화면과 같이 자연스러운 그림자 효과(마치 실제 바닥에 그림자가 생기는 것처럼)를 만들어낼 수 있다. 이외에도 마커(marker)를 이용한 크로마키 촬영을 통해 보다 정밀하게 3D 공간을 복원하는 방법도 있다.

파티클 효과

일반적으로 연기, 물, 불 등과 같이 많은 양의 미세한 입자들이 다양한 물리 효과를 적용받는 현상이나 자동차 폭발과 같이 물체가 수많은 파편들로 쪼개지면서 자유운동하는 모습을 시뮬레이션하기 위해 사용되는 전반적인 기법들을 의미한다. 즉, 기존에는 미니어처나 위험한 실사 촬영을 통해 만들어낼 수 밖에 없었던 영상들을 컴퓨터로 안전하게, 원하는 만큼 시뮬레이션해서 필요한 영상을 만들어내는 획기적인 기법이라고 할 수 있다. 이는 영화 뿐 아니라, 게임 분야에서도 적극 활용되고 있기 때문에 다양한 상용/오픈소스 물리엔진들이 이를 지원하고 있고, 아래는 필자가 주로 사용하고 있는 BULLET 이라는 오픈소스 물리엔진의 데모 동영상이다. (정확히는 BULLET 을 기반으로 한 상용 솔루션을 판매하는 Exocortex 사의 데모 동영상이다.)

몰핑(Morphing)

2D 혹은 3D 의 물체의 모양을 서서히 다른 모양으로 변화시키는 기술을 의미한다. 가장 유명한 예로 마이클 잭슨의 뮤직비디오에서 사람의 형태가 자연스럽게 바뀌는 것도 바로 몰핑 기술을 활용한 것이다. 아래 동영상을 보면 직관적으로 무엇을 하는 기술인지 이해가 갈 것이다.

워핑(Warphing)

몰핑이 전혀 다른 물체로 변형시키는 거라면 워핑은 사물의 모양을 살짝 변경하는 기술을 의미한다. 예를 들면, 고양이의 입꼬리를 올려서 웃는 표정을 만든다든지, 아기가 어른처럼 말하게 한다든지…즉, 사물의 재질과 같은 기본 속성은 그대로 유지한채 모양만 살짝 비틀어서 원하는 효과를 만들어내는 것이다.

이외에도 수없이 많은 기술들이 존재하고, 지속적으로 새로운 기술들이 개발되고 있다. 우리나라 속담에 목 마른 사람이 우물을 판다고 컴퓨터 그래픽 기술의 발전을 가장 적극적으로 주도했던 분야는 결국 영화산업이였던 것 같다. 개별 기술들에 대한 보다 깊이 있는 설명은 추후에 하나씩 진행하도록 하겠다.

[INTERFACE] 립 모션(Leap Motion)의 용도?!?!

2012년 말에 립 모션 소개 동영상을 처음 봤을 땐 큰 감동을 받았다. 이유는 홍보 동영상을 참 잘 만들었기 때문이다. 그래서인지 소셜펀딩을 통해 엄청난 성공을 거두고, 뒤이어 대규모의 투자를 유치하였다. 하지만 개인적으로는 립 모션에 대해 생각을 하면 할수록 용도나 포지션이 애매한거같아 걱정이 됐었다. 그러다가 2013년 ITRC 포럼에서 잠깐 만져보고, 오늘 직접 구매해서 사용해본 결과 내가 우려하던 것들이 결국 현실이 되었구나라는 확신(?)이 들었다.

일단 먼저 입출력 장치들을 내 나름대로의 기준으로 아래와 같이 분류를 해보았다.

input

이벤트 장치와 포인팅 장치의 분류 기준은 입력 장치의 최종 결과물의 용도를 기준으로 나누었다. 즉, 이벤트 장치는 사용자가 다양한 형태로 미리 정의된 범위 안의 이벤트를 지정하는 장치들을 의미하고, 포인팅 장치는 특정 위치를 지정하기 위한 장치들을 의미한다. (음성 인식이나 뇌파 인식은 궁극적으로는 입력 형태의 제한이 없어지겠지만, 현재 사용 가능한 기술 수준이 미리 등록된 데이타와의 패턴 매칭이기 때문에 일단은 이벤트 장치로 분류하였다.)

그리고 포인팅 장치는 절대 위치 장치와 상대 위치 장치로 나누었다. 절대 위치 장치는 멀티터치와 같이 출력 장치의 위치를 한번에 지정하는 방식이고, 상대 위치는 마우스처럼 출력 장치 위에 나타난 가이드를 이리저리 움직이며 위치를 찾아가는 방식이다.

그렇다면 립 모션은 어느 위치에 속한 장치일까?

립 모션의 홍보 동영상을 보면 약간(?) 멀티터치를 대체하는 듯한 느낌을 주려 한다. 하지만 직관적으로 생각해봐도 그렇고, 실제로 써보면 더욱더 느껴지는 것은 스크린과 손가락 사이의 거리가 있기 때문에 특정 위치를 잡기가 쉽지 않다. 그렇다면 마우스와 같이 상대 위치 장치로는 사용할 수 있을까? 이것 또한 쉽지 않다. 이유는 멀티터치나 마우스의 경우 DOWN/UP(멀티터치로 화면을 눌렀다 떼는, 마우스로 버튼을 눌렀다 떼는) 기능이 존재한다. 그렇기 때문에 임의의 A 위치에서 B 위치까지를 편리하게 지정할 수 있다. 하지만 립 모션은 그게 불가능하다. 손가락으로 물체를 가리키고 있는 상태에서 DOWN/UP 이벤트를 넘겨줄 방법이 없다. (립 모션만을 이용해서 그림판으로 그림을 그린다고 상상해보면…답이 안 나온다…)

그렇다면 결국 립 모션의 주된 용도는 이벤트 장치가 될 수 밖에 없다. 근데 여기에 또한 문제가 있다. 립 모션의 센서 인식 범위가 생각보다 좁아서, 결국 간단한 이벤트 몇 가지 넘기기 위해서 장치 바로 위에 손을 들고 있어야 하는 심각한 문제가 생길 수 있다. 이럴바에는 (아직 인식률이 어느 정도 인지는 모르겠지만) MYO 가 훨씬 좋을꺼같다. MYO 는 홍보 동영상에서 나오는 것처럼 프리젠테이션을 할때나 여러 공간을 돌아다니면서 필요한 이벤트를 자유롭게 전달할 수 있다. 즉, 립 모션과 MYO 를 비교해보면 인식률은 아직 미확인 상태이고, 공간 활용성 측면에서는 MYO 가 월등히 우세하다는 말이다.

결국 나의 결론은 립 모션은 키넥트 처럼 제한적인 프로그램(주로 게임)에서나 조금 쓸 수 있지, 일반적인 UX 에서 활용하기에는 심각한 문제들이 복합적으로 존재한다는 것이다.

이건 어디까지나 짧은 내 개인적인 생각이고, 어찌됐든 내가 생각하는 NEMO-UX 를 위한 가장 이상적인 조합은 멀티터치+MYO 이다.