사람들이 왜 스마트폰으로 개발 무대를 옮기는지에 대한 분석은 참 많다.
스톰님의 분석(http://sstorm.egloos.com/5516226)과 같이 손익분기점에 대한 논의가 분석의 중심이겠지만,
난 개발자라 개발자의 미시적인 시선을 적어본다.
사실 작년 KGC2010에서 발표한 내용이지만, 회사 소속을 바꾸고 강연을 하니,
들으시는 분들이 확~~ 줄어버려서 지금 이야기해도 첨 들으시는 분들 많을 듯하다.
N자로 시작하는 회사만 기억하는 드러운 세상!!!!!
들으시는 분들이 확~~ 줄어버려서 지금 이야기해도 첨 들으시는 분들 많을 듯하다.
N자로 시작하는 회사만 기억하는 드러운 세상!!!!!
내가 스마트폰으로 무대를 옮긴 이유는,
1) 클라이언트에서 셰이더를 쓸 수 있다.
2) 클라이이언트가 다중 소켓을 쓸 수 있다.
3) 클라이언트가 웹브라우저를 내장한다.
의 세가지 조건 때문이었고 이 세가지 조건만 있으면 PC와 모든 환경이 같아진다.2) 클라이이언트가 다중 소켓을 쓸 수 있다.
3) 클라이언트가 웹브라우저를 내장한다.
언제나처럼 하나하나 살펴보자. ...정말이지 난 세가지 조건이나 이유를 상당히 좋아하는 듯 하다.
1) 셰이더
셰이더가 PC개발자들에게도 다가온 것은 MS가 XBOX를 만들며 다이렉트X 8.0에 셰이더를 공개한게 처음이었을 것이다.
그전까지 셰이더는 그야말로 콘솔 게임기 개발자들만의 독특한 기술이었고,
PC게임 개발자들에게는 접근할 방법이 없었다.
에이스컴뱃 1
에이스컴뱃 3 Eectrosphere
그러나 이 둘이 차이는 N64와 PS2 정도의 차이를 보여준다.
"기기의 성능을 120% 활용한~"이란 말은 결국은 셰이더를 잘 썼다라는 말이다.
나머지 개발자가 할수 있는 것은 텍스쳐 로딩 방식과 CD/DVD 파일 구조 및 캐쉬 이야기이다.
이럴땐 보통 "빠른 로딩과 쾌적한 플레이를 제공한다~"라고 기사 쓴다. 딴지 걸지말길, 나도 게임스팟 필자였다.
아뭏든 게임기의 전유물이었던 셰이더는 XBOX 개발을 위해 다이렉트X 8.0이 만들어지며 PC개발자들에게 선보이게 되었고 꾸준한 개선을 통해 현재에 이르렀다.
아이폰과 안드로이드도 OpenGL을 이용하므로 당연히 셰이더(픽셀셰이더)가 된다.
이는 언젠가 스마트폰에서 실시간 시차매핑이 등장하리란 기대를 증폭시켜줬고 결국 인피니티 블레이드가 선을 보이게 되었다. 지극히 당연한 결과다.
하지만 셰이더의 힘은 단순히 좋은 그래픽에서 끝나지 않는다. 이를 통해 할 수 있는 것들은 무궁무진하니까.
다만 셰이더가 작동할 메모리가 어디인지 어떤 것인지 안드로이드는 하드웨어에 따라 걷잡을 수 없다.
그래서 안드로이드에서 괜찮은 3D 그래픽 뽑기가 아주 힘들지만, 아이폰이라면 정해진 스펙이 있다.
오오미~ 역시 아이폰은 게임기랑께~~
유튜브를 뒤져보면 아이폰 셰이더 데모는 참 많다.
결국 당장은 아니더라도 약간의 시간이 더 흘러준다면
3D 그래픽에 대한 하드웨어 준비와 엔진들은 쏟아져 나와줄 것이라 예상했고, 그렇게 흘러가고 있다.
우선 그래픽에 대한 기대치와 안정은 확보가 된 셈이었다.
아직 셰이더/성능/배터리에 대한 테스트는 못해봤다.
작년에 그래픽 팀원에게 시켜봤는데 그 중요성을 이해 하지 못한 것 같았다.
직접 해야 하는데...하면서 일년 넘게 못해봄 ㅠㅠ
작년에 그래픽 팀원에게 시켜봤는데 그 중요성을 이해 하지 못한 것 같았다.
직접 해야 하는데...하면서 일년 넘게 못해봄 ㅠㅠ
2) 다중소켓
수많은 PC 온라인/네트워크 게임들은 소켓을 하나 이상 사용한다.
당장 아무 게임이나 하나 실행시켜놓고 네트워크를 검사해보면 생각보다 훨씬 많은 소켓이 접속 중이란것을 알수 있다.
일차적으로 이것만 잘 분석해도 내가 하는 게임의 서버 구성을 유추할 수 있다.
이는 온라인 서비스에서 무척이나 중요한 사항이다.
만약 클라이언트가 소켓을 하나 밖에 열지 못한다면 서버의 구성은 접속서버 하나만 물고 있어야 한다.
채팅서버, 로비서버, 게임서버가 따로 존재하더라도 이 세 서버를 묶은 하나의 서버를 개발하고 이것하고만 통신해야 한다.
전체를 놓고 봤을때 과연 둘중 어느 것이 더 쾌적한 구조일까?
클라이언트만 본다면 하나의 서버와 통신하는게 더 편하게 느껴지겠지만, 클라이언트에도 두명 이상의 개발자가 붙게 되고,
서비스가 커지면 단일 소켓은 참 힘들어진다.
소켓이 여러개 가능할 때
단일 소켓일 때
그리고 다중소켓을 사용하더라도 스마트폰의 배터리를 더 많이 소모시키지는 않는다.
전통적인 TCP/IP에서 alive 체크를 위해 패킷이 좀더 사용되겠지만 이건 크지 않다.
실제 소켓을 하나만 사용하더라도 send/recv 데이터량에 의해 배터리의 차이가 나게 된다.
난 머든 직접 실험해봐야 직성이 풀린다.
소켓의 수가 아니라 데이터 전송량에 의해 배터리가 소모된다.
결과적으로 클라이언트가 여러 개의 소켓을 함께 쓸수 있으면,
PC 온라인 게임과 같은 서버 아키텍쳐를 만들수 있게 된다.
3) 웹브라우저
클라이언트가 웹브라우저를 내장했다는 말은 두가지 의미이다.
하나는 프로그램 내에서 웹브라우저를 내장하여 사용할 수 있다는 의미이고
두번째는 웹브라우저가 가진 HTTP 통신 함수, XML파서, JavaScript 런타임을 쓸수 있다는 의미가 된다.
이 모든 것은 Internet Explorer 4.0 이 등장하면서 보편화된 것이다.
물론 당시 Netscape도 비슷한 환경을 제공했지만 Common Object Model을 들고 OS와 결합한 IE를 이길 브라우저는 없었다(이미 15년전에 세상을 평정한 Visual Studio 6.0은 COM과 IE 4.0이 함께 설치된다.).
IE는 단순한 웹브라우저 프로그램이 아니다.
WinINet 이라 불리는 HTTP 통신 함수와 HTML 렌더러, JavaScript 런타임이 따로따로 구성되어 있었고,
이게 합쳐져서 쉘(Explorer, 탐색기)형태로 UI를 만들면, 웹브라우저라는 이름으로 합체!! 되는 구조이다.
끼워 팔기네~ 더러운 MS네~라고 욕한들, 지금은 이게 iOS에도, 안드로이드에도 기본 모델이 되었고
개발자는 이제 웹브라우저가 제공해주는 함수를 그냥 불러 쓰는 세상이 된 것이다.
IE의 COM은 파이어폭스도 XPCOM이란 이름으로 사용하고 있을 정도이다.
물론 당시 Netscape도 비슷한 환경을 제공했지만 Common Object Model을 들고 OS와 결합한 IE를 이길 브라우저는 없었다(이미 15년전에 세상을 평정한 Visual Studio 6.0은 COM과 IE 4.0이 함께 설치된다.).
IE는 단순한 웹브라우저 프로그램이 아니다.
WinINet 이라 불리는 HTTP 통신 함수와 HTML 렌더러, JavaScript 런타임이 따로따로 구성되어 있었고,
이게 합쳐져서 쉘(Explorer, 탐색기)형태로 UI를 만들면, 웹브라우저라는 이름으로 합체!! 되는 구조이다.
끼워 팔기네~ 더러운 MS네~라고 욕한들, 지금은 이게 iOS에도, 안드로이드에도 기본 모델이 되었고
개발자는 이제 웹브라우저가 제공해주는 함수를 그냥 불러 쓰는 세상이 된 것이다.
IE의 COM은 파이어폭스도 XPCOM이란 이름으로 사용하고 있을 정도이다.
훗~
그 누가 이 분을 아무리 까더라도 90년대에 20년을 앞선 아키텍쳐를 만들었다.
그리고 이제 그를 욕한 사람들이 그가 주장한 아키텍쳐 위에서 노닐고 있다.
심지어 리눅빠, 맥빠, 앱등이,구글빠라도 말이다.
그리고 이제 그를 욕한 사람들이 그가 주장한 아키텍쳐 위에서 노닐고 있다.
심지어 리눅빠, 맥빠, 앱등이,구글빠라도 말이다.
우선 첫번째를 보자.
이미 많은 게임들은 알게 모르게 웹브라우저를 내장하고 있다.
공지사항, 도움말은 물론이고 아이템샵과 결제창에서 빠뜨릴 수 없는 것이 웹브라우저다.
(이는 게임 개발팀과 운영팀/빌링팀을 구분해 작업할 수 있게 해준다.)
그래서 한때 HTML 사이즈에 맞춰 동적 팝업창 만들기와 다이렉트3D 풀화면에서 웹브라우저를 임베딩하는 방법등이 클라이언트 개발자들 사이에 비기로 취급받기도 하였다.
이는 스마트폰에서도 마찬가지로 적용된다.
PC에서 그래왔던 것처럼 지금 대부분의 공지사항과 도움말은 웹브라우저로 작동된다. 아직은 PC처럼 웹창에서 결제를 하는 것이 보편화되어 있지 않은게 흠이다.
그래서 아이템샵에서는 아이템 리스트만 웹브라우저를 이용하고 실제 결제는 웹브라우저위에 앱의 버튼을 올려 결제를 유도시키는 방식이 주를 이루고 있다.
웹브라우저의 기본 장착으로 게임내 게시판이 보편화되었다.
BulkyPix의 MY BRUTE. 웹브라우저 영역과 앱 영역이 잘 구분된 사례를 보여준다.
그러나 진짜 웹브라우저의 저력은 단순한 임베딩이 아니다.
HTTP 통신함수의 제공으로 수많은 SNG를 손쉽게 제작하도록 했으며
JavaScript 런타임으로 HTML/Javascript만으로 앱제작이 가능케했다.
따라서 퀵커넥트 아이폰이나 폰갭같은 하이브리드 앱 프로젝트들이 아이폰 등장 이후 얼마 되지 않아 선보이게 된 것이다.
최근에는 이런 프로젝트들이 더 많아졌는데 이런 추세를 보면 JAVA나 .NET Framework같은 것은 그야말로 인류를 대표하는 잘못된 삽질이 아닐까...하는 생각이 들때도 있다.
여기에 이 말을 하지 않을 수 없는데 이런 JavaScript 런타임 응용 기술은
원래 IBM의 Sash(http://www.alphaworks.ibm.com/tech/sash)이라는 프로젝트가 십여전 먼저 시도했던 것이다.
정말 네이밍 센스 역시 놀라운데, Window(창문)에 맞춰 Sash(창틀)이란 이름을 붙인 것은 IBM 답지 않은 멋진 센스다.
당시 오피스97에 영향을 받아서인지 카를로스라는 나름 긔요미한 캐릭터도 있었다.
급격히 편리해진 윈도우 애플리케이션의 제작방식과 웹의 발전으로 이 재미있는 프로젝트는 널리 흥하진 못했지만, JavaScript로 COM 컴포넌트 접근을 해서 애플리케이션을 만드는 아이디어는 참으로 놀라웠다.
물론 이 기술을 악용하면 악성코드라 불려지게 된다.
원래 IBM의 Sash(http://www.alphaworks.ibm.com/tech/sash)이라는 프로젝트가 십여전 먼저 시도했던 것이다.
정말 네이밍 센스 역시 놀라운데, Window(창문)에 맞춰 Sash(창틀)이란 이름을 붙인 것은 IBM 답지 않은 멋진 센스다.
당시 오피스97에 영향을 받아서인지 카를로스라는 나름 긔요미한 캐릭터도 있었다.
Linux에서 Sash를 돌리는 SashXB의 로고. 앞에 있는 파란 새가 카를로스.
물론 이 기술을 악용하면 악성코드라 불려지게 된다.
나는 케케묵은 바이너리 개발자라서 하이브리드 방식도 좋지만 그래도 역시 API를 직접 호출하는게 제일 좋다.
그러나 세상은 언제 어떻게 변할지 모르는 법이다.
기술이 같아면 아키텍쳐와 운영과 문화 역시 비슷해질 수밖에 없다.
그래서 나는 손익분기점 문제가 아닌, 월급받는 개발자로써 스마트폰으로 뛰어들었다.
그리고 역시...똑같았다.
다만 3G 환경이 엉망이 되
어쩌면 이 만화가 말하는 것이 폰 점유율 이야기가 아니라 지금 기술은 PC/Windows에서 시작되었다는 것이 아닐까?
