서버에서 사이트에서 접속하여 결과값을 이미지로 모바일 디바이스에 전송하는 서버사이드 풀브라우저는 태생적인 몇가지 한계로 인하여 일부 사람에게 '풀브라우저'측에도 못끼는 '웹뷰어'로 불리우고 있다. 이러한 대접을 받는 이유는 대부분의 사람이 이러한 서버사이드 방식은 클라이언트 방식의 브라우저로 가기 위한 중간과정 쯤으로 생각하고 이 중간 과정이 굉장히 짧을 것이라고 예상하기 때문이다. 클라이언트에서도 16Bit Color로 빠른 렌더링을 보여주고, 플래쉬 Plug-In을 통해 youtube를 볼 수 있는데 굳이 중간에 서버가 들어갈 필요가 없다고 생각하는 것이다. mobizen도 전적으로 동감하는 부분이다.
이러한 서버 사이드 클라이언트는 굉장히 개발하기 쉬운 메카니즘을 가지고 있다. 사용자는 모바일 디바이스로 서버에 접속을 하면 서버는 각 Session마다 IE Instance를 생성한다. 그 Instance는 사용자의 마우스 이동이나 문자 입력 등을 받아서 해당 결과를 계속해서 모바일 디바이스에 보내는 방식이다.
이러한 방식은 기존 미디어에서 지적한 대로 파일 업로드나 다운로드가 불가능하고, 서버를 거쳐서 정보가 지나가기 때문에 개인 정보에 대한 보안이 취약해 질 수가 있다. 서비스하는 업체에서의 가장 큰 골치거리는 사용자가 많아질 수록 서버를 증설해야 한다는 것이다. 제아무리 L4나 L7 스위치의 기술이 발전을 할지라도 이러한 서버 비용은 기업 입장에서 엄청난 부담이다. 이를 토대로 서버사이드 풀브라우저의 SWOT를 간단하게 정리를 해보았다.
이러한 솔루션이 중간과정임에는 분명하지만 서비스하는 업체 입장에서 생각해보면 생명주기를 최대한 늘려야 하는 노력을 해야 한다. 그렇다면 적어도 저 표안에 있는 Weakness는 Overcome을 해야 하는 것이고 Strength는 'Up to'를 해야하는데 그러한 노력과 발상의 전환이 없는 것이 조금 아쉽다. 잠깐 현재 인터넷 세상으로 눈을 돌려보면 위와 접목할 수 있는 단어 몇개가 눈에 띄인다.
분산, P2P 그리고 KTF에서 서비스하는 'SHOW myPC'이다.
이런 단어와 위의 표를 Overlap을 해보면 사실 저 서버를 굳이 서비스 업체의 서버라고 한정지을 필요가 없다. 'SHOW myPC'처럼 사용자 자신의 PC를 사용하면 되는 것이다. 사용자의 PC에 특정 프로그램을 Install 하고 서비스 업체의 서버는 Session 연결만 해준다. Session 연결 이후에는 P2P로 동작하여 자신의 PC를 통해서 브라우징을 하는 것이다.
이로 인해서 얻을 수 있는 것은 각 개인 PC의 자원을 활용할 수 있다라는 것이다. 파일 업로드도 가능하고 자기 PC내의 지정된 위치로 다운로드를 미리 받아 놓을 수가 있다. 기 저장된 공인인증서도 사용이 가능하므로 불편하나마 인터넷 뱅킹도 사용이 가능하다.(키보드 보안 프로그램 부분은 기술적으로 해결해야 한다.) 또한 PC에서 이미 북마크해놓았던 정보를 공유할 수도 있고, 욕심을 좀 더 부리면 사운드도 지원이 가능하다. 서비스 업체 입장에서 가장 좋은 것은 서버 증설의 부담에서 벗어날 수 있다라는 것이다. 실제 사업에 적용을 하려면 좀더 신중한 고민과 전략적인 마케팅이 따라주어야 한다. 그냥 Concept의 수준에서 받아드려주기 바란다.
현재 국내에서 서버사이드 솔루션을 서비스하는 곳은 '유자드' 밖에 없지만 유사 기술을 가지고 현재 이통사에 제안을 하는 곳은 너무나 많다. 이들이 성공하지 못하는 이유는 제품에 너무 쉽게만 접근하기 때문이다. 이러한 아이디어 자체가 중요한 것은 아니고, 가지고 있는 한계나 단점을 쉽게 인정하지 말고 극복하려고 노력하는 자세이다. 그런 자세가 없이는 서버사이드 풀브라우저는 단순 '웹뷰어'라는 비아냥에서 벗어나기 힘들 것이다. 설령 MS사의 'DeepFish' 라고 할지라도...
아이디어는 아이디어일뿐..... 생각을 정리하지 않고 Concept이 떠오르는데로 포스팅하는거니 허점이 보여도 이해해주기를...
- Posted
- Filed under 모바일 일반
Comments List
비슷한 시도가 몇차례있었습니다.
일단 단말기를 VNC Termianl로 사용해서 자신의 PC를 제어하는 시도도 있었고,
말씀하신 것 처럼, 중간 서버 자체를 자신의 PC를 사용하자는 아이디어도 있었지만,
항시 PC가 켜져 있어야 한다는 등의 문제가 있어서 현실화되지 못했죠 :)
앗싸뵹님의 리플과 같은 커뮤니케이션이 정말 블로그하는 재미죠. 정말 답변 감사합니다.
사실은 정말 아이디어는 아이디어일뿐인지라 생각이 나자마자 앞뒤 안재보고 그냥 포스팅해본 것이었거던요. 아이디어 자체보다는 뭔가 제약 조건이 있다면 그를 극복하려는 노력을 하지 않으면 서버사이드 풀브라우저는 경쟁력이 없으니 차별점을 찾아야 한다라는 이야기를 하고 싶었던 것이고, 그러한 예로서는 이런 것이 있다..였는데 그 예를 설명하다보니 아이디어 포스팅이 되어버렸네요~
벤치마킹 없이 row idea를 올렸더니 역시나 함정이 있었군요. 저또한 이런 생각을 저혼자만 하는거라고는 생각을 안했답니다. "PC가 항상 켜져있는 것은 아니다"는 위 아이디어의 장점을 절반 정도는 깍아 먹는군요. 사용자 PC가 켜져 있으면 그것을 사용하고, 아닐 때는 서비스 사업자의 서버를 사용하면 되겠습니다만 그런 것에 대한 요금제나 극복 방안이 나와야할텐데.. 제가 할 것은 아니니깐 전 아이디어 수준으로만.. ^^
앗싸뵹님의 리플 다시 한번 감사드립니다. 극복 방안에 대한 다른 아이디어들이 있으면 같이 공유했으면 재미나겠네요. 그쪽 일 하시는 분 말고..
주인장님 글 잘보고있습니다 ㅎㅎ
윗글과는 상관없는데 제가 물어볼곳이 없어서
내공이 높으신 주인장님께 질문하나만 올리겠습니다 ㅎㅎ
vm이나 모바일 게임등이 핸드폰 기본 프로그램에 침투할 수 있는지가 궁금합니다
예로 핸드폰에 일정을 설정하면 추후에 다운받은 vm에 그 일정이 나오게 할 수 있는지 궁금합니다
감사합니다^^
질문의 요지가 핸드폰의 기본 프로그램이나 다른 VM이 만들어 놓은 데이타에 VM이 접근을 할 수 있느냐? 인 것 같습니다. 답변은 '예'와 '아니오' 입니다.
기술적으로 VM은 핸드폰 내에 있는 모든 데이타를 Access 할 수 있습니다. 하지만 이렇게 되면 악용될 소지도 있고, VM 하나의 잘못으로 핸드폰 자체의 데이타가 손실이 될 경우가 생깁니다. 그래서 BREW, Java, WIPI과 같은 VM은 모두 접근 권한 레벨이 있습니다. VM에 따라서 컴파일시에 설정이 되는 것도 있고, 다운로드 시스템에서 부여하는 경우도 있습니다.
이 권한에 따라서 Access 할 수 있는 영역이 구별되어 집니다. 일반적인 모바일 게임의 경우는 자신이 저장한 Data영역과 주소록, SMS, 시스템 시간 정도입니다.
이 접근 권한을 올리시려면 이통사 담당자와 이야기 하셔서 올리면 되는데 아주 특별한 경우가 아니면 이 권한은 일반 권한으로 유지됩니다. 그러니 현실적으로는 '안됩니다'가 답이 되겠네요.
SKT쪽으로는 모바일 미니 PC라는 서비스가 있더군요. ShowMyPC는 WinCE계열만 지원하는데 비해 미니PC는 VM형태로 작동하기에 더 많은 단말을 지원하는것 같습니다. 동영상도 실시간 트랜스코딩 서버를 둬서 WMP의 제약없이 다양한 코덱의 동영상을 자막과 함께 감상이 가능하다네요. 웹서핑은 다음버전에서나 지원될 예정이라 하네요. 상당히 흥미로운 서비스라고 생각됩니다.
참고URL: http://www.minipc.co.kr/use/phone.jsp
재미난 서비스네요. 이런 서비스 자체가 대중화가 되거나 큰 반향을 만들거라고 생각하지는 않지만 여러 각도에서 노력하는 것은 좋다고 생각합니다. 사실 이런 서비스는 이통망보다는 WiFi를 열어줘야 재미날텐데요~ ^^
mobizen님 상세한 답변 정말 감사합니다. 그럼 약간의 issue가 생기는군요ㅎㅎ 모비즌님이 가능하시다라고 말씀해주신 부분만해도 1차적으로ㅎㅎ 몇번 더 질문올리도록 하겠습니다. 감사합니다^^
도움이 된다니 다행입니다. ^^
음 그런데 서버사이드 브라우저가 파일 업로드/다운로드가 불가능하다고 하시는 데에는 뭔가 기술적인 근거가 있으신 것인지요? (요즘 기사들도 한결같이 그렇게 기술하고 있더군요...)
다른 단점들은 나름 이유가 있어 보입니다만.
참고로, 유자드의 일부 버전에서는 이미 파일 다운로드를 지원하고 있습니다. (일부 안 되는 사이트가 있을 수는 있겠습니다만.)
글쿤요. 위의 포스팅은 일반적인 관점에서 설명드린겁니다. 특정 제품을 말하는게 아니구요. 서버사이드 풀브라우저 제품이 유자드것만 있는건 아니니깐요. ^^
물론 여러가지 Tip들로 피해갈 수 있겠지요. 개발자라면 누구나 다운로드는 그렇게 어렵지 않게 구현할 수 있다라는 것을 알 수 있죠. 업로드도 시간차가 좀 있어서 그렇지 적당한 꽁수를 쓰면 가능할 거구요. 파일 사이즈 및 해킹등으로 악용될 수 있는 문제는 있겠지만요..
'서버에서 만들어서 뿌린다'라는 기본 컨셉만으로 이야기 한 겁니다. 반대로 예를 들자면 클라이언트 베이스의 브라우저도 일부 모듈은 프록시 서버를 거쳐서 인코딩된 데이타를 Display합니다. 이러한 예로 하나하나 이야기 하면 너무 길어지니깐요. 유자드 제품을 타겟으로 작성한 포스팅이 아니니깐 오해없길 바랍니다.
아... 제 얘기는 특정 제품과 관련된 건 아니구요.
위에 서술하신 것은 주로 '태생적인 한계'와 '태생적인 장점'에 대한 것이라, 파일 업로드/다운로드 지원 여부도 '태생적인 한계'로 생각하시는 것 같아서, 그렇다면 어떤 기술적인 근거가 있기에 그렇게 말하시는 것인지 궁금했기 때문입니다.
물론 저는 별로 그렇게 생각하지 않기 때문이기도 하죠. 서버 기반이라면, 그냥 서버에 받았다가 다시 폰으로 넘겨주면 되겠죠? 좀 그럴싸하게 하려면 서버에서 받는 작업이 완료되기 전에 폰으로 실시간으로 내려줘도 되겠구요. 다운로드의 경우요. 업로드는 거꾸로 하면 되겠구요.
뭐 그렇다는 얘깁니다.^^
네. 이미 위에서 설명하고 메일로도 이미 다 이야기 했지만..
다시 한번 말씀 드리자면 일반적인 관점입니다. 위에서 예를 든 제 아이디어를 적용해버리면 SWOT표에서 Weakness 는 아예 빈칸이 되겠죠? 그런 관점으로 이해 바랍니다. ^^