프로그래머를 위한 사용자 인터페이스 설계론 제2부: 사용자는 무엇을 기대하는가?

글 : Joel Spolsky
번역 : AhnLab
년 4월 11일 화요일

어떤 사용자가 어떤 프로그램을 처음 사용한다고 할 때, 그 프로그램에 대해 완전히 백지 상태로 접근하는 것은 아니다. 그들은 그 프로그램이 어떤 방식으로 작동될 것인가에 대해 자기 나름대로의 기대를 갖는다. 만일 예전에 비슷한 소프트웨어를 사용해본 적이 있다면 그것과 비슷한 방식으로 작동되리라 예상할 것이다. 만일 그 이전에 어떤 소프트웨어도 사용해본 적이 없다면 그 프로그램이 일정한 보편적 규칙에 따라 움직이리라 예상하게 될 것이다. UI가 어떻게 움직일 것인가에 대한 사용자들의 예측이 적중할 수도 있다. 이와 같이 어떤 프로그램이 자신에게 무엇을 해줄 것인가에 대한 사용자의 심리적 이해를 가리켜 사용자모델이라 한다.

프로그램에게도 “심리적 모델”은 있다. 다만, 이것은 비트 단위의 코딩으로 구현되며, CPU에 의해 집행된다. 이를 가리켜 프로그램모델이라 한다. 여기서 법칙이 등장한다. 즉, 제 1부에서 배운 대원칙에 따르면, 프로그램 모델이 사용자 모델과 일치할 때 그 사용자 인터페이스는 성공적이라 말할 수 있다.

사례를 들어보자. 마이크로소프트 워드 프로그램에서 (그 외의 대부분의 워드 프로그램에서도), 사용자가 워드 문서에 그림을 삽입하는 경우 이 그림은 해당 문서 파일에 직접 내장된다. 즉, 사용자가 그림을 만든 다음 이것을 문서에 붙여넣고 원래의그림파일을삭제하더라도 워드 문서에는 여전히 그 그림이 남아있는 것이다.

하지만, HTML의 경우에는 이야기가 달라진다. HTML 문서에서는 이 그림을 별도의 파일에 저장해 두어야만 한다. 워드프로세서를 사용하는 데에는 익숙하지만 HTML에 대해서는 아는 것이 없는 사용자를 데려다가 FrontPage 같은 WYSIWYG HTML 에디터 앞에 앉혀놓으면, 이들은 아마 그림이 파일 내에 저장된다고 생각하게 될 것이다. 이런 현상을 사용자모델관성이라고 하자.

여기서 사용자 모델 (그림이 파일에 내장될 것이다)과 프로그램 모델 (그림은 별도의 파일에 저장되어야 한다)이 서로 충돌하게 되며, UI는 문제를 야기하게 된다.

FrontPage 같은 프로그램을 설계하고 있는 프로그래머라면, 이미 첫번째 UI 문제를 발견했을 것이다. 프로그래머가 HTML을 바꿀 수는 없다. 그러므로, 프로그램 모델을 사용자 모델과 일치시킬 무언가가 필요한 것이다.

프로그래머가 여기서 선택할 수 있는 옵션은 두 가지다. 그 하나는 사용자 모델을 바꾸기 위해 노력하는 것이다. 하지만 이것은 매우 어려운 일이다. 매뉴얼을 통해 사용자에게 그림을 별도로 저장해야 한다는 사실을 설명할 수도 있다. 그러나, 사용자들은 매뉴얼을 읽지 않으며 또, 매뉴얼을 읽어야 할 의무도 없다는 것은 누구나 다 아는 사실이다. 그렇다면, 매뉴얼 대신 대화상자를 화면에 띄워서 그림 파일이 내장되지 않는다는 사실을 일러줄 수도 있다. 하지만, 이 경우에도 역시 문제점이 두가지 있다. 숙달된 고급 사용자에게는 이 대화상자가 방해만 될 것이라는 점과 사용자들은 대화상자도 제대로 읽지 않는다는 점이 그것이다 (이런 문제에 대해서는 6부에서 자세히 이야기하기로 하자). 

자, 정녕 저 산이 마호메트에게 오려 하지 않는다면... 이제 남은 옵션은 사용자 모델 대신 프로그램 모델을 바꾸는 것이다. 가령, 사용자가 그림을 문서에 삽입할 때 문서 파일 하의 서브디렉토리에 이 그림의 사본이 저장되도록 프로그래밍 하는 것이다. 이 경우, 적어도 그림을 복사했다는 사용자의 인식은 충족시킬 수 있다 (그리고 나서 원본 그림은 안전하게 삭제할 수 있다).

사용자모델을파악할수있는방법은무엇인가?

답은 의외로 단순하다. 그냥 사용자들한테 물어보면 된다! 직장 동료나 친구, 혹은 가족들 중에서 임의로 다섯 명만 골라서 여러분의 프로그램에 대해 간단히 이야기하라 (“이건 웹 페이지 저작 프로그램이야”). 그런 다음, 다음과 같은 상황을 설명하라. “넌 지금 웹 페이지를 만들고 있고, 여기 Picture.JPG라는 이름의 그림 파일이 하나 있어. 넌 이 그림을 웹 페이지에 삽입할 거야.” 그리고 나서, 이렇게 물어보라. “그럼, 이 그림은 어디에 있을까? 네가 Picture.JPG 파일을 삭제해도 그 웹 페이지엔 그림이 그대로 남아있을까?” 이런 과정을 통해 그들의 사용자 모델을 짐작할 수 있다.

필자의 친구 중에 포토앨범 애플리케이션을 개발중인 프로그래머가 있다. 사용자가 사진을 삽입하면, 이 애플리케이션은 각각의 사진을 조그맣게 축소한 이미지인 썸네일(thumbnail)을 보여준다. 사진이 많아질 경우, 이 썸네일을 생성하는 데에만도 상당한 시간이 소요되기 때문에 필자의 친구는 썸네일을 하드드라이브의 어딘가에 저장해두려 한다. 이렇게 하면 썸네일을 한번만 생성하면 되기 때문이다. 여기서 이 친구가 선택할 수 있는 옵션은 여러 가지가 있다. 모든 썸네일은 Thumbnails라는 이름의 커다란 파일 하나에 저장해둘 수도 있고, 각각을 별도의 파일에 저장한 후 Thumbnails라는 서브디렉토리에 모아둘 수도 있다. 또는, 사용자들이 그 존재를 알지 못하도록 썸네일 파일을 숨은 파일로 만들어 운영체제 속에 감춰둘 수도 있다. 필자의 친구는 스스로 최선의 방법이라고 생각되는 옵션을 선택했다. 즉, 사진 파일의 이름이 picture.JPG인 경우 이 사진에 대한 썸네일을 picture_t.JPG라는 파일로 저장한 후, 각각의 파일들을 같은 디렉토리에 모아두는 것이다. 가령, 30장의 사진으로 앨범을 만드는 경우, 이 디렉토리 안에는 썸네일까지 포함해 총 60개의 파일이 들어있게 되는 것이다.

물론, 다양한 그림 저장 옵션들을 놓고 각각의 장단점에 관해 프로그래머들끼리 몇 주일씩 논쟁을 벌일 수도 있다. 하지만, 이미 확인된 바와 같이 보다 과학적인 해결 방법이 있다. 여러 명의 사용자들에게 썸네일이 어디에 저장되어 있을 것 같은가를 물어보는 것이다. 물론, 그들 중에는 모르겠다거나 관심 없다고 답하는 사람도 있을 테고 아예 생각도 해보려 들지 않는 사람들도 있을 것이다. 하지만, 많은 사람들한테 묻다 보면, 일정한 합의를 도출할 수 있게 될 것이다. 가장 많은 사람들이 선택한 저장 방법이 가장 좋은 사용자 모델이며, 이 사용자 모델에 프로그램 모델을 일치시킬 것인지 여부는 전적으로 프로그래머의 판단에 달려 있다.

이제, 여러분의 이론을 시험해볼 차례다. 여러분이 설계한 사용자 인터페이스에 대한 모델 또는 프로토타입을 만든 다음, 사람들에게 이것을 이용하여 일정한 과제를 수행하도록 주문해 보라. 사용자들이 주어진 과제를 수행하는 동안, 그들에게 무엇을 예상하고 있는지 물어보라. 목표는 그들이 기대하는 것이 무엇인가를 파악하는 것이다. 가령, 주어진 과제가 “그림 삽입”이라고 하자. 만일 마우스를 이용하여 그림을 이 프로그램으로 끌어오려고 애쓰는 사용자가 있다면, 여러분은 ‘드래그 앤 드롭’ 기능을 지원하는 것이 좋겠다고 깨닫게 될 것이다. 만일 ‘삽입’ 메뉴를 찾는 사용자가 있다면, 여러분은 삽입 메뉴에 ‘그림 선택’ 기능을 포함시켜야 한다는 사실을 깨닫게 될 것이다. 혹시라도 툴바의 ‘글꼴’ 선택 창에서 “Times New Roman” 대신 “그림 삽입”이라는 말을 입력하려 하는 사람이 있다면, 여러분은 아직까지 GUI라는 것을 한번도 써본 적이 없어서 명령라인 인터페이스를 기대하고 있는 원시인을 보고 있는 것이다.

사용자 인터페이스를 테스트해보는 데 얼마나 많은 사용자가 필요할까? 프로그래머들은 직관적으로 “다다익선”이라고 답할지도 모른다. 과학적 실험이라는 측면에서는 맞는 이야기니까. 하지만, 그 직관은 맞지 않다. 사용성 평가를 전문으로 하는 사람들은 거의 모두 대여섯 명 정도의 사용자면 충분하다고 생각하는 것 같다. 대여섯 명이 넘게 되면 그 이후에는 거의 비슷비슷한 결과들을 보게 되며, 더 이상 사용자를 추가하는 것은 시간 낭비일 뿐이다.

그렇다고, 사용성 평가 전문기관에 테스트를 의뢰하거나 시험에 참여할 사람들을 “거리에서” 뽑아와야 할 필요는 없다. 단돈 “50센트”로 사용성 평가가 가능하기 때문이다. 즉, 그냥 옆에 있는 사람을 붙잡고 간단한 사용성 평가를 부탁하면 되는 것이다. 단, 미리 모범 답안을 유출하는 일이 없도록 주의한다. 그저 “자유롭게 사고”하도록 부탁한 후, 다양한 질문을 통해 그들의 사용자 모델을 파악하도록 노력하는 것이다.

지금작업중인프로그램모델은사용자모델과일치하는가?

필자가 여섯 살 때, 아버지가 포켓형 전자 계산기의 초기 모델 중 하나인 HP-35를 집에 가지고 오신 적이 있었다. 아버지는 그 속에 컴퓨터가 들어있다고 말씀하셨지만, 필자로서는 그 말을 믿을 수가 없었다. 영화 ‘스타 트렉’에 나오는 컴퓨터들은 전부 방 한 칸을 차지할 만큼 어마어마하게 크고 커다란 릴 테이프 기록장치가 달려있었기 때문이다. 그 당시 필자는 그 전자 계산기의 숫자판에 있는 각각의 숫자키가 LED 표시부의 점 하나하나와 교묘하게 연결되어 있고 우연치 않게 수학적으로도 맞는 답을 보여주는 것뿐이라고 생각했다. (겨우 여섯 살이었다니까).

중요한 사실은 사용자 모델이라는 것이 그다지 복잡하질 않다는 점이다. 이 프로그램이 어떻게 움직일 것인가를 추측할 때, 사람들은 정교하고 복잡한 것을 생각해내는 것이 아니라 그저 단순하게 추측하는 경향이 있다. 

매킨토시 앞에 앉아보자. 엑셀 스프레드시트 파일을 두 개 열고, 워드 문서 파일을 하나 열었다. 매킨토시를 처음 써보는 사용자라면 대부분 이 세 개의 창들이 따로따로 독립되어 있다고 추측할 것이다. 분명히 그렇게 보이니까.

여기서 사용자 모델은 1번 스프레드시트를 클릭하면 이 창이 맨 위로 나올 것이라고 기대하는 것이다. 그런데, 실제로는 2번 스프레드시트가 맨 위로 올라온다. 대부분의 사용자가 당황하게 될 것이다.

이에 대해서 마이크로소프트 엑셀의 프로그램 모델은 이렇게 말한다. “각 애플리케이션마다 하나씩 보이지 않는 시트가 있고, 각각의 창은 이 보이지 않는 시트 위에 ‘붙어 있다’. 사용자가 엑셀을 맨 위로 불러내면, 다른 엑셀 창까지 위로 올라오게 된다.”

맞는 말이긴 하다. 보이지 않는 시트라니. 사용자 모델에 보이지 않는 시트라는 개념이 포함되어 있는 확률이 얼마나 될까? 아마 거의 영에 가까울 것이다. 때문에, 초보 사용자는 이 같은 결과에 놀라게 되는 것이다.

또 다른 예로, 마이크로소프트 윈도우 시스템에서 “창 바꾸기”에 사용되는 Alt+Tab 키 조합의 경우를 살펴보자. 대부분의 사용자들은 단순하게 이 기능이 열려있는 모든 창을 교대로 보여준다고 생각한다. 가령, A와 B와 C라는 창이 열려있고 현재 A창이 활성화되어 있는 상태에서 Alt+Tab을 누르면 화면이 B로 바뀐다. 대부분의 사용자들은 여기서 다시 Alt+Tab을 누르면 화면이 C로 바뀔 것이라고 생각한다. 하지만, 실제로는 Alt+Tab을 두 번 누르면 화면이 다시 A로 되돌아온다. 화면을 C로 바꾸기 위해서는 Alt 키를 누른상태에서 Tab 키를 두번 눌러줘야 한다. 이것이 두 개의 애플리케이션 사이를 교대로 오고 가며 작업하기에 편리한 방법이긴 하지만, 대부분의 사람들은 여기까지는 미처 생각하지 못한다. 열려 있는 모든 창을 교대로 하나씩 보여주는 모델보다 다소 복잡하기 때문이다.

프로그램 모델을 사용자 모델에 일치시키는 것은 모델이 아무리 단순하더라도 결코 쉽지 않다. 모델이 복잡해지면 더더욱 어려워진다. 그러니까, 가능한 한 가장 단순한 모델을 선택하라!