|
회사에 들어온 웹디자이너가 엘런 쿠퍼가 쓴 "정신병원에서 나온 디자인"이란
책을 주더군요.. 뭐 디자인 책 중에서는 가장 좋은 책이라고 생각한다면 말이죠..
읽어 보니까.. 앞의 1/3은 너무나 복잡한 인터페이스를 씹는 내용이고 나머지
1/3은 그렇게 된 이유가 개발자들이 UI, 특히 사용자 인터페이스에 너무 많은 영향력을
행사하기 때문이고 나머지 1/3은 페르소나를 소개하면서 개발자들을 설득하기 위한
전략을 설명하더군요..
제가 알기로는 엘런 쿠퍼 또한 대단히 수준 높은 개발자로 알고 있습니다. 그래서
그런지 마치 거기서 적은 불특정 다수의 개발자에 대한 이야기가 제 이야기 같...더군요..--;
몇 군데 발췌해 보면요
프로그래머들은 소프트웨어를 배우는 데 엄청난 시간과 에너지를 바치기
때문에, 사용자들이 시간을 들여 그의 작품을 이해하려고 하지 않는다는 것은 그들에게 상상도 할 수 없는 일이다. 그는 회사
내에 문제가 있다는 사실은 기꺼이 받아들였지만, 회사 내에서 자신이 맡은 일에 문제가 있다고는 생각하려 하지 않았다.
-Part3 포크로 스프먹기, 테크노 정신병원
침입자가 접근해 오면 그들은 통제권이 무책임한 사람들에게 넘어가지 않도록 조심한다. 대부분 프로그래머들은 아주 책임감이 강한 사람들이며, 외부
컨설턴트나 마케팅 전문가, 경영자들을 종종 무책임하고 무능한 존재로
여기곤 한다.
프로그래머들에게는 아주 예민한 거짓말 탐지 능력이 있어서, 마케팅 전문가나 관리자들이 '인터페이스를
개선하기 위해' 프로그램을 고치라고 주문했는데 결국 고쳐도 아무런 효과가 없었던 경우를 두어 번 겪고 나면 외부의 간섭에 단련이 돼버린다.
이러한 변경은 바람직한 것이든 아니든 상관없이, 프로그래머에게 추가적인 일을 하게 만든다. 또 변경을 할 때마다 프로그램에 불가피하게 상처와
땜질 자국들을 남기기 때문에 작성된 코드의 품질이 떨어지게 된다. 누군가 '확인' 버튼을 전부 대화상자의 오른쪽 위 구석에 두면 프로그램이
사용하기 쉬워질 것이라고 주장하면, 프로그래머는 자신의 경험과 지혜에 비추어 그것은 그저 시간 낭비라고, 정확하게 말하면 '자신에게' 시간
낭비일 뿐이라고 되뇌일 것이다. 이러한 두려움은 전혀 근거 없는 것이 아니다.
이런 어이없는 일을 몇 번 겪고나면 프로그래머들은
외부에서 오는 모든 디자인 지시 사항을 그저 충고로만 여기기 시작한다. 잘못 설계된 벽들이 너무 많아 철거해야 하는 건축가와 같은 경험을 한
그들은, 이제 청사진을 아니꼬운 눈으로 바라보며 그것을 있는 그대로 받아들이지 않으리라 결심한다.
-Part3 포크로 스프먹기, 테크노 정신병원
대부분의 사람들이 적당한 수준으로 노력을 기울이는데 별 어려움을 겪지 않지만, 프로그래머들이 대부분의 사람들과 다른 점은 그들이 극도로 복잡성한 시스템을
정복하려는 의지와 능력을 지녔다는 점이다. 서로 인터랙션하는 수많은 요소들로 구성된 시스템을 이해하도록 관리하는 것은
프로그래머라는 직업에서 특히 만족스러운 부분이다.
-Part3 포크로 스프먹기, 호모 로지쿠스
이 책에서 개발자로서 최고의 공감 200%의 단락은...
소프트웨어 엔지니어들은 인테랙션 디자이너들과 목표를 공유한다. 즉, 그들도 제품이 성공적이기를 바란다. 단지 그 성공을 측정하기 위한 그들의
도구와 용어가 디자이너들의 것과는 전혀 다른 것 뿐이다.
확실한 증거가 없는 상태라면, 프로그래머들은 반드시 자기 자신의 교육과 경험,
본능적인 감각에 의존하려고 할 것이다. 그의 본능은 그에게 가능한 많은 기능을 제공하라고 말한다. 그의 경험은 아마추어들이 일시적인 기분이나
어림짐작으로 민감하고 복잡하고 섬세한 개발 과정을 망치게 내버려 두지 말라고 말한다. 그가 받은 교육은 그에게 자기 자신을 참조하여 인터페이스를
구축하라고 말한다.
인터랙션 디자이너들은 이러한 동기들을 직접적으로 공격할 수 없다. 개발자들은
너무나 이성적이고 합리적인 사람들이라 절대 다른 사람의 의견을 따르기 위해 자신의 경험을 저버리지 않는다. 디자이너는
그들에게 문제를 바라보는 새로운 관점을 제시해야 하며, 그 관점이 효과적이라는 것과 기존의 관점과 양립할 수 있다는 것. 이렇게 2가지를 추가로
입증해야 한다.
-Part 5 운전석으로 돌아가며, 강력함과 즐거움
이 부분이 많이 공감이 가더라구요..
게임의 부담
소프트웨어 엔지니어링이 갖는 강한 문화적 결정 요소 중 하나는 그것이 홀로 이루어진다는 것이다. 프로그래머들은 홀로 책상에 앉아 있다. 한
시점에 단 한 명의 프로그래머만이 코드를 입력할 수 있다. 코드는 컴퓨터 상에서 겉으로 거의 드러나지 않으며, 읽히는 일도 거의 없다. 다른
사람들이 작성한 코드를 읽는 것은, 책을 읽는 것이라기 보다는 본인만 알아볼 수 있게 끄적거린 타인의 강의 노트를 읽는 것에 더 가깝다.
프로그래밍 작업은 아주 복잡해서 한결같이 집중해야 하고 오랜 시간 방해받지 않으면서 일해야 한다. 프로그래머들은 이러한 고립과 그것이 내포하는
의미를 분명히 의식하고 있다. 그 누구도 프로그래머가 자신의 프로그램 속에서 하는 일에 이렇다 할 통제력을 행사할 수 없다.
프로그래머들은 자기 코드의 질이
스스로의 성실함과 양심에 달린 문제라는 것을 알고 있다. 상사는 높은 품질을 요구할 수는 있어도 정말 높은 품질인지 확인하기
위해 팔요한 시간과 노력을 직접 투자하려고 하지 않을 것이다. 프로그래머가 작성한 코드를 해독하는 데는 그것을 원래 작성하는 데 걸린 시간보다
더 많은 시간이 소요될 수 있다. 프로그래머들도 이 사실을 알고 있으며, 그들의 개인적인 결정과 행동이 다른 어떤 고려사항보다도
최종제품과 사용자 만족에 많은 영향을 미치는 것도 안다. 궁극적으로, 그들은 제품 성공 여부에 대해 개인적으로 책임을 져야 할
것이다. 그들은 자신들이 게임에서 많은 부담을 지고 있다는 것을 안다.
프로그래머의 외로운 작업은 프로그래머가 자신의
권한을 강하게 의식하게 만든다. 어떤
프로그래머들은 이런 권한을 불편하게 느끼기도 하지만, 게임에서 적은 부담을 지고 있는 다른 사람에게 권한을 양도하는 것을 그보다 훨씬 더
불편하게 여긴다. 마케팅 담당자나 관리자, 디자이너가 그들에게 충고를 하면, 프로그래머들은 그 제안을 상당히 회의적인
시각으로 본다. 만약 충고를 받아들여
일이 잘못된다면, 조언자들은 이미 사라진 지 오래고 비난은 프로그래머에게 그대로 쏟아지리라는 것을 그들은 알고 있다.
~중략~
한편, 모든
프로그래머들은 자신들처럼 사용자가 원하는 것이 무엇인지 잘 모르는 관리자들이 내린 멍청한 디자인 지시 때문에 좋은 제품이 시장에서 실패했던
끔찍했던 기억을 가지고 있다. 타이핑을 싫어하는 한 고위 임원이 자기 회사의 모든 프로그램을 마우스만으로 조종 가능해야
한다고 요구했던 일이 기억난다. 또, 마우스 사용이 서툰 또 다른 고위 임원은 자기 회사의 모든 프로그램이 키보드만으로 조종되어야 한다고 지시한
사례도 있었다. 이 자신을 기준으로 하는 이 파괴적인 디자인은 두 회사 모두에 절망적인 파문을 불러 일으켰다.
일부러 심술궂게 굴고
파괴적인 성격의 프로그래머들도 있지만, 내가 만나본 많은 프로그래머들로부터 판단하건데 그런 사람들은 극히 드물다. 제트 전투기 조정사들처럼
훈련과 규율이 아주 엄격하기 때문에, 이들이 일단 정상급 능력에 도달하게 되면 프로그래머가 아닌 사람을 능력이 떨어지는 사람으로 여기게 되는
것은 어쩔 수 없는 일이다. 소프트웨어
엔지니어들은 같은 분야 사람들을 존중하지만, 프로그래머가 아닌 사람이 프로그래밍의 세계로 뛰어들면, 무디가 이야기했듯이,
그들을 깔보거나 심지어는
엘리트주의자처럼 군다.
프로그래머는 소프트웨어 개발이라는 첨단 기술 세계에 참견하려는 아마추어들을 비웃을 권리가 충분히
있다. 마찬가지로, 프로그래머가 경리부장실 문을 두드리고 들어가 사업 관련 수치들을 다시 계산하기 시작한다면, 경리부장은 남의 일에 간섭하는
프로그래머의 욕심과 오만함을 비난할 자격이 있다.
문제가 생기는 것은 인터랙션을 디자인하는 것과 이를 구현하는 것이 일반적인 개발
과정에서 너무나 철저히 뒤섞여 있기 때문이다. 관리자는 프로그램의 행동 방식을 변경해 달라고 요구할 수는 있겠지만, 감히 프로그래머에게 다른
코드 작성법을 이용하라고 요구하지는 않을 것이다. 그러나 프로그램의 행동양식과 그 구현은 아주 밀접하게 관련이 있기 때문에, 어떤 것은
반대하면서 다른 것은 반대하지 않는 것이 불가능하다. 이것이 무디가 마이크로소프트 사에서 경험한 어려움 가운데 하나이다.
소프트웨어 기반
제품의 개발에 관여하는 대부분의 사람들은 사용하기 쉽고 편한 제품을 만들고 싶어한다. 결과적으로 그들은 계속해서 프로그래머들을 귀찮게 한다.
개발자들에게는 시간 여유가 거의 없기 때문에 이러한 간섭은 그들을 화나게 할 수 있다. 많은 프로그래머들이 혼자 일하려 하며 프로그래머가 아닌
다른 팀 멤버들과 잘 대화하려 하지 않는다. 테므라 히더쇼-하트는 테크니컬 라이터로 일할 때 프로그래머들로부터 정보를 얻어냈던 이야기를 나에게
해주었다.
---나는 간절히 부탁하는 것보다 뇌물을 주는 것이 훨씬 효과적이라는 사실을 알게 되었다. 나는 주로 초콜릿을 이용하곤 했다. 뇌물
방법은 효과가 너무 좋아서 한번은 엔지니어링 매니저가 제품의 변경 내용을 알려주지 않은 것에 대해 공식적으로 사과를 하기까지 했다.(어쨌든 그는
뇌물을 받긴 받았다.) 어떤 회사에서는 초콜릿에 사족을 못 쓰는 엔지니어 한 사람이 그의 동료들의 변경 내용까지 전부 이야기해주고, 그들 몫의
초콜릿까지 받아간 적이 있었다. 뇌물 방법을 사용하기 전에는 제품에서 무엇이 변경되었는지 알아내기 위해 오랜 시간 초과 근무를 해야 했다.
결국, 나는 초과 근무 시간을 절반 이상으로 줄였다.---
이 일화가 흥미로운 이유는 소프트웨어 개발 사업에 조금이라도 경험이 있는 사람이라면 정말로 그렇다는 것을 알기 때문이다. 만약 어느 회사의
경리부장이 수금 관리 직원에게 오늘의 입금액에 대한 정보를 얻기 위해 초콜릿을 뇌물로 주어야 한다는 이야기를 듣게 되다면, 당신은 놀라워하고
분개할 것이며, 또 믿지도 않을 것이다.
많은 임원들이 그들이 내린 지시나 심지어는 가벼운 제안에 대해서도 부하 사원들이 즉각 따르는데 익숙해져 있다. 그들은 프로그래머들이
기술직이므로 그다지 높은 지위와 권력을 가지고 있지 않으며 상사의 지시에 순종적으로 따를 것이라고 생각한다. 프로그래머의 관점에서
보면, 임원들은 게임에서 아무런 부담도 지고 있지 않기 때문에 과연 순종해야 할지 상당히 의심스러울 수 밖에 없다. 독립심이
강한 소프트웨어 엔지니어는 직위의 고하를 막론하고 다른 사람이 하라고 한다는 이유만으로 자신의 코드를 고치지는 않을 것이다.
기존의
코드를 수정하기를 원한다면, 당신은 우선 프로그래머의 마음부터 바꾸어야 한다. 그는 기존 코드에 대한 기득권뿐이나라 불필요하게 코드를 변경하는
수고로움을 거부할 기득권도 가지고 있다. 그들에게 명령이 아닌 부탁을 해야 하는 것은 물론이고, 변경해야 하는 논리적이고 납득시킬 수 있는
이유도 제시해야 한다. 이는 엔지니어가 이해할 수 있는 용어로 표현되어야 하며, 또 게임에서 부담을 갖는 누군가에 의해 제시되어야 한다.
-Part3 포크로 스프먹기, 그들만의 문화
선배 분들의 생각은 어떠십니까.. 저는 찔리는 구석이 한 두 군데가 아니라서요...ㅡㅡ;
|