개인적으로 Path라는 모바일 서비스를 좋아하는데, 마음에 드는 이유는 여러가지가 있지만 가장 근본적으로는 ‘모바일에서 시작해서 모바일에 오리엔테이션된 구성’을 가지고 있기 때문이고, 그에 대한 생각을 짧게 정리.

URL길이 제약과 브라우저 새창에 제한없던 PC, 제약 가득하던 트위터

PC를 기반으로 하는 웹서비스들의 경우에서는 URL주소 등의 길이라든가, 다른 서비스로의 이동은 큰 제약사항이 아니었다는 생각이 든다. 웹브라우저의 긴 주소창, 다중 탭/창으로 열어두는 활용성에 제약이 없었기 때문이다.

그런 와중에 트위터가 활성화되고 스마트폰이 본격화되면서 트렌드가 변하기 시작했는데, 트위터의 140자 제한과 텍스트 위주의 서비스라는 점으로 인하여, bit.ly라든가 t.co 같은 단축형 URL주소들이 출연하고, 이미지 등을 첨부할 수 있는 yfrog.com 같은 서비스들이 등장했다.

기존 PC기반에서는 제한없는 URL을 통해 새창/새탭을 통한 외부서비스로의 연동이, 짧은 URL을 중심으로 해서 트위터 안에서 보여지도록 서비스 내에 연동되는 현상으로 변하기 시작했다.

모바일과 API의 번성으로 인한 서비스간 직접 연동

꼭 트위터로 인한 트렌드 변화는 아니겠지만 비슷한 시기에 일어난 다양한 환경적 변화로 인해 여러 웹서비스들은 이제 API 활용을 통해서 보다 직접적으로 각각의 서비스들을 자신들의 서비스 안으로 연동하기 시작했고, 이것은 줄어든 URL주소마저 알 필요성을 줄어들게 하고 있다.

특히나 모바일을 태생으로 하는 서비스들은 앱내 서비스들의 URL을 제공하는 방식이 아니기 때문에, PC에서 태생한 서비스들과는 달리 단축 URL등을 제공하지 않는다는 점에서 사용자편의성의 증가를 보여준다고 생각한다.

Path, 링크없이 외부서비스를 철저히 내부 연동

모바일에서 시작해서 현재도 모바일 버전만 존재하는 Path를 보자면, 당연하게도 이 서비스에서는 링크 주소 같은 개념이 없다. (지금은 지원을 하지만) 심지어 얼마전까지는 유저가 텍스트로 직접 URL을 입력해도 링크되도록 처리조차 하지 않았었다.

이는 기존 PC기반의 서비스들이, 유저가 링크를 통해 얻고자 하는 최종 결과물이 어떤 것일까에 대한 고려보다는 기존 PC용 서비스들을 연결하는 것으로만 ‘개선’한 것과는 다른 점이다. 별 이야기 아닌 것이긴 하지만, 이러한 점이 PC 태생의 서비스들이 모바일로 ‘변화’하는 것과, 처음부터 모바일에서 태어난 서비스들과의 차이를 만든다고 생각한다.

Path와 페이스북에서의 Nike+ 서비스 연동 사례

아래는 Path와 페이스북에서 Nike+ 서비스 연동을 비교해본 화면이다.

우선 Path의 경우, 유저가 달린 내용을 앱 내부에 이미 간략히 요약한 내용으로 보여준다. 그리고 그 자세한 내용을 보려고 클릭하면, 지도상에 시작점/최고페이스지점/도착점 뿐만 아니라, 내가 달리고 있다는 것을 보고 cheer해준 친구가 있었던 지점까지도 Path 앱 내부에서 완전하게 보여준다.

그에 반해 페이스북의 경우, 링크를 제공해주고 해당 링크를 클릭하면 나이키의 사이트로 이동해서 PC버전의 루트를 보여준다. 이는 페이스북에서 통제할 수 있는 부분이 아니라, 나이키 쪽에서 유입되는 기기의 종류가 모바일이면 모바일버전으로 제공해주는 식이어야 하는 것이기 때문에 PC에서 시작한 페이스북의 링크형 연동으로는 제약적일 수 밖에 없다. (심지어 얼마전까지는 나이키 사이트가 플래시로 구현되어서 iOS에서는 빈화면만 덩그라니 보였었다.)

Path에서의 음악 공유 사례

Path에서 유저가 듣고 있는 음악을 태깅한 경우를 보면, 현재 듣고 있는 음악을 보여주고, 그것을 클릭하면 앱내 팝업으로 해당 음악이 바로 흘러나오면서 미리듣기가 진행되며, 뿐만 아니라 아이튠즈에서 바로 그 음악은 구입할 수 있도록 안내가 되고 있다.

페이스북도 이러한 연동이 가능할 수는 있겠지만 아마도 Path에서와 같이 앱 내부에서 바로 해당 음악의 미리듣기가 진행되는 방식이 아니라 아이튠즈로 이동 후에 유저들이 알아서 미리듣기를 해보든가 하는 식으로 진행될 가능성이 클 것이다, 그러한 추론의 이유는, PC를 기반으로 한 페이스북 입장에서는 아이튠즈 연동 고려시 PC환경에서는 곡 링크만 주면 PC/맥용 아이튠즈 프로그램이 실행되면서 거기서 편하게 미리듣기나 구입이 가능하다고 생각한 후에 모바일에서도 비슷한 구현을 할 가능성이 클 것이라고 생각하기 때문이다.

iOS용 앱의 UI와 안드로이드용 앱의 UI가 달라야 하듯, PC와 모바일도 각각 고려되어야

iOS용 앱들은 메뉴나 탭이 하단에 주로 위치하는 UI를 가지고 있다. 그러나 안드로이드의 경우에는 하단에 각종 버튼들이 있다 보니 메뉴나 탭을 화면 상단에 위치하도록 UI를 권하고 있다. 그럼에도 불구하고 개발의 편의성이나 동일 앱에서의 동일한 UX를 위하여 iOS나 안드로이드에 동일한 UI를 구성하면 사용자로서는 이용이 불편하기 마련이다. 마찬가지로 PC에서 편한 연동이 있고, 모바일에서 편한 연동이 있다면 각각을 고려하는 것이 맞겠지만, PC를 기반으로 시작한 서비스의 경우 모바일 태생 서비스처럼 고려하기란 쉽지 않은 것 또한 사실일 것 같다.