거만한 소프트웨어란?
국내 대형 사이트가 해킹 당하는 사건이 일어났습니다. 그 사건을 계기로 저는 언제 발생할지 모르는 또 다른 해킹 사건에 의한 개인정보 유출을 방지하려고, 오랫동안 사용하지 않았던 사이트에서 회원탈퇴를 하기로 결심했습니다. 사이트 몇 군데에 들어가서 계정을 없앤 뒤에 마지막 사이트에 접속했습니다.
이 사이트에 로그인을 한 후, 메뉴에서 탈퇴 기능을 찾아봤으나 쉽게 찾지 못했습니다. FAQ에도 없고 사이트에서 제공하는 찾기 기능으로 검색해 봐도 탈퇴 기능이 보이지 않았습니다. 시간이 지나면서 탈퇴해서 뭐하냐는 체념과 보물찾기보다 더욱 어렵게 숨겨둔 탈퇴 기능을 반드시 찾아내겠다는 의지가 동반상승했습니다. 결국 보물찾기 의지가 힘든 현실을 이겨냈습니다.
탈퇴 신청 양식에 탈퇴 사유를 적고 기쁜 마음에 ‘탈퇴하기’ 버튼을 클릭한 순간, 다시 한번 좌절했습니다. “올바르게 작업이 끝나지 않았습니다. 정보가 제대로 삭제되지 않았습니다.” 하는 메시지가 출력됐습니다. 이 메시지를 본 순간, 반드시 탈퇴하고 말겠다는 의지가 불끈 생겼습니다. 회사에 전화하려고 회사 소개 페이지에 들어갔지만 회사 소개만 있을 뿐, 정작 제가 원하는 회사 전화번호는 없었습니다. 결국 번호를 찾을 수 없게 되자 반드시 탈퇴하겠다는 굳은 의지가 꺾이고야 말았습니다.
탈퇴 할 사이트였기에 이 사이트는 제게 큰 의미가 없었지만, 고객과 의사소통 하지 않으려는 거만한 모습에 이 사이트에 대한 기억은 쉽게 지워지지 않을 듯합니다. 요즘엔 사용자 경험(User Experience)이 매우 중요하다고 말합니다. 아마도 사용자 경험 측면에서 봤을 때, 이 사이트는 형편없게 평가될 것입니다. 자! 그렇다면 사용자 경험이라는 것은 도대체 뭘까요? 어떤 측면에서 이 사이트는 사용자 경험이 형편 없었을까요? 우선, 닐슨노먼 그룹(Nielson Norman Group)에서 정의하는 사용자 경험을 살펴보겠습니다.(참고 http://www.nngroup.com/about/userexperience.html)
‘사용자 경험’ 은 사용자가 회사, 그리고 회사가 제공하는 서비스와 제품을 사용하는 과정에서 발생하는 상호작용의 모든 측면을 포함합니다. 훌륭한 사용자 경험을 만족시키기 위한 첫 번째 요구사항은 고객의 필요(needs)를 정확하게 만족시키는 것입니다. 이런 과정에서 불편이나 불만이 없어야 합니다. 다음으로, 소유함으로써 얻는 기쁨과 사용함으로써 얻는 기쁨을 만들어내는 단순함과 우아함이 필요합니다. 진정한 사용자 경험은 고객이 원하는 것과 체크리스트에 있는 기능 이상의 것을 제공합니다.
닐슨노먼 그룹의 정의에 따르면 사용자 경험은 복합적입니다. 단순하게 고객의 필요를 만족시킨다고 해서 사용자 경험이 훌륭하다고 단정 지을 수 없다는 뜻입니다. 사용자 경험의 복합적인 성격을 공식을 사용해서 간단하게 설명한 것이 있습니다. 미카 힐뚜넨(Mika Hiltunen) 등은 사용자 경험을 다음과 같이 표현했습니다.
사용자 경험 = 실용성 x 사용성 x 가용성 x 심미성 x 오프라인 이슈
• 실용성(utility): 서비스가 가치 있다고 사용자가 인지하는 것
• 사용성(usability): 사용자가 조작 방법을 쉽게 배우고, 쉽게 입력하며, 결과를 쉽게 해석하는 것
• 가용성(availability): 서비스를 사용하고 싶을 때 사용하는 것. 사용하지 못할 때 언제 사용이 가능할지 아는 것
• 심미성(aesthetics): 사용자가 서비스의 형태와 느낌에 흥미를 보이는 것
• 오프라인 이슈(offline issue): 브랜드나 비즈니스 프로세스를 포함 [힐뚜넨07]
저를 지나치게 좋아한 나머지 탈퇴시키지 않으려던 사이트의 사용자 경험을 계산해 보겠습니다. 사실, 여기서 점수는 의미가 없지만 이해를 도우려는 목적으로 각 항목에 대해서 만족인 경우1, 보통인 경우0.8, 나쁠 경우0.5를 주겠습니다.
– 오랫동안 접속하지 않았다는 것은 제게 별로 실용적인 서비스가 아니라는 의미였죠(실용성0.5).
– 탈퇴하려고 시도했을 때 탈퇴 버튼을 찾기가 무척 어려웠습니다. 즉, 검색으로도 찾기 어려웠습니다(사용성0.5).
– 탈퇴 기능 자체가 제대로 동작하지 않았고, 언제 탈퇴 기능이 동작하는지 파악할 수 없었습니다(가용성0.5).
– 사이트 디자인은 그다지 나쁘지 않았지만, “야! 멋진데!” 하는 탄성을 자아낼 정도가 아니었습니다(심미성0.8).
– 이 회사에 대한 브랜드는 그다지 유명하지 않고, 결정적으로 사용자가 겪은 불만을 토로하는 수단조차 마련해 놓지 않았습니다(오프라인 이슈0.5).
이렇게 얻은 값들을 계산해 보지 않아도 이 사이트에 대한 사용자 경험은 무척 낮다는 것을 알 수 있습니다.
이 공식으로 얻은 사용자 경험에 대한 수치가 어떤 의미가 있는 것은 아닙니다. 이 공식을 보면 사용자 경험을 이루는 각 요소들은 합이 아니라 곱의 형태라는 것을 알 수 있습니다. 즉, 어떤 항목을 중요하게 여기는지는 사용자마다 다르겠지만, 한 항목이 나빠지면 전체적인 사용자 경험도 같이 나빠진다는 뜻이죠.
인간의 두뇌에는 슈퍼 컴퓨터도 근접할 수 없는 비선형성이 있습니다. 즉, 인간의 두뇌는 비언어적이고(non-verbal), 비이성적이며(non-rational), 직관적이죠(intuitive).[헌트08] 따라서 사용자 경험을 공식화해서 한 항목 당 평가를 하지 않아도, 암호 같은 메시지를 출력하는 뱅킹 시스템, 삭제를 해도 존재했다는 흔적을 남기는 프로그램, 조폭 세계처럼 한번 가입하면 절대로 탈퇴하지 못하는 서비스, 우리는 이런 것들을 보면 불편을 느끼고 짜증이 나며 좌절합니다. 즉, 우리의 사용자 경험은 거만한 소프트웨어(혹은 서비스)앞에서 한없이 망가져만 갑니다.
우리는 왜 거만한 소프트웨어를 끊임없이 만드는 걸까요? 우리가 가진 기술이 아직 성숙하지 않아서 그럴까요? 하지만 단순하게 지난 10년 동안 우리가 이룬 하드웨어와 소프트웨어 기술을 놓고 봤을 때, 우리가 기술적인 측면에서 진보하지 않았다고 주장하는 것은 매우 궁색한 변명인 듯합니다.
거만한 소프트웨어를 만드는 것들
데이비드S. 플랫(David S. Platt)은 거만한 소프트웨어를 탄생시킨 책임을 괴짜(geek)들에게 돌립니다.[플랫08] 이 괴짜들은 졸트 콜라(Jolt cola, 일반 콜라보다 카페인이 많이 들어있습니다.)를 즐겨 마시며, 남성 호르몬에 중독되었고, 신기술이라면 물불을 가리지 않으며, 똑똑함에 목숨을 거는 종족입니다. 물론 이런 괴짜들, 즉 개발자들이 기술을 사랑한 나머지 사용자를 그다지 배려하는 않는다는 것에는 전적으로 동의합니다. 하지만, ‘거만한 소프트웨어’ 의 모든 책임을 개발자에게 돌리기에는 조금 석연치 않은 부분이 있습니다. 특히, 프롤로그를 장식해준 ‘겸손한 개발자 나대리 이야기’ 에 등장한 나영철 대리의 상황을 보면 더욱 그렇습니다.
월말 실적 때문에 바쁘게 주문을 입력해야 했던 영업부 김진상 대리 입장에서 보자면, 자신이 사용할 ‘생산요청시스템’ 과 관련이 없는 보안 프로그램을 설치하고, 오더를 입력하려고 컴퓨터를 몇 번이나 부팅하고, 웹 브라우저는 시도 때도 없이 죽었기 때문에, ‘겸손한 개발자 나대리’ 가 만든 생산 요청 시스템은 전형적인 ‘거만한 소프트웨어’ 였습니다.
하지만, 나 대리가 만든 ‘생산 요청 시스템이 거만해질 수밖에 없는 이유를 간단하게 요약해 봐도 모든 책임이 개발자에게 있지 않다는 것이 드러납니다. PM인 강과장과 나대리 회사 사이에서 일어나는 갑을 관계의 문제점, 20장짜리 파워포인트 설계서와2시간의 설명으로 모든 것을 파악해야 했기에 발생한 유과장과 개발자 나대리 사이에서의 의사소통 오류, 폭포수 개발방법을 사용했기 때문에 지나치게 늦게 받은 사용자 피드백, 일정만을 챙기는 꽉 막힌 프로젝트 관리, 어설픈 표준화 때문에 생기는 오류 등.
마르크스 주장 가운데 특히 많이 인용되는 것은 ‘상부구조’ 와 ‘하부구조’ 일 겁니다. 마르크스에 따르면 생산력은 하부구조로서 과학, 기술, 노동으로 구성되며, 상부구조는 생산관계로서 정치, 사상, 이데올로기로 구성됩니다. 하부구조와 상부구조의 개념이 중요한 이유는 하부구조가 바뀌어야지만 상부구조가 바뀌기 때문이죠. 즉, 노동자계급이 중심이 되는 혁명의 당위성을 제시하는데, 자본가와 노동자로 구분되는 하부구조가 깨져야 노동자를 억압하는 상부구조도 바뀐다고 합니다.
물론 여기서는 마르크스의 주장의 옳고 그름을 따지려는 게 아닙니다. ‘상부구조’ 와 ‘하부구조’ 와 비슷한 은유가 소프트웨어 분야에서도 존재합니다. 멜빈 콘웨이(Melvin Conway)는1968년 데이터메이션(Datamation) 지에서 이렇게 설명했습니다. “시스템을 설계하는 조직들은 자신들의 조직 사이에 의사소통 구조(communication structure)를 모방한 형태의 설계를 만든다.” 이것을 콘웨이 법칙(Conway’ s law)이라고 합니다. 예를 들자면, ‘네 개의 팀이 하나의 컴파일에서 작업할 때, 4단계(four-pass) 컴파일러를 얻는 것’ 이 바로 대표적인 콘웨이 법칙입니다.[신승환08]
물론, 거만한 소프트웨어가 탄생하는 데에는, 플랫이 지적한 것처럼 괴짜 같은 개발자의 책임도 있습니다. 하지만, 과잉 친절의 세상 속에서 태어나는 ‘거만한 소프트웨어’ 를 저지하려면, 우리는 사회공학적인 콘웨이의 법칙 그리고 ‘거만한 소프트웨어’ 가 탄생하는 그 맥락(context)을 이해해야 합니다. 즉, 마르크스의 표현을 빌리자면, ‘거만한 소프트웨어’ 라는 상부구조를 고치려면 ‘거만한 소프트웨어’ 를 탄생시킨 하부구조를 찾아서 깨트려야 합니다.
* 이미 출판된 <겸손한 개발자가 만든 거만한 소프트웨어>의 글을 옮겨 놓은 것입니다.
참고문헌
[힐뚜넨07] 『Mobile User Experience, 모바일 사용자 경험』 , 2007, 한빛미디어, 미카 힐뚜넨, 마르쿠 라우까, 야리 루오말라
[헌트08] 『Pragmatic Thinking Learning: Refactor Your Wetware』, 2008, Pragmatic Bookshelf, Andy Hunt
[신승환08] 『도와주세요! 팀장이 됐어요』 , 2008, 위키북스, 신승환
[플랫08] 『소프트웨어, 누가 이렇게 개떡같이 만든거야』 , 2008, 인사이트, 데이비드 S. 플랫
글 : 신승환
출처 : http://www.talk-with-hani.com/archives/1292