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

가장 심플한 형태의 ASP.NET MVC 를 만들어 보자
모든 개발 공부는 가장 기본적인 구조에서 부터 출발하여 기술확장, 응용력확장을 해 나가는 것이 원칙이다.
처음부터 복잡한 형태를 이해하려고 하면 진입이 어려워서 쉽게 흥미를 잃어버리기 마련이다.
따라서 ASP.NET MVC 기반의 Hello World 샘플을 제작해 보도록 한다


1. ASP.NET MVC 프로젝트 생성
Visual Studio 2008 에서 새프로젝트를 만든다
아래그림과 같이 ASP.NET MVC2 Web Application 템플릿을 선택하고 프로젝트와 솔루션 이름은
HelloWorld 로 한다

=>

이렇게 파일들을 제거하고 다시 실행을 해 보면 아래와 같은 오류를 보게 될 것이다
뷰와 컨트롤러를 모두 삭제했으니 페이지를 찾을 수 없다는 오류가 난 것이다

    routes.MapRoute(
      "Default", // Route name
      "{controller}/{action}/{id}", // URL with parameters
     new { controller = "Home", action = "Index", id = UrlParameter.Optional } // Parameter defaults
    );
}

URL 규칙은 controller/action/id 형태로 이우러지며
기본값으로는 controller = "Home" , action = "Index" 로 정의되어 있다

즉 앞서 요청과 같이 (http://localhost:11102/)  컨트롤러와 액션메서드 없이 호출하게 되면
자동으로 Home 컨트롤러, Index 액션메서드가 선택되어 실행되는 것이다

따라서 위 규칙에 맞는 다음과 같은 요청은 모두 같은 것이 된다
- http://localhost:11102/                   : 컨트롤러, 액션메서드 지정 없음. 기본 값 사용
- http://localhost:11102/Home           : 컨트롤러 지정, 액션메서드는 기본 값 사용
- http://localhost:11102/Home/Index  : 컨트롤러, 액션메더스 모두 명시함

현재 프로젝트에 적용하려고 하는 기술이 ASP.MVC 버전 2 이다
그런데 ASP.NET MVC 버전 3 (Preview1) 가 출시되었다

정말 빠른 속도다
2가 나온지 얼마 됐다고 3까지... 그리고 새로운 개념이 많이 추가된 것 같다
1,2,3 에 이은 업그레이드가 이전 버전을 완전히 업어 치운것은 아니지만,
간혹 속도를 따라가기가 버겁기도 하다

http://weblogs.asp.net/scottgu/archive/2010/07/27/introducing-asp-net-mvc-3-preview-1.aspx

팀장님이 알려주신 오픈페인트 서비스
오전에 관련 앱과 게임을 다운받아 보고 조금 사용해 봤다

외국에서 개발한 이 서비스는 아이폰 무료 게임들의 게임 스코어 정보를 저장하여 다른 사람과
랭킹 정보를 공유할 수 있도록 해주며 친구를 맺게 하여 지속적인 공유가 가능토록 한다
또한 채팅 및 게시판과 같은 커뮤니티 기능을 제공하며 트위터와 페이스북과의 연계성도 가지고 있다

예를 들어 특정 게임 실행 후 스코어를 트위터에 바로 등록할 수 있는 기능이 있다
트위터에 자동으로 등록된 글을 보니 게임 시코어는 물론 해당 게임의 앱스토어 URL도 같이 표시된다
일종의 광고인 게임 광고인 셈이다

HTML5 로 제작된 멋진 데모들을 제공하는 사이트이다
음.. 놀랍군.

이건 뭐.. 그럴싸한 HTML5 어플만들려면 자바스크립트를 자유자재로 다룰 수 있어야 겠구만!!

http://www.aplossystems.co.uk/articles/look_at_html_5_canvas/

자바스크립트의 영역이 이렇게 커질(?)줄 몰랐다. 아오~

우리 프로젝트에도 멋진 자바스크립트 개발자가 있어야 하겠지...

6월 1일 입사 후 여러가지 조직적 사정으로 인해 프로젝트의 방향성에 약간의 혼란이 있었다

오늘에서야 어느정도는 그 방향에 대한 가닥이 잡힌 것 같다
처음의 방향과 완전히 일치하지는 않으나 그래도 방향성에 대한 혼란이 없다는 것에 만족한다

일단 회사에서 수행하는 모든 모바일 게임을 (급하게?) 지원할 필요는 없다는 결론이다
다만 '포트리스' 라는 게임이 플랫폼에 장착시키기 좋고 적합해 보이는 만큼 이것을 시작으로 할 것 같다

현재 게임플랫폼 팀장님이 프로젝트의 PM을 수행할 것이며, 향후 2주 안에 개발계획, 스펙 등 일종의
프로젝트 설계, 기획 문서를 산출해야 한다

우선 나에게 주어진 미션은, 모바일 빌링 플랫폼에 대한 기획과 설계이다
음... 주제가 조금 난해함을 느낀다.

데스크탑과는 확연히 다른 빌링, 결제 모델을 요구하며 기술적 특징, 정책적 특징도 제 각각인 환경.
그리고 관련 업계의 연동 통일성도 걸음마 단계고 무엇보다 이 모든 것을 플랫폼화 시키기가
애매한 것이다. 그러나.. 해 보 자 ! ! !

SK TAC 에 이은 LG U+ 에서도 모바일 사업제안, 어플리케이션 공모전 환경을
본격적으로 시작한 것 같다

아이디어. 아이디어. 아이디어.
지금까지, 소프트웨어 개발 분야에서 일반 사용자의 아이디어와 어플을 이토록 편리하고
(거의)상시적으로 출품할 곳이 있었던가???

이것은 롱테일이며 제도나 거품에 밀려 쓰러지는 아이디어가 없는 환경으로 가고 있는 중이다

LG U+ : http://propose.lguplus.com/
SK TAC: http://tac.tstore.co.kr/

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

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페이지도 못 읽고 문득 든 생각때문에
몇 시간을 보내 버렸다.......

HTML5에 대한 개괄적인 내용들을 정리해 보았다
이 문서는 HTML5 & API 입문 이라는 책과 관련 블로그 및 온라인 자료를 바탕으로 작성되었다

따라서 순수 창작물이 아니라 정리 및 요약을 목적으로 작성되었으며 일부 개인적 의견이
덧붙여지기도 하였음을 밝혀둔다

HTML5 개요와 기술적 특징

2010.06.14

근래 HTML5에 대한 관심이 뜨겁다. 웹이 더 이상 문서 공유나 문서 표현만을 위한 것이 아니라 하나의 응용프로그램으로써의 면모를 점점 갖추어 나가고 있다. 플러그인 기술과 스크립트의 조화로 웹이 응용프로그램화 되어 왔지만 이는 표준적인 HTML 스펙을 벗어나는 기술의 복잡한 결합으로 가능한 것이었다

HTML5는 웹을 둘러싼 난무한 비 표준을 지양하고 지능적이고 실행가능 한 웹 구현을 위해 탄생한 차세대 웹 표준 기술이다. 본 문서에서는 현재 이슈가 되고 있는 HTML5의 개요와 기술적 특징에 대해 기술한다

HTML5 등장 배경

웹 문서에서 웹 응용프로그램으로의 진화

웹에서 문서를 표현하고 문서간 연결(하이퍼링크)을 주 목적으로 탄생한 HTML은 웹 환경이 보편화되고 발전함에 따라 표준적인 방식으로 구현되는 웹 응용프로그램 수준을 요구하는 시대적 흐름에 의해 탄생하게 되었다. 또한 방대하게 퍼져있는 웹 문서를 의미 있게 구조화하고 효과적으로 탐색, 해석 할 수 있는 시멘틱(semantic) 웹 실현을 위한 표준이기도 하다

HTML5 정의

HTML5는 HTML의 차기 주요 제안으로써 HTML 4.01, XHTML 1.0, DOM Level 2 HTML에 대한 차세대 표준안이다. 플래시나 실버라이트와 같은 별도의 플러그인 없이 웹에서 표준적인 방식으로 멀티미디어를 재생하고 로컬 자원을 이용하는 등의 응용프로그램 수준의 웹을 개발하기 위한 기술의 총칭이다

현재 W3C를 주축으로 한 애플, 모질라, 구글, 오페라, 마이크로소프트 등 모든 웹 브라우저 벤더가 참여하고 있는 산업 표준이기도 하다

HTML History

HTML은 1990년 초부터 지속적으로 업그레이드 되어 왔다

특히 시멘틱 웹의 실현을 목적으로 한 XHTML 추진과 HTML5로의 방향전환이 주목할 만한 업계의 트랜드를 말해 준다

 

	1990년 웹 창시자인 팀 버너스리에 의해 설계 및 개발 시작
	1993년 6월 IETF에 의해 버전 1.0 표준 채택
	1995년 11월 버전 2.0 RFC 표준화
	1997년 1월 W3C 버전 3.2 권고
	1997년 12월 W3C 버전 4.0 권고
	1999년 12월 W3C 버전 4.01 권고 (이후 W3C에서 HTML을 더 이상 업데이트 하지 않을 것을 선언)
	2000년 1월 ~ W3C 시멘틱 웹 실현을 위한 XHTML 1.0 개발추진. 이후 XHTML2 개발 2009년 7월 XHTML2 사양 제정 중지 선언
	2004년 6월 XHTML 보급 실패와 시대 흐름에 부응하기 위한 HTML 업데이트 제안 애플, 모질라, 오페라 제안 -> W3C 거절 -> WHATWG 결성 -> 웹 어플리케이션 1.0이라는 이름으로 세부 명세 작업 시작
	2007년 W3C에서 HTML W/G를 결성하고 WHATWG와 공동작업 시작 2008년 1월 W3C에 의해 HTML5 초안 공개 2009년 5월 Google I/O 개발자 콘퍼런스, ‘차세대 웹 표준’ 으로 적극 추천됨. (전 세계 개발자들의 주목을 받기 시작함) 2009년 10월 WHATWG가 최종심사청구를 선언하고 표준화 작업을 W3C로 넘김 W33C: HTML5 표준화 작업 진행 WHATWG: HTML 업데이트 작업 계속 진행 2010년 6월 현재 W3C의 표준화 프로세스 중 최종 초안 상태 2012년경 권고 후보 예정(실제 브라우저에 표준 전체 기능 적용 요청) 이후 정식 권고

브라우저 및 호환성

현재 HTML5가 초안(Working Draft) 상태이기는 하지만 많은 브라우저 업체들이 이미 HTML5 기능들을

지원하고 있다

2010년 현재 지원되는 브라우저 목록

파이어폭스 3.5 이상, 크롬 3.0 이상, 사파리 3 이상, 오페라 10.0 이상, IE 9 이상

미 지원 브라우저 처리

HTML5는 자체적으로 이 기술을 지원하지 않는 브라우저를 위해 Fall Back 장치를 두고 있다

(태그 무시, 대안 텍스트 표시)

브라우저 호환성 확인:

지원되는 브라우저 내에서도 HTML5 세부 지원 여부가 조금씩 상이하다. 다음의 URL에서 상세한
브라우저 호환성 확인이 가능하다 (참고: http://caniuse.com/)

HTML5 현황

전 세계적인 브라우저 업체들이 이미 HTML5 개발에 협력하고 있으며 자사의 브라우저에 HTML5를

지원하고 있다. 경쟁 기술인 실버라이트를 먼저 선보인 마이크로소프트에서도 HTML5 지원에 동참하고 있는 실정이다. 또한 플래시 개발사인 어도비에서도 자사의 웹 저작도구인 드림위버 신제품에 HTML5
편집 기능을 포함시켰다. 아래는 HTML5에 대한 업계의 관심과 공식적 행보의 예이다

애플: W3C HTML WG의 공동의장으로 활동하면서 HTML5 표준화에 적극 동참.

자사 제품에 플래시 배제. HTML5 적극 지원

사파리개발자센터를 통해 HTML5 데모 및 가이드 제공   

구글: 구글 기어스(Google Gears) 포기, HTML5 집중 선언, HTML5 기반 유투브 서비스 시작

마이크로소프트: IE9에 HTML5 지원 발표. IE3의 TestDrive 사이트에 HTML5 영역 제공

오페라: 오페라 개발자 센터를 통해 HTML5 데모 및 가이드 제공

사례 및 데모

퀘이크 2: http://www.youtube.com/watch?v=XhMN0wlITLk (플레이 동영상)

HTML5의 Canvas와 Audio 및 LocalStorage , WebSocket, WebGL등의 기술을 이용해
GWT(Google Web Tookit)팀에서 퀘이크 2를 HTML5로 포팅하여 에뮬레이션 한 것
 (웹 브라우저에서 초당 60프레임까지 가능)

오픈 소스: http://code.google.com/p/quake2-gwt-port/

이미지 편집기: http://mugtug.com/darkroom/
포토샵과 유사한 기능 제공. HTML5 Canvas 사용

HTML5는 2012년경 그 모습이 완성되어 나갈 것으로 예상되며 많은 기업에서 이를 기반으로 한 웹 응용프로그램을 출시하여 기술이 본격적으로 활성화 될 것으로 보인다

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

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

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

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

물론 애플에서도 부분유료화 모델의 요구를 수렴해서 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 즉 확대/축소 없는, 본 크기 그대로를 지정하였다