반응형
스마트한 RIA 구현을 위한 몇 가지 팁
월간 마이크로소프트웨어 2011년 9월호
구글 트렌드(http://www.google.com/trends) 서비스는 특정 검색어를 기준으로 최근의 트렌드를 살펴볼 수 있는 서비스이다. ‘Rich Internet’이라는 단어로 트렌드를 따라가 보면 2010년 이후 급격하게 하향세를 보이고 있다. 반면에 ‘UX’라는 단어는 꾸준히 검색량이 늘어나고 있으며 ‘HTML5‘라는 검색어는 2010년을 기점으로 급격히 높은 상승세를 보여주고 있다. 특히 후자의 경우는 국내에서 특히 높은 관심을 보이고 있다는 것을 확인해볼 수 있다. 그럼 전통적인 RIA는 역사 속으로 사라져버린걸까?
국내에서는 투비소프트의 엑스플랫폼이 동일한 코드에서 런타임과 AJAX 버전을 개발할 수 있는 기능을 확장해가고 있으며 멀티 디바이스 개발을 지원하는 하이브리드 앱 개발 기능이 추가된 9.2 버전을 9월 2일 선보일 예정이다. 이런 기능의 확대는 사용자의 요구에 맞는 제품을 선정할 수 있게 되고 필요에 따라 적절한 기능을 선택할 수 있게 된다.
지금으로부터 20년 전 8월 6일은 팀 버너스리가 WorldWideWeb을 처음으로 공개한 날이었다. 20년이 지난 지금 별도의 운영체제 없이 웹만으로 모든 서비스를 제공할 수 있다는 크롬북이라는 매체의 등장은 많은 것을 생각해보게 한다. 물론 운영체제가 아예 없는 것은 아니지만 설치된 프로그램을 서비스하는 것이 아닌 모든 애플리케이션이 네트워크상에서 동작하고 웹에서 서비스된다는 점에서 앞으로의 웹이 어떤 모습을 가질지 그려볼 수 있게 한다.
몇 년 사이에 RIA에 대한 정의도 조금씩 바뀌어가고 있다. 최근 위키피디아를 보면 HTML 5를 RIA 플랫폼으로 정의할 것인지에 대한 논란이 진행되고 있는 것을 확인해볼 수 있다(위키피디아는 누구에게나 편집권이 열려있기 때문에 수시로 내용이 변경된다. 특히 새로 등장하는 트렌드에 대한 정의일 경우 더욱 그런 현상이 두드러진다). RIA는 기존 웹이 지원하지 못했던 부분을 보완하기 위한 목적으로 등장했는데 새로운 웹 표준이 이를 지원하면서 기존에 RIA라고 했던 것을 어떻게 바라보아야 할 것인지가 문제가 되는 모양이다(이글을 쓰는 시점에서 위키피디아에서는 플래시, HTML 5, 자바, 실버라이트를 주요 플랫폼으로 보고 있다).
기존 RIA 진영을 이끌고 있는 주요 플랫폼의 움직임을 보면 이런 변화의 흐름을 놓치지 않으려는 움직임을 보이고 있다. 마이크로소프트웨어의 경우에는 IE9 출시와 함께 HTML 5에 대한 공격적인 마케팅을 진행하고 있으며 조만간 공개될 새로운 윈도우 버전인 윈도우 8부터는 HTML만 가지고 오피스나 윈도우에서 활용할 수 있는 확장기능을 만들 수 있게 공개하겠다고 했다. 그러면서 실버라이트 플랫폼은 모바일과 게임 콘솔, 서피스와 같은 테이블 컴퓨팅에서 여전히 강력한 도구로 제공될 수 있는 구조를 만들고 있다. 어도비는 최근 모바일에 집중하고 있는 것처럼 보이지만 드림위버를 중심으로 하는 웹 개발 기술을 바탕으로 HTML 5에 대한 베타 제품을 선보이고 있다. 대표적인 제품이 Edge라고 하는 애니메이션 저작도구이다. 플래시 타임라인의 개념을 그대로 가져와서 동일한 환경에서 애니메이션을 만들 수 있게 도구를 제공하고 결과물은 JQuery와 HTML 5로 배포할 수 있게 지원하고 있다. 현재 프리뷰 상태이고 내년도 정식 제품 출시를 준비하고 있지만 시장 내에서 어떤 식으로 자리를 잡을 지는 아직 확실하지 않다.국내에서는 투비소프트의 엑스플랫폼이 동일한 코드에서 런타임과 AJAX 버전을 개발할 수 있는 기능을 확장해가고 있으며 멀티 디바이스 개발을 지원하는 하이브리드 앱 개발 기능이 추가된 9.2 버전을 9월 2일 선보일 예정이다. 이런 기능의 확대는 사용자의 요구에 맞는 제품을 선정할 수 있게 되고 필요에 따라 적절한 기능을 선택할 수 있게 된다.
(그림 1. 구글 트렌드 - HTML 5)
지금으로부터 20년 전 8월 6일은 팀 버너스리가 WorldWideWeb을 처음으로 공개한 날이었다. 20년이 지난 지금 별도의 운영체제 없이 웹만으로 모든 서비스를 제공할 수 있다는 크롬북이라는 매체의 등장은 많은 것을 생각해보게 한다. 물론 운영체제가 아예 없는 것은 아니지만 설치된 프로그램을 서비스하는 것이 아닌 모든 애플리케이션이 네트워크상에서 동작하고 웹에서 서비스된다는 점에서 앞으로의 웹이 어떤 모습을 가질지 그려볼 수 있게 한다.
트렌드가 빠른 속도로 변해가는 것처럼 보이지만 웹의 본질은 크게 달라지지 않았다. 웹의 세계는 문서와 링크로 구성되어 있고 RIA는 이런 연결 고리를 좀 더 스마트하게 만들고자 하는 것뿐이다. 이번 글에서는 다양한 경험을 바탕으로 스마트한 RIA를 구축하기 위한 몇 가지 팁을 살펴보고자 한다.
AJAX가 최선인가요?
HTML 5 이슈와 함께 최근 발생된 보안 사고의 원인이 개인 PC에 설치된 브라우저 확장 기능이라는 것 때문에 액티브 X나 플러그인, 확장기술이 보안에 취약하다는 인식이 커지고 있다. 무분별하게 인증되지 않은 설치 프로그램이 배포되고 이로 인해 해킹 등의 사고가 생긴 과정에는 문제가 있지만 이에 대응하는 방법에서 또 다른 장벽을 만들고 있는 것이 아닌가 하는 우려를 나타내고 있다.
방송통신위원회에서는 지난 2월 ‘인터넷 이용환경 개선 추진계획’을 발표하고 액티브 X를 퇴출하겠다고 선언했다. 그리고 보안, 웹서비스, 웹응용, UI 4가지 영역에 대한 대체기술 가이드를 지원 사이트에서 제공하고 있다. 대표적인 것이 보안 영역에서 공인인증을 대체할 수 있는 ‘스마트사인’이라는 기술을 소개했다. 하지만 스마트사인 역시 아직 적극적으로 도입되지 못하고 있으며 그 외 항목도 실제 적용에 어려움이 있거나 HTML 5 기술에 한정되어 있어 대체기술이라고 하기에는 제약이 있다.
파일 업로드를 예로 든다면 HTML 5에서 멀티파일 업로드를 지원하지만 브라우저의 제약 때문에 포털에서는 적용하지 못하고 있으며 대용량 파일 업로드의 경우에도 안정적인 서비스를 제공하려고 별도의 플러그인 기술을 사용하고 있다. 그렇다면 국내 서비스되고 있는 주요 포털은 보안의 위험성을 가지고 있으면서도 계속 서비스를 하는 것일까? 플러그인 기술이 취약점을 가지고 있을 수는 있지만 그렇다고 지금까지 서비스하고 있던 기능을 하향조정할 수는 없는 것일까?
어느 주장이 정답이라고 할 수는 없지만 문제점을 알고 이에 대처하며 적절한 기술을 사용하는 것을 무조건 반대할 수만은 없다. 최근 나오는 공공기관의 제안요청서(RFP)를 살펴보면 기존에 사용하던 액티브 X 기반의 프로그램을 제거하고 안전한 대체 프로그래밍을 요청하는 경우가 있다. 정부의 정책이라는 배경이 있긴 하지만 기관의 입장에서는 대체 프로그램을 사용하면서 불편함을 감수하려 하지는 않을 것이다. 그렇다고 별도의 플러그인 기술 없이 기존과 동일한 수준의 서비스를 제공하려 한다면 이를 대체할 수 있는 기술을 준비할 자원과 시간이 필요한데 여기에 견해 차이가 있는 듯 보인다. 물론 인터랙티브한 화면 구현에 대안으로 제시되는 AJAX 기술을 잘 활용하면 기존과 동일한 서비스를 정해진 기한 내에 개발할 수 있을 것이다? 해당 기술을 충분히 이해하고 있고 이를 바탕으로 필요한 서비스를 구현해낼 수 있는 능력이 있다면 말이다.
(그림 2. 대체기술가이드 - 한국인터넷진흥원)
다양하게 활용할 수 있는 라이브러리를 쉽게 구할 수 있고 오픈소스도 많지만 실제 애플리케이션을 만들 때는 여러 가지 문제를 가지고 있다. 어떤 개발 도구를 사용할 것인지? 전문 인력을 확보할 수 있는지? 생산성을 보장해줄 수 있는지? 사용하는 라이브러리를 개발자가 적절하게 이해하고 있으며 해당 라이브러리가 안정적인지? 향후 지속적인 관리가 가능한지? 고민해야 한다.
많은 개발자들이 오픈소스를 가져다 사용하면서 이후 관리영역은 신경 쓰지 않고 그때그때 필요에 따라 입맛에 맞게 수정해놓는다. 작은 규모의 사이트라면 새로 기능을 만들거나 코드를 따라가며 수정할 수 있겠지만 대규모 프로젝트였다면 어떻겠는가? 업무 영역에서 작성된 코드는 검증과정을 거치지만 수정된 오픈소스는 아무런 제약 없이 프로젝트에 포함된다. 이런 코드는 애플리케이션이 잘못 동작하게 할 수도 있고 보안에 구멍이 생기게 하는 요인이 될 수도 있다.
무료로 제공되는 라이브러리를 사용한다고 해서 개발에 필요한 비용이 없다고 생각하면 큰 오산인 것이다. 앞에서 이야기한 것처럼 작은 규모로 직접 코드를 짜서 개발할 수 있는 정도라면 모르겠지만 별도 수주를 할 정도의 규모라면 개발을 진행할 수 있는 적절한 도구나 공통 컴포넌트를 필요로 하고 이를 구현할 수 있는 개발자를 필요로 한다.
좀 더 중요하게 고민해야 하는 부분은 멀티 브라우저를 어떻게 대응할 것인지 결정해야 한다. 자바스크립트라면 모든 브라우저에서 다 동작한다는 오해가 있지만 사용자에 따라 브라우저 설정을 꺼놓을 수도 있고(물론 대부분 기본 옵션이 켜짐이기 때문에 끄지는 않겠지만 중요한 것은 사용자가 선택할 수 있다는 것이다) 동일한 브라우저라도 버전에 따라 성능에 큰 차이가 있다는 것이다. 파이어폭스나 구글 크롬과 같은 브라우저는 사용자가 선택적으로 선택하며 자동 업데이트를 지원하기 때문에 최신 버전을 주로 사용하지만 인터넷 익스플로러는 사용하는 운영체제에 의존적이고 새로운 무언가를 설치하는데 부담을 가지는 일반 사용자가 많기 때문에 최신 브라우저의 보급률이 그렇게 높지 못하다. 간단한 기능 구현이라면 큰 차이가 없겠지만 필요에 따라 화면의 복잡도가 높다면 화면 처리 자체에 부담을 가질 수도 있다.
HTML 5를 따라야 하나요?
특정 분야에서는 이미 HTML 5 기술이 선택적으로 도입하고 있다. 비디오 서비스를 보면 해외의 유튜브, 비메오와 같은 서비스가 해당 기술을 선택할 수 있으며 국내의 판도라 TV도 적극적으로 도입을 검토하고 있다고 한다. 동영상 서비스 업체인 브라이트 커브는 단순한 서비스를 넘어 기존 플래시 기술로 제공했던 기능을 보완할 수 있는 로드맵을 제시했고 실제 서비스에 반영하고 있다. 캔버스를 활용한 캐주얼 게임 구현 사례를 보면 이 정도라면 기존 플러그인 기술을 대체할 수 있지 않을까 생각해보게 된다.
가능한 기술의 한도 내에서는 그렇다고 대답할 수 있다. 하지만 전문적인 영역으로 들어간다면 이야기가 달라진다. 오랜 시간동안 해당 비즈니스에 적합하게 서비스를 설계해왔고 그만큼 다양한 기능을 제공하고 있다. 예를 들어 기업용 애플리케이션에서 주로 사용하는 그리드를 보면 HTML 5 스펙에도 datagrid라는 태그를 사용할 수 있다. 하지만 간단한 데이터 연동이나 단순 편집 기능 정도를 제공할 뿐이다. 대량의 데이터를 처리하건 필터링, 업무에 맞게 데이터를 설계하는 작업은 표준 스펙만으로는 여전히 부족할 것이다. HTML 5 스펙은 어느 특정 비즈니스를 지원하기 위한 기술이 아닌 범용적인 기술이다. 자바스크립트와 함께 다양한 기능 확장이 가능하겠지만 그렇게 된다면 표준 스펙만으로 구현한 것이 아닌 별도의 기술을 적용하는 것이다. 간혹 HTML5 그리드라고 보이는 것들을 보면 대부분 jQuery 외부 플러그인으로 제공되는 기술로 확인된다. jqGrid나 SlickGrid를 사용하기도 하는데 이들은 표준 스펙이 아니며 정식 jQuery 라이브러리도 아니기 때문에 문제가 생길 수도 있으며 더 이상 업데이트를 제공하지 않을 수도 있다. Dojo의 경우에는 IBM에서 그리드 부분을 지원하고 있지만 역시 완벽한 보장을 제공하는 것은 아니다. 그리고 각 구현 방식이 다르기 때문에 서로 다른 기능을 이해하고 적용해야 한다.
(그림 3. SlickGrid – 그리드 내 동적인 그룹 정의)
지금 HTML 5와 관련된 기능을 추가하고자 한다면 해당 기술을 지원하지 못하는 환경을 같이 고려해주어야 한다. 그렇지 않는다면 상당히 큰 시장을 포기하는 것이다. 구글 지메일의 경우 파일 첨부 기능에서 파일 드래그앤드롭 기능을 선택적으로 적용하고 있다. 해당 기능이 지원되는 환경에서는 데스크톱에 있는 파일을 가져다놓을 수 있는 기능을 제공하고 그렇지 않다면 기본 HTML 파일 업로드 기능을 활용한다. 이렇게 상황에 따라 적용된 기술은 사용자가 인식하지 못할 정도로 자연스럽게 기능을 축소하면서 서비스를 제공하고 있다.
기존 RIA 기술을 가진 업체들은 HTML 5 기술을 어떻게 통합할지 고민하고 있다. 특히 기업용 RIA 제품군에서 상대적으로 약점이었던 미디어 서비스와 같은 기능을 받아들이면서 서비스 영역을 확대할 수 있는 기회로 삼기 위한 준비를 하고 있다.
비싼 돈 주고 UX 컨설팅을 받았는데?
여전히 많은 오해는 UX와 디자인을 동일시하는 것이다. 이런 오해는 시장을 잘못 이해하게 만들고 UX 컨설팅의 필요성을 받아들이기 어렵게 만든다. 처음에 보이는 결과 이미지가 좋아 보인다고 해서 사용자가 원하는 것을 만족시켜주는 것은 아니다. 요구사항을 제대로 끌어내지 못한다면 초기 디자인 과정을 전부 무시하고 처음부터 다시 만들게 될 수도 있으며 이에 대한 부담은 프로젝트 팀에서 부담하게 된다.
적절한 UX 컨설팅 프로세스를 도입하는 것은 아까운 비용을 날리는 것이 아니라 장기적으로 보았을 때에는 비용을 절감하는 효과를 만들어낼 수 있다. 기업 내 업무 시스템이라면 이러한 비용 효과는 더 커질 수 있다.
RIA 기술을 도입한다면 다른 UX 프로세스보다 좀 더 엔지니어링과 제품 개발 영역과 커뮤니케이션이 긴밀해야 한다. 다양한 경험을 필요로 하며 개발 프로세스를 이해하고 어떤 서비스를 제공할 수 있는지 사용자가 어느 수준부터 접근해야 하는지 판단할 수 있어야 한다.
외부에 용역을 의뢰해야 한다면 컨설팅을 담당하는 업체가 선택할 기술을 명확하게 이해하고 있는지 확인해야 한다. 사용자에 대한 분석이 적절하게 이루어졌어도 그에 맞는 기술에 대한 방향성을 제시하지 못한다면 비용이 중복되게 투자될 수도 있다. 모바일에서는 이러한 기술적인 선택이 좀 더 어려울 수 있다. 1년에도 수차례 주변상황이 변하기 때문에 프로젝트 기간과 규모를 적절하게 조정할 수 있게 제안하는 것이 필요할 것이다. 화려한 포트폴리오만으로 선택하기보다는 해당 업무와 프로세스를 적절히 이해하고 있는지 확인해보아야 한다.
각 원칙은 애플리케이션에 직접 적용해도 무리가 없다.
기업에서는 애니메이션은 필요 없다
어도비 플렉스가 처음 등장했을 때 기존 콘텐츠와 차별성을 가질 수 있었던 여러 가지 점이 있었지만 그 중 하나가 애니메이션 효과였다. 기본 태생이 플래시였기 때문에 이미 가지고 있는 라이브러리 중 일부를 잘 정리해서 서비스에 반영할 수 있도록 API를 제공해주었고 초기 도입 시 경쟁력을 가질 수 있었다. 하지만 점점 애니메이션 효과는 개발 프로젝트의 발목을 잡기 시작했다. 경쟁 입찰 단계에서 무리한 제안이나 클라이언트의 요구사항은 애플리케이션에서 애니메이션 효과를 적용하는 목적을 잃어버리게 했다.
업무에 적용하는 애플리케이션의 애니메이션 효과는 프레젠테이션 자료를 만들 때 애니메이션을 활용하는 원칙에서 크게 벗어나지 않는다. 파워포인트 블루스(2009, 한빛미디어)의 저자인 김용석은 다음과 같은 3가지 원칙을 제시하고 있다.
1. 쉬운 이해 : 더 쉬운 이해를 돕는가?
2. 메시지 증폭 : 전달하는 메시지를 더 강조하는가?
3. 주의 집중 : 청중들이 집중할 수 있도록 만드는가?
각 원칙은 애플리케이션에 직접 적용해도 무리가 없다.
(그림 4. 투비소프트 엑스플랫폼 애니메이션 에디터)
첫 번째 쉬운 이해의 대표적인 사례는 맥에서 볼 수 있는 지니 효과를 이야기할 수 있다. 마치 알라딘의 요술램프에 나오는 요정인 지니가 램프 속으로 사라지는 콘셉트를 활용해서 윈도우가 사라지거나 파일이 삭제되는 효과를 처리하고 있다. 애플리케이션에서 어떤 일이 일어나는지에 쉽게 이해할 수 있도록 피드백을 주는 것은 매우 중요하다. 트리 구조에서 파일을 드래그해서 옮길 때 어느 위치에 어떤 식으로 들어갈지를 미리 보여주는 애니메이션은 사용자의 행위가 어떤 결과를 만들어낼지 쉽게 이해하게 만든다.
두 번째 메시지 증폭은 실시간 감시 시스템과 같은 경우 문제가 있는 요소를 쉽게 인지할 수 있도록 애니메이션 효과를 사용하기도 한다. 화면 하단에 흘러가는 뉴스 티커와 같은 컴포넌트도 애니메이션 효과를 활용하기도 한다.
세 번째 주의 집중은 사용자의 실수를 최소화하고 중요한 데이터를 강조해주는 기능을 제공한다.
애니메이션 적용에 있어서 얼마나 쉽게 구현이 가능하고 표준화된 방법으로 배포가 가능한지도 중요한 요소가 된다. 그리고 특정 정보를 애니메이션 효과만으로 전달해서는 안된다. 이후 접근성 구현에서 충돌이 생길 수도 있고 애니메이션 효과가 1회로 한정될 경우 전달하고자 했던 정보 자체가 전달되지 못할 수도 있다.
파워포인트는 청중의 공감을 이끌어내는 것이지만 애플리케이션에서의 애니메이션은 사용자가 적절하게 반응할 수 있게 하려는 것이다. 화려한 UI만을 고집하는 곳이 있다면 전문적인 애니메이션 저작 도구를 다룰 수 있는 팀을 소개해주는 것이 좋을 것이다.
접근성
웹접근성에 있어서 RIA는 항상 적대적인 입장이었다. 텍스트 기반의 웹은 어느 정도 사후 수정이 용이한 반면 RIA 애플리케이션은 디자인 단계에서 접근성을 고려하지 않았다면 오히려 다시 만드는 것이 나을 정도로 초기 설계에서부터 준비가 필요하다. 시각 장애를 가진 사용자가 접근 가능한지를 확인해보려면 키보드로 각 항목에 접근할 수 있는지 먼저 확인해보아야 한다. 한 화면에 여러 개의 탭으로 기능을 세분화해서 분리했다면 원하는 항목으로 바로 이동할 수 있는 단축키 메뉴를 제공해주어야 하고 각 메뉴 사이를 이동하는데 불편함이 없어야 한다.
풍부한 기능을 가지고 있는 컴포넌트는 사용하기 쉬운 장점이 있지만 자칫 잘못 설계하는 경우 접근성에 있어서는 블랙홀과 같은 공간이 될 수 있다. 대표적인 경우가 달력이다. 기존 웹에서도 날짜 입력의 편의를 위해 달력에서 날짜를 선택하는 기능을 제공하고 있는데 키보드만으로 실제 날짜를 선택할 수 있도록 구현된 경우를 찾아보기 힘들다. NHN에서 운영하는 웹 표준 개발 가이드 NULI에 공유된 ‘캘린더의 접근성 높이기’라는 글을 보면 똑같아 보이는 달력을 접근성 있게 구현하려고 얼마나 고민해야 하는지 엿볼 수 있다.
(그림 5. NULI 캘린더 접근성 사례 – button으로 구현)
화면 낭독기를 사용하는 경우 관련 이벤트를 받아 해당 소프트웨어로 전달해주게 되는데 동적인 화면 처리를 구현하는 경우에는 이벤트의 전달이 복잡하게 엮이는 경우가 있어 이벤트 처리를 적절히 제어해주어야 한다. 만들어진 화면이 스마트하게 조정되어 제공된다면 좋겠지만 이런 세부적인 처리는 생각보다 어려울 수 있다. 달력이나 그리드와 같은 컴포넌트도 어떤 식으로 접근할지 어느 수준까지 구현할지를 선택해야 한다. 모든 기능을 다 구현하는 것보다는 사용자와의 충분한 커뮤니케이션을 바탕으로 프로세스를 만들어가는 것이 필요하다. 이론과 실제는 분명히 다르다.
다시 강조하지만 접근성에 대한 구현은 선택적이라는 것이다. 일반 웹 코딩과는 달리 대부분의 경우 기본 설정은 접근성 관련 이벤트를 처리하지 않도록 되어 있다. 그렇다고 해서 해당 속성 값만 true로 바꾸어주면 끝나는 것이 아니라 전체적인 프로세스를 관리해야 한다는 것을 명심해야 한다.
웹이 점점 스마트해진다고 하지만 그 뒤에는 여전히 많은 개발자들의 손길이 필요하다는 것을 잊지 말자.
참고자료
1. Rich Internet application - 위키피디아
2. KISA 웹 기술지원센터
3. build 컨퍼런스 공식 사이트
4. Adobe Edge Preview
5. SlickGrid
6. 캘린더의 접근성 높이기 - NULI
728x90
