2008/07/01 01:10
[여행의일상]
여러 분들이 뻔히 아실만한 웹 클라이언트 스크립트 관련 안티패턴 하나를 소개 해 봅니다.
그림 자르기.
90년대 말, 큰 이미지를 그대로 웹사이트에 올리는 행동은 '초보 웹디자이너'로 치부되기 십상이었습니다.
좀 더 빠른 체감속도를 위해 그림파일의 확장자로 JPG보다는 컴퓨서브의 GIF를 사용해야 했고, 큰 이미지는 수고스럽게 포토샵을 켜고 잘게잘게 채를 써는 것을 덕목으로 여겼습니다. 이는 디자인을 마크업으로 재생산하는 과정 중 필수 과정의 하나였죠.
지금은 수고스럽게 채를 썰 이유가 없고, 외려 이런 행동은 비용을 들게 하는 비생산적 행위라고 널리 알려져있지만, 자바스크립트·CSS파일 사용도 이 패턴에 동일하게 적용된다는 사실을 개발자들은 가슴 깊이 느끼고 있을까요?
적어도 저는 인식 하고만 있었지 느끼고 있진 않았습니다. 그런데 오늘 늦은 저녁 회의 중에, 서버 개발자분께
"자바스크립트 파일 너무 많이 만들지 마세요. 안좋아요." 라는 밑도끝도 없는 이야기를 듣고 순식간에 아래 이야기들이 생각 났고, 이내 마음 속으로 정리를 하게 되었습니다.
왜 잘게 자르면 안돼?
오늘, 91.9Mhz 타블로의 '꿈꾸는 라디오'에서 이런 멘트가 있었는데요.
90년대 말에는 인터넷 속도가 시원찮았습니다. 56k, 28.8k모뎀 사용자 또한 고려 해야 했었고요. 그래서 브라우저의 http 연결갯수를 full로 활용하기 위해 이미지를 최대한 잘게 쪼개어, 동시에 여러개의 그림이 계단식 논과 밭 형태로 뿌려지게 함으로, 사용자들이 '오, 그림이 조금씩 보여지고 있어!' 라는 안도감을 느끼게 했습니다.
하지만 현재는 그럴 일이 없습니다. 한국의 인터넷은 이미 트루컬러의 bmp파일이라도 우적우적 씹을만한 충분한 속도를 지니고 있어 지난 세월의 패턴은 이슈 삼을만한 것들이 아니게 되었습니다. 게다가 그런 행동들은 다음과 같은 추가 비용을 가져다 줍니다 :
그렇다면, 파일 하나로 뭉쳐서 쓰면 되나?
그럼 파일 하나만 만들어? javascript.js 라고 만들면 되나??-_-
그건 또 아닙니다. 하나의 페이지에서 전체 자바스크립트를 다운 받으면 불필요한 소스코드까지 다운받게 됩니다. 게다가 소스 관리도 버거워지죠. 이건 뭥미...
그럼 어쩌라고-_-
일단 가장 기본적인건 적당히 효율적으로 나누어 쓰는 것입니다. 반복되는 서버페이지를 돕는 스크립트를 뭉쳐 파일을 만들어, 브라우저 캐시의 효율성을 극대화 시키는거죠.
거기에 더하여, 웹사이트 최적화 기법에서 밝히는, DOM스크립트를 이용하여 동적으로 css나 자바스크립트를 브라우져에 뿌리거나 하는 작업으로 90년대 말, 사용자들이 그림자르기에서 느끼던 '체감속도 효과'를 발휘할 수 있습니다.
쓰고보니 집에 오면서 읽었던 책의 내용이 많이 녹아 있네요.
쉽고 모두 알고 있는 작은 부분에서도, 아는 것과 느끼는 것의 차이로 다른 결과물을 만들게 됩니다.
또한 중요한 것은, 좋은 패턴을 늘여나가는 것도 좋지만 안티패턴을 줄여나가는 것 같습니다.
그림 자르기.
90년대 말, 큰 이미지를 그대로 웹사이트에 올리는 행동은 '초보 웹디자이너'로 치부되기 십상이었습니다.
좀 더 빠른 체감속도를 위해 그림파일의 확장자로 JPG보다는 컴퓨서브의 GIF를 사용해야 했고, 큰 이미지는 수고스럽게 포토샵을 켜고 잘게잘게 채를 써는 것을 덕목으로 여겼습니다. 이는 디자인을 마크업으로 재생산하는 과정 중 필수 과정의 하나였죠.
지금은 수고스럽게 채를 썰 이유가 없고, 외려 이런 행동은 비용을 들게 하는 비생산적 행위라고 널리 알려져있지만, 자바스크립트·CSS파일 사용도 이 패턴에 동일하게 적용된다는 사실을 개발자들은 가슴 깊이 느끼고 있을까요?
적어도 저는 인식 하고만 있었지 느끼고 있진 않았습니다. 그런데 오늘 늦은 저녁 회의 중에, 서버 개발자분께
"자바스크립트 파일 너무 많이 만들지 마세요. 안좋아요." 라는 밑도끝도 없는 이야기를 듣고 순식간에 아래 이야기들이 생각 났고, 이내 마음 속으로 정리를 하게 되었습니다.
왜 잘게 자르면 안돼?
오늘, 91.9Mhz 타블로의 '꿈꾸는 라디오'에서 이런 멘트가 있었는데요.
왜 답은 항상 바뀌는거야? 똑같은 문제인데 어렸을때랑 지금이랑 답이 왜 달라서 날 이렇게 힘들게 해?세상이 이런가 봅니다. 그래서 이전의 패턴은 지금 안티패턴이 되었습니다.
90년대 말에는 인터넷 속도가 시원찮았습니다. 56k, 28.8k모뎀 사용자 또한 고려 해야 했었고요. 그래서 브라우저의 http 연결갯수를 full로 활용하기 위해 이미지를 최대한 잘게 쪼개어, 동시에 여러개의 그림이 계단식 논과 밭 형태로 뿌려지게 함으로, 사용자들이 '오, 그림이 조금씩 보여지고 있어!' 라는 안도감을 느끼게 했습니다.
하지만 현재는 그럴 일이 없습니다. 한국의 인터넷은 이미 트루컬러의 bmp파일이라도 우적우적 씹을만한 충분한 속도를 지니고 있어 지난 세월의 패턴은 이슈 삼을만한 것들이 아니게 되었습니다. 게다가 그런 행동들은 다음과 같은 추가 비용을 가져다 줍니다 :
- 용량이 더 커진다.
파일 헤더, 문서 정보 따위의 주석 등으로 인해 '하나의 파일'일 때 보다 더 많은 용량을 가지게 합니다.
- http 요청수를 늘인다.
예를 들어 설명하자면, 집에서 마을버스를 타고 이마트에가서 이번 주말에 먹을 음식들을 한번에 사오면 되는데, 사과 하나, 우유 한팩, 라면 한 봉지, 과자 한상자를 하나 씩 살 때마다 이마트를 한번씩 따로 가며 비 생산적인 '마을버스 왕복비용'을 발생 시키게 되는 격입니다. 여기서 중요시하는 것은 왕복 거리가 아니고 요금을 내는 횟수입니다. 쓸데없는 http요청 갯수를 늘일 필요가 없습니다.
- 자연스레 DNS서버 조회를 늘인다.
이것은 위와 비슷하지만 또 다른 문제입니다.
대부분의 웹사이트들은 IP주소를 가진 서버가 URL을 사용하여 쉬운 연결명(도메인)으로 접속할 수 있도록 DNS를 사용합니다.
서버 <--------------> DNS서버<--------------> 사용자
여기서 마을버스 왕복비용과 비슷한 비용이 발생합니다. 바로 DNS사용 비용인데요, 브라우저에서 요청하는 주소를 DNS서버가 조회하는 데에 이 비용이 발생합니다. 브라우저는 호스트 이름을 조회하고 완료될 때까지 어느것도 다운받지 못한 채 꾹 참고 있습니다. 수많은 이미지들, 스크립트 파일들은 일렬로 줄을 선 채 자신의 차레를 기다리고 있는 것입니다.
그렇다면, 파일 하나로 뭉쳐서 쓰면 되나?
그럼 파일 하나만 만들어? javascript.js 라고 만들면 되나??-_-
그건 또 아닙니다. 하나의 페이지에서 전체 자바스크립트를 다운 받으면 불필요한 소스코드까지 다운받게 됩니다. 게다가 소스 관리도 버거워지죠. 이건 뭥미...
그럼 어쩌라고-_-
일단 가장 기본적인건 적당히 효율적으로 나누어 쓰는 것입니다. 반복되는 서버페이지를 돕는 스크립트를 뭉쳐 파일을 만들어, 브라우저 캐시의 효율성을 극대화 시키는거죠.
거기에 더하여, 웹사이트 최적화 기법에서 밝히는, DOM스크립트를 이용하여 동적으로 css나 자바스크립트를 브라우져에 뿌리거나 하는 작업으로 90년대 말, 사용자들이 그림자르기에서 느끼던 '체감속도 효과'를 발휘할 수 있습니다.
쓰고보니 집에 오면서 읽었던 책의 내용이 많이 녹아 있네요.
쉽고 모두 알고 있는 작은 부분에서도, 아는 것과 느끼는 것의 차이로 다른 결과물을 만들게 됩니다.
또한 중요한 것은, 좋은 패턴을 늘여나가는 것도 좋지만 안티패턴을 줄여나가는 것 같습니다.
Trackback Address :: http://songsl.net/trackback/6
