Complicated

선택압으로 작용하는 인간의 행동들

aproxacs — Sun, 04 Oct 2009 11:08:43 +0900

17세기, 아직 미국이란 나라가 탄생하기 전, 유럽에서 미국으로 개척민들의 이주가 시작되던 초기에는 뉴잉글랜드 지역에 풍부한 어장이 있었다고 합니다. 그 지역에서 번식하는 대구의 수는 너무나 많아서, 손쉽게 잡아서 유럽지역으로 수출을 할 수 있었습니다. 그 대구 수출이 초기 뉴잉글랜드 지역의 경제의 중심이었다고 하니 그 양이 엄청났나 봅니다.
그 시절에 뉴잉글랜드 지역에 그렇게 많았던 대구들이 지금은 멸종 위기를 맞고 있다고 합니다. 대구를 잡는 어부들의 수가 늘어나면서, 그들의 무분별한 남획이 계속되면서, 대구 개체의 수가 급격히 줄어들었다고 합니다.
이렇듯 인간의 행동은 한 어종의 멸종을 만들어낼 수 있습니다. 과학과 상업 기술이 발전함에 따라 인간의 힘은 점점 더 커지게 되었고, 생태계에 대한 그 영향도 더 커지게 되었습니다.

그 시나리오에 대해서 생각해 봅니다. 인간이 대구 사냥을 시작하기 전에는 대구는 뉴 잉글랜드 지역의 환경에 적응하며 번성하고 있었습니다. 이제 유럽에서의 이주민들이 들어오면서 생계를 위해 대구 사냥을 시작합니다. 초기의 대구잡이는 굉장한 수익을 얻게 해 줍니다. 소문이 퍼져 나가면서 더 많은 어부들이 대구잡이를 시작합니다. 대구잡이 일꾼들은 점점 많아지고 대구의 수는 점점 줄어들어 갑니다. 그렇지만 더 좋은 배, 더 좋은 그물 같은 기술이 발전함에 따라 잡을 수 있는 대구의 양은 크게 감소하지 않습니다. 소문은 더 많은 어부들을 대구잡으로 이끌어 들입니다. 어느 순간에는 대구가 번식하는 속도보다 잡아들이는 속도가 훨씬 빠르게 됩니다. 대부분의 어부들은 이 상황을 알게 됩니다. 그리고 몇몇 현명한 사람들은 이대로 대구를 잡아들이게 되면 대구가 멸종할 것이라고 경고합니다. 대구를 잡는 속도를 줄여야 한다는 의견이 나오기 시작합니다. 그들의 주장이 공감은 되지만, 사람들을 행동을 변화시키지는 못합니다. 모든 사람들이 대구를 마구마구 잡고 있는데, 나 혼자 대구 잡는 양을 제한하는 것은 바보같은 짓입니다. 내가 대구 잡는 양을 제한해도 다른 사람들이 제한하지 않는다면 대구는 결국 멸종될 테니까요. 그렇다면 현재 나의 최선의 전략은 있는 힘껏 대구를 잡아 더 많은 이익을 내서 미래에 대비하는 것입니다. 결국 대구는 멸종됩니다.

이런 비극적인 시나리오를 막기 위해서는 사회적인 약속이 필요합니다. 예를 들어 한 어부가 하루에 잡을 수 있는 대구의 양을 제한합니다. 그리고 어부들에게 대구잡이 허가권을 발행해서 어부의 숫자도 제한합니다. 그렇게 함으로써 대구의 개체 수를 적정하게 유지할 수 있습니다. 좋은 방법이기는 하나 법을 실행하려다 보면 작은 문제가 있습니다. 하루에 잡을 수 있는 대구의 양을 제한하는 법은 실행하기 쉽지 않습니다. '하루 1톤 이하만 잡아야 한다.' 라는 법은 적용하기가 애매한 경우가 있습니다. 한 어부가 하루 동안 잡은 대구의 양을 확인하기 힘듭니다. 한 어부가 1톤 이상을 잡고 더 잡은 양을 숨긴다면, 그것을 적발하는 것도 어렵습니다. 그래서 좀 더 현실적인 법안은 다 큰 대구만 잡을 수 있도록 하는 것입니다. '10kg 이상의 대구만 잡을 수 있다.' 는 법안은 대구가 거래되는 시장만 검사하면 되기 때문에 좀 더 적용하기 쉽습니다.

그런데 꽤 합리적으로 보이는 '10kg 이상의 대구만 잡을 수 있다.' 법안도 대구의 생태계에 영향을 미칩니다. 오랜 시간이 지나면서 10kg 이상의 대구는 점점 더 잡히지 않게 됩니다. 그렇다고 대구의 수가 감소한 것은 아닙니다. 다만 대구가 다 커도 10kg 이상이 되지 않게 된 것입니다. 인간의 10kg이상의 대구만 잡는 행위가 대구에게 선택압이 되어서 다 커도 10kg이 안 되는 작은 대구들이 번성하게 됩니다.

인류가 살아간다는 것만으로 우리의 행동들이 생태계에 영향을 미칩니다. 이는 자연스러운 일입니다. 다만 인간의 영향력이 생태계에 지나치게 크게 작용하는 것을 보면 참 어색합니다.

역방향 추론

aproxacs — Sat, 03 Oct 2009 19:51:43 +0900

여기 게임이 하나 있습니다. 게임 참가자는 두 명입니다. 참가자는 숫자 1~3개를 한 번에 부를 수 있습니다. 번갈아 가면서 숫자를 1부터 불러 나가는데, 21을 먼저 외치는 사람이 게임에 지게 됩니다. 예를 들어 참가자 A가 1,2를 외치고, B가 3을, 다시 A가 4,5,6 이런 식으로 21까지 진행하는 것입니다.

이 게임을 두 명이서 진행을 하면 어떤 규칙을 얻어낼 수 있습니다. 상대방이 21을 외치도록 하기 위해서는 20을 먼저 외치면 됩니다. 20을 먼저 외치기 위해서는 16을 먼저 외치면 됩니다. 그러면 상대가 17을 외치든 17, 18,19를 외치든 내가 20을 외칠 수 있습니다. 같은 논리를 적용하면 16을 먼저 외치기 위해서는 12를 먼저 외치면 됩니다. 12를 위해서는 8을, 8을 위해서는 4를 먼저 외치는 자가 승리를 거머쥐게 됩니다. 결국 이 게임을 제대로 이해하고만 있다면 나중에 시작하는 쪽이 항상 승리를 하게 됩니다.

이런 과정을 거쳐서 결론을 얻어 내는 것을 역방향 추론이라고 합니다. 상대방과 내가 순차적으로 행동을 하게 되는 상황에서, 어떤 결론을 얻어내기 위해서 발생하는 일들을 뒤에서부터 되집어 보는 것입니다.

이제 게임 참가자가 세 명이라고 가정해 봅니다. 나, A, B 이렇게 게임에 참가합니다. 이제 역방향 추론을 진행해 합리적인 전략을 생각해 봅시다.
내가 21을 외치지 않기 위해서는 20이나 19를 먼저 외치면 됩니다. 20을 외치면 A가 게임을 지게 될 것이고, 19를 외치면 A가 20을 외쳐서 B가 게임을 지게 될 것입니다.
내가 18을 외치면 어떻게 될까요? 두 가지의 경우가 있습니다. A가 19를 외치고 B가 20을 외쳐서 내가 지게 되는 경우, A가 19,20을 외쳐서 B가 지게되는 경우. 그래서 18을 외치면 나의 승리 확률은 50%입니다.
17을 외치면 어떻게 될까요? A는 19 혹은 20을 외쳐서 승리를 확정지을 것입니다. 18을 외치지는 않을 것입니다. A가 19를 외치면 내가 지게 되고 A가 20을 외치면 B가 지게 됩니다. 그래서 확률은 역시 50%입니다.
16을 외치면 어떻게 될까요? A는 승리를 위해 19를 외칠 것이고, B는 20을, 그래서 나의 승리 활률은 없습니다. 승리하기 위해서는 절대로 16을 외쳐서는 안됩니다.
15를 외치면 어떻게 될까요? A는 16을 외치지는 않을 것이고, 17 혹은 18을 외칠 것입니다. 그러면 B는 19 혹은 20을 외칠 수 있습니다. B가 19를 외치면 이길 수 있고, 20을 외치면 집니다. 확률은 50%입니다.
14를 외치면 어떻게 될까요? 경우의 수만을 생각해 봤을 때 14는 승리가 유력해지는 수입니다. 내가 지는 경우의 수는 A가 17을 외치고, B가 20을 외치는 단 한 가지입니다. 나머지 A가 15, 16을 외치거나, A가 17을 외칠 때 B가 18,19를 외치면 모두 내가 이길 수 있습니다. 내가 이길 확률은 8/9입니다. 그러나 사실은 이것보다 확률이 훨씩 낮습니다. 위에서 설명했듯이 A는 16은 절대 외치지 않을 것입니다. 그럼 A는 15와 17, 둘 중 하나를 외치게 됩니다. 그래도 경우의 수를 따지면 내가 이길 확률은 3/4입니다. 여전히 높은 수치입니다. 조금 더 생각해 보면 A는 15 혹은 17을 선택함으로써 나 혹은 B를 패자 결정자로 선택할 수 있습니다. 17을 선택하는 경우 B는 19, 혹은 20을 선택할 수 있습니다. 즉 B가 패자를 결정할 수 있게 됩니다. A가 15를 선택하는 경우 B는 17, 18을 선택해야 하고, 따라서 내가 패자를 결정할 수 있습니다. 이 경우 자연스런 공모가 생길 수 있습니다. A가 17를 선택하면 B는 A에게 감사하는 마음에 A를 패자로 만들지 않을 것입니다. A가 15를 선택하면 나는 A에게 감사하는 마음에 A를 패자로 만들지 않을 것입니다. 결국 A는 어떤 수를 말하든 패자가 되지 않을 확률이 높습니다. 한 단계 더 생각해보면 내가 14를 외침으로써 A에게 패자 결정자를 선택할 수 있는 권리를 주었다는 것을 감사해할 수 있습니다. 그래서 A는 내게 호의를 베풀 확률이 높습니다. 결국 내가 14를 외침으로써 나와 A가 공모해서 B를 패자로 만들 확률이 높아집니다.
14의 추론은 너무 지나친 생각으로 보일 수도 있습니다. 저 자신도 오버했다는 생각이 듭니다. 이런 추론이 현실이 되기 위해서는 나 뿐만 아니라 A,B 역시 이런 식으로 추론을 해야 합니다. 그리고 공모에 대한 공감대가 형성되어 있어야 합니다. 과연 이런식으로 의사결정이 이루어질까요? 알 수 없지만 이런 식으로 조금 더 진행합니다.
이제 내가 14를 외치면 나는 A와 공모해서 B를 패자로 만들 수 있다고 가정합니다. 내가 14를 외치기 위해서는 11,12,13을 외쳐서는 안됩니다. 만약 내가 11,12,13을 외치면 A가 14, B가 15를 외쳐서, 즉 A와 B가 공모하여 나를 패자로 만들 것입니다. 11,12,13은 외쳐서는 안되는 수입니다.
10은 꼭 외쳐야 하는 수입니다. 내가 10을 외치면 A가 11,12,13중 하나를 외치게 만들 수 있으며, 나와 B가 공모해서 A를 패자로 만들 수 있습니다.
7,8,9는 외쳐도 좋은 수입니다. 내가 이 숫자들을 외치면 A가 10을 외칠 것이고, 그럼 나와 A가 공모해서 B를 패자로 만들 수 있습니다.
6은 외쳐서는 안되는 수입니다. 내가 6을 외치면 A는 7,8,9중 하나를 외칠 것이고, A와 B가 공모해서 나를 패자로 만들 것입니다.
이런 식으로 계속 진행하면 첫 번째 시작하는 참가자는 3을 외쳐야 합니다. 내가 만약 3을 외치면 A는 4,5,6중 하나를 외쳐야 하고, B는 적어도 7을 외칠 수 있습니다. 그러면 나와 B가 공모해서 A를 패자로 만들 수 있습니다.

위와 같이 역방향 추론을 통해 세명의 참가자가 21외치지 않기 게임에 참가한 경우에는 3을 먼저 외쳐야 한다는 결론을 얻었습니다. 이렇게 얻어낸 결론이 어느 정도까지 유용할까요? 저는 거의 유용하지 않을 것 같습니다. 추론의 과정이 너무 복잡하고, 참가자 모두가 이런 복잡한 생각을 가져야 한다는 비현실적인 가정을 하고 있기 때문입니다. 실제로 대부분의 참가자들은 두 명이 참가하는 비교적 간단한 게임에서도 한 번에 규칙을 찾아내지 못한다고 합니다. 여러번 게임이 여러 번 반복되어야 규칙을 깨닫게 된다고 합니다. 세명이 참가할 때는 얼마나 많은 게임이 이루어진 후 이런 공모가 일어나게 될까요?

분당마라톤 클럽 검푸

aproxacs — Tue, 29 Sep 2009 11:28:23 +0900

달리기는 육체적인, 정신적인 건강을 위해 제가 선택한 운동입니다. 이 운동의 장점은 마음먹은 바로 그 때 혼자서도 할 수 있다는 점입니다. 누구나 달리기를 할 수 있기에 운동을 시작하기 위해 특별히 배울 것도 없습니다. 달리고 싶은 바로 그 때 운동화를 신고 달릴 수 있습니다. 혼자서도 달리기를 즐길 수 있고 작은 성취를 이룰 수도 있지만, 마라톤 동호회에 가입함으로써 즐거움을 배가시킬 수 있습니다. 전국 각지에 마라톤 동호회가 있습니다. 분당에 살고 있다면 분당마라톤 클럽 검푸가 있습니다.

제가 검푸에 가입한 때는 올해 7월 중순입니다. 그 이전에는 혼자 탄천을 달렸습니다. 무엇인가 부족함을 느끼면서, 풀코스에 대한 욕심이 생기면서, 같이 달릴 수 있는 동료가 필요함을 깨달으면서 검푸에 가입하게 되었습니다. 두 달 남짓 되는 기간 동안 모임에 참석하면서 얻은 것이 참 많습니다.
첫째, 달리는 방법, 운동화 끈 묶는 법, 부상에 대처하는 법, 기록향상을 위한 체계적인 훈련방법 같은 귀중한 지식을 얻었습니다. 동호회에서 만난 선배님들은 한결같이 모두 친절하게 자신의 노하우를 가르쳐 줍니다.
둘째, 꾸준함의 위대함을 다시 한번 느낍니다. 검푸는 일 주일에 세 번 훈련을 합니다. 화요일은 언덕훈련, 목요일은 트랙에서 훈련, 일요일 아침에는 장거리 훈련을 합니다. 꾸준히 훈련에 참석하다 보니 기록이 몰라보게 좋아졌습니다. 두 달 남짓 동안 10KM 기록이 4분 정도(47분->43분) 좋아졌습니다. 불가능해 보였던 풀코스 완주를 이제는 할 수 있을 것만 같습니다.
셋째, 같은 목표를 가진 동료들을 얻었습니다. 사회에서는 각기 다른 일을 하고 있지만, 검푸로 모이는 동안 우리의 목표는 하나, “달리는 것” 입니다. 그들을 바라보는 것만으로 엄청난 자극을 느낍니다. “나도 저 선배님처럼 빠르게 달리고 싶다.” 혹은 “나도 저 선배님 나이에 저렇게 달릴 수 있을까?” 라는 생각이 나를 게을러지지 않게 합니다. 또한 그들의 격려와 응원이 꾸준함을 만듭니다. 매 훈련이 기다려지게 합니다.

어떤 일을 성취하려면 다음과 같은 세 단계가 필요합니다.
1. 하고 싶다는 욕구를 갖기.
2. 그것을 이룰 수 있는 방법을 찾기.
3. 실행하기.
검푸는 그 중 두 번째 단계인 기록향상을 위한 훈련 방법을 알려 주었습니다. 그리고 무엇보다 중요한 것은 세 번째 단계인 훈련을 실행할 수 있도록 해 줍니다. 가끔 이 훈련을 혼자서도 해낼 수 있었을까? 라는 생각을 해봅니다. 대답은 쉽지 않습니다. 같은 곳을 바라보는 동료를 갖는 것. 나보다 먼저 그 길을 간 사람들의 조언을 드는 것. 이런 것들이 실행에 미치는 영향은 대단합니다.

제 또 다른 목표 중 하나는 ‘뛰어난 루비 언어 개발자 되기’ 입니다. 지금 두 번째 단계에 머무르고 있습니다. 루비 언어 개발자들 사이에도 서로 자극을 줄 수 있는 정기적인 모임이 있었으면 좋겠다는 생각을 해봅니다.

기다림에 대해서

aproxacs — Mon, 28 Sep 2009 07:58:53 +0900

엘리베이터가 처음 나왔을 때 사람들은 그 느린 속도에 불평을 했다고 합니다. 그 불평을 잠재우기 위해 엘리베이터 안에 거울을 붙여놓았다고 합니다. 그 후 사람들은 거울을 보는 데 정신이 팔려서 더 이상 엘리베이터의 속도에 대해 불평을 하지 않았다고 합니다.

사람들은 보통 기다리는 일을 싫어합니다. 그에 비에 삶은 기다림의 연속입니다. 지하철이 오기를 기다려야 하고, 탄 후에는 목적지까지 데려다 줄 때까지 기다려야 합니다. 친구를 만나기 위해 약속장소에서 기다려야 합니다. 이 페이지를 보기 위해서는 브라우져가 실행되기를 기다려야 하고, 이 페이지가 불려지는 동안 또 기다려야 합니다.

사람들은 왜 기다리는 일을 싫어할까요? 그것은 아마 기다림의 다음 두 가지 속성 때문이지 않을까 싶습니다.

첫 번째는 기다리는 시간이 아무것도 하지 않고 버려지는 시간으로 생각되어집니다. 인간은 시간을 효율적으로 사용하고 싶어합니다. 수명이 한정되어 있다는 것을 고려해 볼 때 그것은 합리적입니다. 효율적으로 시간을 보내는 사람들의 생존 확률이 더 높았을 것입니다. 그런데 기다리는 행위는 시간의 효율성을 해칩니다.
엘리베이터에서는 원하는 층에 도착할 때까지 할 수 있는 일이 전혀 없습니다. 사람은 그 시간 동안 지루함을 느끼고 시간이 낭비되어진다고 생각합니다. 이제 엘리베이터에 거울을 붙입니다. 이제 엘리베이터 안에서 할 수 있는 일이 생겼습니다. 자신의 얼굴을 바라보는 일입니다. 사람은 보통 자기 자신에게 무한한 관심을 가지고 있기 때문에 이 행위는 아주 매력적인 일입니다. 이제 더 이상 사람은 엘리베이터에서의 시간이 낭비되어진다고 생각하지 않습니다. 더불어 지루함도 느끼지 않습니다.
출퇴근 시간이 한 시간 이상 걸린다고 이야기를 하면 사람들은 시간을 절약하기 위해 이사를 할 것을 권유합니다. 보통 출퇴근과 같이 어딘가로 이동하는 시간은 의미 없는 것으로 생각되어집니다. 이동을 하면서 무엇인가를 하기가 쉽지 않기 때문입니다. 특히 꽉 막힌 길을 운전을 하는 경우가 그렇습니다. 저는 이동수단으로 지하철을 타는 것을 좋아합니다. 지하철에서는 책을 읽기가 편하기 때문입니다. 사람들의 걱정과는 달리 긴 출퇴근 시간이 제겐 고통스럽지 않습니다. 제게는 그 시간이 기다리는 시간이 아닌 책을 읽는 시간이기 때문입니다.
컴퓨터에서는 멀티태스킹 기능이 기다리는 지루함을 없애 줍니다. 10GB 나 되는 파일을 복사하는 데는 꽤 오랜 시간이 걸리지만 문제없습니다. 그 동안 웹서핑을 할 수 있으니까요.

다른 한 가지는 기다리는 것에는 불확실성이 있기 때문입니다. 내가 기다리는 그 일이 정말 일어날 것인지 언제 일어날 것인지 알 수가 없는 경우가 많이 있습니다. 미래에 대한 불확실성은 사람들을 불안하게 합니다. 예측을 할 수 없기에 계획할 수도 없고, 계속 그 일을 신경 쓰고 있어야 합니다.
예를 들어 버스를 기다리는데, 이 버스가 10분 안에 올 것인지 한 시간이 걸릴 것이지 모릅니다. 그 때 사람은 정류장에 들어오는 모든 버스의 번호를 확인합니다. 내가 타야 할 버스가 올 때까지. 버스 번호를 확인해야 하기 때문에 기다리는 동안 다른 일을 할 수 없습니다. 그리고 버스 번호를 확인하는 일은 유용한 일이라고 생각하기 힘듭니다. 이런 불확실성은 버스의 도착시간 정보를 알려줌으로써 개선할 수 있습니다. 7번 버스가 10분 후에 도착한다는 사실을 알게 되면 앞으로 7분 정도는 책을 읽으며 보낼 수 있을 것입니다.
컴퓨터 프로그램에서는 프로그래스 바가 불확실성을 없애주는 역할을 합니다. 이 페이지가 로딩되는 시간 동안 브라우저의 하단에서는 프로그래스 바가 보여집니다. 이 프로그래스 바는 당신이 요청한 작업을 지금 수행하고 있음을 알려주고 곧 끝날 것이라는 것도 알려줍니다. 인간중심 인터페이스를 보면 실행시간이 0.25초가 넘는 작업의 경우에는 프로그래스를 보여줄 필요가 있다고 합니다.

정리하면, 어떤 제품을 만들거나, 프로그램을 만들 때는 사용자를 기다리지 않도록 해야 합니다. 그것이 불가능 하다면 – 아마 대부분의 경우 불가능할 것입니다. – 기다리는 동안 할 수 있는 일을 만들어 주어야 합니다. 그리고 얼마나 기다려야 하는지도 알려줘야 합니다. 그리고 자신의 삶이 보다 효율적으로 되기를 원한다면, 책읽기와 같이, 자신에게 기다림이 주어졌을 때 홀로 할 수 있는 일들을 준비해 가지고 다녀야 합니다.

접근성(Accessibility)

aproxacs — Thu, 17 Sep 2009 23:50:35 +0900

지난주 UI study 시간에는 접근성 이란 주제를 가지고 토론이 있었습니다. 부끄럽게도 저 혼자만 접근성에 대한 개념이 없었습니다. 다행인 것은 부끄러운 기억은 오래 남기에 아마도 접근성에 대한 좋은 이야기들은 쉽게 잊혀지지 않을 듯 싶습니다.

접근성(Accessibility)은 제품을 얼마나 많은 사람들이 사용 가능한가를 나타냅니다. 위키피디아를 참조해 보면 접근성은 주로 장애인들도 사용할 수 있는가에 초점을 맞추는 것으로 보입니다. 잘 안보여도, 한 손이 불편해도, 들을 수 없어도 그 제품을 사용할 수 있다면 그 제품은 접근성이 좋은 것입니다. 이렇게 다양한 사람들이 제품을 사용하기 위해서는 사용방법을 또한 여러 가지로 제시해야 합니다. 따라서 접근성은 제품을 얼마나 다양한 방법으로 사용할 수 있는가라는 말로도 표현할 수 있습니다.
정수기에서 물 나오는 부분을 예로 들어 봅시다. 구형 정수기는 물을 받기 위해 두 손이 필요했습니다. 한 손으로는 컵을 잡고 한 손으로는 물 나오는 버튼을 눌러야 했습니다. 오른쪽 그림과 같은 요즘 정수기는 한 손만으로도 물을 충분히 받을 수 있습니다. 물 나오는 버튼을 컵을 이용해서 밀어서 누를 수 있습니다. 이와 같은 디자인은 두 손 사용자는 물론이고 한 손만 사용이 가능한 사람들도 쉽게 물을 받아 먹을 수 있게 해 줍니다.

웹의 경우에는 제품을 정보로 생각해 볼 수 있습니다. 그리고 제품을 사용하는 다양한 방법을 정보에 접근하는 다양한 방법으로 생각해 볼 수 있습니다. 나의 일정에 대한 정보가 구글의 서버 어딘가에 있습니다. 이 정보에 접근하기 위한 기본적인 방법은 파이어폭스와 같은 브라우저를 이용하는 것입니다. 이 때 브라우저를 사용하는 사람이 눈이 불편해도, 잘 안들려도 일정을 확인할 수 있다면 접근성이 좋다고 할 수 있습니다. 어떤 사람은 PC가 아닌 모바일을 통해 구글의 일정을 확인하려고 할 수 있습니다. 어떤 사람은 아웃룩 프로그램을 통해 확인하려 합니다. 어떤 사람의 PC는 인터넷에 연결되어 있지 않습니다. 이 모든 사람들이 일정을 확인할 수 있다면 그것은 접근성이 좋은 것입니다. 웹의 경우 접근성을 매우 높일 수 있는 한 가지 효과적인 방법은 Open API를 제공하는 것입니다.

이쯤에서 정리를 하면, 접근성이 높은 제품은 그 제품을 사용하는 다양한 방법을 제공함으로써 누구라도, 어떤 환경에서라도 제품을 사용할 수 있는 것을 말합니다. 디자이너는 접근성 100%, 즉 모든 사람들이 사용할 수 있는 제품을 만드는 것을 목표로 합니다.

이제부터는 현실적인 이야기를 하도록 하겠습니다. 현재 90%의 사용자가 만족하며 사용할 수 있는 제품이 있습니다. 이 제품은 접근성의 측면에서 봤을 때 10%정도의 개선의 여지가 있습니다. 접근성을 향상시킬 여지가 있으니 개선을 해야 합니다. 그러나 한편으로는 개선을 통해 얻는 이익이 노력에 비해 작다면 개선의 의지는 줄어들게 마련입니다.

접근성 향상에는 한계효용 체감의 법칙이 작용합니다. 40%에서 50%로 향상시키는 것은 작은 노력으로 큰 효과를 얻을 수 있지만, 95%에서 96%로 향상시키는 것은 큰 노력이 필요하지만 얻는 효과는 작습니다. 그래서 현실에서는 100%를 목표로 하지 않고, 적당한 선에서 타협을 하게 됩니다. 그 타협은 매우 합리적이라고 생각됩니다. 모든 장애인들이 웹페이지를 사용할 수 있으면 좋겠지만, 그러기 위해서 드는 비용이 이익을 보장하지 못한다면 기업은 웹페이지를 개선할 필요를 느끼지 못합니다. 이런 측면에서 봤을 때 복지국가를 목표로 하는 한국에서 장애인차별 금지법의 제정은 적절하다고 볼 수 있습니다. 기업이 움직여야 할 동기를 제공하고 있기 때문입니다.

인간중심 인터페이스 4장 정량화

aproxacs — Sun, 06 Sep 2009 21:00:52 +0900

다음은 UI study 에서 진행한 인간중심 인터페이스 스터디 중 4장 정량화에 대한 내용입니다.

정량분석

인터페이스 디자인의 좋고 나쁨을 어떤 기준을 통해 수치화시키는 작업을 정량화라고 합니다.

왜 필요한가?

디자인을 평가할 때 "예쁘다", "편하다" 와 같은 막연한 표현 대신 숫자를 이용해 비교를 함으로써 논란을 줄여 줍니다.
구체적인 근거를 제시함으로써 상대방을 설득하기 쉬워집니다.
인터페이스를 더 나은 방향으로 개선해 나가고 있는지 확인을 할 수 있고, 더 개선할 여지가 있는지 알 수 있습니다.

책에서는 정량분석에 대한 방법으로 GOMS(model of goals, operations, methods, and selection rules), Raskin의 효율 측정, Hick의 법칙, Fitts의 법칙을 소개합니다.

주의) 정량분석은 절대적인 기준이 될 수 없으며, 정성분석과 같은 다른 방법론들과 균형을 맞추어야 합니다.

GOMS 모델

GOMS 모델은 어떤 작업(task)을 수행할 때 걸리는 총 시간을 계산하는 방법을 제시하고 있습니다. 그 방법은 다음과 같습니다. 하나의 작업을 연속적인 기본 제스처의 단위로 나눕니다. 그리고 그 기본 제스처들의 수행시간을 모두 더합니다. 기본 제스처들의 수행시간은 실험을 통해서 얻어낼 수 있습니다. 수행시간은 보통 평균값을 사용합니다.

기본 제스처는 다음과 같은 것들이 있습니다.

키누름시간(K) : 0.2초
포인팅시간(P) : 1.1초
호밍시간(H) : 0.4초
정신적 준비시간(M) : 1.35초
반응시간(R) :

아이폰 같은 터치 인터페이스가 보편화됨에 따라 기본 제스처에 터치, 흔들기와 같은 것들도 포함될 수 있겠습니다.

효율성 측정

정보량을 기준으로 인터페이스가 얼마나 효율적인가를 측정할 수 있습니다. 인터페이스의 효율성은 다음과 같은 공식에 의해 계산되어집니다.

정보 효율성 = 작업을 수행하기 위해 꼭 필요한 정보량/사용자가 제공한 정보량

javascript의 경고창(alert) 과 같이 확인 버튼 하나만 있는 경우는 필요한 정보량이 0이 되기 때문에 효율성도 0입니다.

예를 들어 숫자 하나를 키보드로 입력받는 입력창의 효율성은 다음과 같이 계산됩니다.

꼭 필요한 정보량은 숫자 하나에 대한 가지 수 만큼입니다. 0-9까지 10개의 숫자가 있고 따라서 정보량은 log2(10) = 2.3 입니다. 즉 숫자 하나를 입력받기 위해서는 최소한 2.3byte가 필요합니다.

100 개의 자판을 가진 키보드를 이용해 숫자를 입력한다고 하면, 숫자를 입력하기 위해 사용자가 제공하는 정보량은 log2(100) = 6.7 정도 입니다.(키 하나하나 눌려지는 확률이 동일하다고 가정합니다.) 즉 사용자는 숫자 하나를 입력하기 위해 100개의 자판 중 하나를 선택해야 하고, 그 가지 수를 표현하기 위해서는 6.7byte가 필요합니다.

그래서 정보 효율성은 2.3/6.7 = 0.34 입니다.

이와 같은 경우 정보 효율성을 개선하기 위한 간단한 방법으로는 숫자 전용자판을 이용하는 것입니다.

문자 효율성은 정보를 문자의 갯수로 한정시킴으로써 효율성을 보다 간편하게 구할 수 있게 해 줍니다.

문자 효율성 = 작업에 필요한 최소 문자수/사용자에게 요구하는 문자수

Fitts 법칙

Fitts 법칙은 어떤 표적을 얼마나 쉽게 선택할 수 있는지를 측정할 수 있도록 해줍니다.

즉 표적이 클수록, 표적과의 거리가 가까울 수록 선택하기 쉽다는 의미입니다.

T = a + b*log2(D/S +1)
T : 선택하는데 걸리는 시간
D : 커서와 표적 사이의 거리
S : 표적의 크기
a,b : 실험에 의해 특정된 상수

예를 들어 폼의 확인 버튼을 디자인 할 때 클릭하기 쉽게 하도록 하기 위해서는 버튼을 크게 만들고, 버튼을 폼의 마지막 입력 창과 가깝도록 만들면 클릭하기 쉬워집니다.

그 비율이 log로 증가하고 있다는 것이 흥미롭습니다. 아주 작은 버튼을 조금 크게 만들면 클릭이 확 쉬워지는 반면, 충분히 큰 버튼을 더 크게 만드는 것은 그 개선 효과가 미미해집니다.

가장자리

화면 중 가장자리 부분은 Fitts 법칙에 의해 특혜를 보고 있는 공간입니다. 화면의 가장자리는 마우스 커서가 더이상 이동할 수 없는 지역이기 때문에 더 넓은 표적의 크기를 가지게 됩니다. 무슨 뜻이냐면, 화면의 최상단에 상태바가 있다고 가정할 때, 이 상태바를 선택하기 위해서 마우스를 과감하게 이동시켜도 커서가 화면을 뚫고 지나가지 못하고 화면의 최상단에 위치하게 됩니다. 그래서 가장자리에 위치한 버튼은 약 5cm정도 크기를 더 갖는 효과를 볼 수 있습니다.

Fitt의 법칙을 적용한 다양한 예를 보실 수 있습니다.

1. 메뉴 네비게이션

하위 메뉴를 상위 메뉴근처에 보여줍니다. 따라서 하위 메뉴를 선택하기 쉬워집니다.

2. 맥의 화면 상단에 위치한 메뉴바

맥 에서는 화면의 최상단에 위치한 메뉴바(File, Edit..)가 애플리케이션의 메뉴입니다. 이는 Fitt의 법칙을 잘 따른 구현으로 메뉴를 선택함에 있어서는 효율적이지만, 직관적인 면에서는 좋지 않은 듯 합니다. 직관적인 면에서는 애플리케이션에 메뉴를 포함시킨 윈도우의 방식이 더 좋아 보입니다.

3. 맥에서의 hot spot

화면 네 구석에 자주 사용하는 메뉴를 지정할 수 있습니다.

4. 윈도우의 시작버튼

윈도우의 시작버튼도 가장자리 효과를 이용하고 있습니다. 다만 잘못 베꼈다는 날카로운 지적도 있네요.

Hick의 법칙

Hick의 법칙은 선택의 가지 수가 많아질 수록 선택을 하는데 걸리는 시간이 더 많아진다 입니다. 복잡한 결정을 내릴 때가 간단한 결정을 내릴 때보다 더 많은 시간이 걸립니다. Hick의 법칙은 다은과 같은 공식으로 표현됩니다.

T = a + b*log2(n+1)
T : 선택을 하는데 걸리는 시간
n : 선택의 가지 수
a,b : 상수

Fitt의 법칙과 마찬가지로 시간이 선택 갯수의 log에 비례한다는 것이 흥미롭습니다. 3개에서 6개로 메뉴가 늘어날 때 느껴지는 복잡도가 50개에서 70개로 늘어날 때 느껴지는 복잡도보다 더 큽니다.

결론

모든 인터페이스를 정량분석을 통해서 측정할 수는 없겠지만, 그리고 현실적으로 거의 이루어지지 않고 있지만, 이 방법을 알고 인터페이스를 만드는 것과 모르고 만드는 것에는 큰 차이가 있을 것입니다.

책에 나온 한 구절을 통해 내용을 정리합니다.

정량분석을 통하지 않고는 우리의 작업이 얼마나 잘 진행되고 있는지, 개선의 여지는 없는지 도무지 알 방법이 없다.

지난 주말 Apache와 Tomcat의 연동에 대해 알아보게 된 이유

aproxacs — Sun, 06 Sep 2009 18:38:36 +0900

그 과정은 다음과 같다.

달리기한 내용을 기록하고 그 기록들을 확인할 수 있는 간단한 웹서비스를 만들고 싶었다. 기록할 수 있는 폼, 기록을 볼 수 있는 페이지. 일단 이것으로 될 것 같다. 그러기 위해 rails 프로젝트를 생성하고, 사용하고 싶었던 gem과 plugin들을 떠올려 봤다. rspec, jquery, authlogic, cucumber, compass, haml 등등.. 그러던 중 이런 내용들을 할 일 목록을 통해 정리를 해 놓으면 좋을 것 같았다. 그래서 내가 알고 있는 가장 좋은 이슈 관리 시스템인 jira를 설치했다. 이왕 하는 거 jira 서버에 도메인을 하나 주면 좋겠다. 그래서 jira를 개인 비서처럼 사용하면 좋을 것 같았다. jira는 톰캣을 사용하니까 apache와 tomcat을 연동하면 될 것 같다. 그래서 토요일 오전 내내 fedora 서버에 tomcat을 설치하고, 설정하고, apache에 대해 알아보면서 시간을 보냈다.

개발자들은 무엇인가를 만들기 위해 필요한 연장을 먼저 만드는 경향이 있다고 한다. 그 연장은 무엇인가를 쉽게 만들 수 있게 해 줄 것이고, 두고두고 유용하게 사용될 것이다. 분명히 그럴 것이다. 문제는 그 연장을 만들다 보면 연장을 만들기 위한 또 다른 연장을 만들 필요를 느낀다. 이런 식으로 연장의 연장을 만드는 일이 계속된다. 정작 만들고자 하는 무엇인가는 미루어진 채.

지금의 내겐 달리기 내용을 기록하는 간단한 웹 페이지가 언제 만들어질 지 도무지 모르겠다. 버전 관리 시스템을 정해야 하고, 배포를 어떻게 할 지 정해야 한다. 이런 것들이 지금 꼭 필요한 일일까? 이런 고민에 또 한동안 시간을 보낸다. 그러다가 결국에는 생각나는 것은 뭐든지 해보기로 했다. 개인적인 일이니까, 빨리 하지 않아도 되니까, 뭐라도 하면 뭐라도 얻게 될 테니까. 그러나 일정의 지연이 조직 혹은 개인의 이익과 연관된다면 문제는 달라진다. 그 때 필요한 것은 어느 정도의 연장까지 만들 것인지를 신속하게 정하는 것이다. 누군가가 그 일을 아주 잘 해 낸다면 프로젝트는 편하게 진행될 수 있다. 프로젝트의 일정을 아무리 넉넉하게 잡아도 결국에는 마감에 쫓기게 된다고 말하는 사람도 있다. 그것은 아마 일정 안에 해야 할 일이 막연하기 때문은 아닐까? 일정을 지키기 위해 정말 필요한 것은 해야 할 일들을 명확히 정하는 것이다.

Userfly : 사용자의 동작을 지켜보자.

aproxacs — Thu, 03 Sep 2009 23:23:06 +0900

직접적인 사용자 테스트는 개발/기획 단계에서 생각하지 못했던 문제들을 손쉽게 알려 준다. 개발자의 관점이 아닌 사용자의 관점에서 프로그램을 어떻게 바라보는지 알 수 있게 해 준다. 사용자가 기능을 어떻게 이해하는지, 어떤 부분에서 어려움을 느끼는지 확인할 수 있다. 다만 사용자 테스트를 하기 위해서는 어느 정도의 준비가 필요하다. 적당한 사용자를 포섭해야 하고, 테스터는 그 사용자의 행동을 볼 수 있어야 한다. 다행인 것은 문제점들을 확인하기 위해서 많은 사용자를 대상으로 사용자 테스트를 할 필요는 없다고 한다. Jakob Nielen 의 글을 보면 6명의 사용자가 프로그램을 사용하는 것을 지켜보면 프로그램의 문제점들을 대부분 알 수 있다고 한다.

웹서비스를 개발하고 있다면, 여기 사용자 테스트를 위한 한 가지 멋진 툴이 있다. Userfly 는 사용자의 행동들 – 마우스 이동/클릭, 키보드 입력 – 을 저장해서 나중에 확인할 수 있게 해 준다. 즉 사용자가 사이트에 들어와서 한 행동들을 다시 재현할 수 있다. userfly의 사용방법은 매우 간단하다. 회원가입 하면 제공되는 javascript 코드를 페이지의 <head> 태그 안에 넣어주기만 하면 된다. 이 때부터 들어오는 사용자의 행동들이 기록되기 시작한다. 기록된 내용은 userfly 사이트에서 확인할 수 있다.

userfly.com from Chris Estreich on Vimeo.

userfly 사이트에서는 기록된 내용을 확인할 수 있을 뿐만 아니라, 기록을 잠시 중단 할 수도 있고, 특정 IP에 대해서 기록을 하지 않도록 설정할 수도 있다. 무료 사용자는 한 달에 10개의 사용자 기록을 저장할 수 있다. 10개 이상을 저장하고 싶다면 유료 모델로 전환해야 한다. 값은 비교적 저렴하다. 1000개를 기록하는데 25$이다.

사용하면서 아쉬웠던 점들은

userfly는 굉장히 무거운 javascript를 사용하고 있는 듯 하다. 모든 사용자 행동들을 userfly 서버로 전송해야 할 테니 그럴 만도 하다. 그래서 IE6에서는 티가 날만큼 느려진다.
javascript를 제대로 재현하지 못하는 듯이 보인다.

CSS를 이용해서 프린트 친화적인 페이지 만들기

aproxacs — Wed, 02 Sep 2009 17:38:58 +0900

CSS와 HTML 구성한 웹페이지가 있다. 이 페이지를 프린터로 출력을 하면 내가 보고 있는 페이지 그대로 출력이 될까? 화면 그대로 출력되지 않는다면 얼마나 비슷하게 나올까?

CSS를 이용해서 프린터 친화적인 페이지를 만들어 보자. 출력을 위한 CSS는 다음과 같이 media를 print로 해 주어야 한다.

<link type="text/css" rel="stylesheet" media="print" href="/stylesheets/print/coupon.css"/>

화면을 위해서는 media를 screen으로 해 준다.

<link type="text/css" rel="stylesheet" media="screen" href="/stylesheets/print/coupon.css"/>

화면에 보이는 그대로 출력을 하고 싶다면 위 두 태그를 모두 사용한다.

페이지를 멋지게 꾸민 후 인쇄하기 버튼을 만들어서 이 버튼을 누르면 인쇄 창이 나오도록 해 주자. 이것은 javascript를 이용해서 할 수 있다.

<a onclick="window.print(); return false;" href="#">인쇄하기</a>

페이지를 만들 때 주의해야 할 것은

프린터는 background 프로퍼티를 무시한다. 이 프로퍼티는 사용하지 말자. 그대신 position: absolute 같은 것들은 잘 동작한다. 이들을 이용해서 이미지 위에 다른 element를 위치시킬 수 있다.

[rails] will_paginaton 의 paginator의 URL을 변경하기

aproxacs — Thu, 20 Aug 2009 06:57:54 +0900

will_paginator gem은 페이지네이션을 너무나 간편하게 만들어준다. 데이터를 찾기 위해서는 find대신 paginate 메소드를 사용하기만 하면 되며, view에서는 will_paginate 라는 helper method를 이용해 pagination을 간단히 구현할 수 있다.

# controller
@posts = Post.paginate :page => params[:page]
# view
<%= will_paginate @posts %>

will_paginate 메소드는 똑똑하게 다음과 같은 식의 페이지네이터를 만들어낸다.

이 때 1,2,3과 같은 페이지네이터 숫자에 사용되는 URL은 현재 페이지의 URL과 기본형이 같다. 같은 protocol, host, port, controller, action, id를 사용하고 파라미터로 붙는 :page 파라미터만 적절히 변경된다. 즉 이 페이지가 http://app.com/posts 라고 하면 2 페이지의 link는 http://app.com/posts?page=2가 된다. 때때로 이 페이지네이터의 기본 URL을 페이지의 URL과 다르게 사용하고 싶은 경우가 있다. 이 때는 will_paginate method의 :params 옵션을 이용할 수 있다.

예를 들어 현재 페이지의 URL이 http://app.com/community 이고, 페이지네이터에서는 http://app.com/posts?page=2 와 같은 식의 URL을 사용하고 싶은 경우,

will_paginate @posts, :params => {:controller=>”posts”}

이런 식으로 할 수 있다.

만약 posts를 routes.rb에 resouces로 정의해 놓았다면(RESTful), 그래서 :controller와 :action 에 어떤 것을 써야할지 잘 모르겠다면, hash_for_XXX_url 메소드를 이용할 수 있다.

will_paginate @posts, :params => hash_for_posts_path

이번엔 host 와 port도 바꾸어야 할 필요가 있다면, 다음과 같이 :host 파라미터를 이용한다.

will_paginate @posts, :params => hash_for_posts_path.merge(:host => "aaa", :only_path=>false)

only_path를 false로 해야만 host를 포함한 URL이 사용된다.

will_paginate의 소스를 따라가다 보면 :params 의 내용이 그대로 ActionView::Helpers::UrlHelper#url_for 로 넘어가고 있음을 알 수 있다.