OpenID 자료

저한테 openID 자료가 없냐고 메일로 여쭤보신 분이 계시던데...
저도 없습니다... 를 떠나서 정말 자료 찾기가 너무 힘들어요.

일단 개발하시는 분들은
http://www.lifewiki.net/openid/OpenIDLibraries
에 가시면 본인의 사용언어에 맞는 것으로 개발라이브러리 코드를 구하실 수 있습니다.

몇가지 용어를 이해하시면 더 쉽게 접근하실 수 있으실 겁니다.

Consumer : OpenID로 로그인, 가입, 정보가져오기... 등을 수행하는 서비스/사이트 를 말합니다. 다른 openID 사용자들을 자신의 서비스에 참여시키기 원하시는 분들은 Consumer관련된 코드를 활용하시면 됩니다.
Provider : OpenID를 사용자에게 발급해주고, Consumer의 요청이 있을 때 그에 대한 정보를 제공해주는 서비스/사이트를 말합니다.

반드시 하나의 서비스, 사이트에서 Provider와 Consumer 두가지 역할을 다 할 필요가 없습니다. (OpenID에 대해 좀 더 연구해보면 두가지 역할을 다 떠맡는게 좀 바보스러운 일임을 아시게 될겁니다.) 대개의 경우는 Consumer부분만 연구하시면 충분할 겁니다.

개인적으로는 OpenID를 SSO(Single Sign On) 대용으로 사용하는 것은 재고할 필요가 있다고 봅니다. 한국에서의 RSS의 오용(?)과 마찬가지로 주의깊게 준비하지 않고 OpenID 대응 서비스를 열 경우, 개인정보보호문제에 대해 상당히 시끄러울테니까요.

아무 생각없는 인터페이스

StandardMag에 올라온 질문에 대한 답변을 정리해봅니다.

관습적인 인터페이스는 사용자에게 익숙함을 주긴 하지만, 관습에 매몰되어 매너리즘에 빠지게 되는 경우도 많지요.
회원가입페이지 제작시 가장 쉽게 보이는 매너리즘 인터페이스 두가지에 대해 이야기해보렵니다.

1. 3칸으로 나뉘어진 전화번호.
사실 핸드폰 번호 따로 집전화 번호 따로 입력받는 것도 무의미하긴 하지만.('기분존'같은 서비스도 나온 마당에 말이지요.)
습관적으로 우리는 전화번호 입력 필드를 3칸으로 나누어 놓습니다.
이것은 결코 UX적으로 좋은 인터페이스라 할 수 없습니다.

우선 손이 많이 갑니다.
016 타이핑하고, tab키 누르고, 9447 타이핑하고, tab키 누르고, 8022 타이핑하고.
tab키를 이용할 줄 아는 사용자라면 이정도입니다만, 나이드신 분들은 필드간 이동을 하기 위해 다시 마우스를 잡고 해당 필드를 클릭해야 합니다.
이러다보니 이 불편함을 없애보자고 JavaScript를 써서 앞에 세자리, 입력하면 자동으로 다음 필드로 포커스를 옮겨보기도 하지만, 이러면 원래 tab키 이동이라는 표준 인터페이스에 익숙한 사용자에게는 오히려 잘못된 입력을 유도하게 됩니다.
게다가 이왕 JavaScript를 사용하는 김에 입력값 검사까지 해버립니다. 마지막 필드가 네자리 숫자가 아니면 틀렸다고 한다거나...
그러면 이제는 우리 회사 대표번호는 02-2424-825로 알려져 있는데, 굳이 02-242-4825로 입력해야만 합니다. 신경쓰지 않으면 타이핑 미스 생기지요.
그나마 무슨 이유로든간에 JavaScript 사용이 불가능하면 입력도 먹통이 되는 경우까지 생기기도 하지요.

애초에 그냥 한칸의 입력필드에 022424825로 입력하든, 02)2424-825로 입력하든, 02 2424 825 로 입력하든 사용자 맘대로 입력하게 해도 충분할 일입니다.
일단 그렇게 Form을 submit한 후, 간단한 정규식으로 전화번호를 추출하고, 그것이 전화번호 형식에 맞는지 안맞는지 판단하는 것은 어려운 일이 아니죠. 만약 전화번호가 틀린 포맷이라면 다시 이전 입력Form페이지로 돌리고 에러메시지('전화번호가 틀렸습니다. 다시 입력해주세요.')를 보이면 될 일입니다.

이전 페이지로 돌아가는 게 사용자에게 오히려 번거롭지 않냐구요?
전화번호 입력이 틀리는 경우는 거의 없습니다. 눈감고도 입력할 수 있는게 전화번호라구요. 오히려 세칸에 나누어 적고 JavaScript를 따라 널뛰는 조작보다는 훨씬 더 정확하게 입력할 수 있습니다.
물론 JavaScript가 안되는 환경에서도 문제없이 사용할 수 있구요.

2. 우편번호 팝업
도대체 왜 우편번호와 정확한 주소를 수집해가는지 모르겠습니다. 그거 가지고 인구센서스 통계내나요? 우리 사이트의 주 사용자는 서울에 살고 있어.. 같은?
그런 CRM 자료를 제대로 분석해서 사용하는 기획자나 운영자가 있는지는 모르겠습니다. 아마 오히려 접속 IP 위치를 통계내는 쪽이 좀 더 정확할텐데 말이지요.

우편번호나 주소를 수집하는 이유가 상품 배송이나 우편물 발송때문이라고도 하는데, 실제로 이런 서비스를 할 때에는 사용자에게 정확한 배송주소를 다시 물어보는 것이 정석입니다. 대부분의 업체에서도 그렇게 하고 있구요.
어쨌거나 그래서 정확한 우편번호나 주소가 필요하다 치더라도...

그래도 우편번호 팝업 입력은 아닙니다.

그럼 대안이 있을까요?

제가 전에 살던 집주소는...
"서울특별시 서대문구 대현동 56-38번지 5층"
입니다.

아무리 타이핑이 느린 분이더라도, 자기 집 주소를 한 줄에 입력하는 건 "버튼 눌러 팝업 뜨고 동이름 넣고 검색하고 후보들 나오면 목록에서 위아래로 오르내리며 찾아 선택하고 팝업이 닫긴 후 부모창의 다음 필드에서 번지이하 주소를 다시 입력하는 것"보다는 빠릅니다. 물론 훨씬 더 직관적이고 쉽기도 하지요.

주소가 정확한지는 어떻게 아냐구요? 우편번호는 어떻게 하냐구요?

저 위에 쓴 주소를 정규식 돌려서 도/시, 군/구, 읍/동 을 뽑아내는 것은 일도 아니지요. 그리고 그걸로 DB에서 매치되는 우편번호를 찾아내는 것도 어렵지 않지요. 굳이 AJAX같은 것을 쓰지 않더라도, 그냥 Form Submit한 후 서버사이드에서 매치시켜보고, 정확하지 않거나 매치되는 후보가 너무 많다면 다시 이전 페이지로 돌려 재입력 받게 하거나, 매치되는 후보들 중에서 선택하게 하면 됩니다.

JavaScript도 필요없고, 정상적인 사용자들에게 불편함도 없지요.

생각해보면 이런 관습적인 멍청한 인터페이스야 말로 UX의 가장 큰 적입니다. JavaScript나 AJAX가 없어서 사용성이 제한되는 게 아니라, 단지 상상력과 배려심이 없는 기획자 때문이지요. 아, 어쩌면 정규식을 다룰 줄 모르는 개발자 때문일 수도 있긴 하겠습니다.

Worst Mistakes

이것저것 뒤지던 중에 우연히 보게 된 imakemistakes.com. 한 십분간 정신없이 웃었다.
다음은 worst mistakes 중에서 몇개 발췌.

* 그녀가 '사랑해'라고 말했을 때 웃어버렸어.
* 다리미를 놔두고 일하러 가는 바람에 아파트를 홀랑 태워먹었어.
* 헤어진 여자친구와 기회가 있었을 때 했어야 했는데...
* 내 아이팟 미니에 리눅스를 설치해보려 했어!

영예의 1위 (?)는,
"나 아직도 이 사이트를 보는 중이야."

OpenID 만지작거리기

php로 openID 1.1 spec대로 프로그래밍해서 만지작거리고 있는데, 어떤 consumer에서는 제대로 인증이 되고, 어떤 consumer에서는 취소가 된다. 도대체 이유가 뭘까... 풀리지 않는 수수께끼. 로그를 읽어봐도 별거 없는데.
이런 오픈 규격을 내놓는 측에서는 이것저것 테스트해볼 수 있는 sandbox framework을 제공해야하지 않을까? 아니면 나만 못찾고 있는 걸까?
어쨌거나 일단은 openID 구현이 가능했다는 걸로 만족.

아, 한가지 더 풀리지 않는 수수께끼. provider와 account가 진짜로 reliable한지는 어떻게 알아내지? malicious한 provider라면 악의적인 목표로 fake user를 만들어 인증을 시도한다면 그것을 어떻게 구분하는거지? 도대체 알 수가 없네...

한국에는 마땅히 물어볼 만한 사람도 모르겠고. 끄응. 에라 모르겠다. 일단 gogo..

올블로그 프레임에 대한 마지막 부탁

* 이글을 마지막으로, 올블의 프레임에 대해 또 포스팅하는 일이 없었으면 합니다. 공연히 올블에 대해 나쁜 감정이 있는 것처럼 비추이는 것도 싫고, 실제로 개선되어서 불편함이 없어졌으면 하고 바라기 때문입니다.

1. 올블 프레임, 저작권.
파란의 블로그 스페이스에 대해 논란이 많았는데, 실상 그 메커니즘 자체는 올블이라고 크게 다를 바 없습니다. (지난 포스팅 참조)
개인이 자신의 블로그에 대해 올블 프레임을 다는 것을 허용했다한들 타인의 웹사이트에까지 그 프레임을 따라가게 하는 것을 허용했을리는 없습니다.
애초에, 아무리 올블이 블로거들에게 친화적이고 좋은 서비스라 하여도 그렇게 쉽게 자신의 컨텐츠를 특정 서비스의 프레임안에 가둬두어도 좋다고 허가하는 개인들도 선듯 이해되지 않기는 합니다.

2. 실질적인 불편함
굳이 올블 프레임에 대해 문제를 제기하는 이유는 저작권 등의 남의 다리 긁는 이유때문만이 아니라, 실제로 웹서핑이 불편해지기 때문입니다.

1) 실제 주소를 가립니다.
제가 링크하고 싶은 주소는, 북마크하고 싶은 주소는, machine-feed로 쓰고 싶은 주소는 link.allblog.net이 아닙니다. 아마 여러분들도 그럴 겁니다.
헌데, google에서 "link.allblog.net" (따옴표 포함)으로 검색해보세요. 저 검색결과에 자신의 블로그 주소가 link.allblog.net으로 걸린 블로그 주인들은 자신들의 링크가 저런 식으로 유통되도 좋다는 것을 자각하고 프레임을 허가했을까요?
어쨌거나, 수고스럽지만 클릭한번이면 프레임을 없앨 수 있으니 그 정도 수고쯤은 감수해야 할까요?

2) 프레임은 따라다닌다.
링크마다 새창띄우기(접근성때문에 하지 말라는), JavaScript로 최상위에서 리프레쉬하기(복잡하게 프레임과 AJAX로 얽혀있는 N,D모 블로그)인 블로그들도 있습니다만, 고지식하게 표준문법만으로 만들어진 블로그들이 있습니다. 이런 블로그들은 올블 프레임이 한번 뜨고 나면, 그 블로그 안에는 물론, 바깥으로 연결되는 다른 페이지까지 프레임은 따라다니게 됩니다. 웹서핑의 본질대로 링크따라 흘러다니다가, 아, 이 페이지 적어둬야지 하고 URL주소창을 보면 link.allblog.net/... 아까 출발했던 페이지. 이제 와서 프레임닫기 눌러봤자 최초 출발 페이지로 돌아가버리게 됩니다. 한번 이런 일을 겪으면 심신이 다 피폐해지죠.

3) 로그인안하면 무용지물...
어차피 올블 프레임의 많은 기능들은 로그인하지 않은 사용자에게는 무용지물입니다. 강제로 로그인을 유도해서 추천과 이슈의 활성화를 노리는지는 모르겠으나 어차피 대부분의 사용자는 로그인하지 않은 상태로 들어와, 로그인하지 않은 채로 올블을 이용하고, 앞으로도 계속 그럴 겁니다.
애초에, 로그인과 버튼 클릭이라는 사용자의 의도적 액션을 요구하는 자체가 집단지성이 될리도 없거니와, 그런 시도를 모든 사용자에게 요구한다 해서 달성될 리도 없겠지요.
애당초 올블 이용자가 올블 가입자 뿐일리도 없고, 그런 식으로 제한을 둔다는 건 오히려 전략 미스에 가까운 생각일테구요.
하여간에, 저같은 비로그인 사용자한테는 올블 프레임은 백해무익할 뿐. 차라리 자발적이고 적극적인 로그인 사용자한테만 올블 프레임을 보이게 한다거나,
혹은 올블 페이지에서 각 블로그로 창이 뜰 때 링크를 두개 줘서(하나는 작은 아이콘 형태라 하더라도) 프레임이 있는 창과 프레임이 없는 창을 선택할 수 있는 수단이라도 제공해주면 오죽 좋겠습니까.

올블에서 낚시성 포스트라도 하나 낚여볼라쳐도, 제일 먼저 하는 건 창이 뜨자마자 올블 프레임 닫기 행위입니다. 가끔 제대로 닫겨지지도 않는 프레임의 닫기 버튼을 클릭하기 위해 트랙패드를 긁어대고 있노라면 이 무슨 무의미한 짓을 반복하고 있나하는 회의감만 드네요.

부디... 로그인한 사용자에게만, 추천 버튼 누르겠다는 열의있는 사용자에게만 올블 프레임을 보여주면 안되겠습니까?

5W1H

"누가", "언제", "어디서", "무엇을", "왜", "어떻게" 를 분석해낼 수 있다면 시맨틱/온톨로지는 그다지 뜬구름 같은 이야기가 아닐 수도 있다.

• who : openID, hCard, VCARD, hResume, Identification 2.0, Reputation, Relationship, XFN ...
• when : VEVENT, hCalendar, iCalendar, dc:datetime...
• where : VEVENT, address, long-lat, map ...
• what : URI, ISBN, bar-code, hReview, vocabulary, collabulary ...
• why : ???
• how : ???

why와 how는 irregular text-context이지만, 나머지는 regularized unique-context로 구현 가능. 네가지는 객관적이지만, 두가지는 주관적. 따라서 사용자에게 두가지 가려운 부분을 손쉽게 긁어줄 수 있는 긁개만 제공해준다면 되는 것 아닌가? 결국은 인터페이스의 문제?

ps. 생각해보니, why와 how가 해당하는 서비스의 개성이 될 수 있겠다. 흠흠. just a memo.

딴죽

어쩌다 보니 이 블로그는 "딴지전문" 블로그가 된 것 같네요.
앞으로는 딴지는 좀 줄이고, tagline에 적혀있는 대로 web technical issue에 대해 집중할 생각입니다.
(그런데, "Issue"에 대해 이야기 하다보니 자꾸 딴지로 흐르게 되는군요. 반성.)
- 불친절하다는 소리를 몇번 듣다보니 생긴 노파심 포스팅
* 딴지는 딴죽의 잘못된 말이라지요.

파란과 올블로그

그냥 끄적끄적.

1) 주소창 바꾸는 건 파란이나 올블이나 그게 그거 아닌가?

2) 프레임안에 가두는 건 파란이나 올블이나 똑같은 거 아닌가? 한쪽은 프레임처럼 생기지 않아서? 한쪽은 없애는 버튼이 없어서?

3) 추천 등의 기능으로 마치 자사 서비스인 것 처럼 하는 것도 파란이나 올블이나 똑같은 거 아닌가?

4) RSS를 본인이 등록하건 타인이 등록하건 그게 무슨 상관인가? 그럼 hanrss같은 웹RSS도 주인장이 직접 등록을 해야하고, 개인이 만들어 쓰는 RSS 리더기도 블로그 주인들이 와서 등록해줘야 하는건가?

---

이 글은 파란을 옹호하는 글은 아니다. 파란의 블로그스페이스 서비스는 문제가 좀 있긴 한데 -

1. 무분별하게 이미지등을 직접 링크하고 있어서 트래픽 누수를 일으키고,
2. (robot.txt 같은)규칙을 지키지 않고,
3. 서비스 운영이 세련되지 못하다는 점.
4. 그리고 지금 없어졌지만 무책임한 스크랩기능.

그정도를 제외하고는 글쎄....

처음 네오비스님의 문제제기는 그런가보다 했는데, 그 후에 들불처럼 퍼지는 파란 때리기는 뭐랄까, 촛점을 일탈하고 있는 듯 하다.
하늘보고 침뱉는다고나 할 정도로, 문제점이라고 짚는 게 그들이 사용하는 올블로그에도 해당되는걸...

저 위에 질문으로 적어놓은 것들은 진짜로, 1) ~ 3)은 모두 올블로그도 저작권법을 매우 '심각하게' 위반하고 있는 사항들이다. 다만, 파란과 다른 점은, 사용자들에게 '허가'를 받았다는 점.

그런데 올블로그 사용자들이 가입시 이것저것 과연 제대로 알고 '허가'를 한걸까? 그리고 과연 그 '허가'로 충분한 것일까?
예를 들어 자신은 올블로그에 가입하면서 올블로그 프레임(?)을 허용했으니, 자신의 블로그에 올블프레임이 떠도 괜찮다고 생각할 지도 모르겠지만,
그렇게 올블을 타고 들어온 사람들이 그 블로그에 링크되어있는 다른 URL을 타고 갈 때, 올블프레임도 따라 간다는 걸 알까? 다행히 목적지도 올블에 가입한 블로거고 그 역시 올블프레임을 허용했다면 모를까, 전혀 관계없는 다른 외부 URL로 갈 때 올블프레임도 따라온다는 것, 그래서 전혀 상관없는 제 3자의 홈페이지가 올블주소 아래에 띄어지고 있다는 것... 그 제 3 자의 저작권을 결과적으로 올블이 침해하는데 방조하고 있다는 사실을 인지하고는 있을까?

* 직접적인 예를 들기 위해 올블을 들먹였으나, 사실 콜콜넷이니 윙버스 같은 서비스들 모두 이 저작권 문제에서 전혀 자유롭지 못함을 노파심에 밝혀둔다.

RSS를 모아서 서비스하는 그 자체에 문제가 있는가? 그럴지도 모른다. 어쩌면 이미 사라진 컨텐트를 가리키는 아이템이 있을지도 모르고, 아이템 url을 참고로 본문을 직접 가져왔을 수도 있다.(봇이 안다닌다니 그건 아닐지도.) 어쨌거나 심지어 본문 자체가 검색엔진에 노출된다 해서 우리가 저작권에 대해 뭐라하지 않는 것처럼, RSS역시 RSS에 전문을 싣지 않는다해도 아이템URL을 통해 봇을 보내 본문을 긁어왔다면 그냥 검색이라 우기고 차라리 뭐라하지도 못했을 텐데... 파란 기획자는 좀 반성을 해야하겠다.
검색엔진의 룰을 준수하지 못하고, 서비스 운영이 미숙한 점은 욕먹어 지당하지만 그외에는 흠...

개인이 모은 RSS를 타인에게 제공하는 게 문제일까? hanrss의 '관련 RSS'도 개인이 모은 RSS를 프로파일링해서 타인에게 필터링해 보여주는 서비스인데, 과연 껍데기의 문제인 것인가?

왜이렇게 RSS는 타국에 와서 생고생을 해야하는가. RSS가 이정도이니 hCard나 openID같은 서비스라도 할라치면 아주 볼만하겠구나.

AJAX 응용을 위한 몇가지 Tip

1. Connection을 줄여라.
10초마다 랜덤한 이미지를 DB에서 뽑아와 화면에 뿌려주는 AJAX 루틴이 있다고 하자.

언뜻 보기에 특별한 문제없이 쉽게 구현될 것처럼 보이지만, 실제로는 DB와 HTTP 서버에 꽤 부담을 주게 된다. 실제로 가장 많은 리소스와 시간이 소요되는 것은 바로 이 커넥션 할당부분이다. 알고리즘은 최적화시키고, 데이터는 인덱싱이라도 할 수 있지만, 커넥션 자체에 소요되는 시간은 어떻게도 줄일 수가 없다.

HTTP 프로토콜은 이른바 상태유지가 불가능하다. 그래서 DB 커넥션을 계속 유지하는 것은 어렵다. 물론 EJB등에서 상태세션빈이라든가, 혹은 PHP에서라도 커넥션 유지가 아주 불가능한 것만은 아니다. 다만, 이렇게 커넥션 리소스를 물고 있게 되면 서버자원이 낭비되고 그 결과 다른 접속자의 접속시도가 제한되게 된다. 따라서 대개의 HTTP통신은 Request를 하고 Response가 돌아오는 짧은 시간동안만 커넥션을 물고 있게 한다.

이런 관계로, 10초마다 AJAX를 이용해 이미지를 뽑아오는 기법같은 건, 평균적으로 한 사용자가 1분간 페이지를 유지한다고 하면, AJAX를 쓰지 않았을 때보다 상대적으로 600%의 커넥션 소모를 일으키게 된다.
사장님께 가서 서버와 회선이 모자라니 600% 증설해주세요.. 라고 하자.

권고사직되고 싶지는 않고, 10초마다 랜덤이미지를 1분간 보여주고 싶다면...
AJAX를 쓰지말고 그냥 일반 페이지를 request할 때, 한번의 커넥션 상태에서 6장의 이미지를 랜덤하게 뽑아 JavaScript 혹은 JSON 혹은 숨겨둔 HTML...로 보낸 후, 그냥 JavaScript로 10초마다 로테이팅 시키자.
1분이 모자른 듯 싶다면 아예 10분어치를 한번에 쿼리해서 가져오는 것이 9분 어치가 안쓰여도 AJAX를 쓰는 것보다는 더 이득이다.

2. 메인 컨텐트에 AJAX를 쓰지마라.
카테고리나 메뉴나 광고에 AJAX를 쓰는 것 까지는 좋다.
그러나 메인 컨텐트에 AJAX를 쓰지 말 것.
JavaScript가 disable한 상태이거나 회선불량이라던가, Script Error라든가... 이런 경우 컨텐트가 없는 빈 페이지만 덩그마니 남게 된다.
메뉴나, 사이드바같은 건 어찌되도 좋아, 안보여도 좋고. 허나 메인 컨텐트는 안보이면 안되지...
이 페이지의 핵심기능이 최신글목록이라면, 최신글목록 만은 AJAX를 쓰지 말라는 뜻.
꼭, 반드시 AJAX를 써야겠다면, 그 경우에도 아무것도 없는 빈 컨텐트를 AJAX로 가져와서 채우지 말고, 일단 서버스크립트로 최초 컨텐트는 채워둔 후에, 필요에 따라 AJAX로 변경하는 것은 봐줄만 하겠다. 그래야 AJAX가 안되어도 빈 페이지를 보고 있는 일은 없을 테니까.

3. 크리티컬하지 않은 것만 AJAX를 쓰자.
일단 AJAX를 쓴다 함은, 대개, 현재 보고 있는 페이지와 URL이 매칭되지 않는다는 뜻. 리마커블하게 링크가 걸려야하는 컨텐트, 페이지들은 AJAX를 자제함이 좋다.
그럼 어떤 경우가 AJAX이용에 적당할까?
검색결과페이지는 상대적으로 URL이 덜 중요한 페이지이다. 내용이 수시로 바뀌는 메인 인덱스 페이지라면 AJAX를 써도 크게 상관은 없겠다.
또 덜 중요한 기능- 커멘트 작성같은 -들은 URL과 상관없기 때문에 AJAX로 구현해도 무방하겠다.

4. DB 쿼리보다는 스태틱 빌드를 노려라.
어떤 컨텐트 데이터가 수정, 삭제는 거의 일어나지 않되 추가는 종종 일어나고, 조회는 그 몇배로 자주 이루어지고 있다면, 이에 대한 view를 AJAX로 직접 컨트롤하려는 것은 매우 어리석은 일이다.
이런 경우에는 스태틱 빌드를 쓰자.
데이터가 변경될 때마다 해당 컨텐트를 파일로 만들고(HTML이든, XML이든, JSON이든...) AJAX로는 이 빌드된 파일을 접근해서 읽어오는 쪽이 훨씬 효율적이다.
왜냐하면,
이렇게 빌드된 파일은 다른 사용자들도 동일한 쿼리를 위해 DB커넥션을 할 필요가 없이 바로 그 결과를 파일로 공유할 수 있기 때문이고,
AJAX에 장애가 생겨도 이 파일 주소를 페이지안에 link 나 longdesc로 명기해두었다면 접근성등에 문제가 없어지며,
파일을 읽는 속도가 DB에 연결하는 속도보다는 훨씬 더 빠르기 때문이다.

만약 쿼리가 여러 종류이되 많은 사용자 사이에서 반복되어 나오는 종류라면 최초 쿼리 시에만 DB에서 조회한 후, 그 결과를 파일로 만들고 그 파일이름을 쿼리의 해쉬값을 이용해서 관리하면 여러종류의 쿼리에도 대응할 수 있겠다. 물론 이 경우에는 사용자 맞춤 컨텐트 같은 것에는 약간 힘들 수도 있긴 하다.

5.로드밸런싱(?)
현실적으로 비싼 로드밸런싱 장비를 사용하지 못한다면, 혹은 여러대의 웹서버를 돌릴 수 없다면...
(그런데, 대부분의 웹서비스는, 사실 왠만한 리눅스머신가지고도 훌륭히 퍼포먼스를 낼 수 있다. 이런 커넥션의 낭비만 아니라면...)
간단하게는 서브도메인을 이용해서 일시적으로 커넥션을 늘려서 응답을 빠르게 할 수도 있겠다.
예를 들어 이미지는 image1.sample.com, image2.sample.com, image3.sample.com (내부적으로는 모두 같은 이미지서버)에서 번갈아가며 가져오도록 HTML코드를 작성하고 (그럴려면 일반적인 막코딩으로는 힘들고 별도로 템플릿생성엔진같은 것을 써야하겠다.), ajax call같은 경우에도 ajaxserver1.sample.com, ajaxserver2.sample.com, ajaxserver3.sample.com(역시 내부적으로는 같은 서버)로 분산 호출하게 되면 커넥션이 늘어나게 되어 응답이 빠르다.
그러나 이 방법은 서버의 리소스 사용량을 늘리게 되고, 사용자가 워낙 많은 경우에는 그 시간동안 다른 사용자의 커넥션이 제한되므로 꼭 좋은 방법이라고만은 할 수 없겠다.

AJAX의 오남용을 보고 있자니, Anti-AJAXian이 될 것 만 같은 이 찜찜함...

가변폭 레이아웃 전략

최근 liquid 또는 elastic design 에 대한 관심들이 많아지고 있는데요,
개인적으로 liquid나 elastic design의 유용함을 인정하면서도 실제 현장에서 쓰기에는 힘들지 않나.. 하는 생각을 하고 있었습니다.

여러가지 이유가 있겠으나, 하나의 디자인으로 여러 종류의 디바이스 혹은 브라우저 크기에 맞춰 유동적으로 변하는게 그리 쉽지많은 않거든요. 아무리 빗겨흘리고 늘렸다 줄였다 해도 고정된 디자인의 한계를 벗어나기는 어렵더군요.

그런 생각을 하면서 요즘의 liquid, elastic 유행(?)에 한발 물러서 있던 차에...

오래간만에 ALA에 괜찮은 기법이 하나 소개되었습니다. liquid 또는 elastic 의 한계를 뛰어넘은, 가변폭에 맞춘 디자인 변경입니다.

간단하게 js 파일을 하나 추가함으로써 어떠한 환경에서도 보기 좋은 웹페이지를 만들어낼 수 있겠더군요. 물론 주의깊게 작성을 하긴 해야겠습니다만.

그동안 어떻게 CSS를 조작해서 가변폭 레이아웃을 만족스럽게 표현할까 고민했었는데 좋은 참고가 될 듯 해서 소개합니다.

샘플 1, 샘플 2 (모든 링크는 Shift+Click 으로 새창에서 뜹니다.)

liquid 디자인과 zoom 디자인을 넘어서 adaptive 레이아웃이라는 선언도 곱씹어볼만 한데다, 샘플 2에 Tab 디자인은 영감을 팍팍주는 인터페이스네요. 그동안 ALA에 올라오는 글들이 영양가가 좀 떨어지지 않나 싶었는데 이번엔 아주 Two Thumbs Up!입니다.

AJAX와 퍼포먼스

기획자 나잘난양과 개발자 도야근군, 그리고 옵저버 김단지군은 오늘도 신규서비스 개발을 위한 회의에 열심입니다.

...

나잘난양 : 그러면 우리도 AJAX를 이용한 기술적 진보가 있다고 보도자료를 뿌릴 수 있다는 거지요?

도야근군 : 게다가 AJAX를 쓰면 퍼포먼스도 올라가지요.

나잘난양 : 우리 서비스 메인 페이지가 A,B,C,D의 네 개의 섹션으로 이루어져있는데 각 섹션을 AJAX로 불러오게 될 때 퍼포먼스적 이점이 뭐지요?

도야근군 : 우선 A,B,C,D의 각 섹션의 내용을 페이지가 로딩 된 후에 불러오기 때문에 페이지의 데이터전송량을 줄일 수 있지요.

김단지군 : 그런데 페이지 전체로 보면 결국 전송량은 똑같은 것 아닌가요? 오히려 각 섹션별로 각각 커넥션 헤더가 들어가기 때문에 데이터 전송량은 AJAX쪽이 더 많을 것 같은데요?

도야근군 : 커넥션 헤더는 무시할 만한 수치죠. 핵심은 비동기화 커넥션이기 때문에 각 섹션이 각각 동시에 데이터를 가져올 수도 있으니까 로딩시간이 훨씬 단축되죠.

김단지군 : 그 말은 일단 이 페이지를 다 띄우기 위해서는 기존방식보다 HTTP커넥션을 더 소모한다는 거네요? 동시접속자가 몰릴 때에는 문제가 될 수도 있겠는데요?

도야근군 : 서버의 성능을 믿으세요. -_-a 어쨌거나 잘게 나눠서 여러 커넥션으로 동시에 가져오니까 더 빠르다구요.

김단지군 : 하지만 어떤 커넥션은 HTTP특성상 리스폰스되지 않을 수도 있는데, 그럴 때는 그냥 완성되지 못한 페이지 상태이구요?

도야근군 : 그건 통짜 페이지에서도 마찬가지 잖아요? 예를 들어 5번의 커넥션 중 한번이 실패한다면 통짜페이지는 5번 중에 1번은 못띄운단 소리잖아요.

김단지군 : 그러면 4개의 섹션 + 1개의 페이지로 구성된 이 페이지는 섹션 중의 한개는 매번 로딩할 때마다 안뜨는 셈이겠군요.

나잘난양 : 페이지가 통째로 안뜨는 것보다야 낫겠죠.

김단지군 : 뭐, 어차피 HTTP 커넥션 오류는 흔한 일은 아니니까요.

나잘난양 : 다음 이야기를 해보죠. 핵심 컨텐트인 섹션 A는 10분마다 혹은 사용자가 버튼을 누르면 리프레쉬되는 거지요?

도야근군 : 네. 리프레쉬될 때 다른 섹션과는 달리 섹션 A만 리프레쉬되므로 다 로딩할 필요가 없지요.

김단지군 : 그런데 누가 10분이 넘게 같은 페이지를 보고 있지요? 어차피 여기는 메인 페이지라서 다른 페이지로 가는 인덱스 역할이잖아요?

나잘난양 : 사용자들을 무시하지 마셈. 우리의 충성스런 사용자들은 우리 서비스를 백그라운드로 띄워놓고 틈날 때마다 다시 꺼내본다구요. 게다가 우리는 전부 새창띄우기니까 메인페이지가 사라지지 않잖아요.

김단지군 : 그럼 사용자가 보고 있지 않아도 10분마다 리프레쉬가 일어난다는 거네요? 정말로 데이터 절약되는 거 맞아요?

나잘난양 : 그럼 자동 리프레쉬는 빼고, 버튼을 눌렀을 때만 리프레쉬되도록 할까요?

도야근군 : 그럴 줄 알고 이미 구현해놨습니다.

김단지군 : 난 F5키가 편한데...

도야근군 : 전체 페이지 리로딩은 낭비라니깐요.

김단지군 : 사용자들은 습관적으로 F5를 누르게 되어있다구요. 공통되고 일관된 인터페이스라는 건 무시하기 어려운 거에요.

나잘난양 : 사용법 계몽 이벤트라도 할까요? -_-a

김단지군 : 그렇다면 이번에는 반대로 습관적으로 "갱신" 버튼을 눌러대는 경우에는요? 아직 새 데이터가 추가되지 않았는데도 갱신요청을 하면 또 DB커넥션을 해야 하나요?

도야근군 : 최종요청시간을 가지고 있다가 리퀘스트쿼리시에 같이 넘기던가...

김단지군 : 아, 데이터가 또 늘어나네요?

도야근군 : 그까이꺼 몇바이트나 된다고. 그럼 아예 스태틱 빌드로 섹션의 해당 HTML을 10분마다 빌드한 뒤 무조건 그걸 가져다가 뿌려주는 걸로 하지요.

김단지군 : DB트랜잭션은 줄테니 확실히 이득 맞군요. 괘찮은 아이디어입니다. 근데... 그렇게 스태틱 빌드를 하려면 AJAX는 뭐하러 쓰는거죠? 그냥 가져다가 뿌려주기만 할 건데?

도야근군 : ...

나잘난양 : 섹션 D는 어때요? 이건 1초마다 갱신이니까 이건 확실히 AJAX의 효과가 있겠죠?

도야근군 : 아, 당연히 그렇겠지요. 이건 어차피 1초마다 갱신이니 스태틱 빌드도 불가능하니까요.

김단지군 : 우리 플랫폼이 혹시 DB커넥션을 세션상태에서 유지할 수 있는 시스템인가요? EJB나 뭐 그런 걸로?

도야근군 : LAMP인데요.. 게다가 커넥션을 세션 상태에서 유지하고 있는 건 HTTP특성상 별로 좋지 않은 방법이라서.

김단지군 : 그렇다면 1초마다 새 DB커넥션이 이루어지고 쿼리가 일어난다는 거군요. 그것도 동접자 마다...

도야근군 : 뭐, 어쩔 수 없죠. AJAX를 쓰려면 그 정도는 감수해야.

김단지군 : 하긴, 트렌드니까요.

나잘난양 : 보도자료는 중요한 거라구요.

...

CC를 사용자에게 맡겨두지 않기.

또 한동안 블로고스피어를 달군 저작권 문제.

I. 일단 정리.
1) CCL(Creative Common License)은 무단펌질을 막아주는 부적, 마법의 딱지가 아니다.
2) CCL은 저작권을 보호(좁은 의미로, 펌질금지)한다기 보다는, 합법적으로 사용권을 주기 위한 방법이다.
- 부연 : CCL을 붙이건 말건, 무조건 개인의 창조적 작업의 결과물인 컨텐트는 그 저작권을 보호받는다. 그러다보니, 저작자가 선의로 공유를 하고 싶어도 무조건 저작권을 지키든가, 포기하든가 양자 택일만 가능하므로, 좀 더 합법적으로 컨텐트를 사용할 수 있다는 '선언'이다.

II. 사용자는 사악???
그러니까, CCL을 붙여놨으니까 나는 안심. 이건 정말 순진한 이야기. CC가 뭔지 모르는 사람들이 이 세상의 99%. 아마도 IE사용자보다도 많을 걸?
어쨌거나 이미지 딱지 하나 붙여놓았다고 맘 푹놓고 있다가 누가 불펌(?)해갔다고 길길이 날뛰어봤자 소잃고 외양간 고치는 격.
사용자는 CC가 뭔지도 모르고, 이해하지도 못한다. 아무리 친절히 설명해준다 하더라도. 게다가 페이지 어디에 CC가 붙어 있는지 알지도 못하고. 또 웹페이지에 붙어 있는 CC는 애매한 면이 있어서, 페이지 전체가 CC의 영향을 받는다는 건지, 특정 컨텐트가 CC의 영향을 받는 건지...
사용자에게 너무 많은 것을 기대하지 말 것.

III. 올바르게 CC 붙이기.
CC는 그냥 이미지 딱지만 붙여 놓는다고 되는게 아니다. 붙이는 것도 다 규칙이 있고, 표준이 있는 법. 올바르게 붙어있지 않은 CC는 아무 의미도 없다.

아래처럼 붙어야 올바르게 CC가 붙어 있는 것.

[html]

This work is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 2.5 License.[/html]

자신의 웹사이트는 제대로 CC가 붙어 있는지 확인해보자.

IV. 공은 개발자에게로.
[php]
class MICROFORMAT {
private $str;
private $domain;
private $xpath;
private $dom;

public function __construct($str, $domain) //{{{
{
$this->str = $str;
$this->domain = $domain;

$this->dom = new DomDocument();
@$this->dom->loadHTML($this->str);

$this->xpath = new DOMXPath( $this->dom );
} //}}}

public function get_license() //{{{
{
$events = $this->xpath->query(".//*[contains(@rel, 'license')]/@href");
foreach($events as $event) {
$license["{$event->nodeValue}"] = $event->nodeValue;
}
return $license;
}//}}}

...
}
[/php]

이런 코드(여기서는 PHP5인데, 다른 언어로도 뭐.. 알아서들 잘 하시겠지만)만 있으면 CCL라이센스(는 물론이고, GPL이라든가 기타 microformat에 rel-license로 정의된 모든 라이센스들)를 가져 올 수 있다.

가져와서?

애시당초 WYSIWYG이라는 표준과는 삼만광년 떨어진 비시맨틱한 도구에 의존하는 경우에야 Ctrl+C/Ctrl+V를 어떻게 하긴 어렵겠지만 그 잘하는 "오른쪽 버튼 막기" 기능대신, "지금 보시는 컨텐트는 원저자를 표시하고, 비영리 목적으로 사용하며, 변경을 금지하는 조건으로 사용가능합니다."라는 메시지를 띄워준다거나... IE는 클립보드 컨트롤이 가능하므로 라이센스관련 처리가 가능할테고.
혹은 Tong같은 펌질도구라면 펌질된 부분 밑에 라이센스 관련 처리를 해준다든가(원저작자를 표시해야 한다면 자동으로 원저자를 붙여주고, 변경이 금지라면 사용자가 추가, 변경을 못하게 입력창을 잠궈버린다든가...)...
뭐, 이쯤은 되어야 메이커도 자기 할일 다했다고 사용자에게 책임을 미룰 수 있지 않을까? 무조건 고객센터로 증명서 보내라는 헛소리는 말고 말이지.

V. 수수께끼로 마치며.

하나,
여기, "원저자 표시, 비영리 목적, 변경 금지"라이센스가 걸려있는 컨텐트가 하나 있다고 하자.
네이버(편의상.)에서 이 컨텐트를 수집해 가서 대문에 걸어준다면, 네이버는 "비영리목적"이라는 라이센스규칙을 어긴 것일까? 분명히 네이버의 대문은 사용자를 유인해서 광고수익을 올리려는 의도가 있는 것일텐데 말이지.

둘,
똑같은 컨텐트를 어느 블로거가 펌질해서(물론 원저자도 표시했고 변경도 하지 않았지만...) 자신의 블로그에 올렸다고 하자.
이 블로거의 블로그의 한켠에 Google AdSense가 붙어 있다면 이 블로거는 "비영리목적" 라이센스를 어긴 것일까? AdSense는 분명히 광고수익을 올리기 위한 영리행위인데 말이지...

셋,
똑같은 컨텐트를 어느 메타블로그가 수집해가서 자신의 frame안에서 보여준다고 하자(올블로그같은 방식). 그 메타블로그가 수익이 없다가 어느날부터 광고를 붙이기 시작했다면 이 메타블로그는 라이센스의 비영리목적을 어긴 것일까?

집단소송일어나기 딱 좋군. 언젠가 다들 큰 코 다치리.

올블로그 개편

복잡하고,
페이지 안에서 너무 많은 것을 보여주려 하고 있으며,
역으로 그래서 오히려 아무것도 눈에 들어오지 않고,
익숙해지면 다를 수도 있겠지만 익숙해지고 싶지 않고(굳이 그런 노력을 들여야 할 이유도 없고...),
아무래도 안다니게 되지 싶다.

하긴, 어차피 올블로그에서 새롭고 재미있는 블로거를 만나본지가 언제던가. 리더기에 추가해본 지도 오래.
역시 알음알음 링크타고 다니는 쪽이 더 효율적으로 의미있는 뉴페이스를 만나게 된다고 생각.

뭐, 내가 쓰든 안쓰든 대세와는 상관없지만.

AJAX와 개인정보피싱

AJAX 프로그래밍을 하다보니 찜찜한 것들이 있습니다.

전통적인 Web 개발에서는 페이지 단위 상태라는 오토마타를 따르기 때문에 문제가 없었는데, AJAX와 브라우저의 자동입력 기능이 합쳐지면 개인정보보안상 큰 구멍이 생길 수도 있겠더군요.

AJAX를 이용하면 사용자가 Form서브밋을 하지않더라도 강제로 Form 서브밋을 하게 할 수 있습니다. 예를 들어, input field에 onChange 이벤트를 감시하고 있다가 내용이 바뀌면 HTTPRequest를 이용해 사용자 몰래 데이터를 서버로 보낼 수 있겠지요.

물론, 정상적인, 신뢰할 수 있는 사이트에서는 그럴 일이 없겠지만, 악의를 가진 피싱 사이트에서라면 얼마든지 이를 응용해서 사용자 정보를 채갈 수 있을 듯 합니다. 사용자는 그저 페이지를 열어본 것 뿐인데도 말이지요.

대부분의 자동입력기능은 field의 name을 가지고 판단합니다. 인기있는 사이트들의 페이지를 열어보면, 어떤 field name을 채와야 할지 알 수 있습니다.

그리고는 겉으로 보기에는 아무런 해가 될 것 같지 않은 페이지를 사용자에게 보내는 것이지요. 설문조사나 경품안내 등의 껍데기를 하구요.

(* 블로그 이전으로 예전 샘플 사라짐 *)

설문조사를 작성하면서 필드간에 이동을 위해 Tab을 누른 사용자는 자신도 모르게 자신의 email을 납치당합니다.

혹은 좀 더 직접적인 방법으로 유혹할 수도 있겠지요. "이건 그냥 샘플입니다. 타이핑만 하세요. [확인]버튼을 누르실 필요는 없습니다."

이 코드가 실제로 그렇게 피싱이 가능한지는 잘 모르겠습니다. 다만 가능성이 있는 것 같은데 다른 분들은 어떻게 생각하세요?

마이너의 설움

논란이 된다는 파란 블로그스페이스가 어떤지 궁금하여 접속을 해보았는데...

1: paran.com 초기화면이 와장창 깨져요. Mac 쓰는 설움이지요. 일본에 있어서 가뜩이나 회선 속도도 느린데, 담배 반대 피고 올 시간이 걸리네요.

2: 그 22만건의 글 중에 나는 없네요. 나는 저작권도 상관없고, 스크랩을 하건 긁어가건 신경도 안쓰는데... 왜 민감한 사람들 것만 가져가서 평지풍파를 만들고, 나처럼 맘이 넉넉한 사람은...

3: 프레임 속에 프레임 속에 프레임 속에 프레임 속에... :)

4: RSS를 너무 순진하게들 생각하시네요. :) 그냥 콱 RSS내려버리세요. 저작권이니 이런 거 신경쓰여서 어디 블로깅이나 하겠어요?

5: CC는 저작권을 지키려고 붙이는 게 아니라, 저작권을 풀어주려고 붙이는 거에요. (CC를 붙이든 말든 저작권은 지켜지는게 기본이긴 하지요.)

6: CC는 마법의 부적이 아니에요. 붙이기만 해두면 자동으로 스크랩이 막아진다거나 하는 건 아니지요. 그건 그렇고 가져가는 쪽도 microformat과 rdf에 대해 무지하긴 하지만, 붙여놓는 쪽도 국내에서는 50보 100보인 셈이니 누굴 탓하겠어요. (하긴, 이건 블로거의 문제가 아니라 블로그 메이커의 문제긴 하죠.)

스크랩을 왜할까?

무슨, "웹의 본질은 링크..." 이 따위 교과서적인 소리를 하려는 게 아닙니다....

도대체 스크랩을 왜 할까요?.
답은, 그이외의 수단이 마땅치 않아서입니다..

저는 스크랩을 합니다. 현재까지는 가장 비용이 적게 드는 정보관리 방법이기 때문이죠.

사람들이 웹 페이지를 스크랩하는 이유는, 거기에 정보가 들어있기 때문입니다. 이것을 링크로 대신하라는 것은 조금 무리가 있는데, 왜냐하면 링크는 "레퍼런스"이지, 그 자체가 어떤 유용한 정보를 담고 있는 건 아니기 때문이지요.

링크 자체로는 아무런 유용한 정보를 주지 못합니다. 그 링크가 무엇에 관한 링크인지, 어떤 내용을 담고 있는지조차 알 수가 없지요. (그래서 pretty url같은 것을 필요로 하는 게지요.)

하면, 링크를 다시 별도의 관리작업을 해주어야 하는데, 링크에 대한 부가설명을 달고, 링크의 범주를 분류하고... 뭐 이런 식으로요. 한때 제로보드가 유행했을 때 사람들마다 빠지지 않고 만들었던 게시판이 바로 "즐겨찾기" 게시판이었습니다. 링크를 관리하기 위한 나름의 자구책이었던 셈입니다.
현재 잘나간다는 digg.com이나 del.icio.us같은 소셜 리마커블 인포메이션 서비스들도 결국은 이러한 링크(페이지단위 URL)에 대한 관리 수준을 벗어나지 못하고 있습니다.
브라우저의 북마크는 더 불편하니 말할 것도 없겠지요.

뭐니뭐니해도 페이지를 통채로 스크랩하는 방법이야 말로 일반 소비자가 현재의 웹환경에서 외부정보를 획득,보관,관리하는 가장 저렴한 방법입니다.

이보다 더 효율적인 방법을 제공해주지 않는 한, 스크랩을 하지 말라고 아무리 외쳐봤자, 빵대신 케익을 먹으라는 소리로 들릴 뿐이지요.

그럼, 해결책은 없을까요?

스크랩이 가장 저렴한 방법 중 하나이긴 해도, 효율은 그닥 좋은 편은 아닙니다.
왜냐하면, 스크랩을 통해 정보를 이용하기 위해서는 다시, "스크랩된 내용을 읽고, 필요한 정보를 찾고, 그것을 다시 재분류하는 과정"이 필요하기 때문이지요.

스크랩이건, 링크건 간에, 암묵적인 동의가 깔린 것은, "웹에서 정보의 최소량은 페이지URL단위"라는 고정관념이지요.
과연 그런가... 하면 그건 아니죠.

URL은 정보관리의 단위로 삼기에는 너무 큽니다. 아무 웹사이트나 들어가서 페이지를 열어보세요. 오만가지 잡다한 정보들이 가득 들어있습니다. 이 페이지에서 정작 내가 다시 사용하기 위해 원하는 정보는 아주 작은 일부일 뿐인데도 한 페이지를 통틀어 링크 혹은 스크랩을 해서 관리합니다. 이거 비효율적이지요.

그렇다면, 저 "아주 작은 일부"를 어떻게 추출해서 관리하게 해줄 것인가... 거기에 핵심포인트가 있겠네요. 하나 더 추가하자면, 나는 그 정보를 "왜" 필요로 하는가도요.

"마우스로 그 부분을 긁어다 붙이기..." 정도의 빈곤한 상상력보다는 더 재미있고, 편한 방법이 확실히 존재할 겁니다... :)

태그가 카테고리가 아니라면...

태그는 카테고리가 아니라고 하니까, 어떤 분이 물으시더군요. 그럼 뭐냐고.

결론부터 말해보지요.
Not Categorizing, But Characterizing

The Best Stuff In The World라는 사이트가 있습니다. 집단지성을 이용한 일종의 랭킹서비스인데요, 여기를 보면 Categorize와 Characterize의 차이를 느낄 수 있습니다.

예를 들어 linux란 word를 보면,

The Best Computer, The Best Things In Life, The Best Desktop Computer, The Best Software, The Best Apple Computer, The Best Operating System, The Best Reason To Buy a Mac, The Best Games Console, The Best Fruit, The Best Brand, The Best *nix, The Best Company, The Best Antivirus, The Best Revolution, The Best Innovation, The Best Firewall, The Best PC, The Best Way To Crash Windows, The Best Ideas, The Best Electronics Brand, The Best Computer Brand, The Best Personal Computer, The Best Overrated Stuff, The Best Fruit To Eat Dried and The Best Eye Candy

라고 붙어 있습니다.

linux는 152명에게 가장 좋은 OS로 꼽혔고(OSX가 242명이긴 하지만.), 78명에게 베스트 소프트웨어로 꼽혔습니다.(FF가 827명이긴 하지만.)

이렇게 보면 “가장 좋은 OS” 혹은 “베스트 소프트웨어”라는 “범주”로 linux를 Categorizing할 수도 있겠지요.

그러나 ‘인생에 가장 멋진 것’이라거나, ‘Windows를 박살내는 좋은 방법’이라는 것으로 ‘linux’를 Categorizing하려면 상식의 저항에 부닥치게 되고, 급기야 ‘말려먹기에 가장 좋은 과일’에 다다르면 카테고리란 과연 무엇인지 회의가들게 될 겁니다.

실은, 우리는 실생활에서도 이미 태그를 많이 보고 있습니다.
미니오디오 하나만 사도 뒷면에 많은 딱지들이 들어있지요. ‘Dolby’, ‘SRS’, ‘TurboBoost’ …
PC를 사도 딱지가 많이 붙어 있습니다. ‘Intel Inside’, ‘EcoGreen’ …
태그란, 그런 성격으로 이해되어야 합니다.
“이 PC는 ‘Intel Inside’의 한 종류야.”가 아니라, “이 PC는 ‘Intel Inside’를 가지고 있어.” 라는.
OO에서 이야기하는 ‘is-a’와 ‘has-a’의 관계라고나 할까요.

만약 웹에서의 태그가 텍스트가 아닌 그래픽이었다면 이런 혼동도 줄지 않았을까 싶어요.

non-text tag로 풀어보는 tag

그래픽 태그 이야기를 했더니 곧바로 메신저로 질문이...

좀 추상적이었던 이전 글은 원래 예전에 쓰다만 것인데, "한님의 초건전사이트 운영자 동맹 포스트"을 보고 갑자기 기억이 나서 글을 완성했습니다. 아무래도 배경 부연이 필요한 것 같아서요.

UserSigs라는 서비스가 있습니다. 포럼이나 블로그 등에 글을 쓰고 자신의 Signature를 남길 때 사용자의 성격에 맞는 그래픽 이미지를 가져다 쓸 수 있게 해주는 일종의 배너셰어 서비스지요.

그러니까,

"저는 나이키브랜드를 좋아하고, 커피에 중독된, 리눅스를 쓰는 공산주의자에요." 라는 자질구레한 설명 대신,

이런 이미지를 가져다 쓰라는 거지요.

'rel="tag"'라는 마이크로 포맷에는 맞지 않지만, 거의 완벽한 태그 활용이라 할 수 있지요. (자동입력이니 태그추천이니 하는 인터페이스가 태그의 전부처럼 이야기되는 요즘입니다만. 그건 오히려 곁가지일 뿐이죠.)

1) 집단지성??
집단 지성은 "의도해서" 이루어지는 것이 아닙니다. 사용자에게 별도의 액션을 요구하는 "소위 집단지성" 시스템은 결코 집단지성이 될 수 없습니다. "투표하세요.", "추천점수를 주세요.", "별점을 매겨주세요." 이런 문장이 들어있는 시스템은 집단지성과는 멀어졌다고 할 수 있지요. 사용자의 "의도적인 행위"가 개입되는 순간 집단지성의 의의는 사라집니다.
UserSig의 Top Image 섹션을 보면 그 차이를 잘 알 수 있습니다. rating, vote, hit, download의 네가지 척도에 따라 각각 높은 점수의 sig들을 보여주는데요,
별도의 액션이 필요한 rating, vote에 등장한 이미지와 별도의 액션 대신 사용자의 이용 액션 그 자체인 hit와 download에 등재된 이미지를 비교해보면 차이를 알 수 있을 겁니다. 어느 쪽이 진짜 top image일까요? 당연히 download가 많이 된 이미지가 진짜 인기 이미지겠지요. (vote와 hit에 같이 상위로 등재된 Led-Zeppelin sig는 메인에 노출된 최근등록 sig라서입니다. hit수에 비해 download가 적다는 것이 실제로 그 sig가 그다지 인기가 있지 않다는 뜻이지요.)

rating, vote에 참여자 수가 적어서 그런게 아니냐는 지적이 있을 수 있습니다만, 본질적으로, 집단지성은 무의식의 발현 집합을 근거로 합니다. 에, 다시 말하자면, 집단지성을 체크하는데 rating이나 vote는 그다지 좋은 수단이 아니라는 거지요. '월척'의 폐해가 있을지언정 별점보다는 조회수 많은 글이 더 집단지성을 잘 표현하는 셈입니다. "집단지성"이 반드시 똑똑하란 법은 없으니까요.

2) collabulary
태그의 단점으로 늘상 지적되는 모호성, 다형성을 collabulary로 극복하려는 시도들이 많이 있습니다. 태그추천 같은 기능도 그 일종일텐데요. UserSigs에서는 등록된 이미지를 가져다 쓴다는 형태로 collabulary를 구현하고 있습니다.
collabulary구현시 주의할 점은, collabulary가 강제성을 가져서는 안된다는 거지요. 그러니까,
"'Mac OS X'라는 태그보다는 'MacOSX'라는 태그가 '좋아요.' (이 태그와 관련된 서비스를 사용하려면 Mac OS X라고 쓰지는 마세요, 그건 다른 사용자들이 적게 쓰거든요. MacOSX라는 태그를 꼭 쓰라는 건 아니지만, 그래도 쓰면 훨씬훨씬 더 좋아요.)"
라는 형태는 문제가 있다는 거지요.
애초에 태그의 장점이 모호성과 다형성에 있는데(위에서는 단점이라고는 했지만.) 굳이 그 모호성과 다형성을 강제로 억제하려는 시도자체에 태그 시스템의 모순이 발생하게 되는거지요.
"타인을 위한 태깅"이라는 관점에서 벗어날 필요가 있겠습니다. 누가 뭐래도, 내 맘에 들면 태깅은 이것으로, 타인에 대한 배려는 그 다음... 그리고 그 때에야 vocabulary의 필요성이 생기는 거고, 그것을 collabulary로 구현하는 게 맞습니다.
UserSigs에서 같은 대상에 대한 sig라 하더라도 자기 취향에 맞는 이미지로 골라 선택하거나, 그나마도 맘에 안들면 스스로 만들어 올리도록 하는 체계에서 힌트를 얻을 수 있겠지요.

3. NO more Category
"linux-user"가 나에 대한 Categorizing인가요? 아니죠. "linux-user"는 나에 대한 Characterizing이지요. 그러니까, "linux-user"를 클릭하면 linux-users를 볼 수 있습니다." 같은 서비스는 태그라는 관점에서 보면 그다지 재미있지 않은 접근이지요.(의미가 없다는 건 아닙니다만.)
즉, "linux-user에 누구누구가 속해있느냐"는 건 전통적인 Categorizing 접근 방법이고, "누구는 어떤 속성(character)을 가지고 있느냐" 는게 Characterizing 접근 방법입니다.
그런 면에서 본다면, 차라리 TatterTools 옛날 버전에서 쓰던 keyword라는 것이 오히려 태그의 본래 개념에 더 가깝다 할 수 있습니다.
이 태그에 어떤 글이 붙어 있느냐...보다는 이 글에 어떤 태그들이 붙어 있느냐가 더 좋은 태그의 활용법이 되는 힌트가 될 수 있겠죠.

4. Is really useful?
태그를 사용하는 서비스들은 한번씩 반문해볼 필요가 있습니다.
과연 이 서비스에서 "태그"가 진짜로 유용한 것인가? 트렌드로서의 거품을 걷고, 실제로 정보공학적으로 유의미한 인터페이스가 되기 위해서는, 이 시스템 체계에서 이 태그가 진짜로 쓸모 있는지 진지하게 생각해봐야 합니다.
그저 멀티 카테고리의 다른 이름이 아닌가, 중복패쓰를 양산하는 비효율적인 정보경로는 아닌가, 의미없고 쓰이지 않는, 오히려 방해가 되는 쓰레기 정보의 생산방법은 아닌가...
태그에 대해 많은 고민이 필요하겠지요...

메타론칭 for web 2.0 (?)

한가해지고, 공짜서버라도 생기게 되면 꼭 만들어보고 싶은 사이트가 두개 있는데,
하나는 SF전문 북크로싱 사이트이고, 또 하나는 와인정보 셰어 사이트입니다. 둘다 그냥 취미생활.

오늘 보니, BottleTalk라는 사이트가 딱 제가 생각하던 그대로의 와인정보나눔 사이트이네요.
전형적인 web 2.0(여기에서는 그저 트렌드, 유행 정도의 의미) 사이트. 기능도 그렇고, 인터페이스나 룩앤필조차도. 이제는 매쉬업 혹은 ShareInfo 사이트들은 모두 공장에서 찍어낸 것처럼 보일 정도.

그러고 보니, 이런 웹2.0(?) 서비스를 만들어주는 도구를 만들면 장사가 좀 되려나 하는 생각이 드는군요.
그러니까 블로그를 만드는 블로깅 도구처럼, 이런 사이트를 간단히 클릭 몇 번으로 만들 수 있는 서비스 혹은 프로그램.

“안경소녀 정보공유하기” 라든가, “지도위에 라면맛집을 모아봅시다.”라든가 하는게, 꼭 비즈니스 기업이나 전문프로그래머들만이 할 수 있는 영역은 아니잖아요? 오히려 일반인들이 저런 욕구는 더 크지요. 다만 방법을 모르고 기술이 없을 뿐, 그렇다고 남이 제공해주기만 기다리고 있는 것은 답답하고, 또 남(기업)이 제공해주는 서비스는 왠지 쓰기 싫고.(포털에서 블로그를 제공해줘도 굳이 설치형 블로그를 쓰고, 포털에서 카페를 제공해줘도 굳이 제로보드를 쓰는 사람들이 있는 것 마냥.)
게다가 기업들은 어떻게든 수익을 내야하므로, 저런 ‘돈안되는 웹 2.0′에는 뛰어들기가 오히려 어렵지요. 사실 어느 회사가 “와인정보공유서비스”를 진지하게 생각해보겠어요? 한가한 프로그래머 중에 와인홀릭이 있다면 모를까, 힘든 일이지요. (위의 BottleTalk를 만든 친구들이 걸어놓은 링크를 보세요. 이런 깜찍한 친구들! :))

매쉬업 서비스의 한계(조만간 포스팅 예정)를 고민하다가 나온 생각인데, 뭐, 결론은 이렇습니다.
매쉬업, 너무 좋아하지 마세요. 돈도 안되고, 진입장벽도 낮고. 봉이 김선달같은 비즈니스 모델이 계속 성공할리 없잖아요?

RSS의 법적 해석

민노씨께서 메일로 조선일보의 RSS관련한 사항을 질문해오셨는데, 메일로 답을 드리려다가 공개적으로 포스팅할 가치가 있을 듯 해서 적어봅니다.

“그 피드를 조선닷컴에 ‘제공’하는 데에 어떤 ‘계약’도 필요로 하지 않는 건가요? 그냥 조선닷컴에서는 ‘가져와서’ 쓰면 되는건지요? 이 점이 가장 궁금합니다”.

일단, 전략이나 가치문제를 떠나서(그런 부분은 제 소관사항이 아닌지라.) RSS의 사용과 관련된 법적 부분을 좀 살펴보자면…

핵심사항은 이것입니다.
“RSS는 컨텐트 자체가 아니라, 그 컨텐트를 설명하는 메타정보일 뿐.”

많은 오해가, “RSS = 컨텐트”라는 인식에서 발생하곤 하지요.
RSS는 컨텐트에 관한 메타정보를 담아 배포하는 규격입니다. 이 메타정보는, 컨텐트의 이름, URL, 작성자, 작성시각… 등등등을 포함하고 있지요. 이것들은 저작권(1차 및 2차 ‘창조물’에 대한 권리)과는 상관없는 객관적 사실입니다. 즉, RSS자체는 저작권의 보호대상이 아니라는 것이지요.
따라서 적합하게 제공된 RSS를 이용한다는 것은 통념적인 한도내에서 저작권과는 관계가 없습니다. 저작권이 보호하는 것은 오리지널 컨텐트이지, 그 컨텐트에 대한 “설명”은 아니니까요.

문제는, RSS에 컨텐트 자체 혹은 일부를 담았을 경우의 저작권입니다.

이곳을 보시면 미국의 경우이긴 하지만 참고하실 만한게 있으실 겁니다.
요약하자면,

1) 상업적인 이득을 얻는가.
2) 재가공 정도가 어떠한가.
3) 사용량이 어느정도인가.(웹사이트를 몽땅 긁는 수준인가, 아니면 요약이나 설명을 제공하는 정도인가..)
4) 원본의 시장을 침해하는 것은 아닌가.

이런 사항들을 따져봐서 오리지널 컨텐트의 저작권을 침해하는지를 판단하게 됩니다.

상식(?)적으로 생각했을 때, RSS제공자(=컨텐트저작자)가 제공하는 RSS는, 저작자 자신의 기준에 맞게 공개해도 좋을 만큼을 공개하는 약속이라고 할 수 있습니다. 이에 따라 다양한 수준으로 RSS를 제공할 수 있지요.
이미지까지 몽땅 contents:encoded에 집어넣어 전문을 공개하는 경우도 있고, 아주 일부만 살짝 공개하는 경우도 있고, 또 컨텐트 자체가 아닌 단순한 간접설명(description / excerpt)만 제공하는 경우도 있고, 또 컨텐트에 대한 설명은 전혀없이 url만 제공하는 경우가 있습니다.(참고) 바꿔말하자면, RSS는 충분히 제공자가 의식적으로 인지한 상태에서 공개수준을 결정할 수 있다는 소리입니다. (그 권한이 자유롭지 못한 국내 포털 블로그들은 논외.) 최소한 신문사라면 자신들이 RSS를 왜, 어떻게, 얼마나 제공할 지를 결정할 능력이 있다는 것이지요.

따라서 이렇게 의식적으로 수준이 결정되어 제공된 RSS는 보호받아야 하는 저작물로서의 가치가 높다고 볼 수는 없습니다.

그러므로 RSS를 사용하는 것 자체에 대해서는 딱히 문제될 게 없습니다. 공개를 할 지 말지, 어느 수준까지 할지를 제공자가 결정했다면 그걸로 끝. 수집자가 가져갈 지 안가져갈지, 어떻게 가져갈 지, 가져가서 무엇에 쓸 지는 제공자가 왈가왈부할 꺼리가 아니지요.

일단 RSS를 제공하고, 누군가 그것을 가져가서 쓰게 되었을 때, 그것이 제공자의 오리지널 컨텐트에 대한 저작권까지 침해하는 것이 아닌 한 RSS의 사용에 특별한 문제는 없습니다.

뭐, 원론적인 이야기를 길게 늘여썼는데.(실은 이미 전에 몇번 이와 관련된 포스팅을 했었죠.)
한국, 그것도 신문에 관해서라면 좀 특이한 문제가 있습니다.
바로 “온신협 저작권”이라는 게 문제지요.

“온신협”에서 신문기사 링크에 관해 너무 아전인수격으로 해석을 해놓아서, 이미 아시겠지만 프레임링크는 물론이고, 링크자체도 엄격하게 제한을 두고 있습니다. 심지어 기사의 “제목”을 그대로 쓰는 것 자체도 저작권의 위반이라고 주장하고 있지요.

옛날에 이와 관련해 포스팅한 적이 있습니다.

저작권법상 RSS는 불법??
이해불가 딥링크

음.. 지금보니 오늘의 사태(?)를 예견한 선구자적 포스팅이었군요. 조선일보를 예로 드는 예지력까지!(^_^)

결론내자면 이렇습니다.
1) RSS의 취지만 놓고 보자면 조선일보의 새로운 서비스는 아무런 문제가 되지 않습니다. 오히려 좋은 RSS활용법 중 하나라고도 할 수 있겠지요.
2) 그러나 “온신협”의 관점으로 보자면 자가당착 모순에 빠지는 웃기는 상태이기도 하지요.

에, 민노씨께서 질문하신 부분에 대한 답변은 1)로 갈음하겠습니다.

OSX에 APM설치하기

일본에서 임시로 묵고 있는 곳에 아직 인터넷이 연결되지 않았습니다. 긴긴 밤(?)에 FootballManager만 끌어안고 있는 것도 질려서 뭔가 좀 영양가 있는 것을 해볼까 하다가 인터넷이 안되니 할 수 있는 게 없더군요. 심심풀이 개발이라도 해볼까 해서 맥북프로에 개발환경을 구축해볼까했습니다.

그래서 OSX에 APM설치하기인데요…
너무 간단해서. -_-a

1. Apache 설치하기
OSX에는 Apache가 기본내장되어있습니다. -_-a
즉, 개인용으로 쓴다해도 개인 홈페이지 정도는 인터넷만 연결되면 별도의 호스팅없이 운영할 수 있다는 소리죠.
“시스템 환경설정(Preference)”에서 “인터넷&네트워크” -> “공유” -> “개인웹공유”에 체크만 해주면 됩니다.
체크안해도 127.0.0.1에서 localhost로 접근할 수 있습니다.

httpd.conf는 /private/etc/httpd/ 에 있습니다.

한가지 주의할 점은, OSX에서는 기본적으로 root계정이 활성화되지 않기 때문에 httpd.conf등을 수정하기 위한 su획득을 위해서는 root를 활성화시키고 패스워드를 변경할 필요가 있습니다.
유틸리티안에 들어있는 NetInfo관리자를 열어서 users중에 root를 찾아 ‘*’로 되어있는 패스워드를 변경하면 됩니다. 그리고 터미널에서 ’su root’를 해보세요.

httpd.conf외에 계정별로 /private/etc/httpd/users/ 에 계정별 conf파일이 있습니다. .htaccess등을 이용하려면 여기에서 계정별로 설정을 바꿔주세요. (자세한 것은 아파치 매뉴얼을 참고하세요.)

기본적으로 설치되어있는 아파치 버전은 1.3.2입니다. Apache2가 아닌 것이 좀 그렇지만, PHP5, MySQL5등을 설치하는데 아무런 문제가 없으니 통과. 꼭 Apache2가 필요하신 분은 소스코드를 빌드하거나 별도로 패키지를 찾아 다운받아 설치하셔야 됩니다. 이 경우에는 별도의 prefPanel로 관리해야되므로 좀 귀찮지요.

2. PHP5 설치하기
http://www.entropy.ch/software/macosx/php/에 가서 자신의 환경에 맞는 패키지를 찾아 다운받은 후, 더블클릭해서 설치하면 끝. -_-a

3. MySQL5 설치하기
http://dev.mysql.com/downloads/mysql/5.0.html에 가서 자신의 환경에 맞는 패키지를 찾아 다운받은 후, 더블클릭해서 설치하면 끝. -_-a

지금까지 APM설치해본 중에 제일 간단하군요. ㅎㅎ

참고링크 :
http://www.oreilly.com/pub/ct/49

Are you a VAIO?

Sony가 새 노트북 라인을 내놓으면서 광고타이틀을 재미있게 내놓았네요. Non-PC PC. 그러니까, 방구나 뿡뿡 꿔대는 배불뚝이 아저씨보다 cool한게 Mac청년이라면, 그에게 대등하게 어울릴 만한 것은 VAIO양이라는 말씀. 그러면서 은근슬쩍 VAIO는 PC따위가 아니라는 말씀. 맥 영향력이 커지긴 했나봐요. 경쟁 및 비교상대를 PC가 아닌 맥으로 타겟잡은 것 보면요. http://www.sony.com.au/article.jsp?id=3861&ref=vaioc 그럼에도 불구하고 Sony의 영향력은 예전만큼은 아닌 듯 합니다. 잇달은 사업실패와 철수로 근근히 이어간다는 느낌. PS3가 망하면 아마 그날로 문닫지 않을까 싶네요. 일본내에서도 Sony는 예전보다 많이 브랜드 가치가 떨어졌습니다. 일본에서도 삼성과 LG가 꽤 선전하고 있어요. 한국제에 대한 편견이 많은 그 일본에서도 말이지요. 어쨌든간에 광고로 돌아가서. 젊어서 쌈빡하게 Mac을 쓰다가 VAIO쓰는 새끈한 아가씨를 만나 사귀더라도... 결국 미래는 PC쓰는 양복아저씨라는 이야기도 될 수 있겠군요. :) 오늘은 OSX에 APM을 설치했습니다. 클릭 세번으로 웹서버가 만들어지는군요. 옛날에 Windows에 APM설치하는건 반나절이 꼬박 걸릴 일이었는데 세상 참 좋아졌습니다. OSX만세!!

ekitan

학교때 못다한 일어 배우는 셈 치고 일본에 와있습니다.
바쁘면 포스팅도 없습니다. (원래 게으름.)
포스팅이 적더라도 양해해주시길.

일본의 웹서비스들을 둘러보는 시간이 될 듯 합니다. 벌써 재미있는 사이트를 몇개 발견했습니다.
에키탄(http://ekitan.com)은 오늘 둘러본 사이트 중에 제일 재미있네요.
일단 명색은 전철,지하철 노선안내입니다만, 단순히 최저가격루트나 최단시간루트 등을 알려줄 뿐 아니라, 역세권 정보 등도알려줍니다. 재미있었던 것은, 각 역마다 민간 가이드를 임명해서, 그 가이드가 책임지고 정보관리를 맡는 듯 합니다. 가이드의블로그와 추천링크들이 연결되어 있고, 가이드가 아니더라도 트랙백이나 투고를 통해 해당 지역에 대한 정보를 등록할 수 있네요.
개인의 명예욕(가이드 임명)을 살짝 자극해서 적극적인 활동을 유도하는 모델인 듯 합니다. (일어가 약해 확신할 수 없음)
노선정보에 관해서라면, 각 역의 발착시간표에 맞추어 정확한 시간을 맞춰줍니다. 예를 들어 2시 18분행 전차를 타라는 식으로요. 해당 정보를 폰으로 전송해주고, 열차를 놓쳤을 경우의 대안도 볼 수 있는 듯 합니다.
국내에서도 참고할 만한 아이디어가 있을 것 같습니다.

Flamewar

귀찮네… 씨익. 만박님이 좋은 말씀을 해주셨으므로 갈음.

철저하게 나 중심으로 살자
내가 편해지고, 내가 즐겁고, 내 몸값 올라가게 해주는 게 아니라면 다시 생각해보자
갈길은 멀고 할일도 많다. 남 설득할 시간이 어딨나.
멋진 서비스 만들어서 보여주자