예전 농담입니다.
세상엔 10종류의 사람이 있다. 이진수를 이해하는 자와 그렇지 않은자.
소프트웨어 개발자처럼 또렷한 이미지를 가진 직업이 또 있을까요.
미국에서는 geek이라 불리우고, 우리 나라식으로 치면 장인정신이 투철한 사람들이기도 합니다. 고집 세고, 기술에 대한 집착과 '자기들'만의 세계가 명확한 이들 말입니다.
저도 한때 vi와 telnet (고백컨대 rlogin을 더 선호)이면 즐거웠고, rss보다 더 긴 thread의 usenet을 리더로 읽기도 했었습니다.
심지어, "What is your second language?" 란 질문에 "C." 라고 썰렁한 농담을 하기도 했지요.
열전달 숙제의 간단한 미분방정식을 풀 때는 어땠냐면. 쉬운길 놔두고 유한차분법을 사용한 수치해석과 허큘리스 그래픽카드에서의 시뮬레이션한다고 담배와 커피로 밤새워가며 코딩에 열을 올리기도 했습니다. (갈수록 geek스러운 추억이 새삼 떠올라 여기서 그만.)

20년전 잠시 머물렀던 그 세상인데, 세월이 흐르고 job이 바뀌니 다시 외부적 시선으로 개발자를 이해하게 됩니다. 커피와 도넛속에 파묻힌 영화속 이미지말입니다.
봄에 개발자들과 연봉계약을 하며 많은 면담을 했고, 개발자의 독특한 관점들이 새롭게 다가왔습니다. 마침 '완벽한 컨설팅'의 추천사를 썼던 인사이트 출판사에서 재미난 제목의 책을 소개해 주셨길래 개발자들 생각하며 한권 청해 읽었습니다.

사용자 삽입 이미지

David Platt

(원제) Why software sucks... and what you can do about it

물론 책은 개발자 자체보다, 사용성(usability)이 주제입니다.
프로그래머가 코드 만들던 끝에 지정해 놓은 암호같은 오류 메시지와 내부 구조 의존적인 복잡한 사용법을 왜 사용자가 배워야 하는가를 묻습니다. 이를 위해 PC 소프트웨어에서 웹 프로그래밍, 보안 관련한 구체적인 사례를 가지고 설명합니다.

파일을 지우려면, '정말 삭제하겠냐고' 묻는 짜증나는 메시지, 텍스트를 수정하면 저장하겠냐는 상투적인 물음에 왜 사용자가 대답해야 하는지 생각해 볼 필요가 있습니다.
이뿐인가요. 수많은 입력폼을 채워놓고 서버 오류 메시지와 함께 날려먹는 웹 프로그램, 구매가 되었는지 안 되었는지 참 궁금하게 만드는 어정쩡한 구매 프로세스 등 사례는 충분합니다.
그동안 그러려니 했던 부분을 테이블에 올려놓고 곰곰히 따져봅니다.

저자의 견해로 마우스에 버금가는 최고의 발명품은 UNDO 기능이랍니다. 수긍갑니다. 사용자는 소프트웨어 구조가 아니라 목적을 달성하기 위해 이리저리 실험해보는 정신적 모형을 따라 행동합니다. heuristic이라 부르건 hypertext적이라 부르건 중요하지 않습니다. 소프트웨어는 그런 모델에 맞춰 작동하고 실수하면 간단히 UNDO 할 수 있으면 그 뿐이니까요.

보안도 마찬가지입니다. 패스워드의 보안성을 높인다고, 특수문자를 강제로 쓰게/못쓰게 하거나, 주기적으로 변경을 강요하거나 하는 모든 행동은 사용자를 더 어렵게 몰아갈 뿐입니다. 보안 요구가 거세서 암호가 복잡해지고 고도로 수학적인 알고리듬과 보안정책을 가진 시스템이 갖는 보안 수준은 아이러니컬하게도 포스트 잇 수준으로 떨어져 버리니 말입니다.

결국 핵심은 이렇습니다.
geek들의 지적 만족을 위한 프로그램이 아니라 제품으로서의 소프트웨어를 만들어야 합니다. 사실 고객의 문제만 해결한다면 소프트웨어일 필요조차 없습니다.
저자는 비유합니다.
드릴 사는 고객에게 볼베어링이니 강철베어링을 암만 말해도 소용없다.
고객은 드릴 자체에는 아무 관심도 없다.
고객이 필요한건 드릴이 아니라 구멍이기 때문이다.
아마, 벽에 그냥 붙일 수 있는 구멍을 팔기만 하면 드릴 따위는 거들떠도 안 볼 것이다.
외골수 천재들의 지적 작품으로 알려진 소프트웨어에서, 상품으로서의 소프트웨어로 개방화가 되어야한다는 논지는 모든 정보기술 관련한 회사가 깊이 성찰할 가치가 있습니다.
책의 진행은 가볍고 번역도 깔끔합니다. 제 블로그 포스팅처럼 경어의 대화체입니다. 다소 geek 스러운 농담을 수용하기에 잘 어울리는 어투입니다.
다만, 사용자들에게 마음의 위안은 될지 몰라도 geek들이 이 책을 읽고 얼마나 변할지 의문시 되긴 합니다.
우리 개발자들과 이야기 나눠보고 싶은 주제이기도 하구요.

'Review' 카테고리의 다른 글

승자독식사회  (10) 2008.05.10
先富論 (선부론)  (8) 2008.04.27
소프트웨어, 누가 이렇게 개떡 같이 만든거야  (37) 2008.04.20
대국굴기  (16) 2008.03.30
이 그림은 왜 비쌀까  (6) 2008.03.22
비즈니스는 이메일로 완성된다: SEND  (28) 2008.03.01
  1. BlogIcon 칫솔 2008.04.20 20:47

    글을 읽다가 갑자기 친구의 글이 하나 떠오르더군요. http://uxlog.net/38
    디카에 들어 있는 남은 메모리를 곧이 곧대로 용량으로 표시하는 것과 찍을 수 있는 장수로 표시하는 것은 기계적으로 아무런 차이가 없다 말할 수 있지만, 그 작은 차이만으로도 소비자가 정보를 받아들이는 태도는 큰 변화를 가져오게 되겠지요.

    그나저나 소비자와 개발자의 뇌구조는 여자와 남자의 뇌구조만큼 다른 듯 싶습니다만. ^^

    • BlogIcon inuit 2008.04.20 21:43

      바로 정확한 사례를 들어주셨습니다.
      사용자는 아무리 정확한 바이트 수라도 아무 관심이 없지요.
      내가 몇장 더 찍을 수 있는가가 의미있는 정보일 뿐이구요.

      (살짝 말씀드리면)
      저자는 geek들이 남성 위주라는데 문제점이 한귀퉁이 있다고 진단합니다.
      여성들이 프로그래밍하면 소비자 사고를 쫓아갈거란 뜻입니다.
      남성은 기술을 이야기하지만, 여성은 그 기술의 효익만을 철저히 따지듯 말입니다. ^^
      그런 면에서 칫솔님 말씀처럼, 남성 뇌구조가 개발자 뇌구조로 전이되는 측면이 많다고 저자는 느끼나봐요. 흐흐흐

  2. BlogIcon 도도빙 2008.04.21 00:09

    "사용할 수 있는 아이디인지 확인하세요"
    "주민 번호에 - 를 빼고 (넣고) 입력하세요"

    웹 사이트 이용할 때 가장 많이 부딪히는 프로그래머 위주의 프로그래밍 예가 위 두개가 아닌가 싶네요.


    @ 오늘 주문해야겠군요.

    • BlogIcon inuit 2008.04.21 22:28

      믿기지 않는 이야기지만, 책에 의하면 이런 메시지도 있다더군요.
      "다른 사용자가 사용중인 암호입니다." -_-

      이쯤되면 거의 막가자는 수준이죠. ^^

  3. BlogIcon mode 2008.04.21 00:34

    재미 있는것은 많은 프로그래머들이
    사용성이 높은 프로그램을 만들고 싶어한다는 점과
    동시에 그때문에 자신의 프로그램은 사용성이 높을거라고 믿는다는 것인데
    알고보면,
    대부분 사용하기 어렵습니다.
    그런데다,
    순수하게 기술적인 이유, 사람에 대한 이해도의 문제, 제작 업체의 어쩔수없는 사유가 포함되어 버리면 문제점을 찾지도 못한채 실패해버려서
    다음이라는 디딤돌도 못된다는 것입니다.

    같이 일하는 사람의 언니가 개발자인데 이런 말을 남겼답니다.
    " 우선... 무조건 그건 안된다고 말해야해. 그렇게 말하고 시간을 좀 벌어놓고나서.. " 보통 사람은 모르는 그들의 숨겨진 얼굴이랄까요? ^^

    • BlogIcon inuit 2008.04.21 22:31

      mode님이 깊이 관련된 주제라 많은 사례를 알고 계시겠네요.
      내가 스스로 판단하는 사용성은 아무 의미가 없는데 말이지요.
      "무조건 안된다고 말하기"는 정말 같이 일하기 딱 싫은.. ^^

  4. BlogIcon 행복한고니 2008.04.21 01:18

    요즘 읽고 있는데 완전 제대로입니다. 이제 절반 정도 읽었는데, 주로 UI를 개발하는 입장에서 뜨끔하기도 하고, 무릎을 탁 치기도 하고, 킥킥 거리기도 하면서 재밌게 읽고 있습니다. ^^
    직업에 "개발" 혹은 "디자인"이 들어가는 사람이라면 누구에게나 추천해주고싶은 책입니다.

    • BlogIcon inuit 2008.04.21 22:36

      UI 개발하신다니 더욱 흥미있게 읽으시겠네요.
      행복한고니님은 깔끔한 사용성을 구현해 주세요. ^^

  5. BlogIcon 진영규 2008.04.21 07:26

    하하 10종류의 사람이 포인트군요. 그리고 저도 비슷한 농담을 알아요. Real Engineers know that Halloween is really the same as Christmas, because OCT 31 = DEC 25. 책은 아직 읽어보지 못했지만 표지와 제목부터 참 재미있네요. 트랙백 감사합니다.

    • BlogIcon inuit 2008.04.21 22:37

      와우.
      OCT 31은 정말 DEC 25이군요.
      처음 알았습니다.
      정말 재미있네요.
      할로윈과 크리스마스는 본질적으로 같은 날이라니. 하하

  6. BlogIcon 안불렀슈 2008.04.21 08:00

    내용은 S/W 구현에 종사하는 사람 보다는 S/W 설계나 기획, 요구사항 도출에 종사하는 분들에 대한 내용인 것 같네요 ` ^^

    일을 하다 보니까, 제대로 Requirement Engineering을 하는 분을 만나고 싶다는 생각이 종종 듭니다.

    • BlogIcon dazzilove 2008.04.21 08:54

      바로 앞에 위치한 덧글이어서.. 읽게되었고.. 사족 함 달아봅니다. ^^;;
      제 생각엔 그렇지 않습니다.
      사용자 편의성을 가장 가까이에서 체험할 수 있는 사람이 바로 구현자 입니다.
      왜냐구요? 구현하면서 클릭이나 입력을 통한 테스트를 해야하기 때문이지요.
      개인적으로... 개발을 진행하다가 좀 아니다 싶으면 바로 커뮤니케이션 가능한 환경이어야 한다고 생각합니다.
      '내가 써봐도 어려운데.. 사용자들은 오죽하겠어...'
      '이렇게 고치면 좀더 편할것 같은데.. 어때? '
      등등이요.

    • BlogIcon inuit 2008.04.21 22:39

      안불렀슈//
      SW 구현하는 개발자가 더 눈여겨 볼 가치가 있을겁니다. ^^

      dazzilove//
      저도 동감합니다. ^^

  7. BlogIcon dazzilove 2008.04.21 08:51

    읽으려구 찜해둔 책인데 좋은 리뷰 감사합니다. ^^*

    • BlogIcon inuit 2008.04.21 22:39

      읽어보시고 감상 나누어 주시면 고맙겠습니다. ^^

  8. BlogIcon Hexa 2008.04.21 09:13

    요즘 제가 고민하고 실천하고자 노력하는 분야네요. 모든 개발자가 가지고 있는 딜레마이기도 한 것 같습니다.

    그런데, 대학 때, 기계 전공이신가요? 낯익은 과목과 용어들이 많이 있어서요. ^^;;

    • BlogIcon inuit 2008.04.21 22:44

      네. 사실 말은 쉽지만 실천은 어려운 개발자의 딜레마입니다.
      Hexa님 전공이 기계계열이세요?
      저는 aerospace engineering을 공부했습니다. ^^

    • BlogIcon Hexa 2008.04.28 09:02

      ㅎㅎ. 전 Mechanical Engineering입니다. 사실... 항공우주공학을 지원하려고 했었지만 말이죠. ^^;

    • BlogIcon inuit 2008.05.01 22:13

      아 그러시군요.
      저와 유사한 흥미를 가지셨었네요.
      저 때는 aeronautics였어요. space는 나중에 은근슬쩍 끼어들었구요.

  9. BlogIcon 엘윙 2008.04.21 21:59

    10종류가 맞네요. 푸하하.
    아무튼..UNDO기능은 살면서도 항상 생각나는 기능입니다. 세이브 포인트로 돌아가고 싶어요. ㅠ_ㅠ
    개발하다보면 이것저것 생각할 틈없이 일정에 밀려서 코딩하는 경우가 많습니다. 제가 구현하는 부분은 직접 사용자와 맞닥드릴 가능성은 거의 없지만..제 코드를 쓸 다른 누군가를 생각해서 짜야겠습니다! 그러나 역시 이것은 이론일뿐..-_-

    • BlogIcon inuit 2008.04.21 22:46

      정말.. 살면서 UNDO가 된다면! 뭐든 다해보고 싶네요.
      엘윙님은 후회없는 삶을 살지 않았나요? ^^
      바라는 세이브포인트가 있나봐요.

      그나저나 엘윙님.. 프로그래머셨삼? ^^;

    • BlogIcon 엘윙 2008.04.24 23:06

      넵. 팀장님 빼고는 다 개발자에요.
      코딩한다고 다 프로그래머는 아닐까요? ㅇ-ㅇ?

    • BlogIcon inuit 2008.04.26 21:21

      아뇨. 알고 있었지만 이미지가 새삼 생경해서요. ^^

  10. BlogIcon Ssirius 2008.04.22 01:03

    이 책을 읽게 만들고 싶게 하는 글이네요. 조만간 꼭 읽어봐야겠습니다^^

    • BlogIcon inuit 2008.04.26 21:22

      읽어보시고 느낌 공유해주시면 고맙지요.

  11. BlogIcon smith17 2008.04.22 09:11

    사실 요즘 기획자와 개발자 사이의 구조 때문에 개발자가 좀 지나치게 geek 스럽다는 측면이 강조되는 면이 있다고 봅니다(아닌 개발자도 많이 존재하니까요). dazzilove님이나 inuit님 말처럼 개발자들이 물론 사용성을 향상 시키는데 많이 기여할 수 있는 위치에서 일하긴 하지만, 막상 구현적인 이슈만을 다루기에도 한국의 현실은 시간적인 압박이 상당합니다. 그리고 dazzilove님 말씀데로 개발자들이 사용편의성을 가장 가까이에서 접하긴 하지만 막상 개발하다보면 개발자 눈에 익숙해진 UI는 개발자들에겐 문제로 보이지 않고 편해져버리기 까지... 물론 많은 문제의식을 가지고 쳐다보는데는 동의합니다. 저 같은 경우는 아무것도 모르는 사용자에게 던져주고 테스트를 한다거나 하죠...ㅋㅋ 그냥 "개발자 측의 변명" 정도로 봐주세요..^^ 좋은 책 같으니 바로 읽어봐야겠군요..ㅋㅋ

    • BlogIcon inuit 2008.04.26 21:24

      geek스러움은 하나의 직업적 환상아닐까 싶어요.
      개발자도 은근히 즐기고, 사회적으로도 믿고 싶은 그런 이미지말입니다.

      물론, 우리나라 개발자의 현실은 잘 압니다.
      오히려 우리나라에서는 'geek스러움'에 대한 관용과 배려가 더 필요하지 않을까 싶기도 합니다.

  12. BlogIcon 광이랑 2008.04.22 11:22

    저두 개발자인 시절이 있었고, 매니져인 지금에 와서야 저것이 차이가 있다는걸 확연히 느낍니다. 매니져 관점에서 보면 사용하기 편한게 당연한건데, 개발할때는 잘 모릅니다. 세계적인 트렌드가 '파워유저' 전용에서 '리치유저' 전용으로 바뀌고 있습니다. 개발자들도 그런 시대의 트렌드에 맞춰서 진화해야 할텐데 말이죠 ㅎㅎ

    • BlogIcon inuit 2008.04.26 21:25

      세상과 소통하는 통로를 열어주시는게 매니저의 임무중 하나 아닐까 싶어요.

  13. BlogIcon 로처 2008.04.23 14:28

    드릴 비유는 꽤나 유명한 광고기획자가 한 말인가 봅니다.
    어디서 들었나 했더니 <스틱>에 인용된 것을 읽었다는 걸 찾아냈습니다.
    이놈의 기억력이란 ㅡ.ㅡ;

    댓글 중에 '다른 사용자가 사용중인 암호입니다.' 에서 웃다 생각하다 하고 있습니다.

    환절기 감기 조심하세요.
    아주 끈기있는 놈 이제야 떨어냈습니다. ^^

    • BlogIcon inuit 2008.04.26 21:26

      감기로 고생하셨군요.
      이번 감기는 밤에 더 힘들다고 하던데.
      다시 차가운 날씨인데 조심하세요.

      참. 인용에 대한 정보, 고맙습니다. ^^

  14. BlogIcon 유정식 2008.04.23 22:28

    재미있는 제목의 책이군요. 예전에 저도 프로그래머 생활을 했었는데, 그때 저도 '개떡같이' 프로그램을 만들었을 수도 있겠다 싶습니다. 한번 읽어봐야겠습니다.

    • BlogIcon inuit 2008.04.26 21:27

      거의 제목에서 반은 먹고 들어가는 책입니다. ^^
      유정식님이라면 아무리 개떡같이 만들려 해도 전혀 그렇지 않을거란 생각이 듭니다.

  15. BlogIcon 쉐아르 2008.04.24 00:15

    프로그래머를 저의 천직으로 생각했던 때가 있었습니다. 그렇게 살기 위해 미국에 건너왔구요. 세월이 지나 직접 코딩하는 거는 제 필요에 따라 스크립트 손볼 때뿐이 되었지만, 아직도 프로그래밍을 취미로라도 하고 싶어합니다 ^^;;;

    Requirement Engineering이 중요한 일의 하나인 Solution Architect를 거쳐 지금은 개발팀을 관리하는 입장에서, 이 책의 화두가 어쩌면 당연하기도 하고, 또 새로이 다가오기도 합니다. 제가 참여했던 프로그램들이 사용자에게 어떻게 받아들여졌을까 궁금하기도 하구요.

    결국은 '어떻게'가 아니라 '무엇을' 제공하는가에 중점을 두어야한다고 생각합니다. 이번에 새로 만드는 제품이 있는데, 더 사용자 관점에 집중해야겠습니다.

    • BlogIcon inuit 2008.04.26 21:30

      음.. 쉐아르님이 유사한 일을 하시는건 알고 있었지만, 직접 관련된 업무신가봐요.
      정말 본원적 목적을 잊지 않는게 말처럼 쉽지 않으니 그 부분을 지켜나감에 가치가 있겠습니다.
      이 주제라면 쉐아르님이 쓰시면 더 잘썼을거 같아요. ^^

  16. BlogIcon 광이랑 2008.08.04 11:15

    시간에 쫓겨 이제야 정리했습니다. 트랙백 하나 걸고 가겠습니다. (__

    • BlogIcon inuit 2008.08.04 23:16

      냉큼 가서 읽어보겠습니다.

+ Recent posts