카테고리 보관물: MISC

[TECH] 3D 영화를 위한 영상 압축 기술 소개 (MPEG 3DG)

필자가 관심을 가지고 있는 분야 중의 하나는 전역 조명 기반의 실시간 렌더링 기술이다. 그리고 이를 활용하는 증강/가상 현실과 3D 영화 분야도 늘 관심있게 지켜보고 있었는데, 얼마 전에 아시는 분과 이야기를 하다가 2D 영화는 기존의 수많은 압축 기술을 이용하여 배포하는데 3D 영화는 어떻게 해야하나는 의문이 생겼었다. 그때 막연히 이런저런 것들이 필요하겠구나라는 생각만 하고 넘어갔었는데, 최근에 우연히 관련 연구가 MPEG 쪽에서 이미 꽤 오랜 시간 동안 진행되고 있었다는 사실을 알게 되었다. 그래서 오늘은 MPEG 에 포함되어있는 3DG 관련 부분에 대해 간단히 소개하고자 한다. 필자가 영상 압축과 관련된 분야의 전문가가 아니기 때문에 상세한 이야기는 할 수 없고, 말그대로 간단한 소개 및 개념 이해 정도라고 보면 좋겠다.

우선 필자가 관심을 가지고 있는 3D 영화에 대한 정의부터 하겠다. 기존에도 3D 영화가 있었고, 현재도 JauntVR 과 같은 회사가 새로운 형태의 3D 영화 제작 기술을 공개하고 있지만, 필자가 관심을 가지고 있는 3D 영화는 영화를 관람하는 사람의 시점에서 실시간으로 렌더링을 하는 형태의 영화를 의미한다. 즉, 폴리곤, 텍스처, 그리고 3D 장면을 구성하는데 필요한 모든 정보를 실시간으로 넘겨받아 관람자의 시점에서 렌더링을 한다는 것이다. 여기에는 기본적으로 해결해야 할 두 가지 문제가 있다. 첫 번째는 3D 장면을 구성하는데 필요한 데이터가 기존의 2D 영화와 비교해 굉장히 많다는 것이고, 두 번째는 이러한 많은 데이터를 이용해 실시간으로 고품질의 렌더링을 해야한다는 것이다. 두 번째 문제는 필자가 직접적으로 관심을 가지고 있는 분야이기 때문에 관련된 글을 몇 번 올린 적이 있고, 오늘은 첫 번째 문제와 관련하여 MPEG 쪽에서는 어떤 연구를 진행하고 있는지를 살펴보려고 한다.

겨울왕국과 같은 3D 애니메이션 영화를 이용하여 2D 영화와 3D 영화의 차이점을 좀 더 알아보자. 3D 애니메이션의 제작 과정을 살펴보면, 물체의 형태를 만들고, 물체의 표면에 입혀질 이미지를 만들고, 물체의 움직임을 표현할 수 있는 애니메이션까지 만든 다음, 모든 장면을 렌더링하여 2D 영상으로 제작/배포한다. 즉, 아무리 많은 데이터를 이용해서 렌더링을 하더라도 렌더링된 장면은 지정된 해상도의 크기를 넘지 않는다. (HD급(1080p)은 장면당 1920x1080x4 bytes 만큼) 하지만, 실시간으로 렌더링하기 위해서는 렌더링에 필요한 모든 데이터가 필요하므로 배포해야할 데이터의 양이 기하급수적으로 늘어나게 된다. 또한, 기존의 2D 영상 압축 기술은 기본적으로 연속된 장면에서 중복 데이터를 제거해서 압축 효율을 높이는 것이다. 이를 위해 앞, 뒤에 있는 장면들을 재활용하는 등의 다양한 기술이 활용되는데, 3D 영상 압축 기술은 렌더링에 필요한 폴리곤, 텍스처, 애니메이션 등 데이터의 특성에 맞는 새로운 압축 기술이 필요하다.

우선 물체의 형태를 표현하는 폴리곤과 애니메이션에 대해 살펴보자. 기존의 3D 게임이나 그래픽 관련 작업을 해본 사람은 알겠지만, 일반적으로 3D 모델링을 할 때는 세 개의 점을 연결한 삼각형(폴리곤)을 이어붙여서 물체를 표현한다. 그래서 물체를 매끈하게 표현하기 위해서는 무수히 많은 폴리곤이 필요해지는 것이다. 이외에도 NURBS 와 3차원 베지어 곡선과 같은 수학적인 표현기법을 이용하는 경우도 있지만, 서로 다른 장단점을 가진다. 2차원 그래픽과 비교해서 설명하면, 폴리곤이 비트맵 방식이고, NURBS 가 벡터 방식이라고 보면 된다. 폴리곤은 표현의 자유도가 높지만 해상도와 애니메이션에서 문제가 있고, NURBS 는 자유도는 조금 낮지만 해상도와 애니메이션에서 장점을 가지고 있다. 그래서 물체의 애니메이션을 어떻게 나타낼지는 물체의 형태를 어떻게 표현했는지와 직접적인 연관이 있다. 경우에 따라 하나하나 따져봐야하지만, 실사 느낌이 강할 수록 폴리곤이 유리할 것이고, 겨울왕국 같은 애니메이션 느낌이 강할 수록 NURBS 와 같은 수학적인 표현기법이 유리할 것이다. (실제로 2D 에서도 비슷한 형태로 사용된다. 실사 사진이나 복잡한 이미지를 저장할 때는 JPEG 나 PNG 를 사용하고, 간단한 아이콘이나 이미지를 저장할 때는 SVG 와 같은 벡터 방식을 주로 사용한다.)

그리고 물체의 표면을 표현하는 방식에는 텍스처와 재질이 있다. 텍스처는 말그대로 물체의 표면에 특정 이미지를 덮어씌우는 용도로 사용되고, 재질은 전역 조명 렌더링에서 주로 사용되는 방식으로 물체가 가지는 물리적인 성질을 표현하는 용도로 사용된다. 예를 들어, 거울이나 플라스틱, 철과 같은 느낌은 적절한 재질과 적절한 렌더링을 통해 표현될 수 있다.

이처럼 3D 영상을 렌더링하기 위해서는 다양한 데이터가 필요하고, MPEG 에서는 폴리곤, 텍스처(재질), 애니메이션 각각의 데이터에 맞는 압축 기법을 제시하고 있다. 하지만 위에서 설명한 것처럼 3D 영상을 표현하는 방식에도 다양한 형태가 존재하고, 아직 구체적인 사례가 거의 없기 때문에 MPEG 에서 정의된 내용들은 아직은 초기 단계라고 보는 것이 좋을 것 같다.

Advertisements

[TECH] 3D 영화의 미래?!

지금까지 3D 영화라고 하면 단순히 입체감이 느껴지는 정도의 영화를 의미했다. 하지만 앞으로 나올 3D 영화는 그 정도 수준이 아니라, 내가 마치 영화 속 공간 안에 실제로 있는 듯이 주변을 자유롭게 둘러보면서 원하는 장면을 볼 수 있는 것을 의미한다. 정확히 무슨 의미인지 이해가 안 간다면 오큘러스 리프트와 같은 가상 현실 장치를 생각해보라. 오큘러스 리프트는 헤드 트래킹을 통해 사용자가 마치 3D 공간 안에 있는듯한 착각을 느끼게 하는 기술로, 최근 페이스북 뿐 아니라 삼성까지 큰 관심을 가지고 있는 기술이다. 즉, 앞으로 나올 3D 영화는 오큘러스 리프트와 같은 가상 현실 장치를 이용하여 감상할 수 있는 영화를 의미한다는 것이다. 기존 영화처럼 하나의 시점을 따라가면서 촬영된 영상을 감상하는 것이 아니라, 감상자가 원하는 시점을 선택해서 감상할 수 있다는 것이다. 여기에는 다양한 새로운 연출 기법들이 필요할 것이다. 감상자의 위치를 어떻게 변경할 것인가, 장면을 어떻게 변경할 것인가 등등등…하지만 오늘은 가장 기본적인 3D 영화에 사용할 영상을 어떻게 제작할 것인가에 초점을 맞춰 살펴볼 계획이다.

3D 영상을 만드는 가장 좋은 방법은 영화 속에 등장할 모든 물체를 3D 로 제작하는 것이다. 하지만, 현재 3D 모델링과 애니메이션의 한계로 섬세한 물체를 표현하는 것은 한계가 있고, 또한 감상자의 시점에 따라 실시간으로 렌더링을 하는 것도 아직은 미흡하기 때문에 다른 대체 기술이 필요하다. 그래서 상당히 제한적이지만 충분한 활용 가치를 가지고 있는 것으로 보이는 3D 영화 제작 기술을 가지고 있는 스타트업이 큰 관심을 받고 있다.

https://www.facebook.com/jauntvr

위 링크는 JAUNT 라는 스타트업의 페이스북 페이지이다. 이 스타트업은 360 도를 한번에 촬영할 수 있는 새로운 카메라를 개발하고, 이를 활용하여 실제 영화를 제작 중이라고 한다. 이는 앞에서 설명한 3D 모델링/렌더링 기반의 영화와는 서로 다른 장단점을 가진다. 해당 기술을 이용하면 실사 영화 제작이 가능하고, 영화 감상에 큰 부담이 없지만, 원하는 시점에서 볼 수 있는 장면은 3D 가 아니고, 미리 촬영된 2D 영상일 뿐이라는 것이다. 하지만 이 또한, 앞으로 나올 다양한 3D 영상 제작 기술 중의 하나일 뿐이니, 생각보다 별거 아니네라고 실망할 필요는 없다.

사실 필자가 개인적으로 관심을 가지고 있고, 2년 전부터 개발해왔던 실시간 레이트레이싱 기술을 이용하면 좀 더 혁신적이고, 도전적인 3D 영화 제작이 가능하다.

위의 영상은 3D 모델링과 애니메이션으로 제작하고, 실시간 레이트레이싱 기술을 이용하여 렌더링한 영상이다. 사실 대충 보면 실사 영상이라고 느껴질만큼 놀랍지만, 자세히 보면 사람과 같이 섬세한 표현이 필요한 물체가 없고, 영상에 노이즈가 많이 껴있는게 보일 것이다. 하지만, 이렇게 실사 느낌의 렌더링이 아니라, 현재 드래곤 길들이기나 겨울왕국 같은 스타일의 렌더링을 한다면 훨씬 안정적인 렌더링이 가능할 것이다. (개인적으로는 앞에서 언급했던 스타트업의 방식보다 3D 애니메이션을 이용한 3D 영화가 훨씬 더 재밌을 것 같다는 생각이 든다. 사실, 1년 전쯤에 같이 일하는 후배들에게 오큘러스 리프트와 실시간 레이트레이싱 기술을 이용한 3D 영화를 제작해보면 굉장히 재밌을것같다는 얘기를 한적이 있다. 정말 하고 싶은 일 중의 하나이다.)

재밌는건, 이러한 3D 영화가 실제 제작되기 시작하면 기존의 영화관에서는 상영이 불가능하다. 가장 큰 이유는 기존의 3D 영화와 달리 앞으로 나올 3D 영화는 감상자마다 시점이 모두 다르기 때문에 결국, 개인 상영관 밖에 존재할 수 없다는 것이다. 사실 영화관보다는 현재의 DVD 방과 같이 개인 감상실 같은 형태로 운영될 것으로 예상된다. 어찌됐든 앞으로 3D 영화 제작 기술이나 시장이 어떻게 흘러갈지 개인적으로 무척(!) 기대가 된다.

[TECH] 리눅스 DIRECTX 지원 방식 소개

오늘은 리눅스에서 DIRECTX 를 지원하는 방식에 대해 간단히 살펴보도록 하겠습니다. 가장 기본적으로는 윈도우 에뮬레이션 기능을 제공하는 WINE 이 떠오르실텐데요, 이외에 어떠한 방식들이 있는지, 그리고 어떤 차이점들이 있는지를 알아보도록 하겠습니다.

d3d9

위의 그림에 나와있는 것처럼, 현재 리눅스에서 DIRECTX 를 지원하는 프로젝트는 세 가지 정도가 있습니다. 첫 번째는 가장 유명한 WINE 이고, 두 번째는 VALVE 에서 윈도우용 게임을 포팅하기 쉽게 도와주기 위해 만든 ToGL 이라는 프로젝트이고, 세 번째는 MESA 에서 제공하는 D3D9 state tracker 입니다. 우선 가장 큰 차이점은 WINE 과 ToGL 은 DIRECTX 를 OPENGL 인터페이스와 셰이더(GLSL)로 변환해주는 방식이지만, D3D9 state tracker 는 MESA 에서 DIRECTX 인터페이스를 바로 처리해주는 방식입니다. 그래서 직접 테스트해보진 않았지만 D3D9 state tracker 가 WINE 에 비해 성능이 월등히 좋다고 합니다. (당연한 결과겠죠?!) 하지만 그림에 보시는 것처럼 WINE 과 ToGL 은 오픈소스 드라이버뿐 아니라 NVIDIA/AMD 드라이버까지 지원하지만 D3D9 state tracker 는 당연히 MESA 에서만 지원하고 있습니다. (그래서그런지 WINE 측에서는 반응이 시큰둥한 것 같습니다.) 그리고 WINE 과 ToGL 도 확연히 다른 목표를 가지고 있는데요, WINE 은 DIRECTX 전체를 에뮬레이션하는 것이 목표지만, ToGL 은 리눅스로 포팅하기 쉽게 도와주고 성능도 최대한 유지하는 것이 목표입니다.

이 세 가지 프로젝트가 향후 어떻게 흘러가는지 살펴보는 것 또한 소소한 재미가 될것 같습니다. 앞으로 점점 더 많은 게임엔진과 게임들이 OPENGL 을 지원하게 되면 굳이 이런 짓(?)을 할 필요는 없어지겠지만…

[TECH] 멀티미디어 인터페이스 (Display Port)

본체에 모니터를 연결하는 멀티미디어 인터페이스에도 여러 가지 종류가 있습니다. 과거에 많이 사용되던 D-SUB 나 컴포지트 같은 아날로그 인터페이스도 있었고, DVI 같은 디지털 인터페이스도 있었습니다. 그리고 최근 많이 사용되고 있는 HDMI 는 디지털 영상과 음성까지 전달할 수 있고 케이블도 작아서 여러 기기에서 사용하기 편리하지만, 라이센스를 맺고 특허 사용료를 지불해야 하는 문제가 있다고 합니다. 이를 해결하기 위해 나온게 PC 업체들이 주축이 되서 만든 디스플레이 포트(Display Port)인데요, 오늘은 간단히 디스플레이 포트가 어떤 장점을 가지는지, 향후 어떻게 활용될 수 있을지에 대해 살펴보도록 하겠습니다.

우선, 디스플레이 포트는 HDMI 가 AV 업체들(소니, 파나소닉, …)이 주축이 되어서 만들어진 것에 비해 PC 업체들이 주축이 되어 만들어졌습니다. 그래서 그런지 USB 랑 상당히 유사해 보입니다. 디지털 영상 뿐 아니라 음성까지 하나의 케이블을 통해 멀티플렉싱할 수 있기 때문에 전송할 수 있는 영상이나 음성의 포맷에 제한이 없습니다. 본체와 멀티미디어 기기간의 프로토콜만 맞다면 다양한 영상/음성 포맷의 데이터를 주고 받을 수 있습니다. 또한 MST(Multi-Stream Transport)라는 이름으로 멀티 채널 기능을 제공합니다. 이는 여러 개의 영상/음성을 하나의 케이블을 통해 전송할 수 있다는 얘긴데요, 간단히 얘기하면 본체에서 하나의 케이블로 3개의 영상/음성을 보내면 데이지-체이닝(Daisy-Chaining) 이나 허브를 통해 3개의 모니터에 각각의 영상/음성을 전송할 수 있다는 얘깁니다. 그리고 전송 속도도 현재 주로 사용되고 있는 HDMI 1.4 의 10.2 Gbps 보다 높은 17.28 Gbps (DP 1.2 버전 기준) 를 제공합니다. 그래서 최근 필자가 구매한 4K 모니터 (3840×2160) 에서는 60 hz 를 사용하기 위해서는 반드시 디스플레이 포트를 사용해야 합니다. (4K 모니터에서 60 hz 를 구현하기 위해 필요한 대역폭이 약 15 Gbps 정도 됩니다.)

사실 필자가 디스플레이 포트에 주목하는 가장 큰 이유는 바로 멀티 채널 기능입니다. 간단한 예를 하나 들어보면, 현재 두 개의 모니터를 미러링하기 위해서는 (해상도가 같다면) 본체(GPU)에서 하나의 프레임버퍼를 두 개의 모니터로 스캔-아웃해주는 방식을 사용합니다. 하지만 디스플레이 포트를 잘 활용한다면 본체는 하나의 영상/음성 스트림만을 전송하고 데이지 체이닝으로 연결하거나 허브를 이용해서 동일한 스트림을 두 개의 모니터가 받아서 화면에 뿌려주면 됩니다. 본체에 부담도 덜어줄 수 있고 동기화도 쉬워지겠지요. 또한 더 나아가서 멀티 디스플레이를 지원할 때도 유리할 꺼라 생각합니다. 본체에서 각각의 화면에 뿌려질 데이터를 여러 채널로 나누어서 전송할 수도 있을 것이고, 본체에서는 하나의 큰 화면을 만들어서 뿌리고 허브에서 각각의 모니터에 맞게 화면을 쪼개서 뿌려줄 수도 있습니다. 아직은 대역폭이 그만큼 나오지 않고 지원하는 장비가 없기 때문에 이런 형태의 사용은 불가능하지만, 결국 이런 것들을 하기 위해 나온게 디스플레이 포트이기 때문에 머지않아 실현될 수 있을 것으로 기대됩니다.

마지막으로 이러한 기능을 제대로 활용하기 위해서는 소프트웨어 쪽도 많은 것들이 준비가 되어있어야 하는데요, 현재는 레드햇에서 MESA/DRM 에 디스플레이 포트를 지원하는 작업을 진행하고 있습니다. 하지만 이제 시작하는 단계라서 꽤 시간은 걸릴꺼같습니다.

[TECH] NVIDIA ‘G-SYNC’ GPU-디스플레이 동기화 기술 소개

NVIDIA 에서 G-SYNC 라는 새로운 GPU-디스플레이 동기화 기술을 공개했습니다. 상당히 흥미로운 기술이고 실제 게임 개발자들에게도 큰 환영을 받고 있는 것 같습니다. 아래 동영상을 보면 존 카멕을 비롯한 3명의 유명 게임 개발자들이 G-SYNC 에 대해 호평을 하고 있는 것을 볼 수 있습니다. (다른 그래픽 관련 소프트웨어를 개발하는 사람들에게도 분명 희소속이긴 하지만, 렌더링 시간과 사용자 반응성에 가장 민감한 실시간 3D 게임 쪽에서 가장 효과가 극명할 것 같습니다.)

http://www.geforce.com/hardware/technology/g-sync/videos

오늘은 G-SYNC 에 대한 기술적인 부분들을 간단히 소개드리도록 하겠습니다. 우선 G-SYNC 가 있을 때와 없을 때의 가장 큰 차이를 한 마디로 표현하면 GPU 가 디스플레이의 고정된 화면 갱신 비율을 그대로 따를 것이냐(G-SYNC 가 없을 때), 아니면 GPU 가 디스플레이의 화면 갱신 시기를 알려줄 것이냐(G-SYNC 가 있을 때)입니다. 2013년도에 NVIDIA 가 G-SYNC 를 발표하면서 공개한 자료를 보면서 좀 더 자세히 설명드리도록 하겠습니다.

gsync0위의 그림은 이상적인 GPU 와 디스플레이의 관계를 보여주고 있습니다. 디스플레이 패널(panel)은 고정된 주기로 GPU 가 준비해놓은 프레임버퍼를 스캔(scan)하고, GPU 는 다음 주기까지 다음 프레임버퍼를 준비하는데 문제가 없다면 가장 이상적입니다. (일반적으로 이러한 방식을 V-SYNC, Vertical Sync 라고 합니다.) 하지만 아래 그림처럼 GPU 가 다음 프레임버퍼를 준비하는 것이 조금이라도 늦어지면 다음 화면 갱신 주기를 기다려야하는 문제(lag)가 발생하게 됩니다. (이런 이유로 렌더링 시간을 예측하기 힘든 3D 게임 분야에서 관련 문제가 자주 발생한다는 것입니다.)

gsync1이러한 화면 갱신 지연 문제를 해결하는 가장 간단한 방법은 바로 V-SYNC 를 무시하는 것입니다. 즉, GPU 는 다음 VBLANK(Vertical Blank, 화면 갱신이 끝나고 다음 화면 갱신까지 기다리는 시간) 를 기다리지 않고 강제로 프레임버퍼를 바꿔버리는 겁니다. 아래 그림처럼 일단 화면 갱신이 지연되는 문제는 해결이 되긴 합니다.

gsync2하지만 이 방법은 화면 잘림(tearing) 이라는 새로운 문제를 만들어냅니다. 아래 그림을 보면 알 수 있듯이, 디스플레이가 스캔을 하고 있는 도중에 프레임버퍼가 변경이 되면 화면의 중간까지는 이전 프레임이고 중간 이후부터는 다음 프레임이 나타나는 괴현상이 발생하게 됩니다.

gsync3

gsync4이러한 복잡한 상황들을 한번에 해결하기 위해 나온 기술이 바로 G-SYNC 라고 보시면 됩니다. 즉, NVIDIA 는 현재의 디스플레이가 주도하는 고정된 화면 갱신으로는 이 문제를 깔끔하게 해결할 수는 없다고 보고, 역으로 GPU 가 디스플레이의 화면 갱신을 제어하겠다는 것입니다. 동작 과정은 아래 그림처럼 굉장히 단순합니다.

gsync5GPU 가 프레임버퍼를 렌더링한 후, 디스플레이에게 화면 갱신 명령어를 전달하게 되면 디스플레이는 현재 프레임버퍼를 스캔해서 실제 화면을 갱신하게 됩니다. 프레임버퍼를 생성하는 주체인 GPU 가 실제 화면 갱신을 제어하기 때문에 오히려 동작 과정도 단순해지고, 문제가 생길 여지가 사라진걸 알 수 있습니다. (단순히 영상을 보는 용도의 TV 에서 사용되던 기술이 사용자 반응성이 중요한 컴퓨터에까지 적용되어 발생했던 문제를 현실적으로 해결한 접근이라고 볼 수 있을 것 같습니다.)

이 문제는 리눅스에서 DRM 을 이용해서 그래픽 관련 소프트웨어(윈도우 매니저, …) 를 개발할 때도 발생합니다. 현재의 DRM 에서는 PAGE_FLIP 이라는 API 를 제공하는데, 이 API 의 역할이 요청한 프레임버퍼를 다음 VBLANK 에서 갱신해달라는 것입니다. 이걸 사용하기 싫으면 직접 VBLANK 이벤트를 받아서 처리할 수도 있고, 이를 무시하고 바로 화면을 갱신할 수도 있습니다.

현재 리눅스에서는 NVIDIA 에서 제공하는 최신 드라이버에서는 G-SYNC 를 사용할 수 있을 꺼라고 합니다. 하지만, 여러 가지 이유로 오픈소스 드라이버를 사용할 수 밖에 없는 입장이라서 얼른 NOUVEAU/DRM 에서 G-SYNC 를 지원해줬으면 하는 바램이 있습니다.

[CODE] GOBJECT-INTROSPECTION 간단 예제

여러 대기업들이 새로운 언어를 심심하면 만들어대는 바람에 개발자들이 공부해야 하는 언어가 점점 늘어나는 것 같습니다. 그리고 이미 UI/UX 관련 어플리케이션을 개발할 때는 두 개 이상의 언어를 섞어서 사용하는 경우가 점점 많아지고 있는데요, 대표적으로 gnome 같은 경우에는 컴포지터(mutter) 는 C 언어로 되어있고, 쉘(gnome-shell) 의 대부분의 UI 컴포넌트들은 자바스크립트 혹은 C# 으로 되어있습니다. 일반적으로 성능이 필요하거나 시스템 자원에 직접 접근해야 하는 경우에는 주로 C 언어가 사용되고, 작은 UI 컴포넌트를 개발할 때는 빠르고 쉽게 작업하기 위해 자바스크립트와 C# 같은 언어가 자주 사용되는 것 같습니다.

예전부터 두 개 이상의 언어를 바인딩 하는 방법은 여러 가지가 있었는데, 오늘은 간단하게 오픈 소스 진영에서 자주 사용되는 gobject 를 기반으로 한 gobject-introspection 에 대해 소개드리도록 하겠습니다.

gis

위의 그림처럼 기존에는 C 언어로 되어있는 GTK+ 를 다른 언어에서 직접 사용하기 위해서는 PyGTK 나 GTK# 같은 별도의 추가적인 라이브러리가 필요했습니다. 그래서 언어별로 따로 지원하는게 너무 힘들고 귀찮은 일이니 이걸 한방에 해결하기 위해 나온게 gobject-introspection 이라는 기술입니다. 간단히 말해 오른쪽 그림처럼 gobject-introspection 을 지원하는 모든 언어끼리는 아주 쉽게 서로 연동이 가능해진다는 겁니다.

사용 방법은 간단합니다. GTK+ 를 다른 언어에서 사용하고 싶으면 (g-ir-scanner/g-ir-compiler 툴을 이용해서 당연히 자동으로) GTK+ 를 스캔해서 GTK+ 가 제공하는 외부 인터페이스 정보(typelib) 를 생성하면 끝입니다. 그리고 자바스크립트에서 사용하고 싶으면 gobject-introspection 에서 제공하는 런타임 라이브러리(libgirepository) 를 이용해서 GTK+ 가 제공하는 외부 인터페이스를 사용하기만 하면 됩니다.

간단하게 C 언어로 공유 라이브러리를 개발해서 자바스크립트에서 사용하는 예제를 공유해드릴테니 관심있으신 분들은 살펴보시면 도움이 될 것 같습니다.

https://github.com/haruband/gobject-introspection-example

위의 예제는 자바스크립트에서 C 언어로 되어있는 객체의 속성을 읽거나 쓰고, 외부 함수를 호출하는 기능과 C 언어에서 자바스크립트의 콜백 함수를 호출하는 기능이 들어가있습니다. 자바스크립트 엔진은 gnome 에서 사용하는 gjs 를 사용하였고, 빌드는 일단 제가 cmake 로 자동화시켜놨으니 그냥 하시면 되고, 실행할 때는 C 언어로 되어있는 공유 라이브러리와 typelib 의 위치를 신경써서 실행하시기 바랍니다.

개인적으로 NEMOSHELL 에서 자바스크립트로 되어있는 수많은 시각화 라이브러리를 재활용하기 위해 시작했는데 꽤 괜찮을꺼같습니다. 최근 나온 자바스크립트 라이브러리들이 대부분 HTML5 의 캔버스 기능을 이용해서 렌더링하기 때문에 이것만 네이티브의 wayland 와 cairo 로 잘 엮어주면 아주 효과적으로 사용할 수 있을것 같습니다.

[TECH] SF 영화에 나오는 테이블탑 컴퓨팅 소개

어벤저스와 같은 SF 영화에 자주 등장하는 컴퓨팅 환경은 우리가 일상적으로 사용하는 컴퓨팅 환경과는 상당히 다른 모습이다. 대부분 디스플레이는 크고 투명하며, 인터페이스는 터치 혹은 컴퓨터 비전을 이용하는 방식이다. 그리고 전반적인 UX (User eXperience)는 애니메이션과 같은 동적 효과를 잔뜩 포함하고 있으며, 여러 사람이 동시에 사용하는 모습을 자주 보여주고 있다. 그런 걸 보면 누구나 저게 실제 가능한건가? 가능하다면 언제쯤 사용할 수 있나? 궁금할텐데 오늘은 그에 대한 간단한 기술적인 얘기들을 하려고 한다.

아래의 어메이징 스파이더맨 2 트레일러의 40초 부분에 잠깐 스쳐지나가는게 필자가 말하는 테이블탑 컴퓨팅이다. 실제 영화를 보면 기존의 영화보다는 꽤 길고 자세하게 사용하는 모습을 보여준다.

우선 필자의 블로그에서 관련 글을 읽어본 사람이라면 알겠지만, 필자가 하는 일이 바로 SF 영화에 나오는 그런 컴퓨팅 환경을 여러 가지를 고려해서 실제 사용 가능한 수준으로 개발하는 것이다. 하지만 필자의 전문분야는 ‘시스템 소프트웨어 개발’이기 때문에 UX 적인 측면에 대한 이야기보다는 소프트웨어 관련된 기술적인 이야기들을 주로 할 것이다.

우선 첫 번째로 디스플레이를 살펴보자. 현재 가정에서 사용하는 TV 도 상당히 큰 사이즈이고, 길거리를 돌아다니다보면 굉장히 큰 디스플레이를 보는 것도 어려운 일이 아니다. 그리고 투명 디스플레이도 몇 년전부터 여러 대기업들이 줄기차게 광고를 해왔고 얼마 전에 강남역 2호선 지하철 타는 곳에 50인치 정도되는 투명 디스플레이 네 개를 이어붙여서 만든게 설치되었다. 물론 아직은 단순히 광고를 보여주는 수준이지만, 올해부터 국내 두 대기업을 중심으로 대형 투명 디스플레이가 활용 범위를 점점 넓혀갈 것으로 보인다.

그리고 두 번째로 인터페이스를 살펴보자. 우리가 스마트폰에서 사용하는 터치는 정전식인데, 대형 터치 스크린에서 주로 사용되는 방식은 적외선 방식이다. 적외선 방식도 여러 가지가 있는데 가장 많이 사용되는 방식은 측면에서 적외선을 쏘는 방식이다. 즉, 사각형 형태 스크린의 네 개의 테두리가 서로 마주보며 적외선을 쏘아서 스크린 가까이에 손가락이 어느 위치에 올려져 있는지를 알아내는 방식이다. 그리고 또 하나가 제프 한이라는 재미 교포가 만든 스크린 뒤에서 앞으로 적외선을 쏘는 방식이다. 아래 동영상은 제프 한이 2006년도 TED 에 나와서 발표한 내용이다. 이 연구는 제프 한의 학위 논문 주제이고, 이후에 설립한 회사가 MS 에 인수합병되어 현재는 MS 에 근무하고 있는 걸로 알고 있다. (이것도 제품화가 되었는데 MS 에서 PixelSense 라는 이름으로 공개했고, 이걸 삼성에서 Sur40 이라는 이름으로 양산해서 팔고 있다.)

어메이징 스파이더맨 2를 유심히 본 사람은 기억하겠지만, 영화 중간에 해리 오스본이 사무실에서 아버지가 준 작은 물체를 테이블탑 위에 실수로 떨어뜨리자 테이블탑이 물체를 정확히 인식해서 관련된 정보를 보여주는 장면이 있다. 이건 현재도 PixelSense 에서 제공하는 tag 라는 기능으로 비슷하게 흉내는 낼 수 있다. 간단히 생각해보면 알겠지만 측면 적외선 방식은 스크린의 어느 위치에 빛을 가로막는 물체가 올려졌는지 밖에 인식할 수 없지만, 후방 적외선 방식은 화면위에 어떤 모양의 물체가 올려져있는지도 알 수 있다. (실제로 PixelSense 를 이용해서 개발할 때는 후방 적외선 카메라로부터 들어온 영상을 분석해서 사용한다.) 그래서 일종의 바코드같이 생긴 tag 를 물체의 바닥에 부착하면 화면의 어느 위치에 해당 물체가 올려졌는지 정도는 인식할 수 있게 된다. 아래 동영상에서 유사한 기능을 사용하는 예를 보여주고 있다. 하지만 PixelSense 는 상대적으로 가격이 상당히 비싸고, 주변의 빛에 영향을 받는 등의 문제가 있어 아직 널리 사용되고 있진 않은 것 같다. (우리도 처음에는 PixelSense 를 구매하려고 했지만 가격의 압박과 리눅스 지원 문제 등으로 PQLabs 에서 나온 제품을 구매했다;;)
* 시중에서 쉽게 구할 수 있는 DELL, Samsung 터치 디스플레이에서도 잘 동작한다. (2014.11 업데이트)

그리고 마지막으로 가장 중요한 소프트웨어 이야기를 하도록 하겠다. 사실 하드웨어는 어느 정도 준비가 되었다고 볼 수 있다. 하지만 문제는 소프트웨어, 특히 플랫폼은 아직 굉장히 미흡하다는 점이다. 테이블탑에서 사용할 수 있는 서비스를 개발하는 건 크게 보면 두 가지 방식이 있다. 스마트폰처럼 전체 스크린을 하나의 어플리케이션이 독점해서 사용하는 방식과 데스크탑처럼 여러 어플리케이션이 동시에 동작하는 방식이다.

현재까지는 제한된 활용 분야와 여러 가지 이유로 전체 스크린을 하나의 어플리케이션이 독점하는 방식이 주로 사용되어 왔다. 이 방식의 장점은 원하는 서비스를 지원하는 어플리케이션을 그냥 개발만 하면 된다는 것이고, 단점은 필요한 서비스가 하나의 어플리케이션 안에 모두 들어가 있어야 한다는 것이다. (하나의 어플리케이션이 전체 화면을 덮고 있기 때문에 해당 어플리케이션이 보여주는 화면만이 보여진다.)

반대로 데스크탑처럼 여러 어플리케이션이 동시에 동작하는 방식은 일반적으로 윈도우 매니저라는게 필요한데, 이 방식의 장점은 여러 어플리케이션을 동시에 띄을 수 있기 때문에 여러 서비스를 필요에 따라 분리해서 개발할 수 있고, 그래서 재활용성도 높아진다. 하지만 현재까지 이러한 테이블탑 환경을 지원하는 윈도우 매니저가 없기 때문에 이걸 새로 개발해야 한다는 문제가 있다. (기존의 데스크탑 환경에서 사용하던 윈도우 매니저는 혼자서 키보드와 마우스를 이용해서 사용하는 컴퓨팅 환경에 최적화되어 있다.) 바로 이 문제를 해결하기 위해 나온 윈도우 매니저가 NEMOSHELL 이다. 아직 해야할 일이 굉장히 많긴 하지만…

최근 국내/외 분위기를 보면 앞으로 3~5년 뒤가 너무 기대된다. IT 의 가장 큰 매력은 다른 분야와 달리 순식간에 우리의 삶을 뒤바꿀 수 있다는 점인 것 같다. 내가 늘 꿈꾸는 그런 세상, IBM 에서 만든 EVERYWHERE COMPUTING 이라는 말이 이제 정말 손에 잡힐듯 다가오는 것 같다.