2011.12.19

기고 | 클라우드 UI 디자인, 이것만은 피하라!

David Taber | CIO
클라우드 앱의 UI를 훌륭하게 디자인하기는 보기보다 훨씬 어려운 일이다. 여기 우리가 최근에 경험했던 몇 가지 실수들과 가능한 솔루션들을 몇 가지 담아보았다.

필자는 사용하기에 너무 쉬운 제품을 만들기는 불가능하다고 수년간 주장해왔다. 그러나 업계는 이 주장이 틀렸다는 사실을 입증해 보였다.

단 너무 편이성에만 초점을 맞추어 제품을 만들어내다 보니 시스템 구성은 더 조잡하고 유지보수도 어려워지고 있다. 일부 클라우드 서비스 제공업체들이 개개인들(판매원들부터 소비자들까지)이 충분히 쉽게 사용할만한 제품들만 쫓다 보니 배치 이후 몇 달만 지나면 완전히 엉망진창이 되어 버린다.
 
좋은 겉모양에 치중하는 것!
업체들은 UI 그래픽에 애니메이션과 아마도 유용할 주의사항들을 담아 갈수록 더 예쁘게 만들어내고 있다. 그러나 이러한 UI는 종종 사용자들이 정말로 얻고자 하는 것을 가리는 ‘밝고 빛나는 물체(bright shiny objects)’로 작용한다. 물론 일반 사람들에게는 먹혀들 수도 있다. 하지만 이런 제품을 진짜 프로들이 사용하기는 곤란하다. ‘미모는 가죽 한 꺼풀’일 뿐이라고들 하는데, UI 스킨에서도 이는 마찬가지다.

◆ 해결 전략: 제공 업체들에게 더 나은 내비게이션과 ‘인포메이션 아키텍처(information architecture)’를 요구하라. 업체에 사용성 평가 그룹이 있는지 찾아보고, 이를 자격 요건 기준의 하나로 삼아라. 또 등록하기 전에 자신을 향후 사용성 검토 혹은 평가 집단에 넣어달라고 고집하라.

연속 자동-저장 기능!
인튜이트(Intuit)가 고유의 연속 자동 기능으로 마이크로소프트 머니(Microsoft Money)를 완패시킨 이래로 UI 디자이너들은 연속 자동 저장(continuous auto-save) 기능을 계속해서 추가해왔다. 시도는 좋지만 관리가 다소 복잡한 제품들에 지나치게 단순화시킨 자동저장기능은 완전히 재앙을 불러일으키는 격이다. UI가 자동저장 기능을 제대로 해내려면 복잡한 규칙, 구성, 변수뿐 아니라 다음의 것들까지 제공해야 한다.

· 되돌리기(실행취소) 기능. 이왕이면 여러 로그인 세션에서 실행된 변화들 전부에 대해서 실행취소가 가능하다면 더욱 좋겠다.

· 누가 언제 무엇을 바꿨는지를 보여주는 감사 추적 프로그램의 모든 변경 사항들을 자동 로깅하는 기능. UI가 바꾸고 있는 당사자에게 왜 그것을 바꿔야 하는지를 밝히도록 한다면 더욱 좋겠다.

· 구성을 스냅샷으로 보여주고 그것을 내보내기(export)하는 기능(XML 파일로 내보내기가 가능하다면 더욱 좋겠다).

· 그 스냅 샷 파일들을 불러오기(import)하여 시험, 재해 복구, 혹은 간단한 복제 등을 할 수 있는 기능.

◆ 해결 전략: 위의 기준들에 따라 UI 기능들을 평가하고, CVS와 같이 유용한 제삼자 제품이 있는지 확인하고, 등록하기 전에는 업체들의 로드맵을 보고 결정하라.

너무 쉽게만 만드는 것!
클라우드 업체들은 미친 듯이 새로운 것을 만들어내는데, 무엇보다 중요한 것은 그 성능들이 과연 쓸만한가이다. 그러나 엔지니어링 부문이 UI에 지나치게 치중할 경우, 성능들에 프로그램적으로 접근할 시간적 여유가 없어진다. 즉 그들이 만들어낸 ‘위대한 제품’은 사용자가 실질적으로 사용하고자 하면 ‘별볼일 없는’ 제품이 되어 버리기 십상이다.

· 그렇지 않으면 설정 구성에 코멘트를 달거나 이유들을 설명할 수 없다고? 진심으로 목록에 나열된 항목들의 의미와 거기에 내포된 불린 함수들의 의미를 3개월 뒤까지 기억할 수 있다고 생각하는가? 최우선적인 방법은 설정에 포함된 모든 항목들을 자가-문서화(self documentation)하는 것이다. 과연 당신의 UI에 이러한 기능이 포함되어 있는가?

· 스크립팅(scripting)이 안 된다고? 그렇다면 사용자는 마우스를 엄청나게 움직여야 하고 디버깅에 심각한 어려움을 겪게 될 것이다.

· UI 기능들 중에 API에서는 이용할 수 없는 것들이 많다고? 자동화하기도 어렵고 통합하기는 더욱 어려울 것이다. 뿐만 아니라 클라우드로 옮기려 했던 레거시 애플리케이션을 생각보다 더 오랫동안 잡고 있어야 할지도 모른다.

· 감사 추적, 메시지 디버깅, 에러 로그 등이 너무 적다고? 새벽 네 시에 347개의 룰 중에 어떤 것이 문제를 일으키는지 알아내야 하는 상황이 발생할지도 모른다. 그저 행운을 빈다.
 
◆ 해결 전략: 지금부터 12~18 개월간의 기록을 보관하려면 무엇이 필요한지를 생각해보라. 얼마나 많은 사람이 클라우드 시스템을 이용할 것이며, 얼마나 많은 일들이 동시에 진행될 것인가? 모든 것들이 정말로 일차원적이지 않다면, 위의 문제들에 대해 클라우드 UI들을 평가해봐야 할 것이다.

대형 시스템의 복잡성을 완전히 상실한 것!
사용 초보자들을 위해 쉽게만 만들어진 UI들은 아주 막대한 혼란을 빚어내기도 한다. 왜일까? 사용자들의 자가충족을 도모하다 보니, 모든 기능들이 가장 낮은 수준에서 나타나기 때문이다. 예를 들면 ‘내가 할 일은 바로 이 이메일을 전송하는 것이야…’ 같이 말이다.

그러나 이 것들은 예를 들면 ‘이메일을 보내기 위해 이 변수가 사용되는 모든 곳들을 보여달라’와 같이 톱다운(top-down) 관점에 상응하지 않을 수도 있다. 결과적으로는 눈에는 보이지도 않으면서 혹은 중복에 대한 표시 없이 거의 같은 행위를 하는(혹은 하나도 제대로 하지 못하는) 규칙이나 배열들이 수십 개씩 생길 것이다.

그리고 이로 인해 스크립트가 충돌하고 문제 해결이 아주 어려운 환경이 만들어질 것이다. 만일 UI가 한번 생성된 것들의 이름 변경을 허용하지 않는다면 당장 그만 두는 것이 좋다. 그러한 UI로는 (1) 실질적인 무언가를 시작도 하기 전에 이름부터 잘 붙일 방법을 생각해내야 하며 (2) 이 문제를 해결하기 위해서는 복사해서 원본을 지우는 방법 밖에 없기 때문이다.

◆ 해결 전략: 초보자들뿐 아니라 파워 유자들의 요구까지도 반드시 고려해야 하며, 시간이 흐르면서 해당 UI에서 실질적으로 관심 가져야 할 부분이 어디인지 파악해야 한다. 놀라워할 것 없이 적정 예산 내에서 UI가 제대로 돌아가게 하려면 잘 훈련된 반일제 직원을 고용해야 할 것이다.

*David Taber는 세일즈포스닷컴 성공의 비밀’의 저자이며 세일즈포스닷컴 관련 컨설팅 기업인 세일즈로지스틱스의 CEO다. ciokr@idg.co.kr



2011.12.19

기고 | 클라우드 UI 디자인, 이것만은 피하라!

David Taber | CIO
클라우드 앱의 UI를 훌륭하게 디자인하기는 보기보다 훨씬 어려운 일이다. 여기 우리가 최근에 경험했던 몇 가지 실수들과 가능한 솔루션들을 몇 가지 담아보았다.

필자는 사용하기에 너무 쉬운 제품을 만들기는 불가능하다고 수년간 주장해왔다. 그러나 업계는 이 주장이 틀렸다는 사실을 입증해 보였다.

단 너무 편이성에만 초점을 맞추어 제품을 만들어내다 보니 시스템 구성은 더 조잡하고 유지보수도 어려워지고 있다. 일부 클라우드 서비스 제공업체들이 개개인들(판매원들부터 소비자들까지)이 충분히 쉽게 사용할만한 제품들만 쫓다 보니 배치 이후 몇 달만 지나면 완전히 엉망진창이 되어 버린다.
 
좋은 겉모양에 치중하는 것!
업체들은 UI 그래픽에 애니메이션과 아마도 유용할 주의사항들을 담아 갈수록 더 예쁘게 만들어내고 있다. 그러나 이러한 UI는 종종 사용자들이 정말로 얻고자 하는 것을 가리는 ‘밝고 빛나는 물체(bright shiny objects)’로 작용한다. 물론 일반 사람들에게는 먹혀들 수도 있다. 하지만 이런 제품을 진짜 프로들이 사용하기는 곤란하다. ‘미모는 가죽 한 꺼풀’일 뿐이라고들 하는데, UI 스킨에서도 이는 마찬가지다.

◆ 해결 전략: 제공 업체들에게 더 나은 내비게이션과 ‘인포메이션 아키텍처(information architecture)’를 요구하라. 업체에 사용성 평가 그룹이 있는지 찾아보고, 이를 자격 요건 기준의 하나로 삼아라. 또 등록하기 전에 자신을 향후 사용성 검토 혹은 평가 집단에 넣어달라고 고집하라.

연속 자동-저장 기능!
인튜이트(Intuit)가 고유의 연속 자동 기능으로 마이크로소프트 머니(Microsoft Money)를 완패시킨 이래로 UI 디자이너들은 연속 자동 저장(continuous auto-save) 기능을 계속해서 추가해왔다. 시도는 좋지만 관리가 다소 복잡한 제품들에 지나치게 단순화시킨 자동저장기능은 완전히 재앙을 불러일으키는 격이다. UI가 자동저장 기능을 제대로 해내려면 복잡한 규칙, 구성, 변수뿐 아니라 다음의 것들까지 제공해야 한다.

· 되돌리기(실행취소) 기능. 이왕이면 여러 로그인 세션에서 실행된 변화들 전부에 대해서 실행취소가 가능하다면 더욱 좋겠다.

· 누가 언제 무엇을 바꿨는지를 보여주는 감사 추적 프로그램의 모든 변경 사항들을 자동 로깅하는 기능. UI가 바꾸고 있는 당사자에게 왜 그것을 바꿔야 하는지를 밝히도록 한다면 더욱 좋겠다.

· 구성을 스냅샷으로 보여주고 그것을 내보내기(export)하는 기능(XML 파일로 내보내기가 가능하다면 더욱 좋겠다).

· 그 스냅 샷 파일들을 불러오기(import)하여 시험, 재해 복구, 혹은 간단한 복제 등을 할 수 있는 기능.

◆ 해결 전략: 위의 기준들에 따라 UI 기능들을 평가하고, CVS와 같이 유용한 제삼자 제품이 있는지 확인하고, 등록하기 전에는 업체들의 로드맵을 보고 결정하라.

너무 쉽게만 만드는 것!
클라우드 업체들은 미친 듯이 새로운 것을 만들어내는데, 무엇보다 중요한 것은 그 성능들이 과연 쓸만한가이다. 그러나 엔지니어링 부문이 UI에 지나치게 치중할 경우, 성능들에 프로그램적으로 접근할 시간적 여유가 없어진다. 즉 그들이 만들어낸 ‘위대한 제품’은 사용자가 실질적으로 사용하고자 하면 ‘별볼일 없는’ 제품이 되어 버리기 십상이다.

· 그렇지 않으면 설정 구성에 코멘트를 달거나 이유들을 설명할 수 없다고? 진심으로 목록에 나열된 항목들의 의미와 거기에 내포된 불린 함수들의 의미를 3개월 뒤까지 기억할 수 있다고 생각하는가? 최우선적인 방법은 설정에 포함된 모든 항목들을 자가-문서화(self documentation)하는 것이다. 과연 당신의 UI에 이러한 기능이 포함되어 있는가?

· 스크립팅(scripting)이 안 된다고? 그렇다면 사용자는 마우스를 엄청나게 움직여야 하고 디버깅에 심각한 어려움을 겪게 될 것이다.

· UI 기능들 중에 API에서는 이용할 수 없는 것들이 많다고? 자동화하기도 어렵고 통합하기는 더욱 어려울 것이다. 뿐만 아니라 클라우드로 옮기려 했던 레거시 애플리케이션을 생각보다 더 오랫동안 잡고 있어야 할지도 모른다.

· 감사 추적, 메시지 디버깅, 에러 로그 등이 너무 적다고? 새벽 네 시에 347개의 룰 중에 어떤 것이 문제를 일으키는지 알아내야 하는 상황이 발생할지도 모른다. 그저 행운을 빈다.
 
◆ 해결 전략: 지금부터 12~18 개월간의 기록을 보관하려면 무엇이 필요한지를 생각해보라. 얼마나 많은 사람이 클라우드 시스템을 이용할 것이며, 얼마나 많은 일들이 동시에 진행될 것인가? 모든 것들이 정말로 일차원적이지 않다면, 위의 문제들에 대해 클라우드 UI들을 평가해봐야 할 것이다.

대형 시스템의 복잡성을 완전히 상실한 것!
사용 초보자들을 위해 쉽게만 만들어진 UI들은 아주 막대한 혼란을 빚어내기도 한다. 왜일까? 사용자들의 자가충족을 도모하다 보니, 모든 기능들이 가장 낮은 수준에서 나타나기 때문이다. 예를 들면 ‘내가 할 일은 바로 이 이메일을 전송하는 것이야…’ 같이 말이다.

그러나 이 것들은 예를 들면 ‘이메일을 보내기 위해 이 변수가 사용되는 모든 곳들을 보여달라’와 같이 톱다운(top-down) 관점에 상응하지 않을 수도 있다. 결과적으로는 눈에는 보이지도 않으면서 혹은 중복에 대한 표시 없이 거의 같은 행위를 하는(혹은 하나도 제대로 하지 못하는) 규칙이나 배열들이 수십 개씩 생길 것이다.

그리고 이로 인해 스크립트가 충돌하고 문제 해결이 아주 어려운 환경이 만들어질 것이다. 만일 UI가 한번 생성된 것들의 이름 변경을 허용하지 않는다면 당장 그만 두는 것이 좋다. 그러한 UI로는 (1) 실질적인 무언가를 시작도 하기 전에 이름부터 잘 붙일 방법을 생각해내야 하며 (2) 이 문제를 해결하기 위해서는 복사해서 원본을 지우는 방법 밖에 없기 때문이다.

◆ 해결 전략: 초보자들뿐 아니라 파워 유자들의 요구까지도 반드시 고려해야 하며, 시간이 흐르면서 해당 UI에서 실질적으로 관심 가져야 할 부분이 어디인지 파악해야 한다. 놀라워할 것 없이 적정 예산 내에서 UI가 제대로 돌아가게 하려면 잘 훈련된 반일제 직원을 고용해야 할 것이다.

*David Taber는 세일즈포스닷컴 성공의 비밀’의 저자이며 세일즈포스닷컴 관련 컨설팅 기업인 세일즈로지스틱스의 CEO다. ciokr@idg.co.kr

X