트랙백 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플러즌이다. 나는 도대체 여기에 어떤 집단지성을 발견할 수 있는지 알 수가 없다. 집단바보놀이만 가득한 느낌이다.