소프트웨어, 누가 이렇게 개떡 같이 만든거야

예전 농담입니다.

세상엔 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들이 이 책을 읽고 얼마나 변할지 의문시 되긴 합니다.
우리 개발자들과 이야기 나눠보고 싶은 주제이기도 하구요.