우리는 캘린더를 위아래로 쓸어 넘기는 아이폰 앱을 개발했고 하루 중에 일로 바쁜 시간보다 여유로운 시간에 집중했다. 앱은 2011년부터 있었지만, 나는 한동안 앱을 제작한 배경과 우리 팀이 궁극적으로 터득한 교훈을 얘기하고 싶었다. 앱스토어에서 우리에게 있던 한계가 어떻게 가장 큰 성공과 실패로 이어졌는지에 관한 얘기다.

프리타임 앱이 출시된 배경과 그 과정에서 터득한 교훈을 얘기한다.

한계를 수용하다

‘프리타임’은 여가에 관한 앱이다. 대다수의 프로젝트들처럼 (“언제 한가하지?”라는 질문에 대답하듯) 단순하게 생각했지만, 프리타임을 기능이 더 추가된 꽤 복잡한 앱으로 세상에 출시했다. 대학 시절에 이 아이디어를 생각했다. 그때 나는 강의실을 바쁘게 왔다 갔다 하고 날마다 스케줄을 바꿔가며 친구들과 모일 시간을 찾으려고 애썼다. 2010년에 적잖은 기업들(Tungle.me, Doodle, When Is Good, Scheduly 등)이 우리와 같은 스케줄 문제를 해결하려고 했다. 모든 이들은 사람들의 여가와 그때 모이게 할 방법을 모색했다.

대다수의 회사에서는 클라우드 시스템에 있는 캘린더들을 모아 (서로 다른 시간대에 있는 두 사람 모두 언제 한가한지 알아내는) 서로의 시간을 맞춰주려고 복잡한 인프라를 구축하는 데 지속적으로 거액을 투자했다. 쉽게 들리지만 그리 쉬운 게 아니다. 다행스럽게도 우리는 그 사실을 몰랐다.

본인의 한계를 수용하라. 내가 터득한 첫 번째 교훈이다. 그 당시에는 다음과 같은 한계를 중요하게 보았다.

우리 셋은 모두 땡전 한 푼 없고, 서버를 구축하는 방법도 몰랐기 때문에 모든 기능들을 앱 안에서 구현했다(서로의 시간을 맞춰주는 기능마저). 그러고 나서 앱을 출시했다. 이 앱은 무한히 확장 가능하고 오늘날까지 애플의 개발자 연회비를 제외한 고정 비용이 발생하지 않는다. 과도하게 연결된 이 시대에는 이런 요구를 할 앱 개발자는 많지 않다.

캘린더를 제작하는 작업이 얼마나 복잡한지 몰랐기에 이 앱을 그저 식은 죽 먹기로 만들거라고 생각했다. 작업은 쉽지 않았지만, 시간의 복잡성과 그 내용을 상세히 알았더라면 분명 시작조차 하지 않았을 것이다.

자, 당신이 한계나 제약을 느끼더라도 그렇게 느끼지 마라. 그런 한계들이 큰 차이를 만들고 마침내 가장 창조적인 기회로 이끌어준다.

37시그널^37signals은 한계를 다른 관점으로 생각하길 좋아한다.

한계는 가면에 감춰진 이로움이다. 개발 자금을 위한 벤처 캐피털, 오랜 시간을 들여야 하는 출시 주기, 인재를 빨리 구하는 채용에 관한 생각을 하지 마라. 그 대신에 현재 당신에게 있는 모든 것을 이용해 진행하라.

출시하다

앱 개발을 시작할 때부터 8개월이 지나 앱을 출시했다. 우리 셋은 모두 밤과 주말마다 작업해서 앱을 완성했으며, 앱스토어에 올리고 나서 한숨을 돌렸다.

폭풍 전의 고요함

길고 고통스러운 7일 동안에 앱 리뷰가 진행되었다. 그전에 단순한 앱 몇 개를 제출한 적이 있어서 리뷰 절차에 관해 알고 있었다. 그러나 이번에는 기다림이 심히 길었다. 7일째(우연히 졸업식을 하는 날) 아이튠즈 커넥트에서 프리타임 리뷰가 끝나서 판매를 승인했다. 그리고 현재 앱스토어에 있다고 알려주었다. 주위 사람들이 축하를 많이 해주었다. 친구들에게 앱을 다운로드 해달라고 부탁하고, 페이스북과 트위터에서 앱에 관해 포스팅 했다. 그 시기에 마케팅 계획은 전혀 없었다. 몇 사람에게 얘기했지만 관심을 많이 불러일으키지 못했다.

대학을 졸업하고 앱을 출시하는 데 꼬박 일주일이 지났다.

목요일에 졸업했고 금요일까지 300명이 이 앱을 다운로드했다. 이 결과에 너무 놀라서 출시 첫날밤에 이것은 우연의 일치였고 앞으로 이 앱을 찾는 사람이 없을 거라고 확신하며 잠들었다. 그 다음 날 또다시 300명이 다운로드했다. 이 결과는 계속되었고, 앱스토어에서 판매를 개시한 일주일 후 애플에서 이 앱을 ‘베스트 신규 앱’으로 추천했다.

앱스토어에서 추천 앱이 되는 것은 타오르는 불에 기름을 붓는 격이다. 다운로드, (칭찬과 불만이 적힌) 이메일, 언론의 요청 등이 폭발했다. (두려움에) 짐을 챙기고, ‘현실’을 생각하며, 앱에서 버그를 많이 찾은 카타르 사람들에게 이메일을 받는 것은 신나면서도 섬뜩한 경험이었다.

그 다음 2~3주는 대혼란이었다. 업데이트한 새 버전을 배포하고, 언론 문의에 응대하며, 당시 상황을 파악하려고 했다.

결과

마침내 평온을 찾았다. 사용자의 문제를 처리하려고 업데이트 버전을 꾸준히 배포했고 수년이 흘러 여기까지 왔다. 개발자들은 숫자를 공유할 때를 좋아하므로 프리타임의 흥미로운 숫자를 일부 나열해보겠다.

몇 가지는 잘했지만, 잘하지 못한 점을 얘기한 글이다.

잘한 일보다 잘하지 못한 일과 그 과정에서 무엇을 배웠는지 얘기하겠다.

앱을 개발하고 앱스토어에서 출시했다. 그리고 전 세계 사용자들에게 받은 맹공격(과 항의)을 다루는 과정에서, 우리는 앱의 단점과 현실에서 사람들이 앱과 캘린더를 어떻게 생각하는지 알게 되었다.
 

1. 앱을 눈에 띄게 하는 최적의 방법은 관점을 바꿔 사람들에게 숨은 뜻을 알리는 것이다.

앱을 프로토타입으로 제작할 무렵, 특정한 날에 (당신의) 여유 시간을 알고 싶어 하는 친구나 동료에게 이메일을 보내는 재빠른 방법을 이용해서 프로토타입을 제작했다. 단지 그게 전부였다. 이 동작을 할 수 있도록 (등록된) 일정 사이 시간에 버튼을 두었다. 사용자는 이 버튼을 탭해서 공유하게 된다. 사실은 캘린더 UI의 중요도를 떨어뜨리고 반대로는 (여유 시간에) 그 중요도를 높이게 된다.

등록된 일정 사이 시간은 버튼이 되며, 캘린더 UI의 중요도를 떨어뜨리고 여유 시간에 중요도를 높이게 된다.

전래에 의해 예상되는 캘린더 UI를 뒤집으니 눈에 더 띄었고, 그 앱을 보여줄 때마다 같은 대답을 들었다. 사람들은 “굉장히 멋지고 적절한 발상이네”라고 말했다. 솔직히 말해서, 그것은 우연히 얻은 발상이었다. 하지만 이는 우리의 관점을 바꾸어 이미 알고 있던 사실을 새롭고 흥미로운 방식으로 보게 했다. 결국 사람들이 당연시하는 상식에 비교적 단순한 변화를 주어서 관심을 많이 모았다.

더 넥스트 웹^{The Next Web}의 드류 올라노프^{Drew Olanoff}는 다음과 같이 말했다.

프리타임은 당신이 캘린더를 보는 방식을 완전하게 바꿀 것이다.

 
앱에 새롭고 기발한 아이디어는 필요하지 않다. 앱 때문에 난데없이 사업을 일으킬 필요는 없다. 훌륭한 앱을 제작하는 방법은 단순한 것에 중점을 두고, 심지어 사람들이 당연시하는 것에 초점을 맞추고 나서 그보다 더 좋게 만드는 것이다. 교통 앱인 우버^Uber는 여러 가지 이유로 참신하고 독특하다. 그러나 결국 가장 중요한 점은 이 앱은 택시를 잡기 위한 더 좋은 방법이 될 뿐이다. 개발자들이 했던 일은 사람들의 관점을 바꾸고 어떤 상황을 개선한 것이다.
 

2. 반복 과정 준비하기

처음에 우리는 디자이너 휴스턴이 작업한 횟수보다 훨씬 더 많이 앱을 디자인하고 또 디자인했다. 당신의 앱을 개발할 때, 이 작업을 진행과정에 넣도록 하라. 성공하는 앱의 핵심 요인은 반복하며 개선하는 작업이기 때문이다.

첫 번째 수정된 화면은 왼쪽에, 출시된 화면은 오른쪽에 있다. 둘 다 기능은 거의 같지만, 디자인에서 강조된 부분과 내비게이션이 확 달라졌다.

한 군데에서 시작돼서 전혀 다른 어딘가에서 완성된다는 사실에 염려하지 마라. 반복되는 과정마다 새롭게 배운 점과 피드백을 구체화하려고 애썼다. 초기에 베타 테스터에게 앱을 보여주고 콘셉트를 대략적으로 증명했기에 우리는 외관(디자인)과 콘셉트에 있는 일부 중요한 결점을 발견할 수 있었다.

첫 번째 생각, 공유

초기 수정에서 공유는 별도의 활동이었다. 탭^tab 방식으로 시작했기 때문에 공유 역시 탭으로 하는 게 적절했다. 일찍 진행된 베타 테스트를 통해 우리는 특정한 날에 있을 이벤트 맥락 없이 사용자가 그날 어떤 행동도 하게 해선 안 된다는 점을 빨리 깨달았다. 우리가 시작했던 뷰는 가능한 것만 보여주었다. 하지만 그 주위에 이벤트가 없는 경우 테스터들은 혼란스러워했고 그들의 가능한 시간대와 캘린더를 연관 짓지 못했다.

주위에 이벤트가 없는 경우, 테스터들은 혼란스러워했고 가능한 시간대와 캘린더를 연관 짓지 못했다.

새로운 인라인 접근(즉시 처리하는 방식)

두 번째 수정에서는 여유 시간과 바쁜 시간의 색상 대비를 높이고자 새로운 색 구성표를 채택했을 뿐만 아니라 일반 캘린더 바로 위에 여유 시간을 통합시켰다.

두 번째 수정에서는 여유 시간과 바쁜 시간의 색상 대비를 높였다.

이로써 사용 문맥을 개선했고, 탭을 바꾸고 사용 문맥을 변경하지 않으면서 사용자는 여유 시간에 무언가 행동을 취할 수 있다는 정보를 받았다. 이것 또한 사용자들이 새로운 방식으로 캘린더를 볼 수 있게 했고, 여유 시간에 행동을 취하고 싶지 않을지라도 그들이 바라는 의미를 주었다.

완성품

최종 수정에서 우리는 가능한 많은 이벤트를 보여주고자 캘린더 공간을 늘렸다. 또한 어느 화면에서든지 사용자가 껐다 켰다 하는 모달 기능을 사용해 공유하도록 했다. 캘린더 UI에 더 초점을 맞춤으로써 애플의 캘린더 앱에 익숙한 사용자에게 편한 방식으로 선택 가능한 여유 시간에 대한 개념을 갖게 할 수 있었다.

최종 수정에서는 가능한 많은 이벤트를 보여주기 위해서 캘린더 공간을 늘였다.

하지만 반복되는 수정 과정은 결코 끝나지 않는다. 앱을 완성했기에 아이콘을 업데이트해야 한다.

앱을 완성한 후에 아이콘을 업데이트 해야 한다.

3. 반복되는 수정 과정은 ‘기능을 추가한다’는 의미가 아니다.

반복되는 과정에서 실패했다. 테스터들에게 덜 흥미로웠던 부분과 기능을 버려야 했는데 그러지 못했다. 최소한의 실행 가능한 앱을 인정하지 않았다. “내가 언제 한가하지?”라는 핵심적인 가치 제안을 정련하면서 시간을 보냈어야 했다. 그런데 궁극적으로 우리는 반복 과정에서 앱을 진화하는 데 관심을 두었다. 이로써 기능들이 부득이하게 부풀려졌으며 앱의 가치가 저하되었다. 앱의 뉘앙스와 그 기능을 설명하는 장황한 사용자 워크스루^walkthrough를 만들어야 했다. 그 워크스루는 6개의 화면으로 이루어졌고, 출시했을 때 깜박하고 “건너뛰기^skip” 버튼을 넣지 않았다(큰 실수였다).

6개의 워크스루 화면에서 “건너뛰기” 버튼을 넣지 않은 게 큰 실수였다.

작년에 새로운 사용자의 42%만이 앱을 처음 실행했을 때 첫 워크스루를 다 보았다. 이 사용자들은 모두 앱을 구매하기로 정했고 다운로드와 설치를 하려고 기다렸다. 고로 앱 구매로의 전환 개수에서 이 워크스루는 대실패였다.

무언가에 열중해 있을 때를 유지하는 건 극히 어렵지만, 기능성 결여(단순함이라고 부르는 게 더 바람직하겠다)가 기능성 생명처럼 강한 인상을 준다는 사실을 깨닫는 것이 중요한 것 같다. 초기 콘셉트는 사용자가 하루 중 여유 시간에 집중하도록 해주는 것이었지만 앱을 완성했을 때 다음과 같은 기능들이 들어갔다.

4. 가치 있는 문제를 해결하라. 그러나 당신의 문제를 모든 사람의 문제라고 생각하지 마라.

지금 만드는 앱에 집중하는 게 중요하다. 당신이 사용하고 싶은 앱을 개발할 수 없다면 다른 이들이 사용하고 싶은 앱도 개발하지 못할 것이다. 그러니 자신의 문제를 해결하고, 가려운 곳을 긁어줄 아니면 자신의 요구를 만족시켜줄 앱을 개발하라. 그러면 가치 있는 앱을 창조하는 데 필요한 일을 하려고 열중하게 된다. 인기를 많이 얻지 못하더라도 결국에 쓸 수 있는 앱을 갖게 될 것이다.

하지만 당신이 푸는 문제를 다른 이들의 문제라고 생각하지 마라. 우리가 앱 개발을 시작했을 때 2개의 캘린더 문제를 해결하고 서로의 여가를 보여주는 앱의 능력이 오프라인 용도로 판을 뒤집는 기능이 되리라고 생각했다. 그 당시 사용자들은 늘 여가를 널리 알리게 하고, 고가의 서버를 요구하며, 재미없는 경험을 주는 Tungles와 Doodles의 세계에서 커다란 플레이어(대기업)들의 자리를 우리가 차지하길 원했다. 데이터베이스 구조를 설계하고 서로의 여가를 공유하도록 앱을 수정하며 보냈던 수많은 시간을 합산하는 일 조차 시작할 수 없다. 8개월의 개발 기간 중 아마 한 달은 걸렸다. 출시 이후, 200,000명 이상의 사용자들 중 179명이 사용하고 있다. 다수가 한 번만 사용했다. 수치로 환산하면 사용자의 0.000895%다.

비교하자면, 179명이 서로의 여가를 공유하는 기능을 사용하는 반면 2900명은 다른 방식표현 혹은 유형으로 그들의 여가를 공유하고 있다. 15,000명이 그들의 여가를 지속적으로 필터링 하는 데 반해 대다수는 단 한 번만 한다. 150,000명 이상 캘린더 위에 배치된 여가를 보는 데 만족하는 듯하다.

이해하자니 어렵고 피하자니 더 어렵다. 자, 당신이라면 어떻게 하겠는가? 본능을 믿어라. 하지만 흥분은 가라앉혀라. 좋아하는 것을 만들라. 하지만 본인의 방식으로 다른 이들이 그것을 좋아하리라는 기대는 접어라. 다른 대안이 없다면 그만두어라.
 

5. 당신만의 세계가 아닌 전 세계용으로 구축하라

영어가 아닌 다른 언어를 지원하기 위해서 앱을 글로벌화하지 않았다. 이것이 두 번째로 큰 실수다. 2년 전, 전 세계에 배포하지 않는 앱을 출시해도 그럭저럭 괜찮았다. 요즘 앱스토어에서 팔 앱을 개발한다면 처음부터 전 세계용으로 개발하라.

위 지도에서 2013년 전 세계적으로 프리타임 사용량을 보여준다.

오늘날까지도 프리타임의 총수입 금액의 48%와 사용자의 35%만 미국이다. 만일 다른 국가의 언어를 지원했다면 우리 재무 성과는 더 높았을 것이다.

생소하고 복잡한 개념인 시간을 조심하라.

프리타임을 항상 어느 플랫폼에서도 사용 가능한 앱이라고 생각했고, 당초에 서로의 여가를 공유하는 해답을 가장 중요한 기능으로 보았다(기억나나?). 그래서, 그 사용 사례에 맞추려고 우리 전략을 채택했다. 마침내 안드로이드와 iOS로 컴파일하는 언어인 C++에서 기초가 되는 캘린더-파싱 엔진을 개발했다. 네이선이 Object-C보다 C++을 더 잘 알고 있어서 손해가 되지 않았고, 그 작업은 그에게 딱 맞았다.

NSDate나 NSCalendar 같은 시스템 라이브러리 없이 우리만의 크로스 플랫폼 캘린더 데이터베이스를 구축했기에 개발 과정에서 쓸데없는 시간을 낭비하지 않았다. 절대 이렇게 하지 마라. 시간 고유의 복잡성으로 이러한 노력은 획일적인 문제가 되어버린다. 마치 단지 한 지역을 좋아하지 않아서 그 지역의 도시 전체를 벽돌을 다시 차곡차곡 쌓아 올리는 것과 같다. 다른 누군가의 작업을 활용할 수 있다면 시간 낭비를 하지 않을 것이다.

(이미지 출처: Smythe Richbourg)

캘린더나 시간을 기반으로 하는 계산과 관련된 앱을 개발한다면 한두 개의 시나리오를 생각해보아라.

30 더하기 20은 기초 셈이라 쉽게 계산한다. 이번 달 30일 더하기 20일^days를 계산하는 것은 쉽지 않다. 좋아. 그 계산이 비교적 쉽고 어쩌면 정답은 다음 달 19일이나 20일이라고 생각할지 모른다. 다만 이집트에 거주하는 사람들과 다음 달이 총 5일만 있는 Pi Kogi Enavot (“작은 달”)이란 사실이 생각나기 전까지 말이다.

우리가 알아낸 또 다른 재미있는 사실은 어떤 나라는 어떤 날에 자정^midnight이 없다. 우리가 저장한 24시간 이벤트의 대다수는 어떤 날의 자정부터 시작해서 11:59:59에 끝난다. 이벤트를 저장하는 가장 논리적이면서 간단한 방법으로 생각했다. 하지만 미국에서 하듯이 1:00 am에서 2:00 am이 아니라 12:00 am에서 1:00 am으로 건너뛰는 브라질의 서머타임을 잊고 있었다! 그래서 자정이 없다. 그리고 그 결과, 해마다 적어도 하루는 브라질에서 사용자에게 앱을 출시하는 데 문제가 발생했다.

맞다. 그리고 2012년 윤일(2월 29일)은 내가 좋아하는 날이었다. 적극적인 앱 사용자들 거의 전부가 우리에게 이메일을 보내거나 트윗을 해서 앱이 하루 늦어졌다고 알려줬다(마치 한 달 동안 그랬던 것처럼).

불교식 달력에서 올해는 2557년이다.

또한 다양한 전 세계 캘린더에서 문제가 많이 발생했다. 그저 번역에서가 아닌 근본적으로 현재 연, 월, 일에서 차이가 났다. 사우디아라비아와 카타르에서 앱을 사용하는 사용자들은 놀랄 만큼 많았다. 그리고 프리타임의 한 가지 문제는 그 나라의 공식 캘린더(이슬람 회교식 캘린더)를 잘 지원하지 못한다는 점이다. 그 캘린더에서 올해는 1435년이고 양력이 아닌 음력 캘린더이기 때문에 그 달의 일수는 모두 제각각 다르다. 내가 분명하게 말할 수 있는 건(아직 내가 시도해보지 않았지만), (가장 흔히 사용하는) 그레고리력을 사용하는 사람과 다른 캘린더를 사용하는 사람이 서로의 여가를 공유하게 되면 그 실패는 굉장히 볼 만할 것이다. 감사하게도 그 기능을 사용하는 사람은 없는 듯하다!

언어와 날짜는 문제의 일부일 뿐, 그 나머지는 문화다

세계용으로 개발한다는 것은 그저 앱을 글로벌화한다는 것이 아니다. 전 세계적으로 인구와 문화에 대한 다양한 사용 사례도 고려하라. 프리타임을 출시했을 때 주중(월요일부터 금요일까지)과 주말(토요일과 일요일)이란 개념으로 앱을 개발했다. 이와 더불어 대다수의 사용자들이 월요일부터 금요일까지 일하고, 주중보다 주말에 깨어 있는 시간이 다양할 거라고 추측했다. 지나고 나서 보니 그 추측은 지나치게 단순화시킨 오류였다. 하지만 그때는 전 세계를 생각하지 않았다. 우리 세계만 생각했을 뿐이었고 그 추측은 우리 세계에서 돌아가는 방식이었다.

처음에 월요일부터 금요일까지 근무 요일을 수작업으로 앱의 프로그램을 짰다.

왼쪽 화면은 앱을 출시했을 때의 버전이고 오른쪽 화면은 특정한 날짜에 변화를 줄 수 있도록 한 단순화시킨 UI다.

무심코 우리 세계용으로 개발하면서 인구의 또 다른 계층인 야간 근무를 하는 사람들을 소외시켰다. 사용자에게 일어나는 시간과 잠자는 시간을 입력하게 했기 때문에(이로써 여유 시간을 추론할 수 있다), 12:00 am부터 12:00am까지만 연장된 시간에서 고르는 제어 기능을 만들었다. 야간 교대를 서는 사람들을 생각하지 못했다. 그들은 그들의 ‘낮’과 작업 시간을 12:00pm과 12:00pm 사이 어딘가에 설정해야 한다.

야간 교대를 서는 사람들을 위한 해결책으로 슬라이더를 더 길게 늘였다. 안타깝게도 슬라이더의 증가된 범위로 인해 하루 중의 시간을 선택하는 게 더 어려워졌다.

이는 우리가 캘린더, 시간을 기반으로 한 계산 및 전 세계의 다양한 사용자들을 생각해야 했던, 우리 눈을 뜨게 한 극한 사례들 중 일부일 뿐이다. 애플은 개발자들이 이러한 사용 사례들을 즉시, 운영체제에서 직접 제공하도록 도움을 많이 주고 있다. 단, 당신이 허용하는 한 말이다.

당신은 세계 말고 전 세계를 위해 개발하고 다시 만드느라 시간을 허비하지 마라.
 

6. 미세한 부분에 시간을 투자하라, 사람들은 그 부분을 잘 본다.

우리가 잘한 부분이다. 앱 전체에 걸쳐 애니메이션 로딩과 그 외의 미세한 애니메이션들(가령 사용자 환경, 검색 필터 등 업데이트 용도)을 개선하고 완성하는 데 시간을 많이 소모했다. 다듬은 수준은 시대에 앞섰고 사용자 경험을 돋보이게 했다.

앱 전체에 걸쳐 애니메이션의 완성도는 시대에 앞섰고 사용자 경험을 돋보이게 했다.

요즈음 애니메이션을 넣은 앱은 흔하다. iOS7에서 소개한 새로운 UI 패러다임으로 인해 더 많이 요구되는 상황이다. 아직도 잘 만들어진 애니메이션은 앱들 사이에서 당신의 앱을 차별화시켜 주는 기가 막힌 방법이다. 기억에 남을 경험을 만드는 데 사용자를 놀라게 하고 기쁘게 할 미세한 요소와 기능 사이에 균형을 찾는 과정은 중요하다. 내가 사람들과 프리타임에 대해 얘기를 나눌 때 그들 중 대다수는 회전하는 구름과 시계 바늘은 기억하면서도 그 외의 다른 것은 기억하지 못했다. 이 앱은 캘린더와 관련 있다는 것을 막연히 떠올렸지만 이 애니메이션을 늘 기억하고 있다. 기억에 남을 경험의 유형에 대해 비판적으로 생각하면 멋진 경험이 나올 것이다.
 

7. 계속 밀어붙여라, 가장 좋은 아이디어는 사용할 가치가 있다.

우리가 저지른 최악의 실수였다. 정말 좋은 아이디어들은 계속 남겨둘 가치가 있으며 하나라도 너무 빨리 포기한다면 사용자와 아이디어 모두에게 몹쓸 짓을 한 것이다. 졸업하고 나서 우리에게는 모두 직업을 갖고 초기 경력을 쌓는 것이 우선적인 일이었다. 하지만 수년간 지속적으로 개선하고 업데이트를 하지 못한 것은 나의 큰 후회다.

2013년이 지나면서 프리타임 사용량이 하락하는 데이터를 보여주는 그래프. 새로운 사용자는 빨간색으로 강조했다.

2011년 이후 업데이트를 6번만 했기에 애플리케이션 버그, OS 업데이트, 앱을 유지하는 역량에 관한 신뢰도 상실로 사용량은 급격히 하락했다.

지난주 우리는 다음의 이메일을 받았다.

요약

많은 일을 제대로 했고 잘못하기도 했다. 하지만 우리와 사용자를 매우 실망시킨 것은 앱을 출시한 초기 몇 개월 이후 개선한 적이 없다는 사실이다. 안드로이드 버전, 아이패드 버전, 웹 버전, 맥 버전으로 개발할 수 있었다. 사용자에게 더 적절한 가격 모델을 실험할 수 있었지만, 그렇게 하지 않았다. 여러 가지 이유로 삶이 끼어들면서 우리는 매우 빨리 포기했다. 성공 가능한 비즈니스로 방향을 돌릴 수 있었지만, 우리는 다른 일을 하기로 선택했다.

다행스럽게도 이 앱을 끝내지 않았고 기나긴 활동 중단 기간을 마치고 앞으로 몇 달 안에 2버전을 출시할 계획이다. 꽤 많이 배웠고 꽤 많이 변했다. 이제 캘린더 뷰는 가장 중요한 위치에 자리 잡았고, 공유가 아닌 프리타임(여유 시간)을 찾는 데 중점을 두고 있다. 그리고 기능의 개수는 (유감스럽게도) 대폭 줄어들었다.

프리타임 2의 베타버전 스크린샷.

훌륭한 아이디어나 아직 꿈틀대는 당신만의 아이디어를 계획한다면 다음 목록을 유념하라.

벤 존슨 Ben Johnson
 
 
앱스토어 초창기부터 벤은 앱을 제작하고 모바일을 생각했다. 2011년에 획기적인 캘린더 앱인 프리타임(Free Time)을 구축했다. 벤은 자신의 고향인 미시시피 잭슨의 인구보다 많은 사용자들이 다운로드 하는 앱을 만드는 삶의 꿈을 이루었다. 그래서 또다시 그는 소프트웨어로 세상을 변화하려는 레이즈랩(Raizlabs)에 합류했다.

레이즈랩의 비즈니스 개발 디렉터로서 다수의 프로젝트에 참여했다. 혁신적인 모바일 기술을 이용해서 고객의 비즈니스를 확장하도록 돕고 있다. 또한 그는 보스턴 프리미어 모바일 모임인 드링크 온 탭(Drinks on Tap)의 공동 개설자이며, 다양한 모바일 콘퍼런스에서 모바일 소프트웨어의 애니메이션의 장점에 대해 강연하고 있다.

더 나은 소프트웨어에 관한 생각에 사로잡혀있지 않을 때, 자전거를 타거나 얼티미트 프리스비(Ultimate Frisbee) 경기를 한다.

루크 로블르스키Luke Wroblewski

모바일 우선주의

모바일 우선주의 대한
명쾌한 조언과 사례의 결정판!

책 미리보기책 상세설명

2012년 6월 구글에서 사용자 친화적인 반응형 웹사이트에 대한 선호를 발표했을 때 나는 반응형 디자인과 검색엔진 최적화를 동일시하는 글들이 순식간에 몰려 포스팅되는 상황을 목격했다. 그들의 말대로 반응형 웹사이트가 검색엔진 최적화에 친화적일 수 있지만, 개중에는 그렇지 않은 웹사이트도 있어 안타까운 심정이 들었다.

올해 초 서치 엔진 랜드^{Search Engine Land}에 기고한 글에서 나는 반응형 웹사이트가 검색 결과에서 문제를 일으키는 흔한 오류에 대해 상세히 다루었다. 그렇기에 스매싱 매거진에서 반응형 웹사이트에 관한 SEO 평가를 좀 더 면밀히 할 수 있어 좋다.

사람마다 SEO에 관한 정의가 다르다는 것을 다들 알고 있다. 그래도 내가 무슨 일을 하는지 이해하지 못하는 분들을 위해 SEO의 중요성을 이렇게 강조하겠다. SEO와 관련한 문제를 바로잡으면 사용자 경험이 전반적으로 향상된다고. 오늘날 대다수의 신뢰받는 SEO 전문가처럼 나는 단기간의 순위 혜택을 위해 검색엔진 알고리즘을 조작하는 걸 좋게 보지 않는다.

오늘 내가 평가하려는 웹사이트는 디즈니 주니어의 미국 버전^[1]이다. 내가 이 웹사이트를 선택한 데는 3가지 이유가 있다. 첫째, 내 고객이나 파트너가 이 사이트를 운영하지 않는다. 둘째, 다수의 반응형 웹사이트에 존재하는 SEO 문제가 여기에도 많이 보인다. 마지막으로 나의 4살된 두 아이가 이 브랜드를 정말 좋아하고, 그 웹사이트를 보려고 내 스마트폰이나 가족용 아이패드를 사용한다. 내 아이들과 그들처럼 검색하는 아이들을 위해 디즈니가 이 무료 조언을 활용해 웹사이트를 더 업그레이드하길 바란다.

물론 디즈니 주니어는 내 고객이나 파트너가 아니므로 내가 모르는 비즈니스 요구사항에 관한 정보가 내용 중에 있을 수 있다. 이 경우 나의 조언이 디즈니 주니어에 도움이 못되겠지만, 적어도 반응형 웹사이트에 관한 한 가장 좋은 SEO 사례로서 가치가 있을 것이다.

아름답지만 때로 좌절감을 주는 디즈니 웹사이트와 관련해 이번 평가에서는 웹사이트를 반응형으로 제작해도 모바일 SEO가 끝난 게 아님을 보여주고, 웹사이트가 검색엔진을 통해 좀 더 유용하게 검색될 수 있도록 디즈니에 일종의 틀을 제공하고자 한다.
 

검색엔진에 색인된 웹사이트인가?

구글에서 디즈니 주니어 페이지 대다수를 색인^[2]하고 있으므로 디즈니 주니어는 색인에 관한 문제는 없는 듯하다. 직접 구글 검색 사이트에서 site:domain.com을 입력해 검색 결과를 보거나 구글 웹마스터 도구를 사용할 수 있다면 거기서 확인해보라.

구글은 디즈니 주니어 웹사이트에서 약 1,630페이지 정도 색인을 생성했다. 그러나 페이지 내용 요약에서 콘텐츠 패리티^{content parity[3]} 문제를 보여준다.

검색엔진에 색인되지 않은 웹사이트는 사람들이 그 웹사이트를 검색할 때 당연히 검색결과에 나타나지 않는다. 이는 동적 게재^[4]나 모바일 전용 URL을 사용하는 웹사이트뿐만 아니라 반응형 웹사이트에서도 마찬가지다. 하지만 이 문제는 모바일 URL 문제로 좀 더 기울어지는 경향이 있다. 그 이유는 외부에서 들어오는 링크^{link equity [5]}로 인해 모바일 페이지가 원본^canonical 페이지와 검색 순위에서 경쟁하지 않도록 robots.txt 파일에서 의도적으로 모바일 웹사이트의  링크를 추적하지 않게 nofollow 하는 흔한 관행 때문이다. 그런데 이 관행은 잘못된 것이다. 왜냐하면 양방향 설정^{bidirectional annotation [6]}(이나 스위치보드 태그^{switchboard tags [7]})에 링크를 이용할 수 있고 모바일 URL을 검색 결과에 가져올 수 있기 때문이다. 하지만 반응형 웹사이트는 데스크톱과 모바일 모두에 쓰이므로 이에 관한 한 이도 저도 아니게 된다.

디즈니 주니어는 색인되었지만 Idis와 같은 일부 반응형 웹사이트는 그만큼 운이 좋지 않다. Idis 웹사이트는 반응형이면서 혁신적이어도 구글에 색인된 것은 하나뿐이다. 이 웹사이트는 동적이고 _escaped_fragment_를 사용하지 않았기 때문에 사용자가 웹사이트의 다른 요소(예: 내부 링크)를 클릭할 때 색인된 URL은 변하지 않는다. 그 결과 검색엔진은 색인들이 포함된 딥 링크^{deep links [8]}를 받지 못하게 된다. 만일 누군가 색인되지 않은 페이지에 있는 텍스트를 검색할 경우 그 사람은 인터랙티브하고 상까지 받은 이 웹사이트를 검색 결과에서 찾을 수 없다.

물론 정적인 URL이 없는 웹사이트에서 이런 일이 벌어진다. 하지만 개발자가 웹사이트를 반응형으로 할 것인지 동적 게재를 사용할 것인지 또는 모바일 전용 URL을 사용할 것인지를 정한다고 해서 모바일 SEO가 완료되는 건 아니다.
 

크롤링된 웹사이트인가?

반응형이든 아니든 웹사이트가 색인되기 위해선 구글에서 반드시 그 웹사이트를 크롤링해야 한다. 크롤링이란 검색용 로봇(크롤러)이 특정 콘텐츠로 이어진 링크를 따라가 새 URL을 저장하는 작업을 말한다.

이를 확인하고 싶으면 지누^Xenu나 스크리밍 프로그^{Screaming Frog}와 같은 웹사이트 크롤러를 사용해보라. 나는 모바일 SEO 평가용으로 롭 해몬드^{Rob Hammond}의 SEO 크롤러를 좋아하는데 스마트폰 구글봇^Googlebot을 선호 크롤러로 설정해주기 때문이다. 물론 크롤링하는 URL 개수가 한정적이지만, 크롤링 이슈에 대해 좋은 아이디어를 얻을 만큼은 된다. 만약 당신에게 웹사이트가 있다면 구글과 빙^Bing에서 그 웹사이트를 반드시 검증해봐야 한다. 그리고 이 2개의 검색엔진에는 개발자용 도구가 있다. 이 도구에서 개발자가 맞닥뜨린 크롤링 오류를 명시하고 있으며, 심지어 구글에서는 문제를 발생시킬 수 있는 특정 매개 변수를 개발자가 무시하도록 허용해준다. 만일 당신이 소유한 웹사이트가 없거나 그것을 검증할 수 없다고 해도 위에 설명한 대로 웹사이트를 크롤링하면 대다수의 문제를 밝혀낼 수 있다.

내가 디즈니 주니어 웹사이트를 크롤링했을 때, 다수의 URL(DisneyJunior.com, DisneyJunior.Disney.com, WatchDisneyJunior.Go.com, Disney.Go.com/DisneyJunior)에서 콘텐츠를 중복해서 관리한다는 점이 점점 명확해졌다. 이는 검색엔진이 페이지 권위^{page authority [9]}를 부여하는 데 걸림돌이 된다. 왜냐하면 웹사이트의 페이지 순위에 따라 검색엔진 스파이더가 한정된 크롤링 예산을 배정받기 때문이다. 고로 위의 URL 4개와 도메인 3개를 페이지 순위로 나눠보면 아마도 좋지 않은 웹사이트 구조를 구글에게 보여줄 것이다. 이 부분은 나중에 중복 콘텐츠에 대한 부분에서 더 많이 다루고자 한다.

검색엔진은 정적인 URL과 잘 어울리며, 디즈니 URL은 주로 정적이기 때문에 그 자체에 중요한 크롤링 문제는 없는 듯하다. 반면 사이트맵은 확실히 개선되어야 한다. 몇 년 전에 검색엔진들은 사이트맵을 ‘색인하려는 웹사이트의 콘텐츠를 찾기 위한 협약’이라고 발표했다. DisneyJunior.Disney.com에 사이트맵이 있지만 문제가 있다. 그중 가장 큰 문제는 비디오 외에 콘텐츠가 더 들어 있는 비디오 사이트맵이다.

사이트맵은 웹사이트 소유자가 검색엔진과 직접 소통하는 방법이다. 그러므로 정보는 가능한 한 정확하게 검색엔진이 혼동하지 않도록 만들어야 한다. 구글에는 디즈니 주니어에 있는 콘텐츠를 포함해 여러 유형의 콘텐츠 관련 사이트맵이 있다. 고로 이미지, 비디오, HTML 문서 등에 관한 사이트맵을 분리해서 보여주는 게 가장 좋다.

크롤링은 모바일에 국한된 문제가 아니지만, 무언가 잘못 틀어지면 모바일 사용자를 위한 웹사이트뿐만 아니라 전통적인 데스크톱 웹사이트에도 좋지 않은 영향을 줄 수 있다. 그러므로 어떻게 해서든지 크롤링은 올바로 되어야 한다.

권장 사항

검색엔진이 활성화된 이미지, 플래시나 자바스크립트 없이 웹사이트를 이해할 수 있는가?

검색엔진은 자신이 페이지의 전반적인 검색 관련성을 파악할 수 없다는 것을 알지 못한다. 구글 글래스^{Google Glass}, 구글 드라이브, 구글 고글^{Google Goggles}에서 광학 문자인식^[10]으로 이미지에 있는 글자를 일반 텍스트로 바꾸는 놀라운 일을 할 수 있지만, 구글 검색에서는 아직까지 텍스트만 읽는다. ‘웹마스터 가이드라인’에서는 다음과 같이 얘기한다.

검색어를 이미지나 플래시에 넣은 웹사이트와 달리, 여기에는 검색엔진이 의미 있는 콘텐츠를 보는 것을 차단하지 않는다. 단지 의미 있는 콘텐츠가 많지 않을 뿐이다. 읽을 단어가 없기 때문에 이 경우에 크롤러는 그 웹사이트를 알아보지 못한다.

만일 계층구조상 아래 페이지를 본다면 우리는 검색엔진이 진행하는 데 곤란한 텍스트 이미지를 볼 것이다.

“Watch Sam Sandwich”로 시작하는 텍스트는 검색엔진이 접근 가능하지만, 로고 안에 있는 “The Bite-Sized Adventures of Sam Sandwich”와 같은 단어들은 이미지 텍스트이기 때문에 접근할 수 없다.

권장 사항

링크하고 공유하기 쉬운 웹사이트인가?

반응형이든 아니든 인간의 소비를 겨냥하지 않은 듯한 URL을 적용한 웹사이트가 많이 있다. 기억하고 공유하기 어려운 URL이기 때문에 당연히 SEO에서 불리한 평가를 받는다. 페이지 순위를 매길 때 검색엔진이 공유와 링크를 얼마나 중요하게 보는지를 고려한다면, 링크와 공유를 더 많이 할수록 그 페이지는 검색 결과에서 순위가 더 높아질 것이다.

디즈니 주니어를 위한 프린트와 비디오 URL들이 위의 부류에 해당되는데, 이는 임의의 문자를 다른 기억할 만한 경로(http://disneyjunior.com/print/stethoscope-4e4e43e2e8368d71cf2086da)에 추가하는 식으로 URL을 만들었기 때문이다. 그래도 대부분의 경우 URL에서 검색어를 포함하며 사용자와 검색엔진이 그것을 쉽게 이해한다.

한 단계 더 나아가 그 웹사이트에는 사용자가 소셜 네트워크에서 콘텐츠를 공유하도록 브라우저의 북마크를 응용하는 기술인 소셜 북마클릿^[11]이 있다. 디즈니 주니어는 페이스북, 트위터, 유튜브에서 활발히 활동하고 있으므로 이 아이디어를 낸 사람은 소셜 미디어의 가치를 이해하고 있음이 틀림없다. 하지만 그들은 어쩌면 소셜 미디어를 강화하는 게 자연 검색^{organic search [12]}에서 점점 중요해진다는 사실을 모를 수도 있다. 페이스북 사용자 중에 78%가 모바일 사용자고, PC 사용자보다 모바일 사용자가 소셜 네트워크에서 보내는 시간이 더 많다는 사실을 고려할 때, 모바일 검색자가 원할 때 콘텐츠를 공유하게 해주는 건 당연하다. 물론 어린이 온라인 사생활 보호법^{Children’s Online Privacy Protection Act(COPPA)} 때문에 어린이용 웹사이트에서 콘텐츠 공유를 못하지만, 어른용 디즈니 주니어에서 공유하면 된다.

이 글은 반응형 웹사이트에서 소셜 버튼을 실행하는 방법에 관한 사용 지침은 아니지만, 페이스북의 모바일 ’좋아요’ 버튼은 반응형 웹사이트에서 잘 작동한다. 웹사이트 성능을 고려할 때, 클릭 시 실제 소셜 스크립트를 로딩하는 지연 로딩^{lazy loading}을 적용한 소셜카운트^SocialCount나 소셜 공유 버튼을 사용하는 건 좋은 생각이다. 만일 애드디스^AddThis와 같은 서드파티 플러그인을 사용할 거라면 반응형 웹사이트와 호환되게 하는 방법도 있다.

권장 사항

소셜 네트워크에서 추천수를 늘리고 콘텐츠 발견^[13]을 활용하게 하려면 어른용 디즈니 주니어에서는 반응형에 총체적인 경험을 추가하고, 페이지 로딩 시간을 크게 증가시키지 않는 소셜 공유 버튼을 넣어야 한다.
 

기기와 상관없이 웹사이트에서 사용자에게 필요한 콘텐츠를 보여주는가?

‘콘텐츠 패리티’를 옹호하는 사람에게는 기기와 상관없이 모든 이들이 접근할 수 있는 웹사이트를 제작하는 게 가치 있는 일이다. 하지만 안타깝게도 이 문제는 풀기가 더 어렵다. 모든 플랫폼에서 이용할 수 있는 콘텐츠를 제작하는 것이 대체적으로 사용자에게는 좋다. 물론 그렇지 않을 때도 있지만.

디즈니 주니어는 꽤 판에 박혀 있다. 사용자에게 의미 있는 콘텐츠를 허용치 않고, 의미 있는 콘텐츠와 그것을 원하는 사용자를 서로 연결해주지도 못한다. 그보다 사용자가 그동안 단 한 번도 사용해본 적 없는 콘텐츠를 제공할 뿐이다. 안타깝게도 내 경험상 대다수의 일반적인 반응형 웹사이트들은 기기와 별도로 모든 콘텐츠에 충분히 접근하지 못하게 하며, 모바일 기기에서 사용할 수 없는 콘텐츠를 제공한다.

구글은 모바일 웹사이트들에서 지나치게 자주 발견되는 한 가지 취약점이 스마트폰 검색 결과에서 불리하게 작용할 것이라 판단했다. 그 취약점은 바로 재생되지 않는 동영상이다. 2013년 구글은 다음과 같이 말했다.

우리는 HTML5 표준 태그를 사용해 동영상을 넣는 것이 좋고, 모든 모바일 기기에서 지원되지 않는 플래시 같은 형식의 콘텐츠는 사용하지 말라고 권한다. 그럼에도 가능한 한 많은 기기에서 재생할 수 있는 동영상을 넣어 스마트폰 사용자가 가장 좋은 경험을 할 수 있도록 최선을 다하라.

디즈니 주니어 동영상을 재생하려고 할 때 아래와 같은 화면을 보면 더 염려가 된다.

모바일 사용자를 위한 콘텐츠를 지원하지 않으면 스마트폰 검색에서 순위는 낮아진다.

몇 가지 경우에 디즈니 주니어는 콘텐츠 패리티를 지나치게 넘어섰다. 이 웹사이트의 4가지 핵심 부분은 게임, 동영상, 프린트, 라이브 피드다. 문제는 사용자가 구글 클라우드 프린트^{Google Cloud Print}를 알고 있고, 그것을 기기에 설치하지 않는 한 색칠 페이지나 다른 인쇄 가능한 페이지를 프린트할 방법이 없다는 것이다.

얼마나 많은 사람이 모바일 기기에서 실제로 이 PDF 파일을 인쇄하는지 모르겠지만, 이 콘텐츠에 접속하려고 애쓴 대다수의 사람들은 아마도 불만이 쌓였을 것이다. 물론 구글이 재생할 수 없는 동영상 때문에 검색 결과에서 웹사이트를 불리하게 했는지에 대한 증거가 나에겐 없다. 다만 그 내용이 4개월 전에 발표됐고 언제든지 적용될 수 있다는 점이다. 순위에 미치는 영향과는 별개로 이 문제를 해결하면 이 웹사이트를 방문하는 누구에게나 도움이 될 것이다.

모바일 기기에서 디즈니 주니어에 있는 콘텐츠의 1/4은 접속할 수 없다.

의심할 바 없이 인쇄 가능한 페이지와 색칠 페이지는 데스크톱과 노트북에서 인기 있는 기능이며 사용자는 적극적으로 그런 콘텐츠를 찾는다. 하지만 모바일 기기라면 완전히 다른 얘기가 된다.

기기별 검색량을 보게 해주는 빙 애드 인텔리전스^{Bing Ads Intelligence}에 따르면, ‘색칠 페이지’에 관한 전체 검색량 중 5% 미만이 모바일 기기에서 온다고 한다. 이는 대다수의 모바일 기기가 프린터와 연결되어 있지 않아 그런 콘텐츠를 보여주는 게 유용하지 않기 때문이다.

2013년 4월 내가 이 문제를 다룬 이후 Disney.com 반응형 웹사이트에서 커다란 진전이 있었다. 거의 모든 게임을 HTML5로 호환해 스마트폰 사용자는 플래시 게임에 접근할 수 없게 된 것이다. 고로 반응형, 모바일 전용 웹사이트 둘 다 괴롭힌 이런 문제들을 고칠 수 있으므로 다신 이런 일이 생기지 않을 것이다.

모든 사용자가 이용할 수 있는 콘텐츠를 제작하는 것은 좋다. 하지만 만일 디즈니가 그렇게 한다면 모바일 기기에서 인쇄하기 전에 사용자는 구글 크롬이나 구글 클라우드 프린트 앱을 다운로드하고, 그 기기를 프린터에 연결해야 한다고 미리 설명해줘야 한다. 디즈니에서 그렇게 하지 않으면, 아이들은 실망하고 기분이 상한 채 모바일에서 PDF를 바라보며 인쇄를 어떻게 해야 할지 궁금해할 것이다. 모바일 사용자를 위해 디즈니는 홈페이지에서 기능을 축소하는 것도 고려해볼 수 있다.

마지막으로 디즈니 주니어의 반응형 웹사이트에서는 사용할 수 있는 모바일 콘텐츠에 관한 것이 빠져 있다. 사용자 행동에 대한 추정은 늘 까다롭지만, 이 경우 모바일 사용자는 인쇄 가능한 자료보다는 앱과 모바일 게임을 더 많이 찾는다고 보는 게 거의 맞다. 하지만 모바일 기기에는 플래시가 설치되어 있지 않아 구글에서 ‘디즈니 주니어 앱’으로 찾은 첫 번째 검색 결과는 오류 메시지를 표시하기도 전에 사용자를 반응형이 아닌 다른 페이지로 데려간다.

4살된 아들이 내 스마트폰으로 디즈니 주니어에 접속했는데 플래시를 다운로드하는 페이지로 리디렉트(redirect)되자 “아빠, 이게 뭐예요?”라고 물었다.

더군다나 사람들이 한 달에 12,000번 이상 검색하는 용어인 ‘모바일 게임’으로 검색하면 그 결과에 디즈니가 안 보인다. 스마트폰에서 호환되는 디즈니 게임들은 그 검색어와 관련 있지만, 디즈니 웹사이트에 그 단어가 없기 때문에 검색 결과에 보이지 않은 것이다. 참 유감스러운 일이다. 검색 결과에 나타나지 않으니 이는 검색엔진 최적화라고 할 수 없다.

디즈니와 관련된 플랫폼별 검색어 검색량에 관한 이 수치들은 데스크톱과 노트북 사용자보다 모바일 사용자가 다양한 검색어를 다른 빈도로 검색하고 있음을 보여준다.

권장 사항

반응형 웹사이트의 접근성과 검색 능력 향상을 위한 3가지 기회가 디즈니 주니어에 있다.

웹사이트가 빨리 로딩되는가?

내가 아카마이^Akamai의 에반젤리스트인 가이 포자니^{Guy Podjarny}의 주장 그대로 서치 엔진 랜드에서 ‘반응형 웹사이트는 흔히 부풀려지며 느리다’고 했을 때 반대 지적을 많이 받았다. 그들 대다수는 내 말을 ‘반응형 웹사이트는 빨라질 수 없다’라고 받아들였다. 물론 빨라질 수 있다. 하지만 아쉽게도 대다수 웹사이트는 아니다.

반응형은 성능에 좋지 않을 뿐만 아니라 SEO에도 해가 될 수 있다. 구글에서 검색 결과 순위에서 불리해지는 잦은 실수에 대해 지적했을 때, 그 대상 목록^{hit list}에 로딩 속도가 느린 페이지를 넣었다. 다행히도 구글은 개발자들에게 페이지스피드 인사이트^{PageSpeed Insights} 도구를 포함해 웹사이트 속도를 높일 수 있는 많은 리소스를 주고 있다. 이 도구에 있는 권고 사항들을 따라 하면 당신의 웹사이트를 1초 이하로 뜨게 할 수 있다. 이는 구글에서 최적의 모바일 성능으로 보는 시간이다.

디즈니 주니어는 로딩하는 데 평균 7초 이상 걸리며, 페이지 속도와 관련해 구글은 100점 만점에 71점을 준다.

아카마이(Akamai)의 모비테스트(Mobitest) 도구는 모바일 기기에서 페이지가 뜨는 데 걸리는 시간을 매우 잘 보여준다.

구글의 페이지스피드 인사이트(PageSpeed Insights)는 그들이 제안하는 우선순위를 표시하고자 정지 신호의 컬러 코딩을 따른다.

디자인 커뮤니티에서 반응형 웹사이트 성능에 관한 글을 많이 쓰고 있다. 그럼에도 최소한 반응형 웹사이트는 1초 안에 웹 페이지가 떠야 한다는 구글의 가이드라인을 따라야 한다.

권장 사항

디즈니 주니어는 구글의 페이지스피드 인사이트의 충고에 따라 무엇보다도 콘텐츠에서 이미지를 최적화하고, 렌더링을 막는 자바스크립트와 CSS를 제거하며, 페이지 로딩 시간을 1초 이하로 줄여야 한다.
 

웹사이트에서 요청하는 정보가 아니라 앱을 다운로드하라고 하는가?

WTF 모바일 웹사이트는 사용자에게 콘텐츠를 보여주지 않고 앱을 다운로드하라고 하는 많은 웹사이트를 목록으로 만들었다. 이는 도어 슬램^{door slam [14]}이라고 하는 처리 기법으로 로튼 토마토^{Rotten tomatoes}가 대표적인 사례다.

로튼 토마토 웹사이트에 접속한 스마트폰 사용자에게 보이는 앱 틈새 확인창(An app interstitial)

2013년 6월까지 사용자들은 도어 슬램 때문에 짜증이 날 수밖에 없었다. 바로 그 시점에 구글은 검색 결과에서 불이익을 줄 목록에 그런 웹사이트를 추가했다. 이젠 모든 웹사이트 소유자들까지도 언짢게 된 것이다.

웹사이트의 사용자 에이전트^[15]가 모바일 기기인 것을 감지했을 때 이런 도어 슬램이 흔히 일어난다. 내 경험상 반응형 웹사이트에서는 이런 일이 보기 드물게 일어난다. 왜냐하면 대다수의 반응형 웹사이트 소유자들은 앱으로 전환하라고 사용자를 설득하는 게 아니라 그들의 콘텐츠를 자유롭게 접하도록 허용하기 때문이다.

디즈니 주니어는 그 규칙에서 예외다. 만약 당신이 모바일 기기에서 동영상을 보려고 한다면, 그 페이지는 앱으로 리디렉트되고, 특히 모바일 기기가 안드로이드라면 존재하지도 않는 앱으로 리디렉트될 것이다.

안드로이드 사용자가 홈 페이지에서 ’디즈니 주니어 보기’ 링크를 클릭하면 이 메시지 로그와 마주치게 된다.

만일 당신의 반응형 웹사이트에 앱 틈새 페이지^{app interstitials}가 있다면, 스마트폰의 구글 검색 결과에서 자주 나타나지 않게 될 거라는 예상보다 그들의 사업 가치가 더 큰지를 고려할 때다. 내가 말할 수 있는 건 구글에서 이 페이지에 대해 아직 불이익을 주지 않고 있다는 사실이다. 하지만 재생할 수 없는 동영상의 경우처럼 되는 건 시간 문제일 뿐이다.

권장 사항

디즈니 주니어는 앱 틈새 페이지를 없애거나 적어도 사용자를 방해하지 않도록 그것을 배너로 바꾸어야 한다. 앱 틈새 페이지 대용으로 안드로이드와 iOS에서 스마트 배너를 사용할 수 있다.

iOS에서 스마트 배너를 삽입하는 것은 아래의 메타 태그를 페이지 head에 넣는 것처럼 간단하다. 메타 태그에는 앱 스토어 상세 정보가 들어 있다.

안드로이드에서 스마트 배너를 추가하는 게 그리 쉬운 건 아니지만, 애드몹^AdMob을 통해 할 수 있다. 일부 개발자들은 jQuery를 사용해 안드로이드에서 iOS 배너를 모의 테스트한다.
 

웹사이트에 중복된 콘텐츠가 있는가?

스마트폰이 나오기 오래 전 중복 콘텐츠는 해당 페이지가 지정된 검색어에 관련해 검색 순위를 차지하는 걸 방해했다. 하지만 이젠 중복 콘텐츠로 인해 상황이 점점 복잡해지고 있다. 이 용어의 뜻을 모르는 이를 위해 설명하자면, 중복 콘텐츠는 1개 이상의 URL에 존재하는 단일 콘텐츠다. 이것은 페이지순위^PageRank 지표를 분산하기 때문에 페이지 경쟁력을 낮춘다.

내 사례 연구가 입증하듯이 대개 모바일 서브도메인들이 중복 콘텐츠의 장본인이다. 그러나 웹사이트가 반응형이라는 이유로 중복 콘텐츠가 될 가능성이 없다는 얘기는 아니다. 솔직히 모바일에 친화적이든 아니든 모든 웹사이트에서 중복 콘텐츠를 확인하는 게 중요하다. 이를 무시한다면 구글 자체에서 주어진 콘텐츠에 대해 원본 페이지를 찾으려 할 것이다. 이것은 웹사이트 소유자에게 늘 좋지 않은 결과를 준다.

이를 운에 맡겨서는 안 된다. 그 대신 사용자를 위한 페이지가 무엇이고 그저 원본을 복사한 페이지가 무엇인지 검색엔진이 이해하게 해야 한다. 우리는 검색엔진이 원본을 알 수 있도록(예를 들어 canonical 태그를 넣고, 웹마스터 도구에서 매개 변수 제어를 조정하는 등) 가능한 한 신호를 많이 보낼 수 있다.

앞에서 말했듯이 디즈니 주니어에는 중복 콘텐츠가 꽤 많다. 하지만 소스 코드 안에 canonical 태그가 있어 구글과 빙^Bing에서 순위를 차지할 페이지가 무엇인지 알려준다. 따라서 이와 관련해 디즈니에 권할 사항은 없다. canonical 태그를 잘 모른다면 아래의 태그를 중복 페이지의 head에 추가하는 것만큼 간단하다고 보면 된다.

이 태그에서 참조된 URL은 특정 콘텐츠의 원본 URL이어야 한다. 일부 디즈니 주니어속성에 중복 콘텐츠 문제가 조금 있다. 예를 들면
Chuggington.com과 DisneyJunior.com/Chuggington에 동일한 콘텐츠가 있다. 디즈니에서 Chuggington.com을 원본 URL로 설정하고자 했다면 그냥 DisneyJunior.com/Chuggington에서 아래 태그를 추가하면 된다.

웹사이트에서 추가적인 콘텐츠를 전달하는 데 모바일 기기를 이용하는가?

디즈니 주니어에는 모바일에서만 보여주는 콘텐츠가 없다. 이는 의도한 것일 수도 있고 아닐 수도 있다. 그러나 이는 모바일 기기에만 특화된 콘텐츠로 소비자를 기쁘게 할 기회를 외면한 것이다.

2008년 어떤 분석가는 이동성^mobility이 완전히 새로운 인터넷을 창조할 거라고 예측했다. 음성 인식^{voice-recognition} 앱, GPS와 스캔할 수 있는 콘텐츠^{scannable content}로 가득 차고 .mobi 도메인으로 호스팅되는 그런 인터넷 말이다. 그는 이것을 모바일넷^mobilenet이라 불렀고 우리가 아는 인터넷과는 다를 것이라 생각했다.

하늘을 나는 자동차와 호버보드^hoverboards를 타고 빠르게 돌아다니는 은색 마일라를 입은^mylar-clad 사람들 얘기가 나오는 공상 과학 이야기처럼 보이지만, 저자는 예측에 뛰어났다. 그는 무엇보다도 현재 택시 산업을 분열시키고 있는 모바일 차량 공유 앱인 우버^Uber를 예측했다. 그리고 그의 글에서 2012년 4월 모바일용 사진 앱인 인스타그램을 페이스북이 1조원에 매입할 것을 예시했다. 스마트폰과 태블릿에는 PC와 다른 속성이 있으며 PC를 사용할 수 없는 상황에 자주 쓰인다. 그러기에 스마트폰과 태블릿은 이전 인터넷에는 없었던 동작과 패턴들을 사람들에게 주입하고 있다.

GPS는 사용자가 구글과 빙^Bing을 이용해 주변 것들을 찾게 해주며, 검색 데이터는 사용자가 기본적으로 스마트폰과 태블릿에서 ’~로 가는 길 찾기^{navigate to},’ ‘가장 가까운^closest’, ’내 주변^{near me}’ 같은 단어를 입력해 GPS를 이용한다는 것을 보여준다. 지금 쇼핑과 관련한 검색은 매장 안에서 2배 이상 일어날 가능성이 높고, 모바일 검색자의 70%는 검색 결과를 통해 PC에서 할 수 없는 일을 직접 전화해서 진행한다. 다수의 사람들은 데스크톱 컴퓨터에서 하듯 모바일 기기에서도 똑같은 것을 검색하고, 한가할 때 자주 검색한다고 한다. 반면 그들 가운데 17%는 바쁠 때 데스크톱과 노트북에서는 불가능한 GPS, 카메라, 가속도계, 전화와 같은 기능에 접속한다.

오늘날, 이러한 모바일을 기준으로 하는 경험이 웹(즉 독립된 모바일 웹이 아닌)에 구축되며, 앱에서는 더 자주 구축된다. SEO 관점에서 보면 웹이 가장 이치에 맞다. ‘웹마스터 가이드라인’에서 구글은 “무엇이 당신의 웹사이트를 독특하고 유용하며 매력적으로 만드는지 생각하라. 당신의 분야에서 다른 웹사이트들보다 당신의 웹사이트가 도드라지게 하라”고 말한다. 그리고 이 문장을 ‘검색 엔진 최적화 기본 가이드’에서 되풀이하며 이렇게 말한다. “설득력 있고 유용한 콘텐츠를 제작하는 게 필시 여기서 논의하는 다른 어떤 요소들보다 당신의 웹사이트에 더 많은 영향력을 미칠 것이다.”

요약하자면 사람들에게 유용한 훌륭한 콘텐츠는 링크되고 공유된다. 이는 구글에 그 품질을 알려준다. 하지만 어떤 앱이든 사용자가 ‘다운로드’나 ‘앱’ 혹은 앱 이름을 검색어로 입력하지 않는 한 검색 결과에 나타나지 않을 것이다. 그리고 구글은 앱 안에 들어 있는 딥 링크들을 처리하거나 색인을 생성하지 못한다. 가능한 한 모바일 사용자가 접근할 수 있는 콘텐츠를 제작하는 방법은 그 콘텐츠를 앱이 아닌 웹에 넣는 것이다.

문제는 구글에서 설명했듯이 반응형 웹 디자인으로 이를 실행하는 것이 어렵다는 점이다. 많은 반응형 웹사이트에서 지오로케이션을 마구 사용한다(예: 스타벅스). 대다수가 이를 실행하기 위해 자바스크립트나 서버 측 요소를 이용하는데, 이렇게 하면 구글의 범위 밖으로 넘어가게 된다.

반면 일부 웹사이트는 스마트폰이나 태블릿에서 누군가에게 매우 유용한 콘텐츠를 제공한다. 이는 어쩌면 구글이 그 웹사이트를 다른 경쟁 사이트보다 순위를 높게 매길 정도로 차별화하는 것일지도 모른다. 내가 가장 좋아하는 사례 중 하나는 시어스^Sears다. 시어스는 모바일 웹사이트에서 동적 게재를 사용해 스마트폰 사용자들이 경쟁사의 가격을 시어스 온라인 가격과 비교할 수 있도록 스캐너 기능을 제공한다. 이는 사람들이 시어스에서 최상의 가격을 쉽게 찾을 수 있게 함으로써 ‘쇼루밍^{showrooming [16]}’ 관행을 없애려고 노력하는 동시에 소비자가 가장 합리적인 가격을 찾도록 자율권을 준다.

시어스의 모바일 웹사이트는 스마트폰 사용자가 시어스의 가격과 대조할 아이템을 살필 수 있게한다.

또 다른 사례는 로우스^Lowe’s다. 로우스는 모바일 웹사이트의 매장 위치와 관련한 페이지에서 매장 내 지도를 제공한다. 작게 추가됐지만 일단 사용자들이 매장에 도착하면 이를 이용해 찾고자 하는 것을 더 빨리 찾을 수 있다. 더불어 이 지도는 경쟁 브랜드와이 브랜드를 구별해준다.

로우스의 모바일 웹사이트에서는 매장 위치와 관련한 매장 내 지도를 제공한다.

권장 사항

디즈니 주니어는 자신의 콘텐츠를 경쟁사의 콘텐츠와 차별화하고 사용자에게 가치를 부여하도록 모바일에 특화된 기회를 생각해야 한다.
 

결론

반응형 웹사이트만 만든다고 해서 검색 결과에 최적화되기에는 충분치 않다. 당신이 점수를 매긴다면 디즈니 주니어의 반응형 웹사이트에서 강조하는 콘텐츠의 절반 이상이 스마트폰에서는 유용하지 않다. 물론 웹사이트가 예쁘고, 기기와 상관없이 사용자가 콘텐츠에 접근할 수 있도록 한 것은 칭찬 받을 만하다. 하지만 이 같은 웹사이트를 진정한 의미에서 ‘반응형’이라고 말할 수 있을까? 반응형 디자인에 들어갈 재료들은 모두 있다. 하지만 반응형이라 함은 ‘빠르고 긍정적으로 반응하는 것’을 의미하는데, 바로 이 점에서부터 이 웹사이트는 여러모로 잘못되어 있다.

구글은 사용자 친화적인 반응형 웹 디자인을 선호한다. 또한 구글은 (의도적으로) 사용자가 불만족스러워하는 웹사이트, 사람들이 검색하는 단어를 검색어로 갖고 있지 않는 웹사이트, 경쟁 웹사이트보다 흥미롭지 않은 콘텐츠가 있는 웹사이트에 트래픽을 보내지 않는다. 모바일 SEO와 싸울 때 이 평가가 당신을 모바일 설정에 대한 생각을 좀 더 깊이 할 수 있도록 하길 바란다. 더불어 검색 결과에서 경쟁력을 갖춘 당신만의 반응형 웹사이트를 만들 수 있는 능력을 갖추길 바란다.

다수의 반응형 웹사이트에서 따르지 않는 다음의 기본 SEO 정보로 시작하라.

[1] 디즈니 주니어는 나라별로 버전이 있다.

[2] 색인: 인덱싱이라고도 부르며, 검색엔진이 웹페이지의 간략한 정보를 목록화하여 저장해 놓은 것을 말한다.

[3] 콘텐츠 패리티^{content parity}: 하나의 웹^{One Web} 철학을 적용하여 어떤 종류의 기기에서든지 동일한 콘텐츠를 보여주는 것이다. http://bradfrost.com/blog/mobile/content-parity/

[4] 동적 게재^{dynamic serving}: 페이지를 요청하는 user-agent에 따라 동일한 URL에서 서버가 다른 HTML(및 CSS)로 응답하는 설정이다. https://developers.google.com/webmasters/mobile-sites/mobile-seo/configurations/dynamic-serving?hl=ko

[5] 링크^{Link equity 혹은 Link juice}: 하나의 페이지에서 다른 페이지로 값을 전달하는 링크. 이는 외부 링크와 내부 링크로 나눌 수 있는데, 특히 외부 사이트에서 들어와 내부 링크에 영향을 주는 링크를 의미한다.

[6] 양방향 설정^{bidirectional annotation}: 구글 개발자 사이트에서는 이를 ‘별도의 URL’로 표현하고 있다(https://developers.google.com/webmasters/mobile-sites/mobile-seo/configurations/separate-urls?hl=ko). 개개의 데스크톱 URL에 대해 모바일에 최적화된 콘텐츠를 게재하는 관련 URL을 따로 두도록 설정하는 것을 의미한다.

[7] 스위치보드 태그^{switchboard tags}: 모바일과 데스크톱 페이지 사이를 연결하기 위해 넣는 태그(tag)로 구글에서 제공하고 있다. 즉 에이전트 기반^agent-based의 리디렉션으로 접속한 기기를 감지하고 그에 맞게 자동으로 사용자를 올바른 페이지로 보내는 역할을 한다.

[8] 딥 링크^{deep link}: 연결되거나 검색해 들어간 사이트의 최상위 페이지(홈페이지)를 제외한 나머지 웹 페이지로 연결된 하이퍼링크다. 딥^deep이란 한 사이트에 있는 웹 페이지의 계층구조에 있는 페이지 깊이를 가리키는 말로 계층 구조 내의 최상위 페이지, 즉 홈페이지 아래에 있는 페이지라면 모두 딥이라고 할 수 있다.

[9] 페이지 권위^{page authority}: 어떤 페이지가 검색엔진에서 얼마나 높은 순위로 매겨질지 예측하는, 100점 만점으로 평가한 점수.

[10] 광학 문자인식^OCR: 사람이 아닌 스캐너가 매거진이나 신문 등 인쇄된 도서를 이미지 형태로 읽고 그 내용을 분석하는데, 그림 영역과 글자 영역으로 구분한 다음 글자 영역의 문자를 일반 문서 편집기에서 수정, 편집이 가능한 텍스트 형태로 변환해주는 자동입력 시스템을 말한다.

[11] 북마클릿^bookmarklets: 북마크(즐겨찾기)와 애플릿(applet)의 합성어로 웹 브라우저의 북마크를 활용한 작은 애플리케이션이다.

[12] 자연 검색^{organic search}: 검색 결과 페이지에서 스폰서 광고 위주의 유료 검색을 제외한 나머지 검색 결과를 말한다.

[13] 콘텐츠 발견^{content discovery}:콘텐츠를 적절한 채널에서 적절한 시점에 적절한 사용자에게 노출하는 것이다.

[14] 도어 슬램^{door slam}: 사용자 흐름을 깨고 앱을 다운로드하라고 요청하는 모달 메시지 창이다. http://www.creativebloq.com/mobile/web-needs-fewer-doorslams-and-more-personality-5135640

[15] 사용자 에이전트^{user agent}: 쉽게 말해 신분증과 같은 기능으로 웹사이트에 접속해서 브라우저, OS, 기종 등의 기기 정보를 제공한다.

[16] 쇼루밍^showrooming: 제품을 오프라인 매장에서 자세히 살펴본 뒤, 구매는 가격이 보다 저렴한 온라인 쇼핑몰을 이용하는 현상이다.

[17] 영구적인 리다이렉션: 이 코드는 검색엔진에게 사이트나 페이지가 영구적으로 옮겨졌다고 말해주고 옮겨진 새로운 사이트나 페이지에 대해 색인을 생성하도록 한다.

반응형 웹디자인

국내 최초 반응형 웹디자인의 모든것 출간!

책 미리보기책 상세설명

독자 여러분, 안녕하세요? 아름다운 웹사이트 만들기 시리즈 일곱 번째 책, 《디자이너, 직업을 말하다》를 소개합니다. 이 책은 디자이너라면 사회생활에서 적어도 한 번쯤은 깊이 고민해 볼 만한 이슈들을 다루고 있습니다. 여러분께서 현재 디자이너로 일한다면 이 책을 읽고 자신감과 문제를 해결할 수 있는 폭넓은 지혜를 갖게 될 것이며, 디자이너 지망생이라면 디자이너로서의 경험을 미리 간접 체험할 수 있을 것입니다.

같은 디자이너라도 세부 분야에 따라 여러분에게 주어진 업무는 천차만별일 것입니다. 그 업무가 무엇이든지 여러분은 ‘디자이너’라는 직업적인 공통분모를 공유하고 있습니다. 그리고 다른 직업의 삶과 마찬가지로 디자이너의 삶도 초짜에서 전문가가 되기까지 그 과정은 순탄치 않습니다. 성공하는 기쁨 외에 실패에 대한 좌절, 고객과 동료에 대한 불만, 돈 문제 등의 고민이 때때로 엄습해 오곤 합니다. 치열한 경쟁 속에서 성공하는 삶은 누구나 다 꿈을 꾸지만 실제 그 목표를 이루는 이들은 소수에 불과합니다. 그럼, 디자이너의 성공하는 삶과 실패하는 삶은 무엇이 다를까요?

타이포그래피의 대가인 에릭 슈피커만이 위의 질문에 대한 정답을 제시하는 듯합니다. “디자이너로 살아간다는 것은 결국 태도의 문제입니다. 물론 기술도 갖춰야겠지요. 하지만 우리의 경험에 비추어볼 때 기술은 귀 기울이고 관찰하고 공부할 준비만 되어 있다면 하나둘씩 익혀나갈 수 있습니다. 그러나 제대로 된 태도를 갖추지 못하면 당신은 항상 누군가에게는 장사치로, 또 다른 누군가에게는 광기 어린 예술가로 인식되고 말 것입니다.”

이 책의 저자 마이크 몬테이로 역시 기술 습득이 아닌 디자이너로서의 태도에 대해 얘기를 합니다. 그는 디자이너로 경력을 쌓기 시작해서 뮬 디자인 회사를 창업을 하고 10년 이상 운영해 온 베테랑 디자이너입니다. 《디자이너, 직업을 말하다》의 1장부터 10장까지 그는 디자이너로서 겪은 다사다난했던 경험과 그만의 값진 노하우를 모든 디자이너와 나누고 있습니다. 심지어 그는 아는 친구에게도 말하기 어려운 경험까지도 여러분에게 도움을 주고자 공유합니다.

디자이너라는 공통분모를 가진 여러분은 아마 이 책을 한 장 한 장 넘기면서 그의 말이 본인의 얘기처럼 느껴질지도 모르겠네요. 그가 제시하는 내용에서 자신감을 얻고 어려움에 굴하지 않는 태도로 변할 거라고 믿습니다.

이 책을 멘토로 삼아 디자이너로서의 삶을 힘차게 성공적으로 나아가길 진심으로 응원합니다. 독자 여러분의 많은 관심과 격려바랍니다.

웹액츄얼리 북스팀

고객이 디자이너를 신뢰하고 디자이너가 초심을 잃지 않을 때 훌륭한 디자인이 만들어진다고 뮬 디자인 스튜디오^{Mule Design Studio}의 공동 설립자인 마이크 몬테이로는 말한다.

“‘제기랄^Fuck!’ 저는 청중의 시선을 끌려고 이렇게 말해요.”라고 마이크 몬테이로는 이야기를 시작한다. “제 방식이죠. 웹 콘퍼런스는 세상에서 가장 따분한 행사잖아요. 청중들은 하나같이 자리에 앉아서 이메일을 확인하거나 트위터를 하는데, 불쌍한 얼간이는 무대에서 떠들고 있죠. 아마도 제 말을 듣고서 몹시 놀랐을 거예요. 아무도 주목하지 않는데, 잘된 거 아닌가요?” 어느 날 무대에서 서서 청중들이 딴짓하는 것을 눈치챈 마이크 몬테이로는 욕설을 퍼부었다. 그들은 하던 일을 멈추고 그를 쳐다보았다. 마이크는 확실히 뭔가 감지했다.

마이크 몬테이로는 《이 자식아, 결제나 해^{Fuck You, Pay me}》와 같이 욕설이 난무하는 강연을 하고, 《디자이너, 직업을 말하다^{Design is a job}》와 《You’re My Favorite Client(웹액츄얼리 출간 예정)》와 같은 책도 저술한다. 2001년 에리카 홀^{Erika Hall}과 함께 공동 설립한 뮬 디자인 스튜디오를 매일 신나게 운영하고 있다.

뮬 디자인 스튜디오는 샌프란시스코에 본사를 두고 있다. “크고 하얀 콘크리트 벽이 있는 사무실은 너무 따분해요. 그래서 그 공간을 흥미로운 것들로 가득 채웠습니다.”라고 그는 말한다.

이 모든 게 어떻게 시작되었을까? “우연히 시작됐죠.”라고 몬테이로는 대답한다. “아무짝에도 쓸모 없는 예술 분야 학사를 받으려면 미대를 다녀야 한다고 오해했던 사람들 중 하나였습니다. 미술학 석사까지 취득할 만큼 멍청했죠. 그러던 중 미대 건물에서 매킨토시로 채워진 방을 우연히 발견했습니다.”

“매킨토시를 갖고 놀기 시작했고, 엄청 재미있었어요. 그렇게 해서 디자인에 첫발을 내디뎠죠. 디자인을 부전공으로 해서 졸업했고, 그 후로 그것이 제 밥벌이가 되었습니다.”

그때는 웹이 알려지지 않은 시기여서, 몬테이로의 삶에서 웹이 움트기 시작한 것은 얼마 후였다. “맨 처음에 AOL이 있었죠. 하지만 허용된 콘텐츠에만 접속이 가능한 폐쇄형 네트워크 서비스^{Walled Garden}였어요. 어느 날 접속을 했는데 월드 와이드 웹^{World Wide Web}이라는 아이콘이 있는 거예요. 아주 미치는 줄 알았죠. 방법만 알아내면 누구나 웹에서 자신이 원하는 것을 할 수 있었어요. 그래서 그 방법을 찾기 시작했죠. 마치 펑크 록^[1]을 알게 되는 것과 같았어요. ‘어떻게 하는 건지 모르지만 일단 해보자. 그러면 뭐가 좋은지 알게 되겠지.’ 대체로 이런 자신감이 있었죠. 거기엔 중개인도 없고, 누군가의 승인을 받아야 할 필요도 없었어요. 만들면 그대로 생겼죠. 정말 대박이었어요. ‘바로 이거야!’라는 생각이 들더군요.”

고객이 디자이너(당신)를 고용하는 이유는 그들이 디자인을 모르기 때문입니다

몬테이로는 그때의 열정으로 시작해 기상천외한 사건, 실수, 잘못된 추측 등 연속된 시행착오를 거치며 디자이너로서의 경력을 쌓는다. “회사에 지원했고 면접을 보는 내내 거짓말을 둘러대서 취업을 했어요. 집에 돌아와서 그 일을 어떻게 하는지 찾아보았죠.” 거기서부터 그는 디자인 스튜디오의 출세 가도를 달리기 시작했다. “그러던 어느 날, ‘이보다 내가 디자인 스튜디오를 더 잘 운영하겠는걸.’이란 생각이 들더군요. 이제까지 머리 속에 들었던 생각들 중에 가장 멍청한 생각이었죠. 15년이 지나니 제 인생에서 만난 그 누구보다도 디자인 스튜디오를 운영하는 사람들에게 공감이 더 많이 되더군요. 그들이 받는 스트레스를 이해해요. 관료 체제를 피할 수 있다는 생각을 할 정도로 어리석기도 했어요. 현실을 외면할 수는 없는데 말이죠.”

네 발 달린 친구

디자인 스튜디오를 창업하기로 결심하니 몬테이로는 그에 딱 맞는 이름이 필요했다. “그랜드 캐니언^{Grand Canyon} 아래서 노새를 탈 수 있다는 걸 아세요? 노새 위에 관광객을 태우고 작은 오솔길로 걸어 내려가는 거예요. 처음엔 말을 이용했죠. 말들은 멋지지만, 미련하고 갑자기 뛰어오르거든요. 악몽 같은 하루가 되죠. 그래서 노새를 사용하기로 한 거예요. 노새는 자신과 등에 올라탄 사람에게 해를 주는 행동을 절대로 하지 않기 때문이죠.”

노새는 매우 조심스럽게 한 발 한 발 재면서 걸음을 걷기 때문에 고집이 센 동물로 유명하다. 한 발짝이라도 위험해 보이면 멈춰 서있다고 몬테이로는 설명한다. “그러니 노새 등에 탄다면, 그 노새를 믿어야 안전합니다. 믿지 못하면 저승길로 가는 거죠. 생각해보니 이 단어가 디자인 회사 이름으로 매우 좋더군요. 오늘날 고객을 최우선으로 여기는데 자부심을 갖고 있습니다.”

하지만 그는 고객을 최우선으로 여긴다는 의미가 고객이 원하는 대로 해주는 것은 아니라고 곧바로 지적한다. 그의 경험에 의하면, 보통 고객은 마음에 목표를 담고 그의 사무실을 방문한다. 그런데, 프로젝트의 나머지 부분을 진행하면서 어떻게든 그 목표를 비켜 가려고 애쓴다. 그런 이유로 고객과 논쟁하고 심지어 본인이 알고 있는 디자인이 거절당하더라도 행복하다고 그는 말한다. 그저 아픈 마음에 반창고 하나만 붙이면 된다고 한다. “저는 도덕적으로 올바르고 지속 가능한 디자인을 하고 싶어요.” 이 말에 디자인과 디자이너의 역할을 어떻게 정의하는지에 대해 질문을 했다. 그는 속사포처럼 대답한다. “디자인은 일련의 제약 조건들을 가진 문제를 푸는 해결책이고, 디자이너는 주어진 제약 조건에서 문제를 해결하는 사람이죠. 지루하게 들리나요? 그렇지만 그게 직업이니까요!”

당당하게 말하기

풍선인형인 제리^Jerry는 몬테이로의 첫 고객들 중 한 명이었던 브라이언 크레더스^{Brian Credus}에게서 받은 선물이다.

대화는 어떻게 좋지 않은 디자인이 세상에 나오게 되는지에 관한 얘기로 옮겨간다. “두려움이 형편없는 디자인을 만들어요. 의견을 분명히 말하지 못하고 머뭇거리면 형편없는 결정을 내리게 되고, 결국 결과물이 형편없이 되는 거죠.” 라고 경험에 비추어 그는 설명한다. “디자이너는 자기 자신이 전문가라는 것을 기억하고 있어야 해요. 만일 내가 뭔가 디자인하고 싶은데 그에 맞는 전문 기술이 없다면 디자이너를 고용합니다. 그리고 그 디자이너에게 이러이러한 것들을 하고 싶다고 말하죠. 그러면 그 디자이너는 실제로 구현하는 방법을 찾고요.” 문제는 디자이너가 자신을 전문가로서 보여주지 않기 때문에 고객도 그렇게 대해주지 않는다고 그는 말한다. 그보다 디자이너는 고객이 원하는 것을 무엇이든지 기꺼이 해주는 도우미로 생각하고 있다고 덧붙인다. “보통 디자이너들은 고객에게 디자이너가 되어 직접 디자인을 결정해달라고 요청하죠. 문제는 고객은 디자인에 관해 전문 지식이 없기 때문에 디자이너를 고용한다는 거예요. 병원에 갔다고 상상해봐요. 의사가 수술은 어떻게 하길 원하는지 어떤 약을 먹고 싶은지 환자에게 물어보는 꼴이죠.”

그의 의학적 비유는 계속된다. 의사는 환자에게 그의 문제에 대해 계속 질문을 하는, 발견의 과정을 거쳐야 한다고 몬테이로는 설명한다. 그렇게 모은 정보로 의사는 자신의 지식과 경험을 활용해서 환자의 병을 진단하고, 치료제를 처방한다. 몬테이로는 디자이너들에게 그저 고객이 시키는 대로만 하는 하인이 아닌 의사처럼 행동하라고 말한다.

자신을 팔기

디자이너를 전적으로 신뢰한다는 것은 당신이 좋은 디자이너를 고용했다고 확신하는데 특히 중요하다. 디자인 세계에서는 포트폴리오에 더 많은 관심을 둔다. 이는 몬테이로가 뮬에서 디자이너를 채용할 때 자신과 타협을 봐야 할 부분이기도 하다. “포트폴리오로만 심사하지 마세요. 포트폴리오로 회사 문턱을 넘을 수는 있어요. 그러나 포트폴리오를 근거로 판단해서 사람을 고용하면 안 됩니다. 제가 회사에서 일할 디자이너를 채용할 때도 마찬가지예요. 포트폴리오에서는 그 사람의 이력을 보여주죠. 거기서 직감적인 반응을 얻고 디자이너에게 말을 겁니다.”

몬테이로는 포트폴리오 작품에 담긴 뛰어난 솜씨, 아름다움, 디자이너의 설명에서 매력을 느끼기보단 디자이너가 받았던 제약 사항들에 관심이 간다고 한다. “포트폴리오에서는 (디자인 과정을 거쳐) 완성된 디자인을 보는 거예요. 작품의 보기 좋은 면은 볼 수 있는데, 과연 디자이너의 방법이 고객의 문제점을 잘 해결했는지 알 수가 없어요. 그래서 포트폴리오를 눈으로 훑어볼 때 그 디자이너가 무엇을 해결하고자 했는지, 예산, 일정, 고객의 이해관계자 등 디자이너가 직면했던 제약들에 대해 알고 싶은 거죠. 그 내용들과 6개월 전으로 되돌아가 프로젝트 초기 목표의 달성 여부를 확인했는지, 그 모든 것을 알아야 할 필요가 있죠. 이 내용들을 알기 전에, 제가 아는 것은 디자이너가 예쁜 그림을 제작할 수 있다는 것이죠.”

여러분의 문제를 저에게 말하세요

몬테이로는 고객을 최우선으로 여긴다는 의미가 고객이 원하는 대로 해주는 것은 아니라고 곧바로 지적한다

그렇다면, 디자이너는 고객을 어떻게 응대해야 할까? 새로운 급여 담당자(고객)로부터 프로젝트의 목표와 제약 사항들을 어떻게 꺼내서 시작해야 할까? “고객을 정신과 의사의 의자에 앉혀 놓는 것과 같다고 말하고 싶지 않지만, 실은 매우 비슷해요. 디자이너들은 발견의 과정도 자기 일의 일부분이라고 이해했으면 좋겠어요. 디자이너가 되어 화면에서 하는 작업은 아마 전체의 10% 정도이지 않을까요? 저는 뮬에서 일하는 모든 디자이너들에게 ‘무엇을 디자인할지 정확히 알기 전까지, 문제를 풀 해결책을 찾기 전까지, 그 해결책을 시험해보기 전까지, 책상에 앉아서 아무 곳에도 픽셀이나 선을 그리지 마.’라고 얘기합니다.”

발견의 과정은 어렵다. 그리고 고객이 정보를 디자이너에게 떠넘기는 것을 허용하지 말라고 몬테이로는 경고한다. 디자이너를 고용하기 전에 고객이 사전조사를 많이 한 것은 좋지만, 디자이너 본인이 사전조사를 하는 것이 훨씬 중요하다고 그는 말한다. 실제로 고객이 알고 있는 것을 정확히 파악하려면, 직접 조사해야 한다. 애석하게도 대다수 사람들이 하는 생각은 특별할 게 없는 평범한 지식^{second-rate wisdom}이다.

돈 버는 데 관심이 많은 한 사람으로서, 고객이 디자이너에게 돈을 투자할 가치가 있다고 어떻게 확신하는지에 대해 몬테이로에게 물었다. “가능한 질문을 많이 하세요. 왜 그 디자인으로 결정했는지, (초기에) 설정했던 목표와 문제와 결부시켜서 고객에게 질문해야 해요. 이에 대해 제가 고객에게 가장 많이 듣는 말은 ‘디자인에 대해 전혀 몰라요’ 입니다. 그 말에 저는 ‘네. 그래도 고객님께서는 본인 사업에 대해 저보다 훨씬 많이 알고 계세요. 다행히도 디자인에 대해 잘 아는 저를 고용하셨고요. 자, 우리 함께 힘을 모아봅시다.’라고 대답합니다.”

고객을 정신과 의사의 의자에 앉혀 놓는 것과 같다고 말하고 싶지 않지만, 실은 매우 비슷해요

마지막으로 고객이 디자이너에게 피드백을 어떻게 주어야 하는지에 대해 그는 이야기한다. 여기서 한 번 더, 몬테이로는 쓰라렸던 경험을 토대로 어떻게 고객이 고용한, 픽셀을 사랑하는 디자이너^pixel-pusher의 의욕을 완전히 꺾을 수 있는지에 대해 신랄하게 말한다. “제가 가장 좋아하는 질문은 ‘이 서체를 사용하실 건가요?’예요. 전혀 문제 해결과는 관련 없는 질문이죠. 차라리 그보다는 고객이 가망 없는 일에 우리를 매진시켜서 시간 낭비하게 했던 얘기를 하는 게 더 쉬워요. 디자이너는 이 일을 위해 교육받은 전문가이고, 이 직업으로 밥벌이하는 장인이라는 사실을 잊지 말아야 합니다.”

그에 비해 고객은 사이트를 재설계해 본 적이 없을 것이고, 어떤 과정을 거쳐야 할지도 모른다. 고객과 디자이너의 복잡했던 비즈니스 관계가 어느 정도 대화, 인내, 영업까지 이르렀다고 몬테이로는 설명한다. “자, 예쁘고 사용하기 편하며 모던한 디자인을 잘 하더라도, 왜 그 디자인이 좋은 해결책인지 고객에게 설명하지 못하면 아무 소용이 없습니다. 팔지 못하는 디자인은 그대로 휴지통에 버려지는 거예요. 훌륭한 작품을 팔지 못하는 디자이너보단 평범한 디자인이라도 잘 파는 디자이너가 저에게 소중합니다.”

디자이너,
직업을 말하다

디자이너가 갖춰야 할 비즈니스
‘커뮤니케이션’의 모든 것

책 미리보기책 상세설명

웹액츄얼리 북스팀에서 테크니컬 에디터와 편집 디자이너를 찾습니다.

모집 부문

업무 내용

우대 사항

모집 기간 및 접수 방법

고용 형태

근무 여건

급여

제출 서류

전형 방법

채용 문의

예전의 단순했던 CSS만으로 일했던 그때를 기억하시나요? 사용한 CSS 파일은 단 하나지만 (코드의 줄은) 잠 못 이루는 밤보다 더 길었습니다. (대게 서툴게 작성된) 셀 수 없이 많은 줄과 거기서 알려지지 않고 좌절스럽기만한 IE 버그를 고치고자, 변경할 값 하나를 찾으려고 애썼죠.

여러분, 이제 그런 날들은 과거가 되었습니다. CSS를 다루는 것은 더 흥미로워지고 더 복잡해집니다. 아마도 흥미로워지니 복잡해지겠죠(역자:다양하게 표현할 수 있는 코드가 쏟아지므로 더 복잡해진다는 의미). 멋진 이들이 얘기하는 CSS 전처리기, 반응형 웹 디자인, 점진적 향상^{progressive enhancement}, 적절한 낮춤^{graceful degradation[1]}, 그 외의 것들이 있어서 CSS는 어느 때보다 더 강해지고 있습니다.

CSS는 더 흥미롭고 더 복잡해지고 있습니다.
— 저자

다루어야 할 것이 너무 많기에 체계적인 상태를 유지하는 것이 중요합니다. 그게 항상 수월하지 않다는 것에 대해 동의하실 거예요. 이 글에서 저는 여러분에게 생각하는 법(구현방법이 아닌←이것은 여러분께 맡길게요)을 터득하도록 도움을 드리고자 합니다.

내 구조 만들기

CSS 전처리기를 사용해서 얻는 혜택 중 하나는 성능에 영향을 주지 않고 코드를 나누어 여러 개의 파일에 담을 수 있다는 것입니다. Sass의 @import 지시자 덕분에 개발 환경에서 원하는 만큼 많은 파일을 만들 수 있습니다. 실시간 환경에서 모든 파일이 하나의 파일로 컴파일 될 것입니다.

다중 파일은 개발 환경에서, 하나의 파일은 실시간 환경에서.
— 브루스 리^{Bruce Lee}

CSS를 여러 파일과 폴더에 적절히 나누어 넣는 것에서 정리가 시작됩니다. 저의 은사 중 한 분이 이런 말씀을 하시곤 하셨어요. “모든 것은 그것에 맞는 장소가 있고, 모든 장소에는 그에 맞는 것이 있다.” 그 말씀대로 제가 여기서 하고자 합니다!

폴더는 훌륭하기에 이것을 사용하라

폴더가 없어서는 안되죠. 여러분은 집에서 모든 문서를 상자 하나에 다 넣지 않죠. 아마도 서류철들^folders이 있겠지요. 집/아파트용 서류철, 은행용 서류철, 영수증용 서류철 등등.

제가 모든 SASS 파일을 같은 폴더에 넣을 필요가 없다고 말한다면요?

CSS 구조를 설계하는 것도 정확히 같습니다. 모든 Sass 파일들을 같은 폴더에 넣지 않습니다. 그것들을 분류하세요.

아래는 파일들을 구조화하는 것을 보여줍니다.

보다시피 루트^root에 Sass 파일(main.scss) 한 개만 있습니다. 나머지 다른 파일들은 적당히 나누어져 폴더에 들어 있습니다. 파일명 앞에 밑줄(_)이 붙은 것은 Sass에게 파셜^partial .scss 파일이라고 말해주는 것이에요. 파셜 .scss 파일은 .css 파일로 컴파일 되지 않습니다. 파일을 불러오고 합치는 기본 파일^{base file}의 역할을 수행합니다.

모든 파일을 통치하는 파일 하나,
파일들을 찾는 파일 하나,
모든 파일을 가져오는 파일 하나,
그들을 Sass 방식으로 합쳐라.
— J.R.R. 톨킨^Tolkien

위의 파일 구조에서 폴더를 하나씩 보지요.

Base

base/ 폴더에 일명 프로젝트용 표준 문안^{boilerplate[2]} 관련 내용이 있습니다. 거기에서 reset(아니면 Normalize.css나 그에 유사한 무엇이든) 코드를 찾을 수 있습니다. 아마 프로젝트에 따라 타이포그래피를 다루는 소스나 다른 소스를 발견할 수 있을 것입니다.

Helpers

helpers/ 폴더(때론 utils/로 부르는)에 모든 Sass 툴과 프로젝트 여기저기서 사용할 헬퍼들이 모여있습니다. 기능이 포함됐나요? 믹스인? 다 이 폴더에 넣으세요. 이 폴더에는 _variables.scss(때론 _config.scss로 부르는) 파일도 있어 프로젝트에 대한 모든 글로벌 변수(타이포그래피, 색 구성^{color schemes} 등)를 이곳에 담고 있습니다.

Layout

layout/ 폴더(때론 partials/로 부르는)에 보통 파일이 많이 들어 있습니다. 개별 파일에서 레이아웃(헤더, 푸터 등)의 주요 부분에 관한 스타일을 정의합니다. _grid 파일도 있어서 이 레이아웃을 만드는데 그리드 시스템이 사용된다는 것을 알 수 있습니다.

이 폴더에 네비게이션 파일을 넣는 것이 이치에 맞을 수 있습니다. 저는 이 파일을 components/(다음 내용에서 보실거예요)에 넣지만요. /layout 폴더에 넣는 것이 더 좋을 수 있다고 생각하지만 결정은 여러분 몫으로 할게요.

Components

좀 더 작은 구성요소를 위한 components/ 폴더(흔히 modules/로 부르는)가 있습니다. layout/을 (전역적^global 와이어프레임을 정의하는) 매크로라고 치면 components/는 좀 더 마이크로입니다. 슬라이더, 로더^loader나 그런 유형의 특정한 모듈을 담을 수 있습니다. 여러분의 사이트가 거의 작은 모듈들로 이루어졌기에 보통 components/에 많은 파일들이 있습니다.

Pages

페이지에 특정화된 스타일이 있다면 pages/ 폴더에 그 스타일을 넣고 페이지명과 파일명을 일치시키는 것이 좋을거라 생각합니다. 예를 들면 Home 페이지에 독특한 스타일을 적용하는 일은 흔하죠. 이 스타일을 처리하려고 pages/ 폴더에 _home.scss 파일을 넣을 수 있습니다.

여러분의 배포 과정에 따라 이 파일들은 별도로 호출될 수 있는데 이는 출력되는 스타일시트에서 다른 파일과 합쳐지는 것을 방지하기 위함입니다. 여러분 결정에 달렸습니다. 저의 회사에서는 그것을 partials로 만들지 않기로 결정했습니다. 그것을 요청하는 페이지에만 포함시키도록 하려는 목적이었습니다. 예를 들어 Home 페이지에 특별한 레이아웃이 있고 대략 200줄 되는 CSS를 컴파일한다고 하죠. 모든 페이지에서 그 규칙이 로딩되는 것을 막고자 그 파일을 Home 페이지에만 넣었습니다.

Themes

저처럼 여러 테마를 다루는 규모가 큰 사이트에서 작업한다면 themes/ 폴더가 있는 것이 이치에 맞습니다. 테마/디자인과 관련된 스타일 모두 거기에 넣으세요. 완전히 프로젝트에 특화된 것이어서 여러분이 필요를 느낄 때만 파일을 넣으면 됩니다.

Vendors

마지막이지만 중요한 것으로 여러분은 아마 외부 라이브러리와 프레임워크(부트스트랩, jQueryUI, jQuery에서 제공하며 잘 다듬어진 캐로셀 슬라이더^{FancyCarouselSliderjQueryPowered} 등)에 포함된 모든 CSS 파일을 vendors/ 폴더에 넣을 것입니다. 파일들을 별개의 폴더에 넣는 것은 좋은 방법으로 “이봐, 이건 내가 작성한 파일이 아니고, 내가 짠 코드도 아니며, 내 책임이 아니야”라는 것을 알려줍니다.

예를 들면

게다가 저희 회사에서 vendors-extensions/ 폴더도 있었는데 여기에 벤더 파일을 일부 덮어쓰기하는 파일을 넣었습니다. 예를 들어 _bootstrap.scss 파일을 거기 넣어서 부트스트렙에 있는 구성요소 일부를 바꾸는데 사용했습니다. 벤더 파일 자체를 편집하지 않으려고 했습니다. 그것은 좋은 생각이 아닙니다.

—————————————————————————————————————–

이게 전부입니다. 프로젝트에 따라 구조가 달라질 수 있겠지만 여러분이 이 개념을 이해했다고 확신합니다. 폴더 안에 폴더를 중첩하는 것에 관해 항상 반대하진 않지만 그렇다고 선호하지도 않습니다. 대부분의 경우 단일 레벨^{single level} 구조가 너무 복잡해지지 않고 파일을 깔끔하고 정돈된 상태로 유지할 수 있다는 것을 알게되었습니다. 그렇더라도 프로젝트에서 하위 레벨 구조가 필요하다고 생각한다면 그렇게 하시기 바랍니다.

전문가 조언: 여러분이 scss 폴더를 본 누군가가 파일 구조를 명확히 이해할 수 없다고 생각한다면 구조 전체를 설명하는 README.md 파일을 만들어 (main.scss와 나란히) 루트 레벨에 넣는 것을 고려해 보세요.

파일도 훌륭해!

제가 자주 받는 질문은 “얼마나 많아야지 너무 많은 파일이라고 말하나요?”입니다. 저는 너무 많은 파일은 절대 없습니다고 답변합니다. 작업을 몇몇 파일로 쪼개는 것은 코드를 정리하려는 목적입니다. 여러분이 무언가 더 많은 파일로 나눠야겠다고 느끼면 그렇게 밀어붙이세요!

크리스 코이어가 그의 Sass 스타일 가이드에서 말했듯이

이해될 때까지 작은 파일로 나누세요.
- 크리스 코이어^{Chris Coyier}

저는 단일 구성요소를 다수의 파일로 폭발적으로 증가시키는 데 반대하는 편입니다. 그렇게 하는 타당한 이유가 없는 한 말이죠. 일반적으로 저는 더도 덜도 말고 파일당 모듈 하나를 넣고 모듈의 의미를 알 수 있는 이름을 짓습니다. 이 방식으로 저는 서브라임 텍스트^{Sublime text}에서 코드를 찾고자 할 때 빠른 찾기^{go to[3]}를 할 수 있습니다.

요약

이 글에서 제안한 모든 내용은 저의 개인적 경험을 근거로 작성되었습니다. 저는 프랑스에서 규모가 큰 은행 그룹 중 하나인 크레디 아그리꼴^{Crédit Agricole}사의 웹기반 지사^{web-based branch}에 근무하는 단 한 명의 프론트엔드 개발자입니다. 아마 여러분의 환경과 경험에 맞는 다른 접근방법이 있을 것입니다.

Sass 프로젝트의 아키텍처에 관한 황금률^{Golden Rule}을 뽑으라고 하면 다음과 같이 단순할 수 있습니다. 말이 되는 것을 뽑으세요. 여러분이 프론트엔드 팀에서 일을 하면 모든 팀원들이 선택한 구조에 대해 편히 느끼는지 확인하세요. 그렇지 않으면 어딘가에 문서화하고 공개해서 누구나 파일구조가 어떻게 구성되어 있는지 이해하도록 해주세요.

Sass 구조에 대해 의견이나 제안이 있으신가요? 여러분의 견해를 기다립니다.

큰 힘에는 언제나 큰 책임이 따른다.
— 아쿠아맨^Aquaman

휴고 기로델 Hugo Giraudel
트위터 @HugoGiraudel
GitHub HugoGiraudel
구글플러스: +Hugo Giraudel

휴고 기로델은 프랑스에 거주하는 프론트엔드 개발자이며 재미 삼아 Sass를 하며 시간을 보내는 것을 즐깁니다. 그는 SassyLists, SassyJSON, SassyMatrix, SassyCast, SassySort, Browserhacks를 만든 제작한 저작자입니다.

• [1] 적절한 낮춤(graceful degradation): 먼저 최신 기술기반 혹은 최신 기기에서 동작하는 기능을 만들고 나서 오래된 기술기반 혹은 오래된 기기에서도 유사하게 (성능을 낮춰서라도) 동작하도록 하는 것
• [2] 프로젝트용 표준 문안(boilerplate): (사업상 서류・법률적 합의안 등의) 표준 문안
• [3] 서브라임 텍스트 빠른 찾기(go to): 원하는 파일이나 코드를 빠르게 찾아주는 일종의 검색기능

댄 시더홈 Dan Cederholm

웹디자이너를 위한
SASS

CSS 마스터, 댄 시더홈이 전수하는 SASS 노하우!
SASS로 스마트한 CSS 고수가 되자!

책 구매하기책 미리보기책 상세설명

반응형 웹 디자인이 나온지 수년이 지났고 이는 2012년 웹계의 최대 관심사였다. 브래드 프로스트^{Brad Frost}나 루크 로블르스키^{Luke Wroblewski} 같이 널리 알려진 사람들은 반응형 디자인으로 경험을 많이 쌓았고 우리가 이 분야에서 비약적으로 발전할 수 있도록 도움을 주고 있다. 하지만 여전히 할 일은 많이 남아있다.

이 글에서 반응형 웹 디자인으로 현재 가능한 것과 (CSS Level 4나 HTML5 APIs와 같이) 아직 표준화되지 않은 속성을 사용해 미래에 가능한 것, 계속해서 개선할 것에 대해 살펴볼 것이다. 이 글은 완벽하지 않고 각 기술에 대해 심도깊게 들어가지 않는다. 대신 여러분은 스스로 더 검토할 수 있을 만큼 충분한 링크와 지식을 얻을 것이다.

반응형 웹 디자인 이미지의 현재

반응형 웹 디자인에서 이미지만큼 이야기를 시작하기 좋은 측면이 있을까? 꽤 오랫동안 중요하게 다루어진 주제이다. 고밀도^high-density 화면의 도래로 이미지는 더욱 더 중요해졌다. 고밀도를 말하자면 픽셀 비율이 2보다 높은 화면이며 애플에서 이를 레티나 기기^{Retina devices}라 하고 구글에서 XHDPI라고 한다. 반응형 웹 디자인에서 이미지는 크기와 성능과 연관된 큰 문제에 직면한다.

대부분의 디자이너가 픽셀을 완벽하게 맞추는 것을 좋아하지만 고밀도 기기에서 ‘일반’ 크기의 이미지는 픽셀이 화면에 맞게 보정되어 흐릿하게 보인다. 단순히 두 배 크기되는 이미지를 고밀도 기기에 사용하고 싶은 유혹이 들지않나? 그렇게 하면 성능에 문제가 발생한다. 두 배나 큰 이미지를 로딩하는데 시간이 더 걸리기 때문이다. 고밀도 기기를 소유한 사용자는 그 이미지를 다운로드하는데 필요한 인터넷 대역폭이 제공되는 환경에 있지 않을 수 있다. 사용자가 거주하는 국가에 따라 인터넷 대역폭 사용료가 비쌀 수도 있다.

두번째 문제는 더 작은 기기에 영향을 미친다. 모바일 기기에서 300픽셀 이미지만 필요한데 750픽셀 이미지를 왜 다운로드해야 할까? 작은 기기를 사용하는 사용자가 의미 있는 부분만 볼 수 있도록 이미지를 자르는^crop 방법이 있을까?

2가지 마크업 해결책: <PICTURE> 엘리먼트와 SRCSET 속성

반응형 이미지 문제를 풀려는 첫 단계는 HTML 페이지에 있는 이미지 마크업을 바꾸는 것이다.

반응형 이미지 커뮤니티 그룹은 새롭고 다루기 쉬운 엘리먼트인 <picture> 엘리먼트에 관한 제안을 지지한다. 현재 잘 알려진 미디어 쿼리를 이용해 각각 다른 기기에 다른 이미지를 제공한다는 개념이다. 따라서 작은 기기에 작은 이미지가 다운로드된다. 비디오 마크업과 유사하게 작동하지만 source 엘리먼트에서 다른 이미지를 참조하는 점이 다르다.

제안된 명세서에^{proposed specification} 있는 코드는 다음과 같다.

다른 이미지 자료를 제공할 수 있다면 작은 기기에서 의미 있는 부분을 보도록 이미지 일부를 잘라서 제공하는 것도 상상할 수 있다. W3C ‘아트 디렉션[1]’의 이용 사례는 무엇을 할 수 있는지에 관한 좋은 예를 보여준다.

(이미지: 예고리 파스코^{Egor Pasko})

해결방안은 현재 W3C 반응형 이미지 커뮤니티 그룹에서 논의중이고 아는 바로는 이 순간 어떤 브라우저에서도 사용할 수 없다. 픽쳐필^Picturefill로 부르는 폴리필^polyfill을 사용할 수 있으며 이것은 거의 동일한 기능을 구현한다. 폴리필은 보안을 위해 div와 data- 속성 구문을 사용한다.

반응형 이미지 마크업에 관한 두 번째 제안을 애플이 W3C에 했고 그것을 ‘srcset 속성’이라 부른다. CSS 레벨 4에 있는 image-set()에 해당한다. 이 속성의 목적은 사용자 에이전트^{user agents}가 전체 세트를 가져오지 않고 세트에서 조건에 맞는 리소스를 선택하도록 하는 것이다. 이 제안을 위한 HTML 구문은 <img> 태그 자체를 기본으로 하며 명세서에 있는 예는 다음과 같다.

보다시피 구문이 전혀 직관적이지 않다. 태그 값은 쉼표(,)로 구분되는 문자열로 되어 있다. 속성 값은 각종 이미지 이름이나 URL, 기기의 픽셀 밀도, 각각 의도하는 뷰포트 크기의 최대값이다.

위의 정보를 다음과 같이 쉽게 설명할 수 있다.

srcset 속성이 지원되지 않으면 첫 번째 소스는 기본 이미지가 된다. banner-HD.jpeg 뒤에 있는 2x 접미사는 이 특정 이미지가 픽셀 비율이 2보다 높은 기기에 사용된다는 것을 의미한다. banner-phone.jpeg 뒤에 있는 100w는 그 이미지를 사용해야 하는 최소 뷰포트 크기를 말한다. 기술적 복잡성으로 이 구문은 어떤 브라우저에도 구현되지 않았다.

image-set() CSS속성 구문은 거의 똑같은 방법으로 작동하고 화면 해상도에 맞추어 특정 이미지를 로딩시킨다.

아직까지 이 제안은 W3C 편집자 초안 상태이다. 일단 사파리 버전 6+와 크롬 버전 21+에서 작동한다.

이미지 형식, 압축, SVG: 웹에서 이미지로 작업하는 방법 바꾸기

보다시피 새로운 이미지 마크업 형식을 찾는 시도는 굉장히 실험적이다. 이 문제는 이미지 형식 자체에 대한 이슈를 제기한다. 이미지 자체 처리방법을 바꿔서 반응형 해결안을 생각할 수 있을까?

첫 단계는 더 나은 압축률을 적용한 대체 이미지 형식을 검토하는 것이다. 예를 들어 구글은 WebP라는 새로운 이미지 형식을 개발했다. 이것은 PNG보다 26% 작고 JPEG보다 25%~34% 작다. 이 형식은 구글 크롬, 오페라, 얀덱스^Yandex[2], 안드로이드, 사파리에서 지원되며, 구글 크롬 프레임 플러그인을 사용하면 인터넷 익스플로어에서도 작동시킬 수 있다. 이 형식의 주된 문제는 파이어 폭스가 이를 구현할 계획이 없다는 것이다. 이를 알기에 현재로서는 폭넓게 사용될 것 같지 않다.

좋은 평판을 얻고 있는 다른 아이디어는 progressive JPEG 이미지이다. Progressive JPEG 이미지는 그 이름이 시사하듯 점진적으로 보여진다. 렌더링 초기에 흐릿하게 보이지만 계속 진행될수록 이미지는 점점 선명해진다. Non-progressive JPEG는 위에서 아래로 나타난다. “Progressive JPEGs: 새로운 최고의 방식”이란 글에서 앤 롭슨^{Ann Robson}은 progressive JPEG이 기선^baseline JPEG보다 더 빨리 보여지는 느낌을 준다고 주장한다. Progressive JPEG은 파일이 완전히 로딩되기 전에 사용자에게 이미지의 전체적인 느낌을 빨리 전달한다. 이것이 성능과 이미지 크기의 기술적인 문제를 풀지 못하지만 사용자 경험을 개선해준다.

성능과 이미지 크기 문제에 대한 다른 해결안은 이미지 압축률을 바꾸는 것이다. 오랫동안 우리는 이미지 압축률을 높이면 전반적으로 이미지 품질에 손실을 가져온다고 생각했다. 다안 조브시스^{Daan Jobsis}는 이것을 주제로 폭넓은 연구를 했고 “레티나 혁명”이라는 글을 썼다. 실험에서 그는 다른 이미지 크기와 압축률을 시도했고 매우 흥미로운 해결안에 도달했다. 보여지는 이미지 크기를 두배로 유지하고 더 높은 압축률을 적용하면 그 이미지는 원본보다 파일 용량이 작아지고 일반 화면과 고밀도 화면에서 선명하게 보인다. 이 기술로 조브시스는 이미지 용량을 75% 줄였다.

단 조브시스의 이미지 압축 사례

골칫거리인 반응형 이미지를 고려해 볼 때 가능한 모든 곳에서 픽셀 독립성을 확보하려는 발상은 많은 디자이너와 개발자를 유혹한다. 예를 들어 SVG 형식은 웹사이트의 모든 UI 요소를 만드는 데 사용될 수 있고 해상도에 독립적이다. 작은 기기에서 그에 맞게 축소되고 고밀도 기기에서 흐리게 보이지 않는다. 폰트 아이콘 역시 증가하는 추세이다. 아이콘 글리프를 (Unicode Private Area처럼) 폰트의 특정 문자에 지정하는 것이 필요하고 폰트를 다루기 쉽게 해준다. 불행히도 이 해결안은 사진에 적용되지 않는다. 이에 성공할 수 있는 마크업이나 이미지 형식을 간절히 기대하고 있다.

반응형 레이아웃의 문제: HTML 작업없이 콘텐츠를 재배열하고 관리할 수 있는가?

솔직히 말해 오늘날 우리가 사용하는 float와 inline 블록으로 만들어진 유동형 그리드^{fluid grid}는 더 나은 해결책을 기다리는 부족한 패치^patch이다. 현재 자바스크립트에 의지하지 않고 레이아웃 작업과 모바일 기기 페이지에서 블록을 재배열하는 일은 악몽이다. 융통성도 없다. CMS로 만들어진 웹사이트에서 특히 중요하다. 디자이너는 웹사이트의 모든 버전과 페이지의 HTML을 변경할 수 없다. 그렇다면 어떻게 이것을 개선할 수 있을까?

융통성 없는 레이아웃 문제를 다루는 4가지 CSS3 레이아웃 해결안

가장 확실하고 실행가능한 해결안은 CSS3 플렉시블 박스 레이아웃 모델 (혹은 ‘플렉스박스^flexbox’)이다. 현재 후보 권고안^{candidate recommendation} 상태이며 대부분의 주요 모바일 브라우저와 데스크톱 브라우저에서 지원된다(IE는 버전 10이상). 이 모델은 HTML에 독립적이어서 화면 요소들을 쉽게 재배치할 수 있게 해준다. 문맥에 맞게 박스 방향과 박스 흐름을 변경할 수 있고 공간을 분배하고 정렬시킬 수 있다. 모바일에서 재배열되는 레이아웃에 대한 예제이다. 구문은 다음과 같다.

“CSS3 플렉시블 박스 레이아웃 설명” 글에서 플렉스박스가 작동하는 방식에 대해 깊이 이해할 수 있다.

다른 해결안은 리로케이트^Relocate로 이것은 페이지에서 블록을 재배치하는 플렉스 박스 개념에 매우 가깝지만 자바스크립트를 사용한다.

오늘날 반응형 디자인에 꽤 쓸만한 두 번째 유형의 레이아웃은 CSS3 다중 열 레이아웃^{multiple-column layout}이다. 이 모듈은 후보 권고안 상태이며 IE 9 이하 버전을 제외한 대부분 브라우저에서 잘 작동한다. 이 모델의 주요 혜택은 유연성에 크게 힘입어 컨텐츠가 한 열에서 다른 열로 흘러간다는 것이다. 반응성 면에서 볼 때 뷰포트 크기에 따라 열의 개수가 조정된다.

사용가능한 공간에 따라 열 크기를 정하고 브라우저에서 열 개수를 계산하도록 할 수 있다. 또한 사이 빈 공간과 규칙이 적용된 열 개수를 정할 수 있고 브라우저에서 각 열의 폭을 계산하게 하는 것도 가능하다.

구문은 다음과 같다.

더 자세히 알고 싶으면 데이비드 월시^{David Walsh}의 글 “CSS 열^Columns”을 읽어보라.

향후 더 많은 주목을 받으리라고 생각하는 세 번째 CSS3 속성은 CSS3 그리드 레이아웃^{grid layout}이다. 이 레이아웃은 디자이너와 개발자에게 유연한 그리드를 제공해 각기 다른 레이아웃을 만드는데 이를 사용할 수 있다. 정의된 구조없이도 컨텐츠 엘리먼트를 행렬에 보여지도록 해준다. 우선 컨테이너^container에 그리드를 선언하고 자식 엘리먼트를 이 가상 그리드^{virtual grid}에 배치한다. 그다음 작은 기기에 대한 다른 그리드를 정의하거나 그리드에서 엘리먼트 위치를 변경하면 된다. 미디어 쿼리와 함께 이것을 사용하면 유연함과 방향 변경 등의 효과를 염두해 볼 수 있다.

구문은 다음과 같다. (2013년 4월 2일자 초안에서 발췌)

명세서에 자세히 알려진대로 행렬 크기를 정하는데 여러가지 단위를 사용할 수 있다. 다양한 엘리먼트를 배치하는 것에 대해 명세서에 다음과 같이 쓰여있다. “게임(예)의 각 부분은 그리드 선들 사이에 놓인다. 이는 시작하는 그리드 선을 표시하고 그다음 (한 개보다 많다면) 끝나는 그리드 선을 확정짓는, 전체를 포괄하는 행과 열 개수를 명시한다. 이로서 그 부분의 경계선이 만들어진다.

이 속성의 가장 큰 문제는 현재 IE 10에서만 지원이 된다는 점이다. 이 레이아웃을 더 알고 싶으면 레이첼 앤드류^{Rachel Andrew}의 “CSS3 그리드 레이아웃으로 콘텐츠 우선순위 정하기”를 읽어보라. 2013년 4월 2일을 기준으로 그리드 레이아웃에 관한 명세서와 구문이 변경되었으니 주의하라. 레이첼은 구문에 대한 업데이트 내용을 “CSS 그리드 레이아웃: 무엇이 바뀌었는가?”라는 글에 담았다.

향후 브라우저에서 실행되면 유용한 마지막 레이아웃은 CSS3 템플릿 레이아웃이다. 이 CSS3 모듈은 하나의 엘리먼트와 레이아웃 “이름”을 연결한 다음, 보이지 않는 그리드 위에 그 엘리먼트를 나열해서 적용된다. 그리드는 고정되거나 유동적으로 움직일 수 있고 뷰포트 크기에 따라 변할 수 있다.

구문은 다음과 같다.

보이는 결과는 다음과 같다.

안타깝게도 이 CSS3 모듈을 지원하는 브라우저는 없다. 아마 언젠가 디자이너와 개발자들이 이 명세서에 흥미를 충분히 보이면 브라우저 회사들이 이를 적용할 듯싶다. 지금은 폴리필로 테스트할 수 있다.

뷰포트 상대 단위와 픽셀기반 레이아웃의 마지막

뷰포트 기반의 퍼센트 길이(vw, vh, vm, vmin, vmax)는 뷰포트 자체 면적에 상대적으로 측정되는 단위이다.

1 vw 단위는 초기 컨테이터 블록 너비의 1%이다. 뷰포트 너비가 320이라면 1 vw는 1 x 320/100 = 3.2픽셀이다.

vh 단위도 같은 방식이지만 뷰포트의 높이에 상대적이다. 고로 50 vh는 문서^document 높이의 50%와 같다. 이쯤되면 퍼센트 단위와 무슨 차이가 있는지 궁금할 것이다. 퍼센트 단위는 부모 엘리먼트 크기에 상대적이나 vh와 vw 단위는 부모 엘리먼트 크기와 상관없이 언제나 뷰포트 크기에 상대적이다.

점점 흥미로와지 시점은, 한 예로 콘텐츠 박스^{content box}를 만들어 뷰포트 아래로 박스가 내려가지 않는 것을 확인하고 그 결과로 사용자가 스크롤하지 않고도 정보를 찾을 수 있을 때이다. 또한 전체 부모 엘리먼트에 핵^hack을 적용하지 않고도 정확도 100% 높이의 박스를 생성할 수 있다.

vmin 단위는 vm이나 vh 중 더 작은 값과 같고 vmax는 vm이나 vh 중 더 큰 값과 같다. 따라서 이 단위는 기기 방향의 변화에도 완벽히 대응한다. 아쉽게도 현재 이 단위들은 안드로이드 브라우저에서 지원하지 않는다. 레이아웃에 적용하기 전에 조금 더 기다려야 한다.

적응성^Adaptive 타이포그래피에 관한 한마디

웹사이트 레이아웃은 콘텐츠에 달려있다. 타이포그래피를 논하지 않고 반응형 레이아웃 가능성에 대한 부분을 마무리할 수 없다. CSS3는 폰트 단위를 도입했다. rem단위로 반응형 타이포그래피에 상당히 유용하다.

Em 단위로 측정된 폰트는 부모 엘리먼트에 상대적인 길이인 반면 rem 단위로 측정된 폰트는 루트^root 엘리먼트 폰트 크기에 상대적인 길이이다. 반응형 웹사이트에서 여러분은 다음과 같은 CSS를 작성하고 html 엘리먼트에 명시된 폰트 크기를 변경해서 전체 폰트 크기를 쉽게 바꿀 수 있다.

IE8과 오페라 미니를 제외하고 rem에 관한 지원은 상당히 좋다. rem 단위에 대해 자세히 알고 싶으면 매튜 레티니^{Matthew Lettini}의 글 “rem 단위를 보호하기 위하여”을 읽어보라.

다른 복잡한 콘텐츠를 반응형으로 작동하게 하는 더 나은 방법

느린 속도이긴 해도 반응형 레이아웃에서 이미지와 텍스트를 다루는데 능숙해지고 있다. 그래도 여전히 더 복잡한 콘텐츠 유형에 관한 해결책을 찾아야 한다.

반응형 웹사이트에서 폼^Form 다루기

일반적으로 반응형 웹 디자인에서 폼을 다루는 것, 특히 길이가 긴 폼들은 상당히 어렵다! 폼이 길면 길 수록 작은 기기에 맞추기가 더 난해해진다. 물리적인 적용은 그다지 어렵지 않다. 대부분 디자이너들은 폼 엘리먼트를 한 열에 넣고 input 길이를 화면의 최대 너비로 늘인다. 폼을 눈으로 보기에 매력적으로 만드는 것으로는 부족하다. 모바일 기기에서도 사용하기 쉽게 만들어야 한다.

루크 로블르스키는 초심자에게 텍스트 입력박스^input 대신 체크박스와 라디오 버튼에 의지하고 가능한 곳에서 드롭다운 메뉴를 선택하라고 조언한다. 이런 방식으로 사용자는 정보를 되도록 적게 입력하게 된다. 다른 조언은 제출할 입력내용에 대해 피드백을 받기 전에 사용자가 “전송” 버튼을 누르지 않도록 하는 것이다. 다음 입력으로 넘어가기 전에 진행되는 오류 확인은 모바일에서 특히 중요한데 이는 모바일에서 대부분 폼이 화면 높이보다 길기 때문이다. 사용자가 어떤 입력 필드에서 오타를 냈는데 폼을 전송해야 그것을 알수있다면 (폼을 작성하면서) 오타를 어디서 냈는지 알지 못할 가능성이 많다.

미래에는 자바스크립트 도움없이 새 HTML5 폼 입력박스^inputs와 속성으로 더나은 폼을 만들것이다. 한 예로 required 속성을 적용해 특정 입력필드에 대해 그자리에서 피드백을 받을 수 있다. 아쉽지만 이 시점에 모바일 기기에서 이에 대한 지원은 열악하다. autocomplete 속성 역시 폼을 더 반응형으로 만드는데 도움이 된다.

모바일은 개인용 소지품으로 이름이나 우편주소와 같은 데이터가 일정하게 유지된다고 가정할 수 있다. HTML5 autocomplete 속성을 사용해서 그런 입력필드에 정보를 미리 채워서 사용자가 모든 정보를 반복해서 입력하지 않도록 해준다. 가까운 미래에 폼을 더욱 더 반응형으로 만들 수 있는 새 HTML5 input 전체목록도 있다.

폼 엘리먼트 중에 날짜^Dates는 HTML5로 개선할 수 있는 좋은 예제가 된다. 자바스크립트에 의존해 날짜 선택기^date-pickers를 만들곤 했다. 그 선택기들은 큰 데스크톱 화면에서 쓸만하지만 터치 기기^{touch devices}에서는 사용하기 어렵다. 터치 영역이 너무 작으면 한 손가락으로 날짜를 정확하게 선택하기가 어렵다.

손가락이 날짜 세 개를 동시에 누르는데 어떻게 날짜를 선택하란 말이야?

기대되는 해결안은 새 HTML5 input type=”date”에 있고 이것은 날짜형식에서 문자열을 정한다. HTML5 input type=”datetime”은 날짜와 시간형식에서 문자열을 정한다. 이 방법의 커다란 이점이라면 브라우저에게 어떤 UI를 사용할지 결정하게 한다는 것이다. 이런 식으로 UI는 모바일에 자동으로 최적화된다.

input type=”date”는 데스크톱, (크롬을 사용하는) 안드로이드 폰과 태블릿, 아이폰, 아이패드에서 다음과 같이 보인다.

다른 모바일 기기에서 보이는 input type=”date” 화면

화면 이미지들은 내 안드로이드 폰과 브라우저에서 찍은 것으로 언어가 자동적으로 시스템 언어(불어)로 반영된 것에 주목하라. 내장^native 요소를 사용하기에 여러분은 더 이상 웹사이트의 버전별 언어를 적용할 필요가 없다.

현재 데스크톱 브라우저의 input type=”date” 지원은 오페라와 크롬을 제외하면 전무하다. 안드로이드 내장 브라우저에서 전혀 지원하지 않는다. 하지만 안드로이드용 크롬은 지원하고 iOS용 사파리도 지원한다. 반응형 웹사이트에 이 해결책을 사용하려면 넘어야 할 산이 많다. 그 동안에 기본적으로 해결책을 지원하지 않는 모바일 브라우저에 모비스크롤^mobiscroll 같은 폴리필을 사용하면 된다.

HMTL5 input 해결책과는 별도로 모바일에서의 비밀번호나 마스크^masks를 이용한 복잡한 input 형식화와 같은 다른 디자인 패턴을 개선하려는 시도를 해왔다. 알게 되겠지만 이들은 실험적이다. 완벽한 반응형 폼은 이 순간 존재하지 않으며 이 분야에서 이루어져야 할 게 많다.

반응형 웹사이트에서 테이블 다루기

모바일과 반응형 웹사이트에서 상당히 골치아픈 콘텐츠 유형이 테이블이다. 대부분 테이블은 방향이 수평으로 맞춰지고 수많은 데이터를 한번에 보여준다. 따라서 작은 화면에서 제대로 보이는 테이블을 구현하는 일이 얼마나 어려운지 알게 될 것이다. HTML 테이블은 꽤 유연하다(퍼센트를 사용해 열 너비를 바꿀 수 있다). 그렇게 하면 금새 콘텐츠 가독성이 떨어진다.

누구도 아직까지 테이블을 표시하는 완벽한 방법을 발견하지 못했다. 그래도 나온 의견들이 어느정도 된다.

하나의 접근방법은 “덜 중요하다고 여겨지는 열 숨기고” 체크박스를 두어 사용자가 보고자 하는 열을 고르게 하는 것이다. 데스크톱에서 모든 열이 보여지지만 모바일에서 보여지는 열 개수는 화면 크기에 달려있다. 필라멘트 그룹^{Filament Group}에서 이 접근방식을 설명하고 글에서 실례를 보여준다. 이 해결책은 jQuery 모바일의 테이블 열 토글^toggle에서도 사용되고 있다.

반응형 테이블의 예들

두 번째 접근방식은 스크롤 가능한 테이블을 활용한다. 크기가 고정된 열 하나를 왼쪽에 고정시키고 오른쪽으로 테이블의 더 작은 부분에 스크롤바를 둔다. 데이비드 부쉘^{David Bushell}은 글에서 이 아이디어를 적용하고 있다. 테이블 왼쪽의 <thead>에 콘텐츠 전체가 보이도록 CSS를 사용하고 오른쪽에서 사용자가 콘텐츠를 스크롤하도록 했다. Zurb는 동일한 발상을 다른 방식으로 플러그인에 구현한다. 이 경우 헤더는 테이블 맨 위에 그대로 있고 테이블은 자바스크립트로 복제되어 왼쪽에 첫 번째 열만 보이고 나머지 열들은 오른쪽에 스크롤바와 같이 보인다.

스크롤 가능한 반응형 테이블 2가지 예

스크롤바와 overflow: auto 같은 CSS 속성에 대한 커다란 문제점은 많은 모바일 기기나 태블릿이 스크롤바를 표시하지 않는다는 것이다. 테이블의 오른쪽 영역은 스크롤이 가능하지만 그 사실에 대한 시각적 단서가 없어 사용자는 알지 못한다. 오른쪽에 더 많은 콘텐츠가 있다는 것을 알려줄 방법을 찾아야 한다.

세 번째 접근방식은 큰 테이블을 리플로우^reflow 하고 열을 헤딩과 함께 보여야할 항목으로 나누는 것이다. 이 기술은 jQuery 모바일에 관한 ‘reflow mode’에서 사용되고 크리스 코이어^{Chris Coyier}의 글 ‘반응형 데이터 테이블’에서 설명하고 있다.

다른 기술도 많이 있다. 어떤 것을 사용할지는 여러분의 프로젝트에 달려있다. 2개의 프로젝트라도 서로 같지 않다. 그러기에 다른 사람들이 이 문제를 어떻게 풀었는지만 여러분에게 보여줄 수 있다. 여러분만의 해답을 찾았다면 아래 댓글을 남기거나 트위터에 포스팅해서 세상과 공유하기를 부탁한다. 우리는 한 배를 탔고 모바일에서 테이블은 형편없으니 함께 개선하도록 합시다!

서드파티 콘텐츠 넣기^embedding: 반응형 iframe 문제

많은 웹사이트에 내장된^embedded 서드파티 콘텐츠(YouTube나 Vimeo 동영상, SlideShare 프레젠테이션, 페이스북 애플리케이션, 트위터 피드, 구글 맵 등)가 있다. 대다수 서드파티는 콘텐츠를 iframe을 사용해서 페이지에 넣게 한다. 하지만 솔직히 말하면 iframe은 반응형 디자인에서 다루기 힘든 골칫거리이다. iframe이 가진 가장 큰 문제는 HTML 코드에 직접 고정된 가로와 세로 크기를 넣어야한다는 점이다. iframe에 가로폭 100% 값이 작동하더라도 넣어진 콘텐츠의 비율이 맞지 않을 수 있다. 비디오나 슬라이드쇼를 원래 비율을 유지하면서 넣으려면 차선책을 찾아야한다.

HTML과 CSS에 관한 차선책

티에리 코블렌츠^{Thierry Koblentz}는 “동영상을 위한 고유한 비율 만들기”라는 제목 하에 훌륭한 글를 썼다. 이 글에서 그는 16:9 비율을 사용해 반응형 비디오를 내장하는 방법을 제안한다. 이것은 SlideShare 프레젠테이션이나 구글 맵 같은 다른 종류의 iframe 콘텐츠에도 확대 적용할 수 있다. 코블렌츠는 CSS에서 정한 클래스로 컨테이너^container 안에 있는 iframe을 둘러싼다. HTML에서 iframe에 관한 고정된 픽셀값이 있더라도 그 컨테이너 안에서 iframe은 크기가 유동적으로 조절된다.

앤데르스 M. 앤데르센^{Anders M. Andersen}이 적용한 코드는 다음과 같다.

이것은 모든 iframe에서 작동한다. 잠재적인 문제점 하나는 웹사이트에서 모든 iframe 요소를 <div class=”embed-container”> 엘리먼트로 감싸야 한다는 점이다. 전체 코드를 관리하는 개발자나 HTML에 익숙한 고객에게 괜찮겠지만 기술력이 없는 고객에게는 무용지물이다. 물론 자바스크립트를 사용해서 iframe 엘리먼트를 찾고 클래스에 자동으로 내장시킬 수 있다. 보다시피 여전히 차선책일뿐 완벽한 해결책은 아니다.

향후 반응형 비디오 다루기

HTML5는 동영상에 관해 무수한 가능성를 열어주었다(특히 video 엘리먼트). 굉장한 소식은 모바일 기기에서 이 엘리먼트에 대한 지원이 엄청 좋다는 것이다! 오페라 미니를 제외한 대부분 브라우저에서 이를 지원한다. video 엘리먼트는 꽤 유연하다. 다음과 같이 반응형 동영상을 간단히 보여줄 수 있다.

아마 당신은 이렇게 질문할 것이다. “그럼 뭐가 문제죠?”

문제는 YouTube나 Vimeo가 video 엘리먼트를 지원하더라도 끔찍한 iframe 을 사용해서 동영상을 넣어야 한다. 사랑하는 여러분, 그게 짜증나는거죠. YouTube나 Vimeo가 HTML5 video 태그를 사용해 웹사이트에 동영상을 넣는 방법을 제공할때까지 반응형 웹사이트에 동영상을 넣는 차선책을 찾아야 한다.

크리스 코이어는 FitVids.js라는 jQuery 플러그인으로 차선책을 만들었다. 그것은 앞에 설명한 (동영상 비율을 유지하려고 iframe을 감싸는) 첫번째 방식을 사용한다.

구글 지도 넣기

웹사이트에 구글 지도를 넣었다면 앞에서 말한 컨테이너와 CSS를 적용하면 된다. 다시 말하지만 이건 지저분한 핵에 불과하다. 지도는 정비율로 크기가 바뀌고, 너무 작아져서 사용자에게 보여줄 포커스 영역을 잃을 수 있다. 모바일용 구글 지도에서는 모바일용으로 넣으려면 정적 지도^{static map} API를 사용하면 된다고 말한다. 정적 지도를 사용하면 정말로 iframe 문제가 해결된다. 브래드 프로스트는 이에 관한 글을 쓰고 동일 기술을 사용해 적응형 지도^{adaptive maps}의 사례도 제작했다. 자바스크립트는 화면 크기를 먼저 감지하고 iframe을 모바일 기기용 정적 지도로 대체시킨다. 알 수 있듯이 ‘자체’ 해결책(예: 구글)이 없이 iframe 문제를 풀려고 요령을 부려야 한다.

더 나은 API가 필요해

더 큰 질문. 더 좋은 방법이 있을까? iframe을 사용해 서드파티 콘텐츠를 반응형으로 넣을 때 최대 문제점은 생성된 코드를 제어하는 기술이 부족하다는 점이다. 개발자와 디자이너들은 심각할 정도로 서드파티와 더 나아가 결과적으로 생성된 HTML에도 의존하고 있다. 다른 웹사이트에 콘텐츠를 제공하는 웹사이트 수는 급격히 증가한다. 이 콘텐츠를 페이지에 넣기 위해 iframe보다 나은 해결책이 필요하다.

까놓고 말하면 페이스북 iframe을 넣는 것은 골치아픈 일이다. CSS 제어 부족으로 작업물은 엉성하게 보이고 때로 디자인이 망가진다. 웹은 활짝 열린 공간이다. 아마 지금이 오픈 API에 대해 좀더 생각할 수 있는 적기이다! 미래에는 사용하기 더 좋고 간편한 API가 필요하다. API를 사용하면 반응형도 안되고 고정된 iframe없이 누구나 콘텐츠를 융통성 있게 넣을 것이다. 거대 서드파티 회사가 API를 만들자고 결정할 때까지 조잡한 iframe을 계속 사용하면서 어느 정도 작동하는 속임수에 의존해야 할 것이다.

반응형 네비게이션: 현재 해결책 개요

다른 큰 문제는 네비게이션과 관련이 있다. 웹사이트 구조가 복잡하고 깊어질수록 우리는 더 독창적이 되어야 한다.

이 문제를 간단하게 다루려는 초기 시도로 작은 스크린에서 네비게이션을 드롭다운 메뉴로 변환했었다. 유감스럽게도 이상적인 답은 아니었다. 첫째, 이 해결책은 다층 네비게이션^{multiple-level navigation}에서 엄청 복잡해진다. 접근성에도 문제를 초래한다. 이런 기술로 발생하는 여러가지 문제에 대해 알고 싶으면 “선택 메뉴의 오용을 멈춰라”를 추천한다.

브래드 프로스트와 루크 로블르스키 같은 사람들은 이 문제를 풀려고 시도해왔다. 브래드 프로스트는 웹사이트, 이것이 반응형이다의 네비게이션 섹션에 몇몇 기법을 모아놓았다.

토글 네비게이션은 작은 기기에서 메뉴를 숨기고 ‘메뉴’ 링크 하나만 보여준다. 사용자가 그것을 클릭하면 콘텐츠가 네비게이션 아래로 밀려내려가고 블록레벨^block-level 링크 엘리먼트로 나머지 링크가 메뉴 아래에 나타난다.

내장 애플리케이션 패턴에서 영감을 얻은 다른 방법은 off-canvas 네비게이션이다. 네비게이션은 메뉴 링크나 아이콘 밑에 숨어있다. 사용자가 링크를 클릭하면 네비게이션은 패널 형태로 왼쪽부터 오른쪽으로 미끄려져 나오고 주된 콘텐츠를 밀어낸다.

이 기술에 있는 문제점은 네비게이션이 화면 위에 계속 남아있다는 점이다. 루크 로블르스키는 그의 글인 “반응형 네비게이션: 모든 기기에서 터치 최적화 하기”에서 종류별로 접근하기 쉬운 영역을 보여준다. 모바일에서 가장 도달하기 어려운 영역이 왼쪽 상단이다.

모바일 기기와 태블릿에서 접근 용이한 화면 영역, 루크 로블르스키

이것에 기초해 제이슨 위버^{Jason Weaver}는 화면 하단에 몇 가지 네비게이션 사례를 만들었다. 한 가지 해결책은 ‘하단 고정 메뉴^{footer anchor}’와 ‘메뉴’ 링크다. 하단 고정 메뉴로 작은 기기에서 네비게이션을 화면 하단에 놓고 메뉴 링크로 사용자를 거기로 보낸다. 이는 HTML 앵커 링크 시스템^{anchor link system}을 사용한다.

반응형 웹 디자인에서 네비게이션 문제를 해결하고자 많은 시도를 해왔다. 보다시피 아직 완벽한 해답은 없다. 해답은 프로젝트와 네이게이션의 깊이에 달려있다. 우리에게 행운이라면 이 문제를 해결하고자 노력한 사람들이 그들의 경험을 커뮤니티와 함께 공유하고 있다는 것이다.

해결되지 않은 다른 문제는 무슨 아이콘으로 사용자에게 알려주는가이다. “이봐요! 내 아래에 메뉴가 숨어 있어요! 날 클릭하세요!” 어떤 웹사이트는 (+) 부호가 있고 어떤 데는 정사각형 그리드가 있으며 다른 데는 목록같이 보이는 아이콘이 있고 어떤 데는 (버거 아이콘으로 부르는) 세 줄 아이콘이 있다.

실제 웹사이트에 적용된 아이콘 사례를 보려면 “반응형 웹 디자인 에서 표준 ‘네비게이션 보기’ 아이콘이 필요해”를 읽어보자.

주된 문제는 일반 사용자가 어떤 아이콘을 가장 쉽게 인식할수 있는지 파악하는 것이다. 이중 아이콘 하나만 사용하자고 동의하면 사용자는 훈련을 통해 그것을 인식하게 된다. 문제는 무엇을 선택하는가이다. 필자는 여러분이 어떤 아이콘을 사용하는지를 알고 싶다. 주저하지 말고 아래에 댓글을 남기고 공유해주길 바란다.

모바일 특수성: “사용자가 모바일 기기를 사용중인가? 그렇다면 기기에서 무엇을 할 수 있을까?”

모바일과 태블릿 기기는 데스크톱 컴퓨터와 동떨어진 완전히 새로운 세계이고 그들만의 규율, 행동양식, 기능이 있다. 우리의 디자인을 이 새로운 기능의 범주에 맞추고 싶어질지도 모른다.

네이티브 자바스크립트로 터치 기능 감지하기

화면 크기를 제외하고 데스크톱과 모바일 기기(태블릿 포함)의 차이점이 무엇인지 물으면 대다수 사람들은 터치 기능이라고 대답할 것이다. 모바일 폰에 마우스는 없다(농담이 아니다!). 마우스를 꽂을 수 있는 보기드문 하이브리드 기기를 제외하면 태블릿에서 마우스 이벤트로 할 수 있는 작업은 거의 없다. 브라우저에 따라 CSS 가상 클래스인 :hover가 작동하지 않을 수 있다는 얘기다. 어떤 브라우저는 영리해서 터치 이벤트를 호버 이벤트로 변환하는 자체 대비책을 갖고 있다.

안타깝게도 모든 브라우저가 그정도로 유연하지 않다. :hover 이벤트로 보여지는 숨은 엘리먼트에 의존하지 않는 디자인을 하는 것이 현명하다.

터치 이벤트를 사용하는 것이 다른 해결책이 될 수 있다. W3C 워킹 그룹에서 터치 이벤트 명세서 작업에 착수했다. 미래에는 touchstart, touchmove, touchend 같은 이벤트를 사용할 것이다. Hammer.js나 jGestures 같은 서드파티 프레임워크 필요없이 자바스크립트에서 이런 이벤트에 직접 대응할 수 있을 것이다. 자바스크립트는 하나의 대안이고, CSS는 어떨까?

CSS 레벨 4 “포인터” 미디어 쿼리

CSS Level 4에서 ‘포인터’로 부르는 새 미디어 쿼리를 명시하고 있다. 이것은 마우스 같은 위치 결정 장치^{pointing device}의 존재여부와 정확도를 묻는데 사용될 수 있다. 이 미디어 쿼리는 다음 3개 중 한 개의 값를 취한다.

이 미디어 쿼리를 사용해 터치 기기에 대한 버튼과 링크 크기를 키울 수 있다.

포인터 미디어 쿼리는 아직 지원되지 않으며 제안 단계에 있다. 그럼에도 불구하고 잠재력은 무궁무진하다. 왜냐하면 Modernizr 같은 서드파티 라이브러리 없이 CSS로 터치 기기를 감지할 수 있기 때문이다.

CSS 레벨 4 “HOVER” 미디어 쿼리

CSS 레벨4 명세서에서 새 hover 미디어 쿼리를 제안하고 있다. 이는 기기의 주요 포인팅 시스템이 hover할 수 있는지 여부를 감지한다. 기기가 호버를 지원하면 Boolean: 1을 반환하고 지원하지 않으면 0을 반환한다. 가상 클래스인 :hover와 아무 상관이 없다는 것을 명심하자.

hover 미디어 쿼리를 사용해 호버링을 지원하는 기기에서 특정 기능을 숨기도록 인터페이스를 향상시킬 수 있다. 코드는 다음과 같다.

호버와 연관된 드롭다운 메뉴를 만드는 데 사용할 수 있다. 모바일 기기에 대한 대비책이 CSS 자체에 있기에 기능탐지 프레임워크가 필요없다.

CSS 레벨 4 광도^luminosity 미디어 쿼리

모바일 기기의 다른 특성은 광센서^{luminosity sensor}이다. CSS 레벨4 명세서에 광도에 관한 미디어 쿼리가 있다. 이는 CSS에서 직접 기기의 광센서에 접근한다는 것이다. 다음은 명세서에 있는 설명이다.

‘광도’ 미디어 기능은 기기가 사용되는 곳의 측광 정보를 얻는데 사용되고 그 반응에 따라 저자가 문서 스타일을 조정하도록 해준다.

미래에는 측광에 반응하는 웹사이트를 만들 수 있을 것이다. 사용자 경험을 상당히 개선할 것이다. 예를 들어 washed값을 사용해 예외적으로 밝은 환경을 탐지해 이에 맞춰 웹사이트 대비값을 조정할 수 있다. 밤시간처럼 어두운 환경에 dim 값을 사용한다. 밝기 조정이 필요없을 때 normal 값을 사용한다.

코드는 다음과 같다.

알다시피 CSS 레벨 4에는 새롭고 재미있는 많은 기능을 보증하고 있다. 단지 모바일에 관련되지 않은, 예비된 기능이 궁금하다면, “미래를 살짝 훔쳐보기: 선택자, 레벨4”를 읽어보라.

API와 자바스크립트를 사용해 탐지하는 모바일 기능들

반응형 웹사이트에서 사용자 경험을 놀랍도록 만들기 위해 더 많은 기능을 탐지할 수 있다. 예를 들어 기기의 방향을 알고자 HTML5 DeviceOrientationEvent를 사용해 내장된 자이로스코프, 나침반, 가속도계에 접근 할 수 있다. 안드로이드와 iOS 브라우저에서 DeviceOrientationEvent에 관한 지원은 나아지고 있지만 명세서는 여전히 초안단계다. 그럼에도API는 확실해 보인다. 브라우저에서 HTML5로 작성된 게임을 한다고 상상해보라.

모바일 사용자에게 특히 유용할 다른 API는 geolocation이다. 좋은 소식은 이 API가 이미 잘 지원되고 있다는 점이다. 이 API는 GPS를 사용해 사용자의 위치를 추적할 수 있고 IP주소, RFID, Wi-Fi, 블루투스 MAC 주소 같은 네트워크 신호를 통해 위치를 추측할 수 있다.

이 API를 사용해 반응형 웹사이트에서 사용자에게 맥락적 정보^{contextual information}를 제공할 수 있다. 큰 음식점 체인에서 사용자에게 주변 음식점 위치를 보여주어 모바일 경험을 향상시킬 수 있다. 가능성은 무궁무진하다.

W3C에서 vibration API에 대한 초안도 제시했다. 이것을 이용해 브라우저에서 진동방식으로 사용자에게 촉각적인 피드백을 제공할 수 있다. 이 API는 웹 애플리케이션의 특정 분야와 브라우저에서 작동하는 모바일 게임에 서서히 스며들고 있다.

상당이 논의가 된 다른 API는 network information API이다. 사용자 대역폭을 측정하여 그에 맞게 최적화를 진행할 수 있는 가능성이 많은 개발자들을 유혹해왔다. 높은 대역폭에 있는 사용자에게 높은 해상도 이미지를, 낮은 대역폭에 있는 사용자에게 낮은 해상도 이미지를 제공할 수 있다. 네트워크 API bandwidth 속성을 사용하면 사용자의 다운로드 대역폭을 초당 메가바이트로 측정•가능하다. 두 번째 속성인 metered는 불 방식^Boolean으로 사용자가 (선불카드 같은) 종량제 접속을 한건지 알려준다. 이 두 속성은 현재 자바스크립트로만 접근할 수 있다.

아쉽게도 기술적으로 사용자 접속을 측정하기가 어렵다. 접속상태는 갑작스레 변할 수 있다. 사용자가 터널로 들어가면서 접속이 끊기거나 속도가 갑자기 떨어질 수 있다. 고로 대역폭을 측정하는 마법같은 미디어 쿼리는 이 시점에 가설에 불과해 보인다. 요아브 바이스^{Yoav Weiss}는 그런 미디어 쿼리가 발생시킬 문제와 대역폭 측정에 대한 좋은 글 “대역폭 미디어 쿼리? 필요없어!”를 작성했다.

다수의 다른 API가 모바일 기능을 다루고 있다. 더 알고 싶으면 모질라에 상당히 상세한 목록이 있다. 대부분 완전히 사용가능하거나 표준화되지 않았고 대부분 반응형 웹사이트보다 웹 애플리케이션을 겨냥하고 있다. 그럼에도 불구하고 모바일 웹사이트가 미래에 얼마나 방대하고 복잡해질 수 있는지에 대한 훌륭한 개요를 보여준다.

우리와 사용자가 콘텐츠 다루는 방식을 다시 생각해보기

기술적인 관점에서 글로벌한 콘텐츠를 다루는데 어려움이 많다. 모바일 우선주의 방법이 개발과 디자인 제작과정의 일부가 된지 오래되지 않았다. 예를 들어 모바일 기기에 맞는 최소한의 데이터를 제공하고 그다음 자바스크립트와 AJAX를 사용해 조건부로 데스크톱과 태블릿에서 더 많은 콘텐츠와 이미지를 로드하게 할 수 있다. 하지만 그러려면 콘텐츠를 다루는 방식을 다시 생각해야 하고 충분히 유연하고 적응성이 있는 컨텐츠를 생성하도록 우선순위를 매길 수 있어야 한다. 좋은 예는 앞에 설명한 반응형 지도 해결책이다. 모바일에서 이미지를 부르고 데스크톱에서 진짜 지도를 불러 사용자 경험을 향샹시킨다. 웹사이트가 반응형일수록 콘텐츠를 다루는 일은 더 복잡해진다. 융통성 있는 코드는 적응형 콘텐츠를 형성하는데 도움을 준다.

업계에 있는 사람들이 제안한 하나의 방법은 클래스가 적용된 다수 span으로 문장을 마크업해서 반응형 문장을 만들고, 화면 크기에 따라 특정 문장을 보여주는 것이다. 작은 기기에 맞춰 문장의 일부분을 떼어내는 작업이 가능하다. 이 기법의 적용사례를 37시그널의 “시그널 vs 노이즈” 블로그와 프랭키 로베르토^{Frankie Roberto}의 글 “반응형 텍스트”에서 볼 수 있다. 이런 기법을 푸터^footer에 있는 표어^solgan처럼 웹사이트의 작은 부분을 개선하는데 사용한다 해도 웹사이트의 모든 텍스트에 적용하는 것은 상상하기 힘들다.

이것은 향후 더 중요해질 반응형 웹 디자인 에 문제를 제기한다. 메타 데이터와 컨텐츠의 의미론적인 구조^{semantic structure} 말이다. 언급했듯이 내부^in-house 저자만 웹사이트 콘텐츠를 작성하지 않는다. 다른 웹사이트에서 자동으로 컨텐츠를 받아 재사용하려면 잘 구조화하고 그에 맞게 준비해야 한다. article이나 section같은 새 HTML5 태그는 의미론적 취지^{semantic meaning}를 달성하기에 좋은 시작점이다. 요점은, 콘텐츠를 구조화해서 단일 항목(블로그 포스트라 치면)이 다른 기기에서 다른 형식으로 재활용되고 보여지는 것을 생각해 보라는 얘기다.

가장 큰 도전거리는 웹사이트 콘텐츠 생성 사슬^{creation chain}에 관련된 사람들이 메타 데이터를 쉽게 이해할 수 있게 하는 것이다. 메타 데이터가 콘텐츠 우선순위를 정하는데 어떻게 쓰이고 플랫폼 독립적인 상태에서 프로그램에 따라 콘텐츠를 어떻게 모으는지 설명해 주어야 한다. 또 다른 도전거리는 MS 워드에서 WYSIWYG 콘텐츠 관리 시스템으로 커다란 텍스트 덩어리를 복사하고 붙여넣기를 하는 것이 아닌, 재활용 가능한 블록이라는 관점에서 생각을 시작하도록 돕는 것이다. 디자이너가 콘텐츠(HTML)와 표현(CSS)이 분리되어야 한다는 것을 이해해야 했던 것처럼 콘텐츠와 구조가 두 개의 분리되고 독립적이어야 한다는 것을 이해하도록 도와야 한다.

더 이상 한 가지 플랫폼만 지향하는 콘텐츠를 만들 수 없다. 향후 6개월이나 1년 안에 콘텐츠가 어떤 디바이스 상에 보여질지 누가 알겠는가? 예기치 못한 상황에 웹사이트를 대비해야 한다. 그렇게 하려면 더 나은 편집 도구가 필요하다. 캐런 맥그레인^{Karen McGrane}은 출판업계의 실제 사례들로 “적응형 콘텐츠를 향해 스스로 적응하기”에 관한 강연했다. 그녀는 재사용 가능한 콘텐츠의 생산과정을 얘기하고 COPE 개념(한 번 만들고 모든 곳에 발행하라^{create once and publish everywhere})을 소개한다. 더 나은 CMS가 필요하다. 메타 데이터를 사용하고 만들어 콘텐츠의 우선순위를 정할 수 있는 CMS 말이다. 사람들에게 시스템이 어떻게 작동하는지 설명하고 WYSIWYG 페이지가 아닌 모듈식의 재사용할 수 있는 콘텐츠 오브젝트^{content obejcts} 관점에서 생각할 필요가 있다. 맥그레인이 말한 것처럼.

여러분은 아마 3가지 다른 버전의 헤드라인을 작성하겠죠. 2개의 요약을 작성하고 거기에 달리 잘라진 1~2개의 다른 이미지를 첨부할거예요. 여러분에게 특정 플랫폼에 어떤 이미지와 헤드라인이 보여야 할지 결정하는 권한이 없을 수 있어요. 그 결정은 메타 데이터가 할거예요. 경영 원칙에 의해 결정되겠죠. [...] 메타 데이터는 아트 디렉션^{art direction}입니다.

작은 기기에서 콘텐츠를 잘라내는 것은 미래를 대비한 콘텐츠 전략이 아니다. 재사용 가능한 콘텐츠를 생성할 수 있는 구조를 제공하는 CMS(콘텐츠 관리 시스템)가 필요하다. CMS에서도 더 나은 출판 워크플로가 필요하다. 볼품없이 무거운 인터페이스는 사용자에게 겁을 준다. 특히나 콘텐츠를 생성하는 대다수 사람들은 복잡한 도구에 익숙하지 않다. 사람들이 쉽게 이해할 뿐만 아니라 표현에 독립적인, 의미론적 콘텐츠를 편집할 수 있는 도구를 제공해야 한다.

결론

이 글이 꽤 길지만 빙산의 일각일 뿐이다. 이제 스매싱 매거진 독자는 반응형 웹 디자인이 페이지에 미디어 쿼리를 잔뜩 던져넣는 작업, 적절한 해상도분기점을 고르는 작업, 멋진 새로운 고밀도 폰에 맞게 이미지 크기를 2배로 키우는 작업 그 이상이라는 것을 이해한다. 보다시피 가야할 길은 멀고 아직 목표점에 도착하지 않았다. 해결되지 않은 문제들도 많다. 더불어 완벽한 반응형 솔루션도 없다.

여기서 언급한 새로운 기술과 W3C, WHATWG, 필라멘트 그룹 같은 단체의 협조에 힘입어 미래에는 기술적 해결책이 나올 듯싶다.

더 중요한 것은 웹 디자이너와 개발자들이 더 나은 해결책을 찾도록 도울 수 있다는 점이다. 루크 로블르스키나 브래드 프로스트 같은 사람들과 이 글에 명시된 훌륭한 분들이 각기 다른 기술과 해결책을 계속 실험하고 있다. 실패하거나 성공하더라도 가장 중요한 것은 공유다. 우리(디자이너, 개발자, 콘텐츠 전략가, 웹 디자인 커뮤니티의 구성원)가 반응형 웹 디자인 문제를 풀기위해 무엇을 하고 있는지 공유하는 것 말이다. 결국 우리는 한 배를 타고 웹을 더 나은 곳으로 만들기 위해 노력하고 있지 않은가?

스테파니 월터 Stéphanie Walter

스테파니는 프랑스 출신의 그래픽, 웹 디자이너이자 Pixel과 CSS 애호가, 워드프레스와 커피 중독자이다. 그녀는 모바일과 웹 앱에 관한 UI, UX 디자인을 사랑한다. 그녀는 inpixelitrust에서 프리랜서와 블로거로 활동하면서 그녀의 지식과 생각, 발견, 유용한 링크, 코드 조각, 플러그인 등을 공유하는 일을 즐기고 있다. 스테파니는 또한 Codrops, Onextrapixel, Noupe (불어로 Alsacréations) 등에 글를 기고하고 있다. 스트라스부르그 대학에서 모바일 디자인과 최적화, jQuery 모바일, 초보자를 위한 HTML과 CSS 수업을 하고 있다.

[1] 아트 디렉션(Art Direction): 독특한 CSS 스타일을 적절한 상황에서 콘텐츠 개별 페이지에 적용하는 방식
[2] 얀덱스(yandex): 러시아 토종검색업체로 1997년에 세상에 등장해 자체 개발한 검색기술을 발판으로 2000년대 중반 이후에는 러시아 포탈업계를 평정하며 점유율 60 ~ 70%대를 유지하고 있음

루크 로블르스키Luke Wroblewski

모바일 우선주의

모바일 우선주의 대한
명쾌한 조언과 사례의 결정판!

책 구매하기책 미리보기책 상세설명

루비 인스톨러(Ruby Installer) 설치

루비인스톨러 설치 파일을 다운로드하기 위해 해당 페이지로 이동합니다.

루비인스톨러 파일 다운로드 하기

이동한 페이지에서는 루비인스톨러 실행 파일을 버전별로 나열해서 보여줍니다. 최신 버전을 설치할 것이므로 Ruby 2.0.0-p481를 클릭합니다. 클릭하자마자 파일이 자동으로 다운로드되기 시작합니다.

루비 인스톨러 설치하기

다운로드가 끝나면 실행 파일을 클릭합니다. 설치가 시작되고 언어옵션을 선택하는 화면이 보입니다. 아쉽게도 한글을 지원하지 않습니다. 영어(English)를 선택하고 동의(OK)버튼을 누르세요.

다음 화면에 루비프로그램 설치 및 사용을 위한 라이선스 동의서가 보입니다. ‘I accept the License(라이센스를 수락합니다)’ 라디오 버튼을 클릭하세요. 수락하지 않으면 다음 단계로 넘어갈 수 없습니다.

다음에 나오는 화면이 정말 중요합니다. 이 화면에서 설치폴더를 눈으로 확인하고(기본으로 보여진 폴더를 변경하지 마세요) 바로 아래에 있는 체크박스 옵션 3개 중에서 가운데 옵션(Add Ruby executable to your PATH – 실행할 루비 파일경로를 환경변수에 추가)에 체크하세요. 체크한 후 실행(Install) 버튼을 누릅니다. 설치가 본격적으로 진행됩니다.

설치가 끝나면 설치를 완료했다는 화면이 보입니다. 마침(Finish) 버튼을 누르세요.

SASS 설치

루비를 설치했으므로 그 다음 단계인 Sass를 설치하겠습니다. Sass는 명령 프롬프트(Command prompt)에서 직접 명령어를 입력해서 설치합니다. 예전에 도스(DOS) 시절을 아시는 분은 명령 프롬프트가 친근하겠지만 처음 들어보시는 분은 낯설 것입니다. 겁부터 먹지 마세요. 화면에서 명령어 한 줄만 입력하면 됩니다.

명령 프롬프트 찾아서 실행하기

명령 프롬프트는 어디에서 찾을까요? 2가지 방법이 있습니다. 우선 왼쪽 하단에 있는 ‘시작’ 버튼을 눌러 나오는 ‘모든 프로그램’ 메뉴를 보세요. 보조프로그램 폴더를 클릭해서 펼치면 그 안에 명령 프롬프트가 있습니다. 다른 방법은 ‘시작’ 버튼을 눌러 나오는 화면 하단에 ‘프로그램 및 파일 검색’이라는 검색 입력박스에 ‘cmd’를 입력하고 엔터키를 누르면 명령 프롬프트가 실행되면서 화면에 나옵니다.

SASS 설치하기

명령 프롬프트는 아래와 같이 검정 화면에 텍스트만 있습니다. 단순하죠. 여기서 명령어 한 줄 입력해서 Sass를 설치할 것입니다. 지금 어느 디렉터리에 있든 상관없이 gem install sass를 입력하고 엔터키를 누르세요.

Gem은 루비의 패키지 설치 및 관리 프로그램으로 위의 명령행을 실행하면 Sass 패키지(버전 3.3.8)를 자동으로 다운로드 받아 설치합니다. 설치된 결과는 아래와 같이 보입니다.

축하합니다! 여러분은 지금 윈도우에서 Sass 설치하는 작업을 완료했습니다.

댄 시더홈 Dan Cederholm

웹디자이너를 위한
SASS

CSS 마스터, 댄 시더홈이 전수하는 SASS 노하우!
SASS로 스마트한 CSS 고수가 되자!

책 구매하기책 미리보기책 상세설명

1996년 첫 CSS1이 공식적으로 권고되었고 CSS3까지 발전했으며 이 순간에도 CSS3의 새 규칙이 소개되고 있습니다. 웹 개발에서 CSS 업무의 비중이 커지고 있습니다. 브라우저 호환성을 맞추고 반응형 디자인을 적용하는 작업 등 CSS의 몫이 큽니다. 이에 따라 스타일시트 문서는 길어지고 용량도 커집니다.

이렇게 된 주요 원인 중 하나는 코드의 반복입니다. 전 세계 웹 디자이너들에게 인기 있는 CSS-Tricks의 블로그 운영자인 크리스 코이어^{Chris Coyier}는 “CSS에는 추상화 개념이 없고 코드의 반복만 있습니다. 이런 이유로 CSS가 널리 채택되고 사용되었지만 이제는 관리하기가 어려워졌습니다”라고 말합니다.

코드의 반복으로 인해 CSS 작업자는 파일에 산재해 있는 코드를 찾고 수정하는 데 많은 시간을 보냅니다. 코드를 관리하는 것은 어려워지고 그 효율성도 시간이 갈수록 떨어집니다. CSS를 작성하고 관리하는 분이라면 누구나 공감할 것입니다.

과연 이 문제를 해결하기 위한 좋은 방안은 없을까요? 물론 있지요! CSS의 전처리기가 바로 그것입니다. 전처리기는 위에 언급된 문제에 대해 해결안을 제시합니다. CSS 작업자에게 전처리기는 선택사항입니다. 그럼에도 전 세계 웹 관련 종사자들의 전처리기에 대한 관심은 높습니다. 그들은 여러 전처리기를 비교·분석하고 본인에게 맞는 전처리기를 찾는 데 열심입니다. 마치 이런 변화의 흐름과 거리가 먼 듯 국내에는 아직 그 불꽃이 일어나지 않은 상태입니다.

이 책의 저자인 댄 시더홈은 유명한 웹 디자이너이자 프론트엔드 개발자입니다. 글로벌 웹 디자인계에서 실력 있는 최고 전문가들이 참여해서 저술하는 A Book Apart의 두 번째 책인 《웹디자이너를 위한 CSS3》의 저자입니다. CSS를 10년 이상 직접 손으로 코드를 작성해온 댄은 본인만의 노하우가 담긴 CSS 작업 방식을 고집스럽게 지켜왔습니다. 그렇기에 그는 CSS 전처리기인 Sass에 대해 처음부터 호의적이지 않았다고 고백합니다. Sass를 사용하면서 그의 불신은 강한 믿음으로 완전히 바뀌었고, 이제는 열성적인 Sass 전도사가 되었습니다.

독자 여러분을 위해 댄은 Sass를 처음 접하는 독자의 눈높이에서 복잡하고 어려운 Sass의 용어와 문법을 쉽게 풀어서 설명해줍니다. 그가 제시하는 가상 웹사이트 프로젝트와 예제 코드는 글로 설명할 수 없는 내용을 여러분의 머릿 속에서 쉽게 구체화해줄 것입니다. 댄과 함께 재미있는 Sass 여행을 떠나보세요.

독자 여러분의 많은 관심과 격려 바랍니다.

웹액츄얼리 북스팀

버튼을 넘어서: 제스처 기반 인터페이스의 수용

아마도 당신은 모바일 사용자인터페이스(UI)나 사용자경험(UX) 디자이너로서 애플의 첫 아이폰 발매를 마치 어제 일처럼 기억할 것이다. 무엇보다도 아이폰은 한 개인의 가장 사적인 기기에 터치스크린 중심의 인터랙션을 도입했다. 이로써 시장의 판도가 바뀌었다.

오늘날 아이들은 너무나도 자연스럽게 터치스크린을 경험하며 자란다. 부모들은 아이들이 빠르게 태블릿이나 스마트폰의 작동원리를 이해하는 것을 보고 놀란다. 이는 터치와 제스처 인터랙션을 하면 모바일 경험이 보다 쉽고 보다 재미있어진다는 잠재성을 보여준다.

바(bar)와 버튼에 대한 도전

‘휴먼 인터페이스 가이드라인’의 도입과 애플의 앱 리뷰 보드^{App Review Board}는 모바일 애플리케이션의 품질에 상당한 영향을 끼쳤고, 핵심적인 모바일 UI 요소와 인터랙션을 많은 디자이너와 개발자들이 이해하도록 해 주었다. 예를 들어 애플의 인기 있는 제안 중의 하나는 UITabBar와 UINavigationBar 요소를 사용하는 것이다. 나를 포함한 많은 사람이 이 지침을 따랐다.

사실, 가슴에 손을 얹고 솔직히 말해 보자. 당신이 디자인한 최초의 아이폰 애플리케이션의 위나 아래에 바^bar 요소가 없다고 말할 수 있으면 나에게 연락해서 스크린샷을 보내라. 당신에게 맥주 한 잔을 사고 당신이 시대보다 앞서 있었다고 기꺼이 트위터에 써주겠다.

위, 아래 바에 대해서 내가 가졌던 이슈는 그것이 스크린의 거의 20%를 차지한다는 점이다. 작은 스크린에 맞게 디자인을 할 때 우리는 가능한 모든 픽셀을 콘텐츠에 집중시켜야 한다. 결국 그것이 가장 중요하다.

혁신이 이어지고 있는 이 업계에서 모바일 디자이너들은 더 창의적이고 독창적인 인터페이스를 디자인하기 위해 탐구할 시간이 필요하다. 거기에 애플은 김빠지게도 ‘고정관념을 깨는’ 앱들을 거부해 왔다. Clear나 Rise같이 실험적인 UI와 UX 디자인이 빛을 보기까지 시간이 걸렸던 것은 그다지 놀라운 일도 아니다. 하지만 어찌 됐든 이런 디자인들은 이제 우리 곁으로 왔다. 물론 그 디자인들은 매우 극단적이어서 지식층이나 얼리 어답터 유저들에 집중되고 있긴 하지만, 제스처 기반 인터페이스의 대단한 창의적 가능성을 우리에게 보여주고 있다.

밑으로 잡아당겨서 새로고침을 하는 건 꽤나 직관적으로 느껴진다.

제스처 기반 인터페이스의 힘

2년여 동안 나는 제스처가 모바일 애플리케이션의 사용자 경험에 어떻게 도움이 되는지 연구해왔다. 나에게 가장 중요한 기준은 이런 인터랙션들이 직관적으로 느껴져야 한다는 점이다. 이것이 로렌 브리처^{Loren Brichter}의 “잡아당겨서 새로 고침하기” 같은 창의적인 인터랙션이 눈 깜짝할 사이에 업계 기준이 된 이유이기도 하다. 아이폰용 앱 트위티^Tweetie에 도입된 브리처의 인터랙션은 너무도 직관적인 것으로 느껴져서, 앱이 발매되자마자 수많은 목록기반 애플리케이션들이 너도나도 앞다투어 이와 같은 제스처 방식을 도입했다.

• UI 의 잡동사니 제거하기

더욱 더 제스처 기반에 가까운 인터페이스 디자인을 시작할 때 좋은 방법은 메인 스크린을 메인 콘텐츠의 뷰포트^Viewport로만 사용하는 것이다. 중요한 내비게이션이 항상 스크린에 보여야 한다는 의무감을 갖지 마라. 그보다는 다른 공간을 생각해보자. 가상 2D나 3D의 관점에서 이야기해보면 당신은 내비게이션을 메인 화면의 옆이나, 아래, 뒤, 앞, 위에 위치시키거나 혹은 메인 화면 위쪽으로 숨길 수도 있다. 잡아 끌거나^dragging 미는^swiping 제스처는 사용자를 이러한 UI 요소로 이끌 수 있는 훌륭한 방법이 된다. 앱을 정의하고 디자인하는 일은 결국 당신에게 달려있다.

예를 들어 iOS용 페이스북이나 Gmail 앱에서 내가 좋아하는 부분은 ‘옆으로 미는^side-swiping’ 메뉴를 적용한 것이다. 현재 유행하는 이 UI컨셉은 사용하기가 쉽다. 사용자들은 뷰포트를 오른쪽으로 밀어서 내비게이션 요소를 볼 수 있다. 이런 방식은 앱이 콘텐츠 중심으로 되게 할 뿐 아니라, 단 두 세 번의 터치 인터랙션만으로 앱의 모든 섹션에 접근할 수 있게 한다. 많은 앱이 여기에 미치지 못하고 있다!

페이스북과 Gmail의 옆으로 미는 메뉴

UI 내비게이션 외에도, 당신의 앱은 아마 맥락적 상호작용^{contextual interaction}을 지원할 것이다. 모든 콘텐츠 아이템 밑에 늘 같은 버튼을 두세 개 배치하는 것은 분명히 UI를 어지럽힌다! 시작할 때는 버튼을 사용하는 것이 매우 유용하지만, 제스처에는 콘텐츠와의 상호작용을 더 직관적이고 재미있게 만들 수 있는 엄청난 잠재력이 있다. 탭, 더블 탭^double-tap, 탭핑하며 홀딩하기^{tapping-and-holding} 같은 간단한 제스처를 통합해서 중요한 인터랙션을 만들어 내는 것을 주저하지 마라. 인스타그램은 그들의 핵심 기능 중의 하나인 ‘좋아하기’와 좋아하기의 취소를 더블탭핑 방식으로 지원한다. 가까운 미래에 다른 앱들도 이 단축키를 도입할 것이라 믿어 의심치 않는다.

• 딱 맞는 인터페이스

혁신적인 모바일 제품을 디자인할 때, 사용자 행동을 예측하기란 굉장히 어려운 일이다. 우리가 벨기에의 퍼블릭 라디오^{Belgium’s Public Radio}와 일했을 때 음악 화면과 실시간 뉴스 사이에서 UI 균형을 맞추느라 꽤나 애를 먹었다. 맥락적 시나리오^{Contextual Scenarios}와 취향이 너무 많고 다양하다 보니 완벽한 UI를 만드는 일이 어려웠던 것이다. 그래서 우리는 간단한 끌기^dragging 제스처를 적용하여 사용자가 스스로 균형을 맞출 수 있도록 했다.

사용자는 음악 관련 콘텐츠와 실시간 뉴스의 균형을 드래깅해서 맞출 수 있다.

이 제스처는 애플리케이션에 창의적이고 맥락적인 차원을 부여한다. 끌기 제스처를 하면, 사용자는 한 섹션(뉴스나 음악)에서 다른 섹션으로 옮겨가지 않아도 된다. 다른 콘텐츠를 놓치지 않으면서도 자신이 가장 흥미로워 하는 콘텐츠에 집중할 수 있다.

• 시간, 화면크기, 애니메이션의 관점에서 생각하라

사용자가 아이템을 탭하면 어떤 동작이 일어나는가? 그 일이 실제로 일어났다는 것을 어떻게 시각화할 것인가? 특정 UI 요소가 얼마나 빠르게 뷰포트로 애니메이션 되는가? 5초 동안 인터랙션이 없으면 자동으로 화면에서 사라지는가?

터치와 제스처 기반 기기의 성장은 인터랙션을 디자인하는 방식을 급격히 변화시킨다. 스크린과 페이지를 중심으로 생각하는 대신 우리는 시간, 화면크기, 그리고 애니메이션의 관점에서 생각한다. 당신은 사용자 인터랙션을 미세 조정하고, 그 인터랙션들을 동료와 고객들 앞에서 정적인 와이어프레임 스크린샷으로 보여주는 일이 쉽지 않다는 것을 아마 느꼈을 것이다. 그 방식으로는 터치하고, 누르고, 밀고, 당겼을 때 어떤 일이 벌어질지 100% 예측하고, 이해하고, 느끼지 못하기 때문이다.

Pop이나 Invision 같은 특정한 프로토타입 도구가 와이어프레임에 생명을 불어넣을 수 있다. 그런 도구들은 애플리케이션상의 이동흐름^flow을 테스트하고 언제, 어디에서 사용자가 꼼짝 못하는지를 정확하게 집어내는 데에 매우 유용하다. 당신의 애플리케이션에서는 단순히 앞뒤로만 움직이는 내비게이션 그 이상의 많은 일이 일어나고 있다. 따라서 가능한 한 빨리 인터페이스 버그나 잠재적이지만 혼란이 될 수 있는 원인을 잡아내야 한다. 개발팀이 먼저 당신에게 그걸 지적해내는 상황을 원하진 않을 테니까. 안 그런가?

Invision은 디지털 와이어프레임을 불러오고 링크를 걸 수 있게 해준다.

더 혁신적이고 실험적이고 싶다면 먼저 고객과 만나서 전통적인 와이어프레임이 그들이 필요로 하는 UX 작업물이 아니라는 것을 설명하라. 인터랙티브 와이어프레임의 가치를 보여주고 고객이 그것을 작업과정에 넣도록 권장하라. 시간과 예산이 더 늘어나겠지만, 당신이 한 단계 더 높은 차원의 결과물을 낼 것이라고 고객이 생각한다면 별 문제가 안 될 것이다.

나는 심지어 고객에게 개념적인 인터페이스 동영상을 제작해 주겠다고 제안하기까지 한다. 왜냐하면 인터랙티브 와이어프레임으로 작업해보고 세세한 부분을 정리하면 고객은 내부의 이해당사자들에게 보여줄 만한 매력적인 무엇인가가 종종 필요하기 때문이다.

학습 곡선

제스처 기반의 인터랙션을 디자인할 때 UI의 어수선함을 제거할수록 애플리케이션의 학습 곡선이 상승한다는 것을 기억하자. 시각적 힌트가 없다면 사용자들은 애플리케이션과 어떻게 상호작용할 것인지 혼란스러울 것이다. 약간의 탐색은 전혀 문제 되지 않는다. 하지만 사용자들은 어디에서부터 시작해야 할지 알아야 한다. 많은 앱들이 처음 시작될 때 UI를 단계적으로^walkthrough 보여준다. 그리고 나는 단계적 설명은 가장 중요한 인터랙션만을 설명해야 한다는 맥스 루드버그^{Max Rudberg}의 의견에 동의한다. 한 번에 모든 것을 설명하지 말라. 내용이 너무 대놓고 많거나 길면 사용자들은 설명을 건너뛰고 말 것이다.

자기 자신을 한번 시험해보고 사용자가 애플리케이션을 사용할 때 UI에 관한 창의적인 힌트를 조금씩 조금씩 보여주면 어떨까? 이 방식은 종종 ‘점진적 공개’라고 불리며 사용자의 현재 활동에 연관된 정보만을 보여주기에 훌륭한 방법이다. 예를 들어 유튜브의 Capture 애플리케이션은 사용자가 처음 카메라를 열려고 할 때 사용자에게 장치를 가로 방향으로 돌리라고 말해준다.

UI 단계적 설명과 시각적 힌트로 학습 곡선과 대적하라.

이야기는 그만하고 만들어 보자

아이폰은 인터랙티브 커뮤니케이션의 혁신을 불러왔다. 5년밖에 안 지났는데 터치스크린 기기는 어디에서나 발견할 수 있고, 인터랙션 디자이너들은 사람들이 디지털 콘텐츠를 사용하는 방식을 새롭게 정의하고 있다.

우리는 터치와 제스처 기반 인터페이스의 잠재력을 탐구하고 이해해야 하며 시간, 화면크기, 그리고 애니메이션의 관점에서 생각하기 시작해야 한다. 몇몇 혁신적인 애플리케이션이 보여준 것처럼, 제스처는 앱을 더 콘텐츠 중심적이며 독창적이고, 재미있게 만드는 훌륭한 방법이다. 그리고 처음에는 너무 실험적으로 보였던 많은 제스처 기반 인터랙션이 이제는 무척 직관적인 것으로 보인다.

모든 주요 모바일 플랫폼에서 제스처의 가능성을 완벽히 훑어보려면 루크 로블르스키^{Luke Wroblewski}의 “터치 제스처 참고 가이드^{Touch Gesture Reference Guide}”를 읽어보자. 당신이 제스처 기반의 인터랙션을 탐구하고 모바일 인터페이스에서 심도 깊은 모험을 하도록 영감을 얻기를 바란다. 한 차원 높은 단계로 올라서는 것을 두려워하지 말기 바란다. 인터렉티브 와이어프레임과 함께라면 최고의 경험에 도달하도록 계속 작업할 수 있다. 자, 그럼 이제 얘기는 그만하고 만들기 시작하자.

토마스 주스 Thomas Joos
트위터 @thomasjoos
사이트 http://www.littlemissrobot.com/

토마스 주스는 Little Miss Robot의 동업자이자 인터랙티브 디렉터이다. 그는 창의적이고 혁신적인 디지털 경험을 디자인하며 프로젝트를 개념 단계에서 창조 단계까지 진두지휘한다. 그리고 인터랙티브 경험과 UI/UX 디자인에 대해 대단한 열정을 가지고 있다. 또한 토마스는 디자인 커뮤니티에서 영감을 주는 연사로서 혁신적인 디지털 창조에 대한 생각과 통찰을 활발하게 공유하고 있다.

루크 로블르스키Luke Wroblewski

모바일 우선주의

모바일 우선주의 대한
명쾌한 조언과 사례의 결정판!

책 구매하기책 미리보기책 상세설명