UX는 사용자 경험을 뜻하는 User eXperience의 줄임말로서 사용자가 어떤 제품이나 서비스를 이용하면서 느끼게 되는 총체적 경험을 말한다. 사용자 간의 커뮤니케이션 속도가 빨라지고 경쟁사 간의 기술력 차이가 줄어들고 있는 현대 시장에서 성공하기 위해서는 반드시 사용자로부터 제품에 대한 긍정적인 경험을 이끌어내야 한다. 그렇기 때문에 현대 산업에서 UX의 중요성은 점점 더 강조되고 있고, 여러 가지 학문으로 연구되고 있다. 하지만 언뜻 보면 굉장히 포괄적이기도 한 UX의 정의로 인해 각 산업마다 UX에 대한 해석과 이론이 다양하게 구체화되고 있다. 그 중 웹에서는 사용자 인터페이스에 주로 UX의 개념이 도입되고 있다.

물론 UX란 단어가 최근 웹에서만 불거져 나온 것은 아니다. 예전부터 UX라는 개념은 소프트웨어 개발부터 릴리즈 단계까지 지속적으로 고려해야할 요소 중 하나였다. Out-of-box는 소프트웨어 산업에서 UX를 잘 대변해주는 용어 중 하나이다.

Out-of-box란? Out-of-box란 일반적으로 고정관념을 버리거나 기존의 틀을 깬다는 혁신의 뜻으로 사용되지만, IT산업에서는 사용자가 제품의 포장을 뜯고 이용하기 시작하는 시점을 의미한다. Out-Of-Box Experience의 줄임말로 OOBE로 불려지는 이 사용자 경험은 제품의 기능이 점점 더 다양해지고 복잡해짐에 따라 사용자가 제품을 처음부터 쉽게 사용할 수 있도록 만드는 것이 최우선임을 강조한다. 즉, 사용자가 제품을 처음부터 쉽게 사용할 수 있도록 제품의 설치나 이용을 최적화시키는 것을 미션으로 삼고 있다.

이처럼 UX는 단지 사용자 인터페이스 뿐만 아니라 다양한 영역에서 사용자의 경험을 긍정적으로 이끌어내려는 노력을 해오고 있다. 그럼에도 불구하고 웹에서 유독 사용자 인터페이스를 통한 UX가 강조되는 현상은 그 태생적 특징에 기인한다. 제품의 포장을 뜯고 설치를 하고 초기화를 해야 하는 기존의 하드웨어나 소프트웨어 제품에서는 OOBE의 중요성을 강조할 필요가 있다. 하지만 웹은 브라우저로 접속만하면 서비스를 바로 이용할 수 있는 특징을 가지고 있기 때문에, OOBE대신 사용자가 가장 처음 접하게 되는 디자인이나 사용자 인터페이스가 UX의 중요한 대상이 되는 것이다. 게다가 웹은 이제 단순한 홈페이지를 넘어 대중들에게 다양한 고품질의 어플리케이션으로 인식되고 있고, UX는 점점 더 개발단계에서 무시해서는 안 될 영역이 되어버렸다.

하지만 위에서 설명했듯이 사용자의 경험이란 단지 사용자 인터페이스에서만 얻을 수 있는 것은 아니다. 물론 웹에서 프론트의 기능은 사용자가 처음부터 경험하게 되는 중요한 요소 중 하나이긴 하지만 이 밖에도 다양한 영역에 사용자를 만족시킬 수 있는 여지가 남아있다. 예를 들어 보자. 애플은 다른 경쟁사들과 기능상으로 큰 차이가 없는 제품을 출시하면서도 사용자에게 차별화된 디자인 경험을 제공하여 큰 인기를 끌고 있다.

<사진1>디자인을 통해 차별화된 UX를 제공하는 애플사의 iPhone과 그렇지 않은 타사의 핸드폰

하지만 아무리 디자인이 이쁘고 사용자 인터페이스가 혁신적이더라도, 내구성이 약하거나 고장이 자주 발생한다면 어떨까? 이와 같은 상황은 사용자의 경험이란 측면에서 디자인과 같은 외양적 측면보다 더욱 더 집중해야할 문제이다. 과거 삼성전자는 빠른 서비스 센터의 확충을 통해 다른 경쟁사에 비해 신속하고 안정적인 AS를 제공했고, 그로 인해 긍정적인 사용자의 경험을 이끌어낸바 있다. 이와 같은 사용자 경험이 모여 긍정적인 브랜드 이미지가 구축이 되었고 삼성전자는 그 후 출시하는 전자제품마다 승승장구하게 된다. 이와 같이 긍정적인 사용자 경험, 즉 UX는 사용자 인터페이스 외에도 다양한 영역으로 발현될 수 있다.

다시 과거의 경험으로부터 웹으로 돌아오자. 웹에서의 UX도 마찬가지이다. 디자인이나 사용자 인터페이스외 에도 UX를 개선할 수 있는 부분은 수없이 많다. 삼성전자의 예를 들었듯이 사용자가 서비스를 버그없이 쾌적하게 이용할 수 있는 환경을 만들어주는 것은 그 무엇보다 선행되어야할 UX 실무 사례이다. 하지만 서비스 제공자가 사용자 인터페이스만 강조하는 UX를 추종하다가는 사용자를 섬기는 기본적인 자세를 망각하고 이론이나 기술로만 문제를 해결하려는 잘못된 의사결정을 할 수 있다. 이처럼 현재 웹에서의 UX 도입은 사용자 인터페이스를 넘어 다양한 방법으로 사용자를 만족시켜야 하는 과제에 당면해 있다. 이러한 과도기적인 현실 속에서 개발자는 다양한 곳에서 보이지 않는 중요한 역할을 수행한다. 플렉스나 실버라이트와 같은 기술을 사용하지 않고서도 말이다.

사이트의  속도를 최적화하라.

사용자 인터페이스나 디자인을 강조하는 UX가 트렌드가 되버린 지금, 많은 웹 페이지들이 그에 관련된 기술이나 모듈을 풍부하게 사용하고 있다. 하지만 그럼으로 인해 웹 페이지가 무거워져서 느려진다면 사용자는 그 편리한 기능의 웹 페이지를 제대로 이용할 수가 없을 것이고 부정적인 경험만 갖게 될 것이다. UX 기술을 반영하여 UX를 부정적으로 만들어버리는 것은 결코 우리가 원하던 상황이 아니다.

UX의 관점에서 사이트의 반응 속도를 빠르게 하는 것은 굉장한 경쟁력이다. 이는 데이터 위주의 웹 2.0의 관점에서도 마찬가지이다. 웹 2.0은 사용자의 참여를 가장 핵심으로 여긴다. 사이트의 반응속도가 빠르다면 그만큼 사용자의 참여는 늘어날 것이고 가치 있는 데이터는 급속도로 불어나게 될 것이다. 야후는 이런 중요한 미션을 공식적으로 UX로 인식하고 회사 차원에서 해결을 시도하고 있는 대표적인 사이트이다.

<그림1> http://www.yahoo.com의 웹 페이지 구성요소 반응 속도 차트

<그림1>은 사용자가 야후에 접속했을 때 웹 페이지 구성요소가 브라우저로 다운로드되는 순서를 순차적으로 그린 것이다. 그림의 맨 처음을 보면 html 코드가 사용자에게 다운로드되는 시간은 전체 시간 중 5%에 불과하다는 사실을 알 수 있다. 야후 뿐만 아니라 미국의 다른 Top 10 사이트들 역시 html의 다운로드 시간은 20% 이하라고 한다. 바꿔 말하면 사용자들이 html안에 담긴 이미지나 그 밖의 것들을 다운로드하는데 80%의 시간을 소비한다는 뜻이다. 이 80%를 차지하는 프론트 요소들을 튜닝하면 사이트의 반응속도를 현저히 빠르게 만들 수 있다. 다음은 프론트의 반응 속도를 높일 수 있는 간단한 방법들이다.

1. HTTP 요청을 최소화해라.

웹 페이지의 HTTP 요청 객체 수는 프론트의 성능에 매우 중요한 영향을 미친다. 조사에 따르면 HTTP 1.0 서버는 4개의 객체를 동시에 전송하고, HTTP 1.1 서버는 2개의 객체를 동시에 전송한다. 즉 웹 페이지 안에 수많은 객체들이 존재하더라도 한 호스트당 한번에 2개나 4개 이상 다운로드할 수밖에  없다. 이미지의 개수는 이미지의 사이즈만큼 프론트 속도에 중요한 영향을 미치는 것이다. 그러므로 불필요하게 나눠져 있는 스크립트나 CSS 파일은 합치는 것이 좋다. 그리고 이미지를 잘게 나누는 것보다 통합하여 이미지 맵을 사용하는 것이 바람직하다.

2. 캐쉬를 활용해라.

브라우저는 캐쉬를 사용해서 HTTP 요청을 줄이고, 페이지를 빨리 로딩할 수 있다. 웹 서버는 Expires 헤더를 HTTP 응답에 추가하여 브라우저의 캐쉬를 제어한다.

Expires: Thu, 15 Apr 2010 20:00:00 GMT

위와 같이 헤더를 추가하면 2010년 4월까지 호출한 웹 페이지의 캐쉬를 저장할 것이다.

3. Gzip을 이용해라.

웹 페이지는 네트웍을 통해 클라이언트로 전달되므로 네트웍으로 전송되는 패킷의 사이즈가 프론트 속도에 매우 중요한 영향을 미친다. Gzip과 같은 압축 툴을 사용하여 웹 페이지의 양을 줄인다면 프론트의 속도는 증가하게 될 것이다. HTTP1.1부터 브라우저는 웹 페이지를 호출시 다음과 같은 헤더를 추가하여 압축을 지원함을 표시할 수 있다.

Accept-Encoding: gzip, deflate

웹 서버는 HTTP 응답의 헤더에 다음과 같은 헤더를 추가하여 현재의 컨텐츠가 압축된 상태임을 표시한다.

Content-Encoding: gzip

Gzip은 가장 대중적이고 효율적인 압축 기술로 HTML이나 CSS, 자바스크립트 파일에 사용하면 네트워크 트래픽을 효과적으로 줄일 수 있다.

4. 외부 파일의 위치를 조정하라.

CSS 파일은 위에(HEAD 태그 위치) 포함시켜라. CSS 파일을 먼저 읽고 그 밑에 HTML을 순차적으로 렌더링하도록 만들기 위해서다. 스크립트 파일은 가능한 아래에 포함시켜라. HTML이 다 렌더링된 후에 자바스크립트를 다운로드받도록 하기 위해서다. 이와 같은 조치는 HTML이 다운로드된 후에 사용자에게 빨리 보여지는 효과를 가져다준다.

5. 자바스크립트를 압축하라.

인터넷에는 다양한 자바스크립트 압축 도구가 있다. 이 압축 도구들은 주로 텍스트의 개행 문자와 빈 공간, 빈 줄을 없애고, 변수 명을 압축하며(var frontIndex -> var f), 대문자를 소문자로 변경하는 식으로 불필요한 문자의 양을 줄인다. 다음은 몇 개의 압축 도구이다.

- JSMin : http://www.crockford.com/javascript/jsmin.html

- YUI Compressor : http://developer.yahoo.com/yui/compressor/

이외에도 프론트의 반응 속도를 증가시킬 수 있는 수많은 방법이 있지만 간단하고 범용적인 방법 위주로 열거해 보았다. 필자의 경험상 각 사이트의 특성이나 구조에 따라서 반응 속도를 늦추는 부분이 특화되어 있기 때문에, 자사의 사이트가 어떤 구조적 특징을 가지고 있는지 먼저 분석해보기 바란다.

DBA는 쿼리를 튜닝하여 DB의 퍼포먼스를 증가시키는 역할을 한다. 사이트의 전체 구성에서 DB는 백엔드(Back-end)에 속한다. 그러므로 사이트의 한 부분인 DB의 성능을 튜닝하면 사이트의 속도가 증가한다는 사실을 누구나 인식하고 있고, 그에 대한 중요성도 알고 있다. 이외에도 사이트의 성능을 개선시키기 위해 하드웨어를 추가하거나 시스템 설계를 다시 하기도 한다. 하지만 프론트의 반응 속도를 증가시키는 것을 DB나 서버를 튜닝하는 것만큼 중요하게 생각하는 사람은 많지  않다. DB 튜닝 전문가는 존재하지만 프론트 튜닝 전문가가 없다는 사실이 그러한 현실을 반증한다. 사용자의 경험이 이렇게 보잘 것 없었던가? 대신 개발자가 보살펴주자. UX 전문가는 UI를 분석하여 사용자의 반응 속도를 최적화하지만 개발자는 그보다 앞서 사이트의 속도를 최적화할 수 있다.

웹 사이트를 분석하는 기술을 길러라.

UX를 고려한 제품을 만들어 사용자가 만족스럽게 이용하고 있다고 가정하자. 갑자기 돌발적인 상황으로 인해 제품에 문제가 발생했다. 그때부터 진정한 UX의 세계가 시작된다. 사용자가 그 문제를 신속하게 해결하지 못한다면 혁신적인 사용자 인터페이스와 기발한 디자인은 사용자의 긍정적인 경험에 아무런 도움이 되지 못한 채 무용지물이 될 것이다. 문제가 해결되기 전까지 사용자의 불만은 늘어만 갈 것이다. 자, 이제 어떻게 해야 하나?

일반적으로 사용자가 제품을 이용하다가 문제가 발생해 불만족스러움을 느끼는 것을 방지하는 방법은 세 가지가 있다. 아예 문제가 발생하지 않도록 최대한의 테스트 공정을 거쳐 제품을 출시하거나, 문제가 생겼을 때 해결해 주는 방법을 기술한 풍부한 매뉴얼을 포함하거나, 최종적으로 A/S를 해주는 방법이 있다. 이와 같은 방법들은 제품을 이용하다가 예상치 못한 상황에 처한 사용자의 경험을 다소 힘들지만 긍정적으로 바꿔준다. 웹 사이트는 이와 같은 경우 좀 더 유리한 상황에서 대처할 수 있다. 웹 사이트를 분석하여 사용자가 어떤 경험을 하고 있는지 모니터링할 수 있고, 실시간으로 해결책을 제시할 수 있기 때문이다. 심지어는 문제와 사용자가 아예 만나지 못하게 만들 수도 있다.

웹사이트 분석은 기술적으로 크게 두 가지 방법으로 이뤄질 수 있다. 하나는 웹 서버 로그 파일 분석이고 다른 하나는 스크립트 태깅(Script Tagging) 분석 방법이다. 웹 서버 로그 파일 분석은 말 그대로 사용자가 웹 서버를 호출한 정보를 파일에 저장하여 다양한 관점에서 분석하는 방법이다. 웹 서버는 기본적으로 로그 파일을 남기도록 설정할 수 있고, 다양한 옵션을 통해 저장되는 내용도 조절할 수 있기 때문에 쉽게 대용량의 사용자 데이터를 얻을 수 있다. 하지만 이 대용량의 데이터를 목적에 맞게 분석하기에는 많은 비용이 들기 때문에 이를 해결하기 위해 전문적인 웹 데이터 분석 솔루션이 존재한다. 다음은 그중에서도 무료로 제공되는 몇 가지 분석 솔루션들이다.

이름	특징
Analog	세계에서 가장 많이 쓰이는 웹 데이터 분석 솔루션이다.
AWStats	Perl 기반의 오픈소스로 목적에 맞게 수정하여 사용할 수 있다.
Log Parser 2.0	마이크로소프트에서 개발했으며 IIS에 적용할 수 있다.

<표1> 무료 웹 데이터 분석 솔루션

스크립트 태깅 분석 방법은 웹 로그 파일 분석 방법에 비해 비교적 간단하고 많은 유연성을 가지고 있어 개발자들이 목표를 가지고 쉽게 시도해볼만하다. 스크립트 태깅은 다음과 같은 스크립트를 기초로 이뤄진다.

<script>  document.write('<img src="http://www.yourserver.com/cgi-bin/readtag.pl?  url='+escape(document.location)+'&amp;ref='+escape(document.referrer)+'">');  </script>

원리는 간단하다. 자바스크립트가 외부 서버에 동적으로 투명 이미지 파일을 요청하면서, 수집한 정보를 파라미터로 함께 넘기는 것이다. 이 방법은 전문 분석 소프트웨어에 비해 많은 유연성을 가지고 있다. 자바스크립트를 이용하기 때문에 웹 페이지 호출뿐만 아니라 버튼 클릭이나 자바스크립트를 사용한 사용자 인터페이스, 플래시와 같은 외부 객체에 대한 사용자의 행동까지 저장할 수 있다. 사이트의 모든 페이지가 중요하겠지만 그중에서도 수익에 직접적인 영향을 미치는 페이지가 있을 것이다. 그런 부분에 집중적으로 사용자의 행동을 저장하고 분석한다면 UX를 개선하여 사이트의 이익을 증가시키는 직접적인 효과를 거둘 수 있을 것이다. 예를 들어 쇼핑몰의 장바구니 기능처럼 말이다.

<그림 2> 온라인 쇼핑 다단계 과정

일반적인 온라인 쇼핑은 다음과 같은 일련의 과정을 겪기 마련이다. 이 과정을 하나의 분석 미션으로 정해 순차적으로 데이터를 기록해 보자. 1단계부터 5단계까지 차례로 진행하면서 사용자가 점점 이탈하는 현상을 목격할 수 있을 것이다. 만약 3단계에서 4단계로 넘어가는 시점에 사용자의 참여가 급격히 떨어지는 것을 목격한다면 “3.배송정보 입력“ 단계에 문제가 있거나 UX가 형편없다는 증거가 되겠다. 3단계에서 부족한 부분을 분석하고 보완하자. 그로 인해 3단계까지 도착했던 사용자를 4단계로 더 이동하게 만든다면, 좀 더 많은 사용자의 결제가 이루어질 것이고, 우리의 UX에 대한 노력은 곧바로 수익으로 직결될 것이다.

더욱 적극적으로 UX를 보강하려 한다면 페이지 단위로 단계로 나누는 것 외에 사용자 인터페이스 단위로 단계를 나눌 수도 있다. 입력할 정보가 많은 쇼핑몰 주문에서 데이터를 입력받는 인터페이스의 편리함은 매출과 적잖은 연관이 있다. 사용자가 사용자 인터페이스를 동작시킬 때의 행위를 데이터로 기록하여 분석한다면 사용자의 불편함을 콜센터로 전화하기 전에 미리 눈치챌 수 있을 것이다. 자바스크립트의 onerror 이벤트가 발생했을 때 스크립트 태깅으로 로그를 남긴다면 서비스 제공자가 미처 알아차리지 못한 스크립트 버그들도 찾아낼 수 있다. 이밖에도 사용자를 만족시키기 위한 수많은 개발 팁들이 존재한다. 단지 우리는 그것의 중요성을 인식하지 못할 뿐이다.

물론 웹 데이터를 저장하고 분석하는 일은 개발자가 아니라 웹 데이터 분석 전문가가 해야 할 일처럼 여겨질 수 있다. 하지만 개발자는 자신이 만든 제품의 특징이나 취약한 부분을 알고 있기 때문에 작은 비용으로 사용자의 경험을 드라마틱하게 변화시킬 수 있다. 그것도 사용자가 문제를 인식하기 전에 말이다.

UX는 차세대 개발자의 기본적 소양

지금까지 UX는 사이트의 중요한 경쟁력이고, 개발자가 UX의 많은 부분에 직간접적으로 관여하고 있음을 알아보았다. 위에 언급한 내용 외에도 개발자가 UX에 기여할 수 있는 사례들은 무수히 많다. 신기술을 도입할 때 철저히 검증하는 것도 UX를 위한 개발자의 몫이다. 과거 RIA 기술의 열풍이 불었을 때 별다른 내부 검증 없이 RIA를 사이트 전체에 도입했던 회사들을 기억한다. 물론 전보다 더욱 느려진 사이트에 불만을 느끼는 사용자들만 늘어났다. 이와 같은 상황은 아직도 주변에서 쉽게 살펴볼 수 있다. 하물며 XP나 스크럼으로 대변되는 애자일 개발 방법론조차도 사용자 위주의 결과물 즉 UX를 만족시키는 결과물을 내놓기 위한 고난의 과정일 뿐이다. 이렇듯 개발팀의 액션 플랜이나 개발자의 의사결정 하나하나가 UX를 좌지우지하는 상황을 만들어낸다. 하지만 우리는 그것을 인식하지 못한다. 더 큰 문제는 조직 내에서도 그것을 인정하지 않고 있다는 것에 있다.

기획자는 좋은 비즈니스 모델이나 기획으로 사용자에게 호평을 받을 수 있다. 디자이너 역시 비록 주관적이긴 하지만 이쁜 디자인이라는 가시적인 성과로서 사용자에게 어필할 수 있다. 다른 직군들은 대부분 사용자가 직접적으로 느끼는 영역에 대해 업무를 수행하기 때문에 사용자의 호불호라는 직접적인 평가를 받게 된다. 하지만 개발자는 어떤가. 기획자나 디자이너의 결과물을 제대로 구현했는가라는 다소 궁색한 잣대로서 조직에서 평가를 받게 된다. 즉 조직 내에서 사용자와는 상관이 없는 직군이라는 어이없는 평가를 받고 있는 것이다. 바로 이런 현실이 개발자를 단순히 웹 사이트를 움직이는 수많은 톱니바퀴 중 하나처럼 취급받도록 만든다. 하지만 지금까지 설명했듯이 개발자는 사용자와 매우 밀접한 관계를 맺고 있는 직군이다. 즉 서비스의 성패를 좌우할 수 있는 직군이란 소리이다.

이와 같은 부당한 인식을 바꾸기 위해 개발자들 또는 개발팀들은 본인들이 개선할 수 있는 UX를 체계화하고 미션화하는 능력을 길러야 한다. 그리고 그에 대한 성과를 수치화시켜서 조직에 제시할 수 있어야 한다. 개발자들이여. 회사에서 나는 이렇게 중요한 인재라고 항변하자. 그것은 전적으로 우리를 위해서만은 아니다. 영문도 모른 채 사이트에서 불쾌한 경험을 하고 있는 사용자들을 위해서이다.

]]>

박지강 (jkwave@gmail.com) 개발 및 번역 프리랜서로 활동해왔으며 현재 SK 커뮤니케이션즈에서 근무 중이다. 역서로는 "프로젝트 데드라인"(한빛미디어)이 있으며, 최근 "당신은 웹 2.0 개발자입니까?"(한빛미디어)를 집필하였다..기술을 이용한 기획과 전략, 열린 전략적 제휴, 일인 기업에 관심이 많으며, 현재 목표는 스스로 기획하고 개발하고 디자인한 서비스를 대중들에게 공개하는 것이다.

웹을 고안한 팀 버너스 리, 윈도우의 빌 게이츠, 리눅스의 리누스 토발즈 등은 누구나 한번쯤은 들어봤을 법한 이름들이다. 이 컴퓨터 괴짜들은 우리가 편리한 세상을 누리는데 많은 도움을 준 위인들로 익히 알려져 있다. 하지만 이 유명한 괴짜들조차도 컴퓨터의 도움 없이는 어떤 혁신적인 성과도 이뤄낼 수 없었을 것이다. 아쉽게도 컴퓨터를 고안한 영웅들의 이름들은 우리에게 널리 알려져 있지 않다. 마치 우리가 에디슨의 이름은 알지만 일상 생활에 없어서는 안 될 성냥이나 우산 등을 발명한 사람의 이름을 알지 못하듯이 말이다.

앨런 튜링(Alan Turing)  :  현대 컴퓨팅의 아버지

1930년대, 겨우 20대였던 앨런 튜링은 현대 컴퓨터와 프로그램이 동작하는 원리가 설명된 추상적인 수학 모델을 세상에 내놓았다. 바로 "튜링 머신(Turing Machine)"이다. 앨런 튜링은 자동화된 디지털 컴퓨터를 만들 목표로 연구하지 않았다. 그는 수학가였으므로 컴퓨팅에 대한 자신의 가설을 수학적으로 증명하는데 매진하였다. 튜링 머신 또한 단지 계산 가능한 함수(computable function)를 정의하기 위한 수단으로서 고안해낸 것이다. 하지만 그 여파는 대단하여 지금까지도 컴퓨터 산업에 큰 영향을 미치고 있다.

튜링 머신은 알고리즘을 수학적이고 기계적인 절차들로 분해하여 동작할 수 있는 컴퓨터의 실행과 저장에 관한 추상적인 모델이다. 튜링 머신은 애초에 무엇이 계산되어질 수 있는지에 대한 범위를 규정하기 위해 정의 되었다. 튜링 머신을 소개한 논문을 한마디로 요약하면 이렇다. "만약 튜링 머신에 의해 계산될 수 있으면 그 함수는 계산 가능하다." 튜링 머신의 실행이 중간에 멈추지 않고 끝까지 실행되는 경우를 계산 가능하다고 정의한 것이다.

<그림 1>에서 보다시피, 튜링 머신 그 자체는 실제 기계가 아니라 수학 원리로 구성된 가상 기계이다. 튜링 머신의 동작을 이해하면 튜링의 업적과 현대 컴퓨터에 끼치는 영향력을 온전히 느낄 수 있다.

 

 <그림 1> 튜링 머신의 구조

튜링 머신은 <그림 1>에서 보다시피 다음과 같은 4가지 요소로 구성된다.

1) 테이프(tape) : 사각형의 셀들이 일렬로 나열되어 있다. 각 셀들 안에는 한정된 심볼(숫자나 문자)이 들어간다. 테이프의 길이는 무한정하다.

2) 헤드(head) : 테이프의 셀 안에 있는심볼을 읽고 쓰며 좌우로 이동하는 장치이다.

3) 상태 레지스터 (state register) :  튜링 머신의 현재 상태 값(심볼)을 저장하는 공간으로서 값들은 한정되어 있다.

4) 액션 테이블(action table) : 튜링 머신이 셀을 읽고 쓰며 헤드를 좌우로 이동하고 상태를 변경하게 하는 명령어들의 집합이다. 보통 (현재 상태, 현재 심볼, 새로운 상태, 새로운 심볼, 왼쪽/오른쪽 이동)들로 표현된다. 각 명령어들의 해석 방법은 이렇다. 만약 상태 레지스터에 있는 값이 "현재 상태" 값이고 헤드가 "현재 심볼"을 읽었다면 상태 레지스터의 값을 "새로운 상태" 값으로 변경하고 "현재 심볼" 값을 "새로운 심볼" 값으로 바꾼 다음에 왼쪽 또는 오른쪽으로 이동한다. 만약 상태 레지스터와 헤드가 읽는 값에 대응되는 명령어가 액션 테이블에 없다면 수행을 멈춘다.

마치 어셈블리 언어를 보는 것 같지 않는가? 현대의 관점에서 튜링 머신의 "테이프"는 데이터들의 메모리, "액션 테이블"은 그 데이터를 조작하는 프로그램의 명령어들로 볼 수 있다. 현대의 컴퓨터는 튜링 머신을 구현한 자동화된 기계로서, 0과 1로 이루어진 이진 데이터를 메모리에 저장하고 프로그램의 명령을 중앙처리장치에서 해석함으로서 여러 종류의 계산을 위해 새로운 기계를 만들 필요가 없는 "범용 전자 기계"이다. 프로그램(program)은 심볼들을 이용해 기계에게 명령을 내리는 의미있는 심볼들의 집합체이며, 프로그래밍이란 프로그램을 만드는 과정이다. 프로그램 언어(program language)는 프로그램을 만들기 위한 심볼들의 의미와 관계를 규정한 것이다. 앨런 튜링의 위대한 점을 요약하면 프로그래밍이 가능한 컴퓨터의 수학적 원리를 제시함과 동시에 "테이프"에 있는 데이터와 액션 테이블의 명령어들이 같은 형식의 심볼들(숫자와 문자들)로 구성하였다는 것이다. 데이터(data)와 프로그램(program)을 동일한 방식으로 저장하고 처리할 수 있는 길이 열린 것이다.

앨런 튜링의 아이디어는 존 폰 노이만(John Von Neumann)에 의해 결실이 맺어진다. 앨런 튜링이 프린스턴 대학에서 박사학위를 받을 동안, 지도 교수였던 노이만은 튜링 머신의 아이디어에 관심이 많았으며 앨런 튜링에게 공동으로 연구를 진행하자고 제의하였다. 하지만 튜링은 요청을 거절하고 박사 학위를 받은 후 영국으로 돌아갔다. 그 후 1951년, 노이만은 튜링 머신의 원리를 구현한 프로그램 내장 방식(stored program)의 디지털 컴퓨터인 애드박(EDVAC)을 개발하여 현대 컴퓨터의 원형을 만들었다. 에드박은 10진법이 아닌 2진법을 사용했으며 프로그램 내장 방식의 최초의 컴퓨터이다. 프로그램 내장 방식이란 프로그램을 기억장치에 저장해두고 명령을 순서대로 중앙처리장치가 해석하며 실행하는 것을 의미하며 하드웨어는 중앙처리장치와 메모리가 구별된다. 튜링 머신의 "테이프"와 "액션 테이블"이 각각 데이터와 프로그램의 형태로 컴퓨터 메모리 안에 동시에 저장되어 처리되는 것이다. 현대 대부분의 컴퓨터들은 노이만 방식의 컴퓨터 아키텍처를 채택하고 있다.

하지만 앨런 튜링이 사회에서 고귀한 명성만을 얻었던 것은 아니다. 튜링은 동성애자였다. 1952년, 동성애 파트너가 자신의 집에 도둑질 한 것을 경찰에 신고하면서 그가 동성애자라는 사실이 외부에 알려지게 되었다. 동성애자를 혐오하는 당시 사회적 분위기 속에서 경찰의 감시를 받게 되었고 동성애성을 감소시킨다는 에스트로겐 호르몬을 강제로 투여 받는다. 약물 부작용으로 가슴이 여성처럼 부풀어오르는 수모를 당하면서 2차 대전의 영웅이자 현대 컴퓨팅 모델의 창시자인 그는 결국독이 든 사과를 먹고 자살한다. 그때가 1954년이다. 그의 죽음 후 세계적인 컴퓨터 학회인 ACM(Association for Computer Machinery)은 컴퓨팅 분야의 노벨상인 튜링 상을 제정하여 컴퓨팅 분야에 지대하게 공헌한 사람에게 매년 시상한다. 

<애플사의 로고와 앨런 튜링의 독이 든사과> 많은 이들이 한 입 베어 먹은 사과 모양의 애플사 로고를 보고 앨런 튜링이 자살했을 때   먹은 독이 든 사과를 흉내낸 것이라고 주장한다.  <그림 2> 애플사의 로고 하지만 애플사는 그 주장을 공식적으로 부인하였다. 하지만 애플사의 컴퓨터가 튜링의 영향을 받았다는 사실은 부인할 수 없을 것이다.

* 튜링 머신이 어떻게 동작하는지는 지면 관계로 자세히 설명하지는 못하지만, 좀 더 자세한 정보를 얻고 싶다면 인터넷에서 자바 애플릿으로 구현된 튜링 머신 사이트(http://www.igs.net/~tril/tm/tm.html)를 방문해보자.

배니바르 부시(Vannevar Bush)  :  컴퓨터를 통한 지식의 확장

20세기 초반, 에니악과 같은 초창기 컴퓨터들은 엄청난 비용이 들어 개발되었고 더군다나 크기도 거대했기 때문에 주로 국가나 기업의 특수한 목적으로 활용되었다. 일반 개인들이 사사로운 일과 업무 처리를 하기 위해 그런 거대한 컴퓨터를 사용한다는 것은 상상할 수 없었다. 하지만 부시는 2차 대전이 끝날 때 즈음, 전쟁을 위해 종사한 과학이 인류에게 관심을 돌려야 한다고 생각했다. 전쟁에 승리하기 위해 미사일의 탄도를 자동으로 계산했던 에니악 컴퓨터, 대량 살상용 무기인 핵폭탄 등을 만들기 위해 더 이상 과학 기술이 사용되는 것을 원하지 않았다.

1945년에 부시는 시사 월간지인 애틀랜틱 매거진 (Atlantic Magazine)에 "우리가 생각하는 것처럼(As We May Think)"이란 제목으로 IT역사에 혁명적인 에세이를 기고하게 된다. 이 원고에서 전쟁이 끝나고 나서는 과학자들이 더 이상 인간의 물리적 힘을 확장 시키는 데 열중하지 말고 인간이 가지고 있는 지식의 파워를 증폭시키는 연구를 진행해야 한다고 촉구하였다. 그는 인간이 여러 세대에 걸쳐 축적한 방대한 지식들을 빠르게 검색하고 이용하게 되면 인류의 정신적 능력은 크게 확장되고 발전된다고 믿었다. 그러기 위해서는 각 개인들이 자신들이 생산하는 정보와 지식들을 저장하고 빠르게 검색하는 소형 컴퓨터 시스템이 필요하다고 주장하였으며 그것이 메멕스다. 에세이 내에서 메멕스의 구성과 기능은 자세하게 묘사되었지만 당시 과학 기술이 갖는 한계 때문에 실제로 개발되지는 않았다. 하지만 그 후 메멕스로부터 영향을 받은 수많은 IT 개척자들이 노력하여 지금과 같은 개인용 컴퓨터와 월드 와이드 웹이 탄생하게 된다. "우리가 생각하는 것처럼" 에서 메멕스는 <그림 3>과 같이 그림으로 자세히 묘사되었다.

<그림 3> 라이프지에 실린 메멕스의 모습

책상 위 맨 왼쪽의 사각형은 개인의 노트, 책, 기록 등의 정보를 사진화하여 입력하는 스캐닝(scanning) 장치이고 가운데 2개의 사각형은 모니터 역할을 하는 스크린(screen) 장치이다. 맨 오른쪽에는 화면에 나오는 정보를 검색하고 조작하는 키보드와 레버, 버튼 등이 있다. 책상 안에는 전기에 의해 동작하는 아날로그 자동 장치들이 존재한다. 책상 내부의 동그란 원형 장치들은 스캐닝 시스템에 의해 정보가 저장되는 마이크로 필름들이다. 사용자가 키보드와 레버, 버튼을 눌러 원하는 정보를 입력하면 메멕스의 내부장치는 마이크로필름에서 해당 정보를 찾아서 영화 영사기처럼 가운데 스크린 장치에 투사한다. 무엇보다 중요한 것은 사용자는 스크린에 보여지는 정보들 중 서로 관련 있는 것들을 링크(link)로 연결할 수 있고 나중에 그 링크를 선택하면 해당되는 정보로 곧장 빠른 속도로 이동할 수 있다는 것이다. 마치 우리가 웹 브라우저를 사용하여 어떤 웹사이트의 내용을 보고 있을 때 하이퍼링크된 특정 단어를 선택하면 해당되는 정보로 곧장 이동할 수 있는 것처럼 말이다. 이처럼 메멕스는 현재의 개인용 데스트탑 환경과 월드 와이드 웹이 결합된 형태와 유사하다. 메멕스의 출현 30년 후에 개인용 컴퓨터가 나오게 되었으며 50년 후에 월드와이드 웹이 세상에 나타나 부시의 예언대로 인류의 지식은 한층 확장되게 되었다. 지금으로부터 60 년전, "우리가 생각하는 것처럼" 에서 부시가 주장한 미래의 모습은 이렇다.

"수많은 정보들 사이에 링크가 연결된, 완전히 새로운 형태의 백과사전이 나타나고 그것은 메멕스안에 저장될 수 있다. 변리사는 수백만 건의 특허정보들 중에서 그의 고객이 관심 있어 하는 부분들만 링크로 연결해 따로 확인할 수 있다."

오. 현명한 예지자여.

이반 서덜랜드(Ivan Sutherland)  :  컴퓨터와 인간의 그래픽 대화

텍스트 기반 운영체제인 MS-DOS를 썼던 컴퓨터 사용자들은 지금의 GUI 환경이 얼마나 편리한지 설명하지도 않아도 알 것이다. 화면에 나열된 정교하고 예쁜 아이콘을 마우스로 누르면 컬러풀한 프로그램이 내가 손을 움직이기를 기다린다. 이반 서덜랜드는 컴퓨터와 인간 사이에 그래픽이란 중간 매개체를 놓았다. 그 덕분에 우리는 정밀한 하드웨어 덩어리를 예쁘게 사용하고 있다. 서덜랜드가 컴퓨터 그래픽을 연구하는데 중요하게 사용된 컴퓨터는 MIT의 링컨 연구소(Lincoln Laboratory)에서 1959년에 만들어진 TX-2이다. 이 컴퓨터는 원래 트랜지스터(transistor)가 디지털 회로에 잘 사용될 수 있는지 확인하기 위해 개발되었다. 이전의 컴퓨터들은 대부분 진공관(vacuum tube)으로 만들어졌다. 트랜지스터는 진공관보다 상대적으로 안정성이 높았다. 서덜랜드는 이 컴퓨터를 새벽 3시부터 5시까지 사용했던 유일한 대학원 생이었다고 한다. 

<그림 4> TX-2에 앉아있는 라이트펜을 쥐고 있는 서덜랜드

TX-2는 펀칭한 종이를 컴퓨터 오퍼레이터에게 제출하던 기존의 컴퓨터 동작 방식과는 달랐다. 즉 프로그래머가 컴퓨터에 붙어서 직접 작업할 수 있는 온라인(online) 방식이었다. <그림 4>처럼 프로그래머는 컴퓨터에 프로그램을 직접 입력하고 결과를 컴퓨터 오퍼레이터가 아닌 컴퓨터로부터 즉시 받을 수 있었다. 이런 장점 때문에 서덜랜드는 TX-2 앞에 붙어서 "스케치패드(sketchpad)"란 그래픽 프로그램을 성공적으로 개발할 수 있게 되었다. TX-2에서는 프로그램을 개발하고 수정하며 확인하는 것이 상대적으로 쉬었던 것이다. 서덜랜드는 박사 학위의 주제를 고민하던 중에 TX-2의 콘솔에 달려있는 <그림 5>의 라이트펜을 보고 컴퓨터를 사용하여 그림을 그리는 아이디어를 생각해 낸다.

<그림 5> 라이트 펜

만약 TX-2가 없었다면 컴퓨터 그래픽의 시초를 연 논문인 "스케치패드 : 사람과 기계와의 그래픽 대화 시스템(The Sketchpad : A Man-Machine Graphical Communication System)"는 세상에 나오지 못했을 것이 분명하다. 후일에 TX-2를 개발한 웨스 클락(Wes Clark)은 자신이 만든 이 컴퓨터를 누군가가 홀로 최대한 이점을 살려 잘 사용해 주길 바랬다고 한다. 그 사람이 바로 이반 서덜랜드였던 셈이다. 서덜랜드는 1963년도에 "스케치패드 : 사람과 기계와의 그래픽 대화 시스템" 라는 박사 학위 논문을 쓰면서 TX-2에서 동작하는 스케치패드(SketchPad)란 그래픽 프로그램을 만든다. 이 프로그램은 텍스트 기반의 출력 방식 밖에 없었던 그 시대에는 매우 혁명적인 소프트웨어였으며 사람이 컴퓨터를 다루는 방식을 근본적으로 변화시키게 되는 동력이 되었다. GUI(Graphical User Interface)라는 용어가 나오기 훨씬 이전에 이미 GUI의 기본 요소를 완전히 구현한 최초의 프로그램이었다. 종이 테이프의 실행 결과를 텍스트로 받았던 프로그래머들과 일반 사용자들은 선, 사각형, 원 등의 기하학적 도형을 콘솔 모니터에 그릴 수 있게 되었다.

1981년에 제록스 파크(Xerox PARC)는 당시 연구소에서 가장 발전된 기술을 적용해 상업적인 컴퓨터를 만들려고 시도했다. 제록스 스타 워크스테이션(Xerox Star Workstation)이 그 결과물이었다. 특히 당시에 컴퓨터 마우스로 아이콘을 다루어 데스크탑을 사용하는 혁명적인 GUI를 최초로 선보였는데, 이때 참여했던 제록스(Xerox) 연구원인 스미스(D.C Smith)는 제록스 스타의 혁신적인 GUI는 스케치패드로부터 많은 영향을 받았다고 회고했다.  이 컴퓨터의 GUI는 향후 맥킨토시와 윈도우 인터페이스에 큰 영향을 미치게 된다. 스케치패드는 윈도우와 매킨토시로 이루어진 현대 개인용 컴퓨터의 GUI에 근본적인 영향을 끼친 것이다.  이처럼 서덜랜드는 일반 개인들이 그래픽을 사용해 컴퓨터를 쉽게 다룰 수 있도록 기존의 텍스트 기반의 인터페이스라는 장벽을 부수는데 결정적인 기여를 한 사람이다. 그와 같은 공로로 1988년에 튜링상을 수상하였다.

더글라스 엥겔바트(Douglas Engelbart)  :  마우스를 넘어

배니바르 부시의 비전과 메멕스에 감명을 받은 과학 기술자들이 이 세계에 미친 영향은 거대하다. 월드 와이드 웹을 만든 팀 버너스 리, GUI의 시발점을 제공한 이반 서덜랜드도 그의 영향력 아래 있다. 하지만 더글라스 엥겔바트만큼 그의 비전을 실행하기 위해 자신의 일생을 바친 사람은 없다. 배니바르 부시의 메멕스를 실제로 구현하기 위해 엥겔바트가 설계한 NLS(oN Line System)라는 컴퓨터 시스템은 후대의 컴퓨터와 소프트웨어 발전에 지대한 파급효과를 가져왔다.

<그림 6> NLS 시스템

NLS는 ARPA, NASA, US 공군으로부터 자금을 공급받아 개발된 컴퓨터로서 ARPANET에 연결된 혁명적인 그룹웨어 시스템이었다. 네트워크에 연결되어 여러 사람들이 협력하며 문제를 해결하는 것을 도와주는 시스템이다. 이 컴퓨터는 세계 최초로 컴퓨터 마우스가 장착되었고 하이퍼미디어를 구현하였으며 스크린 기반의 원격 비디오 화상 대화 기능을 실현하였다. NLS는 1968년에 대중에게 공개적으로 시연 되었는데 그것은 모든 데모의 어머니(Mother of Demo)라 불리울 정도로 쇼킹하고 감동적이며 역사적인 이벤트였다.

1968년 12월 9일, 엥겔바트는 샌프란시스코에 있는 컨벤션 센터에서 열린 컴퓨터 컨퍼런스에서 1000여 명의 컴퓨터 전문가들에게 기존에 행해지던 방식과 완전히 다르게 NLS를 시연하였다. 엥겔바트는 컨퍼런스 홀에서 헤드셋을 착용하고 데모를 진행했다. 이 데모에서 엥겔바트는 다음과 같은 세계 최초의 컴퓨터 기술들을 선보인다. 이들은 대부분 현대 개인용 컴퓨터의 기능에 직접적으로 영향을 끼쳤다.

1) 컴퓨터 마우스

2) 2차원 화면 편집

3) 파일 트리뷰(File Tree View)

4) 하이퍼미디어 검색 및 퍼블리싱(publishing)

5) 다중 윈도우

6) 통합된 하이퍼미디어 방식의 인트라넷 이메일 시스템

7) 문서 버전 콘트롤

8) 원격 화상 회의

9) 포맷팅 지시어를 사용한 간단한 워드 프로세싱

10) 문맥 기반 도움말

이 것들이 전부가 아니다.  분산 클라이언트 서버 아키텍처, 일관성있는 명령어 문법, 유니버설 유저 인터페이스, 문법 주도형 명령어 해석기,  버추얼 터미널의 프로토콜, RPC(Remote Procedure Call) 프로토콜들, 게시판, 지식 관리 시스템.. 놀랍지 않은가? 이 모든 것이 NLS에 구현되었고 그 날 대중들에게 데모하면서 처음으로 외부에 공개되었다.  이 충격적인 데모는 http://sloan.stanford.edu/MouseSite/1968Demo.html 에서 동영상 파일로 감상할 수 있다. 이 데모속의 기술들은 개인용 컴퓨팅에 심취한 후대 과학자들에게 큰 영향을 주었고 결국 현재의 개인용 컴퓨터에 모두 구현되었다

우리(We)  : 인간을 위한 컴퓨터

바야흐로 유비쿼터스 시대를 살며 컴퓨터가 주는 혜택을 누리고 있는 우리는 과연 인간다운 삶을 살고 있는가? 주변의 수많은 컴퓨팅 환경으로 인해 인간다움은 잃어버리고 마치 기계톱니바퀴처럼 생각 없이 돌기만 하고 있는 것은 아닌가? 앞서 설명했던 수많은 선인들이 컴퓨터를 발전시킨 목적은 오로지 인간 사회를 이롭게 하기 위해서였다. 빠른 속도로 달려가고 있는 현대 사회에서 필요한 것은 아이러니하게도 미래에 대한 조급함이 아닌 과거에 대한 반성과 다짐이다. 눈부시게 성장하는 컴퓨터를  찬미하고 추종하는 것이 아니라, 인간의 행복을 추구하기 위해 컴퓨터를 사용하는 것이다. 내년이 빨리 오기 전에 올해의 시작을 잡고 서둘러 던진 질문에 답을 해야겠다. 누가 컴퓨터의 심장을 만들었는가? 바로 우리다. 후대에 누군가 역사 속에서 우리를 인간을 위해 컴퓨터를 고안하고 사용한 따뜻한 인간군상이라고 기록해주길 바란다. 이제 그만 컴퓨터를 끄고 사랑하는 가족과 함께 새해를 설계해야겠다.

[참고서적] : 본 원고는 누가 소프트웨어의 심장을 만들었는가? (박지훈 저 / 한빛미디어)에서 원작자의 허락을 받아 책의 내용을 상당 부분 도용하였음을 알려드립니다.

]]>

사용자의 참여를 통한 컨텐츠 생산의 폭발력은 이미 웹 2.0을 통해 확실히 입증되었다. 하지만 언어적 제한으로 인해 컨텐츠 생산자와 소비자는 한글을 사용할 줄 아는 국내의 사용자로 제한되어있고, 이는 컨텐츠 생산력을 비약적으로 증가시킬 수 없는 시장적 요인이기도 하다. 국내 시장의 파이가 작다면 공략해야 할 곳은 바로 세계이다. 만약 전 세계의 사용자들이 컨텐츠 생산자와 소비자가 될 수 있다면 어떨까? 아마도 웹의 컨텐츠 생산력은 아마도 비약적으로 증가할 것이다.
웹 2.0은 기존의 비즈니스와 다를 것이 없다. 국내 기업들이 적은 인구수라는 제한된 시장적 상황을 극복하기 위해 해외로 진출하듯이 웹 2.0 역시 세계화를 시도하여 또 다른 레벨의 컨텐츠 생산력을 얻을 수 있다. 만약 세계의 모든 사람들이 자유롭게 인터넷에서 커뮤니케이션할 수 있는 기반이 마련된다면 웹 2.0이 가지고 있는 비즈니스 모델은 더욱 힘을 얻게 된다. 그것이 바로 일상에서 작은 부분을 차지하고 있는 “번역”이라는 행위가 텍스트 기반의 웹에서는 곧 “세계와의 의사소통”이라는 큰 의미로 다가오는 이유이다. 지금부터 번역의 시장적 가치와 웹에 미치는 영향을 간단히 살펴보자.

기계 번역(Machine Translation)

기계 번역은 인간이 사용하는 언어를 컴퓨터를 사용하여 다른 언어로 번역하는 일을 말한다. Machine Translation의 줄임말로 MT라고 부르기도 한다. 기계 번역은 기본적으로 특정 언어를 다른 언어로 바꾸는 일을 단어 단위로 수행한다. 그러므로 다양한 뜻을 지니는 단어나 어순을 정확히 지키지 않는 문장 등 여러 가지 언어적 특성으로 인해 그 효력을 유연성 있게 발휘하기가 힘들다. 하지만 번역에 필요한 인공지능은 시간이 지남에 따라 지속적으로 발전하고 있으며, 그로인해 기계 번역의 성능도 점점 더 높아지고 있다. 게다가 웹의 보급으로 인해 기계 번역의 경직성도 보완되고 있다. 예를 들어 웹에서 특정 문장의 틀린 번역 결과를 보고 사용자가 바로 잡아주거나 방대한 언어 데이터를 수집해 번역 결과를 반영하는 등 사용자의 참여를 통해 번역의 질을 높이려는 구체적인 노력이 시행되고 있다. 다음은 기계 번역을 수행하는 대표적인 인터넷 번역기들이다.

♦  바벨 피쉬(Babel Fish : http://babelfish.yahoo.com) : 바벨 피쉬는 알타비스타(Altavista)에서 개발한 웹 기반 번역 어플리케이션이다. 바벨 피쉬는 웹에 번역기 서비스를 대중화시킨 장본인으로 현재는 알타비스타가 야후에 인수됨에 따라 야후에 귀속되어있다. 시스트랜(SYSTRAN)이라는 유명한 전문 번역 소프트웨어의 지원을 받고 있다. 

♦  윈도우 라이브 번역기(http://translator.live.com) : 윈도우 라이브는 서비스의 일부분으로 번역기를 제공하고 있다. 이 번역기 역시 시스트랜의 번역 기술을 통해 서비스되고 있다. 

♦  구글 번역(http://translate.google.com) : 구글은 번역의 질을 높이기 위해서 계속 사용해오던 시스트랜의 번역 기술을 자사가 개발한 통계 기반 번역 기술로 교체했다. 이 통계 기반 번역 기술은 방대한 언어 데이터와 구글의 거대한 계산 능력을 바탕으로 한다.

위의 번역기들은 모두 한국어->영어, 영어-> 한국어를 지원한다. 물론 기계 번역의 질은 여전히 완성도가 낮다. 하지만 그럼에도 불구하고 포털들은 자사의 번역 기술을 서비스 곳곳에 심고 있다. 물론 자신들이 가진 데이터를 다양한 국적의 사람들에게 보여주고, 또한 다양한 언어의 번역 결과를 통계학적 데이터로 활용하기 위함이다. 사용자의 참여를 통해 번역의 질은 점점 높아질 것이다.  포털들은 기계 번역 기술을 다음과 같이 활용하고 있다.

 <그림1> 마이크로소프트의 번역기 위젯

마이크로소프트는 자사의 번역기를 블로그나 기타 웹 페이지에 붙일 수 있는 위젯을 배포하고 있다. 위에 나온 스크립트 태그 한 줄만 사이트에 추가하면 그 자리에 아래와 같은 번역 버튼이 생기고 그 버튼을 누르면 해당 페이지의 번역 결과를 확인할 수 있다. 좀 더 자세한 정보가 궁금하다면 http://translator.live.com을 방문하기 바란다.

 <그림2> 구글의 검색 결과 번역하기 베타

구글은 검색 결과 페이지에 “이 페이지 번역하기 BETA"라는 링크를 함께 보여주고 있다. 이 링크를 누르면 해당 페이지가 번역된 팝업이 뜬다. 이와 같이 중요한 검색 결과 공간에 미완성의 번역 기능을 추가한 것만 봐도 자신이 가진 데이터를 세계의 모든 사람에게 보여주고자 하는 구글의 의지를 엿볼 수 있다.
기계 번역의 역사는 오래되었지만 오랜 침묵을 깨는 극적인 변화와 혁명은 아직 일어나지 않았다. 그러나 포털과 검색 사이트는 자신이 가진 데이터를 좀 더 널리 알리기 위한 장치 중 하나로 번역을 선택하려는 움직임을 보이고 있다. 웹을 통한 사용자 참여형 기계 번역은 느리지만 강하게 진화하고 있다.

번역 지원(Computer Assisted Translation) 소프트웨어

일반 사람들은 번역 소프트웨어하면 기계가 전문을 자동으로 번역하는 툴을 떠올릴지도 모르겠다. 하지만 세상에는 말도 안되는 번역 결과를 자동으로 만들어주는 소프트웨어만 있는 것은 아니다. 소프트웨어를 이용한 번역은 크게 두 종류로 나눌 수 있다. MT(Machine Translation)라고 불리는 기계 번역과 CAT(Computer Assisted Translation)이라 불리는 컴퓨터를 이용한 번역 지원이다. 앞서 설명했듯이 기계 번역만으로는 사용자가 100%신뢰할 만한 결과물을 얻을 수 없다. 하지만 사람이 번역할 때 기계 번역의 도움을 받는 다면 좀 더 빠른 속도의 작업이 가능할 것이다. 그리고 기계를 사용한 번역 결과물도 사람이 수시로 모니터링하며 수정할 수 있기 때문에 번역의 질도 높아질 것이다. 이처럼 번역 지원 소프트웨어는 기계의 도움을 받아 사람이 번역하는 번역 소프트웨어를 말한다.
번역 지원 소프트웨어는 사람이 하는 번역을 실시간으로 돕기 위해 TM(Translation Memory)라고 불리는 번역 메모리를 사용한다. 번역 메모리란 원문과 번역문이 한 쌍인 텍스트 단위로 구성된 데이터베이스이다. 텍스트 단위는 블록이 될 수 있으며, 구나 절 또는 문장 등 사용자가 지정한 단위가 될 수도 있다. 번역을 자주 하는 사람이라면 번역 작업 중에 이전에 번역한 문서의 문장을 찾아보거나 현재 작업 중인 문서에서 자주 반복되는 문장을 번역하기 위해 기억을 되살리려 노력한 적이 많은 것이다. 이처럼 예전의 번역 결과물을 세부 단위로 저장하여 필요할 때 다시 꺼내어 재활용하는 것이 번역 메모리의 컨셉이다. 번역 메모리를 활용한 번역은 다음과 같은 장점을 가지고 있다. 

♦  공용 정의나, 구절, 단어를 번역 메모리에 저장하여 재활용하기 때문에 변역물의 내용이 일관성이 있다. 이런 특징은 기억력에 의존해 혼자 번역을 할 때도 도움이 되지만, 한 프로젝트에 여러 명의 번역자가 관여할 때 많은 도움이 된다. 

♦  이미 한번 번역한 구절을 번역 메모리에 저장하기 때문에 반복적 어구가 많은 문서에서 번역 속도가 더욱 빨라진다. 

♦  번역 메모리를 활용해 워드나 PDF, HTML 등 다양한 포맷의 문서로 번역 작업을 수행할 수 있다. 

♦  다양한 용어 사전을 활용해 특정 전문 분야에 대한 용어 해석을 유연히 처리할 수 있다. 

♦  번역된 문서를 이미 다수 가지고 있을 경우 이 문서로부터 문장을 추출해 번역 메모리에 입력할 수 있다. 즉 다른 사람의 경험도 번역에 반영할 수 있다. 

♦  이미 입력된 번역 메모리를 수정하거나 삭제하여 전체적인 번역의 질을 일괄적으로 높일 수 있다.

이와 같은 번역 메모리의 장점은 반복 어휘나 전문 용어가 많은 기술 문서 번역을 통해 충분히 느낄 수 있다. 특히 매뉴얼이나 소프트웨어의 로컬라이제이션(Localization)에도 큰 힘을 발휘할 것이다. 예를 들어 버전 1.0인 소프트웨어의 매뉴얼의 번역 작업을 번역 메모리에 입력했다고 가정해보자. 버전이 2.0인 소프트웨어의 매뉴얼을 번역 지원 소프트웨어로 번역할 때 훨씬 빠른 작업이 가능할 것이다. 중복되는 단어나 어휘들이 상당부분을 차지하기 때문이다. 또한 거대한 양의 번역 프로젝트를 공동 작업할 때 하나의 번역 메모리를 공유하면 정확하고 빠른 협업이 가능할 것이다. 이처럼 기계를 이용한 번역의 완성도를 높여주는 번역 지원 소프트웨어 시장은 이미 산업에 크게 형성되어 있고, 매년 성장을 하는 추세이다. 전 세계에서 가장 많이 사용되고 있는 번역 지원 소프트웨어인 트라도스(Trados)와 같은 경우는 국내의 번역 전문 회사에서 대부분 사용하고 있고, 프리랜서에게 외주를 줄때도 이 툴을 사용해줄 것을 요구한다고 한다. 하지만 이와 같은 고가의 상용 소프트웨어 외에도 누구나 사용할 수 있는 프리웨어들이 존재한다. 상용에 비해 기능이 풍부하진 않겠지만 소프트웨어를 활용한 번역에 관심을 가진 독자들은 한번 시도해 보길 바란다.

♦ 오픈 소스 소프트웨어 
- OmegaT : 언어 제한이 없는 자바 기반의 번역 지원 소프트웨어로 MS 오피스 2007 포맷과 오픈 오피스(Open Office) 포맷을 바로 지원한다. (주소 : http://www.omegat.org)

 <그림3> OmegaT의 실행화면

- Open Language Tools : OmegaT와 같이 언어 제한이 없는 자바 기반의 번역 지원 소프트웨어이다.
(주소 : https://open-language-tools.dev.java.net) 
- Transolution : Python기반의 번역 지원 소프트웨어이다.
(주소 : http://sourceforge.net/project/showfiles.php?group_id=132322)

♦ 프리웨어 
- AidTrans Studio Basic : 윈도우 기반의 번역 지원 소프트웨어이다. 기능에 제한을 둔 무료 버전을 배포하고 있다.
(주소: http://www.aidtranssoft.com) 
- Appletrans : 맥 기반의 번역 지원 소프트웨어이다. 한글 단어집도 제공하고 있다.
(주소 : http://developer.apple.com/internationalization/localization/tools.html) 
- MemoQ 4Free : 윈도우 기반의 번역 지원 소프트웨어이다. 무료 버전을 배포하고 있지만 아직 한국->영어 번역은 지원하지 않는다.
(주소 :http://www.kilgray.com/kilgray/products/memoq/try?locale=en) 
- MetaTexis for Word Lite : 마이크로소프트의 워드를 기반으로 하는 번역 지원 소프트웨어이다.
(주소 : http://www.metatexis.com)

검색 엔진을 활용한 통계 번역

구글의 수석 부사장인 앨런 유스태스(Alan Eustace)는 대전 한국정보통신대학교(ICU)에서 열린 “정보통신기술(ICT) 교육을 위한 세계 대학 총장포럼(IFUP-ICT 2006)”에서 “세계 정보의 체계화(Organizing the world’s information)”라는 주제로 기조연설에 나섰다. 유스태스 부사장은 “전 세계 정보를 누구나 사용할 수 있게 만든다”라는 구글의 목표를 구체적으로 실현하기 위한 방법으로 번역 기술의 중요성을 재차 강조하였다. 구글은 현재 전문 연구 기관들과 함께 번역 서비스 구현에 매진하고 있으며, “웹 데이터 통계 비법”을 통한 문서 번역 기술을 개발하고 있다고 한다. 그는 아랍어-영어 번역의 경우 48.5%정도의 번역 정확도에 불과했지만 구글이 인덱싱한 웹 페이지 정보가 늘어남에 따라 정확도가 53%까지 증가했다고 주장했다. 시간이 흐름에 따라 웹 페이지 정보는 늘어나고 그에 따라 번역 품질이 높아지는 결과를 낳게 되는 것이다.
이러한 주장은 필자에게 매우 흥미롭게 다가왔다. 필자는 예전에 원서를 번역하여 책을 내는 역자로 활동한 경험이 있고, 한글을 영작하는 일도 잠시 한 적이 있다. 그때마다 가장 큰 도움을 준 것은 사전이 아닌 검색 엔진이었다. 원서를 번역하다 보면 사전에 나와 있지 않은 속어나 속담, 전문 용어, 신조어 등 다양한 영어 관용구와 마주치게 된다. 그때마다 필자는 영문 관용구를 따옴표로 감싼 채 구글에 검색어로 입력하여 한글 페이지 검색을 실행하였다.(따옴표로 감싼 문장은 문장을 구성한 단어가 아닌 정확히 그 문장을 포함한 웹 페이지만 찾게 만든다.) 그리고 검색 결과에서 영문 관용구와 함께 한글 해석이 담긴 웹 페이지를 찾을 수 있었다. 검색 대상을 한글 페이지로 제한하였기 때문에 가능한 일이다. 또한 영작 시에는 동사나 전치사를 어떻게 구사해야 하는지 많은 고민을 하게 된다. 영어는 비슷한 뜻을 가진 여러 단어가 존재하지만 경우에 따라서 사용해야 하는 단어가 관습적으로 구분되어 있기 때문에 영어권 문화를 모른 채 영작을 하다가는 봉변을 당할 수가 있다. 이런 경우에 비슷한 단어로 구성한 여러 후보 문장들을 역시 따옴표로 감싼 채 구글에 검색어로 입력해보자. 그 중 가장 높은 숫자의 검색 결과를 가진 문장을 선택하면 옳은 영작을 한 것이다. 왜냐하면 사람들이 가장 많이 사용하는 문장이 문법적으로 옳은 문장일 확률이 가장 높기 때문이다.

<그림4> 구글을 이용한 영작의 한 예

위의 예는 구글을 이용한 영작이 어떻게 가능한지 보여준다. “the number of”는 “~의 수”를 뜻하는 숙어로서 다음에 복수명사가 와야 한다. 모두들 많이 알고 있기는 사실이기는 하지만 항상 기억하기 어려운 문법이라 매 순간 확신을 가지고 사용하기가 어렵다. 그럴 땐 검색 엔진을 이용해 가장 많은 결과를 보여준 문법이 더 옳은 문법이라는 이론을 활용해보자. 위의 결과에서는 “the number of employees is”가 더 많은 검색 결과를 얻었으므로 맞는 문법이다.

<그림5> 구글을 이용한 번역의 한 예

스크럼은 프로젝트 관리를 위한 애자일 소프트웨어 개발 방법론이다. 스크럼은 1986년 하바드 비지니스 리뷰(Harvard Business Review)에서 타케우치(Takeuchi)와 노나카(Nonaka)의 "신제품 개발 게임(The New New Product Development Game"이라는 주제의 글로 처음 거론되었다. 그들은 작은 규모의 협업팀(Cross-Functional Team)들로 구성된 프로젝트를 수행하여 기록적인 성과를 올린 경험을 기록하여 많은 관심을 불러 일으켰다.

협업팀(CFT : Cross-Functional Team)    협업팀은 공통의 목적을 위해 서로 다른 직군의 전문가가 모여 이룬 팀을 말한다. 팀에는 재정이나 마케팅, 인사 등 다양한 직종에서부터 조직의 모든 직급이 포함될 수 있다. 또한 컨설턴트나 클라이언트와 같은 외부 관계자도 팀에 참여할 수 있다. 협업팀은 특정한 목적으로 구성되기 보다는 자발적인 의사 결정을 통해 비전과 목적을 공유한다. 예를 들어 협업팀은 음악 밴드와 같다. 밴드에서 연주자들은 서로 다른 악기를 연주하지만 음악을 통해 한 목소리를 낸다. 그 음악은 연주자들의 협동과 합의를 통해 완성된 것이다. 이처럼 협업팀과 음악 밴드는 서로 다른 분야의 전문가가 만나 협동 작업과 합의를 통해 완성도 높은 결과물을 배출한다는 점에서 많은 공통점을 가지고 있다.

그들은 그때의 팀 구성이 마치 럭비의 스크럼과 같다고 했다. 스크럼은 럭비 게임 중 사소한 반칙이 생겼을 때 공정하게 플레이를 재개하기 위해 공을 가운데 두고 각 팀의 선수들이 짜는 대형을 말한다. 이와 같은 룰은 애자일 방법론을 쉽게 잘 설명하고 있다. 애자일의 대표적인 특징 중 하나는 반복 개발이다. 즉 프로세스를 계속 반복하여 문제를 발견하고 다시 수정하는 작업을 되풀이 하면서 목표를 향해 전진하는 것이다. 스크럼도 반칙(문제)을 심판이 발견하고 팀 간의 부딪힘 속에 목표 지점을 항해 전진한다는 점에서 기막힌 비유가 아닐 수 없다.

스크럼의 아버지, 애자일

일단 스크럼은 애자일 개발 방법론의 한 분류라는 태생을 가지고 있기 때문에 애자일에 대한 이해가 먼저 선행되어야 한다. 애자일 방법론은 정해진 룰이 아니라 지향하고자 하는 가치에 가깝기 때문에 그 정의에 대해 다양한 해석이 나올 수 있다. 하지만 애자일 방법론을 주창하고 실천해온 전문가(XP의 Kent Beck과 같은)들이 모여 함께 작성한 “애자일 소프트웨어 개발 선언문(Manifesto for Agile Software Development / http://agilemanifesto.org )”을 보면 좀 더 가시적인 목표를 확인할 수 있다. 그 선언문을 정리하자면 다음과 같다.

위의 선언문은 기존의 가치도 중요하지만 그것에 집착하다가는 더 중요한 가치를 잊을 수 있다는 내용의 주장을 하고 있다. 프로세스와 도구는 개인들 간의 커뮤니케이션을 원활하게 하기 위해 사용되어야 한다. 많은 문서를 만들기 위해 시간을 소비해 소프트웨어의 완성도를 떨어트리고 있지는 않은가. 계약이 성사된 후에도 고객의 소리에 귀를 기울이는가. 프로젝트를 진행하다 보면 예상치 못한 문제나 변화가 생길 수 있다. 그때 마다 가치 있는 변화에 적절히 대응하지 않은 채 정해진 계획을 수행하는 것에만 집착할 것인가? 프로젝트의 성패는 안중에도 없이 말이다. 이와 같이 프로젝트 내내 좀 더 중요한 가치에 대해 함께 질문하고 답변하는 자세가 바로 애자일 방법론이다. 스크럼은 이와 같은 자세를 구체적인 프로세스를 통해 현실화하고 있다.

스크럼의 특징

스크럼은 반복적이고 점진적인 프로세스를 통해 제품을 개발하고 작업을 관리한다. 그리고 프로세스가 반복되는 마지막 시점마다 진행 작업을 정리하는 과정을 수행한다. 스크럼은 다음과 같은 특징을 가지고 있다.

♦  스크럼은 스프린트(Sprint)라고 불리는 30일간의 기간을 기반으로 진행된다.

♦  제품 책임자(Product Owner)는 제품 개발 계획의 변경 사항과 개발 가능한 기능들의 우선순위를 수집하여 정리한다.

♦  이와 같은 제품 책임자의 작업은 제품 백로그(Product Backlog)라고 불린다. 제품 백로그는 지속적으로 우선순위를 변경되는 작업 리스트이다.

♦  스프린트가 반복되어 실행될 때마다 제품 백로그에서 가장 높은 우선순위의 기능을 스프린트 백로그(Sprint Backlog)로 이동시킨다.

♦  스크럼 팀(Scrum Team)은 가능한 5명에서 9명 사이의 인원으로 구성한다. 스크럼 팀은 제품 책임자와의 회의를 통해 스프린트의 목표를 정하고, 우선순위가 정해진 기능을 좀 더 실행 가능한 작은 업무단위로 쪼갠다. 팀의 구성은 자체적으로 조직하며, 구성원들은 결과에 대한 공동의 책임을 지닌다.

♦  스크럼 팀은 스프린트 기간동안 스프린트 백로그에 정리된 작업 리스트를 수행한다.

♦  매일 열리는 일일 스크럼(Daily Scrum)에서 현재의 진행사항을 파악하고 처리한다.

♦  스크럼 마스터(Scrum Master)는 개발 팀을 지도하고, 프로세스를 수행하는데 방해되는 장애물을 제거한다. 그리고 팀이 스프린트를 계획한대로 잘 실행할 수 있도록 최선의 환경에 놓여져 있는지 지속적으로 확인한다.

♦  팀은 매 스프린트 마다 제품의 시장 가치를 증가시키고 새로운 기능과 개선 사항을 반영하는 작업을 한다.  

스크럼 구성원의 역할

스크럼에는 다양한 역할이 정의되어있으며, 그 역할들은 돼지와 닭이라는 두 그룹으로 나뉘어 진다. 돼지와 닭에 대한 비유는 다음과 같은 오래된 우화로부터 비롯된 것이다.  

돼지와 닭이 함께 길을 걷는 중이다. 닭이 돼지를 보며 말했다.  닭 : 우리 식당 같이 해보지 않을래?   돼지 : 좋은 생각이야. 그런데 그 식당 이름은 뭐라고 하지?  닭 : "햄과 달걀“이라고 부르는 것이 어떨까!"   돼지 : 글쎄.. 좋은 생각이 아닌 것 같아. 난 희생해야 하는데 넌 단지 관여만 하려고 하잖아!

 햄은 돼지가 자기 살을 내어 희생해야지 만들 수 있지만, 달걀은 닭이 단지 낳기만 하면 된다는 상황에서 비롯된 비유이다. 이처럼 돼지에 속한 그룹은 스크럼 속에서 제품을 개발하는데 모든 역량을 쏟는다. 그에 반해 닭에 속한 그룹은 프로젝트와 연관된 사람이지만 돼지처럼 스크럼 안에 투입되어 헌신적으로 일하지는 않는다. 그러므로 닭의 요구와 아이디어는 업무에 참조할 수 있지만, 스크럼 프로젝트의 전반적인 계획에 영향을 미쳐 돼지를 힘들게 해서는 안된다.

돼지

돼지는 스크럼 프로세스와 프로젝트에 투입되어 실질적인 업무를 수행하는 그룹이다.

1. 스크럼 팀(Scrum Team)

문제를 정의하고 해결하는 실질적인 업무를 수행하는 팀이다. 대략 5~9명으로 구성되며 이 인원은 스크럼과 같은 형태의 업무를 수행하기에 최적화된 숫자이다. 팀 구성원들은 업무를 정의하고 분배하는 작업을 스스로 진행한다. 프로젝트 내의 정해진 역할은 존재하지 않는다. 즉 모든 사람이 다른 사람과 수행 업무를 교환할 수 있다.  

2. 제품 책임자(Product Owner)

고객의 의견을 대변하고, 스크럼 팀이 비즈니스 관점에서 올바르게 업무를 수행할 수 있도록 도와준다. 제품 책임자는 제품 백로그를 관리한다. 제품 백로그는 제품에 담고자 하는 기능의 우선순위를 정리한 작업 리스트이다. 그와 관련된 문서는 조직 전체에 공개하여 모든 사람이 제품의 완성 과정을 알 수 있도록 한다. 제품 책임자의 역할은 주로 고객이 맡지만, 내부 조직 사람이 될 수도 있다. 이 임무를 맡은 사람은 엔지니어링과 마케팅, 비즈니스 프로세스 등 제품에 대한 전반적인 지식을 갖추고 있어야 한다.

3. 스크럼 마스터(Scrum Master)

스크럼 마스터는 지도자이자 중재자의 역할을 수행한다. 스크럼 마스터는 매일 열리는 일일 스크럼(Daily Scrum) 회의에 항상 참여하여 스크럼 팀을 관리한다. 그리고 프로젝트의 외부에서 팀과 논의해야할 중요한 이슈를 가지고 있는 경우, 그 사안들이 구성원들의 작업에 여파를 미치지 않도록 최대한 노력을 한다. 이처럼 스크럼 마스터는 팀이 현재 주어진 과제에 충실할 수 있도록 도움을 준다. 팀이 스프린트 기간동안 정해진 목표를 성취할 수 있도록 최선의 환경을 제공하는데 항상 초점이 맞추어야 한다. 스크럼 마스터는 스프린트의 실행이 종료될 때마다 스크럼 팀과 함께 그동안의 작업과 결과물을 평가하는 회의를 연다. 그리고 회의를 통해 팀의 프로젝트 이해도를 높이고, 작업에 대한 동기를 유발시켜 다음 스프린트에 대비한다.

닭

닭은 스크럼 프로세스에 직접적으로 투입되지는 않지만 간접적으로 의견을 제시하는 그룹이다. 애자일 방법론의 핵심은 프로젝트와 관련된 사용자와 비즈니스 그리고 그 밖의 이해관계자들과의 커뮤니케이션을 프로세스의 중요한 일부분으로 인정한다는 것이다. 그들과 함께 일하고, 그 피드백을 스프린트를 계획하고 검토하는 시점마다 프로젝트에 반영하는 것은 매우 중요하다.

1. 사용자

제품은 누군가를 위해 만들어지는 것이다. 사용되지 않을 제품을 왜 만들고 있는가? 그들의 의견은 말할 것도 없이 매우 중요하다.

2. 이해관계자

그들은 프로젝트를 만드는데 기여를 하지만, 프로세스에 직접적으로 관여하지는 않는다. 이해관계자는 CEO를 포함한다.

3. 컨설팅 전문가

스프린트마다 항상 필요한 것은 아니지만 필요한 시기에 전문적인 지식과 의견을 제시한다. 특정 시점의 스프린트에서는 닭에서 돼지로 변신해 스크럼 팀에 포함되기도 한다.

스크럼을 진행하는 동안 닭은 비즈니스에 관여하되 헌신하는 돼지를 방해하지 않는다. 돼지는 동업 관계인 닭을 이해하고 그들의 의견을 수렴한다. 싫건 좋건 돼지와 닭은 한 배를 탔다. 이와 같은 역할 모델은 스프린트 기간 동안 정해진 시간에 목표를 수행할 수 있도록 도와준다.

스크럼 프로세스

스크럼은 다음과 같은 핵심 단위 프로세스를 반복적으로 실행하여 제품의 완성도를 높인다.

백로그(Backlog) 만들기

제품 책임자는 제품의 스펙과 고객의 요구를 수집하여 정리한다. 프로젝트의 최종 목표가 정의된 후, 그 목표를 구체적인 단위로 세분화 시켜 비즈니스 가치를 반영하고 수행할 수 있는 기능 리스트로 변경한다. 그리고 기능들의 중요도를 평가하여 우선순위를 정한다. 우선순위 리스트는 시장적 가치와 고객의 요구를 바탕으로 정렬한다. 제품 책임자는 새로운 스프린트를 시작할 시기가 되면 백로그를 가지고 스크럼 팀과 회의를 열고, 스크럼 팀은 백로그를 작업 리스트 삼아 업무를 수행한다.

스프린트(Sprint)

스프린트는 스크럼의 핵심적인 개념으로 제품 백로그를 완수하기 위해 주기적으로 반복되는 2~4주의 기간이다. 스프린트를 시작하기 전에는 스프린트 계획 회의를 열어 제품 백로그 리스트에서 스프린트동안 수행할 작업을 선택한다. 그리고 그 작업이 선정되면 스프린트 백로그로 옮겨 정리한다. 스프린트 기간동안 성취해야할 목표도 정의한다. 이처럼 스프린트에 필요한 시간과 수행할 업무들이 모두 정의되면 스프린트를 시작한다. 스프린트가 일단 시작되면 스프린트 백로그는 가능한 수정하지 않으며 스크럼 팀은 스프린트를 완수할 책임을 지닌다. 만약 팀이 올바르게 구성되어있다면, 정의된 업무는 팀의 주도하에 구성원에게 알맞게 배분될 것이다. 스프린트가 종료되는 시점에는 스프린트 검토 회의를 열어 스프린트가 목표를 올바르게 달성했는지 평가한다.  

일일 스크럼(Daily Scrum)

스프린트 동안 스크럼 마스터와 스크럼 팀은 매일 15분간 간략한 회의를 연다. 회의의 목적은 업무를 수행하는데 방해가 되는 장애요인들을 제거하는 것 이다. 회의 참여자들은 다음의 세 가지 질문에 적절한 답변을 해야 한다.

♦  지난 회의 이후에 지금까지 무엇을 했는가?

♦  지금부터 다음 회의까지 무엇을 할 것인가?

♦  업무를 수행하는데 있어서 방해가 되는 것들은 무엇인가?

처음 두 질문에 대한 답변은 프로젝트가 얼마나 진행되고 있는지 판단하는데 중요한 정보를 제공한다. 세번째 질문은 컴퓨터 마우스 고장에서부터 회사의 조직 개편까지 다양한 문제를 해결하는 실마리를 제공한다.

 위의 그림처럼 스크럼은 스프린트라는 한 달 가량의 기간을 반복하며 핵심 프로세스를 실행한다. 그리고 반복적인 작업을 통해 제품의 완성도를 높인다. 굳이 애자일 방법론이라는 다소 거창한 이름을 들먹거리지 않더라도 이는 충분히 설득력 있는 프로세스이다. 이미 우리는 고객들과 스크럼을 짜며 제품의 완성도를 높였던 경험을 가지고 있기 때문이다. 소프트웨어를 무리하게 출시하여 한달(스프린트)에 한번씩 패치를 릴리즈하지 않는가? 잠재적으로 많은 버그들이 숨어있는 웹 사이트를 공개하여 한달(스프린트)에 한번 정도는 예외 없이 엄청난 오류를 발견하고 서둘러 고치지는 않는가? 물론 이와 같은 과정을 통해 제품은 완성도를 더해갈 것이고 문제는 점점 줄어들 것이다. 하지만 더불어 고객들도 줄어들 것이다. 이와 같은 시행착오를 줄이는 것이 바로 스크럼이다. 고객들은 돼지와 닭이 아니다.

스크럼이  과연 해답인가?

 애자일  방법론에는 여러 가지 개발 방법이 존재한다. 이 방법론들은 비슷해 보이지만 서로 다른 특징을 가지고 있다.

♦  린 소프트웨어 개발(Lean Software Development) : 린 소프트웨어 개발은 개발 조직 전반에 걸친 법칙과 실천 과정을 다룬다.

♦  스크럼(Scrum) : 스크럼은 프로젝트가 어떻게 조직되어야 하고 계획되어야 하는지 다룬다.

♦  XP(eXtreme Programming) : XP는 프로그래밍을 이용해 어떻게 작업해야 하는지를 다룬다.

XP와 달리 스크럼은 단지 소프트웨어 개발에만 사용할 수 있는 방법론이 아니다. 지금까지의 내용을 숙지했다면 스크럼이 다양한 형태의 프로젝트에 적용할 수 있는 방법임을 눈치 챘을 것이다. 어찌 보면 스크럼은 서로 머리를 맞대고 아이디어를 도출해내는 브레인스토밍(Brain Storming)과 비슷하다. 브레인스토밍과 같은 지식 생산 행위를 세부적으로 스케줄링하여 목표에 맞는 구체적인 결과물이 나오도록 만든 것이 스크럼인 듯하다. 스크럼 팀은 매일 또는 매달 만나며 제품을 완성하는데 필요한 지식을 생각해내고 정리한다. 그리고 정리하는 작업을 함께 진행하는 도중에 또 다시 필요한 지식을 생각해내고 정리한다. 이와 같은 과정을 수행하면 프로젝트를 진행하는데 걸림돌이 되는 장애물은 미처 나타나기도 전에 제거될 것이고, 제품의 완성도는 눈치 채지 못하는 사이에 점점 더 높아질 것이다. 이런 프로세스에서는 과정의 중요함보다는 참여하는 사람의 자세와 팀의 가치관이 매우 중요한 역할을 한다. 좀 더 구체적인 사례를 들어보자. 정해진 업무 시간에만 일을 하고 정시에 퇴근하는 것은 스크럼에 긍정적인 영향을 준다. 누가 야근을 하며 매일 스크럼 회의를 열고 제품에 새로 추가할 기능에 대해 진취적으로 의견을 개진하겠는가? 그와 반면 야근을 고집하는 업무 분위기는 어떨까. 팀원들 모두 기능에 대한 개선점을 알고 있으면서도 언급하지 않은 채 정해진 스케줄만 묵묵히 수행할 것이다. 그리고 결말은? 제품 출시 후 수많은 불특정 고객들과의 힘겨운 스크럼이다.

스크럼을 수행한 효과는 다양한 체험과 보고를 통해 전해지고 있으며 그 중에서도 야후는 베스트 사례로 꼽힐 만하다. 야후는 근 30개월 동안 약 90개의 프로젝트에 스크럼을 도입했다. 야후 포토와 같이 디자인이 많이 들어간 웹 사이트서부터 야후 메일과 같이 사용량이 중요한 백 엔드(Back-end) 서비스까지 다양한 프로젝트에 스크럼을 도입해 유지보수를 진행했다. 그리고 새로 런칭하는 신규 사이트에도 스크럼을 적용해 안정된 서비스를 사용자에게 제공하였다. 이와 같은 야후의 성과는 조사를 통해 수치화 되었고, 스크럼 참여자 중 약 68%가 기존의 방법보다 더 또는 훨씬 더 좋다고 대답한 것으로 밝혀졌다. 그리고 스크럼에 참여한 제품 책임자들은 평균 36% 정도 생산성이 증가했다고 평가했다. 과연 스크럼만 도입해서 야후가 이런 성공을 거둔 것일까. 그들의 업무 문화가 스크럼의 효과를 배가시켰다고 보는 것이 옳을 것이다. 누구나 스크럼을 도입해서 30% 정도의 생산성 향상을 이루어 낼 수는 없는 것이다. 어떤 조직은 스크럼을 사용해 실패를 맛볼 것이고, 다른 조직은 경이적인 효과를 거둘 수도 있을 것이다. 조직의 문화란 하루 아침에 바뀔 수 없기 때문에 스크럼의 무조건적인 도입은 해악이 될 수 밖에 없다. 그럼에도 불구하고 스크럼에 대해 눈을 뗄 수 없는 이유가 있다. 그것은 바로 수많은 까탈스러운 고객들과의 뒤늦은 스크럼보다 친애하는 팀원들과 함께 하는 스크럼이 더욱 재밌고 흥미진진해보이기 때문이다.

이 같은 현실을 직시한 대표 브라우저 기업인 애플(Apple), 오페라(Opera), 모질라(Mozilla)가 2004년부터 WHATWG(Web Hypertext Application Technology Working Group)라는 웹 기술 개발 그룹에서 의기투합하여 새로운 HTML에 대한 논의와 개발을 지속적으로 펼치고 있다.

 결국 이런 현실적이고 구체적인 노력은 많은 진전을 이루었고, 최근 W3C가 WHATWG의 차세대 HTML에 대한 결과물을 채택하고 유지 발전하기로 결정하였다. HTML 5로 불리는 HTML의 새 버전은 기존 HTML에 없던 새로운 엘리멘트와 속성들이 추가되었다. 세부사항을 살펴보면 기존의 <div>, <span>과 같이 레이아웃의 단락을 명시하는 종류의 태그도 있지만, 무엇보다 <nav>와 <footer>처럼 HTML안에 특정한 의미(Semantic)를 담는 태그가 다수 추가되었음에 주목할 필요가 있다. 이 같은 태그들은 검색 엔진을 통해 좀 더 다양한 용도로 활용될 수 있고, 모바일 디바이스나 시각장애인을 위한 음성 인식 브라우저 구현에 중요한 역할을 해 큰 잠재력을 지닌다. 멀티미디어 시대를 맞이하여 <audio>나 <video>와 같은 멀티미디어 관련 태그들이 새롭게 추가되었고, <center>나 <font>와 같이 CSS에서 핸들링할 수 있는 태그들은 배제되었다. <frameset>과 같이 대중들에게 사용되지 않는 태그들도 HTML 5에서 사라졌다.

이처럼 기존의 HTML에 비해 많은 차이점을 담고 있는 HTML 5. 과연 웹 기술에 어떤 변화를 가져올 지 지금부터 개괄적으로 살펴보자.

HTML 5에 달라진 변화들

HTML 5에는 다양한 용도의 태그들이 추가되었다.

1. 섹션(Section)

섹션 관련 엘리먼트(Element)는 페이지의 구역을 위치나 의미로 구분하는 태그이다. <body>나 <head>가 흔히 우리가 알고 있는 섹션 엘리먼트로 HTML 5에 추가된 섹션 관련 엘리먼트의 세부 내용은 다음과 같다.

<body> <h1>Apples</h1> <p>Apples are fruit.</p> <section>   <h2>Taste</h2>   <p>They taste lovely.</p>   <section>    <h3>Sweet</h3>    <p>Red apples are sweeter than green ones.</p>   </section> </section> <section>   <h2>Color</h2>   <p>Apples come in various colors.</p> </section> </body>

♦ <section> : 문서의 단락을 구분할 때 사용한다. <section>은 다양하게 사용될 수 있다. 책의 장(chapter) 안에 단락을 구분할 때 사용할 수 있고, 탭으로 구분된 콘텐츠나 숫자로 구분된 단락에 사용할 수 있다. 사이트에서 소개나 공지사항, 연락처와 같은 단락을 구분할 때도 쓸 수 있다. <h1>~<h6>은 <section>안에서 내용의 제목을 대변한다.

♦ <header> : 페이지 안에 명시적인 헤더를 표시할 때 사용한다. <header>는 <head>와 다르다는 점과 적어도 하나의 <h1>~<h6>를 포함해야 한다는 점에 주의하자.

♦ <footer> : 페이지 하단에 푸터를 표시할 때 사용한다. 보통 사이트에 대한 간략 정보가 들어가는 것이 일반적이다.

♦ <nav> : 다른 페이지로 이동하는 링크들의 집합을 담는다. 우리가 흔히 보는 페이지 하단의 ‘이전’, ‘다음’ 버튼이나 페이지 번호 리스트를 표시하는 부분으로 생각하면 된다.

♦ <article> : 신문이나 블로그, 게시판, 잡지 등 개별적인 저자의 글 단위이다.

2. 블록(Block)

블록 관련 엘리먼트들은 섹션 안에서 좀 더 작은 단위로 글의 단락을 구분하고 개행하는 역할을 한다. <p>나 <br>이 흔히 알고 있는 블록 단위의 엘리먼트들이다. 다음은 HTML 5에 새로 추가되는 블록 관련 엘리먼트이다. 

♦ <dialog> : <dialog>는 사람들 사이의 대화 내용을 표시할 때 사용한다. <dialog> 태그 안에서 <dt>는 청자, <dd>는 청자가 말한 내용을 정의한다.

<dialog> <dt> Costello <dd> Look, you gotta first baseman? <dt> Abbott <dd> Certainly. <dt> Costello <dd> Who's playing first? <dt> Abbott <dd> That's right. <dt> Costello <dd> When you pay off the first baseman every month, who gets the money? <dt> Abbott <dd> Every dollar of it. </dialog>

♦ <aside> : <aside>는 페이지 내의 중심 콘텐츠와는 약간 동떨어진 성격의 내용을 가지고 있는 단락을 구분할 때 사용된다. 팁이나 메모, 사이드 바 등이 좋은 예다.

 3. 구(Phrase)

구 단위 엘리먼트들은 섹션이나 블록 단위 엘리먼트와 달리 작게는 텍스트의 단어나 문장에 의미를 부여하는 태그들을 포함한다. 다음은 HTML 5에 추가된 엘리먼트들이다.

♦ <m> : <m>는 mark를 의미하는 태그로 특정 문장이나 단어를 강조하기 위해 사용한다. 예로 웹 사이트에서 검색어를 입력했을 때 출력되는 결과 페이지 안에 입력한 검색어와 매칭되는 단어를 표시할 때 사용할 수 있다.

<p>Our first date was <time datetime="2006-09-23">a saturday</time>.</p> <p>Many people get up at <time>08:00</time>.</p>

♦ <time> : 페이지 안에서 날짜를 표시하기 위해 사용한다. 물론 기존 HTML도 페이지에 날짜를 표시할 수 있지만, 컴퓨터는 페이지 안의 숫자가 시간인지 온도인지 키인지 확인할 방법이 없다. <time> 태그로 검색 엔진이나 브라우저는 페이지 안의 시간 데이터를 정확히 처리할 수 있게 된다.

<meter>75%</meter> <meter>750‰</meter> <meter>3/4</meter> <meter>6 blocks used (out of 8 total)</meter> <meter>max: 100; current: 75</meter> <meter><object data="graph75.png">0.75</object></meter> <meter min="0" max="100" value="75"></meter>

♦ <meter> : min, max, value, low, high, optimum과 같은 속성과 함께 숫자로 측정할 수 있는 범위를 나타내는데 주로 사용한다. 학생들의 시험 점수나 온도 등 최대치나 최저치와 함께 현재치 등을 표시하는 숫자 패턴을 웹에서 표현하는데 용이하다.

♦ <progress> : 진행 상태를 나타내는데 사용한다. 예를 들어 다운로드나 특정 작업 중일 때 현재 작업이 얼마나 진행되었는지 표시할 때 사용할 수 있다. 자바스크립트를 사용하여 진행도를 런타임으로 업데이트한다면 그 활용도가 더 높아질 것이다.

4. 외부 콘텐츠(Embeded   Content)

외부 콘텐츠 관련 엘리먼트는 현재 HTML이 아닌 다른 콘텐츠를 포함할 때 사용한다. <img>나 <embed>, <object>가 대표적인 외부 콘텐츠 관련 태그들이다. 다음은 HTML 5에 추가된 엘리먼트다.

♦ <figure> : <figure>는 외부 콘텐츠와 함께 외부 콘텐츠의 제목이나 설명을 함께 포함하기 위한 태그이다. 외부 콘텐츠에 대한 제목이나 설명은 <figure>안에 <legend> 태그를 사용하여 표시할 수 있다. 예를 들어 그림과 함께 다음의 설명을 함께 넣고 싶다면 <figure>가 좋은 선택이 될 것이다.

<figure> <img src="1100670787_6a7c664aef.jpg"> <legend>Bubbles traveled everywhere with us.</legend> </figure>

♦ <video> : 현재 HTML에서 동영상 파일을 첨부하고 싶다면 <object>나 <embed> 태그를 사용해야 한다. 이 태그들은 모든 외부 객체를 포함할 때 사용하는 것으로 포함된 파일이 동영상인지 음성인지 분간할 방법이 없다. 하지만 <video>태그를 사용함으로써 현재 웹에서 기하급수적으로 늘어나고 있는 동영상 파일들을 적절히 인식하여 다양한 활용을 가능하게 한다.

<video src="http://www.cafeaulait.org/birds/sora.mov" autoplay="true"/>

♦ <audio> : <video> 태그와 마찬가지로 HTML에 포함된 음성 파일을 정확히 명시함에 따라 웹에서 기하급수적으로 늘어나고 있는 음성 파일에 대한 다양한 활용이 가능하다.

♦ <canvas> : 그래프 또는 게임 그래픽을 그리거나 다른 이미지들을 움직이게 만드는 등 비트맵 그래픽을 동적으로 표현하는데 사용한다.

5. 상호작용(Interactivity)

상호작용 관련 엘리먼트들은 기존의 HTML에 없는 새로운 엘리먼트들이다. 앞서 설명한 HTML 5의 엘리먼트들이 레이아웃 표현에만 충실했던 기존 HTML에 구조화된 의미(semantic)를 부여하는데 초점을 맞췄다면, 상호작용 관련 엘리먼트들은 HTML의 유저 인터페이스로서의 역할을 개선시키기 위한 기능을 수행한다.

♦ <details> : 특정 단어나 문장에 대해 자세한 설명을 담는데 사용한다. 각주나 툴 팁과 같은 유저 인터페이스에 사용할 수 있다. 기본적으로는 페이지에서 숨겨지며 어떤 액션을 가했을 때 내용이 나타나는 식의 인터페이스 구현에 알맞다. open 속성을 이용해 내용의 기본 노출 여부를 설정할 수 있다.

♦ <datagrid> : HTML에서 그리드 컨트롤의 역할을 하는 태그이다. <table>이 변하지 않는 정적인 데이터를 담는데 사용한다면 <datagrid>는 사용자나 스크립트를 통해 다양한 구조의 셀을 수정하고 정렬하는 등 데이터를 다양하게 처리하는데 사용한다. HTMLDataGridElement는 그리드를 다이나믹하게 조작할 수 있도록 만들어주는 스크립트 인터페이스이고, DataGridDataProvider는 그리드에 데이터를 동적으로 설정하는 스크립트 인터페이스이다. <datagrid>는 Ajax와 결합하여 웹의 애플리케이션화를 가속화시킬 것이다.

<datagrid>   <table>     <tr><td>Jones</td><td>Allison</td><td>A-</td><td>B+</td><td>A</td></tr>     <tr><td>Smith</td><td>Johnny</td><td>A</td><td>C+</td><td>A</td></tr>     <tr><td>Willis</td><td>Sydney</td><td>C-</td><td>D</td><td>F</td></tr>     <tr><td>Wilson</td><td>Frank</td><td>B-</td><td>B+</td><td>A</td></tr>   </table> </datagrid>

♦ <command> : 사용자의 지시를 수행하는 컨트롤을 표현하는 태그이다. 독립적으로는 마우스 클릭으로 개별적으로 실행될 수 있으며, 함께 모이면 마치 메뉴 속 명령들과 같이 실행될 수 있다.

<menu type="popup" label="Edit">     <command onclick="undo()"   label="Undo"/>     <command onclick="redo()"   label="Redo"/>     <command onclick="cut()"    label="Cut"/>     <command onclick="copy()"   label="Copy"/>     <command onclick="paste()"  label="Paste"/>     <command onclick="delete()" label="Clear"/> </menu>

♦ <menu> : <menu>는 명령어들의 집합을 메뉴 컨트롤로 표현한다. <menu>안에서 <a>나 <option>, <command>, <input> 등과 같이 마우스 클릭을 통해 특정 기능의 호출이 가능한 엘리먼트를 집합시켜 HTML 안에서 메뉴 컨트롤을 구현할 수 있다.

 이 같은 태그 외에도 다양한 속성들이 새로 추가되었다. 일례로 <input> 태그의 속성에 date, url, email 등과 같은 세부적인 옵션이 추가되었다. 이로서 HTML 5에서는 날짜를 입력할 때 자바스크립트 달력을 일일이 구현하지 않아도 되고, 이메일 주소 입력시 ‘@’를 체크할 필요도 없다. 간단한 속성의 추가지만 이로 인해 불필요한 자바스크립트 사용을 줄일 수 있고, 페이지의 크기도 줄어들어 사용자는 보다 쾌적한 환경에서 웹을 이용할 수 있을 것이다.

지금까지 HTML 5에 추가되는 태그를 간단한 설명과 함께 살펴보았다. 여기서 그치는 것이 아니라 기존 HTML 스펙에서 사용하기 불편하고 접근하기 힘들었던 <frame> 태그나  CSS에서 사용하는 것이 더 합리적인 <font> 태그 등 여러 가지 태그와 속성들의 지원도 중단된다. 이처럼 HTML 5는 기존의 불필요한 엘리먼트는 과감히 없애고 뒤쳐지는 기능은 대폭 개선하는 등 알찬 버전 업을 진행 중이다. HTML 5는 현재 작업이 진행 중인 초안(Working Draft)이기 때문에 스펙 정의에 대한 논의가 활발하게 진행되고 있다. 그래서 앞에서 이야기한 내용에서 큰 틀은 벗어나지 않겠지만 공개적인 논의 중 도출된 개선 사항은 얼마든지 반영될 수 있음을 염두에 두자. 물론 읽는 이가 느끼는 HTML의 개선사항이 있다면 워킹 그룹에 참가하여 HTML 5의 발전에 보탬이 될 수도 있을 것이다. 좀 더 자세한 내용은 http://www.whatwg.org를 방문하여 살펴보기 바란다.

 
웹에 HTML의 씨앗을  뿌려라

그동안 차세대 웹을 표방하는 웹2.0을 구현하기 위해 다양한 웹 기술들이 거론되어 왔다. 하지만 이 기술들은 다음 세대를 위한 새로운 기술들이 아니라 기존 기술을 사용하는 방법론에 가까웠다. 예컨대 기존 기술을 개방과 공유라는 웹의 특징에 알맞게 사용하기 시작한 것 외에 별다른 기술적 혁신은 없다는 얘기다. 좋다. 이제라도 웹의 특징에 맞게 웹 기술을 이용하기 시작했다면 그것 또한 축하할 일이다. 하지만 태생적으로 웹은 방법이 아니라 기술이다. 웹은 이 시대가 낳은 최첨단 기술의 집합체라는 태생을 지니는 만큼 기술의 진보가 없이는 그 어떤 비약적인 발전도 기대할 수 없다.

이제 웹2.0이라는 웹을 제대로 발전시킬 수 있는 방법을 알았으니 기술의 진보로 웹을 또 다른 레벨의 단계로 올려놓을 때가 되었다. HTML 5는 기존 HTML이 지니는 여러 가지 기술적 한계를 극복하고 있다. HTML 안에서 더욱 다양한 사용자 인터페이스를 구현해 접근성과 RIA를 절충하였다. 이로서 모바일을 포함한 좀 더 다양한 브라우저에서 HTML을 왜곡 없이 이용할 수 있게 된다. 그리고 더 많은 의미(Semantic)를 태그로 정의해 검색 엔진이나 음성 인식기 등과 같은 컴퓨터에서 HTML의 이해도를 높일 수 있다. 이 모두가 웹2.0이 원하는 시대적 요구였지만 기존 HTML이 해결하지 못해 써드파티의 기술을 사용했던 부분들이다.

HTML 5가 모든 면에서 장밋빛 미래를 가지는 것은 아니다. WHATWG에 마이크로소프트가 제외된 점이 무엇보다 아쉽다. 마이크로소프트의 인터넷 익스플로러는 현재 가장 많은 사용자층을 거느린 브라우저이기 때문이다. 물론 WHATWG의 작업초안이 국제표준기구인 W3C로 넘어갔으니 마이크로소프트는 HTML 5를 지지할 수밖에 없을 것이다. 또한 HTML 5가 최종적으로 발표되더라도 웹 전반에 채택되어 영향력을 떨치려면 시간이 필요하다. 그러므로 HTML 5이 어떻게 변화하는지 지속적으로 살피고, 주변 기업들의 지원 동향에 대해 관심을 기울여야 한다. HTML 5가 웹을 어떻게 변화시키지는 제대로 파악하려면 말이다.

HTML 5의 <dialog> 태그를 통해 특정 정치인의 발언을 검색하여 관심 사안에 대해 거짓말을 했는지 여부를 파악할 수 있는 검색 엔진이 있다면 좀 더 나은 정치인을 뽑을 수 있을 테고 민주주의는 보다 성숙되어질 것이다. 그리고 올바른 정치인을 뽑아 좀 더 나은 나라를 만드는데 일조를 할 수 있겠다. 태그 하나가 나라를 바꾼다. 너무 비약이 심하다고 생각하는가? 그렇지 않다. 웹이라는 토양에는 하찮은 씨앗이라도 이처럼 풍성한 결실을 거둘 수 있다. 사용자라는 수십억의 영양분이 있기 때문이다. HTML 5는 향후 수 십 년간 우리를 먹여 살릴 모내기라고 생각해도 좋다. 지금까지 우리는 사용자가 가득 담긴 웹2.0이라는 기름진 토양을 만들었고 이제 그 위에 HTML 5라는 씨앗을 뿌려야할 때가 다가오고 있다. 언제가 될지 모르지만 멀지 않은 시일에 풍성한 곡식을 얻게 될 것이고, 그 곡식은 다양한 반찬 즉 서비스로 변모되어 우리 생활에 크나큰 영향을 미칠 것이다. 그것이 바로 우리가 HTML 5가 채 완성되지도 않았음에도 불구하고 관심을 기울여야 하는 이유이다.  

물론 이런 미래가 현실화되려면 적잖은 장애물을 해결해야 한다. <그림 1>에서 알 수 있듯이 시맨틱 웹을 제대로 실행하기 위해서는 RDF(Resource Description Framework)와 OWL(Web Ontology Language) 등 많은 기반 기술이 필요하다. 심지어 컴퓨터의 자동화 처리를 위한 인공지능 알고리즘까지 요구될 수도 있다. 이처럼 무거운 구조로 인해 시맨틱 웹의 현실화는 아직도 구체화되지 않고 있다. 실효성에 대한 논의도 뜨겁다. 상황이 이렇다보니 시맨틱 웹처럼 강력하지는 않지만 손쉽게 사람도 이해하고 컴퓨터도 이해할 수 있는 마이크로포맷이 컴퓨터 중심의 시맨틱 웹과 사람 중심의 웹을 아우르는 시발점으로 인식되고 있다.

마이크로포맷

브라우저에 표현할 레이아웃을 정의하는 용도로 사용하는 HTML과 달리 마이크로포맷은 간단한 방법으로 웹 페이지 내의 특정한 목적의 의미를 부여할 수 있어 다양한 용도로 HTML을 활용할 수 있다. 예를 들어 웹 페이지 안에 마이크로포맷을 적용함으로써 주소록을 공개하고 인맥 관계를 찾아가거나 일정을 공유하는 등 다양한 응용이 가능하다. 검색 엔진 등의 자동화 프로그램은 마이크로포맷이 삽입된 웹 페이지에서 특수한 목적의 데이터를 수집하여 HTML 이상의 가치 있는 정보를 사용자에게 전달할 수도 있다.

HTML은 페이지의 레이아웃을 정의하는 태그 외에도 다른 목적의 정보를 담을 수 있는 방법을 제공한다. 다음과 같은 HTML 표준 속성을 이용해 웹 페이지 내에 마이크로포맷을 삽입할 수 있다.

● class : 마이크로포맷의 가변적인 정보를 정의하는 기본 속성

● rel : 링크와 연결되어 있는 문서와의 관계를 정의하는 속성

● rev : 링크와 연결되어 있는 문서와의 역관계를 정의하는 속성

마이크로포맷은 이러한 기본적인 속성을 이용해 주소록이나 이벤트, 리뷰 등과 같이 특수한 목적의 정보를 HTML 안에 삽입할 수 있다. 다음은 class 속성을 이용해 연락처 정보를 표현하는 마이크로포맷인 hCard의 예이다.

<span class=“vcard”>
      <span class=“fn”>홍길동</span>
      <span class=“org”>유명 주식회사</span>
      <span class=“tel”>02-111-1111</span>
      <a class=“url” href=“http://microformats.org”>http:// microformats.org </a>
  </span>

여기서 일반적인 HTML 태그와 class 속성을 함께 사용해 fn, org, tel, url과 같은 특수 정보를 저장하고 있다. fn은 이름, org는 소속회사, tel은 연락처, url은 홈페이지 주소를 의미하며, 이는 vcard라는 class 속성 안에서 연락처 정보를 형성하고 있다. hCard는 컴퓨터가 이해할 수 있도록 정해진 규약으로 정보를 저장하는 반면 사용자 역시 웹 페이지에서 정보를 시각적으로 확인할 수 있는 장점이 있다.

class 속성이 다양한 속성 값을 부여해 hCard와 같이 풍부한 포맷을 HTML 안에 저장한다면, rel과 rev 속성은 <link>나 <a href> 태그에 관계 정보를 부여해 좀 더 간단한 방법으로 마이크로포맷을 구현한다. XFN(XHTML Friends Network)은 링크에 rel 속성을 이용해 인맥을 저장한다.

<a href=“http://www.jerryis.com/tt” rel=“friend met colleague”>제리</a>

<a href=“http://www.pixie.co.kr” rel=“friend met”>픽시</a>

rel 속성의 friend는 “친구”를 뜻하며, met은 “만난 적이 있는 관계”, colleague는 “같은 직종의 동료”를 의미한다. 그러므로 픽시라는 링크는 “만났던 친구”의 홈페이지를 뜻하며, 제리는 “만났던 같은 직종의 친구”를 의미한다. 이처럼 XFN을 통해 간단하게 홈페이지나 블로그간의 인맥관계를 저장할 수 있다. 자세한 스펙은 http://gmpg.org/xfn/을 살펴보기 바란다.

Vote Links는 rev 속성을 사용하여 링크를 웹 페이지의 정보에 대한 지지나 추천에 대한 의사 표현으로 처리하는 마이크로포맷이다.

<a href=“http://happybean.naver.com” rev=“vote-for”>해피빈</a>

<a href=“http://microformat.com” rev=“vote-abstain”>마이크로포맷</a>

<a href=“http://...” rev=“vote-against”>악질사이트</a>

rev 속성의 vote-for는 “찬성”, vote-abstain은 “중립”, vote-against는 “반대”를 뜻한다. 똑같은 관계임에도 불구하고 rel이 아닌 rev를 사용하는 이유는 rel은 현재 페이지를 기준으로 관계를 표현하는 속성이고 rev는 그 반대의 관계를 표현하는 속성이기 때문이다. 그러므로 다른 페이지의 정보에 대해 찬성이나 반대를 표현하는 행위는 rev 속성을 사용해야 한다. Vote Links는 링크에 대한 사용자들의 평가를 저장하여 링크 정보의 질을 높이는 효과를 발휘한다.

geo는 위도와 경도와 같은 지리적인 수치를 HTML 안에 저장하여 위치를 표시하는 마이크로포맷이다. 이 마이크로포맷을 이용하면 구글 맵과 같은 웹 지도에 정확히 위치를 표시할 수 있다.

<div class=“geo”>GEO: 
 <span class=“latitude”>37.386013</span>, 
 <span class=“longitude”>-122.082932</span>
</div>

이렇게 마이크로 포맷은 HTML 페이지 안에 특수한 목적의 정보를 삽입하여 HTML의 활용성을 높이는 개방형 데이터 구조 표준이라 용도에 따라 쉽고 다양한 형태로 고안될 수 있다. 다음은 특수한 목적의 마이크로포맷들이다.

● hCalendar : 일정 정보를 저장한다.

● hCard : 주소록 정보를 저장한다.

● hReview : 영화나 음악 등에 관한 리뷰 정보를 저장한다.

● hResume : 이력서 정보를 저장한다.

● geo : 위도와 경도를 저장한다.

● XOXO : 리스트와 요약 정보를 저장한다.

● rel-directory : 링크가 디렉토리 정보임을 명시한다.

● rel-nofollow : 검색 엔진과 같은 에이전트에 분석될 필요가 없는 링크임을 명시한다. 링크를 포함한 악성 댓글과 같은 전문적인 스팸 방지할 때 사용할 수 있다.

● rel-tag : 링크가 태그 정보임을 명시한다.

● xFolk : 쇼셜 북마킹을 위한 정보를 저장한다.

● XFN : 링크에 인맥을 저장하여 웹 페이지에 인간관계를 설정할 수 있다.

● XOXO : 리스트와 요약 정보를 저장한다.

물론 이외에도 많은 마이크로포맷이 있다. 현재에도 지속적으로 추가되고 있는 중이다. 생산자를 hCard, 위치를 geo로 저장하고 맛, 색깔, 생산년도 등을 표시하는 와인(Wine) 관련 마이크로포맷까지 논의될 정도로 활발하다.

마이크로포맷, 과연 어디에 사용할까?

마이크로포맷은 웹에서 다양한 형태로 서비스될 수 있다. 국내에서는 마이크로포맷을 적극적으로 사용하는 사이트가 없기에 해외에서 적절한 예를 찾을 수 있다.

1. 마이크로포맷 수집 사이트

일반적으로 사용자는 특정 사이트를 직접 방문하여 데이터를 입력한다. 그리고 사용자가 입력한 정보는 사이트 방문객에 의해 웹 전반에 걸쳐 퍼진다. 즉 사용자는 자신의 정보를 퍼트리기 위해 선호하는 사이트를 방문하여 데이터를 남긴다. 하지만 마이크로포맷과 블로깅이 합쳐지면 다른 패턴으로 웹을 활용할 수 있다. 다른 사이트를 방문할 필요 없이, 내 블로그에 정보를 남기면 다른 사이트가 블로그에 접근하여 그 정보를 가져간다.

예를 들어 무언가를 팔고 싶다면, 상품정보를 저장하는 마이크로포맷인 hListing을 이용하여 블로그에 그 내용을 남긴다. edgeio(http: //www.edgeio.com)와 같은 상품정보 수집 사이트는 그 블로그의 상품 정보를 수집하여 적절한 카테고리에 전시한다. 이와 비슷한 케이스로 hReview 태그를 통해 블로그에 작성된 영화평은 영화정보 사이트에서 수집해 갈 것이고, 인맥관계를 지정하는 XFN 태그는 인맥정보 사이트에서 수집할 것이다. 이처럼 기업은 곳곳에 퍼진 다양한 마이크로포맷을 수집해 또 다른 비즈니스 사이트가 생성할 수 있고, 개인은 자신의 블로그에 글만 하나 남겼음에도 불구하고 다른 사이트에 그 내용이 자동으로 배포하는 효과를 누릴 수 있다. 마치 블로그를 다양한 목적의 RSS처럼 활용할 수 있는 것이다.

2. 특정한 커뮤니티에서 정보를 공유하기

산악자전거 동호회는 다른 사람들과 즐길 수 있는 하이킹 코스를 공유하고 싶을 것이다. 하이킹 코스에 관련된 지리 정보를 블로그에 포스팅하고 그 정보를 지오캐스팅(geocasting) 해보자. geocast란 podcast와 유사한 개념으로 RSS에 지리정보를 포함한 geo 포맷을 포함시킨 형태의 웹 피드이다. 동호회의 다른 사람들은 이 피드를 구글 어스와 같은 지도 프로그램에 등록하여 하이킹 코스를 공유하고 확인할 수 있다.

3. 전문 검색

만약 누군가 웹 툰을 그려서 많은 사람들에게 공개하고 싶다고 하자. 웹 툰 정보를 명시하는 마이크로포맷을 따라 만화를 포스팅한다면 많은 사용자가 검색을 통해 웹 툰을 읽게 될 것이다. 그림이나 동영상은 내용의 텍스트화가 되지 않아 검색의 어려움이 있다. 하지만 만화 속의 대사를 마이크로포맷과 함께 제공한다면 대사 안의 키워드와 매칭되는 만화를 검색할 수 있게 된다. 검색 엔진은 이벤트 정보를 담은 hCalendar를 수집하여 구글 맵과 같은 지도 정보에 지역별 이벤트를 비주얼하게 표시할 수도 있다. 마치 요즘 각광받고 있는 전문 검색 엔진(Vertical Search En gine)처럼 말이다.

4. 인터넷 브라우저를 통해 개인 용도로 활용

마이크로포맷이 삽입된 웹 페이지는 다양한 애플리케이션에 의해 사용될 수 있다. hCard는 연락처를 다루는 국제 표준인 vCard를 HTML 안에 표현한 포맷으로, vCard는 이미 대부분의 주소록 소프트웨어에서 기반 데이터로 활용되고 있다. 그렇다면 HTML에 존재하는 hCard 마이크로포맷을 수집한 후 vCard로 변환하여 주소록 소프트웨어에 자동 추가하는 편리한 기능이 가능하게 된다.

파이어폭스의 확장 기능인 테일즈 익스포트(Tails Export)는 브라우저로 접근한 HTML 페이지 안의 마이크로포맷을 아웃룩 같은 PIMS(Personal Information Management System)가 사용할 수 있는 포맷으로 자동 변환해 주는 기능을 가지고 있다. 특정일의 이벤트 정보를 담은 웹 페이지를 클릭하여 한 번에 일정관리 프로그램에 추가할 수 있게 되는 셈이다.

<그림 3>은 태일즈 익스포트의 실행 화면으로 오른쪽에는 웹 페이지, 왼쪽에는 웹 페이지에 담긴 전자 명함과 일정 정보를 자동으로 보여준다. 사용자는 왼쪽의 마이크로포맷 정보를 몇 번의 클릭만으로 아웃룩에 쉽게 옮길 수 있다. 또 다른 파이어폭스의 확장 기능인 오퍼레이터(Operator)는 좀 더 많은 마이크로포맷을 분석할 수 있다. 오퍼레이터를 설치한 후 Yahoo! Local (http ://local.yahoo.com), Upcoming.org, Flickr(http://www. flickr.com)을 돌아다니다보면 주소록과 지도, 스케줄 등이 상단 툴바에 자동으로 나타나는 것을 확인할 수 있다.

이처럼 수많은 가능성은 마이크로소프트와 같은 유명한 IT 기업들이 앞으로의 프로젝트에 마이크로포맷을 활용하기로 결정하게 만들었다. 현재로선 브라우저의 플러그인으로 마이크로포맷을 활용될 뿐이나 앞으로 출시될 마이크로소프트의 인터넷 익스플로러 8.0이나 모질라의 파이어폭스 3는 마이크로포맷을 기본으로 지원할 예정이라고 한다. 브라우저를 통한 간단한 활용이 가능하게 된다면 마이크로포맷의 영향력은 더욱 더 커질 것이다. HTML의 쉬운 활용이 웹의 부흥을 일으켰듯이.

컴퓨터? 결국은 사람이다

시맨틱 웹은 폭발적으로 늘어나는 데이터를 좀 더 가치 있는 정보로 활용하기 위한 미래지향적인 목표이다. 기술이 아닌 목표다. 컴퓨터를 이해시킬 수 있는 정보를 생산해 내는 기술이 중심이 아니라 웹에 존재하는 데이터를 좀 더 가치 있게 만들어 일상생활을 윤택하게 하여야 한다. 하지만 시맨틱 웹은 온톨로지나 RDF와 같이 다소 난해하고 복잡한 개발 기술로 인해 실질적으로 삶의 질을 향상시키는데 아무런 결과물을 내놓지 못하고 실정이다.

반면 마이크로포맷은 사람이 자주 접하는 웹 페이지에 컴퓨터가 “읽을 수” 있는 정보를 저장하여 활용도를 높인다. 물론 컴퓨터가 “이해할 수” 있는 데이터베이스를 목표로 삼는 시맨틱 웹에 비하면 그 비전은 초라할 지도 모른다. 하지만 마이크로포맷은 사용자의 자발적인 참여를 유도한다는 점에서 더 큰 힘을 가진다. 사용자를 스스로 움직이게 하는 것은 그리 어려운 일이 아니다. 즉 그들이 자신에게 이익이 된다는 사실을 깨닫게 된다면 동기를 가지고 자발적으로 참여할 수 있다. 예를 들어 마이크로포맷은 hCard나 hCalendar와 같이 개인정보관리 소프트웨어에서 활용하던 정보를 웹 페이지에서도 공유할 수 있다는 점에서 사용자의 참여를 유도한다. 이렇게 쌓인 마이크로포맷은 다양한 목적의 메타데이터로 형성되어 대중을 만족시키는 새로운 유형의 서비스를 탄생시킬 것이다. 여기서 끝이 아니다. 컴퓨터가 읽을 수 있는 데이터가 사용자에 의해 점점 더 많이 쌓일수록 자연스레 시맨틱 웹이 형성된다. 컴퓨터가 일단 무언가를 읽을 수 있어야 이해할 수 있는지 테스트도 하고 새로운 시도를 할 수 있지 않겠는가?

컴퓨터 중심의 시맨틱 웹 기술이 좀 더 사용자에게 다가설 수 있는 겸손함을 보일지, 아니면 사용자 중심의 웹이 좀 더 발전하여 컴퓨터를 이해시킬 수 있는 웹의 비전을 보여줄 것인지에 촌각을 곤두세우는 것은 무의미하다. 이미 마이크로포맷을 통해 미약하지만 사용자와 컴퓨터가 함께 이해할 수 있는 시맨틱 웹 2.0이 시작되고 있다.

검색 엔진 최적화는 사이트의 검색 결과 순위를 높이는 방법을 말한다. 간단히 말하면 검색 엔진을 이용한 마케팅 방법 중 하나이다. 사이트의 방문자 수를 늘리기 위해서는 일단 검색 사이트에 보다 많이 노출되어야 한다. 검색 사이트는 인터넷에서 정보를 찾기 위한 중요한 수단이기 때문이다. 검색 사이트를 통해 들어온 방문자들은 일단 강한 동기를 가지고 해당 사이트를 방문했을 확률이 크다. 검색 사이트에서 직접 키워드를 입력하여 들어온 방문자는 단순히 호기심에 의해 다른 곳의 링크를 통해 들어온 방문자보다 어떤 명확한 목적을 달성하기 위해 사이트를 방문했을 것이다. 그 사람은 방문한 사이트의 열광적인 팬이 될 가능성이 크다.

검색 사이트의 결과에 가장 높은 위치로 노출시키는 가장 쉬운 방법은 검색 사이트에 돈을 지불하여 상위로 올리는 것이다. 하지만 예산이 넉넉하지 못한 사이트라면 검색 엔진의 특성에 맞는 사이트를 구성해야 한다. 물론 생각만큼 간단한 일을 아니다. 검색 결과를 만드는 알고리즘은 검색 엔진마다 각기 다르고, 핵심적인 기능은 경쟁력 약화를 우려해 기업마다 일급 비밀로 하고 있다. 하지만 검색 기업들의 다양한 조취에도 불구하고 검색 엔진이 분석해야 할 것은 HTML이라는 텍스트 기반의 저작 언어로 한정이 되어있다. 그러므로 우리는 검색 엔진이 HTML의 어떤 문법과 텍스트를 집중적으로 분석할지 상당 부분 예측 가능한 것이다.  

내 사이트와 검색 엔진을 친하게 만들자.

지금부터 설명할 검색 엔진 최적화 방법은 주로 구글과 같이 고성능의 검색 엔진을 이용한 검색 사이트에 큰 효과를 거둘 수 있다. 국내의 검색 사이트는 스폰서 링크나 키워드 구매 같이 비즈니스에 의해 검색 결과 위치가 좌우되거나 내부에서 사용하는 지식 데이터, 블로그, 뉴스를 먼저 보여주는 검색 모델을 가지고 있기 때문에 큰 효과를 거두지는 못할 것이다. 그러나 구글과 같은 웹 페이지 전문 검색 사이트는 국내에서도 많이 이용되고 있으며 국내 검색 사이트 역시 웹 페이지만을 검색하는 섹션을 따로 제공하고 있다. 검색 사이트의 비즈니스 모델로 인해 인위적으로 검색 결과가 달라지는 것에 거부감을 느끼는 사용자들은 여전히 검색 엔진을 이용한 웹 페이지 검색을 이용할 것이다. 그렇기 때문에 검색 엔진 최적화는 여전히 그 위력을 발휘할 수 있다. 다음은 사이트의 검색 순위를 높여 트래픽을 올리는데 많은 도움을 주는 항목들이다. 
 
1. 텍스트 위주의 컨텐츠를 구성해라

 앞서 말했다시피 검색 엔진은 텍스트를 분석하여 의미있는 데이터를 추출한다. 이미지나 플래쉬로 도배가 된 사이트는 검색 엔진으로 인한 방문자 증가 효과를 누릴 수 없다. 사용자는 크리스마스 선물을 검색하기 위해 “크리스마스 선물”을 검색 사이트에 입력하지만, 화려한 크리스마스 트리가 있는 플래시와 선물이 그려져 있는 이미지로 공들여 만든 페이지는 공교롭게도 검색 결과에 나오지 않을 것이다. 물론 모든 것을 텍스트로만 구성하라는 것은 아니다. 텍스트를 위주로 적절하게 이미지를 가미한 디자인은 보기에도 좋을뿐더러 브라우저에도 빠르게 로딩되는 등 이로운 점이 많다.

부득이하게 플래쉬와 이미지 같은 그래픽 요소가 많이 필요한 사이트는 검색 엔진이 분석할 수 있는 “ALT” 태그를 사용하여 이미지에 대한 텍스트 설명을 첨부하는 것이 좋다. 또한 사이트에 존재하는 모든 페이지의 하단에 중요 페이지들에 대한 텍스트 링크를 나열하는 것도 좋은 대안이다.

 2. 사이트의 타이틀을 명확히 해라

웹 페이지들은 자신이 담고 있는 내용을 타이틀(TITLE) 태그에 함축하여 표현해야 한다. 대부분의 검색 엔진은 검색 알고리즘의 매우 중요한 정보로 타이틀 태그를 활용한다. 사용자가 검색에 사용할 키워드를 미리 예측해서 타이틀에 넣는다면 검색 순위를 올리는데 큰 도움을 줄 것이다.

국내에서는 타이틀의 중요성이 그다지 부각되지 않은 것 같다. 사이트의 모든 타이틀이 똑같은 사이트는 곳곳에서 찾아볼 수 있으며 이는 검색 엔진 최적화 마케팅의 관점에서 굉장히 큰 실수이다. 한 예로 쇼핑몰을 들어보자. 국내 쇼핑몰에 등록된 상품 상세 페이지의 타이틀은 대부분 상품명을 표시하는 것이 아니라 쇼핑몰 이름만을 표시한다. 이는 상품의 상세 페이지를 검색 엔진에서 제대로 검색할 수 없게 한다. 해외의 쇼핑몰들은 대부분 상품명이 타이틀에 표시되어 검색 엔진에서 다양한 쇼핑몰의 상품을 바로 검색할 수 있다.

위의 그림은 국내 유명 쇼핑몰들의 상품 상세 페이지 타이틀이다. 그림을 보면 확인할 수 있듯이 대부분이 쇼핑몰의 이름과 홍보 문구를 적고 있을 뿐이다. 국내 유명 쇼핑몰들 중에선 그림 중 맨 아래의 옥션이 거의 유일하게 상품 정보를 타이틀에 표시하고 있다. 아래에는 해외 유명 쇼핑몰들의 타이틀이 있다.

이처럼 아마존이나 이베이, 노드스톰같이 해외의 유명한 쇼핑몰들은 대부분 상품 정보를 타이틀에 표시하여 검색 사이트에 상품을 노출시키고 있다. 이 상품들은 사용자가 구글과 같은 검색 사이트에 상품명을 입력해서 쉽게 찾을 수가 있다.

3. 의미 있는 이름을 부여해라.

주소의 도메인 명이나 디렉토리 명, 파일 명을 검색 엔진이 알아볼 수 있는 키워드로 구성하는 것이 좋다. 주소는 검색 엔진에 매우 큰 영향을 주는 정보이다. 가장 중요한 페이지는 root 디렉토리에 가깝게 두고, 디렉토리 이름은 검색 키워드를 염두에 두고 정해라. 검색 엔진은 키워드에 적합한 페이지를 찾는데 주소를 중요한 정보로 참고한다. 국내에서는 한글을 사용하기 때문에 이 방법을 활용하기 위해서 한글로 주소를 작성해야 한다는 한계가 있다. 한글로 작성된 디렉토리 명이나 파일 명은 브라우저의 UTF-8 옵션의 선택 여부에 따라 안보일 수 있기 때문에 영어로 작성하는 것이 일반적이다. 하지만 국내에서 사용하는 영어 고유명사는 충분히 검색에 활용할 수 있다. 예를 들어 BMW같은 고유명사 같은 경우, “http://www.bmw.co.kr/bmw.html” 처럼 주소에 BMW라는 키워드를 사용한다면 검색 엔진은 상위의 검색 결과로 위의 사이트를 올려놓을 것이다.

4. 링크

사이트에 대한 링크가 외부에 많이 존재하면 할수록 검색 결과 순위는 높아진다. 인터넷에 많이 존재하는 링크일수록 중요한 정보를 담을 가능성이 크기 때문이다. 물론 외부에 링크를 많이 퍼트리는 방법은 훌륭한 컨텐츠를 만드는 것이다. 컨텐츠가 매력을 가지고 있다면 별다른 노력 없이도 링크의 확산 속도는 기하 급수적으로 늘어나고 곧 검색 결과 상위권에 오르게 될 것이다. 그와 반면에 인위적인 방법을 사용해도 컨텐츠가 매력이 없다면 링크의 확산 속도는 늘지 않을 것이다. 하지만 경쟁력 있는 컨텐츠가 존재한다는 가정하에 좀 더 링크의 확산을 가속화시킬 수 있는 방법이 있다. 같은 관심사를 가진 사이트들끼리 웹 링(*주석)을 구성한다거나 링크를 컨텐츠안에 개재하여 다른 사이트로의 개시를 허용한다면 좀 더 많은 링크가 외부에 확산되어 검색 결과로 반영될 것이다.

5. 사이트 맵을 가져라

사이트 맵은 검색 결과 순위에 지대한 영향을 미친다. 왜냐하면 검색 엔진이 여러분의 사이트의 중요 메뉴를 모두 훑어볼 수 있게 만들기 때문이다. 사이트 맵은 일단 사이트에 대한 간략한 설명과 중요 페이지에 대한 텍스트 링크를 거는 것이 중요하다. 그렇다고 모든 페이지의 링크를 사이트 맵에 표시하는 것은 옳지 않다. 검색 엔진은 특정 개수 이상의 링크가 존재하면 기준 개수를 넘는 링크는 더 이상 분석하지 않기 때문이다. 일반적으로 한 페이지 내에 100개 이상은 넘지 않는 것이 좋을 것이다.

사이트 맵에 대한 링크는 페이지 맨 위에 두는 것이 좋다. 검색 엔진은 페이지의 위에서부터 아래로 분석하기 때문에 위에 위치한 단어나 링크에 좀 더 가중치를 부여하여 분석한다. 또한 사이트 맵에 연결된 링크나 그 안의 내용을 플래쉬나 이미지 맵, 자바스크립트로 구성해서는 안된다. 검색 엔진은 텍스트를 분석하는 알고리즘을 사용한다. 사이트 맵은 기본적인 태그로도 충분히 디자인 요소를 살려서 만들 수 있다. 검색 엔진에 사이트가 좀 더 알려지고 싶다면 사이트 맵 내의 링크를 자바 스크립트 함수나 플래쉬 메뉴가 아닌 텍스트 링크로 만드는 것이 좋을 것이다. 이 법칙은 일반적인 페이지도 마찬가지로 적용된다.

6. 에러 페이지를 활용해라

검색 사이트는 검색 엔진을 이용해 페이지를 분석한 결과와 주소를 별도의 데이터에 저장한다. 이를 전문 용어로 인덱싱이라고 한다. 실제로 사용자의 검색 키워드가 입력된 순간 웹 페이지가 아닌 인덱싱 데이터를 검색하게 된다. 그러므로 검색 엔진이 인덱싱한 후에 변경된 웹 사이트의 내용을 실시간으로 감지하지 못한다. 검색 결과 중 특정 링크를 누르면 브라우저에서 “페이지를 찾을 수 없습니다” 라는 에러 메시지가 나오는 경우가 바로 웹 사이트의 변경 사항을 실시간으로 감지하지 못하기 때문에 발생하는 경우이다.

 웹 사이트는 항상 변하게 되어있다. 링크가 변경될 수도 있고, 페이지 자체를 없앨 수도 있다. 이 경우에 검색 사이트를 통해 힘들게 들어온 고객을 그냥 쫓아버릴 수 있다. 하지만 잘못된 페이지 주소로 들어왔을 때 그에 상응하는 에러 페이지를 출력한다면 고객을 붙잡을 확률을 좀 더 높일 수 있다. 사이트의 전체 메뉴나 이벤트를 에러 페이지에 출력한다면 고객은 좀 더 사이트를 둘러보고 싶어할 수도 있다. 물론 유실된 페이지와 유사한 페이지로 이동시키는 에러 페이지를 구성한다면 더할 나위 없을 것이다.

7. 페이지 컨텐츠

페이지 안의 내용에 중요한 키워드를 보다 강조한다면 검색 엔진이 분석하기 쉬울 것이다. 헤더 태그(<H1>, <H2>, <H3>)를 이용해 강조된 텍스트는 분석에 있어 좀 더 가중치를 받을 수 있다. 또한 헤더 태그 외에도 본문에 특정 키워드에 대한 일관된 내용을 담는 것도 텍스트를 강조하는 효과를 발휘한다. 본문에 여러 가지 주제에 대한 내용을 모두 담고 있는 것보다는 한가지 주제에 대한 내용을 기승전결에 따라 담는다면 주제에 대한 중요 키워드가 자연스레 반복되어 출현하게 되므로 사용자와 검색 엔진 모두 강조하려는 부분을 쉽게 이해할 수 있다. 

8. 검색 엔진에 사이트 등록

물론 지금까지 말한 지침들은 검색 엔진이 사이트 자체를 찾을 수 없다면 아무 부질없는 내용일 뿐이다. 대부분의 검색 사이트는 사이트를 무료로 등록할 수 있도록 지원하고 있다. 사이트 주소와 웹 마스터 이메일과 같은 정보를 등록하면, 검색 엔진은 정해진 스케줄에 의해 직접 사이트를 분석할 수 있다.

 1번부터 4번까지는 대부분의 검색 엔진이 중요한 정보로 사용하는 항목임과 동시에 사이트 설계를 할 때 쉽게 반영할 수 있는 부분이다. 이 밖에도 검색 엔진 최적화를 위한 더 많은 항목이 있지만 간단하게 실행할 수 있는 방법 위주로 설명하였다.

내 사이트와 검색 엔진을 친하게 만들자.

검색 엔진의 분석에 긍정적인 영향을 주는 방법이 있는 반면, 부정적인 영향을 주는 기술적 요인도 있다. 검색 엔진의 원활한 분석 활동을 위해서 지켜야 할 일반적인 사항들은 다음과 같다.

1.과도한 그래픽 요소를 피해라.

과도한 플래쉬나 이미지는 검색 엔진이 사이트를 분석하는데 방해요소가 된다. 검색 엔진은 기본적으로 텍스트로 이루어진 링크나 내용을 최고의 정보로 활용한다. 플래쉬나 이미지 같은 바이너리 데이터는 검색 엔진이 쉽게 분석할 수 있는 대상이 아니다.

2. 프레임을 피해라.

페이지를 프레임으로 구성하지 마라. 프레임은 검색 엔진이 제대로 수집하고 분석하기에 매우 성가신 구조이다. 검색 엔진이 사이트 분석을 통해 전체 프레임이 아닌 일부 프레임에 대한 주소만 저장할 수 있기 때문이다. 검색 사이트를 통해 들어온 사용자는 레이아웃이 망가진 일부 프레임만을 보게 될 수 있다.

3. 쿠키를 피해라.

웹 사이트로 접근을 허락하기 위해 쿠키나 세션을 사용하지 마라. 검색 엔진의 접근을 막기 때문이다.

4. 자바스크립트 사용을 아껴라.

자바스크립트로 이루어진 메뉴는 굉장히 많이 사용되는 웹 인터페이스 요소 중 하나이지만 검색 엔진의 링크 분석을 방해하는 요인을 가지고 있다. 링크를 www.?.co.kr과 같은 텍스트 주소로 걸지 않고 자바스크립트 함수로 걸면 검색 엔진이 함수를 분석해가며 주소를 찾아야 하기 때문이다. 검색 엔진에서 잘 수집되는 사이트는 대개 텍스트 링크 위주로 구성되어있다.  

물론 검색 엔진을 위해서 위와 같은 항목을 모두 지켜야 하는 것은 아니다. 적절한 그래픽 요소나 자바스크립트 사용은 사이트를 풍요롭게 하는 중요한 요소이다. 하지만 페이지가 가지고 있는 중요한 링크나 컨텐츠는 텍스트로 구성하고 그 외의 것들은 그래픽 요소를 고려하는 디자인 방법은 보편적인 관점에서 훌륭한 페이지 설계 방법이다.

검색 엔진과 전략적 제휴를 맺어라.

검색 엔진 최적화(SEO)는 간단한 실천으로 큰 효과를 볼 수 있는 훌륭한 마케팅 비법으로 보이지만, 어두운 면도 가지고 있다. 미국에서는 이미 검색 엔진 최적화를 비즈니스의 한 시장으로 보고 있으며, 검색 엔진 최적화를 전문으로 수행하는 기업들이 많이 있을 정도이다. 문제는 이 기업들이 검색 엔진 최적화를 사이트가 담고 있는 컨텐츠를 기반으로 하지 않고 단지 검색 결과 순위를 올리기 위해 인위적인 편법을 사용하는데 있다. 예를 들어 검색 엔진 최적화를 악용하자면 컨텐츠와 상관없는 링크나 인기 키워드를 페이지에 구석구석에 보이지 않게 숨겨놓아 검색 엔진이 페이지의 중요도를 높게 착각하도록 유도할 수 있다. 하지만 구글과 같은 경우 이미 이런 편법을 발견하면 검색 결과 순위를 낮추는 대처를 기술적으로 하고 있으며, 인위적인 유도를 통해서 들어온 방문자가 해당 사이트를 다시 방문할 확률은 많지 않기 때문에 검색 엔진 최적화를 악용하는 것은 시간낭비일 뿐이다.

검색 엔진 최적화는 단순히 검색 엔진을 속이는 속임수가 아니다. 검색 엔진 최적화는 엄밀히 말하자면 검색 엔진과 전략적 제휴를 맺기 위해 최대한 웹 표준에 맞게 페이지를 작성하는 것을 의미한다. 검색 엔진은 웹 표준을 기반으로 어떤 기준을 세우고 텍스트를 분석하기 때문이다. 우리가 문법이 정확한 언어를 쉽게 알아들을 수 있듯이, 컴퓨터도 해석할 수 있는 문법으로 작성된 데이터만을 분석할 수 있다. 검색 엔진 역시 다르지 않다. 사용자가 입력한 키워드에 맞춰 정확히 검색 순위를 정하려면 웹 표준이라는 문법에 맞게 작성한 웹 페이지가 필요하다. 물론 웹 표준 문서를 참조하며 정확히 페이지를 만들지 않아도 검색 결과에 노출될 수 있다. 우리가 사투리나 외국인이 하는 서툰 우리말을 일정 부분 알아들을 수 있듯이 컴퓨터도 마찬가지이다. 하지만 보다 정확히 의사를 전달하려면 어떻게 해야 하는가? 간단하다. 표준말을 구사하면 된다. 이처럼 웹 페이지가 담고 있는 내용을 정확히 검색 엔진에 전달하고 싶으면 웹 표준을 지킬 필요가 있다. 검색 엔진 최적화를 실행함으로써 검색 엔진은 좀 더 나은 검색 결과를 얻게 되고, 사이트는 검색 결과에 높은 순위로 노출될 수 있기 때문에 서로의 이해 관계가 맞아 떨어지는 전략적 제휴가 가능한 것이다. 또한 검색 엔진 최적화는 검색 엔진에 쉽게 수집되는 사이트를 만드는 것 이상의 부가가치를 만들어 준다. 웹 표준을 지키는 것은 사용자의 웹 접근성도 강화시켜주기 때문이다. 사용자와 컴퓨터가 모두 이해할 수 있는 웹 페이지는 웹 2.0의 특징 중 하나이다. 이처럼 검색 엔진 최적화는 사용자와 컴퓨터를 동시에 만족시키는 웹 2.0다운 마케팅 방법이라 할 수 있다.

검색 엔진 최적화는 지금 당장 실행해서 큰 효과를 볼 수 있는 마법 같은 마케팅 기술은 아니다. 검색 알고리즘은 계속 진화하고 있으며 검색 엔진 최적화 역시 지속적인 관심과 보강이 필요하다. 또한 국내에서 시도하기엔 부족한 점이 많다. 국내 검색 사이트는 검색 결과를 만들 때 지식 데이터나 스폰서 링크 같은 내부 데이터베이스에 많이 의존하며 해외 검색 사이트는 아직도 검색 엔진을 이용한 웹 페이지 검색을 위주로 한기 때문이다. 하지만 국내 검색 사이트들도 검색 엔진 기능 강화의 중요성을 인식하고 NHN이 첫 눈을 인수하고 SK커뮤니케이션이 엠파스를 인수하는 등 제각기 검색 기능의 업그레이드에 힘쓰고 있다. 또한 구글과 같은 강력한 검색 엔진을 기반으로 하는 검색 사이트가 여전히 국내에서도 힘을 발휘하고 있다.

검색 엔진 최적화는 검색 엔진을 무료로 활용할 수 있는 마케팅이지만 동시에 사용자의 웹 접근성을 강화시켜주는 기술적인 방법이기도 하다. 게다가 큰 비용이 아닌 작고 간단한 실천으로 효과를 거둘 수 있다. 사이트를 만들었다면 검색 엔진 최적화를 주저할 아무런 이유가 없다. 모자란 능력을 채우고 경쟁자들보다 우위에 서려면 끊임없이 아군을 찾아 제휴해야 한다. 웹 2.0을 통해 사용자와 제휴했다면 이젠 막강한 검색 엔진과 제휴를 맺을 차례다.

이 그림에서 알 수 있듯이 웹2.0의 기본적인 개념과 서비스는 웹2.0 이전에도 존재한다. 웹2.0 기술도 마찬가지다. 웹2.0이란 개념이 정의되면서 주목을 받거나 새롭게 떠오르고 있는 일련의 기술이 존재할 뿐이다. 서버 소프트웨어, 콘텐츠 신디케이션(사이트 콘텐츠의 일부 또는 전체를 다른 서비스에서 이용할 수 있게 해주는 것. RSS가 대표적), 웹 표준, 리아(RIA), 웹 서비스, 여러 가지 클라이언트 애플리케이션 등 웹2.0 기술은 매우 다양한 범주의 기술을 포함하고 있다.

웹2.0을 개발하려는 사람들은 이처럼 다양한 기술을 보고 상당히 혼란스러워하거나 배신감을 느낄 수 있다. 일반적으로 웹 애플리케이션을 개발하는데 기본 바탕이 되는 기술과는 다른 성격과 기능을 가지고 있기 때문. 과연 웹2.0 기술들을 전부 적용해야 성공적인 웹2.0 애플리케이션을 만들 수 있는지, 아니라면 그 중 무엇을 적용해야 하는지의 판단이 애매모호하다. 이런 기술적 결정은 프로젝트의 성패에 큰 영향을 미친다. 과연 어떤 선택이 올바른 결정일까? 올바른 결정을 내리기 위해서는 먼저 웹2.0 기술의 사용 목적을 명확히 이해해야 한다.

웹2.0 기술의 눈에 띄는 네 가지 변화

다음 항목들은 웹2.0 기술로 불리고 있다.

● X/HTML과 CSS

● Ajax(Asynchronous Javascript And Xml)

● RSS/Atom

● OPEN API와 매시업(Mashup)

● 마이크로포맷(Microformat)

● 어도비 플래시(Adobe Flash)와 플렉스(Flex)

● XUL(XML User Interface Language)

● SVG(Scalable Vector Graphics)

● 태그(Tag)와 태그 클라우드(Tag Cloud)

언뜻 보기에 서로 아무런 연관성이 없어 보일뿐더러 생소한 단어와 영어 약자로 인해 머릿속이 복잡해진다. 여기에 열거된 항목이 전부가 아니다. 이외의 기술들도 웹2.0 기술이라는 타이틀을 달고 인터넷 커뮤니티에서 거론되고 있다. 이 기술 가운데 일부는 웹2.0이라는 신드롬에 걸맞지 않은 영향력을 가지고 있기도 하다. XUL과 SVG는 비즈니스에 사용되기엔 아직 설익은 마크업 랭귀지(Markup Language)이고, 플래시는 전통적인 클라이언트 기술 중 하나이다.

하지만 중요한 것은 각 기술들의 스펙이 아니라 왜 이 기술을 사용해야 하는지에 대한 당위성이다. 웹2.0이 ‘좀 더 나은 웹’을 서비스하기 위해 ‘콘텐츠 생산력’을 강화하는 방법을 열거했듯이 웹2.0 기술도 ‘좀 더 나은 웹’을 개발하기 위해 무엇을 할 수 있는지 이해할 필요가 있다. 2.0이란 버전은 서비스 제공자나 서비스 사용자의 입장에서 모두 ‘좀 더 나은’ 환경을 제공해야 한다는 의무를 뜻한다. 웹2.0 기술이 지금껏 웹을 이끌어 왔던 핵심 영역들의 개선에 어떤 영향을 주는지 이해한다면 복잡한 용어와 기술들의 난립에도 기죽지 않고 올바르게 활용할 수 있는 토대를 마련할 수 있을 것이다.

데이터 유통 흐름의 변화 - 콘텐츠 신디케이션
기존 웹은 사용자가 원하는 정보를 얻으려면 사이트를 직접 방문해야 했다. 하지만 웹2.0은 굳이 그럴 필요가 없다. 콘텐츠 신디케이션이라는 새로운 방식의 정보 제공 방식이 생겼기 때문이다. 콘텐츠 신디케이션은 사용자가 사이트를 방문하지 않고도 정보를 얻을 수 있도록 데이터를 정해진 규약으로 모두에게 공개하는 방법이다. 웹2.0은 RSS와 Atom이라는 기술을 이용해 콘텐츠 신디케이션이라는 새로운 데이터 유통 채널의 중요성을 강조하고 있다.

콘텐츠가 경쟁력인 인터넷 비즈니스에서 콘텐츠의 유통 채널이 새로 생긴다는 것은 커다란 변화를 의미한다. RSS와 Atom은 어려운 기술이 아니다. 단순히 데이터를 HTTP를 통해 XML로 제공하는 간단한 규약이다. 모두에게 공개하려면 누구나 쉽게 이해할 수 있는 데이터 포맷이 필요한데 그 조건을 충족시키는 것이 바로 XML을 이용한 RSS와 Atom이다. 이 간단한 데이터 포맷으로 웹의 데이터 유통 방식은 또 하나의 강력한 옵션을 가지게 되었다.

웹 클라이언트의 변화 - 리아(RIA : Rich Internet Application)
리아는 ‘Rich Internet Application’의 줄임말로 인터넷에서 데스크탑 애플리케이션처럼 풍부한 사용자 인터페이스를 구현한 애플리케이션을 말한다. 기존의 리아는 Active X나 자바 애플릿 같은 별도의 클라이언트 엔진을 사용한 탓에 개발이 어렵고 속도가 느리며 플랫폼 종속적이라는 단점을 가지고 있다. 이는 외부의 변화에 쉽게 적응하고 사용자의 참여를 종용하는 웹2.0 애플리케이션에 위배되는 기술적 특성이다.

그에 반해 Ajax를 이용한 리아는 더 많은 사용자에게 풍부한 사용자 인터페이스를 지원할 수 있는 기회를 제공하였다. 자바스크립트라는 가벼운 웹 기반 기술사용으로 기존 웹 시스템과 통합이 용이하며 대부분의 사용자를 대상으로 쉬운 서비스가 가능하다. 플래시 역시 많이 사용되고 있는 웹 클라이언트 엔진이다. 인터넷이 가능한 PC의 약 97% 가량이 플래시를 볼 수 있다는 통계가 이를 말해준다. 국내만 하더라도 사이트의 필수 요소인 배너 광고의 대부분은 플래시를 이용하므로 통계학적 수치가 상당부분 수긍이 간다. Ajax와 플래시는 많은 사용자가 쉽게 이용할 수 있다는 장점을 바탕으로 웹2.0의 사용자 인터페이스가 진화하는데 큰 공을 세우고 있다.

시멘틱 웹(Semantic Web)으로의 변화 - 태그와 마이크로포맷
시맨틱 웹은 웹의 창시자인 팀 버너스 리(Tim Berners-Lee)에 의해 제안된 웹의 미래상으로 사람이 아닌 컴퓨터가 이해할 수 있는 웹을 말한다. 다시 말해 사람이 웹에서 만들고 이용하는 데이터를 컴퓨터가 이해할 수 있는 형식으로 표현해 컴퓨터끼리 의사소통할 수 있는 자동화된 지능형 웹이다. 태그와 마이크로포맷은 이처럼 컴퓨터가 이해할 수 있는 시맨틱 웹의 의미를 웹에 구현할 수 있는 웹2.0 기술이다.

태그는 사용자가 콘텐츠를 생성할 때 함께 입력한 키워드를 말한다. 태그를 이용하면 기존에 정해진 카테고리 분류 방식에서 벗어나 사용자가 직접 자신이 생성한 콘텐츠에 대한 꼬리표를 달 수 있게 된다. 사용자가 콘텐츠에 부여한 태그들이 쌓이면 컴퓨터에 의해 자동으로 체계화될 것이다. 태그는 컴퓨터에 카테고리라는 의미(Semantic)이기 때문이다. 마이크로포맷은 태그와 달리 HTML 안에 간단한 의미(Semantic)를 담을 수 있다.

마이크로포맷에는 일정 정보를 표현하는 hCalendar, 명함 정보를 표현하는 hCard 등 다양하고 쉬운 포맷들이 존재한다. 이 마이크로포맷들은 브라우저나 검색엔진에서 HTML 안에 담긴 일정이나 인적 정보과 같은 특정한 목적의 정보를 쉽게 가져와 재사용할 수 있도록 도와준다. 시맨틱 웹의 생존을 위한 변화는 웹2.0을 통해 조용히 진행되고 있다.

웹 개발방법론의 변화 - OPEN API를 이용한 매시업
OPEN API는 말 그대로 모두에게 공개된 프로그래밍 인터페이스이다. 구글이나 야후, 아마존, 이베이 같은 메이저 인터넷 기업들은 물론 중소규모의 벤처기업까지 무수히 많은 기업들이 자사의 서비스를 OPEN API로 공개하고 있다. 사용자들은 각 기업의 서비스들이 제공하는 OPEN API를 조합하거나 활용하여 매시업이라는 또 다른 서비스를 쉽게 창출해 낼 수 있다.

예를 들어 지도 정보를 제공하는 구글 맵의 API와 사진 공유 사이트인 플리커의 API를 조합하면 여행 정보 매시업 서비스를 만들 수 있다. 이런 개발 방법은 웹2.0 시대에 등장한 것은 아니다. SOA(Service Oriented Architecture)는 ‘서비스 지향 아키텍처’의 약어로 서비스의 인터페이스를 제공하는 웹 서비스 기술을 통해 기업이나 서비스 단위간에 새로운 서비스를 창출하는 개발방법론이다. 이 기업 중심의 서비스 지향 개발 모델이 사용자 중심의 웹2.0으로 좀 더 쉽고 간단하게 변화된 것이 OPEN API이다. 사용자가 OPEN API를 통해 여러 가지 데이터를 조합해 또 다른 콘텐츠를 창출하는 매시업은 사용자의 참여와 콘텐츠를 중시하는 웹2.0의 기반 기술로 활용하기에 손색이 없다. ‘플랫폼으로서의 웹’을 구현하는 미래지향적 기술이라 할 수 있다.


참여, 공유, 개방을 중심으로 하는 웹2.0은 이처럼 네 가지 기술적 변화들을 통해 서비스를 좀 더 풍요롭게 만들고 있다. 웹2.0 기술은 갑자기 떠오른 혁신적인 분야의 기술이 아니다. 웹2.0이 사람을 중시하는 웹의 기본정신을 강화하고 개선하고 있듯이, 웹2.0 기술 역시 웹을 구성하고 있는 여러 기술적 모델을 계승하고 진화시키고 있다.

단순한 것이 최고다(Simple is best)

웹2.0 기술은 웹 서비스 모델의 각 부분을 확장하고 개선하는데 큰 도움을 주지만 그에 앞서 주목해야 할 공통적인 특징이 있다.

● 간단한 기술 : 대부분이 텍스트를 이용한 웹 기반 기술이기 때문에 기술의 습득이 쉽고, 기존 시스템과 통합이 용이하다.

● 가벼운(Loosely Coupled) 기술 : 쉬운 인터페이스로 기술간의 결합도가 낮기 때문에 다른 기술과의 다양한 조합이 가능하다. 대부분의 기술이 XML를 통해 요구를 처리한다.

● 공개 데이터(Open Data) 기술 : 사이트에 있는 데이터를 쉽게 공개하고 처리할 수 있다. 그러므로 서로 다른 사이트간의 데이터를 조합하여 새로운 서비스를 창출할 수 있다. 웹2.0이 데이터를 공유하고 개방하는 서비스 모델이듯이 웹2.0 기술 역시 대부분 데이터를 공유하고 개방하는 방법에 대해 다루고 있다.

● 순수한 웹 기반 기술 : 웹2.0 기술은 대부분 순수한 웹 기반 기술로 이루어져 있다. 그만큼 인터넷이 연결된 컴퓨터만 있다면 웹2.0 기술로 개발한 애플리케이션을 사용할 수 있다. 예를 들어 자바스크립트 기반의 Ajax를 이용하면 브라우저를 통해 데스크탑 애플리케이션만큼의 풍부한 기능을 제공할 수 있다.

이러한 특징은 웹의 시발점인 인터넷과 HTML, 하이퍼링크, HTTP의 기술적 특징을 그대로 계승하고 있다. 웹 역시 HTML과 하이퍼링크처럼 쉽고 가벼우며 데이터 중심적인 기술을 통해 급속한 발전을 이루지 않았는가. 닷컴버블 시절의 웹 기술은 폐쇄적인 경향을 지니고 있었다.

인터넷 산업이 발달함에 따라 서비스보다는 기술을 이용해 독점적인 위치와 그에 상응하는 수익을 얻으려는 IT 기업들의 비즈니스 전략에 의해 기술 산업이 발전했기 때문이다. 기술의 내부는 경쟁을 위해 감추고 제휴는 기업 논리를 통해 이뤄졌다. IE의 Active X나 비표준 태그 지원 등 마이크로소프트의 국제 비표준 기술의 지원을 통한 시장 지배 방식은 이미 대중들에게 유명하다. 독점이라는 지배구조는 인터넷 산업에도 지대한 영향을 발휘하는 듯 보였다.

하지만 웹 기술 생태계의 씨앗은 HTML의 단순함(Simple) 이었듯이, 단순하고 사용하기 쉬운 기술은 조용히 그 영향력을 펼쳐나갔다. 모든 생태계의 생존 비법은 외부의 변화에도 살아남을 수 있는 적응력과 번식력이다. 웹 기술도 마찬가지이다. 몸집만 거대하고 무거워진 기술과 소프트웨어는 도태되고 비교적 가볍고 쉽지만 본연의 임무에 충실한 기술은 웹 기술 생태계에서 살아남았다. 웹2.0 기술은 이 같은 웹 기술의 생존과정을 온몸으로 증명하고 있다.

● Active X, 자바 애플릿 → Ajax : 별도의 언어를 이용해야 하는 클라이언트 엔진에 비해 Ajax는 자바스크립트를 이용하므로 기존 웹 시스템과 통합이 쉽고 개발이 용이하다.

● 시맨틱 웹 → 태그, 마이크로포맷 : 다소 난해한 온톨로지 언어를 이용해야 하는 시맨틱 웹은 기업과 개인에게 환영받지 못하고 있으나, 태그와 마이크로포맷은 간단한 메타데이터를 이용해 시맨틱 웹의 정신을 웹2.0에 반영하고 있다.

● SOA → OPEN API : 기업 중심의 서비스 지향 아키텍처인 SOA는 SOAP이나 XML-RPC 같은 어려운 서비스 프로토콜로 인해 널리 보급되지 못했다. OPEN API는 REST라는 간단한 프로토콜을 통해 소비자 중심의 서비스 지향 아키텍처로 성공을 거두고 있다.

● CGI → Script 언어(php, jsp, asp) : 기존의 CGI 방식은 초창기 웹에 주도적 개발 방식이었지만 개발이 어렵고 운영체제 의존적이라는 단점이 있었다. 반면 배우기 쉽고 개발이 용이한 스크립트 언어는 현재 대부분의 웹 개발에 사용되고 있다.

물론 모든 기술은 쉽고 간단해야 한다는 어리석은 주장을 하는 것은 아니다. 목적에 맞게 설계되어야 하고 또한 용도에 맞게 사용되어야 한다는 것이다. 좀 더 강력한 기능을 원한다면 단순함을 포기하고 복잡함을 선택할 수도 있다. 하지만 웹은 사용자의 참여와 공유, 개방이 원동력이 되는 열린 공간이다. 웹 기술을 이용한 개발이 쉽고 간단하다면 기업들은 서비스를 빨리 만들어 사용자의 콘텐츠를 남보다 먼저 확보하고, ‘영원한 베타’의 정신을 살려 사용자의 변덕스러운 요구를 만족시킬 수 있을 것이다.

반면 웹 기술이 어렵고 무겁다면 새롭게 기획된 서비스는 오랜 시간에 걸쳐 발표될 것이고 그 사이 경쟁 사이트의 출현으로 미처 꽃피우기도 전에 사그라질 수 있다. 게다가 사용자의 지속적인 개선에 대한 요구는 묵살되고 영원히 완성되지 못한 채 베타 서비스로 전락할지도 모른다. 이처럼 기존 기술에 비해 비교적 쉽고 간단한 웹2.0 기술은 마치 웹2.0의 쉬운 사용자 참여를 통한 폭발적인 데이터 생산 능력처럼 서비스를 생산하는 능력을 높여준다. 더불어 개발자의 보다 많은 참여를 유도해 인터넷 산업의 파이를 키우기에 충분한 역할을 하고 있다. 웹2.0과 웹2.0 기술은 무척이나 많이 닮아있다.

플랫폼으로서의 웹과 윈도우 SDK

웹2.0 기술의 또 다른 특징은 다양한 종류의 기술들이 모여 하나의 플랫폼을 구성하고 있다는 점이다. 웹2.0에서의 플랫폼은 사용자가 자유롭게 참여하여 콘텐츠를 생산하거나 서비스를 이용할 수 있는 공간을 말한다. 웹2.0 기술에서의 플랫폼 역시 몇몇 단어의 의미를 제외하고는 같은 의미를 가진다. 기술의 입장에서 사용자는 개발자이고, 콘텐츠는 애플리케이션이다. 웹2.0의 플랫폼이 “사용자의 참여로 콘텐츠를 생산해 낼 수 있는 공간”이라면 웹2.0 기술에서 의미하는 플랫폼은 “개발자가 자유롭게 참여해서 애플리케이션을 생산해낼 수 있는 공간”을 말한다.

웹2.0 기술은 특정한 목적을 위한 기술이자 자유로운 활용을 위한 기반 기술이다. 초기의 Ajax는 서버에 있는 XML을 호출하는 것이 주목적이었지만 지금은 웹에서 풍부한 인터페이스를 구현하기 위한 기반 기술로 활용되고 있다. RSS나 OPEN API의 경우에도 데이터의 외부 공개라는 무한한 가능성을 이용해 여러 가지 창의적인 시도가 이루어지고 있다. 마이크로포맷이나 태그 역시 메타데이터로 활용해 다양한 서비스를 창출할 수 있다. 마치 웹2.0 기술이 개발 플랫폼의 SDK(Software Develop ment Kit)처럼 여겨지지 않는가?

지금까지 거론한 웹2.0 기술의 공통적 특징은 경쟁력 있는 플랫폼을 구성하기에 모자람이 없다. 지금부터 웹 플랫폼에서 실행되는 서비스를 소프트웨어라 불러보자. 웹2.0 기술의 특징 중 간단하고 쉽다는 장점은 소프트웨어를 빨리 개발할 수 있는 얘기이다. 가볍고 다른 사이트의 데이터를 가져올 수 있다는 특징은 다른 소프트웨어의 라이브러리와 쉬운 결합을 의미한다. 즉 웹은 소프트웨어를 생산하는 개발 플랫폼으로서 상당한 경쟁력을 갖추고 있다는 결론에 다다른다. 웹2.0이 콘텐츠 생산력을 증가시키는 당연한 수순을 밟고 있듯이, 웹2.0 기술 역시 소프트웨어 생산력을 증가시키는 ‘더 나은 웹 기술’의 수순을 밟고 있다. 또한 웹 플랫폼은 비즈니스적 관점에서 운영체제 플랫폼에 비해 다음과 같이 장점을 가지고 있다.

웹 플랫폼은 이러한 잠재성을 가지고 있음에도 불구하고 아직 운영체제 플랫폼에 비해 떨어지는 성능이 단점이다. 하지만 네트워크 대역폭의 확대와 컴퓨터 성능의 발전은 웹 플랫폼의 밝은 미래를 기대케 한다. 이미 구글이 구글 닥스 앤 스프레드시트(Google Docs & Spreadsheets : http://docs.google.com)를 통해 웹 브라우저 환경에서 구현되는 오피스 소프트웨어를 제공하고 있다. ‘플랫폼으로서 웹’이 조용하지만 빠르고 강력하게 진행되고 있다.

종종 플랫폼으로서의 웹을 말하며 어디에 사용해야 할지, 어떻게 수익모델을 만들어야 할지 모르겠다며 거품 기술로 치부하는 이들도 있다. 하지만 우리는 이미 윈도우라는 개발 플랫폼을 통해 수없이 많은 소프트웨어를 경험했다. 윈도우 SDK를 거론하며 그러한 불평을 하는 사람은 없다. 소프트웨어로 수익을 낼 수 있는 간단한 비결은 세상 어디에도 존재하지 않는다.

하지만 소프트웨어로 부를 창조한 사람은 많다. Ajax와 RSS, OPEN API와 같은 웹2.0 기술이 수익을 가져다주지 않는다고 불평하며 낭비하는 시간에 어떤 괴짜는 ‘유레카!’를 외치며 웹2.0 기술 기반의 사용자가 원하는 킬러 애플리케이션을 만들고 있을 것이다. 성공과 실패의 명암은 늘 그런 식으로 아무도 눈치 채지 못하게 다가온다. 웹2.0이 모두가 실패를 경험했을 때 불현듯 찾아왔듯이 말이다.

실패의 역사는 성공의 밑바탕이다

지금까지 설명했듯이 웹과 웹 기술은 타 플랫폼과의 경쟁에서 비교우위를 점하기 위해 치열하게 변화해왔다. 우리는 웹이 처음 등장했을 때 그 충격적이고 급격한 변화의 흐름 속에서 웹의 진정한 가치를 꿰뚫어보지 못했다. 오프라인적인 사고방식에 길들여져 있던 기업과 사용자들은 정보의 공유와 참여에 대해 인색했고, 결국 닷컴버블이라는 지독한 산통을 겪으며 웹2.0이란 2세를 낳았다.

그리고 웹2.0은 인터넷이라는 모두에게 평등한 사회 속에서 공개하고 공유하며 참여하면서 스스로 성장해가고 있다. 물론 우리는 여전히 웹2.0 안에서 과거의 실패를 반복하기도 한다. 사용자 참여의 소중함을 잊은 채 이기적이고 독선적인 서비스가 수없이 나왔다 사라지를 거듭하고 있으니 말이다. 웹2.0에서 중요한 것은 ‘2.0’이라는 미래가 아닌 ‘웹’이라는 과거와 현재라는 사실을 잊고 있는 탓이다.

웹2.0 기술도 마찬가지의 고통스러운 진화를 거듭해왔다. 다양한 기능을 제공하나 난해하고 사용이 어려운 기술들은 점점 도태되어 갔고, 뚜렷한 목적을 지닌 간단하고 쉬운 기술들은 그 틈을 파고들어 웹 구석구석에 빠르게 퍼져나갔다. Ajax가 액티브X와 자바애플릿의 난립 속에서 조그만 싹을 키워 어마어마한 영향력을 떨치고 있지 않은가.

이러한 기술의 치열한 전쟁의 역사는 우리에게 중요한 교훈을 준다. 중요한 것은 기술의 스펙이 아니라 기술의 목적이라는 사실을 잊어서는 안 된다. 요즈음 웹2.0 기술을 사용하면서도 더 나은 웹을 구현하는 데는 별 관심이 없는 서비스를 자주 접한다. RSS는 정보의 공개와 공유가 얼마나 큰 파생력을 가지고 있는지 스스로 증명했다. 하지만 국내 포털 사이트는 RSS를 제공함에도 불구하고 내부의 데이터는 공개하지 않은 채 꽁꽁 묶어두고 있다.

Ajax를 HTML로 구현이 가능한 구태의연한 인터페이스에 적용하여 시스템을 무겁게 하는 경우까지 있다. OPEN API가 현대사회에서 신속한 전략적 제휴가 얼마나 큰 힘을 발휘하는지 기술로 증명하고 있지만, 국내 기업은 단지 몇 개의 API만을 공개한 채 다른 기업과의 제휴에는 인색하다. 수없이 많은 실패를 경험하며 성장한 기술들을 통해 아무것도 배우지 못하고 있는 셈이다.

훌륭한 엔지니어는 기술의 스펙보다는 기술이 탄생한 배경과 역사, 그리고 그 목적을 충실히 이해하는 것이 필요하다. 과거의 실패를 되풀이하지 않기 위해 역사를 공부하듯이 말이다. 실패의 역사는 현재에도 미래에도 계속 되풀이 되어 우리를 좀 더 나은 방향으로 나아가게 만든다. 단 실패를 겸허히 받아들이는 자세를 가진다는 전제하에서 가능하다. 하루가 멀다 하고 쏟아지는 웹 기술들을 실패한 과거를 되새겨 겸손하게 맞이할 자세를 갖추어야 할 것이다. 바로 그 순간 웹2.0 기술은 조용하지만 강하게 효력을 발휘한다.