웹사이트 중에 페이지의 레이아웃을 자바스크립트를 이용해서 출력하는 사이트들이 있다. 자바스크립트를 끄고 웹페이지를 불러보면 레이아웃은 다 없어지고 콘텐츠 영역만 화면에 보이게 된다. 서울시청 사이트나 필립스사이트가 그러하고 가끔가다가 잊혀질만 하면 이러한 방식으로 구현되어 있는 사이트들을 접하게 된다. 접근성이 떨어진다거나 자바스크립트가 작동하지 않는 환경 얘기를 떠나서 이러한 사이트는 큰 문제를 가지고 있다.

이러한 방식으로 구성된 웹사이트의 가이드 라인을 보면 아래와 같이 이 방식의 장점을 나열하고 있다.

• 자바스크립트는 서버쪽의 코드 변경없이 쉽게 적용(included)할 수 있다.
• 사이트 엔터프라이즈 환경에 걸쳐서 사용할 수 있기 때문에 비용적으로 이득(cost-effective)이다.
• 자바스크립트 파일은 캐시가 되기 때문에 전송량이 감소되고 페이지 로드에 걸리는 시간이 단축되기 때문에 사용자 경험이 향상된다.
• 화면의 구성을 중앙집중적으로 관리할 수 있다.

정말로 그럴까?

첫번째 설명은 그럴듯 하게 들린다. 하지만 실제를 살펴보면 다르다. 자바스크립트를 적용하기 위해서 HTML 수정만 하면 되는 것은 맞지만 이것 역시 처음 한번 적용 할 때에는 모든 콘텐츠 페이지를 다 수정해 주어야 한다. 자바스크립트를 사용하든 서버측 언어를 사용해서 포함(include)를 하든 실제 변경하는 파일이나 작업은 크게 차이가 없다는 말이다. 어쨌거나 서버쪽에 있는 파일을 수정해 주어야 한다. 그것이 자바스크립트이든 서버측 언어를 사용한 페이지이든 차이는 없다. 오히려 이스케이프되어 있는 자바스크립트 안에 있는 HTML을 수정하는 것이 서버측 언어 파일에 들어 있는 HTML을 수정하는 것보다 10배는 더 힘들다.

두번째로 비용적 이득이라는 말은 자바스크립트에만 국한된 장점이라고 보기는 힘들다. 엔터프라이즈를 어떠한 개념으로 사용했는지 정확히 이해하기가 힘들어서 오해한 것일 수도 있겠지만 자바스크립트 이기 때문에 전반에 걸쳐서 사용할 수 있다는 것은 이해하기 힘들다. 오히려 XHTML과 같은 환경, 하다못해 동적으로 생성되어 캐시된 HTML을 서버에서 포함하는 것으로도 충분히 달성할 수 있는 장점이다. 네번째인 중앙집중적인 관리도 이와 마찬가지로 자바스크립트 만의 장점이라고 보기는 힘들다.

세번째를 살펴보면 캐시가 되면 처음 한번만 전송을 받고 두번째 부터는 로컬 컴퓨터에 저장되어 있는 파일을 그대로 불러오기 떄문에 속도가 빠르고 사용자 경험이 좋아진다는 얘기다. 하지만 현실은 정 반대다. 글로벌 사이트이다 보니 공통 자바스크립트 파일이 3000라인이 넘어가고 그 크기도 36KB이다. 처음 한번만 전송되고 캐시 된다고 해도 페이지가 로딩될 때마다 3000줄의 자바스크립트가 메모리에 올라가고 페이지가 랜더링 되기 전에 해석을 해야만 한다. 자바스크립트가 서버측 언어보다 훨씬 느리다는 것은 누구나 알고 있는 사실이고 실제로 이 자바스크립트 때문에 페이지를 이동할때 마다 화면이 깜빡이고 페이지가 다 로딩될 때까지 걸리는 시간이 매우 길다. 덩치가 큰 자바스크립트 파일 뿐만 아니라 크기가 작은 스크립트 파일도 같은 현상이 발생된다. 자바스크립트 파일을 먼저 해석하고 실행해야 페이지 랜더링이 되기 때문에 어쩔 수 없는 현상이다. 사용자 경험이 향상되기는 커녕 오히려 매우 떨어지고, 사용자 뿐만 아니라 관련된 모든 사람들 피곤하게 만드는 결과를 초래하고 있다.

레이아웃이나 메뉴의 링크를 자바스크립트로 관리 하는 방식을 사용하는 사이트를 많이 볼 수 있다. 사용하는 사람은 매우 효율적이라고 생각할지 모르지만 서버측에서 처리해야 하는 일을 클라이언트 측으로 전가하여 문제를 발생시키는 아주 비효율적인 방법이다. 서버측의 부담을 줄이기 위해서라는 말을 하는 초보 개발자들도 있지만 서버가 해야 할 일을 효율적으로 처리하는 것이 부담을 줄이는 것이지 안하게 하는 것이 부담을 줄이는 것은 아니다.

서버와 클라이언트를 완전하게 이해하고 각자의 목적에 맞게 적절한 기술을 구현하는 것이 무엇보다 중요하다.