자바스크립트를 이용한 레이아웃 출력의 단점

July 30, 2007 10:36 PM

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

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

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

정말로 그럴까?

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

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

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

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

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

Comments

  • Hooney 2007-07-31 07:07

    지난 몇년 동안 웹의 환경이 지나치게 서버측 중심으로 무게 이동한 점이 잘못이죠. 서버측과 클라이언트측 모두 균형을 잃지 않고 웹사이트를 제작해야 하는데, 이 둘의 역할과 책임 분담이 한곳으로 집중된 잘못입니다.

    해당 사이트 담당자들이 클라이언트 관점에서 최적화를 다루는 "<a href="http://hooney.net/2006/03/23/253/">웹사이트 최적화 테크닉</a>"을 보고 공부해야 겠네요~ ㅎㅎ

  • freeism 2007-07-31 09:07

    '웹사이트 최적화 테크닉' 좋은 책 소개 감사합니다. ^^
    저도 한 번 읽어봐야 겠네요.

  • 신현석 2007-07-31 10:07

    나 아직도 안읽어봤는데...그냥 책장에 꽂혀 있음;;

  • deute 2007-07-31 14:07

    분명히 서버쪽 언어에서도 include를 지원함에도 불구하고 그 비율이 많지 않은걸 보면 개발자들 그거 바꾸는 일을 노가다라고 생각했기 때문일까요 -_-;;
    아직 웹 퍼블리셔가 대우를 못받기 때문일까요;

  • 신현석 2007-07-31 15:07

    서버측 개발자가 자바스크립트로 모듈을 만들어서 클라이언트 개발자한테 자기 일을 떠넘긴 걸수도...

  • Jinoopan 2007-08-03 09:08

    자세히 알지 못합니다만, 저같은 사용자의 입장에서는 어느 브라우저에서나 그냥 빠르고 제대로 보여지길 기대할 뿐입니다. 화면이 깨지면 안가게 되더군요. 자칭 개발자의 작품이라고는 해도 그런 식이라면 저의 주먹구구식 홈페이지 단장과 다른 것이 무엇인가 싶습니다.

  • 지나가다 2007-08-03 11:08

    백엔드 개발자와 연계가 무척이나 중요한 부분입니다. 하지만 현실은...너무 잔혹하기만...
    특히... 대규모 사이트 중 개발과 UI업체가 다른 경우는 정말 많습니다.
    대부분이 UI요소를 include 로 넣는 걸 싫어하며, 그렇게 하는게 업무를 더 떠안는 거라 생각합니다. 개발 코드 소스 또한 절대 공개/공유 하지않습니다. 마크업따로 개발소스따로 이니.. 수정이 많은 UI이슈들에 대해 일일이 반영해주는 것을 귀찮은 일이라 생각하죠
    그래서 JS로 가져가는 경우가 많습니다. 접근성을 해치더라도 그렇게 하자고 하는데 할말있나요... 쩝;;;; 그들의 귀차니즘과 귀를틀어막는 습성. 어쩌라구여... 다른 개발업체랑 일하기 너무 힘듭니다~ㅠㅜ

  • mAGa 2007-08-09 17:08

    레이아웃 말고 시작적 요소를 가미하는데 자바스크립트를 이용하는 것은 어떻게 생각하시는지요?
    HTML+CSS에 어느정도 익숙해지더라도 여전히 만만치 않은 것 중 하나가 미려한 테두리를 만드는 것이 아닐까 생각합니다.
    단순히 레이아웃을 HTML+CSS로 구현한 정도만이 아니라, 접근성이나 의미론까지 충족시키자면 여간 머리를 잘 쓰지 않고는 완성도가 높아지기 힘들더군요. 단순 구현만하는 데까지는 테이블식 레이아웃에 비해 경쟁력이 있을지 모르지만, 담고 있는 철학까지 충분히 실현하자면 투자되는 입력에 비해 출력의 효과가 크지 못한듯 합니다.
    그래서 요즘 생각하고 있는 것이, 아무런 의미론적 정보를 제공하지 않는 테두리와 같은 것은, 머리를 쥐어 짜가며 의미있는 마크업과 연계하여 구현하려고 몸부림치기보다는, 자바스크립트로 처리해버리는 것이 더 효율적이지 않을까 하는 것입니다.
    스크립트로 처리한 효과가 나타나는데 약간의 시간차가 발생하기도 합니다만, 이게 문제될정도로 느리다면 이미 더 결정적인 문제에 봉착해 있는 것이므로 크게 문제가 될 것 같지는 않을듯합니다.
    이런식의 자바스크립트 사용해 대해서는 어떻게 여기시는지요?

  • 신현석 2007-08-09 21:08

    CSS의 한계를 자바스크립트로 보충하는 것은 저도 가끔 사용하고 있습니다. 다만, 너무 과하게 사용해서 부하를 많이 주면 안되게 조심해야 할 것 같습니다.

Post a comment

:

: 공개 되지 않습니다. Gravatar를 표시 합니다.

:

: HTML 태그를 사용할 수 없습니다.