쎈과 서연이의 행방불명 난 이런 사람이야. 지금 이 시간에는 말이지…

141/100

디바이스 성능과 네트워크. 그리고, 보안

UX 소프트웨어를 개발하기 위해서는 기본적으로 갖춰져야 할 요건들이 있다.

1. 디바이스의 성능이 충분한가

UX 라는 것이 "사용자 경험" 을 의미하는 것이기 때문에, 아날로그, 디지털을 구분하는 것은 무의미 하고, 하드웨어, 소프트웨어 적인 측면들을 전반적으로 고려해야 하는 것이긴 하지만, (예로 들어 아이폰의 하드웨어 버튼들과 소프트웨어의 복합적인 경험 구축과 같이...)

기본적으로 UX 라는 것은 "물리적으로 실현 불가능한 행동들을 가능하게 하는 디지털" 을 베이스로 해서 진화하는 분야라고 보기 때문에, (쉽게 이야기해서 물리적인 행동이 정해진 것이 가질 수 있는 디바이스의 사용성은 결국 물리적인 부분에 최우선을 둘 수 밖에 없지만, 디지털은 물리적 행동과 사용방식의 연관을 무시한채로 조합할 수 있기에 더 약한 결합력을 가질 수도 있지만, 더욱 강한 결합력을 가질 수도 있다. 예를 들자면 아이폰의 터치방식을 통한 사진찍기 처럼 말이다... 모든 디지털 카메라 회사들이 아날로그적 사진찍기의 물리적 고정관념에 사로잡혀 있을때 아이폰은 이것을 분리해서 재결합 해버렸다.)

그 디지털의 베이스가 되는 디바이스의 성능은 매우 중요하다. (여기서 디바이스란 OS, VM 과 같은 바탕이 되는 베이스까지 포함한다고도 볼 수 있다.) UX 의 새로운 구축따위가 아무리 중요하다고 해봤자. 그 보다 상위에 존재하는 중요성은 "반응성" 이 된다. UX 란 결국 "인간과 기기의 대화" 를 바탕으로 하는 커뮤니케이션의 한 종류이기 때문에 아무리 뛰어난 방식을 제시한다고 해봤자. 그 반응이 느리다면 아무런 소용이 없게 된다. (아무리 뛰어난 화술이 있어봤자 말더듬이 라서 제대로 말을 못하면 그 대화가 과연 매끄러울까?)

디바이스의 성능이란 크게 "처리속도" 를 바탕으로 하는 "반응성" 과 "디스플레이의 크기, 터치의 정확도, 음질의 정도" 와 같은 것들을 바탕으로 하는 "물리적 제약사항" 을 가진다. 이 중, 물리적 제약사항과 같은 것들은 디바이스의 특성이자 한계성 그 자체이기 때문에 순응하고 적응하는 것이 기본적인 해결방법이지만, 처리속도의 경우는 "투자 대비 효과" 라는 경제성을 바탕으로 하기 때문에 합의해야 할 대상이 되게 된다.

UX 에서 디바이스 성능에 대한 처리는 1차적으로 그 기기가 가질 수 있는 물리적 제약사항을 우선적으로 고려해서 몇 가지의 형태를 정하고, 2차적으로는 예로 나온 몇 가지의 형태와 처리속도를 대입해서 형태를 결정하는 것이 옳다고 본다. 그리고, 디자인과 같은 실제 소프트웨어 레벨의 작업에서 여유분의 처리속도를 가지고 "텍스쳐의 정도, 모션의 정도" 와 같은 시각효과를 조절하는 것이 진행되어야 하고...

현재 "많은 수의 기업" 들이 채택하는 "전문 분야의 파트단위 작업 이 후, 결합" 이라는 워크플로우는 이런 경우에서 매우 빛나는 실패를 만들어내게 된다. 물리적 제약 사항을 기초로 두고 진행되던 기계 산업 시대의 마인드는 "전문가" 라는 부류를 만들어내고 그 전문가들의 작업을 관리하는 "관리자" 라는 소수의 부류를 만들어냈지만, 물리적 제약 사항이 사라진 상태의 디지털 디바이스의 작업에서는 관리자 - 전문가의 수직 체계는 그 한계성을 뚜렷히 드러내게 된다.

각 파트 단위의 작업들에 존재하는 다양한 변수와 한계성을 종합적으로 판단해서 "조절" 해야 하는 것이 디지털 미디어의 작업에 필수적인데도 불구하고, 각 단위의 작업을 선행한 다음 "결합" 하려고 하니 이것저것이 몽땅 뒤틀어지는 상황이 생길 수 밖에... 각 파트의 작업자들이 대화하고 자기 파트의 한계성을 상대편에 적용시킬 수 있는 "수평 성향" 이 필요한데도 불구하고, 그러지 못하는 수직성향은 결국 결과물의 조악함으로 되돌아오게 된다.

"디바이스의 성능이 충분한가?" 라는 명제는 거꾸로 "현재의 작업물이 디바이스의 성능에 부합되는가?" 라는 명제로도 설명될 수 있다. 이런 성능과 반응성에 대한 타협은 매우 중요하고, 어느 한쪽이 고정된 채로는 쉽사리 진행되기 어려운 면이 있다. "최초의 목적에 무조건적으로 맞춰야 한다" 라는 수직적 업무구조를 버리고 "성능상에서 최선의 반응성을 낼 수 있는 가진 UI 로 적절히 조절하는" 방식이 필요하다.

그런 기획 > 디자인 > 개발 이라는 일방통행적 업무구조는 UX 에서 가장 중요한 반응성을 거세하는 최악의 결과를 만들어내게 된다. 모든 파트들이 병렬 순서에 대한 작업에 (예를 들어 기획은 사용자 니즈, 시나리오를 우선적으로 분석하고, 아트웍은 목적에 맞는 타이포, 컬러, 쉐입 등의 테마를 정하고, UX 개발 부분은 성능과 반응성의 합의점을 찾는 최선의 UX 구조를 만들어서 전반적인 합의가 끝난 이후 실 파트 단위의 작업이 이루어지는 형식의 작업에) 익숙해지지 못한다면 조악한 결과물은 피할 수 없는 필연이 될 수 밖에 없다. 그리고... 창의성 따위도 기대하기 어려울 테고...

2. 네트워크에 따른 동기/비동기 데이터 구조

HTML5 이후에 웹 어플리케이션들이 가질 가장 두드러지는 성향은 "언제나 연결되어 있는 랜선과 컴퓨터의 디바이스" 의 서버-클라이언트 데이터 동기 구조가 사라지는 것이지 않을까 싶다.

이는, 모든 디바이스들을 "언제나 순조로운 수준의 네트워크에 접속되어 있는 설치형" 과 "네트워크가 끊기거나 느려질 것을 예상하고 만들어야 하는 이동형" 으로 나누는 계기가 될테고, 후자에 해당하는 거의 대부분의 웹서비스들은 기존의 "사소한 것마저 서버를 통해 프로세싱 하던 웹서비스" 의 기본형에서 벗어나서, 마치 모바일 어플리케이션들과 같은 비동기 데이터 업데이트의 구조를 가지게 될 것이다.

비동기 데이터 업데이트를 기반으로 하는 웹 어플리케이션들은 아주 당연하게 지금의 list - view - write 의 삼중 구분에서 탈피해야 하는 UX 구조의 변경이 필수가 될테고...

비동기 데이터 업데이트의 기반을 1차적으로 하는 UX 구조는 다시, 컨텐츠의 특성에 따른 분기점을 맞이 하게 될 것이다. 신뢰성을 필연적으로 가져야 하는 뉴스나 은행 업무를 보는데 RSS 리더나 메일과 같은 UX 를 적용할 수는 없을테니깐 말이다.

이런 네트워크 특성에 따른 UX 의 새로운 설계는 향후 몇 년간 가장 크리티컬하고 뜨거운 화두가 될 것이고, UX 전문가에게는 가장 최소한의 기본소양이 되지 않을까 싶다.

3. 보안

보안은 일단 디바이스나 VM, OS 따위가 뚫려 버리는 최악의 상황이 있을테고, 어플리케이션의 코드 결함에 따른 상황이 있을수 있다. 그리고... UX 전문가들에게 있어서의 보안이란 뚫리냐 마냐의 문제보다 사용자의 사용 상황에서 "얼마만큼 보안 때문에 걸치적 거릴 일을 없애 줄 수 있는가" 와 "사용상황에서 드러나는 보안유출" 이 있을 수 있을 것이다. 예를 들어 번호 키패드 따위에 각각의 음높이가 있다 했을때 패스워드를 치는 키패드에 마저 그 음높이를 적용하면 청음 능력이 뛰어난 사람이 읽을 수 있다는 소리가 되기도 하다.

UX 에서 보안이란 뚫릴만한 계기를 차단하고, 보안 때문에 무지하게 거추장 스러워질 수 있는 많은 요소들을 교통정리 해주는 일이 될 것이다. (교통정리 드럽게 되어서 최악의 결과를 맞았던 사례를 꼽자면 윈도우 비스타의 UAC 가 있다... 오죽하면 대부분 파워 유저들의 기본 셋팅이 관리자 계정 활성화에 UAC 차단이 되었겠는가...)

바탕 기술의 본질적인 부분들이 아직까지는 불안하기에 UX 와 같은 부분에서의 보안처리가 크게 이슈화 되지 않는 세상이지만, 일정한 시간이 지난 이후에는 보안에 대한 UX 레벨 디자인도 큰 이슈가 될 것이다.

덧글 (0) 엮인글 (0)

아직 덧글이 없습니다.


덧글 남기기


엮인글이 비활성 상태입니다.