데이터 애플리케이션과 인터넷 컨텐츠를 모바일 장치에서 볼 수 있게 하는 것이 현재 가장 주목 받는 기술적 이슈이다.프로스트: 개발자들이 WAP 표준을 쉽게 배울 수 있도록 WAP 표준은 HTML이 정적인 텍스트 페이지를 만들고 자바스크립트로 동적인 특징을 추가한 웹과 아주 비슷한 모델에 기본을 두고 있습니다. WML은 WAP에서 HTML과 같은 기능을 합니다. 단락, 하이퍼 링크, 테이블 속에 들어 가는 텍스트를 작성할 수 있도록 해줍니다. 하지만 이것만으로는 작은 화면에 컨텐츠를 최적화 하여 나타내기는 힘들다는 점을 알게 되었죠. 그래서 이를 보완해 줄 수 있는 무언가가 필요하게 되었고, WAP에서 자바스크립트를 대체하는 WML스크립트가 나오게 된 겁니다. 이것은 클라이언트측에서 입력된 내용을 확인합니다. HTML 문서에서 자바스크립트가 하는 것처럼요. 하지만 자바스크립트만큼 복잡하거나 필요한 장치가 많지는 않다는 게 WML스크립트의 두드러진 장점이 아닌가 생각됩니다. 스튜어트 : WML은 HTML과 매우 밀접하게 관련된 것처럼 보입니다. 그래서 숙련된 웹 개발자들은 별도의 과정 없이 WML을 바로 다룰 수 있어야 합니다. 그렇다면 두 마크업 언어가 가지고 있는 가장 큰 차이점은 무엇일까요? 그리고 HTML에 대한 경험이 있는 상태에서 WML을 배우려고 할 때 특히 주의해야 할 점은 뭐가 있습니까? 프로스트 : 가장 중요한 차이점은 WML은 XML을 기반으로 하고 있어 구문이 HTML보다 훨씬 더 엄격합니다. 예를 들어, WML은 모든 태그 이름을 매우 민감하게 처리하는 반면에 HTML은 어떤 경우라도 허용하죠. XML의 또 다른 점은 종료 태그가 필요 없는 빈 요소 태그(empty-element tag)는 다음처럼 작성해야 한다는 겁니다.
|
|
모바일 인터넷을 사용하는 인구가 급격히 증가할 것으로 예상되기 때문에 무선 컨텐츠 개발 산업도 꾸준히 성장할 것으로 보인다.HTML 웹 브라우저에서는 논리적 오류가 있더라도 대개 무시합니다. 하지만 WAP 브라우저에서는 분명 이런 게 문제가 됩니다. 속성 값을 둘러 싸는 따옴표와 엔티티의 끝에 세미콜론을 넣는 것을 잊어버리는 사용자도 많죠. 웹 브라우저에서는 이런 오류를 무시할 수 있지만, 대부분의 WAP 브라우저에서는 분명 오류를 발생시켜 문제를 일으키게 되는 겁니다. WML은 상호 작용을 할 수 있다는 점에서 HTML과 두드러진 차이를 보이며, HTML에서는 찾아 볼 수 없는 많은 새로운 특징이 있습니다. HTML은 새로운 특성을 첨가하며 발전을 거듭해왔습니다. 처음에 상호 작용은 하이퍼 링크에 제한된 특성이었지만, 넷스케이프에서 체크박스나 텍스트 입력과 같은 기능을 첨가했습니다. 그 후 자바스크립트도 첨가됐구요. WML은 이러한 특성에 접근하는 방식이 다릅니다. 즉 여러 특성을 계속적으로 첨가하기 보다는 일관되게 발전해 나갔다는 거죠. 물론 어느 정도의 새로운 특성은 첨가했지만 말입니다. 이에 대해서는WML과 WML스크립트 시작하기에서 자세하게 다루고 있으니 참고하세요. 스튜어트 : 상호 작용하는 방식을 위해서 WML이 많은 공을 들였다는 뜻입니까? 그렇다면 웹 모델과는 어떻게 다른지요? 프로스트 : 웹 페이지에는 폼 서브밋 버튼과 하이퍼링크가 있지만, 이는 각기 다른 제한 사항이 있고 화면에 따라 다르게 보이기도 합니다. WML에서는 제어(control)와 동작(action)이 별개라서, "태스크(task)"라는 게 있습니다. 태스크란 브라우저에서 수행하는 하나의 동작을 말하는데, 새로운 장소로 이동한다든가, WML스크립트를 구동하는 등을 말하는 거죠. 그 다음엔 실제 제어와 연결되어 실제로 제어하게 되는데, 여기에서 태스크란 하나의 태그일 뿐이므로 제어 내에 있게 됩니다. 이것은 POST 역할을 하는 하이퍼링크를 가지고 있다는 것을 의미하며, 이런 버튼은 WML스크립트가 작용하도록 할 뿐만 아니라 목록에서 선택할 수 있는 특별한 옵션과 동작이 끝난 타이머를 다시 작동하게 할 수 있는 태스크를 연결시킬 수 있습니다. 이렇게 해서 WML은 좀더 일관되게 발전해 왔고, 태스크를 배우게 되면 모든 분야에서 실제 사용 가능하게 되는 겁니다. 스튜어트 : WML에서 사용하는 "카드 데크(deck of cards)"에 대해서 좀 설명해 주시겠습니까?
WML은 HTML에는 없는 새로운 특성도 포함하고 있는데, 가장 눈에 띄는 특성은 상호 작용(interaction)을 지원한다는 것입니다. - 마틴 프로스트프로스트: 웹 페이지는 컨텐츠의 계속적인 흐름에 기반을 두고 있죠. 여러분은 이에 라벨을 붙일 수도 있고, 특별한 장소로 이동시킬 수도 있지만, 실제로 여러분이 하는 일은 흐름에서 고정된 장소로 스크롤하는 것입니다. WML에서는 파일을 카드 스택과 유사하게 다루는데, 카드 스택은 각각 다른 컨텐츠를 가집니다. 라벨은 계속되는 흐름에서 단순히 오프셋을 지칭하는 대신, 카드에 이름을 부여합니다. 스크롤링만으로는 한 카드에서 다른 카드로 이동할 수 없기 때문에, 카드에는 링크를 명시적으로 지정해 줘야 합니다. 이처럼 하나의 카드에 들어 있는 정보의 양을 작게 유지하고, 여러 카드의 순서에 관한 정보를 제공함으로써 스크롤하는 수고를 덜 수 있습니다. 실제 업무에서 프로그래머들은 이러한 특성을 많이 사용하지 않습니다. 꼭 필요한 것인데도 말이죠. 스튜어트 : 이번에 출간된 WML과 WML스크립트 시작하기에서는 현재 나와 있는 WAP 브라우저 도구 중에 많은 부분이 불안전하다고 지적하고 있습니다. 가능한 많은 장치에서 WAP 애플리케이션을 작동하고 싶어하는 개발자들이 특히 피해야 할 WML과 WML스크립트의 특징이 있다면 무엇입니까? 프로스트 : 이는 업무 상황에 따라 다르다고 봅니다. 테이블과 이미지 정렬과 같은 특징은 소수의 WAP 브라우저에서만 사용할 수 있지만, 실제로 사용해 보면 다른 기능에 심각하게 지장을 주지는 않습니다. 화면 표시가 이상하더라도 사용할 수는 있죠. 얼마 전에 WML스크립트를 아예 사용하지 말라고 한 적도 있지만, 지금은 상황이 많이 달라졌습니다. 많은 브라우저가 표준 라이브러리 기능 부분에 어려움을 겪었지만, 지금은 테스트 스위트가 점차 원래의 기능을 수행하게 되고, 잘못된 구현도 없애 나가고 있습니다. 가장 명심해야 할 것은 브라우저가 좀더 완벽해질 때까지 WML과 WML스크립트의 특정 표준에 너무 연연해서는 안된다는 것입니다. 스튜어트: 테스트 스위트는 무엇이며, 어떤 식으로 진행됩니까? 프로스트: 테스트 스위트는 두 가지 경우에 사용합니다. WAP 브라우저를 개발할 때, 정규적으로 테스트 스위트로 테스트해서 버그가 있는지 알아냅니다. 브라우저가 릴리즈할 때쯤엔 테스트 스위트를 다 구동했을 테고, 인증 절차에 이를 이용해서 브라우저가 표준과 호환되는지 입증하게 되는 겁니다. 최신 테스트 스위트는 여기에서 볼 수 있습니다. 스튜어트 : 현재 WAP 게이트웨이는 TLS에서 WTLS로 옮겨지면서 대부분 암호화된 데이터를 요구하고 있으며, 기술적인 부분에서도 주의가 필요한 불안전한 상황이라고 합니다. 이것이 실제로 중요한 부분인지, 그렇다면 왜 그런지 말씀해 주세요.
미국 텔레콤 시장이 불안한 요인 역시 WAP 사용을 지연시키고 있어, 미국에서 WAP이 널리 쓰이기까지는 시간이 더 걸리게 될 겁니다. - 마틴 프로스트프로스트 : 대다수의 보안 전문가는 편집증적인 증세를 보이는데, 이건 어쩔 수 없죠. 그들은 변화하지 않는 완벽주의자들이고 약점이라고 생각하는 부분이 있으면 불행해지기 때문입니다. 그들은 사용자가 누구도 신뢰할 수 없다라는 가정하에 시스템을 설계합니다. 아무리 신뢰할 수 있는 기업들도 개인의 정보가 유출되어 법정이나 정부에서 압력을 받게 되고, 게이트웨이는 크래커들에게 공격당할 가능성이 늘 있는 곳이기 때문입니다. 또 고려해 봐야 할 사항은 은행이나 금융 기관입니다. WTLS가 필요한 주요한 실제 이유가 바로 모바일 금융 처리를 하기 위한 것이기 때문입니다. 대부분의 은행은 컴퓨터 보안이 뭔지 제대로 모릅니다. 제대로 안다면 자칭 전문가라고 떠벌리는 사람들에게 그렇게 비싼 임금을 주진 않을 테니까요. 하지만 다른 사람이 접근해도 되는 정보와 그렇지 않은 정보를 구분하는 일은 잘 하고 있습니다. 그래서 개인적 데이터는 외부에서 접근할 수 없도록 규정으로 명시해 놓고 있으며, 이러한 개인적인 정보도 알고 있는 게이트웨이 운영자를 꺼리게 되는 겁니다. 스튜어트 : 프로스트씨는 개인적 데이터를 WTLS로 전송합니까? 프로스트: 개인적으로 이런 문제에 관해선 아무도 믿지 않기 때문에, 만약 누군가가 정보를 해독해서 나를 곤경에 빠뜨릴 수 있는 것은 전송하지 않습니다. HTTPS로 개인 신용 카드 번호를 웹사이트에 전송하는 것이나, WTLS로 전송하는 건 거의 같습니다. 제가 웹사이트에서 어떤 물건을 사서 카드로 결제하면, 나의 신용 카드 번호가 웹사이트로 전송되고 암호가 해독되어 저장됩니다. 그러면 그 회사는 신용 카드 회사에 정보를 보내기 위해서 재암호화를 시도해야 할 것이며 이 때 제3자가 관련되는 것입니다. 스튜어트 : WAP의 최신판(2000년 6월 Conformance Release)에서는 보안 문제가 거의 해결되었다고 하던데, 일반인이 이 버전을 사용하기까지는 얼마만큼의 시간이 걸릴까요? 프로스트 : 이는 외부 요건에 따라 다릅니다. WAP 관련 회사에서는 가능한 한 빨리 흥미있는 컨텐츠를 만들기 위해 노력하고 있습니다. 이 때 은행이나 개인이 보안에 관해 많은 관심을 보인다면, 관련 회사에서는 보안을 우선시한 제품을 출시하게 되겠죠. 스튜어트 : 직접 WAP 게이트웨이를 작성하신 걸로 아는데요, 이 작업은 어땠습니까? 그리고 기존의 제품을 쓰지 않고 굳이 직접 새로 작성한 이유가 있다면요? 프로스트 : WAP 게이트웨이를 작성하는 건 별로 어렵지 않습니다. 에러에 관한 규약 부분에 좀 문제가 있었고, 규약을 구현하는 데 문제가 발생하긴 했지만, 엔지니어라면 누구나 겪는 경험적 수준이었습니다. 기술은 대부분 고성능 네트워킹 시스템에서 사용하는 표준이었죠. 여러분들도 잘 작성한 TCP 스택 디자인을 공부하면 필요로 하는 실마리를 얻을 수 있을 겁니다.
WAP의 미래는 현재보다 더 재미있을 겁니다. WAP Forum에서 차세대 WAP은 W3C에서 HTML의 차세대 주자라고 밝힌 XHTML에 기반할 것입니다. - 마틴 프로스트직접 WAP을 작성한 건 특정 회사의 애플리케이션 서버 아키텍처와 잘 통합되는 게이트웨이가 필요했기 때문이었습니다. 끊김이 없는 사용자 환경과 나중에 다시 접속할 수 있으며, 작업을 멈춘 곳에서 계속할 수 있는 기능을 제공하려 했던 겁니다. 또 다른 이유는 고객들이 "죄송하지만, 저희 게이트웨이 제공자가 패치를 아직 전송하지 않았습니다"라는 메시지를 보게 되는 상황 대신, 우리가 소스에 접근해서 문제를 빨리 해결하려 했기 때문입니다. 프로젝트를 시작할 즈음엔 오픈 소스 게이트웨이를 사용할 수 있는 상황이 아니긴 했지만, 우리가 직접 작성하는 게 낫다고 결정하게 됐습니다. 스튜어트 : 현재 사용하고 있는 WAP(또는 프로토콜)에서 사용할 수 있는 장치, 즉, 휴대용 장치들이 얼마나 큰 비중을 차지합니까? 그리고 내후년까지 변화하는 수가 얼마나 될 것이라고 예상하십니까? 프로스트 : 대부분의 하이엔드(high-end) PDA는 웹 브라우저 환경을 지원하며, 앞으로도 이러한 경향은 계속될 것입니다. 현재의 PDA는 옵션으로 WAP을 가지고 있거나, 공급업자가 이를 위해 개발 중입니다. 이런 상황은 휴대 전화와는 사뭇 다른데, 유럽의 주요 휴대 전화 제조업체는 WAP을 사용하는 전화기를 한대 이상은 생산하고 있으며, 많은 제조업체에서는 계속 생산하는 구기기에 WAP 사용 환경을 만들기 위해 노력하고 있습니다. 미국에서는 폰닷컴(Phone.com)사의 HDML 시스템을 사용하는 휴대 전화가 많아 WAP 사용이 지연되고 있습니다. 미국 텔레콤 시장이 불안한 요인 역시 WAP 사용을 지연시키고 있습니다. 여러 시스템이 공존하며 아직 아날로그 네트워크를 사용하는 데도 있습니다. 유럽에서는 모두가 GSM을 사용하는데, 이는 전화 제조업체에서는 단 하나의 표준만 신경 쓰면 되며, 하나의 전화 소프트웨어에만 WAP을 통합시키면 된다는 거죠. 아무튼 미국에서 WAP이 널리 쓰이기까지는 시간이 더 걸리게 될 겁니다. 실제로는 어떤지 말을 못 하겠습니다. 모두가 다른 통계 자료로 말을 하고 있거든요. 이런 건 통계학자들에게 맡겨 놓는 게 나을 것 같네요. 스튜어트 : 충분히 공감이 가는군요. WAP을 대신할 가장 인기 있는 NTT 도꼬모의 i-Mode가 일본 외 시장에서도 성공하리라고 봅니까? 프로스트 : 현재로선 아닙니다. i-Mode는 도꼬모의 네트워크와 깊이 연관되어 있어, 이 네트워크의 데이터만을 이용할 수 있습니다. 다른 운영자들도 i-Mode를 그다지 좋아하지 않는 것 같고, 그래서 NTT 도꼬모라는 한 회사에 큰 힘과 영향력을 실어 주는 것도 꺼리는 것 같습니다. WAP의 장점이라면 누구나 참여할 수 있는 WAP Forum에서 규약을 만든다는 겁니다. 입회비가 좀 비싸긴 합니다만. 여러 회사에서 WAP은 죽었고, i-Mode가 미래의 표준이라고도 하지만, 이는 모두 주도권을 되찾기 위해 WAP을 폄하하는 데 지나지 않은 것 같습니다. 현재 WAP 개발에 들이고 있는 투자비가 다른 시스템보다 월등한 게 사실이거든요. i-Mode는 실제로 그렇게 특별한 것이 아닙니다. 일반적인 HTML과 사운드, 이미지 파일을 사용하죠. 실제적인 무선 통신의 세부 사항을 빼면, i-Mode는 HTML의 압축된 형태를 사용한다는 점이 특이할 뿐입니다. 무선 환경에서 유용하고 성공적인 애플리케이션 등에 대해서는 i-Mode에서 배울 게 많지만, 이러한 기술은 WAP을 포함한 다른 기술에도 적용 가능한 것들입니다. 스튜어트 : WAP과 WML의 미래는 어떻습니까? 혹 대역폭 문제 때문에 WAP이 퇴출당하진 않을까요? 프로스트 : 높은 대역폭이 WAP을 망치지 않고, 오히려 사용자의 경험을 올려 주며 컨텐츠를 더 풍부하게 만들어 줍니다. 낮은 대역폭에 최적화된 특별한 커뮤니케이션 프로토콜과 같은 WAP의 특화된 형태가 많이 생겨나, 일반적인 HTTP를 대체할 것으로도 보입니다. WAP의 미래는 현재보다 더 재미있을 겁니다. WAP Forum에서 차세대 WAP은 W3C에서 HTML의 차세대 주자라고 밝힌 XHTML에 기반할 것이며, WML과 마찬가지로 XML에 기반할 것이라고 밝힌 바 있습니다. 하지만 아직 갈 길이 먼 게 사실이죠. 덧붙여 말하자면, XHTML이 사용된다 하더라도 당분간은 WML이 우위를 점하고 있을 겁니다. WML은 작은 스크린에 최적화되어 있어 대역폭에서 앞선 다른 언어들보다 계속 사용될 확률이 큽니다. 다른 수십 메가급의 링크를 가진 전화가 나온다고 하더라도, 사용의 편리성으로 인해 소형 전화기를 계속 사용할 겁니다. 지금 휴대 전화를 들고 다니는 사람들을 한번 떠올려 보세요. 아무리 화면이 큰 전화기가 있다고 하더라도 얼마나 많은 사람이 더 편한 작은 전화기를 놔두고 큰 전화기를 사용할 것 같습니까? 큰 색정 화면에 맞게 디자인된 XHTML 컨텐츠는 이처럼 작은 화면에서는 깨져 보이겠지만, WML로 작성한 컨텐츠는 말 그대로 좋습니다.
이전 글 : 박래혁이 말하는 웹 디자인의 오늘
다음 글 : 단독 심야 데이트! 여성 개발자와 만나다
최신 콘텐츠