나는 종종 사용자 인터페이스(User Interface, UI)와 사용자 경험(User Experience, UX)의 차이점에 대해 질문을 받곤 한다. 비록 UI가 원래 처음부터 그런 의도로 만들어진 것은 아님에도 불구하고 보통은 인터페이스의 시각적인 측면만(혹은 그 중 좋은 점만) 부각시켜 설명하는 경우가 너무 많았다. 여러분이 쉽게 이해할 수 있게 기술과 연관이 없는 예를 하나 들어볼까한다. 최근에 내가 묵었던 더블린의 한 호텔 방에 대한 이야기이다. 이 호텔은 우리가 여느 대도시에서 볼 수 있는 모던한 스타일의 부티크 호텔이었다(Morcheeba의 음악이 흐르는 로비, 블랙과 화이트를 대비시킨 가구 등을 떠올려보라).

밤 늦게 방에 들어선 나는 당연히 전등을 켜야겠다는 생각을 했다. 거의 어둑어둑한 상태인 방 안, 내 앞에는 전등 패널이 하나 있었다.

여러분도 딱 보면 느낄 수 있듯 "인터페이스"는 괜찮아 보였다. 스테인리스 스틸로 마감한, 깔끔하고 우아한 느낌. 그러나 "경험" 쪽은 이야기가 달랐다. 우선 각각의 스위치가 어떤 역할을 하는지에 대한 안내가 없다. 1분여 동안 이리저리 만져본 후에야 왼쪽 다이얼이 메인 전등이고 오른쪽 다이얼이 욕실 전등이며 메인 스위치가 두 다이얼의 마스터 스위치인 듯 하다는 것을 알게 되었다. 단순해보이지만 다이얼을 누르면 전등을 켜거나 끄는 기능도 한다. 하지만 전등의 상태가 어떤지에 대한 어떤 피드백이나 설명도 없다. 더 헷갈렸던 부분은 다이얼을 누르고 나면 3초 뒤에나 전등이 켜진다는 것이었다. 그래서 실제로는 다음과 같은 상황이 벌어졌었다. 마스터 스위치를 누른다 - 아무런 반응이 없다. 다이얼을 돌린다 - 역시 아무 반응이 없다. 다이얼을 누른다 - 아무 일도 일어나지 않는다. 다이얼을 다시 누른다 (마지막으로 다이얼을 누르고 채 3초가 지나기도 전에 일어나는 일이다). 마스터 스위치를 다시 누른다 - 아무 반응도 없다. 하아 (한숨). 반복한다.

겨우 욕실 전등을 켠 다음에 나는 세면대 앞으로 갔다.

이 역시 매우 근사해보인다. 우아미가 살아있는 배관, 수도꼭지. 현대적인 스타일의 개방형 디자인이다. 이 글을 읽는 독자에게 질문을 하나 던지겠다. 이 세면대에서 물은 어떻게 뺄까? 세면대 주변을 살펴봤지만 마개나 줄 같은 것은 물론, 마개를 뽑는 방법에 대한 설명도 없었다. 게다가 마개가 세면대 표면보다 튀어나온 것도 아니라서 물을 빼기 위해 마개를 뽑거나 누를 수 있어야 할 것 같은 어떠한 유도장치도 없었다. 그래서 답은?

아, 그럼 그렇지. 플러그를 왼쪽으로 45도쯤 기울여서 중간에 있는 회전 고리를 돌릴 수 있게 만들어졌다는 걸 모를 사람이 누가 있겠어? (또 다시) 하아. 이렇게 세면대에서 굴욕을 당한 뒤 나는 샤워나 해야겠다고 생각했다. 그리고 이렇게 생긴 샤워기 헤드가 나를 반겼다.

이번에도 연필처럼 생긴 우아하고 독특한 디자인이다. 하지만, 물이 나오고 있을 때 방향을 조금 돌리려고 하자 말을 듣지 않는다. 이 늘씬한 디자인과 구조로 인해 샤워기 헤드의 방향을 어느 쪽으로도 바꿀 수 없었다. 만약 문으로 들어오는 방향을 향하고 있었다면 정말 짜증스러운 상황이 되었을 것이다. 또한 그 디자인 덕분에 아주 강력하고 곧은 물줄기가 나오는데, 굉장히 상쾌하다고 할 수 있는 반면 누구나 좋아할만큼 편한 느낌이라고는 할 수 없었다.

"멋지게 보이는 UI"와 "UX"의 차이? 여러분은 이제 그 차이를 훌륭한 디자인으로 꾸민 호텔이 형편 없는 사용자 경험를 주었던 이 예를 들어 설명할 수 있을 것이다. 나는 독특한 디자인을 좋아한다. 하지만 이를 위해 불편한 경험을 감수하는 것은 사양한다. UI 신기술에서도 똑같은 상황이 반복되지 않았으면 한다. 독특하게 보이는 인터페이스를 제공하는 새로운 UI 중 진짜 사용자 경험에 대한 이해 없이 제작된 것이 상당수이다. 아마도 내가 묵었던 호텔 방과 똑같이 나쁜 인상을 주게될 것이다.


이 글은 User Interface (UI) vs User Experience (UX)를 번역한 글입니다.

Posted by 행복한고니 트랙백 0 : 댓글 0


스티브 잡스가 플래시의 안정성을 문제 삼은 것은 유명합니다. 그런데 마치 그 말이 맞다는 것을 증명이라도 하듯이 Adobe Flash가 모바일 기기에서 시연하던 도중에 다운이 되버렸다(crashing)고 합니다.

제프 크로프트(Jeff Croft)씨가 자신의 블로그에 작성한 바에 따르면, 이 사건은 지난 주 시애틀에서 열렸던 플래시 캠프(Flash Camp)에서 일어났습니다. 키노트를 맡은 플래시 플랫폼 에반젤리스트인 라이언 스튜어트(Ryan Stewart)씨가  발표 도중 넥서스 원(Nexus One)에서 플래시 플레이어 10.1 버전을 시연하다가 문제가 발생했다고 합니다. 크로프트씨는 이렇게 작성했습니다.

사건은 이렇습니다. 라이언의 맥에서 Eco Zoo라는 사이트를 열었습니다. 겉으로 보기에는 아주 좋은 플래시 개발 사례였습니다. 풀 3D 렌더링과, 풍부한 인터랙션, 예쁘고 작은 글자가 있었거든요. 라이언이 이 사이트를 자신의 넥서스 원에서도 열었습니다. 사이트의 진행 바가 다 채워지고 3D 세상이 잠깐 나타나는가 싶더니 몇 초만에 브라우저가 다운되어버렸습니다. 라이언은 이렇게 말했습니다(대충 이런 뜻), “이런! 뭐, 베타니까요. 이 사이트는 좋은 예제군요. 다시 시도해보겠습니다” . 그리고 다시 시도했지만 결과는 마찬가지였습니다. 그가 참석자들에게 "이 사이트는 잘 안되네요. 혹시 잘 동작하는 플래시 사이트 아시는 분 있나요?" 라고 묻자, 누군가 "Hulu 요"라고 말했습니다. 그 소리에 라이언은 "Hulu는 동작하지 않습니다"라고 말하더니 데모를 중단했습니다.

Here’s what happened: On his Mac, Ryan pulled up a site called Eco Zoo. It is, seemingly, a pretty intense example of Flash development – full of 3D rendering, rich interactions, and cute little characters. Then, he pilled up the same thing on his Nexus One. The site’s progress bar filled in and the 3D world appeared for a few seconds before browser crashed. Ryan said (paraphrasing), “Whoops! Well, it’s beta, and this is an intense example – let’s try it again.” He tried it again and got the same result. So he said to the audience, “Well, this one isn’t going to work, but does anyone have a Flash site they’d like to see running?” Someone shouted out “Hulu.” "Ryan said, “Hulu doesn’t work,” and then wrapped up his demo, telling people if they wanted to try more sites they could find him later and he’d let them play with his Nexus One.

공정한 평가를 위해 말씀드리자면, 크로포트는  Hulu가 잘 동작하지 않는 것은 Adobe의 문제라기 보다는 Hulu의 문제일 것이라고 했습니다. 하지만, 사실은 아무도 모를 것입니다. 또한 그는 안드로이드에 탑재된 플래시가 베타 버전이며, 이는 죽거나 버그가 많을 수 있다고 공식적으로 인정한 셈이 됐습니다.

이 데모는 Adobe에게 부담으로 작용할 것입니다. 크로포트가 지금 할 일은 회사측에 플래시가 안정화 되기 전에는 데모를 중단하라고 요청하는 것이 아닐까 합니다.

from Was Apple right? Adobe Flash crashes twice during mobile demo

Posted by 행복한고니 트랙백 1 : 댓글 0

페이스북의 주요 가치 중 하나는 빠르게 움직인다는 것입니다. 지난 6년 동안, PHP의 빠른 개발 속도 덕분에 가능했던 일입니다. 프로그래밍 언어로서 PHP는 간결합니다. 배우기 쉽고, 작성하기도 쉽고, 읽기도 쉬우며 디버그 하기도 쉽습니다. 페이스북은 다른 언어보다 PHP 엔지니어들을 더 많이 늘려왔습니다. 페이스북을 빠르게 개선할 수 있는 사람들이죠.

오늘은 아주 능력 있는 사람들과 제가 지난 2년간 작업한 결과물을 공유하고자 합니다. 바로 HipHop for PHP 입니다. 우리는 HipHop을 사용해서 웹 서버의 평균 CPU 사용량을 50% 정도로 줄였습니다. CPU를 덜 사용한다는 것은 곧 서버를 덜 사용한다는 의미이고, 오버헤드가 더 적다는 뜻입니다. 이 프로젝트는 페이스북에 엄청난 영향을 끼쳤습니다. 우리는 HipHop이 웹 전반에 걸쳐 이득을 가져다 줄 것임을 직감하고, 새로운  오늘 저녁에 이 프로젝트를 오픈 소스로 공개하기로 결정했습니다. HipHop이 PHP를 사용한 대규모 복잡한 웹 사이트에  새로운 관심을 가져올 수 있도록 기대하면서 말이죠. 비록 HipHop이 우리에게는 믿을 수 없을 만큼의 결과를 보여주었지만, 아직 완성된 것은 아니므로 이를 사용하려면 베타 버전의 소프트웨어에 대한 불안감이 없어야 합니다.

기술적으로 HipHop for PHP는 컴파일러가 아닙니다. 오히려 소스 코드 변환기에 가깝습니다. HipHop은 PHP 소스 코드를 주어진 규칙에 따라 매우 최적화된 C++ 코드로 변환하고 g++를 사용해 이를 컴파일 합니다. HipHop은 소스 코드를 의미상 동등한 방법으로 실행하고, eval() 처럼 드물게 사용하는 기능들을 희생시켜 성능을 개선합니다. HipHop은 코드 변환기, 새롭게 작성된 PHP 런타임 시스템, 성능 최적화를 얻기 위해 재작성된 일반적인 PHP 함수 등으로 구성되어 있습니다.

Scaling PHP as a Scripting Language

PHP의 근간은 Perl, Python, Ruby 등과 같은 스크립트 언어로, 개발자의 생산성과 빠른 작업 속도에 이점을 가지고 있습니다. 이는 C++과 같은 전통적인 컴파일 언어나 Java와 갈은 인터프리터 언어와 비교되는 특징입니다. 반면, 스크립트 언어는 일반적으로 CPU와 메모리 사용에 있어 효율이 덜하다고 알려져 있습니다. 이 때문에, 페이스 북이 성장하려면 매월 4조의 PHP 기반  페이지 뷰를 극복해야 했습니다.

이러한 비효율을 극복하기 위해 언급되는 일반적인 방법 중 하나는 PHP 프로그램에서 더 복잡한 부분을 C++로 작성해 PHP 확장기능으로 만드는 것이 있습니다. 이는 PHP를 프론트 엔드 HTML과 프로그램 로직 C++ 중간의 접합 언어로 변환하겠다는 의미와 같습니다. 기술적인 관점에서 보면 이 방법은 잘 동작하겠지만, 전체 프로그램에 대해 작업할 수 있는 개발자 수를 급격하게 감소시킬 것입니다. PHP 확장기능을 작성하려면 C++을 먼저 배워야하고, 그 다음으로는 Zend API에 대해 이해해야 합니다. 우리의 개발팀은 상대적으로 작아서 — 개발자 한 명당 백만명 이상의 사용자가 있습니다 — 우리 코드 일부의 접근성을 떨어뜨리는 방법을 시도해볼 수는 없었습니다.

페이스북의 성장은 특히 힘든 도전이었는데, 거의 모든 페이지 뷰가 로그인 한 사용자에게 사용자화된 경험을 제공하기 때문입니다. 여러분이 자신의 홈페이지를 볼 때, 우리는 여러분의 모든 친구를 찾아서 (우리가 Multifeed라고 부르는 사용자화 서비스로부터) 가장 적절한 업데이트 내역을 뽑은 다음, 프라이버시 설정에 기반해 이를 걸러낸 후, 이렇게 걸러낸 이야기들을 댓글과 사진, 사람들이 페이스북을 좋아하게 만드는 모든 리치 데이터로 채웁니다. 그리고, 이 모든 동작은 1초 안에 처리됩니다. 우리는 뉴스 피드, 검색, 채팅과 그 외의 핵심 부분을 제공하는 커스텀 백엔드 서비스에 의존하면서도 HipHop을 사용해 최종 페이지를 PHP로 조합하고, 재빨리 반복할 수 있었습니다. 심지어 백엔드 서비스들은 C++, Erlang, Java, Python 등의 다양한 언어로 작성되었습니다.

2007년부터 우리는 이런 문제들을 해결할 수 있는 몇 종류의 방법에 대해 고민해왔고, 그 중 일부는 시도해보기도 했습니다. 공통적인 제안으로는 페이스북을 다른 언어로 바꾸는 것이 있었지만, 페이스북의 복잡도와 개발속도 덕분에 이 방법은 시간이 필요했습니다. 우리는 Zend Engine — PHP 내부 — 쪽을 재작성하고, 패치를 PHP 프로젝트에 보내기도 했지만, 궁극적으로는 필요한 만큼의 성능 향상을 얻지 못했습니다. HipHop의 장점은 우리 개발 속도와 거의 비슷하다는 것에 있습니다.

Hacking Up HipHop

저는 몇 년 전 Hackathon에 하룻밤 참가하면서(Prime Time Hack 참고), PHP를 C++로 변환해주는 프로그램을 작성하기 시작했습니다. 두 언어는 문법적으로 유사한 점이 많고, CPU 부하와 메모리 사용량 어느 측면에서 봐도 C++은 PHP보다 훨씬 나은 성능을 보여주었습니다. 심지어 PHP도 C로 작성되었을 정도입니다. 우리는 이미 작성된 전체 코드를 일일이 성공적으로 재작성한다는 것은 불가능하지만, 이런 변환을 프로그램 적으로 해결하는 시스템은 만들 수 있지 않을까라고 생각했습니다.

PHP 성능 개선을 위해 새로운 방법을 찾는 것은 새로운 개념이 아닙니다. 런타임에서 Zend Engine은 PHP 소스를 Zend 가상 머신에서 실행할 수 있는 opcode로 바꿉니다. APCeAccelerator 등의 오픈 소스 프로젝트는 바로 이 opcode를 캐시하며, 이미 PHP를 사용한 대형 웹 사이트에서 사용되고 있습니다. opcode 최적화와 캐싱을 통해 PHP를 더 빠르게 만드는 Zend Server와 같은 유료 제품도 있습니다. 이와 다르게, 우리는 PHP 소스를 C++로 바로 변환한 다음 이를 네이티브 머신 코드로 만드는 방법을 생각했습니다. PHP를 컴파일 하는 것도 새로운 아이디어는 아닙니다. 이미 공개된 오픈 소스 프로젝트들이 있습니다. Roadsendphc는 PHP를 C로 컴파일하며, Quercus는 PHP를 Java로, Phalanger는 PHP를 .Net 으로 변환해서 컴파일합니다.

물론, 이 작업이 하룻밤의 Hackathon으로 끝난 것은 아닙니다. 8개월이 지난 후에야 컴파일된 코드로 더 빠르게 실행하는 일이 실제로 가능한 것임을 시연할 수 있을 정도였습니다. 우리는 이 프로젝트에 박차를 가하기 위해 Iain Proctor과 Minghui Yang을 재빠르게 영입했습니다. 다시 10개월이 지나서 코딩을 마쳤으며, 6개월간 실제 서버에서 테스트를 진행했습니다. 그리고, 자랑스럽게도 HipHop은 배포 후 단 6개월만에 페이스북 웹 트래픽의 90% 이상을 담당하고 있습니다.

How HipHop Works

이 프로젝트의 주요 과제는 PHP와 C++의 차이를 줄이는 것입니다. PHP은 동적이고 약한 타입을 가진 스크립트 언어이고, C++은 강한 타입을 가진 컴파일 언어입니다. PHP에서 여러 동적인 기능들을 제공하긴 하지만, 대부분의 PHP는 상대적으로 직관적입니다. function foo($x) { include $x; } 보다는 if (...) {...} else {..} 를 보는 것과 같습니다. 우리가 성능 향상을 얻은 부분이 바로 여기입니다. 가능하다면 언제든 생성한 코드는 함수와 변수를 정적으로 바인딩합니다. 또한, 변수의 적합한 타입을 골라내는 타입 추론을 사용해서 메모리를 절약할 수 있었습니다.

변환은 크게 세 단계로 이루어집니다.

  1. 무엇을 선언하고 어디에 의존적인지에 대해 모은 정보를 기반으로 정적 분석을 합니다.
  2. 타입 추론을 통해 C++의 스칼라(scalar), 문자열(String), 배열(Array), 클래스(class), 객체(Object), 가변형(Variant) 중 가장 적합한 타입을 선택합니다.
  3. PHP 표현에서 직접적인 연관이 있는 부분을 C++ 표현으로 코드 변환합니다.

우리는 개발을 위해 고안된 실험적인 인터프리터인 HPHPi도 개발했습니다. HPHPi를 사용하면 PHP 소스 코드를 실행하기 위해 컴파일하지 않아도 됩니다. HPHPi 덕분에 HipHop의 버그를 찾아낼 수 있었고, 개발자들은 HipHop을 사용하기 위해 자신들의 PHP 개발 방식을 바꾸지 않아도 됐습니다.

전반적으로 HipHop은 PHP의 좋은 점을 취하면서도 C++의 성능을 얻을 수 있도록 해주었습니다. 우리는 300,000 줄 이상의 코드를 작성했고, 5,000개 이상의 단위 테스트를 실시했습니다. 이 모든 것들은 오늘 저녁 GitHub에서 오픈 소스 PHP 라이센스로 공개될 것입니다.

HipHop wiki : http://github.com/facebook/hiphop-php/wikis

From HipHop for PHP : Move Fast

Posted by 행복한고니 트랙백 4 : 댓글 1
구글이 최근 획득한 특허에 따르면, 구글 스트리트 뷰에 광고가 포함될 듯 합니다. 구글이 2008년 7월에 출원한 이 특허는 온라인 지도에서 사용할 수 있는 광고 시스템에 관한 것입니다. 이 특허에서 구글은 건물, 포스터, 광고판을 인식하고 이들 대신 최신의 광고를 보여줄 보여줄 계획을 세웠습니다. 또한, 문제가 되지 않는 범위 내에서 광고를 경매할 계획도 가지고 있습니다.

구글이 제시한 사례를 보면, 극장 포스터를 새로운 정보로 대체합니다. 이 방법을 통해, 해당 극장은 스트리트 뷰의 이미지가 오래됐다해도, 극장의 포스터를 항상 최신 상영중인 작품으로 보여줄 수 있습니다.


(자세한 내용은 아래 링크에서 확인할 수 있습니다.)

Posted by 행복한고니 트랙백 0 : 댓글 1

티스토리 툴바