들어가며


저는 슬로워크의 이메일마케팅 서비스 스티비의 프론트엔드 개발자입니다. 현재 스티비는 정식버전을 한창 개발하고 있는데요, 개편을 진행하면서 프론트엔드 개발 프로세스에 대해 많은 고민을 하게 되었습니다. 무엇보다 웹서비스는 유용하고 쓸만해야 합니다. 즉, 사용자에게 도움을 주면서 그 과정이 쉽고 편해야 합니다. 쓰기 편한 웹서비스는 명확한 UI를 제시하여 사용법의 학습이 쉽고, 한 번 학습하면 다시 익힐 필요 없도록 통일성있는 UI를 가져야 합니다. 


오류와 경고를 표현할 때, 보통 오류는 빨간색으로 경고는 노란색으로 표현합니다. 하지만 어떤 페이지에는 빨간색이 너무 많이 쓰여서 예외적으로 오류를 보라색으로 할 수도 있을 것입니다. 이런 결정을 내리는 경우는 드물겠지만 과거의 방식처럼 웹서비스를 페이지(화면) 단위로 디자인한다면 충분히 일어날 수 있는 일입니다. 실제로 같은 역할을 하는 상자의 윤곽선 색상이나 굵기, 여백이 화면마다 다른 경우가 많습니다. 


이런 혼란을 막기 위해 등장한 것이 ‘스타일 가이드(style guide)'입니다. 웹서비스 화면을 디자인할 때 참고하는 가이드 문서입니다. 스타일 가이드에 맞춰 개발하면 사용자에게 통일성 있는 UI를 제공할 수 있습니다. 


스매싱매거진의 ‘Designing Modular UI Systems Via Style Guide-Driven Development’에서는 스타일 가이드를 기반으로 한 디자인을 ‘스타일 가이드 주도 개발(Style Guide-Driven Development)라고 합니다. 스타일 가이드 주도 개발은 과거의 개발 방식과 어떤 점이 다른지 알아보고 좋은 스타일 가이드들을 살펴본 뒤, 실제로 스타일 가이드를 작성해보도록 하겠습니다.



무엇이 다를까




페이지(화면)을 그린다 vs. 컴포넌트를 만든다


스타일 가이드 주도 개발은 과거 화면 단위의 개발과 대조되는 개념입니다. 이전에는 웹서비스를 사용하면서 사용자가 마주하는 모든 페이지(화면)을 하나씩 디자인해 왔습니다.(이하 ‘페이지 주도 개발’) 주로 포토샵을 사용하여 웹서비스 화면을 그립니다. 자주 쓰는 컬러 스와치를 미리 구성하여 사용하고, 공통된 레이어나 그룹은 복사하여 사용하지만 기본적으로 화면의 모든 내용을 직접 그리고 위치시킵니다. 


스타일 가이드 주도 개발에서는 화면부터 디자인하지 않습니다. 어떤 화면이 필요하다면 필요한 구성을 작은 단위로 쪼갭니다. 그리고 그 쪼갠 단위들을 공통점을 기반으로 묶어 작은 단위로 기획하고 디자인합니다. 제목을 클릭하면 내용이 보이는 아코디언 UI는 보통 자주 묻는 질문(FAQ) 화면에서 볼 수 있는 UI입니다. 목록에는 제목이 먼저 보이고, 제목을 누르면 해당하는 내용이 보입니다. 여기서 FAQ 페이지를 직접 그리는 방식과 아코디언 UI의 한 부분을 먼저 그리는 방식의 차이가 드러납니다. 즉, 페이지 주도 개발은 빈 화면에 내용물을 더하면서 시작하고, 스타일 가이드 주도 개발은 내용물을 쪼개면서 시작합니다.


완성 vs. 조합


페이지 주도 개발은 화면의 완성을 목표로 합니다. 사용자에게 제시될 화면과 완벽히 유사한 화면을 그리고, 그대로 개발해야 합니다. 하지만 스타일 가이드 주도 방식의 목표는 부품(컴포넌트)의 제작과 조합입니다. 필요한 부품을 만들고, 이들을 각기 테스트한 뒤 전체를 조합하며 화면을 구성해 갑니다. 


변화와 역동 vs. 통일과 안정


페이지 주도 개발은 화면을 통째로 디자인하므로 각 화면마다 개성있는 표현을 넣을 수 있고, 역동적인 디자인을 제시할 수 있습니다. 반면, 스타일 가이드 주도 개발로는 통일성 있는 UI와 안정적인 동작을 보장할 수 있습니다. 한 번 사용할 때 잦은 조작이 필요하거나 오랫동안 사용해야 하는 웹서비스는 통일성과 안정성이 중요합니다. 하지만 남과 다른 브랜드 가치를 표현하거나 사용자에게 감성적인 소구가 필요한 경우는 안정보다는 역동성이 필요합니다. 웹서비스의 목적에 따라 개발 방식에 차이가 있을 수 있습니다. 



아코디언UI




부품의 조합으로 다양한 가구가 된다. IKEA




스타일 가이드 주도 개발은 왜 필요한가


스타일 가이드 주도 개발은 사용자와 개발팀(기획자, 디자이너, 개발자)에게 모두 이점을 가져다 줍니다. 통일, 확정, 효율입니다. 각 장점을 차례로 알아보겠습니다.


통일

사용자에게 통일성 있는 UI를 제공할 수 있습니다. 사용자가 웹서비스를 사용하면서 만나는 모든 UI는 기존에 학습되었거나, 새로이 학습해야 하는 것들입니다. 웹의 역사만큼 표준 UI의 학습이 진행되어 왔지만 여전히 사용자는 UI에 대한 학습이 필요하고, 더군다나 새로운 기능과 가치를 제공하는 서비스라면 반드시 거쳐야할 관문입니다. 너무 어렵거나 일관성이 없는 UI는 사용자에게 혼란을 주고, 이는 이탈을 야기합니다.


스타일 가이드를 만들고, 이에 따라 화면을 구성한다면 최소한 통일성은 보장됩니다. A 화면에서 배운 UI조작법을 B, C, D 화면에서 재사용할 수 있습니다. UI에 익숙해지면 사용자는 안정감을 갖게 되고 더 효율적으로 서비스를 사용할 수 있게 됩니다. 또한 스타일 가이드를 통해 미리 UI 부품들을 만들어 보면서 떨어져 있는 화면 간의 공통점을 찾아낼 수 있고, 각 화면의 조건에 따라 생길 수 있는 혼란을 미리 막을 수 있습니다.


확장


한 번 만든 UI 부품은 언제든 재사용할 수 있습니다. 여러가지 상황과 조건에 테스트가 된 부품이므로 어떤 화면에 넣어도 큰 문제 없이 작동할 것입니다. 최근의 웹서비스는 과거와 달리 매우 많은 화면을 담습니다. 과거의 ‘이전’, ‘다음' 버튼을 통해 화면의 전환으로 해결했던 것과 달리 최근에는 하나의 화면에서 다양한 콘텐츠가 유기적으로 등장하고 사라집니다. 사용자의 인터랙션도 다양해져 상황과 변수가 굉장히 다양해졌습니다. 이렇게 수많은 화면과 조건을 하나씩 그려서 대응할 수는 없습니다. 스타일 가이드를 작성하고서 이를 조합하면 그럴 필요 없이 화면들을 만들어 낼 수 있습니다. 

린스타트업의 관점에서도 스타일 가이드 주도 개발은 매우 가치가 있습니다. 빠른 시장 변화에 맞추어 아이디어를 서비스로 만들어 제공하려면 뛰어난 확장성이 꼭 필요합니다. X라는 기능을 테스트해보고 싶을 때, X화면을 기획하고 디자인하여 개발할 필요 없이 기존의 UI 부품들을 조합하여 빠르게 개발하여 테스트할 수 있습니다. 


효율


뛰어난 확장성은 효율로 이어집니다. 앞서 말했듯 시장의 변화에 맞춘 서비스의 개발 속도는 매우 중요합니다. 기존의 기능을 개선하거나 새로운 기능을 만들 때도 스타일 가이드 주도 개발은 이점이 많습니다. 새로운 UI를 만드는 작업은 스타일 가이드의 ‘업데이트'로 생각할 수 있습니다. 새로운 기능이 기획되면 우선 스타일 가이드화 시킵니다. 이 과정에서 다른 UI와의 통일성을 확인할 수 있고, 화면마다 다른 상황과 조건에 대입해 볼 수 있습니다. 스타일 가이드는 그 자체로 작은 프로토타입 역할을 하므로, 이를 업데이트하면 해당 UI에 대한 기본적인 개발과 테스트를 할 수 있습니다.


팀으로 협업하는 경우에도 스타일 가이드는 중요한 역할을 합니다. 미리 약속된 디자인 패턴을 서로 공유하여 작업자마다 같은 품질의 명확한 결과물을 만들어 낼 수 있습니다. 또한 정확한 커뮤니케이션을 위한 참고 지표가 될 수 있습니다. ‘제목을 누르면 내용이 나오는 상자'라는 모호한 말보다는 미리 정의된 아코디언UI를 함께 보면서 논의하는 편이 낫기 때문입니다. 





좋은 스타일 가이드 구경하기


스타일 가이드를 직접 만들기 앞서 좋은 스타일 가이드를 살펴보겠습니다. 수많은 웹서비스와 브랜드에서 자체적으로 개발한 스타일 가이드를 공개하고 있습니다. 이들을 참고하여 좋은 스타일 가이드의 특성에 대해 살펴보겠습니다.


먼저 Mailchimp의 Pattern Library를 살펴보겠습니다. 메일침프에 쓰이는 여러가지 UI 구성을 분류별로 정리해 두었습니다. Style Guide가 아닌 Pattern Library라는 이름을 쓰고 있는데, 이를 통해 UI 구성 하나 하나를 ‘패턴'이라고 정의하는 것을 알 수 있습니다. 즉, 메일침프가 생각하는 스타일 가이드는 반복될 수 있는 디자인 부품으로서의 UI입니다. 

각 화면의 레이아웃을 결정하는 그리드 시스템부터 타이포그래피, 폼, 내비게이션과 같은 자주 쓰이는 UI를 디자인과 용법, HTML 코드까지 상세하게 정의하고 있습니다. 메일침프는 이미 많은 기능을 갖춘 커다란 서비스이지만 계속해서 보완되고 확장하고 있습니다. 개발 결과물의 품질을 보증하고, 무리없는 확장을 위해 이러한 ‘패턴 라이브러리'는 반드시 필요한 존재입니다. 





다음은 스타벅스의 웹스타일 가이드입니다. 웹디자인에 관심있는 분은 한 번 쯤 봤을 수도 있습니다. 수년 전에 개발되어 스타일 가이드에 대한 개념도 희박하던 때, 많은 작업의 참고가 되었던 곳입니다. 아쉽게도 마지막 업데이트는 2014년이지만 웹/모바일 기반의 기업이 아님에도 웹스타일 가이드를 가지고 일관된 UI와 통일성 있는 사용자 경험을 주었다는데 큰 의의가 있다고 생각합니다. 




styleguide.io에서 더 많은 스타일 가이드를 찾아 볼 수 있습니다. 스타일 가이드 제작에 대한 많은 정보를 제공하고, 예시와 팟캐스트(!)까지 제공하고 있습니다. 




마치며

스타벅스와 메일침프의 공개된 스타일 가이드를 보면서 어떤 생각을 하셨나요? 개인적으로 스타벅스의 스타일 가이드에서는 웹사이트를 방문한 고객에 대한 세심한 배려를 느꼈고, 메일침프의 패턴 라이브러리에서는 메일침프의 UI 디자인에 대한 철학과 꼼꼼함을 느꼈습니다. 이처럼 스타일 가이드는 개발편의뿐 아니라 브랜드 경험을 향상시키고, 신뢰를 쌓게하는 도구가 될 수도 있습니다. 


사용자에게 편리하고 안정된 서비스 경험을 주고, 개발팀에게는 효율과 품질을 위한 강력한 도구가 되는 스타일 가이드는 단순히 웹서비스를 위한 기반작업을 넘어 그 자체로 ‘살아 있는' 서비스의 일부라고 생각해야 할 것입니다. 


다음에는 이런 스타일 가이드를 어떻게 구성하고 작성해야할지 알아보도록 하겠습니다. 



작성자: 스티비 개발 문윤기
Posted by slowalk


슬로워크 블로그에서는 얼마 전, 비디자이너의 얕은 지식 쌓기: 디자인 용어 20에 대해 포스팅했습니다. 그 글을 보고 저 또한 개발팀 내 유일한 비개발자이기에 많은 영감을 받아 이번 글을 작성하게 되었습니다. 저는 웹기획자로 프론트엔드개발자 두 명, 백엔드개발자 한 명과 함께 팀을 이뤄 작업하고 있습니다. 개발자와 함께 일하기 역시 기본적인 용어를 알지 못하면 혼란스러운 상황(나는 누구? 여긴 어디?..)에 처할 수 있습니다. 고객들도 웹사이트 의뢰를 하면서 익숙지 않은 여러 용어에 낯설어 합니다. 저 역시 아직도 갈 길이 멀지만, 개발자와 소통하기 위한 넓고 얕은 개발용어 몇 가지를 안내해 드립니다.



프론트엔드개발자와 백엔드개발자는 어떻게 다른 건가요?


프론트엔드개발자 - 사용자의 화면에 나타나는 웹 화면을 프론트엔드(Front-end) 영역이라고 합니다. 그리고 이 영역을 설계하는 사람을 프론트엔드개발자라고 합니다. 프론트엔드개발자는 사용자가 보는 화면을 주로 HTML과 CSS를 사용하여 보기 좋게 보이게 만들어주는 사람이라고 할 수 있습니다.


백엔드개발자 - 백엔드(Back-end) 영역은 일반적으로 사용자가 볼 수 없습니다. 예를 들어, 회원가입 정보를 입력하면 그 정보는 서버 데이터베이스에 저장되는데, 이러한 동작들이 처리되는 영역이 백엔드 입니다. 사용자가 보이지 않는 웹서버, 내부로직, 데이터베이스 설계, 데이터 처리를 주로 개발하는 사람입니다.

프론트엔드에서 사용자가 클릭, 드래그의 동작을 하면 이를 백엔드에서 처리한 데이터를 다시 프론트엔드로 돌려주어 사용자가 해당 작업을 수행할 수 있게 됩니다. 예를 들어, 페이스북에 사용자가 사진을 올리면 그 사진을 백엔드에서 데이터베이스에 저장하고 다시 프론트엔드로 돌려주어 내 사진을 다른 사용자가 볼 수 있게 되는 것입니다.

꼭 두 영역을 명확히 나눠서 개발하는 것은 아닙니다. 프론트엔드, 백엔드를 함께 진행하는 개발자도 있는 등 역할의 범위는 다양합니다.



자바, 파이썬, 루비, 펄, C++ .. 이게 다 무슨 이름인가요? 프로그래밍 언어는 다양하여 많은 선택지가 존재합니다. 유행을 타기도 하고 순위가 매겨지기도 합니다. 현재 사용되는 프로그래밍 언어는, 위키피디아에 따르면 698종이라고 합니다. 그 중 가장 많이 사용하는 언어는 C 계열 언어와 JAVA 계열의 언어이고, 최근에는 빅데이터 전문가가 뜨면서 R 프로그래밍이나 하둡에 관심을 두는 사람도 많아지는 추세라고 합니다. 각 언어는 저마다 장단점을 가지고 있고, 그렇기에 개발자들도 다룰 수 있는 언어들이 다양합니다.


출처: TIOBE



사용 가능한 프로그래밍 언어가 계속해서 늘고 점유율 순위가 바뀌고 사라지는 이유는 사용성 때문입니다. 요구사항이 변하고 시스템이 바뀔 때마다 손쉽게 바꿀 수 있어야 좋은 프로그래밍 언어가 됩니다.

비개발자이더라도 위 프로그래밍 언어들의 이름 정도만 알고 있으면 개발자들이 옆에서 이야기할 때 ‘아~ 프로그래밍 언어 얘기하는구나!’ 정도는 이해할 수 있습니다. 개발자와 가까워지는 방법은 그들의 언어를 한 번이라도 더 많이 들어보는 것입니다.



PHP, MySQL, Oracle 들어는 봤는데.. 서버? 백엔드개발자들이 사용하는 언어 맞나요?

PHP는 서버 쪽에서 동작되는 언어입니다. 자바스크립트나 HTML이 웹 브라우저에서 구동되는 것과는 구분됩니다. 사용자가 업로드한 파일을 서버에 저장하거나, 입력 데이터를 받아 데이터베이스나 파일에 저장하고, 저장된 정보를 불러와 HTML을 생성해서 웹브라우저로 전송하는 일을 처리합니다.

MySQL은 데이터를 보관하는 데이터베이스 관리 시스템의 한 종류입니다. 데이터베이스는 파일보다 정보 저장에 관해 더 많은 기능을 제공하기 때문에, 대부분의 데이터들이 데이터베이스에 저장됩니다. 그 중 MySQL은 오픈소스이기 때문에 많이 사용되고 있습니다.  


*서버 - 서버란 파일, 홈페이지, 동영상 등의 자료를 보관하고, 보관된 자료를 인터넷이 연결된 곳에서 언제든지 접근할 수 있도록 구성된 소프트웨어를 말합니다. 서버에는 메일서버, 웹 서버, 데이터베이스를 관리하는 DB서버, FTP프로토콜을 이용하여 파일전송을 가능케하는 FTP서버 등 다양한 서버가 있습니다.



서브라임텍스트3 사용하고 있고요, 깃으로 푸시해주세요~ 서브라임텍스트는 개발도구를 말합니다. 일반적으로 프로그래밍을 하는 데는 윈도우에서 메모장, 맥에서는 텍스트 에디터만 있어도 가능합니다. 그러나 규모가 크고, 오류가 없는 프로그램을 만들기 위해 작업을 도와주는 수 많은 개발도구들이 존재합니다. 좀 더 빠르고 효율적으로 개발하기 위해 도구를 사용하는 것이죠. 개발도구에는 비주얼스튜디오, 노트패트++, 빔, 이클립스 등이 있습니다. 그 중 서브라임텍스트는 개발자가 선호하는 도구 2위를 차지할 만큼 인기를 끌고 있습니다. 현재 슬로워크 1팀에서는 서브라임텍스트3을 사용하고 있습니다. 서브라임텍스트는 유료이지만 무료로도 사용할 수 있습니다. 장점으로는 개발자들이 많이 사용하기에 플러그인이 많아 원하는 대로 기능 확장이 가능합니다. 또한 가벼워서 좋다고 합니다.





기본적으로 이러한 까만 창이 서브라임텍스트3 입니다. 코딩을 위한 폰트도 개발자의 설정에 맞게 변경할 수 있습니다. 자세한 내용은 코딩 폰트 디자인기, Monoid를 참조해주세요.

깃(Git)은 버전관리 시스템으로 소스코드의 중요한 변화를 기록하는 것입니다. 어떠한 문제가 발생했을 때 문제의 전후 상황을 파악할 수 있도록 도와주고, 과거의 상태로 쉽게 돌아갈 수 있게 합니다. 특히 백업, 협업에 쉬워 많이 사용되고 있습니다. 물론 Git이 모든 걸 해결해주진 않지만 도움을 주기 때문에 많이 사용하게 됩니다.


CMS는 주로 워드프레스를 사용해요~


CMS-Collage2.png

출처: wooraky's Minority Report



CMS(Contents Management System)는 콘텐츠 관리 시스템으로 웹사이트를 구성하고 있는 다양한 콘텐츠를 효율적으로 관리할 수 있도록 도와주는 시스템입니다. 콘텐츠를 손쉽게 생성, 배포, 관리할 수 있는 http 기반의 프레임워크*라고 생각하시면 됩니다. 웹 서버상에서 운용이 되고 다양한 방식의 기술적 적용이 가능합니다. 우리나라는 XE(Xpress Engine)가 CMS를 표방하고 있습니다. 또한 요즘은 워드프레스(Wordpress)를 많이 사용하는 추세입니다. CMS는 전 세계적으로 워드프레스, 드루팔(Drupal), 줌라(Joomla) 이 세 가지 툴이 많이 쓰입니다. 특히 워드프레스는 쉬운 사용법과 기능들을 통해  CMS 시장을 거의 장악하고 있습니다. 프로그래밍 언어와 같이 다양한 장단점이 있고 어떤 툴이 가장 좋다고는 할 수 없습니다. 다만 대표적으로 많이 쓰이는 CMS 세 가지 정도를 알고만 있어도 개발자의 이야기를 훨씬 많이 이해할 수 있습니다.


*프레임워크 - 소프트웨어 제작을 편리하게 할 수 있도록 뼈대인 클래스와 인터페이스를 제작한 것들을 미리 모아둔 것입니다. 개발자는 이 뼈대에 살을 붙이는 방식으로 어플리케이션을 완성 시킵니다. 개발 생산성이 증대되고, 유지보수가 비교적 편리하다는 장점이 있습니다.

단점은 익숙해지는 데에 시간이 소요되고 모든 상황을 커버할 수는 없다는 한계가 있다는 점입니다. 그렇기에 개발 프레임워크를 얼마나 쉽게 커스터마이징 할 수 있는지가 프레임워크의 우수성을 평가하는 기준이 되기도 합니다.



HTML / CSS / jQuery / JavaScript 를 사용해서 만들었고요~


HTML - HTML은 웹 브라우저를 통해 사용자에게 보이는 프론트 영역을 작성하기 위한 언어로 웹 문서 내용 작성에 집중 합니다. 웹 사이트의 뼈대가 되는 구조라고 볼 수 있습니다.

CSS - CSS는 HTML로 잡아놓은 뼈대에 다양한 스타일을 추가, 변경하여 웹사이트에 디자인을 부여하고 글자의 크기 모양 줄 간격 등을 제어할 수 있게 만들어주는 언어입니다. HTML로 만들어진 뼈대에 CSS로 디자인을 입힌다는 개념입니다.


14066284_10208305726855618_3819602411510392924_o.jpg

출처: 조성도 페이스북


JavaScript - 자바스크립트는 웹사이트에서 팝업창을 열거나 전화번호 또는 이메일 주소의 유효성을 체크하는 등의 기능적인 요소를 위해 사용되는 언어로 액션에 용이합니다. 즉 HTML로 만들어진 뼈대에 CSS로 디자인을 입히고 JavaScript로 움직임을 넣는 개념입니다.

jQuery - jQuery는 자주 사용되는 기능들을 쉽게 사용할 수 있도록 모아놓은 자바스크립트 라이브러리입니다. 쉽게 말해 자주 사용하는 자바스크립트의 복잡한 코드를 간소화해주는 모듈을 말합니다. 크로스 브라우징(웹브라우저의 종류에 상관없이 웹사이트의 레이아웃 위치나 모양이 동일하게 보여지도록 서비스 접근성을 향상시키는 기술)이 쉽게 해결됩니다.



반응형 웹으로 할까요, 적응형 웹으로 할까요?


반응형 웹과 적응형 웹도 웹 사이트 구축 시 빠질 수 없는 알아두어야 할 개념입니다. 해당 내용은 더 자세히 설명된 슬로워크 포스팅 글로 이동합니다.

반응형 웹, 정말 효과적일까?



구글지도API를 사용해서 찾아오시는 길에 넣을게요! API?


API - Application Programming Interface의 약자입니다.

각 단어를 나눠서 생각해보시면,

어플리케이션 : 응용프로그램, 즉 흔히 알고 계시는 앱(app)입니다.

프로그래밍 인터페이스 : 기계가 이해하기 쉽게 입출력이 데이터로 이루어지는 인터페이스 입니다.

즉, 웹 어플리케이션 개발에서 다른 서비스에 요청을 보내고 응답을 받기 위해 정의된 명세를 말합니다.


startup_img3.jpg

출처: 공공데이터포털



이렇게 프로그램 간 서로의 커뮤니케이션을 담당하는 기능이라고 이해하시면 됩니다.

최근 우체국의 우편번호 API, 구글과 네이버 다음지도 API등 유용한 API가 많아 홈페이지 구축 시 따로 추가 개발 대신 이러한 *오픈 API를 많이 사용하고 있습니다. 특히 하이브리드 앱이나 워드프레스로 웹사이트를 만들 때 더욱 유용하게 쓰이곤 합니다.


*오픈API - 말 그대로 오픈되어 있는 API, 즉 자사의 API를 개방하여 외부에서 쉽게 쓸 수 있도록 만든 것입니다. 오픈API는 포털의 개방성을 높이기 위한 기술적 기반/개방 응용프로그램 인터페이스입니다.


대표 오픈 API사이트 몇 가지를 소개해드립니다. 아래 사이트에 가보시면API가 어떤 용도로 쓰이시는지 조금 감이 오실 겁니다. 한 번쯤 구경해 보기에도 좋습니다.


서울시공공 오픈API

구글 디벨로퍼

페이스북 개발자

카카오 디벨로퍼



구글api.png

출처: 구글 디벨로퍼

기본적이지만 모르면 외계어처럼 들리는 개발 용어들에 대해 간단히 알아보았습니다. 사실 정말 많은 개발 용어가 존재하고 있고, 개발자마다 사용언어나 사용법이 조금씩 다릅니다. 그렇기에 가장 중요한 것은 내가 함께 일할 동료들의 대화에 귀 기울이며 많은 대화를 하는 것입니다. 이 글을 작성하면서 저 또한 같은 팀 개발자 동료들께 많은 검수를 받고, 조언을 얻었습니다. 그 과정에서 어떤 도구를 사용해 어떤 식으로 일을 하고 있는지도 더욱 자세히 알게 되었고, 커뮤니케이션의 중요성을 다시 한 번 깨닫게 되었습니다.


참조

공공데이터포털 테크엠






Posted by slowalk



우리는 현재 IoT의 세상에서 살아가고 있다고 말합니다. 그렇다면 IoT가 뭘까요? 위키피디아에서는 IoT를 다음과 같이 정의하고 있습니다.


사물 인터넷(Internet of Things, 약어로 IoT)은 각종 사물에 센서와 통신 기능을 내장하여 인터넷에 연결하는 기술을 의미한다. 여기서 사물이란 가전제품, 모바일 장비, 웨어러블 컴퓨터 등 다양한 임베디드 시스템이 된다. 사물 인터넷에 연결되는 사물들은 자신을 구별할 수 있는 유일한 아이피를 가지고 인터넷으로 연결되어야 하며, 외부 환경으로부터의 데이터 취득을 위해 센서를 내장할 수 있다.


따라서, IoT 세상을 쉽게 말하자면 “모든 것이 인터넷으로 서로 연결되어 있는 세상”이라고 할 수 있겠습니다.



DIY IoT

모든 것이 인터넷으로 연결되어 있는 세상에 살고 있는 요즘 또 다른 대세 용어가 있습니다. 바로“전문업자나 업체에 맡기지 않고 스스로 직접 생활 공간을 보다 쾌적하게 만들고 수리하는 개념을 말한다”는 뜻의 DIY(Do It Yourself), 즉 “네가 직접 만들어라”라는 말입니다.


그렇다면 DIY IoT는? “사물인터넷을 네가 직접 만들어라!”라는 뜻이 되겠네요.



우리집 온습도 측정기

“인터넷에 연결되어 있는 사물 = IoT” 라고 정의할 수 있으니 IoT에 포함되는 범위는 꽤나 넓습니다. 그래도 이왕 만드는 것이라면 실생활에 도움이 되는 것이면 좋겠지요?


올해 저희 가족에게는 소중한 선물이 생겼습니다. 처음 아이를 출산하였을 때, 아내와 저는 무엇을 준비해야 하는지 이것 저것 찾아보기 바빴습니다. 신생아 때는 실내 온습도가 유지가 중요하다고 주워 들어 온습도계를 살까 말까 고민하던 차, 특별한 선물을 주고 싶은 아비의 마음(이라 쓰고 제 욕심 채우기라 읽습니다)으로 직접 온습도계를 만들어 보기로 했습니다.


물론 시중에 저렴한 온습도계가 많이 있지만 싱글보드 컴퓨터인 라즈베리파이 기반으로 제작된 온습도계는 커다란 장점이 있습니다. 바로 커스터마이징이 가능하다는 점이죠! 예를 들어, 스마트폰으로 언제 어디서든 집안의 온습도 확인이 가능하며, 특정 온습도 이하로 떨어지면 알림을 주는 등 내가 원하는 기능을 손쉽게 구현할 수 있습니다. 다만 프로그래밍과 하드웨어에 대한 지식이 필요 하다는 것이 조그만(?) 단점이 되겠네요. 뭐 그렇다고 크게 걱정하지 마세요. 저희에겐 구글 신이 있고 유튜브 동영상 강의가 있으니까요! 이참에 취미로 코딩 한번 시작해 보시는 건 어떨까요?



준비물

라즈베리파이


사진출처 : 엘레파츠



라즈베리파이는 싱글보드 컴퓨터 입니다. 싱글보드 컴퓨터가 뭐냐구요? 그냥 엄청 작은 초소형 컴퓨터라고 생각하시면 됩니다. 이 카드 만한 기판에 컴퓨터의 역할을 할 수 있는 모든 기능이 탑재되어 있습니다. 세상 참 좋아졌죠? 라즈베리파이를 구입할 수 있는 대표적인 사이트로 엘레파츠가 있습니다. 현재 라즈베리파이3까지 나왔네요.


라즈베리파이3 스타터 키트 구매



온습도 센서


사진출처 : 엘레파츠


라즈베리파이와 연결하여 온습도를 측정할 수 있는 센서 입니다. dht11로 많이 알려져 있습니다. 라즈베리파이와 마찬가지로 엘레파츠 등의 사이트에서 구매하실 수 있으며, 센서 키트를 구매하시면 라즈베리파이를 좀 더 다양하게 활용 하실 수도 있습니다.



마이크로SD 메모리(4GB 이상)


사진출처 : SanDisk


라즈베리파이도 하나의 컴퓨터이기 때문에 OS(운영체제) 설치가 필요합니다. 이 운영체제 설치에 필요한, 최소 공간이 4GB 이므로, 그 이상인 마이크로SD 카드를 준비합니다. 넉넉할 수록 좋습니다. 컴퓨터에 하드디스크 공간이 많으면 좋으니까요! (나중에 용량이 많이 필요해지면 외장하드를 연결하여 사용도 가능합니다.)


스마트폰

측정된 온습도를 확인할 수 있는 앱을 만들고, 구동시켜 볼 수 있는 스마트폰!

컴퓨터

앱을 제작(코딩)할 수 있는 컴퓨터 또는 노트북!

그 외

점퍼케이블, 인터넷 공유기, 랜케이블, USB 무선랜 등



제작

제작과정은 1부와 2부로 나뉘어 작성될 예정입니다.


지금 보고계신 1부에서는 라즈베리파이에 OS를 설치하고, 온습도 센서를 연결해 온습도 값을 얻어보는 것을 목표로 하고, 추후 공개되는 2부에서는 이 값을 시각적으로 볼 수 있는 앱과 서버를 구현해보도록 하겠습니다.


라즈비안 설치하기


라즈비안은 라즈베리파이에 설치 가능한 대표적인 OS(운영체제) 입니다. 자세한 설치 과정은 라즈베리 파이에 라즈비안 설치하기를 참조하시기 바랍니다.


설치가 다 끝나셨나요? 그렇다면 라즈베리 파이 환경 설정를 참고해 환경설정을 해주시기 바랍니다. 패스워드 변경과 SSH 활성화는 필수입니다!


설정을 마치고 재부팅까지 끝냈다면 HDMI 케이블로 라즈베리파이와 모니터를 연결하고 키보드와 마우스를 꽂아 주세요. 그럼 다음과 같은 화면이 여러분을 반길 것 입니다.





혹시 검정화면에 로그인 하라는 영어만 덩그러니 보인다면 로그인 후에 startx 라고 입력 후, 엔터를 쳐주시기 바랍니다.



인터넷 연결하기

자! 이제 우리의 라즈베리파이가 사물인터넷의 역할을 다할 수 있도록 인터넷에 연결해 보도록 하겠습니다. 라즈베리파이도 하나의 컴퓨터이기 때문에 인터넷에 연결할 수 있는 방법은 두 가지가 존재합니다. 유선 또는 무선!


라즈베리파이를 구매할 때 스타터키트로 구매하셨다면 무선 USB 랜카드도 같이 포함되어 있는데요. 라즈베리파이만 따로 구매하셨다면 유선으로 공유기와 직접 연결하시면 되겠습니다. 기본 설정이 DHCP라 랜선을 꽂기만 하면 자동으로 인터넷에 연결이 될 텐데요. 이 경우, 라즈베리파이가 꺼졌다 켜지면 IP 주소가 바뀔 수 있습니다. 그래서 대부분 고정 아이피를 할당하여 사용하게 되는데요.


유선에 대한 고정아피 설정법은 여기를 참고하셔서 설정하시기 바라며, 저는 무선(WIFI)설정에 대해서 알아보도록 하겠습니다. USB 무선 랜 카드를 라즈베리파이에 꽂으면, 화면의 우측 상단에 다음과 같은 아이콘이 보입니다.





해당 아이콘 위에서 마우스 우클릭을 하시고 설정창에서 원하는 AP와 아이피를 할당한 뒤에 Apply 버튼을 누르면 적용이 완료됩니다. 혹시 와이파이 비밀번호가 설정되어 있다면 다시 해당 아이콘을 좌클릭 한 뒤 나오는 AP 목록에서 연결을 원하는 AP를 선택하시면 비밀번호 입력 칸이 나옵니다.



온습도 센서 연결 및 값 확인

온습도센서 뿐만 아니라, 라즈베리파이에 연결되는 대부분의 센서는 GPIO를 통해 연결됩니다. GPIO는 General Purpose Input Output의 약자이며, GPIO에 대한 설명은 라즈베리파이 GPIO 강좌를 통해 확인하기 바랍니다. 대부분 센서를 구매하면 “센서를 라즈베리파이의 몇번 GPIO핀에 연결하라” 라고 매뉴얼이 제공 되므로 너무 어려워 할 필요는 없습니다.


제가 온습도기를 만들 때 사용한 라즈베리파이는 모델2 버전이고 해당 버전의 GPIO 구성은 아래와 같습니다.



사진출처 : rs-online.com



뭔가 어려워 보이는데요… 일단 우리의 목표는 온습도 센서에서 값만 읽어오면 되므로, 무작정 따라하도록 하겠습니다. 일단 온습도 센서와 라즈베리파이를 점퍼 케이블을 이용하여 아래와 같이 연결합니다.




온습도 센서 DHT11

라즈베리파이 GPIO 핀(PIN#)

DOUT

7번

GND

6번

UCC

1번


연결이 완료된 후에는 GPIO를 쉽게 제어할 수 있게 도와주는 라이브러리 wiringPi를 설치하여야 합니다. 설치 방법은 다음과 같습니다. 라즈베리파이에서 터미널을 실행시킨 뒤, 아래의 명령을 실행 시킵니다.


$ git clone git://git.drogon.net/wiringPi

$ cd wiringPi

$ ./build

$ gpio readall




위와 같은 화면이 나온다면 wiringPi는 정상적으로 설치가 완료된 것입니다.

다음으로 링크된 소스 코드를 복사하고 터미널에서 아래와 같이 입력합니다.


$ nano myhome_dht.c

에디터가 실행되면 소스코드를 붙여넣기(Shift + Insert) 한 뒤 저장 합니다.(Ctrl + O 엔터)

$ sudo gcc -o myhome_dht myhome_dht.c -lwiringPi

$ sudo ./myhome_dht


아래와 같은 화면이 나온다면 성공!



네! 드디어 라즈베리파이에 센서를 연결하여 온도와 습도를 획득했습니다.


지금은 비록 수동으로 sudo ./myhome_dht 명령어를 통해 확인해야 하나, 2부에서 이를 자동으로 실행하고, 그 결과 값을 앱에서 실시간으로 볼 수 있도록 하겠습니다.



작성: 이학진


Posted by slowalk

이메일마케팅 컨퍼런스 중 최고의 권위를 자랑하는 The Email Design Conference 2016의 보스턴 행사(이하 TEDC)를 슬로워크 스티비팀에서 다녀왔습니다.


스티비(www.stibee.com)는 디자인솔루션 기업 슬로워크에서 운영하는 이메일마케팅 서비스입니다. 현재 무료 베타서비스 중이며, 모바일에 최적화된 반응형 이메일을 손쉽게 제작할 수 있습니다. 이메일마케팅 팁을 공유하는 뉴스레터를 꾸준히 발행하고 있으며, 패스트캠퍼스와 어벤저스쿨 등에서 이메일마케팅 강의를 해 오고 있습니다. 이메일마케팅의 효과를 극대화하고, 마케팅 실무자들의 업무 부담을 줄이는 것을 목표로 하고 있습니다.



이메일마케팅을 전문으로 다루는 컨퍼런스가 있습니다.

한국에서는 찾아볼 수 없지만 해외에는 이메일마케팅에 특화된 컨퍼런스가 여럿 있습니다. 올해를 기준으로 살펴보면 3월에 Email Evolution Conference가 미국 뉴올리언즈에서 열렸습니다. 4월에는 미국 내슈빌에서 Marketing United가 열렸습니다(제목에는 이메일이 없지만 이 컨퍼런스를 주최하는 Emma가 이메일마케팅 회사이고, 어젠다를 보면 태반이 이메일 관련 내용입니다). 10월에는 영국 런던에서 Email Innovations Summit이 열립니다. 11월에는 스웨덴 말뫼에서 Email Marketing Evolved가 열립니다.


이메일마케팅에 특화되지는 않았지만 주요 세션으로 이메일마케팅을 다루는 컨퍼런스도 있는데요, 2월에 미국 라스베이거스에서 MarketingSherpa Summit이 열렸고, 5월에 오스트레일리아 시드니에서 Search Marketing Summit이, 6월에 캐나다 밴쿠버에서 Unbounce Call To Action Conference가 열렸습니다. 이렇게 관련 컨퍼런스가 많은 것을 보면 디지털마케팅 분야에서 이메일에 대한 관심이 뜨거운 것을 알 수 있습니다.


위에 나열하지는 않았지만 이메일마케팅 컨퍼런스 중 왕중왕이 있습니다. 같은 컨퍼런스가 7월에 런던, 8월에 보스턴, 9월에 샌프란시스코에서 열립니다. 바로 The Email Design Conference(TEDC). 보스턴 컨퍼런스가 가장 규모가 크고, 이 컨퍼런스를 주최하는 Litmus 본사가 근처에 있기 때문에 보스턴에 다녀왔습니다.  


스크린샷 2016-07-11 11.18.48.png


The Email Design Conference는 무엇인가요?


The Email Design Conference, 줄여서 TEDC는 2013년부터 매년 개최되고 있습니다. 올해가 4번째네요. 제목에 ‘디자인'이 들어 있지만, 단지 그래픽에 대한 것이 아니라 그보다 더 많은 것들을 다룹니다. 기획, 전략, 제작(디자인 및 개발), 분석을 모두 다룹니다(마케팅/전략 트랙과 코딩/개발 트랙으로 나뉩니다). 마케팅 이메일을 잘 보이게, 잘 작동되게, 고객의 인게이지먼트가 이루어지게 만드는 방법에 대한 컨퍼런스입니다.



어떤 사람들이 참석했나요?


TEDC에는 개발자, 디자이너, 마케터 등 다양한 직군이 참석했습니다. 참석자들의 이름, 회사, 직책을 사전에 공개되었는데 이를 분석해보면 기획/마케팅 직군이 약 50%, 디자인 직군이 약 28%, 개발 직군이 약 13%였습니다.


기획/마케팅 직군에는 Email Marketing Manager, Digital Marketing Manager, Marketing Operations Manager 등이, 디자인 직군에는 Graphic Designer, Creative Director, Creative Manager 등이, 개발 직군에는 Front-end Developer, Web Developer, Email Developer 등이 있었습니다.



무엇을 기대하나요?


한국에서는 이메일마케팅에 대한 논의가 활발하지 않습니다. 이메일마케팅 컨퍼런스는 커녕 디지털마케팅 컨퍼런스에서도 이메일 관련 세션을 찾아보기 어렵습니다. 이메일마케팅을 업으로 삼고 있는 전문가와 실무자들의 교류도 부족한 상황입니다. 이번 컨퍼런스는 높은 성과를 내는 이메일을 제작하는 데 집중하는 사람들을 만나는 기회였습니다. 여러 세션과 라이브 최적화 워크숍, 전문가 라운드테이블, 그리고 참석자들과의 네트워킹을 통해 이메일마케팅의 새로운 기술, 베스트 프랙티스, 최적화에 영감을 주는 아이디어를 얻어 왔습니다. 앞으로 그렇게 얻은 지식과 경험을 한국에서 적용하고 전파하는 데 힘을 쏟을 생각입니다.


콘텐츠/미디어 스타트업 PUBLY와 함께 ‘이메일마케팅 컨퍼런스 왕중왕을 가다' 리포트를 작성하고 있습니다. 스티비팀이 다녀온 TEDC에 대한 자세한 내용은 이 리포트에서 확인할 수 있습니다. 리포트에 다 담지 못하는 깊이 있고 폭넓은 이메일마케팅의 진수와 노하우를 직접 전수하는 ‘현장 워크숍’도 준비하고 있습니다. 리포트와 워크숍 신청은 PUBLY 웹사이트에서 할 수 있습니다.



작성: 조성도


Posted by slowalk

제가 웹 개발을 시작하고 느낀 점 중의 하나가 세상에 이렇게 많은 모바일 기기가 있었나 하는 것인데요. 아무래도 사용자들이 휴대전화나 태블릿을 PC보다 많이 사용하다 보니 다양한 환경에서 웹페이지가 잘 돌아가는지 테스트하고 오류에 대응하는 일이 큰일이 되었습니다.


이때 빼놓을 수 없는 개념이 ‘반응형 웹(Responsive Web)’입니다. 해상도의 변화, 즉 화면 크기에 따라 레이아웃이 조절되는 웹페이지를 말합니다. 사용자의 입장에서는 어느 기기에서든 같은 콘텐츠를 적절한 화면으로 볼 수 있고, 개발자 입장에서는 기기마다 따로 웹페이지를 개발하지 않아도 되므로 비용을 절감할 수 있습니다. 이런 이유로 반응형 웹은 2010년  ‘A List Apart’라는 웹디자이너 매거진에 처음 소개된 이래로 큰 인기를 얻고 있습니다. (‘2016 꼭 알아야 할 웹 디자인 트렌드’에 나온 반응형 웹 보러가기)


하루가 멀다 하고 모바일 기기들이 쏟아져 나오는 상황에서 반응형 웹은 분명히 많은 어려움을 해결해 줍니다. 하지만 반응형 웹이 인기만큼 큰 효과를 가져다줄 수 있는지는 좀 더 생각해봐야 합니다. 왜 그럴까요? 반응형 웹이면 모바일 대응 끝, 아닌가요?






반응형 웹의 약점


로딩 시간이 길어진다


웹 페이지의 스타일을 결정하는 CSS는 표현의 한계를 가졌던 이전 버전과는 달리 CSS3가 되면서 다양한 표현이 가능해졌습니다. 특히 미디어와 화면 해상도의 정확한 구분이 가능해지면서 기기 각각의 조건에 맞는 스타일을 적용할 수 있게 되었습니다. '@media'라는 CSS문법을 사용해서 '미디어 쿼리'라고 하는데 이것이 반응형의 기본이 됩니다.

하지만 여기서 문제가 발생합니다. 기본적으로 반응형 웹은 처음 페이지가 로딩될 때 미디어 쿼리를 불러오게 되는데, 이때 모든 해상도 대응을 위한 CSS와 이미지 등을 전부 불러오게 됩니다. 사용자가 페이지를 보고 있는 화면 해상도와는 상관없는 다른 해상도의 데이터를 미리 불러오게 되므로 자연스럽게 웹 페이지의 로딩 속도가 지연되고 사용자들은 불편함을 느끼게 됩니다.



복잡한 콘텐츠에는 맞지 않는다


우리나라의 대표 포털 사이트인 네이버나 다음이 반응형 웹을 적용하지 않는 이유는 무엇일까요? 다양한 이유가 있겠지만 주요한 이유 중 하나는 바로 콘텐츠의 복잡성 때문입니다.



네이버(www.naver.com) 다음(www.daum.net)의 웹사이트 메인 화면



 반응형 웹은 해상도를 기준으로 웹페이지의 레이아웃을 변형하는 방법입니다. 이때 레이아웃과 콘텐츠가 복잡하지 않아야 최대 해상도 화면부터 최소 해상도의 화면까지 일관된 사용자 경험을 제공할 수 있습니다.





단순한 레이아웃과 콘텐츠로 구성된 스타벅스(www.starbucks.com)의 반응형 웹



우리나라는 사이트를 구성할 때 상대적으로 많은 정보를 담는 편입니다. 한 페이지에 담는 정보의 양도 많습니다. 물론 이것이 나쁘다거나 트렌드에 뒤처진다는 의미는 아닙니다. 문화적인 특성이죠. 하지만 반응형 웹을 무조건 적용하기에는 우리나라 사용자의 편의성 측면에서 적합하지 않을 수 있습니다. 따라서 콘텐츠의 양에 따라 반응형의 적용 여부를 결정해야 합니다.

콘텐츠의 유형에 따라서도 반응형 웹에 적합한지 구분이 됩니다. 표를 이용한 텍스트가 많은 경우 레이아웃이 변하면서 표의 기능이 약해지며 가독성이 떨어집니다. 글자가 많이 들어간 이미지가 많은 경우에도 이미지 자체가 축소되기 때문에 가독성이 떨어지게 됩니다. 물론 이러한 문제를 해결하는 방법은 있습니다. 텍스트가 들어간 이미지의 경우, 해상도와 레이아웃에 맞게 다른 사이즈의 이미지를 불러올 수 있습니다. 하지만 그 노력에 비해 반응형 웹이 과연 얼마나 효과적인지 생각해봐야 합니다. 추가 콘텐츠를 생성하거나 유지 보수를 하는데 똑같이 많은 노력이 들게 될 테니까 말이죠.

이 외에도 반응형 웹은 HTML5와 CSS3를 기반으로 하므로 추가 개발 없이는 Internet Explorer 8과 같은 하위 브라우저 대응이 어렵습니다. 또한, 상위 버전 브라우저라고 할지라도 각 브라우저별로 적용되는 기준이 달라 크로스 브라우징(웹 표준 기술을 사용하여 브라우저 종류에 구애받지 않고 웹을 이용할 수 있도록 하는 개발을 말합니다.)이 어려운 점도 아쉬운 부분입니다.




대안으로써의 적응형 웹?!


반응형 웹의 이러한 문제점들을 대안으로 ‘적응형 웹’이 떠오르고 있습니다. 반응형 웹과 적응형 웹은 모두 웹 사이트가 다양한 해상도의 화면에서 원활한 정보와 더 나은 UX를 제공하고자 하지만 구현하는 방법은 다릅니다.




반응형 웹과 적응형 웹의 구성 방식 비교




해상도가 변하면 유동적으로 레이아웃이 변하는 반응형 웹과는 달리 적응형 웹은 특정 디바이스, 또는 해상도를 정해두고 그 비율에 맞춰 웹페이지를 구성하는 방식입니다. 적응형 웹은 2011년 Aaron Gustofson의 책 ‘Adaptive Web Design: Crafting Rich Experiences with Progressive Enhancement’를 통해 처음 알려졌습니다. 반응형 웹 개념을 포함하는 포괄적인 개념으로 설명했으나 국내에서는 기술적인 부분에 초점이 맞춰져 통용되고 있습니다.

모든 디바이스에 적용할 CSS를 초기에 로드하는 반응형 웹과는 다르게 적응형 웹은 사용자의 기기가 데스크톱인지, 스마트폰 또는 태블릿인지를 서버나 클라이언트에서 체크하여 그에 최적화된 HTML/CSS을 불러옵니다. 필요한 정보만을 노출하게 되므로 사용자는 접속한 기기에서 좀 더 빠른 속도로 웹사이트를 이용할 수 있습니다.



네이버(www.naver.com)의 적응형 웹(왼쪽부터 차례로 휴대폰/태블릿/PC)



모든 해상도에 레이아웃을 대응하는 반응형 웹과는 달리 적응형 웹은 정교함이 떨어지지만, 정해진 해상도에서는 빠른 속도로 적절한 레이아웃을 제공할 수 있습니다.

 하지만 적응형 웹 역시 여러 단점을 가지고 있습니다. 기기에 맞게 HTML/CSS이나 URL을 분리 개발하는 비용 문제가 발생합니다. 또 새로운 모바일 기기가 시장에 나오면 이에 대한 대응과 개발이 필요한지 고려해야 하는 부분이 생깁니다. 그렇다면 반응형 웹에 대한 완벽한 대안은 없을까요?




기술보다는 사용자 경험


여기서 한 가지 의문이 듭니다. 과연 사용자들은 이 사이트가 반응형 웹인지 아닌지 얼마나 알고 있을까요? 반응형 웹으로 만들어졌기 때문에 들어오고 반응형 웹으로 만들어지지 않았으면 사이트를 박차고 나갈까요?  


모바일 환경에서 뉴스를 읽는 사용자를 고려한 뉴욕타임즈(www.nytimes.com)의 적응형 웹 



반응형 웹이든 적응형 웹이든 사용자는 모바일 기기에서의 웹 접근이 편해졌고, 이에 따라 만족스러운 경험을 하게 되었기 때문에 사이트를 이용합니다. 따라서 기술이 아니라 사용자를 먼저 생각해야 합니다. 제공하는 콘텐츠의 유형과 양을 생각해보고, 모바일 사이트에서 사용자가 어떤 행동을 하기를 원하는지 생각해보아야 합니다. 그리고나서 그 방향이 반응형 웹에 적합한지, 적응형 웹에 적합한지, 아니면 앱을 만들거나 새로운 기술을 도입해야 하는지를 결정해야 합니다.


 반응형 웹은 모바일 시대에 많은 이점을 가져다주는 기술입니다. 세상에 나온 지 얼마 안 된 만큼 앞으로 점점 발전할 것입니다. 이미 반응형 웹의 문제를 극복하려는 방법들이 공유되고 있습니다. (반응형 웹사이트를 빠르게 만드는 7가지 방법 보러가기) 하지만 반응형 웹 기술이 발전하거나 완벽한 대안이 나온다고 하더라도, 반응형 웹이라는 작은 우물에 갇혀 중요한 ‘사용자’를 놓치지 않도록 주의해야 합니다.


출처 : Despreneur, ITDAILY, SMASHING




작성: 김다래



Posted by slowalk

데스크탑, 노트북, 태블릿, 모바일 등 다양한 기기에서 하루 한두 번씩은 접속하는 인터넷을 이용할 수 있게 해주는 웹 브라우저. 대부분의 사람들이 웹 브라우저하면 마이크로소프트사(Microsoft)의 인터넷 익스플로러(이하 IE)를 떠올릴텐데요. IE를 중심으로 다양한 웹 브라우저를 살펴보고 제대로 된 웹서핑을 위한 팁을 살펴보도록 하겠습니다.



웹사이트가 깨져보이고 로딩이 느린 이유

똑같은 웹사이트를 방문하더라도 어떤 웹 브라우저를 사용하느냐에 따라 보이는 화면과 속도가 달라질 수 있습니다. 보통 IE 구버전에서 발생하는 문제인데요. 그 이유를 알아보기 전에 전세계 웹 브라우저 점유율 변화를 살펴보시죠.




출처 : StatCounter 전세계 웹 브라우저 점유율


1995년에 마이크로소프트가 윈도우즈(Windows) 운영 체제에 IE를 기본으로 제공하면서, 1999년 이후로 IE는 세계에서 가장 널리 쓰이는 웹 브라우저가 되었습니다. 특히, 2002년과 2003년에 IE 5, 6 버전의 사용률이 정점에 이르러 95%에 달하게 됩니다. 웹 브라우저 전쟁에서 오랫동안 승기를 잡았던 IE는 Active X 등 다른 웹 브라우저들이 사용하지 않는 기술을 독자적으로 사용하면서 웹표준과는 거리가 있는 길을 걸어가며 시간이 지남에 따라 크롬, 파이어폭스 등에 자리를 내어주게 됩니다.



그런데 KISA(한국인터넷진흥원)에서 발표한 2015년도 자료를 보면 StatCounter의 전세계 웹 브라우저 점유율 분석 자료와는 달리 아직까지 IE의 점유율이 크롬보다 상당히 높게 나오고 있습니다.


헷갈리기 시작합니다. 각 웹 브라우저들의 특징을 살펴보며 왜 이런 상황이 발생했는지 알아보겠습니다.



그럼 어떤 웹 브라우저를 써야 하나요?

국내 웹 브라우저 시장은 용도에 따라 적합한 웹 브라우저가 다를 수 있습니다. 왜 그러한지 웹 브라우저 별 특징을 알려드릴게요. 마이크로소프트의 최신 웹 브라우저는 윈도우즈10에 기본적으로 설치되는 ‘Edge’지만, 현재 국내 점유율을 감안하여 IE로 대신하겠습니다. 아래의 표를 보면 IE가 보안, 웹표준, 기술지원에서 다른 웹 브라우저에 비해 약한 모습을 보여주고 있습니다.



IE

Chrome

Firefox

Safari

제작사

Microsoft

Google

Mozila

Apple

속도

7.50

9.38

9.75

8.75

최신버전

11

52

47

9

(windows :5)

출시

1995.08

2008.09

2004.11

2003.1

보안

△버전별 상이

O

O

O

웹표준(HTML5, CSS3)

△버전별 상이

O

O

O

기술지원

△10부터 지원

O

O

O

오픈소스

X

O

O

X

계정연동

X

O

O

△(윈도우즈 제외)

Active X

O

X

X

X


출처 TopTenReviews, 각 웹 브라우저 공식 사이트


인터넷 익스플로러

윈도우즈 버전에 따라 업그레이드 된 IE는 ‘윈도우즈 98’의 대성공과 함께 점유율이 급상승했고, 한 때는 전세계 시장 점유율 90%를 넘어서기도 했습니다.


IE는 현재 하나의 프로그램에서 지속적으로 업그레이드가 되는 다른 웹 브라우저와 달리 버전별로 따로 존재하고, 각 버전 간의 호환성도 떨어지는 문제가 있습니다. 아직도 많은 분들이 오래된 윈도우즈 운영체제를 사용하고 있고, 그 윈도우즈 버전에 기본적으로 깔리는 IE를 사용하고 있습니다. 높은 버전을 따로 구해서 설치하지 않는 이상 편하게 업그레이드하기가 쉽지 않습니다.


Active X는 공식적으로 마이크로소프트 윈도우즈 운영 체제와 마이크로소프트의 웹 브라우저인 인터넷 익스플로러에서만 작동하고, 컴퓨터 바이러스와 스파이웨어와 같은 악성 코드가 뜻하지 않게 설치될 수도 있는 등 여러 문제점이 있습니다.


마이크로소프트는 지난 2010년, 방송통신위원회, 한국인터넷진흥원, 한국인터넷기업협회와 함께 자사 공식 웹사이트 및 국내 포털3사(네이버 , 다음 , 네이트)를 통해 해킹과 피싱, 디도스 등으로부터 인터넷 이용자들의 안전을 보호하기 위해 IE6 퇴출 및 인터넷 이용 환경 개선 캠페인을 진행하기도 하였습니다.




IE 8이하 구버전의 경우 HTML5, CSS3 등 웹표준에 부족한 모습을 보여주고 있습니다. 이때문에 일부 페이지가 구현이 안되거나 비정상적으로 보이는 문제가 발생 하게 됩니다.


보안 또한 기술지원이 뒷받침되어야 하는데 Microsoft에서는 2016년 1월 12일 이후로 IE 11 이전 버전의 IE에 대한 보안 업데이트나 기술 지원을 전혀 제공하지 않는다고 발표하였습니다.


이런 많은 단점에도 불구하고 현재 국내에서는 Active X로 인해 금융권과 관공서의 필수 프로그램으로 자리 잡고 있습니다. Active X가 완전히 사라지기 전까지는 최신 IE 11로 업그레이드를 권장합니다.




크롬

현재 전 세계에서 가장 많이 쓰이고 있습니다. 다양한 플랫폼을 지원하고 있으며, 크롬 웹 스토어 등 각종 구글 서비스와의 연계가 큰 장점입니다. 빠른 업그레이드 만큼 속도도 빠르고 보안도 강력하여 어디하나 빠지지 않는 팔방미인라고 할 수 있습니다. 다양한 기능 만큼 메모리 사용량이 많은 단점이 있습니다.


파이어폭스

역시 다양한 플랫폼을 지원하며, 오픈소스 웹 브라우저로서 개발자들이 개량 및 재배포를 할 수 있습니다. 다양한 부가기능을 설치할 수 있어, 웹개발자들에게 인기가 많은 웹 브라우저입니다.

사파리

맥OS와 윈도우즈를 둘 다 지원하고 있으나 버전이 다르고 버전이 낮기 때문에 제대로 사파리를 이용하시려면 맥OS의 사파리를 사용하는 것이 좋습니다.


엣지

마이크로소프트가 인터넷 익스플로러를 대체하기 위해 만든 차세대형 웹 브라우저입니다. Windows 10부터 시작하여 앞으로 마이크로소프트의 OS 제품군 및 각종 서비스를 사용하는 모든 장치의 기본 브라우저로 사용된다고 합니다. 가장 최신의 웹 브라우저로서 빠른 속도, 다양한 편의기능, 데스크탑 브라우저 중 최고 수준의 터치 친화성을 보여주고 있습니다. Active X도 작동하지 않아서 IE와는 다른 모습을 보여주고 있습니다.

만약 지금 윈도우즈 10을 쓰신다면 경험해볼 만한 브라우저라고 생각됩니다.


마치면서

스마트폰의 보급으로 기존의 데스크탑 환경은 물론 다양한 기기에서의 웹표준, 웹접근성이 요구되고 있습니다. 보안도 무시할 수 없습니다. 보안에 취약한 웹 브라우저 사용 시 해킹을 당하거나 좀비PC가 될 수 있는 위험성이 있습니다.


기본적으로 인터넷 속도가 빠르고 Active X가 필요한 국내 웹 환경에서는 자신의 상황에 맞는 멀티 웹 브라우징이 필요할 것 같습니다.


하루빨리 Active X없이 웹표준, 웹접근성을 지키면서 은행, 관공서 업무를 마칠수 있는 웹 환경이 구축이 되었으면 하네요.


아무쪼록 안전하고 쾌적한 환경에서 웹을 항해하시길 바랍니다.




작성: 임마로


Posted by slowalk

올 초 인터랙션 디자이너로 스티비에 합류하면서 어도비(Adobe)를 벗어나 다양한 프로토타이핑 툴을 사용했습니다. 그 중 가장 선호하는 툴은 스케치(Sketch)로, 새로 리뉴얼하는 스티비의 90% 이상을 스케치 기반으로 만들고 있습니다. 처음에는 왜 스케치를 쓰는 디자이너가 많아지는 걸까? 의문이 들었는데요. 스케치를 쓸수록 반복적인 업무가 효과적으로 단축되고 협업할 때 편리해서 제게도 다른 툴을 제치고 가장 많이 사용하는 툴로 자리잡았습니다.



지난해, 디자이너 툴 서베이 결과에 따르면 조사 대상자 중 스케치 사용자가 34%, 포토샵 사용자는 29%로 스케치 유저가 포토샵 사용자보다 많았습니다. 기존 유저 중 절반을 스케치에 빼앗겨버린 어도비가 안쓰러울 정도였는데요. 이렇게까지 유저들이 포토샵에서 스케치로 작업 환경을 옮겨간 이유는 무엇일까요? 바로 아직까지 어도비에서 모바일 어플리케이션 제작에 최적화된 툴을 내놓지 않았기 때문입니다.


모바일 어플리케이션 디자인은 화면을 만든 후 끝나는 작업이 아니라 직접 사용해보며 기획한 대로 시나리오가 흘러가는지, 화면 이동이 자연스러운지 여러 번 테스트를 거쳐야 합니다. 이때 스케치로 작업하면 레이어까지 그대로 활용해 프로토타입을 만들 수 있는 여러 도구가 있어 다양한 프로토타이핑을 시도해볼 수 있습니다. 하지만 어도비에서는 Photoshop과 Illustrator에서 만든 작업물을 이미지로 추출한 후 AfterEffect나 Keynote 등을 활용해 프로토타이핑을 하게 되는데, 이때 작업에 필요한 레이어를 추출하는 것부터 쉬운 일이 아닙니다.


이렇듯 UI/UX 디자이너들은 빠르게 프로토타입을 만든 후 논의와 수정을 거쳐 새로운 서비스를 내놓아야 하는 환경에 놓여있는데 어도비의 프로그램은 이런 흐름을 쫓아가지 못하고 기존의 개별 프로그램만 업데이트하고 있던 것이죠. 그 사이 UI/UX 디자이너들은 자신들의 메인 툴을 어도비에서 스케치로 옮겨버리게 된 것입니다.


그렇다면 디자인 프로그램의 제왕인 어도비가 유저들이 마구 이탈하는 상황에서 가만히 손놓고 당하고 있을까요? 아닙니다. 이들도 UI/UX 툴의 춘추전국시대를 재패할 엄청난 무기를 만들고 있습니다. 그것이 바로 “Adobe XD(Experience Design)”입니다.


어도비 XD(Experience Design) 프리뷰 공개


어도비는 스케치의 가장 큰 단점인 “스케치만 사용해서 프로토타이핑까지 끝낼 수 없다”는 점을 노리고 스케치와 스케치 플러그인들의 장점을 합친 XD를 시장에 내놓았습니다(아직 시험판입니다). 근데 이게….시험판인데도 ‘우와!’ 소리가 납니다. 그도 그럴 것이 스케치와 다양한 플러그인 조합을 사용해 만든 편리한 디자인 환경을 어도비 XD 하나로 경험할 수 있게 했다는 점이 어마어마한 장점이기 때문입니다. 특히 디자인과 프로토타이핑을 하나의 어플리케이션에서 작업할 수 있는 것은 어도비 XD가 지금까지 나왔던 자잘한 프로토타이핑 툴과 스케치를 대체할 수 있는 유일한 대체제로 우뚝 설 수 있다는 것을 점을 시사하고 있습니다.


그럼 이제 본격적으로 Sketch와 Adobe XD를 비교해보겠습니다.



쉽게 사용할 수 있는 스티비의 새로운 에디터를 만든 스케치!

스케치의 기본 인터페이스



단순 반복작업을 일괄적으로 처리


스케치를 통해 다양한 사이즈로 이미지를 추출하는 모습



이미지를 다양한 모바일 화면에 적합한 크기로 추출할 때 이미지마다 저장과정을 반복해야 하는 기존 프로그램과 달리 스케치는 다양한 크기와 포맷으로 이미지를 한번에 추출할 수 있습니다.


이런 단순 반복 작업일수록 스케치의 장점이 가장 돋보이는데요. 여러 페이지에 반복해서 사용하는 도형을 “심볼”로 정해놓고 작업 중간에 “심볼” 하나를 수정하면 전체에 반영되기 때문에 일일이 수정하지 않아도 빠르게 작업을 마칠 수 있습니다. 이 밖에도 도형을 만드는 것부터 정렬하는 것 까지 이렇게 편할 수가! 하는 순간들이 한 두 번이 아닙니다.


다양한 협업툴

웹 서비스를 만들 때 기획자-디자이너-개발자간의 원활한 소통이 가장 중요합니다. 이를 위해서 다양한 문서작업을 하게 되는데, 스케치를 활용하면 문서작업에 들이는 시간이 훨씬 줄어듭니다.

먼저 시나리오를 만들때 스케치를 활용하면, 각 화면을 인비전(Invision)과 연동해 시나리오가 제대로 만들어졌는지 간단한 프로토타입을 빠르게 만들어볼 수 있습니다. 시나리오 확인 후, 디자이너는 시나리오 파일에 그대로 디자인을 얹어 작업을 진행할 수 있습니다. 따로 틀을 다시 그릴 필요가 없이 한 파일로 mock-up과 시나리오 프로토타이핑 그리고 디자인까지 연동이 가능합니다.


스케치로 작업한 파일을 제플린으로 확인하는 모습


디자인을 마친 후엔 스케치로 작업한 파일을 제플린(Zeplin)으로 연동하게 되면 자동으로 각 페이지의 asset이 얼마인지 개발자가 보기 편하도록 이미지를 문서로 변환해 보여줍니다. 이때 이미지 파일도 함께 연동할 수 있어 디자이너와 개발자 사이에 쓸데없이 오고 가는 문서의 양과 문서를 제작하는데 걸리는 시간을 획기적으로 줄일 수 있습니다.(Photoshop도 CC버젼부터 제플린을 사용할 수 있습니다.)


만약 텍스트 여백 때문에 제플린에 디자이너가 의도한 정확한 수치가 나타나지 않는다면 measure를 사용해 정확한 간격을 입력할 수 있습니다(지금까지 단점으로 지목된 부분은 어도비 CC에서 많이 개선되었습니다).




스케치에게 빼앗긴 유져를 되찾으려 왔다: 어도비 XD

XD의 시작화면. 다양한 사이즈의 화면을 선택해 디자인을 시작할 수 있습니다.


어도비에서도 UI, UX유저를 겨냥한 어도비 XD를 만들었습니다. 스케치와 다양한 프로토타입 툴에 빼앗긴 기존 유저를 되찾아 올 수 있을까요? 지금은 정식 버전 이전으로 프리뷰 버전만 출시되었지만 앞으로 출시될 XD의 모습을 미리 살펴보도록 하겠습니다.


단축키 = 기존 어도비+스케치

디자이너들은 프로게이머와 견줄 수 있을 정도로 끊임없이 단축키를 누르며 작업합니다. 그런데 스케치와 어도비 계열 프로그램은 서로 단축키가 달라 스케치로 작업하다 Photoshop이나 Illustrator에서 작업을 하게 되면 머리와 손에서 단축키가 충돌을 일으킵니다. 허나 XD는 어도비에서 만든 프로그램 아닙니까! 어도비에서 사용하던 단축키를 그대로 사용할 수 있는 것부터 내집에 온듯 편안한 기분이 들게 해줍니다.(만약, XD에서 단축키는 물론이고 Illustrator와 Photoshop 파일까지 자유자재로 호환이 된다면 유저들은 다시 어도비에 충성을 맹세할 것입니다)


Repeat Grid

Repeat Grid로 반복적인 디자인을 구현하는 XD


스케치에서는 craft 플러그인을 활용해서 만들 수 있는 Repeat Grid를 XD에서는 버튼 하나로 바로 구현 가능합니다. (추측이지만 craft팀에서 XD 데모 영상 중 특별한 툴바 없이 finder에서 파일을 드래그만 하면 이미지와 글이 알아서 변경되는 부분을 보고 뒷목을 잡지 않았을까 싶네요.) Repeat Grid, 이것 하나 만으로도 어도비 XD가 위대해 보이는 부분입니다.


인터페이스

Design과 Prototype 패널로 쉽게 페이지를 오고갈 수 있습니다.


스케치와 흡사합니다. 스케치를 사용하던 유저는 조금 더 쉽게 사용할 수 있습니다. 오른쪽 패널은 정렬과 크기, 컬러 등을 선택할 수 있고 왼쪽은 툴이 나열되어 있습니다. 레이어 창이 없는 것이 스케치와 다른 부분입니다. 디자인과 프로토타입 패널도 쉽게 오고갈 수 있습니다.


디자인과 인터렉션을 한번에. 완벽한 프로토타이핑툴

XD는 프로토타입을 만들때 그 장점이 돋보입니다. 스케치에서는 프로토타입을 만들기 위해서 다른 어플리케이션과 스케치파일을 연동시켜 작업하는 것이 일반적입니다. 반면 XD는 디자인과 프로토타입을 한번에, 하나의 어플리케이션 안에서 만들 수 있는 툴입니다.



만드는 방법도 아주 간단합니다. 화면이 시작하는 지점을 클릭하고 그 다음 나타나는 화면을 선택하고 세부 사항을 정하면 완성됩니다. 이렇게 만든 프로토타입은 웹에서 바로 실행해볼 수 있고 핸드폰으로 미러링해 직접 동작해보는 테스트도 가능합니다. URL도 생성할 수 있어 다른 사람들과 바로 공유할 수도 있습니다.


기존 어도비 유저를 그대로 흡수할 가능성이 높은 XD와 다양한 어플리케이션과 함께하는 스케치. 그 최후의 승자가 누가 될까요. UI/UX툴의 홍수 속에서 어서 빨리 XD 정식버전이 나오길 기대합니다.


참고: adobe XD, design tools survey

작성: 조은지


Posted by slowalk



페이스북은 업계 소식을 빠르게 접하고 공유할 수 있는 좋은 채널입니다. 하지만 정보를 저장하고 관리하기에는 적합하지 않습니다. 저장한 정보를 분류하거나 검색하기 어렵기 때문이죠. 수많은 정보가 실시간으로 흐르는 만큼 들어오는 정보를 통제하기도 어렵습니다.


정보를 통제하고 저장하고 관리하는 데 가장 적합한 도구 중 하나는 RSS였습니다. 적어도 구글 리더가 종료되기 전까지 말이죠. 인과관계를 따지긴 어렵지만 어쨌든 구글 리더가 종료될 즈음 RSS 사용은 줄어들었고 RSS를 지원하는 곳들도 줄어들었습니다. RSS는 IRC*처럼 잊혀진 존재가 됐습니다. (IRC의 향수를 불러일으키는 슬랙의 등장처럼, RSS의 향수를 불러일으키는 뭔가가 언젠가 등장할 수도 있겠죠.)


* IRC: 인터넷 초창기부터 사용된 실시간 채팅 프로토콜입니다. 특정 서비스나 플랫폼에 종속되지 않는다는 장점이 있지만 사용법이 어렵기 때문에 메신저 문화가 정착된 요즘은 거의 사용되지 않습니다.


업계 소식을 빠르게 접하고 정보를 저장하고 관리하는 가장 좋은 방법 중 하나는 큐레이션 뉴스레터*를 구독하는 것입니다.

* 큐레이션 뉴스레터: 여러 정보를 재가공하여 제공하는 큐레이션 서비스에 빗대어 임의로 붙인 이름입니다. 큐레이티드(curated) 뉴스레터, 다이제스트(digest) 뉴스레터라고 부르는 게 의미상 더 정확합니다.

큐레이션 뉴스레터는 양질의 정보를 모아서, 요약까지 해서 보내줍니다. 이메일 서비스의 필터링, 라벨 기능을 사용하면 정보를 쉽게 통제하고 저장하고 관리할 수 있습니다. 당연히 검색도 쉽습니다.


디자이너라면 디자인에 대한 뉴스레터를 2-3개 정도 구독해보세요. 수많은 웹사이트, 블로그를 찾아다닐 필요없이 양질의 정보를 얻을 수 있습니다. 페이스북에서 스쳐간 정보를 다시 찾기 위해 고생할 필요도 없습니다. 페이스북을 통해 접하는 대부분의 정보들은 이미 어디선가 웬만큼 이슈가 됐던 것들이고 이곳저곳을 떠돌다 내 타임라인에 비로소 나타난 것입니다. 뉴스레터를 구독하면 - 적어도 국내에선- 누구보다 빨리 업계 소식을 접할 수 있습니다.


저는 업의 특성상 - 이메일마케팅 서비스인 스티비를 만들고 있습니다 - 온갖 뉴스레터를 구독하고 있습니다. (온갖 뉴스레터를 구독하다보니 페이스북 타임라인처럼 “받은편지함"에 정보가 빠르게 쌓이지만 필터링과 라벨 기능을 사용하여 주제별로 뉴스레터를 분리하여 관리하고 있습니다.)



라벨을 만들고 조건에 따라 라벨로 이동하는 필터를 만들면 주제별로 이메일을 분류할 수 있습니다.



직접 엄선한 디자인 관련 뉴스레터를 소개합니다.


물론 이 모두를 다 구독할 필요는 없습니다. 구독하지 않아도 과거에 발행된 내용을 볼 수 있으니, 내용을 살펴보고 취향에 맞는(내용의 종류, 길고 짧음, 텍스트 위주인지 이미지 위주인지 등) 걸 골라서 구독하는 것을 권장합니다. 물론 구독한 뒤에 마음에 들지 않으면 언제든 수신거부 할 수 있습니다.


Sidebar 구독하기

5개의 디자인 관련 소식과 정보를 공유합니다. 디자이너가 아니어도 가볍게 읽을 수 있는 글들이 많습니다. 매일 발행합니다.


이 뉴스레터에서 읽어볼 만한 콘텐츠 3

  1. Prototyping for the web with Framer
  2. What we learned designing a car user experience
  3. New Logo and Identity for MasterCard by Pentagram


UX Design Weekly 구독하기

UX 디자인과 관련된 소식과 정보를 공유합니다. UI 또는 GUI 리소스, 포트폴리오 등 실무에 도움이 되는 자료도 제공합니다. 주 1회 발행합니다.


이 뉴스레터에서 읽어볼 만한 콘텐츠 3

  1. Design Better Forms
  2. Landing Page UI Kit
  3. Gabriel Valdivia's UX portfolio


Product Design Weekly 구독하기

프로덕트 디자인 관련 소식과 정보를 공유합니다. “프로덕트"라는 단어가 제목에 들어있는 만큼 디자인 뿐만 아니라 제품 기획이나 시장과 관련된 내용도 다룹니다. 주 1회 발행합니다.


이 뉴스레터에서 읽어볼 만한 콘텐츠 3

  1. What makes PokémonGo so Addictive? - A Mobile Product Manager's Perspective
  2. Metrics versus experience
  3. The Designer’s Guide to AI — a $70 Billion industry by 2020



Designer News 구독하기

Designer News 커뮤니티에서 공유된 글 중 인기가 많은 것들을 모아 공유합니다. 업계의 새로운 소식을 주로 다룹니다. 커뮤니티 성격이기 때문에 디자이너들의 의견 교환도 활발하게 이루어집니다. 주 1회 발행합니다.


이 뉴스레터에서 읽어볼 만한 콘텐츠 3

  1. Show DN: I redesigned Sidebar.io (sidebar.io)
  2. The :target CSS Trick (bitsofco.de)
  3. Google Fonts (fonts.google.com)


UI Movement 구독하기

UI 애니메이션을 Animated GIF로 공유합니다. 다른 내용없이 Animated GIF 이미지로만 구성되어 있습니다. 매일 또는 주 1회 발행합니다. 구독할 때 선택할 수 있습니다.



이 외에도 HeyDesigner, Hacking UI, The Web Designer 추천합니다. 다음에는 디자이너가 아닌 다른 직군을 위한 뉴스레터를 소개할 예정입니다.



Posted by slowalk