내 마음속 폭풍은 아직 아무것도 삼키지 못했다.

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

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

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

이처럼 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) 분석 방법이다. 웹 서버 로그 파일 분석은 말 그대로 사용자가 웹 서버를 호출한 정보를 파일에 저장하여 다양한 관점에서 분석하는 방법이다. 웹 서버는 기본적으로 로그 파일을 남기도록 설정할 수 있고, 다양한 옵션을 통해 저장되는 내용도 조절할 수 있기 때문에 쉽게 대용량의 사용자 데이터를 얻을 수 있다. 하지만 이 대용량의 데이터를 목적에 맞게 분석하기에는 많은 비용이 들기 때문에 이를 해결하기 위해 전문적인 웹 데이터 분석 솔루션이 존재한다. 다음은 그중에서도 무료로 제공되는 몇 가지 분석 솔루션들이다.

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

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

원리는 간단하다. 자바스크립트가 외부 서버에 동적으로 투명 이미지 파일을 요청하면서, 수집한 정보를 파라미터로 함께 넘기는 것이다. 이 방법은 전문 분석 소프트웨어에 비해 많은 유연성을 가지고 있다. 자바스크립트를 이용하기 때문에 웹 페이지 호출뿐만 아니라 버튼 클릭이나 자바스크립트를 사용한 사용자 인터페이스, 플래시와 같은 외부 객체에 대한 사용자의 행동까지 저장할 수 있다. 사이트의 모든 페이지가 중요하겠지만 그중에서도 수익에 직접적인 영향을 미치는 페이지가 있을 것이다. 그런 부분에 집중적으로 사용자의 행동을 저장하고 분석한다면 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를 체계화하고 미션화하는 능력을 길러야 한다. 그리고 그에 대한 성과를 수치화시켜서 조직에 제시할 수 있어야 한다. 개발자들이여. 회사에서 나는 이렇게 중요한 인재라고 항변하자. 그것은 전적으로 우리를 위해서만은 아니다. 영문도 모른 채 사이트에서 불쾌한 경험을 하고 있는 사용자들을 위해서이다.