macbook pro, smackbook pro

맥북프로를 사용한지 9개월이 되어갑니다만, 만족도는 근 20여년의 컴퓨팅 환경중에 가장 손꼽을 만합니다.
사실, 이전에 8500이나, G4를 썼을 때는 별다른 장점도 못느꼈고, 늘 사자 마자 방치플레이 후 매각… 이었습니다만, 드디어 Intel기반에 OSX 10에 이르러서는 거의 완전히 Windows를 버리게 되었습니다. 일단 부트캠프를 설치해두긴 했습니다만, FootBallManager를 하기 위한 용도 외에는 Windows 부팅할 일 조차 없게 되었습니다.

제가 여전히 Windows 어플 개발을 했다면 Windows를 계속 썼겠습니다만, 웹환경 그것도 LAMP기반이 되다보니 MBP는 개발자에게 최상의 환경을 주는군요.

- MBP에 LAMP를 바로 설치하고, 실서버, 개발서버와 연동시켜 완벽한 개발/테스트 환경을 구축할 수 있습니다. 물론 윈도우즈 환경에서도 나름 WAMP를 설치할 수도 있겠으나 미묘하게 불편함이 있었습니다.
- 개발에 주로 사용하는 도구는 ZendIDE와 Eclipse인데, 둘다 OSX에서 훌륭히 잘 돌아갑니다. 특히 ZendIDE는 Windows에서는 크래쉬가 잘 일어나는데 비해 OSX에서는 거의 크래쉬없이 돌아갑니다.
- 물론 vi도 빼놓을 수 없겠죠. 콘솔 터미널이 시스템과 일체화되어서 네트웍을 넘나드는 작업의 만족성은 Win에서의 그것과 비할 수 없습니다.
- 솔직히, PowerPoint가 Keynote보다 편하긴 합니다만, 만들어진 결과물은… Keynote는 당신을 프로 발표자로 만들어줍니다. PT때 효과 200%죠. 너무 화려해서 사람들이 강연내용보다는 슬라이드 화면에 넋이 빠지는 단점이 있긴 합니다만.

해서.. 새로 오픈하는 서울 사무소에는 개발자 전원에게 맥을 지급할까… 진지하게 고민 중입니다.
비용이 적다고는 할 수 없는게 단점이긴 하지만.

—

SmackbookPro 동영상을 보고 반해서 설치해봤습니다만…
일주일간 사용해본 감상은 미묘. 랄까.

손으로 탁탁 쳐서 버추어데스크탑 페이지를 넘기는 것이 재밌긴 합니다만, 감도 조절이 미묘하게 힘듭니다.
너무 민감하게 해놓으면 책상위에 볼펜이 떨어져도 페이지가 휙 넘어가 버립니다. 그렇다고 둔감하게 해놓으면 맥북프로를 치는 힘이 세져야 합니다.
무엇보다도 조용한 사무실에서 탁탁 거리며 노트북 모니터를 치고 있는 모습을 반대쪽에서 보게 되면, 마치 고장난 흑백텔레비전을 때려서 나오게 하는 것 같은 모양. 맞은 편에 앉은 모리야 상이 뭐하는 짓인가 쳐다보는 것을 깨달으면 어찌나 민망한지…

그래도 요즘은 노하우가 늘어, 미묘하게 무릎으로 책상 모서리를 살짝 건드림으로써 페이지를 넘기게 하고 있습니다. 이른바, 전신 컴퓨팅이랄까요? ^_^;;

BT 키보드와 BT 마이티마우스까지 겸비하고 듀얼모니터(시네마 디스플레이는 아니지만.)를 사용하니 당분간 업그레이드 욕구는 없을 것 같습니다.

한줄 요약 : 저 맥빠돌이 맞습니다. ^_^

소중한 방문자

답글인사같은 것 거의 안하는 eouia입니다만, 찾아주는 분들 모두 소중하게 생각하고 있습니다.그래도 사람인지라, 실은 마음속에는 방문자마다 레벨을 매겨두는 것은 어쩔 수 없다고 변명을 일단.나름 방문자들을 몇개의 그룹으로 나누고 있습니다. 개인의 임의적인 기준은 아니고, 완전히 기계적으로 유입경로별로의 그루핑입니다.

1. 가장 기쁜 그룹은 외부링크를 타고 오시는 분, 혹은 외부링크로 걸어주신 분들입니다.콕 찝어 제 블로그나 포스트를 언급해주셨다는 이야기는 어떤 식으로든 그 블로그와 그 포스트가 유의미하고 리마커블했다는 의미니까요. 게다가 그것을 혼자 보관하지 않고 다른 이들에게도 노출시켜주신다니 황송할 정도입니다. 레퍼러를 볼 때마다 이 트래픽이 가장 기쁩니다.

2. 그다음은 북마커 또는 RSS 리더를 타고 오시는 분들입니다.어찌보면 첫번째 그룹보다 저를 높게 평가해주는 분들입니다만, 저역시 RSS리더를 건성건성 읽고 있기 때문에 많은 분들이 또한 제 블로그 역시 건성건성 읽고 있을 것 같다는 선입견 때문에 두번째 자리를 차지하게 되었네요.그래도 무섭기는 이 분들이 제일 무서워서, 꾸준히, 쓸모 있는 포스팅을 하지 않으면 이 분들은 RSS 리더에서 삭제하실테죠. 리더기로 잡히는 레퍼러들은 채찍질의 의미로 받아들이고 있습니다.

3. 검색엔진에서 오시는 분들도 반갑죠.이 분들은, 정말 본인에게 필요한 정보를 찾다가 제 블로그까지 흘러오셨을 텐데요. 그래서 한편 도움이 될 지도 모른다는 뿌듯함과 함께, 기껏 찾아왔는데 도움이 안되면 어쩌나 하는 걱정도 있습니다. 그래서 검색엔진을 타고 오신 분들께는 찾으셨던 검색어와 관련된 글들을 모아서 보여드리고 있습니다. 만약 검색어와 관련된 글들이 여러개 잡힌다면 그 분들은 그나마 제 블로그에 맞게 찾아오신거고 (실제로 도움이 되는 포스팅이었는지는 별개로.. ), 또 만약 관련 글들이 안잡힌다면, 일부러 제 블로그에서 시간 낭비하며 찾아볼 필요가 없다는 걸 아실테지요.

4. 가장 끄트머리는 메타블로그들이 차지하고 있습니다.이제는 메타블로그에 대한 관심도 거의 없어졌어요. 실상 늘 혹시나 하고 메타블로그에 방문했다가, 역시나 하고 돌아오는 날의 연속입니다. 거의, 포털 뉴스 페이지와 똑같은 취급을 저한테 받고 있습니다. ^^;포스팅이 있는 날은 메타블로그로부터의 유입량이 꽤 됩니다만, 전혀 엔터테인먼트 적인 성격이 아닌 제 블로그에 두번 방문하실 일은 없으신 분들이겠죠. 오히려, 도대체 내가 얼마나 자극적인 제목을 붙였길래 메타블로그를 타고 들어왔을까... 반성하는 계기가 됩니다. (메타에 등록된 모든 글들을 눌러보시는 분은 없잖아요. 결국 제 글을 클릭하신 분은 제 낙시질(?)에 걸린 셈인거죠.)그럼에도 불구하고 메타블로그에서 내리지 않고 있는 이유는, 결국은 설치형 블로그의 어쩔 수 없는 숙명이랄까요. 자력으로 외부에 노출시킬 수 있는 수단으로서의 대안이 없기 때문입니다.거의 계륵...인 셈입니다. 좀 더 고민을 해봐야겠군요.하지만, 내 맘속에서의 제멋대로 편견일 뿐, 일단 방문해주신 모든 방문자들은 소중하답니다. ^_^;

근황

1. hosting을 옮기겠다고 말을 하자마자, 갑자기 속도가 조금 빨라졌습니다. 특유의 게으름이 발동해서 호스팅 이전은 잠시 보류. 그러나 다음번에 또 이런 일이 발생하면 진짜 옮길 겁니다.

2. 귀국하면 운동을 해야겠어요. 체중이 많이 불었습니다. 더불어 뱃살도. 야채가 적고 육류가 빠지지 않으며 튀기기는 기본인 일본음식만 먹었더니 살이 뒤룩뒤룩. 일산에서 신촌까지 자전거로 다녀볼까... 생각중입니다. 아마 힘들겠지만.

3. 2월 3일부터 8일까지 일시로 한국에 들어갑니다. 날짜로는 6일인데, 고향에 다녀오고, 병원가고, 카메라 팔고, 구인자 면접보고, 강연(?) 한판 때려주기에 시간이 빠듯. 혹시 긴한 일로 저를 봐야할 일이 있으신 분은 이 기간동안에 미리 약속을 잡아주세요.(없겠지만.)

실은, 이발이 더 급해요. 여기는 이발하는데 너무 비싸서.

4. 와이프 몰래(..라고는 해도 여기 써놓으면 읽어보니까 몰래도 아니지요.) XBOX 360이라도 사들고 가려 했는데 일본내에서도 품절입니다. 엑박은 물론, PS3고, NDSL이고 모두 품절이에요. 심지어 이번에는 꼭 사야지 맘 먹었던 18-200 VR2렌즈도 품절. 뭡니까 이건. 환율이 750원대라고 기뻐해도 보람이 없잖아요!
어쩌다 아키하바라의 요도바시에 가면, 평일 낮에도 게임사러온 아저씨,언니들이 몇시간씩 줄을 서있어요. 과연 일본이구나 싶네요.

5. 오픈소스 프로젝트를 해야지 맘먹고, 여전히 빈손입니다 그려. 바쁘면서도 게으른 탓이지요.

Google Calendar로 소규모 일정 관리하기

개인적으로는 MS Project의 강력함에 흠뻑 취해있고, Windows환경만 생각한다면 Outlook만으로 충분히 프로젝트 일정 관리를 해낼 수 있지만...
어쩌다보니 그런 환경이 여의치 않을 때 소규모 프로젝트를 관리해야한다면 Google Calendar를 추천합니다. 물론 프로젝트 참여인원 모두가 Google 계정이 있어야 한다는 제약이 있긴 하지만요.

사실 많은 회사에서 인트라넷으로 프로젝트 관리 도구를 사용하고 있습니다만, 지금까지 경험해본 바, 그러한 솔루션들이 구글 캘린더보다 못하더군요.(Outlook보다 못함은 당연하구요.) 물론, ERP환경에서 전자문서결재...등등을 포함하는 기능들은 분명 훌륭합니다만, "일정관리/공유"라는 면에서 본다면 많이 미흡하지요.

하긴, 그나마 그런 인트라넷도 없어서 여전히 엑셀 시트에 달력 그려서 관리하는 곳도 있으니까, 그런 열악한 환경이라면 구글 캘린더를 일정관리에 사용해보는 것도 괜찮겠습니다.

[프로젝트 관리자]
1. 프로젝트 관리자는 프로젝트 이름으로 새로운 Google 계정을 하나 만듭니다. (ex:ourproject@gmail.com)
2. 만들어진 계정으로 접속해서 Google Calendar로 들어간 다음, 왼쪽 하단의 Calendars에 "My Calendar +" 버튼을 클릭해 새 캘린더를 만듭니다.
3. 프로젝트 전체와 관련된 일정 (예:Milestone)을 입력합니다.
4. 이제, 만들어진 캘린더를 프로젝트 멤버들과 공유해야겠지요. "이 캘린더 공유"로 들어가 멤버들의 Google 계정을 사용자로 추가해줍니다. 이 때 옵션은 "모든 이벤트 세부정보 보기"(멤버들이 보기만 하고 변경은 할 수 없습니다.) 로 놓는게 좋겠지요.
5. Trac등의 관리도구를 쓴다면 거기에서 만들어진 일정 데이터를 iCalendar형태로 입력받을 수 있습니다. "기타 캘린더 +" 버튼을 눌러 "공개 캘린더 주소"로 들어가 Trac등에서 만들어진 일정데이터의 iCalendar주소를 입력하면 됩니다.

[프로젝트 멤버]
1. 멤버들은 각각 자신의 구글 캘린더에 접속한 후, 역시 "내 캘린더"를 새로 만듭니다.
2. 캘린더 이름에 자신의 이름을 적어 새로운 개인 업무 일정 캘린더를 만든 후에,
3. 역시 캘린더 공유에서 프로젝트 관리자를 공유 사용자로 추가해줍니다. 이 때 옵션은 "변경 및 공유 관리"로 해두어야 프로젝트 관리자가 각 개별 멤버의 일정을 조정한다든가 하는게 가능해지니 주의.
4. 자신의 캘린더를 수정하면 프로젝트 관리자의 캘린더에도 수정사항이 반영됩니다. 물론 그 반대도 가능.
5. 만약 캘린더 중의 특정 이벤트가 "회의"나 "공동작업"처럼 다른 사람과 공유되어야 할 경우, 이벤트 수정 페이지에서 해당 멤버를 "손님"으로 추가함으로써 이벤트를 공유할 수 있습니다.
6. 프로젝트 관리자가 새 이벤트를 각각의 멤버에게 할당한다든가 커멘트를 남긴다든가 하는 활용법도 있겠지요.
7. Gmail을 통해 여러가지 notifying이 가능하므로 평소에 Gmail 을 볼 수 있는 Alarm기능을 데스크탑에 설치해두는 쪽이 좋겠습니다. (Google Desktop이나, GoogleTalk나... 혹은 Gmail을 자신의 메일 클라이언트에서 받아 볼 수 있게 한다든가...)

[자신의 PIMS와 싱크하기]
안타깝게도, 아직 Google Calendar와 양방향 싱크가 되는 PIMS는 없는 것 같네요.
일단 OSX의 iCal에서는 단방향 싱크는 가능합니다.(Outlook Vista에서도 가능할지도. 테스트는 안해봤습니다.)
사용법은 간단해서, 싱크를 원하는 캘린더를 선택해 설정으로 들어가면 "비공개 주소" 항목에 iCalendar URL이 있습니다. 이 주소를 복사해서 자신의 iCal에 일정 불러오기로 넣어주면, 구글 캘린더에서 변경된 내용이 자신의 iCal에서 확인할 수 있습니다. 마찬가지 방법으로 그 반대방향으로의 싱크도 가능은 합니다만, 일정의 작성은 한군데에서 통일하는 쪽이 좋기 때문에 프로젝트와 관련된 일정의 작성은 구글 캘린더에서, 보기는 iCal에서 보는 쪽을 권합니다.

[작은 팁]
1. "기타 캘린더"를 생성할 때, "캘린더 찾아보기"에 들어가면 휴일 데이터가 있습니다. 저같은 경우 일본 휴일도 필요해서 한국 휴일과 일본 휴일을 모두 추가해서 유용하게 쓰고 있습니다.
2. "비공개 주소"에서 XML이나 HTML 주소를 이용하면 Excel 등에서도 일정 데이터를 쉽게 불러올 수 있습니다. 포매팅이 필요하다면 간단한 프로그램 하나를 짜서 적절하게 리팩토링을 해주는 것도 한 방법이겠지요.

이러이러 해도 MS Project나 Outlook에 비하면 많은 기능이 불편하긴 합니다만...
무료이고, 간단하고, 무엇보다도 OSX에서 문제없이 쓸 수 있다는 점에 억지로(?) 구글 캘린더로 프로젝트 일정관리를 시도해보았습니다. ^_^

페이지 로딩 편집증

대부분의 브라우저에서 지원하는 기능이긴 한데, 내가 사용하고 있는 FF에서는, 페이지가 통신 혹은 로딩중에는 계속 로딩마크가 돌아감을 볼 수 있다.

아직 페이지가 로딩 중이고, HTTP 커넥션이 끝나지 않았음을 보여주는 작은 서비스니까 있어도 그만, 없어도 그만이긴 한데, 없으면 웹커넥션이 죽었는지 어떤 건지 알 수 없어 불안해지니까 있으면 좋다는 쪽.

가끔 로딩마크를 볼 때마다 강박적이 되어가는 것을 느끼는데...

1) 느리다. 느리다. 느리다.
평균 대기시간이 3.5초라는 통계결과도 있거니와, 주소창에 주소 치고 바로 페이지가 안뜨면 답답해진다. 하긴 지금 호스팅받고 있는 업체도 딱히 좋은 환경은 아닌지라 내 블로그 조차도 느리긴 한데. 여튼 페이지 로딩 마크만 돌아가고 있고 늦게 뜨는 사이트들을 보고 있노라면 조급증이...

2) 왜 아직도 돌아. 뭔가 문제 있나?
그런데, 페이지가 로딩된 후에도 여전히 로딩마크가 돌아가는 경우들이 있다. frame을 썼거나, iframe을 썼거나... 혹은 AJAX를 썼거나.
그러면 불안해지기 시작. 뭐지, 왜 이거 아직도 돌고있는 거지. 보일 건 다 보인 것 같은데 아직도 커넥션이 끊어지지 않고 뭔가 데이터가 왔다갔다 하고 있다는 것을 알면 괜시리 불안해진다. 도대체 뭐가 아직도 남았길래 데이터가 오가고 있는가. 나 몰래 브라우저 뒷면에서는 무슨 일들이 벌어지고 있는가. 데이터 주고받기가 끝날 때까지 기다려야하나? 별 잡생각이 다 든다. 직업병이라서인지 '어이구, 저 아까운 커넥션', '스크립트 소스에 문제가 있음이 틀림없어...'라는 생각이 진짜 이유와는 상관없이 먼저 드니. ㅎㅎ

frame이나 iframe이나.. 혹은 리모트 커넥션으로 인해 풀 페이지 로딩이 느린 경우야 '회선의 문제상 아직 로딩이 안끝났습니다.'라고 생각하고 조금 더 기다릴 수도 있겠지만.(사실, 그 경우에도 맘편하지는 않다. 왜 꼭 그런 방식을 써야만 하는가..라는 생각)

게다가 AJAX나 뭐 기타등등 여러 다른 최신(?)기법을 써서, 페이지가 다 로딩된 후에도 커넥션을 물고 돌아가고 있는 로딩마크들이 요즘 늘어났는데, 그것들을 보고 있노라면 답답함과 불안함이 엄습. 과히 편집증 수준인가.

멀티탭속에 가려져 현재 보고 있지 않은 페이지에서도 계속 로딩마크가 돌고 있음을 깨달으면 회선 낭비라는 생각도 들고, 브라우저 뒷편에서 나 몰래 뭔가 꿍꿍이를 꾸미고 있는 건 아닌가하는 의심까지 들 정도니 좀 심하다는 생각이 들긴 한다.

나랑 같은 생각을 하는 사람이 있긴 한가? 그냥 혼자만의 편집증일 수도.

FTA와 IT

오늘 FTA 지재권 관련 기사를 보고 생각나서 포스팅.

한미 FTA 체결 이후 IT 업계의 변화...

1. 일방적 구제절차
A: B 회사는 우리가 개발한 암호화 알고리즘 라이브러리를 몰래 도용해서 쓰고 있음에 틀림없습니다. 일방적 구제절차를 실시하겠습니다!
B: 아니, 우리가 쓰는 라이브러리는 우리가 10년동안 연구개발해서 만든 것임으로..
A: 닥쳐! 아무리봐도 너희는 우리 라이브러리를 쓰고 있음에 틀림없어. 그러니 조사가 끝날 때까지 서비스를 중단하고 증거를 찾기 위해 서버를 압수하겠다!
B: 아니, 이건 코드만 까봐도 알 수 있다니까... 우리가 만들었다는 것을 증명할 수 있는 서류가 여기...
A: 시꺼! 니들은 변명할 방법이나 기회가 없다. 모든 것은 특허권을 가진 우리 맘대로다!
...
A: 미안, 아니었네.
B: ... T_T

2. 친고죄 폐지
A: 아니, B가 제 소스를 가져다 쓴 건 사실이긴 한데요, 저는 괜찮다니까요. 별로 대단한 것도 아니고, 그냥 B가 써도 되는데요.. 아니, 저는 괜찮다는데 왜 B를 구속하세요? 저는 진짜 괜찮다니까요...

3. 법정손해배상제도/부가적손해배상제도
법원:이로써, B가 A의 저작권을 침해했음이 입증되었습니다. 그러므로 피해보상을...
B: 흑흑.. 죄송합니다. 하지만 진짜 저희 이 소스 카피해서 쓴 거 수익을 내지 않았어요. 테스트용으로만 쓴거라서...
A: 그건 상관없지요. 어쨌거나 유사한 케이스의 판례에서 이미 백만달러의 배상금 판례가 있고, 저희 회사의 정신적 피해보상비 삼백만 달러를 추가하여 총 사백만달러의 배상금을 청구합니다.

4. 저작권 보호기간 연장
A: 여기에 '미키마우스' 그림만 들어가면 우리 애니메이션 정보 서비스에 딱인데 말이야.
B: 그거 저작권 아직 20년 더 남았구요. 20년 후에는 또 연장하겠죠.

5. 일시적 복제 권리
A: B씨, 엊그저께 우리 사이트에 들어왔었지?
B: 아, 클릭실수로 그만... 근데 무슨 문제라도?
A: 당신을 일시적 복제권 위반 혐의로 기소하겠소.
B: ?!?!?!?!
A: 훗, 시치미 떼시긴. 당신 PC에 보면 temp디렉토리에 우리 사이트의 내용이 캐싱되어 있다고! 엄연한 저작권 위반이야!!

6. 기술적 보호조치
A: 금번 저희 회사가 만든 포토 앨범 서비스는 디지털 카메라에서 사용자가 촬영한 RAW 파일을 읽어들여 최상의 화질과 색감을 유지하도록...
B: Stop! 우리 회사의 RAW 포맷을 해석하는 것은 기술적 보호조치를 위반한 사례입니다! 소송을 걸겠습니다!

6-1. 기술적 보호조치 2
A: 일본 출장길에 새로 애니메이션 DVD를 샀는데 말이야, 이거 국내에서 보려면 어떻게 해야 해?
B: 안되죠. 코드프리가 불법으로 바뀌었거든요.
A: 왜 내 돈 주고 산 DVD를 내가 보는게 불법이야???

7. 온라인 서비스 책임제한
A: ?? 왜 제가 쓴 글이 삭제되었죠?
포털: 저작권 침해 신고가 들어와서입니다.
A: 그럴리가요? 누가 그래요?
포털: 모르죠. 저희는 일단 신고 들어오면 무조건 삭제합니다.
A: 저한테 먼저 알리고 그래야 하는 것 아닌가요? 그리고 신고한 측이 진짜 저작권자인지도 확인하고 그래야 하지 않나요?
포털: 통지의무없습니다. 즉시 삭제 안하면 저희가 고소당하거든요. 그리고 예전에는 진짜 저작권자인지 입증을 해야했습니다만, FTA 체결이후에는 딱히 그러지 않아도 되니까요. 참, 그쪽에서 고소한다고 고객님의 신상정보를 요구해서 보내드렸으니 소송대처 준비하세요.

암담한걸... -_-a

평판과 신뢰

정보의 과다는 정보의 빈곤만큼이나 '원하는 정보'의 획득에 방해가 된다.

과다한 정보 중에서 자신이 원하는 정보를 정확히 얻기 위해서는('찾기 위해서... 가 아님' ^_^), 정보에 대한 필터링이 우선되어야 하는데, 현재로서는, Profiling과 Reputation이 그나마 어느정도 구현되어 있는 방법이라 할 수 있다.

'개인 맞춤'이라고도 부를 수 있는 Profiling의 단점은, 필터가 세밀해질 수록 필터를 통과하는 정보의 양이 줄어들고, 자신의 프로파일링을 정확히 하기 힘들며, 정보가 해당 필터에 걸리게 하기 위해서는 컨텍스트 마이닝 기술이 필요한데 이것이 아직 쉬이 구현되기 어렵다는 점.

해서 요즘에는 Reputation - 이른바 '평판'에 기반한 가치분석법, 소위 '집단지성'이라는 시스템이 인기이다.

문제는, Reputation이 정보에 대한 질을 담보하기는 어렵다는 점. 모집단이 커지고 모집단의 수준이 평준화될 수록 특정 정보에 대한 가치가 낮아지게 된다. 즉, 모집단이 커질 수록 Reputation은 그 가치를 상실하게 된다.
모집단이 커질 수록, 취급하는 정보의 양이 많아지고, 그 많아진 정보 중에 '자신이 원하는 정보' - '모두가 원하는 정보'말고 - 를 찾는 것은, 또 다른 정보의 바다 속에서 헤엄치는 일인 셈이다.

Reputation이 높은 정보를 선택하면 되지 않겠냐고?
표준분포에 가까워질 수록, Reputation이 높은 정보란, 더 노출되기 쉽고, 더 많은 사람에게 그럭저럭 통용되는 수준이 되기 쉽다. 즉, 그것이 '내가 콕찝어 원하는 정보'일 가능성은 더 멀어지게 된다.
allblog나, digg 등이 점점 덩치가 커지면서 메인에 노출되는 정보들이 예전보다 '나'의 관심을 끌지 못하는 경험은 이상한 것이 아니다.

그렇다면 모집단을 적정 크기로 유지하거나, 혹은 정보의 표준분포를 '나'에게 맞게 인위적으로 이동시키는 방법은 어떨까?

이를 보완하기 위해 취할 수 있는 방법 중에 '신뢰' 시스템이 있다.

우선, 모집단을 '내가 선택한 소스'로 한정지을 수 있다. 그러니까, '뇌이버 지식즐'보다는 'TodaysPPC'에 가서 물어보는 쪽이 더 정확히 PDA에 대해 내가 원하는 정보를 얻을 수 있다는 뜻이다. TodaysPPC에 대한 나의 선택은 '이곳이 나에게 더 유용하다'라는 '신뢰' - Reliability에 기반한다.

또다른 신뢰시스템의 구현은 '가중치'로 표현할 수 있다. 예를 들어 '영화 디파티드'에 남들이 준 별점 네 개보다, 내 친구의 별점 두 개가 나한테 더 의미있다. 나는 그 친구와 같이 영화를 봐야하기 때문에. (혹은, 그 친구와 나의 영화취향은 비슷하기 때문에.)

물론 그 외에도 Reliability를 구현할 방법들은 많겠고...

Reliability를 구현하기 위한 선행조건이 있는데, 그것은 신뢰대상에 대해 나의 '개인적인 경험'이 기반되어야 한다는 것이다. 그 경험을 기반으로, 수치화하기 어려운 조건들을 신뢰대상이라는 라벨로 객체화시킬 수 있다.
즉, '내가 신뢰하는 이유를 나는 안다.(말로 표현하기는 어렵지만...)'라고나 할까?

사실 신뢰시스템은 Profiling 기법을 타인에게 위임하는 것과 마찬가지이다. '내가 무엇을 원하는지'에 대해 정확히 profiling하는 것이 어렵고, 또 기계가 그 profile과 context를 일치시키는 것이 어려운 상황에서, 그 과정을 '신뢰할 수 있는 타인'에게 맡기는 방법이라고 설명할 수도 있을 것이다.

이 시스템의 구현에 문제가 있다면, '신뢰할 수 있는 타인'을 어떻게 '내 경험'에서 뽑아내어 구체화시킬 수 있을까라는 점. 나아가서는 그 과정에 '나 자신의 왜곡된 의도'를 차단할 수 있는가 하는 점. (개인은 의식적/무의식적으로 자신의 의도가 행위에 노출되기 마련이다. '신뢰'는 '호/불호의 감성의 문제'가 아니라 객관적으로 계량화할 수 있는 기준이어야 한다.)

궁극적으로, '신뢰할 수 있는 기계'가 그 역할을 대신하겠지만, 그때까지는 '신뢰할 수 있는 타인'이 '생판 모르는 누군가'라든가 '나 자신도 모르는 나'보다는 나을 것이다.

시맨틱웹과 웹표준

* SWEETIER님의 말씀도 있고 해서 겸사겸사 예전에 쓰다가 쳐박아두었던 글을 다시 꺼내 먼지를 털어봅니다.

저같은 경우, 웹표준에 대해 이야기하는 이유는, "필요에 의해"라고 할 수 있겠습니다. 그러니까, 솔직하게 까놓고 말하자면 "장애인 등의 사회적 약자를 위해..." 라든가, "평등한 정보의 이용...", "비용 절감..." 같은 거창한 이유는 아니라는 거지요. 물론, 강연이나 교육을 나가면 저런 이유를 전면에 내세우긴 합니다만.

사실, 그래요. 남한테 종용할 이유가 없는 거에요. 웹표준의 여러 이점들, 그거 남들은 모르고 아는 사람들만 아는 채로 지나가도 상관없는 거에요. 오히려 남들이 모르고 우리만 알면 더 좋지요.
남들 밤새 야근하고 삽질하면서도 불편한 줄 조차 모를 때, 우리는 시간과 비용 절감하고 더 편하게 작업하면 우리 몸값도 올라가고 더 좋은 일이지요. 뭐라고 남한테 욕들어가며 그거 전도하고 다니고 싶겠어요. 천국은 우리만 가면 되는건데요. ^^;

그럼에도 불구하고 다른 이들에게 표준을 준수하라고 떠들고 다니는 이유는...

남들이 만든 사이트가 엉망이라서 정작 내가 써야할 때 불편하기 때문입니다.

간단한(?) 예를 들어볼까요.

RSS 리더기(웹 리더기 말구요...)나 요즘의 똑똑한 브라우저들은 사이트에 접속하면 알아서 이 사이트의 RSS를 추가할거냐고 물어봅니다. 그러니까, 귀찮게 "페이지내에서 RSS딱지 찾아서 오른쪽 클릭해서 주소복사해서 내 RSS 리더기에 새 RSS 추가선택해서 복사한 거 붙여넣"을 필요가 없는거지요.
이게 가능한 이유는 HTML문서의 head안에 들어있는 link 정보에 RSS주소가 포함되어 있기 때문이지요.
RSS딱지를 어디에 어떻게 이쁘게 붙일까를 고민하는 것 보다, head에 link 한 줄 추가해주는 게 사용자에게는 더 편리함을 주는 거에요.

트랙백의 경우도 마찬가지지요. Trackback RDF가 포함된 문서는 굳이 trackback 주소를 찾아서 복사해 붙이는 번거로운 짓 대신, 문서의 URL만 적어주면 자동으로 Trackback 주소를 찾아 줄 수 있어요. 국내 블로그에는 대부분 안되는 거지만 말이지요.

FF를 쓰고, WP나 MT로 블로깅을 하다보니 당장 위 두가지 기능이 안되는 국내 블로고스피어를 돌아다니는게 여간 불편한 게 아니지요.

위의 두가지 예 모두 시맨틱웹을 위한 온톨로지가 적용된 케이스라고 할 수 있어요.

시맨틱웹이 별게 아니에요. 사용자에게 좀 더 편리한 컴퓨팅을 하게 해주려는게 시맨틱웹의 궁극적 목적이잖아요. 무슨 미사여구를 붙이던 간에, 결국 목적은, 나 손하나 까딱 안하고 편하게 살고 싶다는 거지요.

다음같은 시나리오를 생각해보세요.

오랜만에 친구의 블로그에 방문했더니, 이 친구가 결혼한다고 청첩장을 올렸더라구요. 꼭 가야지 생각하면서 여러분은 어떻게 하시나요?

옛날같으면, 일단 이 페이지를 프린터로 출력하든가...
(그런데 꼭 출력한 인쇄물을 어디다 쳐박았는지 까먹곤 하지요.)

책상을 뒤적여서 포스트잇과 펜을 찾아 열심히 적어서 모니터에 붙여놓죠.
(여기 붙어 있던 포스트잇 누가 치웠어??)

조금 꼼꼼한 사람이라면 프랭클린 플래너를 열어 해당 날짜에 자세한 사항을 기록해두기도 하구요.
(그런데 움베르토 에코의 말처럼 해당하는 날짜에 다이어리를 펼쳐서 약속을 확인해봐야 한다는 걸 까먹으면 어떡하지요?)

나름 컴퓨터와 친하다는 사람은 아웃룩을 열고 일정에 자세한 내용을 타이핑하지요.
(oops! 오타! 18일을 28일로 잘못 쳤네!!)

만약 친구가 시맨틱웹을 지향하는 마이크로포맷 사용자라면, 자신의 결혼 청첩장을 hCalendar 형식으로 만들어 올렸을 겁니다. 자신의 결혼 후 바뀌는 주소는 hCard 형식으로 올렸을 테구요.
그럼 내가 할 일은 브라우저의 버튼 하나를 누르는 것 뿐. 그러면 자동으로 내 일정관리 프로그램에 결혼일정이 추가되고, 내 주소록에 친구의 주소가 신혼집 주소로 변경되지요.

별로 먼 훗날의 상상도 아닙니다. 당장 Windows Vista에 포함되는 기능이고, FireFox같은 브라우저의 확장플러그인으로 이미 있는 기능이지요.

그러니까, 저는 이렇게 게으르게 살고 싶은 거에요. 헌데 게으르게 살기에는 환경이 너무 안받쳐주니까 몸이 다는 거지요. 시맨틱웹은 감히 바라지도 못한 채 그 최소조건인 웹표준부터 이야기하고 있는 이유입니다. 말하자면, 내 한 몸 편하자고, 다른 이들에게 표준을 지키라고 떠드는 것인 셈이지요. ^_^

OpenID 프로토콜 시나리오

Role
SiteA : openID를 지원하는 Consumer 서비스. openID 소유자에게 서비스 이용을 허용한다.
SiteB : openID를 제공하는 Provider 서비스. 회원에게 openID를 발급하고 인증해준다.
홍길동 : SiteB에서 발급한 openID를 소지하고 있는 개인. 이 openID를 URLX에 적어두었다. SiteA의 서비스를 이용하고자 한다.
URLX : 홍길동의 개인(블로그 등) 페이지. openID가 적혀있다.

1. 홍길동은 SiteA에 방문한 후, openID를 지원함을 알고, 입력 Form에 자신의 openID URL인 URLX를 입력한다.

2. SiteA는 주어진 URLX에서 openID 정보를 찾는다.

3. SiteA는 홍길동의 openID가 SiteB의 것임을 알고, SiteB에 openID 인증을 요청한다.(SiteB로 리다이렉팅)

3-1. SiteB와의 연결에 문제가 발생할 경우, 해당 에러를 띄워 홍길동이 문제를 해결할 수 있도록 한다.

4. SiteB는 홍길동의 브라우저에, SiteA로부터의 인증요청이 있음을 알리는 페이지를 띄우고 인증허가여부를 묻는다.

4-1. SiteB는 홍길동이 본인임을 확인하기 위해 또다른 인증(예:로그인, 비밀번호입력)을 요구할 수 있다.

5. 홍길동은 SiteB로 하여금 SiteA에 자신의 정보를 가져가도록 허가한다.

5-1. 또는 홍길동은 SiteB로 하여금 SiteA로의 정보제공을 거부할 수도 있다. (부적절한 요청, 도용 가능성 등)

5-2. 또는 홍길동은 SiteB로 하여금 SiteA로의 정보를 제한적으로 제공하도록 선택할 수도 있다.

6. SiteB는 SiteA에 홍길동의 정보를 제공하고, SiteA의 페이지로 리다이렉팅한다.

6-1. 또는 SiteB는 SiteA에 홍길동의 정보를 제공할 수 없음을 알리고 SiteA의 페이지로 리다이렉팅한다.

7. SiteA는 SiteB로부터 받은 정보를 바탕으로 홍길동이 서비스를 사용할 수 있도록 처리해준다.

----

시나리오로 적으면 별 것도 아닌 것 같은데, 왜 이리 에러가 많은거야.. 징징.

블로그 방문자를 위한 UX

가정 1.
내 블로그를 방문하는 사람은 '나'에 대해 관심있기 때문이다.

가정 2.
'나'에게 좋은 것은, 내 블로그를 방문하는 사람에게도 좋다.

두가지 가정은 모두 사실이 아니다.

블로그 주인에게 블로그란, '자신'에 대한 표현수단이겠지만, 블로그를 방문하는 사람은 사실, 블로거 자체에는 관심이 없다.
그들이 관심있는 것은 Topic일뿐.

블로그 방문자들이 방문한 블로그의 모든 글을 읽기를 기대할 수도 없다. 애초에, 블로그란 형식 자체가 post단위의 archiving/logging이기 때문에, archive(또는 post)는 그 자체로 자기완결되어야만 한다.(물론 어려운 일이다.)

대개의 방문자는 링크를 타고 들어와 그 하나의 포스트를 읽고, 나가버린다. 아주 가끔, 댓글을 단다거나 하는 예외를 제외하곤.

그렇다면 방문자들을 위해 가장 필요한 인터페이스는 무엇일까?

두가지 층위에서 바라볼 수 있는데, inbound entry와 outbound exit 층위가 그것. 들어오는 방문자와, 나가는 방문자를 위한 인터페이스.

'블로그 내 검색'은 방문자를 가장 손쉽게 유혹할 수 있는 인터페이스라 할 수 있다. 방문자들은 카테고리 메뉴를 애용하지 않는다. 일일이 카테고리를 찍어보고, 포스트 목록에서 자신이 관심있어할 글 제목을 찾는 것은 매우 귀찮은 일이기 때문이다. 만약 방문자가 이 블로그에서 무언가 정보를 더 얻기를 원한다면 검색창에 바로 쳐넣고 결과가 뜨기를 기다릴 것이다.
따라서 블로그의 검색기능은 방문자를 위한 가장 훌륭한 인터페이스이다.

'관련글' - 수동으로 만들었거나, 혹은 FullText Search를 통한 자동 연결이거나 - 을 제공하는 것도 좋다. '연예뉴스'를 보러 들어온 방문자에게 관련된 다른 글들을 보여주는 것은 방문자들이 수고스럽게 일일이 뒤져보거나 검색할 필요를 줄여주는 친절한 인터페이스라 할 수 있다.

한가지 더 추가한다면,
referer를 통해, 검색엔진으로부터 유입된 방문자에게 자신이 보려고 했던 컨텐트를 바로 보여주는 것이다. 어떤 방문자가 검색엔진으로부터 'Ajax'라는 키워드를 찾아 블로그로 유입되었다면, 그는 아마도 내 블로그의 다른 'Ajax'관련 글에도 관심이 있을 것이다. 어쩌면, 검색엔진에 노출된 페이지보다, 숨겨진 페이지 쪽에 더 유용한 정보가 있을 수도 있다. 그런 경우 검색엔진으로부터 들어온 사용자에게 해당 엔트리들을 자동으로 보여준다면 얼마나 유용할까. (물론 이러한 기능들은 이미 많은 곳에서 구현되어 있고, 예를 들어 방금 말한 기능같은 것은 wp 플러그인으로 있어서 내 블로그에도 붙여놓았다. google에서 '불친절한 금자씨'로 검색해보시라.)

현재까지 블로그 인터페이스는 블로그 주인을 위한 자기만족적 성격이 강하다. 그러나 방문자로서는 스킨이 드래그 앤 드롭으로 변경되든, BGM이 있든 말든, 주인장 맘대로 태그로 뭘 붙이든 신경쓰지 않는다. (방문자 맘대로 리모콘 조작이 가능하다면야 또 모를까.) 그런 블로그 주인의 자기만족적 인터페이스보다는, 방문자를 위한 배려가 더 좋은 인터페이스일텐데, 이런 것들이 아직도 많이 미비한 듯 하여 아쉽다. (심지어 내 블로그 조차도.)

광고와 AJAX

Ajax가 유행이 되면서 너나 없이 Ajax를 이용한 사이트를 제작하게 된다. 그런데 곰곰히 생각해보면 Ajax의 이용은 현재까지 웹비즈니스모델의 가장 큰 부분을 차지하는 광고시장에 많은 영향을 주게 됨을 알 수 있다.

1. 광고 노출의 약화
특히 Ajax로 메인 컨텐트 부분을 처리하는 사이트들의 경우, page reloading이 일어나지 않기 때문에 reload 처리를 고려하지 않은 광고기법을 사용한다면 유저당 광고노출회수가 줄게 된다.
가령, 이전에는 사용자가 평균 10페이지의 액션을 취하고, 각 페이지마다 2개씩의 광고가 붙어 있던 사이트라면, 사용자당 20개의 광고를 노출시킬 수 있었다.
그러나 Ajax로 메인 컨텐트를 처리하면서 page reloading이 일어나지 않게 사이트를 변경하고 나면, 한 명의 사용자에게 고작 2개의 광고만 노출시킬 수 있을 뿐이다.

2. 광고 overloading - 트래픽 낭비
위와 같은 문제를 해결하기 위해 사용자의 Ajax 액션 때마다 광고를 같이 갱신하려한다면 이번에는 기껏 Ajax로 절약(?)한 트래픽을 낭비하게 된다. 액션 때마다 광고까지 포함해 전체페이지를 뒤엎는다면 Ajax를 쓸 필요가 없지 않은가.

3. 광고 changing - 트래픽 낭비
사용자의 액션과는 상관없이 일정주기로 광고를 갱신하는 방법을 쓸 수도 있다. 그러나 이 경우에도 사용자가 실제로 현재 페이지를 보고 있지 않는 동안에도 광고가 갱신되는 트래픽 낭비를 일으키며, 광고주에게 그 비용을 전가하는 단점이 있다.
너무 늦게 갱신된다면 Ajax를 쓰기 전보다 광고효과가 떨어지고, 너무 자주 갱신된다면 광고주에게 광고노출비용을 효과보다 더 부담하게 만든다.

4. PV와 UV, CV
무엇보다도, PV가 무색해지면서 광고단가에 대한 산정이 어려워지는 문제가 발생한다. UV가 아무리 많다해도 광고주들은 PV가 높은 매체를 선호하고, 광고 단가를 높게 지불한다.
그런데 Ajax를 사용하게 되면 사용자가 10분간 열심히 충성스럽게 사용한다 해도 해당 사용자의 PV는 1일 뿐이다. Ajax 서버측에 기록된 로그를 공개하면 사용자의 액션을 객관적으로(?) 증명할 수도 있겠지만, 광고주들이 매체의 공개된 로그를 신뢰할리 만무. 결국 컨텐트마다 추적코드를 삽입해서 ContentView를 측정하는 방법뿐인데, 이에 대해 신뢰할 수 있는 분석도구나 어필레이트 프로그램은 현재 없다. 서로 다른 형태와 위상을 가지고 있는 Content의 정량적 측정자체가 불가능하므로.
결국 광고서버에서 직접 노출횟수를 세는 방법뿐인데, 이를 위해 Ajax로딩때마다 광고를 갱신해야하면 다시 2번째 문제점으로 돌아갈 뿐.

5. 문맥광고 빠져나가기
현재까지는 가장 진보된 형태라고 불리우는 AdSense등의 문맥광고는 호출 당시의 HTML 컨텐트만을 문맥파악 대상으로 할 뿐, Ajax로 변경된 컨텐트는 인지하지 못한다.
컨텍스트와 일치하는 광고를 뽑아주는 것을 장점으로 하는 문맥광고가 그 역할을 하지 못한다면 과연 광고효과가 있을까?
이를 해결하기 위해서는 문맥광고에 컨텍스트 변경이 있을 때마다 push방식의 재갱신 요청을 처리하는 부분이 추가되거나(웹에서 push는 구현이 쉽지 않다.) 혹은, 문맥광고 자체에서 일정시간마다 pull방식으로 컨텍스트를 다시 읽어와 광고갱신여부를 선택하는 방법이 있을 수 있겠다. 그렇다고는 해도 이는 google등에서 해결해야할 문제이며, 매체측에서는 손가락만 빨고 있을 뿐.

...

개발자들이야 Ajax를 쓰는 것을 마다할 리 없고, 기획자들이야 왠지 좋아보여서라도 Ajax를 붙이겠지만...
사이트의 영업담당자들은 Ajax로 인해 변한 광고시장에 머리 좀 아플 듯.
근데, 이런 이야기를 회의때 안하나??

재미있는 현상들

조금 의외인 것은, 블로고스피어에 네이버의 이번 시즌 2 에피소드 1에 대한 칭찬들이 자자하다는 것.

이미 알고 있겠지만, 이 리모콘이란 용어와 기능은 사실상 1년도 전에 엠파스 블로그에서 써먹었던 것이고, 네이버에서 에피소드 1이라는 이름으로 내놓으면서 엠파스의 그것보다 기술적으로 특별히 진보적이거나 개념적으로 뭔가 더 창의적인 부분이 생긴 것도 아니다.

'따라했다'는 것 자체가 비난의 대상이 될 이유는 없겠지만, 그렇다고 '칭찬'의 이유가 된다는 것은 뭔가 이상하지 않은가?

남은 에피소드들 역시 모두 이미 다른 곳에서 했던 그대로 - 벤치마킹을 넘어서 사실상 표절이라고 표현해도 무방할 정도인데 왜 이렇게 다들 갑자기 호의적이 된 것일까?

역시 포장하는 법과 홍보하는 법이 한국IT 비즈니스의 핵심 역량이 되는 걸까?

거창한 수사를 붙이면 단지 인턴을 뽑을 뿐인데도 엄청난 경쟁률을 보이는 회사가 있는 한편, 쓸만한 인재하나 뽑기가 어려운 회사도 있고...
적절한 명예심과 자존심을 간질여주며 저렴한 가격으로 개발자풀을 돌리는 회사도 있고...
컨퍼런스나 세미나에 참석해서 말만으로 때우는 회사도 있고...

괜찮은 홍보이사를 잡는 쪽이 괜찮은 개발이사를 잡는 쪽보다 성공가능성이 더 높아지는 요즘. 재밌는걸?

표준을 간과한 댓가

"표준"이 강제력이 있는 것은 절대 아니지만, 표준을 지키는 것과 비켜가는 것은 시작은 비슷해도 종래에는 제법 그 사이가 벌어지게 됩니다. 표준이 표준인 이유는, 그게 더 많은 사람이 사용해서도 아니고, 더 편하기 때문도 아니지요. 표준이 표준인 이유는 "당위성"과 "보편성"에 있다고 봐야합니다. 즉, 표준인 이유는 "누가 해도 옳게 할 수 있기 때문에"라는 것이지요. (비표준이 틀렸다는 것은 아니고...)

표준을 지키는 것이 더 불편하거나 귀찮더라도 종국에는 더 이득입니다. 비록 초기에는 비표준쪽이 더 이익인 것처럼 보이긴 해도 말이지요.

사례 1: 올블로그의 태그 수집
RSS의 content:encoded는 기본이 아닙니다. 또한 description은 entity처리된 plain text만 사용하도록 되어있지요. 이것을 무시하고, RSS에서 tag정보를 강제로 넣기 위해 a 태그를 이용하려다 보니, content:encoded를 조장(?)하거나, description에 entity처리되지 않은 a 태그를 포함하도록 유도하는 경우가 있습니다.
애초에, notifying 이라는 RSS의 속성을 생각한다면, 컨텐트 안의 tag 정보가 필요하다면, 갱신된 RSS의 item의 url정보를 참조하여 웹페이지를 크롤링해서 필요한 정보(여기에서는 tag)를 다시 가져오는 것이 맞습니다. tag뿐만이 아니죠. image나 멀티미디어의 경우에도 마찬가지. 그런 정보를 모으기 위해 RSS에 해당데이터를 추가하게 하는 것이 아니라, RSS는 표준대로 두고 봇이 해당 웹페이지에 정보를 수집하러 다녀오는 것이 맞습니다.

사실, 이건 올블의 잘못이 아니죠. RSS를 이상한 형태로 제공하고 있는 많은 블로그 메이커들이 문제의 시발점이긴 합니다. 그러나 비표준적인 스펙에 의존하는 서비스는, 예외를 위한 예외를 처리하다보면 점점 더 표준에서 멀어지게 되지요.

사례 2: TT의 태그 출력
애초에 tag플러그인이나 스킨 제작자들의 문제였겠습니다만. 최소한 tag라는 표현을 쓰고 상식적인(아, 그냥 우리끼리의 '상식'은 말구요.) 용법을 사용하려면 microformat의 tag 용법 정도는 준수했어야했을 것입니다.
물론, 다중카테고리와 tag자체를 구별할 수 없는 현재의 용도하에서 TT쪽에서 스킨제작자나 플러그인 제작자에게 표준을 강제하는 것은 어려운 일이었겠습니다만... 어쨌거나 이 역시 microformat - tag라는 표준을 간과한 결과겠지요.
덕분에, tag라는 이름을 붙인 기능을 쓰면서도 실질적으로 tag가 아닐 뿐더러, 그 문제점을 스킨이나 플러그인 제작자에게 떠넘긴 셈이 되었습니다. 애초에 스킨이나 플러그인 제작자보다 메이커가 더 이런 문제에 대해 잘 알고 책임을 져야할텐데, 너무 자유도를 강조한 나머지 메이커보다 문외한일 3rd party들에게 맡기는 것은 조금 안일하지 않나 싶습니다. MT나 WP처럼 아예 tag는 원래기능에는 포함되지 않음을 확실히 했어야했지요. 현재 tag는 TT에서는 책임지지 않으면서도 TT의 핵심기능 중의 하나인 셈이니 이러한 부분에서 문제가 발생하면 책임소재가 애매해지겠습니다.

각각의 사례는 사실 단독적으로는 별 문제가 없었겠습니다만, 두가지 비표준 사례가 만나다보니 문제가 커지고 서로가 잘못했다는 감정싸움이 되는 듯 하더군요. 뭐랄까, 이전부터 RSS나 microformat에 관해 이야기 해왔던 입장에서 본다면 안타깝다고나 할까요.

표준이 표준이 되기 위해서는 나름 많은 고민과 많은 시행착오를 거쳐야만 합니다. 최소한 한두명의 개발자나 한두개의 기업에서 나름 뚝딱해서 만들어지는 것은 아니라는 것이지요. 표준이라는 딱지를 얻었을 때에는 그만한 이유와 까닭이 있기 때문입니다. 눈 앞의 이익에 혹해 비표준을 용인하는 것은 우선 경계해야할 일이겠습니다.

추가:바람직한 해결책
1. TT에서 사용하는 기능이, 'tag'라면 TT측에서 직접 microformat을 준수할 수 있도록 책임진다. 단, RSS에 추가할 필요는 없다.
1-1. 'tag'가 아니라 멀티카테고리에 불과하다면 지금까지 처럼 3rd party의 플러그인이나 스킨제작자에게 맡긴다.
2. 올블에서는 RSS에 담긴 내용만으로 정보를 수집하는 대신, RSS로 notifying된 url을 찾아가 screen scrapping을 통해 필요한 정보들을 획득해간다.

생각해볼 문제 :
screen scrapping은 죄악인가? 그렇지 않다.
정상적인 RSS 스펙을 해석한다면, 정확히 '새 글이 등록되거나 수정되었을 때에만' 해당 페이지의 screen scrapping을 시도하게 할 수 있다. 원래 RSS의 스펙 자체가, RSS를 컨텐트의 용도로 사용함이 아니라, URL에 대한 notifying용임을 상기하자. 따라서 해당 URL에 대한 정보가 필요하다면 필연적으로 machine-crawling이 필수이며, 이에 대한 방문빈도 등을 제어하기 위한 규격이 이미 RSS내에 존재하고 있다.
단지 봇이 긁어가는 것에 대해 알레르기를 느낀다는 것은, 글쎄, 사용자가 그리 느낀다는데 뭐라 말하기는 그렇지만 잘못된 생각일 뿐이다. 장차 사용될 마이크로포맷이니 시맨틱웹이니 하는 것들은 로봇과 스크래퍼 들을 가정하지 않으면 애초에 성립되지 않는 개념들이다. 그 때가 되면 정말 웹페이지를 샅샅이 뒤지고 긁어서 조그마한 의미 하나라도 기계들이 긁어갈 차에, 봇이 긁어가는 것이 싫어서... 라는 핑계는 러다이트의 재현일 뿐.
무분별하게 긁어가는 것은 트래픽상 문제가 될 수 있긴 하지만, 그걸 막기 위해 RSS에 해당하는 스펙이 있지 않던가. 그것만 따라줘도 충분히 트래픽에 대한 문제는 해결된다.

리모콘 달린 블로그

그런데, 블로그 리모콘 이란 건 엠파스에서 벌써 일년전에 내놓았던 기능 아니었나?
네이버가 대대적으로 광고하면서 내놓기에는 좀 부끄러운 것 아닌지?

지금 보니 기능도 컨셉도 엠파스 것과 완전 동일, 이정도면 같은 개발자... 또는 같은 기획자가 참여하고 있는 것이라는 의심이...

아무튼 간에. Attention의 차이가 네이버와 엠파스가 확연할 테니, 엠파스로서는 또 손가락만 빨면서 억울함을 곱씹을지도.
(그렇다 해도, SK에 인수된 엠파스가 진심으로 억울해 할지는 미지수. 별 상관없으려나?)