디지털 갑질은 사용자를 고려하지 못한 소프트웨어 개발 때문에 발생한다
2008년 데이비드 플릿은 그의 책 “소프트웨어 누가 이렇게 개떡같이 만든거야 Why Software Sucks... and What You Can Do About It”에서 소프트웨어가 너무 복잡해 사용자를 좌절하게 만든다고 지적했다. 그는 1990년대까지는 소프트웨어가 주로 직원들을 위해 사용되었지만, 2000년대 초부터 일반인들도 일상생활에서 소프트웨어를 사용하게 되었다고 설명한다. 이메일, 온라인 사진 저장, 전자 달력 등으로 많은 일이 디지털로 대체되었지만, 여전히 사용하기 어려운 소프트웨어가 문제라고 비판했다.
10여년이 지난 오늘날 우리는 모든 일상과 업무에 걸쳐 소프트웨어를 사용한다. 모바일 앱, 이메일, 키오스크, 대출 신청 등 다양한 서비스를 사용하는 것은 필수가 되었으며, 이는 고객은 물론 기업과 직원 모두에게 영향을 미친다. 심지어 배달 서비스 소프트웨어를 사용하지 못하면 음식점 운영이 어려워질 정도다. 소프트웨어 개발자에 대한 수요가 급증하며, 그들의 몸값도 크게 올랐다. 그러나 소프트웨어의 사용성 문제는 여전히 해결되지 않았다.
"어리석은 사용자 인터페이스 문제"는 여전하다. 예를 들어, 특수 문자를 제한하는 비밀번호 규칙, 저장 실패 메시지, 매장찾기 웹페이지의 결과 없음 메시지 등이다. 사용해야 할 소프트웨어가 더 많아졌지만, 문제 해결은 이루어지지 않았다. 결과적으로 더 많은 개떡 같은 소프트웨어가 생겼다.
'사용성Usability'은 소프트웨어의 성질로 정의되지만, '디지털 갑질'은 사용하기 어려운 소프트웨어를 계속 사용해야"만" 하는 사용자가 겪는 현상이다. 기업들은 1990년대부터 경쟁력을 유지하기 위해 사용성을 개선해왔으나, 정부 웹사이트와 직원 업무용 소프트웨어에서는 여전히 사용성 문제가 심각하다. 예를 들어, 조달청 나라장터는 공공 입찰 정보를 제공하는 필수 서비스이지만, 사용법이 너무 복잡해 사용자들이 동영상을 보고 배워야 한다. 또 건강검진기관찾기 사이트는 대도시에서는 병원이 너무 많이 검색되고, 시골에서는 아예 병원이 나오지 않는 문제가 있다. 이처럼 디지털 갑질은 사용자의 불편을 방치한 소프트웨어에서 여전히 발생하고 있다.
디지털 갑질은 사용자가 불편한 소프트웨어를 어쩔 수 없이 계속 써야 할 때 발생하는 현상이다 (사용성 문제는 원인).
패스트푸드 매장에서 버거 30개를 주문하는데 직원이 “포장인가요? 여기서 드시나요?”라고 물어본다는 농담이 있다. 이 농담은 상황을 고려하지 못하고 규칙대로만 행동하는 직원의 비유연성을 비꼬는 농담이다. 소프트웨어는 원래 유연성이 없으며 규칙대로만 행동한다. 불편한 소프트웨어를 만드는 것은 유연성이 없는 고지식한 직원을 채용하는 것이며, 그 소프트웨어가 사용자에게 부당한 요구를 강요한다.
많은 기획자와 개발자들은 소프트웨어 시스템의 동작과 제약에 익숙해, 사용자 관점에서 생각하기 어렵다. 그들은 시스템 설계 과정에서 초보자의 입장을 충분히 고려하지 못하고 복잡한 기능과 절차를 그대로 사용자에게 떠넘긴다. 이러한 문제는 테슬러의 법칙에 부합하는데, 좋은 소프트웨어는 복잡한 내부 과정을 처리하여 사용자가 쉽게 이용할 수 있도록 설계되지만, 그렇지 않은 경우 복잡도가 사용자에게 전가된다.
이러한 문제는 연동의 부재에서도 나타난다. 예를 들어, 아파트 방문 차량 관리 시스템에서는 경비실에서 차량 번호와 방문 호수를 등록했음에도 불구하고, 주차장 게이트에서 다시 인터폰으로 확인해야 하는 절차가 요구된다. 이로 인해 방문자뿐 아니라, 기다리는 주민들과 경비원도 불편을 겪는다. 이처럼 사용자의 흐름과 맥락을 고려하지 않는 시스템은 비효율적인 경험을 초래한다.
시장 경쟁이 치열한 분야에서는 UX 전문가들이 소프트웨어 개발에 적극 참여해 사용자 경험을 개선하지만, 경쟁이 적은 분야에서는 UX의 중요성이 간과되거나 단순한 시각적 디자인에만 그치기 일쑤다. UX 전문가가 소프트웨어 설계에 참여하지 않거나 개발자의 요구에 따라 인터페이스만 형식적으로 제공하는 경우, 사용자의 경험이 크게 저하된다. 필요한 기능이 있는가(기능성Functionality)와 여러 상황에서도 잘 동작하는가(신뢰성Reliability) 기준으로만 만들어지는 소프트웨어가 너무 많다. 이 두 가지는 아론 월터Aarron Walter가 정의한 사용자 니즈의 4단계 수준 중 가장 아래에 위치한다.
결국, 디지털 갑질은 사용자 경험을 고려하지 않은 소프트웨어에서 발생하며, 기획자와 개발자가 그 원인이 된다. 그러나 이는 그들의 역량을 폄하하려는 것이 아니라, 사용자 경험을 이해하고 반영하는 역량이 필수적임을 강조하는 것이다. 좋은 소프트웨어는 UX 관점에서 설계되고, 사용자와 조직의 경험을 향상시켜 경쟁력을 높인다.
디지털 갑질의 숨겨진 가해자는 소프트웨어를 만든 사람들이다.
디지털 갑질의 책임이 기획자와 개발자에게만 있는 것은 아니다. 소프트웨어가 개발되기 전에는 전략 수립이 먼저 진행된다. 전략은 무엇을 만들지를 결정하는 단계로, 어떻게 만들지에 대한 구체적인 방법은 포함되지 않는다. 비즈니스 목표를 달성하기 위해 어떤 상품을 만들고, 어떤 방식으로 개편하며, 디지털 전환을 위해 어떤 앱이나 웹을 도입할지 결정하는 것은 모든 조직의 중요한 업무이다. 이를 담당하는 부서는 전략기획, 상품기획, 서비스 기획 등의 조직이며, 경우에 따라 외부 컨설팅을 받기도 한다. 실제로 많은 정부 기관, 금융 회사, 서비스 기업, IT 회사들이 매킨지, 보스턴컨설팅, 베인앤드컴퍼니, PWC, KPMG, EY 등과 같은 외부 컨설팅 회사에 전략 수립을 의뢰한다.
경영진에게 보고되는 전략 담당 부서나 컨설팅 회사의 전략 보고서를 본 적이 있는가? 이 보고서들은 체계적이고 논리적이며, 명확한 근거와 메시지로 설득력을 갖춘다. 컨설턴트들은 해당 비즈니스를 이해하고 회사의 KPI를 파악하여, 사내 이해관계자들이 무엇을 원하는지 빠르게 파악하고 그에 맞춘 보고서를 작성한다. 또 여러 비즈니스 사례에서 해당 조직에 적용할 수 있는 방안을 찾아낸다. 덕분에 경영진을 대상으로 한 전략 보고는 대체로 성공적으로 마무리된다. 경영진은 이러한 전략을 추진하면 시장 경쟁력을 확보할 수 있을 것이라는 확신을 갖는다.
이 전략을 바탕으로 경영진의 기대 속에 소프트웨어 개발 과제가 시작된다. 그러나 문제는 여기서부터 발생한다. 전략을 바탕으로 개발 기간과 예산이 설정되지만, 실무 개발자 입장에서는 구체화되지 않은 전략이 많다. 예를 들어, 한 보험사의 전략 보고서에서 제시된 “모바일 웹에서 세 번의 클릭으로 보험 신청 가능하게 한다”는 목표는 매우 적절해 보인다. 그러나 개발 실무자들은 이 목표를 달성하기 막막해한다. 보험 신청 프로세스와 내부 업무 프로세스를 전면 수정해야 하기 때문이다 (정부 규제도 있다 ㅠㅠ). 이러한 어려움 속에서 개발이 시작되면, 경영진의 높은 기대치를 충족하지 못할 것이라는 스트레스가 실무진을 압박하게 된다. 결과적으로 정부나 금융 분야에서 진행되는 개발 과제들은 종종 ‘막장 과제’로 불리게 된다. 이는 전략의 부족으로 인해 소프트웨어 개발 범위와 일정이 잘못 설정된 탓이며, 이는 디지털 갑질의 주요 원인 중 하나다.
대규모 개발 프로젝트를 여러 번 경험한 프로젝트 매니저들은 일정 문제를 해결하기 위해 고군분투한다. 이들은 프로젝트를 완수하기 위해 기능 구현에 집중할 수밖에 없다. 소프트웨어 개발의 성패는 계약서에 명시된 기능이 정상적으로 작동하는지로 판단되기 때문이다. 이 과정에서 UX 전문가들은 사용자가 편리하게 사용할 수 있는 소프트웨어를 설계할 기회가 제한된다. 사용성 문제를 발견해도 인터페이스를 수정할 시간이 없으며, 개발에 시간이 소요되는 화면 설계는 시도조차 어려워진다. 결국 개발이 용이한 화면만 디자인하게 된다. 디지털 갑질이 발생한다.
(다음 글로 연재합니다. 브런치 매거진은 https://brunch.co.kr/magazine/digitalgapjil입니다)