티스토리 뷰
일단은 무척 재미없는 이야기를 해보려고 해요. 요즘 고등학생들은 어떨지 모르겠지만, 보통 고등학생때쯤 배우는 물리학에서는 열효율이라는 개념이 나와요. 열효율이라는 것은 말 그대로 효율성을 나타내는 공식이에요. 100의 연료를 넣었더니 80이 나왔더라. 그러면 효율성이 80%가 되는 것이지요. 100을 넣어서 120이 나오면 에너지 걱정도 없고 기름값 걱정도 없고 좋겠지만 세상에 버그가 나지 않는 이상은 그건 불가능하지요. 열효율은 100%가 최대이고, 그나마도 도달하는 것이 불가능해요.
요즘 대학생들은 어떨지 모르겠지만, 보통 대학교에서 잘 안가르쳐주는 HCI(Human Computer Interaction) 과목에서는 정보효율성(Information-theoretic efficiency)이라는 개념이 나와요. 솔직히 말하면 나올지 안 나올지 잘 모르겠어요. 저도 그냥 대학생이었고, 제가 다니던 학교에서는 HCI를 안 가르쳐줬거든요. 솔직히 가르쳐줬더라도 거기에 정보효율성이라는 개념이 나올 지는 잘 모르겠어요. 구글에서 검색해도 잘 안 나올만큼 마이너한 개념이거든요.
열 효율성은 투입한 자원 대비 얻은 에너지의 효율성을 말해요. 정보 효율성은 그럼 어떤 것의 효율성을 말하는 것일까요? 정보 효율성은 사용자가 제공해야 되는 정보량 대비 실제로 필요한 최소한의 정보량간의 효율성이에요. 정말 재미없는 이야기가 되어버렸네요. 종료하시겠습니까? 예. 아니요. 라는 창이 나오면, 시스템이 할 수 있는 동작은 종료하든지, 종료하지 않든지 두 가지에요. 그걸 결정하기 위해서 사용자에게 정보를 요청하지요. YES입니까? NO입니까? 1 또는 0. 1비트의 정보가 필요해요. 시스템이 필요한 정보량은 어떤가요? 안타깝게도 여기에는 복잡하지는 않지만 블로그에 쓰기에는 조금 난감한 수학공식이 필요해요. 각각의 동작이 시행될 확률을 p(i)라고 하면 모든 p(i)에 대해서 p(i)*log2(1/p(i))의 합이 필요한 정보량이 되는데, 계산과정 생략하고 결과적으로 말하면, 종료할 확률과 종료하지 않을 확률이 동일하면 필요한 정보량 역시 1비트가 되요. 1비트의 정보량이 필요할 때 1비트의 정보를 입력하니까 효율성은 1/1 = 1. 즉 100%가 되는 것이에요. 만약 사용자들이 평균적으로 종료할 확률이 70%이고, 종료하지 않을 확률이 30%라면 필요한 정보량은 평균적으로 0.88비트 정도가 되구요. 물론 1비트 이하의 정보를 전달하는 것은 어려우니 그저 말이 그렇다는 것이지요.
조금 더 복잡한 상황을 가정해볼께요. 워드프로세서로 문서를 만들다가 그냥 종료시켜버렸어요. 워드프로세서는 또 물어봐요. 어떻게 할까요? 저장하고 종료할까요? 저장하지 않고 그냥 종료할까요? 아니면 종료를 하지 말까요? 이걸 간단하게 '저장하고 종료할까요?'라고 물어보고 답변을 예, 아니요, 취소의 3가지로 주어서 결정하게 하지요. 마찬가지 공식으로 계산해보면 시스템에 필요한 정보량은, 1.584 비트가 되요. 눈치챌 수 있겠지만, 2의 1.584 제곱은 3이 되지요. 즉, 3가지 선택지를 가진 질문창은 1.584비트의 정보를 전달할 수 있고, 3가지 동작을 3가지 선택지로 하는 이 인터페이스는 효율성이 마찬가지로 100%에요.
그런데 이렇게 생각할 수 있어요. 사용자가 종료를 눌렀다는 것은 일단 저장을 하든 안하든 종료를 할 의도가 있다는 것인데, 종료를 하지 않고 돌아가는 '취소'버튼을 만든 것은 조금 비효율적이지 않을까? 그리고 이 비효율성도 계산을 할 수가 있어요. 평균적으로 사용자가 저장을 하고 종료할 확률이 40% 정도, 저장하지 않고 종료할 확률도 40% 정도, 저장하지 않고 종료도 안할 확률이 20% 정도라면 1.5219 비트의 정보가 필요하거든요. 따라서 이 인터페이스는 90% 정도의 효율성을 가지게 되지요. 만약에 취소할 확률이 10% 정도라면 효율성은 86%까지 떨어져요. 즉, 취소는 잘 하지도 않는데 취소 버튼을 넣어두는 것은 비효율적이라고 생각할 수 있다면, 그 취소를 잘 안하면 안 할수록 인터페이스는 정말 비효율적인 것이라고 강하게 주장할 수 있는 것이고, 이게 이론적으로 증명이 되는 것이지요. 정말 신기하지 않나요?
사실 정말 효율적인 인터페이스를 만들려면, 이런 식으로 구상할 수도 있겠지요. 종료를 하면 일단은 그냥 종료가 되어버리지만, 저장하지 않고 종료했을 때의 저장본과 저장하고 종료했을 때의 저장본을 모두 파일로 저장하는 것. 즉, 백업 파일을 만들어서 두 가지 경우를 모두 커버하는 방법이 있겠지요. 사용자의 입력이 없고, 두 가지 경우를 모두 만족시킬 수도 있기 때문에 꽤 효율적이라고 할 수 있을 것 같아요.
하지만 이론과 현실이 꼭 맞는 것은 아니에요. 실제로 사용하는 인터페이스는 꼭 효율성 100%를 따라가야되고, 단조성을 만족시켜야 되고, 모드를 유발하지 않아야 되고 그렇게 모든 원칙과 이론을 만족시키는 디자인을 만들어야 되는 것이 아니에요. 오히려 그게 더 불편할 수도 있어요. 백업본이 마구마구 생성되고, 그 중에서 내가 원하는 파일이 어떤 것인지 찾는 것 보다 그냥 좀 비효율적이더라도 (대부분 사용자들은 그게 효율적인지 비효율적인지도 잘 안 따져요) 예 아니요 취소 처럼 직관적인 선택지가 주어지는 것을 선호해요. UI와 UX의 차이가 여기에 있지만, 그건 이 글에서 중요한 것은 아니에요.
정말 극도로 효율적인 디자인이 가지는 문제는 두가지가 있지요. 사용자가 불편하고, 개발자가 불편해요. 사용자들은 생소하고 익숙하지 않고 동작이 어떻게 되는지 잘 모르니까 불편해요. 종료를 눌렀더니 파일 2개가 생기고 그대로 꺼져버리는 워드프로세서를 만난 사용자가 '와, 이 프로그램 정말 효율적인데?'라고 생각할까요? 아마 이걸 만든 사람들이 제정신인가..라는 생각을 먼저 하겠지요. 개발자도 마찬가지에요. 프롬프트에 버튼 3개 띄우고, YES이면 save 하고 quit. NO 이면 그냥 quit. CANCLE이면 return. 이런건 정말 일도 아니지요. 그런데 종료 이벤트가 호출되면 현재 파일이 이전 저장본과 비교해서 변했는지 안 변했는지 확인하고 변했으면 이전 저장본의 확장자를 .bak로 바꿔서 저장하고 현재 파일은 파일명을 유지하여서 저장하고. 그리고 종료를 시켜야되요. 사실 이전 저장본은 하드디스크에 현재 파일명으로 잡혀있고, 현재 편집된 분량은 메모리에 들어 있는 것이고, 그 둘의 파일명을 서로 교환한다는 것까지 고려해야 된다면 파일 핸들을 어떻게 넘기고 넘겨야 될지 난감해질 수 밖에 없어요. 그러니까. 하여튼. 백업 파일 만드는건 정말 짜증나는 일이라구요. 그러니까 그냥 효율성 생각 안하고 예 아니요 취소로 가는게 모두가 좋은 일이에요.
그러니까 왜 이런 재미없는 소리로 시작을 했냐면, 이 효율성 문제가 저를 위기로 몰아간 이야기를 하고 싶었거든요. SI프로젝트에서는 정보효율성 따지는 것이 정말 쓸모없는 노력이 되는 경우가 많아요. 일단 사용자들은 익숙한 디자인과 익숙한 동작을 원해요. 더군다나 SI 프로젝트에서는 사용자를 둘로 나눠서 생각해야 되거든요. 이왕 UI 이야기를 했으니까 UX 이야기도 섞어서, 페르소나를 만들어보자면 SI프로젝트에서 사용자는, 아주 크게 나누면 두 개의 페르소나를 만들 수 있어요. 하나는 '진짜 사용자'이구요. 그럼 가짜 사용자도 있냐구요? 비슷한게 있어요. 다른 하나는 '검수자'에요. 둘 다 사용자에 포함할 수 있어요. 프로젝트에서 나온 프로그램을 써보거든요. 다만 진짜 사용자는 프로그램을 진짜 그 목적에 맞게 사용하고, 검수자. 보통 고객이나 감리, 혹은 테스터라고 불리는 사람들은 프로그램이 그 목적에 맞게 동작하는지 확인하기 위해서 사용해봐요. 사용자에 따라서 요구하는 편의성의 레벨도 다르고, 그 레벨에 도달해야 되느냐 되지 않느냐도 달라요. 이런 상황에서 효율성을 주장하면서 독창적인 디자인을 하는 것은 정말 큰 모험이에요. 진짜 사용자들에게야 메뉴얼 잘 써주고 교육 잘 시켜주면 '이게 이런식으로 하면 정말 편해요.'라고 주장할 수 있을지 모르겠지만, 프로그램을 검수하는 사람들은 아주 잠깐 써보는 정도로 끝나거든요. 원하는 것 처럼 쉽게 동작하지 않으면 대번 퇴짜가 나와요. 그리고 참 불행하게도. 검수자들이 퇴짜를 놓으면 프로그램은 그 사람들이 원하는 방향으로 수정해야 되요. 안 그러면 통과가 안 되는걸요.
웹 어플리케이션을 한참 개발했어요. 사실 개발자들은 자기가 만든 어플리케이션을 정말 수도 없이 사용해봐요. 하나 만들때마다 테스트를 해보고, 버그를 잡고 그래야 되잖아요. 그렇게 수도 없이 실행해보고 만들고 실행해보면서 느꼈죠. 참 효율성 짜증날 정도로 낮구나. 그러니까 그건 자학 비슷한 것이었어요. 그 어플리케이션을 제가 디자인한 인터페이스를 가지고 있었으니까요. 깊이 고민하고 계산해볼 시간도 없었지만, 그냥 버튼을 누르면서도 직감적으로 느낄 수 있을만큼 효율적이지 못한 인터페이스를 가지고 있었거든요. 그리고 그건 어느정도는 사용자 편의성을 위해서 희생한 부분도 분명 있었어요. 그리고 대부분은 그냥 제 실력부족으로 낮아진 효율성이었어요. 분명 이게 여기서 실시간으로 갱신되어야 효율적인데, 버튼을 눌러서 결과를 받아오는 것은 정말 비효율적인데. 그런데 실시간으로 갱신을 시키려면 어떻게 해야 되지? 화면은...이렇게 하면 될 것 같기는 한데 해봐야 겠네. 그런데 서버쪽은 어떻게 해야되지? 매사가 이런 식이었어요. 그리고 거기에 신경쓰면서 하루나 이틀 정도를 투자할 여유가 없었으니까 그냥 효율성은 무시하고 버튼 눌러서 결과 받아오는 선택을 하게 되지요. 그런 것이 정말 한 두개가 아니었어요.
그래도 열심히 하다 보면 일정에 여유가 생기는 순간이 있고, 그럴 때면 그래도 나름의 자존심을 조금이라도 남기기 위해서 효율성을 위해서 몇 가지 어려운 기능들을 추가할 때가 있었어요. 뭐, 일이야 주어진 기능을 다 완수하는 것이 목표니까, 그것이 효율적이든 효율적이지 않든 그건 중요한게 아니니까, 순전히 자기 만족을 위해서 집어넣는 기능들이었지요. 물론 하고 싶은 것은 많았지만, 그리 많은 시간을 낼 수는 없었어요. 그래서 주로 간단간단한 것들만 집어넣었지요. 그 중에서 가장 기억에 남는 것이 바로 반투명 메세지창 이었어요.
이 메세지창은 화면 어딘가에 잠시 떠서 메세지를 전달하고, 시간이 지나면 사라져요. 흔한 인터페이스는 아니지만 그렇다고 그렇게 특이한 인터페이스도 아니었지요. 이러한 메세지창은 보통 Humanized Message라고 불려요. 인간친화적인 메세지라는 것이지요. 이 창이 왜 인간친화적일까요?
이 창을 보통 얼럿(Alert) 창이라고 불러요. 경고메세지를 띄우기 위한 용도로 쓰이고, 보통 호출할때도 alert("Hello!"); 같은 식으로 부르거든요. 위에 있는 Humanized Message와는 달리 이 창은 정말 수도 없이 봤을꺼에요. 쓰기도 편하고 익숙하기도 하고 참 안정적인 인터페이스이지요. 하지만 Alert 창은 심각한 문제점이 있어요. 바로 정보효율성이 그 어떠한 경우에도 0%가 되어버린다는 것이지요. 그 안에 담고 있는 메세지가 '안녕하세요! Guest 님!'과 같은 정말 어이없는 메세지건 세계종말을 고하는 중요한 메세지건 상관 없어요. 이건 무조건 효율성이 0이에요. 최악의 인터페이스에요.
시스템이 필요한 정보량은 얼마인가요? 정보라고 이름을 붙이는 것이 민망할 정도로, 없어요. 저 창이 요구하는 것이 아무것도 없어요. 100%의 확률로 OK를 누를 수 밖에 없어요. 자바스크립트의 Alert창은 Modal Window거든요. 그러니까, Alert창이 뜨면 그 뒤의 브라우저창을 아무리 눌러도 제어권이 브라우저로 넘어가지 않아요. 무조건 Alert창을 꺼야만 제어권이 다시 화면으로 넘어가게 되지요. 정말 경고하는 방법으로는 최상급이지만, 은근히 짜증나기도 해요. 100%의 확률로 전달하는 정보는 '진행하겠음' 하나 뿐이고 '진행하지 않겠음'을 선택할 수는 없어요. log 1은 0이잖아요. 그래서 필요한 정보량은 0이에요. 사용자가 제공해야 되는 정보는 'OK 버튼 클릭했음'이 있으니까 1비트가 되지요. 위 스크린샷의 디자인의 경우 닫기 버튼까지 있어서 조금 더 비효율적이기는 하지만, 그걸 생각할 필요도 없이 이미 분자가 0이니 효율성은 0%가 될 수 밖에 없어요.
그래서 나온 것이 위에 언급한 Humanized Message에요. 저 창은 정보를 전달하기는 하지만 입력을 받지는 않아요. 시스템이 필요한 정보는 여전히 0인데 사용자가 입력해야 되는 정보도 0이에요. 분모가 0이 되면 수학적으로도 컴퓨터 공학적으로도 오류이지만, 정보효율성에서는 0으로 나누는 경우에는 1로 정의해요. 즉, 100%의 효율성을 가진다는 뜻이 되지요. 실제로 이 글을 쓰는 동안에도 티스토리는 쉬지 않고 우측 상단에 '임시저장 되었습니다.'라는 메세지가 나타났다 사라지고 있어요. 마찬가지로 100%의 효율성을 가진 인터페이스가 되겠지요. 저걸 창으로 띄워서 사용자의 확인을 받을 필요가 있을까요? 확인을 받아서 뭘 할까요? 임시저장 하겠습니까? 라는 질문이라면 의미가 있지요. 하거나 안 하거나 할 수 있으니까요. 하지만 했습니다. 라는 통보에 사용자가 임시저장을 하지 말아라. 취소해라. 잘 했어 계속 그렇게 해. 라고 의견을 표명할 수 없이 '임시저장 했다는 사실을 깊이 숙지하였음'이라는 의사만 표현할 수 있는 것은 정말 비효율적이지요.
하다못해 빔 프로젝터를 종료할 때도, 빔 프로젝터를 종료하려면 전원 버튼을 한 번 더 누르세요. 라고 경고창이 뜨지요. 하지만 빔 프로젝터는 '안 누르고 기다리면 안 끕니다.'라는 선택지를 하나는 더 줬어요. 버튼 하나로 두 가지 동작을 하기 위해 선택한 디자인이고, 그래서 좀 불편하기는 하지만 그래도 그럭저럭 효율적이에요. 최소한 0은 아니지요. 그런데 빔 프로젝터 보다 훨씬 더 다양하고 복잡한 동작을 수행할 수 있는 웹 어플리케이션이 Alert창을 남발하는 것은 부끄러운 일이지요.
물론 Alert 창을 쓰지 않을 수는 없어요. 편하거든요. 한 줄이면 끝나니까요. Alert 창을 쓰지 않고 사용자에게 메세지를 전달하는 것은 정말 어려운 일이에요. 일단 뿌려진 페이지에 메세지를 추가하는 것도 일반적인 웹 프로그래밍 기술로 쉽게 해결할 수 있는 일이 아니에요. 메세지 하나 뿌리자고 페이지를 새로고침 하는 것도 인터페이스와는 별개로 성능 자체가 비효율적이구요. 그래서 Alert 창을 많이 써요. 하지만 할 수 있다면 Humanized Message를 쓰는 쪽이 효율적이지요. 할 수만 있다면.
그래서 했어요. jQuery라는 자바스크립트 라이브러리는 정말 할 수 있는게 많았고, 그리 어렵지도 않았어요. 저녁밥 먹고 돌아와서 잠시 휴식을 취할 시간 정도에 휴식만 안 취하고 열심히 일하는 모습을 보여주면, 한 두시간 이내로 대부분의 기능들을 적용할 수 있었고, Humanized Message도 마찬가지였어요. 내가 원하는 시간 만큼만 보이도록, 원하는 위치에 원하는 색으로 나타나게 하는 것은 조금 더 시간이 걸리는 일이었지만, 어쨌든 꽤 무난하고 쉽게 적용할 수 있었지요. 하지만 모든 페이지에 적용하지는 않았어요. 딱 한 페이지에만 적용하고 혼자 좋아했지요.
애초에 시간이 없어서, 그게 제일 무난하니까, 메세지를 뿌려야 될 때는 Alert 창을 뿌려가면서 프로그램을 만들었어요. 그게 비효율적이라는 것을 알면서도 그렇게 했어요. 거부감 같은 것도 별로 없었어요. 어차피 이걸 효율적으로 만들어봐야 누가 알아주지도 않는 것이고, 사실 효율적이라고 설명하기 위해서 위에 했던 설명을 다 설명할 수도 없는 것이구요. 개발하기도 바쁜데 마감 전에 다 끝내려면 그냥 고민 안하고 Alert창으로 띄우는 것이 편했지요. 오류가 날 이유도 없었고 딴지가 걸릴 이유도 없었고 어쨌든 다 좋았어요. 그렇게 타협하고 넘어갔지요. 굳이 Alert 창에 국한된 것이 아니었어요. 효율적으로 만들기 위해서 복잡한 프로그래밍 필요하다 싶으면 무조건 버튼 하나 더 만들고, 링크 하나 더 걸고, 확인 한 번 더 받는 식으로 효율성을 포기하면서 일정에 맞추었지요.
그러니까 나중에 거의 완성된 프로그램을 돌려보면서 참 효율성 낮다고 짜증을 낼 수 밖에요. 그리고 그걸 그렇게 만든 것이 바로 나 자신이기에 나한테도 짜증이 날 수 밖에요.그래서 없는 여유를 만들어서 반투명한 메세지창을 띄워놓고는 혼자 좋아했어요. 그래, 아무리 그래도 내가 몰라서, 못해서 안 하는건 아니다. 라는 일종의 표시라고 해야 될까요. Alert창을 꼭 필요할때만 띄우는 것과 더불어서 그래도 '나는 할 만큼 했음'이라고 주장할 거리를 남겨놨다고 해야 될까요.
그리고 감리가 시작되었어요. 저는 공공쪽에서 프로젝트를 수행했고, 이건 나라 예산으로 만들어지는 프로그램이에요. 나라 예산은 세금이구요. 수십 수백억이 걸린 프로젝트들을 그냥 '시작했음' '끝났음'이라고 보고하고 끝낼 수는 없잖아요. 그러니까 감리 같은 사람들이 와서 제대로 만들었는지 확인을 하지요. 그래서 제가 만든 프로그램은 일종의 심사를 받게 되었어요.
감리가 끝나는 시기였어요. 프로그램 시연이 있는 날이었거든요. 다른 팀원들이 먼저 시연을 하길래, 조금 기다리다가, 제가 들어갈 차례가 되었어요. 들어가서 옆 자리에 앉자, '이건 도대체 어떻게 쓰는거냐'라고 물어보시더라구요. 지난 1주일 동안 도대체 뭘 한거냐 라고 대답하지 않고, 이렇게 이렇게 하는 거라고 하나씩 설명해줬어요. 대충 모든 기능을 돌려보고 나서 다시 물어보시더라구요. '이건 도대체 어디에 쓰는거냐' 그게 개발자에게 할 질문이냐고 대답하지 않고, 잘은 모르겠지만 아마도 이런 이런 용도로 쓰지 않을까요? 라는 식으로 대답을 했어요. 이해를 하셨는지 이해를 하시지 못하셨는지, 몇 가지 지적사항을 말해주셨어요. 그러다가 중간에.
'아마도 신입사원이라서 처음이니까 잘 모를테니까 해주는 말인데요'
예'
'보통 사용자 편의성을 위해서는 진행상황이나 뭐 그런 메세지를 많이 알려줘야 사용자들이 아 어떤 일을 했구나 라고 알게 되는 거거든요'
'예'
'그런데 이 프로그램은 써보면 뭐 메세지가 거의 표시가 안 되더라구요?'
'예'
'삭제했으면 삭제되었습니다. 이렇게 떠야 되는거 아닌가요?'
이 프로그램에서 삭제는 보통 연속된 작업 흐름의 일부로 이루어지기 떄문에 반복 작업이 이루어질때 매번 메세지를 띄우는 것도 오히려 불편하고 비효율적이고 더군다나 AJAX 기반으로 사용자가 연속된 동작을 할때 그 동작의 흐름이 끊기지 않게 하기 위해서 그 고생을 하면서 화면 전환 없이 목록에서 삭제한 항목만 지워지도록 만들어놨는데, 여기서 삭제했습니다 라는 창을 계속 띄워서 흐름을 끊어야 되는게 맞는 건가요? 라고 대답하지 않고
'예'
'보통 남들이 어떻게 만들었나 잘 참고해서 만드는게 좋아요'
'예'
'그리고 여기는 왜 메세지가 창으로 안 뜨고 한 쪽에 표시만 되나요?'
'그게 효율적...'
'아니, 뭐가 됐는지 안 됐는지 알기도 어렵고 보기도 안 좋은데 그냥 얼럿창 띄우는게 좋을 것 같은데요.'
뭐라 대답했는지 기억이 잘 안 나네요. 아마 이 때 부터는 그냥 고개만 끄덕였던 것 같아요.
어쨌든 끝은 났고, 회의실에서 나와서 자리로 돌아왔어요. 그 때 이미 퇴근시간이 거의 다가왔지만 일찍 갈 생각이 별로 없었어요. 그래서 그 날 야근을 했지요. 시작하자마자 반투명 메세지창은 소스코드와 라이브러리를 동시에 다 지워버리고는, 대신 프로그램의 모든 곳의 모든 동작에 Alert 창을 집어넣었어요. 별로 오래걸리지도 않았고, 어렵지도 않았어요. 솔직히 말하면 별로 재미도 없었어요.
요즘 대학생들은 어떨지 모르겠지만, 보통 대학교에서 잘 안가르쳐주는 HCI(Human Computer Interaction) 과목에서는 정보효율성(Information-theoretic efficiency)이라는 개념이 나와요. 솔직히 말하면 나올지 안 나올지 잘 모르겠어요. 저도 그냥 대학생이었고, 제가 다니던 학교에서는 HCI를 안 가르쳐줬거든요. 솔직히 가르쳐줬더라도 거기에 정보효율성이라는 개념이 나올 지는 잘 모르겠어요. 구글에서 검색해도 잘 안 나올만큼 마이너한 개념이거든요.
열 효율성은 투입한 자원 대비 얻은 에너지의 효율성을 말해요. 정보 효율성은 그럼 어떤 것의 효율성을 말하는 것일까요? 정보 효율성은 사용자가 제공해야 되는 정보량 대비 실제로 필요한 최소한의 정보량간의 효율성이에요. 정말 재미없는 이야기가 되어버렸네요. 종료하시겠습니까? 예. 아니요. 라는 창이 나오면, 시스템이 할 수 있는 동작은 종료하든지, 종료하지 않든지 두 가지에요. 그걸 결정하기 위해서 사용자에게 정보를 요청하지요. YES입니까? NO입니까? 1 또는 0. 1비트의 정보가 필요해요. 시스템이 필요한 정보량은 어떤가요? 안타깝게도 여기에는 복잡하지는 않지만 블로그에 쓰기에는 조금 난감한 수학공식이 필요해요. 각각의 동작이 시행될 확률을 p(i)라고 하면 모든 p(i)에 대해서 p(i)*log2(1/p(i))의 합이 필요한 정보량이 되는데, 계산과정 생략하고 결과적으로 말하면, 종료할 확률과 종료하지 않을 확률이 동일하면 필요한 정보량 역시 1비트가 되요. 1비트의 정보량이 필요할 때 1비트의 정보를 입력하니까 효율성은 1/1 = 1. 즉 100%가 되는 것이에요. 만약 사용자들이 평균적으로 종료할 확률이 70%이고, 종료하지 않을 확률이 30%라면 필요한 정보량은 평균적으로 0.88비트 정도가 되구요. 물론 1비트 이하의 정보를 전달하는 것은 어려우니 그저 말이 그렇다는 것이지요.
조금 더 복잡한 상황을 가정해볼께요. 워드프로세서로 문서를 만들다가 그냥 종료시켜버렸어요. 워드프로세서는 또 물어봐요. 어떻게 할까요? 저장하고 종료할까요? 저장하지 않고 그냥 종료할까요? 아니면 종료를 하지 말까요? 이걸 간단하게 '저장하고 종료할까요?'라고 물어보고 답변을 예, 아니요, 취소의 3가지로 주어서 결정하게 하지요. 마찬가지 공식으로 계산해보면 시스템에 필요한 정보량은, 1.584 비트가 되요. 눈치챌 수 있겠지만, 2의 1.584 제곱은 3이 되지요. 즉, 3가지 선택지를 가진 질문창은 1.584비트의 정보를 전달할 수 있고, 3가지 동작을 3가지 선택지로 하는 이 인터페이스는 효율성이 마찬가지로 100%에요.
그런데 이렇게 생각할 수 있어요. 사용자가 종료를 눌렀다는 것은 일단 저장을 하든 안하든 종료를 할 의도가 있다는 것인데, 종료를 하지 않고 돌아가는 '취소'버튼을 만든 것은 조금 비효율적이지 않을까? 그리고 이 비효율성도 계산을 할 수가 있어요. 평균적으로 사용자가 저장을 하고 종료할 확률이 40% 정도, 저장하지 않고 종료할 확률도 40% 정도, 저장하지 않고 종료도 안할 확률이 20% 정도라면 1.5219 비트의 정보가 필요하거든요. 따라서 이 인터페이스는 90% 정도의 효율성을 가지게 되지요. 만약에 취소할 확률이 10% 정도라면 효율성은 86%까지 떨어져요. 즉, 취소는 잘 하지도 않는데 취소 버튼을 넣어두는 것은 비효율적이라고 생각할 수 있다면, 그 취소를 잘 안하면 안 할수록 인터페이스는 정말 비효율적인 것이라고 강하게 주장할 수 있는 것이고, 이게 이론적으로 증명이 되는 것이지요. 정말 신기하지 않나요?
사실 정말 효율적인 인터페이스를 만들려면, 이런 식으로 구상할 수도 있겠지요. 종료를 하면 일단은 그냥 종료가 되어버리지만, 저장하지 않고 종료했을 때의 저장본과 저장하고 종료했을 때의 저장본을 모두 파일로 저장하는 것. 즉, 백업 파일을 만들어서 두 가지 경우를 모두 커버하는 방법이 있겠지요. 사용자의 입력이 없고, 두 가지 경우를 모두 만족시킬 수도 있기 때문에 꽤 효율적이라고 할 수 있을 것 같아요.
하지만 이론과 현실이 꼭 맞는 것은 아니에요. 실제로 사용하는 인터페이스는 꼭 효율성 100%를 따라가야되고, 단조성을 만족시켜야 되고, 모드를 유발하지 않아야 되고 그렇게 모든 원칙과 이론을 만족시키는 디자인을 만들어야 되는 것이 아니에요. 오히려 그게 더 불편할 수도 있어요. 백업본이 마구마구 생성되고, 그 중에서 내가 원하는 파일이 어떤 것인지 찾는 것 보다 그냥 좀 비효율적이더라도 (대부분 사용자들은 그게 효율적인지 비효율적인지도 잘 안 따져요) 예 아니요 취소 처럼 직관적인 선택지가 주어지는 것을 선호해요. UI와 UX의 차이가 여기에 있지만, 그건 이 글에서 중요한 것은 아니에요.
정말 극도로 효율적인 디자인이 가지는 문제는 두가지가 있지요. 사용자가 불편하고, 개발자가 불편해요. 사용자들은 생소하고 익숙하지 않고 동작이 어떻게 되는지 잘 모르니까 불편해요. 종료를 눌렀더니 파일 2개가 생기고 그대로 꺼져버리는 워드프로세서를 만난 사용자가 '와, 이 프로그램 정말 효율적인데?'라고 생각할까요? 아마 이걸 만든 사람들이 제정신인가..라는 생각을 먼저 하겠지요. 개발자도 마찬가지에요. 프롬프트에 버튼 3개 띄우고, YES이면 save 하고 quit. NO 이면 그냥 quit. CANCLE이면 return. 이런건 정말 일도 아니지요. 그런데 종료 이벤트가 호출되면 현재 파일이 이전 저장본과 비교해서 변했는지 안 변했는지 확인하고 변했으면 이전 저장본의 확장자를 .bak로 바꿔서 저장하고 현재 파일은 파일명을 유지하여서 저장하고. 그리고 종료를 시켜야되요. 사실 이전 저장본은 하드디스크에 현재 파일명으로 잡혀있고, 현재 편집된 분량은 메모리에 들어 있는 것이고, 그 둘의 파일명을 서로 교환한다는 것까지 고려해야 된다면 파일 핸들을 어떻게 넘기고 넘겨야 될지 난감해질 수 밖에 없어요. 그러니까. 하여튼. 백업 파일 만드는건 정말 짜증나는 일이라구요. 그러니까 그냥 효율성 생각 안하고 예 아니요 취소로 가는게 모두가 좋은 일이에요.
그러니까 왜 이런 재미없는 소리로 시작을 했냐면, 이 효율성 문제가 저를 위기로 몰아간 이야기를 하고 싶었거든요. SI프로젝트에서는 정보효율성 따지는 것이 정말 쓸모없는 노력이 되는 경우가 많아요. 일단 사용자들은 익숙한 디자인과 익숙한 동작을 원해요. 더군다나 SI 프로젝트에서는 사용자를 둘로 나눠서 생각해야 되거든요. 이왕 UI 이야기를 했으니까 UX 이야기도 섞어서, 페르소나를 만들어보자면 SI프로젝트에서 사용자는, 아주 크게 나누면 두 개의 페르소나를 만들 수 있어요. 하나는 '진짜 사용자'이구요. 그럼 가짜 사용자도 있냐구요? 비슷한게 있어요. 다른 하나는 '검수자'에요. 둘 다 사용자에 포함할 수 있어요. 프로젝트에서 나온 프로그램을 써보거든요. 다만 진짜 사용자는 프로그램을 진짜 그 목적에 맞게 사용하고, 검수자. 보통 고객이나 감리, 혹은 테스터라고 불리는 사람들은 프로그램이 그 목적에 맞게 동작하는지 확인하기 위해서 사용해봐요. 사용자에 따라서 요구하는 편의성의 레벨도 다르고, 그 레벨에 도달해야 되느냐 되지 않느냐도 달라요. 이런 상황에서 효율성을 주장하면서 독창적인 디자인을 하는 것은 정말 큰 모험이에요. 진짜 사용자들에게야 메뉴얼 잘 써주고 교육 잘 시켜주면 '이게 이런식으로 하면 정말 편해요.'라고 주장할 수 있을지 모르겠지만, 프로그램을 검수하는 사람들은 아주 잠깐 써보는 정도로 끝나거든요. 원하는 것 처럼 쉽게 동작하지 않으면 대번 퇴짜가 나와요. 그리고 참 불행하게도. 검수자들이 퇴짜를 놓으면 프로그램은 그 사람들이 원하는 방향으로 수정해야 되요. 안 그러면 통과가 안 되는걸요.
웹 어플리케이션을 한참 개발했어요. 사실 개발자들은 자기가 만든 어플리케이션을 정말 수도 없이 사용해봐요. 하나 만들때마다 테스트를 해보고, 버그를 잡고 그래야 되잖아요. 그렇게 수도 없이 실행해보고 만들고 실행해보면서 느꼈죠. 참 효율성 짜증날 정도로 낮구나. 그러니까 그건 자학 비슷한 것이었어요. 그 어플리케이션을 제가 디자인한 인터페이스를 가지고 있었으니까요. 깊이 고민하고 계산해볼 시간도 없었지만, 그냥 버튼을 누르면서도 직감적으로 느낄 수 있을만큼 효율적이지 못한 인터페이스를 가지고 있었거든요. 그리고 그건 어느정도는 사용자 편의성을 위해서 희생한 부분도 분명 있었어요. 그리고 대부분은 그냥 제 실력부족으로 낮아진 효율성이었어요. 분명 이게 여기서 실시간으로 갱신되어야 효율적인데, 버튼을 눌러서 결과를 받아오는 것은 정말 비효율적인데. 그런데 실시간으로 갱신을 시키려면 어떻게 해야 되지? 화면은...이렇게 하면 될 것 같기는 한데 해봐야 겠네. 그런데 서버쪽은 어떻게 해야되지? 매사가 이런 식이었어요. 그리고 거기에 신경쓰면서 하루나 이틀 정도를 투자할 여유가 없었으니까 그냥 효율성은 무시하고 버튼 눌러서 결과 받아오는 선택을 하게 되지요. 그런 것이 정말 한 두개가 아니었어요.
그래도 열심히 하다 보면 일정에 여유가 생기는 순간이 있고, 그럴 때면 그래도 나름의 자존심을 조금이라도 남기기 위해서 효율성을 위해서 몇 가지 어려운 기능들을 추가할 때가 있었어요. 뭐, 일이야 주어진 기능을 다 완수하는 것이 목표니까, 그것이 효율적이든 효율적이지 않든 그건 중요한게 아니니까, 순전히 자기 만족을 위해서 집어넣는 기능들이었지요. 물론 하고 싶은 것은 많았지만, 그리 많은 시간을 낼 수는 없었어요. 그래서 주로 간단간단한 것들만 집어넣었지요. 그 중에서 가장 기억에 남는 것이 바로 반투명 메세지창 이었어요.
이 메세지창은 화면 어딘가에 잠시 떠서 메세지를 전달하고, 시간이 지나면 사라져요. 흔한 인터페이스는 아니지만 그렇다고 그렇게 특이한 인터페이스도 아니었지요. 이러한 메세지창은 보통 Humanized Message라고 불려요. 인간친화적인 메세지라는 것이지요. 이 창이 왜 인간친화적일까요?
이 창을 보통 얼럿(Alert) 창이라고 불러요. 경고메세지를 띄우기 위한 용도로 쓰이고, 보통 호출할때도 alert("Hello!"); 같은 식으로 부르거든요. 위에 있는 Humanized Message와는 달리 이 창은 정말 수도 없이 봤을꺼에요. 쓰기도 편하고 익숙하기도 하고 참 안정적인 인터페이스이지요. 하지만 Alert 창은 심각한 문제점이 있어요. 바로 정보효율성이 그 어떠한 경우에도 0%가 되어버린다는 것이지요. 그 안에 담고 있는 메세지가 '안녕하세요! Guest 님!'과 같은 정말 어이없는 메세지건 세계종말을 고하는 중요한 메세지건 상관 없어요. 이건 무조건 효율성이 0이에요. 최악의 인터페이스에요.
시스템이 필요한 정보량은 얼마인가요? 정보라고 이름을 붙이는 것이 민망할 정도로, 없어요. 저 창이 요구하는 것이 아무것도 없어요. 100%의 확률로 OK를 누를 수 밖에 없어요. 자바스크립트의 Alert창은 Modal Window거든요. 그러니까, Alert창이 뜨면 그 뒤의 브라우저창을 아무리 눌러도 제어권이 브라우저로 넘어가지 않아요. 무조건 Alert창을 꺼야만 제어권이 다시 화면으로 넘어가게 되지요. 정말 경고하는 방법으로는 최상급이지만, 은근히 짜증나기도 해요. 100%의 확률로 전달하는 정보는 '진행하겠음' 하나 뿐이고 '진행하지 않겠음'을 선택할 수는 없어요. log 1은 0이잖아요. 그래서 필요한 정보량은 0이에요. 사용자가 제공해야 되는 정보는 'OK 버튼 클릭했음'이 있으니까 1비트가 되지요. 위 스크린샷의 디자인의 경우 닫기 버튼까지 있어서 조금 더 비효율적이기는 하지만, 그걸 생각할 필요도 없이 이미 분자가 0이니 효율성은 0%가 될 수 밖에 없어요.
그래서 나온 것이 위에 언급한 Humanized Message에요. 저 창은 정보를 전달하기는 하지만 입력을 받지는 않아요. 시스템이 필요한 정보는 여전히 0인데 사용자가 입력해야 되는 정보도 0이에요. 분모가 0이 되면 수학적으로도 컴퓨터 공학적으로도 오류이지만, 정보효율성에서는 0으로 나누는 경우에는 1로 정의해요. 즉, 100%의 효율성을 가진다는 뜻이 되지요. 실제로 이 글을 쓰는 동안에도 티스토리는 쉬지 않고 우측 상단에 '임시저장 되었습니다.'라는 메세지가 나타났다 사라지고 있어요. 마찬가지로 100%의 효율성을 가진 인터페이스가 되겠지요. 저걸 창으로 띄워서 사용자의 확인을 받을 필요가 있을까요? 확인을 받아서 뭘 할까요? 임시저장 하겠습니까? 라는 질문이라면 의미가 있지요. 하거나 안 하거나 할 수 있으니까요. 하지만 했습니다. 라는 통보에 사용자가 임시저장을 하지 말아라. 취소해라. 잘 했어 계속 그렇게 해. 라고 의견을 표명할 수 없이 '임시저장 했다는 사실을 깊이 숙지하였음'이라는 의사만 표현할 수 있는 것은 정말 비효율적이지요.
하다못해 빔 프로젝터를 종료할 때도, 빔 프로젝터를 종료하려면 전원 버튼을 한 번 더 누르세요. 라고 경고창이 뜨지요. 하지만 빔 프로젝터는 '안 누르고 기다리면 안 끕니다.'라는 선택지를 하나는 더 줬어요. 버튼 하나로 두 가지 동작을 하기 위해 선택한 디자인이고, 그래서 좀 불편하기는 하지만 그래도 그럭저럭 효율적이에요. 최소한 0은 아니지요. 그런데 빔 프로젝터 보다 훨씬 더 다양하고 복잡한 동작을 수행할 수 있는 웹 어플리케이션이 Alert창을 남발하는 것은 부끄러운 일이지요.
물론 Alert 창을 쓰지 않을 수는 없어요. 편하거든요. 한 줄이면 끝나니까요. Alert 창을 쓰지 않고 사용자에게 메세지를 전달하는 것은 정말 어려운 일이에요. 일단 뿌려진 페이지에 메세지를 추가하는 것도 일반적인 웹 프로그래밍 기술로 쉽게 해결할 수 있는 일이 아니에요. 메세지 하나 뿌리자고 페이지를 새로고침 하는 것도 인터페이스와는 별개로 성능 자체가 비효율적이구요. 그래서 Alert 창을 많이 써요. 하지만 할 수 있다면 Humanized Message를 쓰는 쪽이 효율적이지요. 할 수만 있다면.
그래서 했어요. jQuery라는 자바스크립트 라이브러리는 정말 할 수 있는게 많았고, 그리 어렵지도 않았어요. 저녁밥 먹고 돌아와서 잠시 휴식을 취할 시간 정도에 휴식만 안 취하고 열심히 일하는 모습을 보여주면, 한 두시간 이내로 대부분의 기능들을 적용할 수 있었고, Humanized Message도 마찬가지였어요. 내가 원하는 시간 만큼만 보이도록, 원하는 위치에 원하는 색으로 나타나게 하는 것은 조금 더 시간이 걸리는 일이었지만, 어쨌든 꽤 무난하고 쉽게 적용할 수 있었지요. 하지만 모든 페이지에 적용하지는 않았어요. 딱 한 페이지에만 적용하고 혼자 좋아했지요.
애초에 시간이 없어서, 그게 제일 무난하니까, 메세지를 뿌려야 될 때는 Alert 창을 뿌려가면서 프로그램을 만들었어요. 그게 비효율적이라는 것을 알면서도 그렇게 했어요. 거부감 같은 것도 별로 없었어요. 어차피 이걸 효율적으로 만들어봐야 누가 알아주지도 않는 것이고, 사실 효율적이라고 설명하기 위해서 위에 했던 설명을 다 설명할 수도 없는 것이구요. 개발하기도 바쁜데 마감 전에 다 끝내려면 그냥 고민 안하고 Alert창으로 띄우는 것이 편했지요. 오류가 날 이유도 없었고 딴지가 걸릴 이유도 없었고 어쨌든 다 좋았어요. 그렇게 타협하고 넘어갔지요. 굳이 Alert 창에 국한된 것이 아니었어요. 효율적으로 만들기 위해서 복잡한 프로그래밍 필요하다 싶으면 무조건 버튼 하나 더 만들고, 링크 하나 더 걸고, 확인 한 번 더 받는 식으로 효율성을 포기하면서 일정에 맞추었지요.
그러니까 나중에 거의 완성된 프로그램을 돌려보면서 참 효율성 낮다고 짜증을 낼 수 밖에요. 그리고 그걸 그렇게 만든 것이 바로 나 자신이기에 나한테도 짜증이 날 수 밖에요.그래서 없는 여유를 만들어서 반투명한 메세지창을 띄워놓고는 혼자 좋아했어요. 그래, 아무리 그래도 내가 몰라서, 못해서 안 하는건 아니다. 라는 일종의 표시라고 해야 될까요. Alert창을 꼭 필요할때만 띄우는 것과 더불어서 그래도 '나는 할 만큼 했음'이라고 주장할 거리를 남겨놨다고 해야 될까요.
그리고 감리가 시작되었어요. 저는 공공쪽에서 프로젝트를 수행했고, 이건 나라 예산으로 만들어지는 프로그램이에요. 나라 예산은 세금이구요. 수십 수백억이 걸린 프로젝트들을 그냥 '시작했음' '끝났음'이라고 보고하고 끝낼 수는 없잖아요. 그러니까 감리 같은 사람들이 와서 제대로 만들었는지 확인을 하지요. 그래서 제가 만든 프로그램은 일종의 심사를 받게 되었어요.
감리가 끝나는 시기였어요. 프로그램 시연이 있는 날이었거든요. 다른 팀원들이 먼저 시연을 하길래, 조금 기다리다가, 제가 들어갈 차례가 되었어요. 들어가서 옆 자리에 앉자, '이건 도대체 어떻게 쓰는거냐'라고 물어보시더라구요. 지난 1주일 동안 도대체 뭘 한거냐 라고 대답하지 않고, 이렇게 이렇게 하는 거라고 하나씩 설명해줬어요. 대충 모든 기능을 돌려보고 나서 다시 물어보시더라구요. '이건 도대체 어디에 쓰는거냐' 그게 개발자에게 할 질문이냐고 대답하지 않고, 잘은 모르겠지만 아마도 이런 이런 용도로 쓰지 않을까요? 라는 식으로 대답을 했어요. 이해를 하셨는지 이해를 하시지 못하셨는지, 몇 가지 지적사항을 말해주셨어요. 그러다가 중간에.
'아마도 신입사원이라서 처음이니까 잘 모를테니까 해주는 말인데요'
예'
'보통 사용자 편의성을 위해서는 진행상황이나 뭐 그런 메세지를 많이 알려줘야 사용자들이 아 어떤 일을 했구나 라고 알게 되는 거거든요'
'예'
'그런데 이 프로그램은 써보면 뭐 메세지가 거의 표시가 안 되더라구요?'
'예'
'삭제했으면 삭제되었습니다. 이렇게 떠야 되는거 아닌가요?'
이 프로그램에서 삭제는 보통 연속된 작업 흐름의 일부로 이루어지기 떄문에 반복 작업이 이루어질때 매번 메세지를 띄우는 것도 오히려 불편하고 비효율적이고 더군다나 AJAX 기반으로 사용자가 연속된 동작을 할때 그 동작의 흐름이 끊기지 않게 하기 위해서 그 고생을 하면서 화면 전환 없이 목록에서 삭제한 항목만 지워지도록 만들어놨는데, 여기서 삭제했습니다 라는 창을 계속 띄워서 흐름을 끊어야 되는게 맞는 건가요? 라고 대답하지 않고
'예'
'보통 남들이 어떻게 만들었나 잘 참고해서 만드는게 좋아요'
'예'
'그리고 여기는 왜 메세지가 창으로 안 뜨고 한 쪽에 표시만 되나요?'
'그게 효율적...'
'아니, 뭐가 됐는지 안 됐는지 알기도 어렵고 보기도 안 좋은데 그냥 얼럿창 띄우는게 좋을 것 같은데요.'
뭐라 대답했는지 기억이 잘 안 나네요. 아마 이 때 부터는 그냥 고개만 끄덕였던 것 같아요.
어쨌든 끝은 났고, 회의실에서 나와서 자리로 돌아왔어요. 그 때 이미 퇴근시간이 거의 다가왔지만 일찍 갈 생각이 별로 없었어요. 그래서 그 날 야근을 했지요. 시작하자마자 반투명 메세지창은 소스코드와 라이브러리를 동시에 다 지워버리고는, 대신 프로그램의 모든 곳의 모든 동작에 Alert 창을 집어넣었어요. 별로 오래걸리지도 않았고, 어렵지도 않았어요. 솔직히 말하면 별로 재미도 없었어요.
댓글