2-3주동안 아직 100페이지도 못본 책을 오늘 마음 먹고 읽었다.
원서의 제목은 다음과 같다.
Why Software SUCKS... and what you can do about it.


  소프트웨어, 누가 이렇게 개떡같이 만든 거야 - 사용성을 제대로 이해하는 유쾌한 통찰  데이비드 플랫 지음, 윤성준 옮김
왜 사용자가 소프트웨어를 사용하기가 어려운지를 사용성 문제에 관심이 있거나 관심을 갖기 시작한 초보 프로그래머, 웹 기획자, 관리자, UI 개발자, 웹디자이너, 웹 개발자, 컨텐츠 작성자, 마케팅.비즈니스 담당자 등에게 쉽게 알려주는 책이다. 어려울 수 있는 소프트웨어의 사용성 문제를 일반인이 읽어도 소화할 수 있을 정도로 쉬운 용어와 유머러스한 문체로 풀어냈다.

우선 확 눈길을 끄는 제목과 표지에 한표.

위에 설명이 나와 있으니 더 이상 이 책에 대해서 다시 설명할 필요는 없을것 같고
항상 그랬듯이 책을 읽으면서 괜찮다 싶은 부분을 발췌해 본다. ( 좀 많다. ;; )

스크롤의 압박이 있을테니.. 책을 읽은 결론 부터 이야기 하면.


책 내용의 대략 다음과 같은 내용이다.

1. 왜 이딴식으로 만들었나? 조금 생각해서 만들면 안되나?
2. 사용자들과 괴짜(Geek)혹은 프로그래머는 생각 자체가 다르다.
3. 마이크로소프트에 대한 잡다한 이야기
4. 프로그램이 맘에 안 들면 사용자가 갈궈(feed back)해 주자. 칭찬도 잊지 말고.

뭐 이런 내용들이다.
딱 책의 원서 제목대로 "우리가 할 수 있는 일"을 마지막에 배치해 놓았다.


충분히 읽을만 하다. 특히 프로그래머한테는.
정확하게 이야기 하면 프로그래머 보다는 기획자가 읽어야 한다.
책에서 계속 지적당하는 UPS나 스타벅스는 웹사이트를
과연 프로그래머 혼자서 생각하고 만들었을까?



그럼 아래는 발췌한 내용들이다. ( 생각보다 내용이 길다. )

( 사진은 다른 곳에서 그냥 암거나 퍼온것임 )

그림4.(그림생략) 마이크로소프트 워드의 메뉴 바가 문서 위에 떠 있다. 이렇게 할 수는 있지만, 누가 이런것을 원하겠는가?


예를 들면, 문서를 윈도우의 휴지통으로 보낼 때 나타나는 확인 대화상자("~ 항목을 휴지통에 버리시겠습니까? 정말로? 정말, 정말, 정말로?")를 끄는 방법과 같은 것들 말입니다. ( Undo와 같은 기능을 사용하면 되지? )


그 시절에는 프로그램을 사용하기 쉽게 만드는것은 잘못이라는 통념이 있었습니다..... 지적투쟁을 통해 자신의 가치를 증명한 사람들만이 프로그래머의 노력으로 인한 혜택을 받을 수 있어야 한다는 것이었습니다. 처음 사용했던 시스템에서 문서를 인쇄하기 위한 명령어이 Print 또는 P가 아니라 Q (인쇄를 하기 위해서는 문서를 큐에 넣어야 하므로)라는 것을 알아 냈을 때 느꼈던 자부심이 기억납니다. 저는 마법의 주문을 배운것이었습니다. 저는 소수의 선택받은 사람이 된 것이었습니다. 저는 똑똑했으니까요!


그대의 사용자를 알라. 사용자는 그대가 아닐지니


사용자 인터페이스를 설계할 때 프로그래머가 하는 두번째 실수는 사용자로 하여금 프로그램의 내부 동작을 이해하도록 강요하는 것입니다.....누군가 사용자 인터페이스가 왜 그런 식으로 동작하느냐고 묻는다면 그는 의아해하며 "그게 제 프로그램의 동작방식입니다."라고 대답할 겁니다.


우리는 프로그래머처럼 생각하도록 강요 받고 있었던 것입니다..... 자동차를 운전하려고 자동차 정비공 처럼 생각해야 하는것도 아니고, 아스피린 한 알 먹으려고 의사처럼 생각해야 하는것도 아니며, 햄버거를 굽기 위해 정육점 주인처럼 생각해야 하는것도 아닙니다. 우리는 힘들여 번 돈을 이 제품에 지불했습니다. 제품이 우리에게 맞도록 프로그래머가 노력해야지, 그 반대가 아니란 말입니다.


단 한번이라도 "이런! 삭제하려던게 아니었는데. 물어봐줘서 고맙군."라고 말하며 '아니오' 버튼을 클릭한 적이 있습니까? ... 자동차 키를 꽂아 돌렸을 때 "정말 시동을 걸고 싶으십니까?" 하고 물어 보는 차는 없습니다.... 자동차에 시동을 걸때나 가게에서 물건을 살 때 확인 질문을 받지 않는 또 다른 이유는 실수라고 깨닫는 즉시 작업을 취소해 원래대로 되돌릴 수 있기 때문입니다.... 이런 실행 취소(undo) 기능은 사용자 인터페이스 설계자의 무기고에 있는 무기 중 가장 훌륭한 것입니다.


스타벅스의 프로그래머들은 아마 검색에 대해 더 많이 제어할 수 있게 만드는 것이 더 강력하고 좋을 것이라 생각했을 겁니다. 그러나 실제로 그것은 불필요할 뿐 아니라 사용자를 짜증나게 합니다. 어느 누구도 "반경 5마일 안에 스타벅스 매장이 있는가? 10마일은? 15마일은?" 과 같은 식으로 묻지 않습니다..... 해당 범위에서 매장을 찾지 못한 경우 적절한 결과를 찾을 때까지 자동으로 검색 반경을 넓혀야 합니다.


컴퓨터를 실제로 사용할 때는 적절한 수준에서 보안과 실용성 사이에 타협을 하게 됩니다. 애플리케이션에 대해 적절한 수준의 트레이드오프를 선택하는 것이 프로젝트의 성공과 실패를 가릅니다.


지문을 통한 인증은 문제가 많습니다. 지문은 훔치기는 쉬운 반면 바꿀 수는 없기 때문입니다. 생각해 봅시다. 식당에서 사용한 모든 유리잔을 깨끗이 닦을 겁니까? 모든 문고리는 어떻고요?.... 패스워드의 장점중에 하나는 새로운 패스워드를 만드는 데 드는 비용이 싸다는것 입니다. 사실 공짜나 다름없죠. 따라서 패스워드가 유출됐다는 생각이 들면 언제든 새로운 패스워드로 바꿔 버릴 수 있습니다.


요즘은 아무도 개인 외상 장부를 관리하지 않습니다. 대신 상점은 전체 지불 프로세스를 비자나 마스터 같이 회계, 지불, 수금 과정을 처리하는 신용카드 회사로 아웃소싱합니다. 상점은 자신들의 핵심역량(옷을 팔거나 자동차를 수리하는 등의)에 노력을 집중합니다.....상점의 지불 과정을 아웃소싱한 것처럼, 웹 사이트도 인증 과정을 (1) 자신들이 뭘 하는지 잘 알고 따라서 (2) 제대로 할 수 있는 제3의 회사로 아웃소싱하는 것이 좋습니다.


그러나 이런것이 실제로 활용되려면 조금 기다려야 할 것입니다. 마이크로 소프트는 2000년도 경에 패스포트 시스템으로 이와 정확히 같은 서비스를 시도했었습니다..... 원래의  아이디어는 어떤 웹 상점이든 마이크로소프트에 적정한 요금을 내면 그들의 고객 인증을 마이크로소프트로 아웃소싱할 수 있게 만드는것 이었습니다..... 시장이 패스포트를 거부한것이 분명합니다.... 기본적인 문제는 마이크로소프트가 인증 데이터를 보관하는 것을 허용하는 것에 대한 고객의 부정적 생각이었습니다....."은행으로서 우리가 파는 가징 기본적인 상품은 신뢰입니다.... 우리가 고객의 인증 데이터를 직접 보관하지 않고 마이크로소프트가 보관하게 하는 것은 신뢰에 대한 배신이라고 생각하는 고객의 비율이 거북할 정도로 높다는 것을 알게 되었습니다..... 우리는 패스포트를 사용할 수 없었고, 그걸로 얘기는 끝났습니다.


책에 나오는 용어 설명

opt in : [명사]<통신> 미리 받아 보겠다고 허락한 사람에게만 전자 우편을 보내도록 하는 일. 또는 그런 방식.

opt out : [명사]<통신> 전자 우편을 보내서 받은 사람이 수신을 거부하면 이후에는 보낼 수 없도록 하는 일. 또는 그런 방식.


유럽 연합은 미국보다 개인정보 보호에 대해 엄격한 법을 가지고 있어 데이터를 수집, 사용하기 위해서는 보통 옵트인(opt-in) 동의를 필요로 하지만, 옵트인 박스는 흔히 디폴트로 체크되어 있고, 아무도 자세히 살펴보지 않는 라이선스 동의서 속에 숨겨져 있습니다.


그런 곳에는 항상 자신이 고객을 제대로 이해하지 못한다는 사실을 인정하기보다는 자기가 이해하지도 못하는 전문 용어를 나불거리면서 고객을 낚아 제품을 팔 생각만 하는 마케팅 얼간이들이 있게 마련입니다. 자기네 소프트웨어 새 버젼이 '객체지향'으로 만들어졌다고 잘난척 하던 사람이 기억납니다...... "제가 구매하는데 있어 그런 차이점에 왜 신경을 써야 하는지 설명해 주시겠습니까?" 라고 물어서 그들의 입을 다물게 합니다.


저는 오해하고 있는 모든 팀에게 설명하기 위해 많은 노력을 했습니다. 컴퓨팅은 더 이상 기술 분야가 아니라, 사람과 관련된 분야입니다.


괴짜(Geek) [명사]
종종 다른 사람들이 생각하기에 지나치다 싶을 정도로 과도하게 컴퓨터나 다른 기술의 사용을 즐기고 이에 자부심을 갖는 사람. - 마이크로소프트 구내 매장에 걸려 있는 티셔츠에서


그들은 스스로 이렇게 생각합니다. "난 이게 마음에 들어. 이렇게 하는게 명확하지. 따라서 다른 사람들도 이걸 좋아할 거고, 이렇게 하는 게 그들에게도 이해하기 쉬울거야. 그저 상식(common sense)일 뿐이지. 안그래?......틀렸습니다. 소프트웨어를 만드는 괴짜들의 세계관은 사용자들의 세계관과는 매우 다릅니다. 별로 놀랄만한것도 아닙니다. 의사와 환자가 세상을 어떻게 다르게 볼지 생각해 보십시오.
"....이 용어(common sense)는 세상에서 가장 모순되는 단어의 조합이다..... 그들은 확실히 다르게 생각하기 때문입니다. '상식'을 '내 생각'으로 바꾸십시오. 그게 실제 의미입니다.....


괴짜들은 항상 자신들이 상황을 통제하고 있다는 느낌을 갖고 싶어 합니다...... 괴짜들은 수동 기어 자동차를 좋아합니다. 뭔가를 마음대로 제어할 때의 느낌을 좋아히기 때문입니다. 그 방법을 배워야 하는것, 그리고 운전을 하면서 지속적으로 기어를 바꿔야 하는것 과 같은 부가적인 일에는 신경을 쓰지 않습니다. 그들은 이런 것이 상당히 괜찮은 트레이드오프라고(그리고 자동차라면 당연히 그래야 한다고) 생각하며, 그걸 인식하고 그렇게 할 수 있을 정도로 똑똑하다는 것에 대해 스스로 자부심을 느낍니다.


프로그래머는 소프트웨어를 조금 더 좋게(그들이 더 좋다고 생각하는 것은 종종 사용자들의 생각과는 다르지만) 만들려 하면서 하루를 보내고, 다음 날에도 조금 더 좋게, 그 다음 날에도 조금 더 좋게 만들려고 합니다.


프로그래머는 자신 또는 다른 프로그래머가 만든 정신적 구조만을 조작합니다. 따라서 괴짜들은 다른 분야에서와는 달리 추상적 정신 모델을 통해 세상을 바라봅니다.....은행 창구나 항공사 체크인 데스트는 패킷 스위치 큐로 구성되어 있는 반면("줄에 서 있는 다음분은 4번 창구로 오세요"), 슈퍼마켓은 각 계산원마다 별도의 큐를 가지고 있습니다. 캔디 바를 계산하는데 수표책을 가지고 버벅거리고 있는 노쇠한 할머니 뒤에서 기다리다 짜증이 난 한 괴짜가 슈퍼마켓 매니저에게 "이 대기열은 패킷 스위치 큐로 해야 한다는 걸 모르겠습니까?" 라고 비명을 지를 지도 모르는 일입니다..... 괴짜들은 이런 정신 모델속에서 살고 이런 모델을 좋아합니다.


괴짜들의 7가지 습관
5. "고장 나지도 않는 것을 계속 고치려 한다. 고장날때까지."
괴짜들은 간단한 것을 간단하게 만들기보다는 복잡한 것을 가능하게 만드는데 집중합니다.

6. "내가 대답을 잘못한게 아니라, 당신이 질문을 잘못한 것이다." 라고 생각한다.
스타벅스 매장 위치 검색 웹 페이지보다 더 좋은 예가 있을까요?... 스타벅스 매장이 전 우주에 하나 밖에 없더라도, 제 집에서 가장 가까운 매장이 하나는 있을것입니다..... "당신은 5마일 내에 스타벅스 매장이 있는지 물었고, 나는 없다고 대답했다"고 웹사이트가 말합니다. 이 멍청하, 질문을 잘못한건 내가 아니야. 그런 질문은 나 대신 네가 스스로 한거란 말이야.


새로운 제폼을 만들 때나 기존 제품을 수정할 때, 기존 사용자 때문에 엄청난 제약이 따릅니다. 사용자가 이미 익숙하게 사용하는 어떤것을 깨고 새로운 제품을 출시하는 것은 매우 어렵습니다....."Q: 신이 어떻게 6일만에 세상을 창조했지? A: 기존에 설치된게 아무것도 없으니 하위 호환성을 걱정할 필요가 없잖아."



제가 이 책의 전반에 걸쳐 설명했듯이, 벤더는 사용자가 더 좋은 소프트웨어를 요구하지 않는 이상 그런 소프트웨어를 제공하지 않을겁니다. "사람들이 와서 어떤 것이 개떡 같은지를 알려 주면, 우리는 그걸 더 좋게 만들기 시작합니다."....."우리가 어떤 것이 개떡 같고 어떤 것이 그렇지 않은지를 알아내는것은 당신이 상상하는 것보다 훨씬 어렵습니다."


그러나 그들의 궁극적 목표는 사용자의 마음에 드는 소프트웨어를 만들어 구입하게 하는것, 사용자의 마음에 드는 웹사이트를 만들어 사용하게 하는 것, 그리고 그로부터 개발자 자신과 개발자를 고용한 사업주가 보상받을 수 있도록 하는 것입니다.


대부분의 제조업자는 고객의 소리를 듣고 싶어 합니다. 그들은 고객이 어떤 생각을 하는지, 뭘 좋아 하고 싫어하는지, 어떤 것이 바뀌기를 원하고 어떤 것이 그대로 남아있기를 원하는지 알아야 한다는것을 이해하고 있습니다......"제조업자에게는 만족하지 못한 고객이 설계에 대한 피드백의 중요한 원천이다. 그들은 다른 방법으로 쉽게 얻을 수 없는 정보를 제공한다. 설계자와 생산자는 종종 제품에 너무 가까이 있어 제품이 약속한 기능을 다하지 못해 실패할 수도 있다는 것을 올바르게 인식하지 못한다....."


웹이 도래하기 이전 세상에서는 그걸로 끝이었을 겁니다. 화난 고객 한 명이 제품 하나를 반품하지만, 다른 사람에게 큰 영향을 미치지 못했습니다. 그러나 오늘날에는 고객이 엄청 화가 나서 아마존닷컴에 다음과 같은 평가를 올릴 수 있습니다...... 이렇게 되면 아마존에서 그 제품은 거의 팔리지 않을 겁니다. 그리고 제조업체는 그 제품 생산을 중단하게 될 것입니다.


신고
난 아직 2년이 채 되지 않은 개발자이다.
년차로 본다면 개발자라기 보다는 코더에 가깝다고 말하고 싶다.


암튼.
개발을 하다 보면...
이게 취미가 아닌 이상,
하는 일이 회사의 일이 될것이다.



하는 일이 회사의 일이라면...
멋진 코드가 중요한것일까?
일정이 중요한것일까?



회사의 제1목표는 "이윤추구"이다.
특히 작은 회사에서는 절대적인 목표일것이다.
아무리 쓰레기 같은 코드라고 해도
돈을 벌어다 줄 수 있을 정도로만 만들어 주면 된다고 생각한다.


작은 회사는 당장 다음달, 다음분기가 중요하지.
3년, 5년후가 중요하지 않다.
다음달, 다음분기가 없으면 3년후도 없다.
한달 한달을 꾸려가야만 3년후가 있을 수 있다.


1년동안의 매출이 보장된 회사에서는 당연히 다음달은 그리 중요하지 않다.
당장을 위해서 쓰레기 같은 코드로 당장의 돈벌이는 하지 않아도 된다.
시간이 걸려서 더 아름다운 코드를 짜고,
그렇게 해서 몇년후가 편할 수 있다면, 그네들은 그렇게 할것이다.


나 혼자만 고쳐서 되는가?
몇명이 같이 작업을 해야 하나?
지금 하는 일들은 어찌할 것인가?
이제까지 해 왔었던 구조는 어찌하나?
이거 하나 변경하면 도대체 몇군대나 고쳐야 하나?
새로운 개념이 들어 가면 백만개의 버그가 출몰하지 않을까?



정작 바꾸어야 할 것을 알면서도, 바꾸지 못하고.
그냥 아무나 할 수 있는 코드를 잔뜩 "생산"하고 나서 든 생각.




이래저래 불평을 주절주절했어도.

그래도!
나는 작은 회사 입장에서는
"이윤"과 "일정"은 매우 밀접한 연관이 있다고 생각하고,
그리고 그것에 절대적으로 동의한다.
( 전통적인(?) 프로그래머의 기질을 보이지 않는 1人 )

시키는 대로 하기 싫으면, 사장해야지. ㅋ


자기 전에 잡담. ㅋ
신고

'잡다한 글들' 카테고리의 다른 글

으악... 젝일!!!!  (8) 2007.08.31
피곤하다..  (4) 2007.08.31
개발을 하다보면....  (11) 2007.08.29
[펌] 선, 나스닥 거래명 ‘자바’로 변경  (0) 2007.08.27
[펌] 일본 인터넷 이용률 100% 달성!  (1) 2007.08.26
와~ 비다~ ^ㅡ^  (6) 2007.08.13
  1. 효민아빠 2007.08.29 08:48 신고

    마져요.. 닥치고 시키는 대로 해야지 ㅡ,.ㅡ

  2. 옷장수 2007.08.29 09:59 신고

    멋진 코드가 가지는 의미에 따라 다르지 않을까요?
    찬찬찬씨가 만드는 코드가 다른 사람들에게 자주 쓰이는 코드라면 그 코드가 다른 사람이 한눈에 봐서 알기 쉽고 어떤 인터페이스라는게 판단이 될 수 있는 멋진 코드를 짜는게 의미가 더 클 수 있죠.

    그리고, 코드의 중복과 구조를 망치는 코드를 짜면서도 일정을 맞춘다고 한다면 결국에는 성능의 저하와 개선에 더 많은 시간이 걸릴 수도 있습니다. (T사에서의 경험담입니다.ㅋㅋ 그 코드 수정하느라 고생한 시간을 생각하면 아직도 땀이...-_-;;)

    • Chan 2007.08.29 12:20 신고

      일정이 중요하다면 회사 입장에서는 그게 그리 큰 중요한 일이 아닐 수 있다고도 생각합니다. ㅋㅋㅋ
      물론.. 그 뒷일은 감당하기 힘들겠지만 말입니다. ㅎㅎ

      누가 멋지게 안 짜고 싶겠습니까? ㅋㅋㅋ

  3. 지민아빠 2007.08.29 10:13 신고

    일하기 싫은 거구나!!! 그렇죠 그렇죠!!!
    (회사에서 하기 싫은 일을 시켰나 보다. ㅋㅋ)

    • Chan 2007.08.29 12:18 신고

      ㅋㅋㅋ 그렇지 않습니다. ^_^ ㅋㅋㅋ
      고치고 싶은 구조가 있는데도 못 고치는 심정이랄까?

  4. iolo 2007.08.29 11:06 신고

    미안해... 안해도 돼...ㅠ.ㅠ
    (뭘?)

  5. 쇼니 2007.08.29 20:17 신고

    이상과 현실의 차이라고나 할까??
    이상 = 멋진 코드
    현실 = 일정

  6. 토끼 2007.09.01 11:47 신고

    드뎌 현실을 깨달아가고 있는군 -_-~ 난 선배는 그런날이 안올줄 알았는데 충격이야 ~ ㅋㅋ

+ Recent posts