전체 피드 목록

Overview기고 제안을 받자마자 iOS 개발을 시작했을 때가 떠올랐습니다. 신대륙을 마주한 것 같았던 그때의 기분을 아직도 잊지 못하기 때문입니다. 당시까지만 해도 Android 개발만 했기 때문에 iOS는 그야말로 미지의 영역이었습니다. 게다가 개발을 시작하려고 조심스럽게 첫 발을 내딛은 순간, 입이 떡 벌어질 수밖에 없었죠.“이렇게 느린 IDE가 있다니…““개발자 프로그램이 뭐 이렇게 비싸?”XCodeXCode는 그동안 접했던 IDE 중에서도 가장 최악이었고, 개발자 프로그램 등록은 13만 원 상당의 비용을 지불해야 했습니다. 가장 중요한 건 맥 컴퓨터(Macintosh)를 보유해야만 했죠. 처음 개발을 시작하려니 넘어야 할 산이 매우 많았습니다. 맞습니다. 팜므파탈의 대명사 마타하리(Mata Hari)처럼 iOS 개발은 밀당과도 같습니다. 분명 매력적인 일이지만 XCode와 개발자 프로그램 등록은 빙산의 일각이기 때문입니다. iOS는 곳곳에 구덩이를 파고 초보 개발자들을 집어삼킬 준비를 하고있습니다. (예를 들면 리소스를 묶어놓은 R.java 파일 같은 레퍼런스가 없습니다. 흑.)그래서 준비했습니다. 수많은 초보 개발자들이 iOS의 구덩이를 피해갈 수 있는 팁을 말이죠.iOS의 구덩이를 피하는 11가지 방법1.비싼 맥(Macintosh)을 사세요.iOS 개발자에게 MacOS는 필수입니다. XCode가 MacOS만 지원하기 때문입니다. 오픈 소스로 공개된 Swift에는 제약이 없지만 XCode는 MacOS에서만 동작하는 제약이 있습니다. 따라서 맥은 iOS 개발자에게 가장 필요한 준비물입니다. 게다가 하드웨어 리소스를 많이 사용하는 XCode 탓에 더 크고, 더 비싸고, 더 아름다운 맥을 구매하셔야 합니다. Macbook이나 Macbook Air 모두 추천하지 않습니다. 15형 Macbook Pro 모델을 비롯해, Mac Pro나 iMac Pro 등의 고급 모델을 사용하면.. 개발이 잘 됩니다.2.돈을 내세요.iOS를 개발하려면 가장 먼저 Apple Developer Portal에서 연 129,000원의 개발자 프로그램에 등록해야 합니다. XCode를 사용해서 코드만 볼 것이라면 문제가 되지 않지만, 디바이스에 앱을 설치하고, 테스트하며, AppStore에 배포할 거라면 반드시 구매해야 합니다. 이 계정은 앞서 말한 것처럼 1년이 지나면 다시 구매해야 합니다. 만약 기업 개발자로 등록하려면 Enterprise Program이 따로 준비되어 있습니다. 기업을 위해 특화된 In-House 배포 등의 이점이 있습니다. 구매해야할 것이 꽤 많죠? 이제 익숙해져야 합니다.3.XCode를 설치하세요.XCode는 Mac App Store에서 설치할 수 있습니다. 용량이 크기 때문에 설치하기 전에 하드디스크 저장공간부터 확인하는 것이 좋습니다. 처음 실행하면 추가 컴포넌트를 다운로드하는 과정이 실행되고, 그 이후에 XCode를 사용할 수 있습니다. XCode와 관련된 자세한 내용은 아래에서 자세하게 다루겠습니다.4.어려운 것에 대비하세요.1)인증서‘들’XCode 설치 이후에도 몇 가지를 발급 받고, 셋업해야 합니다. 방 탈출 게임처럼 한 단계 한 단계 거치는 과정이 필요합니다. 첫 번째로 인증서‘들’을 발급받아야 합니다. 애플을 대신해 앱을 설치하고, 배포할 수 있는 권한을 위임 받는 과정입니다. 이 인증서들은 Apple Developer Portal의 ‘Certificates, IDS & Profiles’ 항목에서 발급 받을 수 있으며, MacOS의 키체인 앱을 이용해 개인 키를 생성하는 방식으로도 방식으로 발급 받을 수 있습니다. 2)디바이스 등록디바이스-iOS-에 개발한 앱을 설치하려면 애플 개발자 계정에 개발용 디바이스를 등록해야 합니다. 이 과정은 XCode에 신규 디바이스를 연결하고, 빌드 및 배포를 할 때 XCode가 알아서 합니다. 만약 디바이스를 보유하고 있지 않은 상황이라면 해당 디바이스의 UUID를 받아서 개발자 포털에 직접 등록할 수도 있습니다. 3)Bundle IDBundle ID는, 앱의 고유한 ID입니다. iOS가 앱을 식별할 때 사용하는 식별자이며, 보통 ‘com.companyname.appname’ 의 형식으로 회사나 개인의 도메인을 거꾸로 쓰는 것이 보편적입니다. 하지만 Bundle ID는 어디까지나 개발자가 결정하는 영역이므로 인스턴스 이름 지정하듯이 자신만의 고유한 방법을 사용해서 Bundle ID를 지정해도 문제가 없습니다. 4)Provisioning ProfileProvisioning Profile은 디바이스 정보와 앱 정보, 인증서 정보를 매핑해주는 Profile입니다. 최신 XCode에서는 이 Provisioning Profile을 자동으로 관리해주기 때문에 따로 신경쓰지 않아도 좋습니다.5.개발자 포럼에 질문하거나, StackOverflow에 질문하거나!질문하는 사람은 아름답습니다. 궁금하거나, 잘 안 풀리는 코드는 개발자 포럼에서 질문할 수 있습니다. 대신 영어 실력이 좋아야 합니다.크게 기대는 하지 않는 것이 좋습니다. 등록된 discussion에 대한 답글들이 ‘나도 같은 상황이다’, ‘나도 궁금한 점이다’ 등의 다른 개발자들의 답변 정도가 일반적이기 때문이죠.그들의 답변...저는 개발자 포럼보다 StackOverflow를 더 선호합니다. 참여하는 개발자 규모가 다르기 때문에 보다 양질의 정보를 빠르게 찾을 수 있습니다. (하지만 허위 정보도 존재합니다.) Vote 시스템으로 신뢰 높은 정보를 필터링할 수 있으나, 어떤 정보를 선택할지는 당신의 몫입니다.6. iTunesConnect와 친하게 지내세요.앱을 개발했다면, iTunesConnect를 통해 앱을 전 세계의 사용자들에게 배포할 수 있습니다. iTunesConnect는 iOS용으로 개발된 바이너리를 배포하는 등 앱 배포/테스트와 관련된 전반적인 사항들을 관리할 수 있는 포털입니다. AppStore에서 앱을 판매하려면 이 iTunesConnect를 통해 애플과 계약을 해야만 가능합니다. 출시할 앱을 등록하기도 하고, 앱의 사용자들이 어떤 경향을 보이는지 Trend Analysis를 확인할 수도 있습니다.iTunesConnectiTunesConnect에는 다양한 메뉴들이 있고, 앱을 배포하고 관리하는데 필요한 여러 툴이 있으므로 개발 중에 시선을 환기하고자 한다면 iTunesConnect를 한 바퀴 둘러보는 것도 좋습니다. 언젠가는 다 사용하게 될 테니까요.7.앱 개발을 마쳐도 XCode를 사용하세요.앱을 개발하고 iTunesConnect에 업로드하려면, XCode를 통해 간접적으로 바이너리를 업로드하게 됩니다. 서드파티 앱을 사용할 수도 있지만, 제가 주로 많이 사용하는 방식은 XCode입니다. 소스코드가 준비되었다면, XCode 메뉴의 Product > Archive 메뉴를 선택해 XCode가 배포용 앱을 빌드합니다. 빌드가 완료되면, 자동으로 Organizer 창이 열리면서 앱을 업로드할 수 있게 되죠. 이 때 미리 구매한 개발자 계정의 인증서가 준비되어 있어야 합니다. 모든 준비가 완료되고 아카이빙이 완료되면, Organizer의 Archives 탭에서 우측단의 ‘Upload to App Store…’ 버튼으로 바이너리 업로드를 진행할 수 있습니다.8.배포 전에 시험비행을 해봅시다.앱을 개발했다면, 테스트플라이트(TestFlight)를 통해 실제로 앱을 배포하기 전 ‘시험비행’을 할 수 있습니다. iTunesConnect에 관련 테스터들을 등록하고, 등록된 사용자들을 대상으로 미리 앱을 테스트할 수 있도록 요청하는 것이죠. 이 테스트플라이트에 배포된 바이너리를 그대로 AppStore에 배포하게 되므로, 테스트용으로 유용합니다.TestFlight테스트플라이트는 원래 iOS 배포 관리 솔루션을 제공하는 업체였지만 지금은 애플이 인수해 iTunesConnect에서 관리하도록 제공하고 있습니다.9.앱이 죽는다면 Organizer로 확인하세요.iOS는 충돌보고 Crash Report를 Organizer를 통해 오류를 확인합니다. 앱을 설치한 사용자가 동의하면 XCode는 iOS가 앱을 실행하면서 발생한 Crash Report를 애플에 자동으로 업로드합니다. 업로드된 Crash Report들은 XCode의 Organizer를 통해 다운로드하고, 확인할 수 있습니다. Organizer는 XCode > Window > Organizer 항목에서 실행하세요.Organizer와 Crash ReportCrash Report는 Organizer의 상단 Crashes 탭에서 확인이 가능합니다. 또 현재 보고 있는 Crash Report의 어느 부분에서 오류가 발생했는지 알고 싶다면 우측단의 ‘Open in Porject…’ 버튼을 눌러보면 됩니다.10.내 친구 XCode최근 XCode는 메이저 업데이트를 통해 사용성과 퍼포먼스를 향상시켰습니다. 하지만 이만큼 무겁고 느린 통합개발툴 IDE는 이클립스(Eclipse) 이후에 처음입니다. 안드로이드의 경우 IntelliJ 기반의 Android Studio로 쾌적한 개발환경을 제공하고 있는 반면, XCode의 업데이트는 퍼포먼스나 사용성 개선보다는 Swift의 메이저 버전 반영에 더 급급한 느낌입니다. (업데이트 때마다 속지만 ‘혹시 이번에는..’하고 또 속아 넘어갑니다.) XCode 사용을 위한 네 가지 팁을 소개합니다.1)XCode는 모노로그입니다.XCode는 로그를 따로 ‘예쁘게’ 볼 수 없습니다. 검은 화면에 흰 로그가 정리되지 않은 상태로 마구마구 출력됩니다. 개발자들에게는 쥐약같은 상황이죠. 이런 불편한 로그 출력 방식 때문에 저는 별도의 GlobalLogger 모듈을 작성해서 다음과 같은 스타일로 로그를 출력하도록 하고 있습니다.$$ BrandiLogger Error Log ##MESSAGE: Initial Parameter is not exist. ##LOCATION: BRLogPringer.swift @Line: 122 2)iOS개발자를 위한 휴식시간, 빌드 타임XCode의 빌드 타임은 개발자에겐 기나긴 휴식 시간입니다. 소스가 비대해질수록 퍼포먼스는 떨어지며, 담배 한 대를 태우고, 화장실에서 손을 씻고 들어와도 빌드가 절반도 안 된 상황을 마주할 겁니다. 빌드 타임을 줄이고자 구글링을 하면 몇 가지 팁을 발견할 수 있는데, 특히 빌드 타임을 가장 많이 단축할 수 있는 방법이 있습니다.짜잔! 공개합니다!먼저, 프로젝트 셋팅의 ‘Build Settings’ 항목에서 ‘Optimization Level’을 검색합니다. ‘Swift Compiler - Code Generation’ 항목을 찾을 수 있는데요. 여기서 Optimization Level의 Debug 항목을 ‘None’으로 설정하면, 빌드시간이 엄청나게 줄어든 것을 확인할 수 있습니다. Brandi iOS 버전의 소스코드는 원래 컴파일에 7분 이상이 소요되었지만, Optimization Level을 변경한 후 1분 내외로 단축되었습니다. Optimization Setting을 변경할 때는 꼭 Debug 항목만 변경하고, Release 버전은 기존 설정을 유지하는 것이 좋습니다. 그래야 빌드 과정에서의 버그를 막을 수 있기 때문이죠. 만약 이 설정으로 개발하던 도중 소스가 충돌되면 Command+Shift+K 단축키를 눌러 소스를 한 번 클린하고, 재빌드하세요. 충돌이 사라지는 경우가 많습니다. 빠른 빌드를 위해 종종 감수해야 하는 부분이기도 합니다. 3)Derived Data빌드가 자꾸 안되고 꼬일 때는 Derived Data 폴더를 삭제 해 보세요. Derived Data 폴더는 XCode > File > Project Settings(Workspace Settings) 항목에서 ‘Derived Data’ 항목 아래의 폴더 경로에서 접근할 수 있습니다. Derived Data 접근 경로Derived Data 폴더를 삭제하면 거짓말처럼 빌드 오류가 사라지는 기적을 만날 수 있습니다. 4)CocoaPods‘바퀴를 두 번 발명할 필요는 없다’는 격언이 있습니다. 이것을 개발에 적용하면 ‘잘 만들어진 라이브러리를 사용하라’ 정도가 되겠습니다. 개발자의 개발 시간을 현저하게 단축시키는 오픈소스 라이브러리. 이것들을 간편하게 사용하는 방식이 iOS에도 존재하는데, 바로 CocoaPods입니다. 프로젝트 Root 폴더에 Podfile을 생성하고, 원하는 오픈소스 라이브러리들을 명시한 후에 ‘pod install’ 명령어를 입력해주면….CocoaPods오픈소스 라이브러리가 설치되었습니다. 귀찮은 소스 다운로드와 임포트 과정을 거치지 않아도 됩니다. CocoaPods 설치와 사용에 관한 글은 구글링으로 쉽게 찾을 수 있습니다. 꼭 사용하길 권합니다.Mac App Store에서의 XCode 평점XCode는 느리고 불편합니다. 숨겨진 편의기능도 많지만 고질적인 빌드 문제와 사용성 문제를 마주하면 높은 평점을 줄 수가 없습니다. 그런데, 저만 그렇게 생각하진 않더라고요.(위 스크린샷 참조) XCode의 사용법은 기회가 되면 따로 정리하겠습니다.11.어떤 경우에도 대응할 수 있는 화면 구성을 원한다면, AutoLayoutiOS를 사용하면서, 금융권이나 쇼핑 앱들을 사용하다 보면 이런 상황이 발생합니다. 금융권 앱. 화면에 꽉 차지 않는 레이아웃 혹은 비정상적으로 커진 글씨본래 iOS는 단일 디바이스를 지향하는 플랫폼이었습니다. 아이폰 시리즈도 해상도가 변하지 않았기 때문에, 디바이스 종류가 많은 안드로이드처럼 다양한 스크린 사이즈를 지원할 필요가 없었습니다. 하지만 이제는 iPhone SE, iPhone 8, iPhone 8 Plus의 해상도에 iPhone X의 해상도까지 더해지면서 그야말로 ‘해상도 춘추전국시대’가 되었습니다.이런 다양한 해상도를 모두 지원하는 레이아웃을 구성하려면, iOS에서는 AutoLayout을 사용해야 합니다. AutoLayout은 Xib Editor에서 AutoLayout을 활성화하는 방식으로 사용할 수 있습니다. 거기에 한 가지 덧붙이면 Layout Constraints라는 개념도 있습니다. 레이아웃에 조건을 주는 방식입니다. 예를 들어 ‘어떤 해상도에서든 이 컴포넌트는 왼쪽 끝으로부터 10Point의 여백을 가지도록 한다’ 라는 식이죠. AutoLayout, Layout Constraint이 Layout Constraint를 이용하면 짧은 시간 안에 다양한 해상도를 지원하는 레이아웃을 쉽게 만들 수 있습니다. 가히 AutoLayout의 꽃입니다.ConclusionXCode/iOS 개발과 관련된 팁은 대부분 구글링으로 찾을 수 있습니다. 다룰 내용이 많지만 초보 iOS개발자들이 당황할 수 있는 내용을 중심으로 글을 썼습니다. 소소한 이야기지만, 분명 도움을 받을 수 있을 겁니다.글이정환 과장 | R&D 개발1팀[email protected]브랜디, 오직 예쁜 옷만#브랜디 #iOS #개발기 #업무환경 #인사이트 #경험공유

나는 바크 (Bark)라는 이름의 개의 대화법을 적용하여 주변의 서로 모르는 사람들과 소소한 소통이 가능하게 만들어주는 위치기반 채팅 서비스를 운영하고 있다. 이에대한 디자인 이야기는 예전에 쓴 '대화의 장벽을 허무는 UX' 글을 참고하시길 바란다. 오늘 글에서는 이번에 새롭게 런칭한 신기능 이면에 고민했었던 UX 기획 이야기를 좀 풀어보고자 한다.소셜미디어 메인 인터페이스의 양대산맥: 타임라인 VS 카드스와이프개인적인 의견이지만, 세상의 수백가지의 소셜미디어 서비스들의 메인인터페이스는 사실 페이스북으로 대표되는 타임라인 방식과 틴터로 대표되는 카드스와이프 방식으로 양분된다고 생각한다. 타임라인 방식이란, 유저의 메인화면에 사람들이 포스팅한 컨텐츠를 순차적으로 (Chronological Order) 아래로 스크롤 하며 보여주는 방식을 말하고, 카드스와이프 방식이란 컨텐츠를 하나씩 메인화면에 띄워주고, 유저는 제안된 컨텐츠를 왼쪽/오른쪽으로 스와이프 하는 방식으로 컨텐츠를 소비하는 인터페이스를 말한다.유저 입장에서 위 인터페이스가 어떤 의미가 있는지 우선 생각해 보자. 우선 타임라인 방식의 경우 유저의 컨텐츠 소비 편의성에 초점이 맞춰져 있다. 유저가 수 많은 소셜미디어 계정에서 올라오는 컨텐츠를 직접 찾아다닐 필요 없이 그냥 메인 피드에서 순차적으로 보여지는 컨텐츠를 스크롤 쭉쭉 내려가며 소비하는, 마치 잘 차려진 밥상에서 내가 먹을 음식만 젓가락으로 콕콕 찝어가며 소비하는 방식이다. 옛날 원조 소셜미디어인 싸이월드나 마이스페이스와 비교해보면 이 타임라인 방식이 얼마나 편리한지 이해할 수 있다.싸이월드는 유저가 일일이 게정을 들어가서 컨텐츠를 소비하는 방식이였다. (사진 출처 - http://zodiacsword.tistory.com/211)반면, 틴더로 대표되는 카드 스와이프 방식은 타임라인 방식과 싸이월드같이 계정에 일일이 들어가서 컨텐츠를 소비하던 방식의 장점을 적절하게 섞은 방식이다. 타임라인 방식의 경우 발생하는 가장 큰 문제는 크게 1) 차려진 밥상에 음식이 너무 많을 경우 모든 음식을 맛보기가 힘들다는 것과 2) 계정보다는 컨텐츠가 부각되어 사람들을 '소셜라이징'하게 만들기 보다는 '수동적 소비'만 하게 만든다는 단점이 있다. (실제로 페이스북 계정의 45% 이상이 Lurkers, 즉 컨텐츠 업로드 없이 수동적으로 남의 컨텐츠만 쳐다보고 있는 사람들이라는 통계도 있다.)페이스북의 45%는 컨텐츠 공유 없이 타인의 컨텐츠만 소비하는 사람들이라고 한다.카드 스와이프 방식은 위에 언급된 단점을 절묘하게 개선하면서도 여전히 유저 편의성을 유지시키는 방식이라고 할 수 있다. 즉, 유저는 여전히 타임라인 방식 처럼 다른 사람 계정을 일일이 들여다 볼 필요 없이 잘 차려진 밥상을 수동적으로 소비만 하면 된다. 하지만 밥상에 있는 음식을 하나씩 내 앞에 들이밀어줌으로써 내가 직접 맛보면서 음식을 계속 먹을지, 버릴지를 결정할 수 있게 해 주고, 더 나아가 그 음식이 맘에 들었을 때 음식을 만든 사람과 추가적인 교류를 유도하는 방식인 것이다.위치기반+즉시성에 맞는 인터페이스란바크 앱이 유저에게 전달하고자 하는 핵심 경험은 '언제 어디서나 지금 바로 내 주변과의 교류'라고 할 수 있다. 즉, 바크에서 컨텐츠가 소비되는 방식의 핵심 성공요인은 (Key Success Factors) '지금 내 주변'이라는 위치기반의 맥락 조성, 그리고 '즉시 주변 사람들과 감정을 교류'한다는 컨텐츠 공유-소비의 즉시성 담보 이 두개에 모든게 달려있다고 해도 과언이 아니다. '개처럼 서로 짖다'의 UX 이면에는 사실 저 두가지 KSF를 달성하기 위한 중요한 목적이 있는 것이다. 이 목적을 달성하기 위한 새로운 컨텐츠 공유 인터페이스로 위에서 언급했던 타임라인 방식과 카드 스와이프 방식은 모두 다음과 같은 이유로 부적합하다.1) 즉시성이란 몇시간만 지나면 이미 즉시성의 가치를 잃고 만다.타임라인 방식은 스크롤을 아래로 조금만 내려가도 (카드스와입 방식은 스와입을 옆으로 10번만 해도) 이미 반나절 전, 어제, 심지어 몇일 전 컨텐츠 까지 쭉쭉 읽어 내려가기 마련이다. 이미 몇 시간 전의 일도 가물가물 해질 정도로 바쁜 세상에서 살아가는 현대인들에게 타임라인 방식으로는 즉시성이 담보된 컨텐츠를 교환한다는 목표를 달성시키기 어렵다. Short-term memory 연구로 유명한 Atkinson and Shiffrin의 논문에도 인간의 단기 기억 용량은 최대 30초를 넘기지 않는다고 나와있다. 즉, 이미 30초만 지나가도 해당 기억은 working-memory에서 long-term memory영역으로 넘어가거나 사라진다는 뜻이다. 물론 타인의 컨텐츠가 몇시간 전에 형성된거랑 본인의 단기기억과는 아무런 관련이 없는 얘기지만, 얘기하고자 하는 바는 인간의 '즉시성'이란 그만큼 하루, 이틀의 단위가 아닌 한시간, 두시간의 아주 짧은 term에 해당하는 영역이라는 걸 강조하기 위함이다.2) 밥상을 차려주는 순간 이미 위치기반의 맥락을 잃고 만다.타임라인이던 카드스와입 방식이던간에 대부분의 소셜미디어 메인화면은 자체 알고리즘에 의해 유저에게 컨텐츠 밥상을 차려주기 마련이다. 아무리 내 근처에 있는 컨텐츠를 위치순으로 정렬해 준다 하더라도 이미 밥상을 차려줘서 보여주는 순간 위치기반의 맥락을 형성시키기 매우 어렵다고 생각한다. 이유는 두가지가 있는데, 첫째, 위치 기반이란 '나'라는 객체와 '주변'이라는 객체들이 한 공간영역에서 구분 가능해야 형성되는 개념인데 타임라인, 카드스와입 방식 모두 '나'라는 객체는 생략해 버리기 마련이다. 또한 '주변'을 느끼게 만드는 인터페이스는 그저 필터에 '가까운 순'이라는 버튼 하나가 다이다. 유저가 그 '가까운 순'이라는 필터를 지속적으로 기억해주고 있지 않는 한 스크롤을 조금만 내려가도 이게 '위치기반 이구나' 하는 맥락 형성은 실패하게 된다.이런 이유로 바크에는 타임라인이나 카드스와입과는 다른 새로운 방식의 컨텐츠 소비 인터페이스 고안이 필요하게 되었다.Locale Mapping과 개의 대화법과의 결합위치기반 맥락을 가장 잘 살려줄 수 있는 인터페이스는 사실 우리에게 이미 너무나도 친숙한 인터페이스가 존재한다. 바로 지도기반 (Locale Mapping) 인터페이스 이다. 유저에게 유저 객체와 주변객체를 공간영역에 뿌려주는 지도기반만큼 위치기반 맥락을 잘 전달할 수 있는 인터페이스는 존재하지 않는다. 문제는, 이 로케일맵핑 방식을 소셜미디어의 컨텐츠 공유 방식과 적절히 결합시키는 것인데, 이게 쉬운 과제는 아니다. 이미 Periscope라는 라이브스트리밍 앱에서 지도기반의 스트리밍 인터페이스를 구현한 이력이 있지만, 유저 편의성 부분에서 단점이 많아 지금은 타임라인 방식과 지도기반을 병행해서 보여주고 있고, 타임라인 방식이 메인 인터페이스로 변화되가고 있다.유저가 직접 포인팅 된 컨텐츠를 클릭해서 들어갔다 나갔다를 반복해야 하는 로케일 맵핑은 소셜미디어 컨텐츠 공유 인터페이스로서 유저에게 절대로 편리한 방식이 아니고, 이를 아무리 변형한다 해도 기본 골격상 유저 편의성을 담보하기 쉬운 방식이 아니기 때문에, 우리는 아예 방향성을 바꿔서 유저로 하여금 이런 불편함을 감안해서라도 로케일 맵핑방식이 당연하다고 여기게끔 하는 스토리를 부여하고, 이를 컨벤션화 하는 방법을 선택했다. 바로, '개의 대화법'과의 결합이다.바크에서는 이미 모든 유저가 '개의 대화법'으로 소통한다는게 메인 컨벤션이 되어 있다. 개가 아무 맥락없이 서로 짖어대고 단타성 짙은 커뮤니케이션을 하듯이 바크에서도 모두가 뜬금없이 서로 짖어대고 아무 맥락없는 소소한 대화들을 (속된말로) 지껄여 대는 그런 공간이 형성되어 있는 것이다. 여기에서 더 나아가 우리는 '개가 메시지를 남기는 방법'에 대한 고민을 해 보기 시작했다. 즉, 서로 짖는게 사람의 경우 서로 실시간 대화를 나누는 행위라면, 사람들이 뭔가 쪽지를 남기거나 메시지를 전달하기 위해 하는 행위가 개의 경우 뭐가 있을까를 고민하다가 영감을 얻은 행위가 바로 개의 '똥을 누는' 배변행위이다.알다시피, 개는 똥/오줌과 같은 배변행위를 통해 본인의 메시지를 해당 장소에 남겨놓고, 다른 개들은 그 냄새를 통해 '이건 내 영역이다,' '나 오늘 참 행복하오' 등등의 메시지를 읽는다. (물론 생물학적으로 정확한 표현은 아니다. 그저 인간의 레벨에서 해석하기에 저런 행위를 할 것이라는 추측 정도이다.)이 행위를 인터페이스화 하기 위해 구현하게 된 것이 바로 '드랍 바크'라는 신기능이다. 유저는 마치 개가 현재 위치에 똥을 누듯이, 본인의 현재 감정이나 자랑하고 싶은 내용을 현재 위치에 떨어뜨려 놓는다. 이렇게 떨어뜨려진 '똥'들이 로케일 맵핑방식으로 내 주변에 형성되고, 메인화면에서 저렇게 '똥'으로 개체화된 컨텐츠로 보여준다. 이 '똥'을 열면 유저가 남긴 이미지+텍스트가 조합된 메시지가 보여지고, 유저들은 이 메시지에 대해 나도 같이 신난다는 의미의 'Happy,' 본 메시지가 별로거나 불쾌하다는 의미의 'Angry'를 사정없이 눌러댐으로써 본인의 감정을 표현할 수 있다.또한, 앞서 언급한 '즉시성'을 강조하기 위해 모든 메시지는 기본 4시간이 지나면 사라지는 휘발성 메시지로 디자인 했다. 위의 오른쪽 화면 중간에 있는 바가 현재 그 포스트의 남은 수명을 나타내는 바 이고, 4시간이 지나면 그 메시지는 맵에서 사라지게 된다. 마치 똥이 식어서 냄새가 사라지는 것 (또는 냄새가 약해져서 메시지로서 가치가 떨어지는 것)과 같은 것이다. 여기에 재미요소를 주기 위해 다른 유저들이 'happy'보트를 한번 할때 마다 포스트의 수명이 1분씩, 'angry'보트를 할때마다 1분씩 감소하도록 설계했다. 본 인터페이스의 더 자세한 내용은 다음 동영상을 참고해 주시길 바란다.https://www.youtube.com/watch?v=jAFZ5Upu_7k<iframe width="700.000000" height="394.000000" src="//www.youtube.com/embed/jAFZ5Upu_7k" frameborder="0" allowfullscreen="">드랍바크 소개영상안드로이드까지 정식 오픈한지 약 일주일이 안된 지금 하루 약 30% 이상의 활성유저들이 열심히 똥바크를 싸고 있다. 물론 모든 유저가 사용중인 기능도, 모든 사용자가 만족하고 있는 기능은 아니지만 현재까지 반응은 매우 긍정적인 편이고, 앱 내에서 뭔가 소비할 컨텐츠가 생겼다는 점, 그리고 '개의 대화법'이라는 앱의 컨셉을 더욱 공고히 하는 인터페이스라는 점에서 향후 앱의 체류시간 및 리텐션율을 높이는데 긍정적인 역할을 할 것으로 예상하고 있다.글쓴이는 스팀헌트 (Steemhunt) 라는 스팀 블록체인 기반 제품 큐레이션 플랫폼의 Co-founder 및 디자이너 입니다. 비즈니스를 전공하고 대기업에서 기획자로 일하다가 스타트업을 창업하고 본업을 디자이너로 전향하게 되는 과정에서 경험한 다양한 고군분투기를 연재하고 있습니다.현재 운영중인 스팀헌트 (Steemhunt)는 전 세계 2,500개가 넘는 블록체인 기반 앱들 중에서 Top 10에 들어갈 정도로 전 세계 150개국 이상의 많은 유저들을 보유한 글로벌 디앱 (DApp - Decentralised Application) 입니다 (출처 - https://www.stateofthedapps.com/rankings).스팀헌트 웹사이트 바로가기