컬럼/인터뷰
제공 : 한빛 네트워크
저자 : Jenn Webb
역자 : 최현민
원문 : Design your website for a graceful fail
웹사이트는 문제가 생길 수 있다. 문제는 발생할 수 밖에 없다. 하지만 대부분의 경우 사용자가 체감하는 문제를 최소화함으로써 문제를 처리하고 설명할 수 있다. Etsy 기술책임자인 Mike Brittain은 최근 인터뷰에서 탄력있는 사용자 경험(resilient user experience)관해 얘기를 했다. 인터뷰에서 전달한 견해는 아래와 같다.
Mike Brittain : "탄력있는(Resilient)" 사용자 경험은 시스템내에서 개별적인 실패에 대응할 수 있다. 그래서 사용자는 부분적인 기능장애에도 불구하고 문제없이 서비스를 이용할 수 있다. 규모가 큰 웹사이트는 다양한 데이타베이스, API 그리고 기타 백엔드 서비스로 구성되어 있다. 심도있게 애플리케이션을 고민하지 않는다면, 부분적인 사소한 문제가 발생하더라도 일반적인 "Server Error" 메시지를 보여줄 것이다. 이와 같은 결과는 사용자의 사용을 완전히 제한한다. 그리고 이것은 웹사이트, 소프트웨어 그리고 브랜드 자체에 대한 사용자의 신뢰에 잠재적인 격감을 일으킨다.
뉴욕타임즈 사이트의 기사 하나를 예를 들어 보겠다. 각 페이지에는 기사 내용이라는 가장 중요한 콘텐츠가 있다. 그리고 그 외에 소셜 공유툴, 로그인이 되어 있다면 개인적인 정보, 코멘트, 추천기사 그리고 광고와 같은 보조적인 내용과 모듈이 있다. 만약 독자에게 가장 중요한 정보인 기사 자체의 정보를 받아들이는데 문제가 발생한다면, 이것은 독자에게 의미있는 정보를 제공할 수 없다는 것을 의미한다. 하지만 보조적인 내용을 생성하는 하나 이상의 서비스에서 문제가 발생한다는 것은 독자에서 훨씬 적은 영향을 준다는 것을 의미한다. 결국 "탄력있는 디자인(resilient design)" 이라고 하는 것은 독자로 하여금 사이트에서 기본적인 기능(이 경우 기사)을 막지 않고 각각 모듈을 우아하게 실패하도록 만드는 것이다.
필자의 개인적인 상황에 더 맞는 또 다른 예가 있다. Etsy 방문자의 기본적인 기능은 사용자가 수제(handcrafted) 제품을 찾고, 평가하고 구입하는 것이다. Etsy.com의 제품 페이지는 제품을 "Favorite"로 만드는 메커니즘과 같은 모든 종류의 보조적인 정보와 툴을 포함한다. 우리의 Favorites 시스템이 작동하지 않는다고 해서, 사용자에게 오류 페이지를 보여주지 않을 것이다. 대신 우리는 모든 툴들을 숨긴다. 그러면서 소소한 기능 장애에도 불구하고 사용자는 여전히 물건을 찾고 구입할 수 있다. 사실 대부분의 방문자들이 이같은 보조기능이 작동하지 않더라도, 흡족하게 그 사실을 모를것이다.
디봅스(DevOps, Development+Operations) 문화에서 개발팀과 운용팀간의 경험과 지식을 꾸준히 공유하려는 노력을 보아왔다. 자신들의 소프트웨어가 어떻게 작동하는지, 그리고 다양한 서비스와 백엔드 요소들이 어떻게 상호작용하는지를 잘 이해하는 개발자는 실패 종류를 잘 이해하고 그에 맞게 대응한다. 그들의 소프트웨어와 하드웨어의 구성은 "장황한 서비스", "시스템의 대체 작동" 그리고 실패 이후 "재시도"와 같은 패턴을 이용한다. "탄력있는" 사용자 경험은 제품과 디자인 팀에서 더 많은 교류가 필요하다. 제품 디자인 작업은 시스템이 문제없이 돌아가는 환경을 가정한 상황에서만 사용자의 경험에 집중한다. 그래서 우리는 개별적인 서비스의 실패와 형태를 이해하고 그에 대한 계획을 준비하기 위해 제품 디자이너를 개발자와 함께 일하도록 할 필요가 있다.
이런 인터페이스 원칙이 데스크탑/랩탑 환경와 모바일/타블릿 환경에서 달라질까요?
Mike Brittain : 이런 원칙은 모든 사용자 인터페이스에 적용된다. 하지만 우리는 지속적으로 모바일 장치와 환경으로 이동함에 따라, 우리는 인터넷을 통해서 스마트폰 앱이 서버에 연결하는 상대적으로 불안정한 환경을 고려할 필요가 있다.
우리의 디자인 과정은 컴퓨터와 웹브라우져가 유선으로 연결이 되어, 상대적으로 네트웍 연결 실패율이 낮았던 이전의 경험에 영향을 받는다. 그래서 우리는 네트웍 연결이 좀처럼 실패하지 않는다고 기대할 수 있다. 우리는 모바일 소프트웨어가 무선 네트웍 환경에서 백엔드 서비스로 연결하는 시대로 점점 급속하게 접어들고 있다. 물론 이러한 장치들이 고속의 자동차나 기차에서도 사용될 수 있다는 사실은 말할 필요도 없다. 따라서 우리는 "탄력성(resilience)" 디자인을 네트웍 사용이 가능한 모든 환경에 접목시킬 필요가 있다.
프론트엔드(front-end)에서는 어떻게 우아하게 실패 할 수 있는가?
Mike Brittain : 프론트엔드는 클라이언트 사이드라고 생각할 수 있고, 또는 HTML 페이지를 만들기 위해 다른 백엔드 서버와 통신을 하는 가장 앞쪽의 서버 스크립트를 의미할 수 있다. 두 경우 모두 "탄력있는" 디자인을 위한 적합한 상황이다
"탄력있는" UI를 디자인함에 있어, 거의 모든 백엔드 서비스의 실패를 예상할 수 있다. "연결 실패", "연결 시간 초과", "응답 시간 초과" 또는 응답시에 "훼손된 데이타" 등이 예가 될 수 있다. "탄력있는" UI는 이런 문제를 하위 단계에서 찾고 유용한 응답을 보내주어야 한다. 그렇지 않고 일반적인 예외는 전체 페이지의 실패를 일으킨다.
이것은 클라이언트단에서는 Ajax 응답에서 실패를 발견하고 사용자의 사용을 블럭되지 않게 하거나, 제한된 시간동안 재시도하는 것을 뜻한다. 이 시점은 페이지 렌더링을 할때나 사용자와 상호작용하는 중일 수 있다. Gmail에 익숙한 사용자는 네트웍 장애나 백엔드 실패시점을 인지할 수 있다. 메일 송신중에는 "sending" 또는 어떤 변화가 생겼을 때는 "still trying" 또는 "offline"과 같은 작은 상태 메시지가 나타난다. 이런 배려는 한 번 접속 시도 후에 보여주는 "failed to send email"과 같은 범용 메시지보다 바람직하다.
"탄력있는" UI는 아래와 같은 일반적인 패턴으로 정리할 수 있다.
어떻게 실패를 발견할 수 있나?
Mike Brittian : 소소한 실패가 발생된 경우, 기본은 사이트의 필수적인 기능을 제한하지 않게 함으로써 그 실패를 숨기는 것이다. 예를 들어 우리는 "Favorite" 서비스에 문제가 발생했다고 해서 제품 페이지가 멈추지는 않는다. 회사에서는 이 경우에 대해서 많은 이야기를 나눌 필요는 없을 것이다. 정말 문제가 발생한다면 문제를 가장 먼저 알고 해결을 해야할 것이다. 막연하기보단 구체적인 용어를 사용해야 한다. 그리고 시간 정황과 해결 가능한 측정된 시간을 제공해야 한다. 만약 서비스가 중단이 되었고 데이타 복구를 위해 시간이 제법 걸린다면 3시간 뒤에 다시 확인해 보라고 말 하는 것이 사용자들이 20분동안 브라우져를 새로고침 하면서 사이트에 대해 불신을 쌓는 것보다 나을 것이다. 당신은 이런 메시지들이 사용자들에게 전달되기를 바랄 것이다. 이런 상황을 대비해 우리 Etsy에서 꽤나 쓸만한 패턴을 가지고 있다. 우리는 네트웍 외부에 위치한 "status blog"를 운용하고 있다. 우리의 데이타 센터에 문제가 발생하더라도 이곳에는 반드시 접근할 수 있다. Etsy.com의 모든 서비스 경고와 오류메시지는 이 블로그에 링크로 제공된다. 그리고 서비스 경고가 자동으로 커뮤니터 포럼의 최상단이나 또는 멤버들이 사이트의 도움을 찾을 수 있는 곳에 등록된다.
Volocity 2012 keynote summary에서 "게임 데이와 함께하는 실패 시나리오"를 언급했다. 게임 데이가 무엇이고 어떻게 진행이 되는 것인가?
Mike Brittain : 게임 데이란 실 운용환경에서 실패 시나리오 훈련을 의미한다. 이 훈련은 특정한 문제 상황하에서 우리 시스템의 예정된 대응을 확인하기 위해 진행한다. 우리는 이 과정을 적극적으로 관찰하며 어떤 예상치 못한 상황을 표면화시킨다.
우리는 이 훈련을 실 운용환경에서 진행하는데 그 이유는 개발, 테스트, 그리고 스테이징 환경에서는 100% 운용환경과 일치하지 않기 때문이다. 대부분의 경우 아마도 실제의 상황과 흉내낸 트래픽, 다른 개수의 장비 그리고 크기가 다른 데이타를 가지고 있을 것이기 때문이다. 이 훈련의 단점으로는 실 방문자들의 사용에 영향을 줄 수 있다는 것이지만 팀에 대한 실제의 신뢰도를 확인하고 실제 장애에 대한 능력을 훈련할 수 있다는 장점이 있다.
문제를 해결하고 개선했던 기능의 설정 로직이 잘 연결이 되었는지 확인을 목적으로, 우리는 정기적으로 사이트 전체적인 설정 플래그를 테스트 한다. 또 우리는 플래그가 설정이 되지 않았을 때, 사용자 경험이 우아하게 실패하는지 확인하기를 바란다. 예를 든다면, 우리 사이트의 "Favorite" 서비스가 작동하지 않을 때, 데이타를 읽고 쓰는 것이 같이 멈추고, UI의 여러 부분에서 "Favorites" 툴을 숨겼으면 한다. 게임 데이는 이런 것들을 증명하는데 도움을 준다.
"Favorites"를 비활성화시켰을때 우아하게 실패하지 않고 페이지 전체에 문제가 발생한다면 놀랄 것이다. 또 설정 플래그가 비활성화되었을 때, 여전히 서비스에 데이타가 읽고 쓰여진다면 또한 더욱 더 놀랄 것이다. 일부 실 운용 환경외에서 테스트를 흉내낼 경우 관찰할 수 없는 경우도 있다.
저자 : Jenn Webb
역자 : 최현민
원문 : Design your website for a graceful fail
웹사이트는 문제가 생길 수 있다. 문제는 발생할 수 밖에 없다. 하지만 대부분의 경우 사용자가 체감하는 문제를 최소화함으로써 문제를 처리하고 설명할 수 있다. Etsy 기술책임자인 Mike Brittain은 최근 인터뷰에서 탄력있는 사용자 경험(resilient user experience)관해 얘기를 했다. 인터뷰에서 전달한 견해는 아래와 같다.
- 개별 서비스의 실패나 부분적인 기능 문제에 대응하기 위한 디자인은 소프트웨어 개발자, 운용부서 그리고 개발과 디자인팀간의 협동이 필요하다.
- 유선 장치에 사용되었던 이전의 디자인 경험은 불안정한 모바일 네트웍을 고려할 때, 우리의 접속 기대치를 왜곡한다.
Mike Brittain : "탄력있는(Resilient)" 사용자 경험은 시스템내에서 개별적인 실패에 대응할 수 있다. 그래서 사용자는 부분적인 기능장애에도 불구하고 문제없이 서비스를 이용할 수 있다. 규모가 큰 웹사이트는 다양한 데이타베이스, API 그리고 기타 백엔드 서비스로 구성되어 있다. 심도있게 애플리케이션을 고민하지 않는다면, 부분적인 사소한 문제가 발생하더라도 일반적인 "Server Error" 메시지를 보여줄 것이다. 이와 같은 결과는 사용자의 사용을 완전히 제한한다. 그리고 이것은 웹사이트, 소프트웨어 그리고 브랜드 자체에 대한 사용자의 신뢰에 잠재적인 격감을 일으킨다.
뉴욕타임즈 사이트의 기사 하나를 예를 들어 보겠다. 각 페이지에는 기사 내용이라는 가장 중요한 콘텐츠가 있다. 그리고 그 외에 소셜 공유툴, 로그인이 되어 있다면 개인적인 정보, 코멘트, 추천기사 그리고 광고와 같은 보조적인 내용과 모듈이 있다. 만약 독자에게 가장 중요한 정보인 기사 자체의 정보를 받아들이는데 문제가 발생한다면, 이것은 독자에게 의미있는 정보를 제공할 수 없다는 것을 의미한다. 하지만 보조적인 내용을 생성하는 하나 이상의 서비스에서 문제가 발생한다는 것은 독자에서 훨씬 적은 영향을 준다는 것을 의미한다. 결국 "탄력있는 디자인(resilient design)" 이라고 하는 것은 독자로 하여금 사이트에서 기본적인 기능(이 경우 기사)을 막지 않고 각각 모듈을 우아하게 실패하도록 만드는 것이다.
필자의 개인적인 상황에 더 맞는 또 다른 예가 있다. Etsy 방문자의 기본적인 기능은 사용자가 수제(handcrafted) 제품을 찾고, 평가하고 구입하는 것이다. Etsy.com의 제품 페이지는 제품을 "Favorite"로 만드는 메커니즘과 같은 모든 종류의 보조적인 정보와 툴을 포함한다. 우리의 Favorites 시스템이 작동하지 않는다고 해서, 사용자에게 오류 페이지를 보여주지 않을 것이다. 대신 우리는 모든 툴들을 숨긴다. 그러면서 소소한 기능 장애에도 불구하고 사용자는 여전히 물건을 찾고 구입할 수 있다. 사실 대부분의 방문자들이 이같은 보조기능이 작동하지 않더라도, 흡족하게 그 사실을 모를것이다.
디봅스(DevOps, Development+Operations) 문화에서 개발팀과 운용팀간의 경험과 지식을 꾸준히 공유하려는 노력을 보아왔다. 자신들의 소프트웨어가 어떻게 작동하는지, 그리고 다양한 서비스와 백엔드 요소들이 어떻게 상호작용하는지를 잘 이해하는 개발자는 실패 종류를 잘 이해하고 그에 맞게 대응한다. 그들의 소프트웨어와 하드웨어의 구성은 "장황한 서비스", "시스템의 대체 작동" 그리고 실패 이후 "재시도"와 같은 패턴을 이용한다. "탄력있는" 사용자 경험은 제품과 디자인 팀에서 더 많은 교류가 필요하다. 제품 디자인 작업은 시스템이 문제없이 돌아가는 환경을 가정한 상황에서만 사용자의 경험에 집중한다. 그래서 우리는 개별적인 서비스의 실패와 형태를 이해하고 그에 대한 계획을 준비하기 위해 제품 디자이너를 개발자와 함께 일하도록 할 필요가 있다.
이런 인터페이스 원칙이 데스크탑/랩탑 환경와 모바일/타블릿 환경에서 달라질까요?
Mike Brittain : 이런 원칙은 모든 사용자 인터페이스에 적용된다. 하지만 우리는 지속적으로 모바일 장치와 환경으로 이동함에 따라, 우리는 인터넷을 통해서 스마트폰 앱이 서버에 연결하는 상대적으로 불안정한 환경을 고려할 필요가 있다.
우리의 디자인 과정은 컴퓨터와 웹브라우져가 유선으로 연결이 되어, 상대적으로 네트웍 연결 실패율이 낮았던 이전의 경험에 영향을 받는다. 그래서 우리는 네트웍 연결이 좀처럼 실패하지 않는다고 기대할 수 있다. 우리는 모바일 소프트웨어가 무선 네트웍 환경에서 백엔드 서비스로 연결하는 시대로 점점 급속하게 접어들고 있다. 물론 이러한 장치들이 고속의 자동차나 기차에서도 사용될 수 있다는 사실은 말할 필요도 없다. 따라서 우리는 "탄력성(resilience)" 디자인을 네트웍 사용이 가능한 모든 환경에 접목시킬 필요가 있다.
프론트엔드(front-end)에서는 어떻게 우아하게 실패 할 수 있는가?
Mike Brittain : 프론트엔드는 클라이언트 사이드라고 생각할 수 있고, 또는 HTML 페이지를 만들기 위해 다른 백엔드 서버와 통신을 하는 가장 앞쪽의 서버 스크립트를 의미할 수 있다. 두 경우 모두 "탄력있는" 디자인을 위한 적합한 상황이다
"탄력있는" UI를 디자인함에 있어, 거의 모든 백엔드 서비스의 실패를 예상할 수 있다. "연결 실패", "연결 시간 초과", "응답 시간 초과" 또는 응답시에 "훼손된 데이타" 등이 예가 될 수 있다. "탄력있는" UI는 이런 문제를 하위 단계에서 찾고 유용한 응답을 보내주어야 한다. 그렇지 않고 일반적인 예외는 전체 페이지의 실패를 일으킨다.
이것은 클라이언트단에서는 Ajax 응답에서 실패를 발견하고 사용자의 사용을 블럭되지 않게 하거나, 제한된 시간동안 재시도하는 것을 뜻한다. 이 시점은 페이지 렌더링을 할때나 사용자와 상호작용하는 중일 수 있다. Gmail에 익숙한 사용자는 네트웍 장애나 백엔드 실패시점을 인지할 수 있다. 메일 송신중에는 "sending" 또는 어떤 변화가 생겼을 때는 "still trying" 또는 "offline"과 같은 작은 상태 메시지가 나타난다. 이런 배려는 한 번 접속 시도 후에 보여주는 "failed to send email"과 같은 범용 메시지보다 바람직하다.
"탄력있는" UI는 아래와 같은 일반적인 패턴으로 정리할 수 있다.
- 실패하는 기능과 모듈은 그 기능을 막거나 숨겨라.
- 동적인 콘텐츠와 작동하지 않는 기능을 대체할 수 있는 대체 콘텐츠를 준비하라.
- UI 출력이나 상호작용을 제한하는 행동을 피하라.
- 서비스 실패를 발견하고 사용자의 재시도를 가능하게 하라.
- 대체 시스템을 준비하라.
어떻게 실패를 발견할 수 있나?
Mike Brittian : 소소한 실패가 발생된 경우, 기본은 사이트의 필수적인 기능을 제한하지 않게 함으로써 그 실패를 숨기는 것이다. 예를 들어 우리는 "Favorite" 서비스에 문제가 발생했다고 해서 제품 페이지가 멈추지는 않는다. 회사에서는 이 경우에 대해서 많은 이야기를 나눌 필요는 없을 것이다. 정말 문제가 발생한다면 문제를 가장 먼저 알고 해결을 해야할 것이다. 막연하기보단 구체적인 용어를 사용해야 한다. 그리고 시간 정황과 해결 가능한 측정된 시간을 제공해야 한다. 만약 서비스가 중단이 되었고 데이타 복구를 위해 시간이 제법 걸린다면 3시간 뒤에 다시 확인해 보라고 말 하는 것이 사용자들이 20분동안 브라우져를 새로고침 하면서 사이트에 대해 불신을 쌓는 것보다 나을 것이다. 당신은 이런 메시지들이 사용자들에게 전달되기를 바랄 것이다. 이런 상황을 대비해 우리 Etsy에서 꽤나 쓸만한 패턴을 가지고 있다. 우리는 네트웍 외부에 위치한 "status blog"를 운용하고 있다. 우리의 데이타 센터에 문제가 발생하더라도 이곳에는 반드시 접근할 수 있다. Etsy.com의 모든 서비스 경고와 오류메시지는 이 블로그에 링크로 제공된다. 그리고 서비스 경고가 자동으로 커뮤니터 포럼의 최상단이나 또는 멤버들이 사이트의 도움을 찾을 수 있는 곳에 등록된다.
Volocity 2012 keynote summary에서 "게임 데이와 함께하는 실패 시나리오"를 언급했다. 게임 데이가 무엇이고 어떻게 진행이 되는 것인가?
Mike Brittain : 게임 데이란 실 운용환경에서 실패 시나리오 훈련을 의미한다. 이 훈련은 특정한 문제 상황하에서 우리 시스템의 예정된 대응을 확인하기 위해 진행한다. 우리는 이 과정을 적극적으로 관찰하며 어떤 예상치 못한 상황을 표면화시킨다.
우리는 이 훈련을 실 운용환경에서 진행하는데 그 이유는 개발, 테스트, 그리고 스테이징 환경에서는 100% 운용환경과 일치하지 않기 때문이다. 대부분의 경우 아마도 실제의 상황과 흉내낸 트래픽, 다른 개수의 장비 그리고 크기가 다른 데이타를 가지고 있을 것이기 때문이다. 이 훈련의 단점으로는 실 방문자들의 사용에 영향을 줄 수 있다는 것이지만 팀에 대한 실제의 신뢰도를 확인하고 실제 장애에 대한 능력을 훈련할 수 있다는 장점이 있다.
문제를 해결하고 개선했던 기능의 설정 로직이 잘 연결이 되었는지 확인을 목적으로, 우리는 정기적으로 사이트 전체적인 설정 플래그를 테스트 한다. 또 우리는 플래그가 설정이 되지 않았을 때, 사용자 경험이 우아하게 실패하는지 확인하기를 바란다. 예를 든다면, 우리 사이트의 "Favorite" 서비스가 작동하지 않을 때, 데이타를 읽고 쓰는 것이 같이 멈추고, UI의 여러 부분에서 "Favorites" 툴을 숨겼으면 한다. 게임 데이는 이런 것들을 증명하는데 도움을 준다.
"Favorites"를 비활성화시켰을때 우아하게 실패하지 않고 페이지 전체에 문제가 발생한다면 놀랄 것이다. 또 설정 플래그가 비활성화되었을 때, 여전히 서비스에 데이타가 읽고 쓰여진다면 또한 더욱 더 놀랄 것이다. 일부 실 운용 환경외에서 테스트를 흉내낼 경우 관찰할 수 없는 경우도 있다.
TAG :
최신 콘텐츠