'프로젝트 롬'으로 리퀴드 컴퓨팅에서 한 발 앞서 나가는 마이크로소프트

애플이 2014년 iOS 8과 OS X 요세미티에서 핸드오프 기술을 처음 공개했을 당시 필자는 데이터와 애플리케이션 상태가 사용자의 이동에 따라 여러 기기 사이에서 전달되는 리퀴드 컴퓨팅(Liquid Computing)이라는 개념에 매료됐다. 그러나 이 기술은 애플 앱 이외에는 거의 구현되지 않았으므로 큰 관심을 끌지 못했고, 애플 워치라도 사용하면 모를까 그렇지 않은 대부분의 사용자는 그런 기능이 있는지 인식조차 하지 못했다.

지난 주 빌드 2016 개발자 컨퍼런스에서 발표된 내용에 따르면 마이크로소프트는 윈도우 PC와 스마트폰을 위한 프로젝트 롬(Project Rome) API 발표를 준비 중이며 iOS와 안드로이드를 위한 SDK도 출시할 계획이다. 다만 마이크로소프트는 데스크톱 시장에서의 하락세를 여전히 인정하기 싫은지 OS X용은 뺐다.

프로젝트 롬은 핸드오프와 비슷한 점도 있고 다른 점도 있는데, 그 다른 점들이 아마 핸드오프보다 더 널리 도입되는 데 힘이 될 것으로 보인다.

사실 마이크로소프트는 과거 윈도우 8 시절에도 일종의 크로스 디바이스 기능을 내놓은 적이 있다. 다만 그 기능은 같은 계정에 연결된 기기에서 북마크와 설정을 동기화하는 등 클라우드를 기반으로 한 과거 애플의 컨티뉴이티(Continuity) 서비스와 비슷한 기능이었다.

애플 핸드오프와 마이크로소프트 프로젝트 롬은 단순히 메타데이터를 동기화하는 것이 아니라 여러 기기에 걸쳐 앱을 연합하는 것이다. 여기서 여러 기기란 애플의 경우 iOS 8 또는 OS X 요세미티 이상을 실행하는 비교적 최신 맥, 아이폰, 아이패드, 아이팟 터치, 애플 워치를 의미하며, 마이크로소프트의 경우 윈도우 10 이상을 실행하는 윈도우 10와 윈도우 폰, 그리고 버전은 아직 공개되지 않았지만 iOS와 안드로이드 기기까지 포괄한다.

애플 핸드오프 기능
핸드오프는 한 기기에서 다른 기기로 애플리케이션 상태를 전달(hand off)하는 데 초점을 둔다. 예를 들어 아이폰의 메일 앱에서 이메일을 쓰다가 맥 근처로 이동하면 맥은 아이폰에서 메일이 실행 중임을 인식하고 현재 작성 중인 메시지를 아이폰에서 맥으로 전달할 수 있음을 알리고 맥에서 메일을 실행한다.

각 기기는 블루투스와 와이파이 다이렉트를 통해 서로 인식한다. 동일한 애플 ID를 사용하고 핸드오프가 활성화된 경우 자동으로 페어링된다.

핵심은 핸드오프는 전송의 실행dl 수신 기기에 따라 좌우된다는 데 있다. 즉, 사용자가 다른 기기로 이동했고 직전까지 작업했던 것을 가져오고자 한다는 개념이다. 다른 기기를 제어하는 개념이 아니다.

필자가 실제 환경에서 본 핸드오프의 가장 일반적인 사용 사례는 애플 워치와 아이폰 간의 핸드오프다. 애플 워치는 핸드오프를 사용해서 아이폰에 수신되는 전화, 문자 메시지, 이메일 메시지를 받을 수 있다. 핸드오프를 통해 맥 또는 아이패드에서 아이폰으로 온 전화를 받거나 아이폰으로 전송된 문자에 답할 수 있다.

핸드오프를 사용해서 예로 든 메일과 같은 앱 데이터를 전송하는 사람들은 많지 않다. OS X에서는 핸드오프가 가능한 부분을 쉽게 확인할 수 있지만, iOS 기기에서는 그 알림을 거의 인지할 수 없기 때문에 습관을 들이기 어려운 것도 그 이유 중 하나일 것이다.

마이크로소프트 프로젝트 롬
마이크로소프트 프로젝트 롬을 사용해서 핸드오프와 비슷한 상호 작용을 개발할 수 있다. 마이크로소프트 데모를 보면 일종의 리모트 컨트롤과 같이 작동한다. 프로젝트 롬에서는 첫 번째 기기가 두 번째 기기와의 상호 작용을 시작한다. 핸드오프의 경우 연결이 되어 있을 때 백그라운드에서 전송이 제안되고 두 번째 기기가 전송을 시작하는 것과 반대다. 또한 프로젝트 롬은 핸드오프보다 더 일반화되며 여러 가지 형태의 상호 작용을 제공한다.

첫째, 핸드오프가 로컬로만 작동하는 반면 프로젝트 롬은 블루투스 또는 와이파이를 통해 로컬로도 되고 인터넷을 통해서도 기기를 감지할 수 있다. 따라서 컨퍼런스 현장에서 회사 컴퓨터에 저장된 정보를 가져오거나 다른 위치에 있는 컴퓨터로 프레젠테이션 자료를 보내는 경우와 같은 원격 데스크톱 형태의 사용 사례에서 유용하다.

둘째, API가 추구하는 것은 여러 가지 앱 실행 프로토콜과 통신 페이로드의 조합을 사용하는, 마이크로소프트의 명칭을 따르자면 "앱 경험"이다.

가져올 콘텐츠를 확인하기 위한 URI(Uniform Resource Identifier)와 함께 다른 기기에서 앱을 실행하기 위한 API가 있다. 이 개념은 예를 들어 페이스북 앱을 설치해둔 사용자가 페이스북 게시물로 연결되는 링크를 클릭하면 브라우저의 페이스북 웹사이트가 아니라 페이스북 앱에서 게시물이 열려야 한다는 것이다. URI는 기본적으로 표시할 항목을 알아내기 위해 웹사이트에 위치하는 앵커 태그와 같이 사용된다. 사용자는 설정을 통해 이러한 링크를 앱에서 열지 또는 웹사이트에서 열지를 앱별로 조정할 수 있다.

앱 상호 작용을 다른 기기의 다른 앱 인스턴스로 확장하는 API도 있다. 예를 들어 폰에서 앱을 실행한 다음 데스크톱에서도 이 앱을 실행해서 두 앱이 모두 활성 상태로 상호 작용하도록 할 수 있다. 한 기기에서 영화를 보면서, 현재 영화의 어느 부분을 보고 있는지에 따라 다른 기기에서 영화와 관련된 퀴즈 게임을 진행할 수 있다. 이는 단순히 화면을 다른 기기로 보내는 애플의 에어플레이, 마이크로소프트의 와이다이(WiDi) 화면 미러링과는 다르다. 프로젝트 롬에서는 앱이 두 기기에서 모두 실행되며 두 인스턴스가 상호 통신할 수 있다.

여러 기기에 걸쳐 앱을 원격 제어하기 위한 API도 있다. 애플 키노트와 마이크로소프트 파워포인트에는 이미 이 기능이 있어 폰 또는 (애플의 경우) 워치에서 노트북 또는 태블릿의 프레젠테이션을 관리할 수 있다. 마이크로소프트는 프로젝트 롬에서 이와 같은 키노트, 파워포인트의 경우처럼 각 앱을 위한 맞춤 코드에 의존하지 않고도 폭넓게 원격 제어를 사용할 수 있는 API를 제공한다.

프로젝트 롬의 이점
프로젝트 롬은 핸드오프와 비교할 때 더 범위가 넓고 단일 업체의 생태계로 제한되지도 않는다. (물론 앞으로 마이크로소프트가 iOS와 안드로이드를 윈도우와 대등하게 대할지는 지켜봐야 하겠지만) 프로젝트 롬은 또한 핸드오프에 비해 더 많은 가능성을 가진 사용 사례를 다루며 이를 통해 개발자의 도입을 늘릴 수 있다. 이 두 가지 측면이 프로젝트 롬이 핸드오프보다 유리한 점이다.

그러나 지금까지 마이크로소프트가 공개한 것을 기준으로 보면 프로젝트 롬은 개발하기가 복잡할 수도 있다. 많은 작업을 다루고 로컬, 원격 연결을 모두 처리해야 하기 때문이다. 다행히 프로젝트 롬은 다양한 기존 윈도우 10 API를 확장하므로 윈도우 개발자는 이미 윈도우 10에서 습득한 지식을 활용할 수 있다.

프로젝트 롬을 통해 마이크로소프트가 애플보다 더 넓은 범위로 리퀴드 컴퓨팅의 개념을 실현할 수도 있음을 조심스럽게 낙관해 본다.  editor@itworld.co.kr


Read more: http://www.itworld.co.kr/news/98706#csidx512ef70cb9a299cb1beb1c0f3af3460 
Copyright © LinkBack