[마소 2008년 2월] UX 개발자와 만나다.

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

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를 체계화하고 미션화하는 능력을 길러야 한다. 그리고 그에 대한 성과를 수치화시켜서 조직에 제시할 수 있어야 한다. 개발자들이여. 회사에서 나는 이렇게 중요한 인재라고 항변하자. 그것은 전적으로 우리를 위해서만은 아니다. 영문도 모른 채 사이트에서 불쾌한 경험을 하고 있는 사용자들을 위해서이다.

by 마음속폭풍 | 2008/02/04 00:06 | 컬럼 | 트랙백 | 덧글(4)

[마소 2008년 1월] 누가 컴퓨터의 심장을 만들었는가

박지강 (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)  : 인간을 위한 컴퓨터

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


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

by 마음속폭풍 | 2008/02/03 23:24 | 컬럼 | 트랙백 | 덧글(0)

[마소 2007년 12월] 더 넓은 웹으로 번역의 세계


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

사용자의 참여를 통한 컨텐츠 생산의 폭발력은 이미 웹 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> 구글을 이용한 번역의 한 예

위의 예는 “the number of employees is”를 구글을 통해 한국어 웹에서만 검색한 결과 중 하나이다. 보다시피 “The number of employees is 50. (직원은 50명이다.)”라는 구절에서 “the number of employees”는 “고용원의 수”가 아닌 “직원”이라는 단어로 부드럽게 의역되었다. 검색 엔진은 이와 같은 경험 위주의 언어 데이터를 모아 좀 더 부드러운 번역을 위해 사용될 수 있을 것이다. 구글과 같이 인터넷의 데이터를 번역 통계로 활용하는 번역기에게 웹은 거대하고 풍부한 번역 메모리(TM)인 셈이다.  
물론 아직도 해결해야 할 부분은 많겠지만 전 세계의 웹 페이지에서 단어와 문장을 축ㅇㅇ적하여 번역 기술에 활용하겠다는 구글의 야망은 적어도 필자에게는 전혀 허황된 얘기로 들리지 않는다. 만약 높은 정확도의 다국어 번역 서비스가 가능하다면 지금의 웹 2.0 시장은 전 세계의 사용자의 참여를 컨텐츠로 바꿀 수 있는 비즈니스 모델을 이용해 폭발적으로 성장하게 될 것이다. 지금 구글이 최고다라는 말을 하고 있는 것은 아니다. 구글은 이미 자신의 핵심역량을 이용해 웹에서 경쟁력을 한층 더 강화하는 방법을 알고 있음을 지적하는 것이다. 최고의 컨텐츠 생산력을 가지고 있는 검색 엔진을 한 단계 더 업그레이드 시키는 방법은 전세계의 모든 사용자들이 동일한 문서를 이해할 수 있도록 만드는 것임을 구글은 잘 알고 있다.

언어의 장벽을 넘어 더 넓은 웹으로

지난 연말 뉴욕타임즈는 EU가 회원국들을 위해 협정과 조약을 번역하는 데만 1조억원을 넘게 사용한 사실을 기사화했다.  정말 어마어마한 비용이 아닌가! 더군다나 매 해마다 그 비용이 증가하고 있다고 한다. 물론 번역은 단지 EU만의 문제만은 아니다. FTA를 보면 알 수 있듯이 세계화를 통해 국제 관계의 개방은 점점 가속화되고 있으며, 우리의 실생활이나 생업에도 많은 영향을 미치고 있다. 이처럼 세계화 시대에 글로벌 커뮤니케이션의 가치는 아무리 강조해도 지나침이 없다. 웹을 들여다보면 그 중요성은 더욱 커진다. 웹에 존재하는 한국어 정보는 전 세계의 웹 정보량의 수 퍼센트에 불가하다. 즉 전체 정보의 90% 이상을 활용하지 못하고 있다는 말이다. 비약적이지만 웹은 곧 데이터라는 가정을 할 때 우리는 웹을 겨우 수 퍼센트만 이용하고 있는 격이다. 하지만 그 말을 거꾸로 뒤집어보면, 우리나라와 같이 세계적 범용어인 영어를 사용하지 않고 고유 언어를 사용하는 소수 국가는 언어의 장벽을 허물었을 때의 효과가 어마어마해진다는 뜻도 된다.
사용자의 참여를 기반으로 하는 웹은 폭발적인 성장세를 지속해 오고 있다. 유투브와 같은 UCC 동영상 서비스가 급격히 성장할 수 있는 이유는 바로 동영상 플레이어의 글로벌함이다. 플레이 버튼과 스톱 버튼, 프로그레스 바는 굳이 언어로 부연설명을 달지 않아도 세계에 통용될 수 있는 인터페이스이다. 국내의 커뮤니티에서도 유투브 동영상을 게시한 글을 쉽게 찾아볼 수 있는 것이 바로 그러한 이유에서이다. 하지만 텍스트는 그렇지 못하다. 언어는 나라마다 천차만별이기 때문이다. 이처럼 텍스트 기반의 웹에서 번역은 글로벌 커뮤니케이션의 강력한 수단이다. 그렇기 때문에 포털들은 자신들이 가진 데이터를 어떻게 좀 더 많은 사용자에게 보여줄지 고민하고 있고 그에 대한 기술을 꾸준히 연구하고 있는 것이다. 하지만 언제 완성될지 모르는 웹의 세계화를 무작정 기다리는 것은 바보 같은 짓이다. 국내에서 해결할 수 없는 문제가 있다면 검색 엔진을 이용해 영작을 해서 해외 커뮤니티에 질문을 올려보자. 그리고 피드백을 받아보자. 인터넷이 연결되어있는 한 세계는 바로 당신 컴퓨터 앞에 있다.

by 마음속폭풍 | 2008/02/03 22:49 | 컬럼 | 트랙백 | 덧글(0)

[마소 2007년 11월] 애자일 입문서, 스크럼(SCRUM)

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

스크럼이란?

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

  협업팀(CFT : Cross-Functional Team) 

 

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

 

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


<사진 1> 럭비의 스크럼(Scrum) (출처 : Philly Gryphons RFC / Flickr)

1991년, DeGrace와 Stahl의 "Wicked Problems, Righteous Solutions"라는 책에서 처음으로 스크럼과 같은 방법론이 소프트웨어 개발 관점에서 소개되었다. 그 후 1990년대 초 Ken Schwaber는 그의 회사인 Advanced Development Methods에서 스크럼을 사용하고 홍보하기 시작했고, 비슷한 시기에 Jeff Sutherland와 John Scumniotales, Jeff McKenna도 Easel Corporation라는 회사에서 스크럼을 사용했다. 그리고 1996년, 객체 지향 프로그래밍에 대한 컨퍼런스인 OOPSLA(Object-Oriented Programming, Systems, Languages & Applications)에서 위의 멤버들 중 Ken Schwaber와 Jeff Sutherland가 함께 스크럼에 대해 공식적으로 언급하기 시작했다. 스크럼의 데뷔인 셈이다. 그 후 그 둘은 스크럼에 대한 각자의 기록과 경험, 실제 사례들을 통합하는 작업을 수년간 수행했고 그것이 현재 소프트웨어 산업에서 논의되고 있는 스크럼의 근간이 되었다.


스크럼의 아버지, 애자일

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


중요한것

더 중요한 것

프로세스와 도구

개인과 상호 소통

상세한 문서화

잘 동작하는 소프트웨어

계약 협상

고객과의 협동

계획 이행

변화에 대응

<표1> 애자일 소프트웨어 개발 선언문 요약표


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


스크럼의 특징

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

♦  스크럼은 스프린트(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분간 간략한 회의를 연다. 회의의 목적은 업무를 수행하는데 방해가 되는 장애요인들을 제거하는 것 이다. 회의 참여자들은 다음의 세 가지 질문에 적절한 답변을 해야 한다.

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

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

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

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

 <그림 1> 스크럼 프로세스 공정(출처 : http://www.controlchaos.com)

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


스크럼이  과연 해답인가?

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

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

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

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

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

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

by 마음속폭풍 | 2007/11/27 01:30 | 컬럼 | 트랙백(2) | 덧글(0)

[마소 2007년 10월] 차세대 웹을 위한 안내서, HTML 5

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

하루가 멀다 하고 수많은 웹 기술이 등장하는 지금, 아이러니 하게도 가장 발전이 더딘 웹 기술은 웹의 핵심이라 할 수 있는 HTML이다. HTML은 1999년 HTML 4가 릴리즈된 이후 전혀 진전이 없었다. W3C는 HTML을 XML처럼 확장 가능하고, SVG(Scalable Vector Graphics)나 XForms, MathML과 같은 새로운 목적의 마크업 언어로 만드는데 많은 투자를 하였다. 또한 브라우저를 만드는 기업들은 브라우징 탭이나 RSS 리더를 장착하는 등의 부가기능을 추가하고, 웹 관련 개발자와 디자이너는 Ajax나 CSS를 통해 좀 더 나은 사이트를 만드는데 힘을 쏟았다. 이런 과정에서 관련 산업과 기술들이 규모의 경제를 이루고 질적인 향상을 이룬 반면 정작 웹의 가장 핵심 기술인 HTML은 1999년부터 현재까지 거의 성장을 하지 못했다.

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

<그림 1> WHATWG(Web Hypertext Application Technology Working Group)의 홈페이지

 결국 이런 현실적이고 구체적인 노력은 많은 진전을 이루었고, 최근 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가 채 완성되지도 않았음에도 불구하고 관심을 기울여야 하는 이유이다.  

by 마음속폭풍 | 2007/11/27 01:09 | 컬럼 | 트랙백 | 덧글(0)

◀ 이전 페이지다음 페이지 ▶