아이뉴스24의 5월 14일자 기사에 "풀브라우저와 웹뷰어 뭐가 다른가"란 기사가 포스팅되었다. 원문은
이곳에 가면 읽을 수 있고, 주가되는 내용은 아래와 같다.
휴대폰에서 네이버, 다음 등의 유선인터넷 웹페이지를 볼 수 있는 서비스가 인기를 끌고 있다.
이 서비스를 지원하는 무선인터넷 서비스는 크게 두 가지로 나뉜다. 우리에게 익숙한 풀브라우저와 종종 풀브라우저로 혼동되는 웹뷰어가 있다. 보통 같은 것으로 착각하기 쉽지만 전문가들은 둘은 "분명히 다르다"고 말한다.
요는 클라이언트에서 메타 언어를 해석해서 뿌려주면 '풀브라우저'이고, 서버사이드에서 컨버팅해서 웹사이트를 보여주는 것은 '웹뷰어'이므로 이 둘은 구별되어야 한다는 것이다. 기사의 원문에서 아래 부분만 제외하면 기사의 이야기는 사실 틀린 이야기하고 할 수는 없다.
눈에 띄는 차이점은 풀브라우저는 휴대폰 생산단계부터 내장돼야 하는 임베디드 소프트웨어인 반면 웹뷰어는 무선인터넷에서 프로그램을 내려받아 사용할 수 있는 버추얼머신(VM) 응용 애플리케이션이라는 것이다.
'풀브라우저'인가 아닌가를 내장형 어플리케이션인가 VM인가로 구분하는 저 어리석음을 제외하고는 분명히 뭔가를 아는 전문가의 이야기를 정리하고 있다. 실제로 이 기사 외에도 종종 인터넷에서는 이렇게 구별하여 사용하는 경우가 있다.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
ETRI에 근무하고 있으며 별주부뎐 블로그를 운영하는 거부기아찌님은 '
Top 10 Mobile Web 2.0 Predictions for 2008 (2008년도 모바일 웹 2.0 전망)' 포스팅에서 '풀브라우저'와 '모바일 웹 브라우저'를 구분하여 설명하고 있다. 해당 포스팅에서 그 부분의 일부를 소개하자면 아래와 같다.
현재 풀브라우징이라는 용어는 "WAP+WEB"의 의미인데, 올해부터는 전도되어 "WEB"만 남게 될 것으로 보입니다. 그리고 WAP 기반의 브라우저 확장이 아닌 WEB 브라우저 기능만의 사용이 대세가 될 것이라는 예상이기도 합니다. 그런 이유는 아이폰의 사파리 브라우저에서 볼 수 있듯이, 웹 브라우징이 정상적으로 된다면 WAP 브라우징을 거의 할 필요성이 없어지기 때문이기도 하고, Webkit 렌더링 엔진이나 오픈소스 기반의 모질라 모바일 브라우저 등이 보급되면서 시장 환경이 급변할 것 예상되기 때문입니다. 성능이나 효율성의 측면에서도 WAP과 WEB의 풀스펙을 모두 지원하는 브라우저라는 것이 결코 효과적일 수 없기 때문이기도 하죠.
즉, '풀브라우저'는 WAP과 WEB을 한 브라우저 안에서 모두 보여주는 것을 말하는 것이고, '모바일 웹 브라우저'는 WEB만을 지원하는 것으로 두 개를 구분해야 한다는 것이다. '풀브라우저'라는 용어가 NTT에서 시작된 용어로 태생이 WAP 브라우저에서 시작되었다가 WEB의 일부분을 지원하면서 생긴 것을 생각해보면 이러한 구분 역시 설득력이 있다.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
위 두개의 사례는 모두 설득력있는 의견이지만 그렇다고 모두 맞는 이야기다라고 생각하기에도 무리가 있다. 분명히 '풀브라우저'의 역사는 그렇게 시작했지만 여기에 따른 여러 연구와 시도, 그리고 미디어의 왜곡과 그에 따른 사용자들의 오해 때문에 처음의 의미와 많이 변질이 되었기 때문이다. 사실 "풀브라우저의 처음 뜻이 뭔데?"라고 생각하는 것 또한 지금에 와서는 별 의미가 없다.
어떤 산업에서 새로운 단어를 사용하려면 명확한 Define이 되어야 하는데 '풀브라우저'의 Define은 어디에도 없다. 여러 포스팅이나 논문에서 각자 자신의 입장에서 Define을 하기는 하지만 그 Define이 해당 산업에서 표준으로 쓰기에 맞다라고 할만한 용어가 없다라는 뜻이다. 그나마 온 세상 네티즌들이 만들어내어 공감대를 형성한다는
위키디피아에 조차 'Full Browser'라는 단어는 없다는 사실을 알고 있는가?(위키디피아의 한국어판에도 역시 '풀브라우저'는 없다.
결국은 풀브라우저에 대한 정의나 위의 구분등은 하나의 일리가 있는 주장일 뿐 아직까지는 보편타당하게 사용되는 정의와 구분이 아니라는 생각이 든다. 풀브라우저에 대한 정의 중에 개인적으로 가장 적당한 정의는
e-Words에서 정리한 것이라고 생각하는데 아래와 같은 내용으로 이루어져 있다. "이것이 맞다"라고도 말하는 것은 위험하지만 적어도 풀브라우저를 정의하는 요소는 모두 포함되어 있는 듯 하다. '풀브라우저'의 한글 표기를 '풀 브러우저'라고 한 것을 제외한다면..
컴퓨터용으로 만들어진
Web사이트를 그대로 열람할 수 있는 휴대 전화용등의 Web브러우저.
다운로드해서 이용하는 것과 휴대 전화에 미리 내장되어져 있는 것이 있다. 휴대 전화등은 개인용
컴퓨터에 비해서 기능과 성능이 대폭 제한되어져 있기때문에, Web페이지도 통상의 규격으로부터 대폭 축소되어진 독자의 양식에 따라서 기술하는 것을 요구되어지고 있다. 이때문에,
컴퓨터용으로 작성되어진 사이트에 휴대 전화로 엑서스하는 것은 통상 불가능하다. 풀 브러우저는 휴대 전화의
Java프로그램 실
행 기능등을 이용하며,
컴퓨터용 사이트의 표시를 가능케 하는
소프트웨어이다. 단 휴대 전화의 표시와 조작성을 직접 확장하고 개선하는 것은 불가능하기 때문에 표시 내용을 선택해서 간소화하는 등으로 표시와 조작을 가능하게 하고 있다.
컴퓨터와는 완전히 동일하도록 표시할 수 있도록 하는 소프트라고 하기에는 무리가 있다. 덧붙여서 풀 브러우저라고 하는 명칭은 NTT도코모가 상표 출원하고 있다.
또한 사용에 따른 '풀브라우징(풀브라우저가 아님)'의 종류는 통상적으로 아래와 같이 구분을 한다.
1. Browser-based Adaptation클라이언트에서 소켓을 직접 생성하여 목적 웹사이트로 접속하여 메타 정보를 얻어내고 이를 해석하여 화면에 뿌리는 방식.
Opera,
NetFront, Infraware, Safari 등을 이용하여 웹사이트에 접속하는 것이 여기에 속한다.
2. Proxy-based Adaptation
Proxy 서버에서 웹사이트에 접속하여 웹페이지의 내용을 해석하고 이를 Image로 만든 후 Image 정보를 모바일 기기에 전송하여 화면에 뿌리는 방식. 대표적인 예로는 Deepfish와 국내
유자드 브라우저를 이용하는 것을 들 수 있다. 첫번째 기사에서 '웹뷰어'라고 정의한 제품을 이용하는 것을 말한다.
3. Metadata-based Adaptation
1번과 유사하지만 클라이언트 브라우저를 이용해 모바일 최적화한 사이트에 접속하는 것을 말한다. WAP이 아닌 Web의 메타 태그로 사이트를 개발하지만 일반 Web 브라우저로 접속했을 때는 다른 화면을 보여준다. iPhone의 성공으로 Safari 전용 페이지를 만드는 각종 사이트와 국내에서도 Infraware 브라우저로 접속하는
플레이톡과 같은 것을 예로 들 수 있다.
4. Transcoding Adaptation
각종 브라우저 솔루션 업체나 구글과 같은 포탈등이 보유한 기술로 일반 WEB 페이지를 이루는 Meta Tag를 WAP 페이지에서 사용하는 Meta tag로 서버에서 변환하여 '풀브라우저'가 아닌 일반 WAP Browser로 Web 사이트를 접속하는 것을 말한다. 국내에서도 일반 WAP 브라우저로 구글 검색을 한 후 검색 결과에서 나타나는 웹페이지를 선택하면 WAP 브라우저에서도 Transcoding된 Web 사이트를 볼 수 있다.
하지만 위의 풀브라우징의 구분에서 보면 첫번째 기사에서 언급한 '웹뷰어'도 풀브라우징을 할 수 있는 '풀브라우저'의 종류로 구분하는게 더 자연스럽지 않을까 하는 생각이다. 역시나 Web만을 보여주는 Opera나 Safari도 '풀브라우저'라는 테두리안에 넣어주어도 무리가 없지 않을까? 물론, 이러한 정의나 구분 또한 어떤 표준이 아니라 mobizen의 개인적인 경험이나 의견을 토대로 한 것일 뿐, 이게 절대적인 정의와 구분이라고 할 수 없다.
다시 한번 강조하지만 위의 두 의견은 모두 설득력이 있다. 다만, 정의와 종류를 너무 작은 Segment로 나누기에는 아직까지 '풀브라우저'의 존재 정의는 너무 혼란스럽다는 생각일 뿐..
Tomorrow Wireless World.pdf
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 는 아예 빈칸이 되겠죠? 그런 관점으로 이해 바랍니다. ^^