프로그래머를 위한 사용자 인터페이스 설계론 제3부: 선택

글 : Joel Spolsky
번역 : AhnLab
2000년 4월 12일 수요일

어떤 레스토랑에 들어가다 입구에서 “애완견 출입 금지”라는 표지판을 봤다면, 여러분은 그저 이 문구가 금지의 뜻만 전하고 있다고 생각할지도 모른다. ‘아, 레스토랑 씨는 개를 별로 좋아하지 않나 보군. 그러니까 자기가 지은 레스토랑에는 개를 들이지 않겠다는 거겠지’ 라고 말이다.

만약 그것이 전부라면, 거기에는 “뱀 출입 금지”라는 문구도 붙어있어야 할 것이다. 뱀을 좋아하는 사람은 거의 없으니까. 또, “코끼리 출입 금지”라는 문구도 필요할 지 모른다. 코끼리들이 앉았다가는 레스토랑의 의자들이 하나도 남아 나지 않을 테니까.

거기에 그 표지판을 세운 진짜 이유는 과거의 경험을 바탕으로 한 것이다. 다시 말해, 레스토랑에 개를 데려 오는 사람들이 많았다는 역사적 사실을 보여주는 것이다.

대부분의 금지 문구는 사람들이 자꾸 X라는 행동을 반복하는 데 질려버린 시설물 소유자가 제발 그러지 말아달라고 요청하기 위해 붙여두는 것이다. 가령, 뉴헤이븐에 있는 ‘양키두들’처럼 사오십대 아줌마, 아저씨들이 주고객인 오래된 식당에 들어갔는데 벽면 여기저기에 “배낭을 카운터 위에 올려놓지 마시오.”라는 문구가 적힌 종이가 붙어있다면, 이는 사람들이 배낭을 카운터 위에 올려놓는 경우가 많았음을 보여주는 인류학적인 증거다. 이 문구가 적힌 종이들이 누렇게 바랜 상태로 미루어보아 대략 어느 시기쯤에 그 동네 학생들 사이에서 배낭이 유행했었는지를 추측할 수도 있다. 

때로는 그 시기를 추측하기 어려운 경우도 있다. “공원에 유리병을 반입하지 마시오”라는 푯말이 서 있다면, 이는 분명히 과거에 누군가가 맨발로 잔디밭을 걸어 다니다 깨진 유리 조각에 발을 다친 적이 있다는 이야기다. 물론, 시 당국을 상대로 관리 책임을 묻는 소송을 제기했을 테고.

소프트웨어 역시 이와 유사한 고고학적 기록이다. 그래서, 소프트웨어 프로그램을 일컬어 ‘옵션의 역사’라고도 한다. ‘도구’ 메뉴에서 ‘옵션’ 항목을 선택해 보라. ‘옵션’ 대화상자에는 소프트웨어 설계자들이 제품의 설계를 놓고 벌였던 무수한 논쟁의 역사가 고스란히 담겨 있다. 프로그램을 실행하면 최근에 작업하던 파일이 자동으로 열리도록 설정해야 할까? 맞아! 아니야! 논쟁은 두 주일 동안이나 이어지고, 다른 사람의 마음을 상하게 하면서까지 의사결정을 내리려는 사람은 아무도 없고, 프로그래머는 설계자들이 논쟁을 계속하는 동안 자기방어 차원에서 #ifdef만 입력한다. 결국, 그들은 이 기능을 하나의 옵션으로 제공하기로 결정한다.

논쟁이 꼭 두 사람 사이에서만 벌어지는 것은 아니다. 어떤 의사결정을 놓고 혼자 딜레마에 빠질 수도 있다. 가령, 데이터베이스를 속도를 기준으로 최적화해야 할지 크기를 기준으로 최적화해야 할지 도무지 판단이 서지 않을 수도 있다. 어느 쪽을 선택하든, 결국은 윈도우 운영체제 역사상 가장 바보 같은 “마법사” 대화상자를 만나게 될 것이다. 이 대화상자는 쓸모없는 대화상자한테 주는 상이 있다면 당당히 영예의 대상을 차지할만한 그런 멍청한 대화상자다. 사용자가 ‘도움말’에서 무언가를 찾고자 할 때 나타나는 대화상자가 바로 그것이다.

이 대화상자의 가장 큰 문제점은 오히려 사용자를 더 혼란스럽게 만든다는 점이다. 도움말 파일 안에서 도움말을 찾아야 하다니. 이 와중에 데이터베이스는 큰 것이 좋겠는지, 작은 것이 좋겠는지, 혹은 맞춤형 데이터베이스나 초콜릿을 입힌 데이터베이스가 좋겠는지 묻는 것이다. 그러는 동안 이 뻔뻔한 대화상자가 가르쳐주는 것이라고는 목록 (또는 데이터베이스)을 만들어야 한다는 사실뿐이다. 대화상자에 들어있는 문장들은 대부분 모호하고 혼란스럽다. 특히, “사용자의 도움말 파일(들)”이라는 표현은 그야말로 어설프기 짝이 없다. 물론, 도움말 파일은 하나일 수도 있고 둘 이상일 수도 있지. 하지만, 이 시점에서 파일이 한 개든 두 개든 도대체무슨상관이란말인가? 그것이 무슨 차이가 있는가 말이다. 하지만 이 대화상자를 만든 프로그래머는 도움말 파일이 하나가 아닐 수도 있다는 가능성 때문에 괴로워했음에 틀림없다. 만일 파일이 여러 개라면 그냥 도움말 파일이 아니라 도움말 파일들이라고 해야 옳지 않겠나?

도움말을 원하는 사람들이 이런 난해한 도움말을 이해할 수 있는 부류의 사람들이 아니라는 사실에 대해서는 더 자세히 이야기하지 않겠다. 아니, 인덱스 텍스트를 훤히 알고 있는 컴퓨터공학 박사 출신의 프로그래머라도 이 대화상자가 진정으로 사용자에게 선택하도록 요구하고 있는 것이 무엇인지를 파악하기는 쉽지 않을 것이다.  

더 기가 막히니 사실은 이 대화상자가 사실은 마법사라는 점이다 (그 다음 페이지에는, 알기 쉽게 설명하자면, “이런 쓸모없는 일에 기꺼이 시간을 할애해 주셔서 고맙다” 라는 취지의 문구까지 나온다). 분명한 것은 설계자도 어떤 선택이 최선인가에 대해 나름대로 뭔가 생각이 있었다는 사실이다. 다만, 한 가지 옵션을 권고하려다가 보니 문제가 복잡해졌던 것이다.

여기서, 사용자 인터페이스 설계에 관한 두 번째 규칙이 등장한다.

옵션을제공할때는전적으로사용자에게의사결정을위임하라.

사용자에게 의사결정을 내리도록 주문하는 것은 그자체로는 나쁜 일이 아니다. 선택의 자유란 달콤한 것이다. 사람들이 스타벅스의 에스프레소 음료를 즐기는 이유도 다양한 선택이 가능하기 때문이다. 휘핑 크림을 살짝 얹은 카페모카 발렌시아 큰 컵 하나요. 참, 아주 뜨겁게 해주세요!

문제는 사용자들과는 아무 상관도 없는 선택을 강요할 때 발생한다. 앞에서 예로 든 도움말 파일의 경우처럼, 사람들은 실제로 자신이 하고자 하는 작업을 진행하다가 난관에 부딪혔을 때 도움말 파일을 찾게 된다. 가령, 생일파티를 준비하다가 풍선에 그림을 거꾸로 인쇄하는 방법을 알 수가 없어 도움을 요청하는 것이다. 그런데, 성가시기 짝이 없는 마이크로소프트사의 도움말 인덱스 엔진 담당 프로그래머가 자신의 일의 중요성을 너무 과대평가한 나머지 뻔뻔스럽게도, 도움이 필요한 사용자를 붙들고는 목록 (또는, 데이터베이스)을 어떻게 만들 것인지 생각해 보라고 요구하는 것이다. 이런 선택은 사용자가 원래 하고자 했던 작업과는 아무 상관도 없는 일이며, 사용자는 당황해 하다가 끝내 화를 내게 될 뿐이다.

사용자들이 관심을 갖는 것은 대개 프로그래머들이 생각하는 것보다는 훨씬 사소한 것들이다. 그들은 어떤 작업을 수행하기 위해서 소프트웨어를 사용하는 것이며, 그 작업에 관련된 것에만 신경을 쓴다. 가령, 그래픽 프로그램을 사용하는 사용자라면 화소 하나하나를 가장 미세한 수준까지 제어하고 싶어할 것이다. 웹사이트 저작 툴을 사용하는 사용자라면, 자신이 원하는 모양과 똑같은 웹사이트를 만드는 일에 광분할 것이다.

사용자들은 프로그램의 툴바가 화면 상단에 있든 하단에 있든 그런 것에는 관심이 없다. 도움말 파일의 인덱스가 어떻게 구성되는가 따위의 문제에도 관심이 없다. 사용자들이 신경 쓰지 않는 이런 많은 것들에 대한 의사결정은 전적으로 설계자가 책임져야 한다. 사용자들이 자신과는 전혀 무관한 옵션들을 놓고 무엇을 선택해야 할 것인지 고민하는 일이 없도록. 그저 소프트웨어 설계자가 어떤 옵션이 정말로 더 나은 지를 충분히 생각해볼 여유가 없다는 이유만으로 이런 선택을 사용자에게 떠넘긴다면 그건 너무나 오만 방자한 처사다. (앞에서 예로 든 WinHelp의 경우처럼 사용자에게 어려운 선택을 떠맡기면서 이를 마법사 같은 것으로 적당히 위장해서 그 사실을 감추려 하는 것은 더 나쁜 일이다. 마치 사용자가 한번에 두 단계 이상의 선택은 제대로 소화할 수 없는 저능아라도 되는 것처럼 취급하면서 말이다.)

지금까지 설계는 선택의 예술이라는 점에 대해 이야기하였다. 하다못해 인도 위에 설치할 쓰레기통 하나를 디자인하는 데에도 여러 가지 상충하는 요소들을 놓고 선택하지 않으면 안 된다. 이를테면, 쓰레기통은 적당히 묵직해야 날아가버리는 일이 없다. 그런가 하면, 큼직해야 많은 쓰레기를 담을 수 있다. 하지만, 통행하는 사람들에게 불편을 주지 않으려면 크기가 작아야 한다. 설계자는 사용자에게 선택을 떠넘김으로써 자신의 책임에서 벗어나려 한다. 다른 누군가가 성가신 지시사항 없이도 똑같은 작업을 수행할 수 있게 해줄 보다 손쉬운 프로그램을 만들게 될 지도 모른다. 그러면, 사용자들은 모두 그 프로그램을 선택하게 될 것이다.

1990년 마이크로소프트 엑셀 3.0이 출시됐을 때, 그것은 ‘툴바’라는 기능을 제공하는 최초의 애플리케이션이었다. 툴바는 편리한 기능이었고 사람들의 반응도 좋았다. 그러자, 소프트웨어 업체들은 너나 할 것 없이 툴바를 흉내내기 시작했다. 지금은 툴바가 없는 애플리케이션은 찾아보기 힘들 정도다.

툴바가 대성공을 거두자 엑셀 팀은 특수한 버전의 엑셀 프로그램을 사용하여 현장 조사를 실시했다. 이 버전은 사용자가 가장 빈번하게 사용하는 명령이 무엇인지 모니터링한 후, 그 통계치를 마이크로소프트에 보고하도록 만들어진 프로그램이었다. 조사 결과를 바탕으로, 그 다음 엑셀 버전에는 사용자들이 가장 자주 사용하는 명령들로 구성된 또 한 줄의 툴바 버튼들이 추가되었다. 여기까지는 좋았다.

문제는 그 이후에도 툴바 설계 팀이 해체되지 않았다는 데 있다. 이들은 아름답게 물러나야 할 때가 언제인지를 몰랐던 모양이다. 이제, 툴바 설계 팀은 사용자정의가 가능한 맞춤형 툴바를 만들겠다고 나섰다. 또, 툴바를 화면의 상하 좌우 어디로든 끌어다 놓을 수 있도록 만들고 싶어했다. 급기야 그들은 메뉴바로 아이콘 대신 문자가 들어있는 툴바일 뿐이라며 메뉴바까지 화면 여기저기로 끌어다 놓을 수 있는 기능을 개발하기 시작했다. 이쯤되면 부작용도 맞춤형이 된다. 문제는 사용자들은 이런 기능에 관심이 없다는 사실이다. 필자는 지금까지 메뉴바가 화면 상단 외에 다른 위치에 있었으면 좋겠다는 사용자는 한번도 본 적이 없다. 그러나, 이런 웃지 못할 농담이 현실이 되었다. 가령, 사용자가 마우스로 ‘파일’ 메뉴를 연다는 것이 그만 실수로 메뉴바를 좌측으로 약간 끌어당겼다. 그러자, 메뉴바 전체가 통째로 딸려오더니만 전혀 엉뚱한 위치에 자리를 잡고 말았다. 문서 작성 공간을 차지해 버린 것이다.

이런 경험을 몇 번이나 해보셨는지? 처음 이런 일을 당하면, 사용자는 자신이 뭘 잘못했는지도 정확히 파악할 수 없고 이것을 어떻게 시정해야 할지도 알 수 없다. 이리하여, 아무도 원치 않는 (아니, 지구인의 0.1% 정도가 원하고, 나머지 모든 사람들한테는 방해만 되는) 메뉴바 이동 옵션이 등장하게 되는 것이다.

어느날, 필자는 한 친구로부터 도움을 청하는 전화를 받았다. 이메일을 쓰고 있던 중이었는데 갑자기 화면 반쪽이 회색으로 뒤덮여 버렸다는 것이었다. 

화면 반쪽이 회색이 됐다고?

필자는 전화기를 붙잡고 5분간을 고민한 끝에야 상황을 파악할 수 있었다. 필자의 친구가 실수로 윈도우 툴바를 화면 우측을 끌어당겼고 이 툴바의 크기가 가로로 확대되었던 것이다. 

이런 일을 일부러 할 사람은 아무도 없다. 그리고, 일반 컴퓨터 사용자들 중에는 이런 상황이 발생할 때 어떻게 이것을 시정해야 할 지 모르는 사람들이 적지 않다. 실수로 어떤 옵션을 ‘재구성’하게 되는 경우, 이 재구성을 어떻게 다시 재구성할 것인지 방법을 알지 못하는 것이다. 프로그램이 뭔가 이상해졌는데 별다른 해결방법을 알지 못하기 때문에, 어쩔 수 없이 프로그램을 삭제한 후 다시 설치하는 사람들이 의외로 많다. (그들은 프로그램 삭제 기능부터 익히게 된 것이다. 그것말고는 통제 불능의 맞춤형 기능을 원 상태로 복구할 방법이 없기 때문에).

물론, 이의를 제기하는 프로그래머들도 있을 것이다. “작업 환경을 자기 스타일에 맞게 조율하고 싶어하는 고급 사용자들에게는 이런 옵션들이 아주 중요합니다!” 사실, 이들이 생각하는 것만큼 중요한 것은 아니다. 예전에 필자가 Dvorak 자판을 사용해보려고 시도했던 적이 있었다. 문제는 필자가 사용하는 컴퓨터가 한 대가 아니라는 사실이었다. 필자는 다양한 기종의 컴퓨터를 사용하고 있고 다른 사람들의 컴퓨터도 자주 사용하며 꾸준히 쓰고 있는 컴퓨터만도 집과 사무실에 각각 세 대씩이나 된다. 또, 회사에 있는 테스트용 컴퓨터도 사용한다. 맞춤형 환경 설정의 문제는 한 대의 컴퓨터에 설정한 맞춤형 옵션이 다른 컴퓨터로 ‘전파’되질 않기 때문에 일일이 번거로운 설정 작업을 반복해야 한다는 것이다.

대부분의 고급 사용자들은 한꺼번에 여러 대의 컴퓨터를 사용하며 2, 3년마다 주기적으로 시스템을 업그레이드한다. 처음에는 워드 자판을 완전히 다시 매핑하고 모든 설정을 자기 기호에 맞게 변경하지만, 시스템을 한번 업그레이드하고 나면 모든 맞춤형 설정이 지워지기 때문에 그 이후로는 모든 설정을 일일이 재구성하는 수고를 그만두게 된다. 필자와 가까이 지내는 “파워 유저”들에게 물어봐도 시스템 합리화에 꼭 필요한 최소한의 설정 이외의 맞춤형 설정을 즐겨 이용하는 사람들은 거의 없다.

옵션을제공할때는전적으로사용자에게의사결정을위임하라. 이 말은 사용자가 무언가에 대해 생각하고 결정을 내려야 한다는 뜻이다. 기본적으로는 이는 나쁜 일이 아니다. 하지만, 사용자에게 요구되는 의사결정을 최소화하도록 노력해야 한다.

그렇다고 모든 선택의 기회를 박탈하라는 뜻은 아니다. 사용자들이 스스로 선택해야 할 사항들은 얼마든지 있기 때문이다. 자신이 작성중인 문서의 형식이나 자신이 만들고 있는 웹사이트의 작동 방식, 기타 사용자가 하고 있는 작업에 필수적인 요소들을 결정해야 한다. 이런 영역에서라면, 사용자들에게 최대한 많은 선택의 기회를 제공하라. 많으면 많을수록 즐겁다. 사람들이 좋아하는 또 다른 선택의 영역은 근본적인 작동 원리에는 영향을 미치지 않으면서 시각적인 모양들을 바꿔볼 수 있는 기능들이다. 누구나 WinAmp를 좋아하고 모두들 바탕화면에 그림을 바꿔넣는 것을 즐긴다. 이런 선택들은 기본적인 작동 방식은 그대로 두고 시각적인 효과만 즐길 수 있다는 점에서, 또한, 사용자가 아무때나 자신의 선택을 취소하더라도 사용자의 작업에는 아무런 영향을 미치지 않는다는 점에서 바람직한 옵션이라 할 수 있다.