이바닥이 원래 그래
EBADAC - OOPARTS : Out Of Place Articles.
Archive for December, 2006
December 20, 2006 at 9:30 pm · Filed under WebDevelopment, WebStandard
최근 liquid 또는 elastic design 에 대한 관심들이 많아지고 있는데요,
개인적으로 liquid나 elastic design의 유용함을 인정하면서도 실제 현장에서 쓰기에는 힘들지 않나.. 하는 생각을 하고 있었습니다.
여러가지 이유가 있겠으나, 하나의 디자인으로 여러 종류의 디바이스 혹은 브라우저 크기에 맞춰 유동적으로 변하는게 그리 쉽지많은 않거든요. 아무리 빗겨흘리고 늘렸다 줄였다 해도 고정된 디자인의 한계를 벗어나기는 어렵더군요.
그런 생각을 하면서 요즘의 liquid, elastic 유행(?)에 한발 물러서 있던 차에…
오래간만에 ALA에 괜찮은 기법이 하나 소개되었습니다. liquid 또는 elastic 의 한계를 뛰어넘은, 가변폭에 맞춘 디자인 변경입니다.
간단하게 js 파일을 하나 추가함으로써 어떠한 환경에서도 보기 좋은 웹페이지를 만들어낼 수 있겠더군요. 물론 주의깊게 작성을 하긴 해야겠습니다만.
그동안 어떻게 CSS를 조작해서 가변폭 레이아웃을 만족스럽게 표현할까 고민했었는데 좋은 참고가 될 듯 해서 소개합니다.
샘플 1, 샘플 2 (모든 링크는 Shift+Click 으로 새창에서 뜹니다.)
liquid 디자인과 zoom 디자인을 넘어서 adaptive 레이아웃이라는 선언도 곱씹어볼만 한데다, 샘플 2에 Tab 디자인은 영감을 팍팍주는 인터페이스네요. 그동안 ALA에 올라오는 글들이 영양가가 좀 떨어지지 않나 싶었는데 이번엔 아주 Two Thumbs Up!입니다.
December 20, 2006 at 1:47 am · Filed under WebDevelopment
1. Connection을 줄여라.
10초마다 랜덤한 이미지를 DB에서 뽑아와 화면에 뿌려주는 AJAX 루틴이 있다고 하자.
언뜻 보기에 특별한 문제없이 쉽게 구현될 것처럼 보이지만, 실제로는 DB와 HTTP 서버에 꽤 부담을 주게 된다. 실제로 가장 많은 리소스와 시간이 소요되는 것은 바로 이 커넥션 할당부분이다. 알고리즘은 최적화시키고, 데이터는 인덱싱이라도 할 수 있지만, 커넥션 자체에 소요되는 시간은 어떻게도 줄일 수가 없다.
HTTP 프로토콜은 이른바 상태유지가 불가능하다. 그래서 DB 커넥션을 계속 유지하는 것은 어렵다. 물론 EJB등에서 상태세션빈이라든가, 혹은 PHP에서라도 커넥션 유지가 아주 불가능한 것만은 아니다. 다만, 이렇게 커넥션 리소스를 물고 있게 되면 서버자원이 낭비되고 그 결과 다른 접속자의 접속시도가 제한되게 된다. 따라서 대개의 HTTP통신은 Request를 하고 Response가 돌아오는 짧은 시간동안만 커넥션을 물고 있게 한다.
이런 관계로, 10초마다 AJAX를 이용해 이미지를 뽑아오는 기법같은 건, 평균적으로 한 사용자가 1분간 페이지를 유지한다고 하면, AJAX를 쓰지 않았을 때보다 상대적으로 600%의 커넥션 소모를 일으키게 된다.
사장님께 가서 서버와 회선이 모자라니 600% 증설해주세요.. 라고 하자.
권고사직되고 싶지는 않고, 10초마다 랜덤이미지를 1분간 보여주고 싶다면…
AJAX를 쓰지말고 그냥 일반 페이지를 request할 때, 한번의 커넥션 상태에서 6장의 이미지를 랜덤하게 뽑아 JavaScript 혹은 JSON 혹은 숨겨둔 HTML…로 보낸 후, 그냥 JavaScript로 10초마다 로테이팅 시키자.
1분이 모자른 듯 싶다면 아예 10분어치를 한번에 쿼리해서 가져오는 것이 9분 어치가 안쓰여도 AJAX를 쓰는 것보다는 더 이득이다.
2. 메인 컨텐트에 AJAX를 쓰지마라.
카테고리나 메뉴나 광고에 AJAX를 쓰는 것 까지는 좋다.
그러나 메인 컨텐트에 AJAX를 쓰지 말 것.
JavaScript가 disable한 상태이거나 회선불량이라던가, Script Error라든가… 이런 경우 컨텐트가 없는 빈 페이지만 덩그마니 남게 된다.
메뉴나, 사이드바같은 건 어찌되도 좋아, 안보여도 좋고. 허나 메인 컨텐트는 안보이면 안되지…
이 페이지의 핵심기능이 최신글목록이라면, 최신글목록 만은 AJAX를 쓰지 말라는 뜻.
꼭, 반드시 AJAX를 써야겠다면, 그 경우에도 아무것도 없는 빈 컨텐트를 AJAX로 가져와서 채우지 말고, 일단 서버스크립트로 최초 컨텐트는 채워둔 후에, 필요에 따라 AJAX로 변경하는 것은 봐줄만 하겠다. 그래야 AJAX가 안되어도 빈 페이지를 보고 있는 일은 없을 테니까.
3. 크리티컬하지 않은 것만 AJAX를 쓰자.
일단 AJAX를 쓴다 함은, 대개, 현재 보고 있는 페이지와 URL이 매칭되지 않는다는 뜻. 리마커블하게 링크가 걸려야하는 컨텐트, 페이지들은 AJAX를 자제함이 좋다.
그럼 어떤 경우가 AJAX이용에 적당할까?
검색결과페이지는 상대적으로 URL이 덜 중요한 페이지이다. 내용이 수시로 바뀌는 메인 인덱스 페이지라면 AJAX를 써도 크게 상관은 없겠다.
또 덜 중요한 기능- 커멘트 작성같은 -들은 URL과 상관없기 때문에 AJAX로 구현해도 무방하겠다.
4. DB 쿼리보다는 스태틱 빌드를 노려라.
어떤 컨텐트 데이터가 수정, 삭제는 거의 일어나지 않되 추가는 종종 일어나고, 조회는 그 몇배로 자주 이루어지고 있다면, 이에 대한 view를 AJAX로 직접 컨트롤하려는 것은 매우 어리석은 일이다.
이런 경우에는 스태틱 빌드를 쓰자.
데이터가 변경될 때마다 해당 컨텐트를 파일로 만들고(HTML이든, XML이든, JSON이든…) AJAX로는 이 빌드된 파일을 접근해서 읽어오는 쪽이 훨씬 효율적이다.
왜냐하면,
이렇게 빌드된 파일은 다른 사용자들도 동일한 쿼리를 위해 DB커넥션을 할 필요가 없이 바로 그 결과를 파일로 공유할 수 있기 때문이고,
AJAX에 장애가 생겨도 이 파일 주소를 페이지안에 link 나 longdesc로 명기해두었다면 접근성등에 문제가 없어지며,
파일을 읽는 속도가 DB에 연결하는 속도보다는 훨씬 더 빠르기 때문이다.
만약 쿼리가 여러 종류이되 많은 사용자 사이에서 반복되어 나오는 종류라면 최초 쿼리 시에만 DB에서 조회한 후, 그 결과를 파일로 만들고 그 파일이름을 쿼리의 해쉬값을 이용해서 관리하면 여러종류의 쿼리에도 대응할 수 있겠다. 물론 이 경우에는 사용자 맞춤 컨텐트 같은 것에는 약간 힘들 수도 있긴 하다.
5.로드밸런싱(?)
현실적으로 비싼 로드밸런싱 장비를 사용하지 못한다면, 혹은 여러대의 웹서버를 돌릴 수 없다면…
(그런데, 대부분의 웹서비스는, 사실 왠만한 리눅스머신가지고도 훌륭히 퍼포먼스를 낼 수 있다. 이런 커넥션의 낭비만 아니라면…)
간단하게는 서브도메인을 이용해서 일시적으로 커넥션을 늘려서 응답을 빠르게 할 수도 있겠다.
예를 들어 이미지는 image1.sample.com, image2.sample.com, image3.sample.com (내부적으로는 모두 같은 이미지서버)에서 번갈아가며 가져오도록 HTML코드를 작성하고 (그럴려면 일반적인 막코딩으로는 힘들고 별도로 템플릿생성엔진같은 것을 써야하겠다.), ajax call같은 경우에도 ajaxserver1.sample.com, ajaxserver2.sample.com, ajaxserver3.sample.com(역시 내부적으로는 같은 서버)로 분산 호출하게 되면 커넥션이 늘어나게 되어 응답이 빠르다.
그러나 이 방법은 서버의 리소스 사용량을 늘리게 되고, 사용자가 워낙 많은 경우에는 그 시간동안 다른 사용자의 커넥션이 제한되므로 꼭 좋은 방법이라고만은 할 수 없겠다.
AJAX의 오남용을 보고 있자니, Anti-AJAXian이 될 것 만 같은 이 찜찜함…
December 19, 2006 at 2:56 pm · Filed under WebDevelopment, WorldWideWoops
기획자 나잘난양과 개발자 도야근군, 그리고 옵저버 김단지군은 오늘도 신규서비스 개발을 위한 회의에 열심입니다.
…
나잘난양 : 그러면 우리도 AJAX를 이용한 기술적 진보가 있다고 보도자료를 뿌릴 수 있다는 거지요?
도야근군 : 게다가 AJAX를 쓰면 퍼포먼스도 올라가지요.
나잘난양 : 우리 서비스 메인 페이지가 A,B,C,D의 네 개의 섹션으로 이루어져있는데 각 섹션을 AJAX로 불러오게 될 때 퍼포먼스적 이점이 뭐지요?
도야근군 : 우선 A,B,C,D의 각 섹션의 내용을 페이지가 로딩 된 후에 불러오기 때문에 페이지의 데이터전송량을 줄일 수 있지요.
김단지군 : 그런데 페이지 전체로 보면 결국 전송량은 똑같은 것 아닌가요? 오히려 각 섹션별로 각각 커넥션 헤더가 들어가기 때문에 데이터 전송량은 AJAX쪽이 더 많을 것 같은데요?
도야근군 : 커넥션 헤더는 무시할 만한 수치죠. 핵심은 비동기화 커넥션이기 때문에 각 섹션이 각각 동시에 데이터를 가져올 수도 있으니까 로딩시간이 훨씬 단축되죠.
김단지군 : 그 말은 일단 이 페이지를 다 띄우기 위해서는 기존방식보다 HTTP커넥션을 더 소모한다는 거네요? 동시접속자가 몰릴 때에는 문제가 될 수도 있겠는데요?
도야근군 : 서버의 성능을 믿으세요. -_-a 어쨌거나 잘게 나눠서 여러 커넥션으로 동시에 가져오니까 더 빠르다구요.
김단지군 : 하지만 어떤 커넥션은 HTTP특성상 리스폰스되지 않을 수도 있는데, 그럴 때는 그냥 완성되지 못한 페이지 상태이구요?
도야근군 : 그건 통짜 페이지에서도 마찬가지 잖아요? 예를 들어 5번의 커넥션 중 한번이 실패한다면 통짜페이지는 5번 중에 1번은 못띄운단 소리잖아요.
김단지군 : 그러면 4개의 섹션 + 1개의 페이지로 구성된 이 페이지는 섹션 중의 한개는 매번 로딩할 때마다 안뜨는 셈이겠군요.
나잘난양 : 페이지가 통째로 안뜨는 것보다야 낫겠죠.
김단지군 : 뭐, 어차피 HTTP 커넥션 오류는 흔한 일은 아니니까요.
나잘난양 : 다음 이야기를 해보죠. 핵심 컨텐트인 섹션 A는 10분마다 혹은 사용자가 버튼을 누르면 리프레쉬되는 거지요?
도야근군 : 네. 리프레쉬될 때 다른 섹션과는 달리 섹션 A만 리프레쉬되므로 다 로딩할 필요가 없지요.
김단지군 : 그런데 누가 10분이 넘게 같은 페이지를 보고 있지요? 어차피 여기는 메인 페이지라서 다른 페이지로 가는 인덱스 역할이잖아요?
나잘난양 : 사용자들을 무시하지 마셈. 우리의 충성스런 사용자들은 우리 서비스를 백그라운드로 띄워놓고 틈날 때마다 다시 꺼내본다구요. 게다가 우리는 전부 새창띄우기니까 메인페이지가 사라지지 않잖아요.
김단지군 : 그럼 사용자가 보고 있지 않아도 10분마다 리프레쉬가 일어난다는 거네요? 정말로 데이터 절약되는 거 맞아요?
나잘난양 : 그럼 자동 리프레쉬는 빼고, 버튼을 눌렀을 때만 리프레쉬되도록 할까요?
도야근군 : 그럴 줄 알고 이미 구현해놨습니다.
김단지군 : 난 F5키가 편한데…
도야근군 : 전체 페이지 리로딩은 낭비라니깐요.
김단지군 : 사용자들은 습관적으로 F5를 누르게 되어있다구요. 공통되고 일관된 인터페이스라는 건 무시하기 어려운 거에요.
나잘난양 : 사용법 계몽 이벤트라도 할까요? -_-a
김단지군 : 그렇다면 이번에는 반대로 습관적으로 “갱신” 버튼을 눌러대는 경우에는요? 아직 새 데이터가 추가되지 않았는데도 갱신요청을 하면 또 DB커넥션을 해야 하나요?
도야근군 : 최종요청시간을 가지고 있다가 리퀘스트쿼리시에 같이 넘기던가…
김단지군 : 아, 데이터가 또 늘어나네요?
도야근군 : 그까이꺼 몇바이트나 된다고. 그럼 아예 스태틱 빌드로 섹션의 해당 HTML을 10분마다 빌드한 뒤 무조건 그걸 가져다가 뿌려주는 걸로 하지요.
김단지군 : DB트랜잭션은 줄테니 확실히 이득 맞군요. 괘찮은 아이디어입니다. 근데… 그렇게 스태틱 빌드를 하려면 AJAX는 뭐하러 쓰는거죠? 그냥 가져다가 뿌려주기만 할 건데?
도야근군 : …
나잘난양 : 섹션 D는 어때요? 이건 1초마다 갱신이니까 이건 확실히 AJAX의 효과가 있겠죠?
도야근군 : 아, 당연히 그렇겠지요. 이건 어차피 1초마다 갱신이니 스태틱 빌드도 불가능하니까요.
김단지군 : 우리 플랫폼이 혹시 DB커넥션을 세션상태에서 유지할 수 있는 시스템인가요? EJB나 뭐 그런 걸로?
도야근군 : LAMP인데요.. 게다가 커넥션을 세션 상태에서 유지하고 있는 건 HTTP특성상 별로 좋지 않은 방법이라서.
김단지군 : 그렇다면 1초마다 새 DB커넥션이 이루어지고 쿼리가 일어난다는 거군요. 그것도 동접자 마다…
도야근군 : 뭐, 어쩔 수 없죠. AJAX를 쓰려면 그 정도는 감수해야.
김단지군 : 하긴, 트렌드니까요.
나잘난양 : 보도자료는 중요한 거라구요.
…
December 18, 2006 at 10:45 pm · Filed under WebDevelopment, WebStandard
또 한동안 블로고스피어를 달군 저작권 문제.
I. 일단 정리.
1) CCL(Creative Common License)은 무단펌질을 막아주는 부적, 마법의 딱지가 아니다.
2) CCL은 저작권을 보호(좁은 의미로, 펌질금지)한다기 보다는, 합법적으로 사용권을 주기 위한 방법이다.
- 부연 : CCL을 붙이건 말건, 무조건 개인의 창조적 작업의 결과물인 컨텐트는 그 저작권을 보호받는다. 그러다보니, 저작자가 선의로 공유를 하고 싶어도 무조건 저작권을 지키든가, 포기하든가 양자 택일만 가능하므로, 좀 더 합법적으로 컨텐트를 사용할 수 있다는 ‘선언’이다.
II. 사용자는 사악???
그러니까, CCL을 붙여놨으니까 나는 안심. 이건 정말 순진한 이야기. CC가 뭔지 모르는 사람들이 이 세상의 99%. 아마도 IE사용자보다도 많을 걸?
어쨌거나 이미지 딱지 하나 붙여놓았다고 맘 푹놓고 있다가 누가 불펌(?)해갔다고 길길이 날뛰어봤자 소잃고 외양간 고치는 격.
사용자는 CC가 뭔지도 모르고, 이해하지도 못한다. 아무리 친절히 설명해준다 하더라도. 게다가 페이지 어디에 CC가 붙어 있는지 알지도 못하고. 또 웹페이지에 붙어 있는 CC는 애매한 면이 있어서, 페이지 전체가 CC의 영향을 받는다는 건지, 특정 컨텐트가 CC의 영향을 받는 건지…
사용자에게 너무 많은 것을 기대하지 말 것.
III. 올바르게 CC 붙이기.
CC는 그냥 이미지 딱지만 붙여 놓는다고 되는게 아니다. 붙이는 것도 다 규칙이 있고, 표준이 있는 법. 올바르게 붙어있지 않은 CC는 아무 의미도 없다.
아래처럼 붙어야 올바르게 CC가 붙어 있는 것.
[html]
This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.