(출처: 소프트웨어 공학센터 웹진 자료:2015년 11월)
SI와 솔루션 개발의 차이 두 번째 시간으로, 이번에는 SI보다는 솔루션 개발에서 더 많이 활용되는 UX(User eXperience)에 대해 살펴보기로 한다. SI 소프트웨어에서 사용되는 대부분의 기능은 입력, 수정, 삭제, 출력이었다. 이런 기능들은 클라이언트/서버를 거쳐 웹 기반이 되면서 일정한 패턴의 화면 레이아웃을 유지할 수 있었다. UX가 적용된 후에도 큰 변화는 없었다. 단편적인 기능이었기 때문이었다. 하지만, 다양한 형태로 서비스되는 솔루션 소프트웨어에는 UX의 사용이 매우 두드러진다.
UX는 사용자의 환경과 목표를 공감하면서 만들어야 그 의미와 완성도가 깊다. UX가 사용자의 경험으로 소프트웨어를 사용하도록 인터페이스를 만드는 것이기 때문이다. UX가 기술적인 부분보다 감성적인 부분이 강조되는 이유도 이 때문이다. 하지만 UX는 디자인하고는 다른 개념이라는 것을 꼭 기억해야 한다. 디자인은 UI에 국한된 화면 위주의 결과를 내지만 UX는 사용자의 경험과 소프트웨어, 그리고 서비스가 모두 어우러지는 결과를 내는 것이기 때문이다.
이번 회에서는 UX에 대한 명확한 정의와 소프트웨어에서의 UX 역할에 대해 알아보도록 한다. 그리고 SI와 솔루션에서 UX의 차이가 무엇인지 살펴보고, UX를 설계하고 반영하는 방법에 대해 정리하도록 한다.
1. UX에 대한 명확한 정의
대다수의 사람들이 UX에 대한 정의가 명확하지 않다고 생각한다. 기존의 UI로는 설명하기 어려운 부분들이 있어 의미적으로 ‘확장’의 필요성에 의해 나타난 것이 바로 UX이다. <그림 1>은 API와 UI의 정의를 나타낸 것이다. API는 시스템 간의 인터페이스이고, UI는 시스템과 사용자 간의 인터페이스이다. 인터페이스는 양자 간의 약속된 통신 방법이기 때문에 시스템 간의 통신이 많았던 SI에서는 매우 중요하게 다뤄졌던 분야이다.
<그림 1> API와 UI 정의
API만 존재하던 호스트, 클라이언트/서버 시스템에는 사용자 화면이 크게 고려되지 않았지만, 웹 시스템이 나타나기 시작하면서 사용자 화면이 고려되기 시작했다. 처음에는 단순히 디자인만 고려하는 정도였지만 사용자 요구사항이 많아지면서 UI에 대한 관심이 많아졌다. 초기 UI는 사용자가 시스템에 단순한 명령을 내리기만 했지만 사용자와 시스템 간 필요한 대화를 하는 상호작용이 나타났다. 이것을 인터랙션이라고 한다. 이러한 인터랙션을 사용자 관점에서 정의하기 위해 사용자 경험이 필요하게 되었고 UX가 나타난 것이다. 이러한 내용이 <그림 2>에 나타나있다.
<그림 2> 인터랙션과 UX 
UX는 시스템, 해당 비즈니스 또는 제품을 사용할 때 사용자가 겪는 다양한 경험을 나타낸다. 또한 API, UI 등의 인터페이스와 인터랙션의 경험을 포함하고, 시스템이나 컨텐츠, 서비스를 사용한 경험도 포함한다.
2. 소프트웨어에서 UX 역할
<그림 3>은 화면 설계할 때 나뉘어 지는 역할자를 나타낸 것이다. 불과 몇 년 전만 하더라도 SI에서는 고객의 요구사항을 정리한 후 화면 설계를 시작한다. <그림 3>에서 보면, 개발자(Application Developer)가 분석부터 백-엔드까지 모두 설계하고 개발한다. 이러한 화면 설계는 대체로 요구된 기능 위주로 만들어지기 때문에 사용 만족도는 그다지 높지 않다. 그리고, UI가 적용된 SI에서는 단순히 화면 디자인만 디자이너가 역할을 넘겨받게 된다. UX를 적용한 화면 설계에서 가장 이상적인 역할 분담이 <그림 3>과 같다. UX 디자이너는 사용자 정보 분석을 통해 인터랙션을 정의하고, 이를 바탕으로 눈에 보이는 디자인을 UI 디자이너가 설계한다. 마지막으로 개발자가 기능과 네비게이션을 설계하고 코딩을 한다.
<그림 3> 화면 설계의 단계와 역할자
SI나 솔루션으로 구분하지 않더라도 최근의 소프트웨어 개발 프로젝트에서는 사용자 분석을 많이 하고 있다. 애자일의 사용자 스토리 워크샵(User Story Workshop)을 적용하기도 하고 전통적인 개발방법론에 사용자 리서치 프로세스(페르소나; Persona)를 넣어 사용자 분석을 하기도 한다. 또한 개발 프로젝트에서만 수행되던 이러한 작업들에 실사용자들이 직접 참여하는 경우도 점차 늘어가고 있는 추세다.
페르소나(Persona)의 개념 이해
http://guide.agilealliance.org/guide/personas.html
SI는 담당자를 제외하고는 고객(사용자)가 참여하는 경우가 거의 드물었다. 이러한 이유로 SI는 고객의 요구사항을 직접적으로 파악하기가 어려웠고 상호 관계도 좋지 않은 편이 많았다. UX의 등장은 이러한 어려움을 해소하고 프로젝트 팀과 고객 간의 신뢰를 회복하게 도움을 주었고, 고객의 참여로 인해 <그림 4>와 같이 사용자 요구사항 분석을 쉽고 명확하게 정리하게 하였다. 또한 이렇게 정의된 요구사항은 명확한 프로토타입을 만들 수 있어 소프트웨어의 초기 모습을 정의하는데 도움을 주었다.
<그림 4> UX를 통한 사용자 요구사항 분석
UX는 소프트웨어에서 협의적으로, 사용자가 시스템을 좀 더 이해하기 쉽고 사용하기 편하게 해주는 역할을 해준다. 개발자 관점으로 만들어진 인터페이스에서 사용자 관점으로 인터페이스가 구성되면서 사용자는 더 편하게 소프트웨어를 사용하고 이해할 수 있게 되었다. 광의적으로, 고객(사용자)을 프로젝트에 참여시키는 계기가 마련되었다. 소프트웨어 개발에 있어 가장 큰 고민은 개발자와 고객 간의 커뮤니케이션이 많지 않아 요구사항 파악이 어렵다는 것이다. 또한 사용자 요구사항이 변경되는 경우가 잦아 일정에 무리를 주는 경우도 많다. 하지만, 고객의 참여가 높아지면서 만들고자 하는 소프트웨어의 형태가 더 명확해지고 고객의 관점으로 소프트웨어를 확인할 수 있어 프로젝트의 성공률을 높이고 있다.
SI에서 고객의 요구사항이 제대로 반영되었는지 확인하는 프로토타입은 매우 중요한 프로세스로 인식되었지만 프로토타입이 개발로 이어지는 경우는 거의 없었다. 왜냐하면 SI의 프로토타입은 사용자 관점이 아닌 개발자 관점으로 작성되어 사용자가 이해하기 어려웠기 때문이다. 사용자 관점으로 작성되는 UX는 프로토타입에도 적용될 수 있어 SI에서 계속 확대되는 추세이고, SI보다 더 다양한 서비스와 기능을 제공하는 솔루션의 증가는 사용자 관점을 중시하는 UX의 역할을 더 확대할 것으로 보인다.
3. SI UX와 솔루션 UX의 비교
사용자 관점으로 소프트웨어를 개발하는 것은 SI UX와 솔루션 UX의 차이는 없다. 다만, 개발 시작 전에 사용자가 정해진 SI와 불특정 다수인 솔루션의 차이 때문에 UX를 적용하는 프로세스가 다르다.
SI는 인터페이스 구성이 대부분 비슷한 웹 기반 애플리케이션이 많아 UX의 표준을 정의하고 그에 따르는 경우가 많다. 이러한 이유로, 대규모 SI 프로젝트를 수행하는 업체는 UX 표준을 전담하는 부서를 운영하고, 표준 UX 시스템을 개발하여 사용 중이다. 표준 UX의 내용은 일반적으로, 흔히 볼 수 있는 웹 기반 애플리케이션의 화면 레이아웃을 선택하고, 이벤트 발생을 위한 메뉴, 버튼, 입력상자 등을 선택하도록 하고 있다. (<그림 5> 참조)
<그림 5> LG CNS의 DevOn UI
솔루션 UX는 SI UX와는 다르게 표준으로 잡기가 어렵다. 그 이유는 불특정 사용자 대상이라 사용자 관점이 매번 바뀌기 때문이다. 따라서 만들고자 하는 솔루션마다 UX 전략을 별도로 수립해야 한다. <그림 6>은 UX 수립 프로세스를 나타낸다. 솔루션 UX에서 가장 중요한 프로세스는 사용자 리서치를 통한 사용자 경험 분석이다. 이 프로세스에 따라 UX의 가치와 전략이 천차만별로 나타날 수 있다. SI에서도 <그림 6>과 같은 프로세스로 UX를 수립해도 되지만, 일반화된 웹 기반 표준 UX를 따르는 경우가 많다.
<그림 6> UX 수립 프로세스
자료: 조성봉의 Ux for beginners
이번에는 프로토타입부터 개발, 테스트까지의 프로세스를 살펴보겠다. <그림 7>은 SI의 UX 개발 프로세스를 나타내고 있다. 사용자 리서치를 통해 만든 프로토타입을 기초로, UX 구조와 인터랙션을 설계한 후 UI를 개발하고, 이와 동시에 html로 보여지게 되는 컨텐츠를 설계한 후 시각적인 디자인을 반영하여 개발하게 된다. 이러한 개발을 나타낸 것이 <그림 7>에서 보이는 ‘UI 개발’과 ‘시각 디자인’이다. 앞에서 언급된 SI의 표준 UX가 이 프로세스에서 적용되어 개발된다.
<그림 7> SI UX 개발 프로세스
자료: 오래가는 UX 디자인, http://bahns.net/5673489
UX가 이슈화된 최근에서야 SI 표준 UX가 나타나기 시작했지만, SI는 웹 브라우저로 서비스되는 것이 일반적이고 기간도 20년이 넘었기 때문에 UX가 표준화가 가능했다. 솔루션은 서비스되는 기기나 형태가 다양하여 이러한 표준화가 어렵다. <그림 8>은 솔루션의 UX 개발 프로세스를 나타내고 있다. 솔루션은 서비스 방법에 따라 크기, 동작 방식, 소재 등에 따라 겉으로 드러나는 외형을 설계하게 된다. 이를 <그림 8>에서는 ‘산업 디자인’으로 표시하고 있다.
<그림 8> 솔루션 UX 개발 프로세스
자료: 오래가는 UX 디자인, http://bahns.net/5673489
UX는 사용자들이 소프트웨어가 좋은지 나쁜지 판단하는데 가장 많이 반영되는 요소다. UX의 중요성이 강조되는 이유가 이 때문이다. 하지만 UX를 UX 디자인, UI, UI 디자인 등 다양한 의미로 오해하는 경우가 많아 디자이너의 역할이라고 생각하는 경우가 많다. 많은 시간과 비용을 들였지만 솔루션과 사용자를 연결해주는 것은 좋은 디자인만 해결하기에는 부족하다.
이번 회에서는 소프트웨어를 만드는데 UX가 필요한 이유를 명확히 파악함으로써 사용자가 소프트웨어를 더 편하고 만족스럽게 사용하기 위해서는 UX가 반드시 필요하다는 것을 확인하였고, 이를 위해 소프트웨어에서 UX가 차지하는 역할에 대해서도 살펴보았다. 또한 SI와 솔루션 UX를 비교하면서 솔루션에서 UX를 어떻게 적용하는지에 대해서도 살펴보았다.
개인적인 사용자 경험과 감성이 점점 더 요구되는 최근의 트렌드로 볼 때 소프트웨어에서 UX에 대한 요구는 더 높아질 것으로 보인다. 소프트웨어 관점에서 볼 때 UX는 아직 초기 단계이기 때문에 체계적으로 적용할만한 사례나 가이드가 많이 부족하다. 따라서 만들고자 하는 솔루션의 특징을 잘 파악하여 필요한 UX 요소가 무엇인지, 소프트웨어의 기능과는 어떻게 연계하는 것이 사용자에게 도움이 되는지 분석하는 것이 중요하다.
