본 내용은 'Ajax in Aaction'(에이콘)이란 책의 Chapter 6에 해당하는 '편의성을 고려한 인터페이스' 부분에서 발췌한 내용을 기반으로 정리해 놓은 것입니다.
개요
웹 사이트의 특성상 접속자는 사용자가 엄청나게 많고 변동이 크기 때문에 Ajax 관점에서도 유저빌리티는 굉장히 중요한 주제이다. 애플리케이션을 즉시 다운로드받아 실행해볼 수 있다는 장점을 거꾸로 생각해보면 사용자가 시간이나 노력을 거의 투자할 필요가 없다는 점을 알 수 있는데, 사용자는 투자한 노력이 없기 때문에 구글에서 검색할 수 있는 80억 개의 다른 페이지로 언제든지 옮겨갈 수 있다는 문제가 있다. Ajax 애플리케이션이 기존의 데스크탑 애플리케이션과 일반적인 웹 페이지의 장점을 융합하고 있다는 관점에서, 좀더 복잡한 문제도 생각해 볼 수 있다. 두가지의 애플리케이션 실행 방법을 섞어낸다는 것은 상당히 모험스러운 일이 분명하고, 좋은 방향으로 적당히 장점을 섞어내지 못한다면 열심히 개발한 노력이 수포로 돌아갈 수도 있다.
...중략... 사용자가 애플리케이션에서 원하는 게 무엇인가? 사용자는 애플리케이션으로 무슨 일을 하려 하는가? 이제 '유저빌리티라는 부분을 충족시키려면 어떤 방법으로 개발해야 하는가'로 질문을 살짝 바꿔보자. 여기를 시작점으로 본다면, 실제로 어떤 작업을 진행해야 Ajax 애플리케이션이 업무 효과를 내도록 만들 수 있는지 찾아볼 수 있다. ...중략... - p247
반응성
일반적인 컴퓨터 사용자가 느끼는 가장 어려운 부분은 컴퓨터가 시간이 많이 걸리는 작업을 처리하는 동안 사람의 업무 흐름이 깨어진다는 점이다. 대량의 영화 파일을 디스크에 써넣는 것과 같이 많은 시간이 필요한 작업을 처리할 때 전체 사용자 인터페이스를 막아 버리는 것과 같이 설계가 잘못돼있다면 사용자가 처리하던 작업이 뭔지 잊어버릴 수도 있고, 사용자가 실제 자신의 업무에 집중하지 못하고 컴퓨터 하드웨어 자체의 한계를 느끼고 신경쓰이게 할 수도 있다.
반응성(responsiveness)을 확인하려면 애플리케이션의 사용자층과 일반적인 시스템 구성도 주의깊게 살펴봐야 한다. 영화 파일을 디스크에 써넣는 경우를 본다면, 로컬 하드웨어에서 7200RPM의 SATA(Serial ATA) 하드디스크를 사용하는 개발자라면 어느 정도 감당할만한 속도를 얻을 수 있겠지만, 사용자가 많은 네트웍 상에 공유된 디스크를 사용하거나 USB 메모리 등을 사용하는 사람은 만족스러운 속도를 얻지 못할 가능성이 높다. 웹 애플리케이션을 개발하는 입장에서 본다면 개인 PC에 웹 기본 환경을 갖추고 개발하는 경우가 많은데, 다시 말해 웹 서버와 웹 브라우저가 동일한 컴퓨터에서 작동하는 환경을 갖추는 경우가 대부분이다. 이런 환경이라면 네트웍이 갖는 속도 저하 문제를 제대로 느낄 수 없기 때문에 내부이건 외부이건 실제 네트웍을 사용하는 환경에서 사용자가 많들어내는 것과 비슷한 정도의 부하를 걸어 성능을 확인해야만 한다.
네트웍의 성능 문제를 제외하고도 클라이언트 프로그램 자체의 작동 성능도 반응성을 떨어뜨리는 큰 문제일 수 있다. ...중략... - p247
안정성
부하가 걸린 시스템에서 흔히 발생할 수 있는 여러 가지 상황에서도 적절히 동작해야 '안정적(rpbust)'인 애플리케이션이라고 할 수 있다. 실행하는 도중에 네트웍이 잠깐 끊긴다면 어떻게 될까? 잘못 작성된 프로그램이 5분간 CPU 자원을 모두 사용해버린다면 5분이 지난 다음 여러분의 애플리케이션이 정상적으로 작동할 수 있는지? 최근에 저자가 직접 참여했던 프로젝트에서 약 10초간 키보드를 마구 두드려보기도 하고, 웹 페이지 상에서 마우스를 무작위로 클릭하면서 여기저기 드래그하는 등의 테스트를 했던 경험이 있다. 이런 테스트는 어이없긴 하지만, 나름대로 효과를 볼 수 있었고 재미있기도 했다.!
이런 무작위 테스트를 거치면 어떤 문제가 나타날까? 예를 들어 이벤트 처리 부분의 프로그램에 문제가 있는지 확이할 수 잇다. 키보드를 누르고 마우스가 움직이는 것을 위시한 비슷한 기능의 처리 함수는 애플리케이션이 동작하는 동안 매우 많이 호출될 수 있기 때문에 처리 시간이 아주 짧아야 한다. 또한 컴포넌트 간에 의도하지 않았던 의존성이 있다는 문제점도 발견할 수 있다. 예를 들어 GUI상의 모달 대화상자가 전체 화면을 사용하지 못하게 막고 있는데, 열려있는 메뉴 때문에 모달 대화상자를 사용할 수 없는 경우도 있었다. 대화상자를 여는 시점과 메뉴를 여는 시점이 미묘하게 엉켜 이런 문제가 나타난다면, 일반 사용자가 일상적인 작업을 한다고 볼 때, 오픈한 지 두 달이 지난 다음에 이런 문제를 발견할 수도 있다. 하지만 일단 수천 명의 사용자를 대상으로 서비스하기 시작했다면 몇 시간 안에 문제점이 나타날 수 있고, 사용자가 제보한 내용만을 토대로 한다면 문제를 이해하고 재발현시키기가 엄청나게 어려울 수 있다 이처럼 문제점을 전면에 노출시키고, 수정하는 작업을 거쳐야 애플리케이션의 전체적인 안정성을 높일 수 있다.
애플리케이션의 안정성을 확보할 수 있는 테스트 방법으로 키보드를 마구 두드리는 것보다 좋은 방법이 있다. 개발자가 아닌 아무것도 모르는 일반 사용자가 애플리케이션을 사용하는 모습을 관찰하는 것이다. 개발된 애플리케이션을 처음 써보는 초보자라면 개발 단계에서 설계했던 사용자 인터페이스가 유저빌리티 관점에서 얼마나 효과가 있는지를 쉽게 알 수 있다. 반대로 해당 업무 분야나 애플리케이션에 정통한 전문가를 데려다 새로운기능을 사용해보게 하는 것도 유저빌리티를 확인하는 측변에서 큰 도움이 된다. 해당 애플리케이션의 코드를 직접 작성한 사람이 애플리케이션을 사용한다면, 그 개발자는 화면을 보면서 내부에서 돌아가는 코드를 알 수 있기 때문에 특정 상황에서 문제가 될 수 있는 입력 패턴을 무의식적으로 피해갈 수도 있다. 일반 사용자는 개발자가 가진 애플리케이션내부에 대한 지식이 없고, 개발자와 옆자리에 앉아 개발 과정을 볼 수 있는 것도 아니기 때문이다(짝 프로그래밍을 하지 않는 한 말이다). 제 3자를 불러다 애플리케이션을 실행해보도록 한다면 훨씬 안정적인 결과를 얻을 수 있다. - p248
일관성
이미 언급한 바와 같이 Ajax 애플리케이션의 유저빌리티에 대한 패턴은 데스크답 애플리케이션에서 사용하던 갖가지 내용부터 시작해 웹 브라우저에서 통용되는 것까지 계속해서 발전하고 있다. Bindows, qooxdoo, Backbase와 같은 Ajax 툴킷에는 데스크탑 애플리케이션의 버튼, 트리, 테이블 등을 비슷하게 구현한 위젯이 들어 있기도 하다.
이처럼 어려운 문제에 대한 올바른 답은 웹이 발전하는 과정에서 웹 마스터, 유저빌리티 전문가, 일반 사용자가 모두 조금씩 찾아가고 있다. 아무튼 그런 과정에서, 현재로써 가장 올바른 답은 모든 부분을 일관성 있게 만들라는 것이다. 여러분이 개발한 애플리케이션을 사용할 때 이쪽에서는 팝업창을 띄울 때 웹에서 하던 것과 같이 클릭을 한 번 해야 하고, 다른 기능이지만 비슷한 모양을 가진 아이콘을 사용할 때는 두 번 클릭해야 한다면, 사용자는 금세 혼란을 겪을 게 분명하다. '말하는 돼지'를 만들어 처음 접속한 사용자에게 사이트를 소개하도록 만들었다면, 사이트를 안내하는 도중에 말투나 의상, 헤어스타일 등은 바꾸지 않는게 좋다.
애플리케이션의 코드를 놓고 본다면, 일관성과 코드 재사용은 거의 같은 의미라고 봐도 좋다. 만약 버튼을 화면에 그려 넣는 코드를 재사용하지 않고 복사하기와 붙여넣기를 일삼았는데, 요구사항을 반영하느라 복사된 코드를 찾아다니며 변경된 내용을 고치다가 한군데라도 빼먹는 일이 생긴다면 여러분의 애플리케이션은 시간이 지날수록 일관성이 떨어질 수밖에 없다. 하지만 모든 사용자가 사용하는 부분의 버튼 코드를 한가지만 만들어두고 재사용한다면, 코드를 여러 번 변경하더라도 일관성을 높게 유지할 수 있다. 코드를 재사용할 때 얻을 수 있는 이런 장점은 사용자 인터페이스뿐만 아니라 화면에 보이지 않는 네트웍 시간초과 오류처리 부분이나 잘못된 결과를 처리하는 부분 등에서도 얼마든지 얻어낼 수 있다. - p249
간결성
이제 간결함의 중요성을 알아볼 차례다. Ajax 기법을 활용하는 웹 페이지에서는 지금까지 보지 못했던 공격적이면서도 창의적인 여러 가지 일을 할 수 있다. 지금까지는 화면에 정보가 딱 나타나는 것뿐이었기 때문에 이처럼 창의적인 내용을 표시할 수 없었다. 물론 창의적이고 공격적인 기능을 구현하지 않는 다른 이유도 생각해볼 수 있다. 화면에 튀어 들어와서 서서히 사라지는 스프링 메뉴를 예로 들면, 개발자에게도 재미있고 한두 번 접속하는 사용자라면 보기에도 재미있을 수 있다. 하지만 스프링 메뉴를 하루종일 사용해야 하는 사용자라면 통통 튀면서 사라지는 기능이 얼마나 짜증나는 일이겠는가?
새로 추가한 기능을 실제로 사용하는 사용자가 생산성이 좋아진다고 느끼는지를 항상 확인해야 한다. 그래도 Ajax를 활용할 때에는 생산성이 늘어나는 경우의 비율이 많으니, 개발자는 실제로 도움이 될 수 있는 기능을 만드는 데 좀더 집중할 수 있다. - p250
이 글은 스프링노트에서 작성되었습니다.