하늘 아래 세상 이야기.

일반적으로 많은 사람들이 보유하고 있는 흔한 이름을 갖고 있는 경우, 웹에 나온 검색 정보량은 모두 관련 개인과 연계성을 갖을 수가 없습니다. 그래서 취할 수 있는 방법은 회사명 + 이름(에델만 이중대)을 기입해서 판단할 수 있겠지요.

혹은 그냥 이름을 기입해서 1차 검색하고, 전체 검색 결과 중 다른 검색 카테고리는 그 수치가 많지 않아 일일히 연관성을 파악할 수 있겠으나, 웹문서 카테고리 경우 상위 3개 페이지에서(가령 총 30개) 나와 연관성이 있는 콘텐츠의 수치를 평균 내어 관련 수치를 전체 웹문서량에 곱하기하면 대략적인 수치를 마련할 수 있을 것입니다.

아직 외부적으로 비즈니스를 전개하지 않는 쥬니어 혹은 대학생들의 경우는 상기 웹문서 결과가 그리 많이 나타나진 않겠지만, 기업 대표, 독립 컨설턴트, 프로 스포츠 선수, 연예인, 오피니언 리더 등은 검색 결과가 많기 때문에 상기 방식으로 정보량을 수치화할 것을 제안합니다.

자, 단순히 수치를 진단하는 수준에서 조금 더 고민을 해서 검색 결과량(volume)과 개인 브랜딩 연관성(relevance) 두가지 기준으로 현재 개인 브랜딩2.0 수준을 보여주는 분류법을 마련해보았습니다. 하단의 이미지에서 먼저 가로축은 웹상에서 자신의 키워드로 검색했을 때 나오는 검색량이고, 세로축은 검색 콘텐츠와 개인 브랜드와의 연관성을 의미합니다.

여기서 연관성이라는 의미는 하단 정도로 생각해주시면 되겠습니다.
-관련 정보들이 내가 이야기하고자 하는 사항과 밀접한가?
-일관성이 있는가?
-관련 정보를 통해 다른 사람들이 나를 이해하는데 도움이 되는가?

 

[개인 브랜딩2.0 전략 개발을 위한 4분면]

세로축 검색 결과량은 솔직히 블로그를 비롯한 소셜 미디어 활용 능력만 있다면, 자기 의지대로 해결해나갈 수 있는 부분이지만, 가로축은 개인 브랜딩 연관성 부분은 내가 아닌 타인들이 나에 대한 인식이 어떠한지에 의해 결정되는 부분입니다. 그래서 정보 검색량부문은 다분히 개인의 열정적인 부분으로 해결할 수 있는 부분이고, 연관성 부문은 타인의 인식 부분이기 때문에 타인의 인식에 긍정적 영향을 끼치기 위한 노력이 필요한 부분이라고 정리할 수 있겠습니다.

다음으로는, 검색 결과의 많고 적음(혹은 어떤 4분면에 속해 있는지)을 판단하는 기준이 필요할 것입니다. 이 부분은 현재 나의 연차와 어떤 업계에 종사하느냐에 따라 달라질 수 있기 때문에, 정확히 수치를 제시하는 것은 어렵겠고요. 다만, 자신이 종사하는 업종에서 가장 유명한 분(혹은 롤 모델)을 포탈 사이트에서 검색해보고, 그분의 수치 중 50%를 기준으로 검색 결과량의 상단과 하단의 포지셔닝을 결정하시면 되겠습니다.

이야기의 주제를 [개인 브랜딩2.0 전략 개발을 위한 4분면]로 돌아와서, 각 분면별로 개인 브랜딩2.0 유형과 아주 간략한 커뮤니케이션 전략 방향을 정리해보겠습니다.

전무 개인 브랜딩: 4분면에는 포함되어 있지 않는 상황으로, 이는 검색 사이트 결과에서 전혀 개인에 대한 언급이 없다는, 한마디로 존재감을 느낄 수 없는 상황입니다. 이는 검색 키워드를 잘못 기입했을 경우 발생할 수도 있겠으나, 개인적으로 블로그 운영도 하고 있지 않고, 온라인 동호회 사이트 활동도 하지 않는 경우일 것입니다. 온라인을 통한 개인 브랜딩 구축에 전혀 관심이 없다면, 상관 없겠지만, 보다 개선을 해보겠다는 의지가 생기셨다면, 자신의 주변인들이 어떻게 온라인을 활용하고 있는지 파악이 필요하겠습니다.

최저 수준 개인 브랜딩: 소수의 검색 결과가 발견되고 있고, 검색 결과의 주요 내용들이 긍정적이기 보다는 부정적인 상황입니다. 검색 결과라도 많으면 다양한 포스트로 인해 해당 개인에 대한 브랜딩 판단에 시간이 걸릴터인데, 최저 수준 개인 브랜딩은 소수의 콘텐츠로 인해 관련 개인에 대한 부정적인 평가가 이루어지기 쉽습니다. 보다 쉽게 예를 들어보자면 이렇습니다. 대기업에서 마케팅 임원을 하던 분이 회사 비즈니스 상황이 좋지 않아 회사를 그만 두고 이직을 준비하면서 여러군데 헤드헌팅회사에 레쥬메를 제출했는데, 인터뷰 기회조차 잡지 못하는 것입니다. 이상해서 파악해보니, 기존 직장에서 같이 근무했던 팀원으로 추청되는 블로거가 익명을 바탕으로 해당 임원의 퍼포먼스와 인간성을 부정적으로 언급한 포스트가 블로그 검색 결과 상단에 나온다는 것이죠. 만약 요런 상황에 빠져있다면, 자신에 대한 업계 의견이 다양해질 수 있도록 블로그 직접 운영 및 온라인 동호회 및 소셜 네트워크 사이트  활동을 고려해야 할 것입니다.

불행한 개인 브랜딩: 다수의 검색 결과가 발견되고 있지만, 검색결과의 주요 내용들이 동일 이름으로, 전혀 관련 없는 개인을 설명하는 콘텐츠가 대다수인 상황입니다. 혹은 자신이 전달하고 싶은 메시지나 이미지가 타겟 시장에 전달되고 있지 않거나, 몇 개 있는 콘텐츠가 본인에게 매우 부정적인 상황입니다. 오프라인에선 어느정도 업계 내 인지도를 확보했다고 하더라도, 온라인 상에서 관련 상황을 극복하기 위해서는 자신을 부각시킬 수 있는 온라인 플랫폼 구축이 필요한데요. 검색결과가 많다는 의미는 해당 개인에 대한 시장 내 관심이 어느정도 형성이 되어 있다는 것을 의미하기 때문에, 업계내에서 오피니언 리더격의 인물들이 어떻게 블로그를 운영하고 있는지 파악을 하고(만약 없다면 해외 전문주제 블로고스피어 분석 필요), 자신에게 맞는 소셜 미디어들을 하나 둘씩 구축해나가야 합니다. 매우 적극적인 온라인 활동을 통해 자신에 대한 인식을 보다 다양화 궁극적으로는 긍정적인 콘텐츠들을 검색결과에 반영시킬 수 있을 것입니다.

분발가능한 개인 브랜딩: 검색 결과는 소수이지만, 관련 개인에 대한 검색 결과들의 내용들이 매우 긍정적인 경우입니다. 이러한 경우 업계 내 인지도 관점에서 조금은 부족하지만, 업계 내 긍정적 네트워크가 어느 정도 구축이 되어 있기 때문에, 조금만 더 진지한 노력을 기울인다면, 긍정적인 개인 브랜딩을 구축할 수 있는 가능성이 높은 상황이지요. 업계 내 긍정적 인지도가 있다는 것은 블로그, 소셜 네트워크 사이트 등 온라인 활동을 어느 정도 진행하고 있다는 의미로 해석될 수 있겠습니다. 다만 자신의 브랜드 정체성을 보다 확립할 필요가 있고, 자신에게 적합한 커뮤니케이션 채널을 확보하고 있는지? 자신을 보다 알릴 수 있는 콘텐츠를 지속적으로 생산하고 있는지? 진단과 함께 커뮤니케이션 전략을 재설정이 필요합니다.

최고 수준 개인 브랜딩: 검색결과도 많고, 대부분 긍정적인 내용들입니다. 일종의 해탈의 경지라 할 수 있는데요. 언론매체 인터뷰도 많이 진행해왔고, 칼럼을 많이 쓰셨거나 혹은 유명 연예인이나 스포츠스타인지라 언론의 주목을 많이 받는 상황이죠. 그런데, 웹 검색 결과라는 것이 긍정적인 상황으로만 유지된다면 좋겠지만, 갑자기 특정한 이슈로 인해 불행한 개인 브랜딩 분면으로 옮겨갈 수 있기 때문에 항상 온라인 대화 내용이 어떻게 전개되는지 모니터링이 필요합니다. 웹상에서 인정 받는 공인으로서 자신의 입장을 적절하게 전달할 수 있는 온라인 플랫폼의 전략적 운영은 개인 브랜딩이 강한 분들에게도 꼭 필요한 사항입니다. 어쨌든 모든 개인들이 가고자 하는 개인 브랜딩2.0 분면이라 할 수 있겠습니다.

여러분들도 이제 현재 자신의 개인 브랜딩2.0 상황이 어떤 분면에 속해 있는지 파악하실 수 있으실텐데요. 어떤 분면이든 강조해서 말씀드리고 싶은 것은 개인 브랜딩은 지속적으로 향상시키려는 노력이 필요하다는 점입니다.

물론, 개인이 제공할 수 있는 독특한 가치를 기반으로 한 개인 브랜딩을 먼저 규명하는 작업이 진행되어야만 긍정적인 개인 브랜딩 혹은 명성을 구축할 수 있을 것입니다. 또한, 공유, 개방, 참여라는 웹2.0 키워드, 링크로 연결된 네트워크의 힘, 콘텐츠를 무료로 생산, 소비, 유통되는 과정, 블로고스피어의 특성 등 새로워진 커뮤니케이션 환경에 대한 이해도 필요하고요. 무엇보다도 개인적으로 상기 언급한 일련의 과정들을 진행하고자 하는 욕심과 열정은 기본적으로 사전에 구축해 놓아야 할 조건이라 할 수 있겠습니다.

개인 브랜딩2.0 참 흥미로운 주제죠?

싸이월드, 미국서 올 연말까지 철수
마이스페이스닷컴·페이스북 등 텃세 못깨고 2년만에 백기
 
- 2006년 8월 진출한 뒤, 누적 적자를 견디지 못하고 올 연말까지 싸이월드USA를 정리하기로 방침
- 싸이월드US가 운영하던 싸이월드 미국 사이트(http://us.cyworld.com/)는 국내서 번역판으로 유지만 하기로.
- 동아시아권에 역량을 집중할 것으로 보임. 지난해 6개 해외법인(미국 독일법인 포함) 모두 적자. 해외 지분법 손실액 189억원.
- 중국에서도 가입자는 600만에 이르지만, 토종 서비스에 밀려 당연히(?) 삽질 중.
- 유현오 전 SK커뮤니케이션즈 사장(SK텔레콤 전무)은 지난 7월 싸이월드USA 대표직을 내놓고 스탠퍼드 대학에서 연수 중
 
기타 참고 - 올초 발표한 싸이월드 글로벌 사업 조정(독일시장 철수 등)
http://www.newswire.co.kr/?job=news&no=320970

- 올초 싸이월드 유럽법인(Cyworld Europe GmbH)을 정리하기로 결정. SK커뮤니케이션즈 유럽법인은 2006년 7월 독일 통신업체 도이치텔레콤 계열 T-Online Venture Fund와의 합작법인으로 출범했으나 폐쇄 가닥.

만약 여러분의 사이트에 검색엔진을 통해 색인이 생성되지 않도록 하려는 콘텐츠가 있다면, robots.txt 파일을 사용하여 웹을 색인하는 검색엔진 로봇(이하 "검색봇")을 차단하거나 필요한 부분만을 검색엔진에 나타나게 할 수 있습니다. 검색봇은 자동으로 작동하며, 한 사이트의 하위 페이지에 접근하기 전에 먼저 특정 페이지에 대한 접근을 차단하는 robots.txt 파일이 있는지 여부를 확인합니다. 이번 기회를 통하여 여러분들에게 올바르게 robots.txt를 사용하는 방법을 제공하고자 합니다.

Googlebot이 ‘?’가 포함된 URL 즉, 도메인 이름으로 시작되거나 임의의 문자열 또는 물음표로 구성된URL 검색을 차단하려면 다음과 같이 하시면 됩니다.
User-agent: Googlebot
Disallow: /*?

robots.txt 란..

‘인터넷 검색엔진 배제표준(Robots Exclusion Protocol)’이란 보안이 필요한 내용이 검색엔진에 유출되지 못하도록 웹 페이지를 작성하는 방법을 기술한 국제기술표준이다. 모든 검색로봇이 이 표준을 따르지는 않지만 일반 웹 사이트 개발자들이 손쉽게 적용할 수 있어 이용이 확산되고 있다.

서버관리자가 웹페이지 HTML 작성시 맨 위에 검색로봇을 배제한다는 의미의
 ‘File:robots.txt’, ‘User-agent: *’, ‘Disallow: /’ 등을 적어놓으면 검색로봇의 검색 대상에서 제외된다. 일반 웹 페이지에서도 와 같은 메타태그를 입력하면 검색을 피할 수 있다.

-----------------------------------------------------------------------

[대처법]
웹 사이트 wwwroot 루트 디렉토리에  robots.txt 파일을 하나 만듭니다.

내용에

 User-agent: *
 Disallow: /

라고 하면 모든 긁어가기 검색에서 제외됩니다.

To allow all robots complete access (몽땅 긁어가기 허락)
 User-agent: *
 Disallow:

Or create an empty "/robots.txt" file. (빈파일 만들기로 해도 됨)
To exclude all robots from part of the server (일부분 긁어가기 제외)

 User-agent: *
 Disallow: /help  : /help.html 과 /help/index.html 둘 다 허용 안한다.
 Disallow: /help/  : /help/index.html 는 허용 안하나, /help.html 은 허용됨.
 Disallow: /private/

To exclude a single robot  (배드봇 검색로봇만 긁어가기 제외)

 User-agent: BadBot
 Disallow: /

다음 메인 페이지에 담긴 비밀 - UI개발팀 - 김선진

미니다음 개편 사례: 20픽셀의 미학, 그 현재와 미래 - UI개발팀 - 추홍엽

XUL을 이용한 개발 사례 - RIA기술팀 - 김대웅

한메일 Express iPhone 버전 개발 사례 - RIA기술팀 - 조영주


Session 2

JRIA Widget 구현의 핵심 - UI개발팀 - 구경택

액션스크립트3.0에 대한 개발자들의 호기심 - UI개발팀 - 박형석

RIA와 Silverlight2.0 - UI개발팀 - 박종현

AJAX 채팅 어플리케이션 구현 - UI개발팀 - 최종배

브라우저 확장 - 플랫폼의 다양화 - UI개발팀 - 유시형

Front-End 성능 향상 Tip - UI개발팀 - 유승근

웹표준화와 웹접근성 강화에 대한 이슈가 커지고 있다. 오는 4월 11일(차주 금요일) '장애인 차별금지 및 권리구제를 위한 법률'이 시행되고, MS의 Internet Explorer 8은 그동안 문제가 많았던 CSS 렌더링 엔진을 자사 제품중(IE 5.5, 6, 7) 가장 완성도 있는 표준 지원 엔진으로 바꿔놓았다. 애플은 자사의 'Safari' 웹브라우저를 윈도우용으로 출시하였고, 최근에는 웹표준기술 테스트인 Acid3를 통과했다는 소식을 전했다. 오페라 역시 'Safari'와 같은 날 Acid3를 통과했고, 모바일 시장(휴대폰, PDA 등에 탑재되는 미니 브라우저 시장)에서의 강세를 이어가고 있다.

바야흐로 2008년은 웹표준의 전환점이 될 것으로 보인다. 그동안 은비까비가 들려주는 옛날 옛적 이야기쯤으로 치부하던 웹 실무자들도 조금씩 관심을 보이기 시작했고, 해야겠다는 생각을 하기 시작했다. 며칠전 사내 웹표준 세미나 이후 계획되어 있던 프로젝트가 곧바로 웹표준 개발로 전환되는 쾌거(!)를 이룬 것이다. 적어도 두시간 가까이 목말라가며 떠들었던 내 작은 수고가 헛되지만은 않았던 것일까.

그런데 바로 고민거리가 생겼다. 해야한다고 이연사 목청 높여~ 외쳤으나 정작 'How?'에 대한 해답을 확실히 주지 못한것이다. 세미나 직후 웹표준 개발로 선회한 프로젝트를 담당하신 기획자분이 내게 왔고, 어떻게 해요... 라고 물으시는데 참 미안해지더라. 지금까지는 웹표준을 위해서 웹퍼블리셔들이나 개발자들이 표준기술을 익혀왔고, 디자이너나 플래셔들에게는 접근성에 대한 이해를 구해왔었다. 하지만 사실 기획자를 통한 개발 프로세스의 적절성 논의에서부터 필요하다면 새로운 개발 프로세스가 필요하지 않을까 하는 생각을 하게 되었다.

한국소프트웨어진흥원에서 발표한  '실전 웹 표준 가이드(2005)'에 보면 마지막 챕터에 표준 개발 프로세스를 자세히 설명하고 있는데 이를 먼저 소개해보고, 김철수님의 웹 표준 개발 후기를 통한 문제점과 개선점 등을 고민해 보겠다.

실전 웹 표준 가이드의 '실전 표준 개발 프로세스'

기존 웹 개발 프로세스는 일반적으로 Waterfall 방식이라고 불리우는 선형적이고 밀어내기식의 프로세르를 따르고 있다.

쉽게 말해 '기획 → 시안 → 스토리보드 → 디자인 → 코딩 → 프로그래밍/디버깅'으로 이어지는 방식인데 전문적인 지식이 없더라도, 또는 프로젝트가 진행중인 새로운 인력이 투입이 되더라도 별도의 교육이 필요하지 않는 비교적 쉽고 단순한 방법이다. 때문에 웹개발 초기부터 도입이 쉬웠고 아직까지도 크게 변하지 않고 적용되고 있다.

이 방법의 문제는 ① 업무의 병목현상 ② 의존적 스토리보드 ③ HTML문서구조화의 어려움 ④ 개별 역활 중심의 프로세스를 통한 업무 과중을 들 수 있습니다.

1. 업무의 병목현상
   Waterfall 방식은 선행 프로세스가 지연될 경우 전체 프로세스의 지연으로 이어진다. 즉, 기획이 늦어지면 디자인과 코딩, 개발이 차례로 늦어지는 문제가 생긴다. 코딩까지 완료된 시점에서 기획이나 디자인이 변경되면 재코딩이 이루어지는 것도 병목현상에 한 몫 하게 된다. 아울러 프로세스상 뒤에 위치한 코딩이나 개발 인력의 프로젝트의 초기 참여율이 낮고, 둘 이상의 프로젝트에 참여하게 되면서 집중도를 낮춰 전체적인 생산성을 떨어뜨리는 경우가 생긴다.
2. 의존적 스토리보드
   스토리보드는 웹개발의 시작이고, 밑그림입니다. 그만큼 중요하죠. 문제는 디자이너나 개발자들이 지나치게 스토리보드에 의존적이라는 것입니다.

   “스토리보드에는 그에 대한 지시사항이 없는 걸요” - 아주 기본적인 에러확인 로직을
   스토리보드에 없다는 이유만으로 개발하지 않은 프로그래머의 반문
   “저는 스토리보드에 그려진 대로 그린 것 뿐인데요...” ? 디자인이 참신하지 못하다는
   지적을 받은 디자이너의 변명
   “어째서 스토리보드에 있는 그대로 하지 않았지?” ? 발전적 창의성을 적용한
   프로그래머/디자이너를 인정하지 않는 기획자의 질책

   위의 예는 의존적 스토리보드의 문제점을 제대로 보여주고 있죠. 이로 인해서 기획자는 스토리보드를 수백장씩 상세하게 기술해야만 하는 업무적 과중을 느끼게 됩니다. 웹디자이너에게는 스토리보드를 그대로 Photoshop에 그려내는 '오퍼레이터'와 같은 수동적인 자세를 가지는 것도 문제가 됩니다. 또한, 전체 프로세스를 한 눈에 보여주지 못한 수백장의 스토리보드는 개발자에게 별로 도움이 되지 못합니다.

3. HTML문서 구조화의 어려움
   HTML문서를 코딩하는 일은 관례적으로 웹디자이너의 역활로 지정되어 온 경우가 많습니다. 규모가 커지고, 웹디자이너의 부담을 줄이기 위해서 'HTML코더'라고 불리우는 직군이 생겼지만 상대적으로 낮은 대우와 평가를 받아왔습니다. 때문에 웹디자이너가 코딩을 하든, 웹개발자가 하든, 별도의 코더가 하든 HTML문서가 제대로 '구조화'되지 못하는 문제가 생기게 된 것입니다.
   
   
4. 개별 역활 중심의 프로세스를 통한 업무 과중
   기획자나 디자이너, 개발중 어느 한 직군(역활)을 중심으로 프로세스를 개선하거나 정리할 수 있습니다.
   기획자 중심의 프로세스는

웹 표준 가이드에서는 위와 같은 기존 프로세스의 문제점을 지적하고 '웹퍼블리셔 중심의 개선된 모델'을 제안하고 있습니다.

보기엔 상당히 복잡해 보이지만 단순히 HTML 코딩만을 위해서 'HTML 코더'를 두었던 것과 달리 웹 표준 기술에 대한 전문성을 가진 '웹퍼블리셔'라는 직군을 포함시키면서 기획자나 디자이너, 개발자가 가질 업무의 과중을 덜어냄과 동시에 전체 프로세스의 효율성을 높이고 있다고 볼 수 있습니다.

이제 여기서 실제로 위의 프로세스를 실무에 적용했던 김철수님의 후기를 살펴보겠습니다.

김철수님의 'Storyboard - 표준 스토리보드 구상기'

김철수님은 웹 2.0 에 따른 Ajax 사용등을 고려하면서 새로운 스토리보드의 필요성을 느끼셨다 합니다. 그리고 앞서 소개해 드린 '실천 웹 표준 가이드'의 '웹퍼블리셔 중심의 개발 프로세스'를 받아들여 프로젝트에 적용하는 노력을 해 주셨습니다. 특히 김철수님은 웹퍼블리셔에게 XHTML, CSS, JS와 같은 웹 표준 기술의 전문성과 더불어 프로젝트의 실무적인 조율 능력이 필요함을 지적하고 있습니다. 그리고 다음은 김철수님께서 실제로 적용한 방법이다.

방법은 이러했다. 우선 전체가 모여 프로세스 플로우를 짜기 시작했다. 이때 사실상 전반적인 기획과 분석과 설계가 같이 진행되어서 대략 2개월 정도가 걸렸다. 그 다음에는 컨텐츠 명세서를 간단히 작성하고 곧바로 퍼블리셔를 임명하여 HTML 코딩 작업에 들어갔다. 그 산출로 나온 CSS를 디자이너가 실시간으로 확인하면서 디자인 작업을 했고, 개발자는 DB 개발과 서버 프로그램 개발을 진행했다.

그리고 다음과 같은 문제점들을 나열했습니다.

첫째, 전체가 모여 프로세스 플로우를 맞추는 것이 매우 힘든 일이었다.

둘째, 컨텐츠 명세서를 작성하는 것이 쉽지 않았다.

셋째, 퍼블리셔의 작업을 충분히 해낼 사람이 없었다.

넷째, CSS를 잘 다루는 디자이너가 없었다.

아무래도 새로운 프로세스를 직군별로 설득하고 이해시키는 일이 쉽지 않았을 것이며, 새롭게 등장한 컨텐츠 명세서를 어떻게 해야하는지 기준도 없는 상태에서 진행하기란 쉽지 않았을 것이다. 그리고 웹 표준 기술을 제대로 숙지하고 적용할 수 있는 전문적인 웹퍼블리셔의 부재는 어제 오늘의 문제가 아니고, CSS 디자인과 같은 웹 표준 기술이 요구되는 작업을 디자이너가 하기에는 무리가 있었을 것이다. 이러한 문제가 있었지만 김철수님은 나름의 노하우를 익히셨고 다음과 같이 공개해 주셨다.

하나, 사이트맵 대신 모듈맵을 만든다.

둘, 모듈 단위로 HTML을 작성한다.

셋, 최종사용자의 UX를 먼저 확정한 뒤 서버 프로그램을 시작한다.

넷, 텍스트 기반으로 먼저 만들고 나중에 세세한 디자인 요소를 삽입한다.

다섯, 위키 방식으로 모두가 개발 소스에 접근하여 수정할 수 있도록 한다.

자세한 설명은 김철수님 블로그에서 직접 확인해 볼 수 있는데, 간단히 코멘트를 하자면 전체 프로세스를 모듈화 하는 것이 중요해 보인다. 과거처럼 거대한 프로젝트를 수백장의 스토리보드에 다 담아 내는 것이 아니라, 기능별로 모듈화된 페이지를 고려하고, 그에 맞는 명세서나 차트를 만들어 개발자와 디자이너에게 전달한다. 그리고 텍스트 기반(XHTML 마크업)의 프로토탑입 설계를 함께 진행하여 디자인 이후에 있을 오류를 최소회 시켜야 한다. 또한, 개발 팀원간의 소통을 위한 도구로 '위키(wiki, 누구나 접근하여 쓰고, 지우고, 수정할 수 있는 시스템)'를 제안하고 있다. 제 의견으로는 'Trac' 의 사용을 추천해 드립니다.'Trac'는 '위키'시스템과 '포럼' 형태를 모두 가지고 있고, 버전관리와 연동이 되기 때문에 프로젝트 게시판으로 사용하기 좋은것 같습니다.

개량형 '웹퍼블리셔 중심의 웹 표준 개발 프로세스'

위 표는 '실전 웹 표준 가이드'와 김철수님의 후기를 읽은 뒤에 살짝 고민을 덧붙여 변형을 가해 본 것이다. 가이드에서도 밝혔고, 나 역시 미리 밝혀두는 것이지만 이러한 웹 표준 프로세스라는 것이 아직은 정형화 되어 있지 못하고, 객관적인 장단점이 불분명한 상태이다. 따라서 프로젝트의 성공 여부를 보장해주지 못한다. 다만, 웹 표준을 준수하는 웹 개발을 할라치면 이러한 고민과 적용이 필요하지 않을까 해서 시작된 것이고, 이렇게 나의 의견까지 덧붙이게 된 것이다.

'개량형'이라고는 했지만 '실전 웹 표준 가이드'에서 소개하는 내용과 크게 다르지는 않다. 용어가 일부 변경('코딩' 보다는 '마크업'이라는 용어로, 일부는 김철수님의이 제안하신 것)되었고, 프로세스가 약간은 더 복잡해졌다고 볼 수 있다. (없던 화살표가 생겼다!) 풀어서 서술하자면 다음과 같다.

• 기획자 : 기획자는 '실전 웹 표준 가이드'에서 제안하는 것과 같이 기획문서를 '프로세스 플로우'와 '컨텐츠 상세화'로 구분하여 작성한다. 차이가 있다면 '프로세스 플로우'와 함께 게시판이나 회원가입/로그인과 같이 모듈화가 가능한 것들에 대한 모듈 명세서 또는 모듈 맵이 함께 작성된다. 그리고 이것은 개발자에게 전달되어 프로젝트 전반에 대한 설계와 프레임 개별 모듈에 대한 설계를 할 수 있도록 한다.
• 디자이너 : 디자이너는 기획/분석 단계에서 만들어진 아이디어를 통해 시안과 스타일 가이드(문서 또는 준하는 이미지 파일)를 만듭니다. 그리고 기획자의 컨텐츠 상세화 문서(기존의 스토리보드로 생각하면 쉬울것 같다)를 받아 화면 디자인을 시작한다. 여기서 완성된 스토리보드를 가지고 시안을 만들지 않는다는 것은 중요합니다. '실전 웹표준 가이드'나 김철수님이 지적했듯이 상세한 스토리보드는 디자이너의 창의력을 둘러싸는 장벽이 될 위험요소가 있습니다. 때문에 기획/분석 단계에서 나온 아이디어나 컨셉 등 필요한 만큼의 적은 정보만으로 시안을 잡아 디자이너로 하여금 충분히 창의력을 발휘할 수 있도록 해야 합니다.
• 개발자 : 개발자는 기획/분석 단계에서 나온 아이디어와 컨셉을 통해 기술적 이슈(HTML문서의 DTD, 인코딩, 폼 영역의 ID값 등)에 대한 개발 가이드를 작성하여 퍼블리셔에게 전달합니다. 그리고 기획자로부터 '프로세스 플로우'와 '모듈 맵'을 전달받아 시스템 설계와 모듈 단위의 개발 준비를 시작합니다. 이후 퍼블리셔로부터 마크업이 완료된 XHTML문서를 받아 프로그래밍과 디버깅 작업을 진행합니다.
• 퍼블리셔 : 퍼블리셔는 기획자로부터 '컨텐츠 상세화 문서' 또는 '페이지 명세서'를 받아 XHTML 마크업을 시작합니다. 이때 개발자로부터 받은 '개발 가이드'를 바탕으로 XHTML 문서의 Doctype 설정, 인코딩 설정, 공통  ID값 등을 결정하거나 적절치 않을시 재논의하여 적용하도록 합니다.(한 번 결정된 Doctype이나 인코딩은 개발 과정에 쉽게 바꾸기가 어려우므로 반드시 확실히 결정을 하고 넘어가도록 합니다.) XHTML 마크업이 완료되면 개발자에게 전달하여 프로그래밍이 진행될 수 있도록 합니다. 이후 디자이너로부터 받은 '스타일 가이드'와 '화면 디자인(PSD 파일)'을 통해 XHTML 문서에 CSS 디자인을 시작합니다. 다음으로 개발자와 소통하며 완료된 페이지를 '퍼블리싱'하면서 CSS 오류 등을 잡아내는 '디버깅' 작업을 진행합니다. 마지막으로 기획자와 함께 '표준화 준수 확인'작업을 하게 되는데 '실전 웹 표준 가이드'에서는 이를 퍼블리셔의 역활로 두었으나 제 경험상 '내가 작업한 것을 내가 테스트 하는 것은 실효성이 적다'였습니다. 다시말해 내 실수를 내가 찾아내는게 쉽지 않았다라는 겁니다. 프로세스대로 디자이너와 개발자가 표준에 맞춘 일정을 따라주었다면 최종적으로 퍼블리셔의 웹 표준 기술(XHTML, CSS, DOM, JS 등)에 의한 크로스 브라우징과 접근성 문제 등이 주요 이슈로 나타날 수 있는데 이를 퍼블리셔 스스로 검증하기란 쉽지 않습니다. 따라서 애초에 기획자에게 책임을 지우는 것이 좋다는 생각을 해봤습니다. 그리고 단계적으로는 최종 단계이긴 하나 기획자는 프로젝트가 진행되는 가운데 지속적으로 디자이너와 개발자, 퍼블리셔가 표준을 준수하고 있는지를 검증해야 합니다.
  

특별히 부연 설명을 드리고 싶은 것은 위 표에서도 나타나 있듯이 양쪽화살표로 되어 있는 굵은 선 프로세스들입니다. 퍼블리셔를 중심으로 기획자와 퍼블리셔, 디자이너와 퍼블리셔, 개발와 퍼블리셔가 지속적으로 커뮤니케이션을 이루도록 되어 있습니다. 또 한가지 기획자와 퍼블리셔가 같은 색 영역으로 묶여 있음을 보실 수 있습니다.

김철수님도 쓰셨듯이 웹 표준 개발 프로세스에서 기획자와 퍼블리셔의 협력은 굉장히 중요해 보입니다. 1차적으로 과거의 스토리보드가 세부화된 개별 문서와 XHTML 문서로 만들어집니다. 이렇게 만들어진 XHTML문서는 디자인이 입혀지기 전에 1차적으로 프로세스 테스팅을 가질 수 있다는 장점이 있습니다. 일종의 프로토타입을 만드는 것입니다. 버튼이 빠져 있거나 페이지가 잘못 연결되어 있거나 추가되는 페이지등을 사전에 고려하여 디자인 이후에 생길 수 있는 추가 작업을 줄일 수 있습니다.

디자이너가 CSS를 다루지 않는 것도 김철수님의 경우와 다릅니다. HTML이나 CSS도 모르면서 웹을 어떻게 하냐는 소리를 하곤 했지만 사실 웹디자이너에게 전문적인 수준의 XHTML과 CSS를 강요할수만은 없다고 생각합니다. (현실적으로 불가능에 가깝습니다.) 때문에 CSS 디자인 역시 퍼블리셔의 영역 안에서 해결해야 한다고 생각합니다. 실제로도 대부분의 퍼블리셔들이 시멘틱한 마크업과 CSS 작성은 자신들의 영역이라고 생각하면서 공부하고 있습니다.

아울러 개발자들이 텍스트로만 이루어진 XHTML 문서를 통한 개발에 적응할 수 있어야 한다고 봅니다. 개발 영역에서는 MVC모델이라는 것이 확실히 자리잡고 있지만 아직도 많은 경우에 XHTML문서 내에 직접 프로그래밍을 입히는 경우가 많습니다. 이 경우 XHTML문서와 서버측 스크립트 언어, CSS 등이 뒤섞여 유지보수가 매우 어려워질 수 있고, 위의 개발 프로세스도 적용하기 힘들 수 있습니다.

▶트랙백은 원격 댓글을 쓰고 이를 알려주는 기능입니다.

초기 블로그에는 없던 새로운 기능입니다. 트랙백은 댓글(reply, 답글), 덧글(comment, talkback 등) 기능의 확장판이라고 보면 됩니다. 기존의 답글과 덧글은 해당 게시판에 독자가 게시물을 읽고 난 뒤 답변이나 감상문을 적는 기능입니다. 따라서 덧글은 해당 게시물 밑에만 남겨집니다. 트랙백은 이보다 좀더 개선된 기능으로 다른 곳에 댓글을 남기는 기능입니다. 즉 해당 게시물에 대해 댓글이나 덧글을 달되 다른 사이트에서 원격으로 덧글을 다는 행위입니다. 이전에는 A 사이트의 '장터' 게시판 '1번' 게시물에 대해 덧글을 남길 경우 이 덧글을 보기 위해서는 A 사이트 장터 게시판 1번 게시물을 읽어봐야만 덧글을 볼 수 있습니다. 하지만 덧글을 지원하는 경우에는 A 사이트의 장터 게시판 1번 게시물에 대한 덧글을 B 사이트의 게시판에서 볼 수 있는 겁니다.

그렇다면 트랙백이라는 기능은 왜 만든 것이며 그 의미는 무엇일까요? 트랙백을 만든 이유와 그 의미는 '내가 쓴 글을 다른 사람에게 알리기 위함'입니다. 트랙백은 이를 지원하기 위한 기능이죠. 트랙백은 다른 사람이 쓴 블로그 문서에 자신이 원격 댓글을 달았다는 사실을 알려주는 행위를 말합니다.

▶트랙백으로 작성한 글은 작성자 블로그의 새 엔트리가 됩니다.

예를 들어 A 사이트의 블로거가 '한글날에 대하여'라는 글을 올렸을 경우 B 사이트의 블로거는 해당 글에 대한 의견을 자신의 블로그 사이트에 트랙백 형태로 올릴 수 있습니다.

트랙백 과정

1. A가 자신의 블로그에 '한글날'에 대한 글을 올렸다.
2. B가 A의 블로그에 올라간 글을 보고 자신의 블로그에 '한글날' 글에 대한 소감을 적어 글을 올렸다.
3. B는 A의 블로그에 트랙백 핑(TrackBack Ping)을 보내 자신의 블로그에 A가 쓴 '한글'에 대하여 코멘트를 달았음을 알려준다.
4. A는 자기가 쓴 '한글날' 게시물에 달린 트랙백을 통해 B가 B의 블로그에 '한글날'과 관련된 글을 올렸다는 사실을 알 수 있습니다.


▶핑은 작은 문장을 뜻하며 트래픽 핑은 트랙백을 알려주는 작은 문장입니다.

트랙백을 건 다음에는 트랙백 핑(TrackBack Ping)이라고 부르는 작은 메시지를 상대편에게 보내줍니다. 물론 이는 프로그램이 알아서 자동으로 보내줍니다. 트랙백을 건 사람은 원 게시물 작성자에게 트랙백 핑을 보내 자신의 사이트에 관련 코멘트를 달았다는 사실을 알리는 겁니다.


▶핑은 인터넷 도구 중 하나로 MS윈도에 프로그램으로 포함되어 있습니다.

핑(ping = Packet Internet Groper)이라고 하는 것은 초기 인터넷부터 사용된 도구 중 하나로 호스터 컴퓨터에 변경 요구를 보내고 응답이 오는 것을 검사해 목적지까지의 도달성을 검사할 때 사용하는 프로그램입니다. 예를 들어 인터넷 주소를 입력했을 때 접속이 잘 안되는 경우 ping 테스트를 통해 해당 호스트가 실제로 운영 중인지 알아낼 수 있습니다. 응답이 없다면 호스트 운영이 멈추었거나 해당 호스트가 존재하지 않는 겁니다. 또한 현재 운영중인 호스트일 경우에는 해당 호스트까지 자료를 송수신하는데 걸리는 시간이 측정되므로 선로 속도 측정에도 사용됩니다. 핑은 윈도에 포함된 프로그램이므로 도스창에서 ping이라고 입력하면 ping 프로그램을 사용할 수 있습니다.

핑은 별도의 도구로만 작동하는 것은 아니고 인터넷의 주요 도구에서 지정된 주소에 재대로 자료를 송수신할 수 있는지 시험하는 용도로 다양하게 활용합니다. 전자우편(Email)의 경우에도 편지를 보내기 전에 ping을 보내 해당 주소록의 전자우편 주소로 편지 배달이 가능한지 시험합니다.

블로그 프로그램에서도 트랙백을 사용할 때 핑 형태로 동작하는 트랙백 핑을 주고받음으로써 트랙백을 거는 겁니다.


▶트랙백은 두 블로그 사이의 연락 수단이 됩니다.

이런 트랙백 형태로 글을 올리면 기존의 댓글보다 편리한 점이 많습니다. 트랙백은 두 블로그 사이트 사이에 연락을 취하는 수단이 됩니다. 트랙백을 통해 A는 B사이트의 글에 관심이 있다는 것을 표명할 수 있고 B는 A라는 사람이 자신이 쓴 글에 대해 관심을 가지고 있다는 사실을 알 수 있습니다.

예를 들어 제로보드와 같은 기존의 게시판은 댓글, 덧글 기능이 있지만 몇 가지 한계를 가집니다.

기존 댓글, 덧글의 단점

1. 긴 글을 작성하기에 적합하지 않습니다.
2. 주인장의 기능 제한으로 대개는 HTML 태그 사용이 제한됩니다. 이 때문에 텍스트로만 된 글을 올려야 합니다.
3. 자신의 홈페이지에도 기록을 남기기 위해서는 해당 게시물에 덧글을 달고 자신의 홈페이지에도 기록해야 하는 이중 수고를 해야 합니다.
4. 자신이 작성한 덧글에 대한 추가 반응을 얻기가 어렵다. 덧글에 대한 덧글로 커뮤니티를 형성하기 어렵습니다.
5. 작성자의 홈페이지 방문을 유도하기가 어렵습니다.

트랙백은 자신의 블로그에 글을 새롭게 작성하는 것이므로 기존 댓글이 지닌 단점을 대부분 보완합니다. 한 두 줄의 짧은 텍스트가 아니라 사진이나 동영상이 들어간 제대로 HTML 문서로 작성할 수 있기 때문입니다. 물론 자신의 트랙백으로 쓴 엔트리(글)가 또 다시 트랙백의 대상이 되거나 링크의 대상이 됩니다. 이는 과거의 게시판에서 제공하지 못하던 기능입니다.


▶일단 트랙백을 '먼댓글(먼거리 댓글)'로 번역하겠습니다.

이 책에서는 트랙백이라는 용어를 많이 사용하지만 한글 용어로 바꾼다면 먼댓글이나 댓글자국이 적당하다고 봅니다. 먼거리에서 단 댓글과 이를 알려주는 기능이므로 '먼거리 댓글'의 의미로 먼댓글이라 할 수 있고, 다른 곳에서 댓글을 달았다는 자국을 남겨주는 것이므로 댓글자국이라고 써도 좋을 것 같습니다.

B라는 내 사이트에 보면 A 블로그의 '한글날' 글에 대하여 댓글을 남긴 상태이므로 원격 코멘트의 의미인 '먼댓글'의 의미를 부여할 수 있습니다. 또한 자신이 남긴 '댓글'을 가리켜야 하므로 '글'의 의미를 강조한다면 '멋댓글'이 적합한 해석입니다. 자신의 사이트에 올린 엔트리를 가리켜 '자국'이라고 말하기는 조금 곤란합니다. '글'이라고 지칭해야 적합하죠. 따라서 트랙백을 쓴 블로거 입장에서 보면 '댓글'을 쓴 것이므로 '먼댓글'을 썼다고 하는 표현이 어울립니다.

반면 A 블로그의 입장에서 보면 자신의 글에 대해 B가 댓글을 남겼다는 자국(흔적)을 남겨주는 것이므로 '댓글자국'의 의미가 더 강합니다. B가 자신의 글에 댓글자국을 남겼다고 표현하는 것이 적절합니다.

댓글 작성자의 관점에서 보는 것을 기준으로 생각한다면 '먼댓글'이라는 낱말이 더 어울린다고 생각합니다. 낱말이 생소한 관계로 일단 이 책에서는 원어인 트랙백이라는 용어로 계속 설명하겠으니 이점 양해 바랍니다.
참고로 트랙백의 한글 용어는 사이트마다 각기 다릅니다. 엮인글, 이어 말하기, 관련글, 되오름글 등등. 다양한 용어가 트랙백을 뜻하는 용어로 사용 중입니다.


▶트랙백은 콘텐트 수집의 수단이 될 수 있습니다.

트랙백(먼댓글)은 여러 가지 면에서 혁신적인 기능입니다. 과거의 게시판 형태는 조회수를 통해서 인기도는 알 수 있지만 그 글을 읽은 사람에 대한 정보는 얻을 수 없었습니다. 물론 댓글을 쓰면서 자신의 홈페이지 주소와 링크를 함께 올리는 방법으로 자신의 존재를 밝힐 수는 있지만 이렇게 하는 사람이 없었고 또 매번 자신의 주소를 밝히기도 어려운 일입니다. 이에 비해 트랙백은 자동으로 자신의 사이트가 링크되므로 사용하기 편리합니다.

두 가지 경우를 생각해봅시다.
영화 '취화선'에 대한 글을 올렸다고 합시다. 이 글이 좋은 글이라면 댓글이 수 십 개 이상 올라오겠지만 댓글을 쓴 사람과 연결되기는 어렵습니다. 반면 트랙백의 형태로 글을 쓴다면 다음과 같은 점이 달라집니다.
'취화선' 글에 대하여 관심 있는 블로거들의 그룹이 만들어지며 해당 블로거가 운영하는 블로그 사이트를 클릭 한 번으로 방문할 수 있습니다.

즉 '취화선' 글을 한 편 올림으로써 취화선과 관련된 그룹이 트랙백을 통해 수집되는 겁니다. 따라서 '콘텐트 수집(content aggregation)'이 매우 용이해지는 겁니다. '취화선' 글 하나를 통해 '취화선'과 관련된 블로그 사이트가 뭉치게 되고 사람들은 취화선 관련 블로그 사이트를 골고루 돌아다닐 수 있게 됩니다. 하나의 글이 해당 게시판에서 게시물 하나로 끝나지 않고 관련 블로그 사이트를 취합하는 결과를 가지는 셈입니다.


▶트랙백은 블로그 프로그램의 기능이자 프로토콜로 공개된 기능입니다.

트랙백은 공개 규격으로 2002년 8월에 무버블타입의 기능으로 발표되었습니다. 따라서 역사는 매우 짧은 셈입니다. 트랙백은 하나의 프로토콜이지만 블로그 프로그램인 무버블타입(Movable Type) 2.2의 한 기능으로 발표되었기 때문에 프로토콜이자 무버블타입의 기능이라는 양면성을 가지고 있습니다. 트랙백 규격은 국제규격으로 서로 다른 서비스와 프로그램 사이의 트랙백이 가능하게 호환성을 부여합니다.

트랙백의 기본적으로 공개로 운영되도록 설계되었습니다. 그 이유는 블로그 자체가 공개와 네트웍을 목표로 만든 개념이고, 트랙백 역시 특성 상 좀더 많은 블로그 사이트가 지원해야 트랙백의 가치가 빛나기 때문입니다. 이처럼 트랙백 기능은 공개로 계획되었기 때문에 다른 블로그 툴도 트랙백 기능을 쉽게 구현할 수 있습니다.

트랙백을 지원하는 블로그 프로그램

Movable Type, B2, Bloxsom, Blojsom, Nucleus, Radio, TrackBack Standalone Tool

트랙백은 블로그의 필수 조건이 아니지만 많은 블로그 사이트에서 트랙백을 지원하는 추세이므로 앞으로 나올 블로그 프로그램은 대부분 트랙백을 지원할 것으로 보입니다.


▶트랙백은 푸시 형태이므로 트랙백이 걸린 글은 수정하기 어렵습니다.

트랙백은 현재 한 가지 중요한 특징을 가지고 있습니다. A 블로거가 자신의 블로그에 글을 올렸을 경우 이 글에 대한 트랙백이 달리면 A 블로거 자신도 원문을 수정할 수 없다는 점입니다. 그 이유는 현재 국내외 블로그 툴에 적용된 트랙백이 대부분 PUSH 방식이기 때문입니다. 때문에 이미 밀어낸 글에 대해서는 글을 수정하고 싶어도 수정할 수가 없습니다. 따라서 트랙백을 지원하는 경우에는 자신이 쓴 글에 트랙백이 달리는 순간 더 이상 수정 불가능한 글이 된다는 점을 심각하게 고려해야 합니다.

우리나라의 경우 국내 최초 블로그 사용자 모임으로 알려진 WIK(한국어 웹로그 모임, wik.ne.kr)에서 블로그에 대한 트랙백을 활발하게 주고받음으로써 블로그에 대한 정보를 공유합니다. 개인 블로그 사이트는 트랙백을 적용하는 곳이 많지만 아직까지 국내 포탈 업체는 트랙백을 지원하는 곳이 드뭅니다. 업체로는 웹 솔루션 업체인 온네트에서 제공하는 블로그 서비스인 이글루스(http://www.egloos.com)에서 트랙백(TrackBack)을 처음으로 적용시켰습니다. 네이버의 블로그는 트랙백 기능을 지원하기는 하지만 한정된 공간에서만 지원합니다.

▶RSS는 웹사이트끼리 자료를 주고받기 위한 규격입니다.

RSS는 웹사이트의 결합(신디케이팅, 배급망 만들기)과 자료 구축, 교환을 위해 필요한 규격으로 공개 프로젝트인 아톰 프로젝트(옛날: 에코 프로젝트)와 경쟁 관계에 있습니다. 현재 아톰과 RSS 2.0이 업계 표준을 둘러싸고 선의 경쟁을 벌이고 있는 중입니다.

RSS는 뉴스, 블로그 등 자주 업데이트(갱신)되는 성격의 사이트를 위한 XML 기반의 포맷으로 자료 교환을 위한 규격입니다. 웹 사이트끼리 서로 자료를 주고받기 위한 규격이라고 보면 됩니다. RSS는 'RDF Site Summary' 또는 'Really Simple Syndication', 'Rich Site Summary' 등의 약자입니다. 해석이 다양한 이유는 다양한 규격의 RSS가 존재하기 때문입니다.


▶RSS 파일을 이용해 사이트의 각종 정보를 수집할 수 있습니다.

RSS는 XML 서비스 중에서는 가장 성공적이라는 평을 받고 있습니다. 다소 복잡한 원리에도 불구하고 웹 사이트를 통해 콘텐트 정보를 교환하는 커뮤니티 표준으로 자리잡은 상태입니다. 요즘 파이썬과 같은 언어가 새롭게 떠오르고 있는데 파이썬이 RSS에 적합한 도구이기 때문이라는 점도 한 이유가 됩니다.

RSS 규격에 따라 만든 RSS 파일은 특정 사이트의 정보를 담고 있습니다. 예를 들어 B 사이트의 운영자는 A라는 사이트의 각종 정보(갱신된 글의 제목, 링크, 주요 내용 등)를 RSS 파일을 통해 수집한 다음에 자기가 운영하는 B 사이트에 올려놓을 수 있습니다. 이렇게 하면 B 사이트 방문자는 A 사이트를 방문하지 않더라도 A 사이트의 최신 변환 내용을 쉽게 알 수 있습니다.

RSS 역시 트랙백만큼이나 활용도가 큽니다. 만약 자신이 A 뉴스 사이트를 운영한다고 합시다. 이때 과거의 방식으로는 B, C, D, E 뉴스 사이트의 기사를 퍼오는 수고를 하면서 직접 자신의 사이트에 글을 올려야 했습니다. 좀더 쉬운 방법은 B, C, D 사이트의 최신 뉴스 제목에 링크를 걸어 자신의 사이트에 링크를 올리는 것입니다. 그렇지만 뉴스 제목만 볼 수 있고, 그나마 이것마저 수동으로 작성해 링크를 걸어야 하는 불편이 있었습니다. 그렇지만 이들 사이트가 RSS를 지원한다면 A 사이트 운영자는 B, C 사이트의 RSS 파일을 읽어 자동으로 자신의 사이트에 B, C 사이트의 최신 뉴스와 링크, 요약 발췌 내용을 올려놓을 수 있습니다. 즉 손도 대지 않고 거대한 뉴스 사이트를 만들 수 있는 겁니다.

또 각종 영화 사이트의 RSS 파일을 읽어서 자신의 사이트를 국내 각 영화 사이트의 최신 소식을 전하는 종합 영화 소식 사이트로 만들 수도 있습니다. 이처럼 RSS는 콘텐트 수집이나 콘텐트 신디케이트(syndicate, 콘텐트 배급망)를 구성하기에 매우 좋은 도구입니다.


▶개인도 RSS 구독 프로그램을 이용해 RSS 기능을 사용할 수 있습니다.

RSS는 사이트끼리만 사용하는 도구가 아닙니다. 개인 사용자도 RSS 구독(reader) 프로그램을 사용해 각 사이트의 콘텐트 정보를 쉽게 구할 수 있습니다. 즉 B 사이트를 직접 방문하지 않더라도 RSS 구독기(리더기, 구독 프로그램)를 이용해 B 사이트의 최신 콘텐트가 무엇인지 자신의 PC에서 확인할 수 있습니다. RSS 리더 프로그램을 설치하고 환경을 설정하면 RSS 구독기는 자동으로 알아서 설정한 사이트를 돌아다니면서 RSS 정보를 수집해 보여줍니다. 개인 사용자는 이렇게 수집한 RSS 정보를 통해 관심이 가는 콘텐트만 골라 보면 됩니다.


▶[XML] 아이콘은 RSS를 지원한다는 뜻입니다.

블로그 사이트를 방문해보면 많은 사이트에서 블로그 사이트들을 지나다 보면 'Syndicate this site (XML)'이라고 표기하거나 주황색 계통의 [XML] 아이콘이 붙어있는 것을 볼 수 있습니다. 이것은 RSS 파일의 링크를 표시하는 것입니다. 즉 이 사이트에서는 RSS 파일을 제공한다는 뜻입니다.
이들 사이트에서 제공하는 RSS 파일은 보통 index.xml, index.rdf, rss.xml 등의 이름을 가지고 있습니다.

요즘은 하트 모양의 아이콘을 함께 붙이는 경우가 많습니다. 얼핏 보면 무슨 알약(어린이용 영양제 같은) 아이콘 모양인데, RSS를 지원한다는 아이콘입니다. 알약 색이 조금씩 다르고 어떤 알약에는 'RSS' 'Love RSS' 'I Love RSS'등의 글씨가 있습니다. 아이콘을 두 개 이상 붙여놓은 경우에는 규격에 따른 지원을 표시하는 경우입니다. 예를 들어 RSS 1.0 규격 지원 아이콘에는 index.rdf 파일이 링크되어 있고, RSS 2.0 규격 지원 아이콘을 누르면 index.xml 파일이 링크되어 있는 경우가 보통입니다.

▶RSS 공급을 피드(feed)라고 부릅니다.

한 사이트에서 다른 사이트의 주요 글들을 RSS를 통해 공급하는 것을 RSS feed(공급) 서비스라고 합니다. 그리고 이렇게 RSS 기사를 공급(feed)해주도록 도와주는 프로그램을 RSS feed 프로그램이라고 부릅니다.

title; More on CardSpace and XRI
link; http://xditao.blogspot.com/2007/03/more-on-cardspace-and-xri.html

XRI/XDI는 현재의 URI 기반 주소 체계 위에 추상화된 계층을 구축하려는 기술입니다. 가령 제 블로그 주소를 =ayo/+blog 로 표시하고, 메일 주소를 =ayo/+email 로 표시하는 것이죠. 나를 가리키는 식별자인 =ayo 만 기억하면 쉽게 모든 정보에 접근할 수 있는 서비스를 제공할 수 있습니다. 프라이버시와 보안을 고려하여 Link Contract라는 접근/공유 제어 기술 또한 포함되어 있습니다.

XRI/XDI를 CardSpace와 연계하여 사용한다면 어떨까요? Andy Dale은 CardSpace와 XRI/XDI로 연계로 인해 얻을 수 있는 3가지 이점을 소개합니다.

1. Portability

CardSpace은 한 컴퓨터에서만 사용할 수 있습니다. CardSpace가 아무리 다양한 인증 기술을 커버하고 많은 사이트에 도입되더라도, 언제 어디서나 사용할 수 없다면 큰 문제가 됩니다.
Higgins 프로젝트의 HBX Card Selector는 이 문제를 깔끔하게 해결해줍니다. 로컬 PC에 Card를 저장하는 것이 아니라 신뢰할 수 있는 사이트에 저장합니다. 사용자는 처음에(boostrap) 사이트 로그인을 하고, 사용자의 로그인을 요구하는 다른 사이트에는 i-name을 입력하고 Card를 선택하여 인증절차를 통과하는 시나리오가 가능합니다.

2. i-Name authentication

XDI는 데이터 교환에 관한 기술을 정의합니다. 그 데이터의 한 종류로 Assertion을 사용한다면 i-Name 인증이 가능합니다. Andy Dale은 EZI Broker라는 사이트를 활용하여 Managed Card를 생성하고, 사용자의 XRDS에 해당 내용을 추가하는 방법을 제안합니다. 사이트가 i-name을 resolution할 때, XRDS의 내용을 이용하여 Assertion의 발급 요청을 할 수 있습니다.

3. Pointers as Data

CardSpace는 사이트가 요청하는 데이터를 Managed Card로 직접 제공하거나 다른 사이트에 있는 데이터를 가져와서 제공하게 됩니다. 즉, 실제로 데이터를 전송합니다. 하지만 XRI/XDI는 데이터의 위치(Pointer)를 전달할 수 있습니다. Pointer는 C 언어의 포인터와 마찬가지입니다. 데이터가 아닌, 데이터가 저장된 위치 정보를 전달하는 것입니다. 위치 정보를 이용하여 실제 데이터를 해석(dereferencing)하는 작업이 필요한데, 이 때에 여러가지 보안 요소가 적용될 수 있습니다. XDI의 Link Contract가 사용되겠죠.

Portability와 i-Name Authentication은 확실히 좋을 것 같습니다. 3번은 약간 애매하네요. 직접 데이터를 전송하는 것보다 위치 정보를 전송하는 것이 더 좋은 경우가 무엇이 있을까요? Link Contract를 맺어, 한 번 위치 정보를 제공하면 RSS 처럼 정보가 수정될 때마다 PULL/PUSH 방식으로 제공하는 것이 그럴듯 합니다. 다른 이점은 무엇이 있을지 생각해봐야겠네요.

일단 위키백과에서 가져온 정의.

오픈아이디(OpenID)는 웹에서 자신의 계정을 통합적으로 관리하는 방식으로, 흔히 쓰이는 중앙집중식 로그인에 비해 비교적 느슨한 방식으로 사용자를 인증한다. 즉 각각의 사이트에서 아이디와 비밀번호를 관리하는 대신, 오픈아이디를 지원하는 사이트에서는 사용자 인증을 독립된 각 서비스 제공자에게 맡기고, 그러면 개별 오픈아이디 제공자가 사용자를 인증해준다.

OpenID 커뮤니티에서 가져온 보다 쉬운 정의.

여러 업체의 서비스들을 매번 가입하지 않고 모두 사용할 수 있는 하나의 아이디 입니다.
OpenID 에서 ID 는 인터넷 주소 (URL) 로 표현되며, 인증 서비스를 통해서 사용자가 ID 의 소유자 임을 인증합니다.

즉 하나의 아이디로 여러 사이트를 이용할 수 있다는 말이다. 여기서 아이디의 형태는 기존에 알고있는 영문+숫자의 조합이 아니라 url 형태이거나 최근에는 XRI형태라고 하는데 후자의 경우는 디지털주소 형태라는데 구체적인 내용은 영어 해석에 능한 분이라면 위키백과 영문판에서 확인하시라.

그렇다면 왜 오픈아이디가 각광받는지 그 장점을 알아보자.

1. 하나의 아이디로 여러 사이트에 이용가능하므로 매번 사이트에 가입해야하는 번거로움을 해소할 수 있다.

2. 공용아이디니까 사이트마다 여러 아이디를 사용함으로써 오는 혼란도 어느 정도 막을 수 있다.

> 자주 사용하지 않는 사이트인데도 정보를 보기 위하여 가입하게 되는 경우가 있다. 괜히 찜찜한 기분을 가실 수 없고, 게다가 매번 개인정보 입력하는 것도 상당히 귀찮다. 어쩌다 내가 사용하는 아이디가 이미 사용중이라고 뜨면 정말 낭패 -_-; 그래서 생각해낸 새로운 아이디는 훗날 다시 그 서비스에 로그인할 때 기억이 나지 않는 경우를 만들기도 한다. 실제로 나는 야후에 아이디가 있는데 야후를 하도 안써서 기억도 안난다.

3. url 형태이므로 본인의 블로그나 미니홈피를 주소를 ID로 사용함으로써 기억하기 쉬우며  홍보효과 비슷한 것을 누릴 수 있다.

> 오픈아이디는 만약 내가 myid.net에서 인증을 받아 사용한다고 했다면, ABCD.myid.net 이라는 형태로 사용하게 된다. 뭐야 이건? 더 길고 어렵잖아! 라고 할 수도 있다. 하지만 이걸 내 블로그 주소로 사용할 수 있다면? 현재 서비스를 제공중인 곳은 이글루스, 태터툴즈, 티스토리, 그 밖에 설치형 블로그다. (자세한건 여기서 확인) 만약 네이버에서도 오픈아이디를 적용한다면 blog.naver.com/ABCD 이게 내 아이디가 되는 거다. 어디에서 비로그인 상태로 댓글을 남길 때 이름/ 비번/ 내용을 입력하는데 여기서 이름/비번 대신 내 블로그 주소를 남기는 것! 그러면 내 댓글을 보고 누군가 반박이나 동의를 하고 싶다면 그 블로그 주소를 누르고 들어와서 커뮤니케이션 할 수 있는거다. 미니홈피나 블로그는 요즘 거의 하나씩은 있으니까 확실히 편하겠지?

4. 암호 변경의 문제도 훨씬 간편하며 어려운 암호로 설정해도 하나로 통일되므로 보안면에서 유리하다.

-> 여러 사이트에 가입하는 것은 그만큼 아이디 노출이 많이 된다는 거다. 대부분 어느 사이트에 가입하든 비슷한 아이디를 사용하니까- 그렇게 노출이 많이될수록 스팸의 공격을 받을 확률도 높아진다. 게다가 이번에 옥션에서 개인정보유출 해킹사건 이후 모든 사이트마다 비밀번호 변경하라고 난리인데, 이미 손에 익은걸 일일이 바꾸기란 정말 귀찮아 죽을 노릇이다. 오픈아이디는 하나만 바꾸면 전부 쓸 수 있으니 얼마나 편한가! 원래 개인정보보호를 위해서 암호는 3달에 한 번은 바꾸라고 하는데 난 벌써 몇년째 같은걸 쓰는지;;;

오픈ID 어떻게 사용하면 되지?

현재 오픈ID 인증 서비스를 제공하는 업체(Open ID Provider)는 3군데다.

다음의 오픈ID(아직은 베타서비스), 안철수연구소의 IDtail, 오픈마루의 myId.net.

이 중에서 마음에 드는 한 곳을 골라 인증절차를 거치면 된다. 나는 마이아이디에서 가장 먼저 접했기 때문에 마이아이디를 기준으로 설명하겠다.

1. 마이아이디에서 myID 발급받기를 통해 간단한 인증을 거치면 오픈아이디를 얻게 된다.

2. 댓글이나 정보를 보고 싶은 사이트에서 로그인을 하라고 떴는데 그 창이 아래와 같은 오픈ID 적용 사이트라면 내 ID를 적는다.

3. 그러면 내가 인증받은 업체의 사이트로 연결되며, 거기서 비밀번호를 입력하고 로그인한다.

4. 로그인을 한 뒤엔 내가 처음에 로그인하고자 했던 사이트의 url이 보여지고 이는 기록으로 남는다.

5. 이 과정을 거치면 처음 이용하려던 사이트에서 간단한 약관체크 후 사이트를 이용할 수 있다.

그렇다면 지금 국내에서 오픈아이디를 지원하는 사이트(consumer)는 어디어디가 있을까?

스프링노트, 미플레이, 이글루스, 제로보드, 위자드 닷컴, 라이프팟 등 국내 사이트와 해외사이트가 있다. 국내 사이트는 지금 확인가능 한 곳이 약 30-40군데 인듯 싶은데, 웹 2.0 신생서비스들로 혁신적인 서비스를 좋아하는 사이트에서 이를 허용하고 있다. 앞으로 점차 늘어날 것으로 보인다. (1. 로고형으로 확인하기!  / 2. 좀더 다양하지만 텍스트로 확인하기!)

하지만 과연 좋은 점만 있을까?

1. 하나의 사이트에서 개인정보를 통합관리하는 것은 그만큼 위험부담도 따른다.

인증사이트가 해킹을 당한다면? 그 서비스를 통해 로그인할 수 있었던 모든 사이트로 그 피해가 번질 것이다. 위의 장점 4와 상반되는 내용이지만, 결과적으로 중요한 것은 인증 제공업체의 철저한 보안이겠다.

2. 위에서 잠깐 언급했던 사항인데, 기억해야할 아이디가 더 길어졌다는 점은 제법 치명적이다.

사람들은 복잡하고 어려운 걸 싫어한다. 사실 꽤나 웹에 관심있다는 나도 오픈아이디가 번거로워 거의 사용하지 않고 있다. (사실은 아직 내가 자주 가는 사이트 중엔 오픈아이디를 허용한 곳이 별로 없다 -_-; 게다가 오픈아이디 아니라 이미 가입한 아이디로도 사용이 가능하니까 필요를 못느꼈다;) 그런 나도 이모양인데, 대부분의 인터넷 이용자들은 어떻겠냔 말이다. 실제로 글을 보다보면 아이디가 길어서 불편하다는 의견이 많았다.

3. PC방 등에서 철저한 개인정보 보호가 필요하다.

한 번 인증을 거치고 나면 오픈아이디를 허용하는 다른 사이트를 이용할 때는 별도의 비번 입력(인증과정)을 거치지 않는다. 이것은 물론 편리하기는 하지만 만약 PC방 등 공용 컴퓨터에서 오픈아이디를 사용한 뒤, 하나의 사이트만 창을 닫고 나왔다면 다른 사이트는 아직 인증된 상태이므로 내 아이디가 도용될 수 있다. 따라서 공용 컴퓨터에서는 모든 사이트를 로그아웃하고, 브라우저를 다 끄는 등 각별한 주의가 요구된다. 하지만 사실 이건 다른 포털 등에서도 마찬가지로 적용되는 부분이긴 하다. 조금 더 주의가 요구되지만.

4. 오픈아이디는 위의 사용방법에서 보았듯이 내가 정보를 이용하려는 사이트 내에서 모든 것이 이루어지는게 아니라, 인증업체의 페이지 내에서 로그인 과정을 거치고 다시 사이트로 돌아와야 한다. 이 과정은 다소 번거롭게 느껴질 수도 있다. 역시 사람들은 편한 걸 좋아하니 말이다.

오픈 ID 앞으로는?

오픈아이디는 개방형서비스라는 점에서 웹2.0의 대표서비스라 할 수 있다. 오픈아이디는 지난 2005년 미국의 개발자인 브래드 피츠패트릭이 제안한 기술로써 이미 해외에서는 9천개 정도 되는 사이트가 허용했다고 하지만, 국내는 미미한 수준이다. 야후와 구글이 오픈아이디를 허용한다고 했고 MS도 그러한 움직임이 있다니 국내 포털들에도 빠른 시일 내 반응이 오지 않을까? =) (실지 국내 포털에서 이를 기대하기는 좀 어려울 듯 싶다 T-T 우리나라 포털들은 제법 폐쇄적이란 말이야;)

지금 프로바이더인 3업체는 IT에서는 나름 탄탄한 기업들이니 도중에 서비스가 중단되면 어쩌지? 라거나 보안에 대해서 걱정하는 것은 조금 덜어놓아도 될 것 같다. 하지만 나날이 보안이 중요해지는 시점이니만큼 철저한 관리가 중요할 것이다.

또, 세계적인 트렌드가 되어가는 서비스임에도 불구하고 국내에는 consumer가 많지 않아서 허울뿐인 서비스가 되지 않도록 좀 더 많은 업체에서 마음을 열고 이를 허용해야 할 것이다. 개인적으로 굵직한 포털들에서 (특히 블로그랑 미니홈피 쓰고 있는 네이버랑 SK컴즈!!)

최근에 다음하고 AhnLab, 오피니티, 더블트랙, 오픈마루 스튜디오에서 합동으로 대대적인 이벤트를 진행하기는 했지만 아직까지 사람들은 오픈아이디에 대해 모르고 있다. 나도 이번 기회가 아니었다면 그냥 통합 로그인 시스템 정도로 밖에 생각하지 못했을 테니까.. 좀 더 홍보를 겸하면 좋겠다 =) 일단 알아야 뭘 쓰지 않겠어?

아직 미흡하긴 하지만, 오픈아이디는 앞으로가 기대되는 서비스니만큼, 모두가 공유하는 서비스가 되었으면 좋겠다. =)

그 밖에 참고하면 좋은 것

국내 OpenID 커뮤니티 : 오픈아이디에 대한 개괄적 설명과 여러가지 정보 제공
OpenID FAQ in korea : 오픈아이디 이해를 돕기 위한 FAQ
[알아봅시다] 오픈아이디 디지털타임스 IT/과학 | 2008.01.22 : 가장 기본적인 내용이 잘 정리된 기사

웹 2.0의 개념도 아직 완전히 정립되지 않은 단계에서, 정보통신 업계와 컴퓨터과학 학계에서는 벌써 “웹 3.0”에 대한 논의가 시작되고 있다. 웹 3.0은 좀 더 인간에 가깝고 영리한 검색 엔진의 등장과 긴밀히 연계될 것이라는 예상이 전문가들로부터 나오고 있다.

뉴욕 타임즈의 존 마르코프(John Markoff)가 웹 3.0은 컴퓨터가 온라인 데이터를 기반으로 하나의 결론을 끌어내는데 필요한 효율적 시스템을 제공하는 기술이라고 정의한 이래 이 정의가 널리 알려졌다.

또한, Project10X가 발표한 “Semantic Wave 2008：Industry Roadmap to Web 3.0 Multibillion Dollar Market Opportunities(시맨틱의 물결 2008 ： 수십억 달러 시장의 기회)」라는 보고서에서 웹 3.0은 “인터넷을 유저에게 보다 편리하고 즐겁게 하기 위해 의미를 표현하고 지식을 이어주는 것”이라고 정의되고 있다. 아울러, 웹 4.0은 유비쿼터스 웨이브 환경으로 이어가며, 인간과 그 외의 것이 명확한 의사를 가지면서 서로 통신하는 것이라고 정의하고 있다 [관련기사].

　영국신문 Guardian 웹판은 “웹 3.0을 정리한다고 하면 레코멘데이션(Recommendation)과 개인화이다”라는 기사를 게재하였다. 웹 3.0의 정의는 ReadWriteWeb에서도 몇번 정의한바 있다.

　영국신문 Guardian는 현지시간 2월 4일, Jemina Kiss씨가 웹 3.0은 레코멘데이션을 가리키는 것이 될 것이다라고 시사하였다. “만약 웹 2.0을 한마디로 「상호작용」이라고 한다면, 웹 3.0은 레코멘데이션과 개인화가 될 것이다”라고 同씨는 말하고 있다. Kiss씨는 Last.르, Facebook의 Beacon을 예로 들면서 개인화된 레코멘데이션 서비스가 새로운 음악, 제품, 레스토랑 등의 정보를 우리에게 가져오는 것으로 웹의 미래상을 그리고 있다고 하였다.

　지금까지 웹 3.0에 대해 최근 몇 년동안 수 없는 정의들이 산재해 있다. 지금까지의 거의 모든 기사에서 공통된 웹 3.0 테마의 하나는 시맨틱웨이브로 끊을래야 끊을 수 없는 관계에 있는 것 같다.

　2007년 4월, ReadWriteWeb은 독자들이 생각하는 웹 3.0의 정의 콘테스트에서 우승한 Robert O`Brien씨의 정의는 “비집중화한 비동기의 나(decentralized asynchronous me)”라고 하였다.

　“웹 1.0은 집중화된 그들, 웹 2.0은 분산화된 우리, 그리고 웹 3.0은 비집중화한 나”라고 정의하고 있다. “웹 3.0은 자신의 환경에 누군가를 끌어 들여 보다 강하게 제어하고 싶은 나와 관계된 것이다. 웹 3.0은 나의 주의를 대상으로 누구에게, 혹은 무엇에게 자신을 보여주는 것이다. 이것이 나에게 있어서 보다 효율적인 커뮤니케이션이다.”라고 O`Brien씨는 말했다.

　O`Brien씨의 말은 기본적으로 Kiss씨의 말과 같은 개인화와 레코멘데이션이다. 그리고, 이것은 시맨택웨이브에서 제공하거나 약속하고 있는 것이기도 하다. 시맨틱웨이브의 비전을 유저에게 알리는(판매하는) 가장 간단한 방법은, 그들의 생활을 편리하게 해 준다고 이야기를 하는 것이다. 기계가 인간의 말을 이해하여 유저의 지식을 이용할 수 있다면, 우리가 언제 무엇을 원하는지 알 수 있는 웹을 만들 수 있다.

ReadWriteWeb의 Sramana Mitra씨는 웹 3.0에 대해 개인화에 콘텍스트(Context)를 더하는 것이라고 하였다. “MyYahoo의 개인화 시도는 만족할 수 없는 한정적인 것으로, 문제는 출발 지점이 되는 콘텍스트를 가지지 않은 것에 있다.”라고 지적하고 있다. “내가 예상하는 웹 3.0은 구성요소가 다수 존재한다. 예를 들면 영화(Netflix)나 음악(iTunes), 요리?음식, 일하는 여성, 싱글 부모 등의 콘텍스트를 기본으로 알게 되는 것이다. 그리고 그 콘텍스트들의 집합으로 소비자가 필요로 하는 것을 이끌어내는 웹 3.0의 공식을 만들어낼 수 있다”, 바꾸어 말하면, 웹 3.0은 자신이 갖고 싶을 때에 갖고 싶은 정보를 (적절한 콘텍스트로) 피드 해 주는 것이다.

위에서 말한 웹3.0의 공식은 Web 3.0 = (4C + P + VS)이다. 4C중에서 3C는 Content, Commerce, Community이고, 네번째 C가 Context 인 것이다. P는 Personalization 이고, VS는 Vertical Search로 정의하고 있다.

참고자료 : Readwriteweb, 2008/2/5


원본 : 2008년 시맨틱의 물결, 웹 3.0의 모습

웹 2.0의 개념도 아직 완전히 정립되지 않은 단계에서, 정보통신 업계와 컴퓨터과학 학계에서는 벌써 “웹 3.0”에 대한 논의가 시작되고 있다. 웹 3.0은 좀 더 인간에 가깝고 영리한 검색 엔진의 등장과 긴밀히 연계될 것이라는 예상이 전문가들로부터 나오고 있다.

시맨틱 웹 분야는 거품이라는 반발이 있을 정도로 언론을 통해 많은 홍보되었고, 대형 기업들이 많이 뛰어든 분야이다. 그러나 요란한 출발에 비하면 주류로의 편입은 늦어지는 편이다. 하지만, 시맨틱 웹이 현재처럼 특정 분야에서만이 아니라 전체 웹 공간으로 확대 도입될 때 웹 3.0의 시대가 열릴 것으로 예측되고 있다[GTB2007030578].

이러한 시맨틱 기술과 시장을 다룬 “Semantic Wave 2008：Industry Roadmap to Web 3.0 Multibillion Dollar Market Opportunities(시맨틱의 물결 2008 ： 수십억 달러 시장의 기회)」라는 제목의 400 페이지 리포트를 Project10X가 발표했다. 이 리포트는 소비자 전용의 시맨틱 기술과 기업 어플리케이션의 등장, 그리고 웹 2.0에서 이른바 「웹 3.0」으로의 진화에 대해 다루고 있다.

　이 리포트에서 웹 3.0은 “인터넷을 유저에게 보다 편리하고 즐겁게 하기 위해 의미를 표현하고 지식을 이어주는 것”이라고 정의하고 있다. 즉 시맨틱 웨이브 그 자체이며, 「웹 3.0」이라는 말은 별로 좋아하지 않지만, 시맨틱 기술이 현재의 소셜 웹 시대를 강화하고 넓히는 시대에 접어 들은 것에는 동의 한다. 이와 관련된 기사는 ReadWriteWeb의 Alex Iskold가 최근 쓴 「시맨틱 웨이브 : 유저층에서 활용의 기폭제가 된 킬러어플리케이션은?」이라는 기사이다.

아울러, 시맨틱 웨이브에서 뜻하는 ‘의미표현’은 인간뿐 아니라 기계(프로그램)도 이해할 수 있는 ‘의미’를 뜻한다. 기계가 이해한다는 말은 매우 중요하다. 즉, 인간이 메타정보를 주면, 그것을 이해하여 프로그램이 의미에 따라 정보를 통합하여 제공할 수 있어야 한다는 전제조건을 가정한 것이다. 따라서 응용분야에서 기계가 하나로만 해석할 수 있는 ‘의미’단위를 가정해야 한다는 것이다.

또, 이 리포트에서 「웹 4.0」을 다음과 같이 정의하고 있다. “웹 4.0은 유비쿼터스 웨이브 환경으로 이어가며, 인간과 그 외의 것이 명확한 의사를 가지면서 서로 통신한다”. 다음의 그림은 이러한 웹의 버젼을 잇는 개념을 잘 나타내고 있다.

World Wide Web Consortium(W3C)는 10년만에 HTML을 발표하였다.

　미국 시간 1월 22일에 릴리스 된 「HTML 5」의 최초 워킹 드래프트는 개발자, 브라우저 벤더, 콘텐츠 프로바이더가 참가하는 W3C HTML Working Group의 작업에 의해 탄생했다.

　HTML 5는 2010년까지 최종 권고할 예정이지만, 음성이나 멀티미디어 콘텐츠를 제어하는 새로운 API군을 포함시키고, HTML을 오늘의 리치한 인터넷 환경에 맞추어 진화시키는 것을 목적으로 하고 있다.

　“HTML은 말할 필요도 없이 매우 중요한 규격이다”라고 HTML 최초 버젼의 저자이며 W3C의 디렉터인 Tim Berners-Lee씨는 말한다. “나는 브라우저 벤더를 포함한 개발자 커뮤니티가 협력하고, 웹에 대한 생각을 나눌 수 있는 자리가 있다는 것에 기쁘게 생각한다. 많은 개발자의 의견을 정리하는 것도 대단한 작업이지만, 무엇보다도 혁신성과 안정성의 밸런스 및 이상주의와 실용주의의 밸런스를 맞추는 일도 큰 과제이다”라고 Berners-Lee씨는 말했다.

W3C HTML Working Group은 웹의 진화에 대해 연구하면서, Ajax의 발전 프로세스 등의 동향과, 단순하고 정적인 페이지 집합체를 넘어 오늘의 웹에 어울리는 새로운 규격을 작업하고 있다.

HTML 5의 새로운 기능은 오늘날 인기 높은 웹 사이트에서 대부분 사용되고 있는 요소가 규격화되어 상호 운용성이 높아지게 된 것이다. 최종적으로는 authoring tool 적용의 시작과 동시에 보급되는 것이라고 전문가들은 주장하고 있다.

　HTML 5는 클라이언트측의 데이터 보존에 초점을 맞추어 유저가 문서를 쌍방향으로 편집할 수 있도록 하고 있다. 또, HTML 문서를 손쉽게 취급하기 위해 간결한 룰과 함께 에러를 수정하는 방법에 대한 설명서를 제공하는 것으로 코스트 문제에도 대처한다고 한다. 이러한 강화와 함께, 화면에 친숙한 페이지 섹션이나 네비게이션 요소를 도입한 새로운 기능도 계획되고 있다. HTML 5는 「고전적인」HTML 과 XML 웹 어플리케이션의 모바일 플랫폼으로 확장키 위한 상호 운용성도 목적으로 하고 있다.

“웹에는 방대한 양의 데이터가 HTML 형식으로 기록되어 있지만, 특정 프로그램으로 동작하도록 코드화 되어 있는 케이스도 많다. 이러한 정보를 잃지 않으려면, 설계된 특정 프로그램이 없어도 정보를 처리할 수 있는 방법을 알아 둘 필요가 있다”라고 모바일 브라우저 기업 Opera의 최고 표준 기술 책임자(CSO)인 Charles McCathieNevile씨는 말한다. “새로운 HTML 5의 초안은 사양에 따라 기존 HTML을 신뢰성 높은 방법으로 명기할 수 있으며, 향후 이 사양들에 따라 자유롭게 적용할 수 있게 된다. 또, 과거 10년 이상에 걸쳐서 적용되고 받아 들여져 온 중요한 몇 개의 웹 기능에 대한 사양도 추가되고 있다” 라고 McCathieNevile씨는 말했다.

　HTML 5의 초안은 Microsoft 등의 벤더가 브라우저 상호 운용성을 주장을 강하게 하고 있는 시기에 공개되었다. Microsoft는 지난 12월 「Internet Explorer 8」(IE8)이 Web Standards Project의 일부인 「Acid2」테스트에 합격한 것이다. “Acid2의 렌더링에 성공한 것은 우리가 IE8의 릴리스에서 본격적인 상호 운용성, 규격의 준거 및 호환성을 강조하는 결과로 IE8에 있어서 획기적인 사건이다”라고 Microsoft의 관계자는 말하고 있다.

　그러나, 일부 전문가는 Microsoft가 Acid2에 합격했다고 표명하는 것은 시기 상조라고 주장하고 있다. Microsoft는 IE8의 렌더링 모드의 방법에 관해 일부 개발자로부터 비판을 받고 있기 때문이다.

o HTML5는 기존의 정적인 페이지를 넘어, 쉽고 역동적인 멀티미디어화된 형식으로 발전할 것이며, 모바일로의 진화도 가속화 될 것임

  - 위키피디아, UCC, 블로그 등 사용자가 생산한 콘텐츠를 담기 위해 기존 HTML 형식에서 벗어나 상호 연결성을 강조한 협업과 공유에 기반한 웹 애플리케이션의 요구에 의해 탄생

왜 RSS를 지원해야 하는가?

RSS는 정보의 배급, 배포, 수집에 관한 표준 포맷이다.

즉 정보를 효과적으로 전달하고 수집하고 검색하며 관리할수 있는 새로운 방법에 관한 것이다. 이것은 기존 HTML 중심의 한계를 극복하는 획기적인 변혁의 표준이 될 것이다.

또한 정보흐름의 변화를 주도하는 새로운 포맷이 될 것이며 새로운 패러다임의 변화를 몰고 올 것이다.

본 문서는 이러한 RSS를 지원해야 하는 이유를 정보접근적 측면에서 고찰하여

향후 새로운 시대의 변화와 혁신을 주도할 RSS를 기업,개인,공공기관 등에서 적극적으로 지원하길 기대하며 글을 쓴다.

어떠한 데이터가 정보인가

정보는 찾는 사람에 따라 그 가치가 결정된다.

정보의 가치는 정보를 찾는 사람이 어떠한 데이터를 정보로 인식하는가에 관련된 문제이다.

즉 정보를 찾는 사람이 자신이 찾는 목적에 부합하지 않거나 찾는 본질에 비하여 불필요한 내용이 너무 많다면 정보의 가치는 떨어진다. 그 정도에 따라서는 정보가 아닌 쓰레기에 전락해버린다. 즉 정보 가치는 정보를 찾는 정보탐색자의 요구의 의하여 결정된다.

정보는 시간 개념이 포함 되어 있다.

정보탐색자가 그 정보의 필요정도와 함께 적절한 시기의 정보을 였는가 또한 역시 중요한 문제이다. 정보의 가치가 시점이 중요함으로 정보탐색자는 정보의 관리를 한다.

필요에 따라서는 정보관리를 위하여 많은 시간을 할애하며 지금 또는 나중에 사용될 것을 예상하며 관리를 한다. 즉 정보탐색자는 정보의 필요성과 필요시기에 따라 정보를 관리한다.즉 정보탐색자에서 정보관리자로 역할을 동시에 수행한다.

수 없이 많은 데이터의 홍수에서 정보라 함은 내가 원하는,필요하는 데이터와 그 시점이 정확한 데이터를 정보라 할수 있다.

적절한 노력을 들여 활용 할 수 있어야 한다.

관리되는 정보의 량이 증가하면서 분류의 필요성이 대두되며 검색이 활용되어 진다.

잘 분류되지 못한 정보는 필요한 시점에 정확히 정보를 찾아 내는데 많은 시간이 소요되어

효과적으로 검색되어지지 않는 정보는 결국 이용 할수 없으며 또한 사장된다.

기존의 정보획득의 방식과 새로운 패러다임 RSS

정보라 함은 위에 기술한 것처럼

“ 나에게 필요한 것인가? ” 

“ 필요한 정보에 얼마나 접근하는가? “

“ 적절한 시기의 정보였는가? “

“ 적당한 노력을 하여 나의 정보를 인식 활용할 수 있는가? ” 등을 만족시켜야 한다.

위에 열거한 조건이외에도 여러가지 다른 조건들도 있겠지만 정보를 정보 또는 쓰레기로 분류하기 위한 가장 기본적인 조건이며 이 조건은 바로 정보를 획득하는 과정이다.

 

1. RSS 지원하는 것은 정확한 정보의 제공이 목적이다.

수없이 많은 정보의 홍수속에 대량의 정보가 연속해서 쏟아지고 있는 인터넷의 시대에 살고 있는 필자는 그 수없이 많은 정보에서 내가 원하는 정보를 찾는 일은 매우 힘들고 고된일이다. 그러한 일들이 매우 힘들어 사용자들은 자신에게 필요한 정보만을 수신하는 방향으로 정보는 흘러간다. 즉 정확한 정보만을 원한다.

메일의 서비스는 나의 메일주소가 노출되면 처음에는 필요한 정보가 구독되어지지만

노출된 나의 메일주소로 스팸이 섞여 오고 점차 자신의 메일함에 정보보다는 쓰레기로 넘쳐난다. 필요한 정보보다 불필요한 쓰레기 데이터가 더 많음에도 불구하고 여전히 메일을 쓸수밖에 없다. 이유는 필요한 정보와 쓰레기를 완벽히 구별 할 수 없기 때문이다.

이미 노출된 메일주소는 내가 거부 할 수 있는 권한이 너무 미약하고 그 노력이 너무 많이 소요 되기 때문이다.

메일은 두가지 방향에서 사용되어 왔었는데 그 하나는 커뮤니케이션이고 다른 하나는 정보의 구독 및 배달이었다. 그러나 정보는 정확한 방향으로 흐르기에 메일의 미래는 점차 없다고 하여도 과언은 아니다.

커뮤니케이션의 의미로 메일은 의미는 현재 매우 약화되어가고 있다.

이 글 쓰고 있는 필자는 커뮤니케이션의 역할로 이미 3년전부터 메신져에 더 의존하는 것이 사실이다.

정보구독 및 배달의 의미로써의 메일은 이미 RSS라는 새로운 포맷의 출현으로 그 앞날이 모호하다.

RSS는 원하는 정보만 정확하게 사용자에게 배달한다.

또한 원치 않을 경우 언제든지 사용자가 거부할수 있는 부분이 다르다.

메일의 푸쉬(PUSH)와 서비스와 다르게 RSS는 풀(PULL)서비스이기 때문이다.

정보의 주도권을 온전히 사용자가 직접 제어 할 수 있어 RSS는 사용자를 위한 맞춤화된 서비스로 RSS는 이메일 보다 정확한 정보를 제공한다.

조만간 모든 이메일 서비스는 상호보완적으로 RSS를 동시에 제공할것이며

웹사이트는 사용자에게 정확한 정보의 제공을 위하여 전체메일발송의 시스템을

RSS로 교체될것이다.

2. RSS 제공하는 것은 사용자에게 최대한 빠르게 정보를 제공 할 수 있다.

RSS는 기존의 웹사이트의 웨이팅(wating)서비스이다. 즉 사용자가 브라우저에 주소를 입력한후 방문을 하는 구조를 가지고 있다. 즉 사용자의 방문을 기다리는 것이 기존 웹사이트의 특징이다. 그러나 RSS서비스는 찾아 가는 서비스의 구현이다.

웹사이트의 정보를 RSS변환하면 기존의 데이터가 구독하는 사람에게 배달된다.

사용자입장에서는 자주 방문하는 웹사이트를 방문하지 않고도 여러사이트의 정보를 구독할수 있다. 이는 기존의 이메일의 정보전달의 의미를 계승한것으로 웹사이트의 진화방향과 일치한다.

만약 사용자가 블로그를 운영하는 블로그 운영자라고 가정하였을 경우 자신의 블로그를 방문하는 사람들의 블로그를 방문하는 것이 블로거들의 일반적인 유형이다. 만약 하루에 3명이 방문한다면 RSS를 지원하는 것이 큰 의미가 없겠지만 50명의 방문자가 있는 블로그운영자라면 이야기는 달라진다. 또한 어제 방문한 블로그에 다시 방문하고자 하였을 경우에는 RSS 서비스는 필수적인 요소가 된다.

매일 새로운 블로그와 방문하는 블로거의 새글을 취합해서 볼수 있는 포맷인 RSS는 기존의 웹사이트의 방문을 기다리고 그에 따라 정보 전달이 느려지는 것에 비하여 RSS서비스는 새로운 컨텐츠 아주 빠르게 RSS구독자에게 전달하는 신속성을 가지고 있다.

3. RSS는 이용자가 관리 가능한 편리한 서비스를 제공한다.

매일 검색하는 최신의 정보를 효과적으로 관리하는 것은 이미 불가능하다.

하루에도 한 개의 신문사에서 나에게 필요한 정보의 갯수는 이미 수백개에 달한다.

웹사이트에서 즐겨찾기로 이 많은 갯수의 정보를 관리 할 수는 없다.

그렇다고 하여 네트워크 시대에 정보를 관리하는 것이 의미 없어진 것은 아니다.

대량의 정보를 관리하는 것은 모든 정보를 세분화하여 분류화 관리 하는 것이 아니라

정보의 위치 기록과 좀더 더 중요한 정보를 관리하는 것에 초점이 맞춰진다.

RSS는 문서의 특징은 문서의 제목과 내용의 일부 또는 전체를 내 컴퓨터에 가져와

내 컴퓨터에서 정보를 관리 할 수 있다. 해당위치의 문서에서 업데이트 되었을 경우

지속적인 관리까지 가능하여 편리하다.

RSS문서를 지원하는 것은 방대한 사이트의 데이터베이스를 사용자에게 관리 가능하기에 사용자에게 좀더 중요한 데이터로 인식 할 수 있다.

사용자에게 중요한 데이터로 인식되는 것은 결국 데이터의 신뢰도 상승을 의미하며 타사이트 대비 잦은 방문을 유도하는 핵심적 요소가 될수 있다.

RSS지원하는 것은 편리한 서비스의 제공임과 동시에 사용자입장에서 RSS문서를 RSS리더로 구독하는 것이 대량의 정보를 체계적이고 지속적으로 관리 가능케 하여 궁극적 웹사이의 충성도를 높일수 있는 것이다.

마치면서

RSS지원하되 효과적으로 지원해야 한다.

본 글의 주제는 “왜 RSS를 지원해야 하는가” 이다

그러나 RSS 지원한다고 하여 위에서 나열한 이유를 모두 만족시키기는 어렵다.

현재 대부분의 인터넷 사용자들이 RSS의 개념에 생소하다.

RSS지원을 하되 효과적으로 지원함이 필요로 하다. RSS지원을 효과적으로 지원하기 위해서는 RSS지원 여부를 사이트의 메인페이지에 확실하게 홍보하는 것이 필요하다.

또한 RSS를 사용자에게 쉽게 사용하게 하기 위해서는 RSS리더와 함께 제공하는 것이 무엇보다 중요한 일이다.

국내의 RSS지원사이트이 예제.

조선일보 http://www.chosun.com/rss 의 페이지에서는 조선일보가 RSS지원하는것과 동시에 RSS리더를 제공함으로써 사용자에게 쉽게 접근을 유도하고 있다.

오마이뉴스의 http://www.ohmynews.com/make_file/rss/ 의 페이지 역시 사용자에게 손쉽게 제공하는 것을 목적으로 한다.

즉 “왜 RSS지원해야 하는가” 에 대한 결론은 RSS지원하는 것이 방문자를 증가시키는 것임과 동시에 찾아가는 서비스로 컨텐츠의 관리가 편리히며 정확한 정보의 제공을 가능하게 하기 때문에 지원해야 한다.

1. 사회 정의에 부합하며, 도덕적으로 옳은 일입니다.

P/S
움직이는?
깜빡이는?
제목을 정하기가 좀 어려운데, 어쨋거나 기존의 정적인 아이콘에 비해 동적으로 바뀌었으니, 움직이는 아이콘이라고 표현하는 수 밖에..
다운로드는 마우스 오른쪽을 이용하면 되는 것이라 별 다른 링크는 제공하지 않음..