닷컴의 붕괴는 웹2.0 탄생의 필연?

2001년의 닷 컴 버블의 붕괴는 웹에 있어서 하나의 전환점이 되었다.「웹은 과대하게 선전되고 있었다」라고 많은 사람이 결론을 내렸지만 버블과 그 후의 도태는 모든 기술 혁명에 공통되는 특징인 것처럼 생각된다. 일반적으로 도태는 신생 기술이 지금까지의 주역을 대신할 단계에 도달한 것을 나타내 보이고 있다. 전자는 붐을 쫓아갔지만 진짜 실력을 갖춘 기업이 성공을 거둔다. 이들이 서로 분리되는 것도 이해가 될 것이다.

「웹2.0」이라는 개념은 오라일리(O'Reilly)와 미디어라이브 인터내셔널(MediaLive International)에 의한 브레인 스토밍(brainstorming)에서 부터 탄생했다. 웹의 개척자이며, 현재는 오라일리의 부사장을 맡고 있는 데일 도어티(Dale Dougherty)는 웹은 「붕괴」되기는커녕 전보다 중요한 존재가 되었다고 한다. 활발한 웹사이트 들이 놀라운 정도로 착실하게 태어나고 있다고 지적했다. 또 버블 붕괴에서 살아남은 기업에는 닷컴의 붕괴에 의해서 웹은 웹2.0과 같은 확실히 어떤 전환점을 맞이해야 할 것이 아닌가 하는 공통점이 있어 보인다. 이러한 생각을 기초로 우리는 웹2.0 컨퍼런스의 개최를 결의했다.

불과 1년 반 사이에 웹2.0은 완전히 뿌리를 내렸다. 이 말을 구글로 검색하면 950만 건 이상에 달한다. 그러나 웹2.0이 의미하는 것에 대해서 아직껏 다수의 상이한 의견 차이가 있다. 이것을 말뿐인 무의미한 마케팅 용어라는 사람도 있고, 새로운 사회의 통념으로 보는 사람도 있다.

이 논문의 목적은 웹2.0이 무엇을 의미하고 있는지를 명확하게 하는 것이다.

최초의 브레인 스토밍(brainstorming)에서는 구체적인 예를 들어 웹2.0의 개념을 잡았다.

웹1.0웹2.0
DoubleClickGoogle Adsense
OfotoFlickr
AkamaiBitTorrent
Mp3.comNapster
Britannica OnlineWikipedia
Personal websitesblogging
eviteUpcorming.org and EVDB
Domain name speculationSearch engine optimization
Page viewsCost per click
Screen scrapingWeb services
publishingparticipation
Content management systemswikis
Directories(taxonomy)Tagging("folksonomy")
stickinesssyndication
<표 1> 웹1.0과 웹2.0의 비교

이 그 밖에도 다양한 예가 있다. 그러면 우리는 무엇을 가지고, 어느A 애플리케이션 또는 어프로치가 「웹1.0」이나 「웹2.0」에 속한다고 판단한 것일까(이 점을 분명히 하는 것이 우선시 되고 있다. 웹2.0이라는 문화의 전달자는 완전히 퍼져서 이 말의 진정한 의미를 이해하지 않고, 단순한 마케팅 용어로서 남용하는 기업이 증가하고 있기 때문이다. 게다가 이러한 유행어를 좋아하는 신생 기업의 대부분이 웹 2.0이라고는 도저히 부를 수 없다. 우리가 웹2.0의 예로서 이름을 든 앱스터(Napster)나 비트토런트(BitTorrent)는 엄밀하게는 웹 애플리케이션 조차 아니다).

우리는 웹1. 0의 성공 사례나 새롭게 등장한 흥미로운 애플리케이션에 주목하는 것으로 웹 2.0의 원칙을 이끌어내기로 했다.

웹2.0의 원칙

2004년 10월에 개최된 제1회 웹2.0 컨퍼런스의 개회 연설에서 존 베텔레(John Battelle)와 나는 이러한 원칙의 일부를 소개했다. 제1 원칙은 「플랫폼으로서의 웹」이었다. 그러나 이것은 웹1.0의 총아로 MS와의 격투의 끝에 진 냅스터가 내건 슬로건이기도 했다. 또 첫머리에서 웹1.0의 예로서 이름을 든 더블클릭(DoubleClick)과 아카마이(Akamai)도 웹을 플랫폼으로서 다룬 선구적인 기업이었다. 광고 서비스를 「웹 서비스」라고 생각하는 사람이 많지 않을지도 모르지만 광고 서비스는 광범위하게 배치된 첫 웹 서비스-최근의 용어를 사용하면 「매쉬 업」이었다. 모든 배너 광고는 2개의 웹 사이트가 밀접하게 협력해 통합된 페이지를 유저의 컴퓨터에 표시하는 형태로 나타난다.

아카마이도 네트워크를 플랫폼으로서 다루는 기업 중의 하나다. 아카마이는 스택의 한층 더 깊은 부분에서, 대역폭의 혼잡을 해소하기 위한 캐싱과 콘텐츠 전달 네트워크를 구축하고 있다.

그럼에도 불구하고 이 2개의 선구적 기업과 웹2.0 기업의 사이에는 명확한 차이가 있다. 후의 참가자들은 새로운 플랫폼을 보다 깊게 이해하는 것으로 같은 문제에 대해서 보다 효과적인 솔루션을 제공했다. 더블클릭과 아카마이는 웹2.0의 선구자였지만 웹2.0의 디자인 패턴을 도입하면 더 많은 가능성을 실현할 수 있다.

여기에서는 웹1.0과 웹2.0의 본질적인 차이를 알아보자

넷스케이프 vs 구글

넷스케이프가 웹1.0의 기수였다고 하면 구글이 웹2.0의 기수라는 것에 이의가 없을 것이다. 양 회사의 IPO는 각각의 시대를 상징하는 사건이기도 했다. 우선 양 회사와 그 포지션의 차이를 비교해 가자.

넷스케이프는 낡은 소프트웨어 패러다임(paradigm)의 관점으로부터, 「플랫폼으로서의 웹」을 구상했다. 넷스케이프의 가장 중요한 제품은 웹 브라우저와 데스크톱 애플리케이션이었다. 넷스케이프는 브라우저 시장에서의 우위를 이용해 고액의 서버 제품 시장을 확립하려고 했다. 넷스케이프는 콘텐츠와 애플리케이션을 브라우저에 표시하기 위한 표준을 지배하고 있었으므로 이론적으로는 MS가 PC시장에서 향수하고 있는 것과 같은 시장 지배력을 손에 넣을 수 있을 것이었다. 「말 없이 달리는 탈 것」이라고 하는 표현이, 마차를 즐겨 온 사람들에게 자동차를 친밀한 것과 느끼게 한 것처럼, 넷스케이프는 데스크톱을 대신하는 것으로 「웹 톱」을 추진했다. 이 웹 톱에 넷스케이프 서버를 구입한 기업이 전달하는 업데이트하는 애플릿을 싣는다는 것이 넷스케이프의 계획이었다.

그러나 웹 브라우저와 웹 서버는 상품화해, 가치는 「스택의 상류」, 즉 웹 플랫폼상에서 제공되는 서비스로 옮겨 버렸다.

넷스케이프와 대조적으로 구글은 네이티브의 웹 애플리케이션으로 탄생했다. 구글은 소프트웨어를 판매한 것도 패키지 소프트웨어를 개발한 적도 없다. 구글은 서비스를 제공해 고객은 직접적 또는 간접적으로 서비스에 대한 사용료를 지불한다. 구글에는 과거의 소프트웨어 업계를 상징하는 것은 아무것도 없다. 소프트웨어의 발표 계획은 없고 개선은 계속적으로 행해진다. 라이센스 공여도 없으며, 판매도 없고, 사용량이 있을 뿐이다. 고객의 환경에 맞추어 소프트웨어를 다양한 플랫폼에 이식할 필요도 없다. 대량의 상품 PC를 사용하고, 극히 확장성이 높은 시스템을 구축해 자가의 커스텀 애플리케이션과 유틸리티를 오픈 소스 OS 위에서 실행하는 것만으로 좋다.

구글에 필요한 것은 넷스케이프가 전혀 필요로 하지 않았던 능력이다. 그것은 데이터베이스 관리다. 구글은 단순한 소프트웨어 툴이 모아진 것이 아니라 매우 특수한 데이터베이스다. 데이터가 없으면 툴은 도움이 되지 않지만, 소프트웨어가 없으면, 데이터를 관리할 수 없다. 웹1.0시대에 귀중한 보물 된 소프트웨어 라이센스나 API 관리 방법은 구글의 비즈니스 모델에게는 들어맞지 않는다. 구글은 소프트웨어를 배포할 필요는 없고, 그것이 적절히 기능하도록 하면 좋기 때문이다. 실제, 데이터를 수집해, 관리하는 능력이 없으면, 이 소프트웨어는 어떤 도움도 되지 않는다. 소프트웨어의 가치는 그 소프트웨어가 관리하는 데이터의 규모와 다이너미즘에 비례한다.

구글의 서비스는 대량의 인터넷 서버로 구성된 시스템을 통해 제공되지만, 구글의 서비스는 서버는 아니다. 유저는 브라우저를 통해 구글의 서비스를 이용하지만, 구글의 서비스는 브라우저는 아니다. 구글의 기간 사업은 검색 서비스이지만 구글은 검색 결과에 표시되는 콘텐츠조차 소유하고 있지 않다. 통화가 발신자와 수신자의 전화기뿐만이 아니라, 그 사이의 네트워크가 일어나도록 구글의 서비스는 브라우저, 검색 엔진, 그리고 목적의 콘텐츠가 보존되고 있는 서버 사이에 생겨 구글은 유저와 온라인으로의 경험을 묶어, 중개하는 역할을 완수한다.

넷스케이프나 구글은 어느쪽이나 소프트웨어 기업이라고 부를 수 있지만, 넷스케이프가 로터스, MS, 오라클, SAP 등의 1980년대의 소프트웨어 혁명으로부터 태어난 기업과 같은 소프트웨어의 세계에 속했다면 구글은 eBay, 아마존, 냅스터, 그리고 물론 더블클릭과 아카마이 등의 인터넷 애플리케이션 기업과 같은 그룹에 속한다.

웹2.0의 교훈:유저 셀프서비스와 알고리즘에 의한 데이터 관리를 도입해 웹 전체--중심부 뿐만이 아니라 주변부, 머리 뿐만이 아니라 긴 꼬리(롱 테일)의 끝에도 서비스를 제공한다.

플랫폼은 항상 애플리케이션을 능가한다

MS는 플랫폼이 비장의 카드로서 모든 경쟁에서 승리해 왔다. 과거의 경쟁 상대 중에는 높은 시장 점유율을 자랑하는 애플리케이션도 있었다. MS는 윈도우를 이용해 로터스1-2-3를 엑셀에, 워드퍼펙을 워드에 그리고 넷스케이프 내비게이터를 인터넷 익스플로러에 옮겨놓았다.

그러나 이번 싸움은 플랫폼과 애플리케이션이 아니고 완전히 다른 비즈니스 모델을 가진 플랫폼끼리의 사이에서 벌어지고 있다. 한 쪽은 거대한 인스톨 베이스와 긴밀히 통합된 OS나 API를 무기로, 프로그래밍 패러다임(paradigm)를 지배하고 있는 소프트웨어 프로바이더, 다른 한편은 공통의 프로토콜, 개방적인 표준 그리고 협력 협정에 의해서 연결된 소유자를 가지지 않는 시스템이다.

윈도우는 소프트웨어 API에 의한 독점적 지배의 결정판이다. 넷스케이프는 MS가 다른 라이벌에 대해서 사용한 것과 같은 방법으로 MS의 지배권을 강탈하려고 했지만, 그 시도는 실패로 끝났다. 한편 웹의 개방적인 표준을 고집한 아파치(Aache)는 성공을 거두었다. 현재의 싸움은 플랫폼 대 애플리케이션이라는 어울리지 않은 것이 아니고, 플랫폼 대 플랫폼이라는 대등한 것이다. 이 싸움에서는 어느 쪽의 플랫폼이- 더 중요한 지, 어느 쪽의 아키텍처 또는 비즈니스 모델이 향후의 기회에 적합한지가 중요하게 된다.

PC시대의 초기에는 윈도우는 문제를 해결하기 위한 훌륭한 솔루션이었다. 윈도우는 애플리케이션 개발 기업에 공평한 씨름판을 제공해, 업계를 괴롭히고 있던 많은 문제를 해결했다. 그러나 하나의 회사가 관리하는 획일적인 어프로치는 이미 솔루션이 아니고 하나의 문제에 지나지 않는다. 커뮤니케이션 지향의 시스템(플랫폼으로서의 인터넷은 틀림없이 그 하나다)은 상호 운용성을 필요로 한다. 모든 상호작용의 양단을 관리할 수 없는 한 소프트웨어 API에 의해서 유저가 로그인 하는 것은 어렵다.

플랫폼을 지배하여 애플리케이션의 이득을 로그인 하려는 웹2.0 기업은 필연적으로 플랫폼을 비장의 카드로 하지는 않을 것이다.

로그인이나 경쟁 우위를 획득할 기회가 없는 것은 아니다. 그러나, 소프트웨어 API나 프로토콜을 지배하는 것으로 그러한 기회를 손에 넣는 것은 어려워질 것이다. 새로운 게임이 시작되었다. 웹2.0시대에 성공을 하는 것은 PC소프트웨어 시대의 룰로 퇴보하려고 하는 기업이 아니라 새로운 게임의 룰을 이해하고 있는 기업이다.


♣ 자료출처 : O'Reilly Network

WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

블로그의 인기는 식을 줄 모르며 누구든 최신 기술을 좋아하는 건 부정할 수 없는 사실이다.

그러나 블로그가 과연 기업 내부의 통신용 툴로도 과연 적합할 것인가? 블로그와 위키를 비교해, 특히 공공기관에서 사용하기 좋은 것이 어떤 것일지 골라보자.

이 글을 쓰기 전 기업 내 차세대 통신 수단으로 블로그가 적격이라는 기사를 읽은 바 있다. 그런데 솔직히 말해 나는 블로그가 기업, 특히 공공기관에 적합한 툴이라는 생각에 그다지 동의하지 않는다.

몇몇 기업에서는 블로그와 같은 개인 정보 배포 시스템이 괜찮다고 결론내리고 직원들이 참여할 수 있는 내부용 블로그(IBM의 경우)나 외부용 블로그(썬 마이크로시스템즈의 경우)를 만들기도 했다. 외부에 노출된 시스템의 경우 블로그 이용 규칙, 그리고 넘지 말아야 할 선이 직원들에게 주입되지만, 시간이 지나고 규모도 커지면서 회사 측의 검열은 없어질 수밖에 없다.

내부 블로그도 아주 유사한 형태로 운영된다. 하지만 회사 내부의 이야기는 사실 "은연중에" 블로그에 게재되기 마련이다.

블로그 개방성 "무조건 좋은가?"

신기술 거부론자가 되는 건 싫지만 내부 블로그건 외부 블로그건 상관없이 블로그는 기업 환경에서 폭넓게 사용할 만한 가치가 있기보다는 문제거리가 될 소지가 높다고 본다. 그래도 나는 특수한 상황, 즉 인트라넷 상의 보안 경고 블로그를 만드는 IT 부서나 선거로 당선된 단체장과 같은 사람들이 내부 구성원들과 대화할 목적으로 블로그를 만드는 경우에서는 블로그가 가치있는 툴이 될 수도 있을 거라고 생각한다.

정부 기관들의 경우 "한 목소리"를 내는 것조차도 힘든 것이 현실이다. 국가 기관의 공식 블로그에 현 정책을 거침없이 비판하는 공무원 때문에 혼란이 야기되는 상황은 단지 상상속의 일만은 아닐 것이다.

즉, 직원들에게 인트라넷 상에 자기 생각을 이야기할 수 있도록 한다면 아마도 득보다는 실이 많다는 부정적인 결론이 도출될 것이다. 공공 기물을 개인 용도로 사용하는 것도 문제이며 HR 규칙도 그렇고, 게다가 내부 블로그에 쓴 글은 몽땅 다 공개된 기록으로 남을 수밖에 없다. 이처럼 복잡하고 귀찮은 문제를 정말 떠안고 싶을까?

통신 방법이 부족하다는 말도 그렇다. 이메일, 메신저, 그룹웨어 등 이런 건 다 무엇인가. 의견을 공유하기 위해 또다른 툴이 정말로 필요한 것일까?

위키, 인지도 낮지만 잠재력 "더 크다."

내가 기업 내에서 잠재력이 더 크다고 보는 기술은 바로 위키다. 위키가 뭐냐고? 위키에 대해 세상에서 가장 대중적인 정의를 내려보자. 들어봤을지 모르겠지만 위키피디아(Wikipedia)의 정의를 살펴보자.

"위키란 사용자들이 내용을 추가할 수 있는 웹 애플리케이션으로, 인터넷 포럼이지만 누구라도 내용을 수정할 수 있다… 위키는 웹 브라우저에서 간단한 마크업 언어(markup language)를 이용해 공동 문서를 작성할 수 있게 해준다."


위키는 인트라넷 기능을 멋지게 강화한 시스템으로 상대적으로 저렴한 비용으로 협업 기능을 이용할 수 있도록 한다. T위키(Twiki)는 오픈소스 라이선스를 따르는 구조화된 위키로, 모토로라, SAP, 야후, 디즈니와 같은 대기업들이 사용하고 있다. 다른 종류의 위키로는 잣스팟(JotSpot), 소셜텍스트(Socialtext), 그로브사이트(GroveSite) 등이 있다.

표준 인트라넷 웹페이지와 비교할 때 위키의 장점은 무엇일까? 위키라고 다 같은 건 아니지만 위키가 갖는 공통적인 속성은 공유하고 있다.

사용하기 쉽다 : 페이지 편집, 페이지 연결, 텍스트 형식 변환은 표준 HTML에 비해 훨씬 더 쉽다. 게다가 페이지를 업로드할 때 FTP가 필요치 않다.

관리하기 쉽다 : 변경 관리는 위키가 가진 본래 속성이며 위키에서 일어난 모든 변화는 차후 추적 가능하다. 위키의 모든 텍스트는 검색 가능하고, 위키의 내용은 쉽게 구조화된다.

원하는 기능을 추가할 수 있다 : 사용중인 위키 도구가 무엇이냐에 따라 표준 인트라넷 사이트에서는 프로그램적으로 하기 어려운 일들, 이를테면 데이터베이스 접근, 파일 업로드와 다운로드, 위지위그(WYSIWYG) 기능 등을 플러그인을 이용해서 위키에 아주 쉽게 추가할 수 있다.

위키는 온라인 백과사전인 위키피디아를 만드는 데 사용하는 것 뿐 아니라 다음과 같은 일을 할 때에도 사용할 수 있다.

헬프 데스크 도구
FAQ, 표준 문서, 회의록
지식 베이스(Knowledge base)
프로젝트 협업 도움

위키의 단점은 역설적이지만 '누구나 기여할 수 있다'는 점이다. 이 말은 내용에 대해 제어하기가 상대적으로 어렵다는 의미다. 하지만 Twiki같은 것들은 좀더 구조화돼 있고 내용 수정 허가 기능도 포함돼 있다. 따라서 제어는 상대적으로 큰 문제는 아니다.

명심해야 할 게 또 있다. 지원 문제다. 위키 소프트웨어를 어디서 구했느냐에 따라 오픈소스 공동체나 소규모 업체의 지원에 목을 맬 수밖에 없을 수도 있다. 대다수 위키 툴들의 경우 유지해나가려면 회사 내에 펄(Perl), 자바/자바스크립트, 리눅스/유닉스를 다룰 줄 아는 사람이 상시 대기해야 할 것이다. 윈도우 기반 위키도 몇 개 있으나 리눅스에서 구동되는 위키가 더 많다.

요약해보자. 필자는 블로그가 정부 조직의 통신 수단에 가장 적절하지는 않다고 생각한다. 대신 위키는 어디든 도입을 고려할 게 틀림없을 만큼 저렴하고 상당히 유용한 툴이라고 본다.


♣ 자료출처 : http://www.zdnet.co.kr


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

구글은 정말 마술로 운영되는 것 같다. 이들에게 있어 검색 작업은 노력을 들이거나 심각하게 고민하지 않아도 순탄하게 진행되는 마법과 같은 툴로 보인다.

검색엔진들은 상용 검색 툴을 구입해 내부에서 개발 작업을 거쳐 만들어졌든지, 아니면 구글과 같은 공적 인덱스·검색 서비스를 사용하든지 상관없이 모두 동일한 기초 규칙들을 준수한다. 내부 검색을 통해 의미 있는 결과를 산출하도록 사이트를 개발하면 외부 검색에 대해서도 적절한 결과를 산출해 낸다.

1. 메타태그를 작성하라

검색 엔진을 제어하기 위해 해야만 하는 가장 기초적인 작업은 내부적이든 외부적이든 상관없이 ‘ROBOT’ 네임 속성을 지닌 메타태그와 ‘INDEX’ 또는 ‘NO INDEX’ 그리고 ‘FOLLOW’나 ‘NO FOLLOW’ 등을 포함하는 콘텐츠 속성을 지닌 메타태그를 작성하는 것이다.

이 간단한 태그는 검색엔진에게 웹페이지와 관련해 어떤 일을 해야 하는지 알려준다. 내/외부 검색엔진 모두 페이지 작업에 관한 한 이 메타태그 지침을 준수한다.

<META NAME="robots" CONTENT="noindex">

‘INDEX’는 검색 엔진이 만드는 인덱스 내에 페이지를 포함시키도록 허용한다는 뜻이다. 이와 반대로 ‘NO INDEX’는 인덱스 내에 페이지를 포함하지 않도록 검색엔진에 지시한다. 검색엔진이 사용자 검색 결과를 찾기 위해 사용하는 것은 바로 이 인덱스다. 만약 이 페이지가 인덱스에 덧붙여지지 않으면 검색을 통해 발견되지 않을 것이다.

ROBOT 메타태그에 대해 NO INDEX 설정을 활용할만한 좋은 사례는 바로 전자상거래 웹사이트에서 단기 판매 제품을 보유하고 있을 때다. 사용자들이 주문을 검토할 수 있도록 제품을 카탈로그 내에 유지하고 싶겠지만 불특정 다수의 누군가가 이 제품을 맞닥뜨리긴 원하지 않을 것이다. 단기 특판 제품이 아닌, 카탈로그 내 제품은 대부분 INDEX 설정을 갖게 된다.

‘FOLLOW’는 검색엔진이 반드시 페이지 내의 링크를 따라가야 한다는 것을 의미하며 ‘NO FOLLOW’는 검색엔진이 페이지에서 발견되는 링크를 따라가지 않도록 지시한다. ‘NO FOLLOW’ 설정은 예를 들어 토론 포럼을 인덱스 작업하고 있는데 내부 검색엔진이 통제를 떠나 게시물 내에 있을 수 있는 다른 사이트로의 링크를 인덱스 작업하는 것처럼 따라가지 않았으면 하는 링크를 참조하지 않도록 해준다. 이 경우 인덱싱되는 콘텐츠들은 검색엔진이 페이지 자체를 인덱스로 만들지는 않지만 제공된 링크를 따라가기 위해 ‘NO INDEX’나 ‘FOLLOW'’등의 설정을 가질 공산이 크다.

2. 목록을 만들라

검색에 친숙한 사이트를 구축하는 데 있어서 핵심 도전과제 중 하나는 추가되는 웹페이지가 과연 어떤 것인지 검색 인덱스가 알 수 있도록 지원하는 것이다. 전통적으로 검색엔진은 사이트의 루트 페이지를 지향하며 모든 링크를 발견할 때까지 사이트 구석구석을 누비고 다닌다. 이는 웹 기반 HREF 속성을 지닌 ‘앵커(A)’ 태그로 항상 링크를 산출하는 사이트에서 잘 동작한다.

또한 많은 웹사이트들이 한 페이지를 다른 페이지에 연결시키기 위해 활용하는, 자바스크립트 기반 링크가 있다. 그러나 이 방법의 문제는 검색 크롤러(crawler)가 사이트 내의 링크를 따라갈 수 없게 된다는 것으로 따라서 검색 인덱스는 단지 이는 홈페이지의 정상적인 링크에서 건질 수 있는 소수의 링크만을 확보하게 된다.

해결책은 검색엔진이 수집했으면 하는 모든 링크가 포함된 페이지를 별도로 제작하는 것이다. 이 페이지는 전자상거래 사이트의 경우 모든 제품에 대한 링크를 포함하거나, 커뮤니티 사이트에서는 모든 종류의 토론에 대한 링크를 포함할 수도 있다.

이렇게 만들어진 웹페이지의 목적은 사이트의 모든 콘텐츠로 연결되는 대량의 앵커 태그가 포함된 HTML 페이지를 만든다는 것이다. 이 페이지는 사이트 내의 일부 특정 스크립트로 작성돼야만 한다는 점에서 특별하진 않다. 단지 필요한 모든 링크를 재빨리 제공해야만 한다는 점이 차별점이다.

일부 경우에서 이 기술은 사이트 인덱스를 활성화하는 빠르고 위력적인 방법이 될 수도 있다. 비록 사이트 구조 자체가 그다지 인덱스 작성에 용이하진 않다고 해도 말이다. 즉 파일 시스템이나 IIS 가상 디렉토리 사이를 말 그대로 돌아다님으로써 사이트 상의 모든 파일들의 목록을 만들 수 있는 프로그램을 제작할 수 있다.

이에 따르면 각각에 대한 링크를 제공함으로써 모든 페이지를 검색 인덱스에 덧붙이는 것이 가능하다. 그러나 부작용으로 메인 사이트에서는 오래전에 폐기처분한 웹페이지와 파일들이 검색 인덱스에 포함될 수도 있다.

검색 크롤러 시작 페이지는 검색엔진이 링크를 따라가되 페이지 그 자체를 인덱스로 만들지는 말라고 지시하는 ‘META ROBOT’ 태그로 설정된다. 위에서 살펴 본 것처럼 이 콘텐츠는 ‘NO INDEX’, ‘FOLLOW’ 등의 메타태그를 갖고 있다. 이 페이지로 인해 검색엔진은 사이트 전체에서 모든 목록화된 페이지를 인덱스로 만들 수 있게 된다.

몇몇 검색엔진, 특히 내부에서 개발된 것들은 이런 링크 페이지에 대해 검색엔진을 직접 지목할 수 있도록 허용한다. 그러나 크롤러의 출발점을 제어하는 ‘사치’를 누리지 못하는 경우도 있다. 이 경우 홈페이지의 검색 크롤러 페이지로의 링크만이 필요하게 된다. 검색엔진이 링크를 따라가도록 하는 것이 실질적인 목적이라면 어떤 텍스트도 앵커 태그에 넣을 필요가 없다.

이에 따른 결과는 태그 내부를 조명하는 텍스트가 전무하기 때문에 존재하는지도, 심지어 인식조차 하지 못한 상태에서 검색 엔진이 검색 크롤러 인덱싱 페이지에 도달하도록 지원하는 링크라 할 수 있다. 바로 아래 구문과 같은 것이다.

<A HREF="./searchcrawler.aspx">

3. 태그를 활용하라

검색엔진에 대한 글을 마치며 마지막으로 당부하자면 모든 페이지에 적절한 특정 타이틀이 확실히 포함돼 있어야만 최적화가 가능하다는 것이다. 대다수 검색엔진들은 검색결과 조합에 있어 페이지의 타이틀을 활용한다.
이와 비슷하게, ‘KEYWORDS’의 이름을 지닌 메타태그를 사용하면 해당 키워드들을 검색할 때 페이지가 더 빈번하게 노출될 수 있다.


♣ 자료출처 : http://www.zdnet.co.kr


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

트랙백의 원리

트랙백의 핵심은 매우 간단하다. 누군가의 글에 대해 자신의 블로그에 의견을 피력하면서 그 글에 대해 “당신이 쓴 글에 대해 제가 의견을 썼습니다. 당신이 관심을 가질 것 같아서 일부 내용과 함께 알려드립니다”라고 알려주는 것이 바로 트랙백이다. 트랙백을 사용할 때와 그렇지 않을 때 어떻게 커뮤니케이션이 이루어지는지 예를 들어 보겠다.

1. 트랙백을 사용하지 않은 경우

디지털 카메라(이하 디카) 커뮤니티 사이트에서 활동하고 있는 A와 B가 있다. 어느 날 A는 B가 써놓은 글을 보게 되고 B가 자신이 가지고 있는 디카와 동일 기종을 가지고 있고 그 디카에 대한 활용팁 등을 적어 놓은 것을 보게 된다. 이 글을 본 A는 B의 글이 상당히 유용하지만 자신이 알고 있는 활용팁이 몇 가지 빠진 것을 보고 답글 또는 꼬리말 형식으로 B의 글을 보충해준다.

2. 트랙백을 사용한 경우

디카에 대해 관심이 있는 A와 B가 각자의 블로그를 쓰고 있다. 어느 날 A는 B의 블로그에서 자신이 가지고 있는 디카와 동일 기종에 대한 활용팁을 적은 글을 보게 된다. A는 B의 글에 대해 꼬리말을 달아 자신만이 알고 있는 부분을 보충할 수도 있지만 그 글의 트랙백 URL을 찾아서 자신의 블로그에 나머지 활용팁을 적은 후 B가 자신의 글에 대해 관심을 가질 거라고 생각하고 B의 글에 대해 트랙백 핑을 보낸다.

이 두 가지 예제는 웹 사이트에 올라온 글에 대해 트랙백을 사용한 경우와 사용하지 않은 경우 그 글에 대해 취할 수 있는 한 가지 행동 예를 보여 준다. 트랙백을 사용하지 않은 경우에 비해 트랙백을 사용한 경우가 가지는 가장 큰 차이점은 하나의 웹 사이트 공간(블로그)을 초월한 A와 B 사이의 링크가 만들어진다는 점과 A는 자신의 공간에서 자신의 의견을 독립적으로 표현할 수 있다는 것이다.


♣ 자료출처 : http://www.zdnet.co.kr


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,

웹사이트 구축시 CSS를 사용하면 HTML에 들어있는 반복되는 형식 코드를 CSS 스타일 시트에 통합함으로써 HTML 자체에서 제거할 수 있기 때문에 시간과 노력을 줄일 수 있다. 또한 스타일을 사용함으로써 다중 텍스트 블록의 형식을 만들고 레이아웃을 제어함으로써 여러 페이지의 형식을 만들어낼 수 있다.

여기에 재사용할 수 있는 형식을 한 곳에 보관할 수 있기 때문에 개발 시간도 단축할 수 있다. 특히 웹사이트를 편집하거나 계속 업데이트해야 할 경우 더욱 효과가 크다.

반면 CSS는 스타일 시트에 스타일을 추가하면서 파일이 금방 엉망이 될 수 있다는 것이 단점이다. CSS에는 HTML 태그 속성을 재정의하는 스타일과 다양한 텍스트 블록의 형식을 정의하는 클래스와 id 셀렉터, 페이지 레이아웃을 위한 스타일 등이 포함되며 몇몇 스타일들은 전체 웹사이트에 적용되기도 하며 다른 것들은 개별 페이지에 적용되기도 한다.

또한 브라우저간 호환성 문제를 해결하기 위해 임시 변통책을 사용해야 하는 경우도 있다. 스타일 시트에 포함되는 모든 것들을 고려해볼 때 CSS 스타일 시트를 관리하는 일관된 계획이 없다면 통제권이 순식간에 사라져 버릴 것이라는 사실은 명약관화하다.

CSS 스타일의 조직화

CSS 개발을 해본 적이 없는 많은 웹 개발자들이 흔히 하는 실수는 단일 CSS 파일에 웹사이트 전체 스타일을 구겨 넣는 것이다. 이러한 방식은 몇 개 페이지로 구성돼 있으며 특정 스타일을 가진 아주 작은 웹사이트라면 괜찮게 적용될지도 모른다. 그러나 일반적인 다른 웹사이트들은 여러 개의 CSS 파일을 쓰는 게 낫다.

예를 들면 사이트 전체에 적용되는 단일 CSS 파일을 먼저 개발하고 서로 구분지을 수 있는 웹페이지들의 집합 각각에 대해 별도의 CSS 파일을 두는 방법이 있을 수 있다. 즉 특정 부서를 위한 스타일이나 다른 레이아웃 스타일을 지닌 페이지가 있을 수 있다는 것이다.

그리고 고유한 스타일을 필요로 하는 특정 페이지에 대해서는 각 페이지마다 별도의 CSS 파일을 둔다. HTML 헤더에 넣기에 스타일이 너무 많을 경우다. 또한 적당한 CSS 파일을 각 페이지에 연결하거나 가져오게 할 수 있다. 그렇게 되면 페이지를 표시하는데 필요한 스타일을 모두 적재할 수 있으며 다른 페이지에서만 나타나는 불필요한 것들은 적재되지 않는다.

CSS 스타일 시트를 조직화하는 데 있어 본인이 애용하는 기법은 스타일 시트 파일을 섹션으로 분리하는 것이다.

예를 들어 메인 스타일 시트에서 첫번째 섹션에는 사이트의 전체 애플리케이션에 폭넓게 적용되는 스타일을 둔다. 즉 HTML 태그의 속성을 재정의하는, 가장 빈번한 스타일이 위치하게 된다. 다른 섹션에는 네비게이션 바나 각주와 같은 보편적인 페이지 요소의 형식을 정의하는 데 필요한 스타일을 담는다.

또 다른 섹션에는 사이트 전체에 걸친 페이지 레이아웃을 통제하는 스타일을 담는다. 나머지 섹션들은 점점 더 범위를 좁혀 스타일을 집합시킨 것들을 담는다.

특정 사이트에서 모든 사이트 전반에 적용되는 스타일은 단일 CSS 파일로 만들 수 있으며 각 섹션은 코멘트로 구분된다. 그러나 보다 복잡한 사이트의 경우라면 각 섹션을 별도 파일로 만드는 게 좋다. 많은 웹 개발자들은 페이지 레이아웃을 위한 스타일을 별도로 두고 텍스트나 다른 요소를 정의하기 위한 스타일을 다른 CSS 파일에 두기를 좋아한다.

‘클래스 남용’은 피해라

웹 개발자들을 괴롭히는 또다른 문제 중 흔해빠진 것으로는 클래스와 ID의 남용을 들 수 있다. 클래스와 ID를 마크업에 추가하고 CSS 스타일을 정의해 요소들의 형식을 만드는 것은 CSS의 사용방식에 있어서 기초가 된다.

그러나 형식을 정의하고 싶은 모든 것에 대해 자동으로 클래스를 정의하려고 마음먹기는 상당히 쉽다. 하지만 실질적으로 HTML 태그의 속성을 재정의하는 것이 대상 요소의 속성을 나타내는 새로운 클래스를 정의해 계속 적용하는 것보다 훨씬 효율적이다.

스타일 시트에서 필요한 클래스 스타일의 갯수를 줄이는 또 다른 방식은 이미 존재하는 두개의 스타일을 단순히 결합하는 것보다 동일 페이지 요소에 여러 개 스타일을 적용하는 것이다.

최선을 다해 코드를 작성하고 나머지는 테스트에 맡겨라

믿거나 말거나’일지도 모르지만 사실 개발 기간 중에 웹페이지를 보는 데 사용하는 브라우저가 CSS 스타일 시트 개발에 큰 영향을 준다.

엄청난 시장 점유율 때문일지 몰라도 많은 웹 개발자들이 인터넷 익스플로러를 주요 웹브라우저로 사용하고 잇다. 이들은 대다수 방문객들이 사용하는 브라우저에서 보기 좋도록 사이트를 먼저 개발하고 다른 브라우저가 해당 사이트를 표시하는 방식에 따라 적당히 조절해나간다. 분명 논리적인 접근법으로 보인다.

하지만 문제는 인터넷 익스플로러가 웹브라우저 중 가장 표준을 따르지 않는다는 것이다. 따라서 IE를 사용하는 웹 개발자가 작성하고 있는 코드에는 인터넷 익스플로러의 수많은 특이점들이 불가피하게 탑재되는 경우가 발생한다. 따라서 보다 표준에 부합하는 브라우저에서 코드를 동작시키려면 상당부분을 다시 써야 한다.

다행히도 인터넷 익스플로러가 가진 문제는 웹사이트들이 전반적으로 표준에 부합하는 추세로 나아감에 따라 결국 없어질 것이다. 미래를 염두에 둔다면 표준에 맞춰 코드를 개발하는 것이 나으며 현재 최적화되지 않은 브라우저에서도 사이트가 동작하도록 필요한 임시조치를 취하는 것이 좋다.

표준에 부합하는 코드를 구형 웹브라우저에서 동작시키는 브라우저 해킹 방법은 여러 곳에 잘 기록돼 있다. 이 해킹 방법을 추가하고 나중에 지우는 것이 특정 브라우저의 특이점들을 제거하기 위해 코드를 재작성하는 것보다는 낫다.

목적이 표준에 부합하는 코드 개발이라면 가장 표준에 부합하는 웹브라우저를 사용해 HTML 페이지를 보는 게 낫다. 현재 가장 적합한 웹브라우저는 모질라의 파이어폭스다. 파이어폭스에서 원하는 효과를 얻은 후 다른 웹브라우저에서 그 페이지를 테스트하고 웹브라우저 호환성 문제를 해결하기 위해 해킹을 추가하거나 코드를 변경하는 절차를 시작하라.

파이어폭스 웹브라우저의 또 다른 장점은 웹 개발자를 위한 툴바 확장이 제공된다는 것이다.

위의 권고를 따른다 해도 인터넷 익스플로러로 웹사이트를 보면서 많은 시간을 보낼 수 있다. 하지만 다른 웹브라우저에서 개발 결과물을 먼저 본다면 결과적으로 코드가 더 깨끗해질 것이라는 점은 확실한 사실이다.


♣ 자료출처 : http://www.zdnet.co.kr


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

,