BLOG main image
분류 전체보기 (239)
Rails (65)
Ruby (34)
이야기 (40)
스토리큐 (61)
그 밖에.. (30)
C# (6)
드리밍 인 코드
The note of Legendre
작은아이의 생각
agiletalk's me2DAY
[rails] Growl4Rails
美소년 ㅇㅅㅇ씨의 一日
마사키군의 생각
ayukawa's me2DAY
작은아이의 생각
agiletalk's me2DAY
63,404 Visitors up to today!
Today 9 hit, Yesterday 22 hit

 SUBSCRIBE

'이야기'에 해당되는 글 40건
2009/10/04 11:08


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

codfish_6997_lg 300px-Map_of_USA_New_England.svg


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

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

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

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

2009/10/03 19:51


여기 게임이 하나 있습니다. 게임 참가자는 두 명입니다. 참가자는 숫자 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을 먼저 외쳐야 한다는 결론을 얻었습니다. 이렇게 얻어낸 결론이 어느 정도까지 유용할까요? 저는 거의 유용하지 않을 것 같습니다. 추론의 과정이 너무 복잡하고, 참가자 모두가 이런 복잡한 생각을 가져야 한다는 비현실적인 가정을 하고 있기 때문입니다. 실제로 대부분의 참가자들은 두 명이 참가하는 비교적 간단한 게임에서도 한 번에 규칙을 찾아내지 못한다고 합니다. 여러번 게임이 여러 번 반복되어야 규칙을 깨닫게 된다고 합니다. 세명이 참가할 때는 얼마나 많은 게임이 이루어진 후 이런 공모가 일어나게 될까요?
2009/09/29 11:28

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

 logo_title

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

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

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

2009/09/28 07:58

Elevators at 240 Sparks

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

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

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

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

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

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

'이야기' 카테고리의 다른 글

역방향 추론  (0) 2009/10/03
분당마라톤 클럽 검푸  (0) 2009/09/29
기다림에 대해서  (0) 2009/09/28
접근성(Accessibility)  (0) 2009/09/17
지난 주말 Apache와 Tomcat의 연동에 대해 알아보게 된 이유  (0) 2009/09/06
TDD의 요건  (0) 2009/06/09
2009/09/17 23:50

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

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

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

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

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

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

'이야기' 카테고리의 다른 글

분당마라톤 클럽 검푸  (0) 2009/09/29
기다림에 대해서  (0) 2009/09/28
접근성(Accessibility)  (0) 2009/09/17
지난 주말 Apache와 Tomcat의 연동에 대해 알아보게 된 이유  (0) 2009/09/06
TDD의 요건  (0) 2009/06/09
아이콘 : 스티브 잡스  (0) 2009/05/21
2009/09/06 18:38

그 과정은 다음과 같다.

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

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

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

'이야기' 카테고리의 다른 글

기다림에 대해서  (0) 2009/09/28
접근성(Accessibility)  (0) 2009/09/17
지난 주말 Apache와 Tomcat의 연동에 대해 알아보게 된 이유  (0) 2009/09/06
TDD의 요건  (0) 2009/06/09
아이콘 : 스티브 잡스  (0) 2009/05/21
넛지(Nudge)  (0) 2009/05/20
2009/06/09 06:16

ruby on rails로 개발할 때에 이어 C#을 이용하는 지금도 테스트 코드를 쓰고 있다. rails로 개발할 때는 rspec만이 최고이고 다른 환경에서는 테스트를 쓰기가 어렵지 않을까 라는 생각을 가졌었는데, 분명히 그렇지 않은 것으로 판명되었다. C#으로 개발하는 요즘 테스트 코드 쓰는 것에 상당한 재미를 느낀다. 언어 자체를 봤을 때는 ruby가 C#보다 훨씬 더 유연하다. 그래서 mocking을 할 때 편한 것은 사실이다. 약간 불편함, 그리고 낯설음이 있음에도 불구하고 C#으로 테스트를 쓰는 것이 편하게 느껴지는 이유가 무엇일까 생각해 본다.

우선 테스트 수행속도를 들 수 있다. C#에서는 테스트 수행 속도가 매우 빠르다. 결과를 곧바로 알 수 있어서 진행에 막힘이 없다. 테스트 주도 개발은 테스트를 쓰고 실패하는 테스트를 보고, 실제 코드를 쓰고 성공하는 테스트를 보는 일을 계속 반복해야 한다. 이 때 테스트 속도가 느리다는 것은 큰 문제가 된다. rails는 테스트 속도가 느린 편이다. 속도를 빠르게 하기 위해서는 drb를 사용해야 한다. 좋아하는 IDE가 drb를 제대로 지원하지 못하는 경우가 있는데, 난감하다.
한 테스트 단위로 실행할 수 있는 것도 편리하다. 내가 수정한 테스트만 실행하면 테스트 수행 속도도 빨라진다. rails로 개발할 때는 autotest를 사용해서 수정된 부분에 해당하는 테스트만 실행하도록 할 수 있었다.

테스트 수행속도와 더불어 테스트 결과를 보여주는 UI도 매우 중요하다. 깔끔한 Red-Green 테스트 결과를 볼 수 있는 것은 코드를 작성하는데 리듬을 살려준다. 이 때 실패한 테스트의 스택 트레이스와 바로가기 링크는 필수다. Resharper가 보여주는 테스트 결과는 훌륭하다. 좋은 IDE는 개발의 즐거움은 물론이고, 생산성도 크게 향상시킬 수 있다. Resharper의 단축키, 인텔리 센스, 메소드 스텁기능, 그리고 빠른 속도 모두 프로그래밍에 재미를 준다.

좋은 테스팅 프레임웍도 테스트 코드를 쓰는 것을 즐겁게 해 준다. ruby에서의 rspec. C#에서 사용한 xunit.net과 moq. 두 프레임웍은 rspec만큼은 아니지만 테스트 코드를 간결하게 작성하는데 도움을 준다.

언어 자체가 가지고 있는 간결함, 그리고 유연함도 언급하지 않을 수 없다. rspec을 사용할 때 무엇이든 mocking가능하다는 사실은 테스트를 훨신 수월하게 쓸 수 있도록 한다. 반면 moq의 제약사항(virtual 메소드와 interface만 mocking할 수 있다.)는 좀 답답함을 느끼게 한다.

정리하자면 테스트를 즐겁게 쓰기 위해서는 테스트 수행 속도, 좋은 UI가 매우 중요하다. ruby 언어가 더 유연하고 rspec이 뛰어남에도 불구하고 C#에서 테스트를 쓰는 것이 ruby 못지 않게 재미있었던 이유는 좋은 테스트 UI와 실행속도 밖에 없다.

'이야기' 카테고리의 다른 글

접근성(Accessibility)  (0) 2009/09/17
지난 주말 Apache와 Tomcat의 연동에 대해 알아보게 된 이유  (0) 2009/09/06
TDD의 요건  (0) 2009/06/09
아이콘 : 스티브 잡스  (0) 2009/05/21
넛지(Nudge)  (0) 2009/05/20
독서법  (0) 2009/05/20
2009/05/21 05:55

8937425475_1

스티브 잡스의 일생에 대한 이야기입니다. 잡스의 학창시절부터 현재에 이르기까지 그가 이루어낸 성공, 실패, 에피소드들이 400페이지에 걸쳐 쓰여져 있습니다. 이야기가 너무나 흥미로워서 잠을 자는 시간을 기꺼이 줄이게 됩니다. 마치 행복한 결말을 알고 있는 헐리우드의 블록버스터 영화를 보는 기분이었습니다.

애플을 창업하고 결국 대단한 성공을 이루었지만, 그는 좋지 않은 습성을 많이 가지고 있습니다. 보통 성공하는 사람이라면 가지지 말아야 한다고 알고 있는 그런 단점들. ‘혼자 결정하기’, ‘잘 삐치기’, ‘고집 부리기’, ‘변덕’, ‘주변 사람들과 잘 싸우기’. 이런 엄청난 약점에도 불구하고 그는 장점을 더욱 부각시켜서 커다란 성공을 이루어 냅니다. ‘열정적으로 일하기’, ‘비전을 제시하고 믿게 만들기’, ‘포기하지 않기’, ‘뛰어난 실행능력’. 놀라운 일입니다. 그의 삶은 마치 이렇게 이야기하는 듯 합니다.

열정. 대단한 것을 만들 수 있다는 믿음. 성공을 위해 그 외 다른 것들은 별로 중요하지 않다.

매킨토시, 픽사 애니메이션, 성공하는 프로젝트 속에는 한결같이 열심히 일하는 참여자들이 있었습니다. 모든 것을 쏟아 붓는 열정. 그 열정이 성공의 보증 수표는 물론 아닐 것입니다. 그럼에도 그 열정을 느낄 때면 내 가슴도 콩닥콩닥 뛰고 있음을 알게 됩니다. 나도 그 격정의 시간과 공간에 머물러 있었으면…

책 중반에 나온 픽사의 인사원칙이 인상적입니다.

"우리보다 나은 사람을 뽑는다"

'이야기' 카테고리의 다른 글

지난 주말 Apache와 Tomcat의 연동에 대해 알아보게 된 이유  (0) 2009/09/06
TDD의 요건  (0) 2009/06/09
아이콘 : 스티브 잡스  (0) 2009/05/21
넛지(Nudge)  (0) 2009/05/20
독서법  (0) 2009/05/20
스티브 잡스의 신의 교섭력  (0) 2009/05/16
2009/05/20 23:28

강제적이지 않은 방법으로 어떤 행동을 이끌어내는 힘.

예를 들면 변기 사진 속의 파리그림. 넛지를 가장 잘 설명하는 사진인 듯.

355810066_3154216306

이 파리그림 하나가 변기 밖으로 튀는 소변의 양을 80% 줄였다고 합니다.

'이야기' 카테고리의 다른 글

TDD의 요건  (0) 2009/06/09
아이콘 : 스티브 잡스  (0) 2009/05/21
넛지(Nudge)  (0) 2009/05/20
독서법  (0) 2009/05/20
스티브 잡스의 신의 교섭력  (0) 2009/05/16
침묵의 카드 게임  (0) 2009/05/15
2009/05/20 05:37

평균적으로 하루에 한 시간 정도 책을 읽습니다. 그 시간은 주로 퇴근하는 지하철 안에서와 잠자리에 들면서입니다. 주말에는 시간을 조금 더 낼 수 있습니다. 이렇게 찔끔찔끔 책을 읽다 보니, 책을 읽고 감상문을 쓰려고 하면 무슨 내용인지 정리가 잘 안됩니다. 읽으면서 마음에 들었던 문장, 가졌던 생각이 다 읽고 난 후에는 날아가 버립니다. 책을 오랜 기간 동안 읽은 경우에는 무슨 내용인지 완전 잊어 버립니다.

alankang 님은 좋은 독서 방법을 사용하고 있습니다.. 그 방법은 책을 읽으면서 마음에 드는 곳을 줄을 그어서 표시합니다. 그리고 그 내용을 위키에 옮겨 적습니다. 그리고 관련 글과 링크를 겁니다. 줄 긋기 대신 포스트잇을 사용하시는 분도 계시군요.  북다트라는 것도 있네요.

책을 두 번씩 읽는다는 분도 있습니다. 두 번 읽음으로써 기억을 더 오래가게 만들 수 있습니다.

읽은 기간을 책 앞에 표시해 두시는 분도 있습니다. 책 읽는 재미를 좀 더 높여주는 효과, 책을 질질 끌지 않게 되는 효과를 기대할 수 있습니다.

중요한 부분을 표시해 놓았다가 다시 한번 음미하는 단계가 필요한 듯이 보입니다. 따라 해 봐야겠습니다.

  1. 책을 읽으면서 마음에 드는 부분을 포스트잇으로 표시하면서 생각을 적는다.
  2. 표시한 부분을 틈틈히(매일) 노트에 옮겨 적는다.
  3. 책을 다 읽은 후에는 감상문을 쓴다.

'이야기' 카테고리의 다른 글

아이콘 : 스티브 잡스  (0) 2009/05/21
넛지(Nudge)  (0) 2009/05/20
독서법  (0) 2009/05/20
스티브 잡스의 신의 교섭력  (0) 2009/05/16
침묵의 카드 게임  (0) 2009/05/15
사진빨 받은 진이  (0) 2009/05/13