Google Suggest Dissected... Gmail과 더불어 JavaScript/XMLHTTP 기술의 극한을 보여주는 Google Suggest의 메카니즘을 분석한 글이다. 조금이라도 더 빠른 응답시간을 얻기 위해 Google의 엔지니어들이 얼마나 머리를 쥐어짰는지 대충이나마 알 수 있다. 너무 일찍 브로드밴드 인터넷이 일반화되어 버리고 quick & dirty 웹사이트가 판을 치는 우리나라에선 이런 기술을 추구할 이유도 없고 그럴 여건도 안되지만, 기질이 있는 엔지니어라면 항상 어디까지 갈 수 있는지 추구해보고 싶기 마련이다 (월급만 나오면!).

이런 기술을 보다 보니 몇 해 전, N사의 WAP 브라우저를 포팅하는 프로젝트에서 비슷한 일을 하려했던 것이 기억난다. 그 때 경쟁 브라우저와 차별화 포인트의 하나로 tree 태그를 추가 구현한 후 XMLHTTP와 비슷한 방법에 의해 페이지 전체를 reloading하지 않으면서 subtree가 더해질 수 있도록 하려 했었는데 N사의 브라우저가 너무 작은 메모리에 최적화되어있어 DOM을 제대로 지원하지 않는 바람에 포기했었다. 그 프로젝트는 결국 여러가지 이유로 상용화되지 못했지만, 이런 류의 기술은 bandwidth가 제한된 무선 인터넷 브라우저에서 더 쓸모가 많을 것임에도 불구하고 ECMAScript를 지원하는 브라우저가 속속 실용화되고 있는 지금에도 아직 무선 인터넷쪽에선 사용되지 않고 있다.

브라우저의 bookmark, back & forward, reload등의 기능이 항상 기대하는 대로 동작하던 시절은 frame과 cookie가 등장할 때부터 이미 지나갔지만, JavaScript와 XMLHTTP의 적극적인 사용은 그런 경향을 더욱 가속화할 것이다. XAML에 의한 사이트는 로컬 애플리케이션과 사실상 구분이 되지 않을 것이다. 보다 나은 usability를 추구하는 노력들이 웹을 그토록 빨리 확산시키는데 일조했던 단순함과 일관성을 해치게 되지는 않을까?