박종명의 아름다운 개발 since 2010.06

아이폰의 사파리 브라우징을 제공하는 사이트가 있었구먼

http://www.testiphone.com/

떱! 난 그것도 모르고 여태껏 내 아이폰 열어서 수동으로 확인했구먼...

이런.. 역시... Know Where 얌... 모르면 손발이 고생한다더니.. ㅎ

그리고 아래는 위 요청에 대한 응답 헤더와 바디 정보의 일부이다
응답 컨텐츠 타입이 자바스크립트이며 JSON 특유의(?) 데이터 포맷인 바디 구성이 눈에 띈다

비동기 호출 (갱신) 주기
그렇다면, 비동기 호출 주기는 과연 얼마로 설정했을까? 일명 폴링 주기이다

폴링주기는 웹 사이트의 성능과 웹 서버의 부담이라는 측면에서 최대한 긴 것이 좋으며
최대한 실시간 같은 갱신 효과라는 측면에서는 최대한 짧은 것이 좋다

폴링주기 설정은 사이트의 특징과 사용 패턴, 웹서버 가용성 및 규모, 네트워크 환경에 따라
환경에 맞도록 최적화 시키는 것이 중요한데, 트위터에서는 어떻게 했는지 궁금해 졌다

비동기 호출을 일정기간 캡쳐했다. 그리고 각 호출간 시간차를 살펴 보았다
재미있는 것은 폴링 주기가 일정하지 않다는 것이다

즉 호출간 매번 일정한 간격이 아니라 조금씩 다른 간격으로 호출되는 것이다
그러나 패턴은 있었다. 항상 같은 간격은 아니지만 간격의 패턴은 유지되고 있었다

대체로 살펴봤을때,
45초 -> 1분 7초 -> 45 - > 1분 7초....와 같은 패턴이 많이 보였으며,
경우에 따라 2분 32초 -> 3분 48초 -> 5분 -> 3분 48초 -> 2분 32초... 와 같은 패턴도 보였다

음... 트위터에서는 항상 같은 간격으로 호출하지 않는다는 것은 명백하다
그러나 일정한 패턴은 유지하고 있다. 그럼 이유는???

글쎄....
처음엔 어떤 상황에 따라 패턴이 분리되지 않나 싶어 꽤 오랫동안 지켜봤다
예를 들어 사이트가 로딩 된 후 사용의 행동이 오랫동안 감지 되지 않을 경우에 간격을 조정한다?
라는 식으로 말이다

즉 항상 일정한 폴링주기가 아니라 나름대로 상황에 맞게 최적의 주기를 설정한 것이 아닌가 했다.
그리고 그 상황과 패턴을 찾고 싶었다

몇 가지 가설을 세워놓고 꽤 오랫동안 패킷을 지켜봤으나 딱 떨어지지는 않았다
다시말해 폴링 주기가 일정한 패턴으로 변경되는 상황을 알 수 없었다

나의 가설이 틀렸던지 아니면 정말 랜덤일수도 있다
몇가지 주기를 설정해 두고 랜덤하게 꺼내 쓴다... 처럼...

뭐.. 어쨋던 정확한 상황을 알지 못했지만 (웬지 관련성이 있을 것만 같은) 한가지는 목격(?)했다
새로운 트윗이 생긴경우 since_id 파라메타 값이 바뀐다는 것이다
그리고 계속 이 since_id는 변화가 없다가 다시 새로운 트윗이 생기면 바뀌는 식이다

어쨋던 점심시간,, 읽고 싶은 책은 1페이지도 못 읽고 문득 든 생각때문에
몇 시간을 보내 버렸다.......

요즘 모바일 환경의 어플리케이션들이 인기다
특히 아이폰과 같은 스마트폰의 어플이 날개 돋친듯 팔리고(?) 있다

수익을 목적으로 하는 유료 어플도 많으며 대부분 다운로드 시 유/무료가 구분되고 있다
그러나 모바일 어플이 점점 다양해지고 관련 비즈니스도 점점 성장함에 따라 기존 데스크탑 환경과
같은 소액 결제나 부분유료화 모델의 요구가 늘어나고 있다

그러나 지금까지 부분유료화 모델의 가장 큰 걸림돌은 애플의 과금 정책이었다
애플은 기본적으로 자사의 플랫폼에서 서비스되는 콘텐트에 대해 신용카드 결제를 원칙으로 하고 있다
얼마전 음원 서비스 업체에서 별도의 휴대폰 과금을 적용했다가 앱스토어에서 퇴출되는 사건도 있었다

그러나 어플을 개발하는 업체 입장에서는 애플의 앱스토어라는 시장을 배제할 수도 없다
애플의 앱스토어에는 가장 많은 어플이 등록되어 있으며 거래 역시 굉장히 활성화 되어 있기 때문에
무시할 수 없는 시장인 것이다

물론 애플에서도 부분유료화 모델의 요구를 수렴해서 In App Purchase 라는 SDK를 내 놓았다
이제 앱스토어에서도 다운로드 시에는 무료, 콘텐트 이용 도중 (필요시)소액 결제와 같은 부분유료화
모델을 정책에 위반되지 않게 구현할 수 있게 되었다

문제는 우리가 구축해야 할 '플랫폼'이다
단위 어플을 개발하는 개발사 입장이 아닌 어플들의 통합 환경을 제공하는 플랫폼 입장에서는 애플의
정책에 여전히 걸림돌이 많은게 사실이다

플랫폼은 비단 애플 앱스토어 뿐만 아니라 안드로이드나 윈도우모바일과 같은 다른 환경도 흡수해야
한다. 애플의 폐쇄형 모델과 안드로이드의 개방형 모델의 차이를 하나의 플랫폼에서 녹여야 하며
다른 제조사 및 통신사의 정책에도 민감할 수 밖에 없다

즉 심플하고 통일되고 통합된 빌링 플랫폼을 설계할 때 정책의 상이함과 연동의 특수성이 걸림돌이
될 수 있는 것이다

한가지 예를 들어 과거 위피기반의 게임에서 주로 이용되었던 '정보 이용료' 와 같은 모델을 스마트폰 어플에 도입하고자 할 때 개방형 플랫폼에서는 가능하겠지만 애플의 정책과는 충돌하는 부분이다

그렇다면 두 가지 버전으로 갈 수 밖에 없다.
아니면 빌링 오픈 API를 상당 수준 추상화 하여 몇 단계 랩핑과정을 거쳐야 한다.
이것은 자칫 복잡도만 증가시키고 플랫폼이 오히려 어플의 걸림돌이 될 수 있음을 경고한다. 

어쨋던 모바일 플랫폼 프로젝트의 빌링 플랫폼을 고민하면서 모바일 환경에서의 결제 시스템을
조사해 봤고 어떻게 플랫폼화 시키는 지 고려해 보면서 느낀 몇 가지 사항들이다

이는 문서로 정리 되었으며 1차 자료조사 수준과 일부 의견을 남기는 것으로 하였다

모바일 결제 시스템 조사

개요

본 문서는 모바일 환경에서의 통합빌링 플랫폼 구축을 위한 사전 조사 단계로

모바일 결제시스템의 모델과 사례, 과금 방식 및 연동 방식 등을 러프(rough)하게 조사한 문서이다

따라서 이 문서에서는 어떠한 결론을 도출하지는 않으며 조사 및 일부 의견을 게재하는 것으로 한다

모바일 빌링

모바일 빌링이란 아이폰, 구글 폰과 같은 스마트 폰과 아이패드와 같은 타블렛 PC 등의 모바일 장치에서

서비스되는 컨텐츠의 결제, 과금, 정산 등의 일련의 프로세스 및 체계를 일컫는다

모바일 환경은 기존의 데스크 탑 환경에 비해 표준을 준수해야 하며 애플과 같은 모바일장치 공급업체

및 통신사의 정책에 매우 민감하다. 이러한 환경의 차이는 기술적 차이를 가져오며 이는 기존 데스크 탑

환경에서의 빌링 모델과 다른 접근법을 필요로 한다

(모바일) 통합빌링 플랫폼

통합빌링 플랫폼이란 결제, 과금, 정산, 환불, 수익 배분 등의 일련의 체계를 플랫폼 차원에서 구축하여
일관되고 통합된 시스템과 연동 API를 제공함으로써 CP(Content Provider)의 개별적 빌링 개발의 부담을
제거하고 결제, 환불, 정산, 배분 등 전체 빌링 활동을 통합되고 일관된 정책과 프로세스로 지원하는
소프트웨어 환경 및 비즈니스 시스템을 일컫는다

스마트 폰 결제 시스템 현황

스마트 폰 환경에서의 소액 결제 및 부분유료화를 위한 모델 및 기존 PG사가 제공하는 솔루션에
대해 정리한다

1) (WIPI 기반) 정보 이용료 및 3G 과금

기존 위피 기반 환경에서의 소액 결제는 통신 요금(정보이용료)으로 부과된다

(각 통신사에서 위피 기반의 결제 모듈(API)를 제공하고 이를 게임에 연동하는 구조)

이 모델을 안드로이드와 같은 개방형 플랫폼에서는 응용 및 적용가능 한 것으로 파악된다

(애플 정책과 충돌되는 부분일 수 있음)

3G 과금을 부분유료화로 사용해도 될 듯 하며 다만 이통사의 수수료율이 꽤 높은 편이다(20~30%)

2) In App Purchase (by Apple)

아이폰 앱 부분 유료화 지원 시스템.

iTunes 에 등록된 신용카드를 이용한 결제 시스템(아이폰 OS 3.0부터 지원)

애플에서 연동 SDK 제공. 결제는 애플을 통해 이루어 지며 수익 배분은 7: 3 (개발자: 애플)

연동 사례>

컴투스 홈런 배틀 3D 아이템 구매에 적용, Gogo3D 네비게이션 지도 데이터 다운로드에 적용 등

In App Purchase 프로그래밍 가이드>

http://developer.apple.com/iphone/library/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction/Introduction.html

gogo3D의 In App Purchase 결제 시스템 Flow(UI 기준)>

3) INIPay Mobile for iPhone (by 이니시스)

PG사 이니시스에서 개발한 아이폰용 모바일 결제 시스템

App to App, App to Web, Web to App, Web to Web 방식 지원 (가맹점 to PG)

App to App 및 Web to App 방식>

이니시스 전용 앱을 아이폰에 설치되어야 함. 가맹점 App(Web)에서 PG App을 실행하는 구조.

App to Web 및 Web to Web 방식>

가맹점 App(Web)에서 HTTP Post 방식으로 PG 결제 페이지를 호출하는 구조

이니시스 결제 전용 앱 및 웹을 통한 결제 연동 모델 지원>

이니시스 전용 앱을 통한 결제 Flow(프로세스 기준)>

4) tMobile (by 다날)

휴대폰 전문 PG 사인 다날에서 개발한 스마트 폰 용 휴대폰 결제 시스템.

스마트 폰 장치 수준의 지원은 없음

(다날 결제 서버와 이와 연동하는 클라이언트 모듈만 제공하는 심플한 형태)

(가맹점의 서버를 필요로 하고 스마트폰 – 가맹점간 통신은 가맹점 몫)

자바기반 연동 API 제공. Server to Server 방식

다날 tMobile 결제 Flow>

5) 모빌리언스 스마트 폰 휴대폰 결제 시스템 (by 모빌리언스)

휴대폰 전문 PG 사인 모빌리언스에서 개발한 스마트 폰 용 휴대폰 결제 시스템

 HTTP Post 호출 방식 및 Socket 방식 지원

6) BC카드 ISP 앱 (by BC카드)

아이폰 용 모바일 안전결제 솔루션

신용카드 정보 일회 등록 후 ISP비밀번호 만으로 결제 가능

의견

폐쇄 및 개방형 플랫폼에 대한 이중적 고려

애플은 자사의 플랫폼에서 서비스되는 콘텐트에 대해 신용카드 결제를 원칙으로 하고 있다

이러한 애플의 폐쇄적 정책은 모바일 빌링 플랫폼 설계에 중요 변수로 작용할 것으로 보인다

기타 다른 개방형 플랫폼에서는 빌링 모델 설계의 자유도가 높을 것으로 예상된다

 

통합 가상 머니 도입

통합 가상 머니의 도입을 고려해 볼 만 하다 (개방형 플랫폼에 한해?)

심플한 모델 도출이 가능하며 빌링을 플랫폼화 시키기 가장 쉬운 구조이다

매끄러운 소액 결제?

게임 진행 도중 특별한 추가 정보나 웹 사이트를 열지 않고 자연스럽게 결제를 할 수 있는 모델로는

다음과 같은 것이 있을 수 있다

- 애플의 In App Purchase
- 3G 과금(기존 위피 기반 정보 이용료 부과 모델)
- 휴대폰 결제(기존 데스크 탑 환경과 거의 유사한 모델을 모바일 환경에서도 이용)

 

기타 현재 PG사에서 제공하는 모바일 결제 솔루션의 대부분은

APP TO APP 이나 APP TO WEB 과 같은 이중 호출 구조를 지니고 있어 매끄럽지 못하다
(빈번한 소액결제 모델에 부적합. 다만 가상 머니 일괄 충전개념으로는 도입할 만 함)

얼마전 참석했던 세미나에서 뷰포트(Viewport)에 대한 언급이 잠시 있었다

모바일 웹 UI 개발시 Display 영역 조절과 관련된 기술요소인듯 하였고 자세한 설명보다는
뷰포트 메타태그 기술방식 위주의 설명이여서 완전한 개념을 파악하기는 힘들었다

뷰포트에 간략히 조사해 보았다

뷰포트가 사파리 기술?
뷰포트를 조사하다 처음 든 의문은, 이것이 애플의 (모바일) 사파리 기술인가? 하는 것이었다

대부분의 인터넷 블로그에서 뷰포트를 소개하면서 아이폰 기반 모바일 웹을 대상으로 하였고
사파리 브라우저가 인식하는 메타태그로 설명하고 있었다

또 다른 자료에서는 아이폰과 안드로이드 심지어 오페라 모바일 등 다른 브라우저에서 권장하는
뷰포트 태그를 제시하기도 하였다

뭐지.. 이거? 뷰포트 태그가 모바일 사파리가 인식하는 개념처럼 하더니 다른 브라우저에서도
인식되나보네? .. 하면서 살짝 의문이 들기 시작했다

짧은 시간 의문을 품다 문득  떠 오른 생각은 바로 웹킷(WebKit) 이었다
웹킷은 아이폰에 있는 모바일 사파리의 핵심 엔진이며 안드로이드의 브라우저 기반이기도 하다
더불어 웹킷은 다른 모바일 브라우저에서도 사용되고 있는 기술이다
웹킷과 뷰포트의 연결고리가 더 자연스럽다는 생각이 들었다

그렇다. 뷰포트 메타태그는 웹킷 기반의 모바일 브라우저에서 인식 가능한,
표시영역 제어와 관련된 기술요소 였던 것이다

2013.01.15: 위 내용 수정합니다. xCoda 님이 댓글로 안내 해 주셨습니다
아래 댓글 내용 확인 바랍니다.

뷰포트(Viewport)란?
뷰포트라는 개념자체는 모바일 웹에 국한된 것은 아니다
DirectX 나 여타 그래픽, 디자인 관련 기술에 개념적으로 사용된 용어인 듯 하다
그러나 처음 나에게는 낯선 용어였다

뷰포트를 대략 정의하자면,
컴퓨터나 휴대 단말기 등 장치에 Display 요소가 표현되는 영역을 말한다
모바일 웹의 경우 아이폰 사파리 브라우저에서 웹 페이지가 표시되는 영역으로 해석할 수 있다

다음 두 애플의 자료에서 뷰포트에 대한 상세한 내용이 제공되고 있다
Configuring the Viewport
Supported Meta Tags 


뷰포트 설정 참고
포털 등 기 개발된 모바일 웹 사이트에서 설정한 뷰포트 태그를 참고해 보자

1) m.naver.com
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, user-scalable=no, target-densitydpi=medium-dpi" />

2) m.daum.net
<meta name="viewport" content="user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, width=device-width" />

3) m.nate.com
<meta name="viewport" content="user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, width=device-width" />

4) m.yahoo.com
<meta name="viewport" content="width=device-width, initial-scale=1.0, maximum-scale=1.0, user-scalable=no"/>

5) m.aladdin.co.kr
<meta name="viewport" content="user-scalable=no, initial-scale=1.0, maximum-scale=1.0, minimum-scale=1.0, width=device-width" />

어쩜 이렇게 모두 거의 동일할까?
이것이 최적의 구성인가... ㅎㅎ

가로 너비는 장치 너비를 지정하였으며 사용자에 의해 확대/축소가 되지 않도록 설정하고
초기 스케일은 1.0 즉 확대/축소 없는, 본 크기 그대로를 지정하였다

트위터를 보면 글에 인터넷 주소 링크를 심심찮게 볼 수 있다
그리고 대부분의 링크 주소는 꽤 심플하다

그런데 링크를 클릭해서 넘어가보면 다른 주소, 원래의 긴~ 주소 페이지로 이동한다
그럼 긴 URL 을 짧은 URL로 매핑 시켜주는 무엇인가가 있다는 예기인데...
트위터가 제공하는 걸까? 아니면 실제 컨텐츠 제공자가 지원하는 걸까?

팀장님으로 부터 조사 임무를 부여받고, 살펴 보게 되었다
아래는 조사 후 팀에 공유한 메일 내용이다

그나저나 이 조사 덕에 기존에 관심을 두지 않았던 트위터에 가입하게 되고 재미까지 느끼고 있다
조사하는 시간은 약 1시간 정도였는데, 트윗질은 하루 종일 했다는 ... ㅎ
------------------------------------------------------------------------------------------
아시다시피 트위터는 글 수 제한(140자)이 있습니다

외부링크주소(URL) 역시 글 수에 포함되기 때문에 URL 단축 기법이 이용됩니다

URL을 줄일 수 있는 방법이 필요한데, 현재 트위터에서 사용되고 있는 대부분의
단축 URL 기법은 트위터와는 무관한 제 3자에 의해 제공됩니다

제 3자에 의한 URL 단축 서비스 제공

기본적으로 URL을 단축해 주는 시스템은 제 3자에 의해 제공됩니다

URL을 단축해 주는 사이트가 굉장히 많으며 트위터는 물론 기사원문을 제공하는 곳과도
완전히 별개의 사이트 입니다. 아래는 단축 URL 에 대한 서비스 흐름도 입니다

단축 URL 을 제공하는 사이트 목록입니다(꽤 많네요..)

http://bit.ly http://tln.kr http://durl.kr http://tinyurl.com http://yep.it http://foldurl.com http://is.gd http://j.mp http://tr.im http://url.fm

http://qurl.net http://url123.com http://ataja.es http://lin.kz http://lnk.in http://shurl.net http://simurl.com http://tinyclink.com http://urlcut.com http://w3t.org http://2u.lc

컨텐츠 공급자가 직접 제공하는 Fancy Url

팬시 URL 기법은 이전부터 존재 했던 방식으로 유저가 URL을 기억하기 쉽도록 서비스 사에서 직접 단축 url을 제공하는 방식입니다

예를 들어, 네이버 블로그의 경우 다음과 팬시 url 이 제공됩니다

실제 주소: http://blog.naver.com/NBlogMain.nhn?blogId=mkex&

Fancy Url: http://blog.naver.com/mkex/

이는 블로그 주소는 물론 게시물 주소도 해당됩니다. 서비스를 제공하는 업체에서 직접
제공하는 방식입니다

이 개념을 적용해 컨텐츠 공급자 차원에서 트위터를 겨냥해 단축 url 을 제공해 주는 경우도
있습니다. 국내 위키트리라는 뉴스 사이트에서는 기사 원문에 대해 단축 url 을 직접 생성 해 주며 글 내용도 자동 생성해 줍니다

아래 그림과 같이 기사 원문에서 트위터 이미지를 클릭하면,

다음과 같이 트위터 글 쓰기 폼이 열리며 단축 주소와 글 내용이 자동 생성되어 열립니다

오픈 API를 이용한 연동 가능

트위터는 기능에 대한 API 를 오픈하고 있어 이를 이용하면 외부 사이트에서 트위터로 글을
등록할 수 있습니다

현재 대표적으로 트위터에 이미지를 등록하는 http://twitpic.com  에서 트위터의 Open API 를 이용해 이미지를 등록해 줍니다. 이 방식을 활용하면 우리의 서비스 글을 트위터로 올리는
편리한 프로세스를 (제한적이지만) 만들 수 있을 것 같습니다

아래는 트위터에 이미지를 등록해 주는 사이트 목록입니다

http://twitpic.com http://www.yfrog.com http://www.mobypicture.com http://www.twitgoo.com http://tweetphoto.com

이상 기본적인 조사입니다

추가 확인 사항 있으면 회신해 주세요