이바닥이 원래 그래
EBADAC - OOPARTS : Out Of Place Articles.
Archive for September, 2006
September 30, 2006 at 2:12 am · Filed under WebDevelopment, WebPlan, WebStandard
작년에 한 컨퍼런스에서 웹표준에 관해 강연한 후, 받은 질문 중에 이런 것이 있었습니다.
페이지를 아무리 구조적으로 만든다 해도, 사용자가 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은 이제 좀 자제할 때도 되었잖아요?
September 28, 2006 at 2:37 am · Filed under WebDevelopment, WebPlan
국내 가입형 블로그 서비스들 대부분이 달력을 제공합니다.
그런데, 실상, 현재 국내 블로그에서 가장 쓸모없는 인터페이스가 뭔가하면, 그건 바로 달력이라 이거죠.
달력 쓰세요?
거의 안쓰실겁니다.
그럼에도 불구하고 왜 달력은 블로그들마다 달려있는 걸까요? 심지어 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의 용도라면 용도랄까요.
예전에 썼던 참고링크 : http://eouia0.cafe24.com/blog2/archives/002556.html
September 25, 2006 at 12:37 am · Filed under WebDevelopment, WebStandard
1) IE 7에서는 바뀐다지만, 현재까지는 PNG 24의 알파채널을 IE에서는 제대로 못써왔다. PNG의 알파채널이 먹지않기 때문에, CSS를 이용한 디자인에서 레이어간의 부드러운 이미지 중첩이 어려웠었다.
2) IE에서는 이 문제의 해결을 위해서는 필터를 사용해야 하나, 이럴 경우 접근성의 문제가 있다.
3) 어차피 이미지는 접근성 면에서 그다지 좋다고 할 수는 없다.
세가지 문제를 해결한 IR기법에 대한 소개.
demo : http://eouia0.cafe24.com/temp/ajax_or_dhtml/accessibility/ir.html
위 데모는, FF로 볼 경우에는 정상적으로 보이지만, IE에서는 두번째 이미지가 알파채널이 제대로 적용이 안되어 이상하게 보일 것이다.
첫번째 이미지가 새로운 IR 기법이 적용된 예이다.
자세한 내용은 소스를 보시고…
이번에는 javascript, image, CSS를 disable시키고 같은 페이지를 확인해보면, 첫번째 이미지 자리에 “PNG”라는 문자열이 나옴을 알 수 있다.
image를 disable시킨 경우에는 alt텍스트로 대체되었고,
javascript를 disable시킨 경우에는 IR되기 전의 원본 텍스트가 표시된다.
웹브라우저 외에 다른 디바이스나 프로그램에서 읽어들여도 내용이 통하게 되는 방법이다.
덤으로 바로 앞글에서 소개한 pageOnload 객체를 이용한 javascript binding기법의 샘플도 겸한다.
추가(20061018)
백그라운드로 PNG를 사용할 때에 적용되게 함.(샘플에서 3번째 “PNG”이미지)
September 24, 2006 at 11:20 pm · Filed under WebDevelopment, WebStandard
듣기 싫어하는 사람들이 제법 많은 “접근성”이란 말을 시작부터 써야겠다.
“접근성”을 높이는 방법 중 한가지는, HTML안에 javascript를 최대한 빼버리는 작업이 포함되는데,
물론 오늘날의 화려한 웹페이지에서 javascript를 안쓸수는 없는 일.
따라서 javascript를 별도로 밖으로 빼어두어 javascript가 없이도 작동하게 한 후, 나중에 binding하는 방법을 쓰는 것이 좋은데, 이는 behavior를 컨텐트와 분리시킨다는 요즈음의 트렌드와도 일맥상통한다.
무슨 소리인고 하니,
[html]
[/html]
이런 코딩을 하지 말라는 뜻.
대신
[html]
[/html]
이런 식으로 쓰라는 건데…
한가지 문제가 있는 것이, 이 window.onload는 어쩔 수 없이 HTML안에 손으로 적어줘야 한다는 점. 모듈별 js를 이용한다거나 js 프레임워크를 쓸 때에도 window.onload는 페이지의 상황마다 그 구성이 달라질 수 밖에 없다.
이 window.onload를 밖으로 빼고, 모듈별 js로 관리할 때 자동으로 window.onload의 구성을 바꿔주는 방법이 없을까?
그래서 만들어본 pageOnload 객체.
pageOnload.js
[javascript]
var PageOnload = new pageOnload();
window.onload = function() {
PageOnload.run();
}
function pageOnload() {
this.stackFunc = new Array();
this.add = function() {
var args = new Array();
var len = this.stackFunc.length;
for(var i = 0; i < arguments.length; i++) {
args[i] = arguments[i];
}
this.stackFunc[len] = args;
}
this.run = function() {
var tstr='';
for (var i=0; i < this.stackFunc.length; i++) {
var myFunc = this.stackFunc[i].shift();
if (this.stackFunc[i].length > 0) {
var str = “‘” + this.stackFunc[i][0] + “‘”;
if (this.stackFunc[i].length > 1) {
for(var j=1; j < this.stackFunc[i].length;j++) {
str = str + ", '" + this.stackFunc[i][j] + "'";
}
}
}
eval(myFunc + "(" + str + ");");
}
}
}
[/javascript]
이 파일을 밖으로 빼두고
[html]
[/html]
처럼 javascript의 제일 처음에 불러온다.
그럼 moduleA.js에서는
[javascript]
PageOnload.add(”initModuleA”, argument1, argument2, argument3, …);
initModuleA(arg1, arg2, arg3, …) {
// window.onload시 moduleA의 초기화에 필요한 작업.
}
[/javascript]
처럼 자기자신을 초기화하는 코드를 window.onload에 직접 기록하는 대신 pageOnload객체에 위임할 수 있다.
물론 javascript없는 HTML코드 따위를 지향하지 않는 경우에는 필요없는 코드.
TODO : 머리가 돌이 되었는지, eval말고 분명히 function pointer를 이용해서 해당 함수를 직접 실행시키는 방법이 있었을 터인데 기억이 안난다. -_-a
TODO : 현재는 초기화함수의 인자를 string형으로만 받고 있는데, 다른 타입도 전달가능하도록 할 것.
개선부분에 대해 아이디어 있으신 분 알려주세요.
September 23, 2006 at 8:02 pm · Filed under WebStandard, WorldWideWoops
그러니까, 졸지에 무슨 지하철 껌팔이라도 된 듯한 느낌.
“목마른 사슴이 물을 찾듯이… 맘잡고 살아보려니 조금씩 도와주쇼. 껌한통 천원임다.”
—
그 내용이 어떻든 간에, 불친절한 금자씨 덕분에 거부감을 느끼게 되어 받아들이지 못한다는 묘한 증언을 참, 어떻게 받아들여야 할지.
하긴 그렇지요. 누군들, “니가 5년간 해왔던 건 말짱 틀렸어. 다시 처음부터 제대로 배우시지…” 라고 하면 기분좋을 사람 누가 있겠습니까.
“안타깝고 황송하게도 5년간 익히고 배우신게 사실은 조금 뭐랄까, 아쉬운 점이 있다고나 할까 그게 꼭 틀렸다고는 할 순 없지만 그래도 더 나은 방법이 있다고도 할 수 있으니 혹시 시간이 조금 남아도신다거나 딱히 덧붙이고 싶으시다면…이러이러한 자료가 있으니 바쁘시더라도 한번쯤은 보시고 여기는 이러이러하게 해보시고…”
처럼 숟기락에 밥담아 떠먹이듯 말해야 했었다는 게지요. 쉬운 말로, 부드러운 말로…
그러니까 대한민국의 웹개발판이 개판이 된 건 그렇다 치고, 다시 정상으로 돌려보자는 노력이 자꾸 헛바퀴를 도는 건, 불친절한 금자씨 때문이라는 거지요. 금자씨만 친절했어도 진작에 맘바꿔서 “그래, 뭐, 그렇게 까지 말해주니 내 한번 틈날 때 봐보기는 해볼께.”라고 그 귀하신 몸뚱아리를 좀 움직여주셨겠다는 거지요.
에, 뭐 그런 일이 어디 이뿐이겠습니까.
교사가 자기 애한테 관심을 안줘서 공부를 못한다고 하며 “우리 애가 공부를 안해서 그렇지 머리는 좋아요.”라고 말하는 부모들.
선임병의 친절한 말 한마디가 부족해서 탈영사고는 매일처럼 일어나고 있고,
선배의 말이 옳긴 하지만 그렇게 강압적인 자세는 싫어요, 라고 하는 대학 신입생들..
뭐 세상이 다 그렇고 그런거죠.
불친절한 금자씨야 불친절하도록 내버려두고…
친절한 분들은 여전히 있으니… 친절한 분들까지 싸잡아 욕먹으면 그건 좀 섭섭하겠죠. 애초에 금자씨들이 무슨 활동을 하는지 별 관심도 없으셨잖아요.
아래는 친절한 금자씨들.
박수만님께서
이런 책을 내신 지 벌써 몇개월이 되어가는군요.
현석님과 조훈님은 본업보다는 강사로 뛰시는게 더 많아보입니다. 한달에 한두건 이상 교육, 세미나 등이 열리니 꽤나 바쁘실겁니다.
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/
뭐, 이외에도 많은 분들이 “꽁하니 그들만의 모임에 갇혀서 찢고 떠드는” 대신 밖에서 친절히 활동하고 계십니다.
—
아, 저는 최근에는 불러주는데도 없고, 그냥 불친절하게 살 겁니다.
September 23, 2006 at 1:37 am · Filed under WebDevelopment, WebPlan, WebStandard
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
September 22, 2006 at 4:15 am · Filed under WebDevelopment, WebPlan, WebStandard
그러니까, 지겹게 듣는 이야기는 “자본주의하의 현실론”으로 요약할 수 있겠다.
여기, 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가 아니면 웹에서 불가능한 기능이 있었지?
결론부터 말하자면, 그런 것 따위 없다. 그런 것이 있다면 그건 “웹”이 아닐 뿐.
September 21, 2006 at 12:36 pm · Filed under WebDevelopment, WebPlan
마이크로포맷에 관해 정리할 일이 있어 겸사겸사.
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]
[/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에 대해… (아마도.)
September 19, 2006 at 4:56 pm · Filed under WebDevelopment
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을 위해 개발자 포럼등에서 활발하게 논의되고 있습니다.
September 18, 2006 at 12:47 pm · Filed under WebDevelopment, WebPlan
트랙백이 멍청한 기술이냐고 묻는 글을 보고…
트랙백이 멍청해진 이유는, 개발자들이 멍청하거나, 게으르기 때문이 절반정도 이유가 된다. (나머지 절반은 기획자의 잘못이다.)
먼저 핑백(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]
