Outsider's Dev Story: Mobile 카테고리 글 목록https://blog.outsider.ne.kr/Stay Hungry. Stay Foolish. Don't Be Satisfied.2024-03-15T10:12:02+09:00Textcube 1.10.7 : Tempo primo[Book] 안드로이드 뜻밖의 역사 - 세상을 뒤흔든 모바일 OS에 담긴 숨은 이야기Outsiderhttps://blog.outsider.ne.kr/16212022-09-14T01:58:20+09:002022-09-14T01:58:20+09:00<div>
<fieldset style="padding: 20px 5px 5px 5px;">
<legend><a href="https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=299230041">안드로이드 뜻밖의 역사 - 세상을 뒤흔든 모바일 OS에 담긴 숨은 이야기</a></legend>
<table>
<tbody>
<tr>
<td>
<a href="https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=299230041"><img src="//blog.outsider.ne.kr/attach/1/7513793119.jpg" width="350" height="524" alt="책 표지" title="안드로이드 뜻밖의 역사" /></a>
</td>
<td style="vertical-align: top">
<a href="https://www.aladin.co.kr/shop/wproduct.aspx?ItemId=299230041">안드로이드 뜻밖의 역사 - 세상을 뒤흔든 모바일 OS에 담긴 숨은 이야기</a> - ⭐⭐⭐⭐
<br>쳇 하스 지음<br>송우일 옮김<br>인사이트
</td>
</tr>
</tbody>
</table>
</fieldset>
<br>
</div>
<p>지금은 iOS와 안드로이드의 세상이 된 게 자연스럽지만, 안드로이드가 어떻게 만들어졌는지를 다룬 책이다. 지금은 애플의 제품을 거의 다 쓰고 있는 관계로 안드로이드에서는 관심이 멀어진 지 오래되었고 안드로이드 개발자도 아니지만, 안드로이드 이전부터 모바일 제품에 관심 있어서 아이폰과 안드로이드가 등장할 때도 관심 가지고 보고 있었기에 책이 나오자마자 편한 마음으로 읽어봤다.</p>
<p>아는 내용도 있지만 몰랐던 부분도 있어서 꽤 재미있게 읽었다. 아마도 안드로이드 개발을 한다면 들었던 이름도 꽤 나올 가능성이 있어서 더 재미있게 읽었을 것 같다. 안드로이드의 개발되어서 성공까지 간 과정이 자세하게 정리되어 있고 이런 의미 있는 일이 기록으로 남게 된 것만으로도 큰 가치가 있다고 생각한다. <strong>안드로이드 하면 앤디 루빈을 떠올리기 쉽지만, 이 책은 한 명의 영웅이 아니라 안드로이드를 만드는 데 관여한 사람들의 업적을 모두 설명하고 있어서 원서의 제목이 왜 "Androids: The Team That Built the Android Operating System"인지 알 수 있었고 실제로 팀에 훨씬 집중하고 있다는 느낌이다. 그래서 더 좋았다.</strong><br />
<br></p>
<h1>1부 시작</h1>
<blockquote>
<p>2003년 후반 디지털 카메라용 운영 체제를 제공하는 포토팜을 창업하고 루빈이 CEO를, 화이트가 CTO를 맡았다.</p>
</blockquote>
<blockquote>
<p>화이트는 루빈에게 '포토팜'보다 더 나은 이름을 찾아야 한다고 말했다. 루빈이 android.com이라는 도메인을 가지고 있어서 그들은 회사 이름을 안드로이드로 바꾸고 캐릭터라는 디자인 회사를 고용해 로고와 명함을 비롯한 CI를 만들게 했다.</p>
</blockquote>
<p>앤디 루빈이 카메라 운영체제를 만들기 위해서 스타트업을 만들었다는 것은 모르고 있었다. 역시 도메인 드리븐인가!!</p>
<blockquote>
<p>루빈은 카메라 운영 체제를 만들지 못했다. 그러나 스마트폰에서 카메라가 얼마나 중요한지 감안한다면 그가 가장 널리 쓰이는 카메라 운영 체제를 만들었다고 주장해 볼 수도 있을 것이다. 단지 우회적인 방법으로 만들었을 뿐이다.</p>
</blockquote>
<p>이 문장은 나한테는 꽤 울림이 있었다. 카메라 OS를 만들고 싶었지만, 주위 반응도 별로여서 하기 싫었던(?) 모바일 운영체제를 다시 만들게 되었는데 돌고 돌아 결국은 카메라 운영체제라고 해도 틀리진 않아 보인다. 세상에서 가장 많이 사진을 찍는 운영체제 중 하나니까...</p>
<blockquote>
<p>2006년까지 안드로이드 팀에 합류한 사람들은 대부분 비-팜소스, 웹티비-마이크로소프트, 데인저 중 한 회사 또는 두세 군데 회사에서 일한 적이 있다.</p>
</blockquote>
<blockquote>
<p>비와 마이크로소프트 웹티비 팀에서 일했고 나중에 안드로이드 엔지니어링 팀을 관리한 스티브 호로위츠는 말했다. "그게 이 세계에서 중요한 부분이죠. 성공보다 실패에서 더 많은 걸 배울 수 있습니다."</p>
</blockquote>
<p>BeOS를 만들던 Be, PalmOS를 만들었던 <a href="https://www.palmsource.com/">PalmSource</a>, Microsoft가 인수한 WebTV, 그리고 앤디 루빈이 창업해서 초창기 스마트폰을 만들던 데인저까지 이 회사들의 이름은 책 전반에 걸쳐서 계속 나오고 안드로이드 초창기 개발자들은 대부분 이 회사들에서 같이 일한 적이 있는 사람들이다. 그리고 안드로이드를 만들기 위해 필요한 기술에 대한 경험이 있고 또 실패한 경험도 있었기에 그 경험을 바탕으로 안드로이드가 더 잘 만들어질 수 있었던 것 같다.</p>
<p style="text-align: center;"><img src="//blog.outsider.ne.kr/attach/1/3694290065.jpg" width="750" height="562" alt="Palm Tungsten T3, Palm Pre, Nexus One" title="" /></p>
<p>나는 1990년대 말부터 모바일 기기에 관심이 많았다. 폰도 그렇지만 당시엔 PDA라는 기기(책에도 나온다)를 무척 좋아하면서 포켓PC 등이 등장하면서 스마트폰으로 넘어갈 때까지 관심 있게 보고 있었다. 위 사진은 지금도 가지고 있는 당시 기기들인데 맨 왼쪽은 내가 제일 좋아했던 PalmSource의 palm Tungsten T3이다. 가운데는 안드로이드, 아이폰과 경쟁하기 위해 Palm이 막바지에 만들었던 Palm Pre인데 여기 들어간 WebOS가 당시 사용성에선 셋 중 가장 좋았다고 생각한다. 하지만 자금력이 없는 Palm Pre는 Palm을 재기시키지 못했고 HP에 인수되었다가 LG전자에 넘어가면서 지금은 LG 스마트TV에 들어가 있는걸로 알고 있다. 맨 우측은 책에도 나오는 안드로이드의 첫 레퍼런스폰 Nexus One이다. 그때는 iPhone보다 오픈 플랫폼을 지향하는 Android가 성공할 꺼라고 생각해서 미국에서 거금을 들여와서 한참 동안 사용했었다.(하지만 이후 아이폰으로 넘어갔다.)</p>
<blockquote>
<p>삼성 미팅은 휴대전화 사업부 대표인 이기택과의 만남으로 시작됐는데 이기택은 과거 데인저와의 기회를 놓쳤는데 같은 일이 다시 일어나는 걸 바라지 않는다면서 안드로이드와 함께하는 데 관심이 있다고 말했다. 시어스는 당시 미팅 상황을 설명했다. "이기택이 그의 팀에 성사시키자고 말해서 우리는 계약이 이뤄졌다고 생각했어요. 그런데 열 명이 넘는 중간 관리자가 있는 그의 팀을 만났는데 그중 누군가가 물어보더군요. '누가 운영 체제를 만드나요?' 우리가 '스웨트랜드라는 개발자입니다'라고 말하자 그들이 웃더군요. 삼성에서는 300명이 삼성 자체 운영 체제를 만들고 있다면서요."</p>
</blockquote>
<p>Android가 시장에서 성공했을 때 앤디 루빈이 삼성도 찾아왔다던 일화가 뉴스로 많이 돌아다녔고 삼성이 이 중요한 프로젝트를 놓쳐서 아쉽다는 얘기가 많았다. 그 이야기가 책에도 나오는데 루빈이 투자받기 위해서 한창 돌아다닐 때이다. 개인적으로는 삼성이 안드로이드를 놓친 게 별로 아쉽지 않다고 생각하는 편이고 삼성이 안드로이드에 투자하거나 인수했더라면 지금의 안드로이드의 위치에 못갔을 꺼라고 생각하는 편이다. 위 일화에서도 당시 삼성의 시선을 보여주고 있다고 생각한다.</p>
<blockquote>
<p>"우리는 시연 프로그램을 보여 주었고 앤디는 발표 자료를 넘겼죠. 루빈이 수익 창출 부분을 이야기하자 래리가 발표를 끊고 이야기했던 게 기억나요. '그건 걱정 말아요. 나는 여러분이 최고의 휴대 전화를 만들기를 바랍니다. 나머지는 나중에 궁리해 보죠."</p>
</blockquote>
<p>위는 안드로이드가 구글에 인수된 뒤에 회사에서 첫 발표를 할 때 얘기다. 지금은 안드로이드로 모바일 시장을 차지한 가치의 중요성이 당연하게 느껴지지만, 당시에는 어찌될 지 예상하기 어려운 상태에서 <strong>안드로이드라는 프로젝트 혹은 팀을 다루는 구글의 태도가 많은 것을 보여준다고 생각한다</strong>.<br />
<br></p>
<h1>2부 플랫폼 구축</h1>
<blockquote>
<p>"휴대 전화 제조사가 다른 누군가의 플랫폼에 흥미를 느끼게 하기는 정말 어려웠어요. 그들은 자기 회사만을 위한 소프트웨어를 만들었고 휴대 전화가 PC와 똑같아지는 걸 무서워했어요. PC 세계는 플랫폼을 소유한 소프트웨어 판매사가 하드웨어를 일상 용품으로 만들어 버리는 곳이었으니까요."</p>
</blockquote>
<blockquote>
<p>아이폰 출시를 계기로 운영 체제가 필요해진 회사들은 자신들이 만들 수 있는 것보다 더 복잡한 뭔가를 찾고 있었고 그에 따라 좀 더 기꺼이 안드로이드와 함께 일하려고 했다.</p>
</blockquote>
<p>당시 휴대폰 시장을 다시금 생각나게 했다. 우리나라는 좀 더 통신사가 힘을 가지고 있지만 휴대폰 제조사들은 어느 정도 경직되어 있었고 그런 요구사항을 받아들이느라고 힘들어했던 일화들도 책에 나오는데 아이폰은 아이폰 자체로도 대단했지만, 아이폰의 등장은 안드로이드에게도 중요한 기회가 되었다는 점이 재미있다.</p>
<blockquote>
<p>'다이앤, 구글로 와요. 여기 정말 멋진 일들이 있어요.' 그들이 내게 넌지시 말했죠. '플랫폼이고 오픈 소스에요.' 돈 걱정할 필요가 없는 구글에서 오픈 소스 모바일 플랫폼 일을 한다니? 어떻게 싫다고 말하겠어요? 완벽했죠.</p>
</blockquote>
<blockquote>
<p>팀은 액티비티 접근 방식을 받아들이기로 결정했다. 해밀턴이 어떤 식으로 그렇게 됐는지 설명했다. "다이앤에게는 그녀가 원하는 비전이 있었고 그냥 앉아서 타이핑했죠. 그렇게 된 거에요. 그녀가 생산적이고 일을 마무리 했기 때문이죠." 이 결정 모델은 오노라토가 구현한 초기 뷰 시스템 같은 다른 부분에서도 마찬가지였다. 팀은 일을 어떻게 해야 하는지에 관해 회의를 하거나 위원회를 열거나 논쟁을 벌이는 데 시간을 많이 쓰지 않았다. 그래서 누군가가 해법을 단숨에 만들어 내면 일이 거기서부터 진행됐다.</p>
</blockquote>
<p>나도 좋아하는 접근 방법이다. (현실에서는 말처럼 쉽진 않지만) 일을 하는 사람이 결정하게 되는 구조였고 안드로이드 팀에서는 잘 동작했다.</p>
<blockquote>
<p>시장에 안드로이드 기기가 몇 가지밖에 없을 때도 팀은 장기적인 게임을 생각했고 잠재적으로 거대하고 다양한 사용자와 기기 생태계를 예상했다.</p>
</blockquote>
<blockquote>
<p>리눅스가 이미 어느 정도 발전해 있었지만 내게는 이게 더 나은 기회였는데 특정 제품에 초점을 맞추고 있어서였어요. 안드로이드는 운영 체제 명세 또는 구상이었을 뿐 아니라 제품 개발이기도 했어요. 분명한 도전이었고 성공하지 못할 수도 있었지만 우리는 시도했죠. 비전을 실현하는 가장 좋은 방법은 그 일을 돕는 것이었습니다.</p>
</blockquote>
<p>지금은 당연한 안드로이드의 결과를 당시에도 꽤 꿈꾸고 있었고 그래서 더 성공할 수 있었던 거 같다.</p>
<blockquote>
<p>로봇을 자유롭게 사용하게 한 건 획기적이었다. 이리나는 좀 더 전통적인 브랜딩 접근 방식에 대해 이야기했다. "독자성이 브랜드 가이드라인에 도입되고 정말 엄청난 제약이 따라붙죠. '로고 주위에 빈 공간이 있어야 해요. 색상은 이렇고요. ...' 로고는 신성시되죠. 그런데 이 로고가 전통적인 관념을 완전히 산산조각 냈어요." 로고의 이러한 측면은 안드로이드 팀 자체에서 나온 게 아니라 안드로이드 오픈 소스화에 대응해 이리나의 브랜딩 그룹에서 나온 것이다. "이 방식은 그 문제를 해결하려는 우리의 창의적인 아이디어였어요. 디자이너로서 업무는 제품이 무엇을 상징하는지 소통하는 것이에요. 그건 당시로서는 획기적이고 창의적인 아이디어였어요. 오픈 소스는 우리에게 제약이 아니라 해법이었고 이 로고 작업 중에서 가장 잘한 일이라고 생각해요."</p>
</blockquote>
<p>여기서 로봇은 안드로이드 로고를 말한다. 로고를 자유롭게 변형할 수 있게 했다는데(사실 몰랐지만...) 이 부분도 안드로이드가 다른 팀과 다르게 일했던 것을 느낄 수 있었다.</p>
<blockquote>
<p>티모바일의 동의를 얻기 위해 안드로이드 팀은 두 가지 일을 해야 했다. 첫째는 티모바일 네트워크가 안전할 것이라고 안심시키는 일이었고, 둘째는 안드로이드 마켓과 함께 티모바일에서 관리하는 앱 스토어를 운영할 수 있게 하는 일이었다.</p>
</blockquote>
<blockquote>
<p>울타리 친 정원은 무너졌다. 그리고 안드로이드와 티모바일은 구글 플랫폼에서 애플리케이션 스토어를 운영하기로 합의했다. 이제 스토어를 제대로 만들어야 했다.</p>
</blockquote>
<blockquote>
<p>"우리는 팜소스에서 다른 사람들이 우리 플랫폼을 사용하게 하려고 애썼는데, 어려웠던 점 한 가지는 마이크로소프트가 PC 세계에서 했던 것과 똑같은 일을 누군가가 모바일 세상에서 하지 않을지 사람들이 몹시 두려워 한 것이었어요."</p>
</blockquote>
<p>아이폰이 흔든 시장에 나온 안드로이드는 빠르게(?) 스마트폰 플랫폼으로 자리 잡기 시작한다. 아마 그 이전에는 통신사와 하기 어려웠던 협상도 가능해졌다.</p>
<blockquote>
<p>다른 회사들은 사람들이 한 일을 보고 채용하고 그 일을 더 하라고 한다. 구글은 어떤 사람인지 보고 채용하고 그들에게 필요한 일은 뭐든 하라고 한다. 그 사람들이 과거에 한 일은 그들이 무엇을 할 수 있는지 보여 주는 훌륭한 예이지만, 구글이 보기에는 그들이 할 수 있는 일로 그들을 제한할 필요는 없었다. 그렇게 해서 뛰어난 글꼴 렌더링 전문가가 구글에서 에뮬레이터를 개발하게 됐다.</p>
</blockquote>
<p>이건 좋은 거 같기도 하고 아닌 거 같기도 하고... ㅎㅎ</p>
<blockquote>
<p>안드로이드의 '결과적인 오픈 소스'[^1] 모델 그 자체에 있다. 외부 개발자는 버그를 발견해서 고쳤을 때 그 버그가 그사이에 내부 또는 향후 버전 코드에서 고쳐졌는지, 심지어 자신의 시간 전부를 들여 작업한 코드가 존재 하기는 하는지 알 방법이 없다. 코드는 향수 요구 사항이나 변경 사항에 따라 옮겨지거나 재작성되는 경향이 있다.<br />
[^1]: 결과적인 오픈 소스는 당시 안드로이드 오픈 소스 모델에 내가 붙인 용어다. 안드로이드는 오픈 소스가 됐지만 오픈 소스로 개발되지는 않았다. 그보다는 팀이 몇 달간 내부적으로 개발하고 나서 코드를 공개했다.</p>
</blockquote>
<blockquote>
<p>"나는 오픈 소스 소프트웨어에 대한 확고한 믿음이 있습니다. 오픈 소스는 전혀 상상하지 못했던 걸 만들 힘과 스스로 뭔가를 만들어 볼 수 있는 자원을 사람들에게 주기 때문이죠. 안드로이드가 나왔을 당시 상황을 보면 OEM은 iOS 라이선스를 받을 수 없었습니다. 그리고 마이크로소프트는 획일적인 경험을 제공했어요. 그와 대조적으로 안드로이드는 OEM이 매장 진열대에서 스스로를 특화할 수 있도록 빠르고 손쉽게 기능을 만들 수 있는 기회를 주었어요."</p>
</blockquote>
<blockquote>
<p>"무언가를 오픈 소스로 만드는 게 중요하다고 생각하지 않아요. 오픈 소스로 만들지 않고도 공짜로 줄 수 있죠. 나는 오픈 소스 옹호자에요. 나는 우리가 하고 있는 것보다 더 오픈 소스를 해야 한다고 생각해요. 그런데 안드로이드의 강력함이 오픈소스라는 점에 있다고 단정할 수는 없을 것 같아요. 안드로이드를 오픈 소스로 만들지 않고 공짜로 제공했더라고 성공했을 거예요."</p>
</blockquote>
<p>오픈 소스로서의 안드로이드도 많이 나오지만 안드로이드는 "결과적인 오픈 소스"라고 하고 있다. 지금은 정확히 모르지만 한때 외부 기여를 안받기 때문에 구글의 안드로이드식 오픈소스를 비판하는 얘기도 많이 있었다. 그럼에도 오픈소스로 공개된 안드로이드는 충분히 효과를 본 것 같다.</p>
<blockquote>
<p>"그게 OR드로이드가 아니라 AND로이드라고 부른 이유에요. 두 가지 대안 중에서 결정해야 한다면 우리는 늘 둘 다 골랐거든요."<br />
- 팀에서 누군가가 한 말</p>
</blockquote>
<blockquote>
<p>초기에(그리고 이후 수년가) 팀에서 계속된 논쟁 한 가지는 그들이 만들고 있는 게 제품인가 아니면 플랫폼인가 하는 것이었다. 다시 말하면 휴대 전화(제품)를 만들고 있는가 아니면 다양한 제조사가 만드는 여러 가지 휴대 전화에서 현재와 미래에 사용할 운영 체제(플랫폼)를 개발하고 있는가 하는 토론이었다.</p>
</blockquote>
<blockquote>
<p>팀에서 벌어진 제품 대 플랫폼 논쟁은 사람들이 출신 회사에 따라 의견이 갈렸다. 바로 데인저 출신 대 비-팜소스, 웹티비-마이크로소프트 출신으로 나뉘었다. 데인저 출신 사람들은 단순한 해법을 선호했고 제품에 좀 더 중점을 두었다. 비-팜소스와 웹티비-마이크로소프트 출신 사람들은 좀 더 플랫폼적인 사고방식을 지녔고 안드로이드에서도 그러한 접근 방식을 선호했다.</p>
</blockquote>
<blockquote>
<p>브라이언 스웨트랜드는 양쪽을 다 알았는데 비와 데인저에서 일했기 때문이다. "둘 다 필요합니다. 내가 비에서 얻은 교훈이에요. 비는 당시 틀에 박혀 있었어요. 그래서 플랫폼이 되는 데 집중했죠. 제대로 된 앱이 없고 순수한 플랫폼만 만든다면 악순환을 끊지 못해요. 사람들이 필요로 하는 걸 만들지 않은 거고요."</p>
</blockquote>
<p>안드로이드처럼 대단한 프로젝트가 아니라고 하더라도 (내 취향일 수도 있지만) 비슷한 결정을 하게 되는 경우는 많은 것 같다. 잘못하면 둘 다 고른다는 것은 아무것도 안 고른 것과 다름없기도 해서 현실에선 쉽지 않긴 하다. 안드로이드 내에서도 출신에 따라서 선호가 달라진다는 것도 재미있었는데 성공 혹은 실패했던 경험에 따라 달라지는 걸로 보인다.<br />
<br></p>
<h1>4부 출시</h1>
<blockquote>
<p>당시 안드로이드 팀의 어떤 엔지니어가 한 말이 다양한 곳에서 인용됐다. "소비자로서 나는 반해 버렸어요. 당장 하나 갖고 싶네요. 그러나 구글 엔지니어로서 '우리는 처음부터 다시 시작해야만 해'라고 생각했어요."<br />
이 발언은 아이폰 때문에 안드로이드의 모든 게 바뀌고 개발 계획이 재작성됐음을 암시한다.</p>
</blockquote>
<blockquote>
<p>아이폰 발표는 모든 휴대 기기 제조사에 영향을 끼쳤는데 전체 모바일 산업에 파문을 일으켰으며 두려움을 야기함으로써 결국 다소 역설적으로 안드로이드가 시장에서 자리 잡는 주요한 이유가 됐다.</p>
</blockquote>
<p>아이폰은 발표 자체도 충격적이었지만(사실 난 그때 그렇게까지 아이폰의 위력을 알아채진 못했다.) 앞에서도 얘기했듯이 확실히 안드로이드에도 긍정적인 영향을 주었다. 마치 아이폰이 나오고 안드로이드가 만들어진 것처럼 보이지만 실제로는 비슷한 시기에 비슷한 목표를 가지고 두 프로젝트가 움직인 것이고 잘 모르는 성공하지 못한 프로젝트도 많이 있을거라고 생각한다. 당시 추억이 자꾸 생각나서 책을 보는 내내 재미가 있었는데 아이폰 이전의 PDA나 포켓PC 등은 대부분 스타일러스라고 부르는 얇은 팬을 통해서 화면을 터치했다. 나도 거기에 익숙했고 당시 대부분 기기의 화면 터치 성능은 좋지 않았기에(보통 손톱으로 터치했다 ㅋㅋ) 스티브 잡스가 아이폰을 시연하면서 QWERTY 키보드를 손가락으로 터치하는 걸 보고 놀랐다기보다는 말도 안 된다고 저렇게 동작할 리가 없다고 생각했었다.(안목이 없었지...)<br />
<br></p>
<h1>5부 안드로이드가 해낸 이유</h1>
<blockquote>
<p>우리는 적당한 때에 적당한 위치에 있었어요.</p>
</blockquote>
<p>수많은 안드로이드 팀이 비슷하게 얘기한다. 우리 팀이 엄청나게 잘했다고 얘기하는 게 아니라(실제로 잘했지만) 수많은 사람이 비슷하게 위처럼 얘기한다는 게 더 좋았다. 현실에선 한 명의 영웅적인 활동으로 되는 일도 많지 않고 미래를 다 예측하고 준비되어 있었다고 말하기 어려운 거니까...</p>
<p><strong><a href="https://blog.outsider.ne.kr/1621?commentInput=true#entry1621WriteComment">댓글 쓰기</a></strong></p>나는 AMP를 좋아하지 않는다.Outsiderhttps://blog.outsider.ne.kr/12852017-04-22T17:02:17+09:002017-04-22T09:30:00+09:00<p>AMP가 처음 등장했을 때 꽤 관심이 있었고 그동안 모바일 최적화에서 느끼던 어려움을 해결해 줄 것으로 생각했지만, 자세한 내용을 보면 볼수록 내가 생각하던 웹의 방향과는 달라서 지금은 전체적인 추세만 보고 있을 뿐 내가 직접 구현할 것 같지는 않다. 정말 큰 흐름이 된다면 거스를 수는 없겠지만 내가 먼저 구현해서 그 흐름에 참여할 생각은 별로 없다.<br />
<br></p>
<h1>AMP란 무엇인가?</h1>
<p><a href="https://www.ampproject.org/ko">AMP</a>는 Google에서 시작한 프로젝트로 Accelerated Mobile Pages의 약자이다. 즉, 모바일전용 빠른 웹페이지를 의미한다. 요즘은 하나의 웹사이트를 만들고 미디어쿼리로 큰 해상도부터 작은 해상도까지 모두 대응하고 있다. 하나의 문서를 가지고 다양한 클라이언트 환경에 맞추어서 보여주는 이 방향은 맞는다고 생각하지만, 현실에서 이를 제대로 구현하기는 쉽지 않다. 미디어쿼리로 구현한 경우 어쩔 수 없이 성능이나 기능에서 손해를 볼 수밖에 없는데 몇 가지 예를 들면 <a href="http://caniuse.com/#search=srcset">srcset을 아직 현실에서 사용할 수 없는 상황</a>에서 이미지 등을 상황에 맞게 사용하려면 이미지를 CSS에서 미디어쿼리로 지정해야 하는데 이렇게 하면 검색엔진에서는 이미지가 제대로 수집되지 않는다. 그리고 자바스크립트를 상황에 따라 동적으로 로딩하는 수준으로 구현하는 게 아니라면 데스크톱에서만 필요한 스크립트를 모바일에서도 다운받아야 하고 그 반대의 경우가 생기기도 한다. 이는 복잡한 사이트일수록 모바일에서 성능 저하가 생길 수밖에 없게 된다.</p>
<p>이런 문제를 해결하려고 AMP가 나왔다고 생각하는데 모바일에서 빠른 속도를 보장하기 위해 AMP는 몇 가지 제약사항을 가지고 있다.</p>
<ul>
<li>CSS는 모두 인라인으로 지정해야 하며 50KB를 넘을 수 없다.</li>
<li>스크립트는 <code><script async src="https://cdn.ampproject.org/v0.js"></script></code>처럼 AMP에서 제공하는 스크립트 외에는 외부 JavaScript를 허용하지 않는다.</li>
<li>기본 HTML 태그 대신 <code><amp-img></code>, <code><amp-anim></code>, <code><amp-video></code>같은 <a href="https://www.ampproject.org/ko/docs/reference/components">AMP 전용 태그</a>를 사용한다.</li>
<li>모든 리소스는 크기를 지정해서 리소스를 다운로드 한 후에 브라우저가 레이아웃을 다시 그리지 않도록 한다.</li>
</ul>
<p>이 외에도 브라우저 속도에 영향을 줄 수 있는 요소를 차단하는 다양한 제약사항이 있다. 이를 통해서 아주 빠른 모바일 전용 페이지를 제공하고 있다. AMP에 대해서는 검색하면 자세히 설명하는 다양한 글을 볼 수 있다.</p>
<p>웹사이트가 모바일에서 느리다는 것은 모두가 겪는 문제인데 각 서비스에서는 이를 해결하려는 움직임을 보였다. Apple에서는 <a href="https://www.apple.com/news/">News</a>를 공개했고 Facebook은 <a href="https://instantarticles.fb.com/">Instant Article</a>을 공개했다. Apple과 Facebook이 모바일에서 빠른 속도를 보여줄 수 있는 환경을 만들자 여기에 위기를 느낀 구글이 AMP를 만들었다고 생각하고 있다.(이런 배경을 설명하진 않으므로 이건 내 추정일 뿐이다.) News와 Instant Article이 완전히 자사 플랫폼 전용임과 비교하면 AMP는 좀 더 범용적인 포맷을 만들어서 반격을 꾀했다고 생각하고 현재까지는 꽤 괜찮은 분위기를 만들고 있다고 본다.<br />
<br></p>
<h1>하지만 나는 AMP가 잘못된 방향이라고 생각한다.</h1>
<p>이렇게 생각하는 이유가 몇 가지 있는데 AMP는 그동안 웹이 발전해 온 방향과는 다른 방향이라고 느끼기 때문이다. 웹이 계속 발전해도 나는 웹은 그 근간이 문서라는 개념에 무게를 크게 두고 있고 이게 웹의 핵심이라고 생각하기에 이를 거스르는 느낌이 들면 거부감이 드는 편이긴 하다.<br />
<br></p>
<h2>AMP는 모바일 전용 페이지 시대로의 회귀이다.</h2>
<p>스마트폰이 처음 등장했을 때 웹에는 모바일 전용 페이지라는 개념이 있었다. outsider.ne.kr이 웹사이트면 모바일은 m.outsider.ne.kr 같은 식으로 만들었다. 이는 서버에서 User Agent를 확인해서 모바일 브라우저라고 판단되면 모바일 전용 페이지로 리다이렉트 시키는 방식으로 동작했고 이 페이지는 작은 해상도에서 최적화된 레이아웃으로 구성된 웹페이지를 제공했고 하단에는 보통 "PC 버전 보기" 같은 버튼이 있어서 둘 사이를 오갈 수 있도록 구현했다.</p>
<p>이 모바일 전용 페이지는 현재 국내에도 많이 남아있지만 각 모바일 페이지가 상당히 형편없게 만들어진 것과 상관없이 이는 하나의 페이지가 두 가지 주소를 가지고 있다는 문제를 가지고 있었다. 이는 <strong>웹 문서의 퍼머링크라는 개념과 맞지 않았고(요즘은 이런 용어를 잘 안 쓰지만) 결국 2개의 페이지가 존재하는 것과 다름없게 되었다.</strong></p>
<p>그리고 <strong>모바일 페이지가 잘못된 방향이라고 내가 생각하는 이유 중 하나는 모바일과 데스크톱의 경계가 모호해졌기 때문이다.</strong> 데스크톱과 모바일은 얼핏 보면 명확한 구분 같지만 모바일 디바이스가 점점 발전하면서 이 경계는 무너져버렸다. 예를 들어 iPad Pro는 1024x1366의 해상도를 가지고 있다. 그러면 여기서 iPad Pro는 모바일로 구분해야 하는가 데스크톱으로 구분해야 하는가? 이는 쉽지 않은 문제다. 만약 1280을 기준으로 모바일과 데스크톱을 나눈다고 하더라도 1280 해상도가 안되는 노트북도 많이 존재하고 iPad Pro같은 경우 가로로 보면 폭이 1366이 되어 버린다. 같은 장비가 세로로 보냐 가로로 보냐에 따라 모바일이냐 데스크톱이냐를 다르게 구분할 수는 없다. 이런 문제는 모바일 전용 페이지로 해결할 수 있는 문제가 아니라 미디어쿼리로 각 상황에 맞게 모든 픽셀에 대응할 수 있는 게 더 옮은 방향이라고 생각한다.(아직 부족한 점이 있다고 하더라도...)</p>
<p>다시 AMP로 돌아가 보자.</p>
<p><a href="http://www.theverge.com/2017/4/14/15303338/apple-autonomous-vehicle-testing-permit-california">Apple just received a permit to test self-driving cars in California</a>라는 The Verge의 기사를 보자. 이 기사의 주소는 <a href="http://www.theverge.com/2017/4/14/15303338/apple-autonomous-vehicle-testing-permit-california">http://www.theverge.com/2017/4/14/15303338/apple-autonomous-vehicle-testing-permit-california</a>이고 이 페이지는 큰 해상도에서 보면 다음과 같은 디자인으로 되어 있고 당연히 모바일에서도 잘 볼 수 있도록 반응형 디자인으로 만들어져 있다.</p>
<p style="text-align: center;"><img src="//blog.outsider.ne.kr/attach/1/8329990877.jpg" width="750" height="477" alt="The Verge의 뉴스 기사" title="" /></p>
<p>이 페이지의 소스를 보면 다음과 같은 HTML 태그가 존재한다.</p>
<pre class="line-numbers"><code class="language-html"><link rel="amphtml" href="http://www.theverge.com/platform/amp/2017/4/14/15303338/apple-autonomous-vehicle-testing-permit-california">
</code></pre>
<p>이 태그가 이 페이지의 AMP 페이지 주소를 알려주는 역할을 하고 그 주소는 <a href="http://www.theverge.com/platform/amp/2017/4/14/15303338/apple-autonomous-vehicle-testing-permit-california">http://www.theverge.com/platform/amp/2017/4/14/15303338/apple-autonomous-vehicle-testing-permit-california</a>가 되고 이는 큰 해상도에서 접속해 들어가더라도 다음과 같이 모바일 전용 레이아웃으로 보이게 된다.</p>
<p style="text-align: center;"><img src="//blog.outsider.ne.kr/attach/1/8470806628.jpg" width="750" height="644" alt="The Verge의 뉴스 기사의 AMP 페이지" title="" /></p>
<p>나는 이 구조가 앞에서 본 모바일 전용 페이지와 별로 달라 보이지 않는다. 서버에서 자동 리다이렉트를 안 해준다는 것과 서로 간에 가시적인 이동 버튼이 없는 것 말고는 나한테는 똑같아 보인다. 이 AMP 구조가 모바일에 최적화 사이트이므로 좋은 방식이라면 m.도메인으로 시작하는 모바일 전용 페이지도 괜찮은 접근이어야 한다. 물론 AMP가 여러 방향에서 더 좋은 기술적인 요소를 가진 것은 맞지만 큰 흐름의 방향은 거의 비슷하다고 본다.<br />
<br></p>
<h2>AMP는 검색엔진 중심이다.</h2>
<p>위에서 간단히 AMP의 구조를 설명했지만 실제로 사용자들이 이용하는 방식을 살펴보자. AMP가 위에서 보았듯이 <code><link></code> 태그로 표시되어 있고 UI에 버튼이 없으면 사용자는 어떻게 AMP 페이지를 이용하는가? 구글에서 검색하면 AMP를 지원하는 웹페이지 즉, 위처럼 <code><link rel="amphtml" href=""></code>를 제공하는 웹페이지는 다음과 같이 AMP 페이지라고 보여준다.</p>
<p style="text-align: center;"><img src="//blog.outsider.ne.kr/attach/1/3677289634.gif" width="422" height="750" alt="구글 검색에 표시된 AMP 페이지" title="" /></p>
<p>이 페이지를 클릭하면 <code>https://www.google.co.kr/amp/www.theverge.com/platform/amp/2017/4/14/15303338/apple-autonomous-vehicle-testing-permit-california</code>같은 주소로 접속이 된다. 이 주소는 스마트폰 등에서 열면 아래와 같이 열린다.</p>
<p style="text-align: center;"><img src="//blog.outsider.ne.kr/attach/1/1597279244.gif" width="422" height="750" alt="구글에서 보여주는 AMP 페이지" title="" /></p>
<p>좀 더 설명을 하면 다른 환경에서 접속하면 원래의 주소인 <a href="http://www.theverge.com/2017/4/14/15303338/apple-autonomous-vehicle-testing-permit-calif">http://www.theverge.com/2017/4/14/15303338/apple-autonomous-vehicle-testing-permit-calif</a>로 리다이렉트된다. 기술적으로 설명하면 AMP 페이지에는 <code><link rel="canonical" href="http://www.theverge.com/2017/4/14/15303338/apple-autonomous-vehicle-testing-permit-california"></code>처럼 원본 페이지에 대한 주소 정보를 알려주고 있고 기술적으로 말하면 크롤러가 이 모바일 페이지에 오게 되면 canonical 주소를 찾아가므로 실제 크롤링을 원본 문서만 크롤링 된다.</p>
<p>다시 위의 구글에서 접속한 AMP 페이지로 돌아가 보자. 이 페이지는 주소에서 볼 수 있듯이 google의 사이트이다. 구글에서 AMP 전용 사이트를 가지고 있고 뒤의 주소를 이용해서 아이프레임으로 해당 페이지를 AMP로 보여주고 있다. 상단에 <code>www.theverge.com</code>이라고 표시된 헤더 부분은 구글의 사이트이고 그 아래 <code><iframe></code>으로 AMP 페이지를 보여주는 방식을 취하고 있다. 이렇게 하는 경우 해당 문서에 대한 URL(여기서는 the verge의 기사) 대신 구글 주소가 주소창에 표시되므로 구글에서는 이를 조금이라도 완화하기 위해 상단 헤더에서 원본 주소를 복사하고 AMP에 대한 정보를 얻을 수 있는 버튼을 제공하고 있다.</p>
<p>그리고 AMP를 서비스해서 테스트해보진 않았지만 내가 아는 지식 선에서는 이 AMP 페이지를 더 빠르게 제공하려고 <a href="https://developers.google.com/amp/cache/">Google에서 AMP 캐시</a>를 제공하고 있다. AMP 페이지를 접속할 때마다 해당 서버에서 가져오는 것이 아니라 구글이 제공하는 AMP 캐시에 저장해 뒀다가 사용자에게 빠르게 제공하는 것이다. 물론 구글 캐시서버의 성능과 인프라는 신뢰할만하니 사용자는 빠르게 페이지를 볼 수 있지만, 사용자는 해당 서버에 접속하지 않는다.(물론 콘텐츠 내에 광고로 수익을 내거나 로깅을 하려는 방법 등은 존재한다)</p>
<p>나는 이 구조가 아주 이상하게 느껴진다. 내가 알던 모든 웹 기술은 해당 서비스 프로바이더 중심이었고 웹브라우저 기반이었다. 계속 예시로 사용한 The Verge를 계속 얘기하면 사용자가 어떤 페이지를 보고 어떻게 보여줄지는 The Verge 사이트 더 정확히는 The Verge 서버에 HTTP 요청이 왔을 때 The Verge가 결정한다. 이를 동적으로 처리해서 보여주던 정적페이지로 캐시 해서 CDN으로 배포하던 어쨌든 The Verge의 서버가 결정하고 표준에 맞춰서 구현된 웹브라우저가 그것에 맞게 처리해준다. 처음 AMP를 보여줬을 때 나는 당연히 여태 하던 이 개념 내에서 AMP를 이해하려고 했고 수많은 문서를 보았지만 내 사이트에 사용자가 접속했을 때 어떻게 빠른 AMP 페이지를 이용할 수 있게 하는지 이해하지 못했다. 그래서 <a href="http://stackoverflow.com/questions/35502996/how-do-i-support-amp-html-and-desktop-html-simultaneously">Stackoverflow에 질문</a>도 올렸다가 AMP가 동작하는 방식을 이해하게 되었다.</p>
<p>AMP는 기존에 우리가 알고 있던 웹사이트가 동작하는 방식대로 돌아가는 게 아니라 검색엔진 중심으로 동작한다. 내 블로그가 AMP를 제공한다고 하면 사용자가 AMP를 이용하려면 구글 검색을 통해서 들어와야 한다. 내 블로그에 접속해서는 AMP를 이용할 수 없다. AMP가 보급되면서 구글뿐 아니라 다른 검색엔진에도 AMP 지원이 확대되고 있고 더 발전하면 페이스북이나 트위터 같은 대형서비스에서도 AMP를 지원할 수도 있지만 내 웹사이트에서 내가 통제권을 가지고 있지 않다는 것은 여전히 같다. A 사이트가 내 AMP를 이상하게 제공한다면 그냥 이상하게 제공되는 거다.</p>
<p>이건 내가 여태까지 이해하고 공부하던 웹이 나아가던 방향과는 완전히 다르고 극단적으로 말하면 페이스북 내에 페이스북 페이지를 만드는 것과 크게 다를 바가 없다고 느껴진다. 구글은 그나마 이런 방향 내에서도 최대한 웹의 방향을 적게 헤치려고 노력을 하고 있지만 다른 서비스도 똑같이 할 거라는 보장은 전혀 없다. 나는 이게 완전히 잘못된 방향이라고 생각한다.<br />
<br></p>
<h2>AMP는 기술적으로 새로울 것이 전혀 없다.</h2>
<p>물론 기술이란 것은 항상 새롭고 혁신적인 것만 만들어야 하는 것은 아니다. 이미 존재하는 기술을 새롭게 연동하거나 새로운 개념을 부여하는 것도 충분히 혁신적인 일이다. 그렇긴 하지만 앞에서 설명한 방향적인 문제를 포함해서 생각할 때 AMP가 제공하는 기술적인 혁신은 전혀 없다. AMP는 모바일에서 웹페이지를 더 빠르게 보여주겠다는 것이 목표이다. 내가 AMP 제약조건에 맞추어서 간단한 웹페이지를 만들어서 CDN으로 제공하면 AMP보다 느릴까? 물론 구글 캐시 서버나 CDN보다는 느릴 수도 있지만 비싼 CDN을 쓰지 못하더라도 요즘은 저렴한 CloudFront나 CloudFlare 등 저렴한 CDN을 쓸 방법이 많이 있다. AMP에서 다수의 대단한 사람들이 좋은 라이브러리를 빠르게 만들고 잘 모르는 개발자라도 실수하지 않게 좋은 제약사항을 제공한 것은 이해하지만, 오픈소스로 누군가 yet-another-amp.js같은 라이브러리를 만들어서 가져다 쓸 수 있게 한다면 다를 건 하나도 없다.</p>
<p>기존에 모바일에서 웹사이트가 느렸던 이유는 기술적으로 모바일에서 빠른 전용 웹사이트를 만들 수 없었기 때문이 아니다. 현재 웹 기술로 데스크톱 웹을 제공하면서 모바일에도 최적화할 기반 기술이 안 만들어졌기 때문이다. 맨 앞에서 얘기한 대로 이런 방향이면 나로서는 다시 m.도메인 사이트를 모바일 전용으로 만들어서 사용자에게 빠르게 제공하는 게 훨씬 더 낫다고 본다.</p>
<p>그리고 대부분 웹사이트가 점점 느려지는 이유는 서비스마다 다양한 요구사항이 있기 때문이다. 모든 사이트가 뉴스 사이트라서 간단한 텍스트만 제공하면 끝나는 것이 아니다. 콘텐츠 사이트라고 하더라도 사용자 온보딩을 위해서 여러 요소를 넣어야 하고 광고도 그냥 보여주는 게 아니라 다양한 실험을 해야 하고 애플리케이션 적이 고급 요소도 제공해야 한다. 실제로 이런 요구사항을 맞추기 위해서 AMP에도 새로운 컴포넌트가 계속 추가되고 있다. 이게 과연 모두의 요구사항을 맞출정도로 다양한 컴포넌트가 갖춰진다면 여전히 지금처럼 빠를까? 나는 AMP도 결국 요구사항을 맞추기 위해서 점점 느려지거나 요구사항을 맞춰주지 못할 것이라고 본다. 물론 AMP는 뉴스사이트 같은 문서에 기반을 둔 웹사이트를 타게팅하고 있는 것은 확실하지만, 시간이 지나면서 이는 점점 흐려질 것으로 생각한다.<br />
<br></p>
<h1>결론</h1>
<p>구글은 AMP를 지원하면 구글 검색결과에 더 높은 중요도를 배정하면서 웹사이트 운영자에게 AMP는 달콤한 유혹이 되었다. AMP라는 요소만으로 검색 결과에 상위로 올라갈 정도로 검색 알고리즘이 간단하지는 않지만, 조금이라도 상위에 올리고 싶은 웹사이트 운영자들에게 AMP 지원은 할 수 있다면 안 할 이유가 없는 부분이다. 물론 난 이 검색 결과에 적용하는 방식은 기술의 제대로 된 검증 없이 구글이 점유율을 이용해서 기술을 강요했다는 거부감이 훨씬 더 크다.</p>
<p>난 <a href="https://developers.google.com/web/progressive-web-apps/">PWA</a>이 웹의 방향성에서는 훨씬 좋은 방향이라고 보고 있는 편인데 자연스럽게 AMP가 PWA와 같이 어울리면서(둘 다 구글이 주도하다 보니) 섞여 들어오는 게 더 싫기는 하다. 물론 내가 이렇게 생각한다고 AMP가 안된다는 것은 아니다. 보통은 오히려 내가 비관적으로 보는 기술이나 회사는 더 잘되는 경향이 있지만....</p>
<p><strong><a href="https://blog.outsider.ne.kr/1285?commentInput=true#entry1285WriteComment">댓글 쓰기</a></strong></p>프로토타이핑 도구 Framer와 Origami를 테스트 본 후Outsiderhttps://blog.outsider.ne.kr/10972014-11-19T19:12:02+09:002014-11-19T19:12:02+09:00<p>프로토타이핑 도구에 관심을 가진지는 꽤 오래됐다. 개인 프로젝트를 종종 하다 보니 웹이든 앱이든 모바일 사이트든 생각을 더 구체화하려면 프로토타이핑이 필요했고(머릿속으로만 생각하는 건 한계가 있어서) 실제로 만드는 건 시간도 걸리고 귀찮으니까 자연스럽게 프로토타이핑 도구를 찾게 되었다. 그냥 프로토타이핑이라고 하면 꽤 많은 부분이 포함되는데 스토리보드처럼 간단히 화면을 그리는 <a href="https://gomockingbird.com/">Mockingbird</a>, <a href="http://proto.io/">proto.io</a>도 써봤고 앱의 UI를 만들어 볼 수 있는 <a href="http://www.appcooker.com/">AppCooker</a>라는 iPad 앱도 한동안 꽤 잘 사용했었다.<br />
<br></p>
<h1>프로토타이핑 도구들</h1>
<p>보통 기획을 할 때 파워포인트를 사용해서 스토리보드(혹은 기획서)를 만드는데 여기에 프로토타이핑이라고 하면 여기에 약간 더 추가해서(어떤 형태로든) 동작하는 것을 의미한다고 본다. 애플리케이션 전체를 프로토타이핑할 수 있고 특정한 인터렉티브 요소나 애니메이션을 프로토타이핑해 볼 수도 있는데 웹이나 모바일 앱이 정적인 문서이던 시대를 지나서 점점 화려해지고 인터렉티브한 부분이 많이 들어감에 따라 기존의 파워포인트로 만들던 적정인 화면만으로는 기획의 의도를 정확하게 전달하기가 어려워져서 프로토타이핑에 대한 필요가 더욱 커졌다고 생각한다. 물론 이는 웹 2.0 이후(오랜만에 사용해 보는 말이군) 웹에서 Ajax가 보편화되면서 이미 많이 거론되었던 문제이지만 최근에는 모바일 앱이 많아지면서 더욱 자세하고 인터렉티브한 프로토타이핑이 필요해 졌다.</p>
<p>그래서 이전의 프로토타이핑 도구라고 하면 미리 UI 요소들이 있어서 파워포인트보다 쉽게 만들 수 있는 <a href="https://balsamiq.com/">Balsamiq</a> 등의 도구가 유명했지만, 이제는 화면의 메뉴나 버튼에 흐름은 연결할 수 있는 <a href="http://www.invisionapp.com/">Invision</a>, <a href="http://proto.io/">proto.io</a>, <a href="http://www.infragistics.com/">Infragistics</a> 등의 도구들도 많이 알려진 상태이다.(팀에서 Invision을 써봤는데 디자이너도 쉽게 화면의 흐름을 연결해서 앱 내에서 동작해 볼 수 있다. 물론 단순히 이미지를 특정 영역에 연결해서 동작 흐름을 보는 정도이다.)</p>
<p>하지만 이러한 도구들도 디자인 시안의 확인이나 앱의 흐름을 볼 수 있는 정도인데 모바일에서는 이러한 흐름뿐이 아니라 애니메이션 효과나 제스처같은 부분도 UX/UI에 큰 영향을 미치기 때문에 이런 부분까지 프로토타이핑해야 하는 중요성이 아주 커졌고 이에 따라 꽤 많은 서비스나 도구들이 등장했다. 개인적으로는 Photoshop에 확장 기능이 생겨서 서드파티가 이를 이용할 수 있게 되면서 많은 서비스나 도구들이 생겼다고 생각한다.<br />
<br></p>
<h1>프로토타이핑이 필요한 이유</h1>
<p>프로토타이핑은 말 그대로 앱을 실제로 만들어 보기 전에 미리 만들어 보는 것을 의미한다. <strong>미리 만들어 보는 이유는 실제 애플리케이션을 만드는 것에 많은 시간과 비용이 들기 때문에 애자일에서 개발 시 빠른 실패를 강조하듯 제품 제작에 큰 비용이 들기 전에 빨리 만들어 보고 선택을 하기 위함이다.</strong> 예를 들어 버튼 애니메이션이나 인터렉티브한 화면의 경우 세세한 애니메이션 효과가 UX에 많은 영향을 주기 때문에 미리 만들어보고 테스트를 해본 뒤 검증해서 결정된 내용을 개발하는 것이다.</p>
<p>그래서 프로토타이핑은 실제 앱 개발보다 훨씬 빠르게 만들 수 있어야 한다. 실제 개발보다 오래 걸린다면 그냥 iOS 앱이나 안드로이드 앱에서 직접 프로토타이핑해보는 게 낫고 그 특성상 여러 가지를 만들어 보고 결정해야 하므로 약간 빠른 정도가 아니라 상당히 빠르게 만들 수 있어야 한다. 그리고 실제 앱과 거의 유사하게 만들 수 있어야 하는데 완전히 같을 수야 없겠지만(그러면 이걸로 앱을 만들겠지) 거의 비슷한 느낌은 들 수 있어야 사전에 프로토타이핑하는 의미가 있고 실제 구현할 때 개발자와의 커뮤니케이션 오류를 줄일 수 있다.<br />
<br></p>
<h1>Framer와 Origami</h1>
<p>계속해서 다양한 도구들이 나오고 있지만 최근 모바일 앱 프로토타이핑 도구로 가장 대표적인 도구로는 <a href="http://framerjs.com/">Framer</a>와 <a href="https://facebook.github.io/origami/">Origami</a>가 있다. 둘 다 실제 네이티브 앱으로 만드는 것과 거의 비슷한 인터렉티브 UI를 프로토타이핑할 수 있고 상당히 공을 들인다면 실제 앱과 구별하기 어려운 정도의 퀄리티까지 만들 수 있을 것으로 보인다. 최근에 프로토타이핑을 해야 하는 필요성이 있어서 어떤 것을 사용할지를 정하기 전 둘 다 사용해 보고 있는데 이 글은 약간 사용해 본 첫인상을 정리하는 글이고 각 도구에 대한 사용방법은 나중에 기회가 되면 따로 소개하려고 한다. 둘 다 깊게 사용해 본 것은 아니므로 잘못 생각했거나 오해한 부분이 존재할 수도 있다.<br />
<br></p>
<h2>Framer</h2>
<p><img src="//blog.outsider.ne.kr/attach/1/3368072726.jpg" width="250" height="245" alt="Framer 로고" style="float: left; margin-right: 10px;" title="" /> <a href="http://framerjs.com/">Framer</a>는 모바일 앱을 프로토타이핑할 수 있는 도구로 웹 프레임워크인 <a href="https://github.com/koenbok/Framer">Framer.js</a>와 GUI 도구인 Framer Studio로 구분할 수 있다. Framer는 Photoshop과 <a href="http://bohemiancoding.com/">Sketch</a>에서 레이어를 그대로 가져올 수 있다는 점이 큰 특징 중 하나인데 Photoshop이나 Sketch에서 레이어를 가져오면 각 레이어 그룹명이 Framer 내에도 같은 이름을 가진 레이어가 되고 이를 <a href="http://coffeescript.org/">CoffeeScript</a>로 조작해서 동작을 추가하는 방식으로 프로토타입을 제작한다. 여기서 Framer.js는 모바일 웹 UI 프레임워크 정도로 생각하면 되는데 각 레이어를 조작하기 쉽도록 이벤트나 레이어 조작 API를 잘 구성해 놓아서 각 레이어를 특정 위치에 두거나 애니메이션 효과를 두는 등의 처리를 할 수 있다.(이른 API만 추상화되어 있을 뿐 웹사이트에서 DOM에 애니메이션을 추가하는 것과 같다.) Framer Studio는 Phtoshop이나 Sketch와 연동하고 프로토타입을 작성할 때 바로 결과를 볼 수 있는 GUI 도구로 유료로 구매를 해야 하는데(현재 79.99달러) 실제 프로토타입을 제작하려면 유료로 구매를 해야 한다.(없이도 할 수 있는지는 잘 모르겠다.)</p>
<p>최종적으로 만들어지는 결과물은 모바일 웹페이지이므로 서버를 실행해서(Framer Studio가 자동으로 서버를 실행한다) 데스크톱 내에서 보거나 폰에서 접속해서 사용해 볼 수 있다. 그리고 Framer.js는 오픈 소스이지만 실제 프로토타입을 제작하려면 Photoshop이나 Sketch와 연동해야 하므로 Framer Studio를 사야 한다.</p>
<p style="text-align: center;"><img src="//blog.outsider.ne.kr/attach/1/9939074820.jpg" width="750" height="566" alt="Framer Studio 화면" title="" /></p>
<p><br></p>
<ul>
<li><strong>CoffeeScript를 사용한다.</strong> 그래서 코드를 작성해서 모든 동작을 만들어야 한다. 코드로 작성하므로 웹에서 가능한 한 거의 모든 동작을 만들어 낼 수 있고 Framer가 강력한 프로토타이핑 도구인 이유 중에 하나라고 생각한다. 대신 프로토타이핑 도구는 비 개발자가 사용해야 하는 경우도 많은데 이럴 때는 이 부분이 큰 장벽이 될 수 있다. JavaScript 대신 코드가 좀 더 직관적인 CoffeeScript를 선택한 이유가 이 때문이라고 추측한다.</li>
<li><strong>Photoshop과 Sketch에서 레이어를 가져올 수 있다.</strong> 이 부분도 역시 Framer에서 강력한 장점 중 하나인데 디자인 도구에서 만들 레이어 그룹을 그대로 가져와서 레이어 그룹명까지 그대로 사용한다. 디자인을 수정할 경우에도 다시 가져오기를 지원하기 때문에 디자인을 변경하면서 프로토타입을 수정하기에 아주 편리하다.</li>
<li><strong>Framer.js는 꽤 잘 만들어져 있다.</strong> 아주 복잡한 UI까지는 만들어 보지 않았지만 각 레이어의 위치를 이동하고 애니메이션 효과를 주고 동작을 추가하기 위한 Framer.js 프레임워크는 잘 만들어져 있어서 직관적으로 코드를 작성할 수 있는 편이다.</li>
<li><strong>모바일 웹페이지이므로 어디서나 볼 수 있다.</strong> 기본적으로 Framer Studio를 사용하면 내부에서 서버를 실행해 주므로 주소만 공유하면 어떤 브라우저에서든 모바일 기기에서든 접근할 수 있다. 모바일 앱 프로토타이핑용이므로 모바일 기기에서 실제 사용하면서 반응을 볼 수 있는 것은 큰 장점이고 꼭 Framer Studio가 아니더라도 웹서버를 띄우면 접속하게 할 수 있으므로 접근성이 매우 좋다.</li>
<li><strong>라이브 리로딩을 지원한다.</strong> 이는 Framer Studio에 내장된 기능인데 코드를 수정할 때마다 새로 고침을 하지 않더라도 웹 브라우저나 모바일 기기에서 자동으로 수정한 결과물을 볼 수 있다. </li>
<li><strong>Framer Studio는 그다지 편하진 않다.</strong> Framer Studio는 왼쪽에 에디터 화면과 오른쪽의 미리 보기 화면으로 구성되어 있는데 라이브 리로딩으로 코드를 수정할 때마다 미리 보기에 바로 적용된다. 이 라이브 리로딩 간격은 설정에서 조정할 수 있지만, 간격이 짧으면 코딩을 하기 어려울 정도로 반응성이 좋지 않다. 그리고 에디터라고 하기에는 수준이 좀 낮아서 개발자라면 금세 답답함을 느끼고 다른 에디터에서 코드를 수정하고 싶어질 것이다.</li>
<li><strong>웹에 대한 지식이 필요하다.</strong> 개발할 때 CSS를 직접 수정하거나 자바스크립트로 각 요소를 수동으로 조작해야 하는 것은 아니지만, 결과적으로는 웹 페이지이므로 웹 개발에 대한 지식이 필요하다. 예를 들어 디버깅하기 위해서 개발자 도구를 열어서 본다거나 동작이 원하는 대로 되지 않을 때 왜 안되는지 추측해 본다거나 할 때 웹 프론트 개발경험이 필요하다고 생각된다. 이런 경험이 없이 Framer로 프로토타입을 만든다면 어떨지를 상상하는 것은 나로써는 어려운 일이지만 그런 지식 없이도 쉽게 할 수 있다고는 말 못하겠다.</li>
<li><strong>Framer의 버전업은 활발하다.</strong> Studio를 유료로 판매하기 때문인지 그동안은 계속해서 새로운 버전이 릴리즈되고 개발상황도 활발한 편이라 문제가 있어도 금세 해결되는 편이었고 성능도 계속 개선되고 있다. 사용하는 입장에서 이는 꽤 큰 장점이다.<br />
<br></li>
</ul>
<h1>Origami</h1>
<p><img src="//blog.outsider.ne.kr/attach/1/2845505794.jpg" width="250" height="239" alt="Origami 로고" style="float: left; margin-right: 10px;" title="" /> <a href="https://facebook.github.io/origami/">Origami</a>는 페이스북이 만든 프로토타이핑 도구로 <a href="http://radiofun.tumblr.com/post/75679444549">Paper 앱을 만들려고 만든 것으로 알려져</a> 있다. Apple의 비주얼 프로그래밍 언어인 <a href="http://en.wikipedia.org/wiki/Quartz_Composer">Quartz Composer</a>에 기반을 두고 있어서(그래서 Mac에서만 사용할 수 있다.) 코딩하지 않고 각 요소와 효과를 화면에 배치하고(Quartz Composer에서는 이를 Patch라고 부른다.) 이를 선으로 연결해서 동작하도록 만든다. 예를 들면 이미지를 추가하고 클릭 요소와 연결하고 클릭했을 때 어떤 효과(위치 이동이나 애니메이션 효과 등)를 줄지를 연결해 주면 그에 따라 동작하는 방식이다. 코드는 단 한 줄도 작성하지 않으므로 개발자가 아니더라도 만들 수 있으며 간단한 프로토타입 정도만 만들어봤지만, 웹에서 볼 수 있는 예제를 보면 앱에서 가능한 한 거의 모든 효과를 프로토타이핑할 수 있다.</p>
<p style="text-align: center;"><img src="//blog.outsider.ne.kr/attach/1/2683797558.jpg" width="750" height="371" alt="Origami 화면" title="" /></p>
<p><br></p>
<ul>
<li><strong>코드를 작성하지 않는다.</strong> 프로토타이핑 도구의 특성상 비 개발자가 사용할 가능성이 높으므로 이는 좋은 부분이라고 생각한다. 대신 어떻게 조합해야 원하는 효과를 얻는지 알기 위해서는 많은 노력이 필요할 것으로 보인다.(물론 코딩할 수 있다는 것은 사전에 이러한 노력이 포함된 것이므로 이 노력이 Framer 대비 나쁜 점이라는 의미는 아니다.)</li>
<li><strong>이미지를 사용해서 프로토타입을 만든다.</strong> 이는 레이어를 바로 연동하는 Framer와 대비되는 점인데 프로토타이핑에 사용하는 각 요소를 이미지로 만들어 낸 후 이를 Origami에서 사용한다. 요즘은 Photoshop에서 이미지로 추출하는 것이 어렵지 않고 레이어 대신 이미지를 사용할 때의 편리한 점도 약간 있어서 이 부분이 꼭 단점인지는 모르겠지만 프로토타입 중 디자인을 수정해야 하는 경우는 다시 이미지를 만들고 추가하는 등의 작업의 번거로움은 생긴다.</li>
<li><strong>Quartz Composer에 기반을 두고 있다.</strong> Quartz Composer에 대해서 잘은 모르지만 신뢰할 수 있는 기존의 플랫폼상에서 동작한다는 것은 큰 장점이라고 생각한다. 대신 Mac에서만 사용할 수 있다는 단점은 있다. 그리고 약간 만져본 느낌으로는 Quartz Composer를 기존에 잘 알고 있다면 물론 좋겠지만 그렇지 않더라도 배울 수 있는 정도라고 본다.</li>
<li><strong>복잡한 다이어그램을 관리하기가 어렵다.</strong> GUI로 만들다 보니 다이어그램처럼 화면에 요소를 계속 추가하게 되는데 간단한 인터렉티브 요소를 만들려고 해도 화면에 상당히 많은 요소를 추가하게 된다. 아직 경험이 적어서 그런지 모르겠지만, 이 요소들을 보기 쉽고 관리도 편하게 배치하는 방법을 아직 잘 몰라서 장시간 관리하면서 수정해 나가야 한다면 꽤 많은 어려움이 있을 것으로 생각된다. </li>
<li><strong>예제나 관련 자료가 많다.</strong> Quartz Composer의 역사가 있다 보니 온라인에서 예제나 관련 글에 대해서 많이 볼 수 있다. GUI로 만들다 보니 비슷한 요소를 보고 어떤 패치를 사용해서 효과를 줄 수 있는지 참고하면 바로 적용해 볼 수 있다는 점도 큰 이점 중 하나라고 본다. 대신 Origami라는 이름 때문에(일본어로 종이접기다) Quartz Composer나 Prototype 같은 키워드로 같이 검색하지 않으면 종이접기에 대한 정보만 잔뜩 볼 수 있다.</li>
<li><strong>Quartz Composer에서만 실행할 수 있다.</strong> 다양한 효과를 주고 동작해 볼 수 있지만, 이는 Quartz Composer 내에서만 가능하다. 그래서 Framer처럼 앱에 넣어보거나 하는 등의 테스트를 할 수 없고 결과물도 동영상으로 촬영하거나 프로젝트 파일 자체를 공유해야 한다.(내가 모르는 게 아니라면...)<br />
<br></li>
</ul>
<h1>에필로그</h1>
<p>Origami 관련 글에서 비슷한 도구를 본 것 같은데 <strong>현재 존재하는 효과들을 구현하는 수준의 프로토타입도구가 아니라 새로운 효과라도 상상할 수 있으면 만들어 낼 수 있는 정도의 도구를 둘 다 목표로 하고 있으므로 현재로서는 강력한 프로토타이핑을 원한다면 이 둘이 대표적인 후보라고 생각한다.</strong>(앞으로도 그럴지는 모를 일이다.) 그리고 <strong>두 도구 모두 완전한 하나의 앱을 프로토타이핑한다기 보다는 각 화면의 전환 효과, 버튼 애니메이션 등을 별도로 프로토타이핑하는 접근을 권장하는 것으로 보인다.</strong> Framer의 경우 코드의 기본적인 관례를 이용해서 어느 정도 유지 보수성을 높일 수 있지만 둘 다 도구 자체에서 복잡한 화면 구성에 대한 관리 방법을 전혀 제공하지 않는다. 예를 들어 전체 앱을 하나의 프로토타입으로 만든다면 못해도 화면이 십여 가지는 될 텐데 이를 하나로 만든다면 그 복잡도가 엄청나게 증가하는 느낌이고 이를 별도로 모듈화해서 쉽게 할 방법이 전혀 존재하지 않는다. 열심히 검색해 본 결과 각 화면이나 효과별로 나누어서 만드는 것이 권장하는 접근이라고 판단 내렸다.</p>
<p>둘은 접근 방식은 상당히 다르지만 아주 강력한 프로토타이핑 도구라서 약간 사용해 봤을 때 어느 쪽이 좋은지 우열을 가리기 어려웠다. 물론 나는 개발자이고 CoffeeScript를 할 줄 알아서 Framer에 대한 러닝 커브가 많이 줄어들기 때문에 Framer 쪽으로 약간 기운 것은 사실이지만 이는 개인적인 입장일 뿐이다. 그리고 앞에서 프로토타이핑 도구는 실 개발보다 상당히 빠른 개발속도가 필요하다고 했는데 러닝 커브가 좀 있어서 그 정도 생산성이 나오려면 상당한 노력이 필요할 것으로 보이지만 그만큼 강력하므로 한번 익혀두면 프로젝트 내에서 요긴하게 써먹을 수 있을 것으로 보인다.</p>
<p><strong><a href="https://blog.outsider.ne.kr/1097?commentInput=true#entry1097WriteComment">댓글 쓰기</a></strong></p>iPhone 5에서 웹앱을 전체화면으로 실행하기Outsiderhttps://blog.outsider.ne.kr/9762013-09-05T01:47:10+09:002013-09-05T01:47:10+09:00<h1>viewport 메타 태그</h1>
<p>모바일용 웹페이지를 만들때 일반적으로 <code>viewport</code> 메타태그를 사용해서 페이지가 모바일에서도 잘 보이도록 합니다.</p>
<p style="text-align: center;"><img src="//blog.outsider.ne.kr/attach/1/9527280283.gif" width="400" height="710" alt="모바일 사파리에서 viewport를 지정하지 않아서 작게 나오는 화면" title="" /></p>
<p>위처럼 <code>viewport</code> 메타태그를 사용하지 않으면 원래의 사이즈로 나와서 모바일에서 보기에 좋지 않은 페이지에 다음과 같이 <code>viewport</code>를 지정하면 아래 화면과 같이 모바일 사이즈에 맞춰서 나온다.</p>
<pre class="line-numbers"><code class="language-html"><meta name="viewport" content="width=device-width,
initial-scale=1.0,
maximum-scale=1.0,
user-scalable=no">
</code></pre>
<p style="text-align: center;"><img src="//blog.outsider.ne.kr/attach/1/7868208111.gif" width="400" height="710" alt="모바일 사파리에서 viewport지정으로 모바일에 맞게 나오는 화면" title="" /></p>
<p><a href="https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/MetaTags.html">Safari 개발자 문서</a>를 보면 <code>viewport</code>에서 사용할 수 있는 프로퍼티에 대한 설명이 나와 있다. 이 프로퍼티는 모두 iOS 1.0부터 지원한다.</p>
<ul>
<li><strong>width</strong>: 뷰포트의 넓이이고 픽셀값이다. 기본값은 980이고 200부터 10,000까지 지정할 수 있다. 기기의 넓이를 의미하는 상수인 <code>device-width</code>나 높이를 의미하는 <code>device-height</code>를 사용할 수도 있다.</li>
<li><strong>height</strong>: 뷰포트의 높이이고 픽셀값이다. 기본값은 <code>width</code> 프로퍼티에 기반해서 화면 비율에 따라 계산한다. 223부터 10,000 픽셀까지 지정할 수 있으면 <code>device-width</code>나 <code>device-height</code> 상수를 사용할 수 있다.</li>
<li><strong>initial-scale</strong>: 뷰포트의 기본 비율이다. 기본값은 보이는 영역에 화면을 맞춰주고 <code>minimum-scale</code>과 <code>maximum-scale</code> 프로퍼티로 범위가 결정된다.</li>
<li><strong>minimum-scale</strong>: 뷰포트의 최소 비율을 지정한다. 기본값은 0.25이고 0부터 10.0까지 지정할 수 있다.</li>
<li><strong>maximum-scale</strong>: 뷰포트의 최대 비율을 지정한다. 기본값은 5.0이고 0부터 10.0까지 지정할 수 있다.</li>
<li><strong>user-scalable</strong>: 사용자가 뷰포트를 축소/확대 할 수 있는지를 지정한다. <code>yes</code>로 지정하면 축소/확대할 수 있고 <code>no</code>로 지정하면 축소/확대할 수 없다. 기본값은 <code>yes</code>다. 이 값은 <code>no</code>로 지정하면 인풋필드에 글자를 입력할 때 웹페이지가 스크롤되는 것을 막는다.</li>
</ul>
<p><br></p>
<h1>아이폰 5에서 웹앱으로 전체화면 사용하기</h1>
<p>모바일 사파리에서 사용할 때는 상관없지만 iOS에는 웹페이지를 앱처럼 홈화면에 추가하는 기능이 있고 <a href="http://rainygirl.com/">rainygirl님</a>이 올려주신 <a href="http://blog.rainygirl.com/?p=612">iOS Web-App 용 몇 가지 스킬</a>에 나와있는 <code>apple-mobile-web-app-capable</code> 메타태그를 사용하면 모바일 사파리의 주소창같은 것 없이 풀 스크린으로 띄울 수 있다. 이 부분은 웹을 페이지가 아닌 웹앱형태로 구성했을 때 유용한 기능인데 iPhone 5에서 위의 <code>viewport</code> 메타태그를 사용해서 홈화면에서 앱처럼 실행하면 다음과 같이 나온다.</p>
<p style="text-align: center;"><img src="//blog.outsider.ne.kr/attach/1/5799396497.gif" width="400" height="710" alt="웹앱으로 실행했을때 위아래가 잘려서 나오는 화면" title="" /></p>
<p>(빈공간을 알 수 있도록 테두리를 추가했다.)</p>
<p>아이폰은 세로가 더 길기 때문에 전체화면으로 나타나지 않고 위아래에 공백이 나타난다. 아이폰4는 640x960인데 반해서 아이폰 5는 640x1136인데 여기서 상단의 상태바가 40픽셀이므로 실제 화면에 사용하는 높이는 640x1096이 된다. <code>viewport</code> 메타태그의 height는 <code>width</code>에 기반해서 적용되는데 <code>initial-scale</code>를 1로 지정한 경우에 <code>width</code>가 320픽셀이 된다. 그래서 비율에 따라 <code>height</code>가 480픽셀이 되고 실제 기기의 픽셀로 보면 960픽셀이 되므로 176픽셀(1136-960)만큼 비게 되는 것이다. width가 320이니까 height는 568픽셀이 되어야 전체화면이 다 채워지는데 이 문제를 해결하는 방법은 아주 쉽다.(<a href="https://gist.github.com/burin/3840737">Burin Asavesna가 올려준 코드</a>를 참고했다.)</p>
<pre class="line-numbers"><code class="language-html"><meta name="viewport" content="width=device-width,
initial-scale=1.0,
maximum-scale=1.0,
user-scalable=no">
<meta name="viewport" content="initial-scale=1.0,
maximum-scale=1.0,
user-scalable=no"
media="(device-height: 568px)">
</code></pre>
<p>위와 같이 메타태그를 2개 지정하고 미디어쿼리를 사용해서 기기의 높이가 568픽셀인 경우에는 <code>viewport</code>에서 width를 지정하지 않으면 다음과 같이 전체화면으로 웹앱이 나타나게 된다.</p>
<p style="text-align: center;"><img src="//blog.outsider.ne.kr/attach/1/3356408135.gif" width="400" height="710" alt="아이폰 5에서 웹앱이 전체화면으로 나온 화면" title="" /></p>
<p><strong><a href="https://blog.outsider.ne.kr/976?commentInput=true#entry976WriteComment">댓글 쓰기</a></strong></p>모바일 사파리에서 스크롤 구현과 관련된 문제Outsiderhttps://blog.outsider.ne.kr/9712013-08-18T16:52:56+09:002013-08-18T01:51:57+09:00<p>HTML5가 나오고 나서 웹에도 엄청난 변화가 일어났지만 초반에 열심히 쫓아가다가 너무 많이 쏟아져 나와서 한참동안은 너무 깊게 파지는 않고 있었고 모바일은 딱히 만질일도 없었기 때문에 기본적인 수준 이상으로는 크게 관심을 두지 않았었다. 지금은 프론트앤드쪽 작업을 하고 있으므로 모바일도 좀 알아야 되겠다 싶어서 모바일웹쪽을 만져보고 있는 중이다. 개인 프로젝트에서 모바일 웹을 작업하고 있는데 스크롤을 구현하는게 상당히 골치가 아팠다. 스크롤은 어디나 들어가는 아주 일반적인 기능이라고 생각하고 있었음에도 구현하는데 여러가지 어려움이 상당히 많았다.</p>
<p>모바일에서 스크롤 관련 라이브러리로 가장 유명한 것은 <a href="http://cubiq.org/iscroll-4">iScroll</a>이다. 현재는 4버전이 최신 버전이고 <a href="http://cubiq.org/iscroll-5-ready-for-beta-test">iScroll 5가 베타상태</a>에 있다. 처음에는 iScroll로 작업을 했는데 처음 사용해봐서 제대로 구현못한 건지 모르겠지만 아주 깔끔하게 안되는 부분이 좀 있었고 안드로이드 기기로 넘어가니 퍼포먼스가 너무 안나왔다. 그래서 OS 탑재된 네이티브 스크롤을 직접 이용하기로 하고 iScroll을 제거하고 직접 구현하고 있는데 그 가운데 스크롤에 관련된 내용을 좀 정리해야 좀더 다양한 기능 구현 및 최적화를 할 수 있을것 같아서 정리를 한다.(이미 다 아는 내용인데 나만 이제 확인한 것 같긴 하지만)</p>
<p>일단 내가 가진게 iOS라서 iOS에 맞추어서 작업을 하고 있다. 안드로이드에서도 동작하리라고 생각하지만 많은 테스트를 해보진 않았다. 예제는 <a href="http://angularjs.org/">Angular.js</a>를 사용했는데 이벤트나 좌표를 추적해서 보여주기 위한 것이므로 스크롤과는 상관이 없다. 그리고 스크롤을 설명하는 예시일 뿐이므로 퍼포먼스가 많이 고려되어 있지는 않다.(누가 잘아시는 분이 설명을 해주시면 감사.)<br />
<br></p>
<h1>스크롤</h1>
<p>스크롤 영역으로 지정하는 것은 딱히 모바일 웹에 특화된 것은 아니다. 스크롤을 사용할 곳의 크기를 지정하고 CSS 속성에서 <code>overflow: auto;</code>로 지정하면 된다. 이러면 해당 영역보다 작을때는 상관없지만 해당 영역보다 내용이 많아지면 자동으로 스크롤이 동작하게 된다. 가로나 세로만 하고 싶다면 <code>overflow-x: auto;</code>, <code>overflow-y: auto;</code> 같은 식으로 작성하면 된다. 다음 예제를 보자.(스크롤은 스샷을 찍어서 설명하기가 어렵고 또 동영상을 찍기고 쉽지 않아서 실행해 볼 수 있는 예제를 만들었다. 이벤트가 다르므로 데스크탑에서는 제대로 동작하지 않을 수 있으므로 모바일장비에서 테스트해봐야 한다.)</p>
<iframe width="100%" height="300" src="http://jsfiddle.net/outsider/hBc7g/embedded/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<p><a href="http://jsfiddle.net/outsider/hBc7g/show/">실행가능한 예제 링크</a></p>
<p>각 동작을 한눈에 볼 수 있도록 예제를 구성했다.(폭이 좁아서 블로그내에서는 예제를 실행해보기 어려우므로 모바일에서 띄워보는게 확인하기 좋다.) 상단에는 좌표관련 정보를 표시하고 좌측에는 예제의 스크롤 영역이 있다. 우측에는 스크롤 동작과 관련한 이벤트가 출력되도록 했다. 모바일에서는 마우스가 없으므로 터치이벤트를 통해서 스크롤이 동작하게 되는데 터치할 때 <code>touchstart</code>이벤트가 발생하고 움직이면 <code>touchmove</code>가 발생하고 손가락을 뗄 때 <code>touch</code>가 발생한다. 움직이지 않고 바로 떼면 <code>touchmove</code>가 발생하지 않고 바로 <code>touchend</code>가 발생한다. 여기서는 스크롤 영역에 대한 테스트이므로 <code>touchmove</code>를 통해서 스크롤이 될 때 <code>scroll</code>이벤트도 함께 발생한다.</p>
<p>좌표와 관련해서는 스크롤 영역에는 <code>scrollTop</code>이라는 속성이 존재한다. 가장 최상위에 있을 때는 <code>scrollTop</code>이 0이고 스크롤을 내릴 수록 값이 커지게 된다. 각 이벤트에 대한 좌표를 알 수 있도록 <code>touchstart</code>, <code>touchmove</code>, touchend`의 좌표를 따로 표시하도록 했다. 예제소스는 jsFiddle에서 볼 수 있으므로 따로 전체소스를 담지는 않겠다.<br />
<br></p>
<h1>모멘텀(momentum) 스크롤</h1>
<p>앞에서 본게 기본 스크롤 영역이지만 이 스크롤을 실제로는 사용할 수 없다. 모바일에서 스크롤을 할 경우에는 가속도가 먹어서 손가락을 튕기면 스크롤이 빠르게 이동하는 스크롤을 사용하고 사용자에게도 이게 당연한 동작이다. 이를 모멘텀 스크롤이라고 부르는데 앞에서 본 예제는 손가락을 떼는 순간 스크롤이 멈추기 때문에 사용하기가 아주 불편하다.</p>
<p>iOS 즉 모바일 사파리(웹뷰 포함)에서 모멘텀 스크롤을 사용하려면 스크롤 영역에 <code>-webkit-overflow-scrolling: touch;</code> CSS 속성을 지정한다. 이 스타일만 지정하면 스크롤이 자연스러운 모멘텀 스크롤로 동작하게 된다.</p>
<iframe width="100%" height="300" src="http://jsfiddle.net/outsider/hBc7g/1/embedded/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<p><a href="http://jsfiddle.net/outsider/1/hBc7g/show/">실행가능한 예제 링크</a></p>
<p>이제 스크롤이 아주 자연스러워 진 것을 볼 수 있다. 하지만 모멘텀 스크롤에는 몇가지 문제가 좀 있다.(이는 iOS의 버그수준이라고 생각하는데 어쨌든 문제가 있다.)</p>
<p><strong>모멘텀 스크롤 중에는 <code>scrollTop</code>이 업데이트되지 않는다.</strong> 모멘텀 스크롤을 손가락으로 스크롤 영역을 튕겨서 동작하므로 즉 <code>touchend</code>이벤트가 발생한 이후에도 스크롤이 계속 이동하게 되는데 <code>tocuchend</code>이벤트까지는 <code>scrollTop</code>이 갱신되지지만 <code>touchend</code>이벤트가 발생한 이후에 모멘텀 스크롤가 동작하는 동안에는 <code>scrollTop</code>이 변하지 않고 모멘텀 스크롤이 시간이 지나서 자동으로 멈춘 순간 <code>scroll</code>이벤트가 발생하면서 <code>scrollTop</code>이 갱신된다. 그래서 현재 스크롤이 어느 위치에 있는지 찾을 수가 없고 심지어 모멘텀 스크롤이 동작하고 있다는 것 조차 알 수가 없다.(나중에 <code>scroll</code>이벤트가 발생하므로 모멘텀 스크롤이 동작했었구나 정도만 알 수 있다.)<br />
<br></p>
<h1>모멘텀 스크롤에서 선택영역 사용하기</h1>
<p>모멘텀 스크롤에서 선택영역을 함께 사용하지 않는다면 큰 문제는 없다. 아주 자연스럽게 스크롤을 할 수 있지만 나는 다음과 같이 하고 싶었고 어플리케이션에 따라 다르겠지만 당연한 동작이라고 생각했다.</p>
<ul>
<li>스크롤을 자연스럽게 사용할 수 있어야 한다.(이건 당연히...)</li>
<li>리스트를 터치하면 선택했음을 알 수 있도록 색상을 변환한다.</li>
<li>터치한 상태에서 스크롤을 하기 시작하면 선택하고자 한 것이 아니므로 선택은 취소되고 스크롤이 동작한다.</li>
<li>스크롤도중에 클릭한 것은 선택하기 위한 것이 아니라 스크롤을 멈추고자 하는 것이므로 선택이 되지 않는다.</li>
<li>리스트를 선택한 후에 손가락을 떼면 선택으로 동작한다.</li>
</ul>
<p><strong><code>scrollTop</code>이 업데이트되지 않으므로 모멘텀 스크롤중의 터치도 잘못된 좌표가 인식된다.</strong> 말로 설명하려니 어려운데 스크롤 영역에 <code>li</code>같은 태그에 클릭 효과가 나도록 <code>:active</code>로 스타일을 주었을 경우 모멘텀 스크롤 중에(멈춘뒤 말고) 클릭을 해서 멈춘다면 현재 클릭한 부분이 선택영역으로 잡히지 않고 모멘텀 스크롤을 시작하기 전에 해당 위치에 있던 엘리먼트가 선택된 것으로 표시가 된다. <code>:active</code> 스타일이 다른 위치에 가서 먹고 실제 이벤트도 여기서 발생한다. 이는 다음 예제에서 확인해 볼 수 있다.</p>
<iframe width="100%" height="300" src="http://jsfiddle.net/outsider/hBc7g/2/embedded/" allowfullscreen="allowfullscreen" frameborder="0"></iframe>
<p><a href="http://jsfiddle.net/outsider/2/hBc7g/show/">실행가능한 예제 링크</a></p>
<p>그래서 맨 앞에 얘기한 조건대로 클릭할 경우 리스트의 스타일을 변경해 주기 위해서 <code>:active</code>상태를 쓸 수 없다고 생각했다. 내가 생각한 방법은 선택에 대한 CSS 클래스를 주어서 터치이벤트에 따라 조건에 따라 클래스를 넣었다 빼었다 하는 것이다. 이렇게 하려면 지저분한 플래그가 꽤 필요하고 그래도 해결이 되지 않아서 스크롤에 대한 가속도를 측정하는 방법을 시도했다. 마지막 4개의 이벤트의 시간간격을 측정해서 모멘텀 스크롤처럼 손가락을 튕긴 것인지 아니면 그냥 스크롤을 하다가 손가락을 뗀 것인지를 판단하려고 한 것인데 일단 내 개인 프로젝트에서는 잘 동작하고 있다. 완벽하진 않지만 한 95%의 경우에서는 제대로 동작하는 것으로 보인다. 사실 이 부분도 예제로 만들려고 했지만 이건 잘 안됐다. 내가 만든것에서는 여러가지 UI가 섞여있어서인지 가속도 측정이 예제로 다시 구성하니 전혀 다르게 나와서 구성할 수가 없었다.(어째서!!!) 일단 내가 시도한 방법이 범용적으로는 쓸 수 없다고 생각해서 좀더 고민을 해봐야겠다. 정말 이 버그가 iOS 7에서는 해결이 되었으면 좋겠다. ㅠ</p>
<p><strong><a href="https://blog.outsider.ne.kr/971?commentInput=true#entry971WriteComment">댓글 쓰기</a></strong></p>