프로그래머를 위한 사용자 인터페이스 설계론 제5부: 일관성과 불규칙성(Hobgoblins)

글 : Joel Spolsky
번역 : AhnLab
2000년 4월 22일 토요일

마이크로소프트 오피스 슈트의 주요 프로그램인 워드 및 엑셀은 마이크로소프트사 내부에서 개발됐지만 다른 제품들은 다른 회사에서 구매한 것으로, 가장 잘 알려진 예가 FrontPage(Vermeer로부터 구입)와 Visio(Visio에서 구입)이다. 이 두 프로그램 사이에 공통점이 있을까? 두 가지 모두 마이크로소프트 오피스 응용프로그램처럼 보이고 느껴지도록 설계되었다는 점이다.

 

오피스 UI를 모방하기로 결정한 이유는 단순히 마이크로소프트에 “흡수”되기 위한 것이었거나 마이크로소프트사에 판매를 원했기 때문이 아니다. 실제로, FrontPage를 개발한 Charles Ferguson은 마이크로소프트사에 대한 반감을 주저하지 않고 털어놓았고 (자신의 회사를 Redmond Beasties에 팔기 전까지) 미 법무부에 Redmond Beasties에 대해 조치를 취해달라고 계속해서 항의했었다(회사를 판 후, 자신의 위치가 더 복잡해짐.) 사실, Vermeer나 Visio에서 오피스 UI를 모방한 주된 이유는 그러는 편이 훨씬 쉬웠기 때문인 것으로 보인다. 새로 개발하는 것보다 모방이 훨씬 용이하고 개발속도도 빨랐다.

 

마이크로소프트사 그룹 프로그램 매니저인 Mike Mathieu가 Vermeer사 웹사이트에서 FrontPage를 다운로드 받아서 사용해 본 결과, 자사 워드 프로그램처럼 작동한다는 것을 알게 되었다. 자신이 기대하는 방향으로 프로그램이 작동했기 때문에 사용이 더 용이했다. 그리고 이러한 용이성으로 인해 즉각적으로 그 프로그램에 대한 좋은 인상을 갖게 되었다.

 

어느 프로그램에 대해 마이크로소프트사에서 즉각적으로 좋은 인상을 갖게 되면, 그 프로그램의 판매가격은 150 만불 정도 된다. 여러분의 목표는 이보다 겸손할 수 있다. 여러분의 고객이 여러분의 제품에 좋은 인상을 갖게 되면 아마 $39 선에서 그 프로그램을 팔 수 있을 것이다. 하지만 기본적인 아이디어는 동일하다. 일관성으로 인해 용이성이 발생하고 이 용이성으로 인해 좋은 감정이 생기며 더 많은 수익의 결과를 가져다 준다.

 

사람들이 다양한 프로그램을 배우고 사용하는데 있어서 일관성이 얼마나 많은 도움을 주는지는 이루 말할 수 없다. GUI가 등장하기 전에는, 모든 프로그램마다 사용자 인터페이스의 기본틀을 다시 만들었다. 모든 프로그램에 필수적인 "exit"(종료) 같은 간단한 동작조차 완전히 비일관적이었다. 이 시절에는 사람들이 적어도 일반적인 프로그램의 종료 명령 정도는 외우고 있었기에 자신들이 이해하는 프로그램을 종료하고 실행할 수 있었다. vi 사용자들은 "C-x C-c" (Emacs에는 제어 문자를 나타내는데 있어서도 고유한 방법이 있다)를 암기한 반면, Emacs의 열렬한 팬들은 실수로 vi에서 빠져 나오지 못하는 경우에 대비해 ":q!"(이 외의 것은 아무 것도 외우지 않았음)를 암기했다. DOS 상에서는, Alt+Ctrl+F3의 기능이 무엇인지 상기 시켜주는 플라스틱 키보드 템플릿 중 하나를 가지고 있지 않는 한 WordPerfect 조차 사용할 수 없었다. 나는 DOS에서 빠져나올 수 있는 F7만 기억하고 있었다.

 

이러한 비일관성 외에도, 디폴트 입력 행위(덮어쓰기나 삽입)와 같은 사항에 있어서의 작은 일관성 또한 사용자의 신경을 날카롭게 할 수 있었다. 나는 윈도우 응용프로그램에서 Ctrl+Z는 "undo"(취소)를 의미한다는 사실에 너무 익숙한 나머지, Emacs 사용시 Ctrl+Z를 눌러 창을 최소화 하는 실수를 계속 반복한다. (재미있는 것은 Emacs에서 Ctrl+Z를 minimize(최소화)로 인식하는 그 이유가 우수한 사용자 인터페이스 csh(UNIX의 C 셀)의 ‘일관성’을 위함이라는 사실이다.) 이 현상은 즐겁지 않다는 일반적인 느낌에 누적되는 작은 좌절감 중의 하나이다.

 

더 작은 예를 들자면, Pico 및 Emacs 모두 라인 삭제 시 Ctrl+K를 사용하는데, 내가 Pico를 사용할 때마다 발견하게 되는, 보통 내 문서에 흠집을 내는 약간 다른 점이 둘 사이에 있다. 여러분 또한 자신만의 여러 가지 예가 있을 것이라 확신한다.

 

마이크로소프트 윈도우 이전 매킨토시 초창기에는, Apple사의 ‘전도자’들이 모두에게 말하길, 동일한 작업을 완료하는데 있어 일반적인 Mac 사용자가 일반적인 DOS 사용자 보다 더 다양한 프로그램을 사용한다고 했다. 정확한 숫자는 기억 못하지만, 일반적인 DOS 사용자의 경우 1 또는 2 개의 프로그램인 반면 일반적인 Mac 사용자의 경우 12 개의 프로그램인 것으로 기억한다. 그 이유는 Mac의 경우 서로 상이한 프로그램들도 일반적으로 동일한 방법으로 작동하는 관계로 새로운 프로그램을 배우기가 쉬웠기 때문이었다.

 

일관성이 우수한 UI 디자인의 기본원칙이지만, 이는 "프로그램 모델이 사용자 모델과 일치하도록 하기"라는 원칙에서 파생된 것에 불과한데, 그 이유는 사용자 모델은 사용자가 다른 프로그램의 작동에서 목격하는 방법을 반영하기 쉽기 때문이다. 문자를 더블 클릭하면 단어선택이라는 사실을 배운 경우, 그 사람들에게 전에 본 적이 없는 프로그램을 보여주면, 단어를 선택하려면 그 단어를 더블 클릭해야 한다고 추측할 것이다. 이런 경우 그 프로그램은 사용자가 단어를 더블클릭 했을 때(말하자면, 사전에서 단어를 찾아보는 대신에) 그 단어를 선택하는 것이 좋게 된다. 그렇지 않은 경우, 사용성 문제가 발생할 것이다.

 

일관성의 이점이 명백하다면, 왜 내가 거기에 대해 설명하려고 여러분과 나의 시간을 낭비하겠습니까? 불행히도, 일관성에 역하는 ‘암흑의 세력’이 존재하고 창조적이려고 노력하는 것이 설계자 및 프로그래머의 자연적인 경향이다.

 

“창조적이지 말라.”라고 말하는 사람 중의 하나가 되고 싶지 않지만, 불행히도, 사용자 인터페이스 사용을 용이하게 하려면, 창조력을 다른 분야로 돌려야 한다. 밑바닥에서부터 설계하기 전의 대부분의 UI 결정시, 다른 프로그램이 무슨 작업을 하는지 반드시 관찰해야 하며 그 프로그램 작업을 가능한 비슷하게 모방해야 한다. 일종의 문서 편집 프로그램을 만드는 경우, 마이크로소프트 워드처럼(공통적인 메뉴 항목 상의 accelerator처럼 세부사항까지) 보이는 것이 훨씬 좋다. 일부 사용자는 저장 기능으로서 Ctrl+S을 사용하는데 익숙해져 있으면 일부는 Alt+F, S를 그리고 다른 일부는Alt, F, S(Alt 키는 해제)를 사용하는데 익숙해져 있다. 어떤

사용자들은 프로그램의 좌측 상단에서 플로피 디스크를 찾을 것이다. 이 네 개의 경우 모두 작동돼야 한다. 그렇지 않으면, 사용자들이 원하지 않는 것을 경험하게 될 것이다.

 

나는 프로그래밍시 마이크로소프트사와 의식적으로 다르게 하는데 대해 임원들이 자부심을 갖는 회사를 본적이 있다. 그들은 "마이크로소프트사에서 한다고 해서 그것이 올바르다곤 할 수 없지.”라며 말하고 나서는, 사용자들이 익숙해져 있는 사용자 인터페이스와 불필요하게 다른 사용자 인터페이스를 만들려고 한다. "마이크로소프트사에서 한다고 해서 그것이 올바르다곤 할 수 없지.”라면서 맨트라를 노래하기 전에, 다음 두 가지를 고려해야 한다.

1. 비록 올바르지 않을 지라도, 마이크로소프트사에서 워드, 엑셀, 윈도우 및 인터넷 익스플로러 등과 같은 널리 쓰이는 프로그램에서 사용하게 되면, 수많은 사람들이 생각하길 마이크로소프트사에서 하는 일이 올바르다고 생각하거나 적어도 괜찮은 표준이라고 생각할 것이며, 여러분의 프로그램 역시 동일한 방법으로 작동할 것이라고 가정하게 된다. (넷스케이프 6.0 엔지니어들이 명백하게 주장했던 것처럼) 여러분이 Alt+Left는 "Back"에 대한 단축키로 적합하지 않다고 생각하더라도, 수백만 명의 사용자들이 뒤로 가기 위해 Alt+Left를 사용함에 불구하고 여러분이 빌 게이츠는 악마라는 일부 종교적 원칙을 바탕으로 이 키사용을 거절한다면, 여러분의 프로그램은 불필요하게 낙후되어 여러분 스스로는 잘났다고 자기 만족을 누릴 수 있을지는 몰라도, 사용자들은 여기에 대해 감사하지 않을 것이다.
2. 그리고 마이크로소프트사의 방식이 옳지 않다고 확신하면 안된다. 마이크로소프트사에서는 사용성 시험에 여러분 보다 더 많은 돈을 투자해서 수백만의 기술 지원 전화통화를 기반으로 한 세부 통계를 가지고 있으며, 어느 특정 방식을 채택했다면 그 이유는 단지 더 많은 사람들이 그런 방식 하에서 프로그램 사용법을 이해할 수 있었기 때문일 확률이 매우 높다.

유용한 사용자 인터페이스가 있는 양호한 프로그램을 개발하려면, 필요 없는 고집은 버려야 한다. 마이크로소프트사가 모방해야 하는 유일한 회사가 아닐 수도 있다. 온라인 서점을 제작하는 경우, 이 웹사이트가 Amazon의 웹사이트와 적어도 의미 상으로 동일한지 확인해야만 할 것이다. Amazon에서는 사용자의 카트를 90일 동안 보관한다. 이 카트를 24 시간 후 비우도록 설정하고서는 Amazon 보다 똑똑하다고 생각할 수도 있다. 하지만 이런 경우, Amazon 고객이었던 사람이 여러분의 쇼핑 카트에 쇼핑 품목을 담은 후 이주 후에 찾았을 때 여전히 카트에 있을 것이라 믿을 것이다. 만약 그 품목들이 사라진 것을 알게 되면, 여러분은 고객 한 명을 잃어버리게 되는 것이다.

 

그래픽 전문가를 위한 고기능(high-end) 사진 편집기를 만드는 경우, 사용자의 90% 이상이 Adobe Photoshop에 대해서 알 것으로 추측한다. 따라서, 여러분이 제작하는 프로그램과 Photoshop에 중복되는 분야에서는 Photoshop과 아주 비슷하게 만드는 것이 좋다. 그렇지 않으면, Photoshop 보다 사용이 쉽다고 아무리 여러분이 생각해도, 여러분의 프로그램이 사용자가 기대하는 식으로 작동하지 않기 때문에, 사용자들은 여러분의 프로그램은 사용이 어렵다고 말할 것이다.

 

윈도우에 설치된 일반적 제어를 다시 제작하려는 경향이 높다. 넷스케이프 6에 대해서는 말하고 싶지 않다. Borland's C++ 컴파일러도 컴파일된 프로그램은 구분할 수 있었던 적이 있는데 그 이유는 이 컴파일러는 커다란 녹색 체크박스가 있는 크고 굵은 OK 버튼을 사용했기 때문이다. 이는 Kai의 Photo Soap만큼 나쁘진 않았다.

 

 

좋다. 그래서, 아주 놀라울 정도로 멋있지만 라인이 그려진 O(실제로 "아니오"를 뜻함)는 나로 하여금 "OK"를 상기 시키고 윈도우 상에서는 OK가 왼쪽에 오는 것이 표준이기에, 나는 자주 잘못된 버튼을 누르곤 했다. "OK" 및 "Cancel" 대신에 다른 재미있는 기호의 사용으로 인한 유일한 이익은 다른 사람들처럼 여러분이 얼마나 창조적인가를 자랑할 수 있다는 점이다. Kai의 창조력으로 인해 사람들이 실수를 한다면, 글쎄, 예술가의 위치에 있으면서 감수해야 하는 손해라고 할 수 있다. ("dialog"에 있는 또 다른 문제는 화면 상에서 dialog 이동에 사용할 수 있는 표준 타이틀 바가 없다는 점이다. 따라서, dialog의 질문에 답하기 위해 보고 필요한 정보를 dialog에 가려지게 되는 경우, 짜증이 날 것이다.)

 

멋지고 근사한 사용자 인터페이스에서 얻을 수 있는 것이 많다. Kai처럼 좋은 그래픽 디자인은 보는 사람을 즐겁게 하고 사람들의 관심을 프로그램으로 끌게 될 것이다. 비결은 이 그래픽 디자인 시 규칙을 어기지 않는데 있다. Dialogs의 외관을 바꿀 수는 있지만 이 변화로 인해 기능이 저하돼서는 안된다.

 

Juno 초기 버전이 나왔을 때, 사용자 이름과 암호를 요구하는 표준 dialog가 있었다. 사용자 이름을 입력한 후, 암호 필드로 이동하기 위해 TAB을 눌러야 했고 그런 후 암호를 입력할 수 있었다.

 

이 사실이 Juno의 프로그래밍 관리자 중 한 관리자(윈도우 보다 UNIX에 경험이 많았던 이유로, 사용자 이름을 입력한 후, 암호 필드로 이동하기 위해 TAB 대신 ENTER를 누르는데 익숙해진)에게 혼란을 가져다 줬다. 비전문 윈도우 사용자를 목표로 하는 프로그램을 작성할 경우, UNIX 프로그래머는 일반적인 사용자에 대한 이상적인 예는 아닐 것이다. 하지만 이 관리자는 윈도우 표준인 “OK”를 사용하는 대신에 입력키를 통해 다음 필드로 이동해야 한다고 고집을 피웠다. "단지 마이크로소프트사에서 한다고 해서 그것이 올바르다는 법은 없지.” 하고 말했다.

 

그래서 프로그래머들은 정말로 놀랄 만큼의 많은 시간을 투자해 윈도우 디폴트를 대신할 엄청나게 복잡한 대화상자 처리코드를 프로그램했다(일관성이 없으면 당연히 필요 이상의 작업이 요구된다). 이 코드를 유지보수하는 작업은 악몽이었다. 코드를 16-비트에서32-비트 윈도우로 이동시 제대로 작동하지 않았다. 사용자들이 원하는 대로 작동하지 않았다. 신규 프로그래머들이 팀에 합류했을 때, 이 낯선 대화용 서브클래스가 있는 이유를 이해하지 못했다.

 

아주 많은 프로그래머들이 재구현 대상으로 마이크로소프트 오피스 팀이 가장 선호하는, 다양한 일반 윈도우 제어(버튼, 스크롤바, 도구모음 및 메뉴바)를 재구현하려고 노력해 왔다. 넷스케이프 6.0의 경우 이 재구현 작업의 정도가 지나쳐 단일 일반 윈도우 제어 전체를 재구현 했다. 이로 인해 예측하지 못한 악효과가 일어나기도 했다. 가장 좋은 예가 편집상자이다. 편집상자를 재구현하는 경우, 뭔지도 모르는 엄청나게 많은 유틸리티(중국어 편집 add-in 및 오른쪽에서 왼쪽으로 진행하는 문자를 지원하기 위한 쌍방향 원도우 버전 같은)가 있는데 이러한 유틸리티는 비표준 편집상자를 인식하지 못하는 관계로 제대로 작동하지 않게 된다. 넷스케이프 6.0 예비버전을 검토한 사람 중 일부는 비표준 넷스케이프 편집제어를 사용하는 URL 상자가 내용 메뉴를 열기 위한 오른쪽 마우스 버튼 클릭과 같은 일반 편집 기능을 지원하지 않는다는 사실을 발견했다.

 

일관성에 대해서 반마이크로소프트 원리주의자나 창의성 있는 그래픽 설계자와 논쟁하게 될 경우, 이 사람들은, Emerson의 인용을 엉뚱하게 할 것이다. "일관성은 작은 생각들이 모인 도깨비 같다..." 올바른 인용은 "어리석은 일관성은 작은 생각들이 모인 도깨비 같다." 우수한 UI 디자이너는 비록 자신들의 창조력을 발휘할 수는 없을지라도 일관성이 있는 설계를 해, 궁극적으로 사용자들을 즐겁게 한다.