WYSIWYG vs. WYSIWYM

작년에 한 컨퍼런스에서 웹표준에 관해 강연한 후, 받은 질문 중에 이런 것이 있었습니다.

페이지를 아무리 구조적으로 만든다 해도, 사용자가 WYSIWYG 에디터를 써서 입력한 컨텐트는 구조화가 안되어있는데 이럴 때 웹표준 및 CSS를 어떻게 적용합니까?

어렵죠. 어려운 이야기입니다.
애초에 WYSIWYG란 Structure와는 동떨어진, Presentation을 위한 컨셉이니까요. WYSIWYG을 쓰면 웹표준과는 100% 안맞는다고 해도 틀린 말은 아닙니다.
사실, 웹에디터 모듈뿐만이 아니라, 웹페이지 제작시에도 Dreamweaver나 Namo같은 WYSIWG 도구를 쓰면 웹표준을 맞추는게 상당히 어려워집니다. Dreamweaver 최신 버전에서는 많은 기능향상이 있긴 했습니다만, 그럼에도 불구하고, 주의깊게 사용하지 않으면 웹표준을 적용하는 것이 쉽다고는 할 수 없습니다.

What You See Is What You Get.
말은 좋습니다만, 문제는 “보기 좋은 떡이 먹기 좋은 떡은 아닐 수 도 있다”는 것이지요.

이 문제가 1년 내내 화두처럼 머리속에 남아있게 되네요.

1년이 지나서 나름대로 얻은 해답은 WYSIWYM입니다.

What You See Is What You Mean. (실은 What You Get Is What You Mean쪽이 더 뜻이 통하는 것 같지만, 이미 굳어진 용어라서. :))

Lyx라는 LaTeX의 프론트엔드 프로그램이 있습니다. 이 Lyx에서 채택하고 있는 것이 WYSIWYM입니다. 보이는 그대로 똑같이 출력되는 것이 아니라, 출력될 결과와 “대충 비슷하게” 편집화면에서 보여줍니다. 똑같이 출력되지 않고 “대충 비슷한” 이유는 편집화면에서 보이는 것은 결과물의 외관이 아니라, 결과물의 구조를 보여주기 때문이지요. 구조만 편집하고, 결과는 별도로 정의된 포맷에 적용되어 보이게 됩니다.

이러한 개념이 웹에디터 모듈에도 적용되어야 하겠습니다.

현재 구현되어 있는 WYSIWYM 방식의 웹에디터모듈은 WYM이 있습니다. (데모보기)

완벽하진 않지만, 이를 통해 이상적인 WYSIWM 방식의 웹에디터모듈을 추측해 볼 수 있는데, 아마도 쓸만한 WYSIWYM 에디터가 되려면 이러한 것들이 있어야겠지요.

1) CSS를 Word의 Style처럼.
워드 프로그램들은 빼놓지 않고 “스타일”이라는 것을 가지고 있게 마련입니다. 대개 스타일들은 “대제목, 소제목, 목차, 본문, 인용, 주석…” 이런 식으로 구성되어있죠. 적용을 원하는 부분마다 해당 스타일을 적용시키고, 만약 수정이 필요하면 문서를 수정하는 것이 아니라, 스타일자체를 수정하는 방법을 사용합니다.
따라서 WYSIWYM 에디터에는 반드시 스타일 적용, 스타일 해제, 스타일 생성, 스타일 편집 기능이 들어있어야 합니다.

2) 비시맨틱 요소의 제거
그러니까, “배경색”이니, “문자색”이니 하는 버튼들은 모두 WYSIWYM에디터에서 빠져야 합니다. 필요하다면 “강조1″, “강조2″ 처럼 스타일을 생성하고, 자주 쓰는 스타일을 미리 에디터에 버튼으로 등록시켜 둘 수는 있겠죠.

3) 개인 CSS의 적용.
WYSIWYM에디터들은 사용자 CSS를 적용시킬 수 있도록 개인마다 준비된 CSS를 외부에서 불러들이거나, 업로드하거나 하는 방식을 지원해야 할 것입니다.

4) 다양한 포맷확장기능
microformat에 관해 글을 쓰다가 WYSIWYM 이야기를 빼놓을 수 없어서 이 글을 쓰게 되었는데요.
기존의 WYSIWYG 에디터에서는 microformat을 사용하는 것이 거의 불가능합니다.
알라딘의 TTB 서비스라든가, 이글루스의 LifeLog 기능들도 궁극적으로는 microformat으로 대치되길 간절히 바랍니다만, 어찌되었건 microformat을 WYSIWYG을 통해 입력하는 것은 거의 불가능. 따라서 WYSIWYM에서는 이런 microformat(혹은 비슷한 무언가들…)을 활용한 입력보조플러그인 기능들이 많이 활성화될 것입니다.
예를 들자면, “천하장사 마돈나 감상문”을 쓰려면, WYSIWYM에디터에서 “영화감상문” 포맷을 선택한 후, 빈자리들에 내용을 채워넣으면 보기좋게 영화리뷰 페이지가 만들어진다든가… 하는 방식으로요.

어쨌거나…
누군가는 좀 쓸만한 WYSIWYM 에디터를 완성해서 내놓아주면 참 좋을 텐데 말이지요. 구질구질하고 지저분한 WYSIWYG은 이제 좀 자제할 때도 되었잖아요?

블로그에 달력이 있는 이유는?

국내 가입형 블로그 서비스들 대부분이 달력을 제공합니다.
그런데, 실상, 현재 국내 블로그에서 가장 쓸모없는 인터페이스가 뭔가하면, 그건 바로 달력이라 이거죠.

달력 쓰세요?

거의 안쓰실겁니다.
그럼에도 불구하고 왜 달력은 블로그들마다 달려있는 걸까요? 심지어 de facto 표준이라고 할 MovableType의 기본 스킨에도 달력은 들어있죠.
허나 WordPress의 기본 테마에는 달력이 빠져있고, 또 MT의 경우에도 사용자들이 만든 커스텀 스킨은 대부분 달력이 빠져있습니다. (TT나, 국산 블로그들은 아쉽지만 이 논의에서 빼자구요. 왜 애초에 TT에 달력을 집어넣었는지 솔직히 저는 잘 모르겠습니다. 위험하지만 굳이 추측하자면,” 남들이 넣기에 넣었다”일 것 같긴 합니다.)
도대체 왜 달력은 블로그에 들어있을까요. 그리고 왜 달력은 있기도 하고 없기도 하는걸까요?
그냥 있어도 그만, 없어도 그만? 혹은 디자인 때문에?

이를 위해서는 블로그의 여러 개념에 대한 이해가 필요합니다.

최초에 블로그(blog)라는 단어는 peterme.com에서 Peter Merholz가 “weblog”란 단어를 “we blog”라는 식으로 말장난처럼 사용하면서 퍼지게 되었습니다. “weblog”란 단어는 John Barger가 Web + Log라는 개념으로 처음 사용했구요.
우리나라에서 zeroboard가 폭발적인 인기를 끌며 너도나도 자작 홈페이지 열풍을 일으키고 있을 때, 의외로 다른 나라에서는 홈페이지 만들기가 그리 쉬운 일은 아니었습니다. 제로보드에 비견할 쓸만하면서도 쉬운 CMS가 드믈었고, 인터넷 인프라도 우리 만큼 좋지는 않았지요.
사람들은 간단한 저널, 일기장, 메모장 형태의 프로그램을 이용해서 원시적인 “웹일지”를 만들기 시작했습니다. 이것이 블로그의 시초입니다.
외부로의 링크와 짧은 자기 이야기, 이것이 초기 블로깅의 모습이었지요.

잠깐 주의를 돌려서,
여러분들은 하루에 블로그 글을 몇개나 쓰시나요?

사람에 따라 다르겠지요. 장문의 Article을 쓰는 사람들은 하루에 한개 쓰기도 버겁습니다.
허나 웹서핑중 발견한 링크와 그에 대한 짤막한 자기커멘트정도만 쓴다면 하루에 여러개라도 쓸 수 있지요.

블로그계에서는 필자가 쓰는 글의 단위를 “포스트(post)”라고 합니다. 또는 “엔트리(entry)”라고도 하지요.
응? 왜 document라든가, page라든가, article이 아니지? 라고 의심해보신 분 계세요?
그것은 블로그에서는 “쓰는 단위”와 “보는 단위”가 다르기 때문입니다.
아까 필자가 글을 쓰는 단위를 “포스트”라고 했는데, 보는 단위는 “아카이브(archive)”라고 합니다.
한개의 포스트가 한개의 아카이브를 이루는 경우도 있지만, 여러개의 포스트가 하나의 아카이브를 이루는 경우도 있지요.

옛날, 링크와 짧은 커멘트가 블로그포스트의 대세였던 때에는, “하루단위”로 글을 보는게 편했습니다.
아침먹고 웹서핑하다가 괜찮은 사이트 발견, 블로그에 적어놓고, 점심먹고 갑자기 뭔가 생각나서 짧게 끄적대고, 저녁먹고 자기전에 하루일을 생각하다 또 뭔가 소소한 쓸거리 발견.
지금의 국내 블로그 시스템하에서는 위와 같은 경우는 3개의 페이지가 나오겠지요. 사실 3개씩이나 페이지를 만들만큼 대단한 내용도 아닌데 말이죠.
일기를 생각하시면 이해하시기 쉬울거에요. 오늘 사건 사고가 3건이 있다해서 하루 일기가 3개의 페이지가 될 필요는 없단 말이죠.

그럼 한개의 포스트만 만들어놓고 나중에 수정으로 계속 추가하는 건 어떨까요? 분명 그렇게 쓰시는 분들도 있습니다.
헌데 이럴 경우에는, 일일이 각 아이템마다 시간을 따로 적어줘야 한단 말이죠. 왜냐하면 한개의 포스트는 하나의 시간만 가질테니까요. 그 안에 여러건의 내용이 있는데 시간분류가 안되면 쫌 그렇잖아요?

그래서 초기의 블로그 시스템에는, 글은 아무 때나 쓰되, 볼 때는 일종의 “모아보기”를 하도록 한 경우들이 환영받았습니다. 일기장이나 저널용 프로그램들이 기본이어서이기도 했구요. 이것이 포스트와 아카이브의 차이를 만들었지요.

최근에는 대세가, 한 번에 길게 쓰는 경우가 대세. 입니다. 이런 건 모아보면 오히려 혼란스럽죠. 한 개의 포스트가 한 개의 페이지. 이런 경우를 Individual Entry Archive라고 합니다. (MT의 용어를 차용했습니다.)

그러나 여전히 짤막짤막한 기록들을 남기는 블로깅 스타일도 많습니다. 이런 경우는 한 개의 포스트마다 한 개의 페이지를 만들면 관리하기도(예전에는 심지어 손으로 HTML을 짜서 블로깅하는 경우도 있었거든요.), 보기도 불편합니다. 일기처럼 사용하는 이들에게는 포스트가 몇 개가 되었건, 하루의 일은 한 개의 페이지에서 보고 싶습니다. 이런 경우를 Daily Archive라고 합니다.

물론 월별로 모아보는 Monthly Archive도 있습니다. 아마도 이런 형태가 필요한 경우는 “이 달의 XXX 소식”같은 형식의 블로깅을 하는 경우겠지요.
특이한 경우지만 Category Archive도 있습니다. 카테고리별로 모아보는 것이지요. 블로그를 자료나 지식관리용으로 쓰는 이들에게 필요합니다. 글이 쓰여진 시점이 중요한 것이 아니라, 글의 종류에 따라 하나의 페이지로 묶어보는 쪽이 좋겠지요. 예를 들자면 “맛집 리스트”같은 형태가 되겠습니다.
더 특이한 케이스로는 Yearly Archive라든가, PerNum Archive라든가, Author Archive같은 것도 존재하겠지요. 또는 Alphabet Order Archive같은 형태도 있을 수 있을테구요. Search Result도 일종의 Archive라고 볼 수도 있지요.

물론 Individual Entry Archive나 Daily Archive에 비하면 다른 Archive들은 활용도가 많이 떨어집니다. 일단 Archive 단위가 너무 커지면, 한개의 페이지에 담아야 하는 양이 많아져서 비효율적이거든요. 그래서 대개의 Archive 페이지들은 “목록” 수준으로 운영되는게 일반적입니다. (꼭 그래야 되는 건 아닙니다. 아니고 말고요… ^^;)

이러면서 블로그가 발전해가다보니 한가지 문제가 있습니다. 보는 방법은 아카이브 단위에 따라 다양할 수 있으므로, 한개의 포스트가 여러가지 아카이브에 동시에 속할 수 있다는 거지요. 그러다보니 도대체 이 포스트의 진짜 주소는 뭐냐 하는 문제가 생깁니다. “‘영화 카테고리’의 6번째 글”인지, “‘2006년 9월’의 11번째 글”인지, “‘홍길동’이 쓴 백만스물한번째 글”인지 혼란스럽다는 거지요.
제목으로 구분하면 되지 않냐고 할 수도 있겠지만, Individual Entry Archive가 아닌 형태가 기본이라면, 굳이 제목을 따로 쓸 필요가 없거든요. Daily Archive라면 “2006년 10월 1일”, Category Archive라면 “Game News”라는 식으로 해당 아카이브 페이지의 타이틀이 이미 존재하니까요. (그래서 외국산 블로깅 도구들에는 “제목”이 필수가 아닌 경우들도 많습니다. 심지어 RSS포맷에도 제목은 필수가 아니에요. :))

이래서 많은 이들이 고개를 갸웃하게 하는 Permalink라는 개념이 나왔습니다. 즉, 어떤 형태의 Archive가 되든 간에, 개개의 포스트에는 고유한 URL을 주자는 개념입니다. Archive page의 URL은 다를 수 있지만, 개별 post의 URL은 고유하게 유지하자는 개념이죠. 그래야 설령 Archive가 바뀌어도 고유한 주소로 post를 찾아갈 수 있도록 말이지요.

여기서 우리는 국내 블로그에서 의도적으로(?) 또는 실수로(?) 빼놓은 개념을 알 수 있습니다.
즉, Archive의 부재… 라는 것이지요.
국내 블로그들은 거의 대부분이, “Individual Entry Archive”만 지원합니다. 한 개의 포스트가 한 개의 페이지를 이루는 경우만 있지요.
확실히, 대세는 그렇긴 합니다. 아마 Archive 선택의 자유를 주어도 대부분의 사용자들은 Individual Entry Archive만 사용할 겁니다.
뭐, 그건 그렇다치고, 이 때문에 국내 블로그 서비스들이 몇가지 삐걱거리는 부분이 생기게 되었는데,
바로 “달력 인터페이스”와 “Permalink”죠.

일단 Permalink라는 개념은 아카이브 페이지의 주소와 포스트 단위가 다르기 때문에 필요한 것이었는데, 한 개의 포스트가 한 개의 페이지를 이루는 국내블로그에서는 필요없는 개념입니다. (국내에서는 어째, Permalink라는 개념이 pretty link의 개념과 합쳐지면서 이상한 쪽으로 흘러가긴 합니다.)

또한, Daily Archive를 사용할 때에는 하루 단위로 모아볼 때 요긴하게 쓰였던 달력 인터페이스가 Individual Entry Archive에서는 필요없게 되었죠. 그냥 목록에서 보거나 앞,뒤로 움직이면서 보는 게 더 편하거든요.
달력을 채택하고 있는 많은 국내 블로그에서는 달력의 날짜를 누르면, 그저 해당 날짜에 쓰여진 포스트의 목록만 보이고 맙니다. 으흠. Daily Archive를 운영하지 않는다면 굳이 그렇게 볼 이유따위는 없지요.
이게, 달력이 붙어 있어도 그 사용은 저조한 이유입니다

그러다보니 스킨이나 테마 제작자들은 달력을 빼놓는 경우가 많습니다. 또 WP는 아예 기본 스킨에서 달력을 빼놨구요. 이제는 Daily Archive를 쓰는 사람은 거의 없기 때문이지요.

헌데, Daily Archive를 지원하지도 않으면서 굳이 달력을 집어넣고 있는 국내 서비스들은 왜 그랬을까요.. 미스테리가 아닐 수 없습니다.

현재의 블로그 형태의 기준이라 할 수 있는 blogger.com이나 MovableType등에서는 달력을 채택하는 대신, Daily Archive를 운용할 선택권을 줍니다. 단지 “일간 목차”의 개념이 아닌 “일별 모아보기”수준에서요. 뭐, 대개의 사용자는 신경쓰지 않으므로 Daily Archive에 목차만 보이게 하는 수준으로 운영하고 맙니다만.

국내 블로그 서비스들은 이 외관만 보고 차용해서 만들었나 봅니다. 그래서, 실제로는 아무 쓸모 없는 달력이라든가, Permalink들이 떡하니 붙어있게 되었지요.

물론, 발전적인 활용법은 있습니다.
달력 인터페이스를 방문자 용이 아닌 블로그 주인용으로 쓰게 하는 방법이지요. Public Personal Information Managing System 같은 것을 만들어 붙인다면 달력 인터페이스는 요긴하게 쓰일 것입니다. 물론, 현재에도 Individual Entry Archive 시스템임에도 불구하고 Daily Diary처럼 사용하는 이들에게는 달력의 일간 목록 조차도 편리하긴 합니다만.(더 편리할 수 있는데, 그것이 한계인 줄 알겠죠. 아니, 그게 한계라는 것도 모르려나…)

뱀발.
국내에서 포털 블로그들의 경우에는 오히려 Permalink를 또다른 용도로 필요로 하게 되었는데요, 그 이유는 주소창의 주소와 실제 블로그 글의 주소가 달라지기 때문입니다. AJAX, DHTML, iFrame, Frame 등으로 이루어지는 바람에 글의 주소를 알아내기가 매우 어려워졌습니다. 덕분에, 사용자들을 위해(?) URL로 사용할 Permalink(?)를 제공하고 있지요. 뭐, 그것도 Permalink의 용도라면 용도랄까요.

불친절한 금자씨

그러니까, 졸지에 무슨 지하철 껌팔이라도 된 듯한 느낌.

“목마른 사슴이 물을 찾듯이… 맘잡고 살아보려니 조금씩 도와주쇼. 껌한통 천원임다.”

—
그 내용이 어떻든 간에, 불친절한 금자씨 덕분에 거부감을 느끼게 되어 받아들이지 못한다는 묘한 증언을 참, 어떻게 받아들여야 할지.

하긴 그렇지요. 누군들, “니가 5년간 해왔던 건 말짱 틀렸어. 다시 처음부터 제대로 배우시지…” 라고 하면 기분좋을 사람 누가 있겠습니까.

“안타깝고 황송하게도 5년간 익히고 배우신게 사실은 조금 뭐랄까, 아쉬운 점이 있다고나 할까 그게 꼭 틀렸다고는 할 순 없지만 그래도 더 나은 방법이 있다고도 할 수 있으니 혹시 시간이 조금 남아도신다거나 딱히 덧붙이고 싶으시다면…이러이러한 자료가 있으니 바쁘시더라도 한번쯤은 보시고 여기는 이러이러하게 해보시고…”
처럼 숟기락에 밥담아 떠먹이듯 말해야 했었다는 게지요. 쉬운 말로, 부드러운 말로…

그러니까 대한민국의 웹개발판이 개판이 된 건 그렇다 치고, 다시 정상으로 돌려보자는 노력이 자꾸 헛바퀴를 도는 건, 불친절한 금자씨 때문이라는 거지요. 금자씨만 친절했어도 진작에 맘바꿔서 “그래, 뭐, 그렇게 까지 말해주니 내 한번 틈날 때 봐보기는 해볼께.”라고 그 귀하신 몸뚱아리를 좀 움직여주셨겠다는 거지요.

에, 뭐 그런 일이 어디 이뿐이겠습니까.
교사가 자기 애한테 관심을 안줘서 공부를 못한다고 하며 “우리 애가 공부를 안해서 그렇지 머리는 좋아요.”라고 말하는 부모들.
선임병의 친절한 말 한마디가 부족해서 탈영사고는 매일처럼 일어나고 있고,
선배의 말이 옳긴 하지만 그렇게 강압적인 자세는 싫어요, 라고 하는 대학 신입생들..
뭐 세상이 다 그렇고 그런거죠.

불친절한 금자씨야 불친절하도록 내버려두고…
친절한 분들은 여전히 있으니… 친절한 분들까지 싸잡아 욕먹으면 그건 좀 섭섭하겠죠. 애초에 금자씨들이 무슨 활동을 하는지 별 관심도 없으셨잖아요.
아래는 친절한 금자씨들.

박수만님께서

웹 표준 + 방탄웹 전2권 세트 댄 씨더홈 지음, 박수만 옮김/에이콘출판

이런 책을 내신 지 벌써 몇개월이 되어가는군요.

현석님과 조훈님은 본업보다는 강사로 뛰시는게 더 많아보입니다. 한달에 한두건 이상 교육, 세미나 등이 열리니 꽤나 바쁘실겁니다.
http://www.uiacademy.co.kr/program/pro_ws9.asp
http://www.bizdeli.com/offline/detail.asp?pfid=S1057

이런 교육도 있군요.
http://sumanpark.com/blog/36

드림위버를 사용한 표준과 접근성부분에 대해 정찬명님께서 공저하셨습니다. 다음달쯤 서점에 나온다지요.
http://naradesign.net/wp/2006/09/09/61/

뭐, 이외에도 많은 분들이 “꽁하니 그들만의 모임에 갇혀서 찢고 떠드는” 대신 밖에서 친절히 활동하고 계십니다.
—

아, 저는 최근에는 불러주는데도 없고, 그냥 불친절하게 살 겁니다.

웹표준의 경제학 -2-

charlz님의 커멘트에 대한 답변입니다.

“매달 수익은 계산하기 쉽게, IE전용이 0.9, 표준방식은 1이라고 하겠다. (90% vs 100%)”

스위칭을 한다고 전체합이 늘어나는 것은 아니겠고, FF에서 안돼서 IE에서 다시 안하고 아예 안들어가는 사용자가 전체의 10%를 넘어야하고, 그 사용자가 모두 수익과 연결된다고 가정해야하는 수치입니다. 웹표준을 지키는 것이 직접적으로 수익을 늘어나게 하기 위해서라는 이야기도 이상할테구요. 혹, 늘어난다고 하더라도 아래와 같이 0.1차이가 아니라 0.01, 0.001, 0.0001 차이가 될 수도 있겠죠. 그러니 큰 요인이 아니라고 가정하고 미미한 차를 무시하고 같게 둘 수도 있겠죠.

“1개월간 유지보수에 IE전용이 0.2, 웹표준방식이 0.1이 든다고 하자. (진짜로 유지보수가 편하다.)”

유지보수가 편한 것임에는 이의가 없으나 역시나 0.1차이인지 0.01 혹은 0.001차이인지는 정량적으로 잴 수는 없으니 이를 증명할 수 없겠죠.

이를 생각하고 간단히 숫자를 살짝 바꿔보고 전체 지출만 보면:

IE전용 : ((1) (0.2 * n)) = 0.2 * n 1
표준방식 : ((1.2 0.3) 0.19 *n) = 0.19 * n 1.5

n > 50

가정만 조금 바꿔도 수치가 이렇게 달라집니다. 4년 그대로 버티는 사이트는 그렇게 많지 않죠. 물론 사이트개발과 추가 교육 비용을 또 바꾼다면 또 달라지겠죠. 위에서 제가 사용한 숫자도 틀리다고 장담합니다. 제가 하고 싶은 이야기는 이 공식은 무엇을 증몀하고 있지 않다는 사실입니다. 주장하는 바에 따라 숫자를 바꾸면 되니까요.

charlz님, 수치에 따른 변화는 나름 앞글에서 설명드린 것으로 갈음하겠습니다. 앞글의 두번째 케이스에 따르면 확실히 숫자의 변화에 따라 대차대조가 가능한 n값이 큰 폭으로 늘어날 수도 있습니다. 그러나 포인트는, 그럼에도 불구하고 현실적으로 불가능한 4년동안 리뉴얼안하는 사이트일지언정 결국은 웹표준을 따르는 쪽이 이득이라는 겁니다.

그리고,사용자 브라우저 스위칭의 경우는, 제 글에서 놓치신 게 있으신 것 같습니다. 앞에서 90%의 IE사용자라는 통계는 위에서 언급했다시피 재방문자를 포함한 케이스인 경우가 대부분입니다. 즉, 이미 스위칭한 결과가 90% IE 사용자로 잡힌다는 뜻이지요. 나머지 10%는 표준방식이었다면 놓치지 않았을 트래픽이죠. 따라서 크로스브라우징을 고려한 표준방식의 사이트와 비교하면 말 그대로 90% vs 100%의 트래픽 차이가 발생한다고 생각해도 틀리지 않을 듯 싶습니다. 그래서 일부러 앞 글에서 재방문자를 친 트래픽 분석에 대한 경고를 말했지요.
(그리고, 웹표준이 단지 FF 사용자를 위한 크로스 브라우징뿐인가요? 접근성, 크로스 플랫폼, 비PC기반 브라우저 등을 고려한다면 사실 차이는 더 크게 벌어지게 마련입니다.)

charlz님께서 말씀하신 케이스를 다시 한번 볼까요? 분명 “무언가”를 증명하고 있습니다.
4년동안 리뉴얼 안하는 사이트는 현실상 없으니 1년마다 리뉴얼한다고 하겠습니다. 당연히 개발비용이 표준방식쪽이 늘어나겠지요.

IE 전용 :
개발비용 1 * 4
유지보수비용 : 48 * 0.2
전체 지출은 13.6 입니다.
전체 수익은 4 * 12 * 0.9 = 43.2 입니다.
4년 후의 결과기대값은 29.6입니다.

표준방식의 경우
개발비용 1.2 * 4 + 0.3 (매번 새로 교육할 필요는 없으니까요.)
유지보수비용 : 48 * 0.19
전체 지출은 15.2 입니다.
전체 수익은 4 * 12 * 1 = 48 입니다.
4년 후의 결과기대값은 32.8입니다.

여전히 표준방식이 이득이군요.

이 숫자가 임의적인가요? 그럴 수 있습니다. 어차피 이건 모델링이니까요.
charlz님, 설마 모델링의 의의를 “현실 그자체”로 생각하시는 건 아니시겠죠.
이 모델링에 사용된 공식이 가지는 의미는 결국
“유지보수 비용과 손실될뻔한 트래픽을 고려한다면 웹표준방식이 이익이다.” 라는 뜻입니다.
이 모델링 공식이 깨지는 경우는 단 한가지,
트래픽비율을 0.9로 잡았을 때, 유지보수 비용차가 1.1배 이상 웹표준방식이 더 소요될 경우입니다.

그러나 아무리 까탈스러운 회의주의자라도 웹표준 쪽이 유지보수 비용이 “더 든다”고는 말할 수 없겠지요.

혹시 도저히 임의의 숫자가 불만스러우시다면, man-month-salary단위로 놓고 아무 프로젝트나 시뮬레이트해보시길 권해드립니다. 수치를 얼마로 잡든간에, 결국은 웹표준이 이익입니다.

ps. 웹표준이 아무런 이득이 없는 책상물림들의 이상론이었다면, 표준전도사들이 그렇게 “욕”먹어가며 전도하겠습니까? -_-a

웹표준의 경제학

그러니까, 지겹게 듣는 이야기는 “자본주의하의 현실론”으로 요약할 수 있겠다.

여기, IE만을 지원하는 A라는 사이트가 있다고 하자.
현실적으로, “IE만을 지원한다”는 이야기는 두개의 층위가 혼합되어 표현된다.

1) IE만을 지원하지 않을 수도 있긴 한데, “효율과 편의성, 시장성”을 고려하여 IE전용으로 만들었다.
2) 구현하려는 기능이 정말로 IE에서만 돌아가기 때문에 IE전용으로 만들었다.

“현실주의자”들의 문제는 이 두가지를 구분하지 않고 이야기한다는 점이다.

일단, 1)에 관해 살펴보자.
“전도사”들이 누누이 말하지만, 웹표준을 준수했을 때 얻는 비용적 이득은, 웹표준을 준수하지 않고 같은 효과를 얻으려할 때 필요한 비용보다 크다. 개발이 용이하고, 유지보수가 쉬우며, 접근성이 확보되고, 사용성이 증가한다.
또한 웹표준을 준수했을 때 얻는 비용적 이득은 웹표준을 적용시키기 위해 투자되는 비용보다 크다. 맘잡고 학습하면 한달이면 너끈하고도 남는다. 한달 안에 안된다면… 아쉽게도 잘못된 방법으로 학습했거나, 혹은 소질과 적성에 맞지 않았다고 할 수 밖에. 일단 이루어진 “투자”는 두고두고 우려먹을 수 있다.
즉, 효율과 편의성 문제에 대해서는 표준 쪽에서도 얼마든지 할 말이 있다.

헌데, 그 놈의 “90% IE 사용자 신화”는 여전히 유령처럼 세상을 떠돈다. (그나마 99%에서 많이 낮아진 편.)
이 블로그의 트래픽은 놀랍게도, IE 사용자가 55%, 비IE 사용자가 45%이다. 확실히, 블로거들은 FF를 많이 쓰고 있고, 이 블로그 자체가 FF와 친해서인 이유도 있겠지. 그럼에도 불구하고 생각보다는 꽤 많은 비율이라 조금 놀랐다. 물론 국내 전체 네티즌들을 포함한다면 이런 수치가 나오진 않을 것이다.

그런데, 트래픽 분석때 주의해야 할 부분이 있다.
IE 전용사이트인 A에 90%가 IE사용자라는 건 너무나도 당연한 일이다. 비IE사용자는 A에 1회 접속해보고, 발길을 끊거나, 또는 IE로 바꿔서 접속한다. 따라서 브라우저별 접속분포를 보기 위해선 최초방문자들만을 대상으로 통계를 내야 한다. 그렇지 않고 재방문자들을 포함한 통계를 보고 “거봐, 역시 IE가 대세라니까.”따위 분석을 내놓는 것은 제법 멍청한 짓이다.
소변기를 같이 설치해놓고는 “여자들은 화장실에서 볼일을 안보나봐…”라고 해봤자 소용없는일.

어쨌거나 계산을 좀 해보자.
실제로 IE사용자가 90%이고, 비IE 사용자가 10%라 가정하자.
사이트 개발에 드는 비용은 IE 전용이 1, 웹표준방식이 1.2이라고 하자. (숙련된 표준전도사들은 표준대로 만드는게 더 빠르지만, 모두가 그 정도 스킬은 아니라고 치고…)
웹표준준수를 위한 학습비용이 별도로 0.3이 필요하다고 하자. (사이트 하나 만드는데 3개월 든다면, 학습 제대로 하는데 1개월 걸리니까…)
1개월간 유지보수에 IE전용이 0.2, 웹표준방식이 0.1이 든다고 하자. (진짜로 유지보수가 편하다.)

매달 수익은 계산하기 쉽게, IE전용이 0.9, 표준방식은 1이라고 하겠다. (90% vs 100%)

이랬을 경우,
사이트 오픈부터 n달까지 대차대조를 해보자면,
IE전용 : (0.9 * n) - ((1) + (0.2 * n)) = 0.7 * n - 1
표준방식 : (1 * n) - ((1.2 + 0.3) + 0.1 *n) = 0.9 * n - 1.5
n > 2.5, 즉 3달째부터 표준방식이 더 이득이다.

응? 유리한 숫자를 고른 거 아니냐고?
그럼 웹표준 쪽에 좀 더 페널티를 줘보자.
웹표준 사이트 개발비용을 IE전용보다 2배 많게 해서, 2로 놓자.
웹표준 학습 비용을 통크게 1로 주자.
웹표준 유지보수비용은 0.19, 거의 IE 전용과 비슷하게 놓았다.
이랬을 경우,
표준방식 : (1 * n) - ((2 + 1) + (0.19 * n)) = 0.81n - 3
IE 전용 : 0.7n - 1

n > 18.1… 대략 18개월째부터는 표준방식이 이익이다.
상당히 과장된 숫자를 넣었음에도 불구하고, 기간의 차이는 있을지언정 웹표준 방식이 궁극적으로 더 이득임을 볼 수 있다.

좀더 심화해볼까?
A라는 사이트가 대단한 인기를 끌어 수익이 엄청난 대박아이템이라고 하자.
그래서 다달이 들어오는 이익이 바로 위의 두번째 계산보다 3배 많다고 하자. 물론 대형 사이트이니 유지보수 비용도 3배 많다고 가정하겠다.
이경우에는,
표준방식 : (3 * n) - ((2 + 1) + (0.57 * n)) = 2.43 * n - 3
IE전용 : (2.7 * n) - ((1) + (0.6 * n)) = 2.1 * n - 1
n > 6.0… 대략 6개월만에 웹표준 방식이 이익이 됨을 볼 수 있다.
즉, 규모가 큰 사이트일 수록 웹표준 방식을 적용하는 것이 더 이득이라는 뜻이다. 영리를 목적으로 하는 서비스라면 민감하게 받아들여야 하지 않을까?

이 공식이 정확한 공식이라는 것은 아니다. 허나 간단하게 모델링 해본 것만으로도 충분히 웹표준 쪽이 이득임을 증명할 수 있었다. 표준방식이 IE전용보다 손해가 되는 경우는, 유지보수 비용이 IE전용보다 많이 들어갈 때 뿐인데, 흐흠. 과연 그런가?
글쎄, 이 정도 계산도 안해보고 현실론을 운운하는 기획자, 개발자, 경영자들은 머리 속에 뭐가 들었는지 알다가도 모를 일이다. 혹시 영세한 사업자라서 초기투자조차 버겁다거나, 수익을 전혀 기대하지 않는다거나 하면 이해가 가지만…

아, 2)IE가 아니면 웹에서 불가능한 기능이 있었지?
결론부터 말하자면, 그런 것 따위 없다. 그런 것이 있다면 그건 “웹”이 아닐 뿐.

microformat에 대해 배워봅시다. (1)

마이크로포맷에 관해 정리할 일이 있어 겸사겸사.

1) 마이크로포맷이 뭔가요?
시맨틱웹이라는 말은 많이 들어봤을 겁니다. “의미가 통하는 웹”이라는 뜻이죠.
오잉? 지금까지의 웹은 의미가 안통하나요?
네, 앞에다 몇자를 더 추가해야겠군요. “사람에게도, 기계에게도 의미가 통하는 웹”이라는 뜻입니다.

어느 블로거 주인이 오늘 본 영화에 대해 주절주절 리뷰를 썼습니다.
방문객들은 그 리뷰를 보고, 호, 이 주인장이 “괴물”에 대해 쓴 리뷰구나… 라고 생각하겠지요.
허나, 기계는?(여기서 기계란.. 프로그램 혹은 기타 디바이스들을 통틀어 가리킵니다.)
기계에게도 이 글이 “괴물”에 대한 리뷰임을 알려줄 방법이 있어야겠지요. 그것이 마이크로포맷의 목적입니다. 물론, 사람들이 볼 때에도 의미가 통하는 것은 기본이구요.

2) 지금까지는 이러한 시도가 없었나요?
왠걸요. 시맨틱웹 및 온톨로지를 위한 시도는 매우 다양합니다. 그 중 가장 대표적인 것은 RDF라 할 수 있겠죠. Resource Description Framework이라는 매우 훌륭하고도 적절한 도구가 있습니다. W3C에서 정식으로 채택하고 있구요.
문제는, RDF는 XML로써, HTML이나 XHTML에 사용하는 데에는 큰 문제는 없으나, 아무래도 웹에서는 덜 인간친화적이라는 점이죠. 기계에게는 더할나위없이 좋은 포맷이지만, 인간이 그 의미를 정확히 잡아내기가 힘들고, 무엇보다도, 웹상에서는 인간의 눈으로는 볼 수 없다는 점이죠. (XML 및 XSL기술이 발달하여, XML로 웹을 만드는 가까운 미래에는 또 달라지겠습니다만.)
마이크로포맷의 가장 큰 장점은 같은 코드로 인간과 기계가 같이 사용할 수 있다는 점입니다. 물론 쉽기도 하구요.

일단, 이런 잡상식을 베이스로 깔아두고, 오늘 이야기할 것은 개인프로필에 해당하는 hCard에 대해서입니다.

그 전에 먼저, vCard를 알아둬야죠. 이바닥이 이렇습니다. 뭔가를 알려면 그 전에 알아둬야 하는게 꼭 있죠. 선행학습이 없이 말단기술만 익혀봤자 왜 사용하는지, 어떻게 써야 효과적이고 올바르게 쓰는지 틀리기 쉽거든요.

vCard(대소문자 주의.)는 인적정보를 기술하는 표준포맷(RFC2426)입니다. MS Outlook을 쓰시는 분은, 연락처의 메뉴중에 보면 “vCard로 내보내기” 같은 메뉴를 보실 수 있습니다. Outlook 데이터를 표준포맷으로 바꿔서 다른 프로그램에서도 활용할 수 있도록 하는 것이지요.
메일 보낼 때, 메일 하단부에 이름, 주소, 전화번호, 직장, 직위… 이런 것들을 적어 보내잖아요. 실은 그냥 vCard만 첨부파일로 붙여 보내면 간단합니다. vCard를 다운받아 더블클릭하면 자동으로 Outlook에 해당 정보가 입력되거든요. 일종의 전자명함이라고 생각하면 됩니다. Outlook외에도 대부분의 PIMS 소프트웨어는 vCard를 지원합니다. 물론 그 외에도 다른 용도는 많이 있지요.

vCard의 샘플포맷은 다음과 같습니다.

BEGIN:VCARD
VERSION:2.1
N:eouia, Yi
FN:eouia
ORG:eouia Company;research institute
TITLE:Programmer
TEL;CELL;VOICE:016-9447-8022
URL;WORK:http://dnzin.com/cunningweb
BDAY:19740819
EMAIL;PREF;INTERNET:eouia0819@gmail.com
REV:20060921T030301Z
END:VCARD


hCard는 이런 vCard를 어떻게 웹상에서 구현할까에 대해 나온 해답입니다. 물론, RDF를 이용한 XML vCard라는 방법도 있습니다.

참고로, 위의 내용을 RDF로 구현하면 대충 다음과 같습니다.

<rdf:RDF xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:vCard = "http://www.w3.org/2001/vcard-rdf/3.0#">
<rdf: Description rdf:about = "http://dnzin.com/cunningweb/about" >
<vcard:FN> eouia </vcard:FN>
<vcard:N rdf:parseType="Resource">
<vcard:Family> Yil </vcard:Family>
<vcard:Given> eouia </vcard:Given>
</vcard:N>
<vcard:BDAY> 1974-08-19 </vcard:BDAY>
<vcard:TITLE> eouia Company, research institute </vcard:TITLE>
<vcard:ROLE> Programmer </vcard:ROLE>
<vcard:TEL rdf:parseType="Resource">
<rdf:value> +016 9447 8022 </rdf:value>
<rdf:type rdf:resource="http://www.w3.org/2001/vcard-rdf/3.0#work"/>
<rdf:type rdf:resource="http://www.w3.org/2001/vcard-rdf/3.0#voice"/>
</vcard:TEL>
<vcard :EMAIL rdf:parseType="Resource">
<rdf :value> eouia0819@gmail.com </rdf:value>
<rdf :type rdf:resource="http://www.w3.org/2001/vcard-rdf/3.0#internet"/>
</vcard:EMAIL>
</rdf: Description>
<rdf:RDF>

미리 해석하는 방법이 정의되어있는 XML답게 조금 복잡해보이긴 해도 기계가 해석하기에는 괜찮은 구조죠.
허나, 웹상에서 RDF를 바로 사용하면 기계에게는 보기좋아도, 인간에게는 안보이는 게 문제.
실은, 반대로 생각하면, 인간에게는 보기 편하도록 마음대로 아무렇게나 써주고, 대신 인간에게 안보이는 RDF만 명확하고 규격에 맞게 기술해주면 되니까 자유도는 높은 편입니다.

어쨌거나, 이를 hCard 마이크로포맷을 이용하면 다음과 같습니다.

[html]

eouia Yi

eouia Company, research Institute

eouia0819@gmail.com

016-9447-8022

[/html]

음. 민망할 정도로 단순하군요. 이게 끝입니다.
핵심은, class 이름이 vCard 속성값을 그대로 쓴다는 점. 태그는 어떤 태그가 쓰였는지는 중요하지 않습니다.
필요에 따라서 hCard 스펙에 없는 장식요소들을 더 넣어도 되구요.
물론 당연히, 디자인은 CSS로 나중에 입히면 됩니다. 얼마든지 원하는 대로.

더 완벽한 온톨로지를 위해서는, hCard 마이크로포맷과 RDF를 같이 써주고, 덤으로 vCard를 다운받을 수 있는 링크도 제공하면 퍼펙트.

오잉, 그런데 도대체 그래서 이걸 뭐에 쓴다냐…
여러가지 활용법이 있겠죠.

예를 들어 블로그 한 귀퉁이에 hCard를 적어놓아봅니다. 검색엔진이 와서 읽고는, 아, 이 블로그 주인이 누구구나.. 알릴 수 있겠죠. (꼭 검색엔진이 아니더라도 비슷한 요구는 많이 있습니다.) 보안이라는 문제는 차치하고, 이런 것이 검색엔진에서 구현된다면 예를 들어 “dnzin.com 주인장의 메일주소는?” 같은 자연어 검색이 가능하다는 것.

싸이월드 1촌 리스트를 좀 어케 뽑아서 주소록을 만들고 싶은데 일일이 손으로 치기는 싫다? 만약 싸이월드가 hCard(를 비롯한 RDF나 vCard등등)을 지원한다면 그 일을 자동으로 해주는 프로그램을 만들 수도 있겠죠. (이런 것도 안하면서 싸이월드가 어째서 플랫폼 기반의 소셜 네트워크라고 불리는지 당췌 이해가… -_-a)

지금도 있나 모르겠는데, 한때 명함 OCR 리더기가 있었답니다. 명함을 기계에 집어넣으면 자동으로 이름, 전화번호 등등을 추출해서 내 PIMS(Outlook 같은..)에 저장해주는 기계지요. 그러나 100%인식은 힘들다는 점.
만약 어느 누군가가 개인의 프로필을 관리해주는 서비스를 만들고, 가입자에게 고유한 일련번호를 준 뒤, 그 일련번호를 명함에 새겨가지고 다닌다면, 받은 이는 그 번호를 프로그램에 입력만 해도 해당인의 정보를 전달받을 수 있도록 하는 서비스도 가능하지 않겠어요? “내 메일 주소는 xxx입니다”와 마찬가지로 “내 hCard 고유번호는 xxx입니다.”가 통용될 수도 있겠죠. (한때 이런 서비스를 SKT에 제안했었는데 뭔 소리인지 당췌 못알아들으시더라는… -_-a)

뭐, 그런겁니다.
앞으로 웹상에 누군가의 신상정보를 적어야 할 일이 있다면, hCard 마이크로포맷을 이용해주십사라는 점. 누군가는 그 정보를 유용하고 고맙게 쓸 지도 모르니까요. (스패머가 수집해간다면 그건 낭패.)

다음은 hCalendar에 대해… (아마도.)

트랙백 210%

yser님의 커멘트를 읽고.

몇가지 말씀하신 부분에 대해 답해봅니다.

1. MT 트랙백 표준확장에 대해

1) MT 트랙백 규격은 현재 버전 1.2입니다. (2004년 8월 1일)

2) encoding은 트랙백 보낼 시에 선언할 수 있습니다. HTTP의 Content-type에 그 내용을 적어야 합니다.
[code]
POST http://www.example.com/trackback/5
Content-Type: application/x-www-form-urlencoded; charset=utf-8

title=Foo+Bar&url=http://www.bar.com/&excerpt=My+Excerpt&blog_name=Foo[/code]
원래는 이렇게 보내져온 것을 받으면 그에 따라 수신처에서 알아서 풀어서 해독하고 하면 될 일입니다. 송신처에서 수신처의 인코딩타입따위를 알아야할 필요는 없습니다. 물론 국내의 서비스 및 도구 개발자들이 charset이나 encoding에 무지한 관계로 이런 기능을 활용못한 것이지요. 국내의 개발자들이 멍청해서 EUC-KR 전용이 되어버린 서비스를 배려하기 위한 꼼수등은 필요없습니다. 필요한 것은 욕설 한바가지 뿐이지요.

3) Retrieving TrackBack Pings은 deprecated되었습니다. 표준규격도 아니고, 그 효용도 없다고 판단되어서라지요. 그러나 Ver 2.0에서는 다른 형태로 이 기능을 지원할 예정이라고 합니다. 개인적으로는 별 필요없다고 생각합니다. 트랙백 RDF와 DB저장내용을 잘 참조하면 이 스펙이 없어도 얼마든지 구현가능하니까요.

4) 트랙백의 수정, 삭제는 확실히 미진한 기능이긴 합니다. Ver 2.0에서는 개선될 지도 모르겠군요. 미리보기는 오버라고 생각합니다. 그건 트랙백 규격의 문제가 아니라 사용하는 서비스 도구의 문제겠지요.

2. 트랙백 자동발견 및 자동전송기능의 중복은 트랙백 규격의 문제가 아니라 역시 도구의 문제입니다. 어디로 트랙백을 보냈는지 DB에 저장해두고 중복된 곳으로 보내지 않게 구현하면 될 일이지요.

3. 상대방에게 얼마나 표시될 지 모른다…는 것은 사실상 의미없는 불만입니다. 왜냐하면, 받은 트랙백의 표시방법은 수신처의 마음이거든요. 트랙백을 받고도 전혀 표시안할 수도 있고, 필요하다면 트랙백 받은 주소로 봇을 보내어 페이지를 통째로 긁어와서 표시해줄 수도 있습니다. 요컨데, 트랙백이란 “댓글”이 아니라 “ping”이니까요. 신호를 전달해줄 뿐이지, 그 신호를 어떻게 쓰고, 어떻게 해석할 지는 수신처의 소관이지요.

4. 따라서 보낸 트랙백의 수정, 삭제는 ping이라는 관점에서 본다면 넌센스에 가깝습니다. 다시 말씀드리지만, 트랙백은 “댓글”이 아니라 “ping”입니다. 글이 publish된 시점에 수신처로 ping신호를 한번 보내기. 그걸로 끝입니다. 이미 전에 보낸 ping신호를 어떻게 수정하고 삭제하겠습니까.
그러나 만약 필요하다면 이것은 서비스 차원에서 해결할 방법은 있습니다. 예를 들어 이전에 받았던 트랙백과 같은 title로 같은 도메인에서 새로 트랙백이 보내진다면, 그것을 “수정신호”로 인식해서 이전에 받았던 트랙백기록을 새 트랙백 기록으로 교체하기 같은 아이디어를 구현할 수 있겠죠. (거듭 말씀드리지만, 이 역시 트랙백 규격의 문제는 아닙니다.)

5. excerpt 문제는 국내의 블로그 서비스 개발자들에게 비난을 돌리세요. 트랙백의 문제가 아니죠. excerpt 필드가 없어서 RSS에서도 description문제가 발생하지 않았습니까.

6. excerpt의 길이문제도 마찬가지이긴 한데, 한가지 문제가 있는 것이, 원래 트랙백은 HTTP GET을 염두에 두고 작성되었습니다. 따라서 전달할 수 있는 데이터의 byte 제한이 있었습니다. 물론 지금은 HTTP POST로 형식이 바뀌었습니다. 길이 제한은 없어졌으나, 그것을 어떤 식으로 표시할 지는 송신처든 수신처든 나름 재량입니다.

7. SixApart사는 그다지 놀고 있지 않습니다. 현재에도 트랙백 규격 2.0을 위해 개발자 포럼등에서 활발하게 논의되고 있습니다.

트랙백 200% 만들기

트랙백이 멍청한 기술이냐고 묻는 글을 보고…

트랙백이 멍청해진 이유는, 개발자들이 멍청하거나, 게으르기 때문이 절반정도 이유가 된다. (나머지 절반은 기획자의 잘못이다.)

먼저 핑백(Pingback)에 대해서 알아둬야 한다.
핑백은, 어떤 URL에 다른 URL에서 그 URL을 링크했음을 알려주는 간단한 신호였다. 트랙백과 거의 유사한 기능인데, 너무 간단한 구성이라 Notify이상의 기능을 제공하기는 힘들었다.핑백을 수신하기 위한 별도의 XML-RPC 프로그램이 필요하다.
이후 MovableType으로 유명한 sixapart사 에서 MT를 만들면서 Trackback이라는 규격으로 비슷한 기능을 제안하고, 그것이 널리 받아들여져 사실상 de facto 표준이 되었다. (하긴, MT는 모든 블로그의 de facto표준 아니던가.) 핑백과 트랙백의 가장 큰 차이는 URL에 대한 확장정보(title, author, excerpt등)가 포함되는 XML을 사용한다는 점이다. 핑백과는 달리 XML-RPC를 쓰지 않고 HTTP GET/POST 메쏘드를 사용함으로써 문서와 분리된 트랙백 시스템 구현이 용이하다.

그럼 도대체 트랙백이란 뭐에 쓰이는 물건인가.. 그리고 왜 멍청한 것처럼 불편하고 쓸모없어 보이는가?

핑백과 마찬가지로 트랙백은 어떤 문서에 다른 문서에서 그 문서로 링크를 연결했음을 알려주는 역할을 한다.
자세히 보면 두가지 레벨로 되어있음을 알 수 있다.

1) 이쪽 문서에서 외부 문서로 가는 링크
2) 외부 문서에서 이쪽 문서로의 역링크

대부분의 국산 블로깅 도구의 트랙백 시스템은 “2)외부 문서에서 이쪽 문서로의 역링크” 기능을 제공한다. 즉, 이쪽에서 트랙백을 보내면, 자동으로 그쪽 페이지에서는 이 곳의 URL을 표시해준다는 뜻이다. 이거야 익숙할 테고.

너무나 당연해서 간과해버리는 쪽은 오히려 “1) 이쪽 문서에서 외부 문서로 가는 링크” 쪽이다.
이곳에서 두가지 문제가 발생하는데,

(1) 이쪽 문서에서 외부 문서로 가는 링크를 사용자가 적지 않는다.
(2) 링크를 적는다 해도 트랙백이 자동으로 걸리지 않는다.

이 두가지 문제로 인해 국내에서 트랙백이 절름발이가 되어버린 셈이다.

(1)은 사용자의 문제일 수도 있다. (2)는 개발자의 문제이다.
그런데, 둘 다 트랙백에 대한 오해때문에 비롯된 것일 수도 있다.

즉, 우리는 무의식적으로 트랙백이란, “완성된 글을 가지고 다른 문서에 역링크를 거는 것”이라고 생각하곤 한다. 그렇기 때문에 트랙백 입력란이 있어서 트랙백 보낼 곳에 대한 트랙백 주소를 적거나 한다. 또 태터툴즈의 예를 보아도, “글을 쓰고, 트랙백을 보낸다.”라는 식이다.

허나, ping의 관점에서의 트랙백이란, 그저 본문중에 언급된 링크에 대해 notify를 해주는 기능이다. 그러니까 실은 사용자가 별도의 액션(트랙백 주소를 적고… 따위)을 취하는 건 잘못된 인터페이스라 할 수 있다.

무슨 소리인가 하면, 본문 중에 어떤 링크를 언급하면, 자동으로 트랙백이 날아가야 한다는 뜻. 국산 블로깅 서비스나 도구들이 이 기능을 빼먹은 바람에 절름발이 트랙백이 되버린 셈이다. (가장 대표적인 국산 블로깅 도구인 태터가 이런 기능이 되는지는 모르겠다. -_-a)
이를 위해 필요한 기술은 크게 두가지이다.

* Trackback Auto-discovery
문서URL에서 트랙백URL을 자동으로 찾아주는 기술이다.
이게 구현되어 있는 경우에는, 사용자가 글을 퍼블리쉬하면 자동으로 그 글에 링크된 문서URL을 찾아서, 해당 문서안에 기술된 트랙백 주소를 찾아 자동으로 트랙백 보내기가 된다는 뜻이다.
사용자는 트랙백에 대해 전혀 신경쓰지 않아도 된다. 심지어 그런 시스템이 돌아가고 있다는 사실조차 몰라도 상관없도록.

* Trackback RDF
Trackback Auto-discovery 기능을 만들려면 전제조건이 필요하다. 무엇인고 하니, 문서URL과 트랙백URL이 서로 다를 수 있는데, 그럼 어떻게 트랙백 주소를 찾아내느냐 하는 문제를 해결하는 것. 국내에서 블로그 및 트랙백 과 관련된 개발을 하는 개발자라면 익히 느꼈을 것인데, 시스템에 따라 트랙백 주소체계가 천차만별이라는 점이 개발자들을 늘 곤혹스럽게 한다.
허니, 누가봐도 이 문서의 트랙백 주소는 무엇이다라는 것을 알 수 있는 체계가 필요하고 그것이 트랙백 RDF이다.
즉, 이 문서의 트랙백 주소는 어디이다.. 라는 것을 정해진 포맷으로 기술하는 방식이다.
Trackback Auto-discovery를 지원하지 않더라도, 트랙백을 사용하는 시스템에서는 이 RDF들을 포함해야 한다. (Trackback Auto-discovery를 지원하는 다른 도구들을 위해)

트랙백 RDF 포맷은 간단하다. 지금 보고 있는 이 글의 트랙백 RDF는 다음과 같다.
[html]
<!--

xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:trackback="http://madskills.com/public/xml/rss/module/trackback/">

dc:identifier="http://dnzin.com/cunningweb/?p=44"
dc:title="트랙백 200% 만들기"
trackback:ping="http://dnzin.com/cunningweb/?p=44/trackback/" />

–>
[/html]
이런 내용이 HTML문서 안에 포함되어 있으면, 프로그램이 자동으로 저 주소를 뽑아올 수 있으므로 자동 트랙백 보내기가 가능하다는 뜻.

이 두가지 기능이 없다보니, 사용자가 일일이 트랙백 주소를 찾아서 적어줘야 하고, 또 그러다보니 빼먹고 트랙백을 안보내는 경우도 있고, 또 반대로 트랙백은 보냈으되 어디로 보냈는지 다른 사람은 알 수 없는 경우도 생긴다. 이러니 불편하고, 멍청하다는 소리를 들어도 쌀 수 밖에.

현재 이런 트랙백 자동발견을 지원하는 국산 서비스나 도구가 있던가? (엔비는 지원하고, 블로그밈은 지원하는 걸로 알고 있다.)
그나마 트랙백 RDF를 잘 적어준 egloos는 고마운 편.
어쨌거나 그래서 국내에서는 아직도 트랙백을 보내려면 일일이 트랙백 주소를 적어주는 불편함을 겪어야만 한다.
원래 트랙백 주소 입력란은, 트랙백 자동발견이 안되는 문서로 트랙백을 보내거나, 혹은 본문에 언급되지 않은 제3의 주소로 트랙백을 보내라고 있는 것인데, 지금의 국내 서비스들 처럼 트랙백을 사용하기 위해 일일이 적어주라고 하는 것은 주객이 전도된 인터페이스. 하긴, 귤이 회수를 건너 탱자가 된 것이 어디 트랙백 뿐이랴.

헌데, 트랙백을 제대로 활용하려면 이걸로는 부족하다.

* Auto Trackback to URL
글을 쓸 때마다 특정 URL에 자동으로 트랙백을 보내주는 기능이다. 가장 간단히 활용할 수 있는 것은, 새글 notifying이다. 예를 들어 올블로그가 RSS 긁어가는 주기가 맘에 안든다면, 새 글을 쓸 때마다 올블로그로 트랙백을 자동으로 보내고 그러면 바로 올블로그가 새 글을 긁어가도록 하는 시스템같은 것이 가능하다. (이미 이런게 되던가? -_-a) 이런 식으로 팀블로깅이나 메타블로그에서 컨텐트 수집을 위해 사용할 수도 있다.
좀더 편리해지려면 카테고리별로 이 기능을 지원하면 매우 좋다.
예를 들어, “웹표준”에 대한 글을 쓸 때마다 매번 올블로그의 “웹표준 트랙백모임”주소를 입력하기란 힘들다. 그러므로 “웹표준”이라는 카테고리를 만들고, 그 카테고리에 쓰인 글은 자동으로 “웹표준 트랙백모임”에 트랙백 보내지기가 되면 사용자가 신경쓰지 않아도 되니 오죽 좋은가.

헌데, 이 기능은 국내에서는 조금 이상하게 변질되어 쓰이고 있다. egloos에서는 자신의 “밸리”로만 연결하는데 이 기능을 제공하고 있고, 태터의 경우에는 태터센터로만 보내도록 되어있다. (태터쪽은 잘 모름. 카테고리 별이 아니라 개별 글 단위로 선택하게 되어 있던가…) 물론 이글루스도 태터도 이것의 내부구현은 트랙백과 상관없이 되어있지만.

여튼 이런 기능은 잘 활용하면 얼마든지 확장응용이 가능하다. (생각하는 건 기획자 몫. :))

물론 현재 MT에서는 비밀 트랙백등의 기능도 구현되어 있고, 조만간(?) 트랙백 2.0 포맷이 새로 나온다고 한다.
허나 국내에서는 개발자들이, 혹은 기획자들이 부족하게 만든 트랙백 덕에 트랙백이 애물단지 취급받고 있는 현실이다.
거기다가 대부분 트랙백이란 “원거리 댓글”쯤으로 생각해버리는 바람에 아예 다른 활용방법은 생각조차 못하고 있다.
“원거리 댓글”은 확실히 트랙백의 멋진 활용법 중에 하나지만 너무 그것에만 매몰되는 바람에 ping이라는 트랙백의 기본출발을 놓치고 있는 것은 아닌지.

foobar

Barcamp Seoul에 참가한다. (블로그에 홍보하라는 규칙이 있어 적는다.)
Foocamp건 Barcamp건 한국에서는 열린 적이 없으니, 솔직히 참가는 하되, 가서 뭘 할지는 모르겠다. 컨퍼런스만 해도 힘든데, 언컨퍼런스는 또 뭐란 말인가.

어쨌거나, 쓰려는 이야기는 그게 아니고...

"foobar"는 "Hello, World"만큼이나 프로그래밍계에서는 유명한 단어다. 근데 도대체 foobar가 뭐냐.

위키피디아에 따르면 foobar는 미군속어인 FUBAR에서 나왔다고 한다.
FUBAR는 Fucked Up Beyond Any/All Recognition의 약자라고 한다. 해석하면 "쥐도새도 모르게 당했다..."쯤 되려나?

또다른 가설로는 Rune문자에서 나왔다고 한다. 룬문자의 알파벳이랄까, 원래는 "Futhark"에서 나왔다고.

지금까지 샘플이나 테스트코드 만들면서 foo, bar를 지겹게 써왔지만 무슨 뜻인지도 모르고 쓰다가 이제야 알다. 게다가 foo,bar 다음은 "baz"라는 것도.

요즘 유행의 로고 만들기.

일단, 참고링크부터. web2logo.com

보다보면, 요즘 유행하는 BI/CI의 트렌드가 대충 규칙이 잡히는 듯 하다.
아래 글은 오프라인기업과는 별 상관없고, 온라인-웹 기업 중심이므로 맹신하지 말 것.

1) 크게 두가지 형태로 나눌 수 있다.
- Typo 만으로 구성된 로고
- Symbol과 Typo가 분리되는 로고

Typo로만 구성되는 로고의 대표는 Google이나, Yahoo, eBay, Amazon, Skype등이다.

한때 옛날에는 Symbol을 매우 중요하게 생각했고, Typo는 그 다음쯤으로 생각하던 디자인시기가 있었다. 80년대에서 90년대 초반까지. 이즈음에는 명함을 봐도, 회사로고가 있고 회사이름이 뒤에 붙었는데, 회사명은 사실 시각적으로 크게 중요하지 않았고 로고 자체로 다른 회사와 구별하곤 했다. 우리나라의 경우에도, 현대, 삼성, 대우, 금성 등이 각각 독특한 로고로 CI를 내세우던 시기였다.
그러나 90년대 후반에 들어와서 2000년대 초반까지는 Typo자체가 Symbol의 역할까지 하는 디자인으로 변화하기 시작했다. 기존의 정형화된 디자인 대신 파격적으로 Typo를 앞으로 내세우는 것이 유행하던 때.
여전히 Typo를 전면에 내세우는 기업도 많은데, 살펴보면 대개, BI보다는 CI로 이용하는 경우가 많다. 대형 포털등의 아이덴터티로 이용된다. (우리나라의 경우에도 Naver의 날개모자보다는 초록색 NAVER Typo가 좀 더 유명하다.)

한편 웹 시대에 접어들면서 다시 Symbol의 중요성이 대두되는데, IT의 경우에는 아이콘 등으로의 활용이 중요하기 때문이다. 물론 Typo 중심의 로고도 그 중 일부를 떼어서 Symbol로 사용하기는 하지만, 아무래도 아이콘등을 고려하여 디자인하기에는 Symbol + Typo 쪽이 훨씬 용이하기 때문이리라.
BitTorento, Technorati, Blogger, NewsVine, del.icio.us 등이 대표적이다.

2. Symbol은 정사각형 프레임이 대세.
로고자체가 정사각형이 아니더라도, 가로세로 같은 크기안의 프레임에 들어차는 형태의 Symbol을 만든다. 이는 16X16, 24X24, 36X36, 48X48의 각종 아이콘으로의 활용을 위한 방법이다. 백그라운드부분을 감안하면 대개의 로고는 높이와 넓이가 같은 값을 갖는다.

3. 직사각형의 활용.
부정형 Symbol, Typo는 그다지 흔한 경우가 아니다. 대개는 직사각형 프레임안에 들어가는 형태가 주류를 이룬다. 부정형의 경우에도 크게보면 직사각형 프레임안에 들어간다.(하긴, 넓게 잡으면 뭐든 직사각형안에 들어간다. :))
실제로 백그라운드에 색상을 주어 가시적으로 사각형 프레임을 표현해주기도 한다. 이 사각형 프레임은 배너의 용도로도 쓰이며, 참고할 표준배너사이즈는 다음과 같다.

Rectangles and Pop-Ups
300 x 250 IMU - (Medium Rectangle)
250 x 250 IMU - (Square Pop-Up)
240 x 400 IMU - (Vertical Rectangle)
336 x 280 IMU - (Large Rectangle)
180 x 150 IMU - (Rectangle)

Banners and Buttons
468 x 60 IMU - (Full Banner)
234 x 60 IMU - (Half Banner)
88 x 31 IMU - (Micro Bar)
120 x 90 IMU - (Button 1)
120 x 60 IMU - (Button 2)
120 x 240 IMU - (Vertical Banner)
125 x 125 IMU - (Square Button)
728 x 90 IMU - (Leaderboard)

Skyscrapers
160 x 600 IMU - (Wide Skyscraper)
120 x 600 IMU - (Skyscraper)
300 x 600 IMU - (Half Page Ad)

From:국제표준규격(IAB)

ODEO, Feedburner, Blogger 등.

4. 흰색을 적극적으로 사용.
백그라운드로서의 흰색 외에도 Typo나 Symbol자체에 흰색을 적극적으로 사용하는 경우도 있다. 물론 이를 위해서는 백그라운드 색상을 짙은 색으로 사용한다.
Writely, Popurls, kiko 등.

5. 조합어를 위해서는 2tone으로.
FlickR, YouTube, NetVives, TechCrunch, StyleHive등 2단어의 조합으로 이루어진 대부분의 브랜드 Typo는 2가지 색으로 구성된다. 보기 좋아서.. 이기도 하지만, 대개 조합어간의 끊어읽기를 시각적으로 표시해주는 역할도 한다. (그럼 3개의 단어로 이루어진 브랜드는 3가지 색을 쓸까? :))

6. serif 대신 san serif로.
장식적인 serif요소는 거의 없거나 있어도 아주 순화된 글씨체를 이용한다. serif가 없긴 하지만 그렇다고 모서리가 각진 글씨체는 아니며, 대개 라운드처리된 Typo를 사용하여 부드럽게 표현하는 것이 유행.

7. 색상은 3가지 정도.
배경색, 전경색, 강조색(혹은 보조색) 정도로 구현한다. 주된 색조는 1~2개의 원색 및 나머지는 차분한 중간색을 선호하며 1개는 흰색이나 검정색의 무채색을 포함하는 경우가 많다. 예를 들어 청색이 주된 컨셉색조라면, 흰색 바탕에 청색 혹은 청색바탕에 흰색으로 기본 표현 후, 보색계열의 강조색으로 포인트를 주거나, 혹은 같은 계열의 다른 색조(예:하늘색)를 보조색으로 사용하여 그라데이션이나 장식을 꾸민다.

이상이 요즘 유행하는 트렌드의 로고 분석.
뭐, 분석한 내용을 바탕으로 룰을 지킨다 해서 좋은 로고가 나온다는 보장은 없지만. :)

ps. 아, 물론 Beta나 Test 혹은 Ver 1.0 등을 넣어주는 건 기본 중의 기본. (응? 진짜?)

웹표준/접근성을 위한 디자인시 주의점

다음은 디자이너가 레이아웃, 이미지등을 제작할 때, 웹표준/접근성을 고려시 주의해야 할 점에 대한 가이드라인입니다. 코딩과는 상관없이, 실제 이미지 제작등에 주의해야할 가이드라인입니다.

1) 모든 이미지는 흑백변환시에도 이해가능해야 한다.
비슷한 채도 명도를 가지고 있는 색상으로 디자인을 하면 흑백으로 변환했을 경우 이미지에 사용된 색상간의 경계를 파악하기 어렵습니다. 쉽게 말하자면 흑백복사를 해도 알아볼 수 있게 이미지 색상을 잡아야 합니다.
따라서, 이미지를 제작할 때에는 되도록이면 비슷한 채도명도를 인접해서 사용하는 것은 피해야 합니다. 특히 원색계열의 색을 쓰거나 파스텔 계열의 색을 쓸 때 주의해야겠지요. 또 차트같은 것을 그릴 때에도 주의해야 합니다.
이를 피하기 위해서는 색상배열을 다르게 하거나, 인식가능한 백그라운드 패턴을 주거나, 외곽선을 주거나, 외곽선 형태를 다르게 함으로써 해결할 수 있습니다.
이는 전색맹, 부분색맹, 색약자들에 대한 배려일 뿐만 아니라, 흑백 디스플레이, 저성능 디스플레이, 인쇄, 이미지패턴검출기 등을 위해서도 필요한 내용입니다.

2) 고정된 크기의 이미지는 조각내지 않는다.
CSS를 이용한 디자인시에는, 크기가 고정된 이미지라면 굳이 조각낼 필요가 없습니다.
주어진 영역밖을 벗어나 돌출되는 형태의 디자인을 기존의 테이블 작업에서는 튀어나온 부분을 자르고... 하는 방식으로 조각내어 이어붙였습니다만, CSS를 이용할 경우에는 그렇게 할 필요없이 목표하는 이미지 이외부분을 투명하게 놓고 레이아웃을 투명시트지 위에 올린다는 식으로 생각해야 합니다.
당분간은 PNG 알파채널이 IE에서 원활히 사용할 수 없으므로 투명 GIF를 쓰면 됩니다.
조각나지 않은 이미지는 HTML코드를 단순하고 시맨틱하게 유지시켜줍니다.

3) 가변 크기의 이미지는 3분할을 기본으로 한다.
모든 컨텐트는 최소 3단계의 pseudo-structure를 갖는다고 생각하시면 좋습니다. header,body,footer.
대개 가변 크기의 이미지란 컨텐트를 감싸는 "박스"일 경우가 많습니다. 컨텐트의 크기에 따라서 박스의 크기가 가변적으로 변하겠지요.
이럴 경우 가변폭이 어디냐에 따라 "위-가운데-아래" 혹은 "좌-가운데-우"로 이미지를 분할하고, 각각을 컨텐트의 3분할 structure에 대응시키면 됩니다.
(물론 이외에도 wrapper를 이용한 박싱 테크닉 등이 있습니다만...)

4) 9분할 이미지 분할은 필요한 것일까?
디자인 편의성 때문에 박스를 9조각 내놓고 테이블로 3X3 박스를 만드는 기법을 많이 사용합니다. 실제로 CSS 디자인 초보분들이 제일 많이 묻는 방법이기도 합니다.
확실히 조각난 9개의 이미지는 어떤 크기의 박스도 만들 수 있는 만능방법이긴 합니다만, 코드로 보자면 불필요한 코드가 추가되는 원인입니다.
CSS 디자인시 9분할 이미지가 반드시 필요한 경우는 "가로-세로 가변폭 박스"의 경우밖에 없습니다. 문제는, 이러한 박스는 실제 레이아웃 디자인시 거의 안쓰입니다. 대개 "가로세로고정"이거나, "가로고정-세로가변", "세로고정-가로가변"의 경우입니다. 진정으로 "가로세로-가변"폭인 박스 디자인은 고도의 liquid 디자인시에도 거의 쓰이지 않습니다.
반드시 써야겠다면 방법은 있습니다.
header-header, header-body, header-footer, body-header, body-body, body-footer, footer-header, footer-body, footer-footer의 9단계로 컨텐트 structure를 만들고 각각에 이미지를 대응시키면 되긴 합니다. 추천하지 않습니다. 차라리 다른 레이아웃을 생각하는게 더 바람직하다고 봅니다.
CSS 3에서는 단일 div만으로도 border속성을 이용해서 9분할 이미지박스를 구현할 수 있겠지만, CSS 3의 실제적용은 앞으로도 몇년은 더 기다려야 합니다.

5) 되도록이면 이미지에 텍스트를 포함하지 않는다.
반드시 필요한 경우가 아니라면 이미지에 텍스트를 포함하지 않는 것이 좋습니다. 물론 더 예쁜 폰트로 보이고 싶은 마음도 중요하고, 실제로 기본지원 폰트가 맘에 들지 않는 경우가 많습니다만, 그럼에도 불구하고, 이미지안에 텍스트를 포함하는 것은 지양하는 게 좋습니다.
메뉴의 텍스트폰트를 반드시 "Impact" 혹은 "한양Expo체"를 사용해야만 하겠다면 꼭 그래야만 하는 이유를 제시할 수 있어야 합니다. 실제로 웹폰트를 사용하지 않는 한(그리고 웹폰트는 전혀 바람직하지 않습니다.) 사이트의 기본 텍스트는 기본 폰트만을 사용해서 제작됩니다. BI나 CI정도라면 모를까, 본문은 "돋움"인데 메뉴링크만 "한양Expo"인 경우가 과연 얼마나 사이트 디자인 일관성에 부합할까요.
또 각종 타이틀 등도 디자인상 반드시 필요한 경우가 아니라면 이미지로 만든 타이틀은 자제함이 좋겠습니다. 대체텍스트 기법을 충실히 활용해줄 게 아니라면 말이지요...
접근성등의 이슈와도 연관되기 때문에 되도록이면 이미지와 텍스트는 분리하는 게 좋습니다.

6) 사진은 JPG, 그러나 그외에는 GIF로...
논란의 여지가 있긴 합니다만, 여전히 사용자의 디스플레이의 색상표현력의 한계, 그리고 트래픽등을 고려하면 GIF를 사용하는게 유리합니다. 물론 사진이라면 트루컬러 JPG도 좋겠지요. 그러나 그 외의 이미지는(예를 들어 아이콘 등...) 웹컬러스키마를 이용한 256색 GIF를 쓰는 쪽이 좋습니다.
PNG가 JPG와 GIF에 대한 좋은 대안이긴 합니다만, IE6가 시장에서 퇴출되는 그날까지는 아직 시간이 조금 남아있네요.

7) Animated GIF는 주의깊게.
가장 안좋은 것 중 하나는 번쩍이는 Animated 이미지입니다. 사실, 번쩍이지 않아도, 제맘대로 바뀌고 있는 이미지가 포함된 웹문서를 보고 있는 건 눈에 피로를 줍니다. 반드시 필요한 경우가 아니라면 animated GIF는 자제함이 좋을 듯 합니다.

8) 링크는 본문 및 배경과 구별이 되도록.
이 정도는 기본적으로들 하고 계시긴 합니다만... 주의할 점은, 색상만으로 구별하게 하는 경우 앞서 1)의 문제점이 여기에도 문제가 됩니다.
추천하는 것은 링크에 밑줄로 시각적인 표시를 해주는 것입니다만.... 디자인 상 밑줄을 싫어하는 경우도 많지요.
사실 여러분이 보고계신 제 사이트도 이 문제는 아주 나쁜 편입니다. 왜냐하면 적록색맹이신 분은 제 사이트 본문에서 링크를 찾기 곤란하기 때문입니다.
CSS 2에 :before나 :after 등을 활용하면 좋겠습니다만, 여전히 IE 6가 퇴출될 때까지는 힘들 것 같네요.
링크에 밑줄이 힘들다면 링크임을 표시하는 작은 아이콘등을 추가하는 것도 좋은 방법입니다.
최소한, 흑백변환 혹은 색맹의 경우에도 링크 구별이 가능하도록 색상을 주의깊게 선택하셔야 합니다.

9) 리사이즈는 미리.
원본 이미지를 가지고 HTML 코드상에서 width와 height로 리사이즈하는 경우가 있습니다만 별로 바람직하지 않습니다. 트래픽 면에서 낭비가 심하기 때문입니다. 작은 이미지가 필요하다면 미리 작은 이미지를 만들고(손으로 만들든, 서버사이드프로그램으로 자동으로 만들든) 해당 사이즈에 맞는 리사이즈된 이미지를 표시하는 것이 좋습니다.

10) 사용자의 동선을 생각할 것.
이것은 웹표준, 접근성과 크게 상관은 없을 수도 있습니다만... 어느 정도는 관련도 있고, UX등과도 연계가 됩니다.

처음 사이트에 방문하는 사용자는 메뉴 등도 주의깊게 봅니다. 그러나 자주 방문하는 사용자는 메뉴등은 건너뛰고 컨텐트부터 봅니다.
확실히 좌측 메뉴는 시각적으로 눈에 잘 들어오긴 합니다만, 어느 정도 경험이 쌓인 사용자에게는 건너뜀의 대상이 되기도 합니다.
메뉴의 위상이 컨텐트보다 중요하다면 좌측에 놓는 것이 좋겠지만, 반대의 경우라면 우측에 놓는 것도 사용자 경험상 더 효과적일 수 있습니다.
사용자의 시선은 어느 방향으로 흐르는지, 사용자의 마우스는 어느쪽으로 움직이는지 고려한 레이아웃 디자인을 잡는 게 좋겠지요.

접근성의 측면에서 이러한 배치는 때로는 중요한 문제일 수도 있습니다. 2차원적인 시선의 움직임으로 내용을 능동적으로 파악하는 정상사용자와는 달리, 시각장애인들은 보조기구의 도움을 받아 1차원(linear) 순서로 컨텐트를 수동적으로 전달받습니다. 이러한 경우, 매 페이지에 컨텐트보다 앞에 위치한 상단섹션, 좌단섹션들은 컨텐트보다 중요하지 않음에도 불구하고 선형적인 구성상 앞에 오기 때문에 사용자의 주의력을 흐리게하는 경우도 있습니다.
뭐, 이런 경우에는 링크스킵을 제공하거나, 혹은 컨텐트를 먼저 기술하고 CSS로 레이아웃을 변형하는 해결책도 있기는 합니다만...
레이아웃의 기본은 Beauty보다는 Usability라는 점을 염두에 두고 디자인해야한다는 말이지요. 웹은 아트가 아닌 인포메이션테크놀러지이니까요.

AHAH - AJAX의 보완.

여기저기 어디서나 AJAX 타령. 개나 소나 AJAX를 이용해 서비스를 만들고 있는데, 솔직히 말하자면 아이들에게 칼들려 놓는 것처럼 위태위태하다. 그러다보니 이런 만행도 일어나고.
실제로 웹서비스 개발 중에 AJAX를 사용해보면 그닥 만만한 작업은 아니다.

1) XML 스키마를 정의하고 개발중에 관리하는 것은 꽤나 귀찮은 일이다.
2) 서버사이드에서 XML로 인코딩하고, 클라이언트사이드에서 XML을 파싱한다. 단지 화면에 약간의 HTML 컨텐트를 보여주기 위해 들어야 하는 품이 제법 많다.
3) 서버사이드에 XML을 만들고 발송하는 서버프로그램을 별도로 제작해야한다.
4) 접근성을 위한 대체텍스트 혹은 대체페이지를 개발하기 위한 품이 별도로 들어간다.
5) 잘 아시다시피 클라이언트사이드에서 JavaScript 디버깅하는 것은 매우 골치아픈 일이다.

고작 HTML 조금 동적으로 보여주기 위해 AJAX를 써야 하는가?
여기 대체재 AHAH가 있다.

AJAX는 Asynchronous JavaScript and XML을 가리킨다. 그럼 AHAH는?
Asychronous HTML and HTTP를 말한다.

언제 나온 새 기술인가 하고 의아해하는 분들이 있다면 조금 실망할지도 모른다. 실은 XMLHttpRequest 객체를 활용하는 또다른 방법일 뿐이다.

이미 AJAX를 많이 다뤄본 분들은 XMLHttpRequest.responseXML 대신 XMLHttpRequest.responseText가 편하다는 것을 깨달은 분들이 있을 것이다.
맞다, 그것이 AHAH이다. responseXML대신 responseText를 쓰면 AJAX라고 부르지 말고 AHAH라고 불러주자. 그간, responseText를 쓰면서 XML도 아닌데 AJAX라고 불러도 되나 찜찜하셨던 분들이라면 기꺼워 할 것이다. (나는 그랬다.)

?? 둘 사이에 무슨 차이가 있길래?

AHAH와 AJAX의 가장 큰 차이는, AHAH는 (x)HTML을 이용한다는 점이다. 주의할 점은, Text가 아닌 HTML이라는 점. responseText를 쓰되 그 전달값으로 HTML 서브셋을 쓴다는 소리다.

XHTML역시 XML의 일종이므로 XMLHttpRequest를 이용할 수 있다.

다음은 클라이언트사이드에서 AHAH를 이용하는 JavaScript 함수의 예제이다.
[javascript]
function SendAHAH(url,target) {
if (window.XMLHttpRequest) {
req = new XMLHttpRequest();
req.onreadystatechange = function() {
ReceiveAHAH(target);
};
req.open("GET", url, true);
req.send(null);
} else if (window.ActiveXObject) {
req = new ActiveXObject("Microsoft.XMLHTTP");
if (req) {
req.onreadystatechange = function() {
ReceiveAHAH(target);
};
req.open("GET", url, true);
req.send();
}
}
}

function ReceiveAHAH(target) {
if (req.readyState == 4) {
if (req.status == 200 || req.status == 304) {
result = req.responseText;
document.getElementById(target).innerHTML = result;
} else {
document.getElementById(target).innerHTML="AHAH error:\n" +
req.statusText;
}
}
}
[/javascript]

코드를 보면 AJAX랑 별 다를 것도 없다. 실제로 이미 이와 비슷하게 코딩해서 작업하는 분도 많을 것이다.

그럼 왜 AHAH인가?

1. 파싱이 필요없다.
데이터를 XML로 바꾸고, 다시 그 XML을 파싱해서 필요한 정보를 뽑고... 그것을 다시 DOM을 구성하는 AJAX의 과정이 필요없어진다.
document.getElementById(target).innerHTML = result;
이것으로 만사해결. 아예 처음부터 HTML로 보내고 받은 HTML을 target에 채워넣어주기만 하면 된다.
DOM과 JavaScript에 익숙하지 않은 개발자라면 기뻐할 일이다.

2. 웹접근성이 깔끔히 해결된다.
AJAX를 사용하는 종래의 DHTML은 접근성 면에 문제가 많았다. 동등한 정보를 제공하는 대체텍스트나 대체페이지를 제공해야하는데 그러기 위해서는 XML외에도 따로 똑같은 내용을 담은 HTML을 만들고 연결해야 한다. 당연히, 이 과정을 무시하는 개발자들이 대부분이고(심지어는 왜 대체페이지를 제공해야 하는지 모르는 개발자가 더 많겠지만.), 따라서 근래의 AJAX를 사용한 서비스들은 대부분 접근성에서 많은 문제가 있었다.
비록 접근성을 중요하게 생각하는 개발자라 하여도, XML데이터 외에 별도의 HTML데이터를 만들어야 한다는 것은 부담스러운 일이다.
그러나 AHAH를 사용하면 아예 처음부터 HTML을 되돌려주므로 접근성을 완벽히 보장할 수 있다.
다음 코드를 보자.

[html]
...

...

...

title="카테고리 목록">
카테고리 목록 바로가기

[/html]

getCategoryList.php가 이 페이지의 카테고리 목록을 다음처럼 보여준다고 하자.
[html]

• 분류 1
• 분류 2

[/html]

여기, 세가지의 접근성을 고려한 기법이 들어갔다.

1) head안의 link에 AHAH 서버페이지를 적어준다. 검색엔진봇이나 텍스트 브라우저, 텍스트리더기들은 이 link에 기술된 URL에 들어있는 HTML 정보에 문제없이 접근가능하다.
2) target 엘리먼트에 longdesc 속성으로 해당 AHAH 서버페이지를 적어준다. 여기에서는 div에 걸었으므로 엄밀하게 말해서는 맞는 방법이 아니지만, 만약 target 엘리먼트가 img라면 매우 좋은 방법이 될 수 있다.
3) target 엘리먼트안에, AHAH로 대치되기전까지 사용될 대체텍스트를 넣어둔다. 만약 JavaScript가 disabled되어있거나 지원하지 않거나 혹은 기타등등 에러가 발생해서 컨텐트를 동적으로 받아올 수 없다면 이 대체텍스트가 화면에 뿌려질 것이다. 사용자도 JavaScript가 안되어서 텅빈 화면을 멍하니 바라보는 것이 아니라, 대체텍스트나 수고스럽긴 해도 클릭 한번이면 대체페이지가 보이게 되는 것이다.

이 기능들을 AJAX로 구현하려고 하면 혀가 빠진다. MVC 프레임워크를 쓴다 하여도 XML데이터를 별도의 HTML로 재가공하는 View 기능을 만들어야 하기 때문이다. 그러나 AHAH를 쓰면 이렇게 간단히 해결된다. Hurrrah!

3. 동적 스크립팅이 쉬워진다.
AJAX의 단점중에 하나는, 서버사이드에서는 데이터를 전달할 뿐이고, 그에 대한 처리는 클라이언트사이드에서 담당해야 한다는 것이었다. 미리 정의된 데이터를 정의된 방식으로 처리할 수 밖에 없다. 데이터의 형식이 바뀌거나 처리방법이 바뀐다면 클라이언트사이드의 페이지를 열어서 일일이 수정해야 한다.

그러나 AHAH를 쓰면 동적 스크립팅이 쉬워진다. 클라이언트사이드의 수정없이 서버사이드에서의 변경만으로 얼마든지 브라우저에서 JavaScript 실행을 컨트롤할 수 있다.

위에서 소개한 ReceiveAHAH()를 조금 변형시켜보자.
[javascript]
var bSaf = (navigator.userAgent.indexOf('Safari') != -1);
var bOpera = (navigator.userAgent.indexOf('Opera') != -1);
var bMoz = (navigator.appName == 'Netscape');
function ReceiveAHAH(target) {
if (req.readyState == 4) {
if (req.status == 200 || req.status == 304) {
result = req.responseText;
document.getElementById(target).innerHTML = result;
execJS(result);
} else {
document.getElementById(target).innerHTML="AHAH error:\n" +
req.statusText;
}
}
}

function execJS(node) {
var st = node.getElementsByTagName('SCRIPT');
var strExec;
for(var i=0;i
if (bSaf) {
strExec = st[i].innerHTML;
}
else if (bOpera) {
strExec = st[i].text;
}
else if (bMoz) {
strExec = st[i].textContent;
}
else {
strExec = st[i].text;
}
try {
eval(strExec);
} catch(e) {
alert(e);
}
}
}
[/javascript]

전달받은 HTML중에 <SCRIPT>를 찾아 실행시켜준다. 즉, 클라이언트쪽에서 JavaScript를 준비하지 않아도, 서버사이드에서 필요한 JavaScript를 만들어서 넘겨주면 얼마든지 실행된다는 소리다. 물론 AJAX로도 비슷한 기능을 구현할 수 있다. 허나 저거보다 짧고 쉽게 할 수는 없다.
(IE는 내부적으로 HTML태그를 대문자로 유지하므로 실제로 응용할 때에는 String.upperCase 메쏘드를 이용해서 브라우저별로 SCRIPT 와 script를 분리해서 찾도록 할 필요가 있다. 또 주석의 형태와 세미콜론 사용에 유의해야 한다.)

IE에서만 통용되었던 비호환방식의 dynamic scripting이 AHAH를 씀으로써 아주 간단히 크로스브라우징상에서 구현가능하다.

물론 AJAX가 DOM 컨트롤이라든가 JavaScript 제어를 세밀하게 할 수 있는 장점이 있지만, 장담하건데, 여러분이 AJAX로 시도하려는 작업의 95%는 AHAH만으로도 충분하다. 공연히 몸에 맞지 않는 옷입고 비틀거리지 말고, 쉽고 간단한 AHAH를 써서 효율 좀 올려보자. 물론 내 욕심은 AHAH를 사용하면 접근성 고려가 매우매우 간단해지므로 덤으로 접근성도 좀 신경써달라는 것이다.

AHAH는 Kevin Marks가 2005년 5월, JAH(Just Asynchronous HTML) 라는 이름으로 처음 기법을 고안했고,
Ernest Prabhakar가 2005년 웹 2.0 컨퍼런스에서 처음 AHAH라는 용어를 사용했다. 결국 현재에는 REX(REST-Enabled XHTML) microformat의 일부로 채택이 되었다. 어디 이상한 사이비 기법 아니니 안심하고 쓰시길.

관련 URL
JAH : http://epeus.blogspot.com/2005_05_01_epeus_archive.html#111588374981985824
REX : http://www.opendarwin.org/~drernie/talk/rest-enabled-xhtml-20051019.html

블로그용어사전 v060908

* 18개월 만의 업데이트 (옛날 버전-v050330은 여기에, 추가된 부분에는 밑줄.)

블로그 / blog
도대체 그것이 무엇인지 누구도 뚜렷하게 말할 수 없고 정의할 수 없는 어떤 것. 아직도 누군가는 1인 미디어라는 헛소리를 믿기도 한다. 현재까지는 프랑크푸르트학파에서 주장한 social-exhibishoinsm의 병리적 증상이라는 설이 학계에서 가장 인정받고 있는 편이다.

커멘트 / comment , 리플 / reply, 답글
메일을 대신하여 새롭게 떠오르는 광고 수단.

트랙백 / trackback
멀리 있는 이에게 시비 거는 데 사용하는 결투장. 학창시절 신발장에 들어있곤 하던 것의 인터넷 버전. 마찬가지로 짝사랑(스토킹)의 수단으로도 쓰인다.

RSS
사이트에서 볼 수 있는 내용을 일부러 다른 곳(예를 들어 리더기)에서 불편하게 보기 위해 만든 바보같은 규격. Really Stupid Syntax의 약자.

CC / Common Creative
붙이기만 하면 타인의 스크랩과 불펌 및 허락없는 인용등을 막아준다고 사람들이 믿는 부적의 일종. 교회나 사찰에서 구할 수는 없다.

블로거 / blogger
대단히 한가한 사람의 다른 표현.

블로깅 / blogging
블로거들이 남아도는 시간을 소비하기 위해 몰두하는 비생산적 행위.

엔트리 / entry, 아티클 / article, 포스트 / post, 글
10년 후 되돌아보고 창피함을 스스로 느끼기 위해 작성하는 피학성 정신질환의 최소 단위 증거.

블로고스피어 / blogosphere
폐인, 오타쿠 공동체.

퍼머링크 / permalink
원뜻과는 달리, 시도 때도 없이 변하곤 하는 엔트리의 URI를 가리키는 용어.

아카이브 / archive
아무도 뒤져보지 않는 쓰레기통의 다른 이름.

모블로그 / moblog
패킷사용량을 늘리기 위한 전화회사의 음모.

포드캐스팅 / podcasting
iPod 판매량을 늘리기 위한 Apple사의 음모.

메타블로그 / metablog
인터넷상의 불필요한 트래픽 유발지를 인덱싱함으로써 종량제 시행시 서핑하면서 피해야할 주소들의 모음.
KT가 종량제를 사실상 포기함으로 인해 그 의의가 반감됨

그룹 블로그 / group blog, 팀블로그 / team blog, 링블로그 / ring blog
운영자 혼자 사용하는 블로그를 말함.

UCC, UGC
UCC는 User Crushed Coffee의 약자로 편의점에서만 구할 수 있는 수입 커피 브랜드이다. 처음 UCC에 주목한 업체들은 사용자들이 직접 커피를 갈아먹는 것이 사용자들에게 더 풍부한 경험을 주고 그 커피를 서로 공유하게함으로써 놀라운 비즈니스 모델이 될 것이라 예상했다. 확실히 몇몇 업체는 성공했다. 다른 업체들은 언젠가는 성공할 거라고 생각하며 그 많은 커피콩들을 모아둘 창고유지비를 감내하고 있다.
한편 UCC라는 브랜드 자체가 짝퉁이며, UGC(User Grinded Coffee)가 오리지널 브랜드라고 주장하는 사람들이 있다.
어쨌거나 맛은 있으되, 영양가는 거의 없으며 무엇보다도 귀찮다. 적절한 보상이 없으면 더이상 호기심만으로 커피콩을 갈아대는 전문가들을 붙잡을 수 없다.

AJAX
콜게이트-팜올리브 사에서 만든 레몬향이 나는 세척제.
블로그에 사용하면 인터페이스와 트래픽을 깔끔하고 윤이나게 닦아준다고 한다.
너무 잘팔린 나머지, 사용하지 않아도 될 곳에 사용해서 문제. 보통은 "물이 빠진 것"을 "깨끗해졌다."라고 말하지는 않는다.
여튼 이 제품을 안쓰면 왕따라도 당하는 모양이어서 귀얇은 회사들은 박스채로 구입하고 있다.
발음은 [아약스]만 아니면 맘대로 발음해도 좋다.

태그 / Tag
다른 사람들로 하여금 그 글의 원래 키워드나 범주가 뭐였는지 헷갈리게 하기 위해 만드는 함정.
원래 태그란 짐짝등의 주인을 구별하기 위함이 아니었던가. 별명만 잔뜩 적어놓은 태그만 가지고 가방의 원래 주인을 찾아줄 수는 없다.

개인화 홈
남들과는 다른 나만의 개성있는 초기페이지를 꾸밀 수 있다고 주장한다. 그러나 그 초기페이지는 결국, 개발자가 제공한 것들 중에 몇가지 골라 선택하는 것 뿐. 그러니까 사실, 별로 개성적인 건 아니라는 것.

AdSense
"저 가난합니다. 돈이 없습니다. 이거라도 해서 코묻은 돈 벌어 애기 분유라도 타줘야겠습니다. 그러니 클릭하세요."의 줄임말.

나도 때려보자, 썩플.

과격한 제목으로 글을 시작하는 건 부담이다. :)
허나 요즘 유행하는 써플 때리기라는 신종 스포츠에 기꺼이 동참.

필립.K.딕의 "마이너리티 리포트"를 보면, 예언 당사자가 예언을 알게 되면서 어떻게 예언이 바뀌는지에 대해 나온다.
실험의 신뢰도를 높이는 기본조건중에 "이중맹검"이라는 항목이 있는데, 실험대상이 실험에 대해 몰라야 하며 동시에 실험자도 실험에 대해 몰라야 한다. (예를 들어 신약을 테스트할 때, 실험군과 대조군 환자모두 어느쪽이 신약을 받는지 스스로 몰라야 하며, 그 실험을 실시하는 시험자역시 어느쪽에 신약을 주었는지 실험이 종료될 때까지 몰라야 한다는 뜻이다.)
양자역학에서는 입자의 위치와 운동을 동시에 계측할 수 없다. 왜냐하면 관찰자의 관찰이라는 행위가 입자에 간섭을 주기 때문이다.

시시한 토막상식이다.

IT업계에 집단지성이라는 유령이 출몰하고 있다.
아아, 그 뜻은 좋은 거지.
문제는 그 구현은 그리 간단하지 않다는 것이다.

모 신문사는 대문에 오르는 기사순서에 네티즌의 "추천"이라는 행위를 반영한다고 한다.
"오늘의 인기글"은 왠만한 커뮤니티 등에서는 빠지지 않는 코너이다.
검색사이트였는지 잊고 있었던 모 포털(이라고 숨겨봤자 뭐하겠는가. 네이트의 신 서비스 썩플에 대한 이야기이다.)에서는 검색순위에 네티즌의 "추천"을 이용한다고 한다.

인기글은, 뭐 크게 상관은 없겠다. 집단지성이라는 레테르를 붙이진 않았으니까.
신문사 기사게제순서야 어차피 편집자의 맘이니 그런 식으로 편집한다 해도 누가 뭐라겠는가.

그러나 검색사이트에서 로그인한 사용자의 추천?
세상 참 편하게 산다 싶다.

영화나 상품은 구매한 사용자의 충성도를 기대할 수 있다. 소비되는 가치가 아무려면 웹페이지 한장 보다는 크겠지. 영화보고 와서 영화사이트에 별점 매기는 건 조금 번거롭긴 하지만 자발적인 참여를 기대할 만 하다.

하지만 검색은 아니잖아?
포털들이 왜 덩치를 키웠는가? 검색과 색인으로 시작했던 포털들이 덩치를 키운건, 검색과 색인은 사용자들의 최종목적이 아니기 때문이었다. 즉, 검색과 색인은 최종목적지를 위한 중간단계였을 뿐 빨리 최종목적지로 보내줄 수록 좋은(?) 검색엔진이라는 딜레마 때문에 사용자를 붙잡아 두기 위해 덩치를 키운 것이다.
뭐, 반대로 더욱더 빨리 최종목적지로 보내버리겠다는 DON'TBEEVIL Google이 있긴 하지만.

드디어는 검색을 위해 로그인을 해줘야만 할 것 같은 검색서비스라... 멋지구리.

1. 대부분의 사용자는 로그인하지 않아도 되는 서비스에는 로그인하지 않는다.
2. 로그인하지 않아도 되는 서비스에 사용자가 로그인하는 것은 특별한 "의도"를 가지고 있을 때이며, 대개 그 "의지"는 평상시의 자연스러움과는 달리 의도적인 강한 동인을 내포한다.
3. 그 "의도"는 필연적으로 평시의 자연스러운 정보의 흐름을 왜곡하려 한다.

결론 : 사용자의 "의식적 행위"에 기인하는 결과는 "집단지성"보다는 "집단감성"에 어울린다. 속되게 과장하자면 "빠돌-순문화"나 다름없다. 우리 오빠들이 1등 먹어야 해요. 기타는 XXX가 짱이지.

그럼 검색에 집단지성은 불가능한건가?
무슨 소리. 이미 Google이 처음부터 하던게 그거 아닌가. PageRank는 여러가지 고려사항이 있지만 기본적으로는 얼마나 많이 "참조"되었는가를 따진다. "참조"는 의지로 조절 가능한 것이 아니고, 또 설령 가능하다 하더라도 기회비용이 많이 든다. 따라서 간단하게 클릭질 하나로 결정되는 순위보다는 훨씬 신뢰할 수 있다. 집단 속에서 자연스럽게 체화되어 나와야 집단지성이라는 과분한 단어를 붙일 수 있는 것 아닌가?

아아, 한국적 특수성이라는 약방의 감초가 누군가의 입에서 나오겠지만, 그 놈의 한국적 특수성때문에 네이버 검색결과를 신뢰하지 못하잖아. 마치 어느 누구도 가판대 주간지에서 진실을 원하지는 않는 것처럼. 오로지 원하는 건 가쉽일 뿐. 가쉽검색에는 썩플이 최고입니다요.

네이버가 아닌 것이 천만다행. 그나마 네이트이니 그저 한번 씩 비웃어주고 끝날 수 있겠지만, 네이버였다면 벌써 클릭알바가 새로운 SEO 비즈니스 모델이 될 뻔하지 않았나.

차라리 검색순위를, "얼마나 Tong에 많이 클리핑되었는지", "얼마나 미니홈피에 많이 스크랩되었는지", "얼마나 egloos에 많이 링크되었는지" 를 계산해서 매긴다면 훨씬 객관적이면서도 자연스러운 집단지성 아니겠는가. 애꿎게 클릭한번 더하게 만드는 피곤한 서비스가 과연 성공할 것인지 심히 궁금.

1. 집단사고는 과연 회자되는 만큼 가치가 있는가? 통찰력있는 소수의 사고보다 나은 가치를 줄 수 있는가?
2. 집단사고는 결국 소수의 영향력있는 오피니언 리더의 아이디어를 좀더 대중지향적인 모습으로 예쁘장하게 눈속임한 결과는 아닌가?
2-1. 집단의 사고가 근본적으로 오피니언 리더의 영향을 배제할 수 없는 한 엄밀한 의미의 집단사고라 부를 수 있는가?
2-2. 집단사고는 단순히 "집단 속에 속해있는 나"가 헤게모니를 획득했다는 착각과 자기만족을 주는 것뿐은 아닌가?
3. 집단사고는 그 방향성과 목표를 "evil"하지 않게 유지할 수 있는가? 혹은 컨트롤할 수 있는가?
3-1. 컨트롤할 수 있다면 그것은 집단사고라는 근본과 모순되는 것은 아닌가?
4. 집단사고가 철저하게 기층단위를 기반으로 작동하게 하려면 무엇을 전제로 해야하는가?
5. 이러한 모든 과정을 거쳐 집단사고가 긍정적으로 실현된다 하더라도 그것이 나의 가치에 부합한다는 보장을 할 수 있을까? 그렇다면 그 실현방법과 보장이유는?
5-1. 그렇지 않다면 나와 유리된 집단사고라는 것이 도대체 무슨 의미가 있는가?
6. 왜 그럴까? "나"를 제외한 집단사고가 "나"에게도 가치있을거라는 착각이 만연해있는 이유는?
7. 그렇다면 차라리 철저한 "나-중심"의 사고의 "집합-필터링"이 오히려 집단사고의 근본적인 의의에 가까운 것은 아닐까?
From : 옛날블로그 : Group Think, Group Intelligence

아직 더 때릴 것이 남았는데,
이른바 릴레이서플이라면서 프레임링크를 걸어버린다.
예:http://searchplus.nate.com/searchplus/relay.plus?ud=1&query=naver&coll=dir_site&s=1&forbid=&mid=dirSite1
이런 건 naver에서 소송안거나? :)
이는 엄연히 저작권을 침해하는 프레임링크라고.
하긴, 네이버 역시 비슷하게 프레임링크를 이용하는 서비스가 있으니 뭐라 할 말도 없겠지.
웃기는 것은, 죄다 이렇게 프레임링크를 걸었으면서, "웹뉴스"검색결과에는 빠져있다. 왜냐고? 온신협에서 프레임링크는 고소대상이니까.
즉, 뭔 말인가 하니, 저작권 침해로 고소당할까봐 신문사 검색결과에는 붙일 수 없는 프레임링크를 다른 곳에는 맘껏 쓰고 있다는 소리. 이참에 고소해버릴까? (아쉽게도 이 사이트는 검색결과에 나오지 않네... 마이너블로거의 서러움. 아쉽.)

웹 2.0이라면서 요즘 프레임링크를 맘껏(?) 사용하는 서비스들이 늘고 있다. 글쎄.. 물론 저작권법이 현실적으로 바뀌어야겠지만, 어쨌거나 현재 불법(?)인 프레임링크를 이렇게 막 써도 되는건가? 나름 저작권에 민감한 사용자들도 이 건에는 별 불만 없는 건가?

내친 김에 하나만 더 때리자.
"디렉토리/사이트 분류"의 "네이버"와 "웹페이지 분류"의 "네이버"는 별개의 항목으로, 플러즌이나 플러스도 따로 관리된다. 뭐, 개념상 다를 수도 있겠지만, 사용자들은 과연 두 가지를 서로 다른 것이라고 인식하고 있을까? 하나는 25플러즌, 또 하나는 2플러즌. "daum"으로 검색해보면 각각 20플러즌과 4플러즌이다. 나는 도대체 여기에 어떤 집단지성을 발견할 수 있는지 알 수가 없다. 집단바보놀이만 가득한 느낌이다.

CSS에서 selector 우선순위 계산하기

CSS를 사용하다보면 같은 엘리먼트에 대해 여러곳에서 선언하는 경우가 있다.
예를 들자면 다음과 같은 경우.

[html]
li {color:#A00;}
.list_item {color:#0A0;}
#item_1 {color:#00A;}
...

hello

...
[/html]

이런 경우, 어떤 셀렉터가 우선될 것인가.

이에 대해서는 다음과 같은 공식이 있다.

* {} /* a=0 b=0 c=0 d=0 -> specificity = 0,0,0,0 */
li {} /* a=0 b=0 c=0 d=1 -> specificity = 0,0,0,1 */
li:first-line {} /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */
ul li {} /* a=0 b=0 c=0 d=2 -> specificity = 0,0,0,2 */
ul ol+li {} /* a=0 b=0 c=0 d=3 -> specificity = 0,0,0,3 */
h1 + *[rel=up]{} /* a=0 b=0 c=1 d=1 -> specificity = 0,0,1,1 */
ul ol li.red {} /* a=0 b=0 c=1 d=3 -> specificity = 0,0,1,3 */
li.red.level {} /* a=0 b=0 c=2 d=1 -> specificity = 0,0,2,1 */
#x34y {} /* a=0 b=1 c=0 d=0 -> specificity = 0,1,0,0 */
style="" /* a=1 b=0 c=0 d=0 -> specificity = 1,0,0,0 */

1) inline 스타일 (style="")은 무조건 최상위이다. (a = 1, inline 스타일을 사용하지 않으면 a = 0)
2) id selector 갯수를 b라 한다.
3) class selector와 pseudo selector 갯수를 c라 한다.
4) 엘리먼트의 갯수를 d라 한다.
5) abcd의 조합이 큰 순서로 우선순위가 결정된다.

예를 들어,
li {...} : 0001
ul li {...} : 0002
ul li ul li {...} : 0004
.list_item {...} : 0010
li.list_item {...} : 0011
.menu_list .list_item {...} : 0020
ul.menu_list li.list_item {...} : 0022
ul#main_menu li.list_item {...} : 0112
ul#main_menu li.list_item div.item_label img : 0124

간단히 말하자면, 좀더 상세화시킬 수록 높은 순위로 CSS가 적용된다는 뜻이다.

이를 이용해서 모듈별 CSS관리가 가능한데,
즉, 중간정도의 우선순위로 모듈별 CSS를 적고, 나중에 페이지에 적용할 때에는 그보다 높은 우선순위로 페이지별 CSS를 적어주게 되면 모듈별 CSS의 수정 없이 원하는 디자인 대로 페이지별 CSS에 따라 적용시킬 수 있다는 뜻이다.

참조 : http://www.w3.org/TR/CSS21/cascade.html#specificity

놓치기 쉬운 가상클래스의 selector 순서

링크(a)에 대해 셀렉터를 적을 때 주의할 점.
CSS의 선언은 나중에 선언한 것이 앞서 선언한 것을 덮어 쓰게 된다. 대개의 경우에는 문제가 없는데, 한가지 주의해야 할 부분은, a에 대한 가상클래스(pseudo-class) - 예를 들어, :hover 따위... - 를 적을 때이다.

다음 순서를 지켜야 생각한 대로 동작하게 된다.

a:link
a:visited
a:hover
a:active
a:focus

이 부분에 대해서 정찬명씨는 명언을 남기셨다. "링크 방문시 지나치게 활동하면 주목받습니다."
외우기 쉽다.