LimitationOfAjax
기계 번역, 자동번역기 문제
세계에 걸쳐 열려 있는 인터넷, WebTwoPointZero 에서, 기계 번역, 자동 번역기는 매우 중요합니다. 국내 포털에서 일본어 웹 번역 서비스를 제공하면서, 뉴스/TV 외신 보도 보다 훨씬 빠르고 방대하게 정보를 접할 수 있는 커다란 변화가 일어 났으며, 특정 문화권, 특정 언어, 특정 지역에 대한 모든 트래픽이 번역기를 일단 거쳐가게 되는 SearchPortal 역할도 빠르게 확대되고 있습니다.
그런데, 기계 번역에서 AJAX는 문제입니다. 보통 기계 번역이 정적인 HTML 문서를 번역기로 번역한 뒤 그 결과를 다시 HTML로 전송해주는 것이 보통입니다.
그런데, 만약 문서의 내용이 AJAX를 통해 동적으로 전송된다면, 어떻게 합니까? 그렇다면, 그 내용을 번역기가 읽어들이기 위해서, 번역기 자체에 AJAX를 따라가면서 그 동적인 전송을 그때그때 받아올 수 있는 장치가 필요하게 됩니다. 즉, AJAX를 쓴 웹페이지를 기계 번역하기 위해서는 번역기 자체가 웹브라우저의 Javascript/XML 전송 기능을 충실히 재현할 필요가 있다는 이야기입니다.
이것은 결국 아래에 이야기한 검색의 문제와 같은 성격의 문제입니다만, 번역기 업체가 검색 업체에 비해, 상대적으로 가상적으로 웹브라우저의 동작을 흉내내는 기술이 부족한 경우가 많다는 점을 생각해 보면, 좀 더 골치아픈 문제일 수도 있습니다. 나아가서는, 웹브라우저 개발 업체가, 검색, 기계번역 등의 문제에서 효율적으로 교류하거나 참여할 필요를 살펴볼 수 있는 대목이기도 합니다.
검색의 문제
Google Map 을 필두로 AJAX에 대한 관심이 높아지고 있습니다. 데이터를 XML 형식으로 보관하고 Javascript 를 이용해 사실상의 웹표준에 따르면서 동적으로 데이터를 게시할 수 있어서 재미난 일들을 많이 할 수 있습니다.저 역시 XML을 처음 소개 받았을 때부터, 많은 용도를 떠올리고 있었습니다만, AJAX를 이용해서 대부분의 데이터와 프리젠테이션 부분을 분리했을 경우에 상당히 치명적인 문제점이 있습니다. 무엇인고 하니,
웹페이지를 저장을 해도 실제 데이터 내용이 저장이 되지 않는다.
다시 말하면,
현재 검색엔진 사이트에서 내용을 Search 할 수 없다.
라는 것입니다.
예를 들어봅시다. index.htm 이라는 사이트로 연결했을 때, 상황에 따라 kbo.xml 이라는 XML데이터를 가져와서, 화면에 프로야구 결과를 표시해주는 사이트가 있다고 봅시다. 화면에 보이는 URL은 index.htm 이고, 이 페이지를 저장하면, 프로야구 결과가 저장되는 것이 아니라, kbo.xml에 접근하는 자바스크립트 가 저장이 됩니다.
이렇게 해서는 "롯데자이언츠"나 "프로야구"로 검색을 해도 결코 index.htm 을 찾아내기 힘듭니다. 심지어 kbo.xml 을 찾아내기도 힘듭니다. (보통 자바스크립트 코드에 들어 있는 문자열을 링크로 간주해서 거기까지 긁어 저장하지는 않습니다.) index.htm 을 찾아내려면, kbo.xml 으로 검색해야 하는데, 이것을 애초에 검색할 때 생각하기란 쉽지 않습니다.
XML 데이터를 브라우저 상에서 간접적으로 불러온 뒤에 표시하는 것이기 때문에, 기존의 웹페이지 크롤링 방식으로 웹사이트를 검색로봇이 긁어와서는 내용자체가 저장되지 않습니다. 다만, 그 데이터를 긁어오는 자바스크립트 코드만 저장될 뿐입니다. 이래서는 실제 내용에 대한 검색이 이루어지지 않습니다. 이것은, 외부 사용자들과 연결되는 1차 통로가 검색사이트인 요즘 상황에서 치명적인 문제점입니다.
- AJAX에 대한 Likejazz님의 포스트 http://www.likejazz.com/29692...
- 드디어 대가가 붓을 들다! 김중태 문화원의 포스트 http://www.dal.co.kr/blog/200...
가장 적극적으로 AJAX를 도입하고 있는 Google 은, 이런 문제점에 대해서...
그렇습니다. 구글 스스로도 AJAX의 검색에 대해서 해답이 없습니다. 이것을 위해서는 실제로 Javascript를 어느정도 해석을 해서, AJAX로 보여주는 XML 데이터를 찾아가서 접근할 수 있는 URL과 연결시켜야 합니다.
이것은 AJAX 기술자체의 편법으로 해결하기 보다는, 검색엔진과 웹사이트의 페이지 저장 기능 자체가 발전되어서 해결되어야 할 일입니다. 그때가 되어서야 AJAX를 단순한 유틸리티가 아니라, 정말로 데이터와 프리젠테이션을 완전히 분리시키는 도구로 사용할 수 있을 겁니다.
fallback 을 고려해야 합니다.
그러면 문제는 어느 정도 해결됩니다.
편법이긴 하지만, user-agent 를 감지해 robot 이면 fallback 용 페이지로 돌린다면
사용자는 ajax 의 효율을 즐기고, 비 js 지원 브라우저 사용 사용자는 fallback 용 페이지를
즐길테고, 검색 엔진은 ajax 에 구애받지 않고 기존의 js 없이 오로지 서버 스크립트만으로
출력한 페이지를 긁어갈 수 있습니다.
여기서 발생하는 것은 비용 증대의 문제.
외국 사이트도 많이 그렇지만, 국내는 js 를 off 하면 아예 서핑이 안됩니다.
fallback 고려가 전혀 안이루어진 시점에, 과연 그런 것까지 비용을 지출하면서
개발을 지휘하려는 상사, 내지는 개발자가 있을지가 문제.
글쎄요? 제가 볼 때는 현업에서 그걸 스스로 원하는 사람은 1% 도 안된다고 봅니다만..
누가 코딩 양이 늘어나는 작업을 하고 싶어하겠어요. -v-
ajax 로 구현하는 양이 많아지면 많아질수록, fallback 은 그만큼 힘들어지죠.
js 가 하는 일을 모두 서버 스크립트에서 처리해서 기존의 방식처럼 리프레시를 해야
되는 형태로 개발도 같이 떠맡아야 한다면... 과연 ajax 를 쓰려고 할려나요.
그러나 현장에서 그 럴 리 가 없으므로, fallback 무시한 채 개발은 이루어질 것입니다.
그것이 현실.
- yser 2005.07.13, 3:48 pm
fallback 은 아니지만 fallback 처럼 사용되고 있는 예가 포털이나 설치형 블로그입니다.
이글루스나 태터의 경우, iframe 을 사용해서 답글을 읽어와서 때려 집어넣는 구조입니다만
만약 이것이 js 에만 의존했을 경우, 검색기는 답글의 내용을 긁어가지 못했을 것입니다.
그러나, permanent link 라는 형태로 js 를 쓰지 않고 한 번에 답글과 트랙백을 같이 표시하는
기능이 있기에, 이것이 마치 js 기능의 fallback 처럼 작용하여 결국 검색기는 긁는 시점에서
이미 하나의 완성된 문서를 가져가기 때문에 검색이 가능하게 되지요.
이것처럼 부수적인 효과를 누리게 되는 경우도 있지만.. 사실 fallback 을 따로 고려해야 한다는 점은 여전. 하지만 현실 여건 상 개발 시간이 최소 두 배 이상 늘어나는 이 작업을 과연....?
하나 더 문제. ajax 는 완벽한 기술이 아니며, 표준도 아니고, 브라우저마다 미묘한 동작이 다르다는 점. 진정 서비스를 위해서라면.. 구글처럼 IE, FF, OPERA, SAFARI 등에서 다 테스트 해보아야 할 것입니다. 이것은 특히 UTF-8 쪽과 연계되면 꽤나 신경쓸 것들이 여기저기.
생각만해도.. 아희-
- yser 2005.07.13, 3:54 pm
다른 지적들
likejazz님 블로그의 소개 http://www.likejazz.com/29811... 를 따라간 제이콥 닐슨의 글 http://www.usabilityviews.com... 에서 AJAX의 문제점을 주장한 글이 있습니다.대부분, 제 지적과 yser님의 덧글에서 나온 내용입니다만, 정리 요약하면 다음과 같습니다.
- 웹페이지에서 데이터를 페이지 단위로 전송하지 않고 복잡하게 분리해서 전송한다는, 방식자체가 구조적으로 좋지 못함
- (yser님이 언급해 주신) 표준이 없고, 지원하는 브라우저도 한계가 있으므로 호환성이 부족함
- 웹페이지를 프린트할 경우 이상하게 나오기 쉬움
- 만들기 어렵고 읽기 어려움
- (위에서 이 페이지에서도 언급한) 검색의 문제
- (yser님이 언급해 주신) fallback이 있는 경우, 사용자들이 AJAX를 피하는 경우가 많음
프린트 문제는 웹브라우저의 개선, 프린팅 유틸리티 SmallPrograms 의 등장으로 간단히 해결될 수 있는 문제 일 수 있고, 맨마지막 사용자들의 AJAX 싫어함은 언뜻 근거자료가 부족해 보이긴 합니다.
나머지 부분들은, 이 페이지에서 예전부터 이야기되었던 내용과 대체로 부합합니다.
실제로 저장해보세요. 저장됩니다.
http://www.tiddlywiki.com/ - nohmad 2005.12.08, 7:15 pm
- 무엇이 어떻게 저장된다는 이야기신지 조금만 더 설명해 주시겠습니까? 위의 AJAX 페이지 저장문제라면, 대표적인 http://maps.google.com 의 경우, FireFox 1.0.6 , IE 6.0.28 모두 다, 새 이름으로 저장하기 한 것을 다시 읽을 경우 페이지가 모두 깨집니다. XML을 동적으로 처리한 결과가 아니라, JavaScript 소스코드만 저장하게 되기 때문입니다.
위에 적은 TiddlyWiki에 가서 새 페이지를 만들거나 다른 링크를 클릭해서 페이지 내용이 바뀌도록 한 다음에 저장해보세요.
구글맵스의 경우는 이미지 등의 리소스들이 모두 원격에 있기 때문입니다. 이 점은 닐슨 박사도 지적한 바, 외부 리소스이기 때문에 어쩔 수 없습니다. - nohmad 2005.12.09, 4:20 am
- 제 착각일 수도 있습니다만, 제가 살펴본바로, TiddlyWiki의 숨겨진 부분 펼쳐 보여주기는 AJAX 로 구현되어 있지 않습니다. 클릭할 때 동적으로 읽어와서 펼쳐보여주는 것이 아니라, 처음 페이지 로딩을 할 때 이미 다 읽어 온 후에 그냥 JavaScript 로 렌더링만 멋있게 하는 것입니다.
Javascript를 끄고 위 페이지를 TiddlyWiki 페이지를 다시 한 번 보십시오. 초기 페이지에 이미 모든 내용이 포함되어 있는 것이지, 동적으로 XML 데이터를 전송 받는 것이 아닙니다.
xmlhttp 요청을 통해 받아온 데이터로 div 등의 요소를 업데이트한 후에 불여우나 IE 등의 브라우저에서 페이지를 저장하면, 현재 렌더링된 상태로 저장이 됩니다. 이러한 specific한 동작이 얼마나 표준화되어 있는지는 잘 모르겠습니다만, TiddlyWiki가 이 behavior에 강하게 의존하고 있어서 예로 들어보았습니다. TiddlyWiki 자체는 xmlhttp를 사용하는 것은 아니지만, 비동기적인 페이지 변경이란 점에서 Ajax와의 유사점을 찾을 수 있을 것 같습니다..
저도 제이콥 닐슨의 글에 대한 코멘트를 작성하고 있는 중이어서 관심있는 주제여서 초면에 실례를 한 것 같습니다. 다 작성되면 트랙백 걸겠습니다. - nohmad 2005.12.09, 9:43 am
- 실례라니, 과한 말씀이십니다. 저역시 좋은 이야기 나눌 수 있어 기뻤습니다. 말씀하신대로, Javascript가 동적으로 생성한 내용이 어디까지 정적으로 반영되어서 브라우저가 저장하느냐, 하는 내용은 매우 임의적인 것입니다. 예를 들면, 평범한 document.write 같은 것은 대부분 반영된 결과가 저장되고 있지 않습니다.
또한 글 내용 중에 언급하는 요점은, 웹브라우저가 이모양이니, 더욱 간단하고 표준화되어 있지 않은 대부분의 검색 엔진 및, 웹 애플리캐이션의 크롤러, 로봇들은 거의 전혀 이런식의 동적인 페이지의 변형을 저장할 능력이 없다는 점입니다.
이러한 검색엔진의 로봇과 AJAX와의 관계는 ManWatching 페이지에서 좀 더 써보았으니 참고하시기 바랍니다.
(마지막 변경 UNIX clock : 1193966513 / Common clock 2007.11.02, 10:21 am )
다음글 SpamRacism
