썰렁한 엔지니어

간만에 글을 이어 올립니다. 뭔가 마구 쏟아 낼것 같이 번호를 "1"로 붙인것이 후회되었습니다. 요즘 제가 글을 쓸 수 있을 정도로 머리속이 잠잠하지 않은데도 말이죠.

오픈소셜 컨테이너가 제공하는 필드

이번에 얘기하고 싶은 것은, 과연 오픈 소셜 어플리케이션이 얼마나 많은 기능을 컨테이너에게 요구하느냐입니다. 스펙은 한 사람에 대해 가져 갈 수 있는 필드에 대해 실로 많은 것이 정의 되어 있습니다. 그 중 대부분은 OPTIONAL입니다.

어플리케이션을 내가 설치해서 사용하겠다고 하는 순간, 사실 그 어플리케이션은 컨테이너가 제공하는 모든 필드에 접근이 가능한 형태로 구현이 됩니다. 물론, 제한을 가할 수 있습니다만, 그렇게 하게 되면, 어플리케이션에 허용된 필드 리스트를 관리해야하는 부담이 생길 수 있게 됩니다.

왜 이렇게 많은 필드가 있고, 그 필드들에 어플리케이션이 접근할 수 있는 권한을 줘야할까요? 실제 OPTIONAL이 아닌 필드 만으로도 왠만한 어플리케이션은 구현이 됩니다.

• 사용자 ID
• 이름
• 닉네임
  
• 썸네일 주소
• 친구 목록

그리고, OPTIONAL 중에서는

• GENDER
• DATE_OF_BIRTH - 생일
  
• AGE
  
• PROFILE_URL

정도를 활용할 수 있는 어플리케이션이 있을 수 있습니다. 게다가 조금더 제공가능하다면

• ADDRESSES
  
• SCHOOLS
  
• STATUS - 한 줄 상태, 오늘의 한마디
  

이 정도를 구현하면 어플리케이션에서 도움이 될 정도가 되겠습니다.

어플리케이션의 구현 모습

너무 당연한 리뷰인가요? 현재 복잡한 어플리케이션으로 성장하면 다음과 같은 구현이 됩니다.

• 자체 서버를 가지고 있습니다.
• 그 서버에 추가적인 정보를 두어 iframe으로 보이는 것이 대부분입니다.
• 이런 어플리케이션은 컨테이너에서 친구관계와 가장 기본적인 정보만으로 초기 설정이 됩니다.
• 어플리케이션을 사용하면 할 수록, 어플리케이션 서버에 데이터가 쌓이는 형태로 동작합니다.
• 어플리케이션이 제일 관심있는 것은 친구관계입니다.

간단한 어플리케이션은 컨테이너가 제공하는 정보로 구현이 됩니다. 이 어플리케이션은 간단한 데이터로 이루어지게 되며 복잡도가 떨어지지만 가볍고, 개인화된 특성을 지닐 수 있습니다. 예를 들어 그 사람의 시간대 정보만을 가지고 현재 시각을 보여주는 어플리케이션도 오픈소셜어플리케이션이라고 할 수 있습니다. 물론 친구관계를 이용하지는 않지만 오픈소셜 컨테이너가 제공하는 개인 정보로 구동되기 때문입니다.

예상되는 어플리케이션

느낌상 어플리케이션이 주로 인기를 끄는 것은 소셜게임이나 로맨스 요소가 들어간 것입니다. 또는 일상생활의 스케치가 계속 반영이 되는 중독성이 강한 요소들이 오래 발전하게 됩니다. 제가 생각하고 싶은 것은 미팅 주선 사이트나 성인 채팅 사이트까지도 오픈소셜에서 충분히 인기를 끌 수 있을 것이고, 아마 초창기 컨테이너 사업에서는 홍보상 자제해주었으면하는 바램도 있을지도 모르겠습니다만, 19세 이상 통제만 잘 이루어질 수 있다면, 예상할 수 없이 인기 어플리케이션이 될 수도 있습니다.

어플리케이션은 단지 위젯이 아닙니다. 하나의 사이트이며, 그 사이트의 홍보 대행을 컨테이너가 대신해주는 것입니다. 사이트 제작의 규모로 접근하지 않으면, 그다지 많이 깔리지 않을 것이고, 지속성이 없을 것입니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 최호진

짧은 기간 경험했던 오픈 소셜 플랫폼에 대한 경험을 공유하고자 이렇게 정리하는 마음으로 글을 씁니다. 아직까지는 플랫폼이 많이 나오지 않은 상황에서, 어줍잖은 경험이나마 공유할 만한 가치가 있을 것이라 생각되어 정리해봅니다. 글은 두서가 없을 것이며, 생각나는대로 주제를 잡아 끄적이는 노트라고 생각하시면 됩니다.

캔버스 모드의 어플리케이션은 사용자의 데이터를 사용해야 한다

전에 기술 세미나를 했을 때에도 한 말입니다만, 어플리케이션의 프로필모드는 소유자(owner)의 데이터를 가지고 구동이되며, 캔버스모드는 사용자(viewer)의 데이터를 가지고 구동이 됩니다. 이것은 오픈소셜에서 정의하는 것은 아니고, 일반적으로 그런 방식으로 구현이 된다는 것을 의미합니다. 이것으로, idtail에서 초창기 논란이 많았습니다만, 운영하다보니 나온 결론이었고, 마지막 개편안에는심지어

어플리케이션을 캔버스(canvas) 모드로 전환할 때, 소유자(owner)가 크게 부각되지 않아야한다였습니다.

설치냐 가입이냐

이야기를 더 진행하기에 앞서 먼저 해결해야할 문제가 있습니다.

어플리케이션과 사용자의 접근성을 설치 방식으로 하느냐 아니면, (표현이 이상하지만) 가입하는 방식으로 하느냐는 문제가 그것인데요. 어플리케이션을 설치한다라는 방식으로 접근을 하게 되면, 캔버스 모드로 동작할 때도 소유자의 공간에서 동작한다는 느낌으로 구현하게 됩니다. 또, 가입하는 방식으로 접근한다면, 어플리케이션은 하나의 내부 사이트이고 내부 서브 메뉴 중 하나를 방문하여 뭔가를 사용한다는 개념으로 구현될 것입니다. 마치 까페같은 것이겠죠.

어플리케이션이 위젯이라는 이름을 가지고 있을 때, 우리는 흔히 설치했다는 느낌을 갖게합니다. 여기에서 모든 생각이 꼬이기 시작합니다.

캔버스 모드 어플리케이션은 어플리케이션 자체가  UI의 중심에 있어야한다.

설치 개념으로 사이트가 구현되어 있는데, 소유자(owner)의 얼굴이 버젓이 보이는 공간에서, 사용자(viewer)의 정보나 사용자의 친구들이 화려하게 펼쳐(?)진다고 생각하면, UI가 굉장히 어색하게 됩니다.
캔버스 모드의 근본적인 성격 때문에, 가장 활동적인 모습을 보여주는 상황은 사용자 중심으로 동작하게 되며, 이 경우에 소유자 정보는 어플리케이션이 어떤 방식으로 시작해야할지에 대한 힌트로 사용되고, 어플리케이션이 동작하는 UI를 방해할만한 요소들(소유자의 얼굴사진 등)은 모두 제거 되는 것이 좋습니다.
예를 들어 어떤 사람의 프로필에 설치된 미니 서재를 클릭하여 캔버스로 확대할 경우와 내 프로필에서 캔버스로 확대할 경우, 소유자의 정보가 다르게 되고, 이 때 시작 위치를 다르게 하여 미니서재를 구동할 수 있을 것입니다.

즉, 어플리케이션이 이렇게 구현이 되면, 소유한 어플리케이션이라는 느낌보다 방문하는 서브 메뉴라는 개념으로 구현이 됩니다.

위젯...

어플리케이션 혹은 위젯이라는 개념이 일반 사용자에게는 생소합니다. 블로거들이 위젯을 설치하여 사용하지만, 블로그 시스템에서 절대 다수는 방문자일뿐 블로거가 아닙니다. 그런 위젯을 방문자 모두가 적극적으로 사용하는 상황이 SNS에 도입이 되는데, 이 때 설치한다는 느낌은 UI 면에서 실패할 가능성이 많을 것이라고 결론 지어봅니다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 최호진