한계에서 이어진 나의 앱스토어 성공과 실패 이야기

폰에 있는 캘린더를 보아라. 나와 비슷하다면 캘린더에 있는 일정은 회의, 만날 장소, 할 일, 만날 사람들로 가득하고 빈 공간은 많지 않을 것이다. 캘린더를 좋아하는 이들은 별로 없다. 그래서 우리는 스스로 캘린더를 바꿨고 그 과정에서 많이 배웠다.

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

한계를 수용하다

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

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

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

• 개발에 필요한 자금이 없다.
• 서버를 구축하는 방법을 모른다.
• 캘린더와 시간을 계산하는 일이 얼마나 복잡한지 모른다.
• 앱스토어에서 앱을 팔아본 경험이 없다.

이런 한계들은 다루기가 힘들지만 보이지 않는 이로움도 있다. 월급을 지급하지 못했기에 친구이자 디자이너인 휴스턴^Houston은 모바일 디자인을, 1학년 때 룸메이트였던 네이선^Nathan은 캘린더 계산 방법 및 C++를, 난 Objective-C를 공부했다. 허접했지만 스스로 노력해서 마침내 앱을 완성했다.

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

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

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

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

출시하다

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

폭풍 전의 고요함

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

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

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

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

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

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

• 다운로드 수
  지금까지 200,000명 이상의 사용자들이 앱을 다운로드했다. 그런데 우리는 웹사이트와 소셜 페이지를 제외하고 마케팅을 해 본 적이 없다.
• 국가
  전 세계 150개가 넘는 나라에서 앱을 사용하고 있다(영어만 지원하는 데도!). 놀랍게도 미국은 전체 수익의 48%와 전체 사용자의 35%만 차지한다.
• 시간
  앱 출시 후, 2달간 익명의 세션 사용을 추적한 이후 프리타임 사용자는 2년 동안에 이 앱을 사용하고 있다. 사람들의 시간을 아껴주려는 앱인데 좀 아이러니하다.
• 칭찬
  CNN, ReadWriteWeb, Lifehacker, AppAdvice에서는 앱에 대한 기사와 프로필을 썼고, 애플에서는 손꼽을 정도로 추천했다.
• 금액
  처음엔 무료였다. 다운로드 수가 많은 원인들 중에 하나였을 것이다. 그렇다고 해도 앱스토어에서 결제하는 인앱in-app 구매와 결제 모델로 프리타임 수익은 과거 3년 동안 우리 셋이 매일 커피를 사서 마실 정도였다. 삶을 지탱할 정도가 아니었지만, 우리는 자부심을 느꼈다. 수익과 더불어 프리타임 덕분에 각자의 삶을 유지할 직업을 찾았다.

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

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

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

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

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

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

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

2. 반복 과정 준비하기

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

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

첫 번째 생각, 공유

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

새로운 인라인 접근

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

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

완성품

최종 수정에서 우리는 가능한 많은 이벤트를 보여주고자 캘린더 공간을 늘렸다. 또한 어느 화면에서든지 껐다 켰다 해서 사용자가 모달 작업을 공유하도록 했다. 캘린더 UI에 더 초점을 맞춰서 때마다 즉시 그리고 애플의 캘린더 앱에 익숙한 사용자에게 편리한 방법이다. 사용자가 여유 시간을 선택할 수 있다는 생각을 갖도록 할 수 있었다.

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

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

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

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

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

• 사람들은 그들의 캘린더 상단에서 여유 시간을 볼 수 있다.
• 빠른 필터 검색도구로 특정한 식사 시간, 날, 기간 동안에 여유 시간을 찾을 만한 사용자 지정 검색을 사용할 수 있다.
• 사용자는 여유 시간 범위를 좁히기 위해서 깨어 있는 시간과 더불어 근무 시간을 명확히 지정할 수 있다.
• 캘린더를 변경하면 프리타임에도 그 내용이 반영된다.
• 화면에 보이는 시간 단위를 구체화하고 사용자 선호도에 맞춰 특정 시간 단위를 쪼갤 수 있는 복잡한 알고리즘을 개발했다.
• 식사하는 동안 여유 시간을 간략히 보기로 확인할 수 있다.
• 특정한 시간 범위, 날, 식사 시간, 기간 동안에 여유 시간을 검색할 수 있다.
• 이메일, 클립보드로 복사하기, (단축된 텍스트를 지원하는 특정 버전) 문자 메시지, 그리고 폰 흔들기^{bumping phones}(그때 유행이었다)를 해서 여유 시간을 공유할 수 있다.
• 두 사람이 시간을 공유하면 특정 파일 유형으로 각자의 여유 시간을 볼 수 있고 둘의 공통된 여유 시간을 보여주는 (전용) 화면도 볼 수 있다.
• 이벤트 편집하기, 새로운 이벤트 등록하기, 온종일 하는 이벤트 보여주기, 중첩되어 서로의 위에 포개어진 이벤트 조정하기 같은 캘린더 앱에서 지원하는 모든 기능은 프리타임에서도 제공한다.

사람들이 새로운 방식으로 여유 시간을 볼 수 있는 단 하나의 기능은 정말 중요하다는 사실이 밝혀졌다. 우리가 분석한 자료에 따르면, 전체 시간 중 95%는 사람들이 캘린더를 보고 여유 시간을 확인하고 그들만의 방식으로 앱을 사용했다. 검색 필터 기능을 사용하지 않고(사용자의 8%만 사용했다) 공유하지 않으며(사용자의 2%만 공유했다) 둘 다 한가할 때를 알려고 폰을 흔들지 않았다(사용자의 0.002%만 폰을 흔들었다).

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

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

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

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

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

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

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

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

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

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

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

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

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일)은 내가 좋아하는 날이었다. 적극적인 앱 사용자들 거의 전부가 우리에게 이메일을 보내거나 트윗을 해서 앱이 하루 늦어졌다고 알려줬다(마치 한 달 동안 그랬던 것처럼).

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

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

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

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

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

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

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

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

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

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

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

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

• 사용자의 50%만 6일 이상 앱을 사용함.
• 15~20%만 한 달 후 다시 사용함.
• 2012년과 2013년 사이에 59%까지 세션 감소. 55%까지 평균 세션시간 감소(1분 34초까지 줄어듦). 61%까지 사용자 수 감소(20,000명까지 줄어듦).

사람들은 사용하는 소프트웨어와 심리적 유대감을 형성한다. 앱스토어에서 프리타임이 존재함으로써 사람들에게 이메일을 꾸준히 받았다. 그들은 특별히 앱을 얼마나 좋아하고 캘린더를 보던 방식이 완전히 바뀌었는지 전해주었다. 사람들이 매일 사용할 앱을 구축할 때 시간이 지나면서 어떻게 앱을 개선할지, 고객 요구에 어떻게 적응할지를 생각하라.

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

요약

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

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

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

• 당신의 한계를 받아들이고 장점으로 이용하라.
• 사람들의 사고방식을 전환하는 것을 만들어서 늘 당신을 기억하게 하라.
• 수정을 자주 반복하는 일을 두려워하지 말고 반복할 때마다 (기능을) 더 추가하려는 욕구를 억제하라.
• 본능을 믿고 좋아하는 것을 (다른 이들이 좋아하지 않더라도) 제작하라.
• 본인의 세계가 아닌 전 세계를 무대로 제작하라.
• 포기하지 마라.

아! 그리고 캘린더 앱을 개발하는 것은 신중히 생각해야 한다. 여유 시간에 진을 홀딱 빼놓을 수 있기 때문이다! 프리타임 2의 소식을 듣고 싶다면 가입하고, 아니면 앱스토어에서 프리타임을 확인할 수 있다.